It’s a basic project management skill: determining project assumptions and then what is inside your scope.  And so when the folks at NIST created their risk management framework, they made several assumptions that the rest of us practitioners have to deal with.

A quick list of assumptions:

• You are working at the enterprise level or the project level.
• You don’t own custom code.
• You’re not governed by any laws other than FISMA and the Privacy Act.
• You’re using Microsoft and Cisco products.
• Your system is networked.
• You have some kind of Internet access.

Looking back through the list, it’s basically a description of the “typical” IT Enterprise built from COTS components.  And I think this is a good thing because it fits about 80% of the IT systems out there.  For these systems, the focus is on secure configurations and buying security products.

Assumption, Minnesota photo by afiler.

Now for why you need to understand this list:  it’s because if you’re not operating under the exact same set of assumptions as the catalog of controls, you have to adjust the catalog of controls to fit what it is you’re trying to accomplish.

And this, dear readers, is my theory on why compliance as a security management model does not work–there simply are enough variations in implementation that wherever you draw the line for a standard, you’re bound to either include too much and make everybody into an exception to the catalog of controls or you are going to include not enough and it becomes a watered-down standard.

And now, the secret for surviving in a catalog-of-controls culture:  you have to tailor the controls for any of the following activities:

• Building security requirements
• Building test procedures
• Assessing risk and performing risk management

Plainly stated, controls are not one-size-fits-all.  Neither are test cases.

But guess what: SP 800-53 has a huge section about assumptions and selecting controls in section 3.3.  It lists the following considerations for scoping controls:

• Common Controls:  What did you inherit from the infrastructure and the enterprise and how much do you need to augment?
• Security Objectives:  What is it that you’re actually trying to accomplish?
• System Component Allocation:  Does a particular chunk of the system need this control when it’s been satisfied elsewhere?
• Technology-Related:  Are you putting Sharepoint directly on the Internet?  Do you need more protection because of this? (this one’s for Dan Philpott)
• Physical Infrastructure:  You don’t need datacenter environmental controls if your system is a bunch of laptops.
• Policy/Regulatory: Is there a special law about the data in this particular system that typically isn’t in the scope of IT security?
• Operational/Environmental:  Is this something that you’re dropping into an embassy where you assume that layer-1 back to the US has been compromised by the host nation?
• Scalability:  Local passwords only scale up to a certain amount of users.  After that, you need better identity and access management by us
• Public Access: Have you increased the attack surface by letting the public access kiosks with a direct connection into the system?

Sadly, nobody ever reads those parts.  For your sanity, please do.

• 20 Critical Security Controls: Control-by-Control
• 20 Critical Security Controls: What They Did Right and What They Did Wrong
• Observations on SP 800-37R1
• How to Not Let FISMA Become a Paperwork Exercise
• Realistic NSTIC

OK, so it’s been a couple of months of thinking about this thing.  I threw together a rainbow-looking beast that now occupies my spare brain cycles.

Rybolov’s Information Security Management Model

And some peculiarities of the model that I’ve noticed:

Regulation, Compliance, and Governance flows from the top to the bottom.  Technical solutions flow from the bottom to the top.

The Enterprise (Layer 4) gets the squeeze.  But you CISOs out there knew that already, right?  It makes much sense in the typical information security world to focus on layers 3, 4, and 5 because you don’t usually own the top and the bottom of the management stack.

The security game is changing because of legislation at layers 5 and 6.  Think national data breach law.  It seems like the trend lately is to throw legislation at the problems with information security.  The scary part to me is that they’re trying to take concepts that work at layers 3 and 4 and scale them up the model with very mixed results because there isn’t anybody doing studies at what happens above the Enterprise.  Seriously here, we’re making legislation based on analogies.

Typically each layer only knows about the layer above and below it.  This is a serious problem when you have people at layers 5 and 6 trying to create solutions that carry down to layers 1 through 4.

At layers 1 and 2, you have the greatest chance to solve the root causes of security problems.  The big question here is “How do we get the people working at these layers the support that they need?”

• A Layered Model for Massively-Scaled Security Management
• Massively Scaled Security Solutions for Massively Scaled IT
• Professor Rybolov’s Guide to InfoSec and Public Policy Analysis
• Blow-By-Blow on S.773–The Cybersecurity Act of 2009–Part 5
• Blow-By-Blow on S.773–The Cybersecurity Act of 2009–Part 4

For those of you who didn’t know the real purpose of DojoCon, it was to raise money and awareness for Hackers for Charity. If you like anything that is in this post, go to HFC and make a donation of time, equipment, tech support, and maybe money. If you’ve never heard of HFC because you’re not one of the “InfoSec Cool Kids”, now is your chance–go read about them.

The video of my dojocon presentation. The microphone was off for the first couple of minutes but I look pretty animated.

And then the compliance panel that I tried not to dominate:

And finally, my slides are up on slideshare:

• Massively Scaled Security Solutions for Massively Scaled IT
• Building A Modern Security Policy For Social Media and Government
• Barcode Hacking
• Metricon 5 Wrapup
• DojoCon DDoS Video

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

This week’s lolcat is a shout-out to Bruce Schneier Facts who have kept me rollin’ on the floor laughing quite a few times.

• Lolcats Attend B-Sides
• IKANHAZFIZMA and Transparency
• Cellular Phone Hacking
• LOLCATS Get Fingerprinted
• Exhaustive Security Testing is Bad For You

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