Yet More Security Controls You Won’t See in SP 800-53

Posted September 12th, 2007 by

MP-52 Self-Destructing RFID Implants
Control:
The organization equips all employee-integrated storage media with self-igniting RFID devices so that they can be tracked throughout any government facility and destroyed upon command.

Supplemental Guidance:
All CISOs know that the information inside their employees’ heads is the real culprit.  When they get a new job, they take that information–all learned on the taxpayers’ dime–with them.  This is a much bigger security risk than the data on a USB drive could ever be.  Instead of denying the obvious truth, why don’t we implement security controls to minimize the impact of out-of-control employees?

Control Enhancements:
(1) The organization destroys the information inside an employee’s head when the employee leaves the organization, much like hard drives need to be degaussed before they are sent for maintenance.
Low: MP-52 Moderate: MP-52(1) High: MP-52(1)



Similar Posts:

Posted in BSOFH, FISMA, NIST, The Guerilla CISO | 3 Comments »

One Catalog to Rule Them All

Posted September 11th, 2007 by

Interesting article at Federal Computer Week that hints at a unified catalog of controls (read: SP 800-53, DoDI 8500.2, and DCID 6/3 combined into a huge one) that applies to all federal IT systems.  It’s coming, the big question is “how many years until it’s done?”

I know you guys know me well enough by now to reason that I’m going to tell you why we care.  And you’re right.

Well, one of the reasons where FISMA is failing (at least according to some people, my opinion differs) is that we have a shortage of people who have the necessary training and skills.  What a unified catalog of controls means is that we now have something that is standardized across the board so that I can take an IA practitioner from the DoD side, put them into a civilian agency, and have a reasonable expectation that they will succeed there.  In other words, I’ve decreased the switch costs for personnel transfers.  I’ve also made it easier for agencies to share data with each other (conspiracy buffs here can think things about Census data feeding the Total Information Awareness program and corroborated against your classified file) and to support each other as vendors under Lines of Business, which the government needs desperately.

The one downside is that I can see is that if you have a catalog of controls that runs the entire range from low-criticality to TS-plus, the tendency will be for every ISSO out there to build more controls than they actually need.  But we have that today, only not as severe.



Similar Posts:

Posted in FISMA, NIST | 3 Comments »

What the Government Looks for in a Product

Posted August 13th, 2007 by

I’ve been sitting in some vendor presentations lately–I think they invite me along so I can be the resident curmudgeon–and I’m starting to get a good feel for what both the government and myself want in a product.

I want to know how a tool fits into my IA framework. That framework for me is NIST SP 800-53. One side effect of 800-53 is that I can’t justify a product “just because”–I have to state how this tool or service will help me attain “compliance” with the minimum baseline of security controls. It’s not enough anymore to just say “hey, our product helps you with SP 800-53 controls, have some magic FISMA Fairy Dust“.

Advice for vendors: take the day of effort to provide a traceability matrix for me. What I have is a Plan of Actions and Milestones (POA&M) that requires me to implement the following controls:

  • AC-11 Session Lock
  • AC-12 Session Termination

Now what I want is for your product to say the following:

  • AC-11: Our product locks out users after 15 minutes of activity on their Frobulator workstation.
  • AC-12: Our product terminates users after 25 minutes of activity on their Frobulator workstation.

If your product doesn’t do a control, don’t mention it. But by all means get somebody who routinely works with the catalog of controls to determine if you meet the control objective: there’s nothing I hate more than trying to understand how somebody stretched their interpretation of control objectives that I now have to turn around and rationalize to an auditor. It’s OK if your product doesn’t do everything as long as it does the right things.

Now the reason I bring all this up is that I, too, am a vendor–a services/outsourcing vendor. I’m taking the time this week to do my own traceability matrix that says something like this:

  • For the Basic Hosting Service, these are the controls that you get (mostly Physical and Environmental Protection (PE) and Media Protection (MP) )
  • For the IDS Monitoring and Management Service, these are the controls that you get (mostly Audit (AU) controls with a smattering of Incident Response (IR) controls)
  • For the Network Monitoring and Management Services, these are the controls that you get (hardly any except for availability monitoring)
  • This is what we provide for support when you do a risk assessment or certification and accreditation
  • Some controls are Inherent Government Functions (IGF) and cannot be outsourced to us such as FIPS-199 categorization and risk acceptance

The whole idea is to delineate the responsibilities for pre-sales work so that when somebody contracts with us, they know the Government’s responsibilities, our Project Management Office’s (PMO’s) responsibilities, and my operations group’s responsibilities. It’s going back to the nature of outsourcing and the fact that transparency is key.



Similar Posts:

Posted in FISMA, NIST, Outsourcing, The Guerilla CISO | 3 Comments »

Another Day, Another Vendor

Posted July 10th, 2007 by

So I got “roped into” another vendor presentation yesterday. I should have done a little bit of research beforehand because then I would know that the product they pitch is Yet Another Technical Policy Compliance Tool (YATPCT)(tm) and I could have safely skipped it.

From my standpoint, this market is getting crowded, but the nature of the beast is that it’s low sales volume but high cost. Ie, it’s a market that will forever be make-or-break. Not a good place to be as a vendor, and I have a feeling that the majority of them will die a horrendous death but to the business leadership one sale looks pretty good.

One thing that I did see is that the typical YATPCT has now evolved. Most of them have incorporated workflow now so they’re aiming for “security team in a box”.

Now for people who know what they are doing, the people that I refer to as “clueful”, these tools are pretty good at keeping you on track. The problem is that there is a shortage of clueful people, so they’re buying tools to compensate for the lack of skill. The end result of this game is that you end up broke with no adequate security–not exactly what I would call “effective security”.

One of these days I’ll find a vendor who “gets it” and is worth my time to teach them how to do the last 5% of what they need to work for me. God knows I’ve taken hours to explain it to anyone that wanted to hear. This is what I want to see:

  • Grouping assets together
  • Determining a criticality for the group based on the Business Reference Model (SP 800-60)
  • Yes, a baseline of controls from 800-53 but the ability to add my own controls and do tailoring because I have to distill the control into an exact requirement that people can build to
  • The ability to extract a complete System Security Plan to hand to an auditor
  • An engine to build a test plan and record results
  • Workflow for Plan of Action and Milestones so I can get funding from Congress and actually get things fixed. Exhibit 300 format would be highly superb.

The problem is that a tool adds to the effort involved, not detracts from it–you still have to use the thing in addition to all the people-power. If you still need the people with the wetware to use the tool, what has the tool effectively saved you? Probably not much. In fact, I ask the basic question: what does automation really provide for something that is perpetually a one-off system? You only get efficiency when you optimize the parts of a process that are repeated–ask any programmer about it. Yet at the same time, if you have a set of systems that habitually have a large amount of shared controls between them, why aren’t they lumped together into the same system already?

In the meantime, all I see are SoX technical compliance solutions kluged into FISMA compliance solutions. We think differently here inside the beltway. I don’t assign dollar values to individual servers, and I don’t care about ALE calculations. To be bluntfully honest, I don’t really care about compliance, I care about risk management (both security risk and project risk), so at the end of this exercise, no matter what the scope of it is, I want to know what the residual risk is and if we should do one of the following:

  • Leave it as-is
  • Pump more money into it
  • Kill it or at least investigate feasible alternatives
  • Beat people about the head with the giant foam cluebat until they fix a small subset of problems
  • Fire the staff
  • Fire the evaluation staff
  • Go fishing (trick answer, I was going to do that anyway) =)


Similar Posts:

Posted in FISMA, NIST, Risk Management | 5 Comments »

Response to “What is Information Assurance – The Video”

Posted June 18th, 2007 by

Movie from George Mason professor Paul Strassman on Information Assurance which was digitized and shared forever thanks to Google Movies.

My response to the movie:

This presentation has many problems.

FISMA is not that large of a law.  You can get the text from the NIST website at the following url:
http://csrc.nist.gov/policies/FISMA-final.pdf (16 pages long)

FISMA does not require SP 800-53.  It charges NIST with creating standards for information security.  FIPS 200 dictates that an agency use 800-53 as their baseline security controls.  Once again, we’re confusing the law with the implementation.

The security plan is a vehicle to get people to agree on what the security controls should be, not a post-fact documentation on what security controls that exist.

DIACAP is not the first time that systems have had to be certified.  Prior to this, there was DITSCAP, NIACAP, FIPS 102, and SP 800-37.  I also wonder how we got from SP 800-53 to DIACAP since they are different flavors–civilian agencies v/s DoD.

In certification, you do not certify compliance.  You certify that the controls meet the needs of the business owners.  Those needs might be considerably more relaxed than you think.  For example:  completely air-gapped systems in a SCIF don’t need a sizeable chunk of the control in 800-53.  Compliance is costly because you don’t have the ability to not do something that doesn’t make sense.

The “Hamster Wheel of Pain” that is shown as the DIACAP process is detached from other SDLC activities, which is rapidly becoming one of my pet peeves.  If you do DIACAP divorced from the SDLC, you are creating liarware.

“The DIACAP activities, the certification of the system, is a very involved, complicated, time-consuming, laborious process that nobody has as yet completed.”  It’s so wrong I can’t even begin to explain.

The DAA is not responsible for DIACAP.  The DAA is only a key decision maker.

The DAA does not sign a statement saying that you are secure, they sign a statement saying that the level of risk to the system and to the mission is of an acceptable level.

The CIO does not usually go to the DAA.  The CIO is more likely to be *the* DAA than just about anybody else.

The second half of the movie is general security information, not really IA-specific.

If this is what they teach in the universities around the beltway, no wonder we have an IA constituency who don’t “get it“.



Similar Posts:

Posted in DISA, FISMA, NIST, What Doesn't Work | 3 Comments »

Speaking in July/August

Posted June 15th, 2007 by

My friends and I will be teaching the NIST Framework for FISMA with the Potomac Forum from July 13th to August 10 in 5 Friday segments.  This is a small (limited to 35) class and is restricted to government employees only because we go down into frightening detail. =)

I always love this series.  The students start out being quiet and expecting us to force-feed them powerpoint slides in the beginning, but by the end, they know the entire IA framework and are very vocal about defending their position on why a certain risk should be accepted or not.  I get all choked up inside to hear people talk about making a cost-benefit-risk decision and giving a system a conditional ATO.

As a side note, I wrote most of the exercises and tell everybody that the actual answer you gave isn’t as important as the logic you used to get there, but really what you should do is pick one answer and be ready to argue. =)



Similar Posts:

Posted in FISMA, NIST, Speaking | 4 Comments »

« Previous Entries Next Entries »


Visitor Geolocationing Widget: