Renata Budko
The concept of Zero Trust has been around since 2009. It stems from the idea that with the computing world becoming more decentralized, relying on a network perimeter to be a boundary between trusted and untrusted no longer works. The concept’s implementation into a security model involving network-based microsegmentation, VLANS, internal security zones and the like.
In 2018, Forrester has published a report describing a Zero Trust Extended Ecosystem (ZTX).
With this, the concept has further evolved to become user and data centric, rather than looking purely at the network access.
In the old days when all the servers were sitting in the server closets and employees worked from stationary computers under their desks. Today, with a “stay at home” mandated by COVID 19, distributed workforce, BYOD and essential cloud services incorporated into the IT mix, the policy on who is trusted for what becomes a lot more complicated.
Rather than basing trust on where the user is logging in from, the centerpiece of the model is the data, applications that process the data and users who run the applications. Thus the application security policy becomes as important if not more important to zero trust as the network security policy.
It’s also extremely important that trust and access decision are made in the context:
Signals derived from such context can determine if this transaction should be explicitly enabled, always blocked, or, perhaps, should require an additional authorization or verification.
ZTX advocates many measures that are centric to the application security, such as the use of visibility and analytics to detect and proactively predict threats. Additionally, context is very important, especially when securing systems with high degree of orchestration and automation.
User centric threat detection approach allows for proactive protection and reduction in threat dwell time.
So what are the threat vectors that can be exploited if the zero trust principles are not observed? There are many threats that are specific to the application logic and the vertical industry, but we will only consider a few that are common for most enterprises.
Businesses and websites alike have the users create accounts to interact with internal business resources. Employees might have more stringent account creation and authentication processes, perhaps enabled by Microsoft Active Directory or a SaaS IAM solution like Okta. Customers or partners might be using a simple username / password combination or they might be logging in with their Yahoo or Facebook accounts.
What will happen, however, if a password is compromised? There are common known techniques to compromise account passwords, such as trying all possible letter combinations (brute-forcing) or trying previous pawned passwords assuming it’s in human nature to use the same password on multiple accounts (credential stuffing). Phishing is another way that attackers can steal credentials of unsuspecting users.
When an attacker is in control of a legitimate user account, firstly, they can exploit internal systems, including changing the settings to exclude legitimate users from access. This is the exploit that was at the foundation of the recent Twitter situation where access credentials of internal twitter administrators were initially compromised that then led to a compromise of many other accounts of the individual users. The second issue, of course, is that this issue is very difficult to deal with since blocking a legitimate user might result in interruption of business or loss of revenue.
For the end users accounts that are easy to create, such as e-commerce users or users of SaaS services, there are possibilities that accounts are created for an explicit purpose of exploiting the business to the benefit of an attacker. This account creation can even be automated via botnets. Even the account creation itself can become a problem creating a denial of service situation by overloading the systems. In addition, with somewhat legitimate access, these accounts that are not actually the real users can use up valuable resources, scrape coupons, collect proprietary information and create other systematic problems.
The second family of threat vectors comes from the employees and other privileged users exploiting their access in the way that was not intended.
Privilege escalation describes the situation where users illegitimately gain access to the information, data or functions that are above and beyond what they need to do business.
The device from which an employee or a user accesses the application or a SaaS service may already be compromised with malware. In the present day situation, where most employees are remote and the workforce is distributed, even the work devices are often accessible to the kids and the other members of the household, who may not have the same amount of security training and just be too careless about accessing malicious sites. COVID is not just a danger to our health - it's also a danger to our devices.
Even in an office environment, Bring Your Own Devices policy means that the devices on the inside of the network perimeter cannot always be trusted either.
The employees and privileged users might come into a situation where they are not entirely happy with their employers. Disgruntled employees can be quite destructive to a business. For example, a dissatisfied employee of a Morrison supermarket in the UK has posted some confidential information with regards to the other employees on public websites. Not only the reputation of the store was damaged, they actually came to be a subject of a lawsuit for vicarious liability.
These threat vectors should be convincing enough for most of us to adhere to zero trust philosophy. What measures should an enterprise implement to actually practice zero trust for both the network and the application security?
The most powerful practice here is to protect internal APIs, including the API logic. Noticing unusual API behaviors would help catch outlier behaviors and situations where normally legitimate accounts are used in an inappropriate way.
Secondly, understanding the security of the data within the system and implementing the data controls appropriate for the data risk levels. Since the perimeter can no longer be trusted, the protection of sensitive and PII data must happen where the data are processed. Typically, this implementation relies on data classification and the ability to trace the data paths.
Lastly, we must make it difficult for the bad guys to gain credentials improperly. This can be accomplished with a wide-spread use of multi-factor authentication and the use of password-less authentication methods. The ability to rely on the user identity and role also makes for excellent user-centric policies that, in addition to improving security, allows business to optimize user experiences based on what they are trying to accomplish.
Traceable helps protect organizations from many of the Zero Trust attack vectors. Further, similar to the strategy of Zero Trust, Traceable advocates the principles of being user and data centric.
By design, Traceable instruments the distributed application to secure both the edge and internal APIs. Protecting internal APIs with Traceable means not just looking at potentially harmful API calls, but also understanding the dynamic application context.
Traceable establishes baselines for the user behavior, API logic, and data flow to identify the anomalies. Watch a recorded Traceable demo to see for yourself.
Zero trust is a key principle in designing modern applications where microservices and api security are key
