In today’s world application security has been a very important role in Network Security. Every day hackers are using new technologies and techniques to access important data and do the other petty activities at the network application .and in today’s world. It is very important to secure applications is most use in today’s generation and the other important data. This approach to application security has proven to be disastrous: many vulnerabilities have gone undetected allowing applications to be attacked and damaged. That’s why the network and application security is very important for today’s world. So the one method being developed to implement application and network security in the design process is threat modeling. Threat modeling is a process for optimizing network security by describing objectives and vulnerabilities and is used to identify the reasons and methods that an attacker would use to identify vulnerabilities or threats in the system. The basic is to threat modeling is to determine where the most efforts should be applied to keep a system secure. Threat modeling creates a security profile for each application, identifying hidden threats. Identifies a logical thought process in defining the security of a system.

So What the threat modeling covers

  • Assets _ The main reason for threat exist is ASSETS. The hacker’s main goal to access company assets. Assets can be physical or abstract many examples like employee safety, company’s reputation, etc., so the security team needs to find that which assets need to be protected from unknown users.
  • Threats _ The threat model is a characterization of the many groups of persons who may be able to attack your application. These groups should include insiders and outsider. And What may an attacker do to the system?
  • Vulnerabilities Once you know the security in the application, you can then analyze for new vulnerabilities. The search is for vulnerabilities that connect the possible attacks you’ve identified to the negative reaction you’ve identified

How to Create a Threat Model

The five major threat modeling steps are shown in figure

1. You should continuously refine your threat model by performing again and again steps 2 through step 5.

The five threat modeling steps are:

  • Step 1: Identify security objectives. Clear objectives help you to see the threat modeling activity and define that how much effort to spend on subsequent steps.
  • Step 2: Create an application overview. Listing the application’s main characteristics and actors helps to identify relevant threats during step 4.
  • Step 3: Decompose your application. The detailing of the mechanics of your application helps you to disclose more relevant and more detailed threats.
  • Step 4: Identify threats. Use steps 2 and 3 to find threats relevant to your application scheme and situation.
  • Step 5: Identify vulnerabilities. Use vulnerability categories to find those areas where mistakes are most generally made.

Identify Assets

  • Entry and exit points: – Where the data enters or exit in the application that place called entry or exit point. When you are finding entry/exit points. The following things have been identified and collected.
  • Name: – Assign a name to the entry/exit point and identify it reasons.
  • Description: – write a description that shows that what the place entry/exit taking point. And identify the trust levels that exist that point
  • Numerical ID: – Every Entry and exit point have a numerical ID for cross-referencing assigned to it with threats and vulnerabilities

The Trust Levels: –

The trust levels are cross-referenced with the entry points and assets. This allows us to define the access rights or privileges required at each entry point. Example, a change in access control levels in your application where a specific role or privilege level is required to access a resource or operation, would be a change in trust level.

The following things have been identified and collected when identifying the trust level.

  • ID: – A creative number is assigned to cross-reference with entry and exit point and assets.
  • Name: – Creative a name to the trust level.
  • Description: – Create a useful description that has a more detailing to explain the trust level and its purpose.

Identify Threat

Identification of threat might be harmful or affect your system, and you have to compromise your assets. Identification threat is the key to a secure system. The identifying process is analyzing each entry/exit point and how it might be attacked.

To start this identification process 1st Make a powerful team bring some members of the development and test team together the team consists of application architects, security professionals, developers, testers, and system administrators.
This is a simple way to identify potential threats.

Threats mainly used to protect target assets and threats the threat model documents also represents that threat is cross –referenced with the assets. Microsoft suggests approaches for writing up threats is a threat graph, as shown in Figure 2

Fig 2

A threat graph shows more information quickly, but it takes longer to construct,

  1. Attacker may be able to read other user’s messages
  2. User may not have logged off on a shared PC
  3. Data validation may allow SQL injection
  4. Implement data validation
  5. Authorization may fail, allowing unauthorized access
  6. Implement authorization checks
  7. Browser cache may contain contents of message
  8. Implement anti-caching directive in HTTP headers
  9. If eavesdropping risk is high, use SSL

