SSDLC — TryHackMe Walkthrough

This room focuses on the Secure Software Development Lifecycle (S-SDLC), its processes, and methodologies.

Task 1 Introduction

Introduction

This room focuses on the Secure Software Development Lifecycle (S-SDLC), its processes, and methodologies.

Learning objectives

• Understand what SSDLC is and why it’s important
• Learn about the processes of SSDLC
• Understand the Secure SDLC methodologies

Answer the questions below

Let’s get this bread

No Answer Needed

Task 2 What is SSDLC?

Secure Software Development Lifecycle (SSDLC)

During SDLC, security testing was introduced very late in the lifecycle. Bugs, flaws, and other vulnerabilities were identified late, making them far more expensive and time-consuming to fix. In most cases, security testing was not considered during the testing phase, so end-users reported bugs after deployment. Secure SDLC models aim to introduce security at every stage of the SDLC.

Why is Secure SDLC important?

A study conducted by the Systems and Sciences institute at IBM discovered that it costs six times more to fix a bug found during implementation than one identified as early as during the design phase. It also reported that it costs 15 times more if flaws are identified during testing and up to 100 times more costly if identified during the maintenance and operation phases. See the figure below:

The research paper on the cost of identifying vulnerabilities can be found here.

Apart from faster development and reduction of costs, integrating security across the SDLC helps discover and reduce vulnerabilities early, reducing business risk massively. Examples of introducing security at all stages are architecture analysis during design, code review and scanners during the development stage and conducting security assessments (e.g. penetration tests) before deployment. For example, in waterfall models, this sort of testing was carried out at the end of the lifecycle, right before production; in more agile processes, we can implement a “security by design” approach. If the pentests result in errors like an SQL injection in a waterfall scenario, mitigating the bugs would entail doing another cycle to fix the bug. It would require redesigning, applying the changes and retesting to check it has been remediated. In a more agile approach, discussions on whether to prevent flaws like this, such as deciding on parameterisation during the planning phase, can avoid having to roll back changes, and it only costs a planning discussion.

Summary

• Security is a constant concern, improving software quality and security constantly.
• Boosting security education and awareness: all stakeholders know each phase’s security recommendations and requirements.
• Flaws are detected early before deployment, reducing the risk of getting hacked or disrupted.
• Costs are reduced, and speed increases, thanks to the early detection and resolution of vulnerabilities. Business risk, brand reputation damage, and fines that could lead to economic disaster for a company are prevented.

Answer the questions below

How much more does it cost to identify vulnerabilities during the testing phase?

15

Task 3 Implementing SSDLC

Implementing SSDLC

As the Intro To DevSecOps room shows, Secure SDLC involves instilling security processes at all lifecycle phases. From security testing tools to writing security requirements alongside functional requirements.

Understanding Security Posture

Like with every new process, understanding your gaps and state is critical for successfully introducing a new tool, solution, or change. To help grasp what your security posture is, you can start by doing the following:

• Perform a gap analysis to determine what activities and policies exist in your organization and how effective they are. For example, ensuring policies are in place (what the team does) with security procedures (how the team executes those policies).
• Create a Software Security Initiatives (SSI) by establishing realistic and achievable goals with defined metrics for success. For example, this could be a Secure Coding Standard, playbooks for handling data, etc. are tracked using project management tools.
• Formalise processes for security activities within your SSI. After starting a program or standard, it is essential to spend an operational period helping engineers get familiarized with it and gather feedback before enforcing it. When performing a gap analysis, every policy should have defined procedures to make them effective.
• Invest in security training for engineers as well as appropriate tools. Ensure people are aware of new processes and the tools that will come with them to operationalise them, and invest in training early, ideally before establishing / on-boarding the tool.

SSDLC Processes

After understanding your security posture, now is the time to prioritise and instil security in your SDLC. Generally speaking, a secure SDLC involves integrating processes like security testing and other activities into an existing development process. Examples include writing security requirements alongside functional requirements and performing an architecture risk analysis during the design phase of the SDLC. These processes are the following:

• Risk Assessment — during the early stages of SDLC, it is essential to identify security considerations that promote a security by design approach when functional requirements are gathered in the planning and requirements stages. For example, if a user requests a blog entry from a site, the user should not be able to edit the blog or remove unnecessary input fields.
• Threat Modelling — is the process of identifying potential threats when there is a lack of appropriate safeguards. It is very effective when following a risk assessment and during the design stage of the SDLC, as Threat Modelling focuses on what should not happen. In contrast, design requirements state how the software will behave and interact. For example, ensure there is verification when a user requests account information.
• Code Scanning / Review — Code reviews can be either manual or automated. Code Scanning or automated code reviews can leverage Static and Dynamic Security testing technologies. These are crucial in the Development stages as code is being written.
• Security Assessments — Like Penetration Testing & Vulnerability Assessments are a form of automated testing that can identify critical paths of an application that may lead to exploitation of a vulnerability. However, these are hypothetical as the assessment doesn’t carry simulations of those attacks. Pentesting, on the other hand, identifies these flaws and attempts to exploit them to demonstrate validity. Pentests and Vulnerability Assessments are carried out during the Operations & Maintenance phase of the SDLC after a prototype of the application.

There are methodologies to apply the processes in task 5 that will help you navigate and guide you when introducing risk assessment, threat modelling, scanning and testing, and operational assurance. The following tasks will cover these processes in more detail.

Answer the questions below

What should you understand before implementing Secure SDLC processes?

Security Posture

During which stages should you perform a Risk Assessment?

planning and requirements

What should be carried out during the design phase?

Threat Modelling

Task 4 Risk Assessment

Risk Assessment

Risk refers to the likelihood of a threat being exploited, negatively impacting a resource or the target it affects. For example, vulnerabilities being exploited after a new version of the software is published, design flaws, and poorly reviewed code can increase the risk of these scenarios. Risk management is an important pillar to integrate into the SDLC to mitigate risk in a product or service.

Risk assessment is used to determine the level of the potential threat. Risk identified in the risk assessment process can be reduced or eliminated by applying appropriate controls during the risk mitigation process. Usually, a risk assessment is followed by threat modelling, which will be explained further in the next section.

Performing a Risk Assessment

1. The first step in the risk assessment process is to assume the software will be attacked and consider the factors that motivate the threat actor. List out the factors such as the data value of the program, the security level of companies who provide resources that the code depends on, the clients purchasing the software, and how big is the software distributed (single, small workgroup or released worldwide). Based on these factors, write down the acceptable level of risk. For instance, a data loss may cause the company to lose millions, especially if they require to pay fines nowadays with GDRP, but eliminating all potential security bugs in the code may cost $40,000. The company and some other stakeholder groups have to decide whether it is worth it; it is also crucial to communicate these tradeoffs. Hence, everyone has an understanding of risk and its implications. From a brand reputation perspective, if the attack causes damage to the company’s image, it costs the company more in the long run than fixing the code.
2. The next step is risk evaluation. Include factors like the worst-case scenario if the attacker has successfully attacked the software. You can demonstrate the worst-case scenario to executives and senior engineers by simulating a ransomware attack. Determine the value of data to be stolen, valuable data such as the user’s identity, credentials to gain control of the endpoints on the network, and data or assets that pose a lower risk. Another factor to consider is the difficulty of mounting a successful attack, in other words, its complexity. For example, if an attacker can gain access to the company’s tool for giving feedback to colleagues or running retrospective meetings, it would have a lower impact than accessing a production environment’s monitoring and alerts system. The high level of risk will not be acceptable, and it is best to mitigate it. For example, a vulnerability can be exploited by anyone running prewritten attack scripts or using botnets to spread the scripts to compromise computers and networks. Users affected are a vital factor.
3. Some attacks only affect one or two users, but the denial of service attack will affect thousands of users when a server is attacked. Moreover, thousands of computers may be infected by the spread of worms. The last factor is the accessibility of the target. Determine whether the target accepts requests across a network or only local access, whether authentication is needed for establishing a connection, or if anyone can send requests. It has more impact if an attacker accesses a production environment vs a sandbox environment used in local playgrounds for people to do labs or tutorials.

Types of Risk Assessments

There are several types of Risk assessments best suited for different scenarios. Below are the different types of Risk Assessments:

Qualitative Risk Assessment

This is the most common type of Risk Assessment that you will find in companies (hopefully). In a Qualitative Risk Assessment, the goal is to assess and classify risk into thresholds like “Low”, “Medium”, and “High”. It systematically examines what can cause harm and what decisions should be made to define or improve adequate control measures. Like all types of Risk Assessments, each level has a priority, where “High” has the most urgency. Even though Qualitative Risk Assessments don’t use numbers, a typical formula to evaluate qualitative risk is:

Risk = Severity x Likelihood

“Severity” is the impact of the consequence, and Likelihood is the probability of it happening. It is up to the risk assessor to judge these circumstances.

Quantitative Risk Assessment

The Quantitative Risk Assessment is used to measure risk with numerical values. Instead of “Low”, “Medium”, and “High”, you would have numbers that represent those bands. When carrying out Quantitative Risk Analysis, we can use tools to determine Severity and Likelihood or custom series of calculations based on the company’s processes.

For example, suppose there are services with assigned business criticality levels. In that case, you can say that if a bug affects a business-critical service (an authentication service, a payment infrastructure etc.), you will assign 5 points. This highlights why it is vital to understand a security posture and its processes. Measuring risk and priority with an endemic equation to a company’s services will have great results. An example of a Qualitative Risk Assessment Matrix can be seen below:

Risk assessments are better performed at the beginning of the SDLC, during the planning and requirement phases. For example, “Customer data gets exfiltrated by an attack”. Once the system is developed, you can perform quantitative risk analysis: “One customer can sue us for $ 20,000 if their data gets leaked”, and we have 100 customers. However, the Annual Rate of Occurrence (ARO) is 0.001. Hence Annual Loss Expectancy is = $20,000 * 100 * 0.001 = $ 2,000, meaning as long as our compensating security control is less than $ 2,000, we are not overspending on security.

Answer the questions below

What is a formula to assign a Qualitative Risk level?

Severity x Likelihood

Which type of Risk Assessment assigns numerical values to determine risk?

Quantitative Risk Assessment

Task 5 Threat Modelling

Threat Modelling

Threat modelling is best integrated into the design phase of an SDLC before any code is written. Threat modelling is a structured process of identifying potential security threats and prioritising techniques to mitigate attacks so that data or assets that have been classified as valuable or of higher risk during risk assessment, such as confidential data, are protected. When performed early, it brings a great advantage; potential issues can be found early and solved, saving fixing costs down the line.

There are various methods to perform threat modelling. Not all the methods have the same purpose; some focus on risk or privacy concerns, while some are more customer-focused. We can combine these methods to understand potential threats better; it is essential to analyse which way aligns more with the project or business. STRIDE, DREAD, and PASTA are among the common threat modelling methodologies.

STRIDE

STRIDE stands for Spoofing, Tampering, Repudiation, Information Disclosure, Denial Of Service, and Elevation/Escalation of Privilege. STRIDE is a widely used threat model developed by Microsoft which evaluates the system’s design in a more detailed view. We can use STRIDE to identify threats, including the property violated by the threat and definition. The system’s data flow diagram is to be developed in this model, and each node is applied with the STRIDE model. Identifying security threats is a manual process that tools are not supported and should be carried out during the risk assessment. Using data flow diagrams and integrating STRIDE, the system entities, attack surfaces, like known boundaries and attacker events become more identifiable. Stride stands for Spoofing Identity, Tampering with Data, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege. STRIDE is built upon the CIA triad principle (Confidentiality, Integrity & Availability). Security professionals that perform STRIDE are looking to answer “What could go wrong with this system”. Here are the components of the framework:

1. Spoofing: It is an act of impersonation of a user by a malicious actor which violates the authentication principle from the perspective of the CIA triad. Common ways include ARP, IP, and DNS spoofing.
2. Tampering: The modification of information by an unauthorised user. It violates the integrity principle of the CIA triad.
3. Repudiation: Not taking responsibility for events where the actions are not attributed to the attacker. It violates the principle of non-repudiability. For example, the attacker clears up all the logs that could lead to leaving traces.
4. Information Disclosure: It is an act of violation of confidentiality of the CIA triad. A typical example is data breaches.
5. Denial of Service: Denial of Service occurs when an authorised user cannot access the service, assets, or system due to the exhaustion of network resources. DoS is a violation of the availability principle of the CIA triad.
6. Elevation/Escalation of Privilege: Escalating privileges to gain unauthorised access is a classic example of a violation of the authorisation principle of the CIA triad.

DREAD

The abbreviation DREAD stands for five questions about each potential: Damage Potential, Reproducibility, Exploitability, Affected Users and Discoverability. DREAD is also a methodology created by Microsoft which can be an add-on to the STRIDE model. It’s a model that ranks threats by assigning identified threats according to their severity and priority. In other words, it creates a rating system that is scored based on risk probability. Without STRIDE, the DREAD model also can be used in assessing, analysing and finding the risk probability by threat rating. Here are the components of the framework:

1. Damage: refers to the possible damage a threat could cause to the existing infrastructure or assets. It is based on a scale of 0–10. A score of 0 means no harm, 5 means Information Disclosure, 8 means user data is compromised, 9 means internal or administrative data is compromised, and 10 means unavailability of a service.
2. Reproducibility: it measures the complexity of the attack. So how easily a hacker can replicate a threat. A score of 0 means it is nearly impossible to copy, 5 stands for being complex but possible, 7.5 for an authenticated user and a score of 10 means the attacker can reproduce very quickly without any authentication.
3. Exploitability: Referring to the attack’s sophistication or how easy it would be to launch the attack. A score of 2.5 implies it would require an advanced skill set of networking and programming skills; 5 means can be exploited with available tools, a score of 9 means we would need a simple web application proxy tool and a score of 10 means it can exploit through a web browser.
4. Affected Users: it describes the number of users affected by the successful exploitation of a vulnerability. A score of 0 would mean that there would be no affected users, 2.5 shall mean for an individual user, 6 would mean a small group of users, 9 would mean significant users like administrative users, and 10 would imply all users are affected.
5. Discoverability: The process of discovering the vulnerable points in the system. For example, the threat would be easily found in case of compromise. A score of 0 would mean it would be challenging to discover it, a score of 5 means that the threat can be discovered by analysis of HTTP requests, and 8 means it can be easily found as it’s public-facing. A score of 10 would mean it’s visible in the browser address bar.

PASTA

PASTA is short for Process for Attack Simulation and Threat Analysis; it is a risk-centric threat modelling framework. PASTA’s focus is to align technical requirements with business objectives. PASTA involves the threat modelling process from analysing threats to finding ways to mitigate them, but on a more strategic level and from an attacker’s perspective. It identifies the threat, enumerates them, and then assigns them a score. This helps organisations find suitable countermeasures to be deployed to mitigate security threats. PASTA is divided into seven stages:

1. Define Objectives: The first stage focuses on noting the structure and defining objectives. This makes the end goal a whole lot clearer and ensures the relevant assets are threat modelled by defining an asset scope.
2. Define Technical Scope: This is where architectural diagrams are defined, both logical and physical infrastructure. Helpful in mapping the attack surface and dependencies from the environment.
3. Decomposition & Analysis: Each asset will have a defined trust boundary that encompasses all its components and data in this stage. For example, mapping threat vectors for a payment service and evaluating which components underlying the service can be leveraged for an attack; components can be libraries, dependencies, modules or underlying services etc.
4. Threat Analysis: This refers to the extracted information obtained from threat intelligence. Useful to identify which applications are vulnerable to specific vectors; for example, a customer/public-facing application can be susceptible to DDOS, unauthorised data alteration etc.
5. Vulnerabilities & Weaknesses Analysis: it analyses the vulnerabilities of web application security controls. It identifies security flaws in the application and enumerates vulnerabilities. It is highly recommended to add mitigation to the identified threat in this stage. For example, when describing a past incident involving an exploit of a mail server, lessons learned or mitigation: lack of thorough testing before implementation and hardening the server.
6. Attack/Exploit Enumeration & Modelling: In this stage, we map out the possible threat landscape and the entire attack surface of our web application. We then map all potential attack vectors to the different nodes, identifying exploits and attack paths. This stage simulates all the enumerated information extracted from all of the previous steps; this helps security professionals determine the extent and probability of successfully launching the identified vulnerabilities.
7. Risk Impact Analysis: Based on the collective data from the previous stages, all of the scoped assets that have been affected are analysed and finally, based upon the risk analysis, recommended steps to mitigate the risks and eliminate all of the residual risks are documented.

Answer the questions below

What threat modelling methodology assigns a rating system based on risk probability?

DREAD

What threat modelling methodology is built upon the CIA triad?

STRIDE

What threat modelling methodology helps align technical requirements with business objectives?

PASTA

Task 6 Secure Coding

Secure code review & analysis

According to research conducted by Verizon in 2020 on Data Breaches, 43% of breaches were attacks on web applications, while some other security breaches resulted from some vulnerabilities in web applications. Implementing a secure code review in the phases of an SDLC, especially during the implementation phase, will increase the resilience and security of the product without bearing any additional cost for future patches. Secure code review is defined as a measure where the code itself is verified and validated to ensure vulnerabilities that are found can be mitigated and removed to avoid vulnerabilities and flaws. Having the developers be aware and proactive in reviewing the code during development can result in faster mitigation responses and fewer unattended threats. Reviewing code is a crucial step in the SDLC for developers. It prevents any setbacks on the release and issues exposed to the users. As shown in the previous SSDLC task, the cost of the project itself and the effort put in is proportional and cheaper in the long run than the cost of applying code reviews and analysis. By implementing this approach, the organisation will also be compliant with the standards set by government bodies and certifications.

Code review can be done manually or automated. A manual code review is where an expert analyses and checks the source code by going line by line to identify vulnerabilities. Therefore, a high-quality manual code review requires the expert to communicate with the software developers to get hold of the purpose and functionalities of the application. The analysis output will then be reported to the developers if there is a need for bug fixing.

Code Analysis

Static analysis examines the source code without executing the program. In contrast, Dynamic analysis looks at the source

code when the program is running, static analysis detects bugs at the implementation level, and dynamic analysis detects errors during program runtime. Automated Static Application Security Testing (SAST) automatically analyses and checks the source code.

SAST

SAST means Static Application Security Testing, a white box testing method that directly analyses the source code.

Many people tend to develop an application that could automate or execute processes quickly and improve performance and user experience, thereby forgetting the negative impact an application that lacks security could cause.

Why is it Static? — Because the test is done before an application is live and running. SAST can even help detect vulnerabilities in your application before the code is merged or integrated into the software if added as part of the SDLC development phase.

How Does SAST Work

SAST uses a testing methodology of analysing a source code to detect any traces of vulnerabilities that could provide a backdoor for an attacker. SAST usually analyses and scans an application before the code is compiled.

The process of SAST is also known as White Box Testing. Once a vulnerability is detected, the following line of action is to check the code and patch the code before the code is compiled and deployed to live. White Box Testing is an approach or method that testers use to test software’s inner structure and see how it integrates with the external systems.

Bonus: SCA

To summarise, SAST is used to scan source code for security vulnerabilities. Another type of testing goes hand in hand with SAST, Software Composition Analysis (SCA). SCA is used to scan dependencies for security vulnerabilities, helping development teams track and analyse any open-source component brought into a project. SCA is now an essential pillar in security testing as modern applications are increasingly composed of open-source code. Nowadays, one of the biggest challenges developer teams have is ensuring their codebase is secure as applications are assembled from different building blocks.

DAST

DAST means Dynamic Application Security Testing, a black-box testing method that finds vulnerabilities at runtime. DAST is a tool to scan any web application to find security vulnerabilities. This tool is used to detect vulnerabilities inside a web application that has been deployed to production. DAST tools will always send alerts to the security team assigned for immediate remediation.

How Does DAST Work

DAST works by simulating automated attacks on an application, mimicking a malicious attacker. The goal is to find unexpected outcomes or results that attackers could use to compromise an application. Since DAST tools don’t have internal information about the application or the source code, they attack just as an external hacker would — with the same limited knowledge and information about the application.

DAST is a tool that can be integrated very early into the software development lifecycle. Its focus is to help organisations reduce and protect against the risk that application vulnerabilities could cause. It is very different from SAST because DAST uses the Black Box Testing Methodology; it conducts its vulnerability assessment outside as it does not have access to the application source code. DAST is typically used during the testing phase of SDLC.

IAST

IAST means Interactive Application Security Testing that analyses code for security vulnerabilities while the app is running. It is usually deployed side by side with the main application on the application server. IAST is an application security tool designed for web and mobile applications to detect and report issues even while running. Before someone can fully comprehend IAST’s understanding, the person must know what SAST and DAST mean. IAST was developed to stop all the limitations in both SAST and DAST. It uses the Grey Box Testing Methodology. How Does IAST Work IAST testing occurs in real-time, just like DAST, while the application runs in the staging environment. IAST can identify the line of code causing security issues and quickly inform the developer for immediate remediation. IAST checks the source code similar to SAST, but at the post-build stage, unlike SAST, which occurs during development. IAST agents are typically deployed on the application servers. When the DAST scanner performs its work by reporting a vulnerability, the deployed IAST agent will now return a line number of the issue from the source code. Can deploy IAST agents on an application server. During functional testing performed by a QA tester, the agent studies every pattern that a data transfer inside the application follows regardless of whether it’s dangerous. For example, if data is coming from a user and the user wants to perform an SQL Injection on the application by appending an SQL query to a request, the request will be flagged as dangerous.

Bonus: RASP

“RASP” stands for Runtime Application Self Protection. RASP is a runtime application integrated into an application to analyse inward and outward traffic and end-user behavioural patterns to prevent security attacks. This tool is different from the other tools as RASP is used after product release, making it a more security-focused tool when compared to the others that are known for testing.

How does RASP work RASP is deployed to a web or application server next to the main application while running to monitor and analyse the inward and outward traffic behaviour. Immediately once an issue is found, RASP will send alerts to the security team and immediately block access to the individual making a request. When you deploy RASP, it will secure the whole application against different attacks. It does not just wait or try to rely only on specific signatures of some known vulnerabilities.

RASP is a complete solution that observes every detail of different attacks on your application and knows your application behaviour.

Choosing tools

SAST, DAST, and IAST are great tools that complement each other. A key strength of DAST is that it identifies runtime issues — weaknesses that aren’t discoverable when an application isn’t running. SAST is excellent at identifying vulnerabilities while code is being written. Additionally, DAST looks at how an application responds to an attack, providing helpful insight into how likely it would be for that vulnerability to be manipulated. AST enables DevSecOps and supports continuous testing, monitoring, assessment, and validation in real-time. IAST helps prioritise and alert on vital critical risks, as defined by business goals and application security needs. The security experts always support using two or more of these tools to ensure better coverage, which will lower the risk of vulnerabilities in production. Ensure you fit these tools to the way engineers push code and interact with the pipeline; watch out for integrations and focus on providing support and education vs being a blocker. For example, if choosing SAST, you can integrate it when engineers push code, and they can get feedback on the PR before merging.

Timeline of Application Security Automation

Check the diagram below to see where you can fit security testing tools!

Above is a standard timeline when choosing when to implement security testing tooling. As described earlier, SAST is a static approach; there is no need for a running application. Therefore, SAST can be implemented in the earliest development stages. SCA typically work best for Identifying open source components, like packages via dependencies. It is also beneficial for identifying open-source licenses being used, especially from a legal risk perspective. Because of this, you can implement governance and control by enforcing security and license policies across the different stages of SDLC.

On the other hand, DAST relies on the execution of the application, so integrating it in the pipeline is not as straightforward as SAST. DAST is typically implemented after the acceptance stage of the code and pre-production stage. This is where the application starts running in testing environments (e.g. sandbox/staging) similar to IAST. DAST and IAST reside on the far right of your pipeline because the execution of your application is required for DAST tools to do their work. This can become quite time-consuming, significantly if your application has grown over time. RASP helps uncover third-party packages and associated vulnerabilities at runtime, more effectively enabling developers to prioritise the remediation and mitigation of their highest pressing vulnerabilities. This is usually enabled in the production stage as security vulnerabilities are evaluated during the runtime of the application.

Answer the questions below

Is it recommended to use SAST analysis at the beginning of the SDLC? (y/n)

Y

Which type of code analysis uses the black-box method?

DAST

Which type of code analysis uses the white-box method?

SAST

Task 7 Security Assessments

Security Assessment

A security assessment plays a primary role in achieving security in SDLC and should be implemented in all phases where possible. Security testing assesses a system, software or web application for vulnerabilities and other attack vectors. Because they test from a holistic point of view of the application, they are usually carried out at the end of the SDLC, in the Operations and Maintenance phase, once the version has included all the working components and updates. There are two types of assessments: Penetration Testing and Vulnerability Assessment. Usually, a company employs and authorises external security testers to attempt to break into a company’s network and systems legally.

Vulnerability Assessment

Vulnerability Assessments focus on Finding Vulnerabilities, but do not validate them or simulate the findings to prove they are exploitable in reality. Typically, automated tools run against an organisation’s network and systems. Examples of tools: are OpenVAS, Nessus (Tenable), and ISS Scanner. These scanners probe ports and services on systems across various systems and IP Addresses. Other activities include checking service versions against a database of vulnerabilities affecting said version. The result is a report with a list of vulnerabilities usually found, with an automated threat level severity classification, e.g., High/Medium/Low or an assigned CVSS score.

Penetration Testing

It Includes Vulnerability Testing but goes more in-depth. It is extended by testing/validating of vulnerabilities, quantifying risks and attempting to penetrate systems. For example, trying to escalate privileges after a vulnerability is found, some vulnerabilities can be a lower risk but can be used as leverage to cause more damage. The tester can provide a thorough report with suggested countermeasures to mitigate the vulnerabilities. This makes it easier to understand the threats by demonstrating the actual risk, for example, recovering an employee password by exploiting the mentioned vulnerability.

Pros and Cons

Vulnerability Assessment

Penetration testing

Answer the questions below

Which form of assessment is more budget-friendly and takes less time?

Vulnerability assessment

Which type of assessment identifies vulnerabilities and attempts to exploit them?

Penetration Testing

When do you typically carry out Vulnerability Assessments or Pentests?

Operations and Maintenance

Task 8 : SSDLC Methodologies

SSDLC Methodologies

You can follow different methodologies to integrate security in the SDLC best. Before we dive into each method., regardless of the chosen development methodology (Agile, DevOps, Extreme Waterfall, etc.), there is a need to:

• Build with security in mind
• Introduce testing focused on security

There are several methodologies for SDLC; some examples of widely used methodologies are:

• Microsoft’s Security Development Lifecycle (SDL)
• OWASP Secure Software Development Life Cycle Project (S-SDLC)
• Software Security Touchpoints

Microsoft’s SDL

SDL principles:

• Secure by Design: Security is a built-in quality attribute affecting the whole software lifecycle.
• Security by Default: Software systems are constructed to minimise potential harm caused by attackers, e.g. software is deployed with the least necessary privilege.
• Secure in Deployment: software deployment is accompanied by tools and guidance supporting users and administrators.
• Communications: software developers are prepared for occurring threats by communicating openly and timely with users and administrators

SDL is a collection of mandatory security activities grouped by the traditional software development lifecycle phases. Data is collected to assess training effectiveness. In-process metrics are used to confirm process compliance. Post-release metrics are used to guide future changes. SDL places heavy emphasis on understanding the cause and effect of security vulnerabilities. A development team must complete the mandatory security activities to comply with the Microsoft SDL process. You can implement SDL by following these practices:

SDL principles

OWASP’s S-SDLC

S-SDLC Principles

• SDL is a collection of mandatory security activities grouped by the traditional software development lifecycle phases.
• Data is collected to assess training effectiveness.
• In-process metrics are used to confirm process compliance.
• Post-release metrics are used to guide future changes.
• SDL places heavy emphasis on understanding the cause and effect of security vulnerabilities.
• A development team must complete the sixteen mandatory security activities to comply with the Microsoft SDL process.

OWASP S-SDLC aims to build “security quality gates”, to support quality and secure software made throughout the pipeline. This is done by following an Agile Security approach, where sprints are dedicated to security. Examples of Sprints can include: Code reviews, authentication, authorisation, input validation, and assessing technical risks like code injections. The gates comprise sprints focusing on similar building blocks like those seen in Microsoft SDL. OWASP S-SDLC Agile approach is heavily influenced and based on a “Maturity Model” approach, in particular OWASP SAMM. The Software Assurance Maturity Model (SAMM) is an open framework to help organisations formulate and implement a software security strategy tailored to the organisation’s specific risks. It helps to evaluate an organisation’s existing software security practices, build a software security assurance program, demonstrate improvements to that program, and define and measure security activities for an organisation. SAMM helps explain objectives, actions, results, success metrics, costs etc. An example would be a security scorecard for gap analysis, for instance, in a particular area, like endpoint protection. It aims to answer “How well are we doing and where do we want to get to?”. OWASP SAMM link

Another critical security model is the Building Security In Maturity Model (BSIMM). BSIMM is a study of real-world software security initiatives and reflects the current state of software security. BSIMM can be described as a “measuring stick” to understand your security posture by providing a comparison of other companies’ security states. In other words, it does not tell you what you should do but rather what you are doing wrong. There are hundreds of organisations involved. BSIMM link

Answer the questions below

What methodology follows a set of mandatory procedures embedded in the SDLC?

Microsoft SDL

What Maturity Model helps you measure tailored risks facing your organisation?

SAMM

What maturity model acts as a measuring stick to determine your security posture?

BSIMM

Introduction

Ensure you are able to travel through the SDLC in a secure manner by selecting which secure processes you can implement at each stage.

Safe travels!

To start, select View Site

Level 1

Risk management

Level 2

Threat Modelling 

Level 3

SAST

Level 4

DAST

Code Review

Obvioiusly NOT Cry and Scream ;)

Secure Configs

Now that's one straight line acceleration to the moon!

Security Assessement

Answer the questions below

What is the flag?

do a barrel roll?

If you liked this contetnt you know what to do ;)