Time flies like an arrow...

...and fruit flies like a banana.

A lot happened in the past year. I moved to San Francisco, survived being seriously hit by a car  - facing a long, maybe a year, recovery... While at the hospital, I figured out a few things about life, universe, and everything. I won't reiterate those things here - I might sound as a buddhist nut if I do.

I will try to start blogging again, slowly. Among plans - translate the best articles drops.wooyun.org has on Android (my current fancy and job).

PS. In case I never gave out a link to my Twitter, it's @agelastic. Still struggling with typing, so most posts are retweets :)

Implicit security and waste-cutting

I have a nagging feeling that I've read some of this somewhere a long time ago. Probably in @mjranum's papers.

Imagine you have a product or a process. It kind of works, although you can already see the ways you can improve it by cutting some stuff here and there and changing the way it operates.

A random example: an old paper based process in a company (say, a telco) is replaced with a nice workflow all done on a web site. All information is available there for anyone immediately, all staff are happy, costs decrease, productivity increases 10-fold and so on. The process was concerned with customer contracts, so the information is kind of sensitive.

Bad hackers discover the web site, dump all the data, identity theft sky-rockets, the bank is massively fined and everyone is sad. Downsizing occurs, and so on.

Now what happened here? The old process was slow and cumbersome and low productivity. At the same time it had a number of implicit security measures built in simply by the nature of it being paper based. In order to steal a million paper contracts, one has to break-and-enter the bank facility, plus have a big van to haul all this stuff out. The loss would be immediately discovered (photocopying is not an option due to the time limitations of the heist).

Designers of the new process did not identify these implicit measures or implicit requirements because nobody thought about them. After all, the measures were implicit.
Some of the cost savings of that redesign came from (unintentional) dropping these implicit requirements or measures.

Why I am writing about this? To remind: when you are putting together a new project or re-engineer a process, check if you forgot to implement security that you did not even know was there. Stop for a moment and think about what weaknesses your product or process has, what or who may exploit these weaknesses and what the results will be. "What" could be random event, not necessarily a malicious person. In some places they call this risk management.

The funniest example is OpenSSL in Debian - http://research.swtch.com/openssl.

A less funny example is Vodafone AU customer database project which is more or less described above. It did have one password for all employees.http://www.smh.com.au/technology/security/mobile-security-outrage-private-details-accessible-on-net-20110108-19j9j.html

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

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.

Medievalism in infosec

Dedicated to the last pope.

In my quest to understand the elusive American puritanist psyche I've been reading up on origins and history of Christianity recently.

As a side note - original biblical languages are so much fun. Not only nobody is quite sure which tense in Biblical Hebrew is past and which - future, but even when the meaning is obvious, translations do so much moralising and sweeping all the blood sex and genocide in the Old Testament under the carpet.

Example: did you notice how many times a woman fiddles (uncovers, kisses, touches etc) man's feet in the OT? But never the other way around or, God forbid, a man to a man? It turns out, "feet" is an euphemism :)

Anyhow, this post is about striking parallels between some old religious metaphors and the modern "cybersecurity" ones.

Infosec thinking as Judaism of 1st century BCE

A quote from a very respected Biblical scholar:

"Apocalyptic eschatology" is ... centering in the belief that  

(1) the present world order, regarded as both evil and oppressive, is under the temporary control of Satan and his human accomplices, and
(2) that this present evil world order will shortly be destroyed by God and replaced by a new and perfect order corresponding to Eden before the fall.  

During the present evil age, the people of God are an oppressed minority who fervently expect God, or his specially chosen agent the Messiah, to rescue them. The transition between the old and the new ages will be introduced with a final series of battles fought by the people of God against the human allies of Satan. The outcome is never in question, however, for the enemies of God are predestined for defeat and destruction. The inauguration of the new age will begin with the arrival of God or his accredited agent to judge the wicked and reward the righteous, and will be concluded by the re-creation or transformation of the earth and the heavens. This theological narrative characterized segments of early Judaism from ea. 200 BCE to ea. 200 CE"

Let's change some words:

• 'World order' => information systems
• 'Satan and his human accomplices' => evil hackers, APT!!1!
• 'God' => well, I guess, it stays?
• 'The people of God' => various infosec consultants, from Mandiant to the forthcoming 13 tribes of the US cyberdefense.

You get my drift. There is also an awesome document called The War Scroll, describing the final fight of Sons of Light and Sons of Darkness... then there are Gnostics... There is a PhD in this somewhere.

Infosec industry as pre-reformation Catholic church

No needs for extensive quotes here, Catholicism is a popular topic this week. Just one example: exorcisms.

A typical exorcism: a person was apparently possessed by an invisible evil spirit who caused all kind of trouble (Exorcist is a fine movie, watch it), then a licensed exorcist priest was called, who did strange things and expelled the immaterial possessor out of the victim's body, collected fee and told the victim to install a fountain with holy water, pray and not sin any more.

People sinned, confessed, sinned again...

The priests themselves were idealistic young men or hypocritical old farts who did not practice what they preached.

Substitution table:

• 'Satan', as before => 'bad hackers'
• 'possessed human' => 'infiltrated company'
• 'exorcists' => security consultants, especially DFIR type
• 'sins' => "bad" security practices
• 'confession' => audit or pentest, perhaps.

I could go on but it's time to wrap up, since we ought to celebrate: according to Iranian sources, Habemus Papam has been elected the new pope

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

Thought distortions, or why some of my infosec friends are alcoholics

@dinodaizovi recently quipped that infosec industry is a hybrid of "Mensa and a mental hospital," these are related thoughts.

You all know one or, more likely, many "security consultants" who are telling others that in order to improve security of $system they must do A and B, otherwise imminent failure will occur. Then these consultants go around being upset at their advice not being followed, they perceive the situation as personal failure, end up "burning out"...

Below is a list of cognitive distortions that, according so some theories in psychology, lead to perpetuation of a number of psychological conditions, including depression and alcoholism. I think I've got it from an iPhone app called "MoodKit" (by the way, try it). Have a think - aren't most of these associated with "security consultants," especially the internal consultants, in the eyes of their customers?

Common Thought Distortions

All-or Nothing Thinking 
Seeing people or events in absolute (black-or-white) terms, without recognizing the middle ground (e.g., success/failure; perfect/worthless).

"Without perfect security there is no security"

Blaming 
Blaming yourself or others too much. Focusing on who is to blame for problems rather than what you can do about them.

"These people just do not want to understand the importance of security!"

Catastrophizing 
Blowing things out of proportion, telling yourself that you won’t be able to handle something, or viewing tough situations as if they will never end.

"Ehrmergerd, these people just hate me, I will never be able to do anything to improve security here"

Downplaying Positives 
Minimizing or dismissing positive qualities, achievements, or behaviors by telling yourself that they are unimportant or do not count.

"Well, we got these vulns fixed, but there are soooo many more, probably!"

Emotional Reasoning 
Believing something is true because it “feels” true. Relying too much on your feelings to guide decisions.

"I have a gut feeling the attackers are out to get us!"

Fortune Telling 
Making negative predictions about the future, such as how people will behave or how events will play out.

"The company data will be breached in the most harmful way"

Intolerance of Uncertainty 
Struggling to accept or tolerate things being uncertain or unknown (e.g., repeatedly wondering “what if?” something bad happens).

"What if a firewall is misconfigured? What if there is a new RCE in Struts tomorrow?..."

Labeling 
Describing yourself or others using global, negative labels (e.g., making judgments about one’s character or name calling).

"These lazy developers just do not care!"

Mind Reading 
Jumping to conclusions about another person’s thoughts, feelings, or intentions without checking them out.

"I know they are not interested in fixing this stuff"

Negative Filtering 
Focusing only on the negatives and ignoring the positives in a situation, such that you fail to see the “big picture.”

Ok I give up with examples - the list is getting somewhat repetitive, but you get the drift...

Not Accepting 
Dwelling on an unpleasant situation or wishing things were different, instead of accepting what has happened and finding ways to move forward.

Overgeneralizing 
Drawing sweeping conclusions on the basis of a single incident, such as when we say people or things are “always” or “never” a certain way.

Personalizing 
Telling yourself that events relate to you when they may not.

“Should” and “Must” Statements 
Focusing on how things or people “should” or “must” be. Treating your own standards or preferences as rules that everyone must live by.

Who hasn't done that??? :)

One additional point for thoughts is that the above mindset is occasionally perpetuated by infosec vendors. Send them your therapist's invoice...