Security Orchestration and Incident Response

Last month at the RSA Conference, I saw a lot of companies selling security incident response automation. Their promise was to replace people with computers ­-- sometimes with the addition of machine learning or other artificial intelligence techniques ­-- and to respond to attacks at computer speeds.

While this is a laudable goal, there's a fundamental problem with doing this in the short term. You can only automate what you're certain about, and there is still an enormous amount of uncertainty in cybersecurity. Automation has its place in incident response, but the focus needs to be on making the people effective, not on replacing them ­ security orchestration, not automation.

This isn't just a choice of words ­-- it's a difference in philosophy. The US military went through this in the 1990s. What was called the Revolution in Military Affairs (RMA) was supposed to change how warfare was fought. Satellites, drones and battlefield sensors were supposed to give commanders unprecedented information about what was going on, while networked soldiers and weaponry would enable troops to coordinate to a degree never before possible. In short, the traditional fog of war would be replaced by perfect information, providing certainty instead of uncertainty. They, too, believed certainty would fuel automation and, in many circumstances, allow technology to replace people.

Of course, it didn't work out that way. The US learned in Afghanistan and Iraq that there are a lot of holes in both its collection and coordination systems. Drones have their place, but they can't replace ground troops. The advances from the RMA brought with them some enormous advantages, especially against militaries that didn't have access to the same technologies, but never resulted in certainty. Uncertainty still rules the battlefield, and soldiers on the ground are still the only effective way to control a region of territory.

But along the way, we learned a lot about how the feeling of certainty affects military thinking. Last month, I attended a lecture on the topic by H.R. McMaster. This was before he became President Trump's national security advisor-designate. Then, he was the director of the Army Capabilities Integration Center. His lecture touched on many topics, but at one point he talked about the failure of the RMA. He confirmed that military strategists mistakenly believed that data would give them certainty. But he took this change in thinking further, outlining the ways this belief in certainty had repercussions in how military strategists thought about modern conflict.

McMaster's observations are directly relevant to Internet security incident response. We too have been led to believe that data will give us certainty, and we are making the same mistakes that the military did in the 1990s. In a world of uncertainty, there's a premium on understanding, because commanders need to figure out what's going on. In a world of certainty, knowing what's going on becomes a simple matter of data collection.

I see this same fallacy in Internet security. Many companies exhibiting at the RSA Conference promised to collect and display more data and that the data will reveal everything. This simply isn't true. Data does not equal information, and information does not equal understanding. We need data, but we also must prioritize understanding the data we have over collecting ever more data. Much like the problems with bulk surveillance, the "collect it all" approach provides minimal value over collecting the specific data that's useful.

In a world of uncertainty, the focus is on execution. In a world of certainty, the focus is on planning. I see this manifesting in Internet security as well. My own Resilient Systems ­-- now part of IBM Security --­ allows incident response teams to manage security incidents and intrusions. While the tool is useful for planning and testing, its real focus is always on execution.

Uncertainty demands initiative, while certainty demands synchronization. Here, again, we are heading too far down the wrong path. The purpose of all incident response tools should be to make the human responders more effective. They need both the ability and the capability to exercise it effectively.

When things are uncertain, you want your systems to be decentralized. When things are certain, centralization is more important. Good incident response teams know that decentralization goes hand in hand with initiative. And finally, a world of uncertainty prioritizes command, while a world of certainty prioritizes control. Again, effective incident response teams know this, and effective managers aren't scared to release and delegate control.

Like the US military, we in the incident response field have shifted too much into the world of certainty. We have prioritized data collection, preplanning, synchronization, centralization and control. You can see it in the way people talk about the future of Internet security, and you can see it in the products and services offered on the show floor of the RSA Conference.

Automation, too, is fixed. Incident response needs to be dynamic and agile, because you are never certain and there is an adaptive, malicious adversary on the other end. You need a response system that has human controls and can modify itself on the fly. Automation just doesn't allow a system to do that to the extent that's needed in today's environment. Just as the military shifted from trying to replace the soldier to making the best soldier possible, we need to do the same.

For some time, I have been talking about incident response in terms of OODA loops. This is a way of thinking about real-time adversarial relationships, originally developed for airplane dogfights, but much more broadly applicable. OODA stands for observe-orient-decide-act, and it's what people responding to a cybersecurity incident do constantly, over and over again. We need tools that augment each of those four steps. These tools need to operate in a world of uncertainty, where there is never enough data to know everything that is going on. We need to prioritize understanding, execution, initiative, decentralization and command.

At the same time, we're going to have to make all of this scale. If anything, the most seductive promise of a world of certainty and automation is that it allows defense to scale. The problem is that we're not there yet. We can automate and scale parts of IT security, such as antivirus, automatic patching and firewall management, but we can't yet scale incident response. We still need people. And we need to understand what can be automated and what can't be.

The word I prefer is orchestration. Security orchestration represents the union of people, process and technology. It's computer automation where it works, and human coordination where that's necessary. It's networked systems giving people understanding and capabilities for execution. It's making those on the front lines of incident response the most effective they can be, instead of trying to replace them. It's the best approach we have for cyberdefense.

Automation has its place. If you think about the product categories where it has worked, they're all areas where we have pretty strong certainty. Automation works in antivirus, firewalls, patch management and authentication systems. None of them is perfect, but all those systems are right almost all the time, and we've developed ancillary systems to deal with it when they're wrong.

Automation fails in incident response because there's too much uncertainty. Actions can be automated once the people understand what's going on, but people are still required. For example, IBM's Watson for Cyber Security provides insights for incident response teams based on its ability to ingest and find patterns in an enormous amount of freeform data. It does not attempt a level of understanding necessary to take people out of the equation.

From within an orchestration model, automation can be incredibly powerful. But it's the human-centric orchestration model --­ the dashboards, the reports, the collaboration --­ that makes automation work. Otherwise, you're blindly trusting the machine. And when an uncertain process is automated, the results can be dangerous.

Technology continues to advance, and this is all a changing target. Eventually, computers will become intelligent enough to replace people at real-time incident response. My guess, though, is that computers are not going to get there by collecting enough data to be certain. More likely, they'll develop the ability to exhibit understanding and operate in a world of uncertainty. That's a much harder goal.

Yes, today, this is all science fiction. But it's not stupid science fiction, and it might become reality during the lifetimes of our children. Until then, we need people in the loop. Orchestration is a way to achieve that.

This essay previously appeared on the Security Intelligence blog.

Posted on March 29, 2017 at 6:16 AM28 Comments

Kalyna Block Cipher

Kalyna is a block cipher that became a Ukrainian national standard in 2015. It supports block and key sizes of 128, 256, and 512 bits. Its structure looks like AES but optimized for 64-bit CPUs, and it has a complicated key schedule. Rounds range from 10-18, depending on block and key sizes.

There is some mention of cryptanalysis on reduced-round versions in the Wikipedia entry. And here are the other submissions to the standard.

Posted on March 28, 2017 at 6:26 AM71 Comments

The TSA's Selective Laptop Ban

Last Monday, the TSA announced a peculiar new security measure to take effect within 96 hours. Passengers flying into the US on foreign airlines from eight Muslim countries would be prohibited from carrying aboard any electronics larger than a smartphone. They would have to be checked and put into the cargo hold. And now the UK is following suit.

It's difficult to make sense of this as a security measure, particularly at a time when many people question the veracity of government orders, but other explanations are either unsatisfying or damning.

So let's look at the security aspects of this first. Laptop computers aren't inherently dangerous, but they're convenient carrying boxes. This is why, in the past, TSA officials have demanded passengers turn their laptops on: to confirm that they're actually laptops and not laptop cases emptied of their electronics and then filled with explosives.

Forcing a would-be bomber to put larger laptops in the plane's hold is a reasonable defense against this threat, because it increases the complexity of the plot. Both the shoe-bomber Richard Reid and the underwear bomber Umar Farouk Abdulmutallab carried crude bombs aboard their planes with the plan to set them off manually once aloft. Setting off a bomb in checked baggage is more work, which is why we don't see more midair explosions like Pan Am Flight 103 over Lockerbie, Scotland, in 1988.

Security measures that restrict what passengers can carry onto planes are not unprecedented either. Airport security regularly responds to both actual attacks and intelligence regarding future attacks. After the liquid bombers were captured in 2006, the British banned all carry-on luggage except passports and wallets. I remember talking with a friend who traveled home from London with his daughters in those early weeks of the ban. They reported that airport security officials confiscated every tube of lip balm they tried to hide.

Similarly, the US started checking shoes after Reid, installed full-body scanners after Abdulmutallab and restricted liquids in 2006. But all of those measure were global, and most lessened in severity as the threat diminished.

This current restriction implies some specific intelligence of a laptop-based plot and a temporary ban to address it. However, if that's the case, why only certain non-US carriers? And why only certain airports? Terrorists are smart enough to put a laptop bomb in checked baggage from the Middle East to Europe and then carry it on from Europe to the US.

Why not require passengers to turn their laptops on as they go through security? That would be a more effective security measure than forcing them to check them in their luggage. And lastly, why is there a delay between the ban being announced and it taking effect?

Even more confusing, the New York Times reported that "officials called the directive an attempt to address gaps in foreign airport security, and said it was not based on any specific or credible threat of an imminent attack." The Department of Homeland Security FAQ page makes this general statement, "Yes, intelligence is one aspect of every security-related decision," but doesn't provide a specific security threat. And yet a report from the UK states the ban "follows the receipt of specific intelligence reports."

Of course, the details are all classified, which leaves all of us security experts scratching our heads. On the face of it, the ban makes little sense.

One analysis painted this as a protectionist measure targeted at the heavily subsidized Middle Eastern airlines by hitting them where it hurts the most: high-paying business class travelers who need their laptops with them on planes to get work done. That reasoning makes more sense than any security-related explanation, but doesn't explain why the British extended the ban to UK carriers as well. Or why this measure won't backfire when those Middle Eastern countries turn around and ban laptops on American carriers in retaliation. And one aviation official told CNN that an intelligence official informed him it was not a "political move."

In the end, national security measures based on secret information require us to trust the government. That trust is at historic low levels right now, so people both in the US and other countries are rightly skeptical of the official unsatisfying explanations. The new laptop ban highlights this mistrust.

This essay previously appeared on CNN.com.

EDITED TO ADD: Here are two essays that look at the possible political motivations, and fallout, of this ban. And the EFF rightly points out that letting a laptop out of your hands and sight is itself a security risk -- for the passenger.

Posted on March 27, 2017 at 6:28 AM74 Comments

Commenting Policy for This Blog

Over the past few months, I have been watching my blog comments decline in civility. I blame it in part on the contentious US election and its aftermath. It's also a consequence of not requiring visitors to register in order to post comments, and of our tolerance for impassioned conversation. Whatever the causes, I'm tired of it. Partisan nastiness is driving away visitors who might otherwise have valuable insights to offer.

I have been engaging in more active comment moderation. What that means is that I have been quicker to delete posts that are rude, insulting, or off-topic. This is my blog. I consider the comments section as analogous to a gathering at my home. It's not a town square. Everyone is expected to be polite and respectful, and if you're an unpleasant guest, I'm going to ask you to leave. Your freedom of speech does not compel me to publish your words.

I like people who disagree with me. I like debate. I even like arguments. But I expect everyone to behave as if they've been invited into my home.

I realize that I sometimes express opinions on political matters; I find they are relevant to security at all levels. On those posts, I welcome on-topic comments regarding those opinions. I don't welcome people pissing and moaning about the fact that I've expressed my opinion on something other than security technology. As I said, it's my blog.

So, please... Assume good faith. Be polite. Minimize profanity. Argue facts, not personalities. Stay on topic. If you want a model to emulate, look at Clive Robinson's posts.

Schneier on Security is not a professional operation. There's no advertising, so no revenue to hire staff. My part-time moderator -- paid out of my own pocket -- and I do what we can when we can. If you see a comment that's spam, or off-topic, or an ad hominem attack, flag it and be patient. Don't reply or engage; we'll get to it. And we won't always post an explanation when we delete something.

My own stance on privacy and anonymity means that I'm not going to require commenters to register a name or e-mail address, so that isn't an option. And I really don't want to disable comments.

I dislike having to deal with this problem. I've been proud and happy to see how interesting and useful the comments section has been all these years. I've watched many blogs and discussion groups descend into toxicity as a result of trolls and drive-by ideologues derailing the conversations of regular posters. I'm not going to let that happen here.

Posted on March 24, 2017 at 2:20 PM188 Comments

Second WikiLeaks Dump of CIA Documents

There are more CIA documents up on WikiLeaks. It seems to be mostly MacOS and iOS -- including exploits that are installed on the hardware before they're delivered to the customer.

News articles.

EDITED TO ADD (3/25): Apple claims that the vulnerabilities are all fixed. Note that there are almost certainly other Apple vulnerabilities in the documents still to be released.

Posted on March 24, 2017 at 6:46 AM24 Comments

Hackers Threaten to Erase Apple Customer Data

Turkish hackers are threatening to erase millions of iCloud user accounts unless Apple pays a ransom.

This is a weird story, and I'm skeptical of some of the details. Presumably Apple has decided that it's smarter to spend the money on secure backups and other security measures than to pay the ransom. But we'll see how this unfolds.

Posted on March 23, 2017 at 9:09 AM38 Comments

NSA Best Scientific Cybersecurity Paper Competition

Every year, the NSA has a competition for the best cybersecurity paper. Winners get to go to the NSA to pick up the award. (Warning: you will almost certainly be fingerprinted while you're there.)

Submission guidelines and nomination page.

Posted on March 22, 2017 at 12:17 PM15 Comments

New Paper on Encryption Workarounds

I have written a paper with Orin Kerr on encryption workarounds. Our goal wasn't to make any policy recommendations. (That was a good thing, since we probably don't agree on any.) Our goal was to present a taxonomy of different workarounds, and discuss their technical and legal characteristics and complications.

Abstract: The widespread use of encryption has triggered a new step in many criminal investigations: the encryption workaround. We define an encryption workaround as any lawful government effort to reveal an unencrypted version of a target's data that has been concealed by encryption. This essay provides an overview of encryption workarounds. It begins with a taxonomy of the different ways investigators might try to bypass encryption schemes. We classify six kinds of workarounds: find the key, guess the key, compel the key, exploit a flaw in the encryption software, access plaintext while the device is in use, and locate another plaintext copy. For each approach, we consider the practical, technological, and legal hurdles raised by its use.

The remainder of the essay develops lessons about encryption workarounds and the broader public debate about encryption in criminal investigations. First, encryption workarounds are inherently probabilistic. None work every time, and none can be categorically ruled out every time. Second, the different resources required for different workarounds will have significant distributional effects on law enforcement. Some techniques are inexpensive and can be used often by many law enforcement agencies; some are sophisticated or expensive and likely to be used rarely and only by a few. Third, the scope of legal authority to compel third-party assistance will be a continuing challenge. And fourth, the law governing encryption workarounds remains uncertain and underdeveloped. Whether encryption will be a game-changer or a speed bump depends on both technological change and the resolution of important legal questions that currently remain unanswered.

The paper is finished, but we'll be revising it once more before final publication. Comments are appreciated.

Posted on March 22, 2017 at 6:23 AM42 Comments

Photo of Bruce Schneier by Per Ervland.

Schneier on Security is a personal website. Opinions expressed are not necessarily those of IBM Resilient.