Security Intelligence - Reactive -v- Proactive

The RSA Conference bandwagon rolled into London this week, which promises to bring some interesting sound bites from the big players in the security sector.  Yesterday's opening key note speech from RSA's own Arthur Coviello, focused on some of the key challenges organisations face from an information security perspective.  The lack of skilled personnel, shrinking security budgets and the difficulties of ever complex risk management, make attacks more difficult to identify and overcome.

Coviello called for more of an 'intelligence-driven' security model to help evolve the traditional security operations centre into something more analytical and proactive.  Whilst being able to carefully understand and dissect and attack source, flow and impact, security intelligence could also be seen as just another level of reaction, albeit a more detailed one.

Intelligence-Driven Security

Security intelligence can be seen to bring together, several different sources of security information, from SIEM, identity and access management tools, perimeter defences (IDS, IPS, NGFW) and even HR systems.  There are several products available today, that aim to create a central warehouse of security data, so that analysts and operations teams can help to identify how and why data breaches have occurred, if insider fraud has taken place, or if a long term strategic cyber attack has taken place.  By analysing data from different sources, you can start to understand the threat landscape in a more detailed and conceptual way.  The same way a police investigator builds a case together, looking at evidence from different angles.

The major difficulty for many security operation centres, is the sheer bulk of security information they face - the age-old needle-in-a-hay stack problem.  This has been a failure of many SIEM solutions.  Whilst, they have great functionality in connecting and collating log and security data from different devices, all that serves to achieve is a greater pile of 'evidence' to shift through.  To overcome this, SIEM products then focused on speed of execution, with regards to free-form queries.  The ability to go from 1 million records to 10 records in milliseconds.  This is perfect...if you know exactly what query you want to execute.

As cyber attacks and even internal fraud and insider misuse becomes more strategic and complex, it will become impossible to use a signature and known-query approach to identifying attacks and attack parameters.  The next stage for security intelligence, is to start and use a more analytical, conceptual and behavioural driven approach.  This can help to add context to particular events.  If a particular user for example, always logs in via the corporate LAN, and then suddenly logs in from an untrusted public network, this could be assigned a higher risk rating, than if a field engineer, who always logs in from a public network, performed the same action.

Aiming for Proactive

However, one fact still remains.  This increased intelligence, is still reactionary.  The incident has potentially already occurred.  Data has already been lost, passwords have already been cracked, accounts compromised and brands damaged.

The main issue facing many information security managers and CISO's, is how to get security embedded into the organisation in a proactive way.  Let security become the default stance for the organisation.  Whilst CISO's need to acknowledge (and promote this message to other CxO's), that they will be attacked at some point, proactive (or offensive) security is a game changer.  It's a long term plan, which many will fail to achieve, mainly due to the lack of instant tangible results it can produce.

Proactive security needs to focus on both the tooling being used and the employees using it.  This will therefore require changes to the software development life cycle - how the software is tested, designed and released.  Many developers will see security as an add-on component, often being managed by a testing or post completion audit team.  Security should become a much earlier part of the design and code phase.  Code with security in mind, not the other way round.

From an employee and end user perspective, security should be entirely transparent (as acknowledged by a great post from HP's Rafal Los  - Security -v- Useability...).  If not it will be seen as inhibitive and complex.  Stealing a standard software design pattern analogy, security should be seen from a 'convention over configuration' mind set.  The application or process should be secure by default, not requiring additional or bespoke end user configuration changes.

Whilst intelligence driven security is the next step in managing complex security scenarios, I can only think it's a sticking plaster fix, for a more complex and long term problem.