Slashdot Mirror
Book Review: Designing and Building a Security Operations Center
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
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
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.
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.
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.
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.
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)
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 the executive team/customers on a regular basis
4. When it gets too expensive, outsource the monitoring staff to one of the third parties working with the consultants in Step 1.
Now this book comes out explaining that a SOC is basically just a bunch of smart (expensive) people intelligently mining data? Those consultants who do this for a living must want to hunt this guy down...
Seriously, I'm in systems integration and I can't count the number of Magical Vendor Tools used in operations that I've had to work with and/or get working. Operations seems especially vulnerable to software salesmen offering magic cures to operational headaches.
u r obviously a closet obama supporter!
I concur..
this may be Slashdot....but it is no place for racism.
I'm no psychologist....but you are a psycho!
I long for the old days where there was intelligent comments on Slashdot...
You are a farce.
Now I know who American Psycho is written about.....
Using most anti-virus software could be actually considered harmful now due to multiple privacy and security violations, e.g. outsourcing your files "to the cloud" by Avast client if you participate in Community IQ or Avast FileRep.
this was a decent book review but no intelligent replies..
there was a racist reply...a guy from avast peddling his wares...but no back and forth dialogue about the issues.
is slashdot dead?
u crazy and u angry!!!!