This tip comes from TechRepublic’s Security Solutions newsletter. Sign up instantly to begin receiving the Security Solutions newsletter in your inbox.
By Mike Mullins
Security doesn’t begin with a server installation, and it doesn’t end with the latest hot fix. In fact, security actually begins with a formal policy. But unless you actually follow your security policy, that piece of paper won’t stop a single attempt to destroy your network or steal its data.
Hackers and script kiddies are trying to access your network. On a daily basis, worms and viruses target your desktops and servers running security-hole-riddled Microsoft operating systems and software. You apply service packs and hot fixes in a never-ending effort to balance between testing the fix against your configuration, gaining downtime permission to apply the fix, and waiting to discover if the fix will work or crash a critical business process instead.
A secure network doesn’t exist, so stop chasing it. Instead, jump ahead of the game: Secure your perimeter by loading only the services your network and customers need to survive.
Move your public assets off your private network and into a DMZ. Then, shift your focus to the insider threat. Your worst enemy isn’t outside your network–it’s inside it and logged on right now as a validated user. Cybersabotage and theft of company data are prevalent and require a tight watch to circumvent.
Identify internal threats
Internal threats can come from a variety of sources, such as disgruntled and/or recently terminated employees. However, a curious user or a poorly designed internal application can be just as harmful.
Secure your intranet using the same reasoning and logic that you use to secure your external network: Treat all connections, both internal and external, as potentially hostile.
Take the following steps to mitigate and remove the insider threat.
Access and permissions
- Document your internal structure, and institute a consistent system for assigning access rights to all data resources. Obtain management approval for restricting users’ access.
- Develop a communications link between the IT and HR departments. Monitor outbound employees, and act immediately to disable their system access. As employees leave or are suspended, terminate their access.
- Remove the Everyone Group from all network shares; there’s no reason for everyone to be able to access everything. Apply Group Access lists to all shared directories, using the least permissions model. Create and manage group security permissions on a need-to-know basis.
System and user accounts
- Identify inactive user IDs, and find orphaned system accounts. Disable both, and mark them for deletion.
- Maintain a list of all system accounts and service passwords. You should change system accounts/service passwords whenever someone with access to that password leaves, every 180 days, or after any network security breach.
- Verify that all users with elevated privileges use and maintain a normal user account with which to browse the Web and read their e-mail. Viruses initiated with Administrative privileges are much more disastrous than those unleashed from a normal user account.
Password policy
- Institute a password policy that’s stringent but not self-defeating. For example, a 12-character, monthly changing pass phrase that mandates the use of capitals, lowercase, numbers, and special characters is self-defeating; in fact, it’s an invitation for disaster. Policies shouldn’t force users to write down their passwords.
- Password policies should include a provision for disabling the accounts of users who share passwords or compromise their passwords by leaving them written in a public place (and, yes, under the keyboard is “public”).
- Make sure users change their passwords every 180 days at a maximum; every 90 days is better.
Successful security, inside and out
Proper configuration during server installation, loading all the hot fixes, and limiting external traffic are good steps toward security. But blocking thousands of daily attacks at your borders does little good if your network is vulnerable from the inside.
Focusing on the external threat and forgetting about the enemy within is a common mistake and a recipe for disaster. Don’t let one of your users compromise your network or your credibility.
Getting hacked from the outside is bad; getting hacked from the inside is insulting. Avoid this insult: Develop, publish, and strictly apply a security policy, and limit and direct your users’ activities–then, watch them like a hawk!
Mike Mullins has served as a database administrator and assistant network administrator for the U.S. Secret Service. He is a Network Security Administrator for the Defense Information Systems Agency.