We’re calling this part II - and it’s being advertised as:

“How to conduct a risk analysis and produce a high impact deliverable to senior management.”

With topics:

• The life-cycle of a quantitative risk analysis
• Key control opportunities against targeted attacks
• Getting senior management to understand the risk posed to the business

I got to do the Q&A backchannel on the last presentation, and there were great questions asked.  I think this presentation will be even more exciting, as it’ll cover both analyst and management considerations.

If you’re a regular reader of the blog, I don’t think you’ll have to have attended the last one for this one to be worth your while.

REPEAT PERFORMANCES OF THE FIRST WEBEX ARE AVAILABLE

We’ve had a some folks who attended the original WebEx ask us to do a “private” performance for just their  infosec group and/or other members of their organization (like audit and ERM).

We’ve been given the OK to do these provided that there are a minimum of 5 attendees.  Leave me a comment to this post if you’re interested (be sure to include your email in the submission - it won’t be made public but we’ll need it to contact you to set this up), or just email me:  alexh -shift2- riskmanagementinsight:dot:com.

And if you missed it the first time, the playback of the first preso is here, and the slides are here.

Now the interesting thing to me is that NIST is working with some other players (DNI comes to mind) on reference implementations of 800-53A.  This is big, so big that I can’t add enough hyperbole to it.

Why do they need to do reference implementations?  Well, because by itself, SP 800-53A is dangerous if it’s given to people who “don’t get it”.  By that what I mean is this:

• SP 800-53 needs tailoring to distill into actual requirements.
• SP 800-53A needs a huge amount of tailoring to distill into test cases/procedures that match the tailoring that you did with 800-53.
• Taken at face value, 800-53 and 800-53A become the source of “death by compliance”.
• If you think the auditors could grill you to death with 800-53, 800-53A gives them tons more material.

Now time for a war story: I worked on a project where the contractor was having a hard time building a security program, mostly because they didn’t have the right staff to get the job done.  The government told the contractor to use 800-53A as a starting point, and 6 months of insanity followed with 13 “security engineers” in a conference room cranking out documentation that had no basis in reality.  At the end of it all, the contractor handed the Government a bill for $1M.

Now don’t get me wrong, I like the ideas behind 800-53A, but the first thing you need to know when you start using it is when you shouldn’t use it:

• Don’t run test procedures on every computer you have, use an automated tool and do spot-checks to validate that the automated tool works.
• Use less test procedures on low-criticality systems.
• “This procedure is conducted as part of the hardening validation process.”
• Common controls are even more important because you do not want the repetition of effort.

And whatever you do, don’t let 800-53A turn your risk management into a compliance activity.  It has all the potential to do that.

US Government Doc’s photo by Manchester Library.

Bookmark to: