Software security is one of the most important things in today’s software development process. Security has become a critical factor to consider since the world had faced a lot of cybersecurity attacks due to various loopholes that exist in the software development process. This is one of the major reasons to convert the traditional software development lifecycle to a secure software development life cycle.
Software design is one of the phases of the secure software development life cycle. A secure SDLC involves integrating and interacting with security testing and other activities into an existing development process.
Secure software design contains 4 points to consider as below.
Secure software design contains 4 points to consider as below.
- Reduce the Attack Surface
- Threat Modeling
- Risks in Design
- Controls Evaluation
- Reduce the Attack Surface
[Reference: What is an Attack Surface? (And How to Reduce It) | Okta]
Software attach surface is the complete profile of all functions in any code running in a given system that is available to an unauthenticated user. As an example, in 2014, reporters said nearly half of all Fortune 500 companies had employee email addresses and passwords exposed in hacker forums within the year. (Unwitting Workers Give Hackers Keys to Fortune 500 Firms’ Networks: Study (nbcnews.com))
Attach surface of a product can include
- User Input Fields
- Protocols/Services/Interfaces/Processes
- Resource files ( files, directories & registries)
- Open named pipes/open sockets
- How many items are accessible
- Dynamic web pages (ASP, etc)
- Guest accounts enabled
- ACL configuration
E.g. An intruder can simply issue an input validation attack by entering a malicious input to confuse the software application to carry out some unplanned action. This can include code, scripts, and commands which can bypass the application if the input is not validated properly. SQL Injection, Cross-site scripting, and Buffer overflow are some of the main attacks that can issue via user input fields.
Software developers/designer has to put more effort on not only programming the above features according to the business requirement but also in a way of avoiding software attacks through them.
Earlier, software security has become a Non Functional requirement when it comes to the required specification. However, it’s time to make it a functional requirement since the cost of an attack is very high.
- Threat Modeling
Threat modelling is a process by which potential threats can be identified. Enumutratrd and prioritized all from a hypothetical attacker’s point of view.
Threat modelling contains 6 components.
Step 1: Identify security objectives and assets.
Step 2: Profile the application.
Step 3: Decompose the application.
Step 4: Identify threats and vulnerabilities.
Step 5: Document the threats.
Step 6: Prioritize the threats.
Step 1 – Identify security objectives and assets.
Security objectives are the targets the customer establishes for their security program. Not knowing the security objectives creates issues with understanding the goals and what to accomplish. Security Objectives are one of those areas requiring the customer’s involvement, and so the assessment team cannot make up the information. Security objectives include
- Legislative Drivers
- Contractual Requirements
- Alignment with Business Objectives
Step 2 – Profile the application.
- Identify Physical & Logical Topology
- Determine components, services, protocols & ports
- Identify human & non-human actors of the system
- Identify Data Elements
- Generate Data Access Matrix (CRUD)
- Identify Technologies
- Identify external dependencies
Step 3 – Decompose the Application
It is easy to decompose the application using Data Flow diagrams. This allows identifying the entry points of an attacker. These can include trust boundaries, entry/exit points, data flows, privileges code, etc. All the points are essential to be documented in a way that allows identifying the individual elements that have values which has a risk of being attacked.
When decomposing, dependencies are parts of the software application that lay outside the application’s code. As these items are outside of your control they may pose a threat if they are not properly maintained so identifying these dependencies will minimize the application’s overall risk.
Step 4 – Identify threats and vulnerabilities
Thinking like an attacker when evaluating the software system is one of the most effective ways to spot threats and vulnerabilities. To roleplay like an attacker, using an Attack Tree is an effective way. Attack trees are conceptual diagrams showing how an asset, or target, might be attacked. Attack trees have been used in a variety of applications. In the field of information technology, they have been used to describe threats on computer systems and possible attacks to realize those threats.
E.g. Attack Tree based on “Rob the Casino”
[Reference: Attack tree diagrams and application security testing | Synopsys]
Another effective method of threat identification is using categorized threat lists developed by Octave, Stride, and Microsoft, etc.
Microsoft: Microsoft Security Development Lifecycle Threat Modelling
Stride: What is STRIDE and How Does It Anticipate Cyberattacks? (securityintelligence.com)
Threat Modeling: Stride
|
Threat |
Description | Mitigation |
| Spoofing | Can an attacker impersonate another user? | Authentication |
| Tampering | Can the data tamper while in transit or storage? | Integrity Verification (Message Digests/CRCs) |
| Repudiation | Can the attacker deny the attack? | Non-Repudiation (Digital Signatures, Keys) |
| Information Disclosure | Can the information be disclosed to unauthorized users? | Confidentiality Through Encryption |
| Denial of Service | Is DOS a possibility? | High Availability/Redundancy/Fault Tolerance |
| Escalation of Privilege | Can the attacker bypass the least privileged implementation and execute the elevated privileged processes? |
Authorization |
Step 5 – Threat Documentation
- Threat documentation can be implemented following a standard template.
- This should include the thread description, attack technique, Threat target, Impact likelihood, Risk, possible controls, etc.
E.g.
| Threat Identifier | T0011 |
| Thread Description | Injection of SQL Commands |
| Threat Targets | Data access component, Database |
| Attack Techniques | Attacker appends the SQL commands to the username which is used to form an SQL query |
| Security Impact | Information disclosure, alteration, destruction, authentication bypass |
| Risk | High |
Step 6 – Prioritize the Threats
- Risk ranking
- Probability x Impact ratings
- Delphi Ranking
R = Reproducibility
E = Exploitability
DI = Discoverability
D = Damage Potential
A = Affected Users
- Risks in Design
- Reusing the code
A technique of exploitation that relies on executing the code which is already present in the memory instead of shipping it to the attacked host as part of the payload.
- Flaws vs. Bugs
A Flow is an inherent fault with the design of code whereas a Bug is an Implementation fault.
- Open vs. Closed Design
Open design refers to the availability of an extension. It should be possible to add fields to the data structures it contains, or new elements to the set of functions it performs and the Closed design refers to the available for use by other modules. This assumes that the module has been given a well-defined, stable description.
- Controls Evaluation
- Economy of Mechanism
The principle of economy of mechanism states that security mechanisms should be as simple as possible. If a design and implementation are simple, fewer possibilities exist for errors. The checking and testing process is less complex because fewer components and cases need to be tested.
- Psychological Acceptability
The principle of psychological acceptability states that security mechanisms should not make the resource more difficult to access than if the security mechanisms were not present. Configuring and executing a program should be as easy and as intuitive as possible, and any output should be clear, direct, and useful.
[Psychological Acceptability | CISA]
- Efficacy of Controls
- Cost/Benefit Analysis
By going through the above-mentioned secure software design principles, it is better to plan and develop the design stages accordingly. It will allow the software application to be none/less exploitable. As consideration for software design, the CIA (What Is The CIA Triad? (f5.com) ), AAA (What is authentication, authorization, and accounting (AAA)? – Definition from WhatIs.com (techtarget.com)), and Secure Design Principals can be recommended.