Movie from George Mason professor Paul Strassman on Information Assurance which was digitized and shared forever thanks to Google Movies.

My response to the movie:

This presentation has many problems.

FISMA is not that large of a law.  You can get the text from the NIST website at the following url:
http://csrc.nist.gov/policies/FISMA-final.pdf (16 pages long)

FISMA does not require SP 800-53.  It charges NIST with creating standards for information security.  FIPS 200 dictates that an agency use 800-53 as their baseline security controls.  Once again, we’re confusing the law with the implementation.

The security plan is a vehicle to get people to agree on what the security controls should be, not a post-fact documentation on what security controls that exist.

DIACAP is not the first time that systems have had to be certified.  Prior to this, there was DITSCAP, NIACAP, FIPS 102, and SP 800-37.  I also wonder how we got from SP 800-53 to DIACAP since they are different flavors–civilian agencies v/s DoD.

In certification, you do not certify compliance.  You certify that the controls meet the needs of the business owners.  Those needs might be considerably more relaxed than you think.  For example:  completely air-gapped systems in a SCIF don’t need a sizeable chunk of the control in 800-53.  Compliance is costly because you don’t have the ability to not do something that doesn’t make sense.

The “Hamster Wheel of Pain” that is shown as the DIACAP process is detached from other SDLC activities, which is rapidly becoming one of my pet peeves.  If you do DIACAP divorced from the SDLC, you are creating liarware.

“The DIACAP activities, the certification of the system, is a very involved, complicated, time-consuming, laborious process that nobody has as yet completed.”  It’s so wrong I can’t even begin to explain.

The DAA is not responsible for DIACAP.  The DAA is only a key decision maker.

The DAA does not sign a statement saying that you are secure, they sign a statement saying that the level of risk to the system and to the mission is of an acceptable level.

The CIO does not usually go to the DAA.  The CIO is more likely to be *the* DAA than just about anybody else.

The second half of the movie is general security information, not really IA-specific.

If this is what they teach in the universities around the beltway, no wonder we have an IA constituency who don’t “get it“.

• Some Random Thoughts on C&A SOPs
• Rebuilding C&A
• Feds to Embrace SaaS, End is Nigh for Security!
• Observations on SP 800-37R1
• Mike’s Guide to Information Security Policy

Good things are afoot.  DISA has a SRR Lite CD that has all of the tools that you would need.

• Our “Peace Dividend”: DISA SRR Scripts
• My Inbox this Afternoon: Best Practices Checklist
• GSA Looking for a Few Good Tools
• Save a Kitten, Write SCAP Content
• Evolution of Penetration Testing: Part 1

I can’t believe there is such a market for technical policy compliance tools–I guess they’re all “Risk Management Tools” this year.  Save your money, you can get what you need for free.  It’s all at DISA IASE

Roughly a year ago, I wrote this post to the Security Focus penetration-testing listserv:

The SRR scripts are very good, but keep in mind that what they do is
check the configurations that are specified in the STIGs.

It goes like this:
NSA creates Security Guides
Which begat:
DISA Security Technical Implementation Guides
Which begat:
DISA Manual Checklists
Which begat:
DISA SRR Scripts

What the SRR Scripts are is an automated way to do the checks in the
manual checklists.

A word of caution is that if an OS is configured according to the STIGS,
they will break. The good thing is that it’s a fast tool to check for
vulnerabilities.

The scripts for windows machines use winbatch as the script language.
They take about 15-20 minutes to run once you’ve figured out how to do
it. What we do is go into an office, select a random percentage of
computers to check, load the script, and start it. By the time we’re
done starting the script on the last computer, it’s time to start
retrieving results off the first ones.

When DISA sends their audit team around, they run the SRR Scripts and an
external scan with ISS or Retina.

As for the .mil restriction, last time I looked at them, they allow
anybody to download the STIGS but you need a .mil address to download
the SRR Scripts. There is also the “gold disk” which has all the SRR
Scripts on it.

HTH
–Mike

Anyway, I’ve gotten a ton of mileage out of this fairly simple posting.  Here it is over a year later, and I have people that I work with telling me that they did an Internet search for DISA SRR Scripts and came up with this email, so since I’m a “qualified expert” would I give them a demonstration?

Now the beauty of the technical guidance from DISA is that they have some really good information and tools that you can use in your security program.  Managing my own commercial infrastructure, when somebody asks me what hardening guidance to use, my standard response is “How hard is it to spell DISA STIGs?”  STIGs are probably the most stringent hardening guide you’ll find out there, and very explicit in the “click this widget to off” form that the system administrators want.

All the DISA technical guidance (one exception is the Gold Disks which have all the current vendor patches and can’t be distributed for licensing reasons) is now available to the commercial world to use.  This is good, and I jokingly refer to it as our “peace dividend”.  While some of it is DoD-specific (don’t use the DoD warning banner, and be careful about disabling “bypass traversal checking” for service accounts), it makes a very good start to “roll your own” if you have to harden your IT systems.

The way to use them is that the Security Technical Implementation Guide (STIG) is a hardening guide.  The Manual Checklists are a step-by-step guide to audit a system against the STIG.  The SRR Scripts are automated versions of the checklists.  What you do is run the SRR Script and where necessary, refer back to the STIG if you have any questions on what the tool is giving you as a finding.  There are numbers to provide you with traceability back and forth.  After you’re done STIG-ing your system, hit it over the wire with a Nessus or similar, and you’ve got a hardened building block.

The advantage to using the DISA tools is that you can sit down and in half a day create a standard server/workstation/router/$foo image that can serve as your base for all builds.  With a little bit of Group Policy Object mastery, you can propagate hardening out to a bazillion workstations.

And all it costs is your time, which you would spend anyway using somebody else’s pay-to-play tools.  That’s something neat to think about.

DISA IASE

• The Vendors are Already Jumping on the 07-11 Bandwagon
• DISA SRR Lite CD
• Some Words From a FAR
• Comments on SCAP 2008
• 20 Critical Security Controls: Control-by-Control