If you're new here and would like to see more of what I'm saying, you may want to subscribe to my RSS feed or have a look at my papers and presentations page for downloads of stuff that you can share or "borrow heavily from". You also might find my guidelines for posting comments interesting, especially if you're a government employee. Thanks for visiting and happy hacking!

Are we done with the Federal Desktop Core Configuration yet? Are we compliant with OMB Memo 07-11?? Have we staved off dozens of script-kiddies armed with nmap and some ’sploits they downloaded from teh Intarweb, all through hardening our desktops to the one true standard?

No? I didn’t think we would. Of course, neither did the CISOs and other security managers out there in the agencies. It’s too much too fast, and the government is too large to turn on a time. Or even a quarter, for that matter. =)

Now get ready for a blamestorm at the end of the month. By that time, all the agencies are supposed to report on their status to OMB. It’s not going to be pretty, but it’s hardly unexpected.

So why haven’t we finished this yet? Inquiring minds want to know.

Well, it all goes back to the big question of “how many directions can today’s government CISO be pulled in?” Think about it: You’ve got IPV6, HSPD-12, all the PII guidance (Memo 06-16 et al), reducing Internet connections down to 50, aligning your IT systems with the Federal Enterprise Architecture, getting your Internet connections monitored by Einstein, and the usual administrative overhead. that’s too many major initiatives all at the same time, and it’s a good way to be torn in too many directions at the same time. In government-speak, these are all what we call “unfunded mandates”, and one is bad enough to cripple your budget, much less a handful of them.

Where we’re at right now with FDCC is that the implementers are finding out what applications are broken, and we’re starting to impact operations–not being able to get the job done. Yes, this is the desired effect, it puts the pressure on the OS vendors and the application vendors, and it’s a good thing, IMO–we won’t buy your software if it doesn’t support our security model, and we’ll take our $75B IT budget with us. Suddenly, it’s the gorilla of market pressure throwing its weight around, and the BSOFH inside me likes this.

Now don’t get me wrong, I’m a big believer in FDCC (for both the Government and with a payoff for the civilian world), and I think it’s security-sound once it’s implemented, but in order for it to work, the following “infrastructure” needs to be in place:

• An official image shared between agencies
• Ability to buy a hardened FDCC OS as part of purchasing the hardware
• Microsoft rolling FDCC into its standard COTS build that it offers to the rest of the world
• Applications that are certified to run on the “one standard to rule them all” and on a list so I can pick one and know that it works
• Security people who understand GPOs and that even though it’s a desktop configuration standard, it affects servers, too
• An automated tool to validate technical policy compliance (there, I said it, and in this space it actually makes sense for a change)

Until you have these things, what OMB is asking for the agencies to get squeezed between a vendor who can’t ship a default-hardened OS, lazy applications vendors who won’t/can’t fix their software, and the 5+ levels of oversight that are watching over the shoulder of the average ISSO at the implementation level. In short, we’re throwing the implementers under the bus and making them do our dirty work because at the national level we have failed to build the right kind of influence over the vendors.

Gosh, it sounds like this would go so much better if we phased in FDCC along with the next tech refresh of our desktops, doesn’t it? That’s how the “sane world” would tackle something like this. Not a sermon, just a thought. =)

Bookmark to:

SCAP is becoming one of my favorite government acronyms: Security Content Automation Protocol. OK, what does that mean in English? Well, it’s a glue to hold together a whole slew of xml nummie data goodnesses such as the National Vulnerability Database and a standard for asset inventory management.

I was pretty skeptical on SCAP (and the Federal Desktop Core Configuration–FDCC) when it was first announced–like wow, we have yet another obscure memo from Karen Evans that we have to address.

I had a change of heart after I heard the magical phrase “We know it’s going to break things, and we don’t care”. That made me take notice. I thought about it all weekend–I was getting really riled up over such an obvious irresponsible security hard line. But then I found the magic in what they were doing and learned to stop fearing SCAP and embrace the love that it brings. I’ll tell you why.

Imagine you’re Microsoft. You can’t harden down your OS because you have all the applications vendors (including the A-V/Malware guys) raising the big anti-trust flag. And they’re right to do so. Maybe at one point, you could make your software “secure by default” but that was 20 years ago, and if you would have done so, you would have been last to market.

But that doesn’t work to plug the holes in the OS. In my opinion, it’s the lesson of Vista: if you make it stronger, it breaks applications. We all know that, so a design choice is to either leave the holes or give you a nag-screen or a combination of the two. Speaking strictly from the security side of things, that–along with continuous OS patching–is just “polishing a turd”. Yeah, you can make it all shiny on the outside, but deep down inside it’s still nothing pretty.

But now put yourselves in the Government’s shoes: You buy an OS and spend how much time and effort into OS hardening. That’s money you could spend elsewhere. The people at the top of the Government understand this, that’s why they’re always looking at ways to simplify.

OMB and others have been pushing SCAP pretty hard. So far, most of the focus has been on the databases that exist (CVE, NVD) and the desktop configuration (FDCC).

Think about a pre-hardened Government OS. What it does is break applications–applications that are poorly designed. If your application is poorly designed and doesn’t work with the FDCC, then you’re squeezed out of the public sector. The true capitalists here would say something like “let the market decide who the winners are” or something like that. Realistically, if you want a slice of the federal IT budget, then you need to make your software compatible with their hardening standard. They make it easy to do, with tools to test your software and a certification program.

The part that I like about SCAP is that it’s the Government doing what the OS vendors can’t–put pressure on the applications guys. As usual, this should have a trickle-down effect for the private sector, with the beginning being free hardening guides and the vulnerability databases and the end being a comprehensive information security management toolset.

Check out the presentations from the SCAP conference last month. The Tim Grance presentation (.ppt) alone is worth the price of admission.

Right now SCAP is at the national/CISO level. Give it 6 months and it will be at the forefront of what people are doing.

Bookmark to:

Ah, DISA, gotta love it. They give me periodic spam–not as bad as it sounds. =)

This time, I got one that immediately perked my interest:

“DISA FSO is releasing the Best Security Practice Checklist. This checklist was developed to assist during the procurement process for managed services acquisitions. “

What’s interesting to me is that it’s mostly based on web applications service providers. I don’t think most of it applies to what my guys do, or we’re doing something along a different scope.

Bookmark to:

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“.

Bookmark to:

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

Bookmark to:

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

Bookmark to: