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

June 26th, 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!

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 »

Why You Should Care About Security and the Government

June 3rd, 2008 by rybolov

Well, this is a little bit of a departure from my usual random digital scribblings that I call a blog:  I partnered up with Vlad the Impaler and we created a slideshow complete with notes about why you should care about security and the Government and what you can learn from watching the Government succeed or fail.

The .pdf of the presentation is here.  Feel free to share with your friends, coworkers, and co-conspirators.

Posted in FISMA, Speaking | 4 Comments »

More on Georgia’s FISMA Reporting

May 19th, 2008 by rybolov

I remember it like it was March:  Georgia voluntarily adopted FISMA-esque metrics.  I just found the policy statement for what they’re collecting in 2008.  On a side note, all of Georgia’s security policies feature concepts borrowed from NIST, something I like.

Let’s talk about the scope creep of Government security, shall we?  Fact of the matter is, it’s going to happen, and you’ll get eventually get caught up in FISMA if you’re one of the following:

  • State and local government
  • Government contractor
  • Telco
  • Government service provider
  • COTS software vendor
  • Utilities who own “Critical Infrastructure”

Why do I say this?  Mainly because just like how the DoD is discovering that it can’t do its InfoSec job without bringing the civilian agencies along due to connectivity and data-sharing issues, the Federal Government is coming to the point where it can’t secure its data without involving these outside entities.  Some are providers, but the interesting ones are “business partners”–the people that share data with the Government.

State and local government are the ones to watch for this pending scope creep.  The Federal Government works on the premise that the responsibility to protect data follows wherever the data goes–not a bad idea, IMO.  If they transfer data to the states, the states need to inherit the security responsibility and appropriate security controls along with it.

Now if I’m a contractor and exchange data with the Government, this is an easy fix:  they don’t pay me if I don’t play along with their security requirements.  When a new requirement comes along, usually we can haggle over it and both sides will absorb a portion of the cost.  While this might be true for some state programs, it becomes a problem when there is no money changing hands and the Federal Government wants to levy its security policies, standards, etc on the states.  Then it becomes a revolt against an unfunded mandate like RealID.

There are some indicators of Federal Government scope creep in the Georgia policy.  This one’s my favorite:

The performance metrics will also enhance the ability of agencies to respond to a variety of federal government mandates and initiatives, including the Federal Information Security Management Act (FISMA).

Georgia on my Mind

Georgia on my Mind by SewPixie.

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


Visitor Geolocationing Widget: