|< Day Day Up >|
21.5 Medium- Sized Networks
Let us now consider a small- to medium-sized business, which likely has no dedicated security staff. Although similar to the home system case, the medium-sized network has some important differences, outlined below. As discussed in Chapter 18, a company is regulated by more administrative requirements and legal responsibilities than the home office of a private citizen. Thus, the level of security and accountability is higher. Most organizations connected to the Internet have at least one firewall and some sort of DMZ set up for public servers (web, email, FTP, remote access). Many deploy intrusion detection systems and virtual private networks (VPNs). Signals coming from all these technologies need to be interpreted and dealt with The technologies deployed during the preparation stage can greatly help future identification and containment.
The security response for such an organization focuses on severe threats. It is well known that many low-severity threats (such as someone performing port scans ) might be precursors for more serious attacks (such as attempted break-ins). Unfortunately, a small company rarely has the personnel to investigate them. Ideally, security reports should include more serious attacks that actually have a chance of succeeding (unlike, say, exploits for services that are not installed). A central syslog server (for Unix environments) is of great value: using freeware tools such as logcheck (http://www.psionic.com), swatch (http://www.oit.ucsb.edu/~eta/swatch/), logwatch (http://www.logwatch.org), or logsurfer (http://www.cert.dfn.de/eng/logsurf/) helps to cope with a flood of logging information and to detect signs of an attack. A host-based IDS will probably take priority over a network IDS, since the latter produces much more information that requires analysis, while alerts from the former usually indicate a successful intrusion requiring immediate corrective action.
In addition, however unconventional it might sound, security controls for this environment must be user -friendly in order to work. The reasoning behind this is simple: the friendlier they are, the more they will be used ”saving the company , for example, from the "password disease" (if you force everybody to have difficult-to-guess passwords, they are likely to post them on their monitors so they don't forget them). The recent rise of hardware security appliances configurable via a browser-based GUI proves this trend.
The audit trail (including security device and system logs) also needs to be collected and kept with more diligence in a medium-sized network than in a home system, since it might be used for attack analysis. System logs and logs from security devices should be archived for at least a week, if storage space permits . This allows you to track the events that led to a compromise, especially if the attacker first tried other methods or tried to penetrate other machines. This information helps investigators assess the damage, evaluate the efficiency of network defenses, and accumulate more evidence for possible litigation or prosecution . It is necessary to stress the importance of a written security policy for audit data collection. Unless mandated by policy or present in a contract signed by all employees , collection of such data can be considered a privacy offense, putting the company at risk of being sued. This danger especially applies to network sniffers that record all network traffic.
Because of the expense, the incident response process for a small- to medium-sized company concentrates on restoring functionality rather than prosecuting the attacker. The eradication and recovery stages are prominent, often in lieu of preparation (there's little planning, if any) and identification (the incident is only responded to when it becomes obvious). Reporting the incident to law enforcement might happen if the benefits of such an action are viewed as exceeding the problems it is sometimes known to cause. The critical issue for incident response in this environment is is a response plan. While a dedicated team is impractical , having a plan will take the company a long way toward avoiding common incident problems. Such problems can include panic, denial, confusion, the destruction of evidence, and the blaming of random individuals within the company ”as the worm mayhem scenario earlier in this chapter illustrated . It makes sense to designate a person responsible for incident response. Even if not trained in information security, such a person might be able to recognize that an incident is taking place and put a plan into action by contacting the right people. Thus, the preparation stage centers on finding and dedicating such a person within the organization.
Overall, the security response process for such a company focuses on surviving as opposed to fighting back ” i.e., speedy recovery and inexpensive prevention. Responding to a major incident will probably involve outside consultants , if detailed investigation is justified for cost reasons. Pursuing an attacker is unlikely .
|< Day Day Up >|