Book Review: Designing and Building a Security Operations Center 29
benrothke writes 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. Keep reading for the rest of Ben's review
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. | Designing and Building a Security Operations Center | |
| author | David Nathans |
| pages | 276 |
| publisher | Syngress |
| rating | 8/10 |
| reviewer | Ben Rothke |
| ISBN | 978-0128008997 |
| summary | Good introduction to those looking to build their own security operations center |
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 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.
Those looking for a good reference on SIEM should read: Security Information and Event Management (SIEM) Implementation, which I reviewed on Slashdot. 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.
Reviewed by Ben Rothke.
You can purchase Designing and Building a Security Operations Center from amazon.com. Slashdot welcomes readers' book reviews (sci-fi included) -- to see your own review here, read the book review guidelines, then visit the submission page. If you'd like to see what books we have available from our review library please let us know.
My experience is different. (Score:4, Insightful)
In my experience it is not the budget but the politics.
Is your company's security worth the expense of an additional tech? Or are office politics the reason you cannot get an additional tech?
Does whomever is in charge of your technology have the authority to say "no" to requests from other departments? And the political capital to make it stick?
I've seen too many examples of companies "suffering" from the problems their own decisions/environment created.
Retrofitting security is not the answer.
Re: (Score:3)
>> In my experience it is not the budget but the politics.
Politics are usually about budget. You really can't separate the two.
>> Is your company's security worth the expense of an additional tech? Or are office politics the reason you cannot get an additional tech?
This is an entry-level "think of the children" argument. Come back when you can express your needs for an additional tech in downtime, lost customers, etc. (i.e., money).
>> Does whomever is in charge of your technology have th
Re: (Score:2)
Until failing to follow them costs the company millions due to $problem. Then, they'll fire half of IT, make the other half do two jobs in addition to demanding the highest standards while giving no budgetary or political support.
lather.. rinse.. repeat..
Step One: Build a separate silo (Score:2)
Step One: Build a separate silo. You sure as hell wouldn't want to share data/equipment/space/staff/etc. with your existing NOC.
Step Two: Replace your existing SIEM.
Step Three: ??? (Don't worry, you'll never get here: see "Step Two")
Step Four: PROFIT (or at least play the official anthem of your little fiefdom)
Re:Step One: Build a separate silo (Score:4, Funny)
Step 1.5: Show still images from the CTU on 24 as an example of "doing it right".
Everybody knows you're serious if you have giant, wall-mount displays showing your threat statistics, a world map showing the ISS positional telemetry and a half-dozen cable news channels.
Bonus points if you include several giant red buttons throughout the room with clear plastic safety covers over them with red sirens mounted over them. People will be reassured knowing you can hit the big red button when you need to.
Re: (Score:2)
Bonus points if you include several giant red buttons throughout the room with clear plastic safety covers over them with red sirens mounted over them. People will be reassured knowing you can hit the big red button when you need to.
For bonus points they should be hooked to the network cabling so that hitting the red button air gaps every machine you have.
Funny thing about this... (Score:2, Insightful)
In my experience, large companies that build any IT component that ends in "Operations Center" end up doing the following:
1. Spend millions on ill-suited software tools and consultants
2. Build a state-of-the-art "command center" staffed 24/7 with people literally staring at projected screens with interesting-looking data (maps, traffic charts, etc.) Almost every one I've seen looks like the bridge of a Star Trek starship, complete with low lighting and "red alert" lights.
3. Show off said command center to t
Re: (Score:2)
Now this book comes out explaining that a SOC is basically just a bunch of smart (expensive) people intelligently mining data?
The hard part is finding the capable (expensive) people, even if you are willing to pay a lot. Programmers and IT guys are not hard to find in America, but capable ones are.