Building Secure Software - Integrating Security in Every Phase of the SDLC

The software development lifecycle (SDLC) is a process for planning, designing, building deploying and maintaining software systems that has been around in one form or another for the better part of the last 6 decades. While the phases of SDLC executed in sequential order seem to describe the waterfall software development process, it is important to realize that waterfall, agile, DevOps, lean, iterative, and spiral are all SDLC methodologies. SDLC methodologies might differ in what the phases are named, which phases are included, or the order in which they are executed.

A common problem in software development is that security related activities are left out or deferred until the final testing phase, which is too late in the SDLC after most of the critical design and implementation has been completed. Besides, the security checks performed during the testing phase can be superficial, limited to scanning and penetration testing, which might not reveal more complex security issues. By adopting shift left principle, teams are able to detect and fix security flaws early on, save money that would otherwise be spent on a costly rework, and have a better chance of avoiding delays going into production.

Integrating security into SDLC should look like weaving rather than stacking. There is no “security phase,” but rather a set of best practices and tools that should be included within the existing phases of the SDLC. A Secure SDLC requires adding security review and testing at each software development stage, from design, to development, to deployment and beyond. From initial planning to deployment and maintenance, embedding security practices ensures the creation of robust and resilient software. A Secure SDLC not only helps in identifying potential vulnerabilities early but also reduces the cost and effort required to fix security flaws later in the development process. Despite the perceived overhead that security efforts add to, the impact from the security incident could be far more devastating than the effort of getting it right the first time around. 

1. Planning

The planning phase sets the foundation for secure software development. During this phase, it’s essential to clearly establish the security strategy and objectives and develop a security plan, which shall be part and parcel of the product or project management plan. While doing so, it is important to take into account the contractual obligations with the client, regulatory requirements as may be relevant and applicable for the functional domain and the country and region where the product or project is likely to be executed and deployed. It is also important to define and document appropriate security policies as relevant to the project / product.  The established Security strategies, objectives and the related implementation plan shall be diseminated to all stakeholders, so that they are aware of their roles and responsibilities in meeting the objectives and achieving these goals.

2. Requirements

In the requirements phase, security requirements should be explicitly defined and documented. Collaborate with stakeholders to understand the security needs of the application. Identify compliance requirements and industry standards that must be adhered to. Incorporate security considerations into functional and non-functional requirements. Ensure that security requirements are clear, measurable, and testable.

Security requirement gathering is a critical part of this phase. Without this effort, the design and implementation phases will be based on unstated choices, which can lead to security gaps. You might need to change the implementation later to accommodate security, which can be expensive.

During this phase, the Business Analysts shall gather relevant security requirements various sources and such requirements are of the following types:

• Security Drivers: The security drivers determine the security needs as per the industry standards, thereby shaping security requirements for the given software project or product. The drivers for security requirements include regulatory compliance like SarbanesOxley, Health Insurance Portability and Accountability Act (HIPAA),  PCI DSS, Data Protection Regulaations etc.; industry regulations and standards like ISO, OASIS etc.; company policies like privacy policies, coding standards, patching policies, data classification policies etc.; and security features like authentication and authorization model, role-based access control, and administrative interfaces etc. The policies when transformed to detailed requirements demonstrate the security requirements. By using the drivers, managers can determine the security requirements necessary for the project. 
• Functional Security Requirements (FSR): FSRs are the requirements that focus on the given product or project. The requirements for the FSRs can be gathered from the customers and end users. This may also contain security requirements as derived from the Security Drivers. These requirements are normally gathered by means of misuse cases which capture requirements in negative sense, like what should not happen or what should not be permitted. To ensure that the FSR is fully gathered, it is essential that the involved Business Analysts shall have the requisite level of exposure in Security related aspects or shall collaborate with Security Analysts.

3. Design

The design phase is where the Architects document the technical aspects of the software. This is a critical phase for incorporating security aspects with technical and implementation details into the software architecture. In this phase, the Architects shall consider the Drivers and FSRs documented in the Software Requirements Specification as documented in the previous phase. The following are some of the Non Functional security requirements that the Architects shall take into account while designing the Software Architecture.

