Secure Software Development Life Cycle
Each phase of the SDLC must contribute to the security of the overall application. This is done in different ways for each phase of the SDLC.
Software development life cycle security needs to be at the forefront of the entire team’s minds.
In this early phase, requirements for new features are collected from various stakeholders. It’s important to identify any security considerations for functional requirements being gathered for the new release.
- Functional requirement: During requirement phase, team must consider security concerns at each module. Security concerns may include PI/SPI data, B2B communication where PI data is involved.
- Security consideration: How data is accessed, stored, who has permission to access the data. What controls is implemented to protect data both at Cloud and Data center level.
Design Phase Work in progress
When it’s time to implement the design and make it a reality, concerns usually shift to making sure the code well-written from the security perspective. There are usually established secure coding guidelines as well as code reviews that double-check that these guidelines have been followed correctly. These code reviews can be either manual or automated using technologies.
Modern application developers can’t be concerned only with the code they write, because the vast majority of modern applications aren’t written from scratch. Instead, developers rely on existing functionality, usually provided by free open source components to deliver new features. Sometime choosing a wrong open source may lead to security vulnerabilities.
In fact, 90%+ of modern deployed applications are made of these open-source components.
You can also focus on the below pointers while developing any applications.
- Using parameterized, read-only SQL queries to read data from the database and minimize chances that anyone can ever commandeer these queries for nefarious purposes
- Validating user inputs before processing data contained in them
- Sanitizing any data that’s being sent back out to the user from the database
- Checking open source libraries for vulnerabilities before using them
- Logging at each layer like (Controller, Service and Database level)
The Verification phase is where applications go through a thorough testing cycle to ensure they meet the original design and requirements. This is also a great place to introduce automated security testing using a variety of technologies.
The application is not deployed unless these tests pass. This phase often includes automated tools like CI/CD pipelines to control verification and release.
Verification at this phase may include:
- Automated tests that express the critical paths of your application
- Automated execution of application unit tests that verify the correctness of the underlying application
- Automated deployment tools that dynamically swap in application secrets to be used in a production environment
Once the application is released. In fact, vulnerabilities that slipped through the cracks may be found in the application long after it’s been released.
These vulnerabilities may be in the code developers wrote but are increasingly found in the underlying open-source components that comprise an application. This leads to an increase in the number unknown vulnerabilities that are discovered in production by the application’s maintainers.
These vulnerabilities then need to be patched by the development team, a process that may in some cases require significant rewrites of application functionality.
Vulnerabilities at this stage may also come from other sources, such as external penetration tests conducted by ethical hackers. Addressing these types of production issues must be planned for and accommodated in future releases.
How to Ensure SSDLC?
Ensuring a secure SDLC requires a focus on both how the application operates and how the developers transform requirements into application code.
Security must be at the forefront of the team’s mind as the application is developed. This may require a cultural change within your teams as well as automated processes and checks at each stage of software development.
Ensuring SSDLC for an application is highly dependent on the strengths and weaknesses of the software development team that is working on SDLC security, and as such, it is challenging to pin down a single secure SDLC process.
Since secure SDLC involves changing existing processes, implementing new tools and more importantly, driving a cultural change within several teams, a path to well-functioning secure SDLC is usually unique for each organization and can even differ amongst various business units.
Secure SDLC Best Practices
Educate Your Developers:
Secure SDLC goes hand in hand with multiple related initiatives, including:
- Creating secure coding guidelines
- Providing developers with security awareness and secure coding training
- Setting clear expectations around how quickly issues discovered in production need to be addressed (also known as remediation SLAs).
Not all of these need to happen for an effective SSDLC implementation, but much like a jigsaw puzzle, you’ll need to put enough pieces together before you can see the big picture.
Have Clear Requirements
Whatever you create, it should be easy to understand. Development teams need clear requirements that are easy to act upon. This applies to all security advice, recommendations, and guidelines.
Any vulnerabilities discovered in tests need to be easy to act on. It’s key that all people, processes, and tools involved bring solutions to the table instead of just pointing out problems
Maintain a Growth Mindset
Since SSDLC will change how multiple teams work and interact, it’s important for everyone to go into this experience with an open mind, and for the security team to have the mindset of empowering developers to secure their own applications
Tie Implementation to Other Initiatives
For well-established applications and teams, it may often be easier to implement SSDLC changes when it’s tied to another modernization effort, such as a cloud transformation, a DevOps initiative, or its more security-conscious variation.
Tackle the Big Problems First
Focus on the most important issues and actionable fixes rather than addressing every vulnerability found. While it may be possible for newer or smaller applications to fix every security issue that exists, this won’t necessarily work in older and larger applications. A triage approach can also be helpful. This focuses on not only preventing security issues from making it into production, but also ensuring existing vulnerabilities are triaged and addressed over time.
SSDLC and DevSecOps
It’s important to discuss the relationship between SSDLC and DevSecOps. They are sometimes used interchangeably, which can lead to confusion.
While SSDLC and DevSecOps are closely linked, they are actually complementary practices. Both SSDLC and DevSecOps focus on empowering developers to have more ownership of their application, ensuring they are doing more than just writing and testing their code to meet functional specifications.
Secure SDLC is focused on how the application is designed and built; DevSecOps seeks to shift ownership of the production environment for each application away from traditional IT teams and into the hands of the developers. This lets developers focus on automating build, test, and release processes as much as possible.
DevOps and DevSecOps have started a revolution in redefining the role of software developers. This has of course been aided by other major changes, such as cloud transformations.
But while empowering developers and accelerating security testing are key to success for most modern organizations, it would be a mistake to view application security as just an automation challenge. Instead, it’s important to drive cultural and process changes that help raise security awareness and considerations early in the development process.
This must permeate all parts of the software development life cycle, regardless of whether one calls it SSDLC or DevSecOps.
Moving to a More Secure Future
Traditional practices of testing for vulnerabilities in production are no longer sufficient for securing your applications. As the software industry has evolved, the types of attacks have evolved as well.
Deploying and maintaining a secure application requires securing every step of the application development process. This means asking questions about security behaviors at the requirement gathering stage, adjusting team culture and practices to account for a security-oriented mindset, implementing automated verification into your deploy process, and many other practices that together create a secure SDLC process.
SSDLC allows you to shift security risks left, addressing the origin of security issues at the requirements phase instead of having to backtrack from the maintenance phase. By focusing on security at every stage of development, you can rest assured your application will be far more secure as a result.
Check List
| Check list for Training, People, BCP and Admin |
- TechM's Security Awareness Test Cleared by each team member
- Client's Security Awareness Test Cleared by each team member
- Ensure that each team member has signed Client Specific NDA and is aware of the project's Data Protection and IPR related requirements.
- Are these NDA's stored in a restricted area with the PM / PGM
- Necessary User IDs are created for each individual in the team member in client/ project development environment, as required. No User ID's to be shared
- BG Checks as per TechM and Customers requirements.
- Is clear desk / clear screen followed by the team?
- Is the team aware of the BCP/DR framework, training presentation availability in ISG portal and their role in the event of disaster?
|
- A list is maintained up to date providing information on access rights available to each team member depending on his / her role in the team.
- Appointment Configuration Manager. He will be responsible for ensuring the Confidentiality and Integrity of the Project Doc & Data by ensuring proper access rights to each team member.
- Project level Critical Resources been identified and updated in project BCP on ISG Dashboard
- Ensure that a list of active tokens available with team is maintained.
|
| Check List – (Technology) |
- Does project have any servers (development, test server etc.)? If yes, does the proper access control to server, administration of server is maintained as per Server Security Policy
- Are servers managed with Security patches, antivirus software is installed and updated regularly
- Whether VPN is been implemented as per the client requirement?
- Whether every individual has unique ID and Password to connect the Remote environment, if project needs any?
- Is there a list of approved Third-Party software available with the project, if project is planning to use any COTS or freeware’s? In case, if the software/code is not from approved 3rd party software list, is there any exception approval by Client and/or TIM-Compliance team available with PM?
- Are data backups stored offsite at the client site as required by the client?
- Is the data restoration drill conducted for project server?
|
- Does the usage of Third-Party software / code comply with Application Security policy (WAPT Report)?
- Ensure that the PM has all the evidences for compliance on licensing, for the Third-Party software being used
- VSS/ Clear Case/ any other Configuration management tool being used for the project?
- Segregation of duties been addressed in appropriate areas Ex. like access to development and production server cannot be provided to same user at the same time.
PROJECT CLOSURE
- Permanently revoking access rights on project/ client specific doc & data repositories/ files/ folders on shared drives after project closure.
- Cleaning / Formatting of Server in view of the Client confidential information on the machine.
- Submission of active tokens' back to PMO after project Closure.
|
| New Age Delivery (NAD) |
- Are you doing Agile/Devops today?
- Is there a customer defined Devops/Agile framework?
- What is the general awareness of Devops within your team? Are the teams trained on the concepts? is the project team trained on Devops tools
- Do you have the approved list of Dev Ops tools used in the project like (Maven, GIT, Jenkins, Chef, Dockers, Kubernetes etc.)?
- Have you identified single point of failure?
- Are requirements being broken down into user stories/use case equivalent.
- Are your unit test cases automated (Junit etc.)?
- is there a continuous integration plan/strategy in place?
- is the project using an IDE for development (Eclipse, Visual studio?)
- Are you using any Industry standard frameworks in your Project?
|
- Does the project use a configuration management tool (like Git, for code)
- Is the deployment process automated through tools like Jenkins and Dockers?
- is the project measuring code quality on an ongoing basis through tools like Sonar.
- Does the defects/issues/bugs from code analysis directly get logged into JIRA automatically or manual
- Is your regression pack automated and is it auto triggered once build is done?
- Are you using and security framework like (Spring Security)?
- Are you maintaining logs at in your application (Model, View and Controller level)?
- Health check done at regular intervals.
- Alert mechanism implemented for the project.
PROJECT CLOSURE
- Permanently revoking access rights on project/ client specific doc & data repositories/ files/ folders on shared drives after project closure.
- Cleaning / Formatting of Server in view of the Client confidential information on the machine.
- Submission of active tokens' back to PMO after project Closure.
|
Best Practices
| Track your asset |
Perform Thread assessment |
Stay on top of your patching |
| Manage your containers |
Prioritize Your Remediation Ops |
Encrypt Sensitive data |
| Manage Privileges |
Embrace Automation for Your Vulnerability Management |
Penetration Testing |
| Be Careful with Tokens |
|
|
Application Development Security Measures
Application security should be an essential part of developing any application in order to prevent your company and its users' sensitive information from getting into the wrong hands.
Every application becomes vulnerable as soon as it's open to the internet, but there are many ways you can protect your application and its security when your app is being developed.
-
Application authentication
- Restrict access to application directories and files
- Implement session expiration timeout
- Forbid multiple concurrent sessions
- Provide least privilege to application users
- Implement CAPTCHA and email verification system
- Use encryption algorithms that meet data security requirements
- Cross Site Scripting (XSS)
- Command Injection Flaws
- Data and Input Validation
- Auto Backup
- Alert Mechanism in case of System failure
- Error Handling
- Segregating PI/SPI data from application data
- Logging
- Avoid vulnerable API or function calls
- Run security audit on source codes
- Conduct web application vulnerability scan
- Conduct penetration test
- Remote Administration
- Web Application and Server Configuration
- Implement privacy principal’s functionality like consent, right to delete, data portability etc.) by default
Consider utilizing a two-factor authentication, so users would need to not only enter a password, but also to enter a code sent to the phone number or email that's attached to their account to get in.
This means that if someone is trying to break into your user's account, they won’t be able to even if they're able to guess the password.
Ensure that no one except administrative users have access to application's directories and files.
Normal session timeouts range between 2-5 minutes for high-risk applications and between 15-30 minutes for low-risk applications.
Avoid having multiple concurrent session in the application for security reasons. There are many ways to do this a simple approach might be:
1. Set one flag at the time of login into database
2. Check flag every time when you are sign in
3. Remove flag at time of logout
All users should only have access to what they absolutely need and no more than that. Create a separate admin module to manage privilege access management.
Implement Captcha and email verification systems.
1. Captcha make sure its actual people submitting forms and not scripts.
2. Email verification makes sure that the email address that was entered exists and is working.
Depending on what your organization's data security requirements call for, you might want to consider using a data encryption algorithm.
Also consider data encryption during
- Data at rest (corporate files, backup data storage)
- Data in motion (email attachments, FTP sites)
- Data in use (Database applications)
Development Project Use Case (Ex. Java/J2EE Technology)
- To ensure that application security is no longer an afterthought but a foremost one.
- To lay the foundation required by all application developers and development organizations, to produce secure applications with greater stability and fewer security risks to the consumer, therefore, making security a foremost thought.
- To ensure that the organizations mitigate the risk of losing millions due to security compromises that may arise with every step of application development process.
- To help individuals develop the habit of giving importance to security sacrosanct of their job role in the SDLC, therefore opening security as the main domain for testers, developers, network administrator etc.
| Domain |
Objective / Sub Domain |
Weightage |
| Understanding Application Security, Threats and Attacks |
- Understand the need and benefits of application Security.
- Demonstrate the understanding of common application-level attacks
- Explain the causes of application level vulnerabilities.
- Explain the components of comprehensive application security
- Explain the advantages of integrating security in SDLC
- Differentiate functional and security activities in SDLC
- Demonstrate the understanding of various software security reference standards, models, and frameworks.
|
18% |
| Security Requirement Gathering |
- Understand the importance of gathering security requirements.
- Understand security use case model (Square Model, Octave Model)
|
8% |
| Secure application design and architecture. |
- Understand the importance of secure application design.
- Explain various secure design principals.
- Demonstrate the understanding of Threat modeling.
- Demonstrate the understanding of Secure Application Architecture Design.
|
12% |
| Secure Coding Practice for Input Validation. |
- Understand the need of input validations
- Explain data validation techniques.
- Explain validation framework like Struts and Spring.
- Demonstrate the knowledge of common secure coding practices for input validations.
|
8% |
| Secure coding practices for Authentication and Authorization |
- Understand authentication concepts.
- Explain how authentication implementation in Java.
- Understand authorization concepts.
- Explain access control model
- Explain EJB (Enterprise java beans) authorization.
- Explain JAAS (Java Authorization and Authorization)
- Any industry standard Authorization and Authorization framework like Spring Security.
|
|
| Secure coding practices for Cryptography |
- Understand fundamentals concept and need of cryptography in Java.
- Explain encryption and secret keys
- Demonstrate the knowledge of cipher class implementation.
- Demonstrate the knowledge of Digital Signature and its implementation.
- Demonstrate the knowledge of Secure Socket Layer (SSL) and its implementation.
- Explain secure key management.
- Demonstrate the knowledge of digital certificate and its implementation.
- Demonstrate the knowledge of Hash implementation
- Explain Java Card Cryptography.
- Explain Crypto Module in Spring Security.
|
6% |
| Secure coding practices for Session Management |
- Explain Session Management
- Demonstrate the knowledge of session management in Spring framework.
- Demonstrate the knowledge of best practices and guidelines for secure session management.
|
10% |
| Secure coding practices for Error Handling |
- Explain Exception and Error Handling in Java
- Explain Erroneous exceptional behavior
- Explain Spring MVC error handling
- Explain Exception Handling in Struts2
- Demonstrate the knowledge of Log4J for logging.
- Demonstrate the knowledge secured logging
|
10% |
| Static and Dynamic Application Security Testing (SAST and DAST) |
- Understand Static Application Security Testing (SAST)
- Explain Dynamic application security testing
- Demonstrate the knowledge of Automated application Vulnerability scanning tools for DAST.
- Demonstrate the knowledge of Proxy-based Security Testing Tools for DAST.
|
8% |
| Secure Development and Maintenance |
- Understand the importance of secure deployment
- Explain security practices at Host Level.
- Explain security practices at Network Level.
- Explain security practices at Application Level.
- Explain security practices at Web container level (Tomcat Server)
- Explain security practices at Database Level.
- Demonstrate the knowledge of Security maintenance and monitoring activities.
|
10% |
Check list for Developers and Testers
| Have you identified if the application is capturing an PI/SPI Data | Development/Testing |
| Are you using any production data in test environment | Testing |
| If Yes? Is the data deleted after use? | Testing |
| Specify if the project has minimized the Personal data usage | Development/Testing |
| Is the privacy awareness among project team conducted? | Development/Testing |
| Have you checked if the session expiration timeout implemented to avoid allowing multiple concurrent sessions | Development/Testing |
| Have you tested if the application development and test environment is segregated from the production environment. | Development/Testing |
| Is 2FA implemented while designing the application | Development/Testing |
| Have you implemented a CAPTCHA and email verification system if you allow your users to create account with your application? | Development/Testing |
| Always conduct a proper WAPT before moving your application from the Test environment to the production environment | Testing |
| Is the Data encryption implemented for Sensitive Data | Development/Testing |
| Check if the project has done PII/Personal data pseudonymization | Development/Testing |
| Check if the project has done PII/Personal data Anonymization | Development/Testing |
| Have you tested if Cookies implemented according the best practices of your application development platform | Development/Testing |
| Have you implemented Privilege access control to the application users? | Development/Testing |
| Have you tested if the application is Capturing Logs | Development/Testing |
| Check whether the sensitive data is masked in the log files | Development/Testing |
| Check whether the sensitive data is encrypted while storing in the data base | Development/Testing |
| Is the Authentication and Authorization implemented while logging into the application? | Development/Testing |
| Do you utilize / provide any PI / SPI data in the form of Web Services (XML or JSON)?If Yes? Is the data encrypted while in transit? | Development/Testing |
| If you are relying on consent to process personal data, do you have mechanism to validate the authenticity of the consent? | Development/Testing |
| Have you tested if the application data and Sensitive data is segregated? | Development/Testing |
| Have you tested if there is proper backup measures taken for Sensitive data | Development/Testing |
| Have you verified if the project has identified the data flow of PII/Personal data | Development/Testing |
| Have you tested whether the personal data/PII used in the project is secured end to end | Testing |