Traffic Analysis and Rebuilding C&A

Posted August 17th, 2010 by rybolov

For some reason, “Rebuilding C&A” has been a perennial traffic magnet for me for a year or so now.  Seeing how that particular post was written in 2007, I find this an interesting stat.  Maybe I hit all the SEO terms right.  Or maybe the zeitgeist of the Information Assurance community is how to do it right.  Anyway, if you’re in Government and information security, it might be worthwhile to check out this old nugget of wisdom from yesteryear.



Similar Posts:

Posted in FISMA, NIST, The Guerilla CISO | No Comments »
Tags:

NIST Cloud Conference Recap

Posted June 2nd, 2010 by rybolov

A couple of weeks ago I went to the NIST Cloud Conference for the afternoon security sessions.  You can go grab the slides off the conference site.  Good stuff all around.

Come to think of it, I haven’t blogged about FedRAMP, maybe it’s time to.

FedRAMP is a way to do security authorization (formerly certification and accreditation, get with the times, man) on a cloud then let tenant projects use that authorization.  Hmmm, sounds like…. a General Support System with common controls and Major Applications that inherit those controls.  This isn’t really anything new, just the “bread and butter” security management concepts scoped to a cloud.  Basically what will happen with FedRAMP is that they have 3 standards: DoD, DHS, and GSA (most stringent first) and cloud providers get authorized against that standard.  Then when a project wants to build on that cloud, they can use that authorization for their own authorization package.

All things considered, FedRAMP is an awesome idea.  Now if we can get the holdout agencies to actually acknowledge their internal common controls, I’ll be happy–the background story being that some number of months ago I was told by my certifier that “we don’t recognize common controls so even though you’re just a simple web application you have to justify every control even if it’s provided to you as infrastructure.”  No, still not bitter at all here, but I digress….

And then there are the pieces that I haven’t seen worked out yet:

  • Mechanism of Sharing: As a service provider, it’s hard enough to keep one agency happy.  Add in 5 of them and it gets nearly impossible.  This hasn’t really been figured out, but in Rybolov’s small, myopic world, a panel of agencies owning an authorization for a cloud provider means that the cloud never gets authorized.  The way this has been “happening in the wild” is that one agency owns the authorization and all the other agencies get the authorization package from that agency.
  • Using FedRAMP is Optional: An agency or project can require their own risk assessment and authorization even though a FedRAMP one is available.  This means that if the agency’s auditors don’t understand the process or the “risk monkeys” (phrase courtesy of My Favorite Govie) decree it, you lose any kind of cost savings and time savings that you would get by participating in FEDRAMP.
  • Cloud Providers Rule the Roost: Let’s face it, as much as the Government wants to pretend that the cloud providers are satisfying the Government’s security requirements, we all know that due to the nature of catalogs of controls and solution engineering, the vendor here has the advantage.  Nothing new, it’s been happening that way with outsourcing, only now it’s immediately evident.  Instead of trying to play ostrich and stick our heads in the sand, why don’t we look at the incentives for the cloud providers and see what makes sense for their role in all this.
  • Inspector General Involvement: I don’t see this happening, and to be honest, this scares the hell out of me.  Let me just invoke Rybolov’s Law: “My solution is only as good as my auditor’s ability to understand it.”  IE, if the IGs and other auditors don’t understand FedRAMP, you don’t really have a viable solution.

The Big Ramp photo by George E. Norkus.  FedRAMP has much opportunity for cool photos.



Similar Posts:

Posted in FISMA, NIST, Outsourcing, Risk Management, What Doesn't Work, What Works | 2 Comments »
Tags:

“Machines Don’t Cause Risk, People Do!”

Posted May 26th, 2010 by Vlad the Impaler

A few weeks back I read an article on an apparent shift in emphasis in government security… OMB outlines shift on FISMA” take a moment to give it a read. I’ll wait….

That was followed by NASA’s “bold move” to change the way they manage risk

Once again the over-emphasis and outright demagoguery on “compliance,” “FISMA reports,” “paper exercises,” and similar concepts that occupy our security geek thoughts have not given way to enlightenment. (At least “compliancy” wasn’t mentioned…) I was saddened by a return to the “FISMA BAD” school of thought so often espoused by the luminaries at SANS. Now NASA has leapt from the heights… At the risk of bashing Alan Paller yet again, I am often turned off by the approach of “being able to know the status of every machine at every minute, ” – as if machines by themselves cause bad security… It’s way too tactical (incorrect IMHO) and too easy to make that claim.

Hence the title of this rant – Machines don’t cause risk, people do!

The “people” I’m talking about are everyone from your agency director, down to the lowliest sysadmin… The problem? They may not be properly educated or lack the necessary skills for their position – another (excellent) point brought forth in the first article. Most importantly, even the most seasoned security veteran operating without a strategic vision within a comprehensive security program (trained people, budget, organizational will, technology and procedures) based upon the FISMA framework will be doomed to failure. Likewise, having all the “toys” in the world means nothing without a skilled labor force to operate them and analyze their output. (“He who dies with the most toys is still dead.”) Organizations and agency heads that do not develop and support a comprehensive security program that incorporates the NIST Risk Management Framework as well as the other facets listed above will FAIL. This is nothing new or revolutionary, except I don’t think we’ve really *done* FISMA yet. As I and others have said many times, it’s not about the paper, or the cost per page – it’s about the repeatable processes — and knowledgeable people — behind what the paper describes.

I also note the somewhat disingenuous mention of the risk management program at the State Department in the second article… As if that were all State was doing! What needs to be noted here is that State has approached security in the proper way, IMHO — from a Strategic, or Enterprise level. They have not thrown out the figurative baby with the bath water by dumping everything else in their security program in favor of the risk scoring system or some other bright, shiny object. I know first-hand from having worked with many elements in the diplomatic security hierarchy at State – these folks get it. They didn’t get to the current level of goodness in the program by decrying (dare I say whining about?) “paper.” They made the organizational commitment to providing contract vehicles for system owners to use to develop their security plans and document risk in Plans of Action and Milestones (POA&Ms). Then they provided the money to get it done. Is the State program a total “paragon of virtue?” Probably not, but the bottom line is that it’s an effective program.

Mammoth Strategy, Same as Last Year

Mammoth Strategy, Same as Last Year image by HikingArtist.com.

Desiring to know everything about everything may seem to some to be a worthy goal, but may be beyond many organization’s budgets. *Everything* is a point in time snapshot, no matter how many snapshots you take or how frequently you take them. Continuous, repeatable security processes followed by knowledgeable, responsible practitioners are what government needs. But you cannot develop these processes without starting from a larger, enterprise view. Successful organizations follow this–dare I say it–axiom whether discussing security governance, or system administration.

Government agencies need to concentrate on developing agency-wide security strategies that encompass, but do not concentrate on solely, what patch is on what machine, and what firewall has which policy. Likewise, system POA&Ms need to concentrate on higher-level strategic issues that affect agencies — things like changes to identity management schemes that will make working from home more practical and less risky for a larger percentage of the workforce. Or perhaps a dashboard system that provides the status of system authorization for the agency at-a-glance. “Burying your head in a foxhole” —becoming too tactical — is akin to burying it in the sand, or like getting lost in a bunch of trees that look like a forest. When organizations behave this way, everything becomes a threat, therefore they spray their resource firepower on the “threat of the day, or hour.”

An organization shouldn’t worry about patching servers if its perimeter security is non-existent. Developing the larger picture, while letting some bullets strike you, may allow you recognize threats, prioritize them, potentially allowing you to expend minimal resources to solve the largest problem. This approach is the one my organization is following today. It’s a crawl first, then walk, then run approach. It’s enabled management to identify, segregate, and protect critical information and resources while giving decision-makers solid information to make informed, risk-based decisions. We’ll get to the patches, but not until we’ve learned to crawl. Strangely, we don’t spend a lot of time or other organizational resources on “paper drills” — we’re actively performing security tasks, strategic and tactical that follow documented procedures, plans and workflows! Oh yes, there is the issue of scale. Sorry, I think over 250 sites in every country around the world, with over 62 different government customers tops most enterprises, government or otherwise, but then this isn’t about me or my organization’s accomplishments.

In my view, professional security education means providing at least two formal paths for security professionals – the one that SANS instantiates is excellent for administrators – i.e., folks operating on the tactical level. I believe we have these types of security practitioners in numbers. We currently lack sufficient seasoned professionals – inside government – who can approach security strategically, engaging agency management with plans that act both “globally” and “locally.” Folks like these exist in government but they are few. Many live in industry or the contractor space. Not even our intelligence community has a career path for security professionals! Government as a whole lacks a means to build competence in the security discipline. Somehow government agencies need to identify security up-and-comers within government and nurture them. What I’m calling for here is a government-sponsored internal mentorship program – having recognized winners in the security game mentor peers and subordinates.

Until we security practitioners can separate the hype from the facts, and can articulate these facts in terms management can understand and support, we will never get beyond the charlatans, headline grabbers and other “self-licking ice cream cones.” Some might even look upon this new, “bold initiative” by NASA as quitting at a game that’s seen by them as “too hard.” I doubt seriously that they tried to approach the problem using a non-academic, non-research approach. It needed to be said. Perhaps if the organization taking the “bold steps” were one that had succeeded at implementing the NIST guidance, there might be more followers, in greater numbers.

Perhaps it’s too hard because folks are merely staring at their organization’s navel and not looking at the larger picture?

Lastly, security needs to be approached strategically as well as tactically. As Sun Tzu said, “Tactics without strategy is the noise before defeat.”



Similar Posts:

Posted in FISMA, NIST, Public Policy, Rants, Risk Management, What Doesn't Work, What Works | 14 Comments »
Tags:

Observations on SP 800-37R1

Posted March 29th, 2010 by rybolov

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.

Wordle of NIST SP 800-37R1

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



Similar Posts:

Posted in FISMA, NIST, What Doesn't Work, What Works | 3 Comments »
Tags:

Old Saint NIST: Ho Ho Hold on, what’s this?

Posted December 13th, 2009 by DanPhilpott

Every once in a while an opportunity presents itself to affect some real change in federal information security practice.  Now is such a time.  A slew of new NIST documents are being released between now and April.  These are the core NIST documents that describe how to satisfy FISMA.  They include NIST SPs 800-30 Revision 1, 800-39, 800-37 Revision 1 and 800-53A Revision 1. That’s where you come in.

The documents define what federal government practice will look like in the coming years.  If they are flawed then the practice will be flawed.  To prevent stupidity from leaking in when nobody is looking NIST releases the documents as drafts so everyone gets a chance to eyeball them.  First you eyeball, then you comment.  They look at the comments and they fix the flaws.  Fix the flaws now and you don’t live with them later.

The most important document in draft right now is the NIST Special Publication 800-37 Revision 1.  This document describes the central processes involved in the authorization of information systems that support the federal government.  Notice I didn’t say Certification and Accreditation?  That’s because C&A is deader than a sheep at a wolf convention. Want to know what replaces it?  Pick up a copy of NIST SP 800-37r1 FPD, give it a read and send in your comments.

Better yet, consider joining a formal document review process.  I’m leading a team of hale and hearty volunteers at OWASP in a NIST SP 800-37r1 FPD review and we’d love to have you come join the fun.   We’re on a tight schedule so now is the time to act.

Time is short, the comment period for NIST SP 800-37 Revision 1 FPD ends on December 31st, 2009.



Similar Posts:

Posted in NIST | 3 Comments »
Tags:

NIST Framework for FISMA Dates Announced

Posted April 10th, 2009 by rybolov

Some of my friends (and maybe myself) will be teaching the NIST Framework for FISMA in May and June with Potomac Forum.   This really is an awesome program.  Some highlights:

  • Attendance is limited to Government employees only so that you can talk openly with your peers.
  • Be part of a cohort that trains together over the course of a month.
  • The course is 5 Fridays so that you can learn something then take it back to work the next week.
  • We have a Government speaker ever week, from the NIST FISMA guys to agency CISOs and CIOs.
  • No pitching, no marketing, no product placement (OK, maybe we’ll go through DoJ’s CSAM but only as an example of what kinds of tools are out there) , no BS.

See you all there!



Similar Posts:

Posted in NIST, Speaking | 1 Comment »
Tags:

« Previous Entries


Visitor Geolocationing Widget: