So way back in the halcyon days of 2008 when Dan Philpott, Chris Burton, Ian Charters, and I went to the NIST SCAP Conference.  Just by a strange coincidence, Ed Bellis threw out a twit along the lines of “wow, I wish there was a way to import and export all this vulnerability data” and I replied back with “Um, you mean like SCAP?

Fast forward 6 months.  Ed Bellis has been busy.  He delivered this presentation at SnowFROC 2009 in Denver:

So some ideas I have about what Ed is doing:

#1 This vulnerability correllation and automation should be part of vulnerability assessment (VA) products.  In fact, most VA products include some kind of ticketing and workflow nowadays if you get the “enterprise edition”. That’s nice, but…

#2 The VA industry is a broken market with compatibility in workflow.  Everybody wants to sell you *their* product to be the authoritative manager. That’s cool and all, but what I really need is the connectors to your competitor’s products so that I can have one database of vulnerabilities, one set of charts to show my auditors, and one trouble ticket system. SCAP helps here but only for static, bulk data transfers–that gets ugly really quickly.

#3 Ed’s correllation and automation software is a perfect community project because it’s a conflict of interest for any VA vendor to write it themselves. And to be honest, I wouldn’t be surprised if there aren’t a dozen skunkwork projects that people will admit to creating just in the comments section of this post. I remember 5 years ago trying to hack together some perl to take the output from the DISA SRR Scripts and aggregate them into a .csv.

#4 The web application security world needs to adopt SCAP. So far it’s just been the OS and shrinkwrapped application vendors and the whole race to detection and patching. Now the interesting part to me is that the market is all around tying vulnerabilities to specific versions of software and a patch, where when you get to the web application world, it’s more along the lines of one-off misconfigurations and coding errors. It takes a little bit of a mindshift in the vulnerability world, but that’s OK in my book.

#5 This solution is exactly what the Government needs and is exactly why SCAP was created. Imagine you’re the Federal Government with 3.5 million desktops, the only way you can manage all those is through VA automation and a tool that aggregates information from various VA products across multiple zones of trust, environments, and even organizations.

#6 Help Ed out! We need this.

• Save a Kitten, Write SCAP Content
• Security Automation Developers Conference Slides
• NIST and SCAP; Busting a cap on intruders Part 1
• Comments on SCAP 2008
• Federated Vulnerability Management

During his campaign, then candidate Obama promised he would, “make cyber-security the top priority that it should be in the 21st century. I’ll declare our cyber-infrastructure a strategic asset, and appoint a national cyber-adviser, who will report directly to me.” Since Obama was elected there has been a great deal of speculation as to what real-life changes in direction and policy that promise would bring.

Last month, President Obama appointed Melissa Hathaway to be a Senior Director of the National Security Council. She immediately launched a 60-day review of security of Federal IT systems. As a result of this effort, there is much speculation that at the end of the 60-day review she will be appointed the National Cyber Advisor–the so-called Cyber Security Czar.

Just this week, the Director of the National Cyber Security Center, Rod A. Beckstrom, over at the Department of Homeland Security resigned. The press reports of Beckstrom’s resignation indicate some frustration on Beckstrom’s part. His frustration seems to be primarily aimed at the National Security Agency (NSA). Beckstrom suggests that the NSA has been subverting his efforts to coordinate cyber security efforts across the intelligence community.

A good friend of mine has suggested that the resignation is simply political and an artifact of the transition from one administration to another. He further suggests that this also signals a shift from leadership in cyber security from civilian agencies toward the Intelligence Community taking its turn at leadership. I think he may be right, too. However, I think there is more history here than just a shift in policy from one administration to another.

In my opinion, this isn’t just about politics. There are two drivers for this move. First, congress and the administration recognize that that the on-going assault on government and commercial networks is a national security issue and an economic security and competitiveness issue too. In today’s economic droop people often forget that two of our greatest economic strengths are our accumulated intellectual property and our hard working human capital. Both of these assests are discounted when criminal and national groups successfully attack our nations IT infrastructure. Recognizing this is a good thing, I’m not going to recount the long history of cyber assault on Federal IT systems by international cyber criminals, and “state-sponsored entities.” Facts and figures concerning this on-going assault and the damage associated with it is just a Google search away.

The second driver for a policy shift is that congress and the administration recognize that the FBI, Justice, DHS approach to cyber security is an utter failure. This failed approach sees cyber security as a criminal problem with industry participating in its own defense on a ‘voluntary’ basis. This has led to comical activities such as FBI delegation going to Moscow with hat in hand asking the Russians for help in tracking down successful Cyber Organized Crime groups based in Russia. The fact that these groups may have had strong official or unofficial connections with the Russian government should have given the FBI an indication of the lack of cooperation they would face –- I believe in Law Enforcement circles this is usually called a “clue”. Likewise, FBI delegations to Russia trying to track down Russian Cyber attackers that may have had some direct level of state support were equally unproductive. To be fair, the FBI was placed in an impossible position when they were asked to organize delegations like this.

So that kind of sums up the civilian or “law enforcement” approach toward national cyber security.

That leaves us to consider the much discussed alternative, specifically a shift in policy toward giving the intelligence community leadership in providing cyber national security. There have been attempts in the past to give the Intelligence Community greater responsibility for cyber security, but while the Intelligence Community seemed to have the technical resources to address these responsibilities, they were often confused by the mission and hampered by legislation and culture. By temperament, the Intelligence Community is about collection and analysis of information. Once you start asking them to do something about a situation that they have studied or understand well, you are often asking them to not just change their mission but also act against the very culture that made them successful. To understand a situation, the Intelligence Community works quietly, secretly, and in the shadows. To take action, they have to emerge for the shadows and act very publically. This transition can be difficult and even disastrous. Such transitions can give you the Bay of Pigs, non-judicial detention at Gitmo, and odd-ball assassinations–all sorts of activities that people hate because the actions themselves were not “peer-reviewed” as best security practices.

It’s not that the Intelligence Community is incompetent (well everyone makes mistakes or hides them), it’s just that that transition from intelligence/information collection to public coordination, and policy leadership, with all of the very public meetings, policy reviews, and planning drives the Intelligence Community from a position of strength and expertise to new ground. Unfortunately, another strong element of the culture of the Intelligence Community is that if the President calls, “they haul…” They just can’t bring themselves to say no, even if it’s a bad idea.

That brings us to the question, who should be responsible for cyber security? Well, every government agency wants the mission because of the funding that goes with it. But, it’s not clear who has the right perspective and culture. I suspect that the right answer is to combine the experience, and technical know-how from several agencies and to develop some new capabilities. This means that leadership of the effort has to be unambiguous. That is precisely why I believe the Obama Administration will keep the leadership on their new approach to Cyber Security right inside the White House itself. That really shouldn’t be a surprise since that is exactly what the Obama as a candidate said he would do.

Enigma Machines Collection at the National Cryptologic Museum photo by brewbooks.

• In Response to “Cyber Security Coming to a Boil” Comments….
• Inside the Obama Administration’s Cyber Security Agenda
• Beware the Cyber-Katrina!
• Blow-By-Blow on S.773–The Cybersecurity Act of 2009–Part 3
• The World Asks: is S.773 Censorship?

The Consensus Audit Guidelines (CAG) appear, at this point, to be a reasonable set of guidelines for mediating some human threats. I’m looking forward to seeing what CAG offers and have no doubt there will be worthwhile and actionable controls in the document. That said, there are significant reasons approach CAG with skepticism and assess it critically.

The motivation for CAG is described in a set of slides at the Gilligan Group site. It starts with a focus on what CIO’s fear most: attacks, reduced operational capability, public criticism, data loss, etc. Then it rightly questions whether FISMA is adequately addressing those problems. It doesn’t and this is the genesis of the CAG.

Consensus photo by Eirik Newth.

Unfortunately CAG subsequently develops by pairing this first valid premise with a set of false premises.  These propositions are drawn from slides at gilligangroupinc.com, attributed to John Gilligan or Alan Paller:

1. All that matters are attacks. The central tenet of Bush’s Comprehensive National Cyber Initiative (CNCI) is adopted as the CAG theme: “Defense Must Be Informed by the Offense”. CAG envisions security as defense against penetration attacks. As any seasoned security practitioner knows, attacks are a limited subset of the threats to confidentiality, integrity and availability that information and information systems face.
2. Security through obscurity. CAG seems to have taken the unspoken CNCI theme to heart too, “The most effective security is not exposed to public criticism.” Since its very public December 11th announcement no drafts have been made publicly available for comment.
3. False dichotomy. CAG has been promoted as an alternative to the OMB/NIST approach to FISMA. It isn’t. An alternative would target a fuller range of threats to information and information system security. CAG should be considered a complement to NIST guidance, an addendum of security controls focused on defense against penetration by hackers. NIST has even acted on this approach by including some CAG controls into the 800-53 Rev. 3 catalog of controls.
4. There is too much NIST guidance! This is the implication of one CAG slide that lists 1200 pages of guidance, 15 FIPS docs and the assorted Special Publications not related to FISMA as detriments to security. It’s like complaining that Wikipedia has too many articles to contribute to improved learning. Speaking as someone who scrambled to secure Federal systems before FISMA and NIST’s extensive guidance, having that documentation greatly improves my ability to efficiently and effectively secure systems.
5. NIST guidance doesn’t tell me how to secure my systems! NIST’s FISMA guidance doesn’t step you through securing your SQL Server. The Chairman of the Joint Chiefs also doesn’t deliver your milk. Why not? It’s not their job. NIST’s FISMA guidance helps you to assess the risks to the system, decide how to secure it, secure it accordingly, check that a minimum of controls are in place and then accept responsibility for operating the system. NIST also provides documents, checklists, repositories, standards, working groups and validation of automated tools that help with the actual security implementation.
6. Automated security controls negate human errors. With the premise of all threats being attacks this is nearly a plausible premise. But not all security is technical. Not all threats come from the Internet. DHS, NIST, Mitre, and their partners have pursued automated security controls to enforce and audit security controls for years but automated security controls can only go so far. Human errors, glitches, unexpected conflicts and operational requirements will always factor into the implementation of security.
7. Audit compatibility as a hallmark of good security. There is a conflict of focus at the heart of the CAG, it seeks to both improve its subset of security and improve audit compatibility. For technical controls this is somewhat achievable using automation, something NIST has pursued for years with government and industry partners. For operational and management controls it results in audit checklists. But audits are fundamentally concerned with testing the particular and repeatable, security needs focus on evaluating the whole to ensure the necessary security results. An audit sees if antivirus software is installed, an evaluation sees if the antivirus software is effective.
8. Metrics, but only these metrics over here. When selecting the current crop of CAG controls decisions on what to include were reportedly based on metrics of the highest threats. Great idea, a quantitative approach often discovers counter-intuitive facts. Only the metrics were cherry picked. Instead of looking at all realized threats or real threat impacts only a count of common penetration attacks were considered.
9. With a sample of 1. As a basis for determining what security should focus on the whole breadth of the security profession was queried, so long as they were penetration testers. Yes, penetration testers are some very smart and talented people but penetration testing is to security what HUMINT is to intelligence services. Important players, expert practitioners but limited in scope and best used in conjunction with other intelligence assets.
10. Assessments rely on paper artifacts. The NIST guidance does not require paper artifacts. The first line in the NIST SP 800-53A preface is, “Security control assessments are not about checklists, simple pass-fail results, or generating paperwork to pass inspections or audits-rather, security controls assessments are the principal vehicle used to verify that the implementers and operators of information systems are meeting their stated security goals and objectives.” NIST SP 800-37 specifically and repeatedly states, “Security accreditation packages can be submitted in either paper or electronic format.”

CAG is a missed opportunity. Of the myriad problems with our current FISMA regime a lot of good could be achieved. The problems with guidance have many causes but can be addressed through cooperative development of best practices outside of NIST. The Assessment Cases for SP 800-53A is an example of how cooperative development can achieve great results and provide clear guidance. Other problems exist and can be addressed with better training and community developments.

My hope is that the Consensus Audit Guidelines will move towards a more open, collaborative development environment. The first release is sure to deliver useful security controls against penetration attacks. As with all good security practices it will likely need to go through a few iterations and lots of critical assessment to mature. An open environment would help foster a more complete consensus.

Consensus photo by mugley.

• Clouds of CAG Confusion
• A Funny Thing Happened Last Week on Capital Hill
• How to Not Let FISMA Become a Paperwork Exercise
• When Standards Aren’t Good Enough
• “Machines Don’t Cause Risk, People Do!”

This weekend, Joe Faraone (Vlad the Impaler), Graydon Mckee, and I teamed up to be a guest panel for Michael Santarcangelo’s Security Catalyst podcast.  We wax esoterically on the fine points of certification and accreditation and what kind of value that it brings to an agency or company that does it right.

You can check it out here.

• The Accreditation Decision and the Authorizing Official
• Certification and Accreditation Seminar, March 30th and 31st
• I’m on the OWASP Podcast
• DojoCon 2009 Presentation
• Communicating the Value of Security Seminar Preview

So rybolov asked for another guest blog and a hot topic on my mind recently is training. Training in the IT world is kind of like the chicken before the egg argument – every employer whats you to have the latest Security F00$ training but they never want to pay for it. What is an IT professional to do?

So why are the majority of employers hesitant to train their IT staff? Are they afraid they are going to bring new skills to your resume and then you will jump ship to the next “jump and bump opportunity”? Or do they really have funding shortfalls and budget cuts to to prevent you from taking that 7 day Bahamas IT training cruise you wanted wanted to take this winter? My take is that it is probably a little bit of both.

Let’s think about this for a minute. You are a cash-strapped IT Manager at $your_organization_name_here and have limited funding for a never-ending list of training requests. In your attempt to balance training with the rest of your budget, you eventually have to cut training to the bare minimum. If you do splurge and spend the money to send an employee to the latest security F00$ training, the next time he/she is unhappy they might leave. But chances are you have program requirements that dictate some level of yearly training that is required. This situation can also be double whammy if you are in a consulting or contracting role where opportunity costs also means you are not billable during your time in training.

My suggestion is to strike some kind of balance to make both the employee and IT management happy. If you are in the role of government management, consider the possibility of allowing your contracting/consulting staff to bill their training hours to the program instead of going on company overhead. Another possibility to consider is if you involved in IT management in the  consulting/private/commercial sector, consider offering a reasonable allowance each year towards training. It does not have to be huge amount of money to pay for an expensive 10 day conference out of town but enough to pay the tuition for a week long training class. This will show the employee that you are serious about keeping them current in their career field but at the same time put some effort on them to be reasonable with their training requests. Depending on your geographic location, you can usually find job related training locally, especially if you are located anywhere near the beltway.

I was recently faced with this dilemma in my current position. We were told training funding was not available this year and that we would have to wait until next year. After thinking about this for a while, I approached my manager with an idea they bought into. I identified an area within my field that I have really wanted to get into the last few years but the opportunity never presented itself. Since we have the need for this skill and the organization was planning on investing in this area in 2009, I offered to pay my own tuition to attend this training if they would allow me use PTO for the classes. They agreed and I purchased a one-year training package that will allow me to attend an unlimited number of classes from the vendor over the next year. When training funding becomes available again next year, we are planning on putting my training allowance towards travel costs.  In the end, I was able to turn the situation into a win-win for both my employer and my skills set. In a world of shrinking IT budgets, a little creativity can go a long way in meeting your training goals.

Football Training photo by melyviz

• Introducing the Government’s Great InfoSec Equities Issue
• Blow-By-Blow on S.773–The Cybersecurity Act of 2009–Part 2
• NIST’S FISMA Pase II–Who Certifies Those who Certify the Certifiers?
• “Machines Don’t Cause Risk, People Do!”
• Split-Horizon Assessments and the Oversight Effect

Government and information security–it really means two different things, and I’m going to break it down for you “Big Bird Stylie” as something I call the InfoSec Equities Issue.

If you’re like me, you have to be wondering the same things over and over again:

• Why is is that DHS has perpetually scored low on their FISMA report card and yet they are supposed to be leading the way for cybersecurity for the nation as a whole? (FYI, they got a B+ for FY 2007)
• How is it that the Government as a whole can have these gianormous data breaches ala the Veterans Administration and yet still claim to know how to help us secure our systems?
• Does the FTC really expect me to keep a straight face when I read OnGuardOnline?

Well fear not, dear readers, for this is the secret to understanding these conundrums:  they’re actually different issues with a different funding trail.  This budget difference, although a topic we security people shun whenever we can, is insanely critical.

For securing their own internal systems, the Government faces exactly the same problems that most companies have only amplified because of scale–security is a cost center, and cost centers get reduced wherever possible.  Fudiciary responsibility to the taxpayers requires that the agency CISO’s staff do more with less, and that’s not a happy thought if you end up on the wrong side of the security budget equation.

Minimal Security photo by °Florian.

When it comes to security of external systems (and some national-level internal programs), the Government runs these as a program and offered as a service to the nation.  Some typical programs include the following:

• Almost all of the National Cyber Security Division
• Department of Justice’s Computer Crime and Intellectual Property Section 
• The National Infrastructure Protection Plan
• DHS’s Science and Technology Directorate
• And yes, even NIST’s FISMA Project

It’s one of Washington’s best-kept secrets: being a program manager in the Government means that you get a mission and a bag of money, and your job is to decide where to spend it all.  This is the sweetest job and the one that you want whether it’s in security or any other discipline that you could image is a Government service–health care, law enforcement, or even the infamous “Gub’mint cheese”.

However, all is not peachy for programs.  They can get cancelled based on political will and trends, so if your program ends up non-favorably in the Washington Post, you might end with your bag of money pilfered for other programs.

Heightened Security photo by robmcm.

This concept of divergent funding is all nice and neat except, dear readers, when the issues are not separate–ie, when an internal IT system protected by the internal budget supports a particular program.  For example, consider the following scenarios:

• Security of vulnerability data at US-CERT (external) that resides on a Government IT system (internal).
• A financial system (internal) that tracks distributions to welfare recipients (external).
• A government website (internal) that supports awareness and training on security issues affecting individual citizens such as identity theft (external).

Now this is the concept behind the way Government is supposed to be running security programs:  the internal funds pay for the centralized security and the funded programs pay for any level of security for IT systems that they sponsor.

But several catches:

• The system owner has to understand how to budget for or ensure that security for their program is budgetted for.  Somewhere in there is an understanding of security risk.
• The system owner (who in theory has better funding and therefore better security) is dependent upon the centrally-managed security (which in theory has less funding and therefore worse security).
• Program-specific security comes out of the program, which means that higher security costs means that the program manager can’t spend money on the services they provide, which is where they really want to be spending it.
• A ton of negotiation is required to figure out responsibilities between the program manager and the CIO/CISO.
• If the agency takes too much money out of the program budget for security, we run into the same fudiciary responsibility problems in that we’re not managing our money properly.

• The Press has Me all Confused
• When the Feds Come Calling
• Got Training?
• Splunk Goes After the FISMA Lucre, They’re not Alone
• HR 5983–DHS Now Responsible for Contractor Security