Why You Need to Conduct Risk Assessment

This chapter is from the book

Inside Network Security Assessment: Guarding Your IT Infrastructure

Learn More Buy

This chapter is from the book

This chapter is from the book 

Inside Network Security Assessment: Guarding Your IT Infrastructure

Learn More Buy

With industry compliancy and information security laws and mandates being introduced in the past four years, the need for conducting a vulnerability and risk assessment is now paramount. These recent laws and mandates include the following:

• The Healthcare Information Privacy and Portability Act (HIPPA) is driving the need for vulnerability and risk assessments to be conducted within any health-care or health-care-related institution.
• The recent Gramm-Leach-Bliley Act (GLBA) is driving the need for vulnerability and risk assessments to be conducted within any banking or financial institution in the United States.
• The recent Federal Information Security Management Act (FISMA) is driving the need for vulnerability and risk assessments to be conducted for all United States federal government agencies.
• The recent Sarbanes-Oxley Act affects all publicly traded companies within the United States that have a market cap greater than $75 million; they are now subject to compliance with the Sarbanes-Oxley Act, Section 404, which also is driving the need for vulnerability and risk assessments to be conducted for publicly traded companies.
• The recent Canadian Management of Information Security Standard (MITS) requires regular security assessments for all Canadian federal government agencies.

The need to conduct vulnerability and risk assessments is being driven by these new laws and mandates. Organizations must now be information security conscious and must develop and implement proper security controls based on the results of their internal risk assessment and vulnerability assessment. By conducting a risk assessment and vulnerability assessment, an organization can uncover known weaknesses and vulnerabilities in its existing IT infrastructure, prioritize the impact of these vulnerabilities based on the value and importance of affected IT and data assets, and then implement the proper security controls and security countermeasures to mitigate those identified weaknesses. This risk mitigation results in increased security and less probability of a threat or vulnerability impacting an organization’s production environment.

Risk Terminology

With any new technology topic, terminology, semantics, and the use of terms within the context of the technology topic can be confusing, misused, and misrepresented. Risk itself encompasses the following three major areas: risks, threats, and vulnerabilities.

Risk is the probability or likelihood of the occurrence or realization of a threat. There are three basic elements of risk from an IT infrastructure perspective:

• Asset—An IT infrastructure component or an item of value to an organization, such as data assets.
• Threat—Any circumstance that could potentially cause loss or damage to an IT infrastructure asset.
• Vulnerability—A weakness in the IT infrastructure or IT components that may be exploited in order for a threat to destroy, damage, or compromise an IT asset.

An IT asset or data asset is an item or collection of items that has a quantitative or qualitative value to an organization. Examples of IT assets that organizations may put a dollar value or criticality value on include the following:

• Workstations—Hardware, software, and data assets stored at the end user’s workstation location (PCs, PDAs, phones, and so on).
• Operating systems software—Operating system software, software updates, software patches, and their configuration and deployment on production services and workstations.
• Application systems software—Application software such as databases, client/server applications, software updates, software patches, and their configuration on production servers.
• Local area network hardware and software—Local area network infrastructure, TCP/IP, LAN switches, routers, hubs, operating system and application software within the LAN CPE equipment.
• Wide area network hardware and software—Wide area network infrastructure, TCP/IP, routers, operating system and application software within the WAN CPE equipment.
• Network management hardware and software—SNMP network management infrastructure, operating system and NMS application software, production NMS servers, data collection SNMP polling servers, network-monitoring CPE devices, SNMP MIB I and MIB II data collection and archiving.
• Telecommunication systems—Voice communication systems (PBX or IP Telephony), telephone CPE devices on desktops, operating system and application software (IP Telephony), voice-mail systems, automated attendants, and so on.
• IT security hardware and software—Operating system and security application software, production servers, DMZs, firewalls, intrusion detection monitoring systems, security monitoring, and alarm notification systems.
• Systems and application servers, hardware, and software—Operating systems, application software, client/server application software, production servers, and software code/intellectual property.
• Intellectual property—Customer data, customer databases, application data, application databases, information, and data assets. Intellectual property may have an intrinsic value to an organization depending on what the intellectual property is and whether the organization generates revenue from this intellectual property.
• IT infrastructure documentation, configurations, and backup files and backup data—Complete and accurate physical, logical, configuration, and setup documentation of the entire IT infrastructure, including backup files, backup data, disk storage units, and data archiving systems.

A threat is any agent, condition, or circumstance that could potentially cause harm, loss, damage, or compromise to an IT asset or data asset. From an IT infrastructure perspective, threats may be categorized as circumstances that can affect the confidentiality, integrity, or availability of the IT asset or data asset in terms of destruction, disclosure, modification, corruption of data, or denial of service. Examples of threats in an IT infrastructure environment include the following:

• Unauthorized access—The owner of the access rights, user ids, and passwords to the organization’s IT systems and confidential information is compromised, and unauthorized access is granted to the unauthorized user who obtained the user ids and passwords.
• Stolen/lost/damaged/modified data—Loss or damage of an organization’s data can be a critical threat if there are no backups or external archiving of the data as part of the organization’s data recovery and business continuity plan. Also, if the data was of a confidential nature and is compromised, this can also be a critical threat to the organization, depending on the potential damage that can arise from this compromise.
• Disclosure of confidential information—Disclosure of confidential information can be a critical threat to an organization if that disclosure causes loss of revenue, potential liabilities, or provides a competitive advantage to an adversary.
• Hacker attacks—Unauthorized perpetrator who purposely and knowingly attacks an IT infrastructure and/or the components, systems, and data.
• Cyber terrorism—Because of the vulnerabilities that are commonplace in operating systems, software, and IT infrastructures, terrorists are now using computers, Internet communications, and tools to perpetrate critical national infrastructures such as water, electric, and gas plants, oil and gasoline refineries, nuclear power plants, waste management plants, and so on.
• Viruses and malware—Malware is short for malicious software, which is a general term used to categorize software such as a virus, worm, or Trojan horse that is developed to damage or destroy a system or data. Viruses are executable programs that replicate and attach to and infect other executable objects. Some viruses also perform destructive or discrete activities (payload) after replication and infection is accomplished.
• Denial of service or distributed denial of service attacks—An attack on a TCP/IP-based network that is designed to bring the network and/or access to a particular TCP/IP host/server to its knees by flooding it with useless traffic. Many DoS attacks, such as the Ping of Death and Teardrop attacks, exploit limitations in the TCP/IP protocols. For all known DoS attacks, system administrators can install software fixes to limit the damage caused by the attacks. But, like viruses, new DoS attacks are constantly being dreamed up by hackers.
• Acts of God, weather, or catastrophic damage—Hurricanes, storms, weather outages, fires, floods, earthquakes, and total loss of IT infrastructures, data centers, systems, and data.

A vulnerability is a weakness in the system design, a weakness in the implementation of an operational procedure, or a weakness in how the software or code was developed (for example, bugs, back doors, vulnerabilities in code, and so on). Vulnerabilities may be eliminated or reduced by the correct implementation of safeguards and security countermeasures.

Vulnerabilities and weaknesses are common with software mainly because there isn’t any software or code in existence that doesn’t have bugs, weaknesses, or vulnerabilities. Many vulnerabilities are derived from the various kinds of software that is commonplace within the IT infrastructure. This type of software includes the following:

• Firmware—Software that is usually stored in ROM and loaded during system power up.
• Operating system—The operating system software that is loaded in workstations and servers.
• Configuration files—The configuration file and configuration setup for the device.
• Application software—The application or executable file *.exe that is run on a workstation or server.
• Software Patch—A small piece of software or code snippet that the vendor or developer of the software typically releases as software updates, software maintenance, and known software vulnerabilities or weaknesses.

Herein lies the fundamental problem—software has vulnerabilities, hackers and perpetrators know there are vulnerabilities, and organizations attempt to put the proper software patches and updates in place to combat this fundamental problem before being attacked. The key word here is before being attacked. Many organizations lack sufficient funds for securing their IT infrastructure by mandating a vulnerability window of 0 days or 0 hours, thus eliminating any software vulnerability potential threats. Achieving a vulnerability window of 0 days or 0 hours is virtually impossible given that software vendors cannot provide software patches fast enough to the general public after a vulnerability is exposed. In addition, the time required to deploy and install the software patch on production servers and workstations exposes an organization’s IT infrastructure to potential threats from that vulnerability.

This gap in time is reality in IT infrastructures, especially because a majority of IT assets and devices have some kind of software loaded in them. Remember, vulnerabilities in software extend to firmware, operating systems, configuration files, and applications, and must be combated with a software maintenance, update, and patch maintenance plan. This encompasses the entire software, operating, and application software environment exposing potential vulnerabilities in any device that houses and runs this vulnerable software. In large organizations, combating the software vulnerability issue requires an enterprise, automated software patch-management solution.

The Computer Emergency Response Team (CERT) is an organization sponsored by Carnegie-Mellon University’s Software Engineering Institute. Until 2003, CERT was the organizational body that was responsible for collecting, tracking, and monitoring vulnerability and incident reporting statistics. CERT can be found at http://www.cert.org. CERT publishes statistics for the following:

• Vulnerabilities Reported—This compilation is for vulnerabilities reported, not those that go unreported.
• Vulnerability Notes Published—These notes are published by CERT from data that is compiled from users and the vendor community describing known and documented vulnerabilities.
• National Cyber Alert System Documents Published—Information previously published in CERT advisories, incident notes, and summaries are now incorporated into National Cyber Alert System documents.
• Security Alerts Published—The total number of validated security alerts published by CERT.
• Mail Messages Handled—The total number of email messages handled by CERT.
• Hotline Calls Received—The total number of phone calls handled by CERT.
• Incidents Reported—Given the widespread use and availability of automated attack tools, attacks against Internet-connected organizations are common given the number of incidents reported.

As of 2004, CERT no longer publishes the number of incidents reported. Instead, CERT is working with others in the community to develop and report on more meaningful metrics for incident reporting, such as the 2004 E-Crime Watch Survey. Figure 3.1 shows the dramatic increase in known and documented vulnerabilities and the number of incidents that have occurred and have been recorded by http://www.cert.org during the past few years. Note that as the number of vulnerabilities increases, the number of incidents has also increased, but this value is misleading because the number of incidents that go unreported is unknown.

Figure 3.1 Rise in vulnerabilities and incidents.

Many of the security incidents indicated in 2003 on the http://www.cert.org website were the direct result of software vulnerabilities that were exploited by an attacker. These security incidents can be attributed to the "vulnerability window," which is the amount of time that lapses between when a known vulnerability is identified and documented to when an organization implements the vulnerability fix or deploys the appropriate software patch.

Because of this vulnerability window issue, SQL Slammer, which was a known vulnerability posted by Microsoft in July 2002, affected nearly 90% of the world’s SQL databases on Super Bowl Sunday, January 2003, six months after the vulnerability was exposed.

The stages of vulnerability in software are as follows:

1. Vendors release software and code with unknown vulnerabilities to the general public.
2. Vulnerability is discovered, communicated, documented, and published by the vendor. When the vulnerability is identified and communicated to the general public, this defines when the vulnerability window is open. This is referred to as VTopen.
3. A configuration-based software countermeasure (software patch) is created by the vendor and made available to the public.
4. The software patch is released and made available to the public.
5. The software patch is received, deployed, and installed on the affected devices. When the software patch is deployed and installed on the affected device, this defines when the vulnerability window is closed. This is referred to as VTclosed.

In Figure 3.2, the stages in vulnerabilities in software are defined. This gap in time between when a known vulnerability is identified and communicated to when that known vulnerability is mitigated through a software patch is referred to as the vulnerability window.

Figure 3.2 The vulnerability window.

From a vulnerability perspective, an IT asset or IT infrastructure is most vulnerable during the vulnerability window exposure time. This exposure time is referred to as vulnerability time:

Vulnerable Time (Vt) = Vt(open) - Vt(closed)

Most organizations, when they first conduct a vulnerability assessment on their IT infrastructure, servers, workstations, and systems, are shocked to realize that they are vulnerable because of software vulnerabilities inherent in the code. Upon realizing this, the ultimate goal for an organization is to prioritize those IT assets and IT infrastructure components to assess which IT assets should have their vulnerability time reduced. Reducing the vulnerability time will assist organizations in minimizing the potential risk and threats caused by software vulnerabilities. Many organizations create internal policies that state the maximum vulnerability time exposure for their mission critical IT assets and systems.

Organizations are now realizing that having an IT security architecture and framework consisting of policies, standards, procedures, and guidelines for their production IT systems, software, and applications is critical. Many organizations are apt to create a policy that defines the maximum acceptable vulnerability window for its mission-critical and production IT systems. This policy then drives the priorities for how funds are to be invested for risk mitigation via an enterprise patch-management solution.

Software vulnerabilities are documented and tracked by the U.S. Computer Emergency Readiness Team (US-CERT) in a public-accessible list called the Common Vulnerabilities and Exposures (CVEs) list. In 1999, the MITRE organization was contracted by the U.S. Computer Emergency Readiness Team to track, monitor, and update the CVE list. Today, the CVE list has grown to more than 7,000 unique documented vulnerability items, and approximately 100 new candidate names are added to the CVE list each month, based on newly discovered vulnerabilities. The CVE list can be found at http://www.cve.mitre.org/.

The CVE is merely a list or dictionary of publicly known information security vulnerabilities and exposures and is international in scope and free for public use. Each vulnerability or exposure included on the CVE list has one common, standardized CVE name. The CVE list is a community effort that encourages the support of hardware and software vendors. The CVE list is free and can be downloaded or accessed online at the previously mentioned website.

Prior to conducting an internal risk assessment, it is important to understand the new laws, mandates, and regulations that are driving organizations to create and implement information systems security plans and conduct vulnerability assessments. These new laws, mandates, and regulations are impacting IT infrastructures and their assets and are driving the need for conducting a thorough risk and vulnerability assessment on an IT infrastructure and its assets.