Build Threat Models for Least-Privilege at Scale with ThreatModeler and AWS

MOST RECENT POSTS

The premise behind least privilege is simple: if you want to protect your bank vault, start by being very careful about who gets a key.

In the cybersecurity world, least privilege works very much the same, but instead of keys and bank vaults, its access to sensitive applications and resources within business networks. Least privilege is about giving employees access only to the resources they need to do the job; no more, no less. Give more, and you expand your organization’s attack surface; be too strict, and you’ll impede on your organization’s productivity.

As you might imagine, making decisions about who gets access to which resources poses a challenge – exponentially more so in enterprise-grade companies with many thousands of employees, and even greater for those developing cloud-based applications designed for thousands of simultaneous users. For organizations developing cloud-based applications, here’s what you need to know to understand the threat landscape, and how least-privilege can be done at scale with ThreatModeler and AWS Security Epics Automated.

How Least Privilege Addresses Today’s Threat Landscape

As a security principle, least privilege is particularly well-suited to today’s cybercriminal activity.

Over recent years, cybersecurity incidents have been on the rise. For instance, malware infections grew from $12.4 million in 2009 to $812.67 million in 2018; the sheer volume and damages these incidents cause are severe. In 2021, monetary damages from cybercrime are expected to cost organizations $6 trillion annually, up from $3 trillion in 2015.

The vast majority of hacks – 99 percent to be precise – fall into the category of social engineering attacks, which occurs when hackers send misleading emails to employee email addresses in an attempt to trick that employee into responding with login credentials to sensitive resources. From there, hackers seek to elevate their access by upgrading their security credentials, where they can gain access to broader system controls – all to gain access to targeted resources.

And according to Forrester Research, 80 percent of security breaches involve the use of privileged credentials.

Hackers who have successfully breached and elevated their credentials are difficult to uncover. Since they’ve become a superuser, their activities can remain secret to the rest of the organization. If this sounds like an unlikely scenario, it isn’t. On average, it takes 191 days for most organizations to discover that they’ve been hacked; and 66 days on top of that to contain the threat. Unfortunately, this gives inside threats plenty of time to do damage, and zero in on sensitive resources.

The infamous 2013 Target breach, for instance, began when hackers obtained corporate login credentials through a heating and air conditioning partner vendor, leading to the exposure of sensitive records for roughly 70 million customers. A study from the Ponemon Institute’s calculated of each hacked record to be $194, which brings the total damages in this case to $13.5 billion.

Applied correctly, least privilege greatly reduces the risk of compromise across an entire organization — whether hacks originate from insiders or external forces. Enforcing least privilege is instrumental in reducing the scope of potential damage and minimizing business disruptions that may result from errors or malicious actions.

Cloud-based Environments Bring New Complications to Cybersecurity

The explosive growth of cloud application adoption has helped transform organizational capacity over the last several years. However, in the move to the cloud, new security complications have arisen.

Hosting applications on the cloud invite added security threats and widen the attack surface. And while there’s a myth that the cloud is overall less secure, it’s far from a wholly-secure environment.

Chief among these risks are cloud configuration errors, which hackers can spot with well-circulated digital tools. In one instance, a server on a cloud platform was breached, exposed voting records of 154 million US voters, which included information about gun ownership and preferences on various political issues.

How did the hacker obtain these records?

The database had no set password.

This issue is relatively widespread. Organizations are aware of an average of 37 misconfiguration incidents per month — according to a study from Symantec — but the cloud security provider’s customer data showed far more, 3,500, which meant 99 percent went unnoticed. Organizations also appear to lose track of the volume of cloud services in use, with 76 percent indicating that they run a multi-cloud environment while customer data found that figure to be closer to 92 percent.

It’s of paramount importance, then, for organizations hosting app functionality in the cloud to be acutely aware of:

  • Their cloud environment
  • Its particular features and risks
  • What needs to be done to mitigate those risks.

This is where threat modeling comes in.

ThreatModeler, and the Challenge of Applying Permissions at Scale

Properly permissioning each application and user across an entire enterprise is complicated, to say the least. Combine thousands of employees with thousands of devices, dozens or perhaps hundreds of applications in use, and the possibilities become exponential.

How might one approach identity management for cloud-based applications?

ThreatModeler, an automated threat modeling platform, has been brought to the Amazon Web Services cloud – thanks to a new offering developed with Amazon Web Services (AWS) Professional Services (ProServe) Security and Infrastructure Global (S&I) Specialty Practice (GSP). The offering automates and accelerates the design of secure AWS cloud environments. AWS customers can now proactively secure their cloud infrastructure using AWS’s Security Epics guidance to build a threat modeling process that drives security throughout the Cloud Development Life Cycle (CDLC).

Essentially, ThreatModeler works as a staging tool for the design phase of cloud-based application development – cloud deployment applications can be analyzed by ThreatModeler. Users can reconstruct whiteboard plans for their application’s functionality through the drag-and-drop interface, serving as a high-level architectural roadmap for upcoming work. All this allows DevSecOps to bake security practices into the design and development of cloud-based applications.

After populating the interface with components, ThreatModeler will compare these components to a preexisting library of threats, and identify steps developers can take to mitigate those threats.

Users will then be presented with each component, each threat associated with it, information on the source of the threat, and the number of threats associated with those sources. Users can further drill down and read more, including its current status, and the overall risk level.

Security requirements to ensure protection against these threats are then populated, and outlined in easy step-by-step directions.

Applying ThreatModeler to Least Privileges

New hires, new hardware and software, turnover, promotions; there are numerous events that generally require network managers to update and oversee permissions.

ThreatModeler’s AWS Security Epics Automated enables a self-service model to scale secure Cloud Development Life Cycles (CDLCs) by automatically converting an architecture diagram into a threat model. AWS Security Epics Automated analyzes the live AWS service environment to validate the security controls and ensure all the threats have been mitigated. ThreatModeler’s security controls empower users to protect sensitive and otherwise exposed resources through role-based access. Implementing least privileges with ThreatModeler comes thanks to an integration with Amazon Web Services’ identity-based access management platform.

ThreatModeler helps network administrators by evaluating identity-based security profiles and analyzing their usage data.  It then produces a report detailing the least used roles based on usage patterns.  It also gives users a broader, aggregated view of all assets on their AWS EC2s, including threats. This simulated environment also helps users visualize access policy changes and their impact on the broader environment. Risk information can be reviewed, and aging and outdated policies can be flagged and resolved.

Finally, it also lets people validate architecture post-deployment, secure assets, and make better permissions decisions, just as ThreatModeler does for other security threats.

Learn more about ThreatModeler’s AWS Security Automated by visiting our web page.

Leave a Reply

You must be logged in to post a comment.