As I’m going through a wide variety of control frameworks in a managed services/cloud environment, I’m reminded of how controls work when you’re a service provider.  Mentally, I break them down into four “buckets”:

• Controls that I provide to all customers as part of my baseline. In other words, these are things that I do for all of my customers because it’s either part of the way that I do business or it makes sense to do it once and scale it out to everybody.  Typically these are holistic information security program things (ISO 17799/27001/27002 or similar) matched up with my service-delivery architecture.
• Controls that I provide as an add-on service. Not all of my customers need these but I want to offer them to my customers to help them with their security program.  Usually these are services and products supporting a regulatory framework specific to one industry:  PCI-DSS, FISMA, GLBA, etc fit in here if my market is not exclusive to customers governed by those regulations.  In order to keep the base cost for the other customers low, these aren’t included in the base service but are available for a price.
• Controls that I am planning on building. I don’t have them yet but they’re on my roadmap.  Sometimes this is how I get into new markets by building the products and services that match up against the regulatory framework for that market, then build to that as a specification.
• Controls that I will not provide. Maybe this control doesn’t apply to my products and service (The “We don’t actually own a Windows/HP-UX/AIX server” problem).  Maybe the controls framework didn’t scope my solutions into its assumptions.  Maybe the economics of this didn’t work out.  Maybe I don’t provide this because it’s dishonest for both myself and you as my customer for me to say I provide this–think along the lines of accepting risk on your behalf which puts me into a conflict of interest.  This is why any vendor who says they provide 100% compliancy against FooFramework is lying.

Transparency ties it all together.  The good providers will tell you upfront which controls belong in which buckets.

Tool Bucket photo by tornatore.

• Reinventing FedRAMP
• Security Assessment Economics
• When the Feds Come Calling
• How to Not Let FISMA Become a Paperwork Exercise
• NIST Cloud Conference Recap

Having just finished our mini-semester class on InfoSec and Public Policy, I want to share with my old friend, the Interweblagosphere, a small process/framework for doing some analysis.  This can be a paper, legislation, or even a basic guideline for developing metrics.

• Problemspace Definition: Give a point-of-view on a particular subject and why it is important.  Thinking more conventionally, what is it exactly that is your thesis statement?
• History of Incident: prove the problem is worth time to solve.  Usually this involves identifying a handful of large-scale incidents that can serve as the model for your analysis.  Looking at these incidents, what worked and what didn’t work? Start to form some opinions.  You will revisit these incidents later on as models.
• Regulatory Bodies: beginning of stakeholder definition.  Identify responsible Government or industry-specific organizations and their history of dealing with the problem.  What existing strategic plans and reports exist that you can use to feed your analysis.
• Private Sector Support: more stakeholders.  How much responsibility does private industry have in this issue and what is the impact on them?  They can be owners (critical infrastructure), vendors (hardware, software, firmware), maintainers, etc.
• Other Stakeholders: Consider end users, people who depend on the service that depends on the IT and the information therein.
• Trend and Metrics: what do we know about the topic given published metrics or our analysis of themes across our key incidents?  If you notice a lack of metrics on the subject, what would be your “wish list” and what plan do you have for getting these metrics?  For information security, this typically a huge gap–either we’re creating metrics to show where we’ve succeeded at the tactical level or we’re generating metrics with surveys which are notoriously flawed.
• Options and Alternatives Analysis: pros and cons, what evidence suggests each might succeed.  Take your model incidents and run your options through them, would they help with each scenario?  Gather up more incidents and see how the options would affect them.  As you run through each option and scenario, consider each of the following:
  • Efficacy of the Option–does it actually solve the root cause of the problem?
  • Winner Stakeholders
  • Loser Stakeholders
  • Audit Burden
  • Direct Costs
  • Indirect Costs
• Build Strategic Plan and Recommendations: Based on your analysis of the situation (model incidents, metrics, and power dynamics), build recommendations from the high-performing options and form them into a strategic plan.  The more specific you can get, the better.

Note that for the most part these are not exclusive to information security but to public policy analysis in general.  There are a couple parts that need emphasis because of the immature nature of infosec.

Analysis of Hound Dog Behavior graph by MShades. Our analysis is a little bit more in-depth.  =)

Then the criteria for evaluating the strategic plan and the analysis leading up to it:

• Has an opinion
• Backs up the opinion by using facts
• Has models that are used to test the options
• Lays out a well-defined plan

As usual, I stand on the shoulders of giants, in this case my Favorite Govie provided quite a bit of input in the form of our joint syllabus.

• A Layered Model for Massively-Scaled Security Management
• Metricon 5 Wrapup
• Blow-By-Blow on S.773–The Cybersecurity Act of 2009–Part 4
• The World Asks: is S.773 Censorship?
• Why We Need PCI-DSS to Survive

So by now NIST SP 800-37 R1 has made the rounds.  I want to take a couple of minutes to go over my theory on this update.

Summary of changes:

• Certification is gone.  Accreditation has now changed to “Authorization”.  This is interesting to me because it removes certification which I’ve always equated with compliance.
• There is more focus on continuous monitoring.
• NIST has made it more obvious that the process in 800-37 is the security aspects of a SDLC.
• There is much more more emphasis on enterprise-level controls.

So those of you out there who have been succeeding with the NIST Risk Management Framework  have been doing this all along, and it’s actually why you’ve succeeded.  For the rest of you, if you have to change your existing process, you’ve been doing it wrong.

Now for what’s missing and where you need to fill in the gaps:

• Prioritization of controls.  If everything is important, nothing is important.  You have to be able to determine which controls you need to succeed 100% of the time and which controls only need 75% reliability.  Hey, I even give credit to the SANS 20 Critical Security Controls, as flawed as they are, for this.
• Delineation of controls into shared/common, hybrid, and system-specific.  This is by design, it’s up to the departments and agencies to figure this out.  If you do this correctly, you save a ton of time and effort.  I remember the day my certifier told me that we didn’t recognize shared controls and that it was on me to provide evidence of controls that were provided at the enterprise–it still baffles me how you really expect one person on a project team to have the resources of the entire IT security staff.
• Continuous monitoring is up to you.  Along with prioritization, you have to determine which controls you need to monitor and a plan on how to do that.  Protip: these are usually technical controls that you can automate and should do so because it’s the only way to get the job done.
• Tailor, tailor, tailor.  It is not enough to use generic 800-53 controls.  It definitely is sub-par to use untailored 800-53A test procedures as your test plan.  These all depend on the implementation and need to be tailored to fit.

And finally, a shout-out to Dan Philpott at FISMAPedia.org.  Dan literally consumes new legislation, regulation, guidelines, and standards as they come out and annotates them with a wealth of analysis.

800-37 WordCloud by ME! Thanks to wordle.net for the tool to make it.

• SP 800-53A Now Finally Final
• NIST Cloud Conference Recap
• Special Publication 800-53 Revision 3 Workshop
• How to Not Let FISMA Become a Paperwork Exercise
• Some Comments on SP 800-39

I’m curtailing my blog for a couple of weeks.  I’m busy helping out with Haiti.

I spent last Saturday at CrisisCamp DC.  It’s a barcamp-style hackathon to build applications to help relief workers in Haiti.  Think long-range wifi routers to network the country where the infrastructure is destroyed.  Think a website for quake survivors to tell their story.  Think a Craiglist for relief workers where somebody with an oxygen generator and  somebody with a power supply can get together and make something that helps both of them.  Think all of these created in an 8-hour development stint.

Yes, security folks, you can help.  Not only that, but you have the technical skills to get web apps stuff done and the project management experience to lay out what it is that needs to be done.

We’re holding another CrisisCamp in DC this Saturday the 30th.

Go to crisiscommons.org and look for a project that interests you or a local camp.

Here, let Andy Carvin break it all down “Big Bird Style”:

Movie by @Digiphile, Alex Howard from SearchCompliance.com.  Hopefully I didn’t just “out” him.  =)

• It’s Not Just for the Feds Anymore
• Opportunity Costs and the 20 Critical Security Controls
• Privacy Camp DC–April 17th
• SCAP for Dummies
• Working with Interpreters, a Risk Manager’s Guide

So I’m working with the AppSecDC folks doing press relations amongst other things.  I’ve noticed several themes for the conference that might be of interest to the rest of the world.  Of course there’s the usual “The end is nigh, and not even Norton can save you!!!!!” stuff that’s been the staple of security conferences for the past 5 years or so (oh noes, teh Internetz are broken.  Again)

However, AppSecDC has another set of themes that are mostly unique to OWASP and AppSecDC in particular:

• The OWASP Approach to Security: it’s not process/product, it’s education and outreach.  Thanks to Doug Wilson for this idea.  Basically with host and network security, the option is to buy stuff and throw it at the problem.  With application security, it’s “go out and touch a developer today” and “use ESAPI as a tool to help the developers write better and secure code more quickly”.  This is a new concept to the system integrator that I am, but I like it much better than my usual approach.
• Government and Application Security: we’re about 5 years behind industry, how do we catch up?  To this effort, we have some notable Government speakers such as a keynote by Joe Jarzombek, Director for Software Assurance in the National Cyber Security Division of the U.S. Department of Homeland Security.
• OWASP Top 10 2009/2010: This will be announced at AppSecDC with much w00tness and excitement.
• OWASP National Summit: this will be held the day before the official conference.

Convinced you want to go?  Check out the conference site.

• OWASP AppSec Conference 09
• Ed Bellis’s Little SCAP Project
• Analyzing Fortify’s Plan to “Fix” the Government’s Security Problem
• SP 800-53A Now Finally Final
• Next Up in Security Legislation: S3474

My presentation slides from Sector 2009.  This was a really fun conference, the Ontario people are really, really nice.

Presentation Abstract:

The US Federal Government is the world’s largest consumer of IT products and, by extension, one of the largest consumers of IT security products and services. This talk covers some of the problems with security on such a massive scale; how and why some technical, operational, and managerial solutions are working or not working; and how these lessons can be applied to smaller-scale security environments.

• A Layered Model for Massively-Scaled Security Management
• Metricon 5 Wrapup
• DojoCon 2009 Presentation
• Where is Rybolov?
• Building A Modern Security Policy For Social Media and Government