Countering Advanced Persistent Threats

This week’s ISSA-UK Chapter meeting addressed the subject of the Advanced Persistent Threat (APT). It was illuminating to hear four very different perspectives from a government expert, an engineer, a banker and a top US technologist.

Surprisingly, none of the speakers seemed to grasp the true nature of an APT. They described it as either a method of attack used by governments and criminals, an undetectable Trojan, or just another form of malware attack. In fact, an APT is exactly what it says: a threat that is both sophisticated and persistent. It’s someone that’s after your secrets: someone prepared to invest serious expertise, time and money to get them, and who will not go away, even after they’ve got them.

Each speaker recommended a different solution. The answer was either to share intelligence, install monitoring technology, educate your staff, or implement self-encrypting drives. These are all useful measures. But only the last one is guaranteed to eliminate  a major vulnerability that enables the type of deep-seated, covert attacks associated with APTs. The rest simply improve your odds of detection, which is not good enough, since an attacker only has to succeed once to succeed.  

One speaker claimed “There is no silver bullet technology solution”. That might indeed be true. But there are several available security technologies that are highly effective, yet not commonly deployed. Perhaps the real exposure is that today’s security community is too obsessed with compliance and established process, and takes insufficient interest in emerging security technologies.  

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

David, can you please elaborate how self-encrypting drives eliminate APT vector? I fail to see the connection. Regards Vladimir
Yes, the APT is persistent...but not because of an unbelievable sophistication. If the victim organization is not monitoring, and has neither network- nor host-visibility, then of course they appear sophisticated. Most things do until you understand them. And I'm at a loss in understanding how self-encrypting hard drives are "guaranteed to eliminate the current attack vector associated with APTs." The fact is, if you can access your hard drive, or the hard drive where the data can the APT.
The point I was making is that SEDs protect the boot process, eliminating the possibility of planting undetectable code in this area. Yes, there are other places to plant Trojan code, but this is the most effective way of evading detection.
What, pray tell, does a "self-encrypting drive" do to prevent data exfiltration? Thus far from what has been reported APT actors have used social engineering and 0day exploits to gain control of a victim's machine. From that foothold they gain control of other machines, all the way to the systems that hold the data they're after. The important point here is that they gain control of the machines, which means they can take screenshots, capture keystrokes, etc. Even if all the data on a machine is encrypted, it has to have a decryption method in order for the legitimate owner to use the data. Once they attacker has control of a machine, they can see everything the legitimate owner does and mimic it. Encryption does not protect against this in the slightest. So the world wants to know: how do "self-encrypting drives" defeat that? -c
Avoid detection by... what? Anti-virus? Most of the malware payloads that are dropped are custom and not detected by AV. Once the box is popped by the original exploit and privileges have been escalated, AV can be disabled or crippled any way. It's not like your typical engineer or IT admin is going to be manually combing their file system every day.
The point I make is that we should aim to close down major areas of exposure, rather than just apply less-than-perfect operational controls. I'd be astounded if you did think that protecting the boot process is not a major step towards preventing long range, hidden attacks. Trusted computing architectures and secure development techniques are the major strategic tools to achieve that. Smart monitoring technologies are also useful controls. But prevention is superior to containment.
Granted I haven't worked in this in a few years, but I doubt a 'self-encrypting drive', aka pre-boot measured launch, aka TPM would have effectively mitigated any APT-linked attacks. Are you saying they've just to overwriting my MBR, manipulating the kernel image or trying to virtualize the OS? I don't think you guys know what that technology does exactly, nor how it works.. you're heart is in the right place, perhaps we should just cut to the chase and learn Mandarin.
OK, perhaps my description of the vulnerability was a bit too sweeping. I've changed "the current attack vector associated with APTs" to "a major vulnerability that enables the type of deep-seated, covert attacks associated with APTs".
The current approach clearly does not work. Perhaps we should think about this in a different way... Firstly, from a corporate's point of view, these attacks will always be very difficult to defend again with the current, almost homogeneous, network, OSes and applications. Under typical configurations in the most common OSes, rogue executables inherit very powerful user trust levels (pretty much full file-system and network access by default, for example). OS technology needs to advance, specifically in application and data trust and security compartmentalisation. This is an area ripe for improvement - does notepad.exe really need full network access? Then why does it have it by default? Limit the default trust levels and you limit the scope for malevolent programs. Secondly, we need an international approach to the problem. ISPs cannot track the source of the attacks when they occur outside of their networks (their electronic borders, if you like). Within a country, the police forces and judicial systems can ensure proper tracking across multiple ISPs. However, when this traverses international borders, we are dependent on international police force co-operation and ISP assistance - this is an area asking for a fresh, wide-ranging review. If we can develop working relationships amongst these groups at a multi-national level, we can move towards solving (or at least containing) the problem - in the worse case scenario, perhaps we should disconnect those countries that do not play ball?
Self Encrypting Drive are more than just an encryption device. It is an important security tool as well but most of the advanced features while in the firmware of the drive are still only demonstration capabilities in the field. We have shown full data isolation between logical block arrays on a SED. The drive partition are unlocked with an OR statement that will provide extremely strong Isolation between boot environments. For example My PC and My company PC or My PC and My Cash management PC. Simple to operate but requires a reboot. Using the Drive to supervise the Boot of a Bare metal Hypervisor in conjunction with the TPM boot integrity. Demonstrated at last year’s NSA trusted computing conference. It will assure that there has been no modification to the boot image or the load of the bare metal Hypervisor. If all is good the machine will unlock the drive. It is like nac but all local. Both of these capabilities are interesting tools in the tool box. We need all of the hardware to be characterized and verified at boot. We also have to start somewhere Machine ID followed by Boot integrity is a good start. Move all access certs private keys to hardware so if a machine is taken over credentials can’t be stolen. Agreed not a silver bullet but an important tool. Steven Sprague Wave Systems
The presentation I gave showed using a TCG TPM's capability to provide a measured boot (measuring PCRs 0, 2, and 4 for example). 0,2, and 4, (BIOS, Option ROMs, and MBR) for example, if changed can execute code preboot and like the Apple iPhone Jailbreak or the Android "Rooting" use the same vulnerability to rewrite critical pieces of the OS and thereby inject kernel viruses which are the worst possible APT (I'm pretty certain of that). MBR is the easiest of these three PCRs (0, 2, 4) since it can be rewritten by anyone with Administrator priviledge in the running OS. It is certainly the attack vector of preference by any attacker who wishes to install a kernel virus. We have demonstrated that in self-encrypting drive preboot can detect a malignant MBR and self-heal the MBR, thus both providing the ability to report out an APT attack and also healing it without stopping the boot process for the user. Just FYI. That was the talk.