3. ESTADO DEL ARTE
3.3 LOS ACTORES, LA SEGMENTACIÓN Y LA MEDICIÓN DE IMPACTO
Symantec (www.symantec.com) defines these different flavors of malware in the following ways:
A computer virus is a computer program written by an ill-intentioned programmer. A computer can catch a virus from disks, a local network, or the Internet. Just as a cold virus attaches itself to a human host, a computer virus attaches itself to a program. And just like a cold, it is contagious.
A Trojan horse, while not technically a virus, has the potential to cause the same kinds of problems that viruses do. Many Trojan horses are designed to steal login IDs and passwords and then email them to someone else who can make use of the account. Other Trojan horses display obscene messages or delete the contents of hard drives. A Trojan horse is typically acquired by downloading a program that seems safe or promises something like free online time. Once it is downloaded and executed, the malicious code begins to work. The difference between Trojan horses and viruses is that Trojan horses do not replicate or spread on their own. They can only be transmitted intentionally via email, disk, or a download directly onto a computer.
Like viruses, worms replicate themselves. However, instead of spreading from file to file, they spread from computer to computer, infecting an entire network. Worms copy themselves from one computer to another over a network (using email, for
themselves. Commonly referred to as antivirus software (even through they are designed to search for more than just viruses), these software products should be used to scan all incoming and outgoing mobile code, file downloads, and emails (including their attachments). In addition, regularly scheduled full scans of every machine directly connected to the Web site should also be conducted to ensure that any malware that escaped initial detection (perhaps with the aid of an inside accomplice) can still be caught before further damage can occur. Table 8.9 is a sample list of commercial antivirus software products.
Table 8.9: Sample List of Antivirus Products
NAME ASSOCIATED WEB SITE
Command AntiVirus www.commandcom.com
eTrust Antivirus www.ca.com
F-Secure Anti-Virus www.f-secure.com InterScan/PC-cillin/ServerProtect www.antivirus.com
LockDown www.lockdowncorp.com Norton Antivirus www.norton.com/symantec.com
PestPatrol www.pestpatrol.com Sophos Anti-Virus www.sophos.com
Tauscan www.agnitum.com
VirusScan www.mcafee.com/nai.com/drsolomon.com Note that www.vmyths.com maintains a list of computer virus hoaxes and myths.
According to several of the antivirus tool vendors, by the summer of 2002, there were over 60,000 malware programs in circulation. Fortunately, the majority of these programs are clones of existing programs or are built from standard virus-generation kits, making it easier for an antivirus-signature-based product to detect it due to common code usage. However, as with signature-based IDSs, antivirus programs that rely on signatures to detect a malware program must continuously update their signature databases in order to stay abreast of the most recent mutations. Unfortunately, even the most recent and extensive signature file still provides less than 100 percent protection. Therefore, some antivirus tools also provide functionality to monitor the machine they are installed on for suspicious or anomalous activities (such as writing to the boot sector of a hard drive) that do not typically occur under normal circumstances. Such monitoring would thereby indicate the potential presence of a malware program that would not be detected by the standard signature- detection algorithm.
To prevent malicious mobile code (such as a Java applet or ActiveX control attached to a Web page) from reaching its intended destination, some organizations scan all inbound (and optionally outbound) mobile code. The scan can take place at one or more of the following locations:
At the organization's perimeter firewall, using security policies defined in the firewall's network traffic filtering rules.
To ensure that an antivirus product has been installed correctly, a security testing team may be tempted to install a real live virus onto a machine or send an infected attachment over a network that is theoretically protected by the antivirus software. Unfortunately, using a real virus for testing purposes (even if it is a comparatively
harmless one) could result in the virus inadvertently escaping the controlled test environment and making it into the real world, contributing to the problem that the virus detection solution is trying to mitigate.
Fortunately, there exists an industry-standard dummy virus definition that, when detected by a virus detection product, will be reported as a virus and can be used to test that the antivirus product has been installed correctly. This inert test file (known as the eicar test file/string) and advice on how to use it can be obtained from www.eicar.org.
En route across the organization's LAN via a network-based IDS.
Via a special-purpose application server residing on the organization's LAN, which intercepts all mobile code requests and attempts to evaluate the potential for mischief by exercising the code in a contained environment. The server then forwards the mobile code only if it appears not to request any suspicious resources or performs any questionable activity. Table 8.10 provides a list of mobile code-scanning tools.
Table 8.10: Sample List of Mobile Code-Scanning Tools
NAME ASSOCIATED WEB SITE
AppletTrap www.trendmicro.com/antivirus.com eSafe Enterprise www.esafe.com
eTrust Content Inspection www.ca.com
SurfinGate www.finjan.com
At the client machine requesting the mobile code. Many desktop-based antivirus tools now also perform security checks on Java applets and ActiveX controls.
Table 8.11 summarizes the checks that may be performed to determine if an organization is taking reasonable precautions to prevent malicious code from infiltrating a Web site.
Table 8.11: Malware Prevention Checklist YES NO DESCRIPTION
□ □ Is a documented policy in place that describes how antivirus products are to be deployed?
□ □ Are all the resources that are supposed to be protected by antivirus software actually protected? Or have they been partially or
Table 8.11: Malware Prevention Checklist YES NO DESCRIPTION
□ □ When an antivirus program detects what it believes to be a virus, are the on-duty security personnel notified? And if so, do they react appropriately?
Monitoring
If any kind of automated intrusion detection mechanism is to be deployed, whether it's a tripwire, IDS, or log analyzer, someone needs to be alerted if a suspicious event occurs. Unfortunately, these alerts don't always indicate the presence of an intruder. The activity could be legitimate and just so happen to have a profile similar to that of a known security problem. Therefore, before any drastic response is initiated, the security personnel will typically evaluate the alert and decide if there really is an intruder at large.
Evaluating suspected threats requires a great deal of expertise. Rather than set up the intrusion detection mechanism to send alerts to different points of contact, many organizations choose to send these system alerts to the same person(s) or to a central monitoring system that filters and then relays all the alerts to a single point of contact.
Ensuring that any deployed central monitoring system has been configured correctly may necessitate emulating an attempted breach on every device and service that has been tied into the monitoring system. The central monitoring console would then need to be checked to ensure that each event was reported in a timely manner. Table 8.12 lists some of the tools that act as central clearinghouses for security alerts from other products such as network-based IDSs, host-based IDSs, honey pots, firewalls, and performance monitors (a performance degradation is often a sign that an intruder is at work).
Table 8.12: Sample List of Centralized Security-Monitoring Tools and Services
NAME ASSOCIATED WEB SITE
1stWatch www.redsiren.com Affinity www.mis-cds.com Brinks www.brinksinternetsecurity.com e-Sentinel www.esecurityinc.com Etrust www.ca.com Exodus www.exodus.net Guardent www.guardent.com IntelliSecurity www.verio.com Isensor www.secureworks.com ISS www.iss.net Harvester www.farm9.com
META Security www.metases.com
Table 8.12: Sample List of Centralized Security-Monitoring Tools and Services
NAME ASSOCIATED WEB SITE
NeuSECURE www.guarded.net NSEC www.nsec.net OnlineGuardian www.ubizen.com
Riptech www.riptech.com SAVVISecure www.sawis.com
Security Manager www.netiq.com
Sentry www.counterpane.com Spectrum www.aprisma.com
TruSecure www.trusecure.com VeriSign www.verisign.com Veritect www.veritect.com VigilEnt Security Manager www.pentasafe.com
Vigilinx www.vigilinx.com For some organizations, having the single point of contact be an outsourced vendor,
typically located at a remote location, would make more economic sense. Once the vendor installs one or more software agents on each system to be monitored, each agent then makes an initial assessment of any detected activity and reports back suspicious events to the vendor's control center for further assessment and potential escalation. The agent could also simply forward the raw log files to the vendor's control center where they are typically scanned by proprietary forensic tools. The results would then be manually reviewed to determine what, if any, action should then be pursued.
If a remote control center is implemented, then the response time of the control center should be evaluated to ensure that the control center can detect and report any attempted intrusion within the period of time specified in the accompanying service level agreement (SLA). If the SLA states that some activities will be immediately reported and others which have been determined by the control center to be of no immediate threat will be logged and reported on a weekly (or other frequency) basis, an organization should confirm exactly what activities will not be immediately reported and then assess whether or not this is acceptable. For example, every firewall that is pinged or each email that is stripped of its virus-infected attachment would probably not warrant a phone call from the central control center to the local security personal. It would instead be included on the regular status report, whereas the disappearance (or reduction in size) of a system log should warrant immediate notification. Table 8.13 summarizes some of the tests that could be run to determine if the security defenses that have been deployed are being monitored adequately.
Table 8.13: Intrusion-Monitoring Checklist YES NO DESCRIPTION
security defense will be monitored to detect attempted breaches? □ □ If manual monitoring is to be used, is each and every defensive
measure actually monitored with the frequency specified in the documented policy guidelines?
□ □ If automated monitoring is to be used, is each and every defensive measure connected to the central monitoring application?
□ □ If a remote control center is used, does the control center detect and report on each suspected intrusion attempt within the period defined by the control center's SLA?