Part 1

Part 2

Takeaways from the 20 CSC and what they do right (hey, it’s not all bad):

You have to prioritize. On a system basis, there are maybe 50-60 800-53 controls (out of a number just shy of 200) that need to be built 100% correctly and working every single time.  The rest (I know, I’m putting on my heretic hat here) can lapse from time to time.  For example, if I don’t have good event monitoring, my incident response team doesn’t have much work because I don’t know if I’m pwned or not.  What 20 CSC does is try to reduce that set of stuff that I should be concerned about into a set of controls that are technical, tactical, and track to classes taught by SANS vulnerability-based .

Common controls are more important than ever. They help you scope the smaller systems.  In fact, roughly half of the 20 CSC apply to the modern Enterprise and should be absorbed there, meaning that for systems not owning infrastructure, we only have 10 or so controls that I have to worry a bunch about, and 10 that I just need to be aware of what’s provided by my CISO.

Give examples. I’ll even go as far as to say this:  it should be a capital offense to release a catalog of controls without a reference implementation for both an Enterprise/GSS and a smaller IT system/Major Application inside of it.  20 CSC stops maybe one step short of that, but it’s pretty close in some controls to what I want if they were structured differently.

Security Management v/s IT Management. IT asset inventory, configuration management, change control:  these are IT management activities that somehow get pushed onto the security team because we are more serious about them than the people who should care.  I think 20 CSC does an OK job of just picking out the pieces that apply to security people instead of the “full meal deal” that ITIL and its ilk bring.

Control Key photo by .faramarz.

Now for what they did wrong:

It’s Still Not a Consensus, Dammit! That is, it’s a couple of smart people making a standard in a vacuum and detached from the folks who will have to live by the work that they do.  Seriously, ask around inside the agencies:  who admits to helping develop 20 CSC aside from “yeah, we looked at it briefly”?  And I’m not talking about the list that SANS claims, that’s stripped from the bios of the handful of people who did work on 20 CSC.  Sadly, this is the quick path to fail, it’s like building an IT system without asking the users what they need to get their job done on a daily basis.  Guys, we should know better than this.

It’s Still Not a Standard. It’s still written as guidance–more anecdote than hard requirements.  This isn’t something I can put into a contract and have my contractors execute without modifying it heavily.  It’s also not official, something I’ve already touched on before, which means that it’s not mandatory.  If you want to make this a standard, you need to turn it into ~50 controls each written as a “contracting shall”.  More to come on this in the future.

It Has Horrible Metrics. And I’m talking really horrible…it’s like the goatse of security metrics (NSFW link, even though it’s wikipedia).  Why?  Because they’re time-based for controls that are not time-based.  Metrics need to be a way to evaluate that the control works, not the indirect effects of the control.  Of course, metrics are just a number, but at the end of whatever assessment, my auditor/IG/GAO/$foo has to come up with some way to rank the work that I’ve done as a security officer.  If 20 CSC is the vehicle for the audit and the metrics are hosed, it doesn’t matter what I can do to provide real security, the perception from my management is that I don’t know what I’m doing.

Bookmark to:

Hide Sites

A small presentation Dan Philpott and I put together for Potomac Forum about getting sane social media policy out of your security staff. I also recommend reading something I put out a couple of months ago about Social Media Threats and Web 2.0.

Bookmark to:

Hide Sites

I sat down with Jim Manico a month or so ago when he was in DC and recorded a podcast for the OWASP Podcast.  It’s now live, check it out.

Bookmark to:

Hide Sites

The big news in OMB’s M-09-29 FY 2009 Reporting Instructions for the Federal Information Security Management Act and Agency Privacy Management is that instead of fiddling with document files reporting will now be done directly through an online tool. This has been covered elsewhere and it is the one big change since last year.  However having less paper in the paperwork is not the only change.

Piles of Paper photo by °Florian.

So what will this tool be like? It is hard to tell at this point. Some information will be entered directly but the system appears designed to accept uploads of some documents, such as those supporting M-07-16. Similar to the spreadsheets used for FY 2008 there will be separate questions for the Chief Information Officer, Inspector General and Senior Agency Official for Privacy. Microagencies will still have abbreviated questions to fill out. Additional information on the automated tool, including full instructions and a beta version will be available in August, 2009.

Given the required information has changed very little the automated system is unlikely to significantly ease the reporting burden. This system appears primarily designed to ease the data processing requirements for OMB. With Excel spreadsheets no longer holding data many concerns relating to file versions, data aggregation and analysis are greatly eased.

It is worth noting that a common outcome of systems re-engineered to become more efficient is that managers look to find ways to utilize the new efficiency. What does this mean? Now that OMB has the ability to easily analyze data which took a great amount of effort to process before they may want to improve what is reported. A great deal has been said over the years about the inefficiencies in the current reporting regime. This may be OMB’s opportunity to start collecting an increased amount of information that may better reflect agencies actual security posture. This is pure speculation and other factors may moderate OMB’s next steps, such as the reporting burden on agencies, but it is worth consideration.

One pleasant outcome to the implementation of this new automated tool is the reporting deadline has been pushed back to November 18, 2009.

Agencies are still responsible for submitting document files to satisfy M-07-16. The automated tool does not appear to allow direct input of this information. However the document requirements are slightly different. Breach notification policy document need only be submitted if it has changed. It is no longer sufficient to simply report progress on eliminating SSNs and reducing PII, an implementation plan and a progress update must be submitted. The requirement for a policy document covering rules of behavior and consequences has been removed.

In addition to the automated tool there are other, more subtle changes to OMB’s FY 2009 reporting. Let’s step through them, point by point:

10. It is reiterated that NIST guidance is required. This point has been expanded to state that legacy systems, agencies have one year to come into compliance with NIST documents new material. For new systems agencies are expected to be in compliance upon system deployment.

13 & 15. Wording indicating that disagreements on reports should be resolved prior to submission and that the agency head’s view will be authoritative have been removed. This may have been done to reduce redundancy as M-09-29’s preface indicates agency reports must reflect the agency head’s view.

52. The requirement for an central web page with working links to agency PIAs and Federal Register published SORNs has been removed.

A complete side-by-side comparison of changes between the two documents is available at FISMApedia.org.

All in all the changes to OMB’s guidance this year will not change agencies reporting burden significantly. And that may not be a bad thing.

Bookmark to:

Hide Sites

We have all these data wonks running around now in the information security field thanks to a couple of people (Jaquith, Shostack, Stewart, and our friends at Verizon Business) who brought us some books and some data.

Well, earlier this year, the Government started a website called Data.gov.  This is much awesomeness, Viva Las Transpareny!  However, it’s missing something very relevant to my interests: information security management data.

So, I want people to go to data.gov’s “request a dataset” page and request the following:

Complete responses from the Departments and Agencies to the FISMA reporting requirements for FY2004-2009 based on OMB Memoranda 04-25, 05-15, 06-20, 07-19, 08-21, and 09-29.

Raw incident data for years 2005-2007 as reported to OMB and summarized in their report to Congress on FY2007 FISMA performance and published at http://www.whitehouse.gov/omb/inforeg/reports/2007_fisma_report.pdf

Raw incident data for years 2007 and later in any type and format similar to the Verizon Data Breach Incident Report available at http://www.verizonbusiness.com/resources/security/reports/2009_databreach_rp.pdf

This information is necessary for researchers to study the effectiveness of information security management techniques and regulatory schemes and for industry to propose changes to national-level information security management frameworks and legislation such as FISMA.  This information for the most part has been released in a summary format to Congress and the release of the complete dataset on data.gov would greatly aid the information security community.

It might be a fool’s errand at this point, but it doesn’t hurt to ask, and it only takes a couple of minutes to do.  =)

Bookmark to:

Hide Sites

OK, so there’s this article being bounced all over the place.  Basic synopsis is that FISMA is keeping the government from doing any kind of electronic health records stuff because FISMA requirements extend to health care providers and researchers when they take data from the Government.

Read one version of the story here

So the whole solution is that, well, we can’t extend FISMA to eHealthcare when the data is owned by the Government because that security management stuff gets in the way.  And this post is about why they’re wrong and right, but not in the places that they think they are.

Government agencies need to protect the data that they have by providing “adequate security”.  I’ve covered this a bazillion places already. Somewhere somehow along the lines we let the definition of adequate security mean “You have to play by our rulebook” which is complete and utter bunk.  The framework is an expedient and a level-setting experience across the government.  It’s not made to be one-size-fits-all, but is instead meant to be tailored to each individual case.

The Government Information Security Trickle-Down Effect is a name I use for FISMA/NIST Framework requirements being transferred from the Government to service providers, whether they’re in healthcare or IT or making screws that sometimes can be used on the B2 bombers.  It will hit you if you take Government data but only because you have no regulatory framework of your own with which you can demonstrate that you have “adequate security”.  In other words, if you provide a demonstrable level of data protection equal to or superior to what the Government provides, then you should reasonably be able to take the Government data, it’s finding the right “esperanto” to demonstrate your security foo.

If only there was a regulatory scheme already in place that we could use to hold the healthcare industry to.  Oh wait, there is: HIPAA.  Granted, HIPAA doesn’t really have a lot of teeth and its effects are maybe demonstrable, but it does fill most of the legal requirement to provide “adequate security”, and that’s what’s the important thing, and more importantly, what is required by FISMA.

And this is my problem with this whole string of articles:  The power vacuum has claimed eHealthcare.  Seriously, there should be somebody who is in charge of the data who can make a decision on what kinds of protections that they want for it.  In this case, there are plenty of people with different ideas on what that level of protection is so they are asking OMB for an official ruling.  If you go to OMB asking for their guidance on applying FISMA to eHealthcare records, you get what you deserve, which is a “Yes, it’s in scope, how do you think you should do this?”

So what the eHealthcare people really are looking for is a set of firm requirements from their handlers (aka OMB) on how to hold service providers accountable for the data that they are giving them.  This isn’t a binary question on whether FISMA applies to eHealthcare data (yes, it does), it’s a question of “how much is enough?” or even “what level of compensating controls do we need?”

But then again, we’re beaten down by compliance at this point.  I know I feel it from time to time.  After you’ve been beaten badly for years, all you want to do is for the batterer to tell you what you need to do so the hurting will stop.

So for the eHealthcare agencies, here is a solution for you.  In your agreements/contracts to provide data to the healthcare providers, require the following:

• Provider shall produde annual statements for HIPAA compliance
• Provider shall be certified under a security management program such as an  ISO 27001, SAS-70 Type II, or even PCI-DSS
• Provider shall report any incident resulting in a potential data breach of 500 or more records within 24 hours
• Financial penalties for data breaches based on number of records
• Provider shall allow the Government to perform risk assessments of their data protection controls

That should be enough compensating controls to provide “adequate security” for your eHealthcare data.  You can even put a line through some of these that are too draconian or high-cost.  Take that to OMB and tell them how you’re doing it and how they would like to spend the taxpayers’ money to do anything other than this.

Case Files and Medical Records photo by benuski.

Bookmark to:

Hide Sites