|
|
| Line 27: |
Line 27: |
| | | | |
| | </div></div> | | </div></div> |
| − | {{TOCright}} | + | {{Delete|reason=Expired Content}} |
| − | | |
| − | | |
| − | == Overview ==
| |
| − | Organizations typically have little control over threats, such as floods, hackers, and disgruntled employees. They will occur. However, organizations can reduce the impact of these threats by controlling and mitigating vulnerabilities in their systems, thereby reducing risk. Management of system vulnerabilities is a critical component of the overall risk management process.
| |
| − | [[File:System Risk.PNG|left|thumb|268x268px|System Risk]]
| |
| − | A number of recent cyber attacks have exploited vulnerabilities in government IT management capabilities to exfiltrated sensitive information. These include the Canadian National Research Council (NRC) data breach in 2014 and the loss of personnel data by the US Office of Personnel Management (OPM) in April 2015. These attacks, together with those on commercial businesses (e.g. Target in 2013), have motivated the GC to assess and improve its management of vulnerabilities. These improvement encompass the people, processes, and technical aspects of vulnerability management.
| |
| − | | |
| − | [https://www.ncsc.gov/nittf/docs/CNSSI-4009_National_Information_Assurance.pdf CNSSI 4009] defines vulnerability as a "weakness in an information system, system security procedures, internal controls, or implementation that could be exploited by a threat source." Similarly, [https://www.publicsafety.gc.ca/cnt/rsrcs/cybr-ctr/2015/tr15-004-eng.aspx Public Safety Canada's Top 30 Targeted High Risk Vulnerabilities] defines vulnerabilities as "flaws or weaknesses in computer software that could allow a malicious actor to compromise the integrity, availability, or confidentiality of a system or network."
| |
| − | | |
| − | A threat source is defined by [https://www.ncsc.gov/nittf/docs/CNSSI-4009_National_Information_Assurance.pdf CNSSI 4009] as "the intent and method targeted at the intentional exploitation of a vulnerability or a situation and method that may accidentally exploit a vulnerability."
| |
| − | | |
| − | Together, the risk to any system is that a threat will exploit a vulnerability as represented in the image on the left. The purpose of Vulnerability Management is to mitigate that risk.
| |
| − | | |
| − | <br>
| |
| − | | |
| − | == Vulnerability Management - What It Is and What It Is Not ==
| |
| − | Vulnerability management is more than simply patch management. The SANS report "Implementing a Vulnerability Management Process" says: <blockquote>''"Vulnerability management is the process in which vulnerabilities in IT are identified and the risks of these vulnerabilities are evaluated. This evaluation leads to correcting the vulnerabilities and removing the risk or a formal risk acceptance by the management of an organization. The term vulnerability management is often confused with vulnerability scanning. Despite the fact that both are related, there is an important different between the two. Vulnerability scanning consists of using a computer program to identify vulnerabilities in networks, computer infrastructure, or applications. Vulnerability management is the process surrounding vulnerability scanning, also taking into account other aspects, such as risk acceptance, remediation, etc."''</blockquote>Vulnerability management is not a process of identifying previously unknown vulnerabilities. It is a process of mitigating the risk of known vulnerabilities. Vulnerabilities may be known to the GC enterprise via several sources. External government or partner threat and vulnerability repositories may provide vulnerability information. Another source is penetration testing actively performed against the GC enterprise to discover vulnerabilities. Neither of these methods is considered part of vulnerability management, they simply feed new vulnerability information into the vulnerability management process for the GC enterprise.
| |
| − | | |
| − | Similarly, incident management is not a part of vulnerability management. An incident occurs when a threat source ''exploits'' a vulnerability, requiring recovery steps, such as forensic and causal analysis, containment, and eradication, and followed by restoration to normal operations. Post-event analysis of the incident may identify unknown vulnerabilities that were exploited. As with the previous methods, this introduces another source of newly identified vulnerabilities into the vulnerability management process for the GC enterprise.
| |
| − | | |
| − | === ''Vulnerability Management Mitigates Risk'' ===
| |
| − | [[File:Risk Management Process Applied Across the Tiers.PNG|thumb|555x555px|Risk Management Process Applied Across the Tiers]]
| |
| − | As stated in [http://www.iparchitects.com/wp-content/uploads/Key-Elements-of-a-Threat-and-Vulnerability-Management-Program-ISACA-Member-Journal-May-2006.pdf Key Elements of a Threat and Vulnerability Management Program], "Vulnerability management uses the input from the threat and vulnerability analysis to mitigate the risk that has been posed by the identified threats and vulnerabilities." Vulnerability management is a continuous process based on the risk management process described in the [[Media:GC ESA Description Document (ESADD) - ANNEX D OPS.pdf|GC ESA Description Document Annex D: Security Operations]] document and shown in the image on the right, which is applicable to the entire GC enterprise. Tier one provides the organizational governance and policies that drive vulnerability management. Tier two provides the mission and business processes coordinating the efforts across the GC enterprise enabling a consistent and cohesive vulnerability management process at the information system in tier three, with support from higher tiers as plans and decisions are required.
| |
| − | | |
| − | ''Mitigation'' of risk (i.e. reducing the risk) is one of five risk response choices identified in the risk management process. The risk may also be simply ''accepted'' as is, ''avoided'' by removing the conditions or functions which introduce the risk (which may remove desirable functionality), ''shared'' with or ''transferred'' to another organization. ''Mitigation'' includes options, such as remediation (e.g. software patches or configuration changes) to remove the vulnerability or re-configuring/re-architecting or policy/procedure changes to reduce or eliminate the ability for the vulnerability to be exploited. Vulnerability management strives for a ''mitigation'' response choice, if available and depending on the risk, rather than one of the other four.
| |
| − | | |
| − | The desired vulnerability management process includes the identification of existing vulnerabilities within the enterprise and the associated risk remediation responses. Vulnerabilities may exist in software, hardware, firmware, or policies/procedures. Remediation provided directly by the vulnerability management process is typically realized via vulnerability management tools (e.g. software patches, upgrades or configuration changes), especially for software vulnerabilities (typically the largest proportion of vulnerabilities). Other mitigation efforts may require physical changes to the system architecture or hardware components, manual firmware changes or policy/procedure changes, all of which are performed manually (the design of these mitigations is outside the scope of vulnerability management). Verification of the chosen response process includes methods, such as scanning, penetration testing, architectural review or verification that tools and processes are in place to support a policy. In doing so, Vulnerability Management includes the capability to address all known vulnerabilities via both manual and automated mechanisms.
| |
| − | | |
| − | === ''Vulnerability Management Maturity'' ===
| |
| − | Security vendor Core Security has defined a Threat and Vulnerability Management Maturity Model (TVMMM) based on the Carnegie Mellon Maturity (CMM) model methodology, as shown in the image below. They characterize the "risk of breach as inverse to the maturity of a Threat and Vulnerability Management (TVM) program."
| |
| − | | |
| − | As it stands today, the maturity of patch and vulnerability management practices varies across the GC. While some organizations have some level of automation in place, the discovery of vulnerabilities and verification of patch installation is too often performed on an ad hoc basis. The focus is on software-oriented vulnerabilities. Very few organizations can quickly identify known vulnerabilities on their respective networks, promptly apply patches, or accurately report on patch installation status, all of which put the GC enterprise at risk. This assessment places the GC systems in the range from Level 0 to Level 2 on the TVMMM shown in the image below.
| |
| − | | |
| − | The goal of this initiative is to define a target that will improve the maturity of the GC's vulnerability management capability across the enterprise ultimately reaching Level 5 on the TVMMM. Several sources of threat and vulnerabilities intelligence are available - these include [https://www.sans.org/security-resources/IAD_top_10_info_assurance_mitigations.pdf NSA Top 10], [https://www.sans.org/critical-security-controls/ CIS Top 20], and the [https://www.cse-cst.gc.ca/en/node/1297/html/25231 CSE Top 10] that identifies the top 10 mitigation efforts for GC systems. Not surprisingly, the #4 action in the CIS Top 20 is to implement Continuous Vulnerability Assessment and Remediation, while #2 action in the CSE Top 10 is to implement a timely Patch Management system, a major component of vulnerability assessment and mitigation, though focused on software vulnerabilities. While patch management (within 48 hours for critical issues) addresses two of the "[http://www.infosecisland.com/blogview/23581-The-First-Five-Quick-Wins.html First Five Quick Wins]" from CIS Top 20, Vulnerability Management is more than simply patching software.
| |
| − | | |
| − | <br>
| |
| − | | |
| − | [[File:Threat and Vulnerability Management Maturity Model (Core Security).PNG|centre|thumb|1016x1016px|Threat and Vulnerability Management Maturity Model (Core Security)]]
| |
| − | | |
| − | <br>
| |
| − | | |
| − | === ''Scope of Vulnerability Management'' ===
| |
| − | This initiative addresses the definition of Vulnerability Management within the GC enterprise. It presumes the previous identification of known vulnerabilities to the GC enterprise through several methods, some of which are described in the [[Media:GC ESA ConOps - ANNEX E GC Enterprise VMS.pdf|GC ESA ConOps Annex E: Vulnerability Management System]] document. The scope consists of determining if the known vulnerabilities exist within the GC enterprise, deciding how to respond to the vulnerability, implementing the response, and determining if the vulnerability was removed. Vulnerabilities may exist in software, hardware, firmware or policies/procedures. Along with applicable plans, procedures, reports and metrics, this constitutes the scope of the Vulnerability Management initiative.
| |
| − | | |
| − | <br>
| |
| − | | |
| − | For more information about what a vulnerability management is and is not, please read the [[Media:GC ESA ConOps - ANNEX E GC Enterprise VMS.pdf|GC ESA ConOps Annex E: Vulnerability Management System]] document.
| |
| − | | |
| − | <br>
| |
| − | | |
| − | == Roles and Responsibilities ==
| |
| − | A number of federal departments and agencies have been mandated to transfer operation and management of selected IT/IS resources to a GC Enterprise Service Provider. In general, management of vulnerabilities is the responsibility of the Service Provider owning the particular asset. Because some hosted applications require specialized knowledge to install and configure, management responsibility may be divided between the GC Enterprise Service Provider and the department/agency. Departments and agencies not affected by the mandate may delegate selected responsibilities to the GC Enterprise Service Provider through negotiation of a service agreement.
| |
| − | | |
| − | <br>
| |
| − | | |
| − | For more information about roles and responsibilities for a vulnerability management system, please read the [[Media:GC ESA ConOps - ANNEX E GC Enterprise VMS.pdf|GC ESA ConOps Annex E: Vulnerability Management System]] document.
| |
| − | | |
| − | <br>
| |
| − | | |
| − | == Operational Needs ==
| |
| − | The operational needs are divided into People and Process objectives and Technology objectives. The People and Process objectives identify current best practices that should already be in use, but it may be necessary to develop policy instruments and awareness training to reinforce the need to follow these practices. The Technology objectives are forward-looking and are likely to require planning and investment to achieve over a period of time. Technology works in conjunction with operational procedures (people and processes) to protect GC IT/IS resources. Operational procedures ensure that the technology is operated and maintained in a secure operational state and performs its mission. Therefore, it is critical from a security standpoint that the people and processes are given equal consideration to the technology implementation.
| |
| − | | |
| − | === ''People and Process Objectives'' ===
| |
| − | Development of new policy instruments or update of existing policy instruments that address:
| |
| − | * Risk assessment process
| |
| − | * Division of enterprise and departmental responsibilities for vulnerability management of shared resources
| |
| − | * Reporting hierarchy
| |
| − | * Testing to mitigation efforts prior to introduction into production networks
| |
| − | * Clear organizational assignment of role/responsibilities for managing vulnerabilities across the GC enterprise
| |
| − | | |
| − | === ''Technology Objectives'' ===
| |
| − | Development of new technologies or update of existing technologies and associated designs that address:
| |
| − | * Compatible configuration and asset management tools across the enterprise
| |
| − | * Compatible vulnerability and patch management tools across the enterprise
| |
| − | * Anomaly detection tools
| |
| − | | |
| − | <br>
| |
| − | | |
| − | For more information about the people & process and technology objectives and for a table summarizing operational needs for a vulnerability management system, please read the [[Media:GC ESA ConOps - ANNEX E GC Enterprise VMS.pdf|GC ESA ConOps Annex E: Vulnerability Management System]] document.
| |
| − | | |
| − | <br>
| |
| − | | |
| − | == Assumptions and Constraints ==
| |
| − | The following assumptions and constraints are used in the [[Media:GC ESA ConOps - ANNEX E GC Enterprise VMS.pdf|GC ESA ConOps Annex E: Vulnerability Management System]] document:
| |
| − | | |
| − | === ''Assumptions'' ===
| |
| − | # Management of vulnerabilities is the responsibility of the owner of each asset
| |
| − | # Asset and Configuration Management capabilities are in place since they are the foundation upon which vulnerability management is based
| |
| − | | |
| − | === ''Constraints'' ===
| |
| − | # The proposed solution must balance security, cost, and usability
| |
| − | # Departments must retain responsibility for owned assets
| |
| − | # Legacy tools may exist and will require incremental development of interfaces to new tools
| |
| − | | |
| − | <br>
| |
| − | | |
| − | For more information, please read the [[Media:GC ESA ConOps - ANNEX E GC Enterprise VMS.pdf|GC ESA ConOps Annex E: Vulnerability Management System]] document.
| |
| − | | |
| − | <br>
| |
| − | | |
| − | == Security Considerations ==
| |
| − | This section identifies People, Process, and Technology factors that need to be considered when introducing Vulnerability Management to the GC enterprise.
| |
| − | | |
| − | === ''People and Process Considerations'' ===
| |
| − | The introduction of Vulnerability Management requires consideration of non-technical policy instruments and operating procedures to support successful implementation across the enterprise. These areas include:
| |
| − | * '''''Creation of policy instruments that specifically address vulnerability management'''''
| |
| − | ** Mandate implementation of a formal vulnerability reporting and mitigation program
| |
| − | ** Roles and responsibilities:
| |
| − | *** External identification of vulnerabilities (e.g. US-CERT, vendors, security research companies, and labs)
| |
| − | *** Internal research and identification of new vulnerabilities (GC-CIRT)
| |
| − | *** Vulnerability scanning and penetration testing
| |
| − | *** Reporting of anomalies
| |
| − | *** Departmental resources (all aspects of the resource managed by the same department)
| |
| − | *** Shared resources
| |
| − | **** SSC-managed server running department-managed applications
| |
| − | ** Consequences of non-compliance and false reporting by departments
| |
| − | ** Public cloud provider vulnerability management
| |
| − | * '''''Creation of a formal vulnerability reporting and mitigation program'''''
| |
| − | ** Categorization of identified vulnerabilities by severity (risk)
| |
| − | ** Communication of identified vulnerabilities
| |
| − | *** Currently published by Government of Canada Computer Inciendent Response Team (GC-CIRT) (internally) and Public Safety Canada Canandian Cyber Incident Response Centre (CCIRC) (externally) in the form of alerts, advisories, information notes, and technical reports.
| |
| − | ** Mitigation requirements and timeframes (according to severity)
| |
| − | ** Reporting of mitigation status by departments
| |
| − | ** Supporting communication mechanisms and tools
| |
| − | * '''''Criticality of Vulnerabilities'''''
| |
| − | ** Vulnerabilities have associated criticalities which will be a factor in scheduling, monitoring to determine whether they exist in the enterprise and if found, their remediation. Risk management must be involved in assessing criticality. Procedure must be developed accordingly.
| |
| − | ** Factors affecting criticality include:
| |
| − | *** Criticality ratings provided by the source of the vulnerability information
| |
| − | *** Factors specific to the GC enterprise or organizational environment and business context, such as identification of Mission Critical Applications. Mission Critical and Essential Applications are defined in the Government of Canada Application Portfolio Management Definitions
| |
| − | *** Current GC enterprise or organizational security posture and connectivity of the environment
| |
| − | | |
| − | === ''Technology Considerations'' ===
| |
| − | The introduction of Vulnerability Management requires consideration of tools and technologies to support successful implementation across the enterprise. While tools are not required to be the same at all organizations, they must be compatible to allow integration. These areas include:
| |
| − | * Information sharing between departments and enterprise
| |
| − | ** Publishing vulnerability information (top-down)
| |
| − | ** Reporting mitigation status (bottom-up)
| |
| − | * Tools for processing vulnerability information
| |
| − | * Tools for automating monitoring capabilities (tools may integrate support for functions other than vulnerability management)
| |
| − | * Tools for automating vulnerability mitigation (e.g. patch management)
| |
| − | * Vulnerability and penetration testing tools
| |
| − | * Integration with existing enterprise services, such as asset and configuration management
| |
| − | * Often, tools combine the ability to scan for multiple characteristics/reasons during a single pass, such as for vulnerabilities, diagnostics, or configuration management. Performance efficiencies can be gained by combining these capabilities into a single toolset where possible. Care should be taken when implementing the various initiatives to utilize this shared capability to enable efficiencies and improve effectiveness within the enterprise.
| |
| − | | |
| − | <br>
| |
| − | | |
| − | For more information, please read the [[Media:GC ESA ConOps - ANNEX E GC Enterprise VMS.pdf|GC ESA ConOps Annex E: Vulnerability Management System]] document.
| |
| − | | |
| − | <br>
| |
| − | | |
| − | == References ==
| |
| − | * [[Media:GC ESA ConOps - ANNEX E GC Enterprise VMS.pdf|GC ESA ConOps Annex E: Vulnerability Management System]]
| |
| − | * [[Media:GC ESA Description Document (ESADD) - ANNEX D OPS.pdf|GC ESA Description Document Annex D: Security Operations]]
| |
| − | * [https://www.sans.org/critical-security-controls/ Center for Internet Security's Top 20]
| |
| − | * [https://www.sans.org/security-resources/IAD_top_10_info_assurance_mitigations.pdf National Security Agency's Top 10]
| |
| − | * [https://www.cse-cst.gc.ca/en/node/1297/html/25231 CSE Top 10 IT Security Actions to Protect the GC]
| |
| − | * [https://www.publicsafety.gc.ca/cnt/rsrcs/cybr-ctr/2015/tr15-004-eng.aspx Public Safety Canada's Top 30 Targeted High Risk Vulnerabilities]
| |
| − | * [http://www.iparchitects.com/wp-content/uploads/Key-Elements-of-a-Threat-and-Vulnerability-Management-Program-ISACA-Member-Journal-May-2006.pdf Key Elements of a Threat and Vulnerability Management Program]
| |
| − | * [http://www.infosecisland.com/blogview/23581-The-First-Five-Quick-Wins.html First Five Quick Wins]
| |
| − | * [https://www.ncsc.gov/nittf/docs/CNSSI-4009_National_Information_Assurance.pdf CNSSI 4009]
| |
| − | | |
| − | [[Category:Government of Canada Enterprise Security Architecture (ESA) Program]]
| |
| − | [[Category:Enterprise Security Architecture]]
| |
