Writing down passwords - yes I am OK with that

The other day I read this article on Threatpost.com:
http://threatpost.com/en_us/blogs/why-you-should-write-down-your-passwords-070610

The article is making the case that in these times people have so many passwords that we can't reasonably expect them to remember them all. It also makes that case that malware is so pervasive that we can't expect passwords to be secure even in password management software like Keepass.

There are things that I like about this article, and things that I don't like about it. The main thing I don't like is that there are a lot of statistics thrown about without a whiff of citation. On the other hand, the advise is sound, and something I have been recommending as one way of remembering passwords.

Yes, I agree that we're probably safer if people can just remember their password, and that's why I advocate that users select pass phrases that are easy to remember, but difficult to crack. for a while my password was 'My password is awesome!' Tell me that you can't remember that. But some people just aren't going to do that, so the next best alternative is to write it down.

See, to me, it seems that it doesn't matter so much if you write down your password. What matters is where you keep it. Working in higher ed, you have to be pragmatic and realistic in the advise that you provide and the audience you're dealing with. Let's face it, PhD's are really well educated in a single topic and seem unable to learn anything else. So trying to teach them to remember all their passwords is a fool's errand. Shame seems to work much more effectively. So try shaming them into realizing that they're not the first person to think of hiding their password under their mouse pad.

What I tell people is that if you keep your password in your wallet, then someone would have to steal your wallet to get your password. You're very likely to realize that your wallet is missing shortly after it disappears. You're very unlikely to notice if I lift up your keyboard and copy down your password. It also seems unlikely that I can steal your wallet, write down your password, and return your wallet. Possible yes; but unlikely.

This is an actual photo from my office by the way. No, it's not my machine.

SCCM: Advertise Task Sequence without notifying users

Hey, I love professors as much as the next Information Security guy working for a University, but sometimes they do silly things. When we first started using Microsoft System Center Configuration Manager (SCCM) to manage our machines we encountered one of those silly things. We had created an Operating System Deployment (OSD) task sequence and advertised it to a collection of computers. When the advertisement went out, a small bubble notification showed up on people's computer telling them that software was available. One of our professors clicked on that and saw our OSD task sequence. The professor then proceeded to ignore all the warnings about lost data and ran the task sequence. He was shocked when his computer rebooted itself and reinstalled everything.

Our response to this was to turn off program notification across the board to make sure this didn't happen again. That of course created other problem when we actually WANTED to notify users about programs or restart options.

But now after scouring the Internet, a solution has presented itself. And since it took me more than 15 minutes to find it, I feel obligated to put the answer on my blog for others to see. So here is how you can advertise a task sequence to all your computers without bubbles showing up and without risk of the users running the task sequence from Run Advertised Programs.

Step 1, create your task sequence and save it. Then right-click on the task sequence and go to Properties. On the advanced tab, select the options so that the task sequence can only run on some flavor of operating system that you're not planning to deploy. Since we only use task sequences to push Windows 7 and Windows XP, I selected Windows Server 2003 64 bit.

Step 2, advertise your task sequence to collections that are full of end user workstations. The machines will get the advertisement and reject it because they aren't running Windows Server 2003 64 bit.

The magic that makes this work is that when you use PXE to boot your machines or if you use boot media to start your task sequence, it ignores the operating system settings that we did in step one. Thus you can pxe boot a machine and see the OSD task sequences, but you don't have to worry about end users accidentally running one of them from Run Advertised Programs.

Book Review - The Failure of Risk Management

Today I finished reading The Failure of Risk Management by Douglas Hubbard (ISBN:978-0-470-38795-5). The book comes in at 259 pages plus an appendix. Overall I found it to be an excellent read.

I should start by saying that I have been a disciple of Hubbard since reading his other book, How to Measure Anything (ISBN: 978-0470110126). In that book Hubbard talks about the variety of things that we just can't measure and then talks about how to measure them. There are a couple of themes that need to be taken away from that book, most important of which is that a measurement is ANYTHING that reduces your uncertainty about something. When you measure length with a ruler you learn that the length of an item is really close to 4 and 3/16 inches, but you could always be more precise. Usually you don't need to. The problem that most of us face when measuring immeasurables is that we can't wrap our heads around the idea that we don't need the same level of precision as we get from a ruler or thermometer.

The Failure of Risk Management takes many of the concepts from How to Measure Anything and applies them to Risk Management. One nice aspect of the book is that it doesn't focus on financial risk or information security risk, or product failure risk. It's just risk, across the board. There is a lot of repeated information in the two books, but I think that How to Measure Anything is more of a practical guide while Failure of Risk Management is more of an explanation of why we should do the stuff he talks about in How to Measure Anything.

The two books are very good companions to each other and I would recommend that security managers should read them both if you really want to see our profession become more than soothsaying and water witching. I think if you're dealing with someone who does not yet believe that Risk Management needs to be quantitative and backed up by experiments and scientific skepticism then they should start with the Failure of Risk Management. On the other hand, if you think we should become more quantitative but think it's too hard then you should start with How to Measure Anything. That will make the challenge seem less difficult. Follow up with the Failure of Risk Management to learn why the way we're currently doing things (heat maps, low/med/high charts) are flawed.

Just like the other book, the Failure of Risk Management throws just enough math at you to be interesting without making you feel like you're sinking. I'll be honest, if you try to read this in two or three long sittings you'll probably become fatigued by some of the math. Take it slowly, especially near the end of the book unless you're already pretty strong with statistics. Having said that, anyone that can follow college algebra should be able to keep up with the most difficult parts of the book. Don't be afraid, jump in.

I enjoyed the book, I give it five stars.

I was watching Robot Chicken the other night and I saw this clip. I thought it was pretty funny, but the ending (1:19) really reminded me of several groups in IT Security.

Those people at the end could be security auditors who are unreasonable about compensating controls.

Those people at the end could be people that adhere to checklist security.

Those people at the end could be the doom and gloom types that wont accept any level of risk and demand ever-more-elaborate ways to stop even the strangest of attacks.

Regardless of who you think they are, enjoy 1 minute and 22 seconds of bathroom humor.

OGEC Governance Risk and Compliance

I was at the Twin Cities Information Risk Round Table meeting this morning in St. Paul, MN. Rick Ensenbach was there talking bout OGEC Governance, Risk & Compliance. I'm not going to get into a discussion about the philosophy of GRC, but there were a couple thing that stuck out in the discussion. Rick at one point mentioned that this is such a broad, business focused philosophy that it needs to be driven from the top down. The other thing that jumped up at me was that there is heavy emphasis on collaboration and communication.

Well my organization doesn't do collaboration and communication. We create kingdoms and defend them heavily and we don't like to take the risk that other people will get the glory for even a portion of our work. We also have a top that will not mandate anything. So if we don't have collaboration and we don't have top-down management, then is OGEC GRC a poor choice for my organization? Furthermore, is there any Risk Management framework that can operate without support of C-Level executives?

I hate Microsoft Event Logs!

I have written some impressive python scripts in my day, but if I ever get this one figured out I will be the king of scripting. Possibly even the king of all things Microsoft. I'm trying to generate a simple report of failed logon attempts by source so that I hopefully detect when someone is trying to break into something using a dictionary attack. It is difficult to defend something when you cant detect attacks.

So this should be pretty straightforward, but it turns out that it isn't. I looked up the event code for failed logon attempts: 529. OK, so now I just search for all the 529 events in the log files. Wow, there are a lot. But since I like to test things out a bit before I get too far into a project, I ran over to a workstation and tried to log in with a fake user account. That should generate a 529 error, right?

server.domain.com MSWinEventLog 0 Security 40398013 Mon Mar 15 13:19:27 2010 672 Security SYSTEM User Failure Audit SERVER Account Logon Authentication Ticket Request: User Name: Bigpooper Supplied Realm Name: DOMAIN User ID: - Service Name: krbtgt/DOMAIN Service ID: - Ticket Options: 0x40810010 Result Code: 0x6 Ticket Encryption Type: - Pre-Authentication Type: - Client Address: workstation_ip Certificate Issuer Name: Certificate Serial Number: Certificate Thumbprint: 40383305

Weird. I'm getting a 672 error instead of a 529. According to this document If the username and password are correct and the user account passes status and restriction checks, the DC grants the TGT and logs event ID 672. So the code 672 indicates that Bigpooper logged on successfully, but the message in the event log indicates that he did not. And error 529 is nowhere to be found. Which begs the question, what do all the 529 errors in my log files really mean then? I did some reading and saw that 529 errors might mean that someone tried to log into the local workstation improperly. Still despite my best efforts, I have not been able to force a 529 error.

Obviously I need to keep track of both of these error codes. The thing that is irritating me is that it seems like there are dozens of different codes for failed logon attempts. Sometimes a single event will result in multiple entries with different codes. Other times an event is pretty straightforward.

Anyway, there is a lot of guidance out there on how to audit failed logon events out there on the Internet. It pays to take a moment to test out the information that you're given before you write scripts that report incorrect or incomplete information to you. After all, the only thing worse that no information is incorrect information.

Happy Ides of March

Couldn't help but laugh at this card