Research

From Brian Krebs’ awesome reporting on the Target breach (emphasis added): The source close to the Target investigation said that at the time this POS malware was installed in Target’s environment (sometime prior to Nov. 27, 2013), none of the 40-plus commercial antivirus tools used to scan malware at virustotal.com flagged the POS malware (or any related hacking tools that were used in the intrusion) as malicious. “They were customized to avoid detection and for use in specific environments,” the source said. That source and one other involved in the investigation who also asked not to be named said the POS malware appears to be nearly identical to a piece of code sold on cybercrime forums called BlackPOS, a relatively crude but effective crimeware product. BlackPOS is a specialized piece of malware designed to be installed on POS devices and record all data from credit and debit cards swiped through the infected system. I swear I’ve been briefed by a large percentage of those vendors on how their products stop 0-day attacks. Let me go find my notes… Share:

I am currently polishing off the first draft of my Data Security for iOS 7 paper, and reached one fascinating conclusion during the research which I want to push out early. Apple’ approach is implementing is very different from the way we normally view BYOD. Apple’s focus is on providing a consistent, non-degraded user experience while still allowing enterprise control. Apple enforces this by taking an active role in mediating mobile device management between the user and the enterprise, treating both as equals. We haven’t really seen this before – even when companies like Blackberry handle aspects of security and MDM, they don’t simultaneously treat the device as something the user owns. Enough blather – here you go… Apple has a very clear vision of the role of iOS devices in the enterprise. There is BYOD, and there are enterprise-owned devices, with nearly completely different models for each. The owner of the device defines the security and management model. In Apple’s BYOD model users own their devices, enterprises own enterprise data and apps on devices, and the user experience never suffers. No dual personas. No virtual machines. A seamless experience, with data and apps intermingled but sandboxed. The model is far from perfect today, with one major gap, but iOS 7 is the clearest expression of this direction yet, and only the foolish would expect Apple to change any time soon. Enterprise-owned devices support absolute control by IT, down to the new-device provisioning experience. Organizations can degrade features as much as they want and need, but the devices will, as much as allowed, still provide the complete iOS experience. In the first case users allow the enterprise space on their device, while the enterprise allows users access to enterprise resources; in the second model the enterprise owns everything. The split is so clear that it is actually difficult for the enterprise to implement supervised mode on an employee-owned device. We will explain the specifics as we go along, but here are a few examples to highlight the different models. On employee owned devices: The enterprise sends a configuration profile that the user can choose to accept or decline. If the user accepts it, certain minimal security can be required, such as passcode settings. The user gains access to their corporate email, but cannot move messages to other email accounts without permission. The enterprise can install managed apps, which can be set to only allow data to flow between them and managed accounts (email). These may be enterprise apps or enterprise licenses for other commercial apps. If the enterprise pays for it, they own it. The user otherwise controls all their personal accounts, apps, and information on the device. All this is done without exposing any user data (like the user’s iTunes Store account) to the enterprise. If the user opts out of enterprise control (which they can do whenever they want) they lose access to all enterprise features, accounts, and apps. The enterprise can also erase their ‘footprint’ remotely whenever they want. The device is still tied to the user’s iCloud account, including Activation Lock to prevent anyone, even the enterprise, from taking the device and using it without permission. On enterprise owned devices: The enterprise controls the entire provisioning process, from before the box is even opened. When the user first opens the box and starts their assigned device, the entire experience is managed by the enterprise, down to which setup screens display. The enterprise controls all apps, settings, and features of the device, down to disabling the camera and restricting network settings. The device can never be associated with a user’s iCloud account for Activation Lock; the enterprise owns it. This model is quite different from the way security and management were handled on iOS 6, and runs deeper than most people realize. While there are gaps, especially in the BYOD controls, it is safe to assume these will slowly be cleaned up over time following Apple’s usual normal improvement process. Share:

