(If you don’t get the reference, subtract 50 geek points).

So, if you haven’t heard the news, HHS (finally) submitted their proposed final rule for meaningful use to the OMB last week.  Of course, everyone is very excited (oooo…. shiny new rules) and very nervous (Oh noes!  New rulz!11!!) about  the changes.

Of course, those of us with a security bent are particularly keen on how they address the public commentary.  Most folks seem to think that they’ll relax the final rule across the board.  I agree with that, but my hope is they won’t relax the security aspects they’ve laid out.  There’s some good stuff in there.  For example, if you look at the Interim Final Rule from January, you see awesome little tidbits like this one (on 2034 – page 22 of the pdf link):

Consequently, a HIPAA covered entity could be in compliance with the HIPAA Security Rule if it determines that encryption is not reasonable and appropriate in its environment and it documents its rationale and implements an equivalent alternative measure if reasonable and appropriate. We hope that by requiring Certified EHR Technology to include this capability, that the use of encryption will become more prevalent.

See what they did there?  Not only did they clarify what a covered entity has to do under HIPAA when they believe encryption is not “reasonable and appropriate” (i.e. document the rationale and implement equivalent measures), but they also recognize that few in the provider space actually encrypt ePHI (hey, you made them addressable so point the finger back on you buddy).  So them requiring it of the EHR is pretty cool.

There are a number of reasons that I like what they have in the Interim Final Rule – and not just because of the encryption piece.  For example, I get nervous about makeshift (homegrown) EMRs, EHR software that purports not to be, as well as the finely-chopped slaw of aging software that you see in the field so often.  So…  I’m on board.  Not only do I think that the new rules will drive useful technology adoption (man I wish those folks were public), but I also think it’ll shake out some of the overlap that we’re seeing among traditional products and provide impetus for vendor innovation.

So hats off to HHS for moving this through.

Last month, if you remember, the FFIEC put out their 2005 authentication guidance. We harshed on it here, saying that we didn’t think that there was much of a difference between the 2001 guidance and the 2005 guidance. We’ve received some mixed feedback to that commentary from folks in FS (folks that I’ve worked with in previous lives)… As of now, I’ve spoken to two individuals (one client and one ex-coworker) who pointed out that they feel that the guidance is a mandate – or at least a stick that can be used to get the business folks in line… Anyway, thought some out there might find it useful that folks in FS are actually taking notice of this. As to how much traction 2 factor will get in deployment, that remains to be seen, but at least the interest is there.

I came across this article this morning. For those of you who don’t feel like reading it, basically it says that RedHat and SE (Security Enhanced) Linux are going through common criteria certification so that it can be used in the US government. Good news, right? On the surface, it would seem so – but I think it points out a problem inherent in the process. First of all, non-certified products are in use already (meaning compliance is selective anyway) and certification isn’t “good news” – particularly when it comes to a “release early, release often” product like Linux.

First of all, we know it’s already in use. For example, check out this article from Groklaw. Seriously, when has the fact that a platform is not EAL certified stopped it from being used by the government? After all, Mac OSX is on the federal reference architecture. The reality is: the whole EAL process (and the TCSEC process before that) is broken. As is FIPS 140. Here’s why:

The DITSCAP relies on accredidation personnel within an initiative to ensure that these standards are followed. If an accreditor is not clued in to the fact that this type of certification is a requirement, they won’t enforce the reg. End result: incentive for PO’s to “dumb down” accreditation personnel. In point of fact, it’s less expensive to have accreditors that will let something “slip by” than having accreditors that enforce. Problem #1.

Problem #2 is that these regs all but ensure that federal systems have less security than commercial systems. How is that, you ask? Specifically, a certification is invalid as soon as the product changes significantly. For example, there could be a case whereby a patch that is required to fix a security issue cannot be applied because it will invalidate the FIPS 140 or EAL cert. You disagree? Look at the list. The last version of Oracle that’s certified is Oracle 9.2.0.1.0. What’s the current version? How about 10g Release 2… Wow, that’s a major revision. I wonder what type of security bugs have been fixed in the meantime… The same is true of FIPS 140-2. Certification trumps vulnerability fixes in every case; it also trumps common sense.

Let me tell you a little story. Back in the day, when I was working in the federal sector, the time came to deploy Citrix. This was before the CSG (Citrix Secure Gateway) used FIPS 140-2 approved cryptography. I, as the security engineer, indicated that it would be good to have cryptography on the channel due to the untrustworthiness of the network the traffic passed through. However, turning on cryptography meant that it would be a non-FIPS device; keeping it off meant it wasn’t a cryptographic device and therefore FIPS 140 didn’t apply. The decision? Keep cryptography off, and thereby decrease the security of the system in order to comply with the reg. In other words, don’t think, just comply.

Here’s my point: I think the purpose of FIPS 140 and the EAL is to keep “snake oil” out of the federal government. That’s a great goal. However, in practice, I think these regs need to be applied with intelligence. Taking away the ability of security folks to use their intelligence decreases the security of the systems involved and is not a good thing.

A must read article about compliance with plenty of useful and intelligent commentary from Diana.

The Electronic Banking Group of the Basel Committee on Banking Supervision, a consortium of banks from the US, Europe, and Asia, has released two new/finalized documents, “Risk Management Principles for Electronic Banking” and “Management and supervision of cross-border electronic banking activities.”

The documents are offered as guidance rather than ‘hard and fast’ requirements that all financial institutions are expected to abide by. Specficially the documents address some of the flux that occurs when traditional risk management is applied to cross-border banking.

Both documents are well worth reading. While neither is an in-depth, how-to, cookbook, they both provide a solid foundation for understanding many of the risk issues facing the international financial community.

An eweek article that takes a look at what Sarbanes-Oxley meanrs to companies. “Of particular interest is Section 404 of Sarbanes-Oxley, which requires companies to perform a self-assessment of risks for business processes that affect financial reporting.”

The take away here is that though there are companies that help provide tools that faciliate reporting for compliance, the general need for organizations to have solid, coherent reporting in place goes beyond the act. This is about making companies responsible for their reporting and risk management which is something all companies should be anyhow.

The gov’t is now on the hook to make sure they spell out compliance requirements clearly so that organizations can compy.