Network security is not about “magic boxes”

security

In the security world, there’s a rather unfortunate asymmetry between those of us who seek to defend systems, and those who seek to attack them. The defenders need to find every potential weakness, every point of entry, in order to defend it. The attackers need only find one.

It’s an important principle, and one that is, alas, all too often forgotten, particularly in the face of shiny technology and slick pitches from security companies. “Buy our magical box,” they say, “and you’ll never get hacked.” The company is reputable, and the magic box does what it says it will do. With the box in place, you relax: you’re safe now. And then you accidentally leave your laptop on the train home. You know, the laptop with all those reports and that copy of the customer database on it?

There are no silver bullet solutions to security: It’s an attitude, a methodology, not a product. You don’t “get security” in the way that you’d “get a faster server” – you get secure, more like the way you’d get organized or get efficient. It’s a cross-cutting, pervasive concern.

It can’t be outsourced or delegated; you can’t just leave it to ‘the security department’ to take care of. (That’s not to say that you can’t outsource or delegate the task of designing the security policy to somebody else, but you should expect them to come back with policies that affect everybody and everything within the organization, from CEOs to cleaning contractors).

Microsoft is an interesting example of the difference this approach can make. Back in 2002, a substantial problem that Microsoft faced was a reputation for security problems: exploits, viruses, malware, and so on.

It’s not like they weren’t investing in security: there were teams dedicated to implementing security features in Windows XP, ranging from Trusted Computing Platform support to the Windows Firewall. But these weren’t enough. In the first year of Windows XP’s public release, 119 different security vulnerabilities were found. Craig Mundie, then CTO of the company, started a research program to find ways to improve the situation.

Unsurprisingly, the answer they found was that they needed to change their processes: they had to become secure, instead of employing some people to ‘do the security bits.’ Their new process was formalized in 2004 as the “Security Development Lifecycle,” extending every phase of the traditional Software Development Lifecycle with the appropriate security concerns.

Ensuring that developers are informed about security basics and recent trends in security and privacy is now part of the standard developer training; security and privacy risks form part of the product requirements; attack surface analysis is performed in the design phase, and so on. The extended lifecycle is mandatory process for all products that deal with sensitive data or carry meaningful business risk.

It’s worked, too, to a large extent: Compared to Windows XP’s first year vulnerability count of 119, Windows Vista had 66 (and I count only 26 in Windows 7’s first year). More striking is the change to other products like SQL Server; SQL Server 2000, developed under the old process, had 34 vulnerabilities in its first three years, while SQL Server 2005 used the new process and had only 3.

Security is something that needs to be continually and thoroughly considered. By far the best approach is to train all your staff to do so; and if you simply must outsource the expertise, then someone from that security team should be present at every non-trivial design or decision-making meeting. At least that way you stand a chance of shipping a secure product – though it won’t help you with operational security.

It’s the little things that are the killers: letting a visitor connect his laptop to the company network, neither of you knowing that his machine is actually virus-infected. Transferring sensitive data from one machine to another using an USB key that you just leave lying around afterwards. Handing a hard drive full of confidential data over to an infrastructure support staffer, without thinking about whether it’s acceptable or legal for him to be in possession of that data. (That last one is a particularly bizarre kind of doublethink, and is worryingly common).

There are a huge number of security products out there. Many different people will tell you that their magic box is better than all the other magic boxes, that it’s faster or cheaper or has more magic in it. There’s a lot to learn about them all, and while they’re often very useful, none of them will completely solve your problem. If, instead, you focus your attention not on the magic boxes that “do security,” but on the principles and practices of how to be secure, it’s a lot simpler, a lot cheaper, and a lot more effective.

Richard Fine is a Technical Writer for Grid-Tools. He graduated from Oxford University in 2009 with a Master's Degree in Computer Science. A programmer since the age of 4, he has extensive experience working with real-time interactive simulation systems, as well as a range of Web technologies. He has received the MVP Award from Microsoft 5 times for his contributions to online communities and IT education.