Blog
In a 2019 survey, 42% of organisations that had experienced an external attack blamed the incident on a software security flaw.
Smart software development teams know the importance of implementing “security by design” from the early stages of the SDLC. This approach, radically different from the security as an afterthought approach practiced earlier, focuses on proactively preventing cybersecurity breaches, rather than reactively remediating them, thus enabling dev teams to create secure software from the outset. One of the most effective ways to leverage the security by design approach early in the SDLC is threat modeling.
This involves systematically analyzing, from an attacker’s perspective, any potential threats to the org’s applications, systems, or other assets like confidential data or intellectual property. Continuous and consistent threat modeling using a model like STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privileges) or PASTA (Process for Attack Simulation and Threat Analysis) is a great way to strengthen the org’s DevSecOps culture, drive effective security measures, and lower remediation costs.
Even so, many organisations face challenges in implementing it in practice. Here are five of the most common.
Threat Modeling Process Saturation
Numerous threat modeling processes are available, which frequently leads to confusion, especially for teams lacking an experienced security expert. This makes it difficult to judge the various processes, and select the right one to drive cyber defence priorities. The wrong choice can lead to inadequate or inappropriate cybersecurity investment. Equally worrying, it may lead to overconfidence in the organization’s security posture and risk mitigation capabilities, which increases its vulnerability to attacks.
Some teams also struggle to validate their threat model. When they don’t know how to effectively mitigate the threats they find, threats are left unaddressed, once again increasing the risk of attack.
Non-monolithic, scaled-up applications
Threat modeling is easier to do for simple, monolithic applications, when there is little reliance on external entities, or when a consumable view of the computing ecosystem is available. But today’s applications are anything but simple. As they’re scaled up and migrated to the cloud, the application team is often responsible for full-stack management. This is a complete departure from previous legacy deployments, where IT completely managed the application’s physical servers and networking infrastructure. The threat model must account for these additional infrastructure-related responsibilities, scope changes, expanded topologies, and associated risks, which is not always easy for a Dev team to do.
More entry points and trust boundaries that are not recognized
With most cloud service providers, including popular ones like AWS, there are many entry points that are not recognised. These include a publicly-exposed management plane, APIs and services.
This means, many entry points can be accessed from the Internet, including API gateways that allow cross-account invokes, Lambda functions that can be invoked by bad actors with Invoke IAM permission, S3 buckets with public endpoints, and attackers that can directly inject malicious events into the SQS event queue. Consequently, the Data Flow Diagrams (DFDs) and Process Flow Diagrams (PFDs) used to model threats, and better understand how bad actors can gain access to an asset, are significantly more complex than they would be with known entry points.
Abuse of authentication tokens
An attacker that possesses a properly permissioned authentication token can easily threaten a cloud service provider’s publicly-exposed control plane. For example, in AWS, temporary authentication tokens are transferable, and can be used outside the application environment. An information leak can potentially expose an authenticated session token to bypass security safeguards and mitigating controls, and provide a bad actor access to something they shouldn’t be able to access otherwise. Thus, what was once considered a “low-risk” information leak now carries a higher severity, and therefore requires appropriate representation and analysis in the org’s threat model.
Difficulties breaking down threats and predicting actual risk
It can be difficult to determine high-level threats, and break them down into sub- threats that can be more easily addressed. Another challenging aspect is identifying the failure conditions that could lead to the realisation of these threats. An understanding of these conditions can provide a deeper understanding of the likelihood and criticality of the threat, and also support the org’s risk mitigation efforts.
A completed threat model should support risk mitigation, and provide the right framework and techniques for robust application security testing, so the team can more effectively predict possible attack scenarios.
Conclusion
Over 70% of security vulnerabilities exist at the application layer. Threat modeling provides an effective way to lower the probability that they could compromise the org’s security posture. However, many teams still struggle to extract the most value from threat modeling.
Make threat modeling an invaluable part of your org’s DevSecOps culture. Talk to the threat modeling experts from Packetlabs for a free, no-obligation quote. To know more about our cybersecurity consulting services, visit our website.