Raesene's Ramblings

It's the time of year for New resolutions, so I was thinking about what security people could do differently to help make 2008 better than 2007 for software security.
One thing I came up with. Speak to your purchasing people (if you've got some) or anyone else who approves software purchases in your company and get a criteria added to your purchasing policy that requires software vendors to explain how they ensure the security of the software they're selling you.
After all, software companies are selling you products to help you run your business, and these days if they're selling you vulnerable products it's quite likely to have a negative effect on your company, either through security breaches which exploit the vulnerabilities or through the time you have to spend patching the software they provide.
Now I'm not suggesting that any software you buy will be perfect, but if you make software security a criteria in whether you purchase "package A" or "package B" you give the vendors an incentive to improve the security of their software.
Of course there's the problem of how you actually evaluate their claims... At one level there's the obvious case of listening to what they tell you and asking some searching questions like
"how many vulnerabilities has your product had in the last year" and "what's your policy towards vulnerability researchers and disclosure". Beware of companies who say that their sofware has no vulnerabilities. It's very likely that their either lying or in denial!
Above that another option would be getting your suppliers to submit their software for an independent 3rd party assessment (like the ones Veracode supply). This probably works best for large companies buying critical applications, but I think it's a good idea, in principle anyway, as it helps validate a software suppliers claims of security.

http://www.davidairey.co.uk/google-gmail-security-hijack/
Here's an example of bad-guys using CSRF attacks try and extort money from domain name holders. Interestingly it's the first example of practical use of this kind of attack I've seen.
Although the vulnerability in GMail that seems to have been exploited is now fixed, I bet this won't be the last time we see this form of attack in use, and it does give an example of the kind of damage that a CSRF attack can cause...

Well as is kinda traditional in December various security bloggers have started predicting what 2008 will bring (there's some interesting thoughts and and links to more predictions here).
For my 0.02 of your local currency, I think that next years big topic will be Software Security. A lot of the things we're seeing happen in the security market around exploding vulnerability metrics and malware all come ultimately down to poor software design and development.
Now the industries reaction to this so far seems to be "here's another device for your network to help deal with this". Not surprisingly this isn't a tenable long term strategy as you can't just keep layering on boxes before things start breaking.
Also if you look at the Jericho concepts a key message is that systems have to be able to survive on their own without relying on an ever decreasing "perimeter". Well in order to survive you've got to be well designed/written. The model of hiding all your extremely vulnerable applications behind a big set of perimeter security devices won't work in the future.
So what does this software security trend going to look like in terms of markets...? Well I'd say that companies like Veracode, Fortify and Ounce Labs will do well over the coming year although perhaps for different reasons.
Veracodes service sounds like it could be really useful in starting to answer the hard question "How do I know this software I'm buying is secure?". Traditionally the most that was done was a black-box pen test of such software, and as people know black-box penetration testing is a lousy way to assure the security of anything.
Fortify and Ounce make products which can help companies integrate security focused source code analysis into companies development processes. I don't think that many companies have the business model that allows for the cost of a complete manual review of their codebases, so tools are necessary here to help the process scale.
Of course no product is going to solve this sort of problem alone, so I'd hope to see more output along the lines of some of the OWASP projects, giving guidance on the design side aspect of producing secure software...

Well a combination of holidays/moving server and some problems with my new host (hopefully all sorted now!) have left me not blogging for a while now, but should be back to normal, erratic, service!

Got my Asus EEE PC delivered today! It's a nice little mini notebook which runs Linux out of the box and best of all only costs £219 !
Initially there's a pretty simplistic interface provided (It's targetted at school kids rather than power users) but there's a great wiki and forum over at eee User and it's not too tricky to get shell access and start modifying stuff!!
First off for me has been shutting down the network ports that are listening. Not sure why they thought everyone would need portmapper and samba server running on their laptops, but to me that's a no brainer to remove straight off !
Then it's off to add the debian repositories to the apt setup on it and before you know it it'll be a great little network security machine :)

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!)

User Friendly have been running a series of cartoons on password policies :)
Password policy at it's worst!
A great old one's approach to the problem of password complexity!
Passwords on monitors

The last piece of the puzzle when it comes to password policies is the account lockout . Also this is another area where a tighter policy doesn't necessarily lead to improved security. A lot of companies go for 3 incorrect attempts, and this does lead to a lot of lockouts on Monday mornings and consequently a lot of false positives in the security departments monitoring for attacks on authentication systems.
Again with this section of policy it's important to understand what threat is being mitigated. Account lockout is designed to mitigate online password guessing attacks.
Now given that if you have a password length of say 8 characters with a requirement for upper and lower case characters you've got a theoretical maximum of 52^8 combinations (reality will be obviously be somewhat less than that).
So realistically the risk of an online password guessing attack succeeding is pretty low, if the attacker doesn't have an insight into likely passwords that a user will choose.
So what's a good number for password lockout. Well Microsoft recommends 50, but I've got to say that I think around 10 is good for most circumstances. My reasoning here is that if someone can't remember their password after 10 goes, they've almost definitely forgotten it.
Of course the next part of this is what to do when you've locked the account out. Well if you've gone for a reasonably high setting on the incorrect password attempts, then I'd say in most cases lock the account permanently until the user has gone through the password reset procedure (establishing a good password reset procedure is a topic for another day!).
One problem with account lockout that's raised is the potential for Denial-Of-Service. If the username is predictable to an attacker they can iterate over the namespace and lockout all the accounts.
The mitigation for this depends on the architecture of the systems. If the system is inside a corporation then monitoring should track the attack and incident response should hopefully be able to track down the attacker.
However for Internet facing systems that's obviously not possible, so some other mitigation may be needed.
Two potential options for this are

• IP based lockout. Instead of locking the account for all users, only lock it for the source IP of the attack. This isn't perfect protection but may well work for many attackers
• Use multiple secrets. For example have a password and a secondary secret. Then only increment the incorrect login count if the attacker is getting the username and one of the secrets correct.

The next stop in my trip through password policies and some of the mistakes that are made is password strength (length and complexity).
It seems that for a lot of IT and IT Security people, there's one inevitable truth about password strength which is you can't have too strong passwords.
Unfortunately not true.
Like any security control password strength should reflect the environment that the system is deployed in and the likely threats it will face.
For most circumstances my feeling is that any password over about 9 characters with Upper and lower case alpha and numeric characters is overkill.
For this to be the case I'd say that the password should not be sent across the network in the clear either as plain text or a straight hashed value and should be stored in place in a salted-hash.
If you consider the threats, this will usually be more than adequate.

1. Online Brute-Force. This attack isn't best mitigated by password strength. Account lockout and alerting are a much better way to deal with this. For online systems I saw an interesting twist on this which was to only lockout the ip address the attack comes from as a mitigation of the DoS potential
2. Rainbow Table. The primary mitigation for this is to use salted hashes, as they mitigate this pretty effectively. However where that's not a possibility (off-the-shelf software) consider disk space required for the tables and the time to calculate. I've not seen any tables that go much beyond 7-8, and indeed one estimate I saw for 7-9 character passwords was that it would require 135000GB of space!
3. Offline Hash attack. This one is wheeled out a lot by advocates of extremely long passwords. One point I'd make is that in many scenarios if the attacker already has access to your password database, he's probably already broken in to your system pretty effectively! However even so, it's worth considering.
   Offline password guessing is done either through (hyrbid)dictionary attacks or straight brute-force. For brute force my experience has been that even with modern kit it gets too long to be practical for most attackers beyond about 8 characters. Dictionary attacks work very well if users choose dictionary password so it's worth investing in education/auditing to discourage this

So what does all that leave you with ... Well all of these attacks are reasonably mitigated in typical scenarios with 9 character passwords. Only problem is most people can't reliably remember 9 chunks of totally random information, so the key is to reduce the number of chunks whilst keeping up the number of characters.
There's a number of ways of doing this but things like passphrases like "414 million for that? We was robbed" are easy to remember (especially if you're Scottish) but very difficult to crack.

I jumped in earlier talking about password rotation policies without actually mentioning why I think password policies are so important, so I'll back up and cover that now.
The use of passwords as authenticators for computer systems has been around for a very long time, and for quite some period the security industry has had a focus on reducing their use, as their shortcomings have been well known. Single sign-on, identity management, two factor authentication etc etc have been themes for quite a while.
But here's the thing, passwords aren't going away, in fact I'd say that their usage is increasing.
At home we've got a hugely increasing number of websites offering us services, from social networking sites like Facebook and myspace to forum sites to e-commerce sites, and all of them use passwords (usually not integrated with any over-arching identity management system)
At work, there's the rise of application service providers and "software as a service" which leads to company staff accessing external websites for business purposes, again usually without identity management support...
So it means that getting your password policy right is actually getting more important.
The problem I've seen is that many companies don't actually risk assess their password policies. They set one level for users and one for "super users" regardless of the system location and other controls. Combined with that you get "best practice" principles that seem really inappropriate for most systems and it can be quite a mess....
Over a series of posts I'll look at some examples of where password policies could do with some attention, any feedback/comments welcome :)