February 03, 2010
Advanced Persistent Threats In Computer Networks
What you can not hear is the massive silent sucking sound of Western corporate secrets flowing into servers in China.
“The scope of this is much larger than anybody has every conveyed,” says Kevin Mandia, CEO and president of Virginia-based computer security and forensic firm Mandiant. “There [are] not 50 companies compromised. There are thousands of companies compromised. Actively, right now.”
Mandia claims these intrusions are persistent and used for industrial espionage on a massive scale.
Called Advanced Persistent Threats (APT), the attacks are distinctive in the kinds of data the attackers target, and they are rarely detected by antivirus and intrusion programs. What’s more, the intrusions grab a foothold into a company’s network, sometimes for years, even after a company has discovered them and taken corrective measures.
I do not know whether the threat is this large. Are Chinese hackers really sucking massive amounts of proprietary design and business plan data from American, Japanese, and European corporations?
If the infiltrations really are persistent and on a large scale I have some practical suggestions on how to cut them down by orders of magnitude. Analogies with biological systems come to mind. Biological RNA and DNA viruses can only work because they use the same DNA codon mappings to amino acids. The same 3 letter DNA sequences and RNA sequences map in just about all living organisms on this planet. An organism that used a very different set of mappings would likely be immune to existing viruses.
This description is about to get too technical for most people who aren't computer architects or software developers. Sorry about that.
In computing the problem stems from the universal use of the same operating systems, scripting languages, networking protocols, and CPU op codes. The obvious solution: generate custom instruction set with different orderings of bits in op codes. The same compilers (e.g. gcc) could be used with back-end code generators that would read in tables for how to map to specialized bit orderings of existing processor instruction sets.
Take a microprocessor instruction set like some level of the ARM instruction set. Create a description of an ARM processor in, say, VHDL. Enhance the description so that as instructions get fetched their op code bits will get swapped around from the ordering out in memory to the ordering that the CPU understands. The CPU could execute op codes laid out like any conventional ARM processor. But it could fetch from memory in a secret format which the secret version of the gcc back-end would know how to generate for.
Alternatively, the CPU could execute the secret op code layout. At each site the VHDL (or Verilog or other logic description language) could be transformed into a different unique op code layout. Then the compiled processor architecture could be loaded into an FPGA for execution.
Each super-secure site would generate a different secret bit ordering. The odds of a binary code virus getting into the facility and invading servers would be extremely low because the virus writers wouldn't know how to generate legal op codes.
This same approach could be applied to interpreted scripting languages. Developers could still write and debug in, say, Python or Ruby or Perl. But their source code could be translated into a very different looking interpreted language using a secure (not on a network) computer that would read in, say, Python and split out a different secret scripting language whose interpreter could actually be derived from the open source public Python interpreter engine.
The key to this approach is to develop microprocessor descriptions and interpreted languages that lend themselves to automated transformation into functionally equivalent but different looking instruction execution machines.
In a nutshell: automate the generation of obscure execution languages and op code architectures.
Desktops are a harder nut to crack. One way to do it is to just make desktops as akin to X servers. Run the real word processor, spreadsheet, or browser on the secret server's instruction set architecture. Of course, then Open Office and Mozilla Firefox would need to be compiled for each server. This approach is easier to do with open source.
They would just compile source code on the computers they compromise and let the installed compiler take care of the op-codes.
Security by obscurity doesn't work.
If there's not a compiler on the server then they won't be able to use it.
Theoretically sound, but practical difficulties. I'm hobbled at work because my workstation is so tied up with security, (Reasonably so, I have direct access to all our engineering files. I still don't believe that they left the USB ports on my computer!) that they can't install an important company-wide program on it. Your proposal would require every last application that was going to run on a given computer to go through that security center first. Either users are going to become enormously frustrated because of the needed applications that aren't being ported to their boxes, OR the porting process is going to be automated to the point where malware will be able to ride through it. Indeed, what happens when somebody codes a combinatorial attack on the op set encryption into a common application?
Maybe security conscious corps need to resort to dumb terminals connected to mainframes?
BTW, I proposed this sort of thing as a fix for biological viruses a couple of decades ago. Maybe they ought to incorporate it into SENS?
If there is no compiler on the server, then everything must be shipped to the server as binaries. Whatever mechanism exists for that will then become the attack vector. It wouldn't take much to sample a common, known executable to build an op-code translator.
As good as your solution is - the weakest point is always the social engineering.
If the Chinese want something bad enough they will use insiders to get the technical details they need to provide their hackers with the specs necessary to create a target specific attack.
Of course your solution at least "locks the door" of the house - so targets of opportunity would be significanttly lowered...
I think we all need to get on board with Time Magazine, the WSJ, and the Total Information Awareness program - and let the government force monopolistic ISP's to "license" each one of us to use the Internet. That way that cowardly anonymity will be dispensed with and the secret, unredressable, "No Surf List" can swell nicely to help justify the Homeland's Budget Increases!
Furcht über alles!!
I am not presenting this idea as a general solution for individuals. But it could work in situations where security needs are high and the source code is available for applications.
If the only way to install software on a computer is to carry the software to the computer then people in China can't attack the computer. The difficulty of attack becomes much greater and so the frequency of attacks goes way down.
Corrupt insiders are not always available. Also, my scheme reduces the number of people whose corruption within an organization can result in penetration. One can have a large IT staff and very few of them could know how to translate source code into the secret instruction set on the servers.
A key assumption is that there is data ("secrets") that's available in concentrated form on certain machines (which I agree with) but that there aren't dilute parts of this data spread all over all the computing machinery in the organisation (which is unknown). In the absence of detailled knowledge about how the industrial espionage is being done, that's an open assumption. For exaple, maybe all the engineering blueprints are only on the secure server, but if each component has been printed out at some time and a copy of everything that's passed over the wire to the printer is taken then the whole blueprints can be assembled. Granted it's more human-work than cracking the secure store, but if it's still profitable... That's just one example of how dilute secrets appear on lower security machines, there are certainly others (even just trying to correlate peoples calendars to figure out important client relationships).
That's why I'm sceptical that the way to stem the tide is to have a subset of super-secure machines. Mechnanisms that increase security on every computing device, even if less secure in an absolute sense, may be more effective.
Ah. I'd thought you envisioned this sort of thing for enterprise-wide application.
But if it's only going to apply to select machines, the case for using dumb terminals with secure communication only improves.
If the only way to install software on a computer is to physically carry it there, you don't need to scramble the op-codes. But such a computer--presumably locked in a secure closet with no communication to the outside world--won't have any access to the internet and vice versa.
While Chinese hacking is a problem, I think the NSA is well-aware of Chinese activity, and they certainly have the resources to manage this.
Defense is inherently difficult, but the US employed a highly-successful counter-espionage program against the Soviets in the Cold War, by deliberately allowing the Soviets to steal tampered data. I wouldn't be surprised if such a program is already in place. Unfortunately, the Chinese are not idiots either, and they certainly possess the technical means to validate any technology they have stolen.
One useful model for server stack design is the PS3, which was incredibly difficult to hack, despite physical access to the machine, and is still not completely hacked. They used overlapping worst-case scenarios for each level in the hardware/software stack, with independent validation schemes at each level, already assuming that other levels had been compromised. The PS3 has dedicated hardware snooping the buses, and protected memory and processor resources for the monitoring OS. Currently, the only hack available is sending a voltage pulse to temporarily glitch the monitoring circuits. This is a technique that is obviously unavailable to the remote hacker.
Based on the PS3, the technological-fix seems to be strong encryption, with hardware-only decryption, at runtime, and separate hardware (basically a totally-isolated second computer) constantly monitoring the decrypted memory space. Obviously this doesn't prevent a sweet-talking Chinese agent from simply getting source code from a besotten programmer.
This approach of locking the data is very similar to the use of DRM in movies and music. The posted example uses a tokenized language of some sort, but the net result is the same. The problem is you must give not only the encrypted data but the key as well or the processor will be unable to use the information. This is true even if you place a unique key in a processor with physical defenses. There has been some limited success with smart cards, but that success is fleeting and the added cost is significant. Once a determined attacker has both the code and the key it becomes a matter of time and money to breach security. Defending against attacks is hard, the defender has to defend everything, the attacker only needs one successful attack vector.
Traditional policing methods work, but they're labor intensive as automated intrusion detection, and traffic pattern analysis improve this risks will shift to some different form. Your main risk is and likely always will be a motivated insider.
I am very interested in what the NSA will have to say (if anything) publicly, they are VERY good at this kind of thing.
To clarify my point, I'm not sure what Randall intended. My point was that any large enterprise has huge amounts of "computational machinery" in it, beyond just dedicated servers and workstations. It would be theoretically possible to apply Randall's scheme to absolutely everything -- Blackberrys, electonic whiteboards, printers, secretarial machines, projectors, etc -- in the enterprise. (Just because we don't think of many of these things as "computers" doesn't mean they're not potentially powerful enough to install some eavesdropping software on.) But that means having to buy absolutely everything with bespoke CPUs. Otherwise you put a dividing line between machines which are secured and those which aren't because they won't "have sensitive stuff on them". But there's a high chance that those unsecured machines will at times have "diluted" sensitive stuff on them which is potentially capturable. Dumb terminals would solve part of this, but there's more types of "computing device".
(Look at "true cold war stories" tv programmes where four or five separately "not secret" facts were used to deduce some particular secret.)