Research

Mr. Carr, I read your interview with Bill Brenner in CSO magazine today, and I sympathize with your situation. I completely agree that the current system of standards and audits contained in the Payment Card Industry Data Security Standard is flawed and unreliable as a breach-prevention mechanism. The truth is that our current transaction systems were never designed for our current threat environment, and I applaud your push to advance the processing system and transaction security. PCI is merely an attempt to extend the life of the current system, and while it is improving the state of security within the industry, no best practices standard can ever fully repair such a profoundly defective transaction mechanism as credit card numbers and magnetic stripe data. That said, your attempts to place the blame of your security breach on your QSAs, your external auditors, are disingenuous at best. As the CEO of a large public company you clearly understand the role of audits, assessments, and auditors. You are also fundamentally familiar with the concepts of enterprise risk management and your fiduciary responsibility as an officer of your company. Your attempts to shift responsibility to your QSA are the accounting equivalent of blaming your external auditor for failing to prevent the hijacking of an armored car. As a public company, I have to assume your organization uses two third-party financial auditors, and internal audit and security teams. The role of your external auditor is to ensure your compliance with financial regulations and the accuracy of your public reports. This is the equivalent of a QSA, whose job isn’t to evaluate all your security defenses and controls, but to confirm that you comply with the requirements of PCI. Like your external financial auditor, this is managed through self reporting, spot checks, and a review of key areas. Just as your financial auditor doesn’t examine every financial transaction or the accuracy of each and every financial system, your PCI assessor is not responsible for evaluating every single specific security control. You likely also use a public accounting firm to assist you in the preparation of your books and evaluation of your internal accounting practices. Where your external auditor of record’s responsibility is to confirm you comply with reporting and accounting requirements and regulations, this additional audit team is to help you prepare, as well as provide other accounting advice that your auditor of record is restricted from. You then use your internal teams to manage day to day risks and financial accountability. PCI is no different, although QSAs lack the same conflict of interest restrictions on the services they can provide, which is a major flaw of PCI. The role of your QSA is to assure your compliance with the standard, not secure your organization from attack. Their role isn’t even to assess your security defenses overall, but to make sure you meet the minimum standards of PCI. As an experienced corporate executive, I know you are familiar with these differences and the role of assessors and auditors. In your interview, you state: The audits done by our QSAs (Qualified Security Assessors) were of no value whatsoever. To the extent that they were telling us we were secure beforehand, that we were PCI compliant, was a major problem. The QSAs in our shop didn’t even know this was a common attack vector being used against other companies. We learned that 300 other companies had been attacked by the same malware. I thought, ‘You’ve got to be kidding me.’ That people would know the exact attack vector and not tell major players in the industry is unthinkable to me. I still can’t reconcile that.” There are a few problems with this statement. PCI compliance means you are compliant at a point in time, not secure for an indefinite future. Any experienced security professional understands this difference, and it was the job of your security team to communicate this to you, and for you to understand the difference. I can audit a bank one day, and someone can accidently leave the vault unlocked the next. Also, standards like PCI merely represent a baseline of controls, and as the senior risk manager for Heartland it is your responsibility to understand when these baselines are not sufficient for your specific situation. It is unfortunate that your assessors were not up to date on the latest electronic attacks, which have been fairly well covered in the press. It is even more unfortunate that your internal security team was also unaware of these potential issues, or failed to communicate them to you (or you chose to ignore their advice). But that does not abrogate your responsibility, since it is not the job of a compliance assessor to keep you informed on the latest attack techniques and defenses, but merely to ensure your point in time compliance with the standard. In fairness to QSAs, their job is very difficult, but up until this point, we certainly didn’t understand the limitations of PCI and the entire assessment process. PCI compliance doesn’t mean secure. We and others were declared PCI compliant shortly before the intrusions. I agree completely that this is a problem with PCI. But what concerns me more is that the CEO of a public company would rely completely on an annual external assessment to define the whole security posture of his organization. Especially since there has long been ample public evidence that compliance is not the equivalent of security. Again, if your security team failed to make you aware of this distinction, I’m sorry. I don’t mean this to be completely critical. I applaud your efforts to increase awareness of the problems of PCI, to fight the PCI Council and the card companies when they make false public claims regarding PCI, and to advance the state of transaction security. It’s extremely important that we, as an industry, communicate more and share information to improve our security, especially breach details. Your efforts to build an end to end encryption mechanism, and your use

Yesterday I published an article over at TidBITS describing how Apple’s implementation of encryption on the iPhone 3GS is flawed, and as a result you can circumvent it merely by jailbreaking the device. In other words, it’s almost like having no encryption at all. Over on Twitter someone mentioned this was discussed on the Risky Business podcast (sorry, I’m not sure which episode and can’t see it in the show notes) and might be because Apple intended the encryption only as a remote wipe tool (by discarding the key), not as encryption to protect the device from data recovery. While this might be true, Apple is clearly marketing the iPhone 3GS encryption as a security control for lost devices, not merely faster wipes. Again, I’m only basing this on third-hand reports, but someone called it a “design feature”, not a security flaw. Back in my development days we always joked that our bugs were really features. “No, we meant it to work that way”. More often than not these were user interface or functionality issues, not security issues. We’d design some bass ackwards way of getting from point A to B because we were software engineers making assumptions that everyone would logically proceed through the application exactly like us, forgetting that programmers tend to interact with technology a bit differently than mere mortals. More often than not, design flaws really are design flaws. The developer failed to account for real world usage of the program/device, and even if it works exactly as planned, it’s still a bug. Over the past year or so I’ve been fascinated by all the security related design flaws that keep cropping up. From the DNS vulnerability to clickjacking to URI handling in various browsers to pretty much every single feature in every Adobe product, we’ve seen multitudes of design flaws with serious security consequences. In some cases they are treated as bugs, while in other examples the developers vainly defend an untenable position. I don’t know if the iPhone 3GS designers intended the hardware encryption for lost media protection or remote wipe support, but it doesn’t matter. It’s being advertised as providing capabilities it doesn’t provide, and I can’t imagine a security engineer wasting such a great piece of hardware (the encryption chip) on such a mediocre implementation. My gut instinct (since we don’t have official word from Apple) is that this really is a bug, and it’s third parties, not Apple, calling it a design feature. We might even see some PR types pushing the remote wipe angle, but somewhere there are a few iPhone engineers smacking their foreheads in frustration. When a design feature doesn’t match real world use, security or otherwise, it’s a bug. There is only so far we can change our users or the world around our tools. After that, we need to accept we made a mistake or a deliberate compromise. Share:

A few of us had a bit of a discussion via Twitter on the size of a particular market today. Another analyst and I disagreed on the projected size for 2009, but by a margin that’s basically a rounding error when you are looking at tech markets (even though it was a big percentage of the market in question). I get asked all the time about how big this or that market is, or the size of various vendors. This makes a lot of sense when talking with investors, and some sense when talking with vendors, but none from an end user. All market size does is give you a general ballpark of how widely deployed a technology might be, but even that’s suspect. Product pricing, market definition, deployment characteristics (e.g., do you need one box or one hundred), and revenue recognition all significantly affect the dollar value of a market, but have only a thin correlation with how widely deployed the actual technology is. There are some incredibly valuable technologies that fall into niche markets, yet are still very widely used. That’s assuming you can even figure out the real size of a market. Having done this myself, my general opinion is the more successful a technology, the less accurately we can estimate the market size. Public companies rarely break out revenue by product line; private companies don’t have to tell you anything, and even when they do there are all sorts of accounting and revenue recognition issues that make it difficult to really narrow things down to an accurate number across a bunch of vendors. Analysts like myself use a bunch of factors to estimate current market size, but anyone who has done this knows they are just best estimates. And predicting future size? Good luck. I have a pretty good track record in a few markets (mostly because I tend to be very conservative), but it’s both my least favorite and least accurate activity. I tend to use very narrow market definitions which helps increase my accuracy, but vendors and investors are typically more interested in the expansive definitions no one can really quantify (many market size estimates are based on vendor surveys with a bit of user validation, which means they tend to skew high). For you end users, none of this matters. Your only questions should be: Does the technology solve my business problem? Is the vendor solvent, and will they be around for the lifetime of this product? If the vendor is small and unstable, but the technology is important to our organization, what are my potential switching costs and options if they go out of business? Can I survive with the existing product without support & future updates? Some of my favorite software comes from small, niche vendors who may or may not survive. That’s fine, because I only need 3 years out of the product to recover my investment, since after that I’ll probably pay for a full upgrade anyway. The only time I really care is when I worry about vendor lock-in. If it’s something you can’t switch easily (and you can switch most things far more easily than you realize), then size and stability matter more. Photo courtesy http://flickr.com/photos/31537501@N00/260289127, used according to the CC license. Share:

This week we wrap up our coverage of Defcon and Black Hat with a review of some of our favorite sessions, followed by a couple quick news items. But rather than a boring after-action report, we enlisted Chris Hoff to provide his psychic reviews. That’s right, Chris couldn’t make the event, but he was there with us in spirit, and on tonight’s show he proves it. Chris also debuts his first single, “I Want to Be a Security Rock Star”. Your ears will never be the same. Network Security Podcast, Episode 161; Time: 41:22 Show Notes Chris Hoff’s Psychic Review Fake ATM discovered at DefCon. Korean intelligence operatives pretending to be journalists at Black Hat? Cloud Security Podcast with Chris Hoff and Craig Balding Tonight’s Music: I Want to Be a Security Rock Star Share:

Next week I’ll be joining Ron Gula of Tenable and Eric Cole of SANS and Secure Anchor to talk about the (relatively) recently released SANS Consensus Audit Guidelines. Basically, we’re going to put the CAG in context and roll through the controls as we each provide our own recommendations and what we’re seeing out there. I’m also going to sprinkle in some Project Quant survey results, since patching is a big part of the CAG. The CAG is a good collection of best practices, and we’re hoping to give you some ideas on how they are really being implemented. You can sign up for the webinar here, and feel free to comment or email me questions ahead of time and I’ll make sure to address them. It’s being held Thursday, August 13th at 2pm ET. Share:

Update: based on questions over email- this is only part time and we expect you to have another job, and we are looking for 1-2 people to test the idea out. Also, if you are on the Contributing Analyst track, we’ll focus more on research and writing, and you won’t be asked to do much of normal intern-level stuff. Over the years we’ve met a heck of a lot of smart people, many of whom we’d like to work with, but we haven’t really had a good mechanism to pull off direct collaboration under the Securosis umbrella. Like pretty much any self-funded services company on the face of the planet, we need to be super careful on managing growth to limit overhead. We’ve also been dropping some activities over here that aren’t at the top of the to-do list, which is just as dangerous as bloated overhead. Right before Black Hat I tweeted that we were thinking of starting an intern program, and I received a bigger response than expected. Some of these people are far too qualified for an “intern” title. It also got us thinking that there might be some creative ways to pull other people in, without too much overhead or unrealistic commitments on either side. Being something of community and social media junkies, we also thought we’d like to incorporate some of those ideas into whatever we come up with. Thus we’re officially announcing our intern and Contributing Analyst program. Here’s what we are thinking, and we are open to other ideas: The intern program is for anyone with a good security background who’s also interested in learning what it’s like to be an analyst. We’ll ask for some cheap labor (writing projects, site maintenance, other general help) and in exchange we’ll bring you in, show you the analyst side, and give you access to our resources. We’ll pay for certain scut work, but it won’t be a lot. Floggings will be kept to a minimum, unless you are into that sort of thing. The Contributing Analyst positions are for experienced industry analysts, or others capable of contributing high quality research and analysis. We will ask you to blog occasionally and bring you in on specific projects. We will also support you if you bring in your own projects. In exchange, we will pay you the same rates we pay ourselves on projects, including some of the research products we are planning on producing. In both cases you will be part of the Securosis team – participating on briefings, using our resources, and so on. We realize there might be the occasional conflict of interest, depending on your current employer. Anyone in either program will be restricted from writing about anything that promotes, or potentially promotes, their current employer and will be restricted from briefings and proprietary materials from competitors. You’ll have to be firewalled off from any conflicts. Also, any potential conflicts will be disclosed on your site bio and in any publications. You’ll have to sign a contract agreeing to all this. You’ll get a Securosis email, direct blog access, internal collaboration server access, business cards, editorial support and use of anything else – like our SurveyMonkey account, and so on. We are really persnickety about how we write and the quality of our work. Anything you publish under our name will have to get approved by a full-time analyst and go through an editorial process that may be considered brutal, if not outright sadistic. We’ll train interns up, but any Contributing Analyst will be expected to write at the same level we do, and reviewed too. Unless you are already an established industry analyst (or have that experience) we will have you start in the intern program for a minimum of 3 months. This is so we can feel each other out and make sure it’s going to work. Anyone in either program can eventually become a full timer, if the workload and quality supports it. We don’t plan on “dictating” to people. We want to give you freedom to explore different research projects and new ideas. We’re totally up for helping implement (and even funding) good ideas as long as they support our no-bull totally transparent research philosophies. Basically, we want to expand the community of people we work with directly, even if it’s not a traditional employee/employer relationship. Eventually we’d love to have a network of contributors of different types, and this is only a first step. There are perspectives out there that no full-time analyst will ever get, by the nature of the job, and this might be a way to expand that window. We also think we can support some new, interesting kinds of research that might be difficult to perform someplace else. Think of us as a platform, especially since we don’t feel compelled to directly monetize everything we do. If you are interested, please email us at info@securosis.com. We’ll need a resume, bio, which program you are interested in, and why. We’ll have an interview process that will require some writing, presenting, and an interview or two. We only plan on taking a couple people at a time since it can take a lot of time to get someone up and running, but we’ll stack rank and fill in as we have the capacity to support people. Share:

First, a bit of a caveat. Andrew Jaquith of Forrester is an excellent analyst and someone I know and respect. This is a criticism of a single piece of his research, and nothing more. Over at the Forrester Security Blog today, Andrew posted a change of policy on their use of two important data security terms. In short, they will now be using the term Data Labeling instead of Enterprise Rights Management: So, here’s what Forrester will do in our future coverage. The ERM (enterprise rights management) acronym will vanish, except as a “bridge” term to jog memories. In the future, we will practice “truth in labeling” and call this ERM thing data labeling. Unfortunately, this is a factually incorrect change since data labeling already exists. I agree with Andrew that ERM is a terrible term – in large part because I’ve covered Enterprise Risk Management, and know there are about a dozen different uses for that acronym. Personally, I refuse to use ERM in this context, and use the term Enterprise DRM (Digital Rights Management). Enterprise Rights Management is a term created to distinguish consumer DRM from enterprise DRM, in no small part because nearly everyone hates consumer DRM. The problem is that data labeling is also a specific technology with an established definition. One we’ve actively criticized in the past. Andrew refers back to the Orange book: Here’s what the Orange Book says about data labeling: “Access control labels must be associated with objects. In order to control access to information stored in a computer, according to the rules of a mandatory security policy, it must be possible to mark every object with a label that reliably identifies the object’s sensitivity level (e.g., classification), and/or the modes of access accorded those subjects who may potentially access the object.” Sounds just like what what ERM is doing, no? No – the difference is under the covers. Data labeling refers to tags or metadata attached to structured or unstructured data to define a classification level. Labels don’t normally include specific handling controls, since those are handled at a layer above the label itself (depends on the implementation). DRM is the process of encrypting data, then applying usage rights that are embedded in the encrypted object. For example, you encrypt a file and define who can view it, print it, email it, or whatever. Any application with access to decrypt the file is designed to respect and enforce those policies… as opposed to regular encryption, which includes no usage rights, and where anyone with the key can read the file. This shows the problem with consumer DRM and why it always breaks – in an enterprise we have more control over locking down the operating environment. In the consumer world, the protected file is always in a hostile environment. Since you have to have the key to decrypt the file, the key and the data are both potentially exposed. Labeling and DRM may work together, but are distinct technologies. You can label an individual record/row in a database, but you can’t apply DRM rights to it (I suppose you could, but it’s completely impractical and there isn’t a single tool on the market for it). You can apply DRM rights to a file without ever applying a classification level. I asked Andrew about this over Twitter, and our conversation went like this (Andrew’s post is first): @rmogull Really? Do you think “ERM” is actually a useful name for that category? Want to discuss alternatives? @arj I use “Enterprise DRM” I also hate ERM and refuse to use it. @rmogull Makes sense. Want to send me an e-mail (or do a blog post) critiquing the post? I’m a pretty good sport. I think we are on the same page now, and thank Andrew for bringing this up, and being willing to take some gentle lumps. Share:

Over the past few weeks we’ve seen yet two more security stories get completely blown out of proportion in the press. The first was, of course, the DDoS attacks that were improperly attributed by most commentators to North Korea. The second, no surprise, was the Great Twitter Hack of 2009, which might also be referred to the Great Cloud Security Collapse. In both cases the stories were not only blown completely out of proportion, but many of the articles devoted more space to hyperbole and innuendo than facts. In the meantime, we had a series of unpatched vulnerabilities being exploited on Internet Explorer and Firefox, placing users at very real risk of becoming a victim. Share:

While Microsoft releases patches for various vulnerabilities, including the two active zero day attacks, Firefox is being actively exploited. According to the Mozilla Security Blog, there is a flaw in how Firefox handles JavaScript. We suggest you follow the instructions in that post to mitigate the flaw until they release a patch (which should be soon). Not that we plan to post every time some piece of software is exploited or patched, but this series seems to… bring some balance to the Force. Share:

Microsoft released an advisory today that an unpatched vulnerability in the Office Web Components ActiveX control allows an attacker to run arbitrary code as the logged-in user. Worse yet, this is being actively exploited in the wild. Fortunately it is easy to protect against. For the technical details, please see the SANS Internet Storm Center post, and the official Microsoft advisory. Here’s the short version and how to protect yourself: This is a flaw in the spreadsheet ActiveX control that comes with Office. It only works if you visit a malicious link with Internet Explorer, and have a vulnerable version of Office installed (if you have Office, it’s safest to assume you are vulnerable). This does not affect Outlook, unless you click on an email link that opens Internet Explorer. It is actively being exploited by bad guys on the Internet, and Microsoft is working on a patch. If you switch to another browser, you are safe. If you still need to use IE, you can click on this link for a tool that will help disable the control. Don’t try this if you are on a work computer without talking to IT. And that’s it – no reason to panic, with plenty of ways to protect yourself. You can now safely ignore all the scary emails you’ll be getting any moment from various security vendors… (This is unrelated to the other ActiveX 0day that popped up last week and is also being actively exploited). Share: