Password Policies on Disconnected Systems

Another great post from Jesper's blog, regarding what password policies are not enforced when a system is not connected to the domain:

Some Password Policy Settings Are Not Enforced When Disconnected

My first thought when hearing the topic was, "how can they ignore password expiration and account lockouts when disconnected?" After reading the explanation, however, I realize it couldn't be done any other way. Both of these policies would make it extremely difficult for mobile users to function if they were applied when the user is disconnected.

It's not that the policies are that much worse for mobile users (although Jesper recommends against account lockout policies anyway); the problem is the hoops that must be jumped through if someone runs afoul of one of these policies while away from the domain, or away from an internet connection entirely.

The concept that a user will have to log in to a VPN in order to reset their expired password is bad enough. I could see this being a huge issue for my mobile users, and for myself as well.

But even worse is the account lockout policy. If a laptop could be locked out by entering in the wrong password too many times, the only recourse would be to reconnect the laptop to your network to accept the re-enabling of the account. No VPN shortcuts either; the computer would actually have to be connected for this to work. Imagine having a company based on the U.S., and having a user lock themselves out while traveling overseas! What do they do, ship the laptop back to the States?

Thankfully, Microsoft has insightful people like Jesper who consider these issues before they become a problem.

The wisdom of "Temporary" Adminstrators

Interesting post over on Jesper's blog:

"Temporary " Administrators

As Jesper explains, don't make anyone an administrator temporarily, unless you are prepared to trust them to be an administrator permanently. A temporary administrator can put code in place that will give them access for long after you have revoked their administrative access.

Malicious intentions aside, the pervasiveness of malware should make you think twice about doling out administrative privileges, whether on the local system or domain- (or enterprise-) wide. All it takes is hitting one disreputable website with administrative privileges to turn a system into a Typhoid Mary.

I have had the misfortune to deal with many systems in a similar circumstance. One organization decided, in their shortsighted wisdom, to correct application access issues by giving users local admin rights. This is all too common, especially in small to mid-sized businesses. While this will alleviate the symptoms quickly, it will cause more problems in the long run.

The process of bringing the users' access down to acceptable levels of privilege was painful, but not as painful as attempting to eradicate some of the pests these users had accumulated over the months of surfing the web as administrators. The last few lines of Jesper's post brought back the memory of the solution to this problem:

"Is the rootkit now gone? Noohooo. It is still there, and will remain there until you use the rootkit removal tool: format c:\ (from neutral read-only media)."

This is the only option in most cases, since you can never be sure you have gotten rid of every last piece of malware that can invade a system. I have wasted way too many hours in the past attempting to clean a PC without wiping it out, only to go back a day later to find it just as infected as when I started, if not worse.

Penetration Testing vs Vulnerability Assessment

Informative post on the difference between pen testing and vulnerability assessment:

Penetration Testing vs Vulnerability Assessment

This post brings up an important point. What most companies are looking for, at least initially, is a vulnerability assessment. This allows you to generate a list of problems with your infrastructure that may need repair or some other form of mitigation. This can take the form of a security audit, where you have some outside consultant come in and run all kinds of tests against your network, or it can take the form of some form of vulnerability scanning product, such as the one offered by Qualys.

Why Winternals Sued Best Buy

While this is not a security-related issue directly, it concerns the illegal use of copyrighted software. Why a company as large as Best Buy would choose to do something so blatantly illegal, I can't comprehend.

Why Winternals Sued Best Buy

On a separate note, the Winternals Administrator's Pak is one of the most useful collections of utilities I have ever come across as a network administrator. While I have not had as much need for it since moving into the security field, I still recommend it every chance I get.

Skype Risk Analysis

I spent some time reviewing the risks of Skype, a popular VoIP application. I figured since i put the time into reading it, I'd condense my thoughts into an article on the subject.
Disclaimer: I don't claim to have any inside knowledge of the workings of Skype. The only information I have is based on documentation that is publicly available on their website, as well as a few other analyses I have seen on the web.

Overview

Skype is a popular Voice over IP (VoIP) system, created by Niklas Zennström and Janus Friis, founders of KaZaA. Similar to KaZaA, Skype is based on Peer-to-Peer (P2P) technology. While other VoIP services use a centralized server to manage communications sessions, Skype software clients directly interact with each other to ensure that the network directory is up to date and that calls are quickly completed. This P2P network allows clients in different locations to locate each other and send text messages, hold voice calls, and exchange data files.

Unlike KaZaA, which earns its revenue from advertisements, the Skype client contains no adware and spyware, at least at the time of this writing. Also, calls between Skype clients are free of charge. Instead, the Skype system earns revenue by charging for the use of the gateway that interconnects the Skype network with the regular telephone system.

Another important detail to note is that KaZaA 3.0 contains its own integrated Skype client, so users of Skype may also be communicating with users of KaZaA, rather than just Skype users.

Although some of the files that are traded over KaZaA are exchanged with the permission of the copyright holders, it appears that the primary use of KaZaA appears to be the illegal exchange of copyrighted songs and movies.

Description of Skype services

The Skype client can perform the following functions:

• Voice calling to another Skype user
• Voice conference calling
• Voice calling to traditional telephone lines (SkypeOut)
• Voice calling from traditional telephone lines (SkypeIn)
• Chat, providing instant messaging for groups of up to 48 participants
• Cross-platform file transfer
• Directory and presence management

Skype client software is compatible with the following platforms: Windows XP, Windows 2000, Linux, Apple Macintosh OS X, and Pocket PCs running Windows Mobile 2003.

Network Requirements

At a minimum, the following conditions must be true of the network being used by the computer running Skype for the Skype client to communicate :

• Outgoing TCP connections should be allowed to remote ports 1024 and higher.
• Outgoing TCP connections should be allowed to remote ports 80 and 443.
• Outgoing UDP packets should be allowed to remote ports 1024 and higher. For UDP to be useful to Skype, the NAT must allow for replies to be returned to sent UDP datagrams. (The state of UDP “connections” must be kept for at least 30 seconds, and Skype recommends that these translations be maintained for as long as an hour, if possible.)
• The NAT translation should provide consistent translation, meaning that outgoing address translation is usually the same for consecutive outgoing UDP packets.

Skype is very effective at circumventing the restrictions of firewalls and Network Address Translation (NAT), provided most of the above requirements are met.

Skype Security

When discussing the security of a VoIP solution, there are a number of factors to take into account.

Authentication – the only authentication being done by Skype is based on a user name and password. Obviously, no one should ever share their Skype user name and password, or have it saved on their computer. Potentially, anyone with User A’s user name and password could install a copy of the Skype client, and receive calls that were intended for User A. Equally likely is the scenario where User B “borrows” User A’s laptop, and is able to use the Skype client with a saved password. Of course, even if User B receives a call intended for User A, it is likely that the caller would be able to identify User A by their voice, in many cases.

Encryption – According to Skype, all message contents between any pair of Skype users is encrypted end to end by utilizing the RSA encryption algorithm for key exchange and Advanced Encryption Standard (AES) in its AES-256 mode as its bulk encryption algorithm. The key for a Skype session is unique to that session and is not re-used. However, Skype does not publish its key exchange algorithm or its over-the-wire protocol and has not explained the underlying design of its certificates, is authentication system, or its encryption implementation. Therefore it is impossible to validate the company's claims regarding encryption.

Integrity – Software running on P2P networks could have wide-ranging implications that are not completely understood yet. While the Skype client does not currently include any spyware or adware, there are no guarantees that it might not include them in the future. Also, as Skype is a completely closed-source system, it is harder to determine if the software contains vulnerabilities that could be exploited by malicious users.

Bandwidth – If a Skype client makes a voice call to one person, the bandwidth usage is minimal, approximately 70kbps. However, if conference calling is used, or multiple users are running the Skype client, this can add up very quickly, and have an impact on internet bandwidth.

File Transfer – Similar to Instant Messaging programs, and other P2P applications the Skype client can be used as a file transfer utility. This could potentially allow confidential information to be sent to unauthorized individuals.

Malware Vector – As mentioned above, files could be transferred between Skype clients. This could allow a virus to be brought into the network if the Skype client connects to another computer that is infected. Skype poses more risk than programs like KaZaA because they have built-in anti-virus protection that scans programs as they are downloaded; Skype appears to have no such protection.

Conclusion

In some ways, the voice functionality of Skype appears to have more security than traditional telephone networks, based on the fact that the sessions are encrypted. However, we have no way of knowing how well the encryption is implemented, considering this is a closed source product. It is also feasible that the Skype system could be compromised by a skillful attacker, or by a motivated insider.

The larger concern is the risk of having unwanted software introduced by the Skype client. While the file transfer functionality is an easily recognizable vector, a less obvious risk is that the application itself could be compromised. If a buffer overflow could be utilized to make the application accept a malicious file and execute it, any connection made to the Skype client could be a potential attack.

I am attempting to present both sides of the issue in this analysis. The choice is yours whether this application is enough of a risk to restrict its use in your organization.

Who Sets The Audit Standards? Part 3 of 3

And here is part 3 of this informative series.

http://www.rsasecurity.com/blog/entry.asp?id=1080

Topics covered include what members get out of a professional body, and what needs to be done to further support professionalism. This is the final part of the series, so it also includes a conclusion.

Who Sets The Audit Standards? Part 2 of 3

Part 2 of 3 of a very interesting series by John Madelin.

http://www.rsasecurity.com/blog/entry.asp?id=1077

Among the topics, the devaluation of the CISSP brand, whether the scope of financial auditors should be broadened to include security concerns, and what constitutes a "Professional Body."

StillSecure StrataGuard 4.5 Free

Alessandro Perilli from Security Zero wrote an excellent review of StrataGuard 4.5 Free, an Intrusion Detection System that is available free of charge.

Based on this review, I'm downloading a copy of the ISO to try on my test network.

Florida band blocked from trip by terrorism fears

This story is somewhat close to my heart, because I have family in Southwest Florida. And I will admit that I was in my high school band, and we went on trips, but none as cool as this.

Fort Myers High band denied trip to London

This band is actually invited to go to London, tour some famous historical landmarks, and participate in the 2007 New Years' Day Parade. School officials are blocking the opportunity because of the terrorist attack from July 2005. Any terrorist reading about this story would think "mission accomplished."

Note: I first picked up on this from Stupid Security.

Block Google Desktop

Many organizations are not so keen on their employees using Google Desktop within their enterprise. I share that apprehension, and I have done a little research into what can and cannot be done to rein in this overly communicative application.

A lot of the credit for being able to control this application must go to Google. I'm not sure if this was the case when it was initially released, but the current Enterprise version of the program includes some great resources. Most importantly, it includes an Administrative Template for Windows Group Policy. If you load this template into a GPO, you can effectively curtail any behavior you deem unsuitable for your network.

For my money, the most important settings in this template are the following:
1. Prohibit Policy-Unaware versions - Prohibits installation and execution of versions of Google Desktop that are unaware of Group Policy.
2. Disable sharing and receiving of web history and documents across computers - Prevent Google Desktop from sharing the user's web history and document contents across the user's different Google Desktop installations, and will also prevent it from receiving such shared items from the user's other machines.
3. Disallow Plug-ins - Prevent installation of Google Desktop plug-ins.

If you put these three policy settings in place, you'll be much better off from a security standpoint than if you do nothing.

If you want to go further, you can take some steps to completely block Google Desktop from running at all. Some suggestions:
4. Prevent Indexing policy settings - There are about 19 different "Prevent indexing of ..." policy settings in the Administrative Template. You can enable some or all of them to prevent that category from being indexed at all. If it's not indexed, it can't be shared, copied, or transmitted to a third party.
5. Software Restriction Policies - You can enable these policies through Group Policy, and choose to disallow the application from running throughout a domain either based on a path rule (C:\Program Files\Google\Google Desktop Search\GoogleDesktop.exe) or based on a hash rule, where Windows creates a hash of the current version of the file. (Note, the hash will be rendered obsolete if the version of Google Desktop is updated, but that can be prevented with the following 2 entries)
6. Block Auto-update setting - Another Administrative Template setting; you can choose to block updates to the program. No updates = no additional functionality to worry about blocking.
7. Content Filtering - You could add desktop.google.com to whatever method you use to block access to websites. If your users can't get there, they can't download the installer in the first place.

I'm sure there are other methods that can be used to block Google Desktop, but I've found these to be pretty effective. I must admit, I would probably be doing a lot more administrative acrobatics (such as blocking things through firewall ACLs, or more group policy settings) if Google had not released their Enterprise software. I should also note that it includes an Admin Guide that explains a lot of the features of the program, including all the settings in the Administrative Template file.

While Desktop Search Engines (DSE's) such as Google Desktop do present a risk, that risk can be mitigated, as long as the software company is willing to provide the tools to do so. I think Google is setting a very good example with their Google Desktop for Enterprise option.

I intend to explore other DSE's in the near future. I will post my findings.

Termination Procedures

It is very important for businesses of any size to have in place specific procedures that must be followed whenever an employee leaves the company, whether of his own volition, or by the action of the company. As I mentioned in my previous post, these procedures must be followed no matter which employee is being terminated.

Some considerations for such a procedure:

1. Document it. It doesn't matter if your company has only 1 server that runs 1 critical application, and an email server; there should be a written document that explains how to remove access for any user, and how to disable or delete their email address.

2. Be comprehensive. On the flip-side of the coin, if you have 30 or 40 servers, 5 applications for each department or business unit, and email, VPN access, intranet applications, etc; you need to have a checklist for each item so that all access to each system can be verified and removed.

3. Know your users. This ties in to #2. If you don't know what accounts are out there, you may not be able to track them all down when you need to. Make sure all user accounts for each system are documented per employee, so that you can easily figure out which systems to go to first when disabling accounts. It's important to check the rest, just in case, but if it's going to take you the better part of an hour to get through everything, it helps to prioritize.

4. Beyond IT. Not unreasonably, we tend to focus on computer systems access, since that is our main responsibility. But it is important to think beyond the PCs and servers during terminations. For instance, access to voicemail boxes, teleconferencing systems, keycard entry systems, combination locks, even old-fashioned key locks. While not all these may be "owned" by IT, they must be part of the procedure, so the person or department responsible for restricting those means of access can be notified and respond in a timely fashion.

5. Independent verification. Not that I'm suggesting anyone shouldn't be trusted, but it is a good practice to have a second pair of eyes verify that access has been completely removed during the termination procedures. In that case of having 30 servers or so to go through, it can be a tedious process, and anyone can miss an obscure method of access. Human error should be taken into account in any process whenever possible.

That's the overview for terminations. These procedures should be part of the security manual of any company, large or small.