IaaS Encryption: Protecting Volume Storage

Now that we have covered all the pesky background information, we can start delving into the best ways to actually protect data. Securing the Storage Infrastructure and Management Plane Your first step is to lock down the management plane and the infrastructure of your cloud storage. Encryption can compensate for many configuration errors and defend against many management plane attacks, but that doesn’t mean you can afford to skip the basics. Also, depending on which encryption architecture you select, a poorly-secured cloud deployment could obviate all those nice crypto benefits by giving away too much access to portions of your encryption implementation. We are focused on data protection so we don’t have space to cover all the ins and outs of management plane security, but here are some data-specific pieces to be aware of: Limit administrative access: Even if you trust all your developers and administrators completely, all it takes is one vulnerability on one workstation to compromise everything you have in the cloud. Use access controls and tiered accounts to limit administrative access, as you do for most other systems. For example, restrict snapshot privileges to a few designated accounts, and then restrict those accounts from otherwise managing instances. Integrate all this into your privileged user management. Compartmentalize: You know where flat networks get you, and the same goes for flat clouds. Except that here we aren’t talking about having everything on one network, but about segregation at the management plane level. Group systems and servers, and limit cloud-level access to those resources. So an admin account for development systems shouldn’t also be able to spin up or terminate instances in the production accounting systems. Lock down the storage architecture: Remember, all clouds still run on physical systems. If you are running a private cloud, make sure you keep everything up to date and configured securely. Audit: Keep audit logs, if your platform or provider supports them, of management-plane activities including starting instances, creating snapshots, and altering security groups. Secure snapshot repositories: Snapshots normally end up in object storage, so follow all the object storage rules we will offer later to keep them safe. In private clouds, snapshot storage should be separate from the object storage used to support users and applications. Alerts: For highly sensitive applications, and depending on your cloud platform, you may be able to generate alerts when snapshots are created, new instances are launched from particular instances, etc. This isn’t typically available out of the box but shouldn’t be hard to script, and may be provided by an intermediary cloud broker service or platform if you use one. There is a whole lot more to locking down a management plane, but focusing on limiting admin access, segregating your environment at the cloud level with groups and good account privileges, and locking down the back-end storage architecture, together make a great start. Encrypting Volumes As a reminder, volume encryption protects from the following risks: Protects volumes from snapshot cloning/exposure Protects volumes from being explored by the cloud provider, including cloud administrators Protects volumes from being exposed by physical drive loss (more for compliance than a real-world security issue) IaaS volumes can be encrypted three ways: Instance-managed encryption: The encryption engine runs within the instance and the key is stored in the volume but protected by a passphrase or keypair. Externally managed encryption: The encryption engine runs in the instance but keys are managed externally and issued to instances on request. Proxy encryption: In this model you connect the volume to a special instance or appliance/software, and then connect the application instance to the encryption instance. The proxy handles all crypto operations and may keep keys either onboard or external. We will dig into these scenarios next week. Share:

Read Post

Friday Summary, Gattaca Edition: April 5, 2012

Hi folks, Dave Lewis here, and it is my turn to pull the summary together this week. I’m glad for the opportunity. So, a random thought: I have made a lot of mistakes in my career and will more than likely make many more. I frequently refer to this as my well-honed ability to fall on spears. The point? Simple. This is a learning opportunity that people seldom appreciate. Much like toddlers, we learn to walk by mastering the fine art of the faceplant. We learn in rather short order that we really don’t care for the experience of falling on our faces, and soon that behavior is corrected (for most, at least). So why, pray tell, do we continue to suffer massive data breaches? Not a week goes by without some major corporation or government body announcing that they have lost a USB drive or had a laptop stolen. Have we not learned yet that “face + floor = pain” is not an equation worthy of an infinite loop? Just my musing for this week. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Rich quoted by The Macalope. Adrian’s DR paper: Security Implications Of Big Data. Rich quoted on Watering Hole Attacks. Adrian’s DR post: Database Security Operations. Mike’s DR post: You’re A Piece Of Conference Meat. snort Favorite Securosis Posts Rich: 1 in 6 Amazon Web Services users can’t read. This seriously tweaked me. And don’t give me guff for picking my own post – no one else posted this week. You’d think with 3 full timers and 6 contributors, someone else… Adrian Lane: Proposed California Data Law Will Affect Security… but it will take quite a while before companies take it seriously. David Mortman: Flash! And it’s gone… Dave Lewis: Defending Cloud Data: How IaaS Storage Works. Other Securosis Posts Cybersh** just got real. Proposed California Data Law Will Affect Security. Brian Krebs outs possible Flashback malware author. Appetite for Destruction. Get Ready for Phone Security and Regulations. IaaS Encryption: Understanding Encryption Systems. An article so bad, I have to trash it. Favorite Outside Posts Rich: Activists on Front Lines Bringing Computer Security to Oppressed People. Lives really are at stake for these people. Mike Mimoso is doing a great job with this coverage. Adrian Lane: IT for Oppression. And I just thought this was IT culture. Dave Lewis: Googlers exultant over launch of Blink browser engine. Google rolls their own browser engine. This should be interesting. Dave Mortman: Building Technical Literacy in Business Teams. James Arlen: Delivering message w/ impact && Announing our ‘Reverse Job Fair’. This should be a brilliant workshop. Top News and Posts New PoS malware. That’s “point of sale”, not the other thing. Sometimes. How to Dress Like a Cyber Warrior OR Looking Like a Tier-Zero Hero. This amused me far more than it should have. Bill would allow bosses to seek Facebook passwords. …and then Amendment aimed at workers’ passwords pulled. Apple’s iMessage encryption trips up feds’ surveillance. Because encrytion is haaaard. (h/t James Arlen). Aaron Swartz’s Prosecutors Were Threatened and Hacked, DOJ Says. I’ll just bite my tongue Honeypot Stings Attackers With Counterattacks. Top 10 Web Hacks 2012. FBI Pursuing Real-Time Gmail Spying Powers as “Top Priority” for 2013 Attempted child abduction thwarted when girl asks stranger for code word. This article caught my eye for the brilliant simplicity for keeping your kids safe. Blog Comment of the Week This week’s best comment goes to Nate, in response to 1 in 6 Amazon Web Services Users Can’t Read. I’d go out on a limb and wager a good portion of those open buckets were setup by non-IT groups who used Amazon as an end around governance and process. I’d also wager a fair number just used one of the available tools to manage their S3 because they don’t really understand the technology and that tool set the bucket to public unbeknownst to them. That means even if they received and read the email above, they probably didn’t understand it. Is that Amazon’s fault? Absolutely not. It does highlight the issue of kicking governance down the road to IT rather than dealing with it at a business level so it can be easily avoided, or focusing governance only on dollars so small opex spends fly under the radar. Unless business leaders start caring about governance and process a whole awful lot, nothing is going to get better, it’s not. Sorry, the kids have been watching the Lorax movie non stop lately. Share:

Read Post

Totally Transparent Research is the embodiment of how we work at Securosis. It’s our core operating philosophy, our research policy, and a specific process. We initially developed it to help maintain objectivity while producing licensed research, but its benefits extend to all aspects of our business.

Going beyond Open Source Research, and a far cry from the traditional syndicated research model, we think it’s the best way to produce independent, objective, quality research.

Here’s how it works:

  • Content is developed ‘live’ on the blog. Primary research is generally released in pieces, as a series of posts, so we can digest and integrate feedback, making the end results much stronger than traditional “ivory tower” research.
  • Comments are enabled for posts. All comments are kept except for spam, personal insults of a clearly inflammatory nature, and completely off-topic content that distracts from the discussion. We welcome comments critical of the work, even if somewhat insulting to the authors. Really.
  • Anyone can comment, and no registration is required. Vendors or consultants with a relevant product or offering must properly identify themselves. While their comments won’t be deleted, the writer/moderator will “call out”, identify, and possibly ridicule vendors who fail to do so.
  • Vendors considering licensing the content are welcome to provide feedback, but it must be posted in the comments - just like everyone else. There is no back channel influence on the research findings or posts.
    Analysts must reply to comments and defend the research position, or agree to modify the content.
  • At the end of the post series, the analyst compiles the posts into a paper, presentation, or other delivery vehicle. Public comments/input factors into the research, where appropriate.
  • If the research is distributed as a paper, significant commenters/contributors are acknowledged in the opening of the report. If they did not post their real names, handles used for comments are listed. Commenters do not retain any rights to the report, but their contributions will be recognized.
  • All primary research will be released under a Creative Commons license. The current license is Non-Commercial, Attribution. The analyst, at their discretion, may add a Derivative Works or Share Alike condition.
  • Securosis primary research does not discuss specific vendors or specific products/offerings, unless used to provide context, contrast or to make a point (which is very very rare).
    Although quotes from published primary research (and published primary research only) may be used in press releases, said quotes may never mention a specific vendor, even if the vendor is mentioned in the source report. Securosis must approve any quote to appear in any vendor marketing collateral.
  • Final primary research will be posted on the blog with open comments.
  • Research will be updated periodically to reflect market realities, based on the discretion of the primary analyst. Updated research will be dated and given a version number.
    For research that cannot be developed using this model, such as complex principles or models that are unsuited for a series of blog posts, the content will be chunked up and posted at or before release of the paper to solicit public feedback, and provide an open venue for comments and criticisms.
  • In rare cases Securosis may write papers outside of the primary research agenda, but only if the end result can be non-biased and valuable to the user community to supplement industry-wide efforts or advances. A “Radically Transparent Research” process will be followed in developing these papers, where absolutely all materials are public at all stages of development, including communications (email, call notes).
    Only the free primary research released on our site can be licensed. We will not accept licensing fees on research we charge users to access.
  • All licensed research will be clearly labeled with the licensees. No licensed research will be released without indicating the sources of licensing fees. Again, there will be no back channel influence. We’re open and transparent about our revenue sources.

In essence, we develop all of our research out in the open, and not only seek public comments, but keep those comments indefinitely as a record of the research creation process. If you believe we are biased or not doing our homework, you can call us out on it and it will be there in the record. Our philosophy involves cracking open the research process, and using our readers to eliminate bias and enhance the quality of the work.

On the back end, here’s how we handle this approach with licensees:

  • Licensees may propose paper topics. The topic may be accepted if it is consistent with the Securosis research agenda and goals, but only if it can be covered without bias and will be valuable to the end user community.
  • Analysts produce research according to their own research agendas, and may offer licensing under the same objectivity requirements.
  • The potential licensee will be provided an outline of our research positions and the potential research product so they can determine if it is likely to meet their objectives.
  • Once the licensee agrees, development of the primary research content begins, following the Totally Transparent Research process as outlined above. At this point, there is no money exchanged.
  • Upon completion of the paper, the licensee will receive a release candidate to determine whether the final result still meets their needs.
  • If the content does not meet their needs, the licensee is not required to pay, and the research will be released without licensing or with alternate licensees.
  • Licensees may host and reuse the content for the length of the license (typically one year). This includes placing the content behind a registration process, posting on white paper networks, or translation into other languages. The research will always be hosted at Securosis for free without registration.

Here is the language we currently place in our research project agreements:

Content will be created independently of LICENSEE with no obligations for payment. Once content is complete, LICENSEE will have a 3 day review period to determine if the content meets corporate objectives. If the content is unsuitable, LICENSEE will not be obligated for any payment and Securosis is free to distribute the whitepaper without branding or with alternate licensees, and will not complete any associated webcasts for the declining LICENSEE. Content licensing, webcasts and payment are contingent on the content being acceptable to LICENSEE. This maintains objectivity while limiting the risk to LICENSEE. Securosis maintains all rights to the content and to include Securosis branding in addition to any licensee branding.

Even this process itself is open to criticism. If you have questions or comments, you can email us or comment on the blog.