Cyber attackers today are more creative in how they attack large organizations. They use tactics like hacking suppliers to gain access to customers or compromising the code of an application to attack organisations.
Developers must be more alert to threats when developing applications and products. How can developers be certain they have considered all possible threats when creating applications and products?
A framework like STRIDE threat modeling can be a great help. STRIDE threat modeling helps developers and organizations identify cybersecurity threats to their applications, prioritize them based upon impact and likelihood, then build mitigation into their secure software design lifecycle (SSDLC).
What is STRIDE threat modeling?
STRIDE threat modeling is a developer-focused threat modeling method that uses six common threats to target software. Each of the following threat categories are addressed by STRIDE: Tampering and Spoofing; Repudiation; Information disclosure; Denial of Service; Elevation of Privilege.
Microsoft security researchers created the STRIDE threat model in 1999. STRIDE threat modeling is useful for organisations as a whole, but it is also part of a larger methodology that provides security teams with a practical framework to identify threats and deal with them. This includes creating security requirements, creating an app diagram, identifying threats, mitigating those threats, and validating that they have been reduced.
Spoofing
Spoofing is when attackers use a false identity to impersonate trusted sources and gain access to sensitive data. Spoofing uses social engineering to get users to provide usernames and passwords. Once they have this information, attackers can gain access to the application to infect the network.
Spoofing attacks include session hijacking, cookie replay attacks, and cross-site request forgery attacks (CSRF).
Spoofing is an attack against user authentication. The best way to prevent this is to use secure user authentication methods. This includes both multi-factor authentication (MFA) and secure password requirements.
Read: https://www.techsatisfy.us/tik-tok-marketing-a-success/
Tampering
Tampering is the intentional modification of a system to alter its behavior. Hackers will attempt to compromise applications by altering code or target parameters to modify application data, such as user credentials or permissions.
Cross Site Scripting and SQL injection are two examples of hacking that can compromise the integrity of an application. To protect against tampering, an application must be able to validate user inputs and encode outputs. To identify potential vulnerabilities for tampering in an application, both in development and in production, static code analysis should be performed.
Repudiation
Repudiation attacks are attempts to undermine the validity or integrity of the actions taken on an application. Repudiation attacks exploit a lack in controls that properly track and log user activities. They use this to manipulate or forge identification of new, un-authorised actions. Logs are deleted or the wrong data is logged to log files and deny actions and receipt of service (for instance, committing fraud).
Developers can create non-repudiation. This is the guarantee that no one can deny the validity or legitimacy of an action. They can do this by including digital signatures in the application that provide proof of actions or by ensuring there are complete, tamperproof logs.
Information disclosure
Information disclosure occurs when an application accidentally discloses information about it that could be used to compromise the system.
Developer comments, source code that contains parameter information or error messages can all expose information.
Attackers can use this information to gain access to the application to gather customer information, which can be used to commit further crimes, or to gain privileges that will allow them to access more sensitive areas of it.
- Developers are the ones who prevent information disclosure vulnerabilities in the application.
- To avoid giving away any clues about the application’s behavior, error messages, headers and background information should be as generically as possible.
- To prevent unauthorised access to information, it is important to have proper access controls and authorizations.
- To ensure that developers comments and other information are not disclosed in the production environment, it is important to inspect the application from a user’s perspective.
Service denial
DoS attacks flood the target with traffic, leading to a crash and closing it down to legitimate traffic. DoS attacks are costly in time and money but don’t cause any other harm to the victims. Buffer overflow attacks are the most common type of DoS attack. They simply send too much traffic to an application. Other attacks use vulnerabilities to cause systems crashes.
DoS attacks can be directed at the network layer as well as the application layer. You can protect your applications from DoS attacks by setting up firewalls to block traffic coming from certain sources, such as reserved, loopback or private IP addresses or unassigned DCHPDHCP client traffic, or introducing rate-limiting to manage traffic.
Privilege escalation
Privilege escalation attacks use vulnerabilities and misconfigurations in an application to illicitly gain access to higher or more privileged rights. Privilege escalation may be used to exploit credential and authentication processes, compromise code and design vulnerabilities, and take advantage of misconfigurations or malware to gain access.
At the initial stage of application development, protection against the escalation or granting of privilege should be included. This includes managing the identity cycle, enforcing and enforcing a principle of least privilege for everyone, hardening applications and systems through configuration changes, removing unneeded rights and access, closing ports and other measures.
Benefits of STRIDE threat modeling
Avoid vulnerabilities early
Once the majority of the application is developed, many of the commonly used methods of identifying vulnerabilities (static analysis, penetration testing and bug bounties) are in place. It’s easier and cheaper to fix flaws in development than once they are in the product.
The STRIDE threat modeling is a development-centric approach to assessing potential threats that could impact an application. STRIDE can be used as a checklist to support developers in identifying potential weaknesses early, when they are easier and cheaper to address or remediate.
Security first
The threat modeling engine STRIDE is built around threats. It encourages developers to consider how each threat could affect different parts of an application. It challenges assumptions and forces developers and information security professionals to question their assumptions and verify them for security and validity.
Combining the results of a STRIDE risk modelling exercise with the DREAD model (Damage poten, Reproducibility. Exploitability. Affected users. Discoverability) allows you to evaluate the risk and prioritize remediation options.