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.

I received an email the other day supposedly sponsored by a reputable programmer-related site. What it entailed was signing up for a big vendor’s developer program. If I did so, they would send me a $15 gift certificate to one of the major online retailers. I’m trying to keep all parties in this matter anonymous simply because I do not want to promote anything involved in this so-called promotion, and the actual parties involved are irrelevant. The email went something like this:

 

Happy Holidays Developers!

Get a $15 [online retailer] Gift Certificate by joining the [vendor] Developer Program (no charge!)

Thanks to your [programmer site] participation, here’s all you have to do!

1. Visit The [hyperlink to vendor site] and register at no cost!

2. [vendor] will send you a validation email: confirm your registration following the URL provided in the email which will prompt you to choose a password

3. Once you have chosen a password, [vendor] will then send you a password reset email: forward the password reset email and the sign up email address used to [promotional site email]

4. Once verified on our end, a gift certificate will be sent to you promptly after the program ends!

Hurry! This is limited to the first 600 respondents, one per person.

For full terms and conditions please visit [marketing link to promotional site]

Step 3 is the one that caught my eye here. You want me to forward you an email sent to me that allows me to reset my password? By doing this I would essentially be sending the promoter an email that contained a link with an embedded token allowing them to authenticate as myself and then change my password, essentially gaining access to my account at this vendor site. Mind you, this isn’t exactly a critical account. But still these are very poor security practices.

So, what’s to be learned from this? Pay attention to what’s being asked of you. If it seems slightly out of the ordinary, it probably is. Inboxes are being filled with more and more spam these days, some make it through, and some even seem legitimate. It’s up to the users to educate themselves on how to detect and avoid these types of situations. In closing, I’ll leave you with a list of things you can do to help protect yourself.

• If it seems too good to be true, it probably is. So use common sense people!
• Do not click on links in emails – period! Just because it says it’s a link to SiteA doesn’t mean it’s actually going there.
• Enable spam controls on your email client – if you’re using Outlook, Thunderbird, or even Gmail’s web interface – they are all pretty good at detecting what may or may not be spam.
• Use multiple emails or use gmail’s ‘+’ email features or mailnull to help sort out those mailing list emails and let you know which emails are being distributed to others.
• Do not load images by default or at all.
• Do not enable scripting at all!

These are just the tip of the iceberg, but you get the idea. Help protect yourself and you’ll be helping to protect all of us.

In a previous job, I was charged with creating the security documentation for a particular government system, including the disaster recovery plan. That plan necessarily had to include the power requirements for the system. However, with a certain amount of digging, I discovered that by the standards to which I would be held, the simple fact that the servers used either 110V or 220V power was considered “secure unclassified information” and my report would require rather cumbersome treatment. Mind, what put it over the top was not that the servers required 110V, or that the servers required 220V, but simply that the servers might require one or the other. Or, in other words, that the servers required electricity in the same fashion as every other standard server. The bleedingly, patently, absurdly obvious. But that fact was somehow important for security.

There is a certain tendency, with respect to security, to classify, render confidential, or otherwise obscure every piece of information. I cannot count how many times I have heard “we can’t tell you what kind of encryption we use – that would make it insecure!” or some other variant. Indeed, there is a certain value to hiding some seemingly obvious pieces of information – the number of servers, the ports being used, the location of a datacenter in a building. These are not without purpose. There is no sense in making an intruder’s job any easier, and great value in making it as trudgingly difficult and annoying for them as possible.

But this must be tempered with a modicum of sense. In risk assessment terms, this means examining a piece of information and determining what level of risk it exposes. There is no sense in restricting the fact that servers run off of electricity; an intruder knows that – it’s not something that takes much knowledge to figure out. There’s no sense in hiding the fact that a base which is in contact with the local population can see the mountains – the insurgents know that. These are obvious things.

And there’s an important psychological component there. By trying to secure patently obvious things, security by obscurity (already a bad idea) becomes security of absurdity. The very concept of security becomes eroded. Yes, it’s easier to treat all information as secure, but the end users won’t view it that way. What they’ll see – correctly – is a security posture which has gone amok and which is not connected to the reality of their work. And they’ll start ignoring it because it’s ridiculous. And then they’ll be ignoring actually sensible security; they’ve lost confidence in the directives and the purpose behind them. And then you have a problem.

