Cyber Security Quotes: Why “We’ve never been hacked” probably isn’t true (ever)

November 23, 2017
Share on Facebook0Share on Google+0Tweet about this on TwitterShare on LinkedIn0Email this to someone

As cyber security quotes go its not uncommon to hear the claim “We’ve never been hacked”; it might come up in a conversation when a service provider is trying to win business from a company where there will be an exchange or hosting of data, or maybe it will be a defence against some findings in an audit where there are controls that are missing or ineffective. It may even be part of a board presentation to provide confidence or found on a CV sent in application for a senior CISO role.

It does however belie several truths that are fairly enshrined within the cyber security industry. In this post we’ll try and explain what these truths are, and translate the cyber security quote “We’ve never been hacked” into more likely and appropriate interpretations.

What does this quote actually mean?

As a statement of fact it is pretty definite and clear. However, it is notoriously difficult to prove the absence of something – in this case an intrusion. Whether you are trying to spot a particle at the quantum level, find alien life on a remote planet, or find your keys when you’ve looked in all the places you can think of, proving something doesn’t exist is hard.

Often, all you can say (or prove) is that you haven’t found what you are looking for yet. That could be because it is just a matter of time, or that you are looking in the wrong places, or that what you are hoping to detect is hard to either see or verify (as in the previous example, keys are easy to find, the Higgs boson was a major undertaking).

Finding sub-atomic particles is probably harder than cyber security     Finding keys is hard, but not as hard as cyber security

Finding subatomic particles is hard, but not as hard as finding lost keys. Detecting cyber attacks is also hard.

Cyber Security Quotes: “We haven’t been hacked yet?”

This is probably the most positive comment it is possible to realistically and truthfully make.

There is a view that there are two types of companies: those who have suffered a breach and those that will suffer one. Nihilistic as that sounds, all companies have valuable data that could be of interest and over a long enough time period, especially as they grow in status, revenue, customer base, profile and technological complexity; the chances of a breach of some sort occurring will grow.

Clearly as a business grows its sophistication and control structures will grow too but as with the birthday paradox, as you add more of something (in this case, as the months pass), the greater the chance that an improbable event will occur.

Ignoring the shape of the probability curve, the fact that you haven’t had a breach yet does not make a breach in the future more or less likely; in much the same way that an investment can go down as well and up, so can your cyber security fortunes. Attackers only need to find one obscure vulnerability that works on one occasion to gain access; a company has to defend against all possible attacks and protect all vulnerabilities all the time, for ever, to protect itself.

Cyber Security Quotes: “We were hacked, but didn’t have enough information to detect it”

As cyber security quotes go, this one is rarely voiced out loud, in fact it is almost counter-intuitive but can be tacitly implied in any event where there has been a data loss or breach of personal data that comes to light because it is publicised or posted online (i.e. the breach becomes apparent as the culprit acknowledges or publicises it) to shame, embarrass or impact the originating company.

In these circumstances (such as when a list of account names, emails, passwords and identity numbers is posted on-line), the breach only comes to light because the hacker or intruder themselves publicises it, or in some cases because the patterns of fraud or access that result lead back to the database of a particular company.

Clearly, this is not a good situation and it has a much, much worse corollary: If the hacker didn’t disclose the data and/or publicise the fact that they breached the organisation’s defences, or if the pattern of fraud that resulted was so dispersed that it didn’t lead back to an identifiable point, would the organisation have noticed at all?

Cases of personal data being breached tend to get publicity (under GDPR they will have to be notified); but if the stolen data had been intellectual property, designs, algorithms or future investment plans etc., then the effects of the breach or loss may be hidden (possibly deliberately) for some considerable time, if not for ever.

What is missing here is information – activity and system logs, telemetry, network session data, application transaction details, user logins, traffic meta-data, signs that indicate an attack not from the impact of disclosed data but from the actions of the person, system, application, process or user who caused it.

To detect an attack, breach, loss or intrusion without being told about it or from failing to notice its impact, it is necessary to have sufficient data to actually detect that it has happened from the behaviour or activity of systems or users.

Learn about behaviour anomaly detection here

Read Huntsman’s white paper on Insider Threats and Behavioural Anomaly Detection

 

Cyber Security Quotes: “We were hacked, and have evidence of it, but still didn’t notice”

This is a step up from the above quote, but the net effect is the same. There are two scenarios that could lead to this situation:

  • There is data, evidence, session activity and logs available but they were not being looked at/examined/parsed or analysed in a useful way or not at all.
  • There is too much information such that the signs of attack/loss/intrusion/hacking were masked or obscured by the shear volume of data.

 

Clearly, in either of the above cases there is a need to get smarter. Simple solutions might include deciding what activity/log/network data to collect, how much of it is useful for analysis and what just needs storing for subsequent diagnosis. Considering the value of data in this way and handling it appropriately can solve the volume problem and allows data that may assist an investigation to be stored for a time as well – thus helping the analysis of alerts to become more intelligent.

A better solution is to analyse data in a way that reflects its usefulness and value in the detection of an attack in intelligent ways that allows the optimisation of both the automated and manual processes.

As an example take network data. An IDS/IPS system typically looks at data in-line to detect attacks that fit certain patterns or signatures, or may even detect where the packet flow/activity exhibits some behavioural characteristic. Likewise a DLP solution might flag flows of confidential data, documents or personal data like credit card numbers or dates of birth; however both these solutions can be hampered by the use of encryption (e.g. of web application traffic) so they may not detect some flows of data (outbound) or attack traffic (in bound). Additionally, it may not be possible to examine in detail the contents of every single packet, which leaves the question of whether you collect, analyse and retain every single network packet or just the higher level meta data around sessions, directions, resources, entities etc.

Of course the answer is to accompany one of the above solutions with the monitoring of system and user activity at the end points, servers and within the applications themselves. This allows you to detect situations where either the IDS/IPS system or DLP system flag an alert and correlate it with what is happening on the target system OR to detect the signs of attack at the system/user/application end and so gain the maximum detective coverage.

This might mean less need to analyse every network packet in detail at a content level as it passes through the infrastructure (in particular where encryption is involved) but be of more value in the collection and caching for a shorter period of time so when an alert arrives from a different source, the rest of that network session can be retrieved in real-time and retained for diagnostic purposes as a result of its association with a specific incident.

The actual packet contents being collected can be coupled with the analysis of network meta-data itself, including senders, recipients, message headers, URLs, file names, shared drive destinations. There is a balance between the volume of data in storage and the analytic value. If this balance is too much one way or the other, you get a problem where the volume of data masks the events that are of interest or the volume of findings that are noteworthy in some way becomes so high that the alerts themselves become the challenge to manage.

Cyber Security Quotes: “We were hacked, but it was well concealed and there wasn’t sufficient evidence to detect it”

In many respects this is the worst-case scenario out of all the above variants of our chosen cyber security quote.

This is an intrusion that occurred and went undetected despite all of the comprehensive efforts to gather appropriate data, and the presence of a skilled team and technology tools to analyse it.

A motivated, well-funded and highly expert attacker with a high degree of technical knowledge and patience may simply be too good at covering their tracks to be detectable given the bounds and constraints within which an organisation has to operate. Perhaps the breach has been caused by a user internally who has access and has either been fooled into leaking data or, through their normal duties, has allowed data to be exposed in a way that is sufficiently indistinguishable from normal and hence, in neither case triggered any kind of alarm or report.

In this case, the focus has to be on handling the breach well to show that when things go wrong your organisation can work quickly to put them right (i.e. you have an effective incident management and breach notification process link to other blog https://www.huntsmansecurity.com/gdpr-data-breach-notification-services-9-questions-to-ask-service-providers-2/) but also on making sure you have evidence of the presence and correct operation of the controls and the efficacy of your detective processes so that you can demonstrate that reasonable defensive measures were in place. If you do end up in a position where a highly skilled and determined attacker gained access you may need to be able to demonstrate the sophistication of the attack, rather than have to admit that it was some muddled amateur who got lucky.

The reality is that the assertion in this title quote can be made, but may not be believed! So be prepared to evidence it.

Cyber Security Quotes: “We were hacked, but categorised it so it doesn’t count as a hack”

When is a data breach actually a data breach, or a hack a hack?

If someone internally accesses data they shouldn’t but does not extract, leak or steal it; does that still count as an incident? It could have been an incident if it hadn’t been averted, or even be deemed a “near miss”. Similarly, an external intrusion could be categorised as a malware infection (if it started with a phishing email or a drive-by download), and if no leakage of data occurred that might not count as a data breach either (in the organisation’s defined taxonomy of attacks).

The issue for businesses and consumers is that you might have your interpretation of what a breach, hack, loss etc. means but it may not be a universally accepted definition; certainly when applied to a specific case.

An organisation may assert that they have had “no incidents” (just lots and lots of alerts) or that they have had “no data breaches” (but several external intrusions and malware outbreaks).

Questions might be aimed at alerts and incidents in the broadest sense but a respondent might interpret it very narrowly (just cases of an external attacker remotely accessing systems directly and copying data).

The solution is for the question being asked to be phrased in the terminology of the respondent organisation so that the levels of classification can be known and understood, for example:

Alert ⇒ Investigation ⇒ Confirmed incident ⇒ Breach ⇒ Crisis

Then it is possible to understand what they mean for each designation and what the metrics are in each case.

Cyber Security Quotes: “We aren’t at liberty to discuss whether or not we have been hacked”

New GDPR breach notification rules in the EU/UK mean that there will be a lot more reports of data breaches and security exposures hitting the public domain because for the first time there will be a legal requirement to notify regulators and data subjects.

Likewise in Australia there are similar initiatives around data breach notifications (https://www.oaic.gov.au/media-and-speeches/news/retailers-check-out-mandatory-data-breach-reporting-obligations-and-prepare-for-2018).

GDPR has a presumption that breaches are reported unless they can be deemed to be trivial – and this subjectivity could be used to mask occurrences. An organisation could argue that an attacker who gained access to a system on the network but did not access data held within it, is not a breach, especially if there is no evidence. In such a case it might be possible for the victim organisation to deem this as an attack, but not actually a “data loss” or “breach” and hence determine that it is not in fact a breach.

It does raise the question of whether the organisation spotted the intrusion but missed the data leakage/exfiltration, or if the attacker was able to gain value or insights just by “seeing it” rather than by “stealing it”.

As GDPR relates only to personal data, a business that suspected a breach of its plans, strategies or intellectual property may not wish to disclose that at all, certainly if it didn’t feel compelled to do so. While this may sound dishonest there are lots of valid commercial reasons for not disclosing a breach. It may be defensible in some circumstances where the outcomes or motivations of the attacker were unclear and/or where only incomplete diagnosis had been possible and the nature of any breach was questionable.

Cyber Security Quotes: The reality

This rather negative post highlights that there are a range of interpretations of the over confident assertions we often find (or make) in cyber security.

This can be driven by a lack of information, inadequate analysis, poor understanding of attack methodologies, different ways of categorising events, an absence of negative reports or a desire to keep the reality of events confidential.  The way organisations present their historical security performance can vary depending on so many factors and internal culture such that meaningful metrics may be hard to come by.

In reality, by far the biggest challenge for businesses is the difficulty of spotting serious breaches within a meaningful time window – i.e. one in which they can effectively respond. Whether this is weeks, days or hours is immaterial as an attacker might require only seconds or minutes to mount an attack and steal data and so goes unnoticed either initially or for a considerable period of time.

The most likely interpretation of any claim to a perfect track record in security is that the organisation has been breached and simply hasn’t noticed, or hasn’t noticed yet.

Effective, real-time data collection to gather security events, activity logs, session information and metrics has to be accompanied by modern and intelligent analytics to provide the surest way to both detect data breaches and incidents but also to understand them when they are identified.

Until an organisation has this visibility, a claim of “We have never been hacked” must be accompanied with a pinch of salt.

Benchmark your existing security strategy with our 5 Step Cyber Security Tool: