CHAPTER 7: SECURE DEVELOPMENT LIFECYCLE

 

 

 

Now that we have seen some of the more common attacks on applications, let’s take a look at the vital task of securing software. All of us usually focus on the functionality of our software first. We overlook security when software is first built. Security often only comes into the picture after the application has been developed and deployed.

But research shows that the cost and effort of fixing security weaknesses after deployment is much higher than building security into the application in the first place.

Having said that, please note that security is not a one-time activity. If security has to be built into the software, there are a number of activities that we need to perform throughout the software development lifecycle (SDLC)³⁸. This chapter discusses these activities in detail and shows the importance of each.

Security activities in SDLC

The different phases in the software development lifecycle are:

1. Initiation phase
2. Design phase
3. Development phase
4. Testing phase
5. Deployment and maintenance phase
6. Disposal phase.

In this chapter, we focus on the security activities in each of these phases to ensure the software is secure. We’ll walk through the different SDLC phases with an example. Let’s imagine we want to build a house on a piece of land.

The initiation phase consists of two main activities. The first is to ascertain the exact requirements so we know what to build. The second is to determine whether the house we have in mind can be built on that specific land. These activities in the SDLC initiation phase are known as requirements specification and feasibility study. Along with the functional requirements, such as the number of rooms required, security requirements must also be considered at this time.

So, we’ll conduct a preliminary risk assessment where the high level threats in the environment are considered. Some questions we ask are:

• Is the area prone to frequent floods?
• Is the neighbourhood unsafe?
• Are there many burglaries and thefts?
• Is the area prone to frequent earthquakes?

Answers to these questions give us an idea of some of the important security requirements of the building project. Depending on the answers, we may decide, for example, that the house has to be protected from floods and burglars but not earthquakes.

For a software project, these basic security issues should be considered in terms of availability of the system, integrity and confidentiality of data, accountability, etc. This chapter looks at identifying these basic needs for applications, in line with the ISO27001 control, A.14.1.1, which requires security requirements analysis and specification.

In the design phase of our house building project, we bring in an architect to make the plan. Based on the requirements gathered in the previous phase, the architect prepares the plan for the house. This plan should not only cater for all the functional requirements but should also meet the security requirements we have identified. It should take into account that new additions to the structure (new features) may be necessary at a later date, and must ensure that there is a process to prevent them from threatening the security and functionality of the whole. The majority of bugs arise when new features are added that were not part of the original design.

Also, the plan should look at security in more detail than the preliminary risk assessment of the earlier phase. So, a threat modelling exercise is carried out. This exercise analyses all the threats to the house. We, or the architect, use a structured method to identify controls to mitigate the identified threats. This technique is discussed later in this chapter. Some examples in the case of our house are:

• A thief breaking into the house
• Damage from an accidental fire
• Damage from floods.

Each of these threats will be realised in different ways. These different paths are called ‘attack paths’ or ‘vectors’. We use threat trees to enumerate all the attack paths and arrive at the necessary controls. We shall see how threat trees are constructed shortly. Meanwhile, here are some controls we might arrive at for each of a number of possible attack paths:

Table 9: Attack paths and security controls

Attack paths	Security controls
A thief breaking into the house through a window	Have bars over the windows
A thief breaking into the house through a door	Have strong locks on all doors
A thief breaking into the house by breaking a wall	Have a burglar alarm
Accidental fire in the kitchen	Have a smoke detector and fire alarm
Damage from floods	Build the house on elevated land

Some of these controls have to be included in the basic design itself – like elevating the land. Some are implementation level controls – like installing locks and alarms. Although the latter need not be included in the architect’s plan, these controls have to be documented so that they can be installed during construction.

The next phase is the development phase. This is when the house is actually built. The builders or, in the case of software, the developers, get to work. They build according to the design provided to them by the architect. They construct the walls according to the measurements given in the design. They leave an opening for the doors and windows as specified by the design. But there are certain security controls that the builders are responsible for implementing. For example, the builders ensure that the raw materials they are using are durable, and that they do not use any materials or techniques that are known to be weak. In the case of software there are secure coding practices that developers must follow. For example, a developer must use parameterised queries instead of dynamic queries to prevent SQL injection attacks.

It is better to ensure that the design is being followed during construction than to verify at the end that it was. When the construction for a particular day has been completed, we can check if the newly made wall has the dimensions specified in the design. It is easier to make corrections if the strength of the wall is checked at this point. This translates to daily testing of code in software development. It is easier to spot and correct vulnerabilities if we integrate security scanning of the code at the time of the daily build. We use automated scanning tools and static analysis tools for spotting weaknesses in daily builds.

The next phase of the SDLC is the testing phase. Since there is no equivalent to testing in our house analogy, let’s put the analogy aside for now. Testing is an important phase in software development projects. Various kinds of test are done to see if the requirements identified in the initial phase have been met and to verify that the system functions properly once deployed. For that, functional, performance and load testing exercises are performed. This phase also helps in unearthing any additional security weaknesses that may have crept in due to oversight or which may have resulted from changes made after the threat modelling phase. To check whether the security requirements have been met, conduct security tests. These could be grey-box or white-box tests. In a grey-box test the software’s front end is tested to check for any weaknesses that can be exploited by an adversary with or without valid access to the system. A white-box test looks into the code to spot weaknesses and errors. We discuss these tests in more detail in Chapter 8.

Then comes the deployment and maintenance phase. The software is deployed and is ready for use by end-users. There are a number of security issues to address during deployment. For example, the application should run as a low-privileged OS user. In a web application, the webserver should be securely configured. Only the required ports should be opened at the firewall for the application to operate. All the defences built into the system in the earlier phases are wasted if these deployment issues are not handled properly.

Ensuring security continues even after a successful deployment. We should conduct regular security tests on the application. There may be new threats to the application that were not considered during threat modelling or there may be certain weaknesses that were not spotted in the testing phase. Also, an application will undergo changes as features are added, modified or removed based on user input or on bugs reported. And any change to the application code may introduce new security weaknesses. So, do regular penetration tests or black-box tests.

Maintenance also involves a number of other regular security practices. Set up processes that ensure that the application continues to work correctly. These processes include backup and recovery, change control and incident response.

The last phase is the disposal phase. That is when the software reaches the end of its life and has to be disposed of or destroyed. We cannot just stop using an application and forget about it, particularly not if the application has been dealing with a lot of sensitive data. We should ensure that all that data is destroyed properly if it is not needed anymore. If it has to be stored for a defined period of time, then preserve the data securely, so it can be retrieved as and when required, and ensure that you retain copies of the application (and, if necessary, the OS and hardware), so that you can access the data even after multiple hardware and software upgrades.

The data will have to be removed from the database and any media it may have been stored on. Have formal guidelines on how to erase this data completely from all media. Equally important is secure destruction of the software and hardware that is not required any longer.

We have discussed a number of security activities that need to be carried out during the SDLC – at different times, by different people. It is important to train all the people involved so they are able to do these activities well. Security training needs to be given to software designers, developers and testers.

Now, let’s look at each of these in more detail.

Preliminary risk assessment

“In the Initiation phase, risk assessments evaluate the anticipated vulnerabilities and predisposing conditions affecting the [security] of information systems in the context of the planned environments of operation.”³⁹

A preliminary risk assessment exercise is done by asking a number of questions that show us the basic threats to the application:

1. Will the application be accessible from the Internet?
2. Will it be accessed by unauthenticated users?
3. What are the sensitive data the application will be dealing with?
4. Does the application use a database?
5. Will the application be interfacing with external applications?
6. Who are the potential adversaries? (Anybody on the Internet, users, employees, ex-employees, etc.)
7. What is the acceptable downtime?
8. Are there different privilege levels? If yes, how many are there and what are the privileges?

The answers to these questions help us decide the high-level security controls needed in the system. These answers also help us in deciding which threats we will study in depth in the threat modelling stage. For example, if the application will only be used by unauthenticated users, we will not spend time on threats related to authentication.

In this phase, we also have to decide on the security regulations or standards that our application has to follow. Differing regulations apply in different jurisdictions and industries. IT Governance identifies some of the applicable regulations on its website⁴⁰:

Table 10: Security regulations and standards

Threat modelling

Now comes the time to delve deeper into the threats and security controls.

Threat modelling is a structured technique to identify threats and the security controls required to counter them, so the first phase of threat modelling consists of identifying all the threats the application must protect against, which means creating a threat profile.

Threat profiles

A threat profile is a list of all the threats to the application.

But what exactly is a threat? We discussed threats very briefly in Chapter 3, and described a threat as “something that can attack an asset”. If I ask you what the threats to your house are, you would think of fire, theft, earthquake, etc. If I ask you what the threats to your web application are, you would think of password theft, unauthorised access, illegal transactions, etc. This helps us better understand a threat in the context of application security: a threat can be seen as the goal or objective of an adversary.

For example, for an online banking application, some of the threats would be:

1. An adversary accesses another user’s account, without valid access credentials.
2. An adversary steals other users’ passwords.
3. An adversary transfers fund from others’ accounts to their own account.
4. An adversary pays bills using another user’s account.

The challenge in creating a threat profile is ensuring its completeness. How can we be sure we have thought of all the possible threats and not missed out anything?

Let’s try to logically derive all the threats for a physical building, say a bank.

First step – identify all the assets to be protected

Somebody walking into the bank and stealing cash from the safe is a threat. On the other hand, somebody walking in and stealing some pens from the counter is not ranked as a threat. What is the difference between the two? In both cases we are talking about theft in a bank. Well, what is being stolen is the major differentiator. Cash is an asset that is important to the bank and must be protected, whereas a pen is not. Pens, we might say, are not even in the scope of the security system that is being designed, in this case, to protect the cash.

Second step – identify all the roles that have valid or authorised access to the assets

What if the cashier accesses the cash in the safe? Is that a threat? No. Although cash is a protected asset, some people like the cashier have valid access to it. So, for each asset there are some roles that have valid access.

Third step – identify all the valid paths that a role is allowed

By saying a cashier has valid access to the cash, do we mean he can walk away with the cash at the end of the day? No. The cashier has access to the cash only through some pre-defined processes. So, there are valid paths through which a valid role can access a protected asset.

Anything that violates any of the above is a threat. So, for our bank, some of the threats would be:

• A customer withdrawing money from another customer’s account.
• A non-account holder withdrawing money.
• A bank officer not entering the deposited money into the books of record.

We can create a complete threat profile for any system, including applications, following these three steps.

Threat trees

The second phase in threat modelling is identifying security controls for each threat in the threat profile. This is done with the help of a threat tree.

A threat tree helps in identifying conditions (those vulnerabilities we discussed in Chapter 3) that lead to a threat being realised and helps us decide the controls. Let’s create a threat tree for the threat ‘compromise user passwords’ for an online banking application.

The three ways of compromising a user password would be:

• Access password
• Steal password from database
• Guess password

Representing this information in a tree format, we get the tree shown on the next page.

Let’s drill down one more level. What are the different ways of achieving each of the above?

• Access password – through a sniffing attack or a phishing attack.
• Steal password from database – compromise the database and steal the password.
• Guess password – through a brute-force attack.

Let’s take a closer look at the option of ‘steal password through database’. Is it possible to compromise the database and steal the password? Yes, but only if the password has been stored in cleartext. So there is a condition to be satisfied for the attack to succeed.

Adding this additional information to our threat tree, our tree grows to become the one on the next page.

The arc between the two child nodes of “Steal password from database” represents the ‘and’ condition. So, the password can be stolen only if the database is compromised and the password is stored in cleartext.

By now, you will have realised that each child node for an attack node is either an attack again or a vulnerability. “Password in cleartext” is a vulnerability and “compromise database” is an attack.

For each node that is an attack, we list the different ways of executing the attack and the conditions required for a successful attack. The conditions are the vulnerabilities and the different ways are the attacks. We continue the process until we have broken down each attack node into the vulnerabilities required for exploitation.

So the threat tree now looks like this:

If we look at only the middle part of the tree, it is complete as all leaf nodes are conditions or vulnerabilities.

The next step is to identify mitigation techniques or security controls⁴¹ for each of these vulnerabilities. The following are the controls:

Table 11: Vulnerabilities and security controls

Vulnerabilities	Security controls
Password is in cleartext	Store passwords as hash
DB port is accessible	Restrict access to port
Default usernames/passwords are allowed	Remove default accounts and use a custom account with a strong password

The designers now know which controls are to be included in the design and where. There are other advantages of creating a threat tree. From an ISO27001 perspective, we should go further than this and rate the feasibility or likelihood of the threat-vulnerability combination being realised and, on this basis, rate the identified risks. This can help us in deciding which controls are more important and which need to be addressed as a higher priority.

In some cases, the threat tree and risk assessment process may demonstrate that one control may have the same risk-reduction effect as two or more other controls. This enables the designers to make fully informed cost-benefit decisions about which ones to implement. In our example, storing passwords as hash in the database may be enough to protect against the threat of stealing passwords through the database. Restricting access to the database and removing default accounts may as a consequence not be required to mitigate this particular threat.

As we saw in Figure 7, on page 148, threat modelling can appear in the SDLC, at two points: in the design phase and again in the testing phase.

In the design phase, it helps the designers decide which security controls to include in the software. In the testing phase, it helps the testers in creating the test cases for a thorough round of testing. If threat modelling has already been done in the design phase, it can be reused in the testing phase.

Secure coding practices

We have seen how threat modelling can be used to decide the security controls that are appropriate and necessary for our application. Since a number of these controls are actually standard practices that any code would benefit from having, we can come up with a standard set of secure coding practices.

Of course, secure coding really begins with the choice of programming language and development environment, as each of these will come with different strengths and vulnerabilities. Before creating a set of standard security practices it is a good idea to pick the most secure languages and environments that fit your purpose, and then find out the specific weak points in order to give them due weight when composing your secure coding practices.

Each developer should be given this set of practices to follow while writing the code. The question may be asked: ‘if we are carrying out a detailed risk assessment to identify which controls are required, why do we need standard secure coding practices for developers?’

Secure coding practices address security weaknesses at a code-writing level, unlike threat modelling and risk assessment which address design-level weaknesses. Although the design-level security controls also get implemented through code, there are some secure practices that are specific to coding and to the platform being used. For example, at the design level, one security control may be to have proper error handling in the software. The major types of error to be handled may be specified. But when a developer has to write this code, he has to decide how to handle each type of error. Also, there will be language-specific error handling techniques and syntax that the developer should know. For instance, in .NET the developer would use Try, Catch and Finally blocks for error handling.

So, secure coding practices are code writing-specific security controls.

Some examples of secure coding practices are:

1. Input validation

   • Validate at the server

   • Validate type, length, format, range

   • Allow only known input

   • Reject known bad input

   • Sanitise input data

   • Modularise input validation

2. Authentication

   • Defend against brute-force

    - Enforce strong passwords

    - Use CAPTCHAs

    - Use temporary account lockout

   • Implement a secure change password feature

   • Implement a secure ‘remember me’ feature

   • Implement a secure ‘forgot password’ feature

   • Set AutoComplete = off

   • Use redirection on login/protect against ‘browser refresh’

3. Updates

   • Only use compilers with the latest security patches

Security testing

After the design and development phases, the next phase in the SDLC is testing. Along with other forms of testing like functional testing, performance testing, etc., security testing is also very important.

Security testing ensures that the security controls identified in the design phase have been implemented properly. It also finds out any new weaknesses that either were not identified during threat modelling or were introduced later as a result of changes.

There are three types of security test:

• Black box testing
• Grey box testing
• White box testing.

Black box test

In a black box test, the security testers don the role of a hacker on the Internet. They carry out the testing with minimal information. They are not provided with login accounts or any privileges to the application. With whatever information is publicly available, the tester tries to exploit the application in all possible ways. The tests are focused on bypassing the authentication requirements and on exploiting any vulnerabilities in the deployed environment. So, along with the application, the application server, the webserver and the operating systems also fall within the scope of this test.

This test is generally carried out after the application has been hosted, since it checks for insecurities in the deployed environment.

This test gives an exact idea of how much an adversary on the Internet, without any additional information, is able to learn about the application and what damage can be caused. On the other hand, it gives no idea of how an adversary with valid login credentials could exploit the application. Because of the very nature of the test, a black box test is carried out by external testers with no prior or inside knowledge of the application.

Grey box test

In a grey box test, the tester tests for security breaches that valid users can cause. Login IDs of the different privilege levels are provided for testing. This enables testing to uncover the access rules that can be violated by valid users.

A grey box test can be carried out at two stages:

• either in the testing phase before deployment, or
• after the final deployment.

In the first case, it uncovers all insecurities in the application itself but not in the deployed environment. This helps the developers fix any issues before the application goes into production.

In the second case, it not only finds the weaknesses in the application but also in the entire infrastructure used in the deployment.

Some parts of these tests are automated with the help of tools like vulnerability scanners. But a major part of the test cases are executed manually as these require an understanding of the application features, the specific threats to it and the variables in each page of the application.

White box test

In a white box test or a code review, the tester is given access to the entire source code. The reviewer goes through the code to find the weaknesses in the code at a design level and at the implementation level.

The reviewer doesn’t go through each and every line of the code but follows a threat profile-based approach. After understanding the application features, its architecture, etc., the tester then creates a threat profile. The threat modelling exercise gives an idea of the possible weaknesses in the code and where to look for them.

It is best to carry out this test during development or before deployment. As this test may also recommend a number of design-level changes, it is better for it to be carried out while the development is still in progress.

Table 12: Different types of test

The major steps in any type of security test remain the same:

• Creating the threat profile
• Creating the test plan with detailed test cases
• Executing the test cases.

As discussed earlier, the threat profile is a complete list of threats to the software. The testers first understand the application completely to be able to identify assets, roles and valid paths for the threat profile. Once the threat profile has been created, the tester builds a threat tree or an attack tree to determine the different possible ways of realising each threat. The tester then identifies the exact locations in the application to execute the test cases and also the exact input that will be used. This is the test plan.

Then begins the actual testing, in which the tester may use automated tools along with manual tests. We discuss this in greater detail in Chapter 8.

Backup and recovery

ISO27001 places a lot of emphasis on the information security aspects of business continuity⁴² and preparing for disasters so that the organisation can quickly recover and continue operations with minimum loss. Applications usually form a major part of any disaster recovery plan.

For an application, a disaster could be anything from a hardware problem to a denial of service attack to natural disasters like floods. Let’s see what we need to take care of in order to recover the application quickly during a disaster. This would include the following processes:

1. Regular back-ups.
2. Defining a recovery process.
3. Testing the recovery process.

Regular backups⁴³: We have to back up the data the application works with and also the application code. Since the application may be undergoing continuous changes, there should always be a backup of the most recent code. Choose the frequency and method of back-up according to the needs of the organisation. Backups can be scheduled daily, weekly or monthly. These backups can be full or incremental. Based on the criticality of the application and the data, define a policy for back-up frequency and type.

Define a recovery process: When the need arises, and we have to use the backup to bring up the application or database and continue normal operations, there will be certain steps that need to be carried out in a specific sequence, e.g. the database will have to be started and tested before the application is started. Document these steps well.

Test the recovery process: A lot of organisations take backups but never test them. At the time of an actual disaster they may realise that the backup does not work or that the documentation of the recovery process has flaws. To avoid such a situation, it is very important that the recovery process is tested at regular intervals. These tests help in correcting any mistakes in the process and ensuring a smooth recovery during a disaster.

Change control (ISO27001 A.14.2.2)

In its purest form, the SDLC calls for freezing the design phase before starting the coding. The code is then not allowed to change except for fixing the bugs found during the testing phase. But this is rarely what actually happens. The design may have to be changed for a number of reasons – a change in initial requirements, new features to be added, and enhancements to be made, as well as bugs to be fixed.

Under normal circumstances, a large number of developers may be working on the new application. Imagine the state of the code if different people are making changes in different parts of the code as and when required. One developer may accidentally remove a security feature added by another. This can be avoided if there is an overall authority for approving all changes to the code. The entire team must adhere to a well-defined change control process. The process would require a request to be made for the change desired. The reason for the change, the expected effect of the change on the application, the time and effort required for the change, etc. should be documented in the change request form. Only after an approval from the designated authorised person can the change actually be implemented. The design documents should then be changed accordingly to reflect the change. Control A.14.2.2 of ISO27001 describes these change control requirements.

Incident response

Despite all the controls that we have built into our application, we may still be faced with a security incident. ISO27001 says⁴⁴ we should be prepared for this. Incident response consists of these main steps:

1. Preparing for an incident.
2. Detecting an incident.
3. Containing the incident.
4. Recovering from the incident.
5. Analysing the incident.
6. Learning from the incident.

Many organisations do not pay attention to incident response – until their first incident. When an incident occurs they incur a lot more loss as they have no means of stopping the incident or minimising its effect. Prior preparation is very important. Every organisation must have a trained incident response team and a detailed incident response procedure document that lays down the exact steps to be taken when an incident occurs.

To be able to detect an incident we need to have monitoring mechanisms such as intrusion detection systems in place. Monitor the traffic to the application and alert the security team of any attacks. Apart from intrusion detection systems, there are also application firewalls available that can detect and thwart application-level attacks.

Once an attack has been detected and the relevant personnel alerted, steps have to be taken to stop or contain the incident. The immediate steps taken may vary based on the type of incident being dealt with. Suppose the incident is a denial of service attack on the application. The incident response team first focuses on stopping the flood of requests and protecting the application from crashing. If it is a virus or worm outbreak, their first focus would be on containing the spread. But if it is an application attack like an illegal funds transfer, there may be no means of stopping or containing the incident as the attack has already been performed and the damage done. In which case, the team only focuses on the next steps of recovery and analysis.

The incident will have caused some damage. Depending on the nature and extent of damage the incident response team will have to take steps for recovery. Since the damage could be anything from the application being shut down to the entire database being deleted, it is important for the team to be trained for all possible situations.

Now we have contained the incident and also recovered from the damage. The system has returned to its previous state and normal operations have resumed. Now it is time to analyse the incident and understand the cause. The different logs –application logs, operating system logs, the webserver logs, the firewall and IDS logs – have to be collected and analysed to trace the origin of the incident. All events relating to the incident should have been logged.

This sequence of events is known as an audit trail and will act as evidence in a court of law if we choose to seek legal action against the attacker. These logs will also help us in identifying and plugging the gaps in our security controls.

It is important we learn from the incident by improving the security measures to avoid future incidents, and by improving the incident response strategy so we are able to handle an incident faster and better.

Security training⁴⁵

As we have already discussed, there are different security activities that take place in the SDLC. These are carried out by different teams:

• Preliminary risk assessment – lead risk assessor
• Threat modelling – software designers
• Using secure coding practices – software developers
• Security testing – testers.

Since security is not their area of expertise, these software professionals require training to carry out these activities.

Our training programme should be designed keeping in mind the skill level of the participants and the security duties expected of them. Let’s see what a typical security training programme for software designers will look like:

• It first creates awareness about the importance of information security. The participants are told what information security is, why it is important and what harm can be caused to the organisation by compromises to the integrity, availability and confidentiality of information in the system by the absence of necessary security controls. Only when the trainees are convinced about the need for security will they be able to implement the controls effectively.
• The designers are trained on how to conduct a threat modelling exercise. They are taught how to prepare threat profiles and threat trees.
• The developers are trained in general secure coding practices. They are also trained in the specific coding practices that are to be followed for the platform they will be developing in.
• The testing team is trained in the different types of testing. They are also trained on threat modelling as they may have to do this exercise themselves during testing.

Although the testing team can be trained to conduct the security tests, it may sometimes be more useful – particularly for high-risk systems whose security might benefit from additional, fresh review – to bring in external security experts to do the testing.

The security threats to an application may keep changing. The environment in which the application is running may change, giving rise to new threats. Adversaries may come up with new ways of attacking the application. So, the different teams should be trained on a regular basis to ensure they are aware of the latest security threats and how to mitigate them.

In this chapter, we looked at the security activities to perform across the software development lifecycle. We also saw how they fit together in our efforts to build secure software. Reducing bugs early reduces the costs, and this chapter showed the steps involved.

In the next two chapters we will look in more detail at three of the areas we touched on briefly in this chapter. Chapter 8 will first lay out the steps for creating a threat profile. After that, the chapter will show how to create test plans and perform security testing. The chapter is targeted at testers, though designers will also find the approach to threat profiling useful. Chapter 9 takes a different approach and describes in more detail the secure coding guidelines for writing secure code. This chapter is most useful for developers.

Bibliography

1. NIST Special Publication 800-30, Rev. 1, Guide for Conducting Risk Assessments
2. NIST Report, 2002, The Economic Impacts Of Inadequate Infrastructure For Software Testing
3. ITL Bulletin, September 2004, Advising users on information technology
4. www.itgovernance.co.uk/compliance.aspx
5. The Security Development Lifecycle, Howard M and Lipner S, Microsoft Press, US (2006)
6. Attack Trees, published in Dr. Dobb’s Journal December 1999, Bruce Schneier
7. Threat Modelling, Swiderski F and Snyder W, Microsoft Press, US (2004)