Back in the day when I was PFC Smith, they taught me in school that one of the definitions of good intelligence is that it had 3 qualities:

• Timely–you get the information with enough time to act on it
• Accurate–yes, it’s not an exact science, but as accurate as you can get and still be timely
• Relevant–it answers the questions that the commanders need to make decisions

You can extend these 3 qualities really to just about any piece of information such as vulnerability reports, security metrics, audit findings, or vendor presentations.

Now an interesting piece of trivia: Inside the US Federal Government, security practitioners are charged with providing “adequate security”. I’ve listened to Hord Tipton and his travails with the Cobell v. (Kempthorne|Norton|Babbit) case and it was interesting to me because he had to prove that his organization provided “adequate security”, so there was much talk about the definition of what that entailed.

Really what I’m looking for is a good, concise definition of “adequate security” in keeping with the values of good intelligence.

• Threat-specific–we protect against all likely types of attack
• Cost-effective–we’re not spending money just to check a box in a compliance framework
• Relevant–we support the business processes

• You Didn’t Outsource Your Responsibilities
• Random Thoughts on “The FISMA Challenge” in eHealthcare
• Keys to the Outsourcing Kingdom
• How Much Security Should the Outsourcer Do?
• Split-Horizon Assessments and the Oversight Effect

I’m an engineer at heart. I love technology and I love to build. I can’t really understand the operational mindset, which is a weakness I have to work around at times, considering I’m managing security for an operational division.

Back in November, I spent a month building $3Million worth of equipment. The reason? It was the biggest risk to my organization at the time–failure to meet a delivery deadline.  As a side benefit, I know what each and every device does.

In fact, if I haven’t done anything techie in a week, I start to get antsy. I go home and rearrange my linux partitioning scheme just to move data around.

There’s a lesson in there: Get out of the office and into the Data Center at least once a week, even if you’re a total wonk.

Common sense, right? But you would be surprised how many security people don’t get out of their cubicle and go see the technology. One of the critical failings of how we do security in DC is that because there is a shortage of people with hard skills, we send in the people with soft skills such as financial auditors, technical writers, and quality assurance. Don’t get me wrong, there is a place for these people in security as long as they adopt a security mindset, but overall your security staff need to have some sort of technical background.

Question is, how do you get your non-technical staff into the technology?  Believing in practical solutions and advice, I have a couple tactics, techniques, and procedures for you:

• Give them the responsibility to do a data center walkthrough every week
• Assign them as direct support to a smaller project
• Turn them into a mobile vulnerability scanning and reporting team
• Send them to investigate the security implications of a specialized technology like a SAN
• Give them a cubicle next to the system administrators and encourage them to socialize

Of course, none of this is really a new idea, it’s basic career development activities for a junior security staff member.  I guess that’s the topic for a later post. =)

• Trouble Tickets
• More Security Controls You Won’t See in SP 800-53
• NIST and SCAP; Busting a cap on intruders Part 1
• And in This Corner, Special Publication 800-60
• How I Do the “FISMA Thang”

There’s a nice article at the Smithsonian about the difference between riddles and mysteries. I received this via the security metrics email list.

Risks and Riddles

This reminds me of intelligence work, for obvious reasons.

There are 2 major types of offensive actions an army can conduct: deliberate attack and movement to contact. (Yes, those of you pedantic enough will bring up hasty attacks and a dozen other scenarios, I’m being a generalist here =) )

In a deliberate attack, you know roughly what the Bad Guys are doing–they are defending key terrain. The task for the intelligence people is to find specific Bad Guy battle positions down the the platoon level. This is a puzzle with a fairly established framework, you are interested in the details.

In a movement to contact, you have a very hazy idea that there are Bad Guys out there. You move with an eye towards retaining flexibility so that you can develop the situation based on what you learn during the mission. The task for the intelligence people is to determine the overall trend on what the Bad Guys are doing. This is a mystery, and you’re more concerned with finding out the overall direction than you are with the specifics–they’ll get lost due to “friction” anyway.

Now translated to information security, there is some of what we know about the Bad Guys that is static and therefore more of a puzzle–think about threats that have mature technologies like firewalls, Anti-virus, etc to counter them. Solutions to these threats are all about products.

On the other hand, we have the mysteries: 0-day attacks, covert channels, and the ever-popular insider threat. Just like a well-established military has problems understanding the mystery that is movement to contact, information security practitioners have problems responding to threats that have not been well-defined.

So information security, viewed in the light of puzzle v/s mystery becomes the following scenario: how much time, effort, and money do we spend on the puzzles versus how much time do we spend on mysteries? The risk geek in me wants to sit down and determine probabilities, rate of occurance, etc in order to make the all-important cost-benefit-risk comparison. But for mysteries I can’t, by definition of what a mystery is, do that, and our model goes back to peddling voodoo to the business consumers.

• It’s a Problem of Scale!
• The 10 CAG-egorically Wrong Ways to Introduce Standards
• Trouble Tickets
• Web 2.0 and Social Media Threats for Government
• MOUT and Risk Management

Message to vendors:  If you want to break into the Managed Service Provider market, there is one thing extra that you need to do.

Enterprise-class products are reasonably good at being able to support a 3-tier model.  That way you can abstract out everything into  whatever architectural model you want.  Need more database oomph, add some more power at the database tier.  Need to support a remote site, put a data collector out there on the management LAN and just send events back to the central collectors.  This stuff is great.

But when it comes down to MSPs, there is one thing that we need above and beyond what enterprise-class products have.  We need to be able to flag data as belonging to a certain customer.  That way, once events have trickled up to the Single Pane of Glass (TM) that the NOC operators use, we still can tell which environment the event came from.  That requires tagging and the simple ability to have multiple devices on one IP address when clients have address collisions (everybody using 10.0.0.0 comes to mind).

• In This Corner, the Business Reference Model
• Sprinkling on the Magic FISMA Fairy Dust
• A Little Story About a Tool Named #RefRef
• Compensating Controls
• Database Activity Monitoring for the Government

I don’t think we should attach the word “requirement” to any controls in a framework or catalog of controls. I wish we could use the word “needs” instead.

While it’s a subtle distinction, it implies that there needs to be some wetware involved in order to translate the catalog of controls into real requirements that an engineer (security or otherwise) can build to. Until we do that, we’re only frustrating the people who have to implement.

• Some Random Thoughts on C&A SOPs
• In Search of a Better Catalog of Controls
• An Open Letter to NIST About SP 800-30
• Always Behind
• Opportunity Costs and the 20 Critical Security Controls

Back in my army days, most good leaders carried around a book with info on their squad.  We jokingly called these our “Book of Death”.

Anyway, I aggregated all the spreadsheets I’ve used over the past year, sanitized them, genericized them, and put them up on the web.  Feel free to borrow heavily or let me know what maybe needs to be added or expanded.

Really, I’m just testing the waters to see if there is interest in taking something like this on as a full project or if it should remain a Mike Smith skunkworks project like it has been so far.

CISO’s Book of Death V0.1

• William Jackson on FISMA: It Works, Maybe
• White Professional Male Turned CISSP Seeks Mega-Sized Security Management Model
• Our “Peace Dividend”: DISA SRR Scripts
• CISO’s “Book of Death” for June 22nd
• All Quiet on the ISM-Community Front