The point is to maintain a real connection with the people who have to implement security directives. As I’ve said before, their job is not to keep your infrastructure secure – their job is, well, their job. To keep people following secure processes, they have to be invested. They have to be able to understand why they’re doing these things. You have to acknowledge that they know the mountains are there, and work within that reality.

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.

This facsimile, which may contain confidential or legally privileged information, is intended for the use of the individual to whom it is addressed only. If you are not the intended recipient (or authorized delegate for the recipient) of this message, please telephone the number listed above to advise us, so that we can arrange for its proper destruction and resend it to the correct recipient. Thank you.

It probably goes without saying that there isn’t a “Katie” working here at Gemini (yet). So of course we called the number to let them know we had received this fax in error. It took my office manager over 30 minutes on the phone to get through to the appropriate person to ensure that it was understood that the information went to the wrong fax number. We followed their instructions explicitly, but nobody at the bank seemed to know what to do. Ultimately it wasted our time.

What was in the fax? The materials attached were an absolute treasure trove of information. Names, addresses, phone numbers, birth dates, social security numbers, drivers license numbers… and that was just on the first page. A copy of two driver’s licenses. A copy of two credit cards. A letter of incorporation, a federal EIN, and copies of two credit reports.

This is more than enough information to steal the identity of two individuals and one business. And the terrifying part of it is that nobody would have been the wiser if we didn’t take the time to phone the bank to let them know we had received the information in error.

Which brings up an interesting question. Should we have called the bank? Sure, I feel bad for the individuals and the business who are having their most private information sent via fax. Their information couldn’t be in better hands though – we know better than to do anything with this information, and we securely shredded it. On the other hand, because we called them the bank now has a record that they accidentally sent us this information. If these individuals suffer identity theft, wouldn’t they immediately consider us a suspect?

In these days of heightened concern about identity theft, why are banks still using insecure transport mechanisms such as faxes without even bothering to call the recipients to ensure successful delivery?

You don’t know me.  I’m nobody.  My name is Steve.  I came across a database dump from Gawker.com earlier this evening.  It’s making its rounds around the internet.  Besides just the code dump from gawker.com among other sites, it also contains email addresses and passwords for over 1.3 million accounts.  I’m sending this email to the 200,000 or so people who’s passwords were included, in plain text, in this archive.  I have your password.  However, I have 0 interest in it.  Obviously i’m anonymous so how can you trust me – you can’t.  But trust me, if I had interest in your password, I wouldn’t be emailing you saying I have it. That’s just dumb.  The reason I’m telling you this is because people all over the world, who aren’t like me, who won’t notify you, have it.  They will use and abuse it.  Change your gawker.com credentials. Now.  MORE IMPORTANTLY, change passwords on other sites you visit that use the same one as your gawker.com/lifehacker.com/gizmodo.com login.

Well, it was believable enough… then, I read an article on Forbes and knew it wasn’t a scam. Argh. To their credit, Gawker has some informative posts on their breach and how to audit and update passwords.

As background: I use a password manager to manage my passwords, and it helps me use secure passwords wherever possible. However, I have a number of passwords which predate my use of a password manager, and for many sites I used the same password. Yes, it’s a bad security practice that we’ve talked about before, and even XKCD has weighed in.  The use of this same password didn’t bother me – it was my password for using on sites that I considered “low impact”. In other words, I didn’t feel like it was a big deal if that password was compromised.

Receiving that email, along with a notification from Google that my account had been locked out, was a wakeup call. Suddenly, it became a big deal to me.

So, I spent this evening going through my password manager’s records. I have 507 saved passwords.  I had nearly 150 with the same password.  I changed every one of them to a randomly generated password.  It took me over three hours to go through that process.  A tremendous hassle. Let me suggest from experience: change those passwords you use on many sites.  If you try to do them all at the same time, it will be a tiring and painful process.

