eWEEK Labs recently invited readers to send in their organization-specific questions about security. Well be answering questions on an ongoing basis at www.eweek.com; send your questions, concerns and experiences to [email protected]
The police have procedures to “preserve the chain of evidence” when a crime is being investigated. What procedures should a company follow when an IT security crime is suspected?
Dominique Brezinski of In-Q-Tel and Tom Killalea of neart.org have authored an IETF Request for Comments, dated February 2002, titled “Guidelines for Evidence Collection and Archiving” (ftp://ftp.rfc-editor.org/in-notes/rfc3227.txt) that offers clear and specific guidance here. Lacking abundant case law, a policy based on an IETF “best current practice” like this one could go a long way toward establishing credibility.
- Resist the temptation to analyze until youre sure youve done everything possible to collect hard data — and to protect it against accidental modification. If youre not careful, file system time stamps and other crucial information will be changed in the course of attempts to inspect and repair.
- Dont assume that normal system commands are doing the normal thing: A sophisticated attack may replace system utilities with “dead-man” code that detects a system shutdown and erases its traces.
- Capture raw data, ideally with checksums and cryptographic signatures, to unalterable media and document the time and manner of so doing.
- Write down everything: It may be months, even years, before you need to testify to crucial details.
If you want to detect installed Trojans, worms and other baddies remotely, youll need both an IDS and a vulnerability scanner.
The IDS will detect network traffic probes sent out by hostile software trying to replicate, such as Nimda or Code Red running on internal infected IIS servers. Investigate Internet Security Systems Inc.s RealSecure IDS, Lancope Inc.s StealthWatch G1, NFR Security Inc.s Network Flight Recorder Network Intrusion Detection and Marty Roeschs Snort.
The vulnerability scanner is needed to find hostile software running on client PCs listening on a network port but not normally sending data. Common examples are distributed denial-of-service agents such as Trin00 (commonly listening on UDP port 27444), and stealth system monitoring programs such as Back Orifice (UDP port 31337) and SubSeven (Version 2.1 uses TCP port 27374). We recommend considering Saint Corp.s Saint, eEye Digital Securitys Retina and Renaud Deraisons Nessus.
One of the main points of contention at my organization is the database-powered portion of our Web site. We have stored the database system behind a firewall, only giving the Web server user access to the database. The database connects to the Web server over an internal, private IP connection.
Do we need to encrypt data in the transfer, and do we need to encrypt the database itself across all services?
For background: We are a financial services company with gross revenues between $25 million and $100 million, and serve an extranet with reporting and dynamic services to an audience of 2,500 users daily.
We would suggest worrying much more about searching for application bugs in Web site code and carefully assigning minimal SQL access permissions to the database login used by the Web site. The database and Web server are connected using a private link (a connection physically isolated from the rest of the network), so we wouldnt be concerned about encrypting that traffic because no third party could be capturing traffic without physical access to the site.
Oracles and Sybases databases provide rules-based security systems, which are more valuable than encryption features for keeping information secure.
In addition, be sure to install a firewall in front of the Web server and between the Web server and database; the second firewall should let traffic through only on ports used by the database protocol.
Encrypting database data is most useful when there is concern about the physical security of the disk or backup media. Its less of a defense against online attackers because its hard to store an encryption password so that the application can use it easily but the attacker cant. One approach is to store keys in locked-down tables and create stored procedure wrapper access methods to retrieve encrypted data.
Could you provide more information on the level/17 vulnerability for Cisco devices?
Often referred to as level/17, the formal name for this hole is the Cisco IOS HTTP Authorization Vulnerability. This vulnerability, which was discovered last June, takes advantage of the HTTP server in the IOS software found in most Cisco routers and switches for enabling remote administration. The vulnerability works by sending a special URL to the device that takes the form of http:///level/xx/exec/. (The “xx” is often 17 but can be any number between 16 and 99.) If this exploit succeeds, it gives the attacker full control over the Cisco device.
General good security practices recommend against using an insecure mechanism like HTTP for managing these types of devices. For additional information on the vulnerability as well as information on free upgrades and possible workarounds, go to http://www.cisco.com/warp/public/707/IOS-httplevel-pub.html. There is also information on the exploit available at Bugtraq.
Also in this Special Report
- Ignorance: The Hackers Best Friend
- Security Roundtable
- Here Be Dragons: Web Services Risks
- Threats to Come
- Trail of Destruction: The History of the Virus
- WLAN Hardening Checklist
- Application Hardening Checklist
- Operating System Hardening Tips