How InfoSec Security Controls Create Vulnerability

  • [アーティクル]

One frequent reality in many intrusions is that attackers don’t target the data they are interested in directly; they target the security controls designed to protect them.  That is, the very solution InfoSec professionals craft to protect assets from risks become the means by which the attackers are able to access them.  They steal legitimate credentials of elevated accounts. They target the account management system.  They use security data such as access control lists and security group memberships to target users for compromise. How did the InfoSec solution become the InfoSec problem?

The Key Aspects that Undermine Security Controls

The protection of information in a network has been long studied by information security professionals. There are lengthy standards, numerous certification regimes, and a bevy of security control solutions for risk management problems.  It is the application of these InfoSec methods without due consideration of the following aspects that leads to networks where the choices in individual risk management decisions fail to create a defensible system:

  1. Lack of recursive threat modeling

  2. Security controls with dependencies that resemble a complex IT org chart

  3. The difficulty in visualizing the security dependency graph, especially as it changes

This doomed security control system then becomes the interim target of intrusions because of its power over the assets the attackers ultimately seek.

Lack of Recursive Threat Modeling

Part of an information security program is defining critical assets and threat modeling risks.  These risks are then minimized by the application of one or more security controls—authentication, access control, vulnerability scanning, and so forth. A critical aspect, however, is that these controls have their own risks. Security controls are not a magical, impenetrable substance.  The controls to protect information and systems are themselves information and systems. 

For example, to protect a sensitive document repository, one might employ access controls and authentication (the access control list, account database, and secrets are information), deploy encryption technology (the keys, their storage, and escrowed instances are information), install a data loss prevention system (an appliance with its own operating system and information), and check for weaknesses with a vulnerability scanner (another system with its own information). 

The selection of controls must be recursively and holistically threat modeled for completeness.  This difficulty in doing this can be exacerbated if the subject matter expertise to do the threat modeling is different at every layer. For example, an InfoSec practitioner using a Data Loss Prevention solution to mitigate sensitive data leaving the network may be an expert on SOX, PCI, and categories of customer PII, but they may not be an expert on the security implementation requirements of a Linux based appliance they procured.  Controls come with risks and must be treated accordingly. 

The Org Chart of IT Creates a Graph of Security Dependencies

Once networks get to a certain size, IT organizations specialize. Endpoint management is handled by one team, whereas the data center is handled by another.  Vulnerability scanning is handled by a dedicated team and identity management by another.  These teams tend to have their own support infrastructure.    InfoSec controls are not separable from IT.  This matrix that exists at an organization level expresses itself as a graph of security dependencies at the information level.  For example, the vulnerability scanning systems may use a “god account” that has admin rights on every host in the network to scan for weaknesses.  The vulnerability scanners may be patched or backed up by a different IT team with admin rights to them.  The vulnerability scanner servers are accessed with admin rights from a set of endpoints that are managed by yet another IT team who has control over those endpoints.  The matrix of IT services arising from domain specialization creates a lattice of critical dependencies, each of which can present opportunities for lateral movement.  If the dependencies of the security controls resemble the complexity of the org chart, it’s time to simplify.

The Difficulty of Visualizing Security Dependencies

Security dependencies are often difficult to see.  Identifying the security dependencies of a host involves significant subject matter expertise to inventory the critical settings: the file servers hosting scripts run on every user logon, the background service that pulls down executables from upstream servers to update themselves, the network printers used by the host that cause it to download and install device drivers, and so on.  Networks are very dynamic.  The provisioning or decommissioning of systems affects the graph.  User login behavior and where credentials are used can vary.  Changes in network connectivity or domain trusts can affect it.  There are hidden edges in the graph—an unpatched server or appliance effectively creates new edges in the dependency graph.  The reuse of a password across different trust domains creates a hidden link.  If you can’t manage what you don’t measure, you can’t prune a graph you’re not visualizing.

This is exacerbated in many environments because the fulfillment of compliance requirements does not leave InfoSec professionals enough time to do the analysis necessary to protect a living network. Management support affects this greatly. If achievement of conformance with various InfoSec standards is all that management supports, then the talent, time, and analysis to ensure the details are right won’t be there.  Analysis of this kind requires whitespace from other compulsory activities.

How do Successful Defenders Cope?

Despite these obstacles, I find defenders at many organizations able to cope with these challenges.  Here are the practices I see in them:

  1. They manage from the terrain, not the map.  They seek to know what’s truly running in their network, not just the services that IT officially manages.

  2. They better manage isolation and compartmentalization leading to fewer spaghetti dependencies to manage.  They reduce the number of ingress and egress paths to remove duplication.

  3. They have a bench of subject matter experts to do the required threat modeling.  They know they can’t secure things they don’t understand. Any technology indistinguishable from magic has no place on their network.

  4. They have a keen appreciation of the difference between the risks of Murphy and Satan.  “Murphy risks” cause problems but ones that are not intentional in nature—for example an outage or commodity malware landing opportunistically on a host in the network.  “Satan risks” are risks with intent. There is an active adversary.  InfoSec security control selection does well against Murphy, but requires different thinking for Satan.

  5. They have a heavy emphasis on detective controls that look for abuse of legitimate access. They “Assume Breach” and work from the assumption that their controls will be compromised and are prepared to work the kill chain starting at the end first.

  6. They have management support for the whitespace required to analyze and defend a complex system. Compliance requirements, while mandatory, are seen as necessary but not sufficient.

  7. They embrace the matrix and coordinate well across their peer IT teams and users of the network.

  8. They employ penetration testing but instead of treating it as a report card, an output, they treat it as an input. They use pentesting in a diagnostic way informing a comprehensive security program.

  9. They do attack research.  They know that knowledge on how to find vulnerabilities and assess their exploitability is just as valuable for defenders as it is for attackers.  Their blue teams bleed red and their red teams bleed blue.

  10. They actively manage their graph. They reduce the number of standing administrators.  They consider the attack surface of their defense. 

Until InfoSec teams are better able to handle the aspects of recursive threat modeling, deal with the matrix effects of IT, visualize their security dependencies better, and find the whitespace to do it all, security controls will continue to be a primary attack surface targeted by attackers in intrusions.  InfoSec regimes also need to do a better job at documenting successful methods and practices for doing this kind of analysis.  It’s critical to get right, because that’s the Defender’s Mindset.

-----

This blog expands on a topic from this tweet: https://twitter.com/JohnLaTwC/status/699304590500634625

Thanks to Tal Be'ery (@TalBeerySec) from the Microsoft ATA team, Adam Shostack (@adamshostack), and Erica E for reviewing a draft of this post.