Attacking client security: Our strategy

In order to exercise the endpoint security capabilities of these products, we focused on launching attacks that could occur if the basic network and machine defenses all have failed.

In order to exercise the endpoint security capabilities of these products, we focused on launching attacks that could occur if the basic network and machine defenses all have failed. We chose attacks that a machine would be open to if the client security component has become the last line of defense that must attempt to protect the system itself and the network to which it is connected from further damage.

Client systems, as defined in this test, are desktop systems that physically reside within an enterprise facility or mobile systems that operate inside and outside the facility. In either case, we assume a certain amount of compromise might already have happened. For example, an attacker already could have found an exploit that let him execute code on the client, including code that let him gain administrator privileges. We don’t expect that these parameters are commonplace. But we do expect that situations like these will happen and the network defenses have to be prepared to deal with these problems if and when they arise.

We assumed the attacker might have physical access to the system and can gather trace data – this could be because the mobile user leaves a machine unattended at an Internet café or the attacker is someone who has physical access to the desktop, one of the night cleaning crew, for example.

Our basic testing objectives were straightforward:

•  Determine whether the target could be attacked without being detected.

•  Assess the level of effort being used to defend the machine.

•  Compromise the defenses.

•  Attack the machine.

Because we knew we were attacking a target with some sort of client security defenses in place, we assumed and were prepared for a variety of levels of sophistication for those defenses. For example, the machine could have defenses that perform blocking but do not detect or report simple probes such as port scans, or it could have offer detection and blocking of anomalous program or network behavior.

We used trace tools and network scanning tools to reconnoiter the target. We also investigated a case in which the attacker has physical access – so we could see what you would learn if you had, even for a brief time, access to the system itself.

Because these are all enterprise clients, we looked at the target as not only the client system itself, but also as the entry point into the company to which it connects. Using this assumption, we needed to investigate the idea of blinding the management server, if necessary, to avoid detection while a potentially time-consuming attack is mounted. We also looked at what it would take to disable the defenses so as to use the client for further attacks or to gain time to further compromise the client itself.

Our approach assumes the attacker is in a situation in which he might have several significant advantages such as physical access, network access or administrator rights. While not commonplace, it is not sound security practice to assume machines are always physically secure, or that all software that is legitimate by policy will not contain a compromise, or that the network a client is connected to is not being tapped. We tested for these non-trivial, more extreme cases because that is where client security products become worthwhile investments.

Back to review: “Endpoint security products aid in client defense”