This was announced a couple of weeks ago (at least 9000 days ago in Internet time) so now it’s “old news” but have a look at Metricon 5.0 which will be in DC on the 10th of August.

It’s a small group (attendance is capped at 60), but if you’re managing security in Government, I want to encourage you to do 2 things:

• Submit a paper!
• Attend and learn.

I’ll be there doing a bit of hero-worship of my own with the Security Metrics folks.

• Metricon 5 Wrapup
• NIST Framework for FISMA Dates Announced
• C&A Seminar in August, Instructor-to-Coolness Ratio Goes Up!
• Certification and Accreditation Seminar, March 30th and 31st
• “Machines Don’t Cause Risk, People Do!”

Do you really need an explanation?  OK, I’ll give you one hint on the meme.

• Beware the Audit Hammer
• LOLCATS: Defending our Cyber-Turf
• The InfoSec D-List and IKANHAZFIZMA
• A Stable InfoSec Program?
• Exhaustive Security Testing is Bad For You

Go have a look at what Mike Murray and Lee Kushner have to say on what I endearingly refer to as “Stupid Contractor Tricks”.

Now I know Mike and Lee are supposed to be tactful, and they do a really good job at that.  This post is not about tact.  =)

You need to step back a bit and understand the business model for contractors.  Because their margins are low and fixed, it means a couple of things:

• You have large-volume contracts where you still have the same margin but more total net profit.
• You can’t keep a bench of people off-project because it rapidly eats into your margin.  For some companies, this means that anybody off-project for 2 weeks or more gets laid off.
• The name of the game is to win the proposal, get the work, then figure out how to staff it from rolling people onto the new project and bringing in new hires.  This is vastly inefficient.
• New hires can also be to backfill on contracts where you’ve moved key people off to work something new.

So on to my advice in this particular scenario that Mike and Lee discuss:  Run away as fast as you can from this offer.

There are a couple of other things that I’m thinking about here:

• A recruiter or HR person from Company A left for Company B and took their Rolodex of candidates.  Hence the surprise offer.  Either that, or Company A is now a sub for Company B or Company A is just the “staffing firm” getting paid $500/signed offer letter and doing business in bulk.
• The Government usually requires “Commitment Letters” from the people that have resumes submitted on a proposal.  The reason for this is that the Government realizes what kind of jackassery goes on involving staffing, and requiring a signed letter gives the candidate an opportunity to decide up front.
• If you sign an offer like this, you’re letting down the rest of the InfoSec community that are contractors by letting the recruiters commoditize what we do.  It’s bad for us and it’s bad for the Government.

Other stupid contractor tricks:

• Signing an exclusivity letter that they are the only people who can submit your resume on a contract.
• Making you sign an offer letter then letting the offer linger for 6+ months while you’re unemployed and could really use the ability to move on to a different job.
• Shopping resumes for people you have never met and/or do not intend to make an offer letter to.
• Changing the job completely after you have accepted the offer.
• …and you probably have more that you can put into the comments section below.  =)

• The CyberArmy You Have…
• When the News Breaks, We Fix it…
• NIST’S FISMA Pase II–Who Certifies Those who Certify the Certifiers?
• Engagement Economics and Security Assessments
• Analyzing Fortify’s Plan to “Fix” the Government’s Security Problem

Just a quick post to shill for Privacy Camp DC 2010 which will be taking place on the 17th of April in downtown DC.  I went last year and it was much fun.  The conversation ranged from recommendations for a rewrite of

The basic rundown of Privacy Camp is that it’s run like a Barcamp where the attendees are also the organizers and presenters.  If you’re tired of going to death-by-powerpoint, this is the place for you.  And it’s not just for government-types, there is a wide representation from non-profits and regular old commercial companies.

Anyway, what are you waiting for?  Go sign up now.

• Privacy Camp DC on June 20th
• In Response to “Cyber Security Coming to a Boil” Comments….
• Blow-By-Blow on S.773–The Cybersecurity Act of 2009–Part 3
• Blow-By-Blow on S.773–The Cybersecurity Act of 2009–Part 2
• Metricon 5 Wrapup

Well, several funny things happened, they happen every week.  But specifically I’m talking about the hearing in the House Committee on Homeland Security on FISMA reform–Federal Information Security: Current Challenges and Future Policy Considerations.  If you’re in information security and Government, you need to go read through the prepared statements and even watch the hearing.

Also referenced is HR.4900 which was introduced by Representative Watson as a modification to FISMA.  I also recommend that you have a look at it.

Now for my comments and rebuttals to the testimony:

• On the cost per sheet of FISMA compliance paper: If you buy into the State Department’s cost of $1700 per sheet, you’re absolutely daft.  The cost of a security program divided by the total number of sheets of paper is probably right.  In fact, if you do the security bits right, your cost per sheet will go up considerably because you’re doing much more security work while the volume of paperwork is reduced.
• Allocating budget for red teams: Do we really need penetration testing to prove that we have problems?  In Mike Smith’s world, we’re just not there yet, and proving that we’re not there is just an excuse to throw the InfoSec practitioners under the bus when they’re not the people who created the situation in the first place.
• Gus Guissanie: This guy is awesome and knows his stuff.  No, really, the guy is sharp.
• State Department Scanning: Hey, it almost seems like NIST has this in 800-53.  Oh wait, they do, only it’s given the same precedence as everything else.  More on this later.
• Technical Continuous Monitoring Tools: Does anybody else think that using products of FISMA (SCAP, CVE, CVSS) as evidence that FISMA is failing is a bit like dividing by zero?  We really have to be careful of this or we’ll destroy the universe.
• Number of Detected Attacks and Incidents as a Metric: Um, this always gets a “WTF?” from me.  Is the number increasing because we’re monitoring better or is it because we’re counting a whole bunch of small events as an attack (ie, IDS flagged on something), or is it because the amount of attacks are really increasing?  I asked this almost 2 years ago and nobody has answered it yet.
• The Limitations of GAO: GAO are just auditors.  Really, they depend on the agencies to not misrepresent facts and to give them an understanding of how their environment works.  Auditing and independent assessment is not the answer here because it’s not a fraud problem, it’s a resources and workforce development problem.
• OMB Metrics: I hardly ever talk bad about OMB, but their metrics suck.  Can you guys give me a call and I’ll give you some pointers?  Or rather, check out what I’ve already said about federated patch and vulnerability management then give me a call.

So now for Rybolov’s plan to fix FISMA:

1. You have to start with workforce management. This has been addressed numerous times and has a couple of different manifestations: DoDI 8570.10, contract clauses for levels of experience, role-based training, etc.  Until you have an adequate supply of clueful people to match the demand, you will continue to get subpar performance.
2. More testing will not help, it’s about execution. In the current culture, we believe that the more testing we do, the more likely the people being tested will be able to execute.  This is highly wrong and I’ve commented on it before.  I think that if it was really a fact of people being lazy or fraudulent then we would have fixed it by now.  My theory is that the problem is that we have too many wonks who know the law but not the tech and not enough techs that know the law.  In order to do the job, you need both.  This is also where I deviate from the SANS/20 Critical Security Controls approach and the IGs that love it.
3. Fix Plans of Actions and Milestones. These are supposed to be long-term/strategic problems, not the short-term/tactical application of patches–the tactical stuff should be automated.  The reasoning is that you use these plans for budget requests for the following years.
4. Fix the budget train. Right now the people with the budget (programs) are not the people running the IT and the security of it (CIO/CISO).  I don’t know if the answer here is a larger dedicated budget for CISO’s staff or a larger “CISO Tax” on all program budgets.  I could really policy-geek out on you here, just take my word for it that the people with the money are not the people protecting information and until you account for that, you will always have a problem.

Sights Around Capital Hill: Twice Sold Tales photo by brewbooks. Somehow seems fitting, I’ll let you figure out if there’s a connection. =)

• “Machines Don’t Cause Risk, People Do!”
• GAO’s 5 Steps to “Fix” FISMA
• How to Not Let FISMA Become a Paperwork Exercise
• In Other News, I’m Saying “Nyet” on S.3474
• The 10 CAG-egorically Wrong Ways to Introduce Standards

So by now NIST SP 800-37 R1 has made the rounds.  I want to take a couple of minutes to go over my theory on this update.

Summary of changes:

• Certification is gone.  Accreditation has now changed to “Authorization”.  This is interesting to me because it removes certification which I’ve always equated with compliance.
• There is more focus on continuous monitoring.
• NIST has made it more obvious that the process in 800-37 is the security aspects of a SDLC.
• There is much more more emphasis on enterprise-level controls.

So those of you out there who have been succeeding with the NIST Risk Management Framework  have been doing this all along, and it’s actually why you’ve succeeded.  For the rest of you, if you have to change your existing process, you’ve been doing it wrong.

Now for what’s missing and where you need to fill in the gaps:

• Prioritization of controls.  If everything is important, nothing is important.  You have to be able to determine which controls you need to succeed 100% of the time and which controls only need 75% reliability.  Hey, I even give credit to the SANS 20 Critical Security Controls, as flawed as they are, for this.
• Delineation of controls into shared/common, hybrid, and system-specific.  This is by design, it’s up to the departments and agencies to figure this out.  If you do this correctly, you save a ton of time and effort.  I remember the day my certifier told me that we didn’t recognize shared controls and that it was on me to provide evidence of controls that were provided at the enterprise–it still baffles me how you really expect one person on a project team to have the resources of the entire IT security staff.
• Continuous monitoring is up to you.  Along with prioritization, you have to determine which controls you need to monitor and a plan on how to do that.  Protip: these are usually technical controls that you can automate and should do so because it’s the only way to get the job done.
• Tailor, tailor, tailor.  It is not enough to use generic 800-53 controls.  It definitely is sub-par to use untailored 800-53A test procedures as your test plan.  These all depend on the implementation and need to be tailored to fit.

And finally, a shout-out to Dan Philpott at FISMAPedia.org.  Dan literally consumes new legislation, regulation, guidelines, and standards as they come out and annotates them with a wealth of analysis.

800-37 WordCloud by ME! Thanks to wordle.net for the tool to make it.

• SP 800-53A Now Finally Final
• NIST Cloud Conference Recap
• Special Publication 800-53 Revision 3 Workshop
• How to Not Let FISMA Become a Paperwork Exercise
• Some Comments on SP 800-39