MARCH Secure Software Development WHAT TO CONSIDER

Transcription

1 MARCH 2017 Secure Software Development WHAT TO CONSIDER

2 Table of Content Introduction... 2 Background... 3 Problem Statement... 3 Considerations... 4 Planning... 4 Start with security in requirements (Abuse case)... 5 Risk in business processes... 5 Designing... 6 Enterprise security architecture... 6 User experience design... 8 Developing/Testing... 8 Secure coding practice... 8 Static code scanning... 8 Dynamic code scanning... 8 Deploying/Maintaining... 9 Penetration testing... 9 Environment vulnerability scanning... 9 Security Operations (SecOps)... 9 Conclusion Ian Loe

3 Introduction Cyberattacks surfaces can be classified into 4 main areas: public spaces, private networks (home), organizations network, partner networks. This is illustrated by GRA Quantum 1 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 2 and Protection of Home Networks: A Suggested Approach 3 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 Ian Loe

4 attacks, malware and application specific attacks comprised approximately 62 percent of all attacks during the second quarter of A chart from the report can seen in figure 2 below. Figure 2: SERT summary of attacks for Q There is clearly a need to improve the security posture of all applications before they are placed in production. Background 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. 5 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. Problem Statement 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 Ian Loe

5 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: MS Security Development Lifecycle (MS SDL): One of the first of its kind, the MS SDL was proposed by Microsoft in association with the phases of a classic SDLC. NIST : Provides security considerations within the SDLC. Standards were developed by the National Institute of Standards and Technology to be observed by US federal agencies. OWASP CLASP (Comprehensive, Lightweight Application Security Process): Simple to implement and based on the MS SDL. It also maps the security activities to roles in an organization. Cigital s Security Touchpoints: Proposed by Gary McGraw in Building Security In, presents an artefact-centric approach (designed to operate on documents, diagrams, code, etc.) rather than a process-centric approach. This, in turn makes the security analysis SDLC model agnostic. Figure 3: Secure SDLC frameworks 6 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. Considerations I would highlight some areas to be aware of to improve your security while planning, designing, developing/testing and deploying/maintaining the application. Planning During the planning phase, it is important to design security into the application. You should also be doing some form of threat modelling here. 6 Ian Loe

6 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 , 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 8 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 7 John McDermott and Chris Fox (Dec 1999). "Using Abuse Case Models for Security Requirements Analysis" (PDF). Proceedings of the 15th Annual Computer Security Applications Conference, (ACSAC '99): Ian Loe

7 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 9 Understanding the risk at each process steps early, can help strengthen the process flow and overall security posture of the application. Designing 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. 9 Example from IBM s Method for Architecting Secure Solutions (MASS) Ian Loe

8 Figure 6: Sample Enterprise Security Architecture 10 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 10 Sample from IBM Method for Architecting Secure Solutions (MASS) Ian Loe

9 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 11 is a very good thing in security design, for example in changing passwords, etc. Developing/Testing 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 At a minimum, source code scanning should be performed with automated build processes. This is probably more suitable for traditional languages like.net languages, Java, C, C++, etc. Due to the nature and structure of the language, today there is limited ability to do this for JavaScript based applications or frameworks like AngularJS etc. But as technology improves, there are ways to use machine learning to help identify patterns in these codes. They may not be as robust in capturing all the details like you can with traditional languages and tools, but it does offer some help to identify the more common vulnerabilities. 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. 11 What is a microinteraction - Ian Loe

10 Deploying/Maintaining 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 testing 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. Container scanning 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 12, 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. 12 OWSAP : Continuous Security Testing in a DevOps World- Continuous_Security_Testing.pdf Ian Loe

11 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. Conclusion 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. Remember: Only the paranoid survives J Ian Loe