Archive for the ‘The Regs’ Category

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.