Warning: getimagesize(http://www.guerilla-ciso.com/wp-content/plugins/social-bookmarks/images/facebook.png) [function.getimagesize]: failed to open stream: HTTP request failed! HTTP/1.1 403 Forbidden in /home/rybolov/www.guerilla-ciso.com/wp-content/plugins/csprites-for-wordpress/csprites/classes/SpriteImage.php on line 36

Warning: getimagesize(http://www.guerilla-ciso.com/wp-content/plugins/social-bookmarks/images/feedmelinks.png) [function.getimagesize]: failed to open stream: HTTP request failed! HTTP/1.1 403 Forbidden in /home/rybolov/www.guerilla-ciso.com/wp-content/plugins/csprites-for-wordpress/csprites/classes/SpriteImage.php on line 36

Warning: getimagesize(http://www.guerilla-ciso.com/wp-content/plugins/social-bookmarks/images/google.png) [function.getimagesize]: failed to open stream: HTTP request failed! HTTP/1.1 403 Forbidden in /home/rybolov/www.guerilla-ciso.com/wp-content/plugins/csprites-for-wordpress/csprites/classes/SpriteImage.php on line 36

Warning: getimagesize(http://www.guerilla-ciso.com/wp-content/plugins/social-bookmarks/images/reddit.png) [function.getimagesize]: failed to open stream: HTTP request failed! HTTP/1.1 403 Forbidden in /home/rybolov/www.guerilla-ciso.com/wp-content/plugins/csprites-for-wordpress/csprites/classes/SpriteImage.php on line 36

Warning: getimagesize(http://www.guerilla-ciso.com/wp-content/plugins/social-bookmarks/images/slashdot.png) [function.getimagesize]: failed to open stream: HTTP request failed! HTTP/1.1 403 Forbidden in /home/rybolov/www.guerilla-ciso.com/wp-content/plugins/csprites-for-wordpress/csprites/classes/SpriteImage.php on line 36

Warning: getimagesize(http://www.guerilla-ciso.com/wp-content/plugins/social-bookmarks/images/squidoo.png) [function.getimagesize]: failed to open stream: HTTP request failed! HTTP/1.1 403 Forbidden in /home/rybolov/www.guerilla-ciso.com/wp-content/plugins/csprites-for-wordpress/csprites/classes/SpriteImage.php on line 36

Warning: getimagesize(http://www.guerilla-ciso.com/wp-content/plugins/social-bookmarks/images/tailrank.png) [function.getimagesize]: failed to open stream: HTTP request failed! HTTP/1.1 403 Forbidden in /home/rybolov/www.guerilla-ciso.com/wp-content/plugins/csprites-for-wordpress/csprites/classes/SpriteImage.php on line 36

Warning: getimagesize(http://www.guerilla-ciso.com/wp-content/plugins/social-bookmarks/images/technorati.png) [function.getimagesize]: failed to open stream: HTTP request failed! HTTP/1.1 403 Forbidden in /home/rybolov/www.guerilla-ciso.com/wp-content/plugins/csprites-for-wordpress/csprites/classes/SpriteImage.php on line 36

Warning: getimagesize(http://www.guerilla-ciso.com/wp-content/plugins/social-bookmarks/images/yahoo.png) [function.getimagesize]: failed to open stream: HTTP request failed! HTTP/1.1 403 Forbidden in /home/rybolov/www.guerilla-ciso.com/wp-content/plugins/csprites-for-wordpress/csprites/classes/SpriteImage.php on line 36

Comments on SCAP 2008

Posted September 24th, 2008 by rybolov

I just got back from the SCAP 2008 conference at NIST HQ, and this is a collection of my thoughts in a somewhat random order:

Presention slides are available at the NVD website

I blogged about SCAP a year ago, and started pushing it in conversations with security managers that I came across.  Really, if you’re managing security of anything and you don’t know what SCAP is, you need to get smart on it really fast, if for no other reason than that you will be pitched it by vendors sporting new certifications.

Introduction to SCAP:  SCAP is a collection of XML schemas/standards that allow technical security information to be exchanged between tools.  It consists of the following standards:

  • Common Platform Enumeration (CPE): A standard to describe a specific hardware, OS, and software configuration.  Asset information, it’s fairly humdrum, but it makes the rest of SCAP possible–think target enumeration and you’re pretty close.
  • Common Vulnerabilities and Exposures (CVE): A definition of publicly-known vulnerabilities and weaknesses.  Should be familiar to most security researches and patch monkies.
  • Common Configuration Enumeration (CCE): Basically, like CVE but specific to misconfigurations.
  • Common Vulnerability Scoring System (CVSS): A standard for determining the characteristics and impact of security vulnerabilities.  Hmmm, sounds suspiciously like standardization of what is a high, medium, and low criticality vulnerability.
  • Open Vulnerability and Assessment Language (OVAL):  Actually, 3 schemas to describe the inventory of a computer, the configuration on that computer, and a report of what vulnerabilites were found on that computer.
  • Extensible Configuration Checklist Description Format (XCCDF): A data set that describes checks for vulnerabilities, benchmarks, or misconfigurations.  Sounds like the updates to your favorite vulnerability scanning tool because it is.

Hall of Standards inside NIST HQ photo by ME!!!

What’s the big deal with SCAP: SCAP allows data exchanges between tools.  So, for example, you can take a technical policy compliance tool, load up the official Government hardening policy in XCCDF for, say, Windows 2003, run a compliance scan, export the data in OVAL, and load the results into a final application that can help your CISO keep track of all the vulnerabilities.  Basically, imagine that you’re DoD and have 1.5 million desktops–how do you manage all of the technical information on those without having tools that can import and export from each other?

And then there was the Federal Desktop Core Configuration (FDCC): OMB and Karen Evans handed SCAP its first trial-by-fire.  FDCC is a configuration standard that is to be rolled out to every Government desktop.  According to responses received by OMB from the departments in the executive branch (see, Karen, I WAS paying attention =)   ), there are roughly 3.5 Million desktops inside the Government.  The only way to manage these desktops is through automation, and SCAP is providing that.

He sings, he dances, that Tony Sager is a great guy: So he’s presented at Black Hat, now SCAP 2008 (.pdf caveat).  Basically, while the NSA has a great red-team (think pen-test) capability, they had a major change of heart and realized, like the rest of the security world (*cough*Ranum*cough*), that while attacking is fun, it isn’t very productive at defending your systems–there is much more work to be done for the defenders, and we need more clueful people doing that.

Vendors are jumping on the bandwagon with both feet: The amount of uptake from the vulnerability and policy compliance vendors is amazing.  I would give numbers of how many are certified, but I literally get a new announcement in my news reader ever week or so.  For vendors, being certified means that you can sell your product to the Government, not being certified means that you get to sit on the bench watching everybody else have all the fun.  The GSA SAIR Smart-Buy Blanket Purchase Agreement sweetens the deal immensely by having your product easily purchasable in massive quantities by the Government.

Where are the rest of the standards: Yes, FDCC is great, but where are the rest of the hardening standards in cute importable XML files, ready to be snarfed into my SCAP-compliant tool?  Truth be told, this is one problem with SCAP right now because everybody has been focusing on FDCC and hasn’t had time yet to look at the other platforms.  Key word is “yet” because it’s happening real soon now, and it’s fairly trivial to convert the already-existing DISA STIGs or CIS Benchmarks into XCCDF.  In fact, Sun was blindsided by somebody who had made some SCAP schemas for their products and they had no idea that anybody was working on it–new content gets added practically daily because of the open-source nature of SCAP.

Changing Government role: This is going to be controversial.  With NVD/CVE, the government became the authoritative source for vulnerabilities.  So far that’s worked pretty well.  With the rest of SCAP, the Government changes roles to be a provider of content and configurations.  If NIST is smart, they’ll stay out of this because they prefer to be in the R&D business and not the operations side of things.  Look for DHS to pick up the role of being a definitions provider.  Government has to be careful here because they could in some instances be competing with companies that sell SCAP-like feed services.  Not a happy spot for either side of the fence.

More information security trickle-down effect: A repeated theme at SCAP 2008 is that the public sector is interested in what Big SCAP can do for them.  The vendors are using SCAP certification as a differentiator for the time being, but expect to see SCAP for security management standards like PCI-DSS, HIPAA, and SOX–to be honest here, though, most of the vendors in this space cut their teeth on these standards, it’s just a matter of legwork to be able to export in SCAP schemas.  Woot, we all win thanks to the magic that is the Government flexing its IT budget dollars!

OS and Applications vendors: these guys are feeling the squeeze of standardization.  On one hand, the smart vendors (Oracle, Microsoft, Sun, Cisco) have people already working with DISA/NSA to help produce the configuration guides, they just have to sit back and let somebody turn the guides into SCAP content.  Some of the applications vendors still haven’t figured out that their software is about to be made obsolete in the Government market because they don’t have the knowledge base to self-certify with FDCC and later OS standards.  With a 3-year lead time required for some of the desktop applications before a feature request (make my junk work with FDCC) makes it into a product release, there had better be some cluebat work going on in the application vendor community.  Adobe, I’m talking to you and Lifecycle ES–if you need help, just call me.

But how about system integrators: Well, for the time being, system integrators have almost a free ride–they just have to deal with FDCC.  There are some of them that have some cool solutions built on the capabilities of SCAP, but for the most part I haven’t seen much movement except for people who do some R&D.  Unfortunately for system integrators, the Federal Acquisition Regulation now requires that anything you sell to the Government be configured IAW the NIST checklists program.  And just how do you think the NIST checklists program will be implemented?  I’ll take SCAP for $5Bazillion, Alex.  Smart sytem integrators will at least keep an eye on SCAP before it blindsides them 6 months from now.

Technical compliance tools are destined to be a commodity: For the longest time, the vulnerability assessment vendors made their reputation by having the best vulnerability signatures.  In order to get true compatibility across products, standardized SCAP feeds means that the pure-play security tools are going to have less things to differentiate themselves from all the other tools and they fall into a commodity market centered on the accuracy of their checks with reduced false positives and negatives.  While it may seem like a joyride for the time being (hey, we just got our ticket to sell to the Gubmint by being SCAP-certified), that will soon turn into frustration as the business model changes and the margins get smaller.  Smart vendors will figure out ways to differentiate themselves and will survive, the others will not.

Which leads me to this: Why is it that SCAP only applies to security tools?  I mean, seriously, guys like BigFix and NetIQ have crossover from technical policy compliance to network management systems–CPE in particular.  What we need is a similar effort applied to network and data center tools.  And don’t point me at SNMP, I’m talking rich data.  =)  On a positive note, expect some of the security pure-play tools to be bought up and incorporated into enterprise suites if they aren’t already.

Side notes:

I love how the many deer (well over 9000 deer on the NIST campus) all have ear tags.  It brings up all sorts of scientific studies ideas.  But apparently the deer are on birth control shots or something….

Former Potomac Forum students:  Whattayaknow, I met some of our former students who are probably reading this right now because I pimped out my blog probably too aggressively.  =)  Hi Shawn, Marc, and Bob!

Old friends:  Wow, I found some of them, too.  Hi Jess, Walid, Chris, and a cast of thousands.

Deer on NIST Gaithersburg Campus photo by Chucka_NC.

Posted in DISA, FISMA, NIST, Technical, What Works | 2 Comments »
Tags:

Government Can’t Turn on a Dime, News at 11

Posted February 27th, 2008 by rybolov

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. =)

Posted in DISA, FISMA, NIST, Rants, Technical, What Doesn't Work, What Works | 1 Comment »

SCAP for Dummies

Posted October 2nd, 2007 by rybolov

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.

Posted in DISA, FISMA, NIST, What Works | 5 Comments »

My Inbox this Afternoon: Best Practices Checklist

Posted June 21st, 2007 by rybolov

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.

Posted in DISA, Outsourcing | No Comments »

« Previous Entries


Visitor Geolocationing Widget: