Network Security vs Convenience: A War of Perspective

The network was never secure, or at least not in the way we think of as “secure” today.

The TCP/IP protocols that we use for network transport evolved in a different time for the closed ARPANET network. Dedicated circuits between trusted organizations were the standard means of communication. Presumably trustworthy people were the only ones with access to these circuits. Users were all military personnel or contracted researchers, not bad people — or so the thinking at the time went.

A Question of Trust

In 1985, TCP/IP went semi-public when it found a new home on the NSFNET. This created the foundation upon which the Internet that we know today was built. The network’s user base had expanded from vetted individuals and organizations to educators, students and eventually the public at large. Perhaps trust could never reallybe assumed even in the confines of the ARPANET, but it became a complete myth when things went public.

World Wide Web

The Internet could never be described as “convenient” until Sir Tim Berners-Lee presented the world with the first World Wide Web system in 1989. Though clunky at first, this was the advent of an internet that could be consumed by the average person.

Commercial Interests

Still, it wouldn’t be until 1994 that Netscape Communications would develop the SSL protocol. This development would allow the web to become the basis for an exponential growth of the commercial Internet over the next 30 years.

In 1995, the first IPSec RFC 1825 would be published. This provided the framework for point-to-point encryption of TCP/IP traffic that we still use today.

Security and encryption at the network level really only became a consideration when commercial use of the public internet began. Until money enters the picture, security and privacy aren’t part of the core thinking.

Network Security as an Afterthought

The preceding history lesson wasn’t meant to be so much of this week’s post, but it is important to illustrate that network security has been an afterthought. We have always thought in terms of expedience and what couldbe done rather than how best to do it.

When security mechanisms are an add-on, there are a lot of hacks involved in implementing them. We’ve had to make assumptions about how applications behave to properly identify them and ensure that they’re what they appear to be. We’ve had to make firewalls smart enough to make allowances for applications (SIP, FTP, etc.) that don’t fit those assumptions.

When we add application-level encryption to the mix, we have to defeat the very mechanism that secures the data in order to ensure that it’s not a threat to our organization — and new mechanisms (TLS 1.3) that are coming won’t make it transparent for us to do that either.

We All Want Convenience

We can’t really criticize the network users for wanting convenience. After all, they’ve had it from the beginning. It’s a lot easier to frame restrictions from the starting point and set expectations early than it is to start telling people that they can’t do something that they were able to do before. This is especially true if it’s only because we didn’t think about the problem until now.

On the other hand, we need to educate our users a bit. When we’re draconian with our security policies, it’s never because we don’t want them to have easy access. We really dowant them to have easy access. If they have seamless connectivity to the things they need, then they don’t have concerns to address. Our time is better spent looking at the bigger picture rather than figuring out the exceptions.

The Whisper in the Wires

Unfortunately, the exceptions are often the greater part of the job. It’s a lot easier for us to create general rules that get in the way than it is to build a framework that doesn’t.

I’m becoming more confident that we’re reaching a point where security is more integrated into our networks. I’m seeing a point where we don’t have to sacrifice ease of access for our users to keep things simple and keep our own precarious sanity at the same time.

Until then, we need to keep asking ourselves if our attempts to balance security and convenience is really an effort to create a trade-off between our customers’ convenience and our own. If we keep asking ourselves this, we maintain a vested interest in making it seamless for everyone.

Originally published on the Aruba Blogs site.