"It is impossible for ideas to compete in the marketplace if no forum for
  their presentation is provided or available."           Thomas Mann, 1896

---

Process Before Technology 

Author: Joe Cupano
Contributed by Solsoft, Inc. 

There has been much criticism over the value of Intrusion Detection (IDS) since Gartner's report on the subject last summer. Much of the criticism has focused on management overhead in tuning these systems to yield valuable data, with some recommending Intrusion Protection Systems (IPS) as alternative technology people should gravitate to. Reciprocally, there have been many who praise IDS systems as integral tools in their overall perimeter security solutions. Which school of thought is one to follow?

The value of these technologies is in how effective and efficient they are in the processes they serve in the overall network security policy. But for many organizations the adoption of IDS technology equated the process, namely their "Incident management and response" process within their network security policy. In this situation the "incident management and response process" is a technology silo with business processes built to accommodate the technology. In the end, organizations that followed this path found their "incident management and response process" was heavily invested in detection and correlation but little in remediation and reporting. Yes, we are being attacked but what are we going to do about it and how?

When viewed as a lifecycle, "incident management and response" consists of detection, correlation, notification, remediation and reporting as component processes. IDS would be a primary tool in detection and correlation whose output is integrated into existing IT systems that can provision notification, remediation and reporting. Existing management and monitoring tools can support remediation and correlation processes respectively. Remediation processes may include controls such as disabling Internet access (less business partner VPNs); activating desktop management systems to push out virus signature updates; scheduling automated patch upgrades to desktop operating systems and applications under management; and re-enabling general Internet access with threat signature filtering on perimeter security infrastructure. Though many of these remediation processes may appear "low tech" as compared to some of the emerging technologies out there, they are existing, tangible, and perhaps less complicated processes (k.i.s.s.) to be leveraged where a 70% solution is better than what you have today.

Processes within policy management include a) policy creation and b) translation of the policy to language native to tools or other sub-processes that provide control (enforcement) across the network. Technical implementations include the management of firewall rules and router ACLs across the enterprise. Process control points include procedures for handling new business service requests (e.g., 3rd-party connectivity) that may include risk verification - and whether the requests can be facilitated by existing controls, require no controls, or need policy exception approval.

Compliancy measures the effectiveness of the policy with deltas quantified for any remediation that may be required. Technical implementations include centralized logging for correlation, IDS, SIM/SEM, and vulnerability assessment tools. Process points include traditional audit activities or security risk verification events within an organization. It should be noted that many of these tools are also utilized in other points of the lifecycle, namely remediation and reporting.

As mentioned before, remediation may include leveraging your existing systems management processes and making them more robust. There may be alignment in process needs between security remediation and business contingency planning (BCP) processes in your organization.

Reporting may be at multiple levels that range from operations center (NOC/SOC) up to senior management. Each level may reference a different set of metrics that are relevant to the level being reported to. As quantitative and qualitative as various tools may be in providing security reporting, the final format and metrics reported at the senior management level need to be business-aligned (e.g., service-level agreements in incident management and response). The output of any reporting may dictate adjustments in the network security policy - thus the cycle.

A network security policies implementation should not be driven (or limited) by the technology utilized. A lifecycle of processes and procedures should be defined, with technology leveraged as a potential tool in their implementation - with a proper mix of process and technology assuring a scalable solution. IDS and IPS systems are both good technologies, but like any technology, their value is relative to how effective and efficient they are as tools in enabling the processes they serve in the overall network security policy.

About the Author 

Joe Cupano, Technology Director for Solsoft, Inc. has been an information security professional for nearly ten years working in global financial services and "Big 4" consulting firms that include Salomon Smith Barney and Ernst & Young. In that time, he has developed and executed cost-effective, business-enabling security strategies that focus on delivery of security solutions as transparent value added components within larger IT services driving business alignment. Most recently, Mr. Cupano was a Director in the UBS Investment Banking Information Technology department and served as the global technology manager for security and e-commerce.