SECURE SOFTWARE ENGINEERING

Software engineering—well-designed techniques for designing new software or enhancing existing software—is not a new field, but the problems and solutions of vulnerability to malicious attack have only recently been extensively explored.  Robust software, in the context of secure software engineering, is software that continues to function correctly whilst under such attacks.  Identification of actual or potential vulnerabilities in design or code should be incorporated throughout all stages of the software development cycle and constitutes the practice of secure software engineering.

What accounts for the recent surge in interest in secure software engineering?

This idea of secure and robust software is not new. But what has caused the recent surge of interest in secure software engineering? Some factors include:

• Improved Connectivity - With increased connectivity between systems through the Internet, attacking a system or software at a remote location is not difficult anymore.
• Complex softwares - With improvements in software technology, complex software with intricate functionalities can be developed. However, as the complexity increases, loopholes which may cause security breaches can easily be overlooked.
• Reactive approach to security - Current software products follow a reactive approach to security in that they deal with threats only after the attack, instead of being prepared in advance to function under any adverse condition.

Secure Software Engineering has three major pillars:

1. Touchpoints
2. Risk Management Framework
3. Knowledge

TOUCHPOINTS

Software Security Touchpoints refer to the best security practices based around the artifacts obtained during the software development lifecycle. The diagram below shows the 7 touchpoints for building secure software and the artifacts around which they are based:

Developing secure software shouldn’t be an overhead which increases the product cost drastically. It is not essential to include all 7 touchpoints to build secure software but whatever is feasible. The seven touchpoints can be ranked on the basis of their effectiveness to embed security and their importance as an artifact as below:

1. Code Review
2. Architectural Risk Analysis
3. Penetration Testing
4. Risk-Based Security Tests
5. Abuse Cases
6. Security Requirements
7. Security Operations

Let us dig a little deeper into these touchpoints to have a better understanding of the relevance of each according to your product.

CODE REVIEW:

Target artifact - Code

This touchpoint holds the number 1 slot because code is the one artifact which is produced by all the software products. Code Review involves static analysis of the code (manually or using tools) to find implementation bugs that can cause vulnerabilities.

However, code review can only be used to find the implementation bugs (which would cover at most 50% of the vulnerabilities) and not other vulnerabilities such as the ones caused due to architectural flaws, etc.

ARCHITECTURAL RISK ANALYSIS:

Target Artifact - Design and Specification

The system must be designed like an integrated whole with a secure interface to the external world. Not protecting the critical data within an application or failing to authenticate the external consumers of a service produced by the system fall under architectural risks.

PENETRATION TESTING:

Target Artifact: System in its real environment

It is very important to understand the behaviour of a software product in its real environment before it is actually deployed to one. This helps in identifying the vulnerabilities and risks associated with the system for when it will be operational. The cost and damage associated with a system in its operational environment is much more than that if the risks are identified and rectified before the deployment. Architectural analysis can provide great insights into penetration testing while providing an overview of the vulnerable points to a system.

RISK-BASED SECURITY TESTING:

Target Artifact: Unit components of the system & the whole system

The security testing of a system should involve the following:

1. Testing of the security functionalities of the system using the conventional techniques for functionality testing
2. Testing based on external risks to the system and evaluating the system’s behaviour under such scenarios.

Both of the above techniques are complementary to each other and ensure complete security based testing of the system

ABUSE CASES:

Target Artifact: Requirements Specification & Use Cases

As use cases define the system’s normal behaviour, abuse cases define the system’s behaviour under attack. To implement abuse cases, it is important to have a complete understanding of the system in terms of the data which should be protected, from whom it should be protected and how a breach of this protection can harm the system. Abuse cases are extremely beneficial in understanding the adverse situations a system can get into and how.

SECURITY REQUIREMENTS:

Target Artifact: Requirements Specification

Security Requirements (such as the requirement for authorization and authentication, cryptography, expected system behaviour under failure or attack) should be explicitly stated and well defined in the requirements specification document so as to ensure proper implementation of these.

SECURITY OPERATIONS:

Target Artifact: System in its environment

Along with implementing security functionalities and determining system behaviour under attack, it is important to continuously evaluate the system for its behavior under different and yet unidentified threats and to enhance the existing system so it can handle such adverse situations.

Touchpoints provide a set of best practices to build a secure software system but the truth remains that, though the risks can be minimised to a great extent by implementing the touchpoints, they cannot be entirely eliminated. It is very important to continuously evaluate the risks and their impact on the business and manage the strategies used to mitigate them. A RISK MANAGEMENT FRAMEWORK (RMF), the second pillar of Secure Software Engineering, is used to the accomplish the mentioned.

RISK MANAGEMENT FRAMEWORK (RMF)

Risk Management Framework (RMF) is a repetitive, continuous and expertise driven process to identify the risks associated with a system, track them and provide a mitigation technique for them. Risks can crop up at any point in the software development lifecycle, around any artifact and hence RMF should be carried out throughout the software development and deployment cycle encompassing all the artifacts.

RMF consists of 5 activities, which are as follows:

1. Understanding the business domain and context with respect to the system
2. Identifying the business & technical risks associated with the system
3. Synthesizing and prioritizing the risks, thus ranking the risks identified
4. Defining the strategy for risk mitigation
5. Carrying out the fixes required and validating them for correctness

Let us try to understand the Risk Management Framework in detail.

UNDERSTANDING THE BUSINESS DOMAIN AND CONTEXT WITH RESPECT TO THE SYSTEM:

Risks can not be avoided completely and mitigating all the risks is not always feasible. Motivation behind Risk Mitigation techniques should based on business goals and objectives. The risks which have maximum adverse affect on the business should be given high priority and resolved first. Thus, it is essential to have a deep understanding of the business domain and context and the role played by the system in achieving the goals of the business.

IDENTIFY THE BUSINESS AND TECHNICAL RISKS ASSOCIATED WITH THE SYSTEM:

Business Risks are those risks which impact one or more business goals adversely. They can cause financial loss, in terms of reputation and goodwill to the company. Hence, after identifying business goals, business executives along with field experts should identify the business risks. Technical risks refer to the vulnerable software artifacts which may cause harm to a business. These risks should be identified, recorded and evaluated against the defined business objectives using appropriate metrics.

SYNTHESIZING AND PRIORITIZING THE RISKS, THUS RANKING THE RISKS IDENTIFIED:

Risk Mitigation requires lots of investment in terms of time, effort and money. Once the risks associated with the system have been identified, it is not always possible to provide mitigation against all of them. Hence, the risks should be evaluated using appropriate metrics to determine their impact on the business and the loss caused due to them. The risks with higher impact should be ranked higher and given more priority.

DEFINING THE STRATEGY FOR RISK MITIGATION
Once the risks have been identified, evaluated and ranked, it is essential to define a strategy to mitigate them. The strategy should be defined keeping the business goals and objectives in mind. Also, each strategy should consider a parameter known as the ROI (Return on Investment) which calculates the feasibility of implementing the strategy versus the likelihood of the success of the strategy.

CARRYING OUT THE FIXES REQUIRED AND VALIDATING THEM FOR CORRECTNESS:

After defining the strategy for risk mitigation, it is equally important to implement it. The artifacts having flaws should be fixed. The progress of the risk mitigation strategy in terms of risks covered, risks remaining, impact of threats minimized should be recorded. After this, the fixes should be validated to check if they actually do what they claim to do.

RMF is not a linear process to be carried out just once to identify all the risks and provide a mitigation strategy for them. It is a cyclic process. Each activity of RMF  should be carried out throughout the software development life cycle to identify the risks at each step and provide a mitigation strategy for them to obtain a secure software.

Secure Software Engineering requires in-depth knowledge of domain, business context and possible issues (in terms of vulnerabilities, threats, attack patterns, historical attacks, risks) which must be incorporated for effective execution of touchpoints and hence obtaining secure software. So, now we will focus on the third major pillar of Secure Software engineering i.e. KNOWLEDGE.

KNOWLEDGE

Often it is said that knowledge is the best tool a man can have. Knowledge gives the power to implement the existing techniques more effectively and efficiently.

Knowledge in terms of secure software engineering refers to a set of guidelines, rules, principles which help in laying a strong foundation for secure software practices. The ocean of knowledge is huge and determining which set of knowledge is best suited for various types of systems and technologies comes with experience and expertise in the respective domains.

Secure Software Knowledge can be categorised into three major categories as follows:

1. Prescriptive Knowledge
2. Diagnostic Knowledge
3. Historical Knowledge

Let us throw some light on each of these knowledge types.

PRESCRIPTIVE KNOWLEDGE

Prescriptive knowledge is a set of principles, guidelines and rules which tell us what should be done and what should be avoided during the software development lifecycle.

DIAGNOSTIC KNOWLEDGE

Diagnostic knowledge includes information about vulnerabilities, threats and attack patterns obtained from various sources. It helps us identify the probable flaws in the system under development and fix them.

HISTORIC KNOWLEDGE

Historic Knowledge contains the information on attacks and risks in the past.  It is obtained using similar systems in their operational environment and helps in identifying and evaluating how the system under development can be prone to security attacks.

With increasing threats to software and systems, if best security practices (touchpoints) are followed and risk mitigation strategies are applied using appropriate knowledge, secure software engineering can definitely reduce the loss caused to businesses due to flaws and bugs in software systems.

Check out our article on Duo Mobile for improved security of apps and websites, or

Compare and review the best security tools for your project.