State of the SOC and Using SIEM
Security operations centers (SOCs) need to be able to respond to any kind of alert, attack or incident quickly and effectively while running lean teams and proving ROI to their executives. Accomplishing this requires highly skilled and trained personnel, well-documented processes and finely-tuned technologies. Unfortunately, not many SOCs are blessed with this magic combination. Instead, they have to manage a daily deluge of alerts from an ever-evolving threat landscape and sophisticated bad actors with constant personnel churn and disparate tools and processes. In this typical environment, it takes too long for an analyst to receive an alert, read and comprehend its key details, copy and paste the data into other tools to verify that it is not a false positive, and then take action to stop the attack and begin remediation. Organizations cannot afford to be left vulnerable for that amount of time.
But we have a SIEM.
A security information and event management (SIEM) system is what most SOCs are now using to combat the dire issues described above. The thing about a SIEM, is it typically generates a massive volume of information, making it difficult for SOCs to keep up. In fact, according to recent Enterprise Management Associates (EMA) research, 64% of the security tickets generated per day go uninvestigated because of a lack of manpower.
While a SIEM solution helps capture alert data, it is not a Big Data tool. Security teams need Big Data tools to mine the large sets of data that accompany SIEM alerts to make snap decisions and identify patterns and trends. Organizations are looking at the tooling and the resources they have at their disposal—whether that is data management, data pipeline or even cloud computing—and wondering why they don’t have access to those similar tools on the security side. As organizations migrate more and more of their resources—especially their log aggregation, log management and data analytics—to the cloud, they are starting to look at SIEM along with what tooling is available natively within those infrastructures. Ideally, teams would leverage the same technology stack and the same resources they have internally from a development and engineering perspective for security operations.
Enter automation.
In an effort to keep up with SIEM alerts, SOCs are implementing automation. Teams are automating tasks such as log standardization, log management, log aggregation, and the investigation and the review of log data via correlated alerts, to name a few. Obviously, it is not possible to review every log alert. Rather, the goal is to automate the aggregation and analysis of that logging information. And yes, organizations have been relatively successfully in implementing automation on this level over the past decade.
However, all that really did was stem the top of the funnel relative to the amount of work that people had to do because there has been limited automation for the people component of security operations (SecOps). By automating as much as they could, organizations were really focused on prioritization or deduplication. To truly take advantage of automation, we must rethink our approach and identify opportunities earlier in the lifecycle of an attack. For example, are there earlier key performance indicators that identify something that doesn’t require correlation or analytics on which we can take action? Organizations are beginning to realize the technologies feeding their SIEM or their data lake are hi fidelity and actionable in their original state and don’t require so much of that processing.
So, today’s SOC needs better automation. Is that all?
As an organization scales its resources, what happens when detections occur, and actions are required? Considering the number of cloud-based and other resources constantly being added, where should detections and actions be handled? The surface area is constantly and rapidly expanding with a plethora of new internet of things (IoT) devices, virtualization, mobile devices, containerization and other changes and additions that must be monitored. Each one of these technologies has its own infrastructure requirements, monitoring requirements, security, patching and vulnerability assessment requirements. When we look at the projected number of IP-enabled devices moving as high as 100 billion devices over the next 5-10 years, the number of things that we must do to keep that safe is just mind boggling. The flexibility and ability to scale across that surface area is incredibly important for organizations as they look at building security operations that are forward looking. So, in short, the answer is “no.” Improving automation in the SOC is not all.
In the next two installations of this three-part blog series, we will take a look at how security orchestration, automation and response (SOAR) is working to alleviate the issues described here in the current state of the SOC and what organizations should keep in mind for a new decade of SecOps.
*** This is a Security Bloggers Network syndicated blog from Swimlane (en-US) authored by Jay Spann. Read the original post at: https://swimlane.com/blog/the-past-present-and-future-of-soar-current-state-of-the-soc/