Embedded Connectivity Solves the Right (and Left) Problem

In Stephen Bellovin’s book, Thinking Security: Stopping Hackers Next Year (2015), he wrote:

“Companies spend a lot on security, but we read about massive computer-related attacks. Something is clearly wrong.

The root of the problem is twofold: We protect (and spend money protecting) the wrong things, and hurt productivity in the process.

InfoSec hurts productivity in the organization it’s supposed to protect.”

Belovin explained what he meant by “wrong things.” He noted that security measures tend to survive even when the threat they were intended to address has subsided in the past. These security costs have only increased since 2015 when the book was published, and today represent a trillion-dollar burden on the global economy despite the emergence of integrated software delivery security models such as DevSecOps, Turn Left and Turn Right.

2021 IBM Security Threat Intelligence Index Reports indicate that Attack Vector 1 was a monitoring technique known as scavenging and exploits. Defenders face asymmetric engagement with such threats on the network. A successful attacker needs to exploit only one vulnerability while defenders must secure 100% of the network entry ports 100% of the time. The fundamental problem is the anonymous and unauthorized nature of the Internet. This makes it useful and easy to abuse. Anyone anywhere can conduct reconnaissance and launch attacks on a large scale with little cost or risk. How can we make it difficult or expensive to successfully scan and attack our apps? What if we could reliably defend against an entire class of active scanning methods?

There are no secure networks, only isolated networks. Going back to first principles, the purpose of a network is to transmit data packets from the sender’s address to the recipient’s address. The network has no internal ability to identify any party or discern the legality of any activity. Active scanning techniques identify potential targets that are then scanned by scripts that may be malicious, stealthy, or both. We can simply deny all incoming network traffic with a firewall, but the application servers must be constantly accessible in order to listen for incoming requests. Any interruption in availability causes errors such as “connection denied” and “service not available” to the user.

This necessary network exposure leaves the upper layers of the network and the application server itself vulnerable to hacking and denial of service attacks. “Private” enterprise applications are similarly exposed to the vulnerable group which are the devices of VPN users, and therefore they are by no means immune to this problem. This presents the problem of auto-distinguishing legitimate incoming connections, consistently, forever. Are we trying to solve the wrong problem?

Ideally, we will identify the sender before they connect to the application server. This way, we can see if they have permission to connect at all. This is something we simply cannot do when the sender is known only by the network address. We can’t request credentials because that introduces another application layer with all the same issues. This is exactly why VPNs don’t go far enough: a superficial barrier is created for users that prevents the application server from checking permission even after monitoring and subsequent attacks have occurred.

The connection included as the code solves the correct problem. This represents a shift in thinking about the relationship between the application and the network. Now, the app brings its own point-to-point overlay with an identity that can be verified on both ends. This has significant implications for application security that can be summarized in terms of moving security to the left in the development timeline and shifting it to the right in the post-deployment lifespan.

turning left: OpenZiti Including the connection as an icon makes it convenient for developers and transparent to reviewers and users. As an open source software, it fits DevSecOps processes that scan source code. The management side of OpenZiti is cloud-native, API-based, and fits with the DevOps model of continuous integration testing. For example, a network may be constantly created as code and destroyed by a pipeline to exercise any imaginable configuration of endpoints, services, and policies, or to facilitate dynamic scanning of the data edge and fabric APIs.

right shift: OpenZiti It allows us to transform appropriate security to measure and monitor applications after development, in production, with new ease and without compromising security. Operators maintain an optimal view of deployed applications and do not need to deal with the complexity of navigating through security gates or fortresses or worrying about external malicious actors and incoming connections. This reality, the best of both worlds, is a natural effect of An access control system that relies on a verifiable cryptographic identity, not a weak identifier such as an IP address. Most importantly, this means that it is always possible to know which identity is accessing the services, when and to what extent.

OpenZiti gives applications superpowers! To name a few: identity-driven addressability, private domain name system, shelter from unauthorized connections, portable and programmable micro-segmentation, end-to-end encryption, resolving the lack of IPv4 without IPv6, intelligent routing for choosing optimal paths over the Internet and transparent to end users.

Learn more about OpenZiti by checking out our site Quick start or enter into a conversation dialogue.

Leave a Comment