(Did you miss Part 1 and/or 2? Click here for part 1 and here for part 2 to catch up!)

I apologize for this, but I have to jump back to the beginning again. You see, the Internet was designed during the cold war, and a prime driver was the ability to sustain communication in the event of a nuclear attack. Back then, communication was usually point-to-point. DARPA and many smart people gave us “packet-switched networks.” It meant that a piece of data could flow through different paths and reassemble on the receiving side. This meant if communication hubs were taken out of service between you and where you were trying to communicate, due to, say, a nuclear bomb being dropped, your packets could now travel a different route and your Twitter post about the latte you purchased this morning would stick.

The lesson here is age-old; bolting on security after the fact is always more costly, time-consuming and less effective than baking it in from the start. The first email servers on the Internet were open relay by design. That meant anyone could send email through your email server to someone else. After all, the idea was sustained communications, so if my email server went down, why not use one of the other available email servers?

Unfortunately, as with many well-intentioned plans, it fails to account for bad people. Soon spam became a well-known term to define something other than the delicious food of previous association. Domain Name Services (which translates the web sites we type into IP addresses) is not secure. It has suffered from numerous attacks. The weakness of this core protocol has been known for a very long time and a secure DNS (DNSSEC) was proposed in 2005 via RFC 4033. You can go here to see how that has been going.

In general, the US Root DNS servers were operational in 2010. DNSSEC does not in any way totally fix DNS, as in recent months there has been a rash of DNS Amplification Denial of Services attacks. DNS is just one small area of vulnerability; the list of protocol weaknesses and associated attack vectors is legion.

In short, what we have put in place are insecure computing devices connected together using insecure protocols over a fabric connected to support some of our most critical dependencies and let anyone in the world – good or bad – have access to them.

I remember watching a video with one of the engineers that worked on the initial Internet design and protocols. He stated that, “If you would have told us that we would be putting critical infrastructure on a public network, we would have just laughed – that will never happen.” There was a completely different mindset back in those days. Business standards existed beyond the “want of the moment.” Thought was given to business risk, mostly driven top-down. Today, one could argue business risk is driven bottom-up and in the Information Security world, I would posit that 80-90% of InfoSec programs are driven in exactly that same direction.