Raesene's Ramblings

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

I've been meaning to blog about some of the reading I've been doing recently on password policies, but an article in the latest Insecure Magazine tipped me over the edge into writing..
In the article on password management on page 59 the author mentions some elements of a "best practices" password policy which include password rotation every 30 days as a good thing.
I've seen this repeated in many places but I'm not sure where it came from. My opinion is that, in many cases, 30 day password rotation is actually a very bad thing, both from a user experience point of view and also from a security point of view. It's one of those things that gets put in password policies without any real thought of the consequences.
The reasons I've seen stated for rotating passwords are

1. Mitigate password sharing. This doesn't really hold any water, if a user shares their password then they can just share the next one. A much better control is to educate the users never to share their password no matter who asks. This also has the side effect of helping mitigate some social engineering attacks
2. Reducing the window that someone has to crack a password hash. There may be some circumstances where this may help out but really who's to say that it'll be a specific number of days for a password crack. From my experience of auditing windows passwords, you either get it real quick with a hybrid dictionary attack or rainbow tables(in which case the rotation doesn't really help, or you don't get it at all (if you've set password length over about 9 characters most attackers won't be able to brute force a password with a decently designed algorithm.
   A better mitigation for this risk would be to ensure that password hashes are protected in transit (eg with SSL) and on hosts.

Also password rotation has several possible side-effects which actively reduce security

1. Sequence passwords. Most users when faced with a password rotation will choose a sequence password eg ([password1], [password2], etc), so once an attacker knows one password for the user, they'll pretty easily guess the next one.
2. Helpdesk password reset fatigue. Password rotation (along with some other aspects of password policies I'll come onto later) causes a large number of calls to a help desk. From a security standpoint, we want a password reset request to be an alert that someone is trying to attack one of our systems, but if the people being made aware of that alert (the helpdesk) are swarmed with "false positives" in the form of users forgetting their passwords, inevitably real alerts will be lost in the morass. In order to make password resets an effective control, we should be trying to minimize the number of times that the process is invoked (while maintaining the security of the password system obviously)

There are other elements of "classical" password policies that are just about as annoying, but I'll leave them for next time.

There's an interesting story at The Register about the recent leaking of embassy credentials amongst others, by an individual in Sweden.
The story is that someone set up some Tor exit nodes and then sniffed the traffic that came out over them.
There's several interesting points that come out from this, I think.

• Understand the type of security provided by a system. Tor is not end-to-end encryption and you are trusting the exit node as you would trust an ISP router.
• What was done here can be done by any ISP employee. A Tor exit node is essentially like an ISP router. Anything that can be gained by sniffing a TOR exit node could also be gained by any employee of an ISP for the traffic that that ISP handles.
• Embassy users are logging on to their services in the clear!? The main problem here seems to be that embassy staff are logging on to e-mail systems in the clear over an untrusted network (the Internet). It seems odd that they'd go to the trouble of using Tor to anonymise their traffic but not go to the trouble of using SSL or an equivalent to protect their logon credentials end-to-end...

The Art of Scoping Application Security Reviews (Part 1) - The Business ｫ Mark Curphey - SecurityBuddha.com
Mark Curphys starting a series of posts on application security review scoping, which should be interesting reading (although I imagine it may annoy some people in the industry ;o) )
In this one looking at the business aspects I particularly liked the bit about "Bling Bling or Bang Bang" It's true to say that in a lot of cases the money spent getting consultants to write up reports could be better spent elsewhere, especially in cases where an internal team will be refomatting the output before presenting it to the business.
Also like some other people in the industry (Marcus Ranum being an example) Mark seems to have a flair for analogies. drawing the analogy from security assessment companies to the food industry was in many ways bang on.
There are "Chefs" out there, where you specifically want their services, not just those of the company they work for. That said I'm not sure any of the companies out there will want to be associated with being "food chains" !

TaoSecurity: Marcus Ranum Highlights from USENIX Class
There's some very good points here in TaoSecuritys summary of a Marcus Ranum session at Usenix.
I've not seen the original talk but the summary makes me wish I'd been there.
The point on the perimeter being a complexity management tool is very well made in reference to de-perimeterization. It's all very well saying that each individual device needs to be able to stand alone from a security perspective but it's still a lot easier to manage the security of the wider environment when you've got some control over what can get in at all, and the perimeter can and does provide that.
The points about quantification problems seem to have provoked a response from Alex . I actually think having seen these arguments come up repeatedly on blogs and on the CISSP forum and also having started reading "Security Metrics" by Andrew Jaquaith, that there's less distance between the people who are strong proponents of quantitative analysis and those who are proponents of qualitative analysis. One thing that has struck me in these debates is when you look at the examples on both sides they tend to be in different areas of security.
My feeling is that there needs to be a mix of the two styles depending on where they're most appropriate, but I'll reserve expanding on that till I've sorted my thoughts on the matter out better as it's a bit of a minefield...

Rational Security: On-Demand SaaS Vendors Able to Secure Assets Better than Customers?
An interesting post from Hoff on whether having data with SaaS vendors may leave you more or less secure overall.
I've had a couple of experiences of this over the years and I'll say that generally where I'm seeing data hosted out of the company using SaaS I tend to get less of a feeling of security rather than more.
A couple of reasons for this. Using SaaS adds complexity to areas like leavers/movers/starters procedures as there's another notification point for these, and as we know most companies aren't perfect at leavers policies, so you can introduce risks that people who have left can still get access to company data.
Also there's no really good way to easily assure the 3rd parties security. As Hoff alludes to, a lot of companies think SAS70 == Security, which just ain't the case (although it can be useful for getting assurance over the performance of some security related procedures). So you're left with either engaging in a lengthy assurance process which probably isn't practical if you have a lot of SaaS vendors, or relying on a combination of Pen Test/SAS 70/contract.
Of course, this is complicated even more where the SaaS vendor outsources some of their functions like site hosting, as then you have hierarchies of trust with each agent having similar difficulties in trying to assure the security of the companies they rely on.

Black Hat 2007 Multimedia - Presentation, Audio and Video Archives
Blackhat US 2007 presentation are up on the site now, great news for those of us not lucky enough to have been there, we can get some more details on all the interesting ideas talked about.

Came across a tool that should help make light work of the research phase of a penetration test today. Paterva Evolution.
Essentially seem to be a nice graphical way of establishing connections related to a specific resource. So for example, any email addresses that are findable relating to a given domain name.
Of course that kind of research can be done manually, but this is an awful lot slicker!

Well I'm back from (sometimes) sunny shetland. Thanks to some rain and a laptop I'd taken I got some work done on a tool I've started developing for my SANS GSOC gold paper.
RoraScanner is a Oracle 10G security scanner written in ruby. I'm enjoying writing it at the moment as it's let me develop my ruby skills and my oracle skills at the same time.
Hopefully it'll also become a reasonably useful security scanner!

well like some others in the security blogosphere I'm off on my holidays for the next couple of weeks to lovely shetland. Nice place, but not renowned for the density of it's Wi-Fi hotspots so I'll probably be offline for a bit...