Chapter 7. Special Topics in Cyber Security Engineering

with Julia Allen, Warren Axelrod, Stephany Bellomo, and Jose Morales

• This chapter starts with a discussion of governance, recognizing that security is more than just a technical issue, and describes how organizations can set clear expectations for business conduct and then follow through to ensure that the organization fulfills those expectations.

• Then this chapter describes some findings on cyber security standards, an important area that is still evolving.

• Organizations that perform acquisition—rather than development—can achieve an emphasis on security requirements by using Security Quality Requirements Engineering for Acquisition (A-SQUARE). All too often, cyber security is left to contractors, with little attention from acquisition organizations until systems are delivered or operational. We hope to see organizations address cyber security much earlier in the acquisition lifecycle, and security requirements are a good place to start.

• Next, this chapter discusses DevOps. In the field we are finally seeing recognition of the synergy of development and operations, after years of seeing them treated as disparate activities in a stovepiped project environment.

• Finally, this chapter discusses some recent research work that seeks to identify ways organizations can use malware analysis to identify security requirements that have led to vulnerabilities in earlier systems. These overlooked requirements can then be incorporated into the security requirements for future systems.

Each of these topics is unique, and you may not be interested in all of them. We offer them as a deeper exploration in specific areas of cyber security engineering.

Security’s days as just a technical issue are over. Security is becoming a central concern for leaders at the highest levels of many organizations and governments, and it transcends national borders. Today’s organizations face constant high-impact security incidents that can disrupt operations and lead to disclosure of sensitive information. Customers are demanding greater security as evidence suggests that violations of personal privacy, the disclosure of personally identifiable information, and identity theft are on the rise. Business partners, suppliers, and vendors are requiring greater security from one another, particularly when providing mutual network and information access. Networked efforts to steal competitive intelligence and engage in extortion are becoming more prevalent. Security breaches and data disclosure increasingly arise from criminal behavior motivated by financial gain as well as state-sponsored actions motivated by national strategies.

Current and former employees and contractors who have or had authorized access to their organization’s system and networks are familiar with internal policies, procedures, and technology and can exploit that knowledge to facilitate attacks and even collude with external attackers. Organizations must mitigate malicious insider acts such as sabotage, fraud, theft of confidential or proprietary information, and potential threats to our nation’s critical infrastructure. Recent CERT research documents cases of successful malicious insider incidents even during the software development lifecycle.²

2. Refer to the CERT Insider Threat website (www.cert.org/insider-threat/publications) for presentations and podcasts on this subject.

In the United States, managing cyber security risk is becoming a national imperative. In February 2013, the U.S. president issued an executive order³ to enhance the security of the nation’s critical infrastructure, resulting in the development of the National Institute of Standards and Technology (NIST) Cybersecurity Framework [NIST 2014]. According to the IT Governance Institute, “boards of directors will increasingly be expected to make information security an intrinsic part of governance, integrated with processes they already have in place to govern other critical organizational resources” [ITGI 2006]. The National Association of Corporate Directors (NACD) states that the cyber security battle is being waged on two levels—protecting a corporation’s most valuable assets and the implications and consequences of disclosure in response to legal and regulatory requirements [Warner 2014]. According to an article in NACD Magazine, “Cybersecurity is the responsibility of senior leaders who are responsible for creating an enterprise-wide culture of security” [Warner 2014]. At an international level, the Internet Governance Forum (IGF)⁴ provides a venue for discussion of public policy issues, including security, as they relate to the Internet. Ultimately, directors and senior executives set the direction for how enterprise security—including software security—is perceived, prioritized, managed, and implemented. This is governance in action.

3. www.whitehouse.gov/the-press-office/2013/02/12/executive-order-improving-critical-infrastructure-cybersecurity

4. www.intgovforum.org/cms/home-36966

The Business Roundtable (an association of chief executive officers of leading U.S. companies) recommends the following in its report More Intelligent, More Effective Cybersecurity Protection [Business Roundtable 2013]:

As additional evidence of this growing trend, the Deloitte 2014 Board Practices Report: Perspective from the Boardroom states the following [Deloitte 2014]:

According to the Building Security In Maturity Model [McGraw 2015],

While growing evidence suggests that senior leaders are paying more attention to the risks and business implications associated with poor or inadequate security governance, a recent Carnegie Mellon University survey indicates that there is still a lot of room for improvement [Westby 2012]:

• Boards are still not undertaking key oversight activities related to cyber risks, such as reviewing budgets, security program assessments, and top-level policies; assigning roles and responsibilities for privacy and security; and receiving regular reports on breaches and IT risks.

• 57% of respondents are not analyzing the adequacy of cyber insurance coverage or undertaking key activities related to cyber risk management to help them manage reputational and financial risks associated with the theft of confidential and proprietary data and security breaches.

Moreover, organizations are not the only entities that benefit from strengthening enterprise⁵ security through clear, consistent governance. Ultimately, entire nations benefit. “The national and economic security of the United States depends on the reliable functioning of critical infrastructure. Cybersecurity threats exploit the increased complexity and connectivity of critical infrastructure systems, placing the nation’s security, economy, and public safety and health at risk” [NIST 2014].

5. We use the terms organization and enterprise to convey the same meaning.

6. As used here, security includes software security, information security, application security, cyber security, network security, and information assurance. It does not include disciplines typically considered within the domain of physical security such as facilities, executive protection, and criminal investigations.

• Directing and controlling an organization to establish and sustain a culture of security in the organization’s conduct (values, beliefs, principles, behaviors, capabilities, and actions)

• Treating adequate security as a non-negotiable requirement of being in business

The NIST Cybersecurity Framework defines information security governance as follows: “The policies, procedures, and processes to manage and monitor the organization’s regulatory, legal, risk environmental, and operational requirements are understood and inform the management of cybersecurity risk” [NIST 2014].

In the context of security, governance incorporates a strong focus on risk management. Governance is an expression of responsible risk management, and effective risk management requires efficient governance. One way governance addresses risk is to specify a framework for decision making. It makes clear who is authorized to make decisions, what the decision-making rights are, and who is accountable for decisions. Consistency in decision making across an enterprise, a business unit, or a project boosts confidence and reduces risk.

• How can an organization know what its greatest security risk exposures are?

• How can an organization know if it is secure enough to do the following:

• Detect and prevent security events that require business-continuity, crisis-management, and disaster-recovery actions?

• Protect stakeholder interests and meet stakeholder expectations?

• Comply with regulatory and legal requirements?

• Develop, acquire, deploy, operate, and use application software and software-intensive systems?

• Ensure enterprise viability?

ANSI has the following to say with respect to an organization’s fiduciary duty of care [ANSI 2008]:

As a result, director and officer oversight of information and cyber security (including software security) is embedded within the duty of care owed to enterprise shareholders and stakeholders. Leaders who hold equivalent roles in government, non-profit, and educational institutions must view their responsibilities similarly.

It seems clear that boards of directors, senior executives, business unit and operating unit leaders, and project managers all must play roles in making and reinforcing the business case for effective enterprise security. Trust, reputation, brand, stakeholder value, customer retention, and operational costs are all at stake if security governance and management are performed poorly. Organizations are much more competent in using security to mitigate risk if their leaders treat it as essential to the business and are aware of and knowledgeable about security issues.

7. See also “Characteristics of Effective Security Governance” [Allen 2007] for a table of 11 characteristics that compares and contrasts an organization with effective governance practices and one where these practices are missing.

Leaders who are committed to dealing with security at a governance level can use the following list to determine the extent to which a security-conscious culture is present (or needs to be present) in their organizations:

• The organization manages security as an enterprise issue, horizontally, vertically, and cross-functionally throughout the organization and in its relationships with partners, vendors, and suppliers. Executive leaders understand their accountability and responsibility with respect to security for the organization, their stakeholders, the communities they serve including the Internet community, and the protection of critical national infrastructures and economic and national security interests.

• The organization treats security as a business requirement. The organization sees security as a cost of doing business and an investment rather than an expense or discretionary budget-line item. Leaders at the top of the organization set security policy with input from key stakeholders. Business units and staff are not allowed to decide unilaterally how much security they want. Adequate and sustained funding and allocation of adequate security resources are given.

• The organization considers security as an integral part of normal strategic, capital, project, and operational planning cycles. Strategic and project plans include achievable, measurable security objectives and effective controls and metrics for implementing those objectives. Reviews and audits of plans identify security weaknesses and deficiencies as well as requirements for the continuity of operations. They measure progress against plans of action and milestones. Determining how much security is enough relates directly to how much risk exposure an organization can tolerate.

• The organization addresses security as part of any new project initiation, acquisition, or relationship and as part of ongoing project management. The organization addresses security requirements throughout all system/software development lifecycle phases, including acquisition, initiation, requirements engineering, system architecture and design, development, testing, release, operations/production, maintenance, and retirement.

• Managers across the organization understand how security serves as a business enabler (versus an inhibitor). They view security as one of their responsibilities and understand that their team’s performance with respect to security is measured as part of their overall performance.

• All personnel who have access to digital assets and enterprise networks understand their individual responsibilities with respect to protecting and preserving the organization’s security, including the systems and software that it uses and develops. Awareness, motivation, and compliance are the accepted, expected cultural norm. The organization consistently applies and reinforces security policy compliance through rewards, recognition, and consequences.

The relative importance of each of these statements depends on the organization’s culture and business context. For those who are accustomed to using ISO/IEC 27001 [ISO/IEC 2013], similar topics can be found at a higher level.

An additional standard that is part of the PCI DSS standards suite is the Payment Application Data Security Standard (PA-DSS) [PCI Security Standards Council 2013]. PA-DSS specifically addresses software security. Its purpose is to assist software vendors of payment applications to develop and deploy products that are more secure, that protect cardholder data, and that comply with the broader PCI standard. All 14 PA-DSS practice descriptions include detailed subpractices and testing procedures for verifying that the practice is in place. The PCI Standards Council maintains a list of validated payment applications that meet this standard. Payment card merchants can use it to select applications that ensure better protection of cardholder data.

To be able to certify compliance with security standards, we clearly first need to have a set of generally accepted standards. Although there have been quite a number of attempts to achieve acceptable information security standards, no overarching set is being consistently followed.

Governments around the globe favor the Common Criteria for Information Technology Security Evaluation, also known as ISO/IEC 15408. The PCI DSS [PCI Security Standards Council 2015] and the PA-DSS [PCI Security Standards Council 2013] apply to those handling payment card information and the vendors of software that process this information, respectively.

A subset of software systems need to be certified according to the Common Criteria or PCI standards in order for their acquisition and/or use to be permitted. It is noteworthy that, in both these cases, the standard-setting authorities (i.e., various government agencies and payments processing companies) are relatively powerful in terms of purchasing power (governments) or scope of influence (PCI).

Other compliance or certification reviews—such as auditing against International Organization for Standardization (ISO) or International Electrotechnical Commission (IEC) standards in general as well as specific audit reviews in particular—usually target specific departments and processes within an organization, and the certifications mostly apply only to an examined process at a specific point in time (for example, SSAE 16 reviews, which replaced SAS 70 Type 1 and Type 2 reviews). Such reviews usually do not dig deeply into the particular technologies in operation, nor do they determine whether these technologies meet a certain quality level. However, certain types of technical audits examine program code, platforms, networks, and the like.

Some regulators require broader “policy and procedures” compliance reviews. For example, the National Association of Securities Dealers Regulations (NASDR) requires securities firms in the U.S. to perform and report on extensive reviews of back-office and IT policy and procedures to ensure that they actually exist, are fully documented, and meet certain governance requirements. This situation suggests that we must better understand what standards are and how they relate to directives, policy, guidelines, procedures, etc. Table 7.1 provides a comparison among these various categories.

Table 7.1 includes descriptions from a variety of sources. It is interesting to note that they are not all definitions, and though some descriptions are similar, they are not entirely consistent. Nonetheless, our intent is to show the range of descriptions—where they are the same and where they differ. Inconsistencies might result in the misuse of definitions and terms, confusion about the meaning of terms, and consequent misdirection. These problems could account in large part for the inconsistent use of information security standards.⁹

9. A similar lack of focus and specificity exists in attempts to define policy standards and procedures for cyber warfare, which can have much graver outcomes. Nevertheless, the lack of cyber security standards, despite the proliferation of policies, is extremely costly in financial, economic, and social terms.

The main result of this disparity of descriptions is a hierarchy of rules, some of which are mandatory (“must”) and some of which are optional (“should”). These rules are set at different levels within an organization, usually apply to lower-level groups, and are enforced and audited by other parties.

We need accepted standards and a rich compendium of baselines in order to support universal measures of software cyber security assurance. When standards are not used, the fallback is usually to substitute common, essential, or “best” practices, with the argument that an organization cannot be faulted if it is as protective as or more protective than its peers in applying available tools and technologies.¹⁰

10. Donn Parker asserts that it is impossible to calculate cyber security risk, so metrics are meaningless [Parker 2009]. Steven Lipner claims that a metric for software quality does not exist [Lipner 2015]. Parker suggests implementing the best practices of peer organizations. Peter Tippett, who claims to have invented the first antivirus product, stated that there is no such thing as a “best practice” and instead uses the term “essential practice” to refer to a generally accepted approach [Tippett 2002].

This logic is somewhat questionable since it frequently leads to compliance with mediocrity: If one organization is vulnerable, then other organizations that applied the same level of security are vulnerable also. We see this phenomenon in action when similar organizations fall victim to similar successful attacks.

Experts have argued that software monocultures lead to less secure systems environments. We can consider this argument in the context of software cyber security assurance processes: When many organizations in the same industries use similar systems and observe similar security measures, those organizations become more vulnerable. Organizations could benefit from varying their approaches to cyber security assurance.

11. www.forbes.com/sites/peterhigh/2015/12/07/a-conversation-with-the-most-influential-cybersecurity-guru-to-the-u-s-government/

• NIST SP 800-160: System Security Engineering: An Integrated Approach to Building Trustworthy Resilient Systems

• IEEE/ISO 15288: Systems and Software Engineering—System Life Cycle Processes

• The NIST TACIT approach for system security engineering: Threat, Assets, Complexity, Integration, Trustworthiness¹²

12. Summarized in slide form at http://csrc.nist.gov/groups/SMA/fisma/documents/joint-conference_12-04-2013.pdf.

Another important document is NIST SP 800-53: Recommended Security Controls for Federal Information Systems and Organizations. This document has undergone several revisions in recent years and is being used extensively in government software systems acquisition and development. In addition, standards such as ISO/IEC 27001, ISO/IEC 27002, ISO/IEC 27034, and ISO/IEC 27036 all provide useful support, and NIST Special Publication 800-161 addresses supply chain risk.

There have been some efforts related to acquisition of secure software. The Open Web Application Security Project (OWASP) group provides guidance for contract language that can be used in acquisition; the guidance includes a brief discussion of requirements [OWASP 2016]. An SEI method is available to assist in selecting COTS software [Comella-Dorda 2004]. The Common Criteria approach provides detailed guidance on how to evaluate a system for security [Common Criteria 2016]. In addition, there are security requirements engineering methods, such as SQUARE [Mead 2005], SREP [Mellado 2007], and Secure Tropos [Giorgini 2006]; some of these methods address the acquisition of secure software. The recent NIST Special Publication 800-53, Revision 4 provides guidance for selecting security controls [NIST 2013], and NIST Special Publication 800-161 addresses supply chain risk [NIST 2015].

We next examine various acquisition cases for security requirements engineering, using the SQUARE process model as a baseline.

In the event that the contractor’s security requirements engineering process is unspecified, the resulting compressed process looks as shown in Table 7.4.

Note that in acquiring COTS software, organizations often do minimal trade-off analysis and may not consider security requirements at all, even when they do such trade-off analysis. The acquiring organization should consider “must have” versus “nice to have” security requirements. In addition, reviewing the security features of specific offerings may help the acquiring organization identify the security requirements that are important.

It is important to note that A-SQUARE is just one approach for identifying security requirements during acquisition. We suggest exploring other existing methods before making a decision on which one to use.

Problems such as these drove a handful of practitioners to talk openly about practices they apply on their own projects to address similar problems. This discussion ultimately led to the birth of the DevOps movement. In 2009, Flickr’s John Allspaw and Paul Hammond gave a cornerstone talk at Velocity, titled “10+ Deploys Per Day”¹⁴ that got the attention of the operations community. They described several practices for reducing deployment cycle time while maintaining a high degree of operational stability/resiliency. In 2009, Patrick Debois from Belgium and Andrew “Clay” Shafer from the United States coined the term DevOps. Debois held the first DevOpsDays event in Ghent in 2010. Today, DevOpsDays conferences are held in cities all over the world. The initial scope of the DevOps movement focused primarily on cloud-based information technology (IT) systems; however, the scope has since broadened. There is general agreement that the specific DevOps practices used on each project can and should be evaluated for suitability and tailored for each project context. We are seeing some DevOps practices applied to non-IT-based systems, including embedded and real-time safety-critical systems, such as avionics, automobiles, and weapons systems [Regan 2014].

14. www.youtube.com/watch?v=LdOe18KhtT4

DevOps is essentially a term for a group of concepts that catalyzed into a movement. At a high level, DevOps can be characterized by two major themes: (1) collaboration between development and operations staff and (2) a focus on improving operational work efficiency and effectiveness. We discuss these themes in the next sections.

For many projects, software releases were high-risk events; because of this, many software projects bundled various features together, delaying delivery of completed functionality to users. Continuous delivery suggests a paradigm shift in which features/development changes are individually deployed after the software has passed a series of automated tests/pre-deployment checks. We revisit the deployment pipeline in the next section.

In the popular book Visible Ops Security, the authors describe competing objectives between development and operations groups that cause natural tension [Kim 2008]. Development teams are pressured to make changes faster to respond to business needs. On the other hand, operations teams are incentivized to reduce risk and minimize change because they are responsible for maintaining stable, secure, and reliable IT service. The idea behind Visible Ops Security is that integrating information security (InfoSec) staff on DevOps projects helps alleviate this conflict (see Figure 7.2).

The process of integrating InfoSec into the DevOps project context is described in four phases in Visible Ops Security [Kim 2008]. In the next sections, we use these four phases to structure the discussion of security-related DevOps practices. The term DevOpsSec refers to extending the concept of DevOps by integrating InfoSec.

The following Twitter case study provides an example of a success story about an InfoSec team that successfully integrated a suite of security tests into the continuous build and integration lifecycle.

Once the pre-deployment environment conformance checks are clean and all tests have passed, it is time to deploy code into production. We highly recommend using automated scripts for releasing code into production. These automated scripts, and associated configuration files, are also useful artifacts for InfoSec analysis. They can be used by InfoSec team members to validate that the software deployment configuration conforms to the approved design document.

A key source of input for DevOps dashboards and alerts is log files (e.g., audit, error, and status logs). As with traditional system development, log data is typically routed to a common location, where it can be accessed for dashboard display and other analysis purposes. As with traditional projects, audit logs—particularly information about changing privileges or roles—continue to be useful artifacts for InfoSec analysis. These logs can also be used to support anomaly detection analysis, which involves monitoring for deviation from normal usage patterns. Operations staff use approaches such as anomaly detection analysis to monitor for issues ranging from software responsiveness to cyberattack. In fact, at DevOps DC in June 2015, there was much talk of work that focused on developing complex algorithms leveraging metrics generated from various DevOps tools to identify patterns of deviation and malicious behavior.

Hundreds of vulnerabilities are publicly disclosed each month [NIST 2016]. Exploitable vulnerabilities typically emerge from one of two types of core flaws: code flaws and design flaws. In the past, both types of flaws have facilitated several cyberattacks, a subset of which manifested globally.

We define a code flaw as a vulnerability in a code base that requires a highly technical, crafted exploit to compromise a system; examples are buffer overflows and command injections. Design flaws are weaknesses in a system that may not require a high level of technical skill to craft exploits to compromise the system. Examples include failure to validate certificates, non-authenticated access, automatic granting of root privileges to non-root accounts, lack of encryption, and weak single-factor authentication. A malware exploit is an attack on a system that takes advantage of a particular vulnerability.

A use case [Jacobson 1992] describes a scenario conducted by a legitimate user of the system. Use cases have corresponding requirements, including security requirements. A misuse case [Alexander 2003] describes use by an attacker and highlights a security risk to be mitigated. A misuse case describes a sequence of actions that can be performed by any person or entity to harm the system. Exploitation scenarios are often documented more formally as misuse cases. In terms of documentation, misuse cases can be documented in diagrams alongside use cases and/or in a text format similar to that of a use case.

Several approaches for incorporating security into the software development lifecycle (SDLC) have been documented. Most of these enhancements have focused on defining enforceable security policies in the requirements gathering phase and defining secure coding practices in the design phase. Although these practices are helpful, cyberattacks based on core flaws have persisted.

Major corporations, such as Microsoft, Adobe, Oracle, and Google, have made their security lifecycle practices public [Lipner 2005; Oracle 2014; Adobe 2014; Google 2012]. Collaborative efforts, such as the Software Assurance Forum for Excellence in Code (SAFECode) [Bitz 2008], have also documented recommended practices. These practices have become de facto standards for incorporating security into the SDLC.

These security approaches are limited by their reliance on security policies, such as access control, read/write permissions, and memory protection, as well as on standard secure code writing practices, such as bounded memory allocations and buffer overflow avoidance. These processes are helpful in developing secure software products, but—given the number of successful exploits that occur—they fall short. For example, techniques such as design reviews, risk analysis, and threat modeling typically do not incorporate lessons learned from the vast landscape of known successful cyberattacks and their associated malware.

The extensive and well-documented history of known cyberattacks can be used to enhance current SDLC models. More specifically, a known malware sample can be analyzed to determine whether it exploits a vulnerability. The vulnerability can be studied to determine whether it results from a code flaw or a design flaw.

For design flaws, we can attempt to determine the overlooked requirements that resulted in the vulnerability. We make this determination by documenting the misuse case corresponding to the exploit scenario and creating the corresponding use case. Such use cases represent overlooked security requirements that should be applied to future development and thereby avoid similar design flaws leading to exploitable vulnerabilities. This process of applying malware analysis to ultimately create new use cases and their corresponding security requirements can help enhance the security of future systems.

Design flaws result from weaknesses that do not necessarily require code-based exploits to compromise the system. More specifically, a design flaw can result from overlooked security requirements. Examples are failure to validate certificates, non-authenticated access, root privileges granted to non-root accounts, lack of encryption, and weak single-factor authentication. Some design flaws can be exploited with minimal technical skill, leading to more probable system compromise. The process leading to a vulnerability exploit or remediation via software update is shown in Figure 7.4 [Mead 2014]. We focus on vulnerabilities resulting from a design flaw. In these cases, the overlooked requirements can be converted to a use case applicable to future SDLC cycles.

A large body of well-documented and studied cyberattacks is available to the public via multiple sources. In this section, we describe some publicly disclosed cases of exploited vulnerabilities that facilitated cyberattacks and arose from design flaws. For each case, we describe the vulnerability and the exploit used by malware. We also present the overlooked requirement(s) that led to the design flaw that created the vulnerability. By learning from these cases and analyzing associated malware, we can create use cases that can be included in SDLC models.

A user could be granted access by simply changing his or her web browser’s user-agent string to “xmlset_roodkcableoj28840ybtide.” Interestingly, the string in reverse partially reads “editby04882joelbackdoor.” It was later determined that this string was used to automatically authenticate configuration utilities stored within the router.

The utilities needed to automatically reconfigure various settings and required a username and password (which could be changed by a user) to access the administration panel. The hardcoded string comparison was implemented to ensure that these utilities accessed and reconfigured the router via the web server whenever needed, without requiring a username and password.

The internally stored configuration utilities should not have been required to access the administration panels via the router’s web server, which is typically used to grant access to external users. A non-web-server-based communication channel between internally stored proprietary configuration utilities and the router’s firmware could have avoided the specific exploit described here, although further analysis could have led to a more general solution.

A malicious application already installed in a lower version of Android OS would claim specific privileges and attributes that were available only in a higher version of the Android OS. When the OS was upgraded to the higher version, the claimed privileges and attributes were automatically granted to the application without user awareness.

The overlooked requirement in this case was to specify that during an upgrade of the Android OS, previously installed applications should not be granted privileges and attributes introduced in the higher OS without user authorization.

When an executable file starts running on an operating system such as Windows, a check for a valid digital signature is performed. If the signature is invalid, the user receives a warning that advises him or her not to allow the program to execute on the system. By possessing a valid digital signature, malware can execute on a system without generating any warnings to the user.

The reliance on a digital signature to allow execution of binaries on a system is no longer sufficient to avoid malware infection. The overlooked requirement in this case was to, along with verifying the digital signature, carry out multiple security checks before granting execution privilege to a file, such as the following:

• Scanning the file for known malware

• Querying whether the file has ever been executed in the system before

• Checking whether the digital signature was seen previously in other legitimate files executed on this system

The following abstracts can lead to requirements statements:

• Case 1: Identify all possible communication channels—Designate valid communication channels and do not permit other communication channels to gain privileges.

• Case 2: Do not automatically transfer privileges during an upgrade—Request validation from the user that the application or additional user should be granted privileges.

• Case 3: Require multiple methods of validation on executable files—In addition, as a default, consider asking for user confirmation prior to running an executable file.

In addition to the specific cases of exploited vulnerabilities discussed above, there have been several other cyberattacks on software systems that used one or more exploited vulnerabilities resulting from either a code flaw or a design flaw. These vulnerabilities are defined in a hierarchical structure using the Common Weakness Enumeration (CWE) [Kitten 2013; MITRE 2014].

The CWE provides a common language to discuss, identify, and handle causes of software security vulnerabilities. These vulnerabilities can be found in source code, system design, or system architecture. An individual CWE represents a single vulnerability type. A subset of CWEs can be attributed to design flaws resulting from overlooked requirements; some of the design flaw CWEs pertinent to the cases above are listed in Table 7.6.

The lessons learned from previous cyberattacks and the underlying CWEs can be used to better understand overlooked requirements and resulting security implications. Analyzed and publicly disclosed cyberattacks provide details about how attackers implemented an exploit on a specific vulnerability. CWEs provide a better understanding of security vulnerabilities underlying a cyberattack. Combining information from these two sources facilitates the creation and inclusion of use cases that capture the overlooked requirements that lead to design flaws.

Vendors inform the public of vulnerabilities that are considered critical and that impact a large user base; the OpenSSL Heartbleed vulnerability is an example of such a vulnerability [Wikipedia 2014a]. A vulnerability is usually identified via malware analysis after the malware has entered the wild and compromised systems. Sometimes the discovered exploited vulnerability in the analyzed malware is a zero-day vulnerability.

Zero-day [Wikipedia 2014b] vulnerabilities are some of the biggest threats to cyber security today because they are discovered in private. They are typically kept private and exploited by malware for long periods of time. “Zero-days” afford malware authors time to craft exploits. Zero-days are not guaranteed to be detected by conventional security measures, making their threat even more serious.

One approach to avoid creating vulnerabilities is to implement secure lifecycle models. These models can be enhanced with the inclusion of use cases that are derived from previously discovered vulnerabilities that resulted from design flaws. Analyzing malware that exploits a vulnerability provides details of the vulnerability itself and, more importantly, provides details of the exploit implementation. The exploit details can offer additional insight into the vulnerability and the underlying design flaw.

The previous examples indicate that standard secure lifecycle practices may not be adequate to identify all avenues for potential attacks. Potential attacks must be addressed at requirements collection time (and at every subsequent phase of the lifecycle).

The selected case studies illustrate that malware analysis can reveal needed security requirements that may not be identified in the normal course of development, even when secure lifecycle practices are used. At present, malware discovery is often used to develop patches or address coding errors but not necessarily to inform future security requirements specification. We believe that failure to exercise this feedback loop is a serious flaw in security requirements engineering, which tends to start with a blank slate rather than use lessons learned from prior successful attacks. We recommend that secure lifecycle practices be modified to benefit from malware analysis.

Examining techniques that are focused on early security development lifecycle activities can reveal how malware analysis might be applied. We recommend a process for creating malware-analysis–driven use cases that incorporates malware analysis into a feedback loop for security requirements engineering on future projects and not just into patch development for current systems [Mead 2014]. Such a process can be implemented using the following steps (also illustrated in Figure 7.5 [Mead 2014]:

1. A malicious code sample is analyzed both statically and dynamically.

2. The analysis reveals that the malware is exploiting a vulnerability that results from either a code flaw or a design flaw.

3. In the case of a design flaw, the exploitation scenario corresponds to a misuse case that should be described. The misuse is analyzed to determine the overlooked use case.

4. The overlooked use case corresponds to an overlooked security requirement.

5. The use case and corresponding requirements statement is added to a requirements database.

6. The requirements database is used in future software development projects.

Steps 1 and 2 include standard approaches to analyzing a malicious code sample. The specific analysis techniques used in steps 1 and 2 are beyond the scope of this paper. In step 2, the analysis is used to determine whether the exploited vulnerability is the result of a code flaw or a design flaw. Typically, the source of the vulnerability can be determined through detailed analysis of the exploit code. Of course, these steps presume that the malware is detected, which in itself is a challenge.

Step 2 illustrates the advantage of malware analysis by leveraging the exploit code to determine the flaw type. Standard vulnerability discovery and analysis without malware analysis excludes exploit code and may make flaw type identification less straightforward.

Step 3 details how the exploit was carried out in the form of a misuse case, which provides the needed information to determine the overlooked use case that led to the design flaw.

In step 4, the overlooked use case is the basis for deciding what may have been the overlooked requirement(s) at the time the software system was created that led to the design flaw. These are the requirements that should have been included in the original SDLC of the software system, which would have prevented creation of the design flaw that led to the exploited vulnerability.

Steps 5 and 6 record the overlooked use case and corresponding requirement(s) for use in future SDLC cycles. This process is meant to enhance future SDLC cycles in a simplified manner by providing known overlooked requirements that led to exploited vulnerabilities. By including these requirements in future SDLC cycles, the resulting software systems can be made more secure by helping to avoid the creation of exploitable vulnerabilities.

As mentioned earlier in this chapter, an extended case study explored the proposed process of analyzing a malware sample. Using a sample of malware that steals data from Android mobile devices, we determined the exploitation scenario that was used by the malware exploit. Our investigation into the consequences of this malware exploit revealed a design flaw in a mobile application that could compromise user data. We studied the design flaw to determine the applicable misuse cases and used those misuse cases to ascertain the missing security requirements to be used on future mobile applications for the Android platform [Alice 2014; Mead 2015].

A prototype tool has been developed to support the process of enhancing exploit reports to include misuse cases, use cases for mitigation, and overlooked security requirements. These enhanced reports are then stored in a database that can be used by requirements engineers on future systems. The source code for the MORE tool (Malware Analysis Leading to Overlooked Security Requirements) is available for free download from www.cert.org/cybersecurity-engineering/research/security-requirements-elicitation.cfm.

Exploit kits [McGraw 2015] are often used by malware in a plug-and-play fashion to infect a system. An exploit kit is a piece of software that contains working exploits for several vulnerabilities. It is designed to run primarily on a server (an exploit server) to which victim machines are redirected after a user clicks a malicious link, either in a webpage or an email. The victim machine is scanned for vulnerabilities. If a vulnerability is identified, the exploit kit automatically executes any applicable exploit to compromise the machine and infect it with malware. In general, malware either has exploits built into its binary or relies on exploit kits to initially compromise a machine. The implications of exploit kits is another area of exploration that may provide code samples for use in the process.

An open question for consideration: Do specific types of malware exist that are likely to occur in specific kinds of critical systems, such as control systems? Analysis of historical and current malware incidents may help to identify exploits that target specific types of applications. Knowing these exploit types in advance could help requirements engineers identify standard misuse cases and the needed countermeasures for their specific application types.

These misuse cases would again lead to corresponding use cases and security requirements. It may be wishful thinking to expect all developers of future systems to give priority to security requirements and apply the methods that we are postulating. However, developers of mission-critical systems, financial systems, and other essential systems, such as critical infrastructure systems, recognize the importance of security and should be willing to invest in it throughout the development process.