The introduction covers the recent changes is security threats and the effect those changes have on how we protect systems.

Transcription

1 1 Cyber-attacks frequently take advantage of software weaknesses unintentionally created during development. This presentation discusses some ways that improved acquisition practices can reduce the likelihood of exploitable software weaknesses appearing in a delivered system or software product. This presentation assumes that you have some experience with creating software system requirements to meet business needs and an understanding of system development lifecycle phases.

2 2

3 3 The introduction covers the recent changes is security threats and the effect those changes have on how we protect systems.

4 4 Cyber-attacks have significantly changed over the last 10 years. In the late 1900s, the success of an attack might be measured in the number of sites compromised. Today, an attacker might devote weeks, if not months, to find a way to compromise a specific site. Well-resourced, highly skilled, and persistent attackers have compromised organizations such as Google and the highlyrespected security supplier RSA. RSA was a secondary target. The primary objective was information at a Lockheed Martin site on the F-35 aircraft. Lockheed Martin used software from RSA to authenticate its employees for access to its computing systems. The attackers compromised RSA to obtain copies of employee authentication data so they could log into the Lockheed Martin site. While the consequences of recent attacks have been significant in terms of the loss of intellectual property and trade secrets, those attacks obtained sufficient access to adversely affect the operations of the compromised organizations. The same kind of attacks could degrade the operations of government systems. Attacks frequently exploit a software weakness inadvertently created during development, which is what we call a vulnerability. We refer to them as software weaknesses rather than software

5 5 errors, because the system behaves as expected under normal operating conditions but can be adversely affected under unexpected conditions created by an adversary. Reducing the frequency and severity of such weaknesses requires improved supplier development practices and acquisitions that select suppliers with such capabilities.

6 6 Moat-like defenses that use external security controls such as firewalls and encryption can be effective defenses for attacks that target the network. But attack targets change as weaknesses are eliminated. Application software is now a popular attack target. An analysis of successful software attacks identified over 900 kinds of software weaknesses. The capabilities of highly skilled adversaries who can exploit known weaknesses or find new ones in increasingly complex computer systems have surpassed the defensive capabilities of external security controls. We have a situation similar to rollover risks for early models of sports-utility vehicles or SUVs. There are no significant problems driving a SUV under normal conditions, but there are circumstances such as swerving to avoid an accident where a SUV because of its higher center of gravity has a greater risk of rolling over than a sedan has. The rollover risk cannot be mitigated by adding controls after a SUV is manufactured. The risk is reduced by a redesign where electronic vehicle controls intervene when sensors report conditions that could lead to a rollover. In a similar fashion, we need to reduce the likelihood and severity of exploitable software weaknesses during development rather than by adding controls later. Such a change in strategy

7 7 is reflected in the latest version of the NIST security control document. Security is now a combination of building it right and implementing specific security controls. Building it right or Building security in means that compromises and defenses are considered during all phases of the development lifecycle. We cannot verify that a system was built right after development is completed. Rather we need to find ways to assess the system at various points during the lifecycle so we are confident that development is on track to meet the build it right objective at completion.

8 8 We show how an objective to build it right affects acquisitions and, in particular, show that activities in the early phases of an acquisition lifecycle can support that objective. Software assurance in general considers conditions that could lead to unexpected behavior. We concentrate on those conditions that could lead to a security failure which are described by the trustworthiness component of software assurance. The most important objective is to show that knowing how to analyze security threat using a practice called threat modeling can improve system requirements and supplier selection criteria.

9 9 The NIST Risk Management Framework can help acquirers analyze the consequences of risks and possible mitigations for them. The top tier can address strategic risks by defining policies to govern the implementation and design of the work processes and the associated information system. Tier 1, for example, could establish certification requirements for acquisitions involving critical information systems. The bottom tier is the operational layer, which contains the computing systems and manages the tactical risks that only affect that level. A critical aspect of a risk assessment is to understand the interactions between Tiers 2 and 3. The work processes inherit the computing system risks, but the computing requirements for the work process can increase system security risks.

10 10 Let s expand on the connection between tiers 1 and 2. Acquirers and suppliers both do risk assessments. The acquirer is concerned about the business impact of a compromise and the threat agents that could target a system. A supplier concentrates on system risks and monitors the software weaknesses that have been exploited by successful attacks. Acquirer risks include poor supplier development practices which increase the risk of a compromise. But a supplier s development risks can be increased by an acquirer s functional and operational requirements. Thus, we have a feedback loop between acquirers and suppliers. We describe a practice called threat modeling can be used by a supplier to analyze and mitigate security risks inherited from requirements. A general understanding of threat modeling can also help acquirers understand how their actions can affect the development of secure software.

11 11 In this section, we discuss threats and threat modeling.

12 12 Threats are used in two ways for security. A threat can refer to the agent that executes an attack or to the consequences of an attack, that is, the attacker's objective. The Microsoft STRIDE threat model identifies six consequences of an attack. This presentation considers the three threats that are most closely associated with software vulnerabilities. We cover data tampering, disclosure of information, and an elevation of privilege. The last one is often the most important one to an adversary.

13 13 An elevation of privilege does not directly damage a system, but it often provides an attacker with the necessary privileges to access or modify data. In this slide and the next one, we describe an elevation of privilege that was the first step in the RSA compromise. The objective of the RSA attack was to obtain employee authentication data for organizations that purchased RSA software. Assume the data is not Internet accessible and managed by the application in the upper-right corner of this slide. The first step in the attack is to access the internal RSA network. The RSA attack started with a well-crafted message to an employee in business services. That included a link to what appeared to be useful business information. Of course, the employee should have ignored such an , but a mail message created by an expert using specific employee information obtained from sites such as LinkedIn can be very convincing. The link in the was to a malicious website. When the employee s browser accessed that web page, a vulnerability in a browser add-on for videos let the attackers install their own programs and become insiders with the same access to data and programs as the employee had.

14 14 Most likely, multiple attempts had been made to access the network, and the one described in this example was the first one that worked. If it had failed, a persistent attacker would have tried other options, and with an attacker with expertise and patience would likely succeed. Most likely, multiple attempts had been made to access the network, and the one described in this example was the first one that worked. If it had failed, a persistent attacker would have tried other options, and, with sufficient expertise and patience, such an attack would likely succeed.

15 15 If we are considering the design of a home security system, the thief is now in the house, and sensors should have reported that entry. But in this example, intruders use the identity of a trusted employee to avoid being reported. Internal software systems frequently assume a safe computing environment. But an attacker with access to the internal network can apply sophisticated and likely unanticipated attacks to compromise internal software components and obtain access to additional accounts. Each compromised account could provide access to additional systems and data. The attack does not have to compromise the targeted system if one of the compromised accounts has access to it. Securing a system requires more than just security of the critical components. A weakness in a secondary component can give an attacker a sufficient foothold to eventually compromise the system.

16 16 Threat modeling refers to the threat analysis that is done during design in Microsoft s Secure Development Lifecycle. Its objective is to identify how a design could be compromised before the code is written. The details for how to do that vary among developers, but it is a common objective among organizations that incorporate security into their full development lifecycle. Identifying weaknesses early with threat modeling can result in better security than improving development reviews or security testing. Such reviews and tests only attempt to identify such weaknesses after they have been created. An acquirer does not have to do threat modeling. So what are the benefits for having a general understanding of it? Say you ask a contractor about delays in task completion and the response from the contractor is a query such as Do you really need to do this? For security, this response could mean that the security risks associated with a functional requirement cannot be fully mitigated or that the implementation of the required mitigation will increase costs or delay delivery. If your response is no, that requirement can be removed, but a response of yes, may require you to accept the security risks in order to have the desired system feature. Or it might force you to make changes in the schedule, costs, or other requirements so the design can be revised to reduce the security risk to an acceptable level. An acquirer, who recognizes early in the

17 17 acquisition lifecycle that the requirements could lead to problems with the security analysis, can tailor the source selection criteria to identify suppliers with the security capabilities needed to manage the anticipated complexity. That complexity also requires an acquisition to have a source for security expertise to monitor and evaluate the security aspects of system development.

18 18 There are multiples ways to respond to a risk. A commercial organization might accept a computing risk associated with a business practice where the increased sales compensate for higher risk. An organization can use an insurance policy to transfer a risk to its provider. Unfortunately, a supplier could also transfer the risk of exploitable software weaknesses it created to those organizations that follow it in a supply chain and eventually to the acquirer. In this presentation we consider how risks could be mitigated.

19 19 We now introduce threat modeling as one way for an acquirer to better understand the feedback loop between acquirers and suppliers that we have described. In the next few slides, we describe three risk factors that are analyzed using threat modeling and show how acquirer requirements can affect those factors. Acquirers who understand these interactions can anticipate the security issues that could arise during development.

20 20 The left side of this diagram lists the steps involved in Microsoft s threat modeling. We numbered the steps we cover in this presentation. Steps 1, 2, and 3 are the risk factors considered by threat modeling. Steps 4, 5, and 6 analyze those threats to determine the system risks and feasible mitigations. We start with step 1, then steps 2 and 3, and finally steps 4, 5 and 6, and we alternate between a developer s and an acquirer s perspective.

21 We start with business requirements. 21

22 22 A use case is a way of writing a business requirement. It describes system behavior when it responds to an external request, that is, it can describe an information exchange between a user and a system. We will apply threat modeling to the use case shown on this slide. Customer information is managed by a database server. A database record includes a customer identifier, a 5-digit numeric value, and customer information such as a name and phone number. The business requirement described by the use case is that the input of a 5-digit numeric value CLICKS displays a web page with the ID, name, and phone number for the customer with that ID. A use case is a risk factor because a software weakness in its implementation could provide an adversary with access to business resources such as the customer database in this example. Thus, this use case increases the risk for threats such as data tampering or information disclosure that target that database. Thus a key question for the acquirer is whether the use case as implemented by the supplier can be compromised.

23 23 The developer develops an information flow that meets the business requirements described by a use case.

24 24 In the next two slides, we show an implementation of an information flow for our use case and then describe how that implementation could be compromised. Access to customer information is managed by the database server. That server accepts queries to access or modify data that are written in a special-purpose programming language. Many commercial database products use what is called the Standard Query Language with the acronym SQL. A software application on the web server accepts the user input and uses it to create a SQL command that retrieves the ID, name, and phone number for the record with that ID. Such a query might look like this statement where the user input is inserted at the end. The database server executes that command and returns a table with the desired values. An attacker will attempt to exploit the connectivity created by this implementation of the use case.

25 25 A misuse case is a sequence of actions that can harm a system. Whereas a use case describes what a system should do, a misuse case describes what it should not do, that is, a misuse case is a security requirement. The misuse case for this example is a vulnerability called a SQL Injection, which frequently is at the top of lists of the most dangerous vulnerabilities. A misuse case for this example is a data exchange that starts with the value shown. Why would attackers try such a value? An attacker knows the implementation could create a database query written in SQL that includes the submitted value. The attacker s objective is to modify that query by inserting valid SQL constructs into the input. That s why it s called a SQL injection. The expression or(1=1) that has been inserted for this misuse case is a valid SQL expression. A SQL injection succeeds only if the software application fails to verify that the input is free of SQL expressions or, in this case that the input consists of 5 numeric digits. Maybe the programmer did not verify the input values as it was assumed that the database server respond with a record not found message for invalid ID values. But the command constructed by the software application using this input value is a valid query. Since the where condition is always true, the database server returns a table that contains the ID, name, and phone number for all entries. Variants of this compromise have been used to retrieve credit card data. Skilled attackers

26 26 have used SQL injections to change database entries. This misuse case is an example of an attacker using the connectivity with the user to exploit and compromise the database server.

27 27 We have a tug of war between security and system features where the outcome can help the attacker. A feature we call extensibility is a prime example. On the web, extensibility lets Yahoo and Google develop separate applications and retail vendors design interfaces to their own sales systems. An extensible industrial process control computer can be used by the purchaser to control an assembly line, a power generator, or traffic lights. But such extensibility also enabled the RSA compromise and an attack called Stuxnet that damaged more than 1,000 Iranian centrifuges at a nuclear facility. The web is good example of extensibility. When it was first created, a web page had data, instructions on how display that data, and links to other pages. The initial objective was to access information, rather than to read or make purchases. As the use of the web grew, organizations wanted to be able to add functionality without modifying the browser. A solution that s been applied in similar situations is to add processing instructions to the data feed. In other words, the web page contains data and processing

28 28 instructions often written in JavaScript. The browser shows displays the data and executes JavaScript instructions on that page which, for example, creates a drop-down menu for the user. We can change the items on the menu by changing the JavaScript on the web page rather than changing the browser. The processing instructions for an extensible military system or an industrial process controller are not on a web page but instead in a data file that is part of the configuration. The organization can update an extensible system by changing a data file rather than installing a new system. Smart phones also involve a form of extensibility. A user can customize a smart phone by installing applications rather than modifying that phone s core software. Extensibility is a great feature for almost everyone except those concerned with security. If a user can change a system by changing a data file, an adversary might be able to do it too. Extensibility has to be very well designed to avoid compromises. The more features requested in hardware and software products, the more exposure the system could receive as parts, modules, and libraries are acquired and integrated for the final system.

29 29 Analyzing use cases can provide an acquirer with valuable information. As we just showed, any critical business asset on the information flow for a use case is a possible target for an attack. We noted in the last slide that requirements for features such as extensibility increase the risk of a compromise. That risk might be reduced by using a commercial product where the developer explicitly considered how that feature could be compromised. A one-off custom implementation could have software weaknesses that a commercial developer had identified and avoided. The threat knowledge required should be included in the supplier selection criteria. Supplier s often have in-depth knowledge of the potential software weaknesses and attack patterns only for some domains such as financial systems, or for technologies such as those used for mobile access and industrial process controls. For example, the expertise that can avoid web server compromises is not necessarily applicable to a general purpose information system.

30 30 Next, we consider the two other risk factors considered by threat modeling. Compromises can arise from information we do not know about external systems, and system integration may have to contend with mismatches in the security assumptions made by the system components.

31 An adversary can exploit a weakness in an external resource to compromise the targeted system. In particular, external data sources are a significant risk because they provide a way for an attacker to submit values that could compromise a system. A system can depend on existing infrastructure services such as using the operating system to verify that a user is authentic. In our example, the system depends on the integrity and availability of a shared data store. 31

32 32 Secure network communications is an example of a security assumption. All software makes implicit security assumptions, for example by assuming the validity of a user so as to avoid repeated requests for an account name and password. An organization s security policy could require that a user be authenticated at a particular point in an information flow. Attacks frequently exploit unverified assumptions such as data validity which is a security risk as we saw in the SQL injection example. Whereas we only verified a user at selected points in an information flow, data validity has to be repeatedly checked. Invalid data can result from a software error rather than an adversary action. A security assumption that cannot be verified is a significant risk. For example, the designs for systems only used within an organization have often assumed that the internal network would not be accessed by an adversary an assumption we cannot verify. But with the success that expert and well-resourced attackers have had in obtaining network access, an increasing number of organizations assume the internal network will be compromised.

33 33 Next, we consider how an acquirer s requirements can affect the external dependencies and security assumptions that must be managed by the developer.

34 34 We combine the discussions of dependencies and security. Dependencies such as data sources or use of an acquirer s infrastructure services are often system requirements. Those dependencies have their own security assumptions. The required software functionality may be best provided by a commercial product, but the security assumptions for such software are not always known. Commercial off-the-shelf, or COTS, software may not be designed for high-assurance usage. Commercial developers have to balance the effort devoted to the threat resilience with competitive factors such as time to market and cost. The required threat resilience may have to be provided by how that product is integrated into the system. System integration may have to resolve security issues arising from the use of consumer computer devices such as tablets and cell phones. Security assumptions always arise for use cases that require data exchanges among independently developed and managed systems. The security assumptions are often not known and for externally managed systems can change without notice. How trusting should such a data exchange be? Has an external system been compromised? A security assumption such as trusting

35 35 a user whose identity was authenticated on a remote system requires careful analysis. For such data exchanges, the supplier selection criteria should include secure integration capabilities.

36 36 A supplier that is doing threat modeling uses the information collected on the risk factors to identify probably system risks and their mitigations. This step has to involve system stakeholders to prioritize the threats and make trade-off among business consequences, cost of mitigations, and system functionality. A supplier s development decisions have to be consistent with an acquirer s acceptable level of risk.

37 37 How can a supplier mitigate threats? This chart maps threats to the possible targets for that threat. An attacker seeking information might want to monitor network traffic or access a data store. An attacker with access to the network or a data store could modify data. Certainly access to a network or a data store could enable an attacker to limit access to a system.

38 38 We can use external security controls to mitigate threats that target network links or data stores. Examples of external controls include user authentication and access control, encrypted network links, and encrypted data stores.

39 Software can be a threat target. A SQL injection exploits a software weakness to access information and can also be used to modify data. The compromise of the RSA employee is an example of an elevation of privilege enabled by a vulnerability in a browser plug-in Software is a target for all six STRIDE threats, which increases the importance for developing threat resilient software. 39

40 40 An attacker can only exploit vulnerabilities in software on the information flows that process data they can submit, that is, data from external sources. Applications with access to critical assets require attention. But the continued occurrences of SQL injections suggest that such risks are too often ignored during design and implementation. Web browsers are a target because of their extensibility. The most recent web standard for HTML includes a long list of options such as support for multiple video formats. The implementation of a web page that has a data exchanges starts with defining the use cases that describe the exchanges, and the security assumptions and dependencies for the software that implements the use case. That software could reside on the web server or be included in the web page code to be executed by the browser. The number of possibilities can overwhelm threat modeling. An attacker can only exploit vulnerabilities in software on the information flows that process data they can submit, that is, data from external sources. Applications with access to critical assets require attention. But the continued occurrences of SQL injections suggest that such risks are too often ignored during design and implementation. Web browsers are a target because of their extensibility. The most recent web standard for HTML includes a long list of options such as support for multiple video formats. The

41 41 implementation of a web page that has a data exchanges starts with defining the use cases that describe the exchanges, and the security assumptions and dependencies for the software that implements the use case. That software could reside on the web server or be included in the web page code to be executed by the browser. The number of possibilities can overwhelm threat modeling.

42 42 As we noted earlier, external controls such as data encryption and network controls have been used to mitigate the risk of vulnerabilities. But the mitigations for many of the 900 identified software weaknesses must be done by the system software. Identifying threats and their appropriate mitigations must be done as part of the system development lifecycle. A number of organizations have executed security initiatives to reduce the number and severity of software weaknesses that appear in their software. The Build Security in Maturity Model is a joint effort by Cigital and Fortify to catalog the security activities for a collection of large organizations with such an initiative. Fifty-one organizations had been surveyed by the fall of One observation from the analysis of the BSIMM surveys is that the organizations with the most mature development practices had a strategic commitment to delivering secure software. What does that mean? Such a commitment includes incorporating security into the full development lifecycle. For example, design practices consider possible compromises; those doing detailed design and coding are aware of potential threats and recommended mitigations; and test plans include software weaknesses and the effectiveness of the system mitigations.

43 43 But a strategic commitment requires more than improved development practices. An organization with a strategic commitment has allocated sufficient resources to maintain its core knowledge of attacks and mitigations. The software functions with significant security risks might be developed by experts and then be made available in shared libraries to the application development teams. Such organizations incorporate appropriate standards. A key measure of a strategic commitment is reflected in an organization s governance practices and policies. Have all developers received training on writing secure software? Have security checkpoints, milestones, and signoffs been established at various points in the development lifecycle to ensure consistent and effective application of the lifecycle practices? A security signoff at various times during development ensures that someone has accepted responsibility for security.

44 Next, we discuss how to apply aspects of threat modeling to the acquisition lifecycle. 44

45 45 In this section, we show how knowledge of the interactions between requirements and a developer s threat analysis could be used. We use an FAA project done in 2009 as an example. The FAA objective was to create an external web site that provided current commercial flight information to non-government organizations. An internal FAA system was the source of that data.

46 46 Acquisition requirements should consider possible threats. For this example, the data on the web site could be modified. A more serious threat is that an attacker gains access to the web server and uses that access to compromise the internal FAA system. That internal system may have assumed a very trusting operational environment. But for this example, the FAA system should not trust the web server, that is, it should assume that adversaries have accessed it.

47 47 If we have a medical condition that requires surgery, we seek a specialist. The risk of data tampering requires a supplier with knowledge of compromises associated with data exchanges such as SQL injections. There is a very sophisticated attack community that target web servers. Hence, suppliers should be very knowledgeable about known web site compromises. A supplier s staff must be capable of writing secure web applications. The possibility of compromising the FAA internal systems increases the importance of source selection. In addition to having web security expertise, a supplier for this example should know how an information system like the FAA system could be compromised. This aspect of development might require cooperation between the supplier and those who know the design and security assumptions for the FAA system.

48 48 Supplier selection criteria have to identify suppliers with the experience and capabilities needed to test the system. For example, security testing frequently includes penetration tests in which a skilled attack team tries to compromise a system. For this example, a penetration team experienced with web attacks should attempt to compromise the server. But the most significant threat is an attacker with web server access who compromises the internal FAA system. The penetration team now has access to the web server. This team is likely different from the first one because its members should have experience in compromising large information systems rather than web servers. Finally, it is critical for the acquisition strategy, source selection, procurement contracts, and so forth to enable the acquiring organization to access the artifacts produced by the development practices. For example, an acquirer could require that the supplier provide the results and analysis of the penetration tests to confirm that testing considered possible compromises.

49 We conclude with a summary. 49

50 50 The overall objective is to reduce the frequency and severity of unintentional software weaknesses created during development. In this presentation, we suggested several ways that such risks could be identified early in the lifecycle. Building security in includes anticipating threats but also incorporating security into the full development lifecycle so that possible weaknesses are identified early. But risk reduction also depends on understanding the security risks of software features and system usage. The improved development practices that support building security into a system also have their limits. Ross Anderson is a highly respected computer scientist and security engineer. In an interview, he was asked about the progress being made for security engineering. He noted that over the last 30 years, developers have been provided with improved tools and methods for developing systems, but the percentage of development failures has stayed around 30%. Better tools encouraged the development of larger and more complex systems and also created more dramatic failures. We have a similar situation for security engineering. Threat modeling can remove known weaknesses, but having a large set of system requirements also increases the threat factors that must be considered by the supplier. The additional complexity can create new vulnerabilities, increase the possibility that known weaknesses could be missed, and force system stakeholders to accept higher security risks.

51 51 Practices such as threat modeling help us reduce the likelihood of a malicious compromise but cannot eliminate the possibility of one. Continuous monitoring of system behavior is necessary. Attack techniques and exploitable vulnerabilities evolve, but the consequences as described by STRIDE are constant. We need to build security controls into a system such as strong user authentication, encryption, and auditing that reduce the likelihood of an information disclosure and be able to recover from an attack that tampered with critical assets. Security can be improved if we do not focus exclusively on malicious intent. We may only know after an incident that a problem with data integrity was the result of malicious data tampering and not the result of an accidental user action not anticipated by system designers. The intent should be secondary to mitigating and recovering from possible failures. System capabilities such as rapid recovery that increase resiliency to operational, software, and hardware failures also improve resiliency to a security compromise.

52 52