Application security is an important topic, but often not part of the formal training path for software professionals. Application security is often encountered in a reactionary fashion (e.g., “our site just got hacked, find the flaw and fix it so we can restore from backup”), or by throwing things over the fence as a part of a release process (e.g., to a QA or security team).
Application security is an imposing topic, and it’s often difficult to know how to get started or mentally organize the various security-related application development or deployment dos and don’ts.
In this post, I’ll try to demonstrate some basic ways to think about application security. I’ll start with some common threat models, which can help organize all this information into a framework for thinking about security.
Threat modeling is a process for identifying, enumerating, and prioritizing potential threats from a potential attacker’s point of view. With threat modeling, we work through each potential weakness in our architecture, and then use a consistent and objective set of metrics to allow us to prioritize them by their expected severity if they were to be exploited.
Threat modeling allows us to analyze possible vectors an attacker might use. It can help us find assets that might be most desired or useful to an attacker. These often differ from those that are considered most critical for a normal user of a system.
Threat modeling provides us with information on which assets are most valuable (e.g., personally identifiable information, passwords, admin credentials, etc.), what assets are most vulnerable to attack, which threats are most relevant, and whether attacks can be consistently identified.
One excellent framework for threat modeling (and one of the earlier ones developed) is known as STRIDE, which is a mnemonic for an objective system for categorizing types of security threats.
STRIDE was originally developed in 1999 by Praerit Garg and Loren Kohnfelder at Microsoft, a systematic method of evaluating threats based on earlier concepts of threat or attack trees.
STRIDE is just one of several common threat modeling approaches. As one of the earliest threat modeling systems targeted at commercial use outside of research contexts, STRIDE’s simplicity lends itself to easy understanding and implementation.
This allows it to excel in environments that are starting to integrate application security as part of an existing process.
STRIDE is a mnemonic for sorting vulnerabilities into six categories. Note that the initials of each category spell STRIDE:
• Spoofing identity – An example would be a flaw allowing a user to act or log in as a different user.
• Tampering with data – Malicious changes to data, like modifying information in a database, or changing data during transmission (either locally or over the Internet).
• Repudiation – A repudiation threat means an action cannot be proven to have happened, or details about an important action cannot be traced. This commonly occurs in instances like needing to verify a transaction from both ends to ensure it completes as intended.
• Information disclosure – An example would be allowing access to files that should not be accessible to users.
• Denial of service – This can include anything that denies access to the system by valid users.
• Elevation of privilege – The ability of an unprivileged user to gain access to resources they should not be able to, from user account data that is not their own, all the way to full administrative control of a system.
There are corresponding mitigations for each of the threat categories identify:
• Authenticity – Verifying identity to check for authorization for each action.
• Integrity – Ensuring data is transferred and stored reliability, without unauthorized changes. Inputs should not be trusted, and data in transit should be protected with encryption. Changes to data should be authorized.
• Confirmation – Also known as non-repudiation, implementing transactional systems where transactions are verified, logging data about changes, and keeping system logs are all measures that can help ensure actions are only performed atomically in a consistent manner, as well as verify how and when actions were performed.
• Confidentiality – Accesses to information should only be allowed with the proper privileges. Information in transit over untrusted networks can be protected with encryption.
• Availability – Designing for system availability and reliability will help protect against some Denial of Service (DoS) threats, as will proper patching and configuration. Large-scale DoS threats may require more complex solutions.
• Authorization – Verifying the identity has the proper privileges for any action.
There are several alternatives to STRIDE. Each has its own focus and lends itself more naturally to different teams and methodologies. Some try to take a more detailed approach to quantifying threats beyond the simple categorization that STRIDE uses.
Here are a few alternatives:
• PASTA (Process for Attack Simulation and Threat Analysis) – A seven-step process for defining an attacker-centric application and infrastructure view for developing asset-centric mitigations
• Trike – Uses threat models to satisfy an auditing process and “acceptable” level of risk for each asset
• VAST (Visual, Agile, and Simple Threat modeling) – Emphasizes the need to scale threat modeling across infrastructure and SDLC to integrate into an Agile methodology
With STRIDE (or other) threat models as an organization system, you’re now ready to start looking for flaws (e.g., both known and unknown) in your systems, categorize them, and start thinking about how to triage based on a threat’s impact.
We’re here if you need us
If you have questions or need more information about securing your open source applications, our OpenLogic Solutions team are available to assist you with this and other open source software!