Risk Profile
This section discusses the Application Risk Profile, an activity in the OWASP Software Assurance Maturity Model (SAMM). The risk profile activity is part of the Threat Assessment security practice in the Design business function.
Overview
Risk management is the identification, assessment, and prioritization of risks to the application or system. The objective of risk management is to ensure that uncertainty does not deflect development activities away from the business goals.
Remediation is the strategy chosen in response to a risk to the business system, and these risks are identified using various techniques such as threat modeling and security requirements analysis.
Risk management can be split into two phases. First create a risk profile for the application and then provide solutions (remediate) to those risks in a way that is best for the business; risk management should always be business driven.
Application risk profile
The application risk profile is created to understand the likelihood and also the impact of an attack. Over time various profiles could be created and these should be stored in a risk profile inventory, and ideally the risk profiles should be revisited as part of the organization’s secure development strategy.
Quantifying risks is often difficult and there are many ways of approaching this; refer to the reading list below for various strategies in creating a risk rating model. The OWASP page on Risk Rating Methodology describes some steps in identifying risks and quantifying them:
- Identifying a risk
- Factors for estimating likelihood
- Factors for estimating impact
- Determining severity of the risk
- Deciding what to fix
- Customizing the risk rating model
The activities involved in creating a risk profile depend very much on the processes and maturity level of the organization, which is beyond the level of this Developer Guide, so refer to the further reading listed below for guidance and examples.
Remediation
Risks identified during threat assessment, for example through the risk profile or through threat modeling, should have solutions or remedies applied.
There are four common ways to handle risk, often given the acronym TAME:
- Transfer: the risk is considered serious but can be transferred to another party
- Acceptance: the business is aware of the risk but has decided that no action needs to be taken; the level of risk is deemed acceptable
- Mitigation: the risk is considered serious enough to require implementation of security controls to reduce the risk to an acceptable level
- Eliminate / Avoid: the risk can be avoided or removed completely, often by removing the object with which the risk is associated
- Transfer: a common example of transferring risk is the use of third party insurance in response to the risk of RansomWare. Insurance premiums are paid but losses to the business are covered by the insurance
- Acceptance: sometimes a risk is low enough in priority, or the outcome bearable, that it is not worth mitigating, an example might be where the version of software is revealed but this is acceptable (or even desirable)
- Mitigation: it is common to implement a security control to mitigate the impact of a risk, for example input sanitization or output encoding may be used for information supplied by an untrusted source, or the use of encrypted communication channels for transferring high risk information
- Eliminate: an example may be that an application implements legacy functionality that is no longer used, if there is a risk of it being exploited then the risk can be eliminated by removing this legacy functionality
References
- OWASP Risk Rating Methodology
- NIST 800-30 - Guide for Conducting Risk Assessments
- Government of Canada - The Harmonized Threat and Risk Assessment Methodology
- Mozilla’s Risk Assessment Summary and Rapid Risk Assessment (RRA)
- Common Vulnerability Scoring System (CVSS) used for severity and risk ranking
The OWASP Developer Guide is a community effort; if there is something that needs changing then submit an issue or edit on GitHub.
The OWASP ® Foundation works to improve the security of software through its community-led open source software projects, hundreds of chapters worldwide, tens of thousands of members, and by hosting local and global conferences.
Developer Guide (draft)
- 1. Introduction
- 2. Foundations
- 2.1 Security fundamentals
- 2.2 Secure development and integration
- 2.3 Principles of security
- 2.4 Principles of cryptography
- 2.5 OWASP Top 10
- 3. Requirements
- 3.1 Requirements in practice
- 3.2 Risk profile
- 3.3 OpenCRE and Integration Standards
- 3.4 SecurityRAT
- 3.5 Application Security Verification Standard
- 3.6 Mobile Application Security
- 3.7 Security Knowledge Framework
- 4. Design
- 4.1 Threat modeling
- 4.1.1 Threat modeling in practice
- 4.1.2 pytm
- 4.1.3 Threat Dragon
- 4.1.4 Cornucopia
- 4.1.5 LINDDUN GO
- 4.1.6 Threat Modeling toolkit
- 4.2 Web application checklist
- 4.2.1 Checklist: Define Security Requirements
- 4.2.2 Checklist: Leverage Security Frameworks and Libraries
- 4.2.3 Checklist: Secure Database Access
- 4.2.4 Checklist: Encode and Escape Data
- 4.2.5 Checklist: Validate All Inputs
- 4.2.6 Checklist: Implement Digital Identity
- 4.2.7 Checklist: Enforce Access Controls
- 4.2.8 Checklist: Protect Data Everywhere
- 4.2.9 Checklist: Implement Security Logging and Monitoring
- 4.2.10 Checklist: Handle all Errors and Exceptions
- 4.3 Mobile application checklist
- 5. Implementation
- 5.1 Documentation
- 5.1.1 Top 10 Proactive Controls
- 5.1.2 Go Secure Coding Practices
- 5.1.3 Cheatsheet Series
- 5.2 Dependencies
- 5.2.1 Dependency_Check
- 5.2.2 Dependency_Track
- 5.2.3 CycloneDX
- 5.3 Secure Libraries
- 5.3.1 Enterprise Security API library
- 5.3.2 CSRFGuard library
- 5.3.3 OWASP Secure Headers Project
- 6. Verification
- 6.1 Guides
- 6.1.1 Web Security Testing Guide
- 6.1.2 MAS Testing Guide
- 6.1.3 Application Security Verification Standard
- 6.2 Tools
- 6.2.1 Zed Attack Proxy
- 6.2.2 Amass
- 6.2.3 Offensive Web Testing Framework
- 6.2.4 Nettacker
- 6.2.5 OWASP Secure Headers Project
- 6.3 Frameworks
- 6.3.1 secureCodeBox
- 6.4 Vulnerability management
- 6.4.1 DefectDojo
- 7. Training and Education
- 7.1 Vulnerable Applications
- 7.1.1 Juice Shop
- 7.1.2 WebGoat
- 7.1.3 PyGoat
- 7.1.4 Security Shepherd
- 7.2 Secure Coding Dojo
- 7.3 Security Knowledge Framework
- 7.4 SamuraiWTF
- 7.5 OWASP Top 10 project
- 7.6 Mobile Top 10
- 7.7 API Top 10
- 7.8 WrongSecrets
- 7.9 OWASP Snakes and Ladders
- 8. Culture building and Process maturing
- 8.1 Security Culture
- 8.2 Security Champions
- 8.2.1 Security champions program
- 8.2.2 Security Champions Guide
- 8.2.3 Security Champions Playbook
- 8.3 Software Assurance Maturity Model
- 8.4 Application Security Verification Standard
- 8.5 Mobile Application Security
- 9. Operations
- 9.1 DevSecOps Guideline
- 9.2 Coraza Web Application Firewall
- 9.3 ModSecurity Web Application Firewall
- 9.4 OWASP CRS
- 10. Metrics
- 11. Security gap analysis
- 11.1 Guides
- 11.1.1 Software Assurance Maturity Model
- 11.1.2 Application Security Verification Standard
- 11.1.3 Mobile Application Security
- 11.2 Bug Logging Tool
- 12. Appendices
- 12.1 Implementation Do's and Don'ts
- 12.1.1 Container security
- 12.1.2 Secure coding
- 12.1.3 Cryptographic practices
- 12.1.4 Application spoofing
- 12.1.5 Content Security Policy (CSP)
- 12.1.6 Exception and error handling
- 12.1.7 File management
- 12.1.8 Memory management
- 12.2 Verification Do's and Don'ts
- 12.2.1 Secure environment
- 12.2.2 System hardening
- 12.2.3 Open Source software
Upcoming OWASP Global Events
Corporate Supporters
OWASP, the OWASP logo, and Global AppSec are registered trademarks and AppSec Days, AppSec California, AppSec Cali, SnowFROC, and LASCON are trademarks of the OWASP Foundation, Inc. Unless otherwise specified, all content on the site is Creative Commons Attribution-ShareAlike v4.0 and provided without warranty of service or accuracy. For more information, please refer to our General Disclaimer. OWASP does not endorse or recommend commercial products or services, allowing our community to remain vendor neutral with the collective wisdom of the best minds in software security worldwide. Copyright 2024, OWASP Foundation, Inc.