Grey bar Blue bar
Share this:

Fri, 15 Jul 2011

Security Policies - Go Away

Security policies are necessary, but their focus is to the detriment of more important security tasks. If auditors had looked for trivial SQL injection on a companies front-page as hard as they have checked for security polices, then maybe our industry would be in a better place. I want to make this go away, I want to help you tick the box so you can focus on the real work. If you just want the "tool" skip to the end.

A year and a half ago, SensePost started offering "build it" rather than "break it" consulting services, we wanted to focus on technical, high-quality advisory work. However, by far the most frequently "consulting" request we've seen has been asking for security policies. Either a company approaches us looking for them explicitly or they want them bolted on to other work. The gut feel I've picked up over the years is that if someone is asking you to develop security policies for them, then either they're starting on security at the behest of some external or compliance requirement or they're hoping that this is the first step in an information security program. (Obviously, I can't put everything into the same bucket, but I'm talking generally) Both are rational reasons to want to get your information security policies sorted, but getting outside consultants to spend even a week's worth of time developing them for you, is time that could be better spent in my opinion. My reasons for this are two-fold:

  • If you're starting a security program, then you have a lot to learn and possibly a lot of convincing of senior management to do. Something like an internal penetration test (not that I'm advocating this specifically instead of policy) will give you far more insight into the security of your environment and a lot more "red ink" that can be used to highlight the risk to the "higher ups".
  • Security policies don't "do" anything. They are a representation of management's intention and agreements around security controls, which in the best case, provide a "cover my ass" defense if an employee takes you to task for intercepting their e-mails or something similar. The policies need to be used to derive actual controls, and are not controls in themselves.
Instead, we too often end up in a world where security policies, rather than good security, is the end goal while new technologies keep us amused developing new ones (mobile policies, social media policies, data leakage policies etc.)

Saying all of this is fine, but it doesn't make the auditors stop asking, and it doesn't put a green box or tick in the ISO/PCI/CoBIT/HIPAA/SOX policies checkbox. Previously, I've pointed people at existing policy repositories, where sample policies can be downloaded and modified to suit their need. Sites such as CSOOnline or PacketSource have links to some policies, but by far the most comprehensive source of free security policy templates is SANS. The problem is people seem to look at these, think it looks like work, and move on to a consultancy that's happy to charge for a month's worth of time. Even when you don't, the policies are buried in sub-pages that don't always make sense (for example, why is the Acceptable Use Policy put under "computer security"), even then several of them are only available in PDF form (hence not editable), even though they are explicitly written as modifiable templates. What I did was to go through all of these pages, download the documents, convert them into relevant formats and categorise them into a single view in a spreadsheet with hyperlinks to the documents. I've also included their guidance documents on how to write good sec policies, and ISO 27001-linked policy roadmaps. I haven't modified any of the actual content of the documents, and those retain their original copyright. I'm not trying to claim any credit for others' hard work, merely make the stuff a little more accessible.

You can download the index and documents HERE.

In future, I hope to add more "good" policies (a few of the SANS policies aren't wonderful), and also look into expanding into security standards (ala CIS Security) in the future. If necessary, take this to a consultancy, and ask them to spend some time making these specific to your organisation and way of doing things, but please, if you aren't getting the basics right, don't focus on these. In the meantime, if you're looking for information security policies to go away, so you can get on with the bigger problems organisations, and our industry in general are facing, then this should be a useful tool.

Tue, 10 Aug 2010

Information Security South Africa (ISSA) 2010

Last week we presented an invited talk at the ISSA conference on the topic of online privacy (embedded below, click through to SlideShare for the original PDF.)

The talk is an introductory overview of Privacy from a Security perspective and was prompted by discussions between security & privacy people along the line of "Isn't Privacy just directed Security? Privacy is to private info what PCI is to card info?" It was further prompted by discussion with Joe the Plumber along the lines of "Privacy is dead!"

The talk, is unfortunately best delivered as a talk, and not as standalone slides, so here's some commentary:

We start off the problem statement describing why privacy has grown in importance. The initial reactions were based on new technology allowing new types of information to be captured and disseminated. While the example given is from the 1980s, the reaction is a recurring one, as we've seen with each release of new tech (some examples: Cameras, Newspapers, Credit Cards, The Internet, Facebook). Reactions are worsened by the existence of actors with the funding & gall to collect and collate much information to further potentially disagreeable goals (usually Governments). However, the new threat is that there has been a fundamental shift in the way in which we live our lives, where information about us is no longer merely *recorded* online, but rather, our lives are *lived* on line. It is quite possible that for an average day, from waking up to going to sleep, a significant number of the actions you perform will not only be conducted (in part) online, but that it is possible for them to be conducted using the services of one service provider. My intention is not to beat up on Google, but rather use them as an example. They are a pertinent example, as every business book seems to use them as one. The, arguably, most successful corporation of our current age's primary business model is the collection & monetisation of private data. Thus, while Google is the example, there are and will be many followers.

The next section moves into providing a definition of privacy, and attempts to fly through some fairly dry aspects of philosophy, law & psychology. We've done some entry-level work on collating the conception of privacy across history and these fields, however, brighter minds, such as Daniel Solove and Kamil Reddy have done better jobs of this. In particular, Solove's paper "I've got nothing to hide", and other misconception of privacy is a good introductory read. The key derived point however, is that private data is data with an implied access control & authorised use. Which of the implied access controls & authorised uses are reasonable to enforce or can be legally enforced is a developing field.

As the talk is about "Online Privacy" the talk moves into a description of the various levels at which private data is collected, what mechanisms are used to attempt to collect that data, and what sort of data can be gleaned. It was an academic conference, so I threw in the word "taxonomy." Soon, it will be more frequently quoted than Maslow's Hierarchy, any day now.

At each level, a brief demonstration of non-obvious leaks and their implications was demonstrated. From simple techniques such as cross-site tracking using tracking pixels or cookies, to exploit of rich browser environments such as the simple CSS history hack, to less structured and less obvious leaks such as search data (as demonstrated by the AOL leak), moving to deanonymisation of an individual by correlating public data sets (using the awesome Maltego) and finally to unintended leaks provided by meta-data (through analysis of twitter & facebook friends groups).

Finally, a mere two slides are used to explain some of the implications and defenses. These are incomplete and are the current area of research I'm engaged in.

Thu, 10 Jun 2010

SensePost Corporate Threat(Risk) Modeler

Since joining SensePost I've had a chance to get down and dirty with the threat modeling tool. The original principle behind the tool, first released in 2007 at CSI NetSec, was to throw out existing threat modeling techniques (it's really attack-focused risk) and start from scratch. It's a good idea and the SensePost approach fits nicely between the heavily formalised models like Octave and the quick-n-dirty's like attack trees. It allows fairly simple modeling of the organisation/system to quickly produce an exponentially larger list of possible risks and rank them.

We've had some time and a few bits of practical work to enhance the tool and our thinking about it. At first, I thought it would need an overhaul, mostly because I didn't like the terminology (hat tip to Mr Bejtlich). But, in testament to Charl's original thinking & the flexibility of the tool, no significant changes to the code were required. We're happy to announce version 2.1 is now available at our new tools page. In addition, much of our exploration of other threat modeling techniques was converted into a workshop of which the slides are available (approx 30MB).

The majority of the changes were in the equation. The discussion below will give you a good idea of how you can play with the equation to fundamentally change how the tool works.

There are 5 values you can play with in the equation:

  1. imp - the impact of a risk being realised
  2. lik - the likelihood of the risk occurring
  3. int - the value of an asset (represented by an interface to that asset)
  4. usr & loc - the measurable trust placed in a user & location respectively
The current default formula is:

In English that translates to: The risk is equal to; the average of the impact of the attack and it's likelihood, combined with the value of the asset (exposed through a particular interface), and reduced by the trust of the user performing the attack and the location they are performing it from.

We felt there were two problems with this equation:

  1. It doesn't acknowledge impact as linked to value. e.g. You can't have a huge impact on something of low value.
  2. It doesn't see trust as linked to likelihood. e.g. a trusted user in a trusted location is less likely to commit an attack.
  3. It double weights trust with location and user trust counting at full weight.
  4. It's maybe a little far from semi-consensual views on the subject
After much internal wrangling, and some actual work on modeling fairly complex stuff, we came up with a new equation. While we feel this works better, it does mean the way things are modeled changes, and hence backwards compatibility with existing models is broken (but you don't need to use this equation). The new equation (consider the risk= implied) is:

Once again in English: The risk of an attack is; the likelihood of the attack reduced by the average of both the trust in the user & location, combined with, the value of the asset reduced by the potential impact of the attack (value at risk). (The 0.2 & 2.5 are just to make it fit the scales. Specifically, the 0.2 is because the scale of the entities is 1-5 and we're looking to make a percentage, and the 2.5 is to fit the 0-25 scale on the final graph.)

The key change which breaks backward compatibility here is that impact now becomes a moderator on value. i.e. the impact of an attack determines how much of the asset's value is exposed.

The way things are now modeled, interfaces represent the value of a system. For the most part, all a system's interfaces should have the same value, because as we often see, even minor interfaces that expose limited functionality can often be abused for a full compromise. However, the actual attack (called threats in the tool) determined how much of that value is exposed. For example, a worst-case XSS is (depending on the system of course) probably going to expose less of the system's value than a malicious sysadmin publicly pwning it (once again, dependent on the system and controls in place).

Unfortunately, there's still no provable way to perform threat modeling, but we feel we can go quite far in providing a quick and useful way of enumerating and prioritising attacks (and hence defenses) across complex system.

In a future blog post, I hope to cover some of the really cool scenario planning the tool can let you do, and the pretty graphs it gave us an excuse to justify budgets with.

[ Credit to the Online LaTeX Equation Editor for the formulas, although if you'd like to copy paste the formula described above into the tool, here's an ascii version:

( ( ( lik * ( ( ( (6 - usr) + (6 - loc) ) / 2 ) * 0.2 ) ) + ( int * ( imp * 0.2 ) ) ) * 2.5 )

]

Thu, 11 Jun 2009

Apple vs Microsoft as a malware target.. stop saying market share..

I really enjoy listening to Mac Break Weekly.. Leo Laporte is an excellent host and i would tune in just to hear [Andy Ihnatko's] take on the industry and the (possible) motivations behind certain players moves. (he is sometimes wrong, but always worth listening to). The only time the things ever get a little cringe-worthy is when talk switches to malware and security (although both Andy and Leo for the most part have pretty reasonable balanced views on it).

Disclosure: I am a mac user, and love the hardware.. the fan-boy'ism that surrounds it, not so much..

Most security savvy mac users, dont push Invulnerable-Mac argument too much.. But it does lead to the follow-up "Once Mac gets more market share, we will hit the malware tipping point".. I dont think that this is how it will go down.. Here's my $0.002c on it.

One of the talks we gave at the recent ITWeb Security Summit was titled "One bad Apple".. The aim of the talk was to examine the truth/lies/fud behind the security claims on both the fan-boy and hater end of the spectrum.. I dont want to cover the whole talk here, but do want to touch on just a few of the current annoying red-herrings that normally pop up in this discussion:

Vulnerability counts as a useful Metric

This argument has been had by [many people] far brighter than me, so i wont rehash it here. I think its safe to say that since there isnt really a standard on what gets reported, very few vuln count reports end up comparing apples with apples. What i did pick on during the talk, was that some people dont even bother trying to dress up the stats in a cloak of reasonableness. The table below was taken from ByteSize magazine showing that Apple indeed had more Vulnerability Disclosures than Microsoft:

Vendors with the Most Vulnerability Disclosures (ByteSize - 3rd Ed. 2009)

Instead of muddying the water by asking what a 3.2% disclosure means, or by comparing Apple with Microsoft you have to ask yourself if the table is really comparing Microsoft, with its software, hardware, * against Wordpress with its 60 000 lines of PHP code?

My suggestion there is that if we going to use tables and charts, we should at least stick to the reasonable ones:

Malware defense

Of course the next topic that refuses to die is how mac architecture pixie-dust prevents it from getting worms and viruses.. A quick check should clarify this.. The ILOVEYOU virus which took windows computers all over the world (and according to Wikipedia cost about $5.5 billion in damage) was a snippet of VBS that read your address book, and mailed itself to your contacts (where it did the same). You can hack this up in Automator in seconds.. Same functionality completely..

Memory Corruption Attacks

In recent times, Microsoft has made huge leaps in terms of generic memory corruption protection mechanisms to minimize the effect of buffer overflow/mem corruption attacks. While Apple claimed to do the same with Leopard, they still trail Microsoft in this regard. The 3 points we covered:

  1. Non-executable Stack.
  2. Non-executable Heap.
  3. Address Space Layout Randomization.

(We cover these in more detail in an upcoming [conference in July] - but again, its fairly well understood that OSX in its current form is only randomizing libraries, and that to get the benefit of ASLR, you need to be randomizing everything)

So if we are saying that Apple is just as vulnerable to ILOVEYOU and even more vulnerable today than Windows from a nimda or a code-red, then what explains the fact that we dont see Macs getting owned on the same level as Windows?

The almost global answer is "Market share!". The belief that once more people are running macs, the big bad malware writers will start aiming at them.

If you look at the [netcraft web server survey] (2003) you should notice that at the time that nimda and code-red were running around the Internet, IIS didnt have the lions share of the webserver market either. Their lower market share didnt keep them safe then, why does it keep mac users safer now ?

The real market share difference

One of my guesses here is that we are looking at the wrong data for market share. What Microsoft does have over Apple, is a bigger market share of [developers..]

Microsoft went out of their way to make sure that anyone and their dog could write code for their platform, that any idiot in the world could write an app for them, and many did. I suspect that if you consider that any group will have a proportion of people with evil intentions, then in part what we seeing is just the percentage of the bigger pool.

Different user profiles

The other thing (although it sounds strange) is the question of user culture which is different. My wifes macbook air has very little software that didnt come with the machine. Apples "batteries included" policy means that her machine remains pretty clean.. Her mothers windows machine is a different story

Which means what?

Today, pound for pound, OS X Leopard is indeed more vulnerable than a Vista machine, but the eco system around Mac is holding back the huge embarrassing attacks that shamed Microsoft into action. Apple has a small window during which time they can take action, refine their built in mitigation strategies and come out on the other side acting like they were better all along..

(Recent hires like Ivan give hope for this happening)

If Snow Leopard is done right, it will hopefully be Apples XP-SP2, and us fanboys will be able to keep our securer-than-thou attitude.. If it doesnt, its only a matter of time..

Mon, 9 Feb 2009

Vanilla SQL Injection is oh-so-90's...wait...is it? (Jackin the K)

aka.. Someone put the hurtski on Kaspersky..

The Twitters (via XSSniper and others) and the Interwebs were ablaze with news on a SQL Injection vulnerability that was exploited on AV vendor Kaspersky's site. Detail of the attack can be found here.

It's interesting that SQL Injection (though as old as the proverbial hills) is still such a major issue. In fact, I have it on good authority that the bulk of PCI-related compromises are still as a result of SQL Injection...

In our own work, we see this all over the show.

Also interesting is the fact that the DB in use by Kaspersky is MySQL - so much for the "I don't use MSSQL, I have x database with magical pixie dust SQL Injection protection - what me worry?" argument...

Once again, security one-oh-one...if you aren't *effectively* validating user input, you're going to get bitten some time...

/nick

ED* From the shameless self promotion department:

haroon and Marco have just finished their chapters in an upcoming book dedicated to SQL Injection. We will post more details here when its available. (the book aims to give SQL Injection thorough coverage from OR 1=1 to some of the insanity demo'd at BlackHat last year..)