SafeBits by Luci

Security Controls Implementation

Knowing what should be done is just the first step – keeping your organisation’s exposure to vulnerabilities at a minimum requires an adequate response.

Security controls are countermeasures, whether procedural, technical or physical, that are deployed to reduce or eliminate the risk associated to threats.

Security Controls Implementation

What I can do for you

The goal of implementing security controls is to obtain a measurable positive impact to your business’s security posture. The following are steps that we can focus on and should be considered in the context of one or more identified threats:

  1. If not already covered by a risk assessment, I perform an analysis of various controls which target the threats, to determine the ones best suited, in terms of risk reduction and budget alignment.
  2. I evaluate market alternatives and provide a report to support the management team’s decision; this may involve technical trials.
  3. I work alongside relevant teams during the implementation phase; with considerable experience both directly implementing, as well as overseeing the deployment of various technical solutions, I am well-suited to complementing your team’s expertise.
  4. I evaluate the efficiency of the measure and provide the relevant documentation to support on-going maintenance and regulatory compliance, where applicable.

What they are

There are several classifications of security controls, as they can vary widely in scope or means. Nevertheless, at their core, they are all meant to mitigate risk and, quite importantly, in order to be worthwhile investments, they must cost less than the exposure they are meant to protect against. Therefore, it is important to understand the options that are available and to choose the right alternative or combination.

On the one hand, based on the means used to achieve their purpose, security controls can be classified as:

  • administrative (training, procedures, incident response processes);
  • technical (firewalls, multi-factor authentication, encryption); or
  • physical (security cameras, locks).

Focusing on one set to the detriment of another can lead to sub-optimal results. For example, it is widely accepted that training is the most efficient countermeasure to the threat of phishing, with technical controls struggling to provide adequate protection without becoming a hindrance. However, no amount of training on proper use of passwords and authentication credentials can achieve the same level of security that a good password manager, password-less authentication or MFA can – it’s just too difficult for people to use passwords securely without the assistance of technical solutions.

On the other hand, security controls can have an impact at different times:

  • preventive controls attempt to stop a threat from materialising;
  • detective controls focus on identifying incidents when they occur;
  • corrective controls are meant to help in re-establishing normal operations and contain the disruption after a breach.

Many organisations only consider the first category, in an attempt to avoid incidents from ever occurring. Unfortunately, a perfect level of information security is impossible to achieve and awareness of this fact becomes critical. Detective countermeasures are therefore pivotal to enabling an appropriate response that minimises the impact of breeches when they do occur, with the corrective safeguards performing the actual grunt work.

For example, it is difficult to determine if an access breach occurs without verifiable audit trails and a constant analysis of these logs. Delaying corrective responses because they weren’t previously planned has the potential to not only draw out the disruption to services, but, in some cases, even extend the scope of a breach.

When to do this

Ideally, cybersecurity is treated proactively and security controls are continuously improved, in order to stay ahead of threats. Unfortunately, incidents sometimes reveal vulnerabilities what were previously unknown or inadequately protected against.

It is important to distinguish these two scenarios, in order to ensure that the approach taken has an appropriate focus:

  • an analytical route is well suited for the proactive case, as it ensures cost-effectiveness and an appropriate defence;
  • impact reduction must be the focus in the reactive case, with time constraints quite often imposing limitations on the available alternatives.

Everyone would rather avoid the latter situation, but, whichever applies to you, I have you covered!

Demystification

NIST SP 800-53 Revision 5, which is a publication from a US agency, lists 1009 security controls. These are sometimes abstract, allowing an organisation to adapt them to their individual needs and systems; at other times, they may seem quite specific, even referencing specific technologies. Of course, not all of these are relevant to every organisation and, to be honest, many are inter-related. Navigating them may seem daunting, but that needn’t be the case.

Take the following two examples from the aforementioned publication (the names are for indexing purposes, with IR standing for ‘Incident Response’ and SC for ‘Systems and Communications’):

  • IR-2 – Incident Response Training;
  • SC-20 – Secure Name/address Resolution Service (authoritative Source).

IR-2 simply specifies that staff within an organisation should receive training on what to do during an incident. Which people are involved, with what responsibilities, the procedures to follow, the frequency for refresher courses, when to update the contents and other aspects cannot be prescribed. As a corrective, administrative safeguard, this may include technical training on processes such as backup restoration or audit log analysis for the purpose of threat containment. But breaking it down, the most important aspects are:

  • identifying different types of incidents that can occur;
  • knowing when an incident has occurred;
  • ensuring the right people are given appropriate responsibilities (e.g. which technical team isolates the threat, which team communicates with customers, the press or regulators, who coordinates the response) and they all know what to do with the tools at their disposal;
  • when and how to communicate, both internally and publicly;
  • staff that are not directly involved in the incident response know what is happenning and what they need to do;
  • tough decisions for various scenarios are pre-discussed, as the pressure that mounts under a real incident makes these all the more difficult (e.g. whether to pay a ransom in a crypto-ransomware attack, or whether to restore a service from a backup that does not contain the latest data);
  • when notifications to regulatory agencies need to be made;
  • knowing when the incident is concluded;
  • learning lessons from the incident.

If or when an incident does occur, the response may not be perfect, but it does beat the chaos that may develop otherwise; and the update process is meant to incorporate the lessons learned into a better future response. Nevertheless, expanding on all these points may be overkill for some organisations; at the very least, you should know your regulatory notification obligations and, of course, know how to identify if an incident has occurred.

Unlike the previous example, SC-40 is much more grounded. In fact, if you only use DNS for name/address resolution, as many organisations today do, the NIST publication even references DNSSEC, which is a widely deployed technology. Though a very clear preventive, technical countermeasure, it is still important to understand the risks it mitigates against, to ensure that the investment is worthwhile. Additionally, it doesn’t come without risks of its own: if badly implemented, it can even temporarily affect service availability or not offer any protection at all, thus leading to a false sense of security. Therefore, as with many other security controls, it is essential to have security professionals with the right technical expertise.

Experience

This section provides a short, non-exhaustive list of security controls I have previously been involved in implementing. It is meant to present examples that can further shed light on what they are.

  • Internal PKI for services, using an HSM.
  • Use of password managers and multi-factor authentication.
  • Identity and access management with single sign-on.
  • Elimination of single points of failure in a network.
  • Integrated wired, wireless and VPN access control, using EAP (802.1X for the former two).
  • Training staff on avoiding social engineering threats, such as phishing.
  • Denial-of-service protection using third-party high-capacity networks for custom traffic scrubbing.
  • Ensuring non-repudiation for email by using S/MIME.
  • Vulnerability scanning and analysis.
  • Validation of executed software integrity.
  • Transmission confidentiality and integrity protection for all internal data flows.
  • Protection of information at rest with auditable access.
  • Development of a risk management strategy.
  • Ensuring least privilege for all software components.

Most importantly, one-size-fits-all solutions are rarely efficient and a tailored approach to the implementation of any safeguards can increase the value of your investment. You can always get in touch to have a chat about what would best fit your needs.