#1:  How does a company/organization convert from doing compliance management to doing true risk management?  I think it’s the difference between being good and being great.  There are a couple of non-IT models that we can look at:  Emergency Room care transitioning into long-term care being a good one.

#2:  Compare and contrast the metrics that are collected as part of the annual FISMA reports with the major initiatives that we have on the table.  They don’t add up.

OK, I think it’s time to go fish this weekend, I’m having dreams about LoB initiatives.  Mini-me says I need to do something non-IT/security/$foo for the 8 hours of the day that I’m NOT working.

• Core Belief #4 — Compliance is a Dead-End
• Now ISC2 Blogs have an Opinion on FISMA
• Core Belief #2 — Risk Management Uber Alles
• Comments on the Annual OMB Security Report to Congress
• It’s a Problem of Scale!

I’ve been thinking about SP 800-53 lately because almost all of our efforts in the information assurance world lately are revolving around a catalog of controls concept.

Advantages that you get with a catalog of controls:

• Standardization (Important when you’re dealing with auditors)
• A minimum level of due dilligence “across the board”
• Each control can have an objective/intent, implementation guidelines, and test cases to validate effectiveness
• Easy to score (my cynical readers can retort with “auditor checklist” any time now)
• Applicable to a workforce with varying degrees of training and ability (ie, you don’t all have to have PHDs in IA)

And the dark underbelly of a catalog of controls:

• People just do the bare minimum because that’s all they get credit for
• Controls still need to be tailored by highly-educated people
• Enforces a “one size fits all” mentality which doesn’t work in the real world
• Your security is not streamlined because you’re doing extra where you don’t need it and not enough where you do need it

If you had to recreate your own catalog of controls for internal and external use, how would you go about it?  Well, this is the approach that NIST used to make 800-53:

• Collect all the control requirements from the various applicable laws (FISMA, Privacy Act, etc)
• Collect all the control requirements from other applicable standards, policies, and procedures (PPD-63, OMB Memoranda)
• Collect best practices from vendors and experienced security managers
• Consider the control requirements from comparable control catalogs (27001, PCI, A-123, etc)
• Lump all the requirements together and take the high-water mark
• Add some housekeeping controls that have been implied to bridge the current-state with the desired-state (document your security controls, perform a formal risk assessment, etc)

So far, this all makes sense and is exactly how most of us would do it, right?  NIST even did us a HUGE favor and gave us a traceability matrix in the back of the book to show us where each control requirement came from.

Except for one thing:  this is a compliance-based model, and I’ve just described how to build your own compliance framework.  No, that wasn’t my intent to prove, I realized it as I recreated the process.

We live in a risk management world where what I really need to provide effective and adequate security is a control framework based on threat, risk, and countermeasure.  A catalog of controls does the first 2 for me, and what I end up with as the security practitioner downstream is just the list of countermeasures detatched from what we’re really trying to accomplish–the intent.

So there are 2 approaches that NIST took to minimize some of the negatives of the catalog of controls approach.  The first one is that they allow you to catagorize your system (FIPS-199) and pick a level of controls.  It’s not perfect by any means, but it does that first part of tailoring the controls into large, xtra-large, and jumbonormous-sized buckets so you can choose your own level of involvement.  Sadly, though, most often this process involves the managerial equivalent of throwing darts at a dartboard with H, M, and L written on it.  Yes, it’s easy, but the best thing you can do for security in the government is to pick the right size of security helping that you’re going to eat.

The second thing that NIST gives you is the ability to tailor your controls.  If you’re not doing business impact assessments for where you undershoot and overshoot the untailored 800-53 controls, you’re doing yourself a great injustice.

However, just like the compliance-driven model that it supports, a catalog of controls is only a 75% solution.  The geek in me cringes that we would be using a rock chisel for rocket surgery, but in effect that’s what we’ve done so far as an industry.  And yes, 75% is better than 0%, but it’s still 25% short of perfection.

Will our catalog of controls be around in 5 years?  I don’t know.  There might be other ways to do what we want to do, and I’m sure a couple bright and not-so-bright people would step forward with their opinions if you asked them.  I for one would like to see 2 control catalogs:  one based on the minimum level of compliance where you do not have an option to deviate (and kept very small), and a second catalog that breaks down into threat-risk-countermeasure tuples so that I can exclude controls based on the fact that the threat and subsequent risk does not exist.

After all, that’s the point of tailoring security controls:  to answer the age-old question “How much is enough?”

• Blow-By-Blow Commentary
• An Open Letter to NIST About SP 800-30
• Opportunity Costs and the 20 Critical Security Controls
• What the Government Looks for in a Product
• Special Publication 800-53 Revision 3 Workshop

I’m mulling over some ideas this week.  It’s probably the death-by-CBT that being a new hire has become over the past 5 years.

I work with a ton of accountants in my new job.  Obviously, they’re CPAs and Uber-CPAs, and for the most part, they’re proud of the valuable service that accountants bring to their community and to the US economy as a whole.  $Diety bless them, there is no way I have the patience to do what they do on a daily basis, and from what I gather, they feel the same way about what I do.  However, while learning the history of the accounting profession, I can’t help but notice a couple of things:

• CPAs have some strange ideas and a rich history, cross-training has some merit.
• Accountants are obsessed with compliance.  More on this later.
• Attestation that a company has not cooked the books and is headed into a downward Enron/Worldcom/Hindenburg-esque firey crash is a good thing.
• Accountants highly value attestation.
• Accountants are typically weak on planning and project management (yes, making a generalization here).
• Accountants understand risk, but only qualitative dollar risks that can be measured via actuarial means.
• Accountants perform unnatural acts with spreadsheets.
• I have to be very careful when I mention the word “controls” because somewhere in there an interpreter is needed.

And then somewhere around day 3 of CBT-Hell, it dawned on me:  we’re taking the models for accounting and applying them en-mass to information security management.  Explains quite a bit of things, doesn’t it?

Stop and think about the Federal government.  Who is really in charge of security?  Not NIST, they just write standards.  The correct answer is the Office of Management and Budget (OMB) and the Goverment Accountability Office (GAO).  In other words, the accountants and the auditors.  It’s one of those things that make you go “hmmmm”.

Now, some of this is a necessary evil.  Any good CISO will tell you that whoever controls the money controls the security, just ask a security manager who has had their budget taken away.  As a profession, we’re tied to the economics of security just as tightly as the accountants are tied to the security of IT systems to maintain integrity of accounting systems.  It’s scary when you think about it, although I don’t know if it’s scarier for them or for us. =)

There’s an obvious reason why we adopted the accounting models for security:  expediency.  In the typical CIO’s option of build-buy-outsource, we outsourced the creation and maintenance of our governance model to the accountants.  And just like outsourcing to a managed service provider who has in turn offshored some of their operations, we might not be getting what we planned at the very beginning.

But now we’re getting to the limitations of using that model:

• For the most part, we are an industry driven by vulnerabilities and risk management.
• Accounting is driven by law and oversight boards.
• What laws we have are very broad because the laws cannot keep pace with the technology.
• Information security is not reported to oversight agencies/boards/whatever to the same level of granularity as is financial information.  Imagine reporting your WSUS stats on your SEC filing.
• Even the accountants are starting to agree on a more risk-based model than a compliance model.  The latest guidance from the SEC on SoX 404 called AS-5 is a step in this direction.
• IT has a higher level of acceptable risk on both an organizational and personal level than accounting.
• The accounting model is focused on audit and oversight.  Typically this is at the end of development and/or annually.
• True success in information security management needs a full-SDLC approach.

So this is what I’m mulling over:  we maybe have a need for some better tailoring of what we’re doing.  What I really want is a large-scale method for security management that cuts out the parts of the accounting model that don’t work.

Not that I have an answer today, but it’s something I’m using my spare brain cycles to figure out.  Who knows, maybe I’ll come full-circle and reinvent the current state. =)

• In Search of a Better Catalog of Controls
• Workin’ for the ‘Counters: an Analysis of my Love-Hate Relationship with the CPAs
• Ack! With the Mandates!
• An Open Letter to NIST About SP 800-30
• It’s a Problem of Scale!

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

Ok, we all know how to patrol in the woods looking for things to shoot. We’ve been doing that since the beginning of time, and really it’s ingrained nature for most people. Some people say that it’s why we developed bigger and better brains–so we could hunt more effectively.

Then the world changed. We went from being hunter-gatherers to living on farms to living in cities. And as you might expect, the amount of warfare conducted in cities has grown comparatively, from the Meistertrunk of Rothenburg in the middle ages to the burning of Atlanta during the Civil War to the Rattenkreig of Stalingrad to the mean streets of Baghdad. Truth of the matter is, nowadays cities are where the critical infrastructure is, and that’s where a modern army needs to learn how to combat and win against their enemies. In the US Army, we have a word for it: Military Operations on Urbanized Terrain, or MOUT (the department of modernization just told me that it’s now “OU” or “Urban Operations”).

One lesson from MOUT that there are many ways to kill people. Yes, you can shoot them (the good ol’ standby), but there are new ways: “anti-handling devices” (aka, booby traps and IEDs), channelization of traffic into better kill zones, better line-of-sight for snipers, ability to hide ambushes, short engagement ranges for anti-armor teams, etc.

In MOUT, you have to live with the fact that heavily barricading a building means it’s harder for the bad guys to get in and it’s also harder for you to get out if the building is on fire. It’s something to think about in the IT world where protecting against one type of attack means that you are susceptible to another attack: think dual-homing all your servers on a backup network to help with availability but meaning that if one server gets hacked, it’s a shorter path to the other servers.

Just like MOUT, there are many ways to “die” in the IT security world. Let’s see, this year it’s XSS, Ajax attacks, and USB drives. 5 years ago it was worms, virii and unpatched systems. Next year it will most likely be application vulnerabilities.

Now welcome risk management into that picture. Risk management means being able to triage the “bazillion ways to die” and come up with a list of the ones you need to fix now, the ones you need to fix over the next year, and the ones it doesn’t make sense to fix. In MOUT, it’s a question of “Do I spend the time putting in more wire and mines,” or “Do I need to work on blowing holes between rooms so I can move people and weapons internally?” or even “Which parts of the city do I rig with explosives and give away to the bad guys because they have no strategic value to me?”

• Core Belief #2 — Risk Management Uber Alles
• Puzzles v/s Mysteries
• When Acceptable Risk is Not Acceptable
• “Machines Don’t Cause Risk, People Do!”
• Risk Management and Crazy People, a Script Using Stock Characters

Those cheeky devils over at NIST have an interesting read out in draft form:  NISTIR 7328 (.pdf caveat).  It’s a draft Interagency Report, but in reality it’s a how-to on being assessed and being the assessor.

I’ve given it a glance and it’s all the things that successful Security Test and Evaluation teams have been doing all along.  I know there’s some kind of “take-away” (my MBA phrase for today) that works out in the private sector.

• Help the Government, Become Literate
• How I Do the “FISMA Thang”
• Micro Digital Signatures Howto
• On SP 800-39
• SP 800-53A Now Finally Final