Building the Security Operations Center (SOC)

Whether defending against common malware or some determined Nation State, being able to proactively detect attacks and changes in the organization are required.  The past year I spent a large amount of time helping several organizations setup and put in place the right people, processes, and technology to help defend against increasing security threats.  Although many organizations spend millions of dollars on technology and hire staff to monitor security 24/7 the organizations were still lacking two fundamental items.

  1. The people although good at monitoring lacked the attack and threat mind set.  The staff was not able to figure out when an actual attack was happening.
  2. Second the organizations lacked the basic security operations processes required to keep track and make appropriate use of the vast amounts of data.

As a result I spent the past few months developing a whitepaper that specifically addresses the primary components of a SOC, which can be used to help organizations setup a centralized core and embark on developing the correct operational processes.  Although I don’t address item number one above, this paper explains in detail the following.

  • Defining the SOC
  • Determining the Processes
  • Understanding the Environment that needs protected
  • Identifying the SOC Customers
  • Staffing the SOC
  • Managing the Events
  • Leveraging ITIL compliance

Creating and Maintaining a SOC – The details behind successful Security Operations Centers

If your organization is under attack and you have invested in more people and technology be sure to implement the right processes and build a foundation for future defense.

HIPAA and the Stimulus Bill

Is HIPAA Really changing?

Here is a good summary link of the changes.

I think John did a good job outlining the key changes.  There is no point in regurgitating the information he has already covered in detail.  Overall there are changes to penalties, new breach rules, business associate responsibilities, and more.

What I find interesting is that according to his article HHS is now responsible for issuing guidance specifying technologies and methodologies.  To date I haven’t seen anything yet posted on their site, but they have until February 17, 2010 before the Act is in effect.

I believe many government based organizations currently fail these controls miserably.  It will be good to start seeing some accountability.  I just hope they lay out the expectations clearly unlike when PCI was first issued.  I also hope there is some visibility into the ratings of each entity moving forward.

In the meantime here are a few good older links to help entities make sure they are at least in tune with current expectations.

Authoritative List of Compliance Documents

For anyone looking to find or understand the main key compliance documents across the following industries, regulations, regions of the world the link below has a good list.

(Link Updated Sept. 2012)

Industries, Regulations, Regions:

  • Sarbanes Oxley Guidance
  • Banking and Finance Guidance
  • NASD NYSE Guidance
  • Healthcare and Life Science Guidance
  • Energy Guidance
  • US Federal Security Guidance
  • US Internal Revenue Guidance
  • Records Management Guidance
  • NIST Guidance
  • ISO Guidance
  • ITIL Guidance
  • US Federal Privacy Guidance
  • US State Laws Guidance
  • EU Guidance
  • UK and Canadian Guidance
  • Other European and African Guidance
  • Asia and Pacific Rim Guidance
  • System Configuration Guidance

Also, some of these are already linked off this site.  If anyone is feeling like they have some free time feel free to send me links to the listed documents and I will add them to the Links page.

Working Toward ISO 17799/27001 Business Continuity Management Compliance

This document is written with the assumption that the organization follows ISO and has implemented many of the controls (including Disaster Recovery), but may be lacking in the area of business continuity management. This document aims to consolidate and leverage the work already done for other ISO controls to jumpstart the BCP compliance efforts.


The first step in compliance is to develop and implement a BCP management process.  The process needs to identify the critical business processes within the organization and incorporate management requirements.



  1. Identify critical business processes and associated assets.  Create a template or leverage the disaster recovery (DR) documentation (Note:  The DR information may not be complete enough as it usually only includes recovery of technology functions and may exclude important business functions or process that do not rely on technology.) and send to managers requiring them to document their critical business processes by location.
  2. Identify the consequences in the event of a disaster.  Again most of this should be in a DR plan.
  3. Identify controls to reduce risk.
  4. Ensure information for business operations is available.
  5. Ensure BCP is integrated within business processes and includes security.
  6. Ensure that plans are updated and tested on a regular basis.


Below is a sample that can be used and quickly put together to help meet some of this compliance.  Use Excel and list the critical business processes in a matrix associated with each geographic location as shown below.




The next step is to identity the results of different events by doing a business impact analysis.  Continuity plans have to be developed to for quick restoration of operations and should be integrated with information security and other key management processes.  Controls that can be put in place to reduce risk should be identified.


The Threat should define “Who”

The Event should define “What, Where, and When”




The table below is an expansion of the above.  (Threats are repeated for consistency)




After the assessment the following must be done:

  • Continuity plan(s) must be created.
  • Roles and responsibilities must be documented.  Most should have already been done for other ISO controls, but there may need to be a few short statements added to reflect business continuity compliance.
  • Procedures and processes must be documented.  Many of these should have already been documented as a part of incident response, disaster recovery, change control, and other standard operations.  A few additional procedures may need to be created like the process of documenting and updating plans.


Plans must have the same framework.  This means all departmental plans must be a on a standard template.  A centralized escalation and evacuation plan should be developed.  Evacuation plans can simply state follow building evacuation procedures.  Escalation plans in most cases can follow standard disaster, emergency services, or incident response plans.


Plans need to address:

  • Roles and responsibilities of key staff (i.e. BCP coordinator, executive management, and users)
  • Summary pointing to the documents that have recovery procedures for operations.  In many cases these procedures are in the disaster recovery area or part of the standard operating function.
  • Testing of plans.  This needs to track and schedule each element and when its tested. 
  • Storage of plans at alternate locations
  • Ownership of plans
  • Fallback procedures
  • Resumption procedures
  • Awareness and Training
  • Review of plan(s)


Putting everything important together is the key to the business continuity plan.  Many of the items above exist within many organizations but they have not been organized or consolidated in one area.  A document detailing each of these items and consolidating them all in one location is the key to passing the assessment.  If you are already working towards ISO compliance then Business Continuity Management is just one more minor component that can be accomplished quickly by consolidating a large amount of information in one place and creating a document (plan) that organizes and explains everything that needs to be done with these documents if there disruption to business operations.  In some cases there may need to be department level plans that are a close mirror to the main plan but focus more on departmental operations.  Some assessments will look for both centralized and departmental plans.


For more information you can also review that actual ISO/IEC 17799/27001 documentation and the BS 25999-2 Specification.