5G/SOC Presentation at HP PROTECT Washington DC

I’ll be presenting session BB3055 “5G/SOC: How the world’s most advanced SOCs are leading the way” on Tuesday 5th September at 17:50 at HP PROTECT in Washinton DC – talk about a graveyard shift!

“If we’ve learned anything from all the media attention given to data breaches in the past few years, it’s that no matter who you are, someone out there wants to steal your critical data. The type of data varies, but everyone has something worth stealing. Today’s mature SOC teams are incorporating new technologies, sharing information, and expanding their focus outside of the enterprise to include the modeling of attacker activities and personas. We are now entering the fifth generation of security operations, or what we like to call the 5G SOC. Hear more about the 5G SOCs of today–which monitor more than ever before–and how they change the focus from simply monitoring systems to monitoring the actors perpetrating the attacks. Benefit from 5G SOCs looking beyond their enterprises’ borders and tracking activities in social media, changes in global politics, and shifts in attacker economics in order to discover threats and act on them.

SOC Mistake #10: You confuse your SOC with your NOC

Network Operations Centres (NOCs) are responsible for the operational monitoring of infrastructure and services. Their function is to identify, investigate, prioritise and escalate/resolve issues that could, or do, effect performance or availability. A Security Operation Centre (SOC) shares much in common with a NOC, it’s function is to identify, investigate, prioritise and escalate/resolve issues that could, or do, effect the security of an organisation’s information assets.

It is no surprise then that I am frequently asked by customers looking to build a SOC “Why can’t we use our NOC for this function?”. I can understand the motivation behind this question, once you’ve stood up your Security Information & Event Management (SIEM) platform, identified your use cases, got the right event sources feeding events into the SIEM and then got your SOC procedures nailed, the largest cost of running a SOC is typically headcount.

There are, however, a few reasons why a combined SOC and NOC isn’t always a good idea:

1. They serve different, often conflicting, masters.

Within organisations there is often a conflict between operations and information security teams – information security want to pull the plug on an compromised server that happens to be hosting a critical service; they want vulnerabilities patched as soon as they are available, often without fully testing the impact on operations; they can’t understand why dealing with an incident isn’t always the top priority for the operations team. Likewise, operations often stand-up new pieces of infrastructure without notifying the security team or going through change control; they may not fully harden platforms prior to deployment to “meet a tight deadline”, we’ll come back and patch it later; they may not apply critical patches through lack of a testing environment.

The NOC is measured and compensated for its ability to meet Service Level Agreements (SLAs) for network and application availability, Mean Time Between Failures and application response time. In contrast SOCs are measured on how well they protects against malware; their protection intellectual property and customer data; and ensuring that corporate information assets aren’t misused. The business driver behind both of these is to manage business risks – in a NOC, for instance, the loss of revenue or compensation for breach of an SLA; in a SOC, regulatory fines or loss of customer confidence.

NOCs are about availability and performance, SOCs are about security. Even with the best intentions, having the team responsible for availability and performance make decisions about incident response and the application of controls that will, invariably, impact on the availability and performance of services (even if it is just through the diversion of human resources), is never going to work well.

NOCs and SOCs certainly should be in close co-ordination. One of the best ways of achieving this is to ensure the NOC has a view on of the SIEM platform. I’ve seen SOCs react to “large scale Distributed Denial of Service attacks” that have been the result of legitimate traffic after the launch of a new service, and I’ve seen subtle patterns detected by alert NOC analysts result in uncovering wide-scale penetrations within organisations. When it comes to actually responding to a confirmed incident, operations and information security must work hand-in-hand to investigate, contain, eradicate and recover from the attack with appropriate and proportionate responses. Working together in a collaborative manner as a part of an incident response team, a SOC and NOC help ensure that right balance.

A well-implemented collaboration strategy between a NOC and SOC should identify that the SOC’s function is to analyse security issues and to recommend fixes and then the NOC analyses the impacts of those fixes on the
business, makes recommendations on whether to apply the fix, makes the appropriate approved changes and then documents those changes.

2. The skills needed in, and the responses required from, a NOC analyst
and SOC analyst are vastly different

NOC analysts require a proficiency in network, systems and application engineering, whereas SOC analysts require skills in security engineering. The tools and processes used for monitoring and investigating events also differ, as does the interpretation of the data they produce: A NOC analyst may interpret a device outage as an indicator of hardware failure, while a SOC analyst may interpret that same event as evidence of a compromised device. Likewise, using the example I gave above, high bandwidth utilisation will cause the NOC to take steps to ensure availability, in contrast the SOC may first question the cause of the traffic spike, the reputation of it’s origin and correlations against other known attacks.

One of the biggest differences between a SOC and a NOC is that a SOC is looking for “intelligent adversaries” as opposed to naturally occurring system events such as network outages, system crashes and disk failures. While these naturally occurring systen events can, in fact, be caused by the actions of “intelligent adversaries”, their concern is about the restoration of the quality of service as soon as possible – even if this involves the destruction of evidence that would allow the investigation of the cause.

3. Staff attrition is waaaaaay worse in a SOC

Level 1 SOC Analysts, those responsible for the triage of incoming events burn out with often alarming regularity. The average tenure of a Level 1 SOC Analyst is typically less than two years and can be as high as 20% per annum. In contrast the tenure and turnover of NOC staff is typically much better.

This attrition within a SOC needs to be planned for with a suitable feeder pool of new candidates and an effective on-boarding training scheme to teach them about the use of the SIEM platform, the analytical skills need to investigate incidents and internal procedures. Developing a career progression plan for your analysts will also allow you to retain these valuable resources within your business, potentially moving them to security engineering or incident response positions.

Despite everything I’ve said above it is possible to run an effective coverage SOC/NOC, but it can take more effort, operational expense and better governance than running them as separate functions. The potential benefits can lie through the introduction of a single point-of-contact for all security and operational issues, as well as the tight integration between those who discover and react to information security incidents, and those who have to deploy and manage the mitigations post event. Whether you choose to keep the functions separate or integrate them, it is important to understand the differences between the functions.

University of Washington Introduction to Data Science on Coursera

I’m currently working through the excellent Introduction to Data Science course from the University of Washington on Coursera.

I would say that the course requires a reasonable knowledge of Python programming in order to handle most of the assignments, but there are plenty of resources out there to help you with this too.  Overall the video lectures are well delivered with excellent references given for addition reading.

The main topics covered are:

  • Introduction to Data Science;
  • Relational Databases, Relational Algebra;
  • MapReduce;
  • NoSQL;
  • Statistics;
  • Machine Learning;
  • Visualisation; and
  • Graph Analytics

The course runs over 8 weeks with around 12 hours a week needed to complete the lectures and assignments.   The University of Washington haven’t announced the dates for the next intake, but in the past it’s been around May.

B-Sides Manchester 2014: What #SOCFail looks like, and how to avoid it: AKA sort your “little” data out before going BIG

533dd4_05b32d465d6e4a1ca3f2a59d07b3625c.jpg_srz_p_239_207_75_22_0.50_1.20_0I’m presenting at B-Sides Manchester in Track 2 at 13:00 next week on on 27 June 2014.

The presentation takes a humorous view at what #SOCFail looks like, focusing on the top 10 mistakes made by organisations building Security Operations Centres.  In addition, we’ll discuss how to avoid these pitfalls, discuss what a good SOC looks like and list some emerging trends in event detection, investigation and response.

State of Security Operations Report

Today our practice has puSecOpsRepblished the first State of Security Operations Report, which looks at the trends, best practicesand key capabilities we’ve observed in over

Security Operations Maturity Assessments we’ve conducted over the past few years.

The Security Operations Maturity Assessment looks at over 160 difference aspects of business alignment, governance, people, process and technology involved in running an effective and efficient Security Operations Centre.  The report highlights both the positive trends and common mistakes we’re seeing across all vertical markets and territories.

We’re hoping that the report will become an annual release.

 



5