Today's IDS/IPS technologies are highly effective in thwarting attackers. However, part of the recipe for an effective implementation is a proper mix of IDS and IPS sensors strategically located on the enterprise network. Careful consideration is required to determine where each sensor should be placed to provide optimum protection with the smallest possible effect on performance. Moreover, corporate politics can come into play, forcing VARs into diplomatic roles. This true case study addresses both concerns and shows how an effective strategy was developed.
A company we'll call Infield Geophysical Development Corp. (IGDC) is in the business of doing geological and geophysical surveys to determine the value of mineral lease holdings. The privately owned company has grown from 10 engineers and a receptionist serving a handful of small clients to 50 engineers, salespeople and administrative personnel serving a mix of Fortune 1,000 and Fortune 500 clients while remaining loyal to its founding client base.
Though the company has never experienced an intrusion attempt or data breach, management realized that dealing with high-profile clientele would make the company's network more attractive to attackers. A network security consultant was hired to
Each of IGDC's three divisions has its own servers, centrally located in a physically secure area of its office building. Each division has one data manager whose duties comprise storage, backup and security. Those data managers report to the corporate MIS manager.
Upon initial review, it appeared the best strategy centered on placing four IDS/IPS sensors at various locations. One was to reside at the perimeter to detect and prevent a general penetration attempt, and three others would be placed, respectively, in front of each division's servers to detect and prevent data compromise. This is what the consultant proposed to management.
However, when the consultant presented his proposal to management, they were quick to point out that smaller workgroups within each department had their own subsets of sensitive data. The servers certainly require sensors, but several data entry points in each division are also critical. Some workstations access and store only relatively benign data, but order entry points, job accounting terminals, stations storing survey data and evaluation programs (proprietary software), and the mapping and reporting areas were all sensitive. Installing four sensors would be inadequate; the project would require a minimum of seven. This meant the consultant would have to get managers to agree with having IPS within their operational areas.
Politics of data security
Personnel with access to benign data initially balked at the idea of having HIPS installed on their workstations because they felt nothing on their systems was critical enough to warrant such intrusive security. This is the wrong mindset. Just as auto theft is often a crime of opportunity, so is data theft: Leaving your data ports open and unmonitored on the Internet is like leaving your car unlocked with the keys in the ignition. In reality, these seemingly unimportant areas require the same attention to security as the rest of the network.
Some staff felt monitoring would put restrictions on their use of legitimate research tools on the Web. They feared using host-based intrusion protection systems (HIPS) would result in false positives and cause undue delays in completing their work -- a reasonable assumption, since clearing up any false positives would mean waiting on the in-house IT department to test and approve removal of the access restriction. Additionally, some felt monitoring was a vote of no confidence in their ability to safely use network resources -- another a valid point, since there had been no past network intrusions or data breaches.
The biggest issue raised was the question of accountability: Who would be responsible for dealing with a detected incident and what would the response/mitigation procedure be? Some department managers were concerned their jobs could be at risk if an incident occurred in their area, until the consultant pointed out that data loss -- a much more serious threat to their jobs -- would be prevented by proper IDS/IPS protection.
Resolving IDS/IPS implementation conflict
Since IGDC never experienced an intrusion attempt or data breach on its network, everyone agreed a minimal pilot project would be the best approach.
Initially, four sensors would be installed, the first being a unified threat management (UTM) device with built-in IDS/IPS that would replace the firm's aging hardware firewall at the network perimeter. Additionally, three dedicated HIPS would be installed on each of the divisional servers with custom signatures suitable for the applications and data types in use. This would stop any unauthorized access to the most critical databases.
Divisional managers and the MIS manager would share the monitoring responsibility. Divisional managers would be notified of alerts on their respective servers, while the MIS manager would be notified of alerts at all points. The MIS department would tune and maintain the systems and coordinate with the divisional data managers on an as-needed basis. As MIS gained operational experience, and as managers became comfortable with the system, more points could be monitored if the need arose.
This solution effectively resolved all of the managers' concerns, placing accountability where it should naturally fall and resulting in maximum benefit with minimal ongoing impact to IGDC's operations.
Though this project was a small one, it illustrates the importance of a thorough assessment of the client's risk level and business impact of a proposed IDS/IPS implementation. In this case, the initial proposal was revised when the political considerations surfaced. It is often necessary to compromise in such a situation, but a wise consultant will do so in a way that allows for increasing the scope of the project as the client's risk level changes. Furthermore, small-scale pilot projects are an excellent way to get management to buy into larger implementations; every consultant should use this approach when possible.
About the author
Ken Harthun is a systems engineer at Connective Computing Inc., specializing in network and desktop security for small and medium businesses. He has been working with computers since 1973 and advocating sensible security practices since 1989 when one of his employees infected a company computer with the Stoned virus. He quickly isolated the infected diskette and implemented strict security policies to prevent future infections. Ken is currently working on his first consumer-oriented book on computer security.