Chrome OS is coming, and it is impressive

Today, Google made its first public announcements about Chrome OS, a Linux-derived operating system that it positions as secure and easy to use. I listened in on the Web cast today, and had some initial impressions.

Overall, I am impressed. Google had the luxury to design an OS using a clean sheet of paper, and as a result produced an OS that has some very interesting security properties:

• Trusted boot. The kernel is verified using public keys stored in the firmware.
• OS integrity check. All disk blocks on the root partition are hashed and checked at boot, meaning that malware won't be able to take up residence in the file system.
• No user-installable user applications. Everything is a Web app.
• Application sandboxing. Every process runs in its own memory space. Processes are chrooted. Stack protection, as you might expect.
• OS segregation. The OS enforces separate disk partitions for system (root) and user data.
• User data protection. User data is stored locally on its own partition, and is encrypted.
• Silent and trusted OS updates. No user-serviceable parts inside.

If you remember my earlier blog post on Chrome OS, I predicted most of this stuff, although I got a few details here and there wrong. I did not predict that user data would be encrypted. But I was more right than wrong, so that is gratifying.

Outside of security, a few things surprised me, but make total sense in retrospect. For example, Google OS will only runs on certain hardware. Solid state disk drives will be required. This means Google does not need to do much hardware abstraction layer (HAL) type engineering. That is how they are getting (or claiming to get) 7 second boot times. Again, this is what you can do when you design from a clean sheet, and when you make conscious choices about what you will not do, such as support every SCSI card, video driver, and crazy hard disk made since the invention of fire.

There are a few things that I am still not totally clear about, such as the apparent ability to restore the OS to a known state using a flash drive.

Other than that, though, there is really not too much, from a security design perspective, that I could improve on. The devil is always in the details. But based on my first impressions, it should be a great netbook OS.

Your new client security analyst

After seven years, my colleague Natalie Lambert is leaving Forrester. In the year that I have been at Forrester, she has been a good team-mate, sounding board for ideas, gleeful mischief-maker, and collaborator on shared research topics. I will miss her insights and energy, and I wish her the best as she begins her next adventure.

Natalie covered quite a bit of ground: client security, client management, endpoint virtualization, Bring-Your-Own-PC programs, full disk encryption and several other topics. While it would be impossible to fill her shoes, I am strapping on my hip waders and immersing myself in several of her research topics.

Specifically: henceforth, I will cover all client security topics for Forrester. These include:

• data leak prevention (DLP) on the client
• full disk encryption
• client security (anti-malware and anti-virus)

I am pleased to cover client security topics again. I wrote extensively about client security for three-and-a-half years before coming to Forrester. Among other things, I correctly predicted that Windows Vista would have no effect on the Windows security aftermarket — six months before Vista launched. And in 2006 and 2007, I anticipated the rapid move of anti-virus to the cloud, which we see today in Panda Security’s “collective intelligence,” in McAfee’s Artemis project, Trend Micro’s Smart Protection Network, and in new startups like Immunet. For cloud coverage of client security, I will partner with Chenxi Wang, but security topics that have anything to do with stuff sitting on endpoints, I will be your analyst.

I will not take on any of Natalie’s IT operations topics, such as BYOPC, mobile management, client management. These areas will be covered by other analysts on the infrastructure and operations (I&O) research team, chiefly Chris Silva and Ben Gray. Rather than speak for them, I will let them speak for themselves. I will collaborate with Ben and Chris on security strategies and best practices as it affects their topics.

I will also retain my coverage of data security topics, notably data leak prevention (DLP) and enterprise rights management. A few subjects will transition to my other colleagues on the Security and Risk team. We will likely announce details after we conclude those discussions.

In the meantime, Forrester customers who would like clarification on what the shift in security coverage means for you should contact their client services representative. I would be happy to speak with you! But the short answer is that not much is changing. You will talk to me rather than Natalie. She provided excellent coverage of client security topics, and I will strive to do the same.

 

[posted by Andrew Jaquith]

Information Asset Value: Some Cold-Hearted Calculations

Many readers know this already, but about five years ago (long before I came to Forrester) Dan Geer, Kevin Soo Hoo, and I founded an organization called securitymetrics.org, devoted to the study of security metrics. I moderate a mailing list that has about 800 security researchers, CISOs, consultants, and managers. Discussions are always lively!

One of the list’s most active members, Meritology’s Russell Cameron Thomas, just posted a thoughtful essay on how to value information assets. I liked his post very much. Russ describes an eminently sensible way to calculate business asset value. At the risk of being reductionist, it involves: 1) figuring out the value of those assets that even the coldest-hearted business analyst would agree contribute to the top line and 2) then figuring out the value of everything else. The sum of those two numbers is the total value.

In practice, though, the assets in the first category (the cold-hearted analyst’s favorite ones) are also the scarcest. A key question would be, “did you build security into the business effort this asset serves from the start, because it was critical to customer acceptance?” I can think of exactly one example of this in my entire career where this is true. Everything else has been some flavor of bolt-on.

Because security-as-business-enabler sightings are as rare as the Abominable Snowman, that means just about everything defaults into category #2. As such, to me, the easiest way to value those assets is to apply what (if I remember correctly) was Pete Lindstrom’s test: the value of the asset must be worth at least what you are willing to spend to keep it secure. Lindstrom’s Razor (if I can call it that) identifies a floor value of the information. It doesn’t require interviews or any sort of guesswork, just a spreadsheet and a few defensible ideas about how to allocate costs that are known and can be measured.

In my book, “Security Metrics: Replacing Fear, Uncertainty and Doubt,” I recommended a similar strategy for quantifying and allocating security cost:

Tying back security costs to business units or revenue-generating systems is more difficult. Cost allocation is, for most organizations, a black art. In fact, given the degree of political wrestling that occurs when figuring out chargeback formulas, one might more profitably call it a full-contact sport. Regardless, security organizations should try, to the best of their abilities, to associate specific expenditures with business initiative.
Certain security costs are easy to allocate, such as outsourced security monitoring services for a demilitarized zone, single sign-on systems (SSO), application monitoring tools and external audits:

• Outsourced security monitoring services for a demilitarized zone (DMZ). (Strategy: pro rata allocation based on user sessions or bandwidth)
• Single-sign on system (Strategy: pro rata allocation based on deployment of SSO agents on business servers, plus labor allocation)  
• Database and web application monitoring tools/firewalls (Strategy: chargeback of per-agent software costs, plus labor allocation)  
• Intrusion detection
• External audit fees and consulting: (Strategy: direct chargeback if audit is for a specific application; otherwise, pro rata allocation based on issues found) 

Other costs may be more difficult to allocate, especially those that are incurred by all members of the organization. Security awareness, training and coordination costs, for example, don’t obviously relate to specific business initiatives; neither do directory synchronization and maintenance tools, anti-virus or other ubiquitously deployed security software. In these cases, it might be best not to allocate them at all (thus relegating them to everyone’s favorite nebulous category, “infrastructure”). Alternatively, if costs have clear and obvious per-employee expenses (such as anti-virus), then pro rata allocation to each business unit based on headcount represents a fair and transparent method.

Ultimately, nothing I write or say is going to settle the argument of how to value all this intangible stuff. If you have the time and discipline, Russ’ approach is a good one. But if you don’t, use the ’Razor to calculate the floor value of your information assets based on what you are spending to protect them.

Data Security: One of Forrester's Top 15 IT Technologies to Watch

My colleague Alex Cullen recently released a report for Enterprise Architects called “The Top 15 Technology Trends EA Should Watch,” which describes some of the key technologies that will have the greatest impact over the next three years through 2012.

A key security trend, one which I was interviewed for, described how security will increasingly move from being perimeter- and container-centric towards being data-centric. In other words, while perimeter security, network access controls, and other security measures will continue to be important, the decreasing importance of physical locale and networks will inevitably mean that the data must increasingly protect itself.

Now, this prediction isn’t exactly new — some noted security professionals have been making the case for data- and information-centric security for a while. And in 2000, while at @stake Dan Geer and I were retained by a Very Large Investment Bank to explore this very question. Some of the things we predicted — more use of client-side cryptography, network admission control, bandwidth throttling based on device “trust” and user authentication assurance, and enterprise digital rights management (eDRM) — have made their way into the mainstream. (Not all have, to be sure.) Many, many others, in the field have made similar predictions. 

Three things have changed since the early 2000s that have moved data-centric technologies to the forefront. First, as an industry we have lost our “better living through cryptography” religion. Enterprises don’t believe in cancer-curing, globe-spanning PKI schemes using enterprise certificates whose trustworthiness are absolute, and whose pedigrees come from God (or Stratton Sclavos, if you prefer). Instead, PKI has yielded to “pki” — smaller, point purpose uses of crypto that are integral to solving specific problems, such encrypting laptop hard drives or protecting offsite backup tapes. Cryptography continues to underpin some of the most important security technologies around, but it is now rightly seen as a means, not an end.

Second, enterprises have new tools to help them automate classification and filtering tasks. Data leak prevention (DLP) is a good example. Enterprises don’t have time to burn static security labels into their documents. But if a smartish system can make reasonably decent decisions about information flowing through and exiting company networks, devices, or operating environments, security controls can be applied when needed, rather than when the IT admin gets around to it. The ability to dynamically assign security classifications to information as it is created is better than the alternative. 

Third, and perhaps most important — data security is less and less a “security thing.” The objectives of data security have been winding their way up the stack from network zones and server access control lists to Layer 7 and beyond. Product categories that have historically been siloed, such as DLP, eDiscovery, and enterprise search are starting to merge. Stakeholders other than IT Security increasingly have a say in how data security policies for DLP are created, for example. And the most successful eDRM projects are usually led by business divisions who have their own priorities to protect: inside counsel, the M&A due diligence team, or the research division. As Alex notes in his report, “with content security controls in place, businesses can share data more freely while keeping it secure.” Sponsorship and operation of data-centric security tools are key success factors.

Data-centric security: finally, we are beginning to put the “information” back into Information Security. I'd urge you to read Alex’s excellent report. Data-centric security is just one of the big technologies he touches on. If you found this post riveting, read his report for 15 times more rivets!

 

[posted by Andrew Jaquith]