Matthew Sharp, CISO, Logicworks
Max Sobell, COO, Carve Systems

As we start 2020, many IT leaders are confronted with increased regulatory pressures, new public cloud projects, and an overwhelming number of new tools and processes to assimilate. It is no surprise that 88% of IT leaders believe compliance inhibits further cloud adoption. Sometimes it can feel like walking a tightrope with no safety net.

With the stakes higher than ever, IT leaders still don’t fully understand how public cloud affects an enterprise risk profile. There are risks that were once critical in your datacenter, that are now less important in public cloud. More importantly, new risks arise in public cloud that you never had to think about in your datacenter. As we move beyond the simplistic understanding of “public cloud is secure / not secure”, we need a more nuanced understanding of how to best identify the real risks that deserve your attention in 2020.

In this post, we present a common scenario: a company has already migrated a few workloads to the AWS cloud, but has designed a simplistic architecture that approximates their on-premises architecture (colloquially known as Lift and Shift). Via Threat Modeling, we identify the risks of this simplistic architecture, examine mitigations to those threats, and finally present a more secure architecture that enhances your ability to subsequently optimize cost, performance, availability, and scalability.

Understanding the Threats of Public Cloud

Moving to a public cloud doesn’t make you inherently more or less secure. However, if you don’t reconsider the new attack surface and adequately cover key areas of risk — or worse, just assume that the same security tools and practices you used on-premises are just going to “work” on public cloud — you’re in for some pain.

Below is an example of a cloud architecture, perhaps built by an inexperienced cloud architect, modeled after their on-premises architecture:

The basic features of this diagram are that:

• All resources are in a single Virtual Private Cloud in a single Availability Zone
• There are three Amazon EC2 instances and an RDS database behind a load balancer
• Static web assets are delivered by AWS CloudFront (a CDN)

Now let’s try to understand the threats inherent in this architecture. In order to do this, we’ll undergo a threat modeling exercise and try to think like an attacker.

Introduction to Threat Modeling

Depending upon the architecture and cloud technologies in use, organizations need to consider the attack surface and design a strategy that adequately covers key areas of risk.  One approach to accomplish this is the use of Threat Modeling.

The following process flow diagram outlines the foundational steps to perform a Threat Model exercise:

Every threat modeling effort includes a structured analysis of potential security failures known as “threat enumeration”. Not everyone instinctively thinks about what could go wrong with a system from the attacker’s viewpoint. Luckily, you don’t need the knowledge of a would-be attacker to use threat modeling effectively. There are tons of brainstorming strategies to help you activate your attacker mindset.

One of the most accessible threat enumeration techniques we’ve implemented at Logicworks is STRIDE. We had help from Carve Systems, a boutique security consulting company focused on helping engineering organizations shift security left and ship secure products on time. STRIDE is a mnemonic device for common software security threats:

STRIDE originates from Microsoft and is still used as a part of their SDL (Secure Development Lifecycle). The challenge for developers deploying to the cloud, as explained in the post, is evaluating the risk of potential threats.

Once a threat has been identified, a team must evaluate the risk the threat poses. Requirements, threats, and mitigations all interplay to determine what risk a threat poses to the business. Sometimes a threat doesn’t align with business requirements and may be safe to ignore. Remember that threats can take on many forms. They don’t always come from attackers. Abnormal application usage leading to instability can also be a threat to the business.

Threat Modeling the Simple Cloud Architecture

We particularly like the STRIDE framework because there is lots of overlap between categories, which gives us extra opportunities to identify threats. In addition, it’s very fast to pick up and allows engineering teams to get right into the important activity of threat modeling. It’s important to note, though, that STRIDE only goes one direction: threat enumeration, not threat categorization. Trying to categorize threats into one of the STRIDE categories is an exercise in futility. Most threats will fit into multiple buckets, and the framework isn’t useful in that direction.

Also note that threats to a system will always be present. We use the analogy of a house: the threat of a break-in will always exist. That threat can be mitigated by securing the house: bars on the windows, pry bar on the door. Exploitation of vulnerabilities is what allows an attacker to realize the threat (e.g. an open garage door or window is a vulnerability).

In a brief ~2 hour exercise, a Threat Model on our sample architecture might produce a list of findings and recommended mitigation steps as follows:

Addressing the Threats Identified in Threat Modeling with Logicworks

