The International Standards Organization (ISO) defines a vulnerability as “A weakness of an asset or group of assets that can be exploited by one or more threats.” Therefore, the essence of an effective information security program is based on the avoidance or the mitigation of vulnerabilities in systems and applications.
An information technology (IT) program for any business typically starts out on a clean footing. New servers are built from the ground up with up to date operating systems, middleware components, and databases, etc. The applications that reside on this stack are either purchased off the shelf or built in house.
As time passes, weaknesses or vulnerabilities are either discovered in the underlying code or arise as a result of interdependencies or complexities in the environment. If not managed proactively, these weaknesses contribute to an ever-accumulating technology debt.
"It is the responsibility of the security SMEs to triage the vulnerabilities, ensure that there are no false positives, risk rank them, thoroughly understand what is required for remediation and then approach the system or application owners for remediation."
The technology debt accumulates when the life cycle maintenance of the environment is not conducted in a disciplined manner. Missed updates or skipped security patches lead to a system becoming increasingly vulnerable to exploitation by malicious entities. The technology debt also comes into existence as a result of choices that are made along the way by the IT organization. The choices may be driven by business needs to support certain functions or capabilities or may be driven by expediency to deliver on products and services. Such choices lead to complex environments with interdependencies and lack of supportability. By their nature, these environments become vulnerable to compromise or exploitation.
An effective and comprehensive vulnerability management program attempts to introduce discipline in the technology environment so that the technology debt can be mitigated to some extent. “Discipline” is the key word here. A vulnerability management program can only be effective if there is a rigor around the cadence of scanning etc., and the associated remediation.
It is essential to start with a documented standard around scanning and vulnerability management. This standard must have the following components:
I. Clear assignment of the roles and responsibilities of the various teams in the organization. For example, the role of the Information Security team, the role of the Approved Scanning Vendor and the role of the system owners must be clearly delineated
II. The classification criteria for vulnerabilities must be listed. The industry utilizes varying criteria for classification. If an organization is subject to PCI, it may adopt the recommendation of the PCI Council on what constitutes High, Medium and Low vulnerabilities. Alternately, the Common Vulnerability Scoring System (CVSS) can be used as a yardstick. This section should also outline remediation requirements for each category of classification
III. The schedule for scanning must be published and appropriate change windows obtained. The document must outline the frequency and the nature of scans that are to be done. Example, monthly and quarterly external scans utilizing the PCI scanning template, internal quarterly scans of selected segments of the network using the SANS template, external annual penetration testing, etc.
IV. The timelines for remediation must be clearly defined. This is perhaps the most challenging aspect of a vulnerability management program. Often remediation is driven by a compliance mandate such as PCI which requires remediation of findings within each quarter so that a clean scan may be documented for each quarter. Sometimes, remediation is driven by the development team’s schedules, i.e., it has to coincide with when the next code push is going to occur or when the next suitable change window is.
V. Finally, and most importantly, the document should outline the standard around each type of scanning, viz., internal, external, penetration testing, wireless and application static or dynamic testing.
Once a program has been established and the vulnerability scans start occurring, the real work for the security professionals begins. There is always a tendency on the part of most security teams to take the results of the scans and toss them over the fence to their IT colleagues and ask them to review and fix. This approach does not work very well. It is the responsibility of the security SMEs to triage the vulnerabilities, ensure that there are no false positives, risk rank them, thoroughly understand what is required for remediation and then approach the system or application owners for remediation.
A ticketing system is essential for assigning and tracking remediation. Gone are the days when Excel spreadsheets would have to suffice. In fact, ideally, a Governance, Risk, and Compliance (GRC) system such as Lockpath or Archer should be used. This is especially useful when remediation is not possible and compensating controls or a risk exception must be documented.
A vulnerability management program cannot be practiced in isolation by the information security organization. There has to be broad buy-in across the IT and business organizations. Establishment and socialization of procedures for patching, configuration management, and policy compliance is essential. Ensuring that system and application owners are aware of the need to test patches and updates in non-production environments prior to production rollout, is critical.
Remediation of vulnerabilities must be followed by a rescan of the environment to validate that the remediation has been effective and the weakness no longer exists in the system.
A properly implemented vulnerability management program allows an organization to manage its IT risk and its technology debt. Of all the programs that an information security organization must implement and maintain, a vulnerability management program is perhaps the most crucial. Without such a program, an organization is exposed to compromise or a data breach and therefore, it’s very survival could be at stake.