Recently in General Security Category

One of the great problems and frustrations of working in security is when those darned users don't follow the nice policies that people have spent so much time working on.

But here's the thing, security professionals actually indoctrinate users not to follow policies!

How do they do this? Well people like following patterns, and so when the pattern "It's okay not to actually follow this" is established in relation to security , people will apply that pattern the next time they run into a security policy that's potentially difficult or hard to follow.

I'm sure there's a lot of security people saying "No idea what he's talking about, all my policies were made to be followed!"....

O'Rly..

Here's an example that I'll bet is familiar to a lot of people. Password policy. Does anyone actually follow their companies password policy? I'll bet it looks something like

• Passwords must be 8 or more characters with upper, lower, numeric and special characters
• Passwords must not be based on dictionary words
• Passwords must be rotated every 30 days
• You must have a different password for every system (including not using the same passwords for personal websites
• Oh yeah and once you've got this list of 40 or so random strings that are really tricky to remember and you might not use very often, don't you dare write them down

We're setting ourselves up for failure, and study after study shows that users will write down their passwords, or use sequences or many other tricks to make them more memorable.

This example (which may be a users main interaction with "security") sets the expectation that security policies can be ignored, because they're unrealistic.

So what's the answer..

Well when designing controls, I think that it's not enough to just look at the technical security properties in abstract. We've got to consider the psychological/sociological elements of the people we're expecting to execute the controls, and maybe take a path that isn't the best abstract solution but may well be the one that will work best in real life...

After all once users are set on the path of ignoring security it becomes pretty difficult to get them back on the one true way!

One of the questions that a Information Security person dreads most is someone from the business asking "Are we secure?".

You can be torn between the urge to explain in detail why that question can't be easily answered and the details of the controls in place and residual risks (and sending them to sleep) or a flippant "yes" which may well come back to haunt you...

One of the reasons why the answer could be so long is the obvious question "Secure from what". A set of controls which may be reasonable tight when faced with a non-targeted threat from malware may be totally inadequate against a motivated knowledgeable insider threat.

So, perhaps one way to help is to break down the "secure" question a bit in to categories of threat.

For example: -

• Non-Targeted Threats


• Internal Targeted Threats


• External Targeted Threats

This way you can classify your controls as to how well they target each threat category, giving a better picture as to what level of risk your organisation is actually running.

Non-Targeted Threats

First off is probably the easiest one, "Non-Targeted Threats". This category includes a lot of the "traditional" threats to your security and is also probably the easiest one to mitigate, as the attacker isn't intelligently looking for a way to attack you they're just randomly interested in getting access to assets.

Examples of this category of threat are

• Malware - Most malware isn't targeted and is just looking to compromise a machine (any machine) for the purposes of using its resources or getting access to information held on it or entered into it (eg, users banking credentials).
• Laptop Thefts - The majority of laptop thefts are not targeted, they're just carried out by someone who sees the laptop as a portable asset that can be easily resold.
• Internet Attacks - A large portion of "script kiddy" style attacks again, aren't targeted at a particular company, they're just looking to compromise servers on the Internet for (mis)use.

Looking at these sample threats, we can see that it's likely that more automated controls will be effective against them. We don't need to be absolutely flawless in our execution of security to defeat them but we need to be "good enough" that the attack moves on to someone else.

So controls which are likely to be effective in this space could be :-

• A-V/Anti-Spyware - Whilst there's a diminishing return on these as attackers work harder to bypass them, signature based A-V still adds a lot of value in cutting out the "noise" of malware attacks
• Patching - Again we're not dealing with attackers who are likely to use a zero-day exploit here, so vendor patching will likely be an effective control to mitigate some of these threats.
• Laptop encryption - Whilst it could be argued that this isn't a perfect control (with the cold boot http://www.freedom-to-tinker.com/?p=1257 attacks that have emerged), it's likely to be an effective control for a random laptop theft.
• Network (and Web Application) Firewalls - Until recently you could have argued that non-targeted attacks rarely use application level techniques, the recent mass SQL Injection attack (doubtless the first of many) show that firewalling at the network and application level is necessary to keep you safe('ish) on the Internet.

So far, so good. Next up we'll look at the trickier area of Internal Targeted Threats.

I was thinking about a story I saw recently about the recent update to the british banking code

There's a lot of discussion about Internet banking users potentially being liable for fraud if their PCs aren't "secure", as a result of this update.

The code says "Keep your PC secure. Use up-to-date anti-virus and spyware software and a personal firewall."

This leads to comments of "I use Mac|Linux I don't use A-V does that mean I'll be liable"

So what we have here is, failure to communicate...

The BBA appear to be correlating having basic software security packages installed with being secure. What I expect happened is that they needed to give some kind of shorthand guidance and that was the best they could come up with.

The problem is that without more detailed guidance fraud teams in banks may use this as the definition of secure and treat anyone who falls outside it as being at fault, which would put a lot of the more Internet security savvy people in the "not secure" bucket.

Personally I run Linux at home and I don't use A-V as there's no credible threat that it would mitigate for me....

http://news.bbc.co.uk/1/hi/business/7334249.stm

This time HSBC have lost 370,000 sets of personal details from insurance customers. One thing that puzzles me in the reporting of this story is the statement that

although the data on the disc was protected by a password it had not been encrypted

How do you password protect something without encrypting it ?! Any software I'm aware of that does password protection will at very least use some form of rudimentary encryption (eg, old versions of winzip or office) or in most cases (pgp, modern office/winzip versions) perfectly acceptable levels of encryption for most scenarios...

There's a new portal over at www.infosec-scotland.com thats been started up to provide information about upcoming security events in Scotland (and the wider UK). There's a calendar of events available and some links to relevant sites.

If you've got any events you'd like to get added to the calendar, just send an email over to Events@Infosec-Scotland.com

The February meeting of the scottish OWASP chapter went pretty well on the 28th.

We had Steve Moyle doing a presentation on Database security (slides can be found here )

I picked up some interesting ideas from his presentation. Firstly the idea that relational databases have a fundamental flaw when it comes to security, which is that the channel used to control them and the channel used to access the information they contain, are the same. This allows for someone who should only have access to information in the system to easily attack it as well.

The other thought which occurred to me when I was listening to the presentation was that any IDS/IPS style device which wants to block "malicious" traffic going to a system needs to parse the information it's seeing in the same way as the protected system otherwise there's a risk that quirks of rendering will introduce false positives or negatives.

It's something I was talking to a WAF vendor about recently, as I was asking them whether their product rendered JavaScript when looking for malicious traffic, as there's a specific problem with the idea of self-modifying JavaScript, looking innocuous in transit but then being malicious when executed

The first meeting of the OWASP Scotland chapter is happening on Tuesday at the Caledonian Hotel in Edinburgh. More details here. Hopefully we should get a good turn-out, I'll definitely be going (planes permitting!)