William Jackson on FISMA: It Works, Maybe

June 30th, 2008 by rybolov

If you're new here and would like to see more of what I'm saying, you may want to subscribe to my RSS feed (I can even email my blog posts to you when I publish a new one) or have a look at my papers and presentations page for downloads of stuff that you can share or "borrow heavily from". You also might find my guidelines for posting comments interesting, especially if you're a government employee. If you want to see me blog about anything in particular, drop me a private email on how you think I'm completely full of myself, extend me an invitation to speak at your next security meeting/event, or just to ship a huge bag of money in my direction, you can do that through my contact page. Thanks for visiting and happy hacking!

Article from William Jackson in Government Computer News:  Security policies remain a burden to federal IT managers, but they are producing results.

First off, GCN, come into the modern Web 2.0 era by letting people comment on your articles or at least allow trackbacks.  Having said that, let’s look at some of Mr Jackson’s points:

  • NIST Special Publications: They’re good.  They’re free.  The only problem is that they’re burying us in them.  And oh yeah, SP 800-53A is finally final.
  • Security and Vendors/Contractors:  It’s much harder than you might think.  If there’s interest, I’ll put out some presentations on it in my “copious amounts of free time”.  In the meantime, check out what I’ve said so far about outsourcing.
  • Documentation and Paperwork:  Sadly, this is a fact of life for the Government.  The primary problem is the layers of oversight that the system owner and ISSO have.  When you are as heavily audited as the executive branch is, you tend to avoid risks and overdocument.  My personal theory is that the reason is insistence on compliance instead of risk management.
  • Revising FISMA:  I’ve said it time and time again, the law is good and doesn’t need to be changed, the execution is the part that needs work.

Posted in FISMA, NIST, Outsourcing, Risk Management | 3 Comments »

The Wee Bonny Has a Blog

June 27th, 2008 by rybolov

My friend, the Wee Bonny Graydon McKee, has his own company and a new blog.  Graydon is from Atlanta, helps us teach with the Potomac Forum, and just finished his Masters in Information Assurance.  Pretty good guy all around.  Check him out at Ascension Risk Management and fire up your RSS reader.

Posted in Odds-n-Sods | No Comments »

Civilians Ask “What’s With All the Privacy Act Kerfluffle?”

June 26th, 2008 by rybolov

And by “kerfluffle”, I mean these articles:

Well, let’s talk about how privacy and the Government works with Uncle Rybolov (please hold the references to Old Weird Uncle Harold until we’re through with today’s lesson please).

We have a law, the Privacy Act of 1974.  Think about it, what significant privacy-wrenching activities happened just a couple of years prior?  Can we say “Watergate Scandal“?  Can we say “Church Committee“?  Suffice it to say, the early 1970s was an era filled with privacy issues and is where most of our privacy policy and law comes from.  Remember this for later:  this was the 1970’s!

Each of the various sections of the Privacy Act deals with a particular data type.  For instance, Title 13 refers to data collected by the Census Bureau when they’ll go count everybody in 2010.

The Privacy Act talks about the stuff that everybody in the Government needs to know about:  how you’re going to jail if you disclose this information to a third party.  For those of you who have ever been in the military or had to fill out a government form that required your social security number, the light in the back of your head should be going off right now because they all have the warnings about disclosure.

Huts and Chairs Need Privacy Too

Remember to respect the privacy of the beach huts and chairs photo by Joe Shlabotnik

When it comes to IT security, the Privacy Act works like this:

  • You realize a need to collect PII on individuals.
  • You do a privacy impact assessment to determine if you can legally collect this data and what the implications of collecting the data are.
  • You build rules about what you can do normally with the data once you have collected it.  This is called the “routine use”.
  • You write a report on how, why, and about whom you’re collecting this information.  This is known as the “System of Record Notice”.
  • You file this report with the Federal Register to notify the public.
  • This IT system becomes the authoritative source of that information.

IE, no secret dossiers on the public.  We’ll suspend our disbelief in FISA for a minute, this conversation is about non-intelligence data collection.

Now the problem with all this is that if you stop and think about it, I was 1 year old when the Privacy Act was signed.  Our technology for information sharing has gone above and beyond that.  We can exchange data much much much more quickly than the Privacy Act originally intended.  As a result, we have PII everywhere.  Most of the PII is needed to provide services to the citizens, except that it’s a royal PITA to protect it all, and that’s the lesson of the past 2 years in Government data breaches.

Problems with the Privacy Act:

  • The SORN is hard to read and is not easy to find.
  • Privacy Act data given to contractors or “business partners” (aka, state and local government or NGOs) does not have the same amount of oversight as it does in the Government.
  • Data given to the Government by a third-party is not susceptible to the Privacy Act because the Government did not collect it.  Wow, lots of room for abuse–waterboarding-esque abuse.
  • Privacy Act procedures were written for mainframes.  Mainframes have been replaced with clusters of servers.  It’s easy to add a new server to this setup.  Yes, this is a feature.
  • If you build a new system with the same data types and routine uses as an already existing SORN, you can “piggyback” on that existing SORN.
  • It’s very easy to use the data in a way that isn’t on your “routine use” statement, thus breaking the entire privacy system.

Obviously, at this point, you should have gotten the hint that maybe we need to revise the Privacy Act.  I think GAO and OMB would agree with you here.

So, what alternatives do we have to the existing system?

  • Make blanket data types and do a PIA and SORN on them regardless of where that data lies.
  • Bend the Paperwork Reduction act and OMB guidance so that we don’t collect as much information.
  • Make the Privacy Act more specific on what should be in SORN, PIA, and routine use statements.

To be honest, it seems like most of this is already in place, it just needs to get tuned a little bit so we’re doing the right things.  Once again, the scale of the Government’s IT infrastructure is keeping us from doing the right thing:    there isn’t enough time in the day to do PIAs on a per-server basis or to keep track of every little bit of data.  You have to automate our privacy efforts in some fashion.

And this is why, dear readers, I think the Government needs DLP solutions more than the private sector does.  Too bad the DLP vendors are stuck on credit cards and social security numbers.

Posted in FISMA, Rants, What Doesn't Work | No Comments »

LOLCATS Take on POA&Ms

June 26th, 2008 by rybolov

Truth be told, most people hate POA&Ms because they’re more work for you to do.  Deep down inside, though, they’re a reason to get funding to fix things.

 

funny pictures

Posted in IKANHAZFIZMA | 1 Comment »

Needed: Agency CSOs

June 26th, 2008 by rybolov

Check out this article by Andy Boots on the Tech Insiders blog.

It brings up an interesting point:  Agencies do not typically have a CSO-level manager.  According to FISMA, each agency has to have a CISO whose primary responsibility is information security.

But typically these CISOs do not have any authority over physical security or personnel security:  in reality, they work for the CIO and only have scope over what the CIO manages:  data centers, networks, servers, desktops, applications, and databases.

Except for one thing:  we’re giving today’s Government CISO a catalog of controls that contain physical and personnel security.  The “party line” that I’ve gotten from NIST is that the CISOs need to work through the CIO to effect change with the areas that are out of their control.  I personally think it’s a bunch of bull and that we’ve given CISOs all of the responsibility and none of the authority that they need to get the job done.  In my world, I call that a “scapegoat”.

To be honest, I think we’re doing a disservice to our CISOs, but the only way to fix it is to either move our existing CISOs out of the CIOs staff and make them true CxOs or write a law creating an agency CSO position just like Clinger-Cohen created the CIO and FISMA created the CISO.

Posted in FISMA, Rants | 1 Comment »

Agencies CISOs Star in LOLCATS!

June 19th, 2008 by rybolov

I’m surprised they don’t issue flak jackets to incoming CISOs, what with as many people taking shots at them.

 

funny pictures

Posted in IKANHAZFIZMA | 2 Comments »

NIST’S FISMA Pase II–Who Certifies Those who Certify the Certifiers?

June 17th, 2008 by rybolov

Check out this slideshow and this workshop paper from 2006 on some ideas that NIST and a fairly large advisory panel have put together about certification of C&A service providers.  I’ve heard about this for several years now, and it’s been fairly much on a hiatus since 2006, but it’s starting to get some eartime lately.

The interesting thing to me is the big question of certifying companies v/s individuals.  I think the endgame will involve doing both because you certify companies for methodology and you certify people for skills.

This is the problem with certification and accreditation services as I see it today:

  • Security staffing shortage means lower priority:  If you are an agency CISO and have 2 skilled people, where are you going to put them?  Odds are, architecture, engineering, or some other high-payoff activity, meaning that C&A services are candidates for entry-level security staff.
  • Centralized v/s project-specific funding:  Some agencies have a “stable” of C&A staff, if it’s done wrong, you end up with standardization and complete compliance but not real risk management.  The opposite of this is where all the C&A activities are done on a per-project basis and huge repetition of effort ensues.  Basic management technique is to blend the 2 approaches.
  • Crossover of personnel from “risk-avoidance” cultures:  Taking people from compliance-centric roles such as legal and accounting and putting them into a risk-based culture is a sure recipe for failure, overspending, and frustration.
  • Accreditation is somewhat broken:  Not a new concept–teaching business owners about IT security risk is always hard to do, even more so when they have to sign off on the risk.
  • C&A services are a commodity market:  I covered this last week.  This is pivotal, remember it for later.
  • Misinformation abounds:  Because the NIST Risk Management Framework evolves so rapidly, what’s valid today is not the same that will be valid in 2 years.

So what we’re looking at with this blog post is how would a program to certify the C&A service providers look like.  NIST has 3 viable options:

  • Use Existing Certs: Require basic certification levels for role descriptions.  DoD 8570.1M follows this approach.  Individual-level certification would be CAP, CISSP, CG.*, CISA, etc.  The company-level certification would be something like ITIL or CMMI.
  • Second-Party Credentialing:  The industry creates a new certification program to satisfy NIST’s need without any input from NIST.  Part of this has already happened with some of the certifications like CAP.
  • NIST-Sponsored Certification:  NIST becomes the “owner” of the certification and commissions organizations to test each other.

Now just like DoD 8570.1M, I’m torn on this issue.  On one hand, it means that you’ll get a higher caliber of person performing services because they have to meet some kind of minimum standard.  On the other hand, introducing scarcity means that there will be even less people available to do the job.  But the big problem that I have is that if you introduce higher requirements on commodity services, you’re squeezing the market severely:  costs as a customer go up for basic services, vendors get even less of a margin on services, more charlatans show up because you’ve tipped over into higher-priced boutique services, and mayhem ensues.

Guys, I’m not really a rocket scientist on this, but really after all this effort, it seems to me that the #1 problem that the Government has is a lack of skilled people.  Yes, certifying people is a good thing because it helps weed out the dirtballs with a very rough sieve, but I get the feeling that maybe what we should be doing instead is trying to create more people with the skills we need.  Alas, that’s a future blog post….

However, the last thing that I want to see happen is a meta-game of what’s going on with certifications right now–who certifies those who certify?  I think it’s a vicious cycle of cross-certification that will end up with the entire Government security industry becoming one huge self-licking ice cream cone.  =)

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

« Previous Entries


Visitor Geolocationing Widget: