Secure Software Development
Cyberattacks surfaces can be classified into 4 main areas: public spaces, private networks (home), organizations’ network, partner networks. This is illustrated by GRA Quantum with their infographics below:
Figure 1: Cyber attacks surfaces
As part of my series of papers to cover the cyberattack surfaces, I have covered public and private spaces (home networks) with my papers “Public Wi-Fi Hygiene: Things to Consider” and “Protection of Home Networks: A Suggested Approach” respectively. Now I shall cover a part of the organization’s network pertaining to application security.
As cyber criminals’ skills evolve and with network security maturing, cyber attacks are increasing moving to application level hacking. According to The Solutionary Security Engineering Research Team (SERT) Quarterly Threat Report for Q2 2016, web application attacks, malware and application specific attacks comprised approximately 62 percent of all attacks during the second quarter of 2016. A chart from the report can seen in figure 2 below.
Figure 2: SERT summary of attacks for Q2 2106
There is clearly a need to improve the security posture of all applications before they are placed in production.
Over the years, security has generally been focused on network perimeter security with reference architecture clearly mandating the deployment of network firewalls, intrusion detection and prevention systems, etc., but with the rise in application level attacks, it is clear that traditional network security solutions cannot adequately protect against application attacks.
While firewalls and intrusion prevention systems (IPSs) are essential for preventing network
attacks, “next generation” firewalls go one step further by adding application awareness, which compares traffic against fingerprints of known applications. Unfortunately, none of these products understand acceptable user behavior in the applications, such as the field input length found in interactive screens, and allowed characters. Without this application understanding, network security products cannot accurately detect application attacks like SQL injection, XSS, CSRF, and parameter tampering.
Although Web Application Firewalls (WAF) play an important part in blocking off some of these attacks, there is a limit to externalizing the protection of applications.
To improve the security posture of applications, security needs to be baked into the design from the beginning and not as an afterthought. There is a need to apply design thinking to security too. Most application teams use design thinking techniques to see things from the users’ perspective, but I argue that we also need to apply these same techniques to how a hacker would think.
Security needs to be applied in every stage of the software development lifecycle to improve security in every aspect from requirements to operations.
There are a handful of secure SDLC frameworks proposed by multiple parties, these are some of the more prominent ones today:
Figure 3: Secure SDLC frameworks
l shall not go into the details of each framework or suggest which framework to adopt, but will go through some of the key considerations when putting in place a Secure SDLC methodology in the organization.
I would highlight some areas to be aware of to improve your security while planning, designing, developing/testing and deploying/maintaining the application.
During the planning phase, it is important to design security into the application. You should also be doing some form of threat modelling here.
Start with security in requirements (Abuse case)
Typically, in planning phase, requirements are gathered in the form of use cases. These use cases need to be supplemented with abuse cases. The concept of abuse cases is not new, it was developed in 1999, but is not often used. An example of abuse case for a university system is show in the figure below:
Figure 4: Abuse Case example in UML
It is important to start thinking about exploits so you can bake the defence into the product. I would highly recommend including a security professional or white hat hacker to be part of the planning stage as it “takes a crook to catch a crook” and most application designers are not used to thinking in terms of exploits.
Risk in business processes
As we adopt a risk-based approach to security, we need to look at how risk is injected into process flows and what are the risk-mitigation measures to put in place. These can be technology based measures or simply process based measures. An example of a normal and imperilled business process flow can be seen in the figure below.
Figure 5: Normal vs imperilled process flow
Understanding the risk at each process steps early, can help strengthen the process flow and overall security posture of the application.
During the design phase, we will be looking into the architecture of the solution. These should include the enterprise security architecture as well as application specific security architectures.
Enterprise security architecture
An enterprise security architecture helps tie up multiple applications together by creating solid foundational components and subsystems that are used across all applications. These should include security audit, flow control, access control, trusted credentials and integrity subsystems. A sample enterprise security architecture block diagram is shown in the figure below.
Figure 6: Sample Enterprise Security Architecture
These subsystems can be further expanded to components and processes that must be managed. An example of the credential subsystem process is shown in the figure below.
Figure 7: Sample credential subsystem processes
User experience design
Security should not be separate from design. Many instances of data breaches are a result of human error. Many of these can be avoided by knowing who your users are, and how they would be using the applications. One key design principle to remember is never leave users guessing what they should be doing or how to use the application. Using microinteractions is a very good thing in security design, for example in changing passwords, etc.
I have grouped developing and testing into a single group for discussion as I believe they are tightly integrated. Development is moving to a continuous integration cycle and testing is an integral part of this cycle.
Secure coding practice
There are many articles and books written on good secure coding practises so I shall not go into details here, but these practices are important habits for the development team to adopt.
Some of the principles of secure coding practices are to validate all inputs, keep it simple, default deny to all access, pay attention to compiler warnings, etc.
It would be good to do a refresher once in a while for the development team to reinforce the habits and to introduce new employees to adopt them.
Peer review is also encouraged for highly sensitive applications to further reduce the risk of vulnerabilities creeping in. As this can be an expensive process, users should adopt this at their discretion based on the risk rating.
Static code scanning
Dynamic code scanning
Before deploying an application, it is usually necessary to perform a dynamic code scan. A dynamic code scan can help discover vulnerabilities in a run-time environment which might be missed by static scanning.
Before going live or with any updates, it is recommended that dynamic scans be run and in addition, there are some other actions that are necessary to further enhance the security of the application.
Penetration tests should be employed to discover if any vulnerabilities can be exploited to gain access to the system or data. As penetration testing is an established and mature discipline, I shall not go much deeper into this.
Environment vulnerability scanning
Beyond the boundaries of the application, it is important to understand the environment in which the application is deployed. The operating systems it runs on, the application server it is deployed to, the database where the application data is stored, the transport mechanism used, the message payload protocols, etc. are all areas that needs to be examined for vulnerabilities and needs to be patched or harden accordingly.
With the popularity of container technologies like docker, it is also important to perform image comparison and vulnerability scanning of the container. There are freeware tools such as DockerScan available on GitHub and these should be employed if possible.
Containers should also be configured to only have the minimum required components to run the application to reduce the attack surface.
Security Operations (SecOps)
I would also like to add a section on Security Operations which covers a wider spectrum of the Secure SDLC cycle.
Security operations is the marriage of IT security and operations in the way DevOps is the marriage of development and operations. An example of SecOps practices is “Continuous Security Testing” , which is similar in concept to continuous integration found in Devops practices. Just as DevOps break down development silos in the development and operations process, SecOps does the same to break down security silos to allow a better integration approach.
Adopting SecOps practices would also reduce human errors by automating many of the security testing task that used to be handled manually.
A team adopting SecOps practices would also be able to have better monitoring and controls by integrating better with Security Operations Centres (SOCs) and enable better threat prediction and remediation.
This is a much bigger topic which would be covered in more details in a future paper.
This paper is not a prescriptive approach to secure software development but serves as a piece to encourage better practices that can be adopted in software development to improve the overall security posture of an organization.
There are a lot of developing areas in secure software development and I encourage you to find practices and tools you can adapt to your development and to bake these into your SDLC or DevOps cycles.
Security is everyone’s business, we can all make this world a safer place.