Designing and Building a Security Operations Center


Posted on by Ben Rothke

Many organizations are overwhelmed by the onslaught of security data from disparate systems, platforms and applications. They have numerous point solutions (anti-virus, firewalls, IDS/IPS, ERP, access control, IdM, single sign-on, etc.) that can create millions of daily log messages. In addition to directed attacks becoming more frequent and sophisticated, there are regulatory compliance issues that place increasing burden on security, systems and network administrators.

This creates a large amount of information and log data without a formal mechanism to deal with it. This has led to many organizations creating a security operations center (SOC). A SOC in its most basic form is the centralized team that deals with information security incidents and related issues.

In Designing and Building a Security Operations Center, author David Nathans provides the basics on how that can be done. An effective SOC provides the benefit of speed of response time to a security incident. Be it a DDoS attack or malware which can spread throughout a corporate network in minutes, and potentially knock out the network, every second counts in identifying these attacks and negating them before they can cause additional damage. Having a responsive SOC can make all the difference in how a firms deals with these security issues.

soc1

The book notes that the SOC is akin to an enterprise nervous system that can gather and normalize vast amounts of log and related data. This can provide continuous prevention, protection and detection by providing response capabilities against threats, remotely exploitable vulnerabilities and real-time incidents on the monitored network.

The books 11 chapters provide a start for anyone considering building out their own SOC. Topics include required infrastructure, organizational structure, staffing and daily operations, to training, metrics, outsourcing and more.

When building a SOC, the choices are for the most part doing it yourself (DIY) or using an outsourced managed security service provider (MSSP). The book focuses primarily on the DIY approach, while chapter 10 briefly details the issues and benefits of using a MSSP. The book provides the pros and cons of each approach. Some firms have a hybrid approach where they perform some SOC activities and outsource others. But the book doesn’t details that approach.

The book provides a large amount of details on the many tasks needed to create an internal SOC. The truth is that many firms simply don’t have the staff and budget needed to support an internal SOC. They also don’t have the budget for an MSSP. With that, Mike Rothman of Securosis noted that these firms are “trapped on the hamster wheel of pain, reacting without sufficient visibility, but without time to invest in gaining that much-needed visibility into threats without diving deep into raw log files”.

One important topic the book does not cover is around SIM/SIEM/SEM software. SIEM software can provide a firm with real-time analysis of security alerts generated by network and security hardware, software and other applications.

Many benefits come from an effective SIEM tool being the backbone of the SOC. A SIEM tool consolidates all data and analyzes it intelligently and provides visualization into the environment. But selecting the appropriate SIEM and correctly deploying it is not a trivial endeavor.

Gartner notes that organizations evaluating SIEM tools should begin with a requirements definition effort that includes IT security, IT operations, internal audit and compliance. Organizations must determine deployment scale, real-time monitoring, postcapture analytics and compliance reporting requirements. In addition, organizations should identify products whose deployment and support requirements are good matches to internal project and support capabilities.

To do this, Gartner recommends developing a set of requirements that resolve the initial problem. However, there should also be some planning for the broader implementation of SIEM capabilities in subsequent project phases. Developing a two- to three-year road map for all functions will ensure that the buying decision considers longer-term functional and scaling requirements. Be ready to evolve the plan in response to changes in IT, business requirements and threats.  As you can see, SIEM is indeed a big deal.

Those looking for a good reference on SIEM should read: Security Information and Event Management (SIEM) Implementation, reviewed here. That book does provide an excellent overview of the topic and will be of value to those reading looking for answer around SIEM. Those looking for a solid introduction to the world of SIEM should definitely get a copy.

The book notes that the most important part of a SOC, and often the most overlooked, is that of the SOC analyst. And with that, the book writes how it’s important to be cognizant of the fact of SOC analyst burnout. SOC analysts can burnout and it’s important for an organization to have a plan to address this, including aspects of training, management opportunities and job rotation.

Building an in-house SOC takes significant planning an attention to detail and the book details a lot of the particulars that are required for an effective SOC design.

The implementation of a SOC will cost a significant amount of money and management will often want to have metrics to let them know what the SOC is doing. The book spends a brief amount of time on SOC metrics; which is a topic that warrants a book in its own right. There are many metrics that can be created to measure SOC efficacy. Effective SOC metrics will measure how quickly incidents are handled by the SOC, and how incident are identified, addressed and handled.

The downside to metrics is that they must be used judiciously. It’s important not to measure base performance of a SOC analyst simply on the number of events analyzed or recommendations written. Metrics used in that manner are akin to help desk where analysts are only concerned about getting calls finished, in order to meet their calls completed metrics.

As important as a SOC is, this is surprisingly the first book written on the topic. At under 250 pages, the book provides an introduction to the topic, but is not a comprehensive work on the topic. There are areas in SOC management that the book doesn’t cover, such as SOC documentation, creating and using SOC operation run books, and more.

But even with those missing areas Designing and Building a Security Operations Center is a good reference to start with. A SOC is a security component most organizations are in dire need of, and the book is a good way to get them started on that effort.


Contributors
Ben Rothke

Senior Information Security Manager, Tapad

risk management data security threat intelligence security operations

Blogs posted to the RSAConference.com website are intended for educational purposes only and do not replace independent professional judgment. Statements of fact and opinions expressed are those of the blog author individually and, unless expressly stated to the contrary, are not the opinion or position of RSA Conference™, or any other co-sponsors. RSA Conference does not endorse or approve, and assumes no responsibility for, the content, accuracy or completeness of the information presented in this blog.


Share With Your Community

Related Blogs