Key considerations for SSDLC

The software development life cycle (SDLC) framework maps the entire development process. It includes all stages—planning, design, build, release, maintenance, and updates, as well as the replacement and retirement of the application when the need arises.

Vs

The secure SDLC (SSDLC) builds on this process by incorporating security in all stages of the lifecycle. Teams often implement an SSDLC when transitioning to DevSecOps. The process involves applying security best practices alongside functional aspects of development, and securing the development environment. In SSDLC, security tasks is added to each SDLC activity, Each task has a clear owner and a clear checklist.

Key principles for creating secure code

• Need for an organizational commitment starting with executive-level support, clear business and functional requirements
• Comprehensive secure software development lifecycle that is applicable throughout the product's lifecycle and incorporates training of development personnel.

Security Check List

“Before anything else, preparation is the key to success”.

The prime preparation task for a software solution project is planning and security consideration is integrated part of it:

• Identify relevant internal security architecture guidelines
• Prepare threats model and identify security risks
• Identify encryption, tokenization, and data masking requirements
• Identify authentication and authorization requirements: internal and external users, internal and external 3rd party APIs, server-to-server, service-to-service, etc.
• Identify secrets management requirements
• Classify app data — PI (Personal Info), SPI (Sensitive PI), PCI (credit cards), SOX (Sarbanes–Oxley Act), etc.
• Identify records retention, deletion and archiving requirements
• Identify security logging and monitoring requirements
• Identify relevant internal and external regulations such as PCI, SPI, SOX, GDPR (General Data Protection Regulation), CCPA (California Consumer Privacy Act), etc.

Secure Design Principles?

As organizations strive to develop high-quality software while maintaining the confidentiality, integrity, and availability of sensitive data, it's crucial to incorporate security into every stage of the software development life and below secure design principles as part of architecture and design of software:

• Economy of mechanism: keep the design of the system as simple and small as possible
• Fail-safe defaults: base access decisions on permission (a user is explicitly allowed access to a resource) rather than exclusion (a user is explicitly denied access to a resource).?
• Complete mediation: every access to every object must be checked for authorization.?
• Least privilege: every program and every user of the system should operate using the least set of privileges necessary to complete the job.?
• Least common mechanism: minimize the amount of mechanism common to more than one user and depended on by all users.?
• Psychological acceptability: it is essential that the human interface be designed for ease of use, so that users routinely and automatically apply the protection mechanisms correctly.?
• Compromise recording: it is sometimes suggested that mechanisms that reliably record that a compromise of information has occurred can be used in place of more elaborate mechanisms that completely prevent loss
• Defense in depth: design the system so that it can resist attack even if a single security vulnerability is discovered or a single security feature is bypassed. Defense in depth may involve including multiple levels of security mechanisms or designing a system so that it crashes rather than allowing an attacker to gain complete control.?
• Fail securely: a counterpoint to defense in depth is that a system should be designed to remain secure even if it encounters an error or crashes.?
• Design for updating: no system is likely to remain free from security vulnerabilities forever, so developers should plan for the safe and reliable installation of security updates.

Perform Architectural and Design Reviews?

• Architectural and design review should be incorporated into a security program.
• A poorly designed system that allows a malicious actor to fully compromise a system and its data through a design or logic?flaw can be catastrophic and difficult to remediate.

Secure Coding Practices?

When developers write software, they can make mistakes. These mistakes can have significant consequences:

• Left undetected, these mistakes can lead to unintentional vulnerabilities that potentially compromise.
• A goal of developing secure software is to minimize the number of these unintentional code-level security vulnerabilities.
• This can be achieved by defining coding standards, selecting the most appropriate (and safe) languages, frameworks and libraries, ensuring their proper use (especially use of their security features), using automated analysis tools and manually reviewing the code.?

Establish Coding Standards and Conventions?

• When technology choices are made, it is important to understand which classes of security issues are inherited and to decide how they will be addressed.
• Once these technology decisions are made, appropriate coding standards and conventions that support both writing secure code and the re-use of built-in security features and capabilities should be created, maintained and communicated to the development team.?
• Use built-in security features in the frameworks and tools selected and ensure that these are on by default. Where multiple options exist to address issues, choose one as the standard.
• Look for classes of security issues that a security feature, programming language or framework may mitigate on the developer's behalf and invest in the re-use of such features or frameworks instead of re-inventing them in-house.
• To the greatest possible extent, any frameworks/library/component use should be loosely coupled so that it can be easily replaced/upgraded when needed
• Developers should be provided guidance on what functions to avoid and their safe equivalents within the coding standards described in the preceding section.
• Static analysis and linting tools provide a mechanism to identify usage during build time, and some integrate into IDEs (Integrated Development Environments) to provide authoring time guidance to developers as they write code.
• Enable secure compiler options and do not disable secure defaults for the sake of performance or backwards compatibility. These protections are defenses against common classes of vulnerabilities and represent a minimum standard.?
• All user-originated input should be treated as untrusted.
• The origin of data is often not clearly defined or understood, and applications can consume and process data that originates from the Internet or other network, through a file, from another application via some form of inter-process communication or other data channel.
• Good approach is to ensure that each area in the application?stack defends itself against the malicious input it may be vulnerable to. For example, parameterized queries can be used for database access to help prevent SQL injection attacks. A good threat model will help identify the boundaries and the threats.?

Handle Errors?

• Key feature of any application is to handle and react to unanticipated errors in a controlled and graceful way, and either recover or present an error message.
• While anticipated errors may be handled and validated with specific exception handlers or error checks, it is necessary to use generic error handlers or exception handlers to cover unanticipated errors.
• Error handling should be integrated into the logging approach, and ideally different levels of detailed information should be provided to users as error messages and to administrators in log files.?

Third-party Components?

• To innovate and deliver more value in shorter time periods, developers increasingly use third-party frameworks and libraries.
• These can be commercial off-the-shelf-products (COTS) or increasingly, these can come from open source software (OSS) projects. In either case, there is inherent security risk in the use of third-party components (TPCs) and these risks must be investigated and evaluated before use.

Security Testing

Security testing is a useful tool to identify existing weaknesses in the product or service and serve as a compass to guide initial security investments and efforts, or to help inform a decision on whether or not to use third-party components.

• As in other areas of development, automated security testing allows for repeatable tests done rapidly and at scale.
• These tools can be run either on developers' workstations as they work, as part of a build process on a build server or run against the developed product to spot certain types of vulnerabilities:

- Static Analysis Security Testing (SAST)

- Dynamic Analysis Security Testing (DAST)

- Fuzzing

- Software Composition Analysis (SCA)

- Network Vulnerability Scanning and Tooling

Manage Security Findings

• Threat modeling, third-party component identification, SAST, DAST, penetration testing, etc. all result in artifacts that contain findings related to the product’s security
• The findings from these artifacts must be tracked and action taken to remediate, mitigate or accept the respective risk. For a finding to be remediated, the risk is completely eliminated, and to be mitigated, the risk is reduced but not completely eliminated.
• When the issue cannot be completely remediated, an assessment must be performed to determine whether the residual risk is acceptable. Once the residual risk is understood, a decision must be made whether the risk is acceptable, whether additional mitigations are required, or whether the issue must be fully remediated.?

Define Severity?

• Implementing a severity scale (e.g., Critical, High, Medium and Low or a finer grained scale, Very High, High, Medium, Low, Very Low, Informational), and next define the criteria that contribute to each severity category.
• Common Vulnerability Scoring System (CVSS) thresholds (e.g., 10-8.5 = Critical, 8.4-7.0 = High, etc.). CVSS is primarily used for confirmed vulnerabilities but can also be used to prioritize SDL findings based on their complexity of exploitation and impact on the security properties of a system.

So, these are the key considerations for Secure Software Development Life Cycle. Secure software can be created by adding security checks at each stage of software development and following the secure design practices. Besides this, security is not just the job of information security teams but collaboration between different team where major contributor and driver is development team.