There is no Escalatory Ladder in the Matrix

I'm still reading Bytes, Bombs and Spies, specifically the chapter where they define "OCO" to mean "Offensive Cyber Operations" and then riff on the concept of how command and control and escalatory ladders would exist in wartime, who would authorize what, how doctrine would evolve, etc.

I know the book is meant to at some level portray that policy can be strategically thought out in the unclassified space, but the deeper I get into it, the less I feel like it makes that point. What does a "constrained regional scope" mean in cyberspace? (note: It means nothing.)

If anything, what this book points out is how little value you can get from traditional political-science terms and concepts. Escalatory ladder makes little sense with a domain where a half-decade of battlefield preparation and pre-placement are required for attacks, where attacks have a more nebulous connection to effect, deniability is a dominant characteristic, and where intelligence gathering and kinetic effect require the same access and where emergent behavior during offensive operations happens far beyond human reaction time.

Bytes Bombs and Spies

A shibboleth for whether you should be doing cyber policy work. :)

ISR has to be anticipatory, comprehensive, and real time. And because of that, I'm reading the new compendium of essays edited by Herb Lin and Amy Zegart. The book is dense and long, so I'm not done with it, but I get a very different feeling from it so far than what they've intended I think.

Start by listening to this podcast:
https://www.hoover.org/news/hoover-scholars-examine-cyber-warfare-new-book

In it, a few interesting questions come to light. For example, they say things like this:

1. Does not know why, unlike with nuclear, the scientific community has not gone into policy with cyber (sociology of knowledge problem) 
2. Does not think you need a "CS Degree" to work on cyber policy (in comparison to nuclear work, which was more technical in some way) 

Obviously I disagree with both of those things.

There are things you always hear in this kind of podcast:

• A hazy enumeration of the ways the cyber domain is different
• War versus not-war legal hairsplitting 
• Either wishful thinking or doleful laments about cyber norms
• Massive over-parsing of vague throwaway comments from government officials

For example, the Differences of the Cyber Domain (from this podcast):

• Intangible - manipulates information
• It's man made! Laws of physics don't constrain information-weapons so much as imagination.
• Target Dependance
• Accumulation problem - lots of copies of the same malware doesn't help. Exploits are time-delimited in a way that is quite different from capabilities in the real world.

Ok, so some real talk here: The first thing a hacker learns is that code and data are the same thing, and both are just state space under the covers. This is why when you build a fuzzer, you can measure "code coverage" but you know that you're just estimating what you REALLY want to explore, which is state space coverage. It's why your exploits can use the thread environment block to store code, or why every language complex enough to be useful has an injection bugclass. I have a whole post coming soon about shellcode encoder decoders to really drive the history of this thing home. ADMutate anyone? 

Anyways, once you understand that in your gut, the way a hacker does, the cyber domain is not at all confusing. It becomes predictable, which is another word for computable.

Deep down, the most ironic thing is Lin's statements about the different physics of the physical and cyber domains because the theory of computation is ALSO the physics of quantum mechanics, which is what we learned when we were building nuclear bombs. 

VEP: Centralized Control is Centralized Risk

When we talk about the strategic risks of a Vulnerability Equities Process people get absorbed in the information security risks. But the risks of any centralized inter-agency control group also include:

• Time delay on decision making. Operational tempo is a thing. And you can't use a capability and then kill it on purpose on a regular basis without massive impact to your opsec, although this point appears to be lost on a few former members of the VEP. 
• For teams that need a fast operational tempo (and are capable of it), any time delay can be fatal. 
• For teams that don't operate like that, you either have to invest in pre-positioning capability you are not going to use (which is quite expensive) or further delay integration until the decision about whether to use it has been made.
• One-size-fits-all capability building. While there may be plenty of talented individuals for the VEP process, it is unlikely they are all subject matter experts at the size and scale that would be needed for a truly universal process. I.E. the SIGINT usefulness of a SAP XSS may be ... very high for some specialized team.
• Having multiple arms allows for simpler decision making by each arm, similar to the way an octopus thinks. 
• Static processes are unlikely to work for the future. Even without enshrining a VEP in law, any bureaucratic engine has massive momentum. A buggy system stays buggy forever, just like a legacy font-rendering library. 

It may not even result in different decisions than a distributed system. For example: Any bug bought/found by SIGINT team is likely to be useful for SIGINT, and retained. Otherwise your SIGINT team is wasting its time and money, right?

Likewise, any bug found externally, say through a government bug bounty, is likely to be disclosed.

Here's a puzzle for you: What happens if your SIGINT team finds a bug in IIS 9, which is an RCE, but hard to exploit, and they work for a while, and produce something super useful. But then, a bit later, that same bug comes in through the bug bounty program DHS has set up, but as an almost useless DoS or information leak? How do you handle the disparity in what YOU know about a bug (exploitability f.e.) versus what the public knows?

Outputs

This leads you into thinking - why is the only output available from the VEP disclosure to a Vendor? Why are we not feeding things to NATO, and our DHS-AntiVirus systems, and building our own patches for strategic deployment, and using 0days for testing our own systems (aka, NSA Red Team?). There are a ton of situations where you would want to issue advisories to the public, or just to internal government use, or to lots of people that are not vendors.

During the VEP Conference you heard this as an undercurrent. People were almost baffled by how useless it was to just give bugs to vendors, since that didn't seem to improve systemic security risks nearly enough. But that's the only option they had thought of? It seems short sighted.