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).

“I shall be telling this with a sigh
Somewhere ages and ages hence:
Two roads diverged in a wood, and I
I took the one less traveled by,
And that has made all the difference.”
(excerpt from “The Road Not Taken” by Robert Frost)

DHS and MITRE had a big announcement yesterday. MITRE has developed a new system for scoring weaknesses in applications, as well as for combining that score with “business value context” to produce a risk estimate. Overall, the work is interesting, though perhaps more from an academic perspective than anything else. What I find interesting is that we’re going back down this road again (“trust” evaluation), which seems like it will inevitably lead to another game-able system.

A brief history… in the 80s the federal government (DOD) published the “Rainbow Series” of security tomes, with a particular focus on the “Orange Book,” which set forth the “Trusted Computer System Evaluation Criteria” (aka TCSEC – I still have a set on my bookshelf, ironically placed next to Covey’s The 7 Habits of Highly Effective People and Scott Adams The Dilbert Principle . The DOD’s Orange Book was used to establish criteria for evaluating the level of “trust” a given system might have, which could then be used to determine whether or not a given system could be used at a given security/clearance level.

The problem with this system is that it created a fracture in product development. Commercial products would be developed, and then someone would say “hey, maybe we should sell this to the federal government!” only to realize that their product didn’t meet the right trust level. So, rather than improve the overall product line, companies would split off a line of development specifically geared toward achieving certification, or they would come up with such ridiculous configurations that no enterprise would ever use it (e.g., Windows NT 4.0 and C2 certification).

This problem became progressively worse in the 90s (and beyond) with a shift away from TCSEC toward, first, SEI’s Capability Maturity Model (CMM), and then using Common Criteria (CC). In both of these cases we again saw gaming of the system. As with previous incarnations, we saw development projects intentionally fractured. In the case of CMM, they were split off into “pilot projects” designed to demonstrate a certain level of capability (usually CMM Level 3), but those changes were rarely integrated into mainstream development efforts. In the case of CC, we would see the same thing happen as happened with TCSEC; configurations would be so constrained that they could only meet a very specific point need with no applicability to the enterprise. Moreover, security was not improved, per se. More often than not, services/capabilities were simply removed or disabled in order to achieve the desired “trust” level.

Which brings us to 2011 and the release of the Common Weakness Scoring System (CWSS) and the Common Weakness Risk Analysis Framework (CWRAF). Given the history of these evaluation and scoring systems, you’ll forgive me if I’m a bit skeptical (or even cynical) about the prospects. I think CWSS itself is a very interesting advancement in terms of metrics and measurements, just as I’ve found the CVE and CWE frameworks to be of interest. It’s still too early to tell exactly how these tools will be used, though CWE (and OVAL – a related project) have been integrated into the “FY 2011 Chief Information Officer Federal Information Security Management Act Reporting Metrics.” CWSS would provide the means for scoring applications, and CWRAF may provide a bridge into the NIST Risk Management Framework (RMF). However, to what end? It’s unclear. Maybe they’ll do it the “right way” this time, but I’ll be surprised if we don’t see vendors attempting to game the system once again.

One thing I fully expect to see is rapid integration of CWSS (and possible CWRAF) into appsec tools and possibly GRC products (I could see CWSS going into appsec tools – both dynamic and static analysis – and CWRAF going into GRC products, with the ability to pull CWSS scores from the other tools). The question will be whether or not these are mainstream products or federal-only versions. We’ve already seen this fracturing with cloud services providers (e.g., Google has a “federal-only” cloud that is domestically based and secured to a different standard, but which is not available to non-federal customers).

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.

But this brings to light an increasing problem: the erosion of standalone functionality. PSN customers have not been able to access online content since April 20th. This is, of course, to be expected – if you shut off the network, the network is not available. Unfortunately, this extends to content which isn’t actually hosted on Sony’s network, since PlayStations use the PSN to connect to outside servers. Still, though, not surprising.

Vexingly, however, a certain amount of offline content has also been rendered unavailable, specifically several Capcom games which apparently need internet connection even for single-player mode. This seems to be an increasing trend in the software industry, in games of course, but in other software as well. Even software which has no need to be online, such as a word processing suite, increasingly needs to authenticate with a server in order to install. In fact, you might have noticed that most builds of MS Windows have just such an authentication requirement. And this is continuing to the next level: the Google CR-48 laptop as almost no functionality without an internet connection. Woe betide the user who truly does not want to ever connect a machine to the Internet!

But why would someone want to keep their computer offline?

Well, security, for one. The “airwall” remains the strongest form of security available; no code can ever bridge the gap of a true lack of connection. This isn’t solely the province of super secret government facilities, after all: medical facilities, industrial applications, and numerous other facilities can achieve higher security by dint of simply not connecting machines to the Internet when it is not needed.

Some may not be able to achieve an Internet connection, either due to cost or lack of infrastructure. As amazing as it may seem in 2011, Internet access is not available everywhere, nor to everyone.

But the most important reason is highlighted by this PSN debacle: why should Internet access be necessary? The Internet is a powerful, pervasive tool – but it’s not the end-all of the computing experience, and even now there’s no reason that a computer should be rendered a paperweight by simple lack of connection.

Most of the features are drawn from the standards found in the Opal Security Subsystem Class (SSC) (pdf). The SSC is, in turn, based on the TCG Storage Architecture Core Specification. TCG is the same company behind the TPM platform standard, which was designed to let a system create and operate a trusted subenvironment from within an untrusted environment. The TPM platform still receives a fair amount of criticism for privacy issues and the potential for abuse.

A similar approach is used for some OPAL-compliant storage devices: dedicated on-board hardware that can handle a range of specialized operations (maintenance, authentication, cryptography) independently. The result is hardware like the MK-61GSYG, which probably meets many storage security requirements right out of the box. Although much can be said of the controversy that can surrounds newer standards, they can certainly provide a welcome stepping stone for innovation.

Even without knowing all of the minute details, there are some important things to take away from this:

• Large pools of consolidated personally identifiable information are huge targets for would-be attackers
• Those you trust with your trusted data might not be as careful with it as you’d like them to be (applies to both customers and companies)

But, although there is much to be said of the risk we all take when we share private data, perhaps the bigger issue is the fact that companies hound you for your personal information in the first place. I can *maybe* understand a bank or financial institution needing to know a reference phone number or an email address to send you account information. But Walgreens, Kroger, Eddie Bauer; do they *really* need my personal contact info?

I once had an airport kiosk salesperson to verbally question whether or not I gave him my real phone number on the questionnaire that I filled out to get a “free” prize. I fraudulently reassured him that the last 4 digits were “3210″, and I half-expected him to whip out his phone and double-check.

But not every company is out to spam you to death. And I’m sure there are many people who don’t mind being marketed to (especially by their favorite brands). But for those of us who are asked to give up our email addy at the checkout counter, what can we do to shield ourselves from the inevitable mishandling of information we might not even want to share?

Far be it from me to suggest that *other* people willingly give out inaccurate information, but I regularly switch my phone number digits around and give out the wrong domain for my email (apologizes to my hotmail address twin). Even without resorting to harmless chicanery, there are things we can do to protect some of our important data. For example, disposable email addresses are great for keeping spam out of your real inbox, and have the added benefit of being valued lower by attackers than, say, a business or government account. After all, who targets mailinator accounts? Or, if you have the technical chops, an option may be to sign up with a call-forwarding service (like Google Voice) in order to cloak your actual phone number.

In other words, consider giving out your personal information on a need-to-know basis. Even then, we may have fewer options when it comes to protecting data a company creates in-house about its own customers, or the details associated with payment card purchases. But then again, that’s why we have standards like HIPAA and PCI-DSS…

The conference opened with a fantastic video called “Giants Among Us” which provided a brief chronicle of the rise of public key cryptography, from Martin Hellman, Whitfield Diffie, and Ralph Merkel, to Ron Rivest, Adi Shamir, and Leonard Adelman. It was well produced and is worth a watch. Note: updated link to HD version.

Art Coviello then came out and started his talk with a brief history of the 20 years of the RSA Conference, which was entertaining in its own right. He brought up classic confrontations, amusing talk titles, and showed the advance in both the number of talks and the amount of marketing over the years. During this session, Art showed a chart which displayed the number of talks about public key infrastructure (PKI) over the years.

Note: it turns out that 2001 really was the “Year of the PKI”, and it’s not always next year. This chart was a bit of an eye-opener, especially for me – a long time PKI evangelist. (No wonder those proposed talks aren’t being accepted!) At the conclusion of this discussion, Art made the following comment:

While smart cards and PKI never achieved the ubiquity we thought, they’ll continue to play a major role in security, especially PKI in cloud computing…

Here is where I definitely need to disagree. There is a difference between ubiquity and commodity. PKI’s ubiquity cannot be measured by the number of product vendors on the show floor, or talks offered at the conference – it can only be measured by the deployment and use of actual X.509 certificates throughout the world.

Some examples: If you have used SSL or TLS, you have used a PKI. If you have used a web service, such as SAML, you have used a PKI. If you have used a virtual private network (VPN) solution, you have used a PKI. If you have used Microsoft Remote Desktop, Active Directory, or any number of other crucial back-end services which use public key cryptography, you have used a PKI.

PKI is ubiquitous. It just isn’t getting in the way as much anymore.

Odds are it won’t. Not in the short term, at any rate. Imagine if the post office announced that they’d run out of street addresses. All of the existing houses would be fine, and still be able to receive mail. New houses wouldn’t get addresses, though, and would be unable to send or receive mail. Running out of IPv4 addresses is like that.

Of course, it’s somewhat more complicated. Whereas you can still build a house without a postal address, still live there, still have people come over – well, imagine if you need an address to access the road. Without an IP address, a computer is cut off from the internet. It can neither send nor receive data; it’s just a standalone device.

But there remain options. Plenty of them, in fact.

For one thing, the sale of the last IPv4 addresses doesn’t mean that there are no addresses to be had. There are still significant swathes of unused IP addresses, mostly in the hands of universities which got some of the original /8 (Class A) network blocks but have no need for the staggering 16 million addresses available to them. Thanks to Classless InterDomain Routing, these blocks can be broken into smaller segments. Now is probably a very good time for such organizations to auction off segments of these address blocks – they’ll fetch a very high price now, but their value will drop rapidly. But for right now, there do remain IP addresses to be had, if the price is right.

Another way to squeeze out even more life from IPv4 is to use Network Address Translation (NAT). NAT allows a computer to be assigned a “local” IP address, and multiple computers with local addresses use a single computer with a public address to talk to the wider world. If IP addresses are like postal addresses, then NAT lets you put people in apartment buildings instead of houses. This means that fewer computers need a public IP address, and as with CIDR, this may open up more addresses.

Both of these methods should be familiar: they’ve been in use for the last decade, keeping IPv4 viable. Which, for good or ill, means even these options are mostly exhausted. The simple fact is, we’re running out of addresses, and we can only avoid that fact for so long.

This means we need to migrate to IPv6. I have some misgivings about IPv6, to be sure, but we definitely need to take that plunge. There simply aren’t any other long-term options on the table; CIDR and NAT are just rearguard actions.

So what’s going to happen?

As should be obvious to anyone who knows corporate America, a large number of companies are going to put off the conversion for as long as possible. This won’t last long, but there’s going to be a big opportunity for people who know IPv6 then. But no few companies will see, or have already seen, the writing on the wall and are making the conversion. This means that some ISPs will be using both IPv6 and IPv4. Others will still be on IPv4 only, and new hosts will use IPv6 only. Problem is, IPv6 addresses aren’t backwards-compatible with IPv4 addresses: there’s no guarantee that hosts on IPv4 will be able to talk to hosts on IPv6, nor vice-versa. There are, of course, workarounds for this. In some cases they will be implemented well, and the transition will be seamless. In other cases, not so much. This means that in the coming year we can expect to see network fragmentation. Unfortunately, there’s relatively little that most organizations other than network and internet service providers can do about that; either it’s being implemented properly, or it isn’t.

What can a typical organization do?

First of all, find out about your ISP’s IPv6 offering. The sooner you’re on IPv6 the better off you are, and the less money you’ll spend on IPv4 technology, acquiring new IPv4 addresses, and the inevitable last-minute IPv6 transition. Also, it seems likely that just as it was with IPv4 there will probably be some significant benefits to being an early adopter to IPv6.

Second, make sure your equipment talks in IPv6. Now is definitely the time to apply those firmware updates and set up the IPv6 stacks your network engineers have had on the back burner. Even if your equipment is supposed to have IPv6 support, get updates anyway – beyond the obvious value in frequent updating, it’s likely that older IPv6 implementations will be rather buggy, and some issues may not become apparent until IPv6 becomes more prevalent – so keep your ear to the ground for that, and especially keep up with your vendor notices.

But! You absolutely must do one last thing: check your IPv6 security. Several companies have already been burned, finding out that while their IPv4 traffic is carefully routed, monitored, and scanned, their IPv6 traffic had no controls. Check your policies, check your gateways, check your routers, and check your firewalls. Make sure that when you do start using IPv6 you use it securely.

Unless you work for a network or internet service provider, there’s only so much you can do about the IPcalypse. But you can be ready for the IPv6 transition, and you really should be. We’ve seen this day coming for years now.

In other words, as technology changes, the vulnerabilities enabled by that technology also change. With the quick rise (and rapid acceptance) of HTML5 as the next generation markup language, we are sure to see some interesting new ways that web apps can be bent and broken or otherwise convinced to do things they were not originally designed or developed to do. Indeed, HTML5 seems to be somewhat of a new frontier when it comes to web security. Like its predecessor, each browser rendering engine has its own way of interpreting and displaying HTML5 data. Developers seeking to fully secure their applications would need to account for users that may have HTML5-enabled browsers. Lack of familiarity on the developer’s part can result in unexpected vulnerabilities that are easily overlooked or difficult to detect.

The HTML5 Security Cheatsheet is a resource that shows some things to watch out for when you’re working with HTML5, and should be useful to both developers and regular users.

Also, it’s important to point out that not all unintended uses of a new technology are malicious in nature. Who knows– maybe some HTML5 hack will push future web innovation to new heights. At the very least, it could add some variety to the global discussion on web application security.