Unit Level “Secure by Design” Approach Authors: Vasantharaju MS & Joshua Cajetan Rebelo [email protected] [email protected] Abstract With cyber-attacks on the rise and high-profile breaches becoming the new normal, being on top of the current trends in cyber threats is a key to improve your cyber security posture. Organizations span the spectrum when it comes to the maturity around creating secured products. Overall, organizations should have a well-defined security software development lifecycle (SDL) process which embeds security in each SDLC process instead of considering security as a feature. Any change to the application or environment, changes the attack surface. If you don't have a “secure by design” strategy at every stage - from product development to product deployment, addressing security can become very intimidating and challenging. Security findings found late in the release cycle or post release, can ask for architecture redesigning, which can be expensive. The current scenario is that Unit test design and coverage in most cases covers the functionality and not the security aspect of the product. Security mostly gets addressed later in the SDL cycle, and the product team will rely on the penetration test results. In this paper, we present a Unit level “secure by design” approach which will help in early security defect finding. This approach will help to address multiple layered security testing i.e. address security at Unit level. Many times, penetration test, and security test might not be able to penetrate deep into the product. This is where Unit level test will help to address security. Unit testing platform supports mocking and accessing private members which can be leveraged to ensure security at different abstraction layers of software. As more organizations are adopting Test Driven development (TDD), Unit level security testing will enforce security by design, thus, addressing security early in the SDL cycle. Biography Vasantharaju M.S. is a Senior Software Development Engineer at McAfee Software with over 9 years of experience in developing enterprise-class software. His past experiences include; designing and implementing back-office solution to address a Dodd-Frank clause, enhancing web crawler and vulnerability detection in SaaS based vulnerability scanner and executing multiple Proof-of-Concepts for enhancing SaaS based security management platform. He has a keen interest in application security and secure coding. Joshua Cajetan Rebelo is a Security Researcher at Siemens with 13 years of experience in the security domain. He ensures that the products are under continuous development to incorporate the highest Security Software Development Lifecycle (SDL) standards and adheres to the Product Security Maturity Model (PSMM). He has vast experience in conducting security code reviews, evaluating software architecture for potential risk. He has expertise in Application security, System security, Cloud security, and Industrial Control System security. He is a mentor on product security to many teams. He also brings innovation with new ideas and has three patents issued to his credit. Excerpt from PNSQC 2016 Proceedings PNSQC.ORG Copies may not be made or distributed for commercial use Page 1 Intended Audience The target audience for this paper includes program managers, project managers, developers, quality assurance engineers, and IT professional who are familiar with the software security literature. This paper is also meant for people who are passionate about security and want to integrate security into their standard software development lifecycle (SDL) processes to enhance the product security maturity model to stay secured. 1 Introduction In a typical SDLC approach, unit test is always written to ensure that the unit is functional. These functional unit tests take precedence over secure architecture design. These unit tests which include standard unit testing terminology will not be exhaustive enough to test all possible negative and attack scenarios. These gaps of unexplored code path are of interest to the cyber attackers. These gaps need to be considered, reviewed and addressed. This paper ensures that The unit is secure Security is embedded at different abstraction layers of software. Unit test penetrate deeper into the application and increase the code coverage. Product teams write secure software at early stage of product development. 2 What is Secure Software? Secure software exhibits the following characteristics: Takes care of implementation errors with exploitable effects Contains security features which cannot be bypassed Is self-protective Minimizes the consequence of successful attack (“fail well”) The multi-layered security can be achieved by adopting the STRIDE Threat-Model approach. Spoofing identity Tampering with data Repudiation Information disclosure Denial of service Elevation of privilege This paper will help in writing unit test using this STRIDE model to get maximum security coverage, thus helping developers adopt a “Secure by Design” Approach at unit level. Before we dive deep into the paper, let us understand what Test-driven development is and how we can use it in making the unit level security tests efficient in building multi-layered security. Excerpt from PNSQC 2016 Proceedings PNSQC.ORG Copies may not be made or distributed for commercial use Page 2 Test-driven development is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refractors the new code to acceptable standards. For the sake of this paper, the examples shown are for java development, but can be adopted in any other technology. 3 Test-driven development (TDD) life-cycle 1. Write the test 2. Run the test (there is no implementation code, test does not pass) 3. Write enough implementation code to make the test pass 4. Run all tests (tests pass) 5. Refractor 6. Repeat Let us consider the requirement from product management of an application with logon functionality integrated to a database through the data access object layer (DAO). Let us consider the following example of an insecure login application which didn’t follow secure coding or design practices or TDD approach. This example of login application is vulnerable to attacks like SQL injection, Sensitive Information disclosure, repudiation attacks, spoofing, tampering and privilege escalation etc . Figure 1: Insecure Login Application If the unit test design and coverage was focused only on covering the functionality of the module and not the security aspect, then the unit test would be as follows. Excerpt from PNSQC 2016 Proceedings PNSQC.ORG Copies may not be made or distributed for commercial use Page 3 Figure 2: Unit Test of insecure login Application As seen in figure 2, the unit tests don’t cover attacks like spoofing, tampering, repudiation, information disclosure, denial of service and privilege escalation as defined by the STRIDE model. In the next section we shall see how secure test-driven development approach addresses this problem. 4 Secure Test-Driven development The following would be the approach of secure test-driven development to build secure software with multi-layered security: 1) Start Design discussion 2) Create Data flow diagram for all functionalities and work flows 3) Identification of mocking module 4) Threat Identification using STRIDE Threat Model 5) Unit test designing to detects identified threats 6) Run the test (there is no implementation code, test does not pass) 7) Write enough implementation code to make the test pass 8) Run all tests (tests pass) Let us see how this Secure Test-Driven development can help transform the insecure login application seen in figure 1, into a secure application having multi-layered security in-built. Excerpt from PNSQC 2016 Proceedings PNSQC.ORG Copies may not be made or distributed for commercial use Page 4 4.1 Identification of Mocking Modules It is critical to identify the applicable mocking modules, since mocks are prerequisites for fast execution of tests and ability to concentrate on a single unit of functionality. By mocking dependencies external to the method that is being tested, developer can focus on the task at hand without spending time to set them up. Execution of tests without mocks tends to be slow. Good candidates for mocks are databases and scripting engines. Following are some of the mocking module which can be leverage in writing unit test. a) HSQLDB - to mock the database to test SQL injection attack and error / exception handling. b) MOCKITO - to mock interfaces so that a dummy functionality can be added to a mock interface that can be used in unit testing. 4.1.1 Hyper SQL Database (HSQLDB) Each database will have different dialects like hint or comment, add-on features like server-side executable and limitations. As seen below, we will be using hsqldb which will help to mock the DB for faster execution and to remove the external dependencies. Figure 3: Using HSQLDB to create database for sample login application for Unit testing Similarly other mocking modules like Mockito, PowerMock etc can be evaluated for applicability. Excerpt from PNSQC 2016 Proceedings PNSQC.ORG Copies may not be made or distributed for commercial use Page 5 4.2 Threat Identification using STRIDE Model For the logon functionality