Safety First: Everyone’s Insecure about Network Security

There’s a good reason banks put money in vaults, museums protect priceless works behind glass, and ancient fortresses are booby-trapped. It’s the same reason some people have safes in their homes and others have panic rooms. When it comes to safeguarding valuables, you can’t be too careful. Because whether your first line of defense is an alarm, armed guards, or a croc-filled moat, one level of security simply isn’t enough. To really keep the riffraff out, you need security within security.

Today, of course, these precautions are equally important for all of our intellectual property and valuable personal information. And yet, while this is so self-evident that there isn’t even any debate on the subject, it’s still too often overlooked by both web users and developers. Earlier in our Fallacies of Distributed Computing series, we discussed the different perspectives on their relevance to web systems. In this installment, we’ll look at the one Fallacy everyone agrees was not made obsolete by web technology: “the network is secure.”

There are almost daily reminders that the network is not secure. Not local networks. Not remote networks. And certainly not those in a web environment. Any component of a distributed system capable of two-way communication can be compromised. Although security has improved dramatically since the dawn of the internet age, attackers are innovating just as rapidly. It’s a perpetual struggle of one-upsmanship that doesn’t promise to end any time soon.

New Relic engineer Brian Doll talked about the risks in his review of the Fallacies last year. Even with one strong layer of security, there are still vulnerabilities for ne’er-do-wells to take advantage of – particularly on open wireless connections like those at airports, coffeehouses, and other public places. For example, many websites with secure login functions still assign cookies that are not encrypted. When exposed on unsecured networks, these security tokens can be hijacked to take over a user’s account. We don’t have to tell you what kind of consequences this can have. The point is, having a few safeguards in place does not eliminate the threat and it doesn’t make a network secure. Given enough time, an enterprising attacker will always find a way.

The case has been made that web technologies give developers the freedom to accept some of the Fallacies as true, and our last post on bandwidth explored the role user expectations play in enabling this mindset. We also touched on it with relation to the fallacy of zero latency. In Tim Bray’s thought-provoking piece on this topic, he asserts that users are generally aware and accepting of latency and bandwidth issues impacting their web experiences. Therefore, it’s not imperative to account for these effects in application development; managing expectations is sufficient. Network security, though, is far too critical for laissez-faire tactics. Users understand quite well that they’re susceptible to attacks, but Bray concedes this knowledge is “not nearly enough” to keep them, and the application, protected.

Application builders are obligated to ensure multiple levels of protection. Relying solely on TLS is inviting trouble. Without question, it’s a great first line of defense. But, as the cookie-jacking example illustrated, it does not guarantee app security. And it obviously doesn’t impart any truth to the Fallacy. You still need to fortify your defenses with a vault, or a moat, or a ferocious pack of hounds. Metaphorically speaking.

This is, of course, not a revolutionary approach. It’s been expressed in more practical terms as “a multi-layered solution that is handled on the network, infrastructure, and application levels.” We couldn’t agree more. But in order to determine the appropriate system of safeguards for an app, developers must first identify its specific vulnerabilities. And that requires effective threat modeling, or what security guru Bruce Schneier calls adopting “the security mindset”.

In other words, you need to imagine yourself as an attacker. What flaws could you easily exploit? How could you take advantage of them for nefarious purposes? Developers who examine apps from the bad guys’ point of view will be much better equipped to accurately pinpoint and remediate security issues before their data is compromised, instead of after the damage is already done.

Occasionally, taking a security mindset will mean making a few tradeoffs to keep your app more secure. You may have to sacrifice some non-essential elements of functionality or restrict access to certain resources. But these are minor concessions to make to keep your data safe, and your users are sure to appreciate the extra precautions. What good is a little more luxury if you end up leaving a window open?

Next week: For apps in the cloud, topology is more fluid and ephemeral than ever. 

leigh@newrelic.com'

Marketing Manager, Content View posts by .

Interested in writing for New Relic Blog? Send us a pitch!