Last updated: 2024-11-21 22:07:01.711827 File source: link on GitLab

Secret Management

This document is for the Vault - Secret Management Solution in NuNet

1. Decision on Vault as Secret Management Solution for NuNet

2. Implementation for Vault as Secret Management Solution for NuNet

3. Vault Architecture

4. Automation scripts for building and initialisation

5. Cluster Configuration

Last updated: 2024-11-21 22:07:02.098441 File source: link on GitLab

Process for Security Team for PR Review

1. Get yourself Familiar with Secure Coding Guidelines here: Secure Coding Guidelines

2. Get yourself familiar with defect dojo here: Vulnerability Management

3. See if there are any High/Critical Severity issues found with the commit associated with PR/MR

   • Login to defectDojo

   • Go to Actives engagements

• Here each engagement correspond to the commit, product gives you information about the repo, each product corresponds to the repo

• Click on engagement, it will give you information about the branch, commit hash, findings and other information

• Click on findings, it will gives you information about the findings, if there is any finding with high or critical this PR is not suitable for merge.

1. If the issue/vulnerability is easily understood by developer and can be fixed, then developer should fix it.

2. If the vulnerability/issue needs enrichment then create an issue on the repo using ticketing template from here: Vulnerability Management

   • Make sure to include secvuln label

   • assign it to developer

3. If the vulnerability cannot be fixed add the label to the ticket as exception along with secvuln and include the reason for the decisions in the comment.

Last updated: 2024-11-21 22:07:01.345174 File source:

Tl;DR

• Before diving into this please read:

• Get yourself familiar with our Vulnerability Management Software:

1. Introduction

This document aims to provide a comprehensive overview of the security pipeline architecture implemented in NuNet. It is designed to serve as an informative guide for developers, and stakeholders involved in the software development and deployment process. The primary focus is to detail the various stages of the pipeline, the security tools integrated at each stage, and the specific roles these tools play in enhancing the security of the software development lifecycle. By outlining the workflow, tool specifics, and the conditions under which the pipeline is triggered.

2. DevSevOps Maturity Level 2

3. Pipeline Workflow

The security tools are applied in different stages of the pipeline workflow. These tools are:

• Commit

  • Secret Detection

  • Dependency Scanning

  • Coverage Fuzz Testing (Not in use)

• Build

  • Container Scanning

• Test

  • API Security (Not in use)
• Deploy

  • Operational Container Scanning (TBD)

3.1 Static Analysis Security Testing (SAST)

While GitLab's SAST framework supports many programming languages, at NuNet, our primary programming languages are Python, Golang and JavaScript.

This pipeline applies to both container and binary projects.

Tools

Triggers

• This pipeline is triggered on merge request to every branch.

Stages

It is run on the test (or Security-Test-1) stage.

3.2 Secret Detection

The Secret Detection tool scans repositories to help prevent secrets from being exposed during commits. The primary Secret Detection tool is Gitleaks.

This pipeline applies to both container and binary projects.

Tools

Triggers

This pipeline is triggered on merge request to every branch.

Stages

It is run on the test (or Security-Test-1) stage.

3.3 Dependency Scanning

This stage analyzes an application's dependencies for known vulnerabilities.

Tools

Triggers

This pipeline is currently disabled but can be configured to run every branch commit.

Stages

It is run on the test (or Security-Test-1) stage.

3.4 Container Scanning

The container scanning tool inspects docker images for known vulnerabilities.

Tools

After building the docker image, the following tools scan the built containers.

Triggers

This pipeline is triggered on merge request to every branch.

Stages

This stage is run on the test (or Security-Test-1) stage, primarily after the build stage.

4. Mapping Current Pipeline on Maturity Level 2

• Static Depth

  • Run SAST scans with minor tweaks to rules. ✅

  • Run SCA scans with minor tweaks to rules. ✅

  • Run Secret scans with minor tweaks to rules. ✅

• Dynamic Depth

  • Run DAST scans with minor tweaks to baseline settings. (Binary case) ❌

  • Run DAST scans with minor tweaks to baseline settings. (Container Scanning) ✅

• Intensity

  • Scans to be twice a month. Frequency here is too much, every commit on every branch

• Consolidation

  • The findings in a vulnerability register after analysis. Vulnerability Management Process designed for this purpose

Last updated: 2024-11-21 22:07:00.567345 File source:

1. Vulnerability Management Process

NOTE: Please read the DevSecOps Maturity Models first here:

1.1 Important Definitions

Please refer here for complete picture of NuNet Security Pipeline:

1.1.1 DefectDojo

Open-source application vulnerability management correlation and security orchestration tool used for management dashboard.

1.1.2 Product

Each product represent a repository

1.1.3 Engagement

Each Engagement represents a workflow, which was executed with each commit/PR to master, staging and develop branch

1.1.4 Triggers

• Each Commit to develop,staging,main branches

• Each Pull Request/Merge Request to develop,staging,main branches

1.1.5 types of Security pipelines

• Binary

• Container

1.1.5.1 Tools in Container Pipeline

• 1

• 2

• 3

1.1.5.2 Tools in Binary pipeline

• 1

• 2

• 3

1.2 Creation of tickets on a Security Board

• All merge requests will be scanned by Gitlab and outputs pushed to DefectDojo, Security Team will be focused on Critical and High severity issues from defectDojo.

• Security Team will use DefectDojo board to create tickets which are resultant of Pentest, community tests, any Bug Bounty report that we receive, including the external auditing.

1. Issue Sync to DefectDojo: All security issues originating from Security Pipeline are synced to DefectDojo. This serves as a centralized platform for managing and tracking security vulnerabilities.

2. Prioritization: Due to the potentially large volume of issues, there is a focus on prioritizing Critical and High severity issues from DefectDojo. This prioritization strategy helps the team concentrate on addressing the most impactful vulnerabilities first.

3. Security Board for Ticket Creation: A Security Board is used as a platform for creating tickets based on the prioritized Critical and High severity issues. This board could be a visual representation, possibly using a a Security Vulnerabilities Repo and creating issues on that, where the security team manages and tracks the progress of security-related tasks.

4. Ticket Creation Criteria: Tickets are created on the Security Board for issues deemed Critical and High severity in DefectDojo. These tickets likely include detailed information about the nature of the vulnerability, its potential impact, and steps to remediate.

5. Source of Issues: The issues that contribute to the creation of tickets come from various sources, including Pentests, community tests, Bug Bounty reports, and external auditing. This comprehensive approach ensures that security vulnerabilities from different testing methodologies are considered. We can separate issues using labels, in that way we can measure, monitor and prioritise them.

1.3 Exception Sheet

• Since, a lot of issues won't be relevant in our case, be it a False Positive or not relevant in our environment we will provide developers/service owners a possibility to mark it as exception. This sheet will be maintained and issue will be verified for exception by security team through #security slack channel.

1. Exception Marking by Developers/Service Owners: Developers or service owners have the ability to mark certain security issues as exceptions. This could be due to the issues being false positives or not applicable to your specific environment.

2. Maintaining an Exception Sheet: A centralized sheet or database is maintained to document these exceptions. This sheet serves as a record of issues that have been marked as exceptions, along with relevant details such as the reason for the exception and the individuals responsible.

3. Verification by Security Team: The security team is responsible for verifying the exceptions. This involves a thorough review of the marked issues to ensure that they are indeed false positives or not applicable in the given context.

4. Communication Through Slack Channel: The #security Slack channel is used as a communication platform for the security team to discuss and verify the exceptions. This allows for collaboration and transparent communication within the team.

1.4 SLAs

• Service Level Agreements in place to fix the vulnerabilities in defined period of time e.g. 7 days for Critical/High vulnerabilities

• We may introduce a system of points/credit given to the service, and deducted on number of issues present in the service, when the score/credit goes to 0 or negative, the service owners cannot move forward with their development without fixing the issues.

1. Service Level Agreements (SLAs) for security vulnerabilities are agreements that define the expected response time, resolution time, and other terms related to addressing and fixing security vulnerabilities within a system or application. These agreements are crucial for organizations to ensure a timely and effective response to security issues.

1. Technical Debt: Technical debt refers to the additional work that arises when a development team takes shortcuts or defers necessary work during the software development process. It often results from choosing expedient solutions over more robust ones. Over time, like financial debt, technical debt can accumulate and may need to be "repaid" through activities such as refactoring or improving the codebase.

1. Error budgets in the context of SRE likely refers to the Site Reliability Engineering (SRE) approach, which is a set of practices and principles developed by Google for managing large-scale, reliable software systems. Here's a breakdown: Error Budgets: In the context of Site Reliability Engineering (SRE), an error budget is a concept used to quantify the acceptable level of service disruptions or errors that a system can experience within a given time frame. The idea is to set a threshold for the acceptable amount of downtime or errors, and if the system's performance exceeds this threshold, it triggers a reassessment of the development and release processes. Error budgets are a way of balancing reliability with the need for continuous development and innovation.

Security Champions Program

A Security Champions Program is an initiative within an organization that aims to enhance and promote security awareness, knowledge, and best practices among its development and operational teams. The program typically involves selecting and empowering individuals from various departments to act as "security champions" or advocates within their respective teams. Here are key aspects of a Security Champions Program:

1. Selection of Champions: Identify individuals from different teams or departments who have an interest in security and demonstrate a willingness to contribute to improving security practices.

2. Training and Education: Provide specialized training and education to the selected security champions. This can include sessions on secure coding practices, threat modeling, incident response, and other relevant security topics.

3. Roles and Responsibilities: Define the roles and responsibilities of security champions. They often act as liaisons between their teams and the central security team, helping to disseminate security information and best practices.

4. Advocacy and Communication: Security champions serve as advocates for security within their teams. They communicate security initiatives, updates, and best practices, helping to bridge the gap between security teams and other departments.

5. Collaboration with Security Teams: Foster collaboration between security champions and the central security team. Security champions may participate in regular meetings with the security team to discuss ongoing projects, emerging threats, and ways to improve security measures.

6. Code Reviews and Best Practices: Encourage security champions to participate in code reviews and promote secure coding best practices within their teams. They can help identify and address security issues at the development stage.

7. Incident Response Training: Provide incident response training to security champions so that they are better equipped to handle security incidents within their teams and can act as first responders in the event of a security incident.

8. Feedback Loop: Establish a feedback loop where security champions can provide insights, concerns, and feedback to the central security team. This helps in continuously improving the security program.

9. Recognition and Rewards: Recognize and reward the efforts of security champions. This can include acknowledgment, certificates, or other incentives to motivate individuals to actively contribute to the security program.

10. Continuous Improvement: Regularly assess and refine the Security Champions Program based on feedback and evolving security needs. This ensures that the program remains effective and aligned with organizational goals.

1.6 Ticket enrichment Template

1. TL;DR Write high level summary with impact Example: An Unauthenticated SoluM API Swagger Interface was found which could control the Facility’s systems i.e. CRUD operations on ESL, Cloud, APs, Picking System, Station, Packing, etc. Which could be used by any malicious entity to hinder in the production.

2. Description/summary and business impact: Write the details of vulnerability and its business impact Example:

3. The Solum Gateways are used to send information to the Electronic Shelf Labels. They support PoE and use the frequency; 868Mhz.

4. The API is unauthenticated and CRUD operations can be performed on ESL, Cloud, APs, Picking System, Station, Packing, etc.

5. Which could be used by any malicious entity can change the labels which could impede in the production.

6. Impacted services/components/endpoints: Here you can mention endpoints and service which is impacted Example: http://10.200.240.10:9001/swagger-ui.html

7. [Optional] Steps to reproduce: Steps to reproduce a vulnerability Example:

8. Open the url in browser: http://10.200.240.10:9001/swagger-ui.html

9. You will get access to swagger UI with CRUD operations

10. Mitigation steps: Write detailed mitigation steps for Dev Team to understand and fix the vulnerability Example:

11. Authentication and Authorization:

12. Implement authentication and authorization mechanisms for accessing the Solum API Swagger UI. This could involve using API keys, tokens, or integrating with an existing authentication system.

13. Ensure that only authenticated users with the necessary permissions can access the API documentation.

14. Access Control Lists (ACL):

15. Configure access control lists to restrict access to the Swagger UI based on IP addresses, user roles, or groups.

16. Whitelist only trusted IP addresses that are allowed to access the documentation.

17. HTTPS Encryption:

18. Ensure that the Swagger UI is accessed over HTTPS to encrypt the communication between the user's browser and the server.

19. Use SSL certificates from trusted certificate authorities.

20. Disable Swagger UI in Production:

21. Consider disabling the Swagger UI in production environments to prevent unintentional exposure of sensitive API documentation.

22. CVSS Score: Calculate using: https://www.first.org/cvss/calculator/3.1

23. Likelihood of exploitation: 5/5 [Critical]

24. Impact: 5/5 [Critical]

25. Overall risk score: 5/5 [Critical]

Last updated: 2024-11-21 22:07:00.853112 File source:

DSOMM - DevSecOps Maturity Model - (1 - 4)

• Learn DevOps practices and how your organization works.

• Maintain relationships with Developers, QA, and Operations teams.

• Do not fail builds unless you are at maturity level 3 or 4.

• Do not run any tool which takes more than 10 minutes in CI/CD pipelines.

• Create separate jobs for each tool/scan.

• Roll out tools/scans in phases(iteratively).

• Do not buy tools that don’t provide APIs or CLIs.

• Verify that tool vendors can do incremental/baseline scans.

• Do not be afraid to create custom rules.

• Try to do everything as code.

• Write documentation wikis.