General: September 2007 Archives

The message that you need to sanitize public content to remove tracked changes, comments and other private work product hasn't filtered out to the State Department.

It seems the State Department was caught holding a course on business open to citizens of "Algeria, Bahrain, Egypt, Iraq, Israel (limited to Israeli Arab citizens), Jordan, Kuwait, Lebanon, Morocco, Oman, Qatar, Saudi Arabia, Tunisia, the United Arab Emirates, West Bank/Gaza and Yemen."

When news of this United State State Department program that excluded Israeli Jews leaked, they edited the word document that announced that program, and reposted it. Unfortunately they had left "track changes" on and not purged that prior to reposting.

Let that be a lesson, when trying to cover up a program that discriminates based on national origin, make sure you remove hidden data before posting a document to website. Additionally LGF reports, that one of this sites hosting information on that program was serving up the Tibs-Dialer as well.

I saw this article linked from the drudgereport.

US Video Shows Simulated Hacker Attack

A government video shows the potential destruction caused by hackers seizing control of a crucial part of the U.S. electrical grid: an industrial turbine spinning wildly out of control until it becomes a smoking hulk and power shuts down.

Apparently the US Government has obtained a copy of the latest Die Hard movie.

"They've taken a theoretical attack and they've shown in a very demonstrable way the impact you can have using cyber means and cyber techniques against this type of infrastructure," said Amit Yoran, former U.S. cybersecurity chief for the Bush administration. Yoran is chief executive for NetWitness Corp., which sells sophisticated network monitoring software.

"It's so graphic," Yoran said. "Talking about bits and bytes doesn't have the same impact as seeing something catch fire."

So this is like the Day After Tomorrow, Super Volcano or the disaster movie of the week on SciFi. All that talk of a digital pearl harbor just wasn't getting enough attention or money, so now they are creating videos about what could happen.

Even after Y2K, its quite popular to Speculate Creatively About Dastardly Attacks.

Its always nice when your own auditors follow company policy. We have an external auditor in for the next 6 week in order to obtain FISMA certification. At the kickoff meeting, we told the auditors that they were not allowed to put their computers on our internal network, but they were more than welcome to use our guest wireless. This information was also on the account request form that they signed.

I had a feeling that they weren't going to follow our policy. We don't currently have a technical mechanism in place to enforce such a policy. I opened our DHCP management console and sure enough 5 computers had a DHCP lease with a computername and domain giving away that their owner was this auditing firm.

So I was able to bust them on that, and prove to them that we do review the logs and record anomalies in servicedesk.

Back in February I repeated Rob Pegoraro's announcement that SSL for Cox Webmail would be occurring in the first quarter of 2007.

In July, Cox enabled POP3 over SSL and indicated that SSL for Webmail was coming soon as well.

Cox has finally enabled SSL for Webmail, but it is only protecting the credentials at login.

There are several problems with this.
1) When you type in your login credentials, you are at a non-SSL site. You cannot verify the authenticity of the site to which you are providing credentials.
2) When you read your email it doesn't go over a encrypted link.
3) It may be vulnerable to a cookie replay attack such as the one announced against Google Mail at Blackhat 2007

On this somber day, I pause to remember Rick Rescorla. On September 11, 2001 he helped guide the Morgan Stanley employees in his care out of the World Trade Center. His foresight as a security officer saved many lives that day at the cost of his own life.

God bless Rick Rescorla.

I re-read The Cuckoo's Egg by Clifford Stoll this week. I last read it about 10 years ago as I was just starting my career.

Reading it now, it kind of funny to see that the debates haven't changed. If you are new to this field, you might think that Dan Greer invented the concept of Operating System diversity. As I read the book, I found that Cliff mentioned this twice. Of course then the diversity was Unix, Berkeley Unix, and the VAX.

Passwords were another point of contention that hasn't changed. Cliff was complaining that admins made their passwords requirements too stringent (such as system selected) and as a result the users wrote them down. Of course, Cliff later found that when users select the passwords, they are often dictionary words and that was easily brute forced.

In the book, Bill Chandler of Mitre is quoted as saying, "simply impossible. We're running a secure shop. No one can break in" when told that a hacker had abused their systems to attack others. Lets not similarly stick our head in the sand when it comes to security issues.

Last week I wrote in a semi-literate fashionabout my difficulties in packaging the Cisco VPN client. This week I continued trying to package the CiscoVPN client.

The problems continued this week. During the install of 5.0.01.0600 neither the profile or the rootcert were imported. I was able to fix the profile import issue. It turns out there is a bug article saying the install path should not have dashes in the folder names. TAC tells me the rootcert import issue will not be fixed in 5.0.02 and possibly not for a couple revisions after that.

This leaves me in a quandary. Can I deploy 5.0.00.0340 instead? The later version does solve a privilege escalation issue. However that can be resolved by removing the permission for "interactive" on cvpnd.exe. I dont see any other pressing fixes in the release notes. Perhaps I'll even be able to stick to the installshield version and not be forced into using the MSI.

Steve Riley writes about our favorite topic to beat into the ground, passwords. He hits three key points, account lockouts, disabling unused accounts and password expiration.

I more or less agree with him about account lockouts. They are a poor substitute for good passwords. They cause (a few) calls to the helpdesk, and open a vulnerability to a denial of service attack. The problem is how do you then enforce the 15 character passphrase that he recommends. While it is both more memorable and more secure, that doesn't mean it wont get fought hard.

Can you really do away with account lockouts? Lockouts are still seen by many as a requirement for account security. I heard a story recently of a satellite ground system that wanted to lockout their operators accounts until an administrator could perform a reset. During the night the operators would be unable to access their terminals because the administrators only worked during the day. The computer systems are in a secure area on a private network. Does the perceived benefit of account lockout justify the threat to the satellite and its data? I'd say no. Section AC-7 of NIST SP 800-53 lists requirements for account lockouts. If you've got an audit, account lockouts are probably on the list of things they are looking for.

Steve pretty much says that disabling unused accounts is an HR problem. While it is true that the accounts process needs to be hooked into HR, this will only give you hires, terms, and if you're lucky people transitioning to an "on-call" roll. If you have a policy than an account is created for every employee, there will be employees who don't use the accounts.

Finding a good program or script to disable unused accounts is not easy. You want it to run on a schedule. You dont want to have to do this yourself manually. It must be able to exclude users by account name, security group or OU. It must be able to notice when "password never expires" is set so it ignores those accounts. If you're running a Windows 2000 domain it needs to collect last logon from each domain controller and find the most recent time for each account. If a Windows 2003 domain, there is an AD account attibute that collects this and replicates it for you. Lastly it must be able to disable the account without modifying the other attributes. This is kind of a pain since the account disable attribute is actually part of userAccountControl which stores a bunch of things.

Password expiration helps prevent the bad guy from having access forever if he does penetrate the account It also annoys the crap out of people who are sharing accounts (against policy). To me it makes sense for sensitive accounts to be changed more often then regular accounts. I don't think this can be done with Windows currently. I recently used Anixis Password Policy Enforcer to create separate 60 day expiration for users with domain administrator privileges. (Regular users have a 90 day expiration).

Password Policies generate a lot of discussion. It seems to be like "is antivirus dead". Every 6-12 months someone kicks off the same discussion.