A security paradigm for 2024: ATAF—Access To, Access From

There is a heaping list of security techniques that protect against a wide bastion of attack vectors. Security teams in 2023 have the task of choosing a subset of these strategies to limit the vulnerability of their systems and data. An issue, however, is that teams will pick a mix of security measures, but a single exploit could explode into a massive breach.

Today, we advocate for ATAF (Access To, Access From) as a security framework that should be applied to all security problems. The goal of ATAF is to help security professionals categorize their tactics into two buckets: protection before an initial attack and protection afterward.

To begin, some definitions might be helpful. In the context of ATAF, Access To is defined as access to a resource. This might be access to an infrastructure account, an infrastructure tool, a service, or anything of value. Access From, meanwhile, is defined as what access that resource has to other resources. For instance, a poorly-trusted server might have access to Salesforce data due to a hardcoded Salesforce API key.

An alternative framing of ATAF is the need to protect resources, but contain damage if they are exploited. Resources could be exploited for various reasons—a phishing attack, a zero-day exploit, etc—but what’s made worse is if that resource helps attackers exploit even more resources. The cycle perpetuates itself—those further vulnerable resources might lead to exploits to other resources.

This paradigm might feel like morbid thinking. It is, after all, assuming an exploit might still happen. Regardless, it is a responsible paradigm for limiting damage to customer data. No matter how good a security team is, attacks happen. Airtight security is a fantasy. So, today, teams need to consider both halves of ATAF.

Infra-access is a good starting point

When thinking about how to apply ATAF, begin with your infrastructure access accounts. These are, after all, one of the biggest resources (arguably the biggest resource).

While most companies only grant complete admin access to select individuals, many still give very permissive access to average staff developers. This could lead to very damaging attacks if a developer’s account becomes compromised.

A grand majority of security teams are cognizant of this, employing additional safeguards such as multi-factor authentication (MFA) or FIDO hardware keys. However, these techniques only protect against unauthorized access to the resource. Should the resource be breached, attackers will be able to wreak havoc by accessing live databases, production servers, and stored API secrets.

Infrastructure is a big topic, so there are many strategies that protect against the latter half of ATAF. Let’s survey four of them to establish how security professionals should think about ATAF. (To be clear, none of these techniques will completely foil an attack, only sharply limit it; remember, there is a difference between “someone breached our AWS” and “someone stole all of our data”.)

1. Principle of least privilege

A breached infrastructure account shouldn’t be able to access every single database, server, and load balancer on file.

A simple way to protect against this is with the principle of least privilege (PoLP), where developers are only granted access to resources they actually need to work with. Of course, this collides with some “open-access” development philosophies, but PoLP would also limit production data from being accessed by a breached front-end engineer’s account.

2. Just-in-time access

Either in conjunction or in competition with PoLP, just-in-time (JIT) providers (e.g., Sym) limit employee access unless (i) another employee approves access or (ii) certain heuristics are met, such as familiar IP addresses or behavior. This prevents a hacker who stole employee credentials from actually accessing those resources.

3. Secrets managers

A breached infrastructure account might allow hackers access to company servers, and those servers often have a laundry list of API keys to third-party applications stored in memory. Given that companies have millions of entries of data stored on those respective third-party platforms—like Salesforce or ClickHouse Cloud—gaining API access could really escalate damage. To address this, companies should use secrets managers (e.g., Doppler) to separate API secrets from cloud infrastructure resources (e.g., EC2). It’s a simple addition that really curbs the damage of an infrastructure breach.

4. Encryption by relay

A breached infrastructure account shouldn’t be able to directly access production data. Unfortunately, most companies solely depend on encryption at rest, a technique that protects against yanked hard drives but not cracked AWS credentials.

To protect against this, companies can use an external relay (e.g., Evervault) to encrypt data.

By using encryption by relay, the data in the database stays encrypted when arbitrarily accessed through a cloud account.

ATAF is recursive

Techniques that operate under the umbrella of ATAF often introduce (typically smaller) vulnerabilities.

For instance, encryption by relay is a fantastic way of preventing a data breach if a cloud account becomes hacked. At the same time, if the encryption-by-relay API key is stolen, then the data is at risk should the ciphertext data also be leaked.

At the risk of sounding like an ad, this was exactly why we built data policies for Evervault’s flagship encryption-at-relay solution. Data policies enable our customers to limit which resources are allowed to decrypt data as it is passed through relay per ciphertext. While previously, only destinations could be limited, now destinations are configurable per ciphertext itself.

Now, if an Evervault API key is breached—for instance, if it was hard-coded somewhere it shouldn’t be, like a GitHub repository—it is pretty useless. Unless, of course, the attacker also gains access to a company’s approved endpoints, which obviously complicates an attack’s feasibility in the first place.

After all, ATAF (and all security techniques) are about making security breaches harder, not eliminating the threat of one (an impossible goal). It’s just a principle that should be applied to every attack surface as well as to the solutions for those attack surfaces.

ATAF can be applied externally

A grand majority of companies use third-party applications, and many utilize third-party APIs to programmatically access their data. As mentioned, those API keys can be breached, especially if proper precautions like a secrets manager aren’t used. Recently, Dropbox had all of its secrets exposed after an engineer’s CircleCI credentials were phished.

Even here, ATAF can be applied. While those API keys protect access to a resource, access from those API keys can (often) also be limited. Many APIs support scoping API keys down to only functions relevant to an application’s needs; this prevents a hacker from arbitrarily pulling all the data associated with that third-party account. Additionally, some APIs support allow-lists and block-lists to limit which IP addresses are allowed access.

ATAF can be applied on infra itself

ATAF isn’t just a function of credential-based access; resources themselves could have closed access, so that only resources in the same security enclosure can access each other.

This protects against attacks beyond phishing—such as a zero-day attack or an XSS scripting attack, in which a hacked Linux box might be used to access other core resources, such as a database. By limiting the reach of resources at the network layer (using something like a VPC), developers can limit the damage of an attack.

Closing thoughts

The core moral of the story is that a single attack can have ripple effects that exponentiate the damage of a tiny breach. By applying the bifurcation of ATAF to every secured resource—big or small—teams can effectively limit the damage of an attack.