• The Security dimension: The Architects shall Identify and document the security controls to be considered for protecting the system and interfaces exposed for third parties. For example, component / module segmentation strategy, the types of identities (both human and non-human) needed, authentication and authorization scheme, and the encryption methods to protect data, etc. 
• Shared Responsibilities: It's important to understand and take into account the shared responsibility model of the cloud service provider or such other infrastructure service provider. It will be unnecessary to implement security controls within the system where the service provider has accepted the responsibility. However, it would be appropriate to factor aa conditional compensating controls, so that in the event of any breach on the service provider end, the compensating control could kick-in.
• System Dependencies: Clearly identify the third party or open source components or services to be used after evaluating the security risks associated with such components and services. If appropriate consider factoring additional security controls to compensate any known risks exposed by such components / services.
• Security Design Patterns: Design Patterns offer solutions for standard security concerns like segmentation and isolation, strong authorization, uniform application security, and modern protocols. The Architect shall explicitly call out the relevant and appropriate design patterns to be used by the development teams.

4. Development

During the development phase, secure coding practices are paramount. Educate developers on secure coding techniques and provide them with tools and resources to write secure code. The Developers shall be required to use static code analysis tools to identify and remediate security issues early in the development process. The developers shall have the mindset to expect the unexpected, so that all current and future scenarios are considered while building the software.

The following are some of the common practices that the developers shall adhere to while building the software:

• Input Validation: One of the most common entry points for attackers is through improperly validated inputs. Ensure that all user inputs are thoroughly validated and sanitized. Implement strong input validation techniques to prevent injection attacks, such as SQL injection and cross-site scripting (XSS). It is common that there would be multiple entry points for receiving inputs (e.g. web and mobile user interfaces, APIs, uploads, etc), in which case, the validation and sanitization shall be implemented in all such entry points. 
• Write just enough code: When you reduce your code footprint, you also reduce the chances of security defects. Reuse code and libraries that are already in use and have been through security validations instead of duplicating code.
• Use Parameterized Queries: SQL injection attacks can be devastating, allowing attackers to execute arbitrary SQL code. To prevent this, always use parameterized queries or prepared statements when interacting with databases. This approach ensures that user inputs are treated as data, not executable code.
• Implement Authentication and Authorization: Authentication verifies the identity of users, while authorization determines their access levels. Use strong authentication mechanisms, such as multi-factor authentication (MFA), and implement role-based access control (RBAC) to ensure that users only have access to the resources they need.
• Deny-all approach by default: Create allowlists only for entities that need access. For example, if you have code that needs to determine whether a privileged operation should be allowed, you should write it so that the deny outcome is the default case and the allow outcome occurs only when specifically permitted by code.
• Encrypt Sensitive Data: Encryption is a critical component of secure coding. Encrypt sensitive data both at rest and in transit to protect it from unauthorized access. Use industry-standard encryption algorithms and ensure proper key management practices. With the quantum computing getting closer to commercial adoption, it is time to consider quantum safe encryption methods.
• Secure Session Management: Session hijacking can compromise user accounts. Implement secure session management practices, such as generating unique session IDs, using HTTPS, and setting appropriate session timeouts. Ensure that session tokens are securely stored and transmitted.
• Regularly Update and Patch Dependencies: Outdated libraries and dependencies can introduce vulnerabilities into your software. Regularly update and patch third-party libraries and components to ensure that known security flaws are addressed promptly.
• Implement Error Handling and Logging: Proper error handling and logging are crucial for identifying and mitigating security issues. Avoid exposing sensitive information in error messages. Use logging to track suspicious activities and potential security breaches.
• Conduct Code Reviews: Peer code reviews are essential steps in the development process. Conduct regular code reviews to identify potential security issues. Use automated tools for static and dynamic analysis to uncover vulnerabilities.

5. Testing

The testing phase of the SDLC typically happens after all new code has been written, compiled and the application is deployed in a test environment. This is another opportunity to perform tests in near production environment, even if earlier testing of source code already happened. The testing phase is where security vulnerabilities are identified and addressed. While there exist tools for performing securit testing, the human testers are required to be aware of various security scenarios and accordingly align their test strategy, choice of tools, the level of coverage, etc. Following are some of the widely practiced security testing methods, besides manual functional testing:

• Static Application Security Testing (SAST): SAST is a software testing method that analyzes an application's source code for vulnerabilities. It's also known as static analysis or white box testing. SAST analyzes an application's source code, byte code, and binaries. SAST can help identify vulnerabilities such as buffer overflows, SQL injection, and cross-site scripting (XSS). SAST is a white-box testing method that looks for vulnerabilities inside the application.
• Dynamic Application Security Testing (DAST): DAST is a black-box testing method that analyzes web applications for vulnerabilities by simulating attacks. DAST tests running applications in real-time to find security flaws. DAST evaluates applications from the "outside in". DAST tests for critical threats like cross-site scripting (XSS), SQL injection (SQLi), and cross-site request forgery (CSRF).
• Penetration Testing: A penetration test, also known as a pen test, is a simulated cyber attack against your application to check for exploitable vulnerabilities. The goal is to determine if the application is secure and can withstand potential attacks.
• Fuzz Testing: Fuzz testing is a software testing method that uses automated tools to identify bugs and vulnerabilities in web applications by feeding unexpected or invalid data to see how the application behaves or responds. The goal is to induce unexpected behavior, such as crashes or memory leaks, and see if it leads to an exploitable bug. Fuzz testing can uncover a wide range of vulnerabilities, including those that may not be detected through other testing methods.

6. Deployment

Securing the deployment phase of the Software Development Lifecycle (SDLC) involves ensuring that the software is ready for use and configured securely. This includes implementing access controls to protect the environment used for build and deployment, monitoring for vulnerabilities, and responding to security incidents. The following are some of the best practices to be practiced:

• Environment Hardening: Secure the deployment environment by disabling unnecessary services and applying security patches. Build agents are highly privileged and have access to the build server and the code. They must be protected with the same rigor as the workload components. This means that access to build agents must be authenticated and authorized, they should be network-segmented with firewall controls, they should be subject to vulnerability scanning, and so on.
• Secure the Source Code Repository: The source code repository must be safeguarded as well. Grant access to code repositories on a need-to-know basis and reduce exposure of vulnerabilities as much as possible to avoid attacks. Have a thorough process to review code for security vulnerabilities. Use security groups for that purpose, and implement an approval process that's based on business justifications.
• Protect the deployment pipelines: It's not enough to just secure code. If it runs in exploitable pipelines, all security efforts are futile and incomplete. Build and release environments must also be protected because you want to prevent bad actors from running malicious code in your pipeline.
• Up-to-date Software Bill of Materials (SBOM): Every component that's integrated into an application adds to the attack surface. Ensure that only evaluated and approved components are used within the application. On a regular basis, check that your manifest matches what's in your build process. Doing so helps ensure that no new components that contain back doors or other malware are added unexpectedly.

7. Maintenance

Security does not end with deployment; it is an ongoing process. During the maintenance phase, continuously monitor the application for security threats and vulnerabilities. Apply security patches and updates promptly. Conduct regular security audits and reviews to ensure compliance with security policies and standards. Educate users on security best practices and respond to security incidents swiftly.

Conclusion

Building secure software requires a holistic approach that integrates security into every phase of the SDLC. By adopting these best practices, organizations can create resilient applications that protect sensitive data and withstand cyber threats. Remember, security is a continuous journey, and staying vigilant is key to maintaining a secure software environment.

Managing Third-Party Risks in the Software Supply Chain

Supply chain attacks might leverage multiple attack techniques. Specialized anomaly detection technologies, including endpoint detection and response, network detection and response and user behavior analytics can complement the broader scope covered by security analytics on centralized log management/SIEM tools. 

The software supply chain encompasses many entities involved in the development, production and distribution of IT products and services, including hardware manufacturers, software developers, cloud service providers and even the vendors used by direct suppliers (fourth parties). Organizations rely on numerous third-party vendors and service providers to build, deploy, and maintain their software systems. While this interconnectedness brings numerous benefits, it also introduces significant risks that can have far-reaching consequences. 

The myriad of third party risks such as, compromised or faulty software updates, insecure hardware or software components and insufficient security practices, expand the attack surface of the organization. A security breach in one such third party entity can ripple through and potentially lead to significant operational disruptions, financial losses and reputational damage to the organization.

In view of this, securing not just their own organizations, but also the intricate web of suppliers, vendors and partners that make up their cyber supply chain is not just an option, but a necessity. It is needless to state that managing the third party risks is becoming a big challenge for the Chief Information Security Officers. More to it, it may not just be enough to maanage third-party risks but also fourth party risks as well. Aligning third-party vendors with business objectives is a critical supply chain security priority.

Understanding Third-Party Risks

Third-party risks are potential threats that originate from outside vendors, suppliers, or service providers that an organization relies on. Third-party risk involves the direct suppliers and vendors an organization engages with for products and services used in the software supply chain. These entities often have privileged access to sensitive data, making them prime targets. Fourth-party risk extends further to include the vendors and service providers that the third party rely on to deliver the products or services. This indirect relationship can obscure visibility into potential vulnerabilities, posing challenges for organizations in managing these risks.

These risks can include data breaches, service disruptions, and noncompliance with regulations. The common types include:

• Operational Risks: The risk of a third-party causing disruption to the business operations. This is typically managed through contractually bound service level agreements (SLAs) and business continuity and incident response plans.  Depending on the criticality of the vendor, you may opt to have a backup vendor in place, which is common practice in the financial services industry.
• Cybersecurity Risks: The risk of exposure or loss resulting from a cyberattack, security breach, or other security incidents. Cybersecurity risk is often mitigated via a due diligence process before onboarding a vendor and continuous monitoring throughout the vendor lifecycle.
• Compliance Risks: The risk of a third-party impacting your compliance with local legislation, regulation, or agreements. This is particularly important for financial services, healthcare, government organizations, and business partners. 
• Financial Risks: The risk that a third party will have a detrimental impact on the financial success of your organization. For example, your organization may be unable to sell a new product due to poor supply chain management.
• Reputational risk: The risk of negative public opinion due to a third party. Dissatisfied customers, inappropriate interactions, and poor recommendations are only the tip of the iceberg. The most damaging events are third-party data breaches resulting from poor data security, like Target's 2013 data breach.

Best Practices for Managing Third-Party Risks

Effectively managing third-party risks involves a proactive approach that includes the following best practices:

1. Identify and Classify Third-Party Vendors

First, identify all third-parties who play  role in the software supply chain and classify them based on their criticality of the components and services that are sourced from them . It would be also be importnt to consider the criticality of the system for which such components or services are consumed for. Like most risk mitigation plans, a sound strategy involves categorizing the threats by priority. In terms of third parties, the goal is to determine which third-party relationship is riskiest. This helps prioritize risk management efforts by planning and allocating necessary resources.

2. Conduct Thorough Due Diligence

As  next step, conduct a comprehensive due diligence to assess the security posture, financial stability, compliance with regulatory requirements, and overall reliability of the third-parties. This process should include reviewing their security policies, secure coding practices, supply chain risk management plans, previous incident reports, and financial statements. Based on the assessment, either require the third-party to implement necessary policies, processes and controls or put in place appropriate compensating controls to keep the risk under control. Besides, the duediligence shall be conducted in periodic intervals or upon happening of any event or incident impacting the components or services consumed.

3. Establish Clear Contracts and SLAs

Another important step is to ensure that contracts and Service Level Agreements (SLAs) are executed with the third parties and the contract should clearly contain clauses detailing the expectations, responsibilities, indemnities, and penalties. Such contracts should cover aspects such as data security, incident response, confidentiality, and applicable regulatory compliance. The entity shall also be required to report or notify significant security incidents within reasonable time, so that appropriate action as may be necessary to prevent the cascading impact of such incident can be taken.

Mapping your most critical third-party relationships can identify weak links across your extended enterprise. But to be effective, it needs to go beyond third parties. In many cases, risks are often buried within complex subcontracting arrangements and other relationships, within both your supply chain and vendor partnerships. Illuminating your extended network to see beyond third parties is critical to assessing, mitigating and monitoring the risks posed by sub-tier suppliers.

Furthermore, it’s recommended that companies include a “right-to-audit” clause in any contract. This enables the hiring entity to conduct an audit on the third party, checking to see if signed contract is actually being followed. Such a clause also allows companies to assess whether new clauses need to be added to the contract in the future.

4. Monitor and Assess Continuously

Continuous monitoring of third-party vendors is essential to ensure ongoing compliance and risk management. This involves regular audits, assessments, and reviews of the vendor's performance, security practices, and financial health. Besides, after analyzing your organization’s relationships with vendors and suppliers and grouping them based on their risk level, the risk management strategy should be reviewed and revised to make it more efficient. Properly managing supplier risks is essential for interconnected businesses and helps address cybersecurity vulnerabilities throughout the supply chain ecosystem.

Third-party management isn’t just about monitoring for cybersecurity weaknesses and providing compliance advisory services of third parties, although such concerns are important. Third-party risk management includes a whole host of other aspects such as ethical business practices, corruption, environmental impact, and safety procedures to name a few. How third parties operate can directly impact the reputation of the company hiring them.

5. Implement a Third-Party Risk Management (TPRM) Program

Develop and implement a comprehensive third-party risk management program that includes policies, procedures, and tools to manage and mitigate risks. This program should be integrated with the organization's overall risk management strategy and updated regularly to address emerging threats and vulnerabilities. A well-designed third party risk management program framework provides a win-win situation. It helps in predicting third-party risks and high-risk vendors prior to risk assessment. The risk management planning framework saves time and provides insightful risk assessment.

Effective TPRM requires expertise in information security, privacy, sanctions, ESG and other specialized fields. While some businesses have this expertise in-house, many organizations gain these capabilities and add capacity to their risk management function through outsourcing.

6. Foster Strong Relationships and Communication

Suppliers who feel valued are more likely to work with you to solve problems, share information, and adapt to changes. This can lead to a more resilient supply chain. Communication between stakeholders and external suppliers can improve the process by bringing more creative ideas to the table. By fostering open communication and transparency, you can create a foundation of trust that enables better information sharing and risk management. Regular meetings, feedback sessions, and open channels of communication can help address issues promptly and improve overall risk management.

7. Prepare for Incident Response

In an ideal world, a well-defined supply chain incident response plan, complete with well-tested procedures, SBOMs, and comprehensive software inventories would be in place. However, reality often catches us off-guard. Despite best efforts, incidents may still occur. This is where timely notification of the incidents by the third-party is essential. The incident response plan should include steps for notifying affected parties, containing the incident, and conducting post-incident analysis.

Conclusion

Managing third-party risks in the software supply chain is a critical aspect of modern business operations. By adopting these best practices, organizations can safeguard their operations, maintain regulatory compliance, and build resilient partnerships with their third-party vendors. In an era where cyber threats are ever-evolving, proactive risk management is the key to staying ahead.

While companies can implement a wide range of strategies to manage third-party risks, there’s no guarantee of safety from breaches. Therefore, it’s important to stay vigilant, as third-party risks are now at the forefront of organizational threats.

The Perils of Security Debt: Serious Pitfalls to Avoid

In today's fast-paced digital world with ever evolving cyber threats, businesses face an increasing number of cyber security incidents. As organizations strive to remain agile and competitive, there’s often a tendency to prioritize speed and innovation over security. This can lead to what's known as "security debt"—the accumulation of risks and vulnerabilities that are neglected in the race to deploy new features or systems quickly. For Boards and C-suite executives, understanding the perils of security debt is crucial to ensuring the long-term health and safety of their organizations. Here’s a deep dive into why security debt is risky and how it can be managed effectively.

Defining Security Debt

In some ways, security and technical debt are similar: If you don’t pay the debt off, you’ll end up paying just interest without getting to the principal. But security debt doesn’t just “impede future development” of a project. Instead, an accumulating pile of vulnerabilities puts your organization at a much greater risk of malicious cyber exploits. Just as financial debt accrues interest over time, security debt can accumulate increased risks, leading to significant consequences if not addressed promptly.

Security debt is caused by a failure to “build security in” to software from the design to deployment as part of the SDLC. Security debt accumulates when a development organization releases software with known issues, deferring the redressal of its weaknesses and vulnerabilities. Sometimes the organization skips certain test cases or scenarios in pursuit of faster deployment and in the process failing to test software thoroughly. Sometimes the business decides that the pressure to finish a project is so great that it makes more sense to release now and fix issues later. Later is better than never, but when “later” never arrives, existing security debt becomes worse.

Consequences of Security Debt

1. Increased Vulnerability to Attacks: Neglecting security measures can leave your systems exposed to cyber-attacks like data breaches, ransomware, and insider threats. It broadens the attack surface and thus increasing the likelihood of cyber attacks. It is needless to stress that such attacks can result in loss of sensitive data, financial damage, and reputational harm.

2. Regulatory Non-Compliance: If your organization bypasses security protocols, you might find yourself on the wrong side of compliance regulations such as GDPR, HIPAA, or CCPA or such other applicable regulations. Any compromise on non-compliance such regulatory requirmenets can result in hefty fines and legal repercussions including impact on brand reputation.

3. Higher Remediation Costs: Like in case defects, fixing defects early in the lifecycle of the software would be a lot cheaper. Also, the longer security debt goes unpaid, the software complexity would increase, makint it harder and more expensive to address it. Fixing vulnerabilities retroactively often requires more resources than if they had been managed proactively. This holds good for process related gaps as well.

4. Erosion of Customer Trust: Customers are increasingly aware of privacy and security issues. A security breach not only impacts operations but also damages customer trust and loyalty, which can be difficult to rebuild.

5. Decreased Resilience: The more debt an organization carries, the less resilient it becomes to new threats. New vulnerabilities continue to emerge, and if an organization is already burdened with significant security debt, it will struggle to keep up with the evolving threat landscape.

Strategies to Manage and Mitigate Security Debt

1. Assess and Track Security Debt: Assessing an organization's in-depth security situation is the first step toward paying off security debt. Organizations should locate and record and track any security gaps, weak points, and vulnerabilities in their networks, systems, and applications. Such known security gaps shall be managed as a risk.

2. Incorporate Security into Design & Development Cycles: Emphasize a DevSecOps approach where security is integrated into every phase of development. Integrate automated vulnerability scanning and penetration testing into your workflow to identify and address potential security flaws early in the SDLC. Regular security assessments and automated testing can catch vulnerabilities early in the cycle. Make Security as a business priority, so that security gaps are not compromised in favour of other business priorities. 

3. Prioritize Risk Assessments: Conduct regular and thorough risk assessments to identify and rank potential threats. This helps in directing resources towards the most pressing security concerns. This way, the accumulated security debt can be kept under check.

4. Collaborate with External Security Experts: Organizations may find it advantageous to work with outside security specialists or consultants to address challenging security problems and pay off security debt in certain situations. Penetration testers, security reviewers, and external security assessors can offer insightful analysis and helpful suggestions for strengthening safeguards and resolving vulnerabilities.

5. Invest in Continuous Monitoring: Implement continuous security monitoring tools to detect and address vulnerabilities in real-time. This proactive approach minimizes the potential for unaddressed issues to evolve into major threats.

6. Foster a Security Culture: Encourage a company-wide security mindset. Educate employees at all levels about the importance of security practices and provide regular training to keep security at the forefront of everyone’s mind. Foster an environment where team members feel comfortable reporting potential security issues without fear of retribution. Transparency is key to addressing vulnerabilities effectively.

7. Allocate Budget for Security Improvements: Ensure that your organization allocates sufficient budget for ongoing security initiatives. Recognize that investing in security today can save substantial costs and risks in the future. Invest in regular and periodic training so that the employees stay updated with the latest security trends and threats. Knowledge is the first line of defense.

Leadership's Role in Addressing Security Debt

Great leadership is the beacon that not only charts the course but also ensures your crew – your IT team, support staff, and engineers – are well-prepared to face the challenges ahead. It instills discipline, vigilance, and a culture of security that can withstand the fiercest digital storms.

The Board and leadership must understand and champion the importance of security for the organization. By setting the tone at the top, they can drive the cultural and procedural changes needed to prevent the accumulation of the security debt. Periodic review and monitoring of security metrics, and identifying & tracking security debt as a risk can help keep the organization accountable and on track.

Conclusion

Security debt may be an unseen burden, but its impacts are real and potentially devastating. For Boards and executive teams, recognizing and addressing security debt is not just a technical necessity but a critical component of strategic resilience. Investing time and resources into managing this debt will not only safeguard your organization today but also fortify it against the evolving challenges of tomorrow. By recognizing the challenges presented by security debt, employing a side-by-side approach to remediating both critical and other vulnerabilities, and employing appropriate risk scoring, vulnerability intelligence and related techniques, organizations can reduce both their security debt and exposure to potential attacks.