Are your defenses making you stronger or weaker?

F-Secure Consulting has recently published an advisory on the Carbon Black Endpoint Detection & Response (EDR) product where a web-based, cross-site scripting (XSS) issue in the analyst portal can lead to total control of all monitored endpoints.

Attackers generally focus on areas that are relatively low cost to develop exploits for and that provide the largest potential victim population. In the past this was the operating system but as they become harder targets, focus is switching to software installed in the OS. F-Secure Consulting is seeing a focus on defensive products by attackers in Incident Response engagements and are exploiting these opportunities in our targeted attack simulations.

Security issues in security products are more common than might be assumed. This is in part because such products are often highly complex, highly privileged and highly exposed. It will always be difficult to prevent security issues in this combination.  

Consider the following case studies:

• A number of issues in antivirus products found by Tavis Ormandy allowed exploitation and instant high privileges on the endpoint.
• A number of issues in an email filtering solution would have allowed an email to gain an instant foothold inside the perimeter.
• Vulnerabilities in a Microsoft Exchange plugin to inspect malicious attachments would have allowed an attacker to gain instant control of Exchange itself, which not only stores emails but which provides a highly privileged jump off point into the rest of the organization.

So the question is raised, how do organizations ensure that defensive products that are intended to reduce the risk of compromise don’t leave them exposed to unexpected or unanticipated risks?

The key is to treat security software just like any other software and ensure implementations have a strong architecture.

When implementing a security product (or indeed anything that changes the attack surface of the organization) it needs to be architected well. If an analyst’s portal could potentially lead to privileged code execution across the enterprise then that portal needs to be segregated from attackers. Ideally this means a separate hardened computer not connected to the internet and preferably not to the rest of the corporate network is used to access the portal so that the attack surface is reduced.

The product or service being installed should be threat modelled by your organization, appropriately segregated and itself monitored so that the risk of compromise is contained, and chances of detecting compromise increased.

Other steps include questioning your vendors on their product security. Key questions to ask are:

• Do they have a secure development lifecycle?
• Can they evidence security assessment of their product?
• What is their threat model for the product?
• What is the secure configuration guidance and recommended architecture for their product?

Once installed and configured, the solution can then be technically tested to ensure it has been set up correctly and that vendor security claims have been validated.

These considerations are important for all changes to your environment, and particularly those that will have high privileges, access to sensitive assets or are directly reachable by attackers. Active management of your attack surface is management of the routes available to an attacker. Only through strong architecture and assurance can you ensure that efforts reduce rather than increase the risk.