When we perform assessments, we often ask our customers about whether they have a configuration management database (CMDB) or something similar.  While CMDB systems may be useful for performing a physical inventory of your systems, that isn’t the real benefit. The real power of a CMDB comes in being able to track the current configuration, status, health, usage, and ownership of every system in the organization.  Let’s say a new patch is released; an up-to-date CMDB can help you understand what systems the patch applies to, whether they need to be patched and/or need prerequisite requirements fulfilled, what applications should be tested before and after the patch, and who the administrator(s) and owner(s) of the system are.

In this particular case, while there is a CMDB, it doesn’t do a good job of tracking the administrators and owners of their systems.  We are experiencing a huge gap in responsibility management.  While we may know of a system which needs maintenance, we don’t know who is responsible for its maintenance, and who is responsible for the information and applications which may be affected by the maintenance on that system.  In this organization, they are typically different people from different parts of the organization, who may not have even met.

Without understanding who is responsible for the system, the applications running on it, and the information stored within it, you are setting yourself up for problems. Well, you’re at least setting yourself up for many frantic emails and phone calls as deadlines draw near.

Robert Graham decided to address this topic and to do so he wanted to take some photos of his TSA checkpoint for his blog.  Photography is, by the way, completely allowable under TSA regulations. Unfortunately, due to the fear and concern raised by potential protesters and this opt-out day brouhaha, the TSA employees overreacted and detained Mr. Graham for 30 minutes trying to decide what to do with him.

Many folks will point to quotes from the interaction such as “Not all parts of the government are accountable to the public, especially the TSA” and think that the TSA is out to get us all, strip all our liberties and freedoms away and be accountable to nobody.  While this is a good sensationalistic view and will draw a certain type of reader, I don’t think it accurately reflects the real problem here.

The TSA really is just trying to keep us safe when traveling.  That’s their mission. They are trying to do their job.  Mind you, I disagree with many of their methods because they are ineffective and uncreative.  The TSA’s security mechanisms are focused almost entirely on solving the last security breach, not preventing the next one. That’s a topic for another post.

The TSA’s largest failure is one of communication with their officers. The TSA agents at Mr. Graham’s airport should have known that taking photos was allowable.  Matt Kernan’s post about avoiding scanners upon re-entering the US and how many different phone calls and individuals had to be involved demonstrates that communication and cooperation is limited at best.  All this behavior and resulting blog posts and press articles are exactly why a vocal minority of folks is now dead-set against the TSA, organizing protests, and being labeled as domestic extremists.

I hope the TSA learns from these misadventures and improves its communication before everyone’s view of it becomes unfavorable.  As I said before, I believe TSA is really trying to do its job, but to do that job they must walk a fine line.

• Run deeper analytics across physicians groups and facilities, which can include relevant patient data…
• Provide a wide community of health professionals with feedback on the use and effectiveness of protocols…
• Share similar and alternative protocols and their analyses across many medical facilities and individual providers…

Anyone want to guess what’s completely missing from their approach?  You guessed it, any mention of security.  The commonly misunderstood (and frequently misspelled) HIPAA makes it pretty clear that the privacy and confidentiality of personal health information must be protected.  Even without HIPAA, it would just make good sense to be extra careful when sharing information and running data mining and analytics across large sets of health information.

The only mention of keeping information safe in the article is the fact that there is a division of data between the protocol, protocol modifications, and actual patient data – but it is very difficult to draw such bright, clear lines considering medical records and information.  How can you be sure the protocol modification a doctor submits won’t include information on the patient he tried it on?  Without even mentioning or considering the need for the protection of privacy, confidentiality, and data integrity within such a system, the authors of this article have done themselves and the software community a disservice.  Security requirements and threats must be considered at every phase of the life cycle, especially during the architecture phase.  As Kenneth Van Wyck and Mark Graff put it in their book Secure Coding: Principles and Practices,

As a general rule, the hardest vulnerabilities to fix are those resulting from architectural or design decisions. You may be surprised at how many of the vulnerabilities you have heard of we ascribe to errors at “pure think” time.

By developing an 8 page article published in a respected technical journal without any mention of the need for security controls in such a system, the authors of this article have once again helped me with my job security.  It is still difficult for me to foresee the day where security and risk management training programs won’t be necessary, and we won’t need an information security industry.