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