Research

Yesterday I was in Vegas to participate in a panel at IBM’s Information on Demand Conference. To my amusement and frustration, I was already in Vegas that weekend, drove 4.5 hours home to Phoenix on Sunday, then flew back Monday evening (4 hours door to door). The panel was on database security in the cloud, and at one point I came up with an example to show how this sh*t is seriously different than how we do security today. The example below would be nearly impossible in a non-cloud environment. It’s fictional, but there are no technical obstacles to implementing it right now. There is, however, one limitation I will mention at the end. Imagine a world where you have a robust internal cloud to support business units in a large enterprise. This is in contrast to current environments where, if a business unit wants an application or database resource: they submit a request, things are approved (maybe), then physical or virtual assets are acquired, configured, and assigned. You are one of those forward-thinking orgs which stood up your private cloud with a self-service portal where approved managers can dynamically provision a pre-established set of resources. No, this probably isn’t how most of you use the cloud today, but it will be. Now imagine that some of these resource stacks include databases. You are, obviously, concerned with the security and compliance of these databases. This is the sort of thing that used to constantly bite you in the ass, as teams ranging from developers to sub-departments installed their own stuff, loaded sensitive data, and then failed to secure it. But you now sleep soundly at night because… When the user requests the application stack, all operating systems and software are automatically patched to current levels using mandatory installation scripts. The installation scripts also configure the resources to a secure-by-default state, doing things like inserting user credentials, locking down ports, setting appropriate file permissions, configuring application defaults, and so on. You can even automate service account management and cross-link them between application components (heck, we do this in the CCSK Plus training class). All application components instantiate themselves in different, locked-down network security groups. Only required internal ports are open. This can be much more granular and restrictive than current application stacks which require physical hardware to protect. When the database spins up it registers itself with your Database Activity Monitoring (DAM) and assessment tools via their APIs. The DAM tool performs an initial database vulnerability assessment and registers the database for future scans. (Other stack components do similar things, but we’re focusing on the database for this example). Thanks to those cloud APIs, it knows where to look for the database and who created it, and the necessary firewall ports are opened. After the initial DAM scan is complete and passed, the DAM tool makes an API call to the cloud’s network controller to open up any additional ports needed for internal access. Depending on the script, this may be restricted to subnets, individual IPs, and so on. Similar processes are followed for the application and web server components and their various security tools (vulnerability assessment, asset registration, configuration management, etc.). Assuming everything is hunky dory, any last required ports to access the application can be opened up. The user won’t pick this – it will be handled automatically via API and policy scripts. The DAM tool will have installed its monitoring agent at initial launch. The agent connects back to the DAM server and activity is now monitored (including administrative SQL queries). On a specified schedule, the database is scanned for ongoing configuration compliance and vulnerabilities. It is also scanned for sensitive data, using the content discovery feature of your DAM tool and policies tied to the type of application stack deployed and the business unit assigned. If it isn’t supposed to have credit card numbers, but they start appearing, security gets an alert. Think about this for a moment – today people try to spin stuff up all over the place and it’s nearly impossible to find, never mind configure securely. In the example above we completely automate the configuration and security of the application stack (including the database) on a dynamic basis using APIs and policy scripts. The database spins up with secure settings in a secure network; it is centrally registered, actively monitored, and scanned for both problems and sensitive (read ‘regulated’) data on an ongoing basis. Today’s limitation is that very few security tools, by default, support the automation I described above. But things like initialization scripts and dynamic network management via APIs are fundamental to all cloud platforms. Cool, eh? And heck, I’m probably missing a bunch of things Share:

My wife and I are pretty big Jimmy Buffett fans. I first got hooked way back in high school, working as a lifeguard. The summer of my freshman year in college I went with a group of friends down to the Orange Bowl, and we snuck off for a day trip to Key West and a short visit to the very first Margaritaville. I really got hooked when I was deep into paramedic school. In our program you worked or attended classes 80+ hours a week – bouncing around between a bunch of hospitals, fire stations, and ambulance bays throughout the entire Denver Metro area. In the middle of winter I survived all those hours on the road thanks only to a Buffett tape serenading me with sweet visions of beaches and beer. Later, it didn’t hurt that I met my wife at a Buffett show. While he tours consistently year after year, he only hits Phoenix every 2-3 years now. So when we didn’t see our home town on the schedule, a bunch of us decided to get tickets to the Vegas show. Then he added the Denver show. I lived in Boulder for 16 years and still have a big chunk of friends there who convinced me to pop over for the show – especially since I hadn’t seen some of them in 2 years, and Buffett hadn’t played Denver in 8. Then he added the Phoenix show. And that, my friends, is how I managed to sign up for three Jimmy Buffett shows, in three different cities, in three different states in one week. One of which is tonight, and I have to go assemble our new portable grill. So… On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Quiet week. Guess even media whores need some time off. Favorite Securosis Posts Adrian Lane: Tokenization Guidance: Merchant Advice. Rich: Applied Network Security Analysis. Because Mike writes much better section headings than I do. Other Securosis Posts Incite 10/19/2011: The Inquisition. Database Security Market Sizing and Guesstimation. Favorite Outside Posts Adrian Lane: Secret iOS business; what you don’t know about your apps. There are scarier threats to all mobile platforms than what’s mentioned here, but the post does a great job of underscoring that security is only as good as the app developer. And if they want to spy on you… they will. Mike Rothman: The forever recession (and the coming revolution). Seth Godin is the philosopher king of the Internet age. This is a great post about how every recession gives way to unbounded growth. If you can figure out how to deal with the next thing. Read this. Read his stuff. Adapt. Pepper: Georgia Tech Turns iPhone into spiPhone. Fortunately not suitable for even half-decent passwords, but a very clever hack to eavesdrop via an accelerometer. Should work on Android phones too – for now. Rich: Michael Winslow gets the Led out. I know this has nothing to do with security. And I know it’s been all over Twitter. But it’s still the awesomest thing I’ve seen in a while. Research Reports and Presentations Fact-Based Network Security: Metrics and the Pursuit of Prioritization. Tokenization vs. Encryption: Options for Compliance. Security Benchmarking: Going Beyond Metrics. Understanding and Selecting a File Activity Monitoring Solution. Database Activity Monitoring: Software vs. Appliance. React Faster and Better: New Approaches for Advanced Incident Response. Measuring and Optimizing Database Security Operations (DBQuant). Network Security in the Age of Any Computing. Top News and Posts Venafi’s take on Duqu. W32.Duqu: The Precursor to the Next Stuxnet. Supposedly from the Stuxnet authors. New Jersey Transit Embraces Google Wallet. And so it begins. Oracle publishes major patch release. Many database and Java patches. Cloud Security in Datacenter Terms. Google embraces HTTPS. Social Security kept silent about private data breach. We missed this last week. APT – The Plain Hard Truth. RSA blames breach on two hacker clans working for China. I didn’t get to see the talk, and so am still slightly skeptical, but expect more info to come out at RSA this year. Blog Comment of the Week Remember, for every comment selected, Securosis makes a $25 donation to Hackers for Charity. This week’s best comment goes to Patrick, in response to Database Security Market Sizing and Guesstimation. This post raises an interesting issue for me – And that is, what is the purpose of measurement and estimation? Of anything, really – a market, an effect, a potential risk or loss magnitude? In my mind, it’s a matter of accuracy vs precision, bounded by the contextual requirements of how much reduction in uncertainty is required by the subject/decision at hand. Single point estimates, like the one referenced above – are usually not as informative as we might wish. A range, or even an estimated probability distribution, is much more useful, and not that hard to do quickly. How big is the database security market? I don’t know – but that doesn’t mean I couldn’t come up with something useful if I needed to make a decision. The key here is useful, not precise – just about measurement carries some uncertainty. Share:

We’ve been getting some questions about the beta test, so I decided to put an FAQ together which we will also post within the system. If you have any other questions, please feel free to ask: General What is the Securosis Nexus? The Securosis Nexus is an online environment to help you get your job done better and faster. It provides pragmatic research on security topics that tells you exactly what you need to know, backed with industry-leading expert advice to answer your questions. The Nexus was designed to be fast and easy to use, and to get you the information you need as quickly as possible. Who is it for? The Nexus is for anyone with security responsibilities at their organization. We know that most of the people who work on security don’t have ‘Security’ in their titles, but need to protect their business every bit as much as the Chief Information Security Officer of a Fortune 500 company. The Nexus provides pragmatic research and advice for everyone, even if security is only one of the many hats you wear. What’s “pragmatic research”? Pragmatic research is information you can use. The Nexus doesn’t waste your time on theory and background information (although it is available for the curious). The content tells you exactly what you need to get your job done, and makes it very easy to find. Does that mean it tells me how to configure my products? No. The Nexus provides everything except product-specific information. What’s “expert advice”? Through our Ask an Analyst feature you can submit questions directly to our analysts, each with decades of security experience. We know sometimes reading research isn’t enough and you need direct advice from an experienced professional to get a clear answer on your specific issue. What makes this any different from a wiki, Gartner, or something like LinkedIn? The research is specific to security, and the Nexus presents data in several different ways, making it as quick and easy to locate information as possible. Unlike a wiki, all the content is written by professional research analysts, edited by folks who know how to write and topics are covered completely – not a hodge-podge of whatever people want to contribute. It’s far more structured and pragmatic than big analyst firms like Gartner. And unlike LinkedIn and social media sites, you are guaranteed answers to your questions. The Nexus is not just academic reference data – it is written by people who have built and deployed security products for a living. What else is included? Research and specific answers to your questions is core, but the Nexus includes much more. It offers videos, checklists, podcasts, templates, and other tools to help you get your job done. All the research can be rated and commented on, which helps ensure the content is useful and up to date as well as helping us to improve the content over time based on your feedback. The system tracks your history so you never forget what you read, and enables you to build a custom library of your favorite content. Good questions are anonymized and tied back to the content, to help others with the same problems. And we are just getting going, there will be even more capabilities in the coming months. What are the platform requirements? The Nexus should work with all current browsers, as well as Internet Explorer version 7 and later. Although we don’t have an iOS app yet, we have optimized the site to work well on the iPad. Beta Testing When does the beta start? If you are reading this, it has started. Why can’t I log in yet? We are running the beta in phases and will be adding people on an ongoing basis. We are very conservative, and really want to ensure the system is ready before we let too many people in. We will email you when your name comes up, and we plan to eventually include everyone who signs up for the beta. What can I expect in the beta? This is a real beta test – while the entire system is functional, there will be some bugs. We have set up forum for feedback and will directly answer system questions (but not research questions) there. During the beta, we will be adding research on a daily basis. The beta is opening with the first layer of PCI information, but we have a ton more to add before we open the system to the public (and ask people to pay for it). We will post announcements on the portal page as we add material throughout the beta. Right now, the weakest area is multimedia and tools/templates – such as checklists and PowerPoint samples. We will be adding these along with the rest of the content throughout the beta period. Ask an Analyst is completely open for business, so please do your best to stump us. Is the beta free? Yes. In exchange for your help testing, we provide access to all the content as we build it, plus the Ask an Analyst tool for questions. Will I get a free membership after the beta? No. The Nexus will be competitively priced (think hundreds, not thousands), but beta testers will need to subscribe after we open it up to the public. But until then you get all the free research and advice you can eat. Where should I leave feedback? Please use the beta forum linked on the portal page. That provides direct access to our developers and doesn’t clutter up the comments or the rest of the live system. After the beta, will you delete my account? No – you won’t have access, but your account will stay there if you want to come back. You should also review our privacy policy. Privacy Policy The Securosis Nexus does not sell your information to anyone, ever. We do retain the right to sell or distribute bulk statistics (e.g., what content is most viewed, what topics create the

Yesterday afternoon I decided to head out for my first run since my August health scare (which turned out to be pretty much nothing). I grabbed my iPhone, and as I was putting it into my armband case a news alert popped up. Steve Jobs is dead I stopped. The world paused for a moment. Standing in front of my desk, I turned and opened up a web browser to read the press release from the Apple board. It was true, and it wasn’t a surprise. Like nearly all of you reading this, I never met Steve Jobs. Unlike most of you I was fortunate enough to get to attend his last Macworld keynote and experience the reality distortion field myself. I walked in carrying a BlackBerry. I went home with an iPhone. Call the RDF what you will, but I never regretted that decision. I have spoken with other Apple executives, but never the man himself. My love of technology started with Apple and, to a lesser degree, Commodore. That’s when I started hacking; and by hacking I mean exploring. But I never owned an Apple. I didn’t buy my first Mac until 2005; a victim of the halo effect from the beauty of my first iPod (a third gen model). Today there are 6 or so Macs in my house, a couple iPads, a few iPhones, and various other products. Including, still, that third generation iPod I can’t seem to let go. It doesn’t matter if you love or hate Apple – everything we do in technology today is influenced by the work of the teams Steve led. Every computer, every modern phone, and every music player is influenced more by Apple designs than by any other single source. Even the CG animated cartoons my daughter loves so much. I used to criticize Apple. Too expensive. Too constraining. But over the course of several years I have found my own beliefs aligning with the “rules” Jobs defined. People won’t know what they want until you show them. Don’t let customers derail your vision, but be ready to move when they’re right. Design and usability are every bit as important as features – if either fails, the product fails. Remove as much as possible. Imagine if we had a security leader as visionary as Jobs. We have many who might think they are, but no one comes close. Can you imagine Steve in a UI design meeting for nearly any security product on the market? His death hit me harder than I expected. Because not only do we not have a Steve Jobs in security, we no longer have one at all. The entire technology world just lost the one person climbing the hills in front of us, breaking the trail, and turning back to wave and shout “follow me”. Now we’re on our own. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian & Mel Shakir on SIEM Replacement. Rich is giving a webcast on cloud security next week. This is with Dome9, but all the content coming from me is objective and influence-free. Favorite Securosis Posts Adrian Lane: The iPad-Enterprise-Data Security Spectrum. Face it, the iPad is so compelling that it is forcing its way into the enterprise – Rich offers good tips for facing the inevitable. David Mortman: Force Attacker Perfection. Mike Rothman: Force Attacker Perfection – Rich is right. We can’t stop them, but we should make them work for it. Rich: Need a CISO cert? Got $200? Get one while they’re hot…. Other Securosis Posts When to Use Amazon S3 Server Side Encryption. Incite 10/5/2011: Time waits for no one. Nitro & Q1: SIEM/Log Management vendors dropping right and left. Introducing the Securosis Nexus. Incite 9/28/2011: Renewal. Comment on the Next Version of the Cloud Security Alliance Guidance. Favorite Outside Posts Mike Rothman: Text of Steve Job’s Commencement Address (2005). Passed on, but Steve Jobs’ teachings will stick with me forever. I look at this speech every couple of months. Puts everything (life, job, happiness, purpose, etc.) into context for me. Everything. David Mortman: Application-Layer DDoS Attacks Are Growing: Three to Watch Out For. Adrian Lane: The Web won’t be safe, let alone secure, unless we break it. Topics Jeremiah has covered before, but a very nice overview of the situation. Browsers, like many other platforms, have idiotic ‘features’ that make security impossible, and it’s time to throw some of the garbage out. Rich: The Vendor Beating. I’ve been in similar meetings as an analyst. Nothing beats the blame game. Dave Lewis: Some SCADA Problems Too Big to Call Bugs. Yeah… That will fix it. Top News and Posts Amex XSS Vuln But it’s the twitter dialog that’s worth reading. This is just so typical for a McBank response to any inquiry – they can only follow the script. Awesome. Tool to crack SSL. Hacker nabbed after topping up three EasyCards. Using ICMP Reverse Shell to Remotely Control a Host. Privacy and security implications of Amazon’s new “Silk” browser. Microsoft Pushes Emergency Update After Security Products Call Chrome “Banking Trojan” Cisco patches the other iOS. Blog Comment of the Week Remember, for every comment selected, Securosis makes a $25 donation to Hackers for Charity. This week’s best comment goes to Bill, in response to Nitro & Q1: SIEM/Log Management vendors dropping right and left. Excellent analysis. Until recently, SIEM vendors were a kind of “Switzerland” with respect to third party event sources, i.e, treating them all the same for the most part. I think customers will become concerned if the big three manufacturers start favoring their own complementary security products. What do you think? Share:

As I mentioned in the Incite yesterday, Symantec announced DLP support for the iPad. I have been meaning to talk about this for a while, as various products have been popping onto the market, and now seems like the time. Note: I’m focusing on the iPad because that’s what most people are interested in, but much of what I’m going to talk about also applies to the iPhone. The iPad is an extremely secure device; odds are it is much more secure than any laptop or desktop you let your users on. The main reason is that it is locked down so tightly with a combination of hardware and software controls. This is also a challenge for security, because you can’t run any background tasks. For the record, I really like this approach – it eliminates the need for things like antivirus in the first place. For data security, that means we are limited in what we can do. No DLP running in the background, for example. To fill this gap, a spectrum of approaches and tools have hit the market. I like to list them as a spectrum from least control to most. Most control doesn’t mean it’s better – which of these to use depends heavily on the needs of both your organization and your users. As a baseline I assume you allow access to corporate assets in some way using the device. I’m skipping the “do nothing” and “don’t let them in at all” options: Here we go: ActiveSync and device profiles. You allow users access to corporate email, but enforce a basic device profile to require a passcode/password and enable remote wiping if the device is lost. This enables basic encryption of the entire device (easier to crack), with data protection for email attachments. Server-side DLP. You create DLP policies that restrict the email/files going to an otherwise approved device. Websense offers this – not sure who else. Walled-garden applications. These are apps like Good for Enterprise, the new Zenprise SharePoint client for iPad, Watchdox, and GroupLogic mobilEcho. All access to documents is purely through the approved app, and the app can restrict opening or usage of that document elsewhere on the device. Remember, if you don’t totally wall the content off, any standard document format can be opened in another app – thus losing any security controls. These usually offer viewing but not editing, because that would require building in a complete editor. There is a very broad range of variation between these apps. Fully-managed device with always-on VPN. You use mobile device management (MDM) to enforce an always-on VPN connection and block unmanaged network traffic. Then you use DLP on your network to manage traffic and content. This is how Symantec works. They use an app on the device to enforce the VPN, and made changes on the DLP gateway to improve the user experience with the device. For example, the iPad doesn’t handle failed email connections well (it tends to stall), so they had to play games to block protected content from going to Gmail without ruining the device experience. Each of these models has its own advantages, and there are different levels of control within each tier. But these should give you a good idea of the options. Someday I might write a paper with more detail, but hopefully this is enough for now. Share:

This week Amazon announced that S3 now supports server side encryption. You can encrypt S3 items through either the API or web management console, or you can require encryption for S3 buckets. A few details: They manage the keys. This is full transparent AES-256 encryption, and you only manage the access controls. Encryption is at the object level, not the bucket level. You can set a policy to require any uploads into a bucket to be encrypted. You can manage it via API or the AWS Management Console. It’s interesting, but from a security perspective only protects you from one thing – hard drives lost or stolen from Amazon. Going back to my Three Laws of Data Encryption, you would use this if you are worried about lost/stolen drives or if someone says you have to encrypt. It doesn’t protect from hacking attacks or anything like that. Client-side encryption is more important for improving security. This isn’t really much of a security play, but it’s a big assurance/compliance play. Since I like bullet lists and clear advice, you should use S3 server side encryption: If you are required to encrypt data at rest, and said requirement does not also require you to segregate keys from Amazon. You want to market that you are encrypting the data, but still don’t have a requirement to lock out Amazon. That’s about it. If you are worried about drive loss/theft it’s probably due to a compliance or disclosure requirement, and so I recommend client side encryption instead, for its greater security benefit. This is a checkbox. Sometimes you need them, but if security is that important you have other options which should be higher priority. Share:

I will fully admit that I sometimes finding myself parroting standard industry tropes. For example, I can’t recall how many times I’ve said in presentations and interviews: The defender needs to be perfect all the time. The attacker only needs to succeed once. And yes, it’s totally true. But we spend so much time harping on it that we forget how we can turn that same dynamic to our advantage. If all the attacker cares about is getting in once, that’s true. If we only focus on stopping that first attack, it’s still true. But what if we shift our goal to detection and containment? Then we open up some opportunities. As defenders, the more barriers and monitors we put in place, the more we demand perfection from attackers. Look at all those great heist movies like Ocean’s 11 – the thieves have to pass all sorts of hurdles on the way in, while inside, and on the way out to get away with the loot. We can do the same thing with compartmentalization and extensive alert-based monitoring. More monitored internal barriers are more things an attacker needs to slip past to win. Technically it’s defense in depth, but we all know that term has turned into an excuse to buy more useless crap, mostly on the perimeter, as opposed to increasing internal barriers. I am not saying it’s easy. Especially since you need alert-based monitors so you aren’t looking at everything by hand. And let’s be honest – although a SIEM is supposed to fill this role (at least the alerting one) almost no one can get SIEM to work that way without spending more than they wasted on their 7-year ERP project. But I’m an analyst so I get to spout out general philosophical stuff from time to time in hopes of inspiring new ideas. (Or annoy you with my mendacity). Stop wishing for new black boxes. Just drop more barriers, with more monitoring, creating more places for attackers to trip up. Share:

Two years ago I edited the Cloud Security Alliance’s Guidance (v2.1) with a couple other folks, and it nearly ended me. Pulling together a consensus with such a diverse group of global contributors, each running with very few constraints, lead to… certain quality issues. The CSA learned their lesson and Version 3.0 is under much better control. Aside from a lot more consistency and dedicated editors (our own Chris Pepper edited v2.1), the process is much better organized. Many groups have finished their initial work (including mine: Data Security) and the documents are up for public review. You can see the drafts and submit comments. I highly encourage you to get involved if you are interested in cloud security at all. This Guidance will probably live for 2-3 years, and it is already used extensively by end users and vendors to help guide their projects. I could also use some specific review in my domain (Information Management and Data Security): What do you think of the new lifecycle? Did we capture the right controls? Is the technology depth where it needs to be? Did we balance the practical with the strategic? If you don’t want to go through the full track-changes thing, feel free to email me directly or comment here. Thanks Share:

Most security professionals have long understood at least some of the risks of the current ‘web’ or ‘chain’ of trust model for SSL security. To quickly recap for those of you who aren’t hip-deep in this day to day: Your browser knows to trust a digital certificate because it’s signed by a root certificate, generated by a certificate authority, which was included in your browser or operating system. You are trusting that your browser manufacturer properly vetted the organizations which own the roots and sign downstream certificates, and that none of them will issue ‘bad’ certificates. This is not a safe assumption. A new Mac trusts about 175 root certificates, and Apple hasn’t audited any of them. The root certificates are also used to sign certain intermediary certificates, which can then be used to sign other downstream certificates. It’s a chain of trust. You trust the roots, along with every certificate they tell you to trust – both directly and indirectly. There is nothing to stop any trusted (root) certificate authority from issuing a certificate for any domain it chooses. It all comes down to their business practices. To detect a rogue certificate authority, someone who receives a bogus certificate must notice that the certificate they issued is different than the real certificate somehow. If a certificate isn’t signed by a trusted root or intermediary, all browsers warn the user, but they also provide an option to accept the suspicious certificate anyway. That’s because many people issue their own certificates to save money – particularly for internal and private systems. There is a great deal more to SSL security, but this is the core of the problem: we cannot personally evaluate every SSL cert we encounter, so we must trust a core set of root providers to identify (sign) legitimate certs. But the system isn’t centralized, so there are hundreds of root authorities and intermediaries, each with its own business practices and security policies. More than once, we have seen certs fraudulently issued for major brands such as Google and Microsoft, and now we see attackers targeting certificate authorities. We’ve seen two roots hacked this year – Comodo and DigiNotar – and both times the hackers issued themselves fraudulent certs that your browser would accept as valid. There are mechanisms to revoke these things but none of them work well – which is why after major hacks the browser manufactures such as Microsoft, Mozilla, and Apple have to issue software updates. Research in this area has been extensive, with a variety of exploits demonstrated at recent Black Hat/Defcon conferences. I highly recommend you read the EFF’s just-published summary of the DigiNotar issue. It’s a mess. One that’s very hard to fix because: Add-on models, such as Moxie Marlinspike’s Convergence add-on and the Perspectives project are a definite improvement, but only help those educated enough to use them (for the record, I think they are both awesome). The EFF’s SSL Observatory project helps identify the practices of the certificate authorities, but doesn’t attempt to identify breaches or misuse of certificates in real time. DNSSec with DANE could be a big help, but is still nascent and requires fundamental infrastructure changes. Google’s DNS pinning in Chrome is excellent for those using that browser (I don’t – it leaks too much back to Google). I do think this could be a foundation for what I suggest below, but right now it only protects individual users accessing particular sites – for now, only Google. The Google Certificate Catalog is another great endeavor that’s still self-limiting – but again, I think it’s a big piece of what we need. The CA market is big business. There is a very large amount of money involved in keeping the system running (I won’t say working) as it currently does. The browser manufacturers (at least the 3 main ones and maybe Google) would all have to agree to any changes to the core model, which is very deeply embedded into how we use the Internet today. The costs of change would not fall only on evil businesses and browser developers, but would be shared among everyone who uses digital certs today – pretty much every website with users. We don’t even have a way to measure how bad the problem is. DigiNotar knew they had been hacked and had issued bad certs for at least more than a month before telling anyone, and reports claim that these certs were used to sniff traffic in Iran. How many other evil certs are out there? We only notice them when they are presented to someone knowledgeable and paranoid enough to notice, who then reports it. Dan Kaminsky’s post shows just a small slice of how complex this all is. To summarize: We don’t yet have consensus on an alternate system, there are many strong motivations to keep the current system even despite its flaws, and we don’t know how bad the problem is – how many bogus certs have been created, by how many attackers, or how often they are used in real attacks. Imagine how much more confusing this would all be if the DigiNotar hacker had signed certificates in the names of many other certificate authorities. Internally, long before the current hacks, our former intern proposed this as a research area. The consensus was “Yes, it’s a problem and we are &^(%) if a CA issues bad certs”. The problem was that neither he nor we had a solution to propose. But I have an idea that could help us scope out the problem. I call it a ‘transitional’ proposal because it doesn’t solve the problem, but could help identify the issues and raise awareness. Call it an “Early Warning System for SSL” (I’d call it “IDS for SSL”, but you all would burn my house down). The canary in the SSL mine. Conceptually we could build a browser feature or plugin that serves as a sensor. It would need a local list of known certificate signatures for

I suppose that, all things considered, I’m a pretty nice guy. I tip well, stop my car so people can cross the street, and always put my laptop bag under the seat in front of me, instead of taking up valuable overhead luggage space. While I have had plenty of jobs that required the use of physical force over the years, I always made sure to keep my professional detachment and use the minimum amount necessary. (Okay, that’s to keep my ass out of jail as much as anything else, but still…). And animals? I’m a total sucker for them. I don’t mean in an inappropriate way, but I think they are just so darn cute. We even donate a bunch to local shelters and the Phoenix Zoo. Heck, all our cats are basically rescues… one of which randomly showed up in a relative’s yard during a BBQ, severely injured, and which we nursed back to health and kept. Which is why my current murderous rampage against the birds crapping on our patio is completely out of character. We like birds. We even used to fill a bird feeder in the yard. Then all our trees grew out, and it seems we have the best shade in the neighborhood. On any given day, once the temperature tops 100 or so, our back patio is covered with dozens of birds doing nothing more than standing in the shade and crapping. And you know what birds eat, don’t you? Berries. Lots and lots of berries. Think they digest it all? Think again. Our patio is stained so badly we will never be able to get it clean. How do I know? I paid someone to power spray and hand scrub it with the kinds of chemicals banned from Fukushima – all to no avail. Not even with the special stuff I smuggled across the border from Mexico. They’ve even hit my grill. The bastards. I’ve tried all sorts of things to keep them away, but I suspect I’ll need to build out something using an Arduino and chainsaw by next summer. This year is a loss – 2 weeks after the big cleaning, even with me spraying it down every few days, out patio is unusable. I haven’t killed them yet. To be honest I don’t think that will work – more likely it would just land me on the local news. But I do grill a lot more chicken and turkey out there. Oh yeah, smell the sweet smell of superior birds roasting in agony. Hey… did you hear some dudes named DigiNotar got hacked? On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian’s DR article on DAM. Adrian quoted on dangers to law enforcement from the recent hack. My Spanish is good, no? Adrian’s DR article on Fraud Detection and DAM. Favorite Securosis Posts Adrian Lane: Security Management 2.0: Vendor Evaluation. Mike’s pushing the envelope here, but this is the only way to figure out how the product really works. Mike Rothman & David Mortman: Data Security Lifecycle 2.0. With this cloud stuff, our underlying computing foundation is changing. This post assembles a lot of the latest and greatest about how to protect the data. Other Securosis Posts Speaking at OWASP: September 22 and 23. Incite 9/7/2011: Decisions, Decisions. Security Management 2.0: Vendor Evaluation – Culling the Short List. The New Path of Least Resistance. Making Bets. Favorite Outside Posts Gunnar: Do we know how to make software? David Mortman: Quick Blip: Hoff In The Cube at VMworld 2011: On VMware Security. Mike Rothman: The Good, Bad, and Ugly of Technical Acquisitions. Not sure what Amrit is doing now, besides writing great summaries of what happens when Big Company X buys small start-up Y. Adrian Lane: Don’t Hate The ‘Playas’ – Hate The Game. My fav this week is Mike’s Dark Reading post – it gets to the heart of the issue. Pepper: Protecting a Laptop from Simple and Sophisticated Attacks. Mike clearly thought hard about risks, and took some very unusual steps to protect them as well as he could manage. Rich: OS X won’t let you properly remove bad DigiNotar certificates. I know I need to write this up, but being sick has gotten in the way. Apple really needs to address this – for PR reasons as much as for user security. Research Reports and Presentations Tokenization vs. Encryption: Options for Compliance. Security Benchmarking: Going Beyond Metrics. Understanding and Selecting a File Activity Monitoring Solution. Database Activity Monitoring: Software vs. Appliance. React Faster and Better: New Approaches for Advanced Incident Response. Measuring and Optimizing Database Security Operations (DBQuant). Network Security in the Age of Any Computing. The Securosis 2010 Data Security Survey. Top News and Posts Copyright Troll Righthaven Goes on Life Support. Die, troll, die! Star Wars Fans Get Pwned. Fraudulent Google credential found in the wild. Evidence of Infected SCADA Systems Washes Up in Support Forums. VMware: The Console Blog: VMware Acquires PacketMotion. Don Norman: Google doesn’t get people, it sells them. Blog Comment of the Week Remember, for every comment selected, Securosis makes a $25 donation to Hackers for Charity. This week’s best comment goes to Russ, in response to Incite 9/7/2011: Decisions, Decisions. Re Please Stop! Dear Adrian, While I believe one of the useful roles Securosis can play in the industry is to help turn down the hype on over-blown issues, in this particular case I’m not sure I agree with your conclusion. I spent a career in aviation safety, and found that what the average line pilot was talking about every day had nowhere near the amount of aviation safety content we as aviation safety advocates thought to be adequate (an example would be the extraneous cockpit conversation prior to the Colgan Air Flight 3407 crash in Buffalo). Could it be that the fact APTs is not brought up in your daily conversations with firms could be an indication of how far we have to go in creating a