The Data Security Lifecycle: Beta 1

I never meant to become that “data security” dude. Back when I first transitioned from a consultant to an analyst I was given a hodgepodge of technologies to cover. Since I’d been a DBA and programmer I picked up database security. No one was covering encryption, so that fell in my lap. We’d recently lost the person covering forensics and acceptable use, so I ended up with that as well. This was all about 5 or so years ago, and at the time it seemed like a random collection of technologies. Then I started noticing some similarities and overlap. Clients would call in to ask about these different technologies yet they were all often working on solving the same problems. At first it was defending against, “the insider threat”, but then it started to transition into protecting data/content. I started digging in and realized that although we in security have spent years talking about insider threats and protecting data, our advice was typically little more than hand waving or “encryption”, without really understanding what encryption can and cannot protect against. I decided to try and pull this all together into a framework and my first pass was the Data Security Hierarchy. While a good start at figuring out the various layers used to protect data, it really doesn’t help you figure out when to apply controls and which ones work best under which circumstances. It was little more than an interesting conglomeration of generic technology layers that isn’t actually very practical in designing security controls. Thus I’m proud to announce my next attempt- the Data Security Lifecycle. This time I’ve broken security controls out based on the lifecycle stage of the data. From creation to destruction, the Data Security Lifecycle shows which controls should apply at which phase. This provides more practical guidance and helps prioritize data security technology investments. This diagram is the high-level controls view. While in some cases these controls map directly to a specific technology, in other cases a single control may map to multiple technologies. Future posts will map specific technologies to specific controls, so don’t beat me up over the genericism quite yet. This view represents both structured and unstructured data; future posts will break them out separately since you can’t treat a database the same as a Word document. Finally, this view does not prioritize controls based on data classification. Again, that’s fodder for a future post. Yep, I’ve got a heck of a lot to write about here and will be breaking it out into manageable chunks. In developing the Data Security Lifecycle I reviewed many of the information lifecycles out there, and paid particular attention to Information Lifecycle Management (ILM). I didn’t feel that ILM mapped as well as we needed to the security domain so I decided to borrow elements of it, but in the end designed a more security-specific lifecycle. The stages are: Create: This is probably better named Create/Update since it applies to creating or changing a data/content element, not just a document or database. Creation is defined as generation of new digital content, either structured or unstructured. In this phase we classify the information and determine appropriate rights. Sounds hard, but in many cases this will be performed by technology or default classification and rights applied based on point of origin. Store: Storing is the act committing the digital data to structured or unstructured storage (database vs. files). Here we map the classification and rights to security controls, including access controls, encryption and rights management. I include certain database controls like labeling in rights management – not just DRM. Controls at this stage also apply to managing content in our storage repositories, such as using content discovery to ensure that data is in approved/appropriate repositories. Use: These controls apply to data at the point of use- typically a user’s PC or an application. We include both detective controls like activity monitoring, and preventative controls like rights management. Logical controls are typically applied in databases and applications. I’ve also lumped in application security although that’s a massive domain on its own and mostly outside the scope of this lifecycle. Share: These controls apply as we exchange data between users, customers, and partners. This again includes a mix of detective and preventative controls, such as DLP/CMF/CMP, encryption for secure exchange of data, and (again) logical controls and application security. Archive: In this phase data leaves active use and enters long-term storage. We’ll use a combination of encryption and asset management to protect the data and ensure its availability. Destroy: Not all data is permanently retired, but when it is we need to delete it securely and use tools like content discovery to track down any lingering copies. For you ILM geeks, here’s a mapping of the Data Security Lifecycle phases to ILM: All of this is a work in progress. Over the next few posts I’ll start mapping these high level controls to specific technologies (distinguishing between structured and unstructured data) and prioritize based on classification level. Not all the technologies we’ll be discussing are the most mature in the world, so we’ll also prioritize a little bit based on what’s effective and practical in today’s markets. I don’t consider this anything revolutionary; it’s merely a logical progression, as we see improvements in both the available technologies and our understanding of how data is compromised. I’m trying to present it in an organized big picture. It’s one of those funny things that seems to take endless hours of thought and doodling to build a simple looking diagram that doesn’t look like much. Oh well. This is still all under development and any feedback (preferably in the comments) is appreciated. Eventually I’d like to use this as a basis for a comprehensive book on data security, but that’s still a little ways out unless one of you fine readers is independently wealthy and would like to support my lifestyle while I write full-time. Share:

Read Post

Go Check Your Gmail Settings… XSS Vulnerability

I always wonder what I’ll wake up to on a Monday morning. Today it was a nice new cross-site scripting (XSS) vulnerability over in Google. The details are over at bedford. org (link broken since it’s a little risky), and the focus is on Google Mail. Bedford has three proofs of concept up. The first exploits Blogspot polls, the second Gmail contacts, and the third forwards all your incoming mail to Bedford. I tested them out, and while the contacts one didn’t work for me in a quick test, the forward definitely worked. This means anyone can send you an email or embed code in their web page that will then forward all your Google mail to an address of their choosing. This isn’t a particularly stealthy exploit- if you go into your Gmail settings you can check if your account is forwarding. Just click on settings, Forwarding and POP, and make sure Disable forwarding is checked (as in this screenshot). The proof of concept was posted on September 24th, so it’s not like this is the first day it’s public Umm… I should have coffee and check the calendar before I blog; that’s today . And while my little advice will help with the forwarding problem, the base code looks like it can do pretty much anything it wants with your Google Mail account, so there’s all sorts of other possible nastiness. Some people are recommending FireFox with NoScript. Personally, I suggest you just log out of Gmail with your web browser and set up your mail client to access Gmail directly (no browser access). All of these are crappy workarounds until Google plugs the hole. Update: I shouldn’t blog before my first cup of coffee. If you’re going to enable POP access, you need to first log in from a “clean” browser, change your password, then set up encrypted POP access. Google’s instructions for this are pretty easy, and seriously, don’t skip that changing your password step. (Thanks to Maynor/Errata for the heads up). 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.