During security assessments, I always make sure they’re performing security testing as part of their development process.

This is why: “Apple security blunder exposes Lion login passwords in clear text”

No need to go into details as to what happened here; it’s well-researched in the linked article. However, this is exactly the scenario that development security testing is meant to avoid. A seemingly innocent patch disables or circumvents an important security feature. The results are predictable.

It could be worse, though. Here’s the worst case: the problem isn’t detected. Because the security was included in the original version, and because nobody checked, it is assumed that the security is in place, and successive updates are made, with the security feature in question not working, but everyone assuming it does. And successive patches are built upon the circumvented security. By the time the bug is discovered, fixing it is a gargantuan task.

So, it’s not that bad. It’s still a major breach, though. So if you ever wonder if that testing is really necessary during development, you can point to this incident and confidently say “Yes.”

I’ve had some interesting experiences with two companies recently that I’d like to share. We all do business with companies online: we buy from them, we schedule appointments, we put in support requests, and so on. Today, I very seldom use the mail, and don’t shop in person very often. How these businesses treat customer security is interesting. Some places are very technically savvy and have robust, secure online transactions. Being realistic, though, I know that my dentist’s office does not employ a full-time sysadmin. They buy an off-the-shelf customer care solution and hire someone to install it on their website. Sometimes that’s good, sometimes that’s bad…

First was with my mechanic. I like my mechanic – they’ve saved me quite a bit in the past. But they’re notoriously bad about answering the phone. However, they are surprisingly up to date for such a shop. They have a website which allows you to schedule your appointments online, no need to call. That’s great!
Necessarily, this means you need to have an account on the website. Okay, this makes sense: they track your name, contact information, kind of car you have, and the car’s maintenance history including mileage. While nothing there is particularly incriminating or dangerous unto itself, it’s not the sort of information I’d like to have broadcast to the world, either. So it’s good that this information is kept in an individual account not available to others.
However, I admit that I couldn’t recall my password for that account. No problem, I put in the username and requested a password reset. The automated tool asked for my email, which I gave, and it sent me a new password.
Do you see the problem? It wasn’t asking me for my email address to confirm that I should be the recipient of that password. It was asking in order to know where to send the new password. There was no confirmation process; it just sent the password to the address I’d provided.
And that’s how I got into someone else’s account. My first clue was that I don’t own a Mitsubishi. No harm done – I didn’t even get the person’s contact information, I simply figured out my correct account name (I was off by one letter) and logged in properly. But that’s no security at all.

On the flip side, I wanted to get support for a piece of electronics I bought recently. I was looking for a driver for it, and couldn’t find anything, so I thought I’d go ahead and contact their support team. In theory this should be a straightforward enough thing. In practice, not so much. You have to open an account with the manufacturer. For which you need to own an actual product. Now, that’s a bit of an issue – what if I was looking at buying a product and wanted to know beforehand if the driver existed? But I already owned this item. So I went to open the account (and set up to handle all the forthcoming spam, I’m sure.) Part of the process involves saying just which device you own. Now, the item I had wasn’t listed. I made the best match, a similar item with a different model number. Shouldn’t make a difference, right?
Oh, but it does. The item I selected is listed, for some reason, as out of warranty. And on that I was frustrated – I cannot make inquiries about an item which is out of warranty.
I’m sure this system reduces needless support requests. In this case it also prevented a real request; I won’t be buying this company’s products in the future.

What can we learn here? Well, two companies, two lessons.

In the first case, make sure your system applies basic security. My mechanic has relatively trivial information on me, sure, but they have some information, and they’re not securing it well enough. The idea of a confirmation before resetting a password has been “best practice” for longer than I can remember. If you’re going to bother having individual user accounts, there’s no excuse to not treat them with at least some security.

In the second case, your security shouldn’t get in the way of your business. Sure it’d be nice to be able to make sure every single contact was authenticated and properly routed, but if you have any reason to deal with the public that’s just not going to happen.

The overall lesson is that even if you’re a small company, your security has to match your needs. An off-the-shelf solution without any thought behind its application won’t do you any good.

A service provider shall not be liable for monetary relief, or, except as provided in subsection (j), for injunctive or other equitable relief, for infringement of copyright by reason of the provider’s transmitting, routing, or providing connections for, material through a system or network controlled or operated by or for the service provider, or by reason of the intermediate and transient storage of that material in the course of such transmitting, routing, or providing connections – 17 USC § 512, from the Cornell University Law School

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.

Suppose you want to send a letter to your brother. And let’s suppose it’s got some, oh, maybe potentially embarrassing financial information – he owes you some money and you’re having trouble paying the bills.

Obviously, that’s not the sort of thing you want to put on a postcard; you’d put that in an envelope. (Your brother is notorious about checking his email).

You want him to know that the letter is actually from you, so you sign it – you have a distinct signature that is very hard to forge. And, on top of that, you want him to know that nobody else read the letter, so you also sign across the fold of the envelope, so it can’t just be put in a new envelope.

So, you’ve done the basic security – it’s authenticated (with your signature), it’s not readable by third parties (because of the envelope) and it’s tamper-evident (because you signed the envelope, too). It’s not the most secure communication possible, but you’ve clearly done due diligence.

So what if I told you people were doing that almost 4000 years ago?

Sealing letters in clay envelopes was standard practice. Sometimes it was used for security; other times, in the case of contracts, the contract was written on the inner tablet and the envelope, and both marked with the personal seals of the signatories, making the text of the contract accessible while still having an unalterable copy in case it came into question.

People have known for millennia that secure communication is crucial to business. We’ve known a need for privacy, authentication, and tamper evidence. These aren’t new ideas at all.
However, we seem to have a hard time applying them to modern technology, sadly. That’s the only reason I can figure out to explain why yesterday I had someone asking me to email a scanned image of a check without any encryption.

A few years back, I was working as a tech writer for a company which made medical software. We were trying to get an important certification that we’d need to sell our product. And a crucial part of that was good documentation: we had to show how it worked, what it did, how it tracked everything, how it was secure, etc. Well, that’s what you have a tech writer for, so all is good.

It’s important to know, I didn’t have any existing documentation to work with. There was a wiki which had the developers’ notes in it, but that’s it. Nothing by way of formal hand-it-to-an-outside-entity documentation.

Okay, that’s not too abnormal; tech writing is expensive, and many companies don’t bother with it until an auditor is breathing down their neck. Hardly ideal, but to be expected, and I did have time. So, I set to it.

Since there wasn’t any existing documentation to re-do, I based my organization around the expectations set by the certification. And, a good week before the deadline, I turned in the completed documentation, all 100-something pages of it.

And that’s when disaster struck. The auditors decided they wanted the documentation in a completely different format – they weren’t going to read our documentation, no. They wanted us to fill out a questionnaire. The questionnaire was very comprehensive, encompassing exactly as much material as my documentation covered. And I had less than a week to complete it. I told my boss “No problem.” And I gave him the completed questionnaire in 3 days.

Read the rest of this entry »

I recently had the pleasure of performing one of the best security assessments I’ve ever done. It was great: I didn’t find any gaps. Not a one.

To some people, it might come as a surprise that I’d consider that a good assessment. And I’ll admit, it made me a bit suspicious. Nothing? Seriously? Well, I had to look into why, and I’ll get to that in a moment. But let’s cover something else first.

I’ve been on both sides of the table for security audits. Being audited is Not Fun. You have someone coming in, looking over all your processes, and it’s up to you to prove that you’re doing what you’re actually doing, often for reasons that seem terribly arcane or pointless. And the management directive is almost always “make sure we pass this” which is assuredly not the same thing as “make sure we are actually secure.” It’s a very adversarial relationship.

As the auditor, you’re always looking for the places where they’re trying to hoodwink you, trying to gloss over something, or just outright lying. You’re always suspicious. If you’re not when you start, you will be. Because the people you’re auditing don’t want to be secure – they want to pass the audit. Which is understandable – failure can mean losing their license to operate, losing a major contract (clearly, one that’s big enough to bring in an auditor!) and in extreme cases bringing down the company.

It doesn’t have to be that way. As a security analyst, my goal isn’t to find problems. It’s to locate any security gaps that may exist, and where appropriate offer remediation steps.

Aren’t those the same thing, though?

Well, no. As the old saying goes, “seek and ye shall find.” I’ve met many auditors who took delight in writing overwhelmingly negative, scathing reports. They’d pounce on any excuse to fail a control. Which sounds like they’d at least be informative, but realistically the resultant reports aren’t all that useful – they don’t give much true concept of the security posture of an organization, because they’re invariably negative.

The problem is that nobody is really looking at the true purpose of security audits and assessments. Organizations being audited just want to get through the audit. The auditors are trying to “catch” the organization. But security audits aren’t high school tests or witch hunts. The end goal isn’t the report. The end goal is an organization, system, or project with a good security posture and no known gaps.

That’s what made the assessment I did last week so unusual. You see, they were given the standards in advance. They knew exactly what I was looking for – and so they went out of their way to make sure I’d find it. They had purpose-built the space specifically to meet the standards. There was no gotcha, no hidden agenda, no posturing or hiding. I knew they’d set things up to make sure my assessment would be good – and that’s great. It’s the way it should be, and the result was a completely clean assessment.

Of course, there is a risk. Organizations may know what the standards are and then try to pretend to follow the standard, or look for loopholes. That’s where the auditor really comes into play – to recognize when an organization is trying to follow the letter but not the spirit of the standard. But the most important thing to remember, for both the auditor and the auditee, is that the goal ultimately, is security – it’s not to play gotcha, it’s not to hide gaps. It’s to find and close the gaps that exist.

So, SOPA is the news of the day, in terms of the Internet and security; it has been for well over a month now.
In case you’re not familiar, SOPA is the Stop Online Piracy Act. It will “authorize the U.S. Department of Justice to seek court orders against websites outside U.S. jurisdiction accused of infringing on copyrights, or of enabling or facilitating copyright infringement.”

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’ve mentioned Whole Disk Encryption in the past. There are a number of products, both free and paid, which will allow you to encrypt your entire hard disk, or the hard disks on your servers.

In a recent study whole disk encryption (referred to as FDE in the study) has been shown to significantly hamper investigation. Basically, the encryption is too good. Even with techniques like cryogenic RAM freezing it’s often unlikely that the encryption can be bypassed.

But there’s a huge, gaping hole in such protection: you can’t USE encrypted data. For it to be accessible and usable, it has to be decrypted. (In other news, it is not possible to open properly locked doors, nor to pass through walls.)

And for the last few years, there has been a product out there which makes it possible to remove a computer without powering it down. This product is called HotPlug and it can be used, in conjunction with a portable power source, to remove a machine without disrupting its functioning. Be sure to watch the video.

Of course, lawful search and seizures aren’t the problem per se. But this does show that WDE isn’t a panacea. As with any security, it needs to be backed up by other defenses as well. Physical control trumps software security anyway. Which means, unremarkably, that even the newest technology doesn’t necessarily provide more security than a good padlock.

I am currently experimenting with my smartphone, to see if its Mobile Access Point Functionality allows it to function as a wireless router independent of Internet connection. In theory, it should – it is capable of providing internet access to four attached devices, and that suggests that it should have router functionality, meaning that the attached devices should be able to talk with each other, rather than simply to the Internet. In practice, I know that sometimes seemingly important parts of networking implementations are, well, not implemented. The most egregious example, in my experience, was a commercial-grade firewall which was unable to pass UDP traffic under certain circumstances.

The lesson I learned then was that just because the hardware and software claim to be able to perform a function, it isn’t enough to assume that they actually work. Never assume – always test. Sometimes ports will be blocked; traffic won’t be passed, or there will be an absurd traffic shaping scheme that makes your particular application untenable. Sometimes these problems are resolvable, and sometimes they aren’t. This can be terribly vexing when trying to, for example, set up a VoIP connection.

But from a security standpoint, sometimes the reverse is even worse. What if the connection works, but the security doesn’t? This isn’t hypothetical. There have already been many cases of firewalls which implemented an IPv6 stack but didn’t apply the firewall rules to that stack – or expected a separate set of rules which had never been set up. And, of course, there’s always the risk of a lazy predecessor who, in the rush to Make Things Work set allow *.* in the rules – would you notice? After all, nothing would stop working. Well, until your systems got infected.

Fortunately, there’s a host of tools to save you from this problem. Your first is simple Defense In Depth – relying not just on one company-wide firewall but also on an IDS, software firewalls, and anti-malware software, so one foolish implementation doesn’t leave you wide open. Second, there are scanning and simulation tools – mostly port mapping, but a few others besides – which will tell you what ports are open and what services are actually available. And if that’s not enough, a proper 3rd-party penetration test will probably find anything. But your best line of defense is in your own head – knowing how your network setup should work, being able to read the configurations you have, and knowing if the actual results match up.

A few years ago, a friend of mine served in Afghanistan. It was, as he described it, a long and mostly dull duty. When not busy with soldierly duties, he wrote on his blog and took pictures, often of the rather picturesque – to those who didn’t have to traverse it – scenery. At one point, however, he was informed that these landscape pictures were, in fact, an operational security violation. Not the ones taken in-camp, but the gorgeous panoramas of Afghani mountains and valleys. The theory was that, using those pictures, insurgents could find their position. My friend’s response was succinct: “I think they already know about the mountains, sir.”

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.