The rules for playing “protect the president” are simple: the “bodyguard” isolates the “president” and protects him from being hit by the “attackers.” These rules are logical and follow common sense.

Now, imagine if instead the method the Secret Service used for protecting presidents were:

Step 1: Continually publish the agenda for the president – where he will be and when.

Step 2: At all locations and at all times, allow apparent citizens to freely walk up to the president and shake his hand.

Step 3: Ask citizen for identification.

Step 4: Perform a background check on citizen.

Step 5: Pat down citizen to check for weapons.

Could you imagine what the results would be? We’d need a new president every week. It’s a horrible security model because, as you can see, the sequence of protections is completely backward. But, this is how TCP/IP works in both the Internet and in every corporate network!

Step 1: Announce address of critical servers in DNS.

Step 2: Configure servers to “listen all” in case anyone wants to connect.

Step 3: Respond to all connection requests coming in and “handshake” with all requesters.

Step 4: Request credentials.

Step 5: Evaluate credentials and decide if this is an authorized and authenticated user that you want to interact further with.

This model promotes easy connectivity but it is about as backward as you can get. The result: lots of compromised servers, and lots of OPEX and CAPEX spent on often doomed attempts to achieve security after the fact.

Luckily for us, the Secret Service doesn’t actually implement the sequence discussed above.  Instead, they significantly pre-vet all people who come within a certain distance of the president, for example:

Step 1: Make an appointment to see the president.

Step 2: Secret Service performs a thorough background check on you.

Step 3: You are patted down, x-rayed and sniffed by dogs

Step 4: Secret Service monitors all your interactions with the president closely—just to make sure.  Don’t make any sudden and unexpected moves!

Similarly, what the world needs to improve in network security is to reverse the natural sequence of TCP/IP.  At the company I run, Vidder, Inc., we are working on developing and promoting Software Defined Perimeter(SDP) as a new model for access control using an architecture that allows enterprises to presume zero-trust about devices, software, and users. This zero-trust architecture gives zero visibility and zero access to the protected high value assets—until trust is verified.

Step 1: Isolate critical application servers, executing a “Deny All” initial connectivity state after eliminating unnecessary DNS entries.

Step 2: Executes a system to assess the device, user, and software trust of the end user

Step 3: Dynamically configures visibility and connectivity between authorized users and services only after being satisfied on all dimensions defined by application-specific policies.

Step 4: Monitors these end users to make sure they don’t make any “sudden and unexpected moves.”

You can think of SDP as being the Secret Service of TCP/IP networks. The software doesn’t actually have ear buds, lapel microphones, short haircuts, thick necks, automatic weapons and drug sniffing dogs.  But it is the coded equivalent.

SDP’s Isolate/Verify/Connect sequence for TCP/IP addresses the credential theft, server/application vulnerability exploits, denial-of-service, connection hijacking, and man-in-the-middle attacks that are widespread in networks of all types today.  Not all of your security needs to go away, but by starting withtrusted connectivity rather than today’s wide-open networking, you will have a much more solid starting point for security that can then be enhanced by a smaller number of other critical controls.

When it comes to protecting the president, or your high value assets—it’s not a game.