How to define a security incident
Do we need to do a better job of understanding exactly what a security incident actually is? Davey Winder takes a look...
Probing for the truth
That's an interesting point though, especially when you consider that in the original research that kicked off this debate some 38 per cent of recent incidents were said to have had no impact. At what level, then, does a probe become an attack? Is it an incident if someone starts probing your network or only if they persist in doing so?
Kevin Curran, senior IEEE member and a senior lecturer in Computer Science at the University of Ulster, is in no doubt that an attempt is an incident. "Success of the attempt is irrelevant. An incident is an incident," he says.
"You cannot have a partial incident; you are either pregnant or not pregnant!"
There's no great consensus within the IT security industry on this point though. "I would think that an 'incident' would only be a successful breach," Philip Pieterse, senior security consultant at Trustwave says, adding "But it depends on how the company defines it."
And there lies the rub, a probe becomes an attack when the enterprise says it does. Whether, as in the case of Pieterse, you think a probe should only be classed as an attack if it is "persistent from the same external source" is, I think, irrelevant to the incident definition argument. Not irrelevant to how an individual enterprise reacts to that incident though, that goes without saying, but I'm with Curran on this one as far as the definition is concerned.
Jonathan Martin, director at of enterprise security products at HP, takes up the response issue, however, by suggesting that aligning probes and attacks with risk enables the enterprise to focus time and effort on those that are going to do the greatest damage to the organisation.
"If someone is trying to attack a recently built test server in a lab environment, then we shouldn't be wasting our valuable resources researching or resolving it," he says. "But, if the attack is targeting high risk targets such as customer facing systems, personal information or financial information systems then we need to raise the priority we give to that attack."
Does it matter? (part one)
Which leads me onto whether it actually matters if people think they have been targeted, successfully or otherwise, at the end of the day? Isn't the correct assumption to say you either have been or will be and therefore need to defend accordingly?
If those defences are holding up where's the value in knowing who is attacking you and how, even if those attacks fail? Some 43 per cent of those surveyed in the Lancope research thought that monitoring user activity' and not having a single view' were key network security challenges. But are they right?
Jim Hietala, vice president of security with The Open Group, agrees that to assume that you have been and will be targeted is sound advice and suggests to the extent possible knowing who is attacking you helps to understand the level of sophistication of the attackers.
"In our Risk Analysis standards, we allow risk analysts to gauge threat capability (sophistication of attacker), and depending on whether the attackers are unsophisticated, or sophisticated nation state attackers, the risk level and our response to it can vary widely," he says.
But, as cyber risk advisor with Prolinx, Brad Cox, points out "targeting, and its close cousin, attribution, often absorb operational staff and managers at the expense of actual response."
An important consideration when you realise that the goal of incident management is the rapid return to normal business and, as such, may have little regard for the motivations and actors behind an attack.
"Attribution of cyber-attacks is notoriously difficult given the distributed and anonymous nature of interconnected computers" Cox insists "true attribution is only really possible through combining cyber-attack intelligence with that gathered through more traditional intelligence gathering and analysis techniques."
Cox agrees that it's correct to assume you will be (have been) targeted and that appropriate defences implemented, but reminds us that appropriate is the key word and that demands a perpetual risk-assessment and management process. Which sounds like it costs money to me, and probably to you, and that's because it does.
"You, as an organisation, require adequate staff to defend against and manage your infrastructure in that environment" advises Tim Erlin, director of IT security and risk strategy at Tripwire. "Just like you need to refill the soda machine or keep the lights on."
Erlin warns that it's a serious mistake to fail to recognise when an incident-level event has moved into the realm of normal operations because "if you continue to respond as if it were an incident, you'll be spending far too much money on that process."
In This Article
Managing security risk and compliance in a challenging landscape
How key technology partners grow with your organisationDownload now
Evaluate your order-to-cash process
15 recommended metrics to benchmark your O2C operationsDownload now
AI 360: Hold, fold, or double down?
How AI can benefit your businessDownload now
Getting started with Azure Red Hat OpenShift
A developer’s guide to improving application building and deployment capabilitiesDownload now