For technology and SaaS companies alike, the quickest way to lose customer/ brand trust is being vulnerable to breaches. We’ve seen time and again, how even the biggest brands lose market share because they were at the receiving end of a security breach.
A popular example is Yahoo, who experienced two significant data breaches in 2013 and 2014, affecting billions of user accounts. The breach revelations eroded trust among users, and some chose to discontinue using Yahoo services, impacting the company’s user base and its overall brand image.
In regulated markets/ industries, this mess doesn’t just end with losing paying-customers, potential consequences can also be huge fines levied by federal authorities and out-of-court settlements with customers that were directly impacted by the breach. As was the case with Yahoo at 117 million and British Airways at 183 million respectively.
Understanding Vulnerabilities
Before I delve into the tools and processes that can help you trace vulnerabilities effectively, for the sake of all readers, I’d like to first address the basics such as what is a vulnerability, what are the challenges posed by them, and the traditional practices followed in the industry to mitigate them.
But that’s not it. There are plenty of shortcomings with this traditional approach, especially impacting Software Deployment/ Delivery. I’ll soon publish another blog covering those shortcomings and how OpsMx’s capabilities revolutionizes the way vulnerabilities are remediated throughout the pre-deployment and post-deployment phases.
What is a Vulnerability?
A security vulnerability is a weakness or flaw in a system, application, or network that can be exploited by attackers to compromise the security of the system or gain unauthorized access to sensitive information. Vulnerabilities can exist in various components of a system, including software, hardware, system configurations, or even in human practices.
Some of the most common vulnerabilities include:
- Unpatched operating systems
- SQL Injection
- Weak account credentials
- Cross-Site Scripting (XSS)
- Insecure Direct Object References (IDOR)
- Device misconfigurations
Challenges with Vulnerability Management
When a vulnerability is present, it means that there is a potential entry point or loophole that attackers can exploit to conduct malicious activities. These activities may include stealing sensitive data, compromising the integrity of the system, disrupting services, or gaining unauthorized control over the system.
Here are some of the challenges that impact Vulnerability remediation:
- Time Sensitivity: Vulnerabilities such as zero-day exploits are time-sensitive and a patch needs to be applied at the earliest to minimize the impact from attack.
- Complexity: Remediation may involve changing code, configuration settings, or even modifying the system’s architecture, all of which increase the complexity.
- Testing and Validation: After applying fixes or patches, organizations need to thoroughly test the system to ensure that the changes do not introduce new issues or negatively impact performance.
- Legacy Systems: Older systems or software that is no longer actively supported can be challenging to remediate because the required patches might not be available or feasible to implement.
- Resource Constraints: Remediation efforts require resources, including time, personnel, and sometimes budget. Organizations with limited resources may struggle to prioritize and execute remediation effectively.
- Balancing Priorities: When faced with multiple vulnerabilities, organizations need to prioritize based on severity, potential impact, and other factors which often leads to more complexity.
- Communication and Coordination: Remediation efforts might involve multiple teams or departments. Effective communication and coordination are essential to ensure that everyone is on the same page and that changes are implemented correctly.
- Regulatory Compliance: Some industries have regulatory requirements that dictate how vulnerabilities must be remediated. Ensuring compliance while addressing vulnerabilities can be intricate.
- False Positives and Negatives: Security tools might generate false-positive reports, indicating vulnerabilities that do not actually exist, or miss actual vulnerabilities (false negatives). This can complicate the remediation process.
- Long-Term Maintenance: Remediation efforts aren’t a one-time task. Organizations must establish procedures for ongoing vulnerability management and patch management to ensure that new vulnerabilities are addressed promptly.
- Unknown Dependencies: Systems are often complex and interconnected. Fixing one vulnerability might reveal hidden dependencies that introduce new issues or vulnerabilities.
In today’s time and age, vulnerabilities are being exploited at break-neck speed. According to the US National Institute of Standards and Technology and its National Vulnerability Database as reported by HackerOne, in 2020 alone there were 18,103 vulnerabilities reported by organizations averaging 50 vulnerabilities/ day. What’s even more staggering is that 57% of these vulnerabilities were classified as High or Critical to business impact.
Traditional approach to Vulnerability Management
The key to building a secure software business lies in first of all accepting that vulnerabilities will eventually find a way into your systems if a deliberate effort is not placed into curtailing it. The second notable point is that, the key to reducing impact from vulnerabilities lies in how well you respond to it, i.e reducing the MTTR (Mean Time to Respond). In order to keep the MTTR as short as possible, a well-defined vulnerability management program framework must be in place.
What is Vulnerability Management? And how to automate it?
Vulnerability management refers to the process of identifying and mitigating security vulnerabilities that could have arised either due to:
- Software errors
- Hardware issues
- Network misconfigurations
- Design flaws
- Human Errors, etc.
Remediating security vulnerabilities involves taking necessary actions, such as applying patches, making configuration changes, or implementing security measures, to eliminate or reduce the risk posed by vulnerabilities. While the majority of this process requires manual intervention, you can bring about a certain level of automation to reduce the MTTR. By leveraging various tools for security scanning, tracing and continuous vulnerability monitoring you can automate vulnerability management.
Now let’s move on to the next section on this blog and try to understand 4 steps to vulnerability management which is very critical to automating the whole process in order to respond to issues on time.
4-step Vulnerability Management process to handle production issues
Tracing vulnerabilities swiftly and mitigating them is a 4-step process:
- Detect: Detecting vulnerabilities through scanning and testing
- Prioritize: Understanding which vulnerabilities pose a real and significant risk
- Remediate: Patching, blocking, or remediating in real-time
- Monitor: Real-time alerts and notifications for newly discovered vulnerabilities
1. Detecting vulnerabilities
The first step is to scan for security vulnerabilities using security scanning tools. While the scan report will provide a list of all the known vulnerabilities, it can seldom be relied upon to decide which vulnerability to address first.
An important element of DevSecOps shift-left approach to security, requires vulnerability discoverability via scanning tools to be a continuous process throughout the SDLC. In order not to slow down the CI/CD pipeline, automated vulnerability testing tools are deployed across development, testing, and production environments. The different categories of scanning tools include:
- Software Composition Analysis (SCA) tools
- Open source vulnerability scanners
- White-box Static Application Security Testing (SAST) tools
- Black-box Dynamic Application Security Testing (DAST) tools
2. Prioritizing vulnerabilities
Once the scan reports are in, the real question that developers are faced with is, which of the vulnerabilities need immediate attention. Not every detected vulnerability poses the same level of risk and thus the tradeoff must be influenced by factors such as severity, fixability, coverage, and compliance.
Priority can be assigned through automated scans or manually during the ‘detection phase’. Many organizations use the Common Vulnerability Scoring System (CVSS) to communicate the vulnerability’s severity and characteristics. The CVSS scoring system calculates severity based on the attack vector, complexity, and impact. Thus with risk-based, context-aware prioritization, the security team can place its focus on vulnerabilities that need utmost priority.
3. Remediate vulnerabilities
Once prioritized, vulnerabilities must be disclosed to and addressed by the respective team(s) or member(s) responsible for that part of the system be it database, or front end or back end configurations.
In most cases, remediation involves either applying a temporary patch or providing a software version upgrade.
Remediation times can vary depending on the severity and impact of the vulnerability or time taken to develop the patch. Extra care must be taken to ensure that there are no unintended consequences while remediating. Because it is not uncommon for short term patch fixes to cause sudden system downtime or cause some other functionalities to stop working.
4. Monitor for new vulnerabilities
Just like monitoring for performance in DevOps, monitoring for vulnerabilities is also a continuous and ever lasting process. Automating this step with the right tools that send real-time alerts and notifications for newly discovered vulnerabilities is the way forward. Other activities that vulnerability response teams do are log analysis, and visualizing security data for in-depth analysis.
It is ideal if the monitoring tool can assist teams with contextual prioritization, as and when the vulnerability gets detected. This would reduce MTTR and provide a clear point of action for responders. Or else extra care should be taken to reduce alert noise and not overwhelm responders with too many alerts. If the team is alerted for too many non-critical alerts, it will quickly lead to burnout and alert fatigue.
Conclusion
OpsMx’s Secure Software Delivery (SSD) I hope this blog helped you understand the need to effectively manage vulnerabilities in production, and why you should respond to them on time. In my next blog in this series, I will talk about the shortcomings of this traditional approach to Vulnerability Remediation, and how OpsMx’s Secure Software Delivery capabilities makes Vulnerability management a breeze. I would recommend you to read it if you are a DevOps Engineer or a Release Engineer or an SRE whose work revolves around Software Delivery/ Software Deployment.
0 Comments