(My) CSSLP Notes – Secure Software Design

Note: This notes were strongly inspired by the following books: CSSLP Certification All in one and Official (ISC)2 Guide to the CSSLP CBK, Second Edition

Design Process

Attack Surface Evaluation

A software or application’s attack surface is the measure of its exposure of CSSLP-logobeing exploited by a threat agent i.e., weaknesses in its entry and exit points that a malicious attacker can exploit to his or her advantage.
The attack surface evaluation attempts to enumerate the list of features that
an attacker will try to exploit.

Threat Modeling

Threat modeling is the process used to identify and document all the threats to  system.

The threat modeling process have 3 phases:

  1. model the system for which you want to find the threats.
  2. find the threats.
    1. STRIDE model.
    2. attack trees – An attack tree is a hierarchical tree-like structure, which has either an attacker’s objective (e.g., gain administrative level privilege, determine application makeup and configuration, bypass authentication mechanisms, etc.) or a type of attack
      (e.g., buffer overflow, cross site scripting, etc.) at its root node.
  3. address each threat found in the previous step. Once identified,each threat must be evaluated according to the risk attached to it. There are several ways to quantitatively or qualitatively determine the risk ranking for a threat. These range from the simple, non-scientific, Delphi heuristic methodology to more statistically sound risk ranking using the probability of impact and the business impact.
  4. document and validate.

More details about threat modeling can be found here : Threat Modeling for mere mortals and (My) OWASP BeNeLux Days 2016 Notes – Training Day.

Design Considerations

This part is linked to the Secure Software Concepts and contains how the security software concepts can be applied to have a secured application.

  • confidentiality – use cryptographic and masking techniques
  • integrity – use hashing (or hash functions), referential integrity design (uses primary keys and related foreign keys in the database to assure data integrity), resource locking (when two concurrent operations are not allowed on the same object (say a record in the database), because one of the operations locks that record from allowing any changes to it, until it completes its operation, it is referred to as resource locking), and code signing.
  • availability – replication, fail-over and scalability techniques can be used to design the software for availability.
  • authentication – use multi-factor authentication and single sign on (SSO). Rely of already existing mechanism if possible (like the ones offered by the operating system).
  • authorization – rely of already existing mechanism if possible.
  • accounting (audit) – determine of what elements should be logged and under what circumstances.
Some of the common, insecure design issues observed in software are the
  • improper implementation of least privilege
  • software fails insecurely
  • authentication mechanisms are easily bypassed
  • security through obscurity
  • improper error handling
  • weak input validation

Architecture system with secured design principles:

  • good enough security – care should be taken to ensure that the security elements are in response with the actual risk associated with the potential vulnerability; do not over-engineer.
  • least privilege – use of accounts with non-administrative abilities.
    Modular programming is a software design technique in which the entire program is broken down into smaller sub-units or modules. Each module is discrete with unitary functionality and is said to be therefore cohesive, meaning each module is designed to perform one and only one logical operation.
  • separation of duties – the programmer should not be allowed to review his own code nor should a programmer have access to deploy code to the production environment.
  • defense in depth
    • use of input validation along with prepared statements or stored
      procedures, disallowing dynamic query constructions using user
      input to defend against injection attacks.
    • disallowing active scripting in conjunction with output encoding
      and input- or request-validation to defend against Cross-Site
      Scripting (XSS).
  • fail safe
    • the user is denied access by default and the account is locked out after the maximum number (clipping level) of access attempts is tried.
    • errors and exceptions are explicitly handled and the error messages are non-verbose in nature.
    •  not designing the software to ignore the error and resume next
  • economy of mechanism – trade-off that happens between the
    usability of the software and the security features that need to be designed and built in.
    • Unnecessary functionality or unneeded security mechanisms should be avoided.
    • Strive for simplicity.
    • Strive for operational ease of use.
  • complete mediation
  • open design – the inverse of the open design principle is security through obscurity, which means that the software employs protection mechanisms whose strength is dependent on the obscurity of the design.
  • least common mechanism – mechanisms common to more than one user or process are designed not to be shared. Design should compartmentalize or isolate the code (functions) by user roles, since this increases the security of the software by limiting the exposure.
  • psychological acceptance – security principle that states that security mechanisms should be designed to maximize usage, adoption, and automatic application.The security protection mechanisms:
    • are easy to use,
    • do not affect accessibility.
    • are transparent to the user.
  • weakest link – when designing software, careful attention must be
    given so that there are no exploitable components.
  • leverage existing components – reusing tested and proven, existing libraries and common components has good security benefits.

Securing commonly used architectures

  • mainframe architecture
  • distributed architecture
    • client/server
    • p2p
  • service oriented architecture
    • An ESB is a software architectural pattern that facilitates communication between mutually interacting software application.
    • web-services
      • SOAP
      • REST
  • rich internet aplications (RIA)

Service models:

  • Infrastructure as a Service (IaaS)  -infrastructural components such as networking equipment, storage, servers and virtual machines are provided as services and managed by the cloud service provider.
  • Platform as a Service (PaaS) -in addition to infrastructural components, platform components such as operating systems, middleware and runtime are also provided as services and managed by the cloud service provider.
  • Software as a Service (SaaS) – in addition to infrastructural and platform components, data hosting and software applications are provided as services and managed by the cloud service provider.

Digital Rights Management

The expression of rights is made possible by formal language, known as Rights Expression Language (REL). Some examples of REL include the following:
  • Open Digital Rights Language (ODRL)  – A generalized, open standard under development that expresses rights using XML.
  •  eXtensible rights Markup Language (XrML) – Another generalized REL that is more abstract than ODRL. XrML is more of a meta-language that can be used for developing other RELs.
  • Publishing Requirements for Industry Standard Metadata
    (PRISM) – Unlike ODRL and XrML, PRISM can be used to express
    rights specific to a task and is used for syndication of print media
    content such as newspapers and magazine.

Trusted computing:

  • Trusted Platform Module (TPM) – specification used in personal computers and other systems to ensure protection against disclosure of sensitive or private information as well as the implementation of the specification itself.
  • Trusted Computing Base (TCB) – the set of all hardware, firmware and software components that are critical to its security.

(My) OWASP Belgium Chapter meeting notes

These are my notes of OWASP Belgium Chapter meeting of 16th of June.

OWASP Summit 2017 debrief

The talk was a debrief about the OWASP Summit 2017 which was held in London; more than 200 participants, 176  working sessions, 6 rooms. To see all the outcomes of the summit you can check the Summit Outcomes.

Some info about some of the discussed topics:

  • OWASP Top 10 2017
    • discussions about the process
    • have a broader audience, not developers only
    • more can be found here.
  • mobile security testing guide
    • guide updated
    • new content added; more topics like the best practices for use of OAUTH2 (??)
    • more can be found here.
  • define agile security practices
    • participants redefined the session goals to discuss security practices for agile development teams.
  • SAMM 2
    • more can be found here.
  • app sec education
    • what is the perfect/best curriculum to teach app sec at school.
  • security GitHub integration
    • drafted a letter to be able to  reach out github with a request for comment.
    • more can be found here.
  • threat modeling (TM) sessions
    • OWASP wants to be more visible on threat modeling.
    • TM OWASP pages revamp
    • TM templates
    • TM iot devices
    • TM diagram techniques
    • TM cheat sheets & lightweight TM
    • new slogan: “The sooner the better, never too late”
  • OWASP playbook series
    • actionable consistent process to getting started with various application security topics.
    • more can be found here, here and here.
  • OWASP Testing guide v5

Threat modeling lessons from Star Wars

This is an introductory talk about threat modeling having as goal to demystify the threat modeling is hard and can be done only by very smart/trained people.

You can start to threat model by answering 4 questions:

  1. What are you building?
    • You must represent/draw somehow the item that you want to build.
    • The DFDs (data flow diagrams) are the most common way to represent the system under build but other options are available like Swim Lanes diagrams.
    • You can use any kind of diagram that fits your needs.
  2. What can go wrong?
    • Find the threats using STRIDE, Attack Trees, CAPEC Kill chain, Check Lists.
    • A small introduction to STRIDE mnemonics was done.
  3. What are you going to do about it?
  4. Did you do an acceptable job at 1-3?

The second part of the talk was called “Top 10 lessons” and actually contained a list of 10 misconceptions about the threat modeling:

  1. Think like an attacker
    • it is very difficult to think like an attacker doesn’t help you to know what you have to do.
  2. You’re never done threat modeling
    • the 4 states of a threat modeling:
      • model
      • identify threats
      • mitigate
      • validate
  3. The way to threat model is…
    • should focus on what delivers value by helping people find good threats
    • for each threat modeling phase (model, identify, mitigate, validate) there are different techniques to do the job.
  4. Threat modeling as one skill
    • there are different techniques : DFDs , Attack trees, etc…
  5. Threat modeling is born not taught
    • threat modeling is like playing a violin; you need to train yourself and you will not be able to play correctly from the beginning.
    • practice, practice, practice
  6. The wrong focus
    • focus on the software being build not on the assets that you want to protect or by thinking about your attackers.
  7. Threat modeling is for specialists
    • threat modeling should be like version control, anyone can and should threat model.
  8. Threat modeling without context
    • see threat modeling not in a vacuum but as part of a chain, that can help different teams (dev team, operations team) to fix (security) problems.
  9. Laser like focus on threats
    • requirements drive threats.
    • threats expose requirements.
    • threats needs mitigations.
    • un-mitigatable threats drive requirements.
  10. Threat modeling at the wrong time
    • you must start threat modeling early.

Main take-aways: anyone can threat model and should; all the necessary technique can be learned.

5 (software) security books that every (software) developer should read

I must admit that the title is a little bit catchy; a better title would have been “5 software security books that every developer should be aware of“. Depending on your interest you might want to read entirely these books or you could just know that they exists. There must be tons of software security books on the market but this is my short list of books about software security that I think that each developer that is interested in software security should be aware of.

Hacking – the art of exploitation This book explains the basics of different hacking techniques, especially the non-web hacking techniques: how to find vulnerabilities (and defend against)  like buffer overflow or stack-based buffer overflow , how to write shellcodes, some basic concepts on cryptography and attacks linked to the cryptography like the man-in-the-middle attack of an SSL connection. The author tried to make the text easy for non-technical peoples but some programming experience is required (ideally C/C++) in order to get the best of this book. You can see my full review of the book here.

Iron-Clad Java: Building secure web applications This book presents the hacking techniques and the countermeasures for the web applications; you can see this books as complementary of the previous one; the first one contains the non-web hacking techniques, this one contains (only) web hacking techniques; XSS, CSRF, how to protect data at rest, SQL injection and other types of injections attacks. In order to get the most of the book some Java knowledge is required. You can see my full review of the book here.

Software Security-Building security in  This books explains how to introduce the security into the SDLC; how to introduce abuse cases and security requirements in the requirements phase, how to introduce risk analysis (also known as Threat Modeling) in the design phase and software qualification phase. I really think that each software developer should at least read the first chapter of the book where the authors explains why the old way of securing application (seeing the software applications as “black boxes” than can be protected using firewalls and IDS/IPS) it cannot work anymore in the today software landscape. You can see my full review of the book here: Part 1, Part 2 and Part 3.

The Tangled Web: A Guide to Securing Modern Web Applications This is another technical book about security on which you will not see a single line of code (the Software Security-Building security in is another one) but it highly instructive especially if you are a web developer. The book presents all the “bricks” of the today Internet: HTTP, WWW, HTML, Cookies, Scripting languages, how these bricks are implemented in different browsers and especially how the browsers are implementing the security mechanism against rogue applications. You can see my full review of the book here.

Threat modeling – designing for security Threat modeling techniques (also known as Architectural Risk Analysis) were around for some time but what it has changed in the last years is the accessibility of these technique for the software developers.  This book is one of the reasons for which the threat modeling is accessible to the developers. The book is very dense but it  suppose that you have no knowledge about the subject. If you are interested in the threat modeling topic you can check this ticket: threat modeling for mere mortals.

Book review: Software Security: Building Security in – Part II: Seven Touchpoints for Software Security

This is a review of the second part of the Software Security: Building Security in book.

Chapter 3: Introduction to Software Security TouchpointsSecuritySoftwareBookCover

This is an introductory chapter for the second part of the book. A very brief description is made for every security touch point.

Each one of the touchpoints are applied on a specific artifact and each touchpoints represents either a destructive or constructive activity. Based on the author experience, the ideal order based on effectiveness in which the touch points should be implemented is the following one:

  1. Code Review (Tools). Artifact: code. Constructive activity.
  2. Architectural Risk Analysis. Artifact: design and specification. Constructive activity.
  3. Penetration Testing. Artifact: system in its environment. Destructive activity
  4. Risk-Based Security Testing. Artifact system. Mix between destructive and constructive activities
  5. Abuse Cases. Artifact: requirements and use cases. Predominant destructive activity.
  6. Security Requirements. Artifact: requirements. Constructive activity.
  7. Security Operations. Artifact: fielded system. Constructive activity.

Another idea to mention that is worth mentioning is that the author propose to add the securty aspects as soon as possible in the software development cycle;moving left as much as possible (see the next figure that pictures the applicability of the touchpoints in the development cycle); for example it’s much better to integrate security in the requirements or architecture and design (using the risk analysis and abuse cases touchpoints) rather than waiting for the penetration testing to find the problems.

Security touchpoints

Security touchpoints

Chapter 4: Code review with a tool

For the author the code review is essential in finding security problems early in the process. The tools (the static analysis tools) can help the user to make a better job, but the user should also try to understand the output from the tool; it’s very important to not just expect that the tool will find all the security problems with no further analysis.

In the chapter a few tools (commercial or not) are named, like CQual, xg++, BOON, RATS, Fortify (which have his own paragraph) but the most important part is the list of key characteristics that a good analysis tool should have and some of the characteristics to avoid.

The key characteristics of a static analysis tool:

  • be designed for security
  • support multi tiers architecture
  • be extensible
  • be useful for security analysts and developers
  • support existing development processes

The key characteristics of a static analysis tool to avoid:

  • too many false positives
  • spotty integration with the IDE
  • single-minded support for C language

Chapter 5: Architectural Risk Analysis

Around 50% of the security problems are the result of design flows, so performing an architecture risk analysis at design level is an important part of a solid software security program.

In the beginning of the chapter the author present very briefly some existing security risk analysis methodologies: STRIDE (Microsoft), OCTAVE (Operational Critical Threat, Asset and Vulnerability Evaluation), COBIT (Control Objectives for Information and Related Technologies).

Two things are very important for the author; the ara (architectural risk analysis) must be integrated in and with the Risk Management Framework (presented briefly in Book review: Software Security: Building Security in – Part I: Software Security Fundamentals), and we must have a “forest-level” view of the system.

In the last part of the chapter the author present the Cigital way of making architectural risk analysis. The process has 3 steps:

  1. attack resistance analysis – have as goal to define how the system should behave against known attacks.
  2. ambiguity analysis – have as goal to discover new types of attacks or risks, so it relies heavily on the experience of the persons performing the analysis.
  3. weakness analysis – have as goal to understand end asses the impact of external software dependencies.
Process diagram for architectural risk analysis

Process diagram for architectural risk analysis

Chapter 6: Software Penetration Testing

The chapter starts by presenting how the penetration testing is done today. For the author, the penetration tests are misused and are used as a “feel-good exercise in pretend security”. The main problem is that the penetration tests results cannot guarantee that the system is secured after all the found vulnerabilities had been fixed and the findings are treated as a final list of issues to be fixed.

So, for the author the penetration tests are best suited to probing (live like) configuration problems and other environmental factors that deeply impact software security. Another idea is to use the architectural risk analysis as a driver for  the penetration tests (the risk analysis could point to more weak part(s) of the system, or can give some attack angles). Another idea, is to treat the findings as a representative sample of faults in the system and all the findings should be incorporated back into the development cycle.

Chapter 7: Risk-Based Security Testing

Security testing should start as the feature or component/unit level and (as the penetration testing) should use the items from the architectural risk analysis to identify risks. Also the security testing should continue at system level and should be directed at properties of the integrated software system. Basically all the tests types that exist today (unit tests, integration tests) should also have a security component and a security mindset applied.

The security testing should involve two approaches:

  • functional security testing: testing security mechanism to ensure that their functionality is properly implemented (kind of white hat philosophy).
  • adversarial security testing: tests that are simulating the attacker’s approach (kind of black hat philosophy).

For the author the penetration tests represents a outside->in type of approach, the security testing represents an inside->out approach focusing on the software products “guts”.

Chapter 8: Abuse Case Development

The abuse case development is done in the requirements phase and it is intimately linked to the requirements and use cases. The basic idea is that as we define requirements that suppose to express how the system should behave under a correct usage, we should also define how the system should behave if it’s abused.

This is the process that is proposed by the author to build abuse cases.

Diagram for building abuse cases

Diagram for building abuse cases

The abuse cases are creating using two sources, the anti-requirements (things that you don’t want your software to do) and attack models, which are known attacks or attack types that can apply to your system. Once they are done, the abuse cases can be used as entry point for security testing and especially for the architectural risk analysis.

Chapter 9: Software Security Meets Security Operations

The main idea is that the security operations peoples and software developers should work together and each category can (and should) learn from the other (category).

The security operation peoples have the security mindset and can use this mindset and their experience in some of the touchpoints presented previously; mainly abuse cased, security testing, architectural risk analysis and penetration testing.

(My) OWASP BeNeLux Days 2016 Notes – Training Day

Here are my quick notes from the OWASP BeNeLux Days 2016 (#owaspbnl16) training day on threat modeling presented by Sebastien Deleersnyder. All the training slides can be found OWASP_BeNeLux_2016_logohere.

Definition of threat modeling:  activity of identifying and managing application threats. Threat Modeling should be ideally done on requirements phase of the project. The goal of threat modeling is to uncover flaws in the design of different features.

Threat modeling stages:

  • diagram
    • usually the Data Flow Diagrams are used.
    • different diagram layers
      • context diagram – very high level; entire component
      • level 1 diagram – high level, one per feature
      • level 2 diagram – detailed sub-components
  • identify threats
    • identification can be done using the STRIDE Threat Model
    • rank the threats by risk, to be sure that you are focus on mitigating the most important ones.
    • how the STRIDE elements are applied to each element of the Data flow Diagram:STRIDE_on_DFD
  • mitigate the threats
    • mitigation advice : keep it simple and do not reinvent the wheel.
    • leverage proven best practices
  • validate
    • does the diagram match final code ?
    • is each threat mitigated ?

The training also had some hands-on exercises. I just upload here the last exercise representing the STRIDE analysis of an Internet of Things (IoT) deployment:

DFD with Stride Example

DFD with Stride Example

Some tools that can be used to help:

For me the training was a very good introduction to threat modeling and contained a lot of “from the tranches” tips and advices.

Book review: Software Security: Building Security in – Part I: Software Security Fundamentals

This is a review of the first part of the Software Security: Building Security in book.

Chapter 1: Defining a disciplineSecuritySoftwareBookCover

This chapter lands out the landscape for the entire book; the author presents his view on the today challenges in having secure holes free software.
In the today world, the software is everywhere, from microwaves oven to nuclear power-stations, so the “old view” of seeing the software applications as “black boxes” than can be protected using firewalls and IDS/IPS it’s not valid anymore.

And just to make the problem even harder, the computing systems and the software applications are more and more interconnected must be extensible and have more and more complex features.

The author propose a taxonomy of the security problems that can be affected the software applications:

  • defect: a defect is a problem that may lie dormant in software only to surface in a fielded system with major consequences.
  • bug: an implementation-level software problem; only fairy simple implementations errors. A large panel of tools are capable to detect a range of implementation bugs.
  • flaw: a problem at a deeper level; a flow is something that can be present at the code level but it can be also present or absent at the design level. What is very important to remark is that the automated technologies to detect design-level flows do not yet exist, through manual risk-analysis can identity flows.
  • risk: flaws and bugs lead to risk. Risk capture the chance that a flaw or a bug will impact the purpose of a software.

In order to solve the problem of the software security, the author propose a cultural shift based on three pillars: applied risk management, software security touchpoints and knowledge.

Pillar 1 Applied Risk Management

For the author under the risk management names there 2 different parts; the application of risk analysis at the architectural level (also known as threat modeling or security design analysis or architectural risk analysis) and tracking and mitigating risks as a full life-cycle activity (the author call this approach, the risk management framework – RMF).

Pillar 2 Software security Touchpoints.

Touchpoint it’s just a fancy word for “best practices”. Today there are best practices for design and coding of software system and as the security became a property of a software system, then best practices should also be used to tackle the security problems.Here are the (seven) touch points and where exactly are applied in the development process.

Security Touchpoints

Security Touchpoints

The idea is to introduce as deeply as possible the touch points in the development process. The part 2 of the book is dedicated to the touchpoints.

Pillar 3 Knowledge

For the author the knowledge management and training should play a central role in encapsulation and sharing the security knowledge.The software security knowledge can be organized into seven knowledge catalogs:

  • principles
  • guideline
  • rules
  • vulnerabilities
  • exploits
  • attack patterns
  • historical risks

How to build the security knowledge is treated in the part 3 of the book.

Chapter 2: A risk management framework

This chapter presents in more details a framework to mitigate the risks as a full lifecycle activity; the author calls this framework the RMF (risk Management Framework).

The purpose of the RMF is to allow a consistent and repeatable expert-driven approach to risk management but the main goal is to find, rank, track and understand the software security risks and how these security risks can affect the critical business decisions.

Risk Management Analysis steps

Risk Management Analysis steps

The RMF consists of five steps:

  1. understand the business context The goal of this step is describe the business goals in order to understand the     types of software risks to care about.
  2. identify the business and technical risks. Business risk identification helps to define and steer the use of particular technological methods for measuring and mitigating software risk.The technical risks should be identified and mapped (through business risk) to business goals.
  3. synthesize and rank the risks. The ranking of the risks should take in account which business goals are the most important, which business goals are immediately threatened and how the technical risks will impact the business.
  4. define a risk mitigation strategy. Once the risks have been identified, the mitigation strategy should take into account cost, implementation time, likelihood of success and the impact
  5. carry out required fixes and validate that they are correct. This step represents the execution of the risk mitigation strategy; some metrics should be defined to measure the progress against risks, open risks remaining.

Even if the framework steps are presented sequentially, in practice the steps can overlap and can occur in parallel with standards software development activities. Actually the RMF can be applied at several different level; project level, software lifecycle phase level, requirement analysis, use case analysis level.

Threat Modeling for mere mortals

This ticket is an introduction to the threat modeling in the context of software development.


In the context of the IT security, threat modeling is a structured approach that enables you to identify, quantify, and (eventually) address the security risks associated with an application.

A more formal definition

 For somebody having the security mindset the previous definition might be not very formal; let’s try a new definition but before let’s introduce some new definitions:

  • asset  – an asset is what it must be protected. In the context of software, it could be the infrastructure, the software installed, the user data.
  • vulnerability – a vulnerability is a weakness that can be present in one of the assets.
  • threat – anything that can exploit a vulnerability and obtain, damage, or destroy an asset.
  • risk – the potential for loss, damage or destruction of an asset as a result of a threat exploiting a vulnerability.

So, the threat modeling (also sometimes called risk analysis or architectural risk analysis) is the process integrated in the SDLC (Software Development Life Cycle) having as goal to find and address (mitigate, eliminate, transfer or accept) all possible risks for a specific software functionality.

The threat modeling should be applied in the SDLC as early as possible, ideally in the requirements phase (the earliest the problems will be found the easiest would be to fix) and could even modify or adjust the requirements.

The threat modeling process

The threat modeling process have 3 phases:

  1. model the system for which you want to find the threats.
  2. find the threats.
  3. address each threat found in the previous step.

1. Model the system

The goal is to have a diagram representing the system under process. In the specialized literature, the Data Flow Diagrams are very often used because it easily represent all interaction points that an adversary can leverage to attack a system and also show how data moves through the system. The diagram could be improved adding “trust boundaries”, boundaries where data changes its level of “trust”.

2. Find the threats

After having a diagram of the system then you can ask how an attacher could attack the system. There are different approached that can be used to find “what can go wrong”:

  • STRIDE –this methodology (created by Microsoft) classifies threats into 6 groups:Spoofing, Tampering, Repudiation,
    Information Disclosure, Denial of Service and Elevation of Privilege.
    Threat Modeling is executed by looking at each component of the system and determines if any threats that fall into these categories exist for that component and its relationships to the rest of the system.
  • Threat/Attack libraries – libraries containing common and already known attacks. Threat library can be a quick way to take advantage of industry security knowledge (helping teams that lack sufficient knowledge themselves). Some examples of Threat libraries: OWASP Top Ten, CAPEC, CWE.
  •  Misuse cases – These cases should be derived from the requirements of the system, and illustrate ways in which protective measures could be bypassed, or areas where there are none.

3. Addressing the threats

Once identified,each threat must be evaluated according to the risk attached to it (using a risk rating system such as Common Vulnerability Scoring System), the resources available,the business case and the system requirements.

This will help prioritize the order in which threats should be addressed during development, as well as the costs involved in the mitigation  (if you decide to mitigate it).

Not all the treats can be mitigated. It is also possible to decide that some of them should be eliminated (meaning that the feature of the functionality that if affected should be removed), transfered (let somebody or something else to handle the risk) or accepted (accept the risk that could happen).

If you want to go further

If you want to go further and dig deeper hare are some links that I found useful: