vulnerability_management

Last updated: 2024-09-17 21:09:18.779186 File source: link on GitLab

1. Vulnerability Management Process

NOTE: Please read the DevSecOps Maturity Models first here: DevSecOps Maturity Models

Flow Diagram

image

1.1 Important Definitions

Please refer here for complete picture of NuNet Security Pipeline: 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.

2. 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.

3. 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]