Our cyber security products span from our next gen SIEM used in the most secure government and critical infrastructure environments, to automated cyber risk reporting applications for commercial and government organisations of all sizes.
As 2018 dawns, the time to achieve compliance with GDPR tightens. Issues like the right to be forgotten and the need to set up processes to handle data breach notifications become pressing issues. For some organisations the process of issuing a data breach notification itself will be completely new.
There will be, as has been acknowledged in various studies, a range of degrees of readiness within businesses – but the security and privacy communities; spanning services, consulting and products; are busy both driving demand and also meeting it. The emergence of services specifically to support data breach notifications is one example – these have existing in the US for some time but now will find more traction in the EU.
In specific terms, the area around Security Analytics, automation and machine learning has a clear role to play as businesses try to:
However, there are a wealth of security solutions (and the field of analytics is no different) that expertly solve one of the problems faced and pay little heed to any of the related issues – indeed in some cases, as we shall see, they can solve one problem and exacerbate another.
As a result, going into trolley-dash mode and panic-buying solutions to deal with the spectre of GDPR is absolutely the wrong approach.
There is an ethos within the security industry that revolves around detecting attacks, misuse, phishing, malware, network anomalies, data losses, file access, media insertions, privilege changes, policy breaches, matches with published threat intelligence, black listed application usage etc.
This is perfectly valid – and in a great many cases these detective controls actually serve a preventative function – anti-virus being a good example; a file that matches a pattern is not just detected but is quarantined, deleted, prevented from being opened etc.
The goal of a solution that aims to detect is only met if it actually detects things – hence there is a tendency (in particular during a pilot or proof of concept) to try and detect as much (or as many cases) as possible.
What should be self-evident however is that just detecting more instances poses security teams with two very real problems:
CONCLUSION: When buying solutions that detect problems, make sure that they aren’t going to over classify things as problems to try and “impress” you. Ensure that you have got a plan to deal with the things they do detect that are valid (or not) so that your team, reporting solutions and processes can cope.
If the historic SIEM industry was about collecting data and presenting it in pie chart, bar chart or table form for managers and auditors, the Security Analytics industry is much more about deriving meaning from data in a way that supports the processes of detection, understanding and response within the security operations function itself and in the reporting of this to business stakeholders.
There are several clear imperatives in this – one, apparently very basic, is the need to gather relevant data together in a single place for access. In one respect the amalgam of log data in traditional solutions achieved this; however for a given event/alert/report/alarm (depending on your terminology) there is often also a quantity of supporting information that traditionally would have to be manually collected. Examples might include:
There is a huge difference in usefulness and workload/effort required between “having this data available” and “having this data available in one place” – even if it is not continually stored in a single location as a rule (it would be rare to find a record of the contents every network packet stored within a SIEM for example, but in the case of security report this data might be hugely valuable).
The step beyond gathering the data and having it available is to actually seek to optimise and speed up the investigative processes to provide faster and deeper understanding.
One way this can be achieved is with automation of some of the processes that a human operator would follow as part of the alert triage and investigation process.
Two very obvious examples are the verification of threats and the anticipation of likely questions:
However in either case it should be the security analytics solution that does this, rather than sitting there with a blinking cursor or query builder waiting for the operator to instruct it to do so.
Of course a human operator could ask these things of the analytics platform in front of them – but again, there is no need for a security platform to sit there waiting to be told to do it.
Similarly, in the case of a malware report (malware is still a growing problem) from an end point, likely questions are:
As above, it’s a fair bet these questions will be asked, so choose a security analytics solution that will just answer them, rather than sit there like the ancient oracle at Delphi waiting to be asked.
(… without having to rely on excel)
After the obvious questions that should be anticipated there is a whole investigative process that, for more complex cases, may need considerable human investment in time, expertise and effort.
The important thing here is to allow the creation of questions, queries, lookups and interrogations that provide the maximum value in terms of output for the minimum effort in terms of creation or definition.
What is commonly found is that the methods for querying data sets are too cumbersome or limited for anything outside of normal dashboards or reporting use; or too difficult to learn. Hence, data gets extracted from centralised reference systems and is then pulled into a different tool for analysis.
Rather than taking a user and a workstation and a server and asking “what other users have used this workstation and what servers did they access?” the operator finds there isn’t a way to encode or define that question in the way the analytics tool would like or allow.
Consequently the list of users and workstations is created as one export or CSV file, and the list of workstations and servers is created as another, and these get loaded manually into Excel so that a LOOKUP, or sort, or filter, or conditional formula can be applied.
This output is a set of results that stays stored in “malware incident analysis.xls” because there is also no way to bring external analysis back into the “central analytics platform” to associate it with an incident.
CONCLUSION: The goal of analytics is not to draw graphs; it is to build meaning around data and information so that it can be understood and to allow decisions to be made. When investing in analytics solutions, ensure that they answer questions – preferably automatically but if manually, then with the utmost flexibility and the lowest friction for the operator. Make sure technology makes the work of the human less laborious rather than more.
The ultimate goal, in the event of a security incident – particularly one that is ongoing at the time the investigation happens – is to be able to do something about it.
In its simplest form this might mean disabling a network connection, suspending a user account or quarantining a host from the network to avoid data loss, onward infection or unauthorised access.
Even some time after a breach might have occurred, when the horse has bolted so to speak, there is a need to amend configurations, apply patches or tighten access rights to prevent recurrence.
Ideally, this would be undertaken in a calm and relaxed way by the security team; but with security resources as scarce as they are it is much more likely that it is done in a stressed and panicked way by an overworked security team or possibly not done at all because they aren’t empowered to act and respond.
This need for consistency and promptness in responses all but implies an automated capability – one that can be trusted to operate under a set of guidelines and rules defined by an expert in cyber security but not dependent on them per se to actually do it.
Automation in this context has a large hurdle to overcome, that of trust. If a case is detected and is 80% likely to need a response, for most people that would not be close enough to let the system get on with it autonomously.
If however this certainty can be raised to 99% then the risks of automating a response have dropped considerably. Additionally, if the response can be executed in a trustworthy, sound, consistent and reversible way then the choice to allow the system to take action becomes much easier.
So a security analytics solution that churns out alerts, or exceptions with or without qualification for a human to take action is much less useful than a security analytics solution that will undertake the necessary verification and triage to get to the point where the level of certainty is high enough that it can make a decision, as configured, to act autonomously. The case can then be flagged – with the necessary corroboration – to a human as a fait accompli and with an easy “undo” or “go back” function if the rare case has occurred where the response was not correct.
CONCLUSION: The goal of analytics is to bring meaning to data and provide certainty in decision-making. Use this as a way to leverage automation to improve response times and further reduce manual workload on human resources so they can be better utilised on tasks that require real expertise – not on programmed mitigation workflows that can easily be built within a production-line environment.
It is easy to see GDPR as a way to justify additional investment in prevention, detection, and response. To an extent this is valid, however the problems that security teams are solving are being worsened by the growing technology landscape and expanding threat universe.
Buying tools that do one thing well but are isolated from the wider remit, ecosystem or end-to-end process simply moves the problem (and often data) around.
Bringing meaning to data, supporting the process of making decisions and reacting swiftly is the goal. Compliance driven procurements of solutions that don’t recognise that are likely to deliver only incremental value.
GDPR is not “the perfect time to panic” – instead:
The UK market has its own regulators, security standards and challenges. And while rulings from SEC in the US or the Australian Prudential Regulation Authority (APRA) in Australia don’t apply to UK companies, for the most part, the observations are undoubtedly relevant and the resulting advice instructive. It would be wrong to think UK financial […]Read more
<<< Part 2a: Australia’s Essential Eight: Beyond Endpoint Control <<< Part 2b: Activating UK NCSC & US NIST Guidelines: Beyond Endpoint Control Part 4: Systematic Measurement of Cyber Controls >>> As much as we invest into cyber security controls, external threats are inevitable. In a recent Notifiable Data Breaches Report from the Office of the […]Read more
Keen campers, scouts and even the Swiss Army know – that a good penknife is indispensable. This simple device has mitigated many a disaster at one point in time or another. Whether it’s to cut through a bit of string, tighten a screw or simply to solve the problem of no bottle opener in the […]Read more
Supply chain risk is an area of cyber security that demands the ongoing attention of every enterprise; because it can make the difference between being resilient or not. It’s no surprise that insurers warn that the vulnerability of supply chains is potentially a systemic risk that can quickly propagate across supply chain dominated industries. Organisations […]Read more
It took a “tripartite cyber assessment” by the Australian Prudential Regulation Authority (APRA) to identify that a sample of financial organisations had inadequate cyber security: poor security control management, a lack of business recovery planning and inadequate 3rd party risk assessment. Why were there gaps? Where is the failure? Clearly the common practice of unsubstantiated […]Read more
The discussion over data-driven vs qualitative cyber security assessment has been going for some time. Nowadays, it is at the top of the priority list for many security and senior executive teams. Managing cyber security has always been a noble ambition but without reliable measurement, the lack of actionable information makes evidence-based management decisions almost […]Read more
Attack Surface Management (ASM) characterises a business’s security risks as the monitoring and risk mitigation of a constantly changing and vulnerable “risk-surface”. Importantly, this attack surface extends to both internal and external assets and services. Some ASM solutions deliver clear visibility across both Internet facing and internal assets. Others do not. Instead, they assess external […]Read more
The UK Government has released its annual “Cyber Security Breaches Survey 2023”. It provides some valuable insights into how cyber security is currently being managed in the UK, by a range of organisations. It also speaks to how current competing economic priorities are impacting the effectiveness of some cyber security management efforts. The full report […]Read more
Solving the mismatch between cyber security reporting and directors’ requirements You are undoubtedly familiar with the headlines; you may have even become in part desensitised to them: ‘Cyber-attacks are increasingly damaging’, or ‘large amounts of personal data are most at risk’. The important take-away, however, is that modern day thieves can easily gain access to […]Read more
A system to address the untrustworthy security environment Zero trust approaches to security have been talked about for a while; but in recent times they have certainly gained more currency. As a model for protecting data and services, the simplicity of the concept is its biggest strength – assume, as a default position, there is […]Read more
Read by directors, executives, and security professionals globally, operating in the most complex of security environments.