OK, so the Government Accountability and Office delivered their testimony to Congress on the Government’s dismal state of security.  You can get the testimony here and check out some responses here and here.

My favorite 2 quotes: 

“Federal agencies continue to report progress in implementing key information security activities. The President’s proposed fiscal year 2009 budget for IT states that the federal government continues to improve information security performance relative to the certification and accreditation of systems and the testing of security controls and contingency plans.”

Followed by:

“An underlying cause for these weaknesses is that agencies have not fully or effectively implemented agencywide information security programs.”

Maybe I’m a bear of very little brain, but these sound like GAO is  contradicting itself.  How can things be getting better when they don’t exist?  Truth be told, from a government-wide view, you have to rely on metrics to give you a picture of how things are going, but at the end of the day, they’re still just that, indicators.  Of course, I haven’t worked with all 24 agencies, so maybe my worldview is pretty myopic.

Now, I don’t know about all of you, but I have yet to see an infosec program where there actually was excessive resources to get the job done.  As a result, in the sane world we have to prioritize:  is it worth my time and money to implement a better automated vulnerability scanning tool or mandatory drug testing for IT staff?

But here’s the rub:  in a compliancy-driven information security model, there is no way to priotitize what you need to get done.  It all bears the same weight.  In the world of GAO, if you can not prove that a control exists, you have not implemented a security program.

We’ve talked metrics before, and this has always been one of my problems with the way the Government is doing FISMA reporting right now:  if your metrics are not actionable–that is, you do not use the results to make changes–all you are doing is security management through shame.

Now the things that are happening, I see this is some fairly good analysis of the numbers behind the numbers behind the numbers and what we’re going to see over the next couple of years:

• The Information Systems Security Line of Business:  I think this is a good thing, but it has some issues that the Government needs to resolve before it becomes more than just a pet project.

• Federal Desktop Core Configuration:  Fantastic idea, but the implementation is harder than OMB thinks it will be–you can’t just shake the magic FISMA wand at your LAN and think that the legacy applications will still work.  Now for those of you who think FDCC is just the end, wait for the Router Core Configuration and Server Core Configuration.

• SmartBUY:  Centralized COTS buying.  This is pretty happy, although it’s tangentially related to security, it’s more of an overall IT management strategy.

• Trusted Internet Connections initiative:  I like this, I really do, but implementation is a bear.

• Clarify requirements for testing and evaluating security controls:  Auditors need to say this:  “We could have done a better auditing job but the standard was lacking”.  Yes, the standards for gathering metrics suck, but they’re getting better as we go.  My opinion is that in order to evaluate security controls, you need to have a definitive set of security controls in the first place, but if you’re doing that, you’re looking at compliance and “audit risk” not mission risk and risk to IT investments.

• Enhance FISMA reporting requirements:  The standardes have been evolving for 5 years and will continue to evolve.  So far we’ve been gathering metrics for the sake of gathering them, now it’s time to figure out specifically what we want to know and tailor the metrics to that question.

• Consider conducting FISMA-mandated annual independent evaluations in accordance with audit standards or a common approach and framework:  Um, I thought we already had this.  Maybe I’m just slow-thinking today.

So, the Guerilla CISO’s takeaways from this conversation:

• If you look at the metrics and see that they are improving, what more do you want?
• Government needs to learn how to prioritize.  Their metrics should support this goal.
• It’s the job of an auditor to always find something and to always CYA by spreading stories of woe and gloom.  Anticipate that this will happen and don’t be outraged when it does.

• Comments on the Annual OMB Security Report to Congress
• GAO’s 5 Steps to “Fix” FISMA
• 20 Critical Security Controls: What They Did Right and What They Did Wrong
• More GAO Testimony
• Cage Match: OMB Report V/S GAO Report, Only One Comes Out Alive

OK, the title is for hyperbole purposes, but I think that the current Government security model doesn’t work with the way we do Software as a Service (SaaS) today. =)

Karen Evans has officially thrown her hat in the ring to support Software as a Service. I agree, but I think it’s also harder to accomplish than OMB might think. I’ve said this before, but information sharing, security, and SaaS doesn’t fit into The Government Way of Doing Things ™, and that needs to get fixed.

Hurdles that the government needs to overcome for SaaS (and I guess Lines of Business as a whole):

• Personnel Security: How do I know that my user population is cleared to view the information that I’m providing, and how do I ensure that I get notification when they leave? (note: HSPD-12 in theory could fix this)
• Trustworthiness of Service Provider: How do I trust a server and/or application operated by another agency?
• Interconnectivity: Can we route SaaS traffic over the Internet or do we need to interconnect our LAN/WANs to get to the resources?
• Assurance: How do I prove to a customer agency that my solution meets their security needs without running into “Not Invented Here” problems?
• Certification and Accreditation: If this is a mission-critical system for me, how do I account for the security of it when it’s a low-impact system for the service provider? What do I do if I want the service provider to increase some of the security on the system?
• Guidance: We have OMB telling us what they want to see accomplished (which is SaaS in general) but there isn’t any formal guidance on how to do this and still stay within the bounds of our security framework.

All of the current guidance for information sharing between IT systems is based on IP connectivity between 2 LAN/WANs. The process (SP 800-47 if you want to research) breaks down like this:

• Certify and Accredit the networks of both agencies.
• Do a Risk Assessment of the connection.
• Establish a Memorandum of Understanding (manager-level, we like you, you like us, these are the rules on what you can do with our data).
• Make a “firewall sandwich with circuits betwixt” with each side owning their own firewall so if they decide they don’t want to play anymore, they can unilaterally kill the connection.
• Establish an Interconnect Agreement (technical level, routing and firewall configuration, technical POCs, etc)
• Make the connection.

Nowhere in there is anything we can use for SaaS. Believe it or not, I’ve seen well-intentioned IA analysts trying to get people to sign an interconnect agreement for an RSS feed out on a website when in all actuality, the interconnect is with the Internet and it’s your responsibility as a feed customer to sanitize the input before you do anything with it.

SP 800-95 covers web services but from a Service-Oriented Architecture (SOA) angle but doesn’t talk about the interaction between the players and processes.

Hence, the Guerilla CISO’s guide to SaaS in the government:

• Determine that you want to be a vendor for SaaS. You can be G2G or C2G.
• Pick a security baseline. I usually recommend a Moderate FIPS-199 because it will apply in most contexts.
• Build your SaaS system.
• Certify and Accredit your SaaS system.
• Provide a SaaS kit to your supported agencies containing the following information:
  • Service delivery options (interconnect or via Internet)
  • API/Service Specifications
  • System Security Plan
  • Security Test and Evaluation Report
  • Sign a Memorandum of Agreement that is basically an Acceptable Use Policy at a department level.
• Perform security upgrades at a partial cost to the supported client agency.
• Periodic client agency meetings with the service provider.

• HR 5983–DHS Now Responsible for Contractor Security
• Lines of Business, Relationships, and Trustability
• Alternative Uses for System Security Plans
• Response to “What is Information Assurance – The Video”
• Compensating Controls

Roger writes about his workplace instituting a bag-check on a Friday afternoon. My first though was “Gack, that’s part of the FISMA guidance? Somebody definitely was reading between the lines,” followed by, “I wonder how much miscarriage of security is conducted by people who claim to be the long-lost intellectual progeny of Ron and Marianne (Ron Ross and Marianne Swanson from NIST, work with me here)”. Then I remembered my own security strangeness and laughed….

So a couple of years ago I was in a meeting between my physical security guy and an auditor from the government. I got there a couple of minutes late so I didn’t get introduced. No biggie, my guy had everything in control and had done most of the work with this auditor already. A tip-off should have been that I was the only guy in the room wearing a suit, thereby identifying myself as some kind of manager, but alas for our auditor wasn’t that bright.

But then a problem sprung up: it all revolves around physical access policy and procedure. I had a procedure that said that all employees, contractors, and visitors will badge in EVERY time they enter the building. OK, some of you should be saying a big “DUH!” at this point, and you would be right. Anyway, the auditor didn’t like that. They wanted a specific policy line that says “When you come into the building after a fire drill, you should all badge back in.”

I watched my physical security guy try to rationalize the finding away. “We already say that here in the general procedure,” he said. He drew a Ven diagram on the white board–“See, fire drill is part of ‘every'”. The auditor just wasn’t buying it.

As a last-ditch attempt, I stepped in with the classic contractor phrase: “Where does this requirement come from?” The auditor looked at me and not taking the hint that A) I know what I’m doing, B) I teach this stuff and C) I’m the guy in the suit, you would think I was important in some way; replied “Well, it comes from NIST. You see, they have this book of requirements called 800-53 and it says that you have to have a process to badge back in after a fire drill.”

At that point, I realized the situation. Life had handed me a bozo and it was easier to write a one-line correction than it was to try to educate them on the error of their ways and ask them to show me where it says that in SP 800-53.

So my advice to Roger: One afternoon checking bags (yay, my favorite activity to do in my “spare time”!) is sometimes easier than trying to educate your auditor.

And watch out for bozos. They’ll wear you down to a nub. =)

• Mike’s Guide to Information Security Policy
• Opportunity Costs and the 20 Critical Security Controls
• The Vendors are Already Jumping on the 07-11 Bandwagon
• In Search of a Better Catalog of Controls
• Some Comments on SP 800-39

OK, so it’s about as sensationalist as government news gets (but still way sedate when compared to Brit-nay news), but check out this article on reauthorization of FISMA.
Let’s do some numbers:

• Assuming a $64B IT budget for the federal government (budget request for FY 2007)
• Assuming $29B for 4 years (OK, so we conveniently clipped that out of the headline)
• That is $7.25B/year (29/4)
• That is 8.83% of the total IT budget. (64/7.25)

Now before everybody shows up outside the Capitol with their torches and pitchforks because we’re spending $29B on FISMA (which doesn’t work, and SANS will attest to it), let’s think about that number.

The 9% of the total IT budget is about right on track (some say less, some say more) with large companies. The problem is, the CBO reports don’t tell us what exactly is behind the numbers. IE, $29B could be any combination of the following:

• Direct FISMA costs such as quarterly reporting
• Semi-direct FISMA costs such as C&A, contingency planning, and risk assessments
• Direct security costs such as policy, procedures, firewalls and IDS
• Indirect security costs such as processes taking longer because you have the security layer of abstraction

If it only includes the first point, then I’m shocked but it figures that the study would only include the direct costs. If it includes points 1, 2, and 3, then it’s inline with what I think the budget should be. If it includes all 4 points, then I think it’s a little bit on the light side for a number.

Thing is, the contractors are looking at $29B and thinking it’s a huge market. The FISMA critics will look at FISMA and say it’s horribly expensive.

It’s all different sides of the same coin: does anybody really know what FISMA means?

• Core Belief #4 — Compliance is a Dead-End
• More GAO Testimony
• FISMA: Better if PCI. WTF?
• HR 5983–DHS Now Responsible for Contractor Security
• OMB Wants a Direct Report

Let’s introduce people to a manufacturing concept: that of zero defects and the zero-defects mentality.

See, life in the army during peacetime (and rarely during wartime) sometimes means that you are always “inspection-ready”. In some of the units I’ve seen, they were big on inspections. They would have a formal barracks inspection every week and informal inspections daily. If this seems a little obsessive, then you are right.

So what happens in units like this? Well, people start working around the system: they live out of their cars! If you’re going to do that, why don’t you skip the barracks altogether and just issue people cars to live in? Well, because obviously then the management would expect to inspect the cars for orderliness.

Of course, what does this have to do with security? Well, in most companies and the government in particular, you’re trying to project a zero-defects image to your customers. That’s the way the business and marketing side works. Marketing and security don’t mix precisely for this reason: one is trying to project an image of perfection, the other needs understanding of flaws and risks in order to make informed decisions. I won’t even go into security vendors, but you should be able to extrapolate now what I feel about some of them.

But in security, we’re not doing ourselves any favors by presenting a zero-defect facade to the rest of the world. Sometimes you need disclosure if you want to change the world. That’s why Adam Shostack is so gung-ho on breach disclosure, and I think disclosure is working to the extent that the public gradually is getting over the stigma attached to a breach at least enough to differentiate the “typical breach” with the “holy sh*t that’s an obscene breach!”

Looking at FISMA report cards in particular, it’s turned somewhat into a “management via public disgrace” activity. Not bad in some cases, but then again, it’s not exactly the kind of information you put out there when you’re expecting positive change–you’re encouraging everybody to show a zero defects face out of self-preservation.

Adam has a phenomenal idea that he presents in his breach research: using the public health model for IT security. We have to be able to track breaches back to the root cause in order to prevent it further. If I take my network and connect it to your network, I have a right to know what vulnerabilities you have. Carry this public health model maybe a bit too far, I’m now sleeping with all the people you’ve slept with, and if you come down with an STD, I have a right/need to know.

The good news is that this is where the Government is headed: disclosure with business partners. I’m not sure how it will all work out in the end and if even culturally the Government can make it work, but it has potential to be a good thing.

• And in This Corner, Special Publication 800-60
• Been Off Teaching
• Workin’ for the ‘Counters: an Analysis of my Love-Hate Relationship with the CPAs
• In This Corner, the Business Reference Model
• Monks, Compliance, Risk, and Government

Oooh, there is a committee formed by some notables to provide suggestions to the new President. My thoughts are mixed on this one.

Then Richard Bejtlich gets involved, suggesting Jacquith’s Security Metrics. Yes, that’s part of it.

This is the world according to rybolov and some responses to the various people:

1. What exactly are you trying to measure? When it comes to the FISMA scores, what are we doing except for “Security management through shame?” Metrics are not effective unless they produce something that is actionable. The metrics should be aimed at questions like “Are we getting the kind of security we would expect for as much as we are spending” or “Is our amount of security spending correct for the level of risk that we have” or even “As a nation, where do we need to be putting in additional controls for high-risk activities?”
2. You need a catalog of controls. It’s that simple, not everyone is a rocket scientist when it comes to enterprise risk management, so you need a set of rules to justify the budget. Yes, there is too much time spent doing that thanks to the 5 layers of oversight on where the money is going.
3. Today’s government CIO and CISO serve in an advisory role with Congress micromanaging their budget. Let’s just say that out of all the criteria for selecting representation in Congress, understanding security budgeting isn’t even on the map. Now how do you expect to win in that environment? You can’t continue to beat up the CIOs and CISOs in the executive branch because of decisions made by the legislative branch. You also can’t expect some things that work in the private sector to work in government because the money trail is very different.
4. You will not accomplish anything with the same people doing the same things. Do you think that with the same people doing $FooFramework instead of a FISMA framework you will still be able to succeed? Basic problem is that we have a higher demand for security people than we have clueful people to fill the gaps. As a result, you have to deal with a high percentage of also-rans and charlatans.
5. How do we get the people trained to where they need to be? We have a significant gap in abilities v/s our needs for security people. I’ve talked about this before. http://www.guerilla-ciso.com/archives/270
6. Network Security Monitoring (NSM) practitioners need to figure out how to market to these people as “yes, I’m a Subject Matter Expert and here’s how I fit into your catalog of controls”. In other words, make it easier for people to justify hiring you guys. A *good* FISMA person could sit down in the course of a couple of hours and give you something to trace you back to 800-53 controls and how you satisfy them. In other words, I think Bejtlich has some phenomenal ideas and I’m fairly sold on NSM, but how do I get people to “buy in” when they have all these other ideas competing for people, time, and money?
7. NSM guys need to make contacts with the people who write the framework and convince them that what they do has merit and that the framework should be changed to include the parts of NSM that aren’t already there. Remember my audience is Congress, how do I justify the money to get NSM implemented? Well, I get it added to the rules or I tell people how NSM is implied in the rules.

• Ack! With the Mandates!
• It’s All About Common Controls!
• Do You “Do It” or Do You “Get It”?
• An Open Letter to NIST About SP 800-30
• Core Belief #4 — Compliance is a Dead-End