Secure Software Development Life Cycle
“Necessity may be the mother of invention, but adopting security is an investment, not an expense.”
In the epidemic of digital encyclopaedia, threat landscape has changed drastically and is essential to encourage our business leaders to adopt a culture of security to impart global security best practices from day one of the development process. Organisations are well concentrated to provide innovative products to their customers ahead of the competition. But with the increasing security concerns and business risks, it is equally important to integrate security into every step of Software Development Life Cycle (SDLC) and the process is defined as secure SDLC. One of the basic principles of secure SDCL is shifting security left.
Secure SDLC integrates global security practices and security tools into the SDLC model and ensures security assurance activities like architecture analysis, penetration testing and code review are an integral part of the development and thus helps to discover security bugs at the earliest.
Why Secure SDLC
Many companies consider security in their applications as part of the quality assurance process after their software has been fully developed towards the end of the software development lifecycle. But the cost and time of remediating the security vulnerabilities in post-production is higher compared to addressing it in the earlier stages of the SDLC. A good deal of advantages can be achieved by adopting security from initial phase of development life cycle.
- Early detection of security vulnerabilities brings time and cost efficiency
- Increases the security posture and gains customers trust
- In-depth coverage of security in terms of configuration and architectural designs
- Security risks are identified and managed at every stage to achieve acceptable level of risk
- Spreading security awareness by collaborating with multiple teams involved
Approach and Methodology
The formal way of implementing security as SAST and DAST to identify the vulnerabilities in the developed product uncovers the security posture of architectural design and intermediate components configurations. Integrating security into SDCL enhances the security on front end process. To achieve this efficiently, the security requirements for every phase should be strictly outlined and enforced to review the controls implemented prior to moving to the subsequent phases.
1. Planning and Analysis
Any product development initiates by gathering the requirements and system analysis. In this phase, security experts advise to incorporate applicable security policies, global security standards and regulatory compliance as an important factor to avoid later conflicts.
Risk analysis is carried out based on the type of information application is processing, functionality and use-case modelling.
Once the framework and languages are decided, developers and security experts should collaboratively think the kind of security risks associated with the technologies being used and which risks require attention during design and development phase to achieve a secure product with minimal effort.
This phase engages to derive security requirements from business functionality and build an access control matrix for resources and capabilities.
2. Architecture and Design
This phase address the risk considered in the previous phase using threat modelling and architecture review.
Current threats and new risks associated with the internal components are evaluated, prioritized and mitigated at the design phase to counter the security bugs in development and deployment stages.
Threat Modelling
The two main objectives of threat modelling are:
- Implementing proper security controls adherence to requirements & policies
- Investigating assets involved and potential threats to implement appropriate counter measures against threats. With these contexts, threat modelling is confined to address in four aspects.
- Software Centric
- Asset Centric
- Attacker Centric
- Threat Centric
Software Centric
This phase engages to analyse the design of the system by evaluating the software architecture diagrams like component diagrams, data flow diagrams, use case diagrams, etc.
This approach examines the de-facto standards of network and other systems involved in the process.
Example: Threat Analysis & Modelling (TAM), and Microsoft Secure Development Lifecycle framework (SDL) tools validate the systems being analysed through data flow diagrams.
Asset Centric
This phase involves in identifying the important assets of an organization such as systems (firewalls, deployment servers etc) and data assets. Data assets are interpreted to prioritize the risk levels based on the sensitivity and peculiarity to the potential attackers.
Attacker Centric
This phase engages to profile the skill set, characteristics and the desire of potential attackers to exploit various assets of an organization.
These profiles are further analysed to understand the attack pattern and exploitation techniques perpetrated by an attacker and thus helps to implement the counter measures against potential attacks.
Threat Centric
Threat Centric is a comprehensive approach to implement end-to-end security in highly interconnected cyber ecosystem. It uses the metrics from above approaches and maps the attack surface considering the known and unknown threat agents leading to impact any of the assets in the organization.
The primary objective is to design an end-to-end comprehensive security policy by quantifying the organization’s cyber ecosystem risks considering internal and external threat factors.
STRIDE and PASTA are few threat modelling methodologies that are efficiently used for this approach.
3. Development/Implementation
In the initial phase of development, product is developed at unit level using the technology stack decided at the earlier stage and then developed units are integrated to build the entire product.
Here, security experts ensure to develop the secure code by following global security coding standards and adopt all security controls identified in the design phase for every unit developed.
Initially, every unit of code is reviewed for security standards and then overall integrated build is verified either manually or by using automated SAST tools.
The primary objective is to implement security controls for all potential threats and existing vulnerabilities. Below are the list of industry best security controls advised to implement during development phase.
| S. No | Secure Code Review Best Practices |
| Input Validation | |
| 1 | Conduct data validation on all trusted and untrusted sources for malicious characters |
| 2 | Specify proper charater sets, such as UTF-8, for all sources of input |
| 3 | Encode data to a common character set before validation |
| 4 | All validation failures should result in input rejection |
| 5 | Validate all client provided data before processing including URL's, parameters & HTTP headers |
| 6 | Verify header values of both requests and responses contain only ASCII characters |
| 7 | Validate data for expected data types, length and range |
| 8 | There should be a centralized input validation routine for the application and it should check descretly null bytes (%00), new line characters(%0d, %0a, \r, \n), dot dot slash(../) |
| Output Encoding | |
| 9 | Conduct all encoding on a trusted system (e.g., the server) |
| 10 | Encode all characters unless they are known to be safe for the intended interpreter |
| 11 | Sanitize all output of un-trusted data to operating system commands and data to queries for SQL, XML, and LDAP |
| 12 | Contextually output encode all data returned to the client that originated outside the application's trust boundary. HTML entity encoding is one example, but that does not work in all cases |
| Authentication and User Management | |
| 13 | Require authentication for all the pages and resources, except those specifically intended to be public |
| 14 | All authentication controls and password hashing must be enforced to a trusted system (a server) |
| 15 | All authentication controls should fail securely |
| 16 | Use only HTTP POST requests to transmit authentication controls |
| 17 | Enforce password policies confined to the regulatory standards |
| 18 | Security policies are configurable (not hardcoded) |
| 19 | Standard security frameworks are used (instead of custom code) |
| 20 | SSL is used to protect user credentials and authentication tokens |
| 21 | Application handles suspicious events such as multiple failed logon attempts, session replay and attempted access to restricted resources |
| Session Management | |
| 22 | No session parameters passed in URLs |
| 23 | Session cookies expire in a reasonably short time |
| 24 | Session cookies are encrypted |
| 25 | Session data is being validated |
| 26 | Private data in cookies is kept to a minimum |
| 27 | Application avoids excessive cookie use |
| 28 | Session id is complex |
| 29 | Session storage is secure |
| 30 | Application properly handles invalid session ids |
| 31 | Session limits such as inactivity timeout are enforced |
| 32 | Logout invalids the session |
| 33 | Disable client side caching on pages containing sensitive information |
| Authorization | |
| 34 | Use only trusted system objects, eg: server side session objects for making access authorization decisions |
| 35 | Access controls should fail securely |
| 36 | Seggregate privileged logic from other application code |
| 37 | Restrict access to protected URL's and functions only to authorized users |
| 38 | Restrict direct object reference to only authorized users |
| 39 | Authorization cannot be bypassed by cookie manipulation |
| 40 | ACLs are configured for all files and define roles properly |
| 41 | Use "referer" header as supplemental check only, it should never be sole authorization check, as it can be spoofed |
| Cryptography | |
| 42 | Sensitive data has been secured in memory, storage and transit |
| 43 | All cryptographic functions used to protect secrets must be implemented on trusted system (Server) |
| 44 | Cryptographic modules should fail securely |
| 45 | Cryptographic modules used by the application should be compliant to FIPS 140-2 or equivalent standard |
| 46 | Establish and utilize a policy and process for how cryptographic keys will be managed |
| 47 | SSL provider supports only strong algorithms |
| Exception Handling | |
| 48 | Do not disclose sensitive information in error responses, including system details, session identifiers or account information |
| 49 | Use error handler that do not display debugging or stack trace information |
| 50 | Implement generic error messages and use custom error pages |
| 51 | Error handling logic associated with security controls should deny access by default |
| 52 | All logging controls should be implemented on trusted server |
| 53 | Restrict access to logs to only authorized individuals |
| 54 | Do not store sensitive information on logs, including unnecessary system details, session identifiers or passwords |
| 55 | Log all input validation failures, authentication attempts, access control failures, system exceptions and other failure events |
| Database Security | |
| 56 | Use strongly typed parameterized queries |
| 57 | Utilize input validation and output encoding and ensure to address meta characters |
| 58 | The application should use the lowest level of privilege when accessing the database |
| 59 | Connection string should not be hardcoded within the application, and should be stored in a separated configuration file on trusted server with encryption |
| 60 | Use stored procedures to abstract data access and allow for removal of permissions to the base tables in database |
| 61 | Remove or change all default database administrative passwords |
| General Coding Practices | |
| 62 | Use checksums or hashes to verify the integrity of interpreted code, libraries, executables, libraraies and configuration files |
| 63 | Use tested and approved managed code rather than creating new unmanaged code for common tasks |
| 64 | Review all secondary applicatons, third party code and libraries to determine business necessity and validate safe functionality |
| 65 | Ensure system calls have their return status checked |
| 66 | No exposures to buffer overruns |
| 67 | System calls have their return status checked |
| 68 | Safe update - ensure libraries are up to date |
| 69 | Efficient memory usage |
Tools Used: Checkmarx, Codestriker, CodeBrag & Rhodecode are few automated tools used to perform secure code review.
4. Testing/Staging
Once the complete software is built, it is deployed in the testing environment to carry out functional, non-functional and performance tests. At this point, security experts perform full-blown security assessment, which includes both vulnerability assessment and penetration testing. The main objective of penetration testing is to identify business logic vulnerabilities present in the system. Grey box penetration testing is carried out to identify exploitable vulnerabilities present in the system and mitigating these vulnerabilities ensures the complete coverage of security to the end product to deploy in the production environment.
Tools Used: Burp Suite, OWASP ZAP, Nessus, Ironwasp, etc. are few open-source and enterprise edition tools used to perform security assessment of entire product.
5. Production Deployment
Many organizations strongly believe that building the product with complete security controls at every level is adequate to protect from external threats, but to protect from ever evolving techniques used by the evil hackers to threaten the organizations, it is important to keep an eye on incoming and outgoing traffic.
SIEM tools are integrated into the infrastructure for continuous monitoring of traffic and security analysts perform log analysis and investigate triggered security incidents.
Tools Used: Splunk, McAfee, IBM Qradar, etc.
Conclusion
The world matures digitally with new inventions and incorporating security gains customer trust and enhances the usage of software product. To address the threat landscape efficiently organizations should implement the security as a built-in feature rather than add-on to the product.
Author Bio: With more than 15 years of experience in Information Security across APAC and North America, Venkat leads our Enterprise Security business unit and is responsible for custom solutions and service delivery. He works closely with our Enterprise and ISV clients including start-ups and helps achieve their Enterprise Security objectives. You can reach out to him at vgottipati@innominds.com for any advisory and consultative thought leadership on the topic of Enterprise Security.