In order to address the threats uncovered in the threat modeling exercise, we need to go back to our cloud architect and come up with a new cloud architecture. As a general comment, we can prevent a lot of re-work by doing light threat modeling early in the SDLC, as soon as the initial design is completed but before implementation begins.

To build a secure cloud architecture, your company’s internal IT team must knit together a customized combination of cloud native (AWS Trusted Advisor, Security Hub), Independent Software Vendor (ISV) providers of cloud access security broker (CASB) solutions (Netskope, SkyHigh), and cloud workload protection platforms CWPPs (Cavirin, Alert Logic), container security (Aqua, Twistlock, Aporeto, Trend Micro, WhiteSource), and custom developed intellectual property such as Logicworks Data Loss Prevention.

The architecture diagram below was built by Logicworks, and shows a mature approach to building a standard 3-tier web application. Note that in this diagram, we are not just mitigating threats from the simple cloud architecture above, we are also ensuring that the environment is prepared to scale for additional business use cases.

This diagram represents the networking and cloud native service mitigations required to meet a high security standard. Note that each mitigation identified during the threat modeling exercise (see chart above) is numbered here.

A couple important points to highlight:

• We’ve separated the management plane from the data plane; note management VPC, and production VPC. Typically there would also be an additional Staging and Test VPC. Of course this model is infinitely extensible, and often an organization will have more SDLC tiers or can even separate applications into different VPCs.
  • The business value of this setup is that the company can add additional applications in separate VPCs or in separate instances in the same VPC, without having to re-architect the whole solution. This saves time/money/effort.
• The management VPC includes core security features, including Intrusion Detection, a Bastion Host, and Active Directory servers.
  • Again, the business value of this is that the environment can grow without having to do the hard work of reproducing core security tools and functionality.
• Rather than hitting the load balancer directly, users are directed through a Web Application Firewall.

In addition to these technical features, we also need to develop a strong security practice that helps us implement and maintain these configurations over time. The following diagram represents more of the strategic or high-level service mitigations:

Whether you engage Logicworks or develop these services in-house, each is critical for maintaining ongoing security and governance. All these services are part of our suite of AWS Managed Services, which provides 24×7 support for your infrastructure, plus:

• Logicworks Build Service: Our engineers design and build a secure cloud infrastructure with network and access control best practices built-in.
• Logicworks Compliance Assessment: Provides a compliance report and full findings of your environment including security/compliance baseline, performance by OS/cloud service, top remediation suggestions. Limited to: HIPAA, PCI, CIS, ISO 27002, GDPR, SOC2, NIST.
• Logicworks Data Loss Prevention: Logicworks DLP automatically configures Amazon Macie, a machine learning tool that can detect sensitive data in your AWS S3 storage buckets. Then our serverless technology alerts and takes action when sensitive data is at risk of being leaked. Can remove public access from new or changed S3 objects (objects within my public buckets are ignored) or quarantine new or changed S3 objects within my public buckets when objects have risk level.
• Logicworks Pulse Scanners: We designed custom scripts to scan through customer environments and alert them of potential security and compliance misconfigurations. (In real terms: Scanners are scripts that run on a schedule across all managed AWS client accounts.  They perform security/compliance-type tasks and have a framework for notifying interested parties.)
• Logicworks Advanced Security Services: Patching: We’ll help you detect, assess, test, and execute OS-level patches for your instances.

Conclusion

It’s up to your IT team to determine how to identify, and then mitigate the new risks inherent in public cloud, and unique to your chosen architectures.  Understanding how these pieces fit together – and where they satisfy or do not satisfy specific regulations – can be a significant challenge, and one that companies can’t afford to get wrong.

Given how complicated the world of cybersecurity can be, it’s important to trust the right providers and platforms to help your business stay secure.  Following repeatable processes, leveraging proven development patterns, implementing appropriate developer guardrails, and addressing threats before they can affect your business is recommended to stay ahead of security issues.

Additionally, investing in the right skills will save you money and time in the long run by reducing the likelihood of expensive and time consuming data breaches.

To learn more about how Logicworks can help you build and maintain secure AWS and Azure infrastructure, contact us. For more information on how Carve Systems can help you develop your own threat model and help you avoid re-work by shifting security left, visit their website or email info [at] carvesystems [dot com].