Tuesday 11 June 2019

Si Vis Pacem, Para Bellum


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