Most security practitioners think in terms of protecting the “crown jewels,” whatever those may be relative to the specific business. While each company is different in terms of its resident data and applications or services, every company relies on data and applications/services to function. If those things are compromised in any way, the company is faced with repercussions (relative to the size of the compromise).
Regardless of the magnitude of an incident, any time a security team needs to respond to one, it means the confidentiality, integrity, or availability of the data and/or systems has been called into question—in other words, some person or system resource has gained unauthorized access to the company’s “crown jewels.” And while at a theoretical level this quandary resonates with security practitioners, companies’ “crown jewels” continue to be secured using tools that sit far away from the assets themselves and that rely largely on network IP addresses, ports, and protocols that are easy for attackers to compromise.
It’s important for security professionals to put the things they are tasked with protecting back at the center of their security strategy. The answer: application identity.
Identifying apps/services by their attributes/characteristics/immutable properties allows security teams to build policies based on which applications and data are present, running, and communicating on the network. Doing so extracts security policy from the underlying network infrastructure and ties it directly to the “crown jewels.”
The first key to application identity: Unchanging characteristics
An application’s identity must be based considerably on immutable properties—properties an attacker cannot change—and cryptographic signatures of the application. An example of an unchanging property would be the SHA 256 hash of a binary. If a single bit of that binary changes, that hash is going to result in a different value. You're going to get a different identity.
Other examples of unchanging characteristics include attributes like the universally unique identifier (UUID) of the system’s BIOS and serial numbers of the CPUs—things that are so fundamental to the system that an attacker cannot change them.
The key to immutability is ensuring that the core characteristics of an application or service remain reliable enough to uniquely identify each app/service for verification in a zero trust environment without locking the app/service into where it can’t be upgraded, updated, or improved.
The second key to application identity: Understandable characteristics
One problem with using traditional security tools to protect applications on the network is translating “application speak” (how the app was written) into “network speak” (how security tools function). This mismatch has turned into a wrestling match between many development and security teams.
To avoid such conflict, using understandable characteristics of applications to define them means that both security/networking and development/application teams can communicate in a common language. Oblique, opaque, or arbitrary characteristics erode confidence in their usefulness to function as identifiers. Using characteristics that make sense to the practitioner makes them more likely to trust and use the resulting application identity.
What does “understandable” mean in practical terms? You might have an application, such as java.exe, where the actual process name represents the application running, but the java.exe binary itself, which might give you some specifics, could be used for multiple applications.
One of the most critical things we use understandable traits for is to abstract and identify them against applications to practitioners, to security professionals, because most people who see a SHA 256, will have no idea what it is. On the other hand, if they see an application they're familiar with [such as java.exe], they will have a much better idea of what's going on on their network.
The third key to application identity: A broad variety of characteristics
As mentioned in “the first key,” an application’s identity must be based on a combination of many attributes, not just a smattering that could potentially be used to identify multiple applications. Identifying an application based on a large collection of attributes means that some parts of the identity can change (for example, through software updates) without changing the overall fingerprint of the application. This would be akin to identifying a person based on height, blood type, DNA, (point-in-time) age, eye color, hair color, what kind of clothes they wear, speech patterns, how they walk, where they live, biological parents, etc. Some of these things can change easily while others are inevitably fixed.
Using a cross-section of attributes provides the baseline for the application’s identity and allows administrators to add other more variable traits that further describe the application without losing confidence in the accuracy and viability of the identity.
Using a broad variety of characteristics, organizations can choose the ones that comprise the correct combination of features, which allows them to make the best generalizations about the identity and behavior of the application when it’s communicating in the network.
The fourth key to application identity: Upgrade-tolerance
Created application fingerprints must be upgrade-tolerant, allowing for new versions of software without necessitating an overhaul of security policies every time software is patched or upgraded.
A good illustration of upgrade tolerance is this: If you upgrade Java, the SHA 256 will be completely different, unpredictably different. But the fuzzy hash will be mostly the same because the binary underlined is still mostly the same. This means that, by using a measurement of similarity by the fuzzy hash, we can say when an application is upgraded and when it's similar enough that we can use the same rules to cover that application.
Using a combination of changing and unchanging identity attributes is important because it lets the user upgrade, have different versions, and create varied rules around applications that are very similar rather than about very, very specific binaries.
In short
Security must remain malleable while enforcing the highest level of protection possible. When security can adapt to its environment or updates (as software/apps/services are wont to do), it’s allowing the organization to evolve without sacrificing efficacy. Creating application fingerprints using the four keys described here allows organizations to look at the most salient parts of an application/service that describe, in the most distinctive way possible, what applications are present and talking to each other on the network. Around this, security policies that travel alongside the application (independent of network topology) can be built, ensuring the protection stays with what needs it most.
Read the datasheet to learn how Zscaler Workload Segmentation enables application identity.
