In Retrospect, First Recorded SCADA Casualties

Posted April 10th, 2008 by

I always love it when people review the past and find out new things.

But then they cheapen the experience by something like this:  “If the SCADA system would have been 800-53-compliant, then these two deaths wouldn’t have happened”.

Well, where I come from, SSG Smith has a saying:  “If ‘if’ was a ‘fifth’, we would all be drunk”.  Now this colorful phrase basically means in polite-people-speak that you can “what-if” a past situation to death, but it doesn’t really change what happened.

Credit card breach companies, I feel your pain because you deal with this every single time:  “If they would have been PCI-compliant, this wouldn’t have happened”.    =)



Similar Posts:

Posted in NIST, Rants | No Comments »

FISMA: Better if PCI. WTF?

Posted March 31st, 2008 by

That’s why it’s time to reassess what FISMA should measure.  One model worth considering: the audit guide used by the payment card industry.”

Wow, just wow.  I didn’t know what to say for a couple of minutes…

But here goes.

Guys, seriously, the only time that FISMA gets any airtime at all is this time of the year, when all the reports come out.  The rest of the time, nobody cares unless they’re the CISO’s staff in an agency or they’re trying to pitch a product or service to the government.  Yes, I resemble both of those.

Of course, by now the responses to the annual FISMA reports are getting rote:

  • A couple newspaper articles about security in the government sucks.
  • Some blog posts about how since the government can’t get their act together, they shouldn’t tell the rest of us what to do.
  • GAO and OMB testify in front of congress about what the numbers mean.
  • Recursive commentary about how the numbers mean that collecting the numbers is worthless.
  • A formal statement from SANS about how FISMA is failing.
  • Some techno-geeks chiming in that if only the government would do this one thing that they’re a specialist in, that all of their security problems would go away.
  • A plethora of people misunderstand what “that FISMA thing” is, thinking that it’s some report card.
  • Everybody forgets about it all until next year.

Even I’m part of that, being a contractor and all who sells security services.

So where am I headed with all this?  Well, just to point out that there are a ton of people out there who get to play armchair quarterback every March about FISMA and security in the government as a whole.  It’s fun, but we’ll forget about it as soon as it’s tax time.



Similar Posts:

Posted in FISMA, Rants | 3 Comments »

Remembering Accreditation

Posted March 20th, 2008 by

Accreditation is the forgotten and abused poor relation to certification.

Part of the magic that makes C&A happen is this:  you have certification which is a verification that all the minimum security controls are in place, and then you have accreditation which is a formal acceptance of risk by a senior manager/executive.  You know what?  The more I think about this idea, the more I come to see the beautiful simplicity in it as a design for IT security governance.  You really are looking at two totally complete concepts:  compliance and risk management.

So far, we’ve been phenomenal at doing the certification part.  That’s easy, it’s driven by a catalog of controls and checklists.  Hey, it’s compliance after all–so easy an accountantcaveman could do it. =)

The problem we’re having is in accreditation.   Bear with me here while I illustrate the process of how accreditation works in the real world.

After certification, a list of deficiencies is turned into a Plan of Action and Milestones–basically an IOU list of how much it will cost to fix the deficiency and when you can have it done by.

Then the completed C&A package is submitted to the Authorizing Official.  It consists of the following things:

  • Security Plan
  • Security Testing Results
  • Plan of Actions and Milestones

The accreditor looks at the C&A package and gives the system one of the following:

  • Denial to Operate
  • Approval to Operate
  • Interim Approval to Operate (ie, limited approval)

And that’s how life goes.

There’s a critical flaw here, one that you need to understand:  what we’re giving the Authorizing Official is, more often than not, the risks associated with compliance validation testing.  In other words, audit risks that might or might not directly translate into compromised systems or serious incidents.

More often than not, the accreditation decision is based on these criteria:

  • Do I trust the system owner and ISSO?
  • Has my assessment staff done an adequate job at finding all the risks I’m exposed to?
  • What is the extent of my political exposure?
  • How much do I need this system to be up and operational right now?
  • Is there something I need fixed right now but the other parts I’m OK with?

For the most part, this is risk management, but from a different angle.  We’ve unintentionally derailed what we’re trying to do with accreditation.  It’s not about total risk, it’s about audit risk.  Instead of IT security risk management, it becomes career risk management.

And the key to fix this is to get good, valid, thorough risk assessments in parallel with compliance assessments.   That requires smart people.

Smart CISOs out there in Government understand this “flaw” in the process.  The successful ones come from technical security testing backgrounds and know how to get good, valid, comprehensive risk assessments out of their staff and contractors, and that, dear readers is the primary difference between agencies that succeed and those who do not.

NIST is coming partly to the rescue here.  They’re working on an Accreditor’s Handbook that is designed to teach Authorizing Officials how to evaluate what it is they’re being given.  That’s a start.

However, as an industry, we need more people who can do security and risk assessments.  This is very crucial to us as a whole because your assessment is only as good as the people you hire to do it.  If we don’t have a long-term plan to grow people into this role, we will continually fail, and it takes at least 3-5 years to grow somebody into the role with the skills to do a good assessment, coming from a system administrator background.  In other words, you need to have the recruiting machinery of a college basketball program in order to bring in the talent that you need to meet the demand.

And this is why I have a significant case of heartburn when it comes to Alan Paller.  What SANS teaches perfectly compliments the policy, standards, regulations, and complicance side of the field.  And the SANS approach–highly-tactical and very technologically-focused–is very much needed.  Let me say that again:  we need a SANS to train the huge volume of people in order to have valid, thorough risk assessments.

There is a huge opportunity to say “you guys take care of the policy and procedures side (*cough* the CISSP side), we can give you the technical knowledge (the G.*C side) to augment your staff’s capabilities.  But for some reason, Alan sees FISMA, NIST, and C&A as a competitor and tries to undermine them whenever he can.

Instead of working with, he works against.  All the smart people in DC know this.



Similar Posts:

Posted in FISMA, NIST, Rants, Risk Management, What Doesn't Work, What Works | No Comments »

Layers Upon Layers of Oversight

Posted February 28th, 2008 by

Think you’ve got it bad?  Think about our poor ISSO for a government IT system.  You have the following people looking over your shoulder:

  • Chief Information Security Officer
  • Information System Security Manager (ie, a manager of ISSOs)
  • Certification Agent
  • Independent Validation and Verification Teams
  • Inspector General
  • Office of Management and Budget
  • Government Accountability Office

It’s a high-pressure situation, and the phrase “Who watches those who watch the watchers?” comes to mind.

Just a thought for today:  how risk-adverse do you have to be in a situation like this, and how career-limiting can it turn out?



Similar Posts:

Posted in Rants | 1 Comment »

Been Off Teaching

Posted February 27th, 2008 by

I taught a 2-day seminar yesterday and the day before on Certification and Accreditation (NIST SP 800-37).  It’s fun but tiring, and yesterday I definitely got worked pretty hard, teaching 800-53, 800-53A, and C&A in the SDLC

I like to teach because I always learn when I do it.  But then again, I learn when I blog, too.

Anyway, revelations from yesterday, and things that I don’t really have an answer to yet:

#1 We need a better tool than a POA&M because we’re trying to use them in 2 different ways.  For those of you who don’t govorit’ govie, a POA&M is a “Plan of Actions and Milestones”, what you in the civilian world would call an action items list, a punch-list, or even a list of vulnerabilities.  The problem is that we’re trying to use the POA&M both as a short-term tasklist and as a long-term strategic planning tool.  I need to be able to do both, and I’m not sure if one POA&M list is the end-all be-all.  What I really need is 2 lists, one with a 30-60-90-day scope that is the ISSO/Project Team’s view, and one that is a long-term 1-2-5-year scope to mitigate programatic, enterprise-wide vulnerabilities that require CapEx or other investment such as standing up a secondary data center to support DR/COOP/BCP/$FooFlavorOfTheMonth.

#2 We have 2 conflicting purposes in information security in Government.  One is presenting a zero-defects face to the world.  The other is being able to freely discuss problems so that we can get them fixed.  Understanding the dynamics between these 2 competing ideas is understanding why the Government succeeds in some areas and fails in others.  To be bluntfully honest, I don’t think that as a profession, security people have a good, valid model to deal with this conflict, and until we do, we will have a significant cultural obstacle to go around.

#3 As a government (and as an industry), we are good at the tactical level and fairly good at the operational level, but where we need peoples’ thought-power to go is towards the strategic level.  This is my big heartburn about FISMA report cards:  what we should be doing is to collect Government-wide metrics in order to answer questions that we need to understand before we make strategic decisions.  As it is right now, our strategic moves are ad-hoc and consist mostly of trying to upscale some good security concepts (FDCC, limiting Internet connections, etc) into something that might or might not work at such a huge, megalithic scale.

#4 We’ve bought into the fact that CISOs work for the CIO.  This is old-school stylie and I’m not convinced that this is the way to do it.  If you look at the security controls in SP 800-53, there are activities entirely out of scope of the IT department.  Usually these involve gates, guards, and guns; personnel security; and facilities management.  For the time being, the official response is that “well, the CISO has to work with the people in charge of those areas to get their job done” and I’m thinking that maybe we’ve done a disservice to the senior security officer in our agencies by not having them report directly to the agency head.  Maybe we need true CSOs to take care of the non-IT security aspects and a CISO to take care of the geekspace.

The funny thing to me is that some of our students come in expecting to get spoon-fed information on the one true way to do C&A, and what most of them walk away with is ideas for thought on what are the strengths and weaknesses to how we do business as Government information security people and how do we make it better.

The last thing that I noticed yesterday after all the classes were over:  we taught a C&A class and did not have a dedicated session on what a System Security Plan is and how to write one.  Deep down inside, I like this, because if you do the right things security-wise, you’ll find that the SSP practically writes itself.  =)



Similar Posts:

Posted in FISMA, NIST, Rants, What Doesn't Work | 2 Comments »

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

Posted February 27th, 2008 by

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



Similar Posts:

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

« Previous Entries Next Entries »


Visitor Geolocationing Widget: