Movatterモバイル変換


[0]ホーム

URL:


Skip to content
DEV Community
Log in Create account

DEV Community

Cover image for Security in Requirements phase
OWASP® Foundation profile imageMartin Belov
Martin Belov forOWASP® Foundation

Posted on • Edited on

     

Security in Requirements phase

Building requirements is one of the first steps in the SDLC, where we define the goals and objectives of our future application. Usually, at this phase, we collect relevant stakeholders and start discussing their needs and expectations. We talk to people who will use the application, those who will manage it, and anyone else who might be affected by it to understand what they want the application to do and how it should work.

After reading this article, we will understand how to:

  • Prepare Security Requirements
  • Properly classify and rate threats
  • Use a language of money in the risk assessment and prioritization
  • Make sure, that defined security requirements will be implemented during other steps of SDLC

During requirements engineering, we need to separatefunctional andsecurity requirements. While functional requirements show what an applicationshould do, security requirements show what an applicationshouldn't do.

It's important to carefully consider building security requirements because a large part of the system's security depends on them. Good security requirement followsSMART principle:

NameDefinition
SpecificRequirement shouldn't be complex and too broad, but exact and clear.
MeasurableThere should be a clear way to test if this requirement was met or not.
AchievableDevelopers should have a clear understanding of actions they need to take in order to meet the requirement.
RelevantRequirement should ensure it addresses actual risks and provide meaningful protection, avoiding measures, that don't add values.
Time-boundThere should be a clear timeframe for implementation of this security requirement.

Usually, stakeholders involved in security requirements engineering are:

  • Developers
  • Security experts
  • Project Managers/Architects

All of them can participate in one of the ways to build security requirements:Security andAbuser stories.

Security Stories

As a [role], I want [security feature], so that [benefit]

Security stories are a special type of user stories, that focus on the security of the system.

You should look at the application from the perspective of users and stakeholderswho need protection.

Examples:

  1. As a developer, I want to ensure that all passwords are stored with strong hashing algorithm so that even if the database is compromised, the passwords remain secure.
  2. As a system administrator, I want to log all access to sensitive data so that we can audit and identify any unauthorized access.

Abuser Stories

As a [bad guy], I want to [do something bad]

Abuser stories are the opposite of security stories. Here you need to think like anattacker, finding the ways you canexploit an application.

Examples:

  1. As an attacker, I want to perform a brute force attack on the login page to gain access to user accounts.
  2. As an attacker, I want to intercept data transmitted over the network to steal sensitive information.

So, security and abuser stories allow us to look at the application from both points of view: the user's and the attacker's.

It is aproactive approach, that provides a detailed and scenario-based understanding of security requirements.

Now we need a comprehensive way to ensure our critical assets and potential risks are managed.
For this, we can use theFAIR model:

Factor analysis of information risk (FAIR)

FAIR is a methodology, that helps to assess and manage informational risk in afinancial terms.

It includes the following core steps:

  1. Threat andCritical Asset identification - defining valuable assets of the application and identifying related threats for them.
  2. Contact Frequency (СF) assessment - calculating how frequently the vulnerability interacts with critical asset
  3. CalculatingProbability of Action (PoA) - finding the probability that asset would be attacked
  4. Threat Event Frequency (TEF) assessment - multiplication ofCF andPOA
  5. Vulnerability (Vuln) assessment - the probability that the attack on the asset would be successful
  6. Loss Event Frequency (LEF) assessment - multiplication ofTEF xVuln
  7. DefiningLoss Magnitude (LM) - calculatingPrimary Losses (actual damage in a result of the attack)andSecondary Losses (reputation, litigation losses)
  8. CalculatingOverall risk - multiplication ofLEF xLM

Sounds a bit hard, right? AsFAIR is justmethodology, notframework, there are no concrete ways ofhow you should calculate risks.

But using simpleThreat Modeling techniques, we can cover most of these steps:

Threat Modeling

Threat modeling allows us toidentify andrate threats.

Identifying threats helps us to understand which security aspects are at risk, while rating ensures we prioritize them in the right way.

To properly identify threat we will useSTRIDE framework:

ThreatDescriptionBroken Principle
SpoofingPretending to be as someone or something else.Authentication
TamperingUnauthorized alteration or modification of data/communications.Integrity
RepudiationDenial by involved party of previously performed actions due to lack of auditing and logging.Non-repudiation
Information disclosureUnauthorized access or exposure of sensitive data.Confidentiality
Denial of ServiceDisruption of system's normal functioning.Availability
Escalation of privilegeAllowing entity to do something, what it shouldn't have permission for.Authorization

As we see, it allows us to classify a threat in one or more of 6 categories, defining which security aspects are affected.
After the identification we can calculate the risk by using theDREAD framework:

NameDefinition
Damage PotentialHow big the potential damage would be?
ReproducibilityHow easy is it to reproduce this attack?
ExploitabilityHow hard is it to use this vulnerability?
Affected UsersHow many users would be affected?
DiscoverabilityHow fast can an attacker discover the vulnerability?

Each category in the model is scored from 0 to 10. The sum of the scores in all categories istotal risk score. Maximum risk score is50.

As an example let's create a STRIDE and DREAD analysis forSQL Injection:

ThreatDescriptionMitigation
SpoofingManipulation of SQL queries to bypass authentication mechanisms.Use prepared statements and parameterized queries to prevent manipulation of authentication queries.
TamperingChanging data within the database by injecting malicious SQL commands.Use data versioning for tracking of changes and rollback if unauthorized modifications are detected.
RepudiationAltering transaction records, making it difficult to verify malicious actions.Enable Database Activity Monitor (DAM) for logging and auditing actions within the database.
Information DisclosureRetrieving sensitive information from the database.Encrypt all sensitive data and store all keys separately from the data.
Denial of ServiceExecuting costly SQL queries to disrupt database operations.Implement rate limiting and monitor query performance to detect and mitigate abuse.
Escalation of PrivilegeInjecting to get elevated privileges within the application or database.Enforce Least Privilege principle and use role-based access control.

According to STRIDE classification, we can easily calculate DREAD scores:

DREADScore
Damage Potential9
Reproducibility8
Exploitability10
Affected Users10
Discoverability8

Thus, the total risk score for SQL Injection is9 + 8 + 10 + 10 + 8 =45.


After this, we can useSecurity & Abuser stories,STRIDE andDREAD frameworks to structure our approach withFAIR methodology:

› Threat and Critical Asset identification

UsingSecurity & Abuser stories, we can find critical assets.

  • As a developer, I want all user input to be validated to prevent SQL Injection in the database.

From this security story we see, thatdatabase is our critical asset.
To identify the influence vectors of the threat, we will useSTRIDE.

› Contact Frequency (СF) assessment

This criteria fully depends on the functional requirements.
For instance, if our critical asset is the database and vulnerability relates to it, the frequency is actually how often will the user interact with the database.

› Calculating Probability of Action (PoA)

We can useReproducibility andExploitability scores from theDREAD framework.
For instance, SQL Injection'sReproducibility score is9, and theExploitability's score is10.

Then ourPoA would be(9 + 10) / 20 =0.95

› Threat Event Frequency (TEF)

As mentioned before,TEF =CF xPoA.
For example, if there are 100 user-side interactions with the database, then for SQL Injection:

TEF =100 x 0.95 =95 threat events per day.

› Vulnerability (Vuln) assessment

For theVulnerability assessment we can use the finalDREAD score.
SQL Injection's DREAD score is9 + 8 + 10 + 10 + 8 = 45/50, or0.99.

› Loss Event Frequency (LEF)

LEF =TEF xVuln
Then for our scenario,LEF =95 x 0.99 =94 loss events per day.

› Loss Magnitude (LM)

Loss Magnitude is calculated by summing potentialprimary andsecondary losses. At this step we don't use any threat modeling approaches, cause it requires more specific analysis.

For instance, let's calculate the imaginarySQL Injection's Loss Magnitude:

Primary Losses:
The potential cost of stolen data:50.000$
Cost of restoration works:30.000$
System downtime:10.000$
Total :90.000$

Secondary Losses:
Legal and regulatory losses:60.000$
Increased security costs:20.000$
Total:80.000$

Thus, Total Loss Magnitude is90.000$ + 80.000$ =170.000$

› Overall Risk

Potential Overall Risk = LEF(94) x LM(90.000) =8.460.000$ per day


By usingSTRIDE,DREAD,Security & Abuser Stories, andFAIR, we learned how to develop strong security requirements.

The great thing aboutFAIR is that in the end, it translates these risks intofinancial terms, making it much easier formanagement to understand the importance of each security measure. This is especially helpful since it's oftenchallenging to convey the significance of security risks totop executives.

Now after we have our security requirements and know their financial impacts, we can ensure we don't miss anything by using aSecure Requirements Traceability Matrix (SRTM).

Security Requirements Traceability Matrix (SRTM)

SRTM is a detailed document that links security requirements to their implementation and testing.

It makes sure that all security needs are handled during development, showing a clear path from the start to the final tests.

Requirement IDDescriptionSourcePriorityControl ReferenceImplementation ReferenceTesting MethodStatusComments
Unique identifier for each security requirement.Detailed description of the security requirement.Origin of the requirement (threat model, regulatory, etc)The importance of the requirementReference to design document that address requirement.Links to the code or configuration that fulfills the requirement.The method used to verify requirement (unit/integrity/penetration tests)Current status of the requirement (started/completed/in progress/verified)Additional notes or comments

Let's imagine that after using the FAIR framework with Security & Abuser Stories, we identified the following security requirements:

  • Implement 2FA to follow PCI-DSS
  • Using input validation to prevent XSS Injection
  • Logging access to sensitive assets

In this case, our matrix will look like this:

Requirement IDDescriptionSourcePriorityControl ReferenceImplementation ReferenceTesting MethodStatusComments
SR-01Implement 2-FAPCI-DSSHighData Flow Diagram DFD-01IMP-01Integration Test: IT-01CompletedSMS and Email OTPs being used
SR-02Validate inputs to prevent XSS injectionOWASP TOP 10HighDesign Document DD-02IMP-02Static Analysis: SA-01CompletedOWASP Netryx used for input validation
SR-03Log all access to sensitive dataGDPRMediumDesign Document DD-03IMP-03Penetration Testing: PT-01Not StartedSIEM tool integration planned

For building requirements traceability matrix you will use such tools likeYouTrack orJira.


Summary

In this article, we learned how important it is to build security requirements early in the SDLC. By talking to stakeholders and using methods likeSecurity & Abuser Stories, we can spot critical assets and potential threats from both user and attacker perspectives.

We usedSTRIDE to identify threats,DREAD to assess them, andFAIR methodology to look at these threats fromall angles and translate their impact intofinancial terms, making it easier for management to understand theirimportance.

Finally, we talked about the Secure Requirements Traceability Matrix (SRTM), which helps ustrack security requirements from start to finish.
This ensures thatnothing is missed and all security needs are properly addressed.

Finding and fixing security issues during the requirements phase cansave millions of dollars later on. It’smuch cheaper to address these problems early rather than after the application is built or at later SDLC steps.


OWASP is a non-profit foundation that envisions a world with no more insecure software. Our mission is to be the global open community that powers secure software through education, tools, and collaboration. We maintain hundreds of open source projects, run industry-leading educational and training conferences, and meet through over 250 chapters worldwide.

Top comments(2)

Subscribe
pic
Create template

Templates let you quickly answer FAQs or store snippets for re-use.

Dismiss
CollapseExpand
 
cybertica profile image
Yettsy
I'm an Application Security professional.#appsec
  • Location
    Denver, CO
  • Joined

This is a great resource. I’m a fan of working with our devs by using the Threat Modeling methodology by Shostack and Associates. I’ll drop a link here:shostack.org/books/threat-modeling...

CollapseExpand
 
martinbelov profile image
Martin Belov
OWASP | FinTech | Java Architect
  • Work
    OWASP Project Leader
  • Joined
• Edited on• Edited

Definitely will check the book today, thank you for sharing!

Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment'spermalink.

For further actions, you may consider blocking this person and/orreporting abuse

No more insecure software.

Joining OWASP as a member sustains our mission, and enables you to network and collaborate with other security-minded professionals, as we imagine a world with No More Insecure Software.

More fromOWASP® Foundation

DEV Community

We're a place where coders share, stay up-to-date and grow their careers.

Log in Create account

[8]ページ先頭

©2009-2025 Movatter.jp