Today I am going to write about tokenization. Four separate people have sent me a questions about tokenization in the last week. As a security paranoiac I figured there was some kind of conspiracy or social engineering going on – this whole NSA/Snowden/RSA thingy has me spooked. But after I calmed down and realized that these are ‘random’ events, I recognized that the questions are good and relevant to a wider audience, so I will answer a couple of them here on the blog. In no particular order: “What is throttling tokenization?” and “How common is the ‘PCI tokenization throttle function’ in tokenization products and services?” I first heard about “throttling tokenization systems” and “rate limiting functions” from the card brands as a secondary security service. As I understand the intention, it is to provide, in case a payment gateway is compromised or an attacker gains access to a token service, a failsafe so someone couldn’t siphon off the entire token database. My assumption was that this rate monitor/throttle would only be provided on de-tokenization requests or vault inquiries that return cardholder information. Maybe that’s smart because you’d have a built-in failsafe to limit information leakage. Part of me thinks this is more misguided guidance, as the rate limiting feature does not appear to be in response to any reasonable threat model – de-tokenization requests should be locked down and not available through general APIs in the first place!!! Perhaps I am not clever enough to come up with a compromise that would warrant such a response, but everything I can think of would (should) be handled in a different manner. But still, as I understand from conversations with people who are building tokenization platforms, the throttling functions are a) a DDoS protection and b) a defense against someone who figures out how to request all tokens in a database. And is it common? Not so far as I know – I don’t know of any token service or product that builds this in; instead the function is provided by other fraud and threat analytics at the network and application layers. Honestly, I don’t have inside information on this topic, and one of the people who asked this question should have had better information than I do. Do you still write about tokenization? Yes. Are you aware of any guidance in use of vault-less solutions? Are there any proof points or third-party validations of their security? For the audience, vault-less tokenization solutions do not store a database of generated tokens – they use a mathematical formula to generate them, so no need to store that which can be easily derived. And to answer the question, No, I am not aware of any. That does not mean no third-party validation exists, but I don’t follow these sorts of proofs closely. What’s more, because the basic design of these solutions closely resemble a one-time pad or similar, conceptually they are very secure. The proof is always in the implementation, so if you need this type of validation have your vendor provide a third-party validation by people qualified for that type of analysis. Why is “token distinguishability” discussed as a best practice? What is it and which vendors provide it? Because PCI auditors need a way to determine whether a database is full of real credit cards or just tokens. This is a hard problem – tokens can and should be very close to the real thing. The goal for tokens is to make them as real as possible so you can use them in payment systems, but they will not be accepted as actual payment instruments. All the vendors potentially do this. I am unaware of any vendor offering a tool to differentiate real vs. tokenized values, but hope some vendors will step forward to help out. Have you seen a copy of the tokenization framework Visa/Mastercard/etc.? announced a few months back? No. As far as I know that framework was never published, and my requests for copies were met with complete and total silence. I did get snippets of information from half a dozen different people in product management or development roles – off the record – at Visa and Mastercard. It appears their intention was to define a tokenization platform that could be used across all merchants, acquirers, issuers, and related third parties. But this would be a platform offered by the brands to make tokenization an industry standard. On a side note I really did think, from the way the PR announcement was phrased, that the card brands were shooting for a cloud identity platform to issue transaction tokens after a user self-identified to the brands. It looked like they wanted a one-to-one relationship with the buyer to disintermediate merchants out of the payment card relationship. That could be a very slick cloud services play, but apparently I was on drugs – according to my contacts there is no such effort. And don’t forget to RSVP for the 6th annual (really, the 6th? How time flies ….) Securosis Disaster Recovery Breakfast during the RSA Conference. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian quoted in DBaaS article. Rich talks with Dennis Fisher about the Target breach (podcast). Favorite Securosis Posts Rich: Security Management 2.5: Negotiation. I hate negotiating. Some people live for it, but I can’t be bothered. On that note, I need to go buy a car. David Mortman: Firestarter: Crisis Communications. Mike Rothman: Security Management 2.5: Negotiation. This is a great post. A solid plan for buying any big-ticket item. Adrian Lane: Apple’s Very Different BYOD Philosophy. Nobody else has covered this to my knowledge, but Rich describes it very clearly. Enterprise-owned devices are simpler, but iOS almost seamlessly handles the division between enterprise and user domains on BYOD gear. Not very dramatic but simple and effective. Other Securosis Posts A Very Telling Antivirus Metric. Reducing Attack Surface with Application Control: Use Cases and Selection Criteria. Incite 1/15/2014: Declutter. Advanced Endpoint and Server Protection: