|Executive Summary: Security horror stories abound and serve as wake-up calls for IT folks. You can prevent your own security nightmare by following these tips to protect service accounts, increase computer usage safety, perform high-level security assessments, get to know the Encrypting File System, master the authentication methods for Active Directory, properly use the Administrator account, and generate hash values for files and folders.|
Security horror stories tend to wake and shake IT pros, forcing them to think about the safety of assets in their organizations. No one wants 15 minutes of fame on Internet security blogs as a prime example of what not to do. To prevent security disasters, the wise systems administrator avoids missing something obvious, watches out for the rogue colleague and the clueless CIO, quickly tackles user antics, and anticipates the unexpected. The shrewd IT leader also turns security nightmares into proactive strategies and follows tips, such as the ones I provide in this article, to protect valuable information.
Missing Something Obvious
One of the most common security mistakes is overlooking obvious threats. For example, I frequently hear stories about a stolen or lost laptop that holds thousands of confidential records or credit card data. Why is it possible to copy private data to a laptop computer in the first place? Why isn’t the data protected by some form of encryption?
Another common tale centers on the disgruntled employee who maliciously deletes business-critical data. If the company in question had set up file and folder permissions and had regularly secured file server backups, the amount of damage that such an employee could cause would be minimal. These obvious security holes are easy to plug.
Rogue Systems Administrators
Another security risk is that of the rogue systems administrator. IT managers should beware of laid-off and vengeful colleagues who have planted “dead-man switches” throughout the IT infrastructure. These switches could trigger a routine that deletes critical data. At other times the switches could activate scripts that do more damage, such as reconfiguring or deleting critical domain accounts, changing every password in the environment, and locking everyone in the company out of their computers.
These possibilities jar IT pros because of the infinite number of ways that someone who has complete access to the network can cause damage. The rogue systems administrator knows what he or she wants to do and how to bypass any security measures.
The Clueless CIO
Clueless CIOs, although not malevolent, can be dangerous nonetheless. Have you ever heard of a CIO who blindly ordered a change that ended up making the IT environment less secure? At one organization a CIO insisted on being added to the Enterprise Administrators group because, the CIO argued, managers are higher on the organizational chart than systems administrators. Unfortunately, the CIO brought his son to work with him on the weekend and logged the boy on to the network using privileged credentials. It took the company’s administrators two weeks to put everything back in order, including returning several explicitly labeled user accounts to their original names.
In another enterprise, a CIO acting on behalf of a CFO circumvented a policy restricting users from installing software on their own laptops. The CFO’s teenage son wanted to install games on his father’s powerful laptop to use at LAN parties. Unfortunately, the games were laden with viruses and worms. After the CFO reconnected the laptop to the corporate network, it infected other computers. Even CIOs acting in good faith can put your entire network at risk.
IT pros have to keep a close eye on users, but you might not realize the extent to which users can unknowingly compromise your organization. Some have actually given their passwords to survey-takers in exchange for a bar of chocolate. Security guards have been known to disable the alarm on the emergency exit to a data center in order to prop open the outer door for a smoke break. Stories of user antics prove the adage “Nothing is foolproof to a sufficiently talented fool.” What IT pros can learn from such stunts is that the average worker can either be oblivious to or very creative about getting around security policies and restrictions.
Who Could Have Guessed?
Some security threats are almost impossible to anticipate. Even the most diligent, proactive security professionals can’t foresee horror stories that don’t fit into the usual paradigm. For example, a worm-infested antivirus update server could infect all the other computers in an organization. Likewise, laptop computers sent to a manufacturer for repair could return riddled with spyware. Although risks such as these are difficult to predict, IT managers should be on the lookout for them and ready to react at the first sign.
What To Do
In their eagerness to tackle any immediate concerns that might arise from other companies’ horror stories, IT pros should remember to continually and analytically examine their entire security configuration. If they become too focused on avoiding the threat of the moment, they could miss more dangerous security problems. Don’t be swayed by vendors offering a quick bandaid for a problem your organization might not have. Also, think about whether to use scare tactics to awaken end users to dangers that are lurking behind the scenes.
Shop wisely. Beware of consultants and salespeople who spread disaster tales and then peddle their own wares as the only answer to your potential nightmares. Such marketers might have only limited knowledge of your specific security environment.
For example, without looking too hard on the Internet you can find some frightening stories that involve SQL injection attacks. The way to protect against such attacks is to ensure that your web application validates input data. Some vendors sell software that does this. Protecting against SQL injection attacks is a priority if you are running a public-facing website that interacts with a database but is less urgent if the only web application in your organization is a seldom-used intranet site that contains little important data. In one case a decision-maker at a company purchased an expensive piece of data validation software although the only web-driven databases at the business were used by the HR department to schedule annual leave. To avoid such costly mistakes, look at your overall operations before making security decisions.
Scare the wits out of users. Although bombarding IT pros with horror stories can lead to misdirected resources, it’s OK to occasionally frighten non-IT staff members to help them understand the reasons behind your sometimes baffling security policies. They might learn, for example, from the experience of a financial institution that hired a company to test its security. The company scattered USB thumb drives around the institution’s parking lot. Workers passing through picked up the devices and promptly connected them to their desktop computers, curious as to the contents of the discarded items. Unbeknownst to the employees, the company had hidden Trojan horse software on each device that activated when users accessed what seemed to be a harmless collection of pictures and then transferred complete control of the user’s computer to outsiders.
Such a tactic illustrates why some organizations have a policy disallowing the connection of unauthorized USB storage devices to company computers. It brings a complicated policy into focus and makes security policies seem less arbitrary to the people they affect.
Another area in which scare tactics might help is in preparing non-IT staffers for social-engineering attacks. For example, someone phones an employee, pretending to be from the IT department and asking for the employee’s password. The employee reveals the information and suddenly loses control of his or her user account. You could use this kind of horror story to explain why IT staff members must present identification before being allowed to reset passwords.
Likewise, clever mischief-makers might go to a user’s workspace, pick up the phone there, and call the IT department for a password reset. This tactic could fool the IT department into thinking that the display of the incoming caller’s extension offered proof of identity. Telling your users stories such as these will make them more aware of security risks and less likely to fall for them.
Tips to Avoid Becoming Your Own
Security Horror Story
Think sensibly about the risks your organization faces and deal with them in a structured manner. Avoid diverting all your funds to tackle a specific threat just because you’ve recently heard rumors about it. Consider thunderclouds in terms of how seriously they could affect your organization rather than how they already impacted a victim in a security nightmare. Good IT security practice is not only safeguarding an asset but also realizing why you must do so in the first place. When you understand why, you can prioritize the protection of more important assets over less important ones, thus best utilizing the resources you have available for security projects.
Continue to page 2
An important way to prevent safety snafus is to pay attention to tips designed to help you be proactive in protecting your data. The following seven frequently asked security questions and answers from the Windows IT Pro archives can help keep you out of the disaster maelstrom.
Q: How can I perform a high-level security assessment of my company’s computing environment?
A: Check out the Microsoft Security Assessment Tool (MSAT) at technet.microsoft. com/en-us/security/cc185712.aspx. After extracting the content, execute the .msi file to install the assessment tool and view the user guide.
MSAT doesn’t perform system scanning. It’s a series of 172 questions that ascertains technical and business processes and produces a report about security concerns based on the information entered. Although administrators can use the tool directly, Microsoft partners can also run it to help assess their clients’ security status.
Q: How can I improve my computer usage safety?
A: The amount of malicious software on the web has increased greatly. Here are some guidelines to help protect you.
Practice safe browsing. Avoid unfamiliar or untrusted websites, especially sites that advertise deals that sound too good to be true. Don’t install unfamiliar third-party toolbars. I recommend that you use only the MSN toolbar (toolbar.msn.com) or the Google toolbar (toolbar.google.com). You can increase your browsing security by taking these four steps:
1. Set the Microsoft Internet Explorer (IE) security level to High.
2. Add websites you consider safe to Trusted Sites.
3. Use plain text to read the email messages you receive.
4. Block pop-up windows in your browser.
See www.microsoft.com/athome/security/online/browsing_safety.mspx for directions on how to configure IE to take these precautions. For more tips on safe surfing, visit www.intranetjournal.com/spyware/prevention.html.
Apply only approved security updates. Always follow the appropriate method to update your machine and use fixes from windowsupdate.microsoft.com. Be sure that your machine is running the latest patches.
Check before you click. Exercise caution when you receive Instant Messaging (IM) file transfers or links from both known and unknown sources. A malicious user can tap your Buddy/Contact lists so that it looks like someone you know is sending you a link to a file. Before you click any links, always verify with the sender that he or she did in fact send you the link.
Implement antivirus protection. Always run antivirus products with up-to-date virus definition files. You can find a list of antivirus suppliers at www.microsoft.com/security/ partners/antivirus.asp. You can also manually run the Microsoft Malicious Software Removal Tool. Finally, you should use antispyware software.
Q: When should I log on using the Administrator account?
A: Security best practices dictate that you shouldn’t use the Administrator account to perform everyday tasks because of the risks associated with accidentally introducing problems as a result of using elevated privileges. To steer clear of such problems, you should create a regular user account for day-to-day purposes. Then, when you need to perform a task that requires local or domain administrative privileges, use the Runas command to complete such tasks. This command restricts the administrative abilities to the job that you’re on. For example, to open a command prompt with local administrative privileges, enter the command
runas /user:<local machine> administrator cmd
To open a command prompt with domain administrative privileges, enter the command
runas /user:[email protected]<domain name> cmd
Be aware that you can use the NetBIOS naming format with this command. For example, to open a command prompt with domain administrative privileges on my network, I typed
runas /user:savilltech\administrator cmd
Any commands that you enter at the new command prompt will run as the user entered in the Runas command with that user’s associated privileges.
You can replace “cmd” with any command. For example, to start the Microsoft Management Console (MMC) Computer Management snap-in, type
runas /user:<computer/domain>\<account> "mmc %windir%\system32\compmgmt.msc"
To start the MMC Active Directory Users and Computers snap-in, type
runas /user:<computer/domain>\<account> "mmc %windir%\system32\dsa.msc"
For example, to open this snap-in on my computer, I typed
runas /user:[email protected] com "mmc %windir%\system32\dsa.msc"
Be aware that if you run the Runas command on a client computer (e.g., one running Windows XP or Windows 2000 Professional Edition), the command will fail unless you’ve installed the administration tools. Although using the Runas command is slightly more work, you can create shortcuts for each command that you routinely run and make your system much safer. If you experience problems, be sure that the Secondary Logon service is running, because the Runas command requires this service for operation.
Q: How can I protect service accounts from abuse?
A: Administrators often create specific accounts for certain services to operate under (although more products are now taking advantage of Local System to avoid this requirement). Users who know the password for a service account can log on, making it difficult to track their activities. When an administrator leaves, his or her account might be disabled, but service accounts might not have their passwords changed. One way to protect these accounts is to stop users from being able to employ them to log on. You can do so by removing the following rights:
• Log on locally. This right lets you log on at the console with the account.
• Access this computer from the network. This right gives access to resources such as a shared folder on other computers. (Be aware that if the service needs to get to remote resources, you can’t disable this right.)
• Log on through Terminal Services. This right lets you log on via Windows 2000 Server Terminal Services.
Under usual circumstances, service accounts require only the Log on as a service right, so ensure that they have this permission. However, if the service requires remote access to other resources, it might need the Access this computer from the network right. The easiest way to remove the three rights is to create a group and place all the servicetype accounts in this group. Then develop a Group Policy Object (GPO) that denies the rights discussed and apply it at a level that affects all user accounts (e.g., the domain). A deny always overrides an allow.
Q: How can I generate a hash value for a file or folder?
A: You might encounter situations in which you want to ensure that one file is the same version and has the same content as another file—for example, when you send a file to someone, you might want to ensure it hasn’t been corrupted or altered. A hash is an alphanumeric string that’s generated according to a file’s contents. If the file has been changed in any way, the hash value changes as well. Microsoft created a utility to generate hash values. You can download it at download.microsoft.com/ download/c/f/4/cf454ae0-a4bb-4123-8333- a1b6737712f7/windows-kb841290-x86-enu. exe. The program is extracted to a folder that you specify and consists of a readme file and the fciv.exe image, which generates the hash values. To generate a hash for a file, use the syntax
After you enter the command, you’ll see an on-screen message like the following, the generated hash value, and the corresponding filename:
// // File Checksum Integrity Verifier
To generate hashes for every file in a folder, simply specify the folder name, as this example shows:
The command outputs information similar to this on the screen:
// File Checksum Integrity Verifier
temp\BODFRS Live Meeting.wmv 253f066ffa7c50e1e03fa588f23e3230 d:\
The readme file contains more examples of how to use fciv.exe, including employing different algorithms and generating hash values for entire tree folders.
Q: What authentication methods are available for Active Directory (AD)?
A: Windows 2000 and AD introduced Kerberos as the principal authentication mechanism for all Win2K and later machines. However, earlier authentication protocols are maintained for backward compatibility. Here’s a summary of the available ones.
LAN Manager. Microsoft and IBM created this protocol for OS/2. It’s the least secure of all the authentication protocols and is used primarily by Windows Me and Windows 9x. LAN Manager uses a two-part, 32-character password hash. The first seven characters of the password make up the first part of the hash, and the last seven characters make up the second part (thus the 14-character maximum password size). Consequently, if you have a seven-character password, the second 16 characters of the password hash would be the same as the first 16 characters, thus revealing to an attacker that the password is only seven characters.
NT LAN Manager (NTLM). This is a more secure challenge-response authentication protocol than LAN Manager. It uses 56-bit encryption for protocol security and stores passwords as an NT hash. Windows NT 4.0 Service Pack 3 (SP3) and earlier clients use this protocol.
NTLMv2. This version of NTLM uses 128-bit encryption and is employed on machines running NT 4.0 SP4 and later. This is the most secure challenge-response authentication available.
Kerberos. Kerberos is essentially a ticketbased authentication protocol. See the FAQ “What is Kerberos?” at www.windowsitpro.com/article/articleid/15294/15294.html for a more detailed explanation. You can also find out more by reading “Win.NET Server Kerberos,” October 2002, InstantDoc ID 26450. Kerberos is the most secure authentication method, and you should use it whenever possible.
Q: If I use the Encrypting File System (EFS) to protect confidential files, how can I avoid losing that information when my organization upgrades its computers, or if a user loses a computer and I need to restore files from backup?
A: The best way to prevent data loss is by backing up the data recovery agent certificate and/or the user’s EFS certificate and private key. Without one of these certificates and its private key, there is usually no way to recover an encrypted file.
If your computers are part of an Active Directory (AD) domain, you can take advantage of a Group Policy feature that lets you set up a single data recovery agent certificate that you can use to decrypt any encrypted files in the domain. If a central data recovery agent isn’t an option, then you must export each user’s EFS certificate along with its private key and store it in a safe place.
To export a certificate, log on as the user in question and open the Microsoft Management Console (MMC) Certificates snap-in (not the MMC Certificate Templates snap-in or the MMC Certification Authority snap-in). Open the user’s Personal\Certificates folder and find the EFS certificate. Right-click and select All Tasks, Export. Click Next on the first page of the wizard, select Yes, export the private key, and click Next until prompted for a filename. Save the file to some type of removable media and finish the wizard. Now store the certificate in a physically safe place.
In the future, if a user is unable to access a file—whether it has been restored to a new computer or Windows has been reinstalled— just use the Certificates snap-in to import the certificate, and you have solved your problem. A final note: Your concern about losing data is well placed. There is no back door into EFS; if you lose the key(s) to it, you lose your data.
—Randy Franklin Smith
By following practices such as the ones outlined in these tips and by taking a proactive approach to monitoring your entire security configuration, you can avoid becoming an example of a security horror story. If you invest time and resources in anticipation of a disaster, it’s likely that the calamity won’t occur. You’ll save money in the long run and won’t have to worry as much about the foolhardy folks around you.