Photo credit: https://forums-de.ubi.com/showthread.php/189053-si-vis-pacem-para-bellum
By
Will Lambert
As we
all know, prevention is better than the cure, you can’t close the stable door
after the horse has bolted, etc. These common sayings have a clear and concise
meaning that basically translates that it is better to prepare for an incident,
rather than not prepare and have to clean up the mess, as sometimes the
consequences are irrecoverable. So, how does this transcend to information security?
Information security incidents can take any number of varying guises and may
not just be singular in vector. As an example, two, three or even more attacks can
be deployed as distraction tactics designed to flank and confuse incident
response teams. How would your organisation fare against such attacks? Can your
organisation even prevent such attacks in the first place? If not, can your organisation
detect, react and recover from attacks? The preparation work is known as
Incident Response Preparedness (IRP).
Unfortunately,
the realisation of an organisation’s absolute dependence on IT systems to
deliver their operational output, feeds the delusion that information security
is solely an IT department’s problem. However, we know in the real world that information
security is the responsibility of everyone. This is cemented through the stark
realisation that although every department uses IT systems, it is not the
systems themselves but rather the information
they process in order to deliver the operational output – not forgetting the
information processed by suppliers. Only through effective Supplier Evaluation
and Risk Management can an organisation depict and manage the risk to their operational
deliverables posed by suppliers (see SERM - The Domino
Effect, Automating SERM and Defining the Damage).
Injury
to an organisation’s information is usually measured against the well-known
Confidentiality, Integrity and Availability (CIA) triad and while the
mitigation techniques are many, they are usually broken across three main
categories: people, process and technology.
·
People
o
Does your organisation have and
continue to support its people in the;
§ Implementation, maintenance & effective use of mitigation
controls, including your policies and technology stack?
o
How receptive are they to proposed information
security changes?
§ Do they see information security as an enabler, rather than a blocker?
·
Process
o
What processes do you have to ensure you can deter, react and recover from
attacks?
o
Are changes made within your environment
adequately managed to ensure you can continue to output your deliverable?
§ Can your existing Business Continuity Plan (BCP) restore your
business to a Business as Usual (BAU) state in the quickest time frame possible,
highlighting lessons to prevent reoccurrence or gaps in the proposed plan?
·
Technology
o
What mitigation technologies
do you have?
§ What controls do you take to ensure you are constantly
surveying the data you keep? Remember, if you don’t need to retain it, get rid
of it! (see Data Assessment)
§ How do you monitor your admin accounts? – remember
hackers are known to target these in attacks as they hold the keys to kingdom (see
Protect Your Superusers)
§ Are you alerted to changes within your environment,
such as log event clearance, authentication failures, suspicious outbound
connections? Are these alerts fed with various threat intelligence feeds to
reduce the false positive likelihood? (see Protecting the Pack)
You’ll
find from this list that it is not as clear-cut as what can be believed. Most
mitigation controls are interlinked, intertwined into prevention. Take people
and process for example. You may well have documented your incident response
plan, but have you trained your people in its use? Training (see Battle Plans) is
usually the tool to bridge the gap between your organisation’s agreed policy
and informing the masses; secure code training is another example of this. Demonstrating
you have a process in place is great, but is your development team trained to
recognise software vulnerabilities and reduce your risk exposure? (see Secure Coding).
It is easy
to think that mitigation controls can be complicated beasts – and of course
they can be (firewalls, IPS / IDS, PIM / PUM, SOC, ACL, etc.) but don’t forget
about physical controls (fences, guards, CCTV, etc). Attackers will make use of
both technological and physical defence vulnerabilities - each of which will be
considered by social engineers (see The Power of Social
Engineers). What protection controls do you use to deter a social
engineer in the first instance? How are these controls reviewed or tested?
We do
need to consider an organisation’s need versus their appetite. Even today, some
organisations’ appetite for information security is so low, they are almost hoping
that information security is a fad that will soon pass. If they perceive that
they can avoid paying for mitigation controls, they most likely will. However,
as we said at the start, prevention is better than the cure and the level of
IRP will assist an organisation reduce potential unwanted attention from
regulatory bodies and media if breached (see Invest Early to
Protect Your Business). If the level of IRP meets or even exceeds an organisation’s
need, this will cement their brand as one which accepts its information
security responsibilities with utmost clarity and forethought of mind. This further
demonstrates to their employees, customers and even the world that information security is not a nuisance, it’s here to help us deliver our operational output
safely, securely and with careful regard to all risks involved with processing
activities. But more importantly, it’s here to stay.
If you want peace,
prepare for war