The facts on the cyberattacks
Many of you who follow me of a geekier bent will be aware of what I write in this post. But for those of you who aren't that familiar with cybersecurity, today's hearings have brought up some points that I think should be understood by anyone trying to evaluate the government's (and parts thereof) and individual politicians' statements. To sum up: the source of a cyberattack is always
verified only after the fact; cyber intelligence and cybersecurity experts do
generally know what they're talking about; we can
tell the difference between Russia, China, and a morbidly obese bedridden individual; the Democrats aren't to blame; and Hillary's private email server had nothing to do with it.
If you want to know the details, presented in a way that I think does not require any special knowledge of computer security or cyber intelligence:
1. The idea that to definitively catch hacking, you have to "catch them in the act" is totally incorrect.
This is an idea put forth by Mr. Trump as early as statements weeks before the election, but he made it most succinctly in a tweet on 12 Dec. (at https://twitter.com/realdonaldtrump/status/808300706914594816
): Unless you catch "hackers" in the act, it is very hard to determine who was doing the hacking. Why wasn't this brought up before election?
This is so
incorrect as to leave my head spinning. The basic idea of catching someone "in the act" as being more probative may be intuitive, particularly if you get your information about hacking from dramatic depictions in movie and TV. But I've been involved in investigating attacks on my prior employers' systems many times, and I can testify unequivocally that this is rarely—almost never—the case with hacking.
There are a few reasons for this, but it basically comes down to the difference between crimes in "cyberspace" (i.e., on computer networks, principally the Internet) and crimes in "meatspace". My apologies for being pedantic, but let me break it down to some perhaps obvious basics. In meatspace, people have eyes and ears; "catching someone in the act" means that a person who can later testify has seen or heard the crime while it is in progress.
But with computers, there's no such thing as direct experiential evidence.
First responders attempting to stop the attack (if still in-progress) and mitigate its effects, and investigators attempting to ascertain the source of the attack, can only use the output of computer programs to build evidence. And nearly universally, the programs used to do this forensic work "log" what they do—meaning they keep a detailed, timestamped, immutable record—or, more commonly, work on logs
generated by other programs.
This is such an ubiquitous characteristic of our forensic tools that in "post mortems", analyses which most professionally-managed sites do after any large-scale outage—whether cyberattack-related or not—we tend to discount any hearsay evidence. If a responder says they saw a certain alert or a user or administrator noticed an unusual event, we generally use that testimony only to guide us in reconstructing events, not as evidence itself.
This is for several reasons:
a) because responders are only human, and long experience has shown that in the heat of an incident—particularly an adrenaline-pushing incident like many in-progress cyberattacks are likely to be—responders do not have faultless memory, particularly when it comes to sequence of events or sense of time intervals;
b) much or all of the sort of evidence we're interested in are names and numbers—port numbers, service names, system utilization percentages, Internet addresses, times—or other arbitrary information of the type that humans are poor at recollecting perfectly
— and, for many such kinds of testimony, a slightly-off recollection is worse than no recollection at all;
c) Humans are very good at recognizing patterns, even when no pattern is there
. This has the unfortunate result that responders in-the-moment often come to unwarranted conclusions based on a pattern they think they see. (To make this a bit more concrete, I can think of several times when an incident response I was involved in temporarily went on a wild goose chase because a responder said they recognized an Internet address from a prior event, only to later discover that the address they thought
they had recognized was actually a digit transposition or numerically close to the other address.)
d) Because humans involved can't directly "see" an attack, only the output of tools used to monitor the attack, it's nearly always possible to use logs to recreate what the human had seen—a sort of "crime scene reenactment", if you will—that surpasses in precision, accuracy and detail anything the humans can recall.
To put this into non-cyber terms: suppose a bank vault break-in is observed in realtime by a security guard—not directly, but by the guard's watching security camera feeds. If the guard testifies that he saw four robbers enter the vault on his screen, but the recording of that same feed shows only three robbers, it would be ludicrous to give the guard's recollection of seeing four the same weight, as evidence,
as the recording itself. It might
prompt an investigation into whether the recording had been tampered with, but most likely it would just be written off as a poorly-recollected detail.
Responding to or investigating a cyberattack is like investigating a meatspace crime where all witnesses were only able to witness recorded camera feeds. The existence of the recording not only makes human testimony redundant, but means that it doesn't matter
whether the investigation is being done at the time or later—at minimum, the same information will be available after the fact as during, and more likely, more
information will be available later.
2) Most cyberattacks aren't the kind you think they are.
Here I must explain what we call "APT's", or "advanced persistent threats". A cyberattack being an APT basically means that:
i. The attack uses sophisticated techniques;
ii. The attack continues for a prolonged period of time (days, weeks, or months) before being discovered; and
iii. The attack is directed at a single target.
("Target" has a very loose definition here; it could be a particular document or database, but is more likely against a certain network, or the entity who owns that network.)
Most hacking is not
part of any APT. I've written about this before, but the misconception that most attacks are
APT's is one of the most harmful misconceptions about cybersecurity for laymen to hold. It leads people to say things like, "yeah, I know that website I put up for my kid's choir doesn't have the latest security patches, but who's going to try to hack a site like that?" To the contrary, most attacks are aimed not at stealing data from the owner of the machine under attack, but to gain secret control of the machine for use in a later attack. It doesn't matter the function of the machines under attack in this context: your kid's choir's web server is a perfectly good launchpad for an attack on something else of greater value.
Many attacks, such as DDoS (distributed denial of service), depend on the attacker having access to an army of unwitting accomplices in the form of computers like that youth choir web server. The attacker may use
this army ("botnet") in the service of an advanced persistent threat, but the APT is directed at a target entirely distinct from the owners of the botnet. The attacker effectively is mounting two different attacks: an APT against the attacker's true target, and a dragnet attack to recruit any machines that can be successfully compromised so that they can be turned to the attacker's use.
3) The idea that an attack from a state actor could be indistinguishable from that of a lone hacker operating independently (the "400-pound person sitting on a bed") is theoretically possible, but in practice quite implausible.
This follows from the previous point. State-actor attacks are usually some variety of APT or in the service of an APT. The government of country X wants access to data held by government (or ministry or corporation) Y. They mount an APT against Y using various means, and usually a combination of them:
a) Specific penetration tests, where a known vulnerability (known to the attacker, anyway) is used to gain access;
b) Denial-of-service (DoS) or distributed DoS (DDoS) attacks;
c) "social engineering" attacks;
d) insider (mole) attacks,
as well as others. A few points of explanation here:
• In a known-vulnerability penetration, it's only necessary that the attacker
know the vulnerability. A site can be fully patched and be following all the best security practices but still compromised by a vulnerability not known to the security community. These are called "zero-day attacks" (so named because their identification means the target had no time to fix the vulnerability before it was used against them). State-sponsored actors are not the only, or even primary, users of zero-day vulnerabilities. But when security people speak of "14-year-old hackers", they're usually referring to neophytes using "root kits" or other prepackaged hacking tools available online, which, by definition, do not rely on zero-day vulnerabilities. (Are there precocious 14-year-olds who have found previously-unknown vulnerabilities? Sure. It's just not a particularly likely
scenario, certainly not more likely than zero-day vulnerabilities being used by state actors, many of whom have been known to stockpile information about such vulnerabilities for use as warranted.)
• A DoS or DDoS may not seem to be particularly useful in an APT where the desire is to gain illicit access, since, if a service is down, it can't be accessed anyway. This is true, but service-denials can still be a useful tool because
i. They cause a distraction—both human, in that responders will be busy trying to get service back up and likely not focusing on other simultaneous attacks, and technical, in that an overloaded system typically has impaired monitoring. (Think of the trope in espionage-thriller movies where the spy pulls the fire alarm and escapes detection by melting into the evacuating stampede.)
ii. Overloaded systems—particularly ones overloaded by a massive DDoS—sometimes expose vulnerabilities the same systems, under normal operation, are impervious to. For instance, a common response tactic to a DDoS on a website is to temporarily replace the normal servers with one(s) optimized for speed that do nothing but serve a "fail whale" sort of page in order to let the other overloaded systems calm down. These "fail whale" servers are often hand-built outside the normal web server build process (among other reasons because, if the outage isn't a DDoS but is due to a programming or configuration failure inside the system, a "fail whale" server built using normal practices might fail in the same way as well). This in turn means that such servers often lack the latest patches or may have vulnerabilities that the normal-traffic system does not.
iii. A DDoS "botnet" gives the attacker thousands or millions of points from which to mount their attack(s). The attacker's ability to conceal their location and being able to quickly move from one attack machine to another (to prevent trivial blocking from being successful) is very useful to an APT attacker.
• "Social engineering", or SocEng, refers to a variety of attacks where the attacker uses an unwitting accomplice inside to get access otherwise unobtainable to them. Clinton campaign chair John Podesta's responding to a phishing email is an example of social engineering. While Podesta's incident is one that should have been preventable, it is hard or impossible to get everyone in a large organization who might be useful to an APT attacker to follow security procedure 100% of the time—particularly since prevention of many types of social engineering attacks requires the person unwittingly under attack to be rude or create inconvenience for the attacker (who, for all they know, is not an attacker but a coworker, customer or client).
If you've ever taken a phone call from your bank, insurance company, healthcare provider, cable company, etc., and answered their security questions before they can tell you why they're calling, then you've made yourself a possible vector for a social engineering attack. The "correct" response is to ask the caller how to reach them starting with a phone number you can obtain and authenticate yourself
, such as the number on the back of your credit card, hang up, and call back before providing any personal information. But this is inconvenient, rude, and sometimes impossible. It's hard enough to act correctly in these circumstances as a customer, but treating a customer or client in the way necessary to mitigate SocEng attacks if the caller isn't a real customer or client can risk disciplinary or poor-performance action for an employee who is supposed to be helpful to callers.
• The next step beyond social engineering, where the attacker uses unwitting accomplices, is actually installing moles within the organization. This is so difficult (and so illegal) that state actors are the near-exclusive deployers of this tactic. But they do it. Indeed, many multinational companies keep operations in countries that are known state-sponsors of corporate-espionage cyberattacks siloed, and have the rest of the company act as though there are definitely moles at all levels within the siloed subsidiaries.
The point you should be deriving from all this is that it most definitely is
possible to tell likely state-sponsored attacks from ones conducted by "some random 14-year-old". And this is even before
considering detailed forensic analysis, where logs can show likely origin, types of attack that are distinctive of particular state actors, notes, comments or source code left behind whose language and terminology can provide clues to the attacker's identity, and so on.
4) The idea that the DNC is responsible for its own hacking is, at best, a dangerous one.
What we know of the phishing attack on John Podesta's account certainly doesn't paint his or his IT team in the best light. There are mitigating factors at play here, but let's dispense with them for the moment and imagine that the entirety of all attacks on Democratic Party targets
was due to Podesta's response to the phishing attack and the failure of the campaign's IT people to warn him effectively. Even accepting that, using it to blame the DNC for its own hacking—even if it were a true and complete account of their actions (and it's not)—is like blaming someone leaving their door unlocked for getting burgled, or (not to put too fine a point on it) claiming someone's dress or behavior makes them responsible for their own rape. We wouldn't accept this line of reasoning for any other crime; we shouldn't accept it for this one, either.
Not to mention, there's evidence that Republican targets were hacked as well. If we assume that the weird concatenation of mistakes that resulted in John Podesta's capture by a phishing attack didn't also occur at the GOP, then one can reasonably assume that the attackers could
have gained the access to Democratic targets they wanted through other means.
5) Hillary Clinton's private email server has nothing to do with the attacks being discussed in today's hearings.
This is a line that Republicans at all levels have tried to make fuzzy, but there are simply no shades of gray to fuzz. We don't know of any successful attack on Clinton's private server (though proving the negative, as always, remains impossible). The successful attacks attributed to Russia happened after the private server was permanently shut down.
Mr. Trump's exhortation to Russia at his last press conference to "please" hack into Hillary Clinton's emails to get the deleted ones was unprecedented, but it was never practical.
I hope the above is accurate, helpful to readers who aren't security experts, and isn't slanted by my own partisan bias. (If you disagree, let me know in the comments. I know I skated over a lot of detail for security folks, but as I wrote in the opener, I didn't write this with you in mind as an audience.)