Secure Software

Architecture and Design

Dr. G.Usha Devi
Professor
School of Information Technology and Engineering
VIT University, Vellore
General Objectives of Software
Architecture and Design
• Completeness
• Supports the full scope of the defined requirements
• Stability
• Consistently performs as intended within its defined operational context
• Flexibility
• Can adapt to changing conditions
• Decomposable such that selected components can be replaced going forward with minimal impact to
the software
• Extensibility
• Leverages industry standards
• Long-lived and resistant to obsolescence
• Scalability
• Operates effectively at any size and load
Security-Specific Objectives of Software
Architecture and Design
• Comprehensive functional security architecture
• Security features and capabilities are fully enabled
• Attack resistance
• Contains minimal security weaknesses that could be exploited
• Attack tolerance
• While resisting attack, software function and capability are not unduly
affected
• Attack resilience
• In the face of successful attack, the effects on the software are minimized
Issues and Challenges
• The challenge to building security into the architecture and design
portion of the SDLC is that not only must the architecture address
currently understood security issues—both known weaknesses and
attacks—but at its level of abstraction it must also be flexible and
resilient under constantly changing security conditions.
• The best that can be achieved is a minimized risk profile accomplished
through disciplined and continuous risk management. The practice of
architectural risk analysis (involving threat modeling, risk analysis, and
risk mitigation planning) performed during the architecture and design
phase is one of the cornerstones of this risk management approach.
Specific Project Manager Concerns During Software Architecture and Design

Concern Process/Knowledge

Delivering what was specified Architectural risk analysis

 Deliverables must fulfill the objectives of the
project

Getting it right the first time Architectural risk analysis

 Minimize rework

Effectively shoring up staff expertise shortfalls Security principles

Security guidelines
Attack patterns
Software Security Practices for Architecture
and Design: Architectural Risk Analysis
• The risk analysis methodology consists of six activities:
1. Software characterization
2. Threat analysis
3. Architectural vulnerability assessment
4. Risk likelihood determination
5. Risk impact determination
6. Risk mitigation planning
Software Characterization
• to achieve a full understanding of what the software is and how it works
• Outcome: high level one page sys s/w arch diagram-includes major components, their interactions and various zones of
trust
• Useful artifacts to review for software characterization include, but are not limited to, the following items:
1. Software business case
2. Functional and non-functional requirements
3. Enterprise architecture requirements
4. Use case documents
5. Misuse/abuse case documents
6. Software architecture documents describing logical, physical, and process views
7. Data architecture documents
8. Detailed design documents such as UML diagrams that show behavioral and structural aspects of the system
9. Software development plan
10. Transactions security architecture documents
11. Identity services and management architecture documents
12. Quality assurance plan
13. Test plan
14. Risk management plan
15. Software acceptance plan
16. Problem resolution plan
17. Configuration and change management plan
High-level, one-page system software
architecture diagram
Threat Analysis
• Threats are agents that violate the protection of information assets and
site security policy.
• Threat analysis identifies relevant threats for a specific architecture,
functionality, and configuration.
• It may assume a given level of access and skill level that the attacker may
possess.
• During this analysis, threats may be mapped to vulnerabilities to
understand how the software may be exploited.
• A mitigation plan is composed of countermeasures that are considered to
be effective against the identified vulnerabilities that these threats exploit.
Threat Source Motivation Threat Actions
Cracker Challenge  System profiling
Ego  Social engineering
Rebellion  System intrusion, break-ins
 Unauthorized system access

Computer criminal Destruction of information  Computer crime (e.g.,

Illegal information disclosure cyberstalking)
Monetary gain  Fraudulent act (e.g., replay,
Unauthorized data alteration impersonation, interception)
 Information bribery
 Spoofing
 System intrusion
 Botnets
 Malware: Trojan horse, virus,
worm, spyware
 Spam
 Phishing
Terrorist Blackmail  Bomb
Destruction  Information warfare
Exploitation  System attack (e.g., distributed denial of service)
Revenge  System penetration
Monetary gain  System tampering
Political gain
Industrial espionage Competitive advantage  Economic exploitation
Economic espionage  Information theft
Blackmail  Intrusion on personal privacy
 Social engineering
 System penetration
 Unauthorized system access (access to classified, proprietary,
and/or technology-related information)
Insiders (poorly trained, Curiosity
disgruntled, malicious, Ego
negligent, dishonest, or Intelligence
terminated employees) Monetary gain
Revenge
Unintentional errors and
omissions (e.g., data entry
errors, programming errors)
Wanting to help the company
(victims of social engineering)
Lack of procedures or training
 Assault on an employee
 Blackmail
 Browsing of proprietary information
 Computer abuse
 Fraud and theft
 Information bribery
 Input of falsified, corrupted data
 Interception
 Malicious code (e.g., virus, logic bomb, Trojan horse)
 Sale of personal information
 System bugs
 System intrusion
 System sabotage
 Unauthorized system access
• Some threat actors are external.
• These attackers could include
• structured external: generated by a state-sponsored entity, such as a foreign
intelligence service
• transnational external: generated by organized nonstate entities such as drug
cartels, crime syndicates, and terrorist organizations.
• unstructured external threats: generated by individuals such as crackers
Architectural Vulnerability Assessment
• Vulnerability assessment examines the preconditions that must be present for
vulnerabilities to be exploited and assesses the states that the software might
enter upon exploit.
• Three activities make up architectural vulnerability assessment:
• attack resistance analysis,
• ambiguity analysis, and
• dependency analysis.
• Architectural risk analysis studies vulnerabilities and threats that might be
malicious or nonmalicious in nature.
• Whether the vulnerabilities are exploited intentionally (malicious) or
unintentionally (nonmalicious), the net result is that the desired security
properties of the software may be affected.
ATTACK RESISTANCE ANALYSIS
• Attack resistance analysis is the process of examining software
architecture and design for common weaknesses that may lead to
vulnerabilities and increase the system’s susceptibility to common
attack patterns.
• Architectural-level flaws can currently be found only through human
analysis.
• Common Attack Pattern Enumeration and Classification (CAPEC)
describes the following classes of attack, among others:
• Abuse of functionality
• Spoofing
• Probabilistic techniques
• Exploitation of privilege or trust
• Injection
• Resource manipulation
• Time and state attacks
AMBIGUITY ANALYSIS
• Ambiguity is a rich source of vulnerabilities when it exists between
requirements or specifications and development.
• A key role of architecture and design is to eliminate the potential
misunderstandings between business requirements for software and
the developers’ implementation of the software’s actions.
• All artifacts defining the software’s function, structure, properties,
and policies should be examined for any ambiguities in description
that could potentially lead to multiple interpretations.
• Any such opportunities for multiple interpretations constitute a risk to
the software.
DEPENDENCY ANALYSIS
• The goal of this analysis is to develop a list of software or system
vulnerabilities that could be accidentally triggered or intentionally
exploited, resulting in a security breach or a violation of the system’s
security policy.
• the analysis might focus on the organization’s security policies,
planned security procedures, nonfunctional requirement definitions,
use cases, misuse/abuse cases, architectural
platforms/components/services, and software security features and
security controls (both technical and procedural) used to protect the
system, among other issues.
VULNERABILITY CLASSIFICATION
• Classifying vulnerabilities allows for pattern recognition of vulnerability
types.
• Common Weakness Enumeration (CWE) includes seven top-level
categories for architecture and source code :
• Data Handling
• API Abuse
• Security Features
• Time and State
• Error Handling
• Code Quality
• Encapsulation
MAPPING THREATS AND
VULNERABILITIES
• Microsoft’s STRIDE provides a model of risks to a computer system
related to spoofing, tampering, repudiation, information disclosure,
denial of service, and elevation of privilege.
Risk Likelihood Determination
• “likelihood” is a qualitative estimate of how likely a successful attack will be,
based on analysis and past experience.
• Because of the complexity of the software domain and the number of variables
involved in risk analysis, this likelihood measure is not an actual
mathematical probability of a successful attack.
• Nonetheless, the concept of likelihood can be useful when prioritizing risks and
evaluating the effectiveness of potential mitigations.
• Consider these factors, all of which are incorporated in the likelihood estimation:
• The threat’s motivation and capability
• The vulnerability’s impact (and therefore attractiveness to an attacker)
• The effectiveness of current controls
 Model for Calculating Likelihood
High The three qualities are all weak. A threat is highly motivated and sufficiently capable, a vulnerability
exists that is severe, and controls to prevent the vulnerability from being exploited are ineffective.

Medium One of the three qualities is compensating, but the others are not. The threat is perhaps not very
motivated or not sufficiently capable, the controls in place might be reasonably strong, or the
vulnerability might be not very severe.

Low Two or more of the three qualities are compensating. The threat might lack motivation or capability;
strong controls might be in place to prevent, or at least significantly impede, the vulnerability from
being exploited; and the vulnerability might have a very low impact.
Risk Impact Determination
• discusses three aspects of risk impact determination:
• identifying the threatened assets: Common impacts on information assets
include loss of data, corruption of data, unauthorized or unaudited
modification of data, unavailability of data, corruption of audit trails, and
insertion of invalid data.
• identifying business impact: Examples of business impacts include loss of
market share, loss of reputation, depreciation of stock value, fines, legal fees
and judgments, costs of technical remediation, and theft.
• determining impact locality
RISK EXPOSURE STATEMENT
• The risk exposure statement combines the likelihood of a risk with the
impact of that risk.
• The product of these two analyses provides the overall summary of
risk exposure for the organization for each risk. 
Risk Exposure Calculation Matrix
Risk Mitigation Planning
• Mitigation of a risk entails changing the architecture of the software
or the business in one or more ways to reduce the likelihood or the
impact of the risk.
• Formal and informal testing, such as penetration testing, may be used
to test the effectiveness of these mitigation measures.
 Software Security Knowledge for
Architecture and Design: Security
Principles, Security Guidelines, and Attack
Pattern
Security Principles
• Security principles are the foundational tenets of the software
security domain.
• They are long-standing, universal statements of how to build software
the right way if security is a concern (which it always is).
• These principles represent the experiential knowledge of the most
respected thought leaders and practitioners in the field of software
security.
• By leveraging them, your team gains access to the scalable wisdom
necessary for assessing and mitigating the security risk posed by your
software’s architecture and design.
Security Principles
• Security principles are a set of high-level practices derived from real-world experience that can
help guide software developers (software architects and designers in particular) in building more
secure software. 
• THE PRINCIPLES FOR SOFTWARE SECURITY
• Least privilege
• Failing securely
• Securing the weakest link
• Defense in depth
• Separation of privilege
• Economy of mechanism
• Least common mechanism
• Reluctance to trust
• Never assuming that your secrets are safe
• Complete mediation
• Psychological acceptability
• Promoting privacy
1. The Principle of Least Privilege:
• Only the minimum necessary rights should be assigned to a subject that requests access to a resource and
should be in effect for the shortest duration necessary (remember to relinquish privileges).
• Granting permissions to a user beyond the scope of the necessary rights of an action can allow that user to
obtain or change information in unwanted ways
2. The Principle of Failing Securely:
• secure defaults (the default is to deny access); on failure, undo changes and restore the system to a secure
state; always check return values for failure; and in conditional code/filters, make sure that a default case is
present that does the right thing
• During a failure, attackers must not be permitted to gain access rights to privileged objects that are normally
inaccessible.
3. The Principle of Securing the Weakest Link
• Knowing when the weak spots of a software application have been fortified can indicate to a software vendor
whether the application is secure enough to be released.
4. The Principle of Defense in Depth
• Defending an application with multiple layers can eliminate the existence of a single point of failure that
compromises the security of the application.
5. The Principle of Separation of Privilege
• A system should ensure that multiple conditions are met before it grants permissions to an object
• Compartmentalizing software into separate components that require multiple checks for access can inhibit an
attack or potentially prevent an attacker from taking over an entire system
6. The Principle of Economy of Mechanism
• complexity. If the design, implementation, or security mechanisms are highly complex, then the likelihood that security vulnerabilities
will exist within the system increases
7. The Principle of Least Common Mechanism
• Avoid having multiple subjects share those mechanisms that grant access to a resource
• A different mechanism (or instantiation of a mechanism) for each subject or class of subjects can provide flexibility of access control
among various users and prevent potential security violations that would otherwise occur if only one mechanism were implemented
8. The Principle of Reluctance to Trust
• When building an application, software engineers should anticipate malformed input from unknown users.
• the interface between two systems should be secured.
• Minimizing the trust in other systems can increase the security of your application.
9. The Principle of Never Assuming That Your Secrets Are Safe
• You should always assume that an attacker can obtain enough information about your system to launch an attack.
• For example, tools such as decompilers and disassemblers may allow attackers to obtain sensitive information that may be stored in
binary files.
• Using real protection mechanisms to secure sensitive information should be the ultimate means of protecting your secrets.
10. The Principle of Complete Mediation
• A software system that requires access checks to an object each time a subject requests access, especially for security-critical objects,
decreases the chances that the system will mistakenly give elevated permissions to that subject.
11. The Principle of Psychological Acceptability
• Accessibility to resources should not be inhibited by security mechanisms.
• If security mechanisms hinder the usability or accessibility of resources, then users may opt to turn off those mechanisms
12. The Principle of Promoting Privacy
• Preventing attackers from accessing private information or obscuring that information can alleviate the risk of information leakage.
Security Guidelines
• Security guidelines represent prescriptive guidance for those software
design-level concerns typically faced by the software development
project team.
• they also can provide an effective checklist of what you may have
failed to do to ensure that your software is both resistant and resilient
to likely attack.
WHAT DO SECURITY GUIDELINES
LOOK LIKE?
• Guideline: Follow the Rules Regarding Concurrency Management
• serious vulnerabilities
• without using appropriate concurrency management mechanisms produces
hard-to-find vulnerabilities
• When multiple threads of control attempt to share the same resource, then
• Deadlock: One or more threads may become permanently blocked.
• Loss of information: Saved information is overwritten by another thread.
• Loss of integrity of information: Information written by multiple threads may be
arbitrarily interlaced.
• Loss of liveness: Imbalance in access to shared resources by competing threads can
cause performance problems.
• Competing “Systems” (Time of Check/Time of Use)
• A common mitigation tactic is to minimize the time interval between check and
use. An even more effective tactic is to use a “check, use, check” pattern that
can often detect concurrency violations, though not prevent them.
• Applicable Context
• All of the following must be true:
• Multiple “systems” must be operating concurrently.
• At least two of those systems must use a shared resource (e.g., file, device, database table row).
• At least one of those systems must use the shared resource in any of the following ways:
• Without using any concurrency control mechanism. This includes the situation where no
such mechanism exists, such as conventional UNIX file systems, causing corruption or
confusion.
• Using the right concurrency control mechanism incorrectly. This includes situations such
as not using a consistent resource locking order across all systems (e.g., in databases),
causing deadlocks.
• Using the wrong concurrency control mechanism (even if it used correctly). This includes
situations where a give resource may support multiple concurrency control mechanisms
that are independent of one another [e.g., UNIX lockf() and flock()], causing corruption or
confusion.
 • Competing Threads within a “System” (Races)
