Regular readers of this column know that I'm a big believer in the value of educating users about security. But just as important is the education of security administrators themselves--no one knows everything about security, and the learning process is an ongoing one.
I recently encountered a security situation that drove this point home. After helping a company fix some security problems, I ended helping it recover from a threat I had completely overlooked.
A few months ago, an organization contacted me about a number of problems it was experiencing with its internal network and operations. It soon became obvious that someone wasn't doing his or her job. After hiring me to fix the problems--within a few days and with a bit of help--the organization took care of the majority of them itself.
For my part, I implemented a procedure to fix the company's Windows systems, and I created and distributed instructions for reference. I helped remove existing viruses, installed McAfee VirusScan Enterprise, and made sure the company was up to date with critical updates and service packs.
However, with the exception of the McAfee installation, none of these steps was outside the abilities of the organization's employees. It was just a matter of educating the right people.
Everyone at the company seemed pleased--that is, except the person supposedly in charge of computer system maintenance and security, whom management terminated shortly after securing the organization's network and getting it back in working order. I chalked it up to another completed job and satisfied customer and moved on to my next task.
But a few days later, I heard from the company again; someone had apparently hijacked the company's Internet domain. Someone had changed the name servers for the domain, as well as the administrative and technical contact e-mail addresses.
The organization was dead in the water. No one could receive any e-mail, and the corporate Web page was redirecting to a standard "coming soon" page at Registrar.com.
While I had heard of hijacked domains before, this was my first experience with domain hijacking first-hand. No one at the organization knew how to fix the problem, and correcting the domain information with Registrar.com wasn't an easy process.
Finally, after verification of the organization's identity, many faxes, and several tense phone calls, we were able to change back the name servers. Within a few hours, DNS servers were resolving to the correct information.
But explaining the problem to the organization wasn't a simple task either. This was a problem that no one had considered until it actually occurred.
As I've discussed repeatedly, the best way to ensure Internet and information security is by implementing layers of security and establishing procedures. However, companies often overlook some of the more obscure aspects of security and therefore don't have the appropriate procedures or layers of security in place when they need them.
In this case, what the company failed to prepare for was the internal threat. Remember that terminated employee? Not surprisingly, he wasn't too happy about his termination and decided to get even. As the one in charge of computer system maintenance, he was also in charge of maintaining domain registrations.
While most domain registrars use SSL security, that doesn't stop someone from accessing them from a Web browser from just about anywhere. In general, registrars only require a simple username and password to access domain information, even for multiple domains. Anyone with the username and password can make changes--and that includes a disgruntled ex-employee.
While the administrative and technical contacts for the domain typically receive e-mail notification of the changes, these are often the same people with the username and password. And whoever can access the registrar to make changes can also alter this contact information.
And so I learned an important lesson from this incident: Be careful who has access to change the domain registration information for your organization. Leaving only one employee responsible for this is risky; regardless of the duty, everyone needs a backup.
In addition, don't forget to address this responsibility in your organization's security policy, and build in safeguards in the event that you terminate the person responsible for this area. Remember: Even in the face of a daily barrage of junk e-mail, viruses, and worms from the outside world, nothing compares to willful malicious intent on the inside.
Jonathan Yarden is the senior UNIX system administrator, network security manager, and senior software architect for a regional ISP.