12 steps to saner infosec

Actually, after kicking any references to $deity from the original list, there is about 6 points left.

1. Admit that you cannot be in full control of your systems and networks

There will always be NSA to break your elliptic curves, or a new zero day in a library inside a library that you forked, modified and then used in your code. And if you say "defence in depth", I'll ask you to show me your "perimeter".


2. Recognise that this is not a defeat

Attackers are people too, and are driven by economic motives. If it is too hard and not worth the effort, they will not go after you. Unless they want to make a point, of course.

Make breaking into your stuff not worth the effort. That is, ensure the required effort is hard enough that "the bad guys" will give up.

3. Examine, with the help of others, your past efforts to "secure", "risk manage", "protect" everything to the level of "best practice" 

"Best practice" is partly management speak for "I have no idea how to deal with specifics of my business environment" and partly vendor sales pitch. Risk management is good in theory but does not work in practice for infosec, beyond very basic qualitative judgements.

Talk to others, inside your business sector and outside it. Etsy, Facebook, Twitter, and even Salesforce are doing awesome things. Talk to me, I'll buy you a beer! :)

4. Make amends for these errors (or efforts)

Don't be a business prevention specialist. Be nice to your developers, they are generally smarter than you - learn from them. Listen to your network admins, they are often more protective of their hosts than you think.

5. Learn to live a new life

Give people what they need to do their jobs and get out of the way - figure out a "secure enough" method of doing what people need without disrupting their jobs. Set yourself specific time limited goals and don't fall into the trap of "best practices" again (see point 1)

Make your own informed decisions. You cannot outsource understanding to consultants, whitepapers and Google.

6. Help others who suffer from the same addiction to total control

Run an exploit or two for them... Teach them about the halting problem, just because it's fun to see people realising what it entails, at least in theory. Send them a few links:

• http://sparrow.ece.cmu.edu/group/731-s08/readings/ptacek-newsham.pdf
• http://sparrow.ece.cmu.edu/group/731-s09/readings/Axelsson.pdf
• https://community.qualys.com/servlet/JiveServlet/download/38-10829/Protocol-Level%20Evasion%20of%20Web%20Application%20Firewalls%20(Ivan%20Ristic,%20Qualys,%20Black%20Hat%20USA%202012)%20SLIDES.pdf
• https://www.nsslabs.com/system/files/public-report/files/Correlation%20Of%20Detection%20Failures.pdf

And maybe http://www.phrack.org/!

PS A vaguely related preso I gave is at http://www.slideshare.net/agelastic/security-vulnerabilities-for-grown-ups-gotocon-2012-15479294

Words and works

A short while ago I've mentioned this blog to someone who read through posts and then came back, saying: "Nice ideas, but did you actually implement any of this?"

Here's what we've managed to implement at work, all or most of the ideas in these topics:

Code review tools and techniques

http://www.surrendercontrol.com/2013/05/crutches-and-static-code-analysis.html
http://www.surrendercontrol.com/2012/12/focused-code-reviews-followup.html

Application security for big web apps

http://www.surrendercontrol.com/2012/11/modern-web-application-security.html

Changing security culture

http://www.surrendercontrol.com/2012/12/changing-things-when-change-is-hard.html

Wheels inside wheels

Reblogging from http://seclists.org/dailydave/2013/q2/38

… or, Ptolemaic model of the solar system of infosec.

Required reading: https://en.wikipedia.org/wiki/Deferent_and_epicycle

In all enterprise-y security courses they will teach you that there
are several components to defence processes:

10. If you can, try to prevent bad guys getting to you
20. If you cannot, try to detect an attempt to get in before it succeeds
30. If you cannot detect attempts, aim to detect whether you've been compromised
40. If you've been compromised, do incident response and clean up

(Imagine your enterprise assets is the Earth and those 4 items are other planets, orbiting it)

When the reality demonstrates that the current approach to any of the
components is inadequate, it gets updated with "smarter" technology.

What this "smarter" technology comprises changes with time, but it
always goes through stages of

1. Add more signatures, then
2. Do some sort of local behaviour analysis, then
3. "Big data" / "data mining" or similar magical words, then
4. Whatever else the market fancies

(These are equivalents of "wheels within wheels", or epicycles in Ptolemy's astronomy)

Examples:
- AV is permanently stuck on line 20 with a few epicycles, from signatures to big data, under its belt already;
- IoC (Indicators of Compromise) is line 30, only just at the beginning of its spiral.

The main take away here is that the defending side is, unfortunately,
retreating. Those "let's clean up compromises quicker" contests Spafford
was lamenting recently only illustrate this tendency further.

The other take-away is that I love lists…

Oh and if someone comes up with a true Copernican concept of security,
please tell me. I have to be part of that!

How to feel cool, whether you're an "attacker" or a "defender"

...in which it is "scientifically" (if psychology is considered science) proven why attacking usually feels "cooler" and unqualified self-help advice is provided. No less.

A little on terms: attacking includes both finding vulnerabilities and creating exploits, defending - ensuring that "attackers" don't succeed.

"Cooler" here does not mean the media angle, or the pecking order inside the industry. Here I talk only about self-perception based on ability to achieve own goals.

I stumbled upon an article last year, while researching what motivation developers would have to write secure code (short summary of research results: very little). A Twitter conversation this morning gave me an idea that the same approach can be applied inside the infosec industry as well.

Here are some quotes from the article with their "infosec" interpretation:

...it matters how people frame their good intentions or goals.  

For instance, better performances are observed when people set themselves challenging, specific goals as compared with challenging but vague goals (so-called "do your best" goals). 

Let's see: "attackers" do have specific goals; "defenders" - maybe, it depends. In many organisations it is indeed "do your best".

This goal-specificity effect is based on feedback and self-monitoring advantages, as is also true for the goal-proximity effect (proximal goals lead to better performances than distal goals). 

Attackers' goals are usually closer in time: find a vulnerability in this software, get this exploit running. Defenders... their goals last as long as the company exists.

Goal attainment is also more likely when people frame their good intentions as learning goals (to learn how to perform a given task) rather than performance goals (to find out through task performance how capable one is) 

Not sure about this, looks the same for both "sides" to me - depends how you actually do your work. If your goal is "figure out how quick I can run Nessus (or Metasploit)", then it kind of sucks either way.

...or when they frame their intentions as promotion goals (focusing on the presence or absence of positive outcomes) rather than prevention goals (focusing on the presence or absence of negative outcomes)

This one is obvious - attackers' outcomes are usually positive, while defenders are stuck with "prevention".

Now what you can do if you think "defenders suck", and you're one of them?

Reframe your goals:

1. Make them more specific,
2. Closer in time (e.g. "we need to do X threat models in 3 months")
3. Learn new stuff
4. Stop being a "prevention specialist". Find positive outcomes to pursue.

I bet this can even get you a promotion.

Everyone says do what you love, but what is it?

Hmm, this may be turning into a book blog... Stay tuned, I'll be posting less fluffy stuff as well.

It is a familiar phrase - "do what you love", and it has been repeated over and over again at several hacker/security cons all over the world. I do not know about you, but it took me some time to sit down and figure out what I love. Being a book nerd, I picked up Business Model You for some inspiration. It is a strange book, somewhat an offshoot of a very successful (apparently) book Business Model Generation and applies the same framework to individuals instead of businesses.

What I really liked about this book is not the "business model". Instead, have a look at Chapter 4 "Who are you?" It has a lot of great advice on figuring out what it is that you really love, if you do not know it yet (many people do not).

A thought experiment. Think back to any time before you were 20 years old:
What did you love to do? (I do not think the authors include sex under this rubric, hehe)
What activities - games, hobbies, sports, extracurricular events, school subjects did you enjoy? Recall your natural, uncoerced proclivities.
Think about what kept you absorbed for hours and made you happily oblivious to the rest of the world. What tasks made time fly?

They include a bunch of other thinking prompts - e.g. thinking over what events in your life related to what feelings, what kind of environment you like to be in and so on, yet this "inner teenager" exercise is the most unusual and most powerful. Obviously these memories need to be re-interpreted in the world you are living in, abstracted, re-applied - the core idea still stays.

So, people who love what they do are following their inner teenager..

P.S. If you are wondering, I love solving complex puzzle-like problems (preferably computer-related), working alone or in a small group of peers who share  goals and learn from each other. The rest is, erm, syntactic sugar.

Changing things when change is hard

NB: If the post below makes you think that I have succumbed to managementese and became some kind of consultant, this is a false impression. I am simply reflecting on an unexpected connection between security improvements in code produced by Twitter developers and a management book.

"Switch"

A recent read of mine, recommended by one of the Atlassian owners - Switch: How to Change Things When Change Is Hard. I am not a huge fan of management books - many of them turn out self help books in disguise, others spend 200 pages chewing through an idea that can be explained in a paragraph. "Switch" initially looked like it belonged to the latter category, but to be honest it is worth reading from cover to cover.

The book is about exactly what its title says - changing things when change is hard (Hello there, "security evangelists"!). The premise is simple (and borrowed from another book):

"Jonathan Haidt in "The happiness hypothesis" says that our emotional side is an Elephant and our rational side is its Rider. Perched atop the Elephant, the Rider holds the reigns and seems to be the leader. But the rider's control is precarious because the Rider is so small relative to the Elephant. Anytime the six-ton Elephant and the Rider disagree about which direction to go, the Rider is going to lose. He's completely over-matched."

They draw lessons about change efforts:

Elephant looks for quick payoff over the long term payoff. When change efforts fail, it is usually the Elephant's fault, since the kinds of change we want typically involve short term sacrifices for long term payoffs. Yet it's the Elephant who gets things done in change situations. You need to appeal to both. The Rider provides the planning and direction, and the Elephant provides the energy. Understanding without motivation vs. passion without direction.

...And make another simple but non-obvious observation that change is hard because people wear themselves out. The "one paragraph" summary of the book is that there are three components to a successful difficult change:

1. Direct the Rider - provide crystal clear direction. What looks like resistance is often a lack of clarity.
2. Motivate the Elephant - Engage the people's emotional side. The Rider cannot get his way by force for very long. What looks like laziness is often exhaustion.
3. Shape the path - Shape the situation in a way that facilitates your change. What looks like people problem is often a situation problem.

There are other interesting simple thoughts sprinkled throughout the text. For example:

• Build habits if you want the change to stick
• Shrink change - give simple actions
• Create a destination postcard (pretty vision of the final state) to motivate

Twitter, SADB and elephants

Now, why am I going on about a management book?

In my previous post I included a slideshare link to a talk about security automation from Twitter. There is also a video at http://videos.2012.appsecusa.org/video/54250716. Prominently featured is Twitter's central security dashboard, SADB ("sad-bee", funny) - Security Automation Dashboard.

One of its main functions is checking newly pushed code for known vulnerable patterns with Brakeman (see slides 46+ in the slideshare and quick demo video at https://www.youtube.com/watch?feature=player_embedded&v=0ZZKCyBR8cA and immediately bugging the responsible developer with specific recommendations on what has to be fixed and how.

This strikes me as a perfect implementation of "Direct the Rider" principle and "Shrink the change" approach.

I am going to try similar approach at work, we will see how sticky the resulting improvement is going to be :)

Some links:

Extracts from the book:

http://www.heathbrothers.com/resources/download/switch-framework.pdf
http://www.heathbrothers.com/resources/download/switch-for-organizations.pdf

A related behaviour change framework:

http://www.behaviorwizard.org/wp/ - from Stanford