Part 2: Security response in a midsize office

How can you make security more effective under the constraints of a small or medium-size company?

In Part 2 of this series, we look at this environment and at the similarities and differences with the home-user case discussed in Part 1 (see story).

Small and medium-size businesses probably have no dedicated security staff. Their attitude toward security is to try to stay out of trouble. In this sense, small and midsize companies handle security the way people handle the security of their home office systems -- but with important differences that I'll outline below. These businesses often have employees who would astonish security professionals with questions such as, "Why would somebody want to hack us? We have nothing that would interest hackers." Today, most IT professionals understand that server disk storage, CPU cycles and high-speed network connections have a lot of value for malicious hackers and alleged cyberterrorists.

Even though they're small, these businesses are more regulated and have more administrative requirements than a private citizen in a home office. These requirements might include responsibilities to shareholders, fear of litigation for breach of contract, professional liability and many others. Thus, the level of security and accountability would need to be higher than in a home office. Most organizations connected to the Internet now have at least one firewall and some sort of DMZ setup for public servers (Web, e-mail, FTP, remote access). Many are deploying intrusion-detection systems (IDS) and virtual private networks (VPN). All these technologies raise new concerns about what to do with signals coming from them, since companies rarely hire new security staff just to handle those signals.

Anton Chuvakin

Security responses for such an organization would likely focus on high-severity threats. While it's well known that many low-severity threats, such as someone performing port scans, might be precursors to more serious attacks, such as an attempted break-in, a small company would rarely have the personnel to investigate those types of incidents.

Ideally, security reports should focus on attacks that are more serious and that actually have a chance of succeeding (unlike, say, exploits for services that are not installed). A central Syslog server (for the Unix environment) would be valuable; and using freeware tools such as Logcheck from Psionic Technologies Inc., Swatch and logsurfer could help in handling a flood of logging information and in detecting the signs of attack. A host-based IDS would 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.

The Need for User-friendly Security Controls

Unconventional as it might sound, security controls for this environment must be user-friendly to work. The reason is simple: The more user-friendly they are, the more they will be used. That will save the company from the so-called "password disease," the ailment that befalls organizations that require every employee to have a hard-to-guess password. What happens is that employees choose passwords that are hard to remember and then write passwords on yellow sticky notes, destroying any security benefits. The recent rise of hardware security appliances configurable via a browser-based graphical user interface proves that this is a problem.

In addition, the audit trail (security device and system logs) should be collected and kept with more diligence than for home systems, since it might be used for more in-depth attack analysis. System logs and logs from security devices should be archived for at least a week, if storage space permits. That allows you to track the events that led to a compromise, especially if the attacker tried other methods first or tried to penetrate other machines. Having this information would help investigators assess the damage, evaluate the efficiency of network defenses and accumulate more evidence for possible litigation or prosecution.

It's also important for companies to have a security policy for audit data collection. Unless mandated by the policy or present in a contract signed by all employees, collection of such data can be considered a privacy offense and could put the company at risk of being sued. This especially applies to network sniffers that record all network traffic.

Don't Get Mad or Get Even

Simply for cost reasons, the incident responses of small and medium-size companies should concentrate on restoring the functionality rather than on prosecuting the attacker. Reporting the incident to law enforcement might be worthwhile if the benefits of such action are viewed as exceeding the problems it can cause. The critical issue for incident response in this environment is having a incident response (IR) plan. While having a dedicated IR team is probably impractical, having a plan will take the company a long way toward avoiding common incident problems such as panic, denial, confusion, destruction of evidence and shifting blame among individuals within the company. It makes sense to have 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 launch a response by contacting the right people.

Overall, the security process for small and midsize companies should focus on surviving an attack as opposed to fighting back, on speedy recovery and on inexpensive prevention. Responding to a major incident would probably involve outside consultants if the cost of a detailed investigation can be justified. Going after the attacker is unlikely.

In Part 3, we'll take a close look at security response at the large company.


Copyright © 2002 IDG Communications, Inc.

7 inconvenient truths about the hybrid work trend
Shop Tech Products at Amazon