[BreachExchange] Security Think Tank: Approaches to strengthening security operations

[Audrey McNeil]

http://www.computerweekly.com/opinion/Security-Think-Tank-
Approaches-to-strengthening-security-operations

Security operations is a weak area in a lot of organisations because they
do not have incident response plans in place. They do not proactively
monitor for security incidents, they do not practice their incident
response and they are not prepared for “cloud scale” incidents.

There are a couple of sides to this issue that are well understood by
larger organisations and regulated industries, like financial services, as
they are critical to remaining in business. I will touch on the two most
significant, and explore the lessons we may draw from that understanding.

1. Automation

Automation is key as any organisation scales up in size or activity or
observes increasing attacks. It lets them handle more of the “noise” and to
allow information security professionals to concentrate on difficult and
unusual incidents.

It’s worth remembering, however, that staff in security operations may not
be accustomed to writing code – a skill that may be essential to handle
some types of incoming threats and even develop automated systems to deal
with them at scale.

So, how can we address this? One upside of the proliferation of security
tools that work across diverse environments is there are almost certainly
tools that will work out of the box to a reasonable degree for small- to
medium-sized organisations (and professionals who may lack that coding
expertise).

For instance, monitoring and logging agents, collection tools, data miners,
heuristic analysis tools and even elements of machine learning can help to
build a model of what “good” traffic and behaviours look like.

The connectivity between a lot of these tools already exist, and so there
is a distinct improvement organisations can implement without the need to
train or hire coders to develop and maintain automated solutions. That
being said, these tools are definitely not a silver bullet.

They will improve your situation to a certain degree, not fix it. And they
will not necessarily teach you very much about your environment or the
threats facing it, as a lot of the information automated tools pick up
about your environment may not be presented to you in the most useful way.

Larger, regulated organisations extensively use automation as a core part
of security and continue to invest further in this area, as the sheer scale
of threats combined with complex global environments means it would be
impossible to manage security threats and incidents any other way.

For them, thousands of attacks are identified, defended and logged
automatically, with only those requiring human action raising alerts. To do
this, at a scale equal to the increased workload, there are teams of
developers both in-house and at security providers to customise the tooling
appropriately.

A global organisation with a few hundred points of presence, hundreds of
key applications on thousands of servers, across multiple operating
systems, is not going to find an off-the-shelf solution which encompasses
every aspect of its security solution.

For larger organisations, the decision to invest in diverse security
operations teams is essential and usually forms part of the overall
operational security strategy. As threats continue to evolve, this strategy
is formulated to support the business in years to come and pre-empt future
threats. Smaller organisations should ensure there is at least some
in-house expertise – and retain or develop this as the company grows.

2. Incident Response

In parallel, developing effective incident response processes can make life
much easier for the teams involved, and again, this is an area that many
smaller organisations could benefit from improving.

For example, a small company that suffers a security incident may learn
about it from the media – particularly if it is a data breach, or from
systems failures. At this late stage, it usually requires an “all hands on
deck” approach, which instantly impacts that company, having a domino
effect on other functions.

Building effective playbooks of all the steps required during a security
incident in the same way large enterprises do means there is very little
wasted effort. Understanding every individual’s role in the incident helps
identify efficiencies in underlying processes, while minimising mistakes.

One useful outcome of developing playbooks is understanding where
automation can replace humans at critical times. An important candidate for
automation is initial triage, which can reduce the number of incidents
requiring a full team to assemble by narrowing it down to team, location,
type of incident etc., or in some cases, completing incident resolution
without human intervention.

Playbook and incident response examples are available online, but many
small-to-medium organisations should think about using external consultancy
to provide this. Professional organisations like ISF, ISACA and ISC2 are
also good value, as they provide useful guidance and information to their
members.

Whether or not you develop your incident response processes in house, or
have help, it is essential to test them regularly, as your organisation
will change over time. If your incident responses cover your data centre
but you have moved to a cloud platform and not updated your playbooks, how
will you know what checks need to be carried out, or what instances need to
be updated?

In summary, across both tooling and incident processes, most organisations
should consider external assistance as a key development boost to build, or
reassess regularly. But whether you buy in tools and consultancy or use
third party managed services, ensure you retain in-house expertise to
manage and retain knowledge of the organisation to ensure those tools,
processes and services are current and appropriate.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riskbasedsecurity.com/pipermail/breachexchange/attachments/20180205/501d4ea7/attachment.html>