And by “kerfluffle”, I mean these articles:

• GAO Privacy Report
• Technology Liberation Front
• Center for Democracy and Technology
• And how about an analysis of the Privacy Act from DOJ for background reasons?

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.

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.

• More on Georgia’s FISMA Reporting
• Current Government Security Initiatives
• New SP 800-60 is Out, Categorize Yerselves Mo Better
• Database Activity Monitoring for the Government
• Transparency in Government: Just Give us the Data!

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.

• An Open Letter to NIST About SP 800-30
• Next Up in Security Legislation: S3474
• Opportunity Costs and the 20 Critical Security Controls
• Workin’ for the ‘Counters: an Analysis of my Love-Hate Relationship with the CPAs
• Database Activity Monitoring for the Government

I’ve spent a couple of days traveling around to agencies to teach.  It was fun but tiring, and the best part of it is that since I’m not teaching pure doctrine, I can include the “here’s how it works in real life” parts and some of the BSOFH parts–what I refer to as the “security management heretic thoughts”.

Some basic statements, the rest of this post will explain:

• C&A is a commodity market
• Security controls assessment is a commodity market
• PCI assessment is a commodity market
• Most MSSP (or rather, Security Device Management Service Providers) services are commodity markets

Now my boss said the first one to me about 4 months ago and it really needed some time for me to grasp the implications.  What we mean by “commodity market” is that since there isn’t really much of a difference between vendors, the vendors have to compete on having the lower price.

Now what the smart people will try to do is to take the commodity service and try to make it more of a boutique service by increasing the value.  Problem is that it only works if the customers play along and figure out how your service is different–usually what happens is you lose in the market simply because now you’re “too expensive”.

Where Boutique Sits by miss_rogue.

Since the security assessment world is a services business, the only way to compete in a commodity market is to pay your people less and try to charge more. But oh yeah, we compete on price, so that only leaves the paychecks as the way to keep the margin up.

Some ways that vendors will try to keep the assessment costs down:

• Hire cheaper people (yes, paper CISSPs)
• Try to reduce the engegement to a formula/methodlogy (ack, a checklist)
• It’s all about billability:  what percentage of your people’s time is not billable to clients? 
• Put people on assessments who have tangential skills just to keep them billable
• Use Cost-Plus-Margin or Time-Plus-Materials so that you can work more hours
• Use Firm-Fixed-Price contracts with highly reduced services ($150 PCI assessments)

Now inside Government contracting, there’s a fact that’s not known outside of the beltway:  your margins are fixed by the Government.  In other words, they only allow you to have around a 13-15% margin.  The way to make money is that the pie is a much bigger pie, even though you only get a small piece of it.  And yes, they do look at your accounting records and yes, there are loopholes, but for the most part, you can only collect this little margin.  If you stop and think about it, the Government almost forces the majority of its contractors into a commodity market.

Then we wonder why C&A engagements go so haywire…

The problem with commodity markets and vulnerability/risk/pen-test assessments is that your results, and by extension your ability to secure your data, are only as good as the skills and creativity of the people that the vendor sends.  Sounds like a problem?  It is.

So knowing this, how can you as the client get the most out of your service providers? This is a quick list:

• Every year (or every other), get an assessment from somebody who has a good reputation for being thorough (ie, a boutique)
• Be willing to pay more for services than the bottom of the market but be sure that you get quality people to go along with it, otherwise you’ve just added to the vendor’s margin with no real improvements to yourself
• Get assessments from multiple vendors across the span of a year or two–more eyes means different checklists
• Provide the assessors with your own checklists so you can steer them (tip from Dave Mortman)
• Self-identify vulnerabilities when appropriate (especially with vulnerabilities from previous assessments)
• Typical contracting fixes such as scope management, reviewing resumes of key personnel, etc
• Get lucky when the vendor hires really good people who don’t know how much they’re really worth (that was me 5 years ago)
• More than I’m sure will end up in the comments to this post  =)

And the final technique is that it’s all about what you do with the assessment results.  If you feed them into a mitigation plan (goviespeak: POA&M) and improve your security, it’s a win.

• Engagement Economics and Security Assessments
• Categories of Security Controls in Outsourcing
• Splunk Goes After the FISMA Lucre, They’re not Alone
• When the Feds Come Calling
• Split-Horizon Assessments and the Oversight Effect

Dear NIST People,

I have this semi-random digital scribbling thingie called a blog.  You might have heard of them.  Hey, you might have even at one point heard of mine.  =)

On my blog I let it be known that I am what the rest of the world would call a “NIST Cheerleader”.  I watch your every move.  I comment on your new publications.  I teach your framework every quarter.  From time to time, I criticize, but only because I have a foot in the theory of information security that you live and a foot in the implementation with agencies who know where the theory and models break.

The best thing that you have given us is not the risk management framework, it was SP 800-30, “Risk Management Guide for Information Systems”.  It’s small, to-the-point, and scalable from a single server to an entire IT enterprise.  Sure, the quants hate it, but for the quals and Government, it’s good enough.  I know private-sector organizations that use it.  One of my friends and blog readers/commenters was the guy who taught a group of people how to do risk assessment, then these same people went on to help you write the book.

I heard that you were in the process of revising SP 800-30.  While this is much needed to catch up/modernize, I want to make sure that 800-30 does not follow the “live by the catalog, die by the catalog” path that we seem to be following lately.  In other words, please don’t change risk assessment process to the following:

1. Determine boundary
2. Determine criticality
3. Conduct a gap assessment against a catalog of controls (SP 800-53/800-53A)
4. Attach a priority to mitigation
5. Perform risk avoidance because compliance models are yes/no frameworks
6. Document
7. ???
8. Profit!

At Your Own Risk Photo by  Mykl Roventine.

The reason that I am writing this is to let you know that I have noticed a disturbing trend in how now that we have a catalog of controls, the risk management framework is focusing more and more heavily on the catalog as the vehicle for determine an adequate level of security.  Some of this is good, some of this is not.

Why am I so concerned about this?  Well, inside the Government we have 2 conflicting ideas on information security:  compliance v/s risk management.  While we are fairly decent Government-wide at compliance management, the problem that we have is in risk management because risk management is only as good as the people who perform the risk assessment.  Not that we don’t have competent people, but the unknowns are what will make or break your security program, and the only way that you can known the unknowns is to get multiple assessments aimed at risks outside of the control catalog.

However, if you change the risk assessment process to a “catalog of controls gap analysis” process, then we’ve completely lost risk management in favor of compliance management.  To me, this is a disturbing trend that needs to be stopped.

Thank you for your time

–Rybolov

• Observations on SP 800-37R1
• Workin’ for the ‘Counters: an Analysis of my Love-Hate Relationship with the CPAs
• Reinventing FedRAMP
• It’s a Problem of Scale!
• Now ISC2 Blogs have an Opinion on FISMA

Interesting blog post at Freedom to Tinker about government releasing the raw data.  It makes the security geek in me cringe because well, most of the data that the government has is PII, and I know that the typical government reaction is to say “not only no, but h*ll no!!”  I mean, after all, most of our goal in the Government is to keep the data from reaching the citizens and evil-doers–giving away data is a cultural clash.

Yes, transparent government is a pretty good goal.  I think the authors of Freedom to Tinker have forgotten that not all Government data is fit for public consumption.  The problem is one of sanitization:  how do you clean all of the PII out of data before you release it to the public?  Not only that, but because of the size of the data sets, most likely you need an automated method to sanitize it.  I think that because of the sanitization factor that the Government would not gain that much efficiency by outsourcing the data presentation to others.

As with all things in security, this is nothing new.  There’s a little-known project (First Rule of “Fight Club” being what it is…) known as Radiant Mercury that does exactly this with classified data.  You can check out the basic concept in quasi-official presentations here (.pdf caveat) and here.

If we were going to make all this data available, we would need an unclassified version of Radiant Mercury to filter out all the PII and “Sensitive but Unclassified” bits.

Now as far as letting second parties build interfaces into the raw data, I’m torn on it.  On one hand, private industry can provide access to data “Now at Web 2.0 Speeds!” but on the other hand, then the Government loses control over the presentation and, by extension, accountability for the content.

• Database Activity Monitoring for the Government
• Civilians Ask “What’s With All the Privacy Act Kerfluffle?”
• Random Thoughts on “The FISMA Challenge” in eHealthcare
• “SBU” Must Die
• It’s a Problem of Scale!

The fun part of this time of the year:  the FISMA Report Armchair Quarterbacks.  Hey, even I fit in there somewhere because right now I’m nowhere near being in a decision-making role for the Government.

Well, today it’s the ISC2 blog talking about FISMA.

So why is it that nobody addresses the huge pink and chartreuse elephant in the room?  The problem is not the metrics, as flawed as they might be.  The problem is not identifying a security baseline, even though that makes sense to have.  The problem is not demonstrating Return on Security Investment (as flawed as  the concept is, and no, I don’t want to debate whether it’s a valid concept, even though we all know it’s not) even though good CISOs try to do that as internal marketing to their management.

This is the primary problem for the Government when it comes to security:  due to the scale of the Federal Government, we do not have enough skilled security people to go around.  Almost all of our governance models are designed around this flaw:

• Catalog of controls to standardize
• Checklists so that less-skilled assessors can
• Varying degrees of automation
• Prioritization of security practitioners’ time

This is why I’m adding “Fast Food Franchises” to the list of models that large-scale security can draw from.  =)  More to come on this topic once I sort out the ideas.

McDonald’s Checklist photo by myuibe

• FISMA Report Card News, Formulas, and 3 Myths
• It’s a Problem of Scale!
• Workin’ for the ‘Counters: an Analysis of my Love-Hate Relationship with the CPAs
• An Open Letter to NIST About SP 800-30
• William Jackson on FISMA: It Works, Maybe