No business is an island. There’s no company that does not, to some extent, rely on other businesses. Business models assume that vendors will be able to assure a steady flow of goods, that retailers will sell goods and pay as contractually bound, that shippers will actually ship goods, etc. Our legal system is filled with assurances to that effect. And this is important, because it gives companies confidence to make such agreements. Knowing that business partners can in fact be bound and trusted to perform their duties, companies can more readily act to grow and increase their revenues. The key component here is confidence – a certainty that once a contract is signed, it will be followed.

That’s what makes the MegaUpload case rather disturbing. There’s no doubt that MegaUpload was hosting infringing content. However, the content was not all infringing – but all of it was taken down. Right now there is a case and the hosting company, Carpathia, is seeking court action which would allow it to release the existing data back to MegaUpload users.

However, in a way, the damage has already been done. Whatever the outcome of the case itself, one message has been sent clearly: your data can be held hostage by others’ data. That’s sure to have a chilling effect on the hosting industry for years to come.

I won’t bore you with the typical arguments about how it’ll infringe on free speech, or weakens safe harbor, etc. These arguments have been made, and they may have some validity, but let’s talk technology.

SOPA is the most recent in a long line of legislation intended to regulate the internet. Such legislation is doomed to failure. The internet was designed to be impossible to regulate. SOPA focuses on preventing search engines from directing users to sites, and ordering domain name registrars to delist sites. While there are other provisions, these are the primary tools for stopping piracy outside of US jurisdiction. They’re supremely ineffective tools, because neither search engines nor DNSes are necessary for the function of the Internet.

To understand this, let’s step back and look at what the Internet really is.

The Internet, or rather its precursors, were created in the 1960s as a result of an initiative by DARPA – the Defense Advanced Research Projects Agency. DARPA is notable for investing in all sorts of interesting projects that might have military applications – many are successful, and result in some of the most powerful technologies of our time. Granted, many are pretty off-the-wall and don’t look like they’ll ever amount to anything, but that’s the risk you take.
The Internet was created to enable communications even against attempts to disrupt the network – even against the loss of most metropolitan areas, such as might happen during a nuclear war. This is actually very hard to do: you have to come up with a design that works even if all of your central nodes are gone.
The Internet as we know it today has a number of elegant solutions which make it the most robust communications network ever known.
The first is in the data packet. All data sent on the Internet is broken up into packets – even when it’s called “streaming”, it actually consists of content that has been broken up into separate packets which are then reassembled at the destination. Each packet, in turn, has a portion that says to where the information is going (the address) and a portion which contains the actual data (payload). This means that any given packet can be lost or corrupted, and the entire rest of the message will still get through. Granted, with encryption or compression this might be a moot point, but on the other hand with error correction it can actually be made even more robust.
Beyond that, there are the routing protocols. Various routing protocols work somewhat differently in ways that are hard to describe, but they all serve roughly the same function. When a router receives a packet, it looks at the destination address and tries to find a route to that address. What’s especially clever is that if a given route fails, the router can then select an alternate route. In this way, the Internet can be self-healing. Bandwidth might drop as alternate routes are used, but so long as a path exists the message can still get through. And that path isn’t limited to even the same medium as was used in the past: Internet data can be sent over copper, satellite, radio, laser, physical media, even carrier pigeon!

Now, I haven’t mentioned DNS or search engines so far. That’s because we don’t need either.

DNS – Domain Name Service – is a technology that renders IP addresses into human-readable names. The addresses to which I alluded earlier are numerical. In IPv4 they’re a 32-bit binary number; in the newer IPv6 they’re a whopping 128 bits. Rendered into decimal, they’re a bit more manageable, but not by all that much – would you like to memorize strings of numbers like “192.168.15.106” for every website you visit? DNS is a service that your computer accesses which translates the much easier to recall names, like www.google.com into 74.125.227.147. It’s a nice convenience, but you don’t actually need it. And you’re not locked in to any one DNS server – you can set up your own, or you can actually use one that’s based outside of US jurisdiction.

And search engines?
Same thing – they’re a convenience. There isn’t even a specification on what a search engine is. And as you doubtless know, you can use whatever search engine you like, again including ones that are based outside of US jurisdiction.

There are technical solutions to these oversights, of course. But, thanks to the structure of the Internet, there are workarounds for those as well. The Internet was designed to be hard to disrupt. From a technical standpoint, attempts to regulate the Internet are basically the same as trying to disrupt it; it’s simply not a technology which was designed to be regulated.

However, even an imperfect solution can be useful. This week I came across this list of 35 general mitigation strategies suggested by the Australian DSD (they’re sorta like the NSA). Many of these paint with a wide brush (patch all the things!), but some are directed at specific applications of technology and software. The approach is very proactive in targeting the most widely used components of modern attack vectors. On their website, DSD makes the claim that implementing the top 4 suggested strategies would have prevented 85% of the incidents they responded to in 2010. A bold claim (assisted by wide scopes):

1. Update and patch Adobe products, Microsoft products, and Java.
2. Update and patch your OS
3. Be stingy with administrator/superuser access
4. Whitelist your programs

I’m sure that taking these steps can eliminate much of the low hanging fruit, and doing all 35 would probably eliminate even more. But even if all 35 are not ideal for every scenario, it’s still all-around decent computer security advice. These strategies can be a great reference source when fleshing out a custom security policy for mitigating attacks. The rest of the list can be found here (pdf).

It also sets the stage for wider adoption of EHR in the private sector. But there are reasons to be concerned about this, of course. There are few, if any, pieces of information more intrinsically private and personal than one’s medical records. And while making these records available in an electronic format offers great advantage in medical care, it opens up great risk of compromise.

As with any important data, there are ways to provide EHR. The medical industry in America is very heavily regulated, with HIPAA being the primary source of guidance. Based on HIPAA and related laws and regulations, various healthcare-related certifications exist. The two with which I am most familiar are DIACAP and CCHIT.

DIACAP stands for Department of Defense Information Assurance Certification and Accreditation Process. It’s not specific to medical information, but it is specific to DoD systems. It’s important here because most publicly-available EHR systems will have descended from DoD systems which had to pass DIACAP. DIACAP is a very intensive process which takes reams of documentation and months of work. It’s very comprehensive. Unfortunately, because of how it’s designed it can sometimes be outdated, and even force systems to be insecure. For example, at least as of 2010 when I last worked with it, systems were required to use Internet Explorer 6, with all the limitations of that browser. Nothing newer was possible.

Outside of the DoD, I’ve also worked to certify systems under CCHIT standards. CCHIT stands for Certification Commission for Health Information Technology, and has been required for certain government tax incentives and even in some cases the ability to operate a system at all. While still rather intensive, it is far less so than DIACAP. Realistically, looking back on it, it didn’t go into nearly enough depth on security, being focused on healthcare and data integrity.

This doesn’t even touch on the clinical side of things – the actual data directly gathered by medical devices like MRIs, CT scans, x-rays, etc. Most security audits avoid dealing with clinical data directly – it’s a hassle to allow auditors to know anything about those systems, and the auditors seldom have any idea what they’re looking at anyway. Frequently the data is handled in a proprietary fashion which may or may not be well-documented, and frankly it’s often little short of a miracle that it works at all. As a result, even if a hospital or doctor’s office has a secure computer system, the clinical data, the most revealing data, may be the least secure.

The most worrisome part, having been on both sides of the table for security reviews, is knowing that too often they’re looked upon as just another tedious piece of paperwork. As a tech writer, my job was frequently “write something so these people go away”. I’ve also seen security auditors who felt that their job was “find a reason to fail these people”. These attitudes are, of course, common to all security audits. But they become especially worrisome when it’s medical records on the line.

The victory in the crypto wars didn’t last long. Today, there are a slew of laws in place in various countries controlling the use of strong encryption. Some, like the UK’s “Regulation of Investigatory Powers” Act allows encryption but allows law enforcement to require that information be decrypted. Others, like France, require the use of trusted third parties in case law enforcement desires the keys. Still others, like the Communications Assistance for Law Enforcement Act (CALEA) in the US require other forms of encryption backdoors be in place. In a few places, certain forms of encryption are simply illegal.

There’s good news here, after a fashion. If ever we needed independent confirmation that the current level of cryptographic technology is pretty good, here it is. Governments, in the form of law enforcement, espionage, and military are all concluding that it’s not practical to break existing encryption. (Of course, this doesn’t mean they can’t, just that they either don’t think they can do so fast enough, or that it’s too costly). Still, this is a good sign for the quality of the encryption.

The bad news, however, is that complying with the law may make your data insecure. Notwithstanding how you feel about a given government reading your files and intercepting your communication, it’s a given that if a backdoor exists for one party, it exists for anyone sufficiently motivated to find it. So what are your options?

Well, pretty much the typical ones. First of all, learn the relevant laws about cryptography wherever you’re doing business. This is actually pretty hard, as there doesn’t seem to be any authoritative list, even just for the US, and it’s pretty hard to figure out who would even know. But once you do, it’s time for some hard decisions. You may decide that you can be sufficiently secure within the limits imposed on you. You may choose to keep truly sensitive information off the network, maybe keep something in-house that you’d rather outsource. In some cases, you might even decide you can’t do business, though that’s a pretty extreme measure.

Seemingly in direct response to this outburst, NIST has now released an update to their continuous monitoring FAQ, specifically pointing out that C&A activities are a necessary component of risk-based management of systems, and highlighting that continuous monitoring alone is insufficient.

One of the true oddities of the NASA statement is that continuous monitoring is only one component of the overall NIST Risk Management Framework (RMF). It’s unclear how they concluded that they could just pick one box out of the overall process and claim it covers everything – especially considering their claim to be seeking a risk-based approach.

Of course, in the end it may not matter at all. The House has passed FISMA reform this past week in it’s national security spending bill (also see this Information Week article; didn’t we used to call it “Defense appropriations”? anyway…). The bill also calls for the establishment of a “National Office of Cyberspace” to have better authority than Howard Schmidt currently has in his White House cabinet position. Similarly, the Senate is also pushing through reform, including yet another hare-brained attempt to give the federal government broad, sweeping powers over private critical infrastructure in “emergency” situations. This time around, the bill seeks to authorize DHS with such powers, whereas previous attempts focused on authorizing the President directly. We’ll see what becomes of this, but suffice to say that the move has not gone unnoticed in the security community.

From the FTC press release:

“Congress needs to fix the unintended consequences of the legislation establishing the Red Flags Rule – and to fix this problem quickly. We appreciate the efforts of Congressmen Barney Frank and John Adler for getting a clarifying measure passed in the House, and hope action in the Senate will be swift,” FTC Chairman Jon Leibowitz said. “As an agency we’re charged with enforcing the law, and endless extensions delay enforcement.”

For more information, please check out the following links:

• Wikipedia: Fair and Accurate Credit Transactions Act (FACTA)
• FTC Business Alert: New ‘Red Flag’ Requirements for Financial Institutions and Creditors Will Help Fight Identity Theft
• Legal analysis by The InfoLawGroup on the Red Flag Rules

You would think this would be an easily decided scenario; the digital signature is a superior and more trustworthy technology, right?  Well, not when you change the rules a bit. Basically they made the strength of process the inverse of the strength of the technology.  Here are the key points from today’s trial, and I’d like your suggestions on which one you’d pick.

• Will 1: Ink Signature: happened a long time ago, seems to be in order but there are no surviving attesters to the signature. Gives the entire estate to his wife, and if she predeceases him, his son.  As of today, the wife did predecease him, and his son has become estranged, will #2 being part of the reason.
• Will 2: Electronic Signature: signature is just a hash of the user name and the document being signed.  Gives 1/2 the estate to Stanford University, and the other 1/2 to his son.  The signature was not attested to by any other individuals.  There are no security controls over the log files and no way to prevent modification. However, everything seems to be in order with the signature.
• Will 3: Digital Signature: signature uses the internal PKI of a legal firm which stores private keys on USB memory sticks (not cryptographic devices). A paralegal of the firm who helped create the PKI process is the sole beneficiary.  The signature was counter-signed by two other individuals.  The paralegal (“Bubbles”) administers the PKI system and theoretically could have recreated signatures or digital IDs.

So, if you had to vote for one of these as a juror, which one would you choose?  Personally? I think all 3 are terrible and I fear the entire estate may need to go to probate.  Let us know what you would choose as a juror in the comments.

• Automation of compliance processes
• More regulation en route
• FISMA compliance reform
• More enforcement for noncompliance
• Federal data breach and privacy laws emerge
• Cloud computing complicates compliance
• SOX compliance for small companies
• Migration to risk management

I was quoted in a couple parts of the article with my visions of the future related to FISMA and risk management. It’s worth a read and a comment if you think they missed anything, or if my predictions are way off!

http://eprint.iacr.org/2010/006.pdf Is it time to deprecate 1024bit RSA for, say, 1276bit? (2048 has perf issues.)

The link Dan provided is a research paper which reports the successful factorization of the 768-bit number from the original 2001 RSA challenge. I responded to him that NIST had already deprecated the use of 1024-bit RSA in the government, and it was time for industry to follow suit. Since I posted that, I’ve been surprised that a number of people don’t understand the upcoming changes in key lengths and algorithm strengths that have been mandated by NIST. So, this post offers some information about why I can confidently say the U.S. government has deprecated certain algorithms and key lengths.

What is being deprecated?

• Hashing: 160-bit SHA-1 (note: MD4/MD5 was never an “acceptable algorithm” to the government, and should already be deprecated)
• Signatures: 1024-bit DSA, 1024-bit RSA, 160-bit ECDSA
• Encryption: 80/112-bit 2TDEA (two key triple DES)

When are they deprecated?

• Hashing: for all hashes generated after 12/31/2010
• Signatures: for all signatures generated after 12/31/2010
• Encryption: for any information that needs to remain confidential after 12/31/2010

Where does it say they are deprecated?
While a little more complicated, there is a direct chain of requirements and documents which point to this. The government has unfortunately not made this as obvious and direct as it should be in order to get the maximum buy-in and cooperation from industry. This post is my attempt to help put the pieces together.

• FIPS 200, Minimum Security Requirements for Federal Information and Information Systems requires “Federal agencies must meet the minimum security requirements as defined herein through the use of the security controls in accordance with NIST Special Publication 800-53, Recommended Security Controls for Federal Information Systems, as amended.”
• NIST Special Publication 800-53, Recommended Security Controls for Federal Information Systems, indicates that information systems which need to protect information using cryptography must “produce, control, and distribute symmetric cryptographic keys using [Selection: NIST-approved, NSA-approved] key management technology and processes” and references NIST Special Publication 800-57.
• Section 5.6 of NIST Special Publication 800-57 Part 1, Recommendation for Key Management contains Table 4 indicating the above deprecations I list.

So, here’s the bottom line: 1024-bit algorithms and SHA-1 shouldn’t be used after the end of this year. The government has mandated it, and industry should follow along. It is time — perhaps well past time — to start testing your cryptographic systems, applications, and tools with 2048-bit keys and SHA-2.