This article first appeared in IEEE IT Professional magazine. IEEE IT Professional offers solid, peer-reviewed information about today's strategic technology issues. To meet the challenges of running reliable, flexible enterprises, IT managers and technical leads rely on IT Pro for state-of-the-art solutions.
Before writing a single line of code, software engineers can increase application assurance by instituting the practice recommendations articulated in their enterprise architecture. These recommendations should address application architecture and design, as 40 percent of software weaknesses can be addressed in these early phases of the development life cycle.1
Addressing Common Weaknesses
The Common Weakness Enumeration (CWE) is a compendium of nearly 1,000 flawed and bugprone software practices. It offers, in essence, the root causes of the more wellknown (and far more numerous) common vulnerabilities and exposures (CVEs). CVE numbers are assigned when researchers or firms report specific software vulnerabilities; there are currently more than 61,000 documented CVEs.
Managed by MITRE under sponsorship of the Department of Homeland Security, the CWE provides a publicly available, unified, measurable set of software weaknesses. CVEs are akin to an inventory of traffic accidents, while the CWEs are analogous to the conditions and practices (such as the highway architecture, bridge and road design, traffic signage, driver practices, and enforcement procedures) that lead to accidents.
Unlike CVEs, the CWE is intended for descriptions of good developer practices. The enterprise can use it for policy recommendations and coding standards and for nomenclature for software security tools and services. Thus, the CWE promotes a better understanding and management of software weaknesses related to architecture and design.
Although the CWE is most commonly associated with static code analysis reporting, MITRE classifies 381 of the total of 943 CWEs “as likely introduced in the Architecture and Design phase of the development life cycle.”1 Most of these CWEs aren’t apparent in the coding phase but can be identified during the design phase using the techniques I discuss here. This is significant because the prevention or mitigation of flaws early in the software development life cycle (SDLC) can avoid a ten-to hundred-fold cost in post deployment detection and remediation.2
The Architectural Perspective
The enterprise architect, the security architect, and the software architect each have complementary and overlapping views of software flaws and how to address them.
Enterprise Architects
Enterprise architects are concerned with designing, planning, and governing strategic missions and programs. They seek to achieve interoperability and portability across the entire enterprise by optimizing and harmonizing services, processes, and components. To facilitate the enterprise’s business objectives, enterprise architects work with the respective software architects to leverage solutions across multiple systems and product lines.
For example, an enterprise architect will consolidate individual systems into a service-oriented architecture and eliminate one-off personnel datasets, asset inventories, and expense tracking and reimbursement processes. He or she can promote the adoption of a single technical architecture (such as Microsoft’s .NET or Java Platform, Enterprise Edition) to avoid the headaches of interconnecting incompatible technologies. Portability and interoperability are the key architectural objectives. Each of these actions will reduce the attack surface of the entire enterprise and enable security solutions that scale beyond what would be economical for individual systems.
CWE flaws can stem from a misunderstanding, or a misapplication of, enterprise architecture. Errone- ous business rules can lead, for example, to improper input validation (CWE-20). Misunderstood user authorities and responsibilities can lead, for example, to least privilege violation (CWE-272) and information exposure (CWE-200). Errors in integration and module development can be linked to a deficient or missing SDLC strategy, and incompatible data definitions and inconsistent data management can lead to the exposure of sensitive data through data queries (CWE-202).
Security Architects
The perspective of security architecture concerns itself with marshalling the controls, tools, and skills needed to protect the enterprise from external and internal threats. The security architect applies knowledge of the business goals and roles to identify and mitigate threats to the enterprise. The recent iOS security white paper from Apple is a good example of security architecture.3 The paper covers the iPhone system hardware and software security, encryption and data protection, application security, network security, Internet services, and device controls. Apple identifies the threats at each of these levels and describes how the architecture addresses them: “iOS protects not only the device and its data at rest, but the entire ecosystem, including everything users do locally, on networks, and with key Internet services.” 3
Software Architects
The Guide to the Software Engineering Body of Knowledge (SWEBOK) asserts that software architectural design “(sometimes called high- level design) develops top-level structure and organization of the software and identifies the various components.”4 It’s a top-down process with various subcomponents and relationships between components.
Software architects work within a business unit to identify stakeholders and their concerns, developing the architectural requirements for the systems that the business unit develops and deploys. They coordinate enterprise coding standards and recommended practices with software development managers and software designers to reduce training costs and learning curves and promote portability of developers and applications across the enterprise.
The SWEBOK distinguishes architectural design from detailed design which “describes the desired behavior of these components.”4 However, this distinction varies by organization. Some enterprises don’t have software architects; instead, they divide the duties between enterprise architects and system and software designers. In some cases, the enterprise architecture will incorporate the higher level constructs of the security architecture, relegating the details to the developers and security engineers. The software architects could develop the security architecture, but this isn’t common, given the specialized knowledge and skills of the security architect.
Software Architecture and Design Controls
What can organizations do to mitigate or remediate architectural and design errors? Why not just fix the flaws identified in the CWE/SANS Top 25 Most Dangerous Software Errors? 5
Before itemizing the anti-flaw arsenal, an SDLC-based framework can provide context for these controls and identify the gaps that will result from a purely tool and techniques viewpoint. MITRE recommends that you “treat the Top 25 as an early step in a larger effort towards achieving software security. Strategic possibilities are covered in efforts such as Building Security In Maturity Model (BSIMM), SAFECode, OSAMM [Open Software Assurance Maturity Model], Microsoft SDL [Security Development Lifecycle], and OWASP [Open Web Application Security Project]5 ASVS [Application Security Verification Standard Project].” Using its enterprise architecture, the organization can establish the following methods as integral to the system development lifecycle process.
Threat Modeling
Threat modeling (or threat analysis) is “a design-time conceptual exercise where a system’s dataflow is analyzed to find security vulnerabilities and identify ways they may be exploited” (see). The process of identifying threats can reveal flaws in data handling, data sensitivity, authorization requirements, workflow, business logic, and hazards that can be addressed before applications are developed and deployed.
Just as use-case models have proven quite helpful for eliciting functional requirements, misuse cases can effectively reveal security requirements.
Attack Trees
Attack (or threat) trees provide a formal model for depicting the attacker perspective of the security of systems.6The potential attacks against a system are arranged in a tree structure, with the ultimate objective as the root node. The leaves represent the various paths to achieving that objective. With assigned monetary values, the designer can create countermeasures that increase the expense of attack routes.
Misuse Cases
Misuse cases describe potential abuses of the system. 7 A use case generally describes behavior that the system owner wants the system to implement. In contrast, misuse cases create conditions or situations that are undesirable in the view of the stakeholders. Misuse cases help organizations understand their software as the attackers would.
Identity and Access Management
Owing to the complexity of the task, most applications use enterprise services for identity and access management (IDAM) of internal users (see). The software or security architect, or possibly the application designer, will need to identify and negotiate roles and responsibilities for IDAM controls. The architects and designers will need to agree on password complexity, resulting action for failed login attempts, session timeouts, user session refresh, forced re-authentication, re-authentication for privileged or sensitive data access, and so on.
Least Privilege
The concept of least privilege is that “every program and every user of the system should operate using the least set of privileges necessary to complete the job.”8 A compromised application running with full privileges can perform much more damage than a compromised application with reduced privileges.
Formal Methods
Formal methods are the incorporation of mathematically based techniques for the specification, development, and verification of software.9 Owing to mathematical syntax and semantics, formal specification is precise compared to non-formal and even semi- formal specifications, which might be ambiguous or internally inconsistent.
Formal methods add to the time needed to specify an application, yet they can improve the code quality and reduce testing and maintenance costs. To compensate for a lack of experienced personnel and organizational support, formal methods can focus on algorithms, components, properties, and other key functions in software rather than applying them to the entire system.
Secure Design Patterns
Secure design patterns are descriptions or templates describing general solutions that can be applied in many different situations to eliminate or mitigate the consequences of flaws.10,11By providing a higher level of abstraction than secure coding guidelines, such patterns can be applied across programming languages. Secure design patterns differ from security patterns in that the former don’t describe specific security mechanisms such as access control, authentication, authorization, and logging. While security patterns are focused on security- related functionality, secure design patterns can (and should) be employed broadly in a system.
Secure Session Management
Session management allows Web applications to authenticate users at the beginning of the session by issuing a Session ID. This ID ensures that all actions during the session are performed by the same user (or Web browser) who originally supplied the authentication information. Attackers will seek to manipulate the Session ID to steal the session from an authenticated user.
Developers can defend against such attacks by requiring re-authentication when the session has timed out or when the user at- tempts to use sensitive function- ality. The system designers must identify all functions where preservation of session state is necessary.
If they can come to agreement, enterprise, software, and security architects can significantly improve software assurance by using the enterprise architecture to promulgate these software security controls. Likewise, application development managers can reference the enterprise architecture and encourage their teams to take these and other appropriate measures to prevent software weaknesses.
Acknowledgments
Ram Sriram, Paul Black, Yan Wu, Vadim Okun, Bertrand Stivalet, and Clarence “Butch” Rappe provided useful feedback on earlier versions of this paper.
References
- “CWE-701: Weaknesses Introduced During Design,” MITRE, 30 July 2014;
- C. Jones and O. Bonsignour, The Economics of Software Quality, Addison Wesley Professional, 2012, p. 97, 111, and 112.
- iOS Security, white, paper, Applie, Feb. 2014;
- SWEBOK Version 3.0, IEEE CS Press, 2014, p. 2-1.
- “2011 CWE/SANS Top 25 Most Dangerous Software Errors,” CWE, 13 Sept. 2011;
- F. Swiderski and W. Snyder, Threat Modeling, Microsoft Press, 2004.
- OWASP Comprehensive, Lightweight application Security Process (CLASP), Open Web Application Security Project, Nov. 2007.
- J. Saltzer and M. Schroeder, “The Protection of Information in Computer Systems,” MIT, 1975;
- C. Ghezzi, M. Jazayeri, and D. Mandrioli, Fundamentals of Software Engineering (2nd Edition), Prentice Hall, 2002, pp. 334–337; 550–559.
- C. Dougherty et al., Secure Design Patterns, tech. report, Software Eng. Inst., Oct. 2009;
- Architecture and Design Considerations for Secure Software, Version 2.0, 18 May 2012;
About the Author
Walter Houser is with R4 Information Technologies. Contact him at walthouser@ gmail.com.
This article first appeared in IEEE IT Professional magazine. IEEE IT Professional offers solid, peer-reviewed information about today's strategic technology issues. To meet the challenges of running reliable, flexible enterprises, IT managers and technical leads rely on IT Pro for state-of-the-art solutions.