The entire event was documented and submitted to upper management. Now the IT department had to decide what action to take. It decided that the associate's PC would have to be locked down better, and that IT would need to monitor the machine and the new associate closely. The administrator password was reset using Winternals System Commander 2002. Next, Debra removed the ability to boot from floppy and CD-ROM and set a password on the system BIOS. She knew the BIOS could potentially be reset with a jumper or possibly by removing the system battery. To prevent this, or at least make it difficult to open the system, she added a lock to the case. On the software side, she enabled auditing on the PC and began checking the logs on a daily basis. Several days later, she remembered a TechRepublic article that mentioned a tool known as SELM, or Security Event Log Monitor. She installed the SELM product -- which can e-mail alerts as well as create reports for later review -- so that she wouldn't have to manually check the logs every day. In addition, she monitored the PCAnywhere service on this PC. In a meeting, the new associate apologised for his actions. He explained he was working very late and did not want to bother anyone at that hour. He had some software that he wanted to install for the project he was working on and needed administrator access to install it. The IT manager went on to explain the policies the company has in place restricting anyone from installing software without IT involvement. He further explained that IT was on-call after hours for any problems or needs that might arise. The new associate decided that he did not want to work on the project anymore. More problems
During a routine check the next day, the new associate's PC did not appear to be connected to the network. A call to his office confirmed that he had not arrived for work yet. Debra was given access to his office and discovered he had disconnected his PC from its network jack and had connected his Linux box to that jack instead. She disconnected the Linux box and reconnected his PC. The next day, the same scenario played out again. His PC was gone from the network. Debra couldn't gain access to his office, so she entered the wiring closet where his network jacks were connected and viewed the status of the switch ports. One port had an active connection. Since she knew his PC was not connected, the only possibility was his Linux box. The patch cable was disconnected, and the entire incident was again reported to upper management. He was asked to remove his Linux box from the premises. He indicated he would comply, and his other PC was reconnected to the network. Debra realised that she needed some way to be sure that his Linux box was truly off the network. Again, she remembered a TechRepublic article about various net admin tools. One of those tools was the GFI free network scanner called LANguard. She installed LANguard and scanned her entire network. It did a pretty good job of identifying the types of systems it found. It recognised a Red Hat Linux system as "probably UNIX," but it recognised one of Debra's Mandrake boxes as "Linux Mandrake." After running a scan, LANguard can sort the results by OS, which makes it easy to view what has been discovered. In addition to listing the OS, it indicates all the open ports on a system and points out known vulnerabilities. Debra now runs scans daily and reviews to see whether any new systems show up. The registered version offers a comparison feature that allows comparison of two scans to note any differences. Once a hacker
Things were pretty quiet for a while. Then the SELM software sent a few alerts with the new associate's name. If you have used security auditing in NT, you already know the security event log can have some pretty cryptic messages. Nevertheless, after doing a bit of research, Debra figured out that the new associate had downloaded some software and was stopped dead because of the lack of admin privileges. Looking closer at the machine, she found that several services had been stopped; one was the antivirus software, and another was the PCAnywhere service. The associate was again confronted, and he told IT what it had suspected: He had attempted to install software on his PC but was unsuccessful because of the lack of administrator rights. Next, the IT department turned to the System Policy Editor. It wanted to disable access to several Control Panel applets, especially the Services applet. IT was already using system policies to perform change control, such as limiting access to the Display applet in the Control Panel and use of the Run command and the registry editing tools. Although the System Policy Editor in NT has no built-in controls for limiting the Control Panel except for the Display applet, you can customise it by creating your own ADM files with the proper registry tweaks. So Debra created a custom ADM file that removed the Devices, System, Services, Server, and Network applets from Control Panel. Object lesson
The entire event was exactly what Debra's IT department needed to test its current security policies and find out the strengths and weaknesses of its internal security. Sometimes, a problem such as this is ideal for evaluating your security practices, as long as you have the right stuff to fight the problem -- and most important, to keep a similar problem from popping up in the future. In this battle, Debra and her IT department mainly acted reactively. But it led them to look at their policies and practices and try to be more proactive and prevent similar incidents from occurring. They are still revising their security policies and making changes to keep their network secure and their data protected.
For a weekly round-up of the enterprise IT news, sign up for the
Enterpise newsletter. Find out what's where in the new Tech Update with our
Guided Tour. Tell us what you think in the
Enterprise Mailroom.
Enterpise newsletter. Find out what's where in the new Tech Update with our
Guided Tour. Tell us what you think in the
Enterprise Mailroom.
Talkback
Let me get this straight:
1) IT agrees to let this "associate" set up a Linux system
2) IT never gives him a network jack
3) IT is suspicious of Linux and the project even though they agreed to it
4) This associate is discouraged from installing software on his PC, even though IT could easily determine if the software is "safe"
5) The associate is discouraged from connecting his Linux box to the network
6) IT never gives this associate admin access to his own PC.
Why did they hire this guy in the first place? Sounds like a classic case of turf protection to me.