I'm sure most of you have seen the news of the San Francisco IT administrator who allegedly locked top administrators out of the city's network.
While the mayor was able to obtain the codes from the city employee, the story has obviously been a PR nightmare for the city and a difficult challenge for the city's network administrators. It brings to mind basic questions for all information security professionals to consider, so a similar situation doesn't occur at your organization.
This is a classic example of what a disgruntled person with elevated privileges can do in any enterprise, either encrypting data, or as in this case, changing passwords to restrict access to business functions.
To avoid a similar situation, start with developing a close relationship with the HR folks and management. Once a disgruntled employee starts getting into a position where there are red flags that he or she might be a risk to the organization (i.e. has been formally reprimanded by their manager for insubordination or other malfeasance), there should be steps taken immediately to restrict that person's access to the network.
This applies not just to systems administrators but to the end user as well. Although they may not have the elevated privileges to do the sort of damage that's being alleged in this case, they do have the ability to introduce viruses, worms and malware intentionally into the system by placing malware on a USB stick or CD-ROM, or visiting a known, infected Web site. There are a number of vulnerabilities in any system, and part of any security solution is obviously keeping the bad things out.
That's the simple communications piece of it - have information security professional in regular contact with HR and management to keep each other apprised of potential "problem" employees. This is key to approaching the entire issue of insider threats. FYI, (ISC)² developed a white paper last year that goes more in-depth on the need for information security and HR to partner together to protect the organization.
The second piece is that when these enterprises are architected, there's got to be a way to ensure that no single individual has the ability to do damage. There should always be someone who has the ability to undo the results of malicious behavior. Limiting access to specific circumstances, requiring specific authentication, or ensuring that at least two individuals have access to conduct the same function reduces the likelihood of such an occurrence.
The old concept of the enterprise was to have hierarchies with a person who functioned as the "god of the network" - the system administrator. The nice thing about Windows 2000 was it enabled "delegated authorities." In the early days of Windows in a network environment, if you were tasked with administering a printer, for instance, you received complete domain access control. That meant you could do anything you wanted. Today, most networks assign access to designated groups who only have privilege to administer a printer or a server for a workgroup and don't have the main privilege.
Delegated authorities, as well as the principal of "least privileges," are part of the core tenets of what (ISC)² teaches from its CBK. To find more detailed information, I recommend finding a continuing education course on access control, or consider purchasing one of the official guides to the (ISC)² credentials, or re-reading the section on access control if you already have one.
