Software Development with Built-in Security

Quite often we encounter the situation where Software Security has been an afterthought item which is to be checked off by the group that is responsible for the safeguarding of software security. That approach had been effective to some extent while the software was sitting in an isolated silo, totally disconnected from the outside world and accessed only within the boundary of that organization. But the ubiquitous presence of Internet demands an immediate change in that approach. Time has come to shift the paradigm from reactive software security to a more proactive software security where security would not be implanted into the software after it is built rather the security would be a built-in feature organically grown from the very beginning of the software inception.

So, how the software security can be built into the core fabric of software? This requires not just a change in the process and perception but a complete cultural change where the software security isn't the headache of the security guy sitting isolated in a cubicle at the corner of office, but a collaborative responsibility of everyone who are involved in the software development life cycle (SDLC) i.e. Analysis, Design, Development, Testing and Implementation.

THE GOAL OF SOFTWARE SECURITY

Let's first clarify the goals of the Software Security i.e. what we would like to achieve through this journey of secured software development. The goals are to achieve Confidentiality, Integrity, and Availability (CIA) in that Software. Confidentiality makes sure that the software provides access to the assets (i.e. data, processing, capability etc.) only to the authorized users in a need to know basis. Integrity is the attribute where the software ensures that the assets are kept in a consistent manner in every interactions. Availability is the characteristics that ensures to provide a guaranteed level of availability of the software that's agreed upon by the software provider and the users. This availability is to be considered not by just the availability in terms of being accessible but accessible with certain level of usability, throughput, and completeness. Each phase of the software would have to make sure that the CIA goals are met or, at least, taken into consideration.

PHASES OF SOFTWARE SECURITY DEVELOPMENT

The entire process to effectively incorporate the security in software can be broken into four phases: Planning, Execution, Monitoring and Controlling. These four phases would effectively encompass the secure software development cycle, as depicted by the below diagram.

PLANNING

This is the most overlooking part when the secure software development is taken into consideration. Most of the time, the goals of the secure software are not met due to the poor or, in some cases, lack of planning. The planning process starts with developing the defining the goals of the software security and ends by creating security execution plan. Here’s a high level depiction of planning process and the desired artifacts to be produced through that process.

Below is the deep dive to the detail of the planning process:

1.1. First step is to define the goals that the software security is targeting to achieve. The goals shouldn't be just a vague statement like “we want the software to be resilient and secured when under attack” but the goals should follow the SMART criteria i.e. Specific, Measurable, Achievable, Realistic and Time bound. Here’re few example of SMART goals of Secure Software:  “The software would have 

  - zero code vulnerability as reported by the static code scanner, 

  - log 100% users action at runtime 

  - notify the security administrator within 30 minutes of a predetermined suspicious activities 

  - shutdown all the services to access the “HIGH VALUED ASSETS” such as database that holds customers personal information”

1.2 Define a policy and procedure on how the software security activities would be integrated to the Software Development Life Cycle (SDLC). One of way of achieving that is to define a

“Toll gate” at every stages of SDLC and define the pass through criterion. Here’s a few example of passing criteria : 

- At the end of the Requirement phase, have a requirement review to verify that Security Requirements have been signed off by the Information Security Officer (ISO)

- At the end of the Development, an application code scanner is run and 100% critical vulnerabilities and 80% of Moderate vulnerabilities are resolved

- QA has executed 100% Security Test Cases and are passed with provable evidence 

1.3 Develop a Threat Model of the software being developed. A threat model is a way to understand and prioritize risks and evaluate mitigation possibilities. Steps to a threat model are: Identify assets, Understand systems, Understand threats, Categorize threats and Rank the threats” 

Few things need to be considered while analyzing the system (i.e. the software under construction) and the associated threats. Those are: detail understanding of the underlying technologies used in the software, vulnerabilities and risks of the technologies being used, and the target market segment. Through the development of a threat model, the mitigation plan would be created. Usually the high ranked threats are mitigated and moderate and low ranked threats are kept documented so that when the threats are materialized, an immediate response can be put in place 

1.4 Making sure that the software development plan has incorporated the security artifacts in it 

1.5 Develop and Security Test Plan & Strategy of the software in accordance to the Software Threat Model. The strategy would define on how the software would be tested while being developed during the execution phase

1.6 Documenting the Security assumptions. Though this is true for every other aspects of the SDLC but for security, this rank very high and absolutely critical. The reason is, the software is usually built for a target user group in a certain operating environment but eventually  may end up being used in a completely different environment. As an example, software that  was developed to serve internal customers within a corporate security peripheral may end 

up being used over the internet eventually when the company grows across geographical location around the world. In that situation, the software’s vulnerability should be re-

evaluated but if the initial assumptions weren't documented, it may not be handled at the time of expanding the scope

1.7 The Security Response Plan (SRP) would have to be created as part of planning process. The SRP would be used when the software would be in use .The SRP should elaborate the detail procedure on responses when the software security threats are materialized as well as the roles and responsibilities of the security response team. Security Requirement has been signed off by the Information Security Officer (ISO) vulnerabilities and 80% of Moderate vulnerabilities are resolved.

2. EXECUTION

In the execution phase, all the action plans created during the planning phase would be implemented. At every steps of the standard Software Development Life Cycle (SDLC), the security aspect would be considered and implemented. 

Requirement Analysis: the first step of the SDLC is the requirement analysis phase and security has to start from there as well. Along with the standard Function and Non-functional requirement analysis, a detailed security requirement analysis would be done. This security requirement analysis would start with standard authentication and authorization requirements of the software and then continue to develop the other requirements in light of the previously developed Software Threat Model. This is very important to document all the functional and non-functional security requirements (sometimes dubbed as abuse cases) so that the software can be verified to have those requirements built in to the system. Below is the high level breakdown of execution process and the outcome artifacts:

Design and Development: the development of the software starts with the design of software. The security requirements of the software would be designed in parallel to the software’s functional behavior. If the security requirements are not designed upfront in the process, the security would be used as a band aid to the system rather than built in to the system. In certain situation, the design of functional requirement of the software would be influenced by the security designs. As an example, the way the software would access the customer’s personal confidential data (if available in that system) would be heavily dictated by the security requirement of the system. Here’re few example of design guideline to ensure the software security:

- Appropriate encryption has to be in place to prevent sniffing. This could mean to use of SSL, or if need further security, second layer of encryption can be enforced for certain assets that require higher level of confidentiality

- Data masking would be implemented to have the data visible to the people strictly as need to know basis

- Enforce the use of software library and frameworks that naturally prevents certain security threats, or if further security is needed, a second layer of encryption can be enforced for certain assets that require higher level of confidentiality. As an example, the use of Object Relational Mapping (ORM) framework to access RDBMS database will put an extra level of protection against SQL Injection 

- Every access and access-attempts would be logged 

- The movement of confidential data needs to be traced. The inbound and outbound data movements are to be logged with certain detail (e.g. user ID, computer terminal, geographic location, time zone etc.).

During development, the developers need to use a software security static analyzer (e.g. IBM Security AppScan Source) while performing developer’s unit testing. The software functionality can only be released when all the critical vulnerabilities are resolved. Though the zero vulnerability reported by a static analyzer does not guarantee secure software, but at least this is a good starting point where all the known security issues are handled. Much of security vulnerabilities are exploited through a copy book attack of the well-known vulnerabilities. So there’s no excuse to slip the well-known vulnerabilities. 

Testing: the quality assurance of the software is done through testing phase and the incorporation of the security testing is necessary to develop secure software. The Testing process comprises of two phases: Test Strategy and Test Execution. The Test Strategy has been developed as part of the planning phase and now during the Execution phase, the Security Test Cases are created and subsequently executed on the developed software. The successful execution of the Security test cases would be a precondition to release to software. 

Deployment: This is the last phase of the SDLC when the other aspect of software security would be used to maintain the security of the system. It is imperative to say that, the highly secured software can be deemed vulnerable and at risk due to the substandard deployment environment. The deployment security consists of: 

    - Physical security of the server and network systems

    - Security of Operating systems of the server (through operating system hardening) 

    - Security of the platform consists of application server, database server, web server etc. 

    - Security of the computer network 

    - Security of end users computing platform (when possible)

3. MONITORING

Unlike most of the other software development activities (e.g. analysis, design, development, testing etc.), the software security process does not stop at the completion of software development. Software needs to be kept under constant monitoring. The primary reason behind the need to keep the software under constant monitoring is that, no amount of software security test can be enough to declare any software as free of security vulnerability or as free of security risk. To understand why it’s almost impossible, take this hypothetical scenario: consider that the software uses the Advanced Encryption Standard (AES) 128 bit encryption method and at the time of the software delivery, the testing was done using the computational resources available and found unbreakable in a reasonable time period. But during the life of the software, more powerful computer would be available in a much cheaper cost (Moore’s law has guaranteed that) or a smart hacker would emerge who would break that encryption method using a smarter algorithm. That means the security group has to keep the software in monitoring to make sure that the software is not compromising the security in daily basis. Below are some of the areas that would need active monitoring: 

3.1 The application code base should be periodically scanned for added vulnerabilities. This is very crucial, as even though the software may have been released with zero vulnerabilities but over the period of its life, new code would be added and sometime those newly added code could introduce new vulnerabilities into the piece of code that were previously deemed as secured

3.2 Monitoring the authorized users access log if they are accessing the assets that they are authorized to. Sometime the authorized users could gain access to the confidential functionality or data because of a software bug, administrative mistake, etc. 

3.3 Monitoring unauthorized access as well as the attempt to unauthorized access to the system. The logs of “attempt to unauthorized” access gives clue to the security group on potential vulnerabilities point where malicious users are trying to break in

3.4 The logs of the inbound and outbound data movement in the software should be under constant monitor. The unusual movement of data may be an indication of security breach 

3.5 Server resource utilization have to be kept under constant monitoring. The use of CPU, memory, disks space, network I/O etc. could help to identify a potential abuse of the software. For example, if the software process is taking up unusually high CPU time or using more memory than the trend and don’t have any reasonable cause for that, this gives a reason to investigate that high usage

3.6 Periodical Pen testing, Stress testing, and Load Testing should be conducted to probe the security vulnerability of the system

3.7 Prefer automated monitoring over manual one. Manual monitoring is not sustainable. Manual monitoring can be put in place as an exception basis and only in the case where automated monitoring is impossible or not cost effective

3.8 Software security should be quantified. Though it’s very hard to tag a number to communicate the security level of software but it’s not impossible to achieve. The aspects of monitoring can be calibrated into a scale and compare against that scale. Through which it

would be much easier to compare the improvement or declined of the software security risks. There is downside of quantifying software security as it may give a false sense of security but the benefit of that outweighs the disadvantage

3.9 Finally, prefer the visual presentation of the monitoring results over text based result. Human brain is naturally tuned to visual cue than text interpretation

4. CONTROLLING

There is no value of monitoring if an effective controlling process is not in place. In the controlling process the outcome of monitoring would be used to take necessary action to prevent security threat and provide feedback to the planning process to improve the software’s overall security. 

The primary goal of this phase is to mitigate the potential threat or minimize the damage done due the materialization of a potential security threat. For example, if monitoring of software detects an unusual activity of confidential data movement or a very high usage of server resources (CPU/memory), as an extreme measure, the software could be temporarily shut down to minimize the damage and then after proper investigation this can be reopen if deemed secured. The controlling also involves applying software bug fix, security patch etc. in a timely manner to proactively thwart potential risks. 

In conclusion, the software security in Software Development is more of a culture than a process and can’t be attained at that level unless an organization fully appreciates the value of it. Software organizations should accept the fact that the cost is very high of not putting focus on the security which could even be go up to bankruptcy. Embracing the software security in every aspect of software development life cycle is the key to have the security built into it. If the security is a module that is plugged into the software rather than built into the fabric of the software, the attackers can isolate the security module and force the software to compromise to their attacks. Every piece of the code must have to be security aware and only through that a robust software security can be achieved.