Security in today’s digital landscape isn’t just about identifying vulnerabilities–it’s about resolving them as quickly, efficiently and effectively as possible across a distributed network of stakeholders. Understanding who they are and how to navigate their individual needs is key. But are manual approaches enough?
For every insight detected by vulnerability and misconfiguration scanners, security teams must orchestrate a response. This is quite the challenge in today’s distributed enterprise environments, where the remediation process often involves individuals and teams belonging to departments outside security. Finding them usually requires manual communication, tracing elusive connections from software packages or VM instance names – a convoluted process that eats away at precious time and resources.
Let’s dive into how to streamline the identification of key security remediation stakeholders. But first, it’s fundamental to understand who they are.
The Key Players of Security Remediation
In a typical security remediation process, we can break down stakeholders into three archetypes. Each is typically accompanied by their respective priorities and constraints, and understanding how to make each process fit the needs of all is paramount to lasting success.
Practitioners: These are the individuals or teams responsible for executing the remediation process, such as developers or system engineers. Their primary focus is on efficiently fixing vulnerabilities without causing interruptions or delays. They often face tight schedules and have limited resources for addressing vulnerabilities while simultaneously managing their primary tasks. Many also lack the specialized skill sets often required to carry out remediation processes.
Resource Allocators: These are the decision-makers responsible for distributing engineering resources, such as team leaders and project managers. Given that their resources are finite, they must balance their priorities across many projects and systems, prioritizing vulnerabilities based on the potential risk they pose to the organization. Resource allocators are typically preoccupied with preventing bottlenecks in other essential projects.
End-Users: These are the customers of the system or service in question. Their primary concern is uninterrupted access to the system, and it is important to keep them informed about any possible disruptions or changes that may accompany security updates.
Consider the interplay between these various priorities and concerns and how clashes can affect time-to-fix. For example, the Practitioner's need for effective remediation might clash with the Allocator's resource constraints. Or, the End-User's need for service continuity might create constraints for the Practitioner responsible for implementing fixes without causing disruptions.
Tracking Down the Right Stakeholder
Effective communication, collaborative decision-making, and leveraging automated tools can help mitigate these challenges. We also recommend two approaches for identifying the right stakeholder:
Organizational Mapping by BU: This approach involves structuring an organization into abstract containers known as business units with pre-assigned stakeholders. Resource Allocators can utilize a directory to manage remediation requests, removing the burden of resource management from security engineering teams. Centralizing contact points and streamlining the remediation process are advantageous, though defining these units accurately requires thorough and upfront planning. It is also important to recall that even meticulous planning can be complicated by instances of multiple stakeholders, given that different teams or individuals often specialize in managing specific types of resources or technologies.
Resource Creator Tracking: Another method for identifying stakeholders involves assigning the remediation task directly to the creator of the resource requiring attention. For example, assigning remediation tasks for code-related vulnerabilities can be facilitated by tools like git blame. Similarly, in cloud environments like AWS, tracking creation events through logs or metadata can identify the user responsible for the resource. However, this approach isn’t foolproof either. It can be made particularly difficult by employee turnover or by logs that are missing critical information.
For maximal efficiency, it is best to combine these two approaches and introduce automation wherever possible. Pairing a designated security champion or infrastructure manager with the resource creator who has technical knowledge can expedite the process. Leveraging automated tools to identify stakeholders, organize business units, and automatically allocate tickets, when integrated within an existing security stack, can significantly improve managing queries and remediating numerous vulnerabilities.
Putting Advice into Practice
Let's try identifying resource creators using only the two methodologies outlined above.
In our first hypothetical scenario, a vulnerability alert surfaces from a SAST or SCA scanner, tied to a specific code repository. To determine who should address the issue, it is critical to pinpoint the code committer first. By employing the git blame command, the following developer's email appears:
git blame <package management file> | grep -n "<packagename>"
We’ve now found our possible stakeholder, but verification is necessary. If the developer no longer belongs to the organization or worked on the code as a third party, the security engineer responsible for tracking them down might need to seek the team leader's details from the repository platform.
In another example, a vulnerability on an AWS EC2 instance complicates locating its owner as AWS metadata does not show creators by default. This makes it necessary to enforce EC2 tagging ('system owner') or retrieving creation events from CloudTrail logs in the absence of tags. However, CloudTrail logs are time-limited (typically three months), posing a challenge for older EC2 instances. Additionally, deployment tools like Jenkins might display the tool user in logs, necessitating tracing back to Infrastructure as Code (IaC) for clarity. Searching for the instance ID under the "RunInstances" event in CloudTrail logs can identify the creator's username.
Remediation Needs a Technical Boost
These examples underscore the technical challenges and time consumption involved in identifying resource owners. Each query for thousands of vulnerabilities demands considerable time, given how much cloud provider log structures and tools can vary. By offering queries to identify owners, integrating tools for necessary data, and automating ticket allocation based on defined rules and business units, a vulnerability remediation platform provides the necessary technical capabilities for security teams to navigate the complicated maze of stakeholders far more efficiently and effectively.
Discover how Opus’ can accomplish most of the heavy lifting. Contact us to schedule a demo!
