4 Cyber security operations lessons from MSSPs

There has been a massive up-swing in the formation, growth and adoption of managed security service providers (MSSP) in recent years.  This has been driven by a number of trends such as the ever-growing cyber threat, the increase in the complexity and openness of technology systems, the shortage of cyber security skills (and the resulting difficulty in attracting and retaining good people) and the heightened regulatory and consumer pressures to protect systems and data.

Out-source or in-source cyber security

For end-user companies that want to make use of outsourced MSSP services, the increases in market availability of cyber security-as-a-service is a good thing, the competition means they can choose service types or service levels that match their needs, save money and gain additional assurance by transferring security monitoring, alert investigation or incident response support to an expert third party.

For others however, there is a need or preference to run security “services” such as monitoring or alert management in-house as part of the operational delivery of the security function, with ties into the IT delivery team, the risk and compliance function and under the control of a permanent management team working with employed security experts.

Irrespective of the reasons for this decision, it is useful to see what market and competitive pressures mean for managed security service providers (see this case-study paper).  Their need to survive/prosper and deliver high-quality services in an efficient way is vital for their entire business – and it can provide lessons on how to operate security internally for businesses who are aiming to achieve the same outcomes.

Define Security Operations Processes

MSSPs must determine the processes and services they are going to offer – to know what is standard and common across customers and what can be customised.  Otherwise they run the risk of managing each customer differently and gaining no economies of scale.  Moreover, if they don’t know what they are going to be offering how will they shape sales conversations or know what the dependencies are that will drive technology choices?

For in-house teams there is no sales imperative, but there is a need to justify the spend and costs of operation as part of the budget to senior management (in fact as an alternative to outsourcing, running security in-house does need to be “competitive”).

There is also a need to understand what the team is going to do, what they will be trying to achieve and how they plan to do it so that they can specify requirements and make technology decisions based on this; rather than buying technology and then trying to fit “what they do” around its capabilities.

Think Efficiency: Time per event/alert/issue/activity

For an MSSP with a large number of customers spread across a finite pool of staff it is imperative to track the amount of time that is spent on each activity.  Part of the value of an MSSP for the end user is that they don’t have to retain their own team of highly skilled analysts.  But for the MSSP those highly skilled experts come at a cost and that cost needs to be shared across a number of customers and activities in the most efficient way.

The amount of time each analyst spends on a “per customer” basis, or what the minimum/average/maximum time is to deal with each “incoming alert” or “confirmed incident” really matters.

Factors that can affect this are the intuitiveness and ease of use of the technology solutions, but also the degree of automation, standardisation and pre-configuration that can be employed.  If system can do the moving, formatting, processing of data itself, then people don’t have to – they can work off the results of analysis rather than having to perform it themselves.

Having humans gather data, issue the same queries repeatedly, generate reports manually, confirm the presence of indicators of compromise, take a parameter from one system and look it up on another – these all take time and can be done by systems that support the human process in a pro-active way – using automation and providing tools to help orchestrate investigations and response (See this blog post), rather than just sitting waiting to be told what to do by a human operator or answer queries that have been manually submitted.

Machines can help accomplish tasks much more easily

One entity or separate sub-domains

When Huntsman Security talks to MSSPs offering monitoring or threat detection they invariably have a need to be able to host multiple customers on the same technology platform. This provides a number of benefits, it allows the use of common reporting and alerting profiles (e.g. one single point for unifying threat intelligence and rule/policy configuration) and means that operations teams can have a single window across the whole customer estate, as well as drilling in to answer queries or respond to events within a particular customer silo when an alert or threat arises.

Silos exist inside business and between MSSP customers

This “single technology platform” must provide a robust solution to multi-tenancy, allowing full and effective separation of customer data and the means to deploy different service types, rules, service levels, reporting schedules and data storage requirements in each case based on either the service level or threat profile.

It is easy to assume that for an enterprise customer this isn’t a requirement, but in fact commonly this need does exist.  Certainly, it might be possible within a single business to allow for less strict controls on access to/separation of data; but divisions between parts of an enterprise network may still need to be retained and so the same need for some form of multi-tenancy is present.  This might arise due to:

• Separate business units, subsidiaries, acquisitions or corporate entities sharing the same network/security environment.
• Diverse physical sites with different IT domains and risk profiles (data centres, offices, retail/customer spaces, web server farms).
• Different needs for security policy and operations such as between an IT environment and a SCADA/process control/OT network.
• Separate regional businesses that need to comply with local laws and implement local security regulations around control implementation or monitoring.
• Variable risk profiles and regulatory pressures for systems of different types – for example finance systems at a heightened level as opposed to more routine parts of an enterprise network such a file/print servers.
• Workflows and escalation paths for alerts and reports that differ based on responsibility for systems or the applications.

In all these cases making the security toolset and operations too homogeneous will cause problems and lead either to a race to the bottom or to the top – delivering an average level or service to all parts of the business rather than a tailored one. Both are big risks and/or expensive; hence MSSP-influenced multi-tenancy for separate security domains may be the way to go even in the enterprise/end-user space.

Up-front costs or ones that grow, and how fast?

One thing MSSPs (in particular new ones) struggle with is making large up-front capital investments. The nature of their business growth plan means that they will onboard customers at a gradual rate.  Anything that has to allow for the eventual size of the business and has to be paid for up front is often unworkable as the ROI is too long and/or the initial cost too high to merit the business case for doing it at all.  Also, the “capacity” that has been bought lays unused until those subsequent customers arrive.  The solution scaling and licensing need to allow a very low start-up cost (or ideally none at all) so that capacity (in terms of technology and licences) can be added as customers come on board and data starts to be gathered and utilised.

Make sure costs for security don’t get out of control

This is not quite the same for large enterprises, but similar scenarios do arise.

The roll out of security controls for monitoring and analytics might progress ‘across’ an organisation, especially a large federated one, in stages; or the use cases or data sets might not all be ready on day one so will be brought in and activated in a phased way; or the primary security policy enforcement points (domain controllers, firewalls, AV, IDS) might be assimilated into the monitoring and oversight mechanisms quickly, but wider data sources (such as applications or threat intelligence) or other security platforms may be part of a subsequent phase. As a business grows the size and scope of a monitoring solution can, over time, increase in line with demands.

In these situations, the same need to scale up capacity and licence coverage exists as it does in an MSSP bringing on newly won customers or launching new services.

What service levels does the business need? And what can the security team provide?

In an MSSP there is a need to define services and response times – who does what, and when by and how quickly, and what the outputs are etc.

In a service provider-customer relationship this allows value to be defined, expectations to be set and contracts to determine service levels.  But within an enterprise, between the security operations function and the rest of the business, there is also usefulness in having some pre agreed “rules of engagement”.

Defining the way services will operate, the timescales and performance targets and setting expectations with the rest of the business around how quickly things will be handled and what reports/outputs will emerge, means that the service delivery can be visible (security often only gets noticed where then is a problem) and also means that if service/business expectations aren’t being met then management can decide whether it needs to be reviewed or if intervention is needed – either raising budgets or headcount or aiming to reduce the incidence of a certain type of alert or event.

Be like an MSSP

For enterprises that have decided to in-source their security operations there are clear advantages in “behaving” like an MSSP in terms of how they define what those operations will deliver, how they will work and the technology platforms they use to support them.

MSSPs have to deliver cost-effective and market-leading/advanced security operations services at scale and in a flexible and future-proof/scalable way; and what large enterprise security team would reject any of those attributes as being unnecessary?

Be like a good MSSP, be:

• Cost effective
• Flexible
• Technically proficient
• Scalable

Huntsman Security’s solutions for MSSPs have been geared to provide for these market dynamics – offering true, robust multi-tenancy is just one example.  Avoiding the need for multiple screens and consoles, allowing different security policies, alerting regimes and data management across disparate customers or business areas and keeping data sets separate have shaped the way the technology has evolved; and often these things are hard to retrofit.

The advantages that sound technology platforms can provide for an MSSP are likewise available for enterprises that want flexible and cost effective cyber security too.