Research

I am working on an encryption project – evaluating an upcoming product feature for a vendor – and the research is more interesting than I expected. Not that the feature is uninteresting, but I thought I knew all the answers going into this project. I was wrong. I have been talking with folks on the Twitters and in private interviews, and have discovered that far more organizations than I suspected are configuring their systems to automatically skip preboot authentication and simply boot up into Windows or Mac OS X (yes, for real, a bunch are using disk encryption on Macs). For those of you who don’t know, with most drive encryption you have a mini operating system that boots first, so you can authenticate the user. Then it decrypts and loads the main operating system (Windows, Mac OS X, Linux, etc.). Skipping the mini OS requires you to configure it to automatically authenticate and load the operating system without a password prompt. Organizations tend to do this for a few reasons: So users don’t have to log in twice. So you don’t have to deal with managing and synchronizing two sets of credentials (preboot and OS). To reduce support headaches. But the convenience factor is the real reason. The problem with skipping preboot authentication is that you then rely completely on OS authentication to protect the device. My pentester friends tell me they can pretty much always bypass the OS encryption. This may also be true for a running/sleeping/hibernating system, depending on how you have encryption configured (and how your product works). In other words – if you skip preboot, the encryption generally adds no real security value. In the Twitter discussion about advanced pen testering, our very own David Mortman asked: @rmogull Sure but how many lost/stolen laptops are likely to be attacked in that scenario vs the extra costs of pre-boot? Which is an excellent point. What are the odds of an attacker knowing how to bypass the encryption when preboot isn’t used? And then I realized that in that scenario, the “attacker” is most likely someone picking up a “misplaced” laptop and even basic (non-encryption) OS security is good enough. Which leads to the following decision tree: Are you worried about attackers who can bypass OS authentication? If so, encrypt with preboot authentication; if not, continue to step 2. Do you need to encrypt only for compliance (meaning security isn’t a priority)? If so, encrypt and disable preboot; if not, continue to step 3. Encrypt with preboot authentication. In other words, encrypt if you worry about data loss due to lost media or are required by compliance. If you encrypt for compliance and don’t care about data loss, then you can skip preboot. Share:

I’m very fortunate to have inherited Rothman hair, which is gray but plentiful and grows fast. Like fungus. Given my schedule, I tend to wait until things get lost in my hair before I get it cut. Like birds; or yard debris; or Nintendo DS games. A few weeks back the Boss told me to get it cut when I lost my iPhone in my hair. So I arranged a day to hit the barber I have frequented for years. I usually go on Mondays when I can, because his partner is off. These guys have a pretty sophisticated queuing system, honed over 40+ years. Basically you wait until your guy is open. That works fine unless the partner is open and your guy is backed up. Then the partner gives me the evil eye as he listens to his country music. But I have to stay with my guy because he has a vacuum hooked up to his clipper. Yes, I wait for my guy because he uses a professional Flowbee. But when I pulled up the shop was closed. I’ve been going there for 7 years and the shop has never been closed on Monday. Then I looked at the sign, which shows hours only for the partner – my guy’s hours aren’t listed. Rut roh, I got a bad feeling. But I was busy, so I figured I’d go back later in the week and see what happened. I went in Thursday, and my guy wasn’t there. Better yet, the partner was backed up, but I had just lost one of the kids in my hair, so I really needed a cut. I’m quick on the uptake, so I figured something was funky, but all my guy’s stuff was still there – including pictures of his grandkids. It’s like the place that time forgot. But you can’t escape time. It catches everyone. Finally the situation was clarified when a customer came in to pay his respects to the partner. My fears were confirmed: my guy was gone, his trusty clippers silenced. The Google found his obituary. Logically I know death completes the circle of life, and no one can escape. Not even my barber. Truth be told, I was kind of sad. But I probably shouldn’t be. Barber-man lived a good life. He cut hair for decades and enjoyed it. He did real estate as well. He got a new truck every few years, so the shop must have provided OK. He’d talk about his farm, which kept him busy. I can’t say I knew him well, but I’m going to miss him. So out of respect I wait and then sit in the partner’s chair. Interestingly enough he gave me a great cut, even though I was covered in hair without the Flowbee. I was thinking I’d have to find a new guy, but maybe I’ll stick with partner-man. Guess there is a new barber-man in town. Godspeed Richard. Enjoy the next leg of your journey. -Mike Photo credits: “Barber Shop” originally uploaded by David Smith Incite 4 U Can I call you Dr. Hacker?: Very interesting analysis here by Ed Moyle about whether security should be visionary. Personally I don’t know what that means, because our job is to make sure visionary business leaders can do visionary things without having critical IP or private data show up on BitTorrent. But the end of the post on whether security will be innovation-driven (like product development), standards-driven, innovation-averse (like accounting), or standard-driven, innovation-accepting (like medicine) got me thinking. I think we’d like to think we’ll be innovation-driven, but ultimately I suspect we’ll end up like medicine. Everyone still gets sick (because the viruses adapt to our defenses), costs continue to skyrocket, and the government eventually steps in to make everything better. Kill me now, Dr. Hacker. – MR Learn clarity from the (PHP)Fog: One of the things that fascinates me about breaches (and most crisis events) is how the affected react. As I wrote about last week, most people do almost exactly the wrong thing. But as we face two major breaches within our industry, at RSA (“everyone pretend you don’t know what’s going on even though it’s glaringly obvious”), and Comodo (“we were the victim of a state-sponsored attack from Iran, not a teenager, we swear”); perhaps we should learn some lessons from PHPFog (“How We Got Owned by a Few Teenagers (and Why It Will Never Happen Again)”). Honesty is, by far, the best way to maintain the trust of your customers and the public. Especially when you use phrases like, “This was really naive and irresponsible of me.” Treat your customers and the public like adults, not my 2 year old. Especially when maintaining secrecy doesn’t increase their security. – RM MySQL PwNaGe: For the past few days, the news that mysql.com has both a SQL injection vulnerability and a Cross Site Scripting (XSS) vulnerability has been making the rounds. The vulnerabilities are not in the MySQL database engine, but in the site itself. Detailed information from the hacked site was posted on Full Disclosure last Sunday as proof. Appearently the MySQL team was alerted to the issue in January, and this looks like a case of “timely disclosure” – they could have taken the hack further if they wanted. Not much in takeaways from this other than SQL injection is still a leading attack vector and you should have quality passwords to help survive dictionary attacks in the aftermath of a breach. Still no word from Oracle, as there is no acknowledgement of the attack on mysql.com. I wonder if they will deploy a database firewall? – AL APT: The FUD goes on and on and on and on: I applaud Chris Eng’s plea for the industry to stop pushing the APT FUD at all times. He nails the fact that vendors continue to offer solutions to the APT because they don’t want to miss out when the “stop APT project” gets funded. The nebulous definition of APT helps vendors obfuscate the truth, and as Chris points out it frustrates many of us. Yes, we should call out vendors for