Another approaches by Microsoft for writing up threats  is a structured list The following categories use to understand who might attack the application

  • Accidental Discovery: Done by regular users who make a functional mistake in your application, just using a web browser, and gains access to privileged information or functionality.
  • Automated Malware: Programs or scripts, where are searching for known vulnerabilities, and then report them back to a central collection site.
  • The Curious Attacker: Persons who are a security researcher or a regular user who are notices something wrong with the application, and decides to follow further.
  • The Motivated Attacker: An inside staff member with inside knowledge or a paid professional attacker.
  • Organized Crime: Criminals are seeking high stake payouts, such as cracking e-commerce or corporate banking applications, for financial gain.


So to manage threat process, the great idea is to use threat categorization framework like stride. C STRIDE outlines six common types of threats, and the security controls which are responsible for protecting against them This is a goal-based approach where you consider the goals of an attacker. Using the stride very useful in the identification of threats by classifying attacker goals like: –

  • Spoofing identity: – A Threat action aimed to access and use another user’s password and username. = Security Control: – Authentication
  • .
  • Tampering with data: – A Threat action aimed to change and modify data within the system to achieve malicious goals. And modify data transit between two computers in an open network. Such like The Internet. = Security Control: – Integrity
  • Repudiation: – A Threat action aimed to do some illegal operation in a system. = Security Control: – Non-Repudiation
  • Information Disclosure: – A Threat action aimed to expose the protected data that data which is not allowed to access to a user. = Security Control: – Confidentiality
    Denial of service: – Threat aimed to make a web server currently unavailable or unusable. = Security Control: – Availability
  • Elevation of Privilege: – Threat aimed for gaining unauthorized access to information or gain privileged access to resources and to compromise a system = Security Control: – Authorization

Security Control

The primary focus of the code review is to ensure that these security controls are in place, that they work properly, and that they are correctly invoked in all the necessary places. The checklist below can help to ensure that all the likely risks have been considered.

The design and implementation approaches used for input validation, authentication, authorization, configuration management, and the remaining areas by doing this, you create a security profile for the application.

Category Considerations
Input validation Is all input data validated and DV mechanism is present?

Make sure that input is not modified by a malicious user and that attacker not inject commands or malicious data into the application. Such as HTTP headers, input fields, hidden fields, drop down lists, and other web components are validated properly.

The proper length checks on all input exist.

Make sure that the data is valid on the server side.

Can data in the database Well-formed and contained only known good chars.

A centralized model or decentralized model is used. Where in data validation.

Assure in the validation model there are no backdoors.

Authentication Ensure that credentials secured if they are passed over the network?

Fortify strong account policies used?

Ensure that strong passwords enforced?

Ensure you are using certificates?

Assure all password verifiers used for user passwords?

Backdoors are not present in production code

Authorization Assure that there are authorization mechanism in place and work properly.

Ensure that What gatekeepers are used at the entry points of the application?

Ensure that authorization is checked on every request.

Assure authorization fail securely and only allow access upon successful confirmation of credentials.

Cookie management Ensure that sensitive information is not comprised.

Ensure that proper encryption is in use.

Assure the session data is being validated.

Assure that cookies contain some private information. And entire cookies are encrypted

Identify all cookies being used by the application, their name, and why they are needed.

Sensitive data Examine What sensitive data is handled by the application?

What type of encryption is used

Examine how are encryption keys secured?

Session management Examine How is session generated?  Unauthenticated and authenticated.

Examine how the application tracks sessions

Examine How is persistent session state secured as it crosses the network?

Determine the session HTTP inactivity timeout.

Determine how multithreaded/multi-user session management is performed

Examine how the logout functionality functions

Cryptography Examine algorithms and cryptographic techniques are used

Does the application put its encryption into action?

How often are keys recycled?

Ensure the application is Putting known good cryptographic methods.

Ensure No important data has been transferred internally or externally

Secure code


Examine all memory allocations/de-allocations.

Examine the file structure.

Examine any components that should not be directly accessible available to the user?

Assure that no development environment kit is contained in the build directories.

Exception management Determine how the application handle error conditions

Assure that exceptions and error conditions are properly working.

Ensure resources are released if an error occurs. And no system errors can be returned to the user.

Ensure that the application fails in a secure manner.

Auditing and logging Determine your application audit activity across all tiers on all servers?

Examine How are log files secured?

Make sure no sensitive information is logged in the event of error.

E.g. cookies, HTTP “GET” method, authentication credentials.

Make sure that successful and unsuccessful authentication is logged, and application errors are logged


A list of threats that you are applying in your application. You rate the threats based on the risks they pose. This provides you to address the threat where the most risk first, and then you can resolve the other is not possible to address all of the identity threats, and you have to ignore some. Because the chance of them happen is less and the damage that would is minimum.

Risk = Probability * Damage Potential

The formula shows that the risk posed by the same threat which is equal to the probability of the occurring threat is multiplied by the damage potential, which shows the result to your system if an attack were to happen. So you can use a scale 1 to 10 to calculate the probability and similarly, use the scale 1 to 10 for damage potential.

Where in scale 1 represent a threat that is very low chances to happen and 10 represented a threat is very near definitely.

Let’s think with an Example: – If Probability=10 and Damage Potential=1, then Risk = 10 * 1 = 10. If Probability=1 and Damage Potential=10, then Risk = 1 * 10 = 10.

Another way to analyzing the threats rank the threat and determine the risk of the threat and the conditions by DREAD.


Using DREAD is classification scheme for determine and comparing the amount of risk invented by each evaluated threat. The DREAD model is documented insecure. While using the DREAD model, a threat modeling team calculate the security risk in a numeric value Which is assigned to each in five categories.


The calculation shows the number between 0 to 10 that number shows the amount of risk the higher number shows, the more risk

Damage potential – Ranks the damage caused when the threat exploit

Example: –

  • 0 = Nothing
  • 5 = Individual user data is affected.
  • 10 = Complete system or data destroyed

Reproducibility – How can easily reproduce the threat Exploit

Example: –

  • 0 = hard or impossible, even for administrator also.
  • 5 = One or two steps required, by an authorized user.
  • 10 = Need a web browser and the address bar only, without authentication.

Exploitability – Assign the numbers required to Exploit the threat

Example: –

  • 0 = Needed Advanced programming and networking knowledge, with custom or advanced attack tools.
  • 5 = Malware exists on the Internet, or an exploit is easily performed, using available attack tools.
  • 10 = Just a web browser

Affected Users – if an exploit became widely available many users will be affected

Example: –

How many users will be affected?

  • 0 = None
  • 5 = Some users, average
  • 10 = All users

Discoverability – It is easy to discover external security researchers will find a threat.

Example: –

  • 0 = Very hard needed source code or administrative access.
  • 5 = Can figure it out by guessing.
  • 10 = In the web browser address bar The information is visible in a form.

An example DREAD rating for both threats:

Threat D R E A D Total Rating
Attacker obtains authentication credentials by monitoring the network. 3 3 2 2 2 12 High
SQL commands injected into application. 3 3 3 3 2 14 High


DFDs helps us to learn and a better understanding of the application by giving a visual representation that shows how the application data work. As we know that visuals have more ability to understand and learn the Except reading or listening. So what DFDs does the high-level DFDs aim is to focus on that data which is moving through the application and see what happens to the data as it moves.
 The lower level iterations
aim only on specific processes. The six basic shapes used in a DFDs are listed below with the definitions.


The external entity shape is used to interacts at a system entry/exit point. And represent the entity outside the application


The process shape represents a task that performs some action A task that handles data within the application. The task may process the data or perform an action based on the data.

Multiple Process

.Multiprocess is the collection of the subprocess.

Data Store

The data store represent where the data is stored. This may only interact with multiple processes.

Data Flow

The data flow does the movement of the data in the application. Where the arrow moves shows the direction of the data movement.

Trust or privilege Boundary

Trust boundary is the boundary between trust level or the data flow through the application.

The overall context diagram. Makes a DFD in fig 1.1

Figure 1.1

The system is representing a single multiprocessor entry/exit point. This is the top level, and DFD Is presenting another process.

Threat Trees

Built a Threat tree is the well-known method to identify possible failure modes and vulnerable areas in the system. Threat tree also determines the valid attacks paths in the system and this method is also well suited for determining computer system security issues. A threat is a way of collecting and documenting the potential attacks on your system in a structured manner. And the structure gives you the various attack address that the attacker uses to shut the system.

In a threat modeling document, there are two ways to expressed the threat trees first is graphically and the second one is text. A threat tree has a node that is root node or threat and child node(S). If you are willing to find the treat use Child node because each child node represents the condition, need to identify the threat. As we know that threat tree finds vulnerabilities but if we want to identify the threat vulnerabilities begin at a node Without any children and traverse it up to the root threat.

By creating attack trees, you create a useful representation of security issues that helps and focus on efforts. Test team and the developer make test plans for security design. And architects or developer evaluate the security cost of each approach.

Let’s think of an example of information disclosure threat. Suppose a company has an important data, and the data only flow between the user (Employees) and computer system inside the data center and back. Let’s assume that the data is payroll data and the payroll data is very important to the company as well as the users and that data confidential between the company and the user. So you don’t want a malicious employee or and another unknown user to look someone payroll information, or an attacker may view the in some ways. That means you have to protect your data with the unknown eyes. So use a network protocol analyzer, or sniffer to protect the data.

See A threat tree outlines how an attacker views another user’s confidential data.

1.0 View confidential payroll data on the wire
    1.1 HTTP traffic is unprotected (AND)
        1.2 Attacker views traffic
            1.2.1 Sniff network traffic with protocol analyzer
            1.2.2 Listen to router traffic
       Router is unpatched (AND)
       Compromise router
       Guess router password
        1.2.3 Compromise switch
   Various switch attacks

An Example of Attack Goal #1: Gain SCADA System Access

The following attack tree outlines the methods of gaining access to the SCADA system or Process Control Network (PCN).

Attack: Gain SCADA Access (Difficulty=2) OR

1. Gain physical access to remote field site equipment 2

2. Gain access to SCADA link media 2 OR

2.1. Intercept wiring leaving building or compound 2

2.2. Intercept SCADA links in public carr. 3

2.3. Intercept SCADA link over radio link 3

3. Gain local Process Control Network (PCN) access 2


3.1. Gain physical access to device on the PCN 3

3.2. Gain dial-in access to device on PCN 2

3.3. Gain wireless access to the PCN 2

4. Gain remote access to PCN via IT network 3


4.1. Gain Network Access to IT network 3


4.1.1. Gain physical access to IT network 3

4.1.2. Gain remote access to IT net 3

4.2. Compromise or bypass connection device between IT and PCN 3

5. Gain access via semi-trusted 3rd party 2


5.1. Gain access to semi-trusted 3rd party network 2


5.1.1. Gain physical access to semi-trusted 3rd party 3

5.1.2. Gain remote access to semi-trusted 3rd party 2

5.2. Compromise protection between 3rd party system and PCN 2

6. Gain remote access via untrusted Internet3


6.1. Compromise connection device between The Internet and IT 3

6.2. Compromise or bypass connection device between IT and PCN 2

This illustrates one of the flexible aspects of attack trees: even the initial set of attacker goals are logically related.

Attack Goal #2: Identify MODBUS Device

After access to the SCADA systems is achieved, the next requirement for an attacker is to identify devices that may be vulnerable. The attack tree for identifying MODBUS devices on an SCADA system and also find relationships between technical (scanning) and non-technical (social engineering) attacks.

1. Social Engineering (e.g. pretend to be PLC manufacture’s service engineer) 2

2. TCP/UDP Port Scan for Port 502 2


2.1. Gain local PCN network access (nonblind) 2

2.2. Deploy TCP/UDP scanning tool 1

3. MODBUS Message Scan (only against slave) 2


3.1. Gain access to remote site or SCADA transmission system 2

3.2. Deploy MODBUS Message Scanning Tool 2

4. Management/Application Protocol Scan 2


4.1. Gain local PCN access (non-blind) 2

4.2. Deploy Fingerprinting Tool 2


4.2.1. Scan HTTP/SNMP/Telnet port for identifying characteristics 2

4.2.2. Scan other identifying ports 2

5. Sniff existing MODBUS session 2


5.1. Sniff via compromised master 2


5.1.1. Compromise Master (goal #11) 2

5.1.2. Install packet capture util. 2

5.2. Sniff via intercepted SCADA media 2


5.2.1. Gain access to SCADA link media 2

5.2.2. Install protocol capture tool 1

Attack Goal #11: Compromise Master

the attacker is looking to steal information, disable the SCADA system or attack other corporate assets.

Attack: Compromise Master (Difficulty=2)


1.Physical Attack on Master 3


1.1. Gain Physical Access to the Master 3

1.2. Determine Administrator Password 2

2. Network Attack on Master 2

2.1. Gain Non-Blind Network Access 2


2.1.1. Compromise Master O/S 2

2.1.2. Compromise Primary HMI Application on Master 3

2.1.3. Compromise Secondary Application on Master 2

2.2. Compromise Master via Slave 3


2.2.1. Gain Physical Access to Slave 2

AND Disable Real Slave Device 1 Deploy Rogue Slave Respond to MODBUS Requests from Master 2 Corrupt Master with invalid slave response 3 Load Shell App to Master 3

2.2.2. Gain Access to SCADA Link Media 2

AND Disable Real Slave Device 2 Deploy Rogue Slave Respond to MODBUS Requests from Master 2 Corrupt Master with invalid slave response 3 Load Shell App to Master 3

Windows-based or UNIXbased masters these technology vulnerabilities are well known by the hacker community and relatively easy to exploit.

Start building an attack tree by creating root nodes that represent the goals of the attacker. Then add the leaf nodes, which are the attack method that represents unique attacks. Figure 3.5 shows a simple example.

Ethical Hacking Training – Resources (InfoSec)

 Attack tree using an outline such as the one shown below.

1. Goal One

1.1 Sub-goal one

1.2 Sub-goal two

2. Goal Two

2.1 Sub-goal one

2.2 Sub-goal two

Example for outline approach in action:

Threat #1 Attacker obtains authentication credentials by monitoring the network

1.1 Clear text credentials sent over the network AND

1.2 Attacker uses network
monitoring tools

1.2.1 Attacker recognizes credential data

Attack Patterns

Attack pattern is a general representation of the naturally coming attacks those attack can occur in a different of variety contexts. This method shows you the goal of the attacker and as well as shows or defines the conditions that must exist for the attack occur, the result of the attack and the steps needed to perform the attack. As we read out that the STRIDE is focused on the goals of the attacker, but STRIDE is not focused on the techniques they are using. So the attack pattern helps us to define the techniques

The code – injection is a good example of an attack pattern that is used to describe code injection attacks in a generic way. Attack pattern helps to describe the code – injection attack pattern

Code injection attack pattern

ATTACK GOALS = Code performance or command

Required condition = Weak input validation code has sufficient faculty on the server

Attack technique = 1. Identity program with a correct input vulnerability, 2. Create code using the security context of the target application., 3 Construct input value to insert code into the address space, 4. force a stack corruption that causes application execution to jump to the injected code.


Attack result = Code and perform a malicious action by the attackers runs.


Trike is an open source threat modeling methodology and tool. The project began in 2006 as an attempt to improve the efficiency and effectiveness of existing threat modeling methodologies and is being actively used and developed. Trike is a threat framework like similar like Microsoft threat modeling processes. So why Trike differs from STRIDE/DREAD Because trike uses a risk-based approach to well-defined Execution, threat, and risk models From the Trike paper, Trike’s goals are:

With assistance from the system stakeholders, to ensure that the risk this system entails to each asset is acceptable to all stakeholders.

Be skilled to tell whether we have done this

Tell us that what we have done and its effects on the stakeholders

Authorized to understand and reduce the risk for stakeholders.

There have been three versions of the Trike methodology: –

Version 1 = Highlights include automatic threat generation at the requirements level and automatic generation of attack is white paper documented

Version 1.5 = Highlights include improved automatic threat generation at the requirements level, security objectives, the complete absence of threat trees, and HAZOP analysis. . It is practically documented

Version 2 =   Highlights include semi-automatic threat generation at the architectural level and attack chaining. It is under active development.


An Operationally Critical Threat, Asset and Vulnerability Evaluation (OCTAVE) is a security framework for identifying, addressing and managing information security assessments and risk-based planning. OCTAVE is a heavyweight risk methodology. OCTAVE works only for organizational risk, not for technical risk. Octave has two versions for large organizations Full OCTAVE, and OCTAVE-S for small organizations, OCTAVE mainly targeted at organization-related security risks, not on technological risks.

Building an asset-based threat profile
This identifies critical assets and the security requirements for each one of them. A threat profile for all identified assets is created.

Identifying infrastructure vulnerabilities
This identifying network access paths critical assets classifying technology components and the area to which those components are secured against network vulnerabilities and attacks. 

Develop a security strategy and plan
Based on the data collected in previous phases, a plan is created to address the risks which is associated with the assets.

OCTAVE is popular with many sites and is useful when:

Measuring and Documenting business risk become timely

IT security risk Documenting and measuring the overall, it relates to the corporate IT risk management, becomes necessary.

When documenting risks surrounding complete systems becomes necessary

The limitations of OCTAVE are:

OCTAVE is opposite with AS/NZS 4360, its direction likelihood = 1 (It assumes a threat will always occur). And this is the unsuitable for many organization and that why they don’t prefer OCTAVE

OCTAVE is large and complex, with many worksheets and practices to implement. Consisting of 18 volumes

It does not give the list of “out of the box” practice for evaluating and reduce the web application Risks.

It fails to take threat risk modeling into inspection, and this step is most important at all stages by all the participants to reduce the overall risk.

AS/NZS 4360:2004 Risk Management

The Australian/New Zealand Standard AS/NZS 4360, was first published in 1999 and revised in 2004, AS/NZS 4360:2004 is the world’s most famous and first Formal standard for documenting and managing risk. This approach provides a generic guide for managing risk. It does not lock the organizations into a particular risk management methodology, the risk management system will be affected by the varying needs of an organization, It also provides a risk tables E.g. allows organizations to develop freely and adopt their own. The methodology fulfills the AS/NZS 4360

The five steps of the AS/NZS 4360 process are: –

Establish Context: Establish the risk domain Means Identify which system or assets are important?

Identify the Risks: Identify the risk in the risk domain, What particular risk visible?

Evaluate the Risks: Determine the residual risk.

Analyze the Risks: Identify the risks and Find there are any supporting controls in place.

Treat the Risks: determine the method to treat the risks so that risks selected by the business will be Resolve.

AS/NZS 4360 managed by an operational risk group, has adequate skills and risk management resources to identify, analyze, and treat the risks.

The advantages of AS/NZS 4360:

AS/NZS 4360 Helps as
a risk management methodology for organizations requiring Sarbanes-Oxley compliance

AS/NZS 4360 As Manage the risk in a Standard way for an organization such as just using likelihood to determine an overall risk.

AS/NZS 4360 is Known to most popular risk manager in the world and for your organization AS/NZS 4360 is already Applied and suited approach.

The limitations of AS/NZS 4360:

The AS/NZS 4360 approach works best for business or systemic risks but not good for technical risks.

The AS/NZS 4360 Not provides the methodology to perform a structured threat risk modeling exercise.

The AS/NZS 4360 It also not provide the structured method to calculate web application security risks. It is a generic framework for managing risk.

AS/NZS ISO 31000:2009 Risk Management

Australia/New Zealand adoption of ISO 31000:2009, and supersedes AS/NZS 4360:2004. After five years of development, the Risk Management Standard, AS/NZS 4360:2004 has been superseded by AS/NZS ISO 31000:2009, Risk management – Principles and guidelines. The joint Australia/New Zealand committee OB-007 decided that rather than undertake the same revision in 2009.

ISO 31000:2009 used by any public, private or community enterprise, association, group or individual. Therefore, ISO 31000:2009 is not specific to any industry or sector.

What AS/NZS ISO 31000:2009 can Help to achieve:

helped to work as organizational resilience.

Gives a Proactive management to the organization.

Makes a Stakeholder confident and trust.

Helps organization to making a reliable decision and planning

It is more certainty in today’s market conditions.

AS/NZS ISO 31000:2009 vs. AS/NZS 4360:2004

Expands the Application of framework for risk management and further develops the 2004 framework

Principal for managing is far clear and explicit than 2004

Increase the risk management attributes by included new addition of the Annex

For Guide to Start and implementing effective risk management process New addition included in the Annex compared with previously supplied in HB 436:2004

It is applicable for all industries public, private or community enterprise, association, group or individual Which may involve uncertain outcomes.

The SDL and Agile Methodologies

SDL for Agile is now included in the Microsoft SDL process guidance; There are many agile methodologies in practice today. They included some Scrum and Extreme Programming (XP), and, in some cases, teams want to practices with many methodologies. Anyhow of the methodology you follow, But you don’t have to sacrifice security just because you are developing using one of the agile methodologies. The below figure shows how the SDL combine into agile development methodologies.

SDL activities can be organized into “bite-size chunks” across various iterations or sprints or in buckets as part of agile software development methodologies.


NIAC Vulnerability Disclosure Working Group established by the US Department of Homeland Security (DHS), Which includes input from Cisco, Microsoft, Symantec, ISS, Qualys, CERT/CC, and eBay. One of the outputs of this group is the Common Vulnerability Scoring System (CVSS)

Why use CVSS The advantages of CVSS:

You have just received notification from a security researcher or other source that your product has vulnerability, and you wish to protect that

It has an exact and Trustworthy severity rating, so as to alert your Buyer or user to the appropriate level of action required when you release the patch.

You are a security researcher, and you have been found some several threat exploits within an application. And that time You would like to use the CVSS ranking system to Make reliable risk rankings, to assure that the ISV will take the exploits seriously as Shows by their rating.

The use of CVSS has been recommended by the working group by US Government departments. However, it is unclear if it will become policy or be mostly adopted at the time of writing.

Why to not use CVSS The limitations of CVSS:

CVSS is just a scoring system, not a modeling methodology. It does not find or reduce the attack surface area (i.e. design flaws), nor help to tally possible risks by any arbitrary piece of code, it is not designed for that purpose.

CVSS is more complex than STRIDE/DREAD, as it aims to calculate the risk of announced vulnerabilities as applied to deployed software.

The CVSS risk ranking is complex – a spreadsheet is required to calculate the risk components as the assumption behind CVSS is that a single vulnerability has been identified and announced, or a worm or Trojan has been released targeting a small number of attack vectors.

IF applied to a thorough code review, the overhead of calculating the CVSS risk ranking is quite high; It may have 250 or more threats to rank.


In this mini-course reader will learn how to identify asset, threat, and severity level along with vulnerability or RISK associated with it. Also, Creating threat modeling and major security control, threat rating and DREAD model. We have also explained how to draw Data Flow diagrams with thread trees and what are attack pattern. Additionally, we have mentioned AS/NZA 4360:2004 and 31000:2009 Risk management compliance. The SDL and Agile methodologies and Common Vulnerability Scoring System (CVSS) advantages and limitation.

We recommend this course for penetration tester, ISO compliance officer, risk officer, student and any other information security professional.