"Why do you work in security instead of something more lasting ?"

This post grew out of a friend on Facebook asking (I paraphrase) "why do you spend your time on security instead of using your brainpower for something more lasting ?". I tried to answer, and ended up writing a very long reply. Another friend then encouraged me to re-post my reply to a wider audience. The below is a slightly edited and expanded version. It is much less polished than my usual blog posts, more personal, and somewhat stream-of-conscious-y. Apologies for that.

Why do I work in security instead of on something more lasting?

Predictions about what is "lasting" are very difficult to make :-). I think outside of the exploit-of-the-day, there's lasting work to be done in understanding of exploitation (because machines and automata aren't going away, and neither are programming mistakes), and I sincerely hope I'll have opportunity to do that work.

I tried my hand in cryptography / academia, and found it more prone to political trends/fads and less blindly results-oriented than security - to my great disappointment. When all attacks are of theoretical complexity 2^96, verifying and replicating results becomes difficult, and objective truth suffers (see below).

In the following, I will state a few things that I really like about the computer security community. I did not realize this immediately - instead, I learnt this over many years and engagement in other communities.

1. Original thinkers. I used to joke that there are less than 2 dozen reasons why security as a field doesn't suck, and I know many of them personally. Now, the 2 dozen is bullshit, but what is true that in all the noise & hype, I have met a number of very fun, unconventional, and deeply insightful thinkers of very different backgrounds. They are few and far between, but I wouldn't have met them without security, and I am grateful for having met them. Many exploits require considerable inventiveness, and non-obvious / creative ways of solving problems; they are sometimes like a good joke / magic trick: With an unexpected twist that makes you laugh in disbelief.
2. Tolerance of non-conformism and diverse educational backgrounds. There are few other industries where people who did not finish high school mix with people with postgraduate degrees, and debate on even terms. With all it's problems and biases, the part of the community I grew up with did not care about gender, skin color, or parental income - everybody was green writing on a black screen.
3. Intellectual honesty. When discussing attacks, there is "objective truth" - you can establish whether an attack works or does not work, and checking reproducibility is easy. This is not true in many other disciplines, and "truth" becomes a matter of social consensus - even in pure math, where proof should be absolute. Having objective truth is extremely helpful to prevent a discipline to devolve into scholasticism.

Many other fields which may be more "lasting" do not have the luxury of these three points. Also be aware that my visibility into the security community is very skewed:

My skewed view of the security community

It is common to hear negative things about the community - that it is elitist, full of posturing, or of people that are mean / demeaning to others with less experience. This is not the community I experience - and this discrepancy has been puzzling me for a while.

For one thing, everybody is always nice to me. I am not sure why this is the case, but the only non-niceties I encountered in this industry were in leaked email spools. This makes it difficult for me to notice people being mean to newcomers and elitist - and it saddens me to hear that people are being shit to each other.

People weren't always nice to me - like any group of teenagers, 1990's IRC was very often not a friendly place, and #cracking would kickban you for asking a question. I found a home of sorts in a channel called #cracking4newbies - a very welcoming environment dedicated to joint learning. It was great for me: I could ask questions, and either got answers or links to documentation. A few members of #cracking were no longer active, and held status in the channel for historical reasons, #cracking4newbies on the other hand was full of eager & active youngsters.

I somehow managed to avoid being around the posturing and status games much, and in some bizarre stroke of luck, have managed to do so up to this day. The people in the security community I spend time with are genuinely interested in the technical challenges, genuinely curious, and usually do not care about the posturing part. The posturing may happen at industry conferences, but I tend to not notice - the technically interesting talks tend to adhere to substance-over-style, and the rest is as relevant to me as big advertisements for broken content inspection appliances.

All I want to say with this section is: I do not know how I managed to avoid experiencing the bad sides of the security community much. Some of it was luck, some of it was instinct. There are plenty of things I find annoying about the security community (but that is for another post :-), but in my day-to-day life, I don't experience much of it. If you are in security, and feel that the community is elitist or demeaning to people learning, I hope you succeed in seeking out the (many) people I encountered that were happy to share, explain, and just jointly nerd out on something. Feel free to reach out any time.

On building vs. breaking

I quite often hear the phrase "I quit security and I am much happier building instead of breaking things". This is a normal sentiment - but for me, security was never about "just" breaking things. Tooling was always inadeqate, workflows horribly labour-intensive, and problems were always tackled on the lowest level of abstraction, missing the forest for the trees.

In my reverse engineering classes, I always encourage people to be tool builders. Most of security work today is akin to digging trenches with chopsticks. Invest in designing and building shovels. Perhaps we will even get a bulldozer in my lifetime. Slowly but surely, the industry is changing in that direction: Microsoft is commercializing SAGE, no code auditor is more productive (even though more in-depth) than a farm of computers running AFL - but the discrepancy between the quality and quantity of tools that developers have available vs. the tools that security review has available is still vast.

I like my work most when I can cycle through building / breaking phases: Try to break something, notice how insanely badly the tooling is, cycle through an iteration of tool development, return to the breaking etc.

I realize this isn't the path for everybody, but I don't think that security is "always just about breaking". The most persistent person gets bored of chopstick-trench-digging. Invest in tooling. Being a better developer makes you a better hacker. And perhaps you like building more than breaking, and I can't fault you for that.

My friend Sören happens to be one of the best C++ developers I know. When we first met in undergraduate math class, I described what I do for a living to him (reading code for subtle mistakes), and he said "that sounds like one of the worst imaginable jobs ever". He is a builder, and I have nothing but admiration and respect for him - and from the builder's perspective, his assessment is right.

I still like finding subtle bugs. To paraphrase another person who I respect a lot: "People still search for new stuff in Shakespeare hundreds of years later".

Using security as an excuse for broad learning

I once read that "cryptography gathers many very different areas of mathematics like a focal lens". The same is very true of security and computer science. Security happens at the boundaries between layers, and I have used working in security as an excuse to learn about as many layers as possible: Low-level assembly, high-level stuff on formal verification, and even electrical engineering problems and their implications on security.

People talk about "full stack engineers" a lot; security allows me to roam the full stack of abstractions in computer science without guilt. All layers are relevant for security, all layers are interesting in their own right, and each layer has it's own funny quirks.

Summary

Given the length of this blog post, it is evident that I have asked myself the question "why do I do this" many times. And I have thought about devoting attention to other things often enough. Who knows, I am 35, so I have about 30 years of professional activity ahead of me - which may be enough to fail in one or two other fields before returning to give grandfather-security keynotes. :-)

But right now, I am actually enjoying having my hands dirty and thinking about heap layout for the first time in years.

Essays about management in large(r) organisations (1): Process and flexibility

Even though I often profess that my primary interests are technical, by this point in my life I have been exposed to a variety of different organisations and management styles: From the self-organizing chaos of the 1996-2002 cracking/hacking groups, through the small engineering-centric startup zynamics, via the various organisations (both governmental and industry) I consulted for at some point, to the large (but nonetheless engineering-centric) culture at Google.

I enjoy thinking about organisations - their structure, how information flows, their strengths and dysfunctions. Part of it may be the influence of my father (who wrote extensively on matrix organisations, but also on organisations that fail); the other part is certainly the recognition that both company culture and organisational culture matter. In any organisation, setting the culture and organisational structure - and keeping it healthy - is paramount, and probably the key element that will allow long-term success. Ignore culture and organisation structure (both explicit and implicit) at your peril.

I had a lot of time to think in the last year, so in the coming months I will write a few posts / essays about company culture and management.

The first post is about organisational processes - why they are important, but also how they can take on a life of their own and strangle flexibility.

A technical anecdote to start with

In early 2004, the first prototype of BinDiff started to work properly - just when Microsoft released MS04-001: A series of amusing little memory corruptions inside the H.323 parsing component of Microsoft ISA server (a now-discontinued firewall product). Using BinDiff on the patch, it was evident that the problems were inside the ASN.1 PER parsing routines in a central library - but instead of fixing the library, the patch fixed the issue inside ISA server.

The patch fixed only one exploit path, but the actual vulnerability was still there. This meant that any other program using the same library remained vulnerable, and the patch had now effectively disclosed the security issue. I started searching for other applications that used this library. The first program I found which was also affected by this vulnerability was Netmeeting - Microsoft had inadvertently given a remote code execution bug in Netmeeting to everybody. It wasn't until MS04-011, at some point in April, that this vulnerability got fixed in the correct place -- the library.

The technical details of the bug are not terribly interesting - what is interesting is what the mistake revealed about flaws in Microsoft’s organisational structure, and how they reacted to the bug report.

What could we deduce/learn/extrapolate from this event?

• Bug reports were likely routed to the product teams - e.g. if a bug is reported in your product, the bug report is routed to you.
• Responsibility for fixing a bug appears to lie with the product teams (see above), and teams are incentivized (either directly or indirectly through feature deadlines etc.) to get bug reports “off their desk” quickly.
• Patching shared central code is harder than patching code you own (for various reasons - perhaps compatibility concerns, other priorities from other teams, or perhaps even a heavyweight process to ask for changes in critical code).

What likely happened is that the ISA team decided that dealing with the issue on their side is enough - either because they did not realize that the same issue will affect others, or because dealing with the other team / the library is a pain, or for some other unknown reason. Microsoft’s bug fixing process incentivized “shallow” fixes, so for attackers, finding the ultimate root cause of a vulnerability could expose other vulnerable programs.

This is a classical example of making a locally convenient decision that adversely affects the larger organisation.

From what I heard, Microsoft learned from this event and made organisational changes to prevent similar mistakes in the future. They introduced a process where all patches are reviewed centrally before they go out to ensure that they don't inadvertently fix a bug in the wrong spot, or disclose a vulnerability elsewhere.

Processes as organisational learning

In what an MBA would call ‘organisational learning’, a process was created out of the experience with a previous failure in order to prevent the mistake from happening again. A process is somewhat similar to organisational scar tissue - the organisation hurt itself, and to prevent such injury in the future, the process is established.

Surprisingly, most organisations establish processes without documenting explicitly what sort of failure and what sort of incident caused the process to be established. This knowledge usually only lives in the heads of individuals that were there, or in the folklore of those that talked to those that were there. After a half a decade or so, nobody remembers the original incident - although the process will be alive and kicking.

A process can prevent an organisation from doing something stupid repeatedly - but all too often, the process takes on a life of its own: People start applying the process blindly, and in the hands of an overly-literally-minded person, the process becomes an obstacle to productivity or efficiency. The person in charge of applying and enforcing the process may themselves not know why it is there - just that it is "the process", and that bad things can happen when one doesn't follow it.

My grandfather used to say (I will paraphrase) : "a job with responsibility is a job where you don’t simply apply the rules, but need to make judgements about how and where to make exceptions". This quote carries an important truth:

People at all places in an organisation need to be ...

1. Empowered to make exceptions: After demonstrating sound judgement, people need to feel empowered to make exceptions when the letter of a process gets in the way of the greater good and changing the process would be excessive (for example, in a one-off situation).

2. Empowered to challenge processes: The reasoning behind a process must to be accessible to organisation members, and there needs to be a (relatively pain-free) method to propose changing the process. Since powerlessness is one of the main drivers of occupational burnout, this will help keep individuals and the organisational structure healthy.

Some organisations get the “exception” part right - most big organisations only function because people are regularly willing to bend / twist / ignore processes. Very, very few organisations get the “challenge” part right-- making sure that every employee knows and understands that processes are in the service of the company, and that improvements to processes are welcome.

I think that the failure to achieve the challenge-process frequently arises due  to "lack of institutional memory". When organisations fail to keep track of why a process was created, all sorts of harmful side-effects arise:

1. Nobody can meaningfully judge the spirit of the process - what was it designed to prevent?
2. Making an exception to the process is riskier - if you do not know what it was designed to prevent, how can you know that in this particular case that risk does not apply?
3. Amending the process becomes riskier. (Same reason as above.)
4. Challenging the process cannot happen in a decentralized / bottom-up fashion: It is often the most junior employees who may have the freshest eyes for obstructive processes - but since they do not know the history of why the processes exists, they often can't effectively propose a change since they don’t know the organisation well enough to rule out unwanted side-effects. This directly sabotages decentralised, bottom-up improvements of workflows.

What is a healthy way to deal with processes?

1. Realize that they are a form of “organisational memory”: They are often formed as reaction to some unpleasant event - with the intent of preventing this event from repeating. It is also important to realize that unchecked and unchallenged processes can become organisational “scar tissue” - more hindrance than help.
2. Keep track of the exact motivation for creating each process -- the “why”. This will involve writing half a page or more, and checking with others involved in the creation of the process that the description is accurate and understandable.
3. The motivations behind the process should be accessible to everybody affected by it.
4. Everybody should know that company processes are supposed to support, not hinder, getting work done. Everybody should feel empowered to suggest changes in a process - ideally while addressing why these changes will not lead to a repeat of the problem the process was designed to prevent.
5. People should be empowered to deviate from the process or ignore it - but frequent or even infrequent-but-recurring exceptions are a red flag that the process needs to be improved. Don't accumulate "legacy process" and "organisational debt" through the mechanism of exception-granting.
6. Everybody should be aware that keeping processes functional and lean is crucial to keeping the organisation healthy. Even if a process is unreasonable and obstructive, most people instinctively try to accept it - but the first instinct should ideally be to change it for the better. Constructively challenging a broken process is a service to the organisation, not an attack.
7. It may be sensible to treat processes a bit like code - complete with ownership of the relevant process, and version control, and handover of process ownership when people change jobs. Amendments to processes can then be submitted as text, reviewed by the process owner, discussed, and eventually approved - much like a patch or removal of dead code.

Keeping an organisation healthy is hard. The most crucial ingredient to keeping it healthy, though, is that the members of the organisation care to keep it healthy. Therefore it is absolutely critical to encourage fixing the organisation when something is broken - and to not discourage people into "blindly following the process".

An attempt at fixing Wassenaar

Last year in May, I wrote extensively about the many ways in which the 2013 "intrusion software" amendments to the Wassenaar Arrangement were broken and downright dangerous to all efforts at security the global IT infrastructure. Since then, the debate has heated up from all sides -- extending to a hearing in front of US congress (which was pretty unanimous in condemning these amendments), but also including voices such as James Bamford arguing for these controls in an op-ed. The landscape of the discussion is too complex now to be summarized here (the interested reader can find a partial survey of recent developments here).

Common ground between the different sides of the discussion is not large, but the thing that almost everybody agrees to is "it is bad when despotic regimes that couldn't otherwise get advanced surveillance software purchase sophisticated surveillance software from abroad". How to prevent this is up for discussion, and it is unclear whether export control (and specificially the Wassenaar Arrangement) is the right tool for the task.

To find out whether the export control language can be made to work, my colleagues Mara Tam and Vincenzo Iozzo and me have worked jointly and tried to come up with an amendment to the language of the Wassenaar Arrangement that would satisfy the following criteria:

• Make sure that click-and-play surveillance frameworks such as the ones marketed by HackingTeam or Gamma are caught and controlled.
• Make sure that no technology that is required for defending networks (including bugs, proof-of-concept exploits, network scanners etc.) is caught and controlled.

In order to achieve this, we had to depart from the "traditional" Wassenaar language (that is focused on performance metrics and technical properties) and include much greater emphasis on "intent" and especially "informed consent by the user". We draw the line between good and bad if the design intent of the software in question is to be used against people that did not consent.

As of today, we are circulating our draft more widely. We are not 100% sure that our language achieves what we want to achieve, and we are not even sure whether what we want to achieve can be achieved within the language of export control -- but we have made a very thorough effort at testing our language against all scenarios we could come up with, and it worked well.

We are hoping that by circulating our proposal we can somewhat de-polarize the discussion and attempt to find a middle ground that everybody can be happy with -- or, failing that, to show that even with a lot of effort the 2013 amendments may end up being unfixable.

Anyhow, if you are interested in our document, you can download it here. As we get more feedback, the document will be updated and replaced with newer versions.