In our introduction to Security Benchmarking, Going Beyond Metrics, we spent some time defining metrics and pointing out that they have multiple consumers, which means we need to package and present the data to these different constituencies. As you’ll see, there is no lack of things to count. But in reality, just because you can count something doesn’t mean you should. So let’s dig a bit into what you can count. Disclaimers: we can only go so deep in a blog series. If you are intent on building a metrics program, you must read Andy Jaquith’s seminal work Security Metrics: Replacing Fear, Uncertainty and Doubt. The book goes into great detail about how to build a security metrics program. The first significant takeaway is how to define a good security metric in the first place: Expressed as numbers Have one or more units of measure Measured in a consistent and objective way Can be gathered cheaply Have contextual relevance Contextual relevance tends to be the hard thing. As Andy says in his March 2010 security metrics article in Information Security magazine: “the metrics must help someone–usually the boss–make a decision about an important security or business issue.” That’s where most security folks tend to fall down, focusing on things that don’t matter, or drawing suspect conclusions from operational data. For example, generating a security posture rating from AV coverage won’t work well. Consensus Metrics We also need to tip our hats to the folks at the Center for Internet Security, who have published a good set of starter security metrics, built via their consensus approach. Also take a look at their QuickStart guide, which does a good job of identifying the process to implement a metrics program. Yes, consensus involves lowest common denominators, and their metrics are no different. But keep things in context: the CIS document provides a place to start, not the definitive list of what you should count. Taking a look at the CIS consensus metrics: Incident Management: Cost of incidents, Mean cost of incidents, Mean incident recovery cost, Mean time to incident discovery, Number of incidents, Mean time between security incidents, Mean time to incident recovery Vulnerability Management: Vulnerability scanning coverage, % systems with no severe vulnerabilities, Mean time to mitigate vulnerabilities, Number of known vulnerabilities, Mean cost to mitigate vulnerabilities Patch Management: Patch policy compliance, Patch management coverage, Mean time to patch, Mean cost to patch Configuration Management: % of configuration compliance, Configuration management coverage, current anti-malware compliance Change Management: Mean time to complete changes, % of changes with security review, % of changes with security exceptions Application security: # of applications, % of critical applications, Application risk access coverage, Application security testing coverage Financial: IT security spending as % of IT budget, IT security budget allocation Obviously there are many other types of information you can collect – particularly from your identity, firewall/IPS, and endpoint management consoles. Depending on your environment these other metrics may be important for operations. We just want to provide a rough sense of the kinds of metrics you can start with. For those gluttons for punishment who really want to dig in we have built Securosis Quant models that document extremely granular process maps and the associated metrics for Patch Management, Network Security Operations (monitoring/managing firewalls and IDS/IPS), and Database Security. We won’t claim all these metrics are perfect. They aren’t even supposed to be – nor are they all relevant to all organizations. But they are a place to start. And most folks don’t know where to start, so this is a good thing. Qualitative ‘Metrics’ I’m very respectful of Andy’s work and his (correct) position regarding the need for any metrics to be numbers and have units of measure. That said, there are some things that aren’t metrics (strictly speaking) but which can still be useful to track, and for benchmarking yourself against other companies. We’ll call these “qualitative metrics,” even though that’s really an oxymoron. Keep in mind that the actual numbers you get for these qualitative assessments isn’t terribly meaningful, but the trend lines are. We’ll discuss how to leverage these ‘metrics’/benchmarks later. But some context on your organization’s awareness and attitudes around security is critical. Awareness: % of employees signing acceptable use policies, % of employees taking security training, % of trained employees passing a security test, % of incidents due to employee error Attitude: % of employees who know there is a security group, % of employees who believe they understand threats to private data, % of employees who believe security hinders their job activities We know what you are thinking. What a load of bunk. And for gauging effectiveness you aren’t wrong. But any security program is about more than just the technical controls – a lot more. So qualitatively understanding the perception, knowledge, and awareness of security among employees is important. Not as important as incident metrics, so we suggest focusing on the technical controls first. But you ignore personnel and attitudes at your own risk. More than a few security folks have been shot down because they failed to pay attention to how they were perceived internally. Again, entire books have been written about security metrics. Our goal is to provide some ideas (and references) for you to understand what you can count, but ultimately what you do count depends on your security program and business imperatives. Next we will focus on how to collect these metrics systematically. Because without your own data, you can’t compare anything. Share: