Endpoint security is a complex topic, and how endpoints are configured is dependent on the risk appetite of an organisation, the nature of endpoints being used, and the kinds of information being processed on endpoints. What is a good starting point, even perhaps a baseline, for endpoint security control? In this series of blog posts I’m going to explore some of the common baseline security controls used on endpoints, and hopefully highlight the importance of getting the basics right when it comes to the most critical devices in an organisation today.
The most obvious endpoint security control, whose presence is mandatory in current information security architecture, is comprehensive anti-virus/anti-malware coverage.
Although AV is often derided by security professionals in the cyber security industry as being outdated and based on inefficient principles, it nevertheless offers a number of unique capabilities that improve the security of systems within an organisation. AV is well-tested and reliable at protecting against known attacks, and the benefit of automation ensures unnecessary delay is minimised.
While the technical solution is by far the most important component of this kind of control, the most effective deployment also includes policies and procedures for AV. Many organisations fail to consider this additional dimension, and do not deploy AV systematically with a high-level of rigour. The result is poor configuration, localised detection, file deletions, and weakened forensic readiness (FR). In addition not all users are well-intentioned, and AV detections may in rare cases be an indicator of an insider threat.
In a serious information security situation, basic practices such as AV and patching, will be critical to the resilience of an organisation and how well it can recover from significant attack.
Procedures should be in place to:
- Regularly test the updates of AV signatures, and the AV product
- Periodically test the configuration of the AV product, and to action any necessary improvements
- Regularly test the detection capabilities of the deployment, for example using the EICARS sample
- Set out how system operators should handle the detection of a virus or malware, including how to process the quarantine store
- Specify practices for patch and obsolescence management of the AV product
- Manage all supporting processes relating to AV
A defined, controlled, series of configuration settings must also be in place and applied rigorously. Such a configuration should enable on-access scanning, regular updates and patching from a reliable source, and heuristic detection. Heuristic detection, in many flavours, can assist in detecting indicators of compromise and improve detection capability.
Special cases should also be considered: how will AV update on a public access network, with and without a VPN connection? Is the AV updating process resilient to a system outage of an update server? Is load balancing necessary? What is the impact of AV with and without network drives connected?
It’s also important to engineer an effective configuration for detection and response. This includes both alerting system operators, e.g. through a SIEM, and handling the offending article.
All detections should lead to quarantining action, and the quarantined data should be inaccessible to a normal and a local administrative user (where possible). The goal in respect of privileged users should be to prevent inadvertent execution of malicious code, and that is where good processes and procedures apply. Consider using a dedicated account to remove quarantined data from the system, configured according to the principle of least privilege.
Cloud-based analysis may be beneficial and organisations should carefully weight up the benefits and drawbacks of using remote analysis capabilities. Access to global threat intelligence capabilities is nowadays and important element in improving detection of emerging threats. Depending on the AV product, it may be possible to retain access to global threat intelligence indicators without disclosure of sensitive intellectual property to the vendor.
Another important aspect is coverage. Most organisations fail to apply AV with a diversity principle in mind, and single-vendor AV is a common sight across many large-scale infrastructure. This misses an important opportunity. The idea behind diversity is to avoid dependence on a single vendor signature or heuristic algorithm.
In theory, combining multiple vendor offerings improves coverage and minimises the blind spots in AV signature effectiveness. In a rapidly evolving worldwide outbreak, some vendors may be quicker than others in pushing out an update to your deployment. Moreover, diversity ensures no single vulnerability can be exploited to cut through an infrastructure and undermine security controls.
Particularly for data ingress, multiple vendors should be encountered where possible in order to maximise the probability of a true positive detection. For example, inbound email should be scanned by Vendor A, and endpoint files should be scanned by Vendor B. Another option is to implement segregated import facilities, aka sheep dips, where diversity can be maintained using different products.
Social engineering attacks, in relation to AV, should also be considered. Implement policies and training that improve employee awareness of potential attack vectors, that may undermine AV protection.
Finally, keep the AV configuration secure. The precise settings and policies should be protected, to ensure attackers are not able to easily determine the security configuration used.