• The second largest class of concurrency-related vulnerabilities is generated by
defects in the sharing of resources such as memory, devices, or files.
• design error
• Applicable Context
• All of the following must be true:
• A “system” must have multiple concurrently operating threads of control.
• Two or more of those threads must use a shared data object, device, or other resource.
• At least one thread must use the shared resource without using the appropriate concurrency
control mechanism correctly (or at all).

Impact Minimally Maximally

1 None Deadlock: One or more threads may become permanently blocked.

2 None Loss of information: Saved information is overwritten by another thread.

3 None Loss of integrity of information: Information written by multiple threads may be arbitrarily
interlaced.

4 None Loss of liveness: Imbalance in access to shared resources by competing threads can cause
performance problems.
 • Security Policies to Be Preserved
• Threads must not deadlock.
• Information must not be lost.
• Information must not be corrupted.
• Acceptable performance must be maintained.
• How to Recognize This Defect
• Concurrency defects are extremely difficult to recognize. There is no general-
purpose approach to finding them.

Efficacy Mitigation
Low Where no concurrency control mechanism is available, seek to minimize the interval between the time
of check and the time of use. Technically this action does not correct the problem, but it can make the
error much more difficult to exploit.
Infinite The appropriate concurrency control mechanism must be used in the conventional way (assuming
there is one).
Attack Patterns

• attack patterns are another knowledge resource available to the software project
manager.
• Attack patterns, describing common approaches to attacking software, provide one of
the most effective resources for capturing this attacker’s perspective.
• Attack patterns offer a valuable resource during three primary activities of architecture
and design: design and security pattern selection, threat modeling, and attack
resistance.
• One of the key methods for improving the stability, performance, and security of a
software architecture is the leveraging of proven patterns.
• use of attack patterns as an integral part of the threat model.
• attack patterns can be a valuable tool in identifying and characterizing contextually
appropriate attacker perspectives to consider in a red teaming type of approach.
REFERENCE
• SOFTWARE SECURITY ENGINEERING
• BY
• JULIAH ALLEN, SEAN BARNUM, ROBERT J ELLISON, GARY MCGRAW,
NANCY R MEAD
• PEARSON EDUCATION