|
|
| Line 23: |
Line 23: |
| | | | |
| | |} | | |} |
| − | </div>{{TOCright}} | + | </div> |
| − | | + | {{Delete|reason=Expired Content}} |
| − | == Overview ==
| |
| − | The discipline of vulnerability management is described in the [[Media:GC ESA ConOps - ANNEX E GC Enterprise VMS v0.6.pdf| GC ESA ConOps Annex E: Vulnerability Management System]] document as "a process for identifying vulnerabilities, assessing the risk posed by any identified vulnerabilities, and taking action to reduce or eliminate the risk". The sections below will identify and define the technical capabilities necessary to gather vulnerability information from internal and external sources, identify and report vulnerabilities present in the GC IT/IS infrastructure, and participate in vulnerability remediation activities. Vulnerability management capabilities may also support automated mitigation of vulnerabilities by interacting with other capabilities, such as a configuration management that pushes software updates to endpoints. Technical capabilities that directly mitigate vulnerabilities through the installation of software updates, application of patches, modification of configuration files, updating firewall policy rules, etc. are identified, but as they are not specific to vulnerability management they are not described in detail.
| |
| − | | |
| − | A comprehensive Vulnerability Management system encompasses all aspects of the GC IT/IS infrastructure. The Vulnerability Management system's purpose is to continuously monitor GC IT/IS assets and reduce the attack surface wherever possible. In this respect the Vulnerability Management system supports the cyber resiliency goals of anticipating and withstanding attacks on the GC IT/IS infrastructure. From a security operations (OPS) perspective, the Vulnerability Management system is expected to integrate with supporting security technical capabilities, such as configuration and assets management systems, and inter-operate with other security services, such as identity credential and asset management (ICAM), audit, and evolving enterprise security services in order to support automated OPS work flows and increase situation awareness.
| |
| − | | |
| − | <br>
| |
| − | | |
| − | == Vulnerability Management Concepts and Architecture ==
| |
| − | | |
| − | === ''Vulnerability Process'' ===
| |
| − | When a new vulnerability is identified, the first step is to determine the presence of vulnerable GC IT/IS assets by querying asset and configuration management databases for the presence of vulnerable versions and configuration settings of software, hardware, firmware on GC IT/IS assets. This allows for rapid implementation of mitigation procedures to reduce risk to the GC. However, the information in the asset and configuration management databases may be incomplete and/or out of date. It is therefore necessary to perform routine and ad-hoc scanning to obtain a complete list of vulnerable assets connected to GC networks.
| |
| − | | |
| − | Discover and scanning of assets should be performed at regular intervals. To maximize efficiency and minimize the effect on performance, regular scans should serve multiple purposes including:
| |
| − | * Detecting rogue assets (i.e. assets not registered in asset and configuration management databases)
| |
| − | * Detecting vulnerable versions of installed software and vulnerable configuration settings
| |
| − | * Detecting installations of unauthorized software
| |
| − | * Synchronizing asset and configuration management information such that it accurately reflects the actual state of the GC IT/IS infrastructure
| |
| − | * Verifying compliance with GC standards and regulations by performing compliance scans
| |
| − | When a vulnerability with a high severity level is reported, it may be necessary to perform an ad-hoc query of an asset that is purely focused on detecting that vulnerability. Routine scans are scheduled by a centralized vulnerability management capability. Scans may also be initiated locally when an asset attempts to connect to a GC network (a new asset or an asset that is being powered up). The primary job of a network access control (NAC) capability implemented in a switch or VPN server is to authenticate an endpoint attempting to connect, but it may also be able to verify the integrity of the endpoint and initiate a vulnerability scan. If authentication is successful and no vulnerabilities are found, only then will the NAC device be authorized to enable access to network services.
| |
| − | | |
| − | The table below provides a high level abstraction of the asset types that may contain vulnerabilities and must therefore be considered in a vulnerability management program.
| |
| − | | |
| − | <br>
| |
| − | | |
| − | {| class="wikitable"
| |
| − | | style="background: #000000; color: #ffffff | '''Asset Categories''' || style="background: #000000; color: #ffffff | '''Vulnerability Description'''
| |
| − | |-
| |
| − | | style="background: #777777; color: #ffffff | '''''Software Assets (applications, APIs, application plug-ins, mobile apps, and OSs)'''''
| |
| − | | style="background: #e5e5e5; color: #000000 | Software coding flaws, bugs, and insecure coding practices are all possible sources of vulnerabilities in software. In order to management software vulnerabilities in the production environment, all executable software must be identified and monitored. As an example, the Dynamic Link Libraries within Microsoft's OS provide executables for application services. In order to monitor the executables, a digital signature or hash is required to compare the executable to a good known state. If the digital signatures/hashes do not match, then the executable has been changed from the known desired state. | |
| − | |-
| |
| − | | style="background: #777777; color: #ffffff | '''''Hardware Assets (endpoints, network appliances, storage devices, peripherals, etc.)'''''
| |
| − | | style="background: #e5e5e5; color: #000000 | Any hardware asset that runs code is likely to contain bugs that are exploitable. Hardware exploits contained in firmware or in CPUs are harder to fix and usually require the hardware to be taken offline to perform remediation. In some cases, there is no available patch and compensating controls may be required. An example of a hardware exploit is the BadUSB exploit that exploits the USB firmware with malicious code. Since the host cannot detect the firmware code the exploit bypasses traditional malware detectors and the code is used to exploit the subject host.
| |
| − | |}
| |
| − | | |
| − | === ''Vulnerability Management Actors'' ===
| |
| − | The primary user classes (actors) who are responsible for the operation of a Vulnerability Management solution are represented by:
| |
| − | * '''Security Operator:''' Provides the daily operation support and oversight of the Vulnerability Management operations. Security Operators directly interact with the Vulnerability Management system.
| |
| − | * '''System Administrator:''' Provides oversight of vulnerability management software and hardware components. Responsible for system administration of the vulnerability management solution. The System Administrator may also be responsible for remediation activities, such as the installation of the latest patches to software assets.
| |
| − | * '''Risk Manager:''' Provides risk assessments based on asset criticality, vulnerability scan results, threat/vulnerability information, and internally sources risk information, such as incident reports. Risk assessments may impact scan parameters, scan schedules, and scan rates.
| |
| − | | |
| − | === ''Relationship to the OPS Security Functional Model'' ===
| |
| − | The Vulnerability Management ConOps functional design is based upon the security operations functional model. The image to the below depicts the four lifecycle phases (Plan, Monitor, Assess, and Respond) superimposed on the security operations functional model. The [[Media:GC ESA ConOps - ANNEX E GC Enterprise VMS v0.6.pdf| GC ESA ConOps Annex E: Vulnerability Management System]] document identifies core and supporting functions from the ESA components depicted in the functional model.
| |
| − | | |
| − | <br>
| |
| − | | |
| − | [[File:Vulnerability Management Functional Model.PNG|centre|thumb|711x711px|Vulnerability Management Functional Model]]
| |
| − | | |
| − | For more information about the Vulnerability Management System concepts and architecture, please read the [[Media:GC Enterprise VMS HLD v0.5.pdf|GC ESA Vulnerability Management System High-Level Design]] and the[[Media:GC ESA ConOps - ANNEX E GC Enterprise VMS v0.6.pdf| GC ESA ConOps Annex E: Vulnerability Management System]] documents.
| |
| − | | |
| − | <br>
| |
| − | | |
| − | == Vulnerability Management High Level Design (HLD) ==
| |
| − | The vulnerability management high level design (HLD) objective is to describe a vulnerability management system that provides an integrated and hierarchically-managed vulnerability management capability across the GC enterprise and departments. The HLD describes a vulnerability management system composed of initiative components and interface relationships. Initiative components represent tightly-coupled technical capabilities that expose interfaces for data exchanges. The use of initiative components provides flexibility in deploying technical capabilities at the enterprise or department level while preserving the Report & Inform information sharing hierarchy.
| |
| − | | |
| − | The following sections, which can be expanded by clicking on 'Expand' on the far right, provide Vulnerability Management system design and rationale organized into five sub-sections:
| |
| − | | |
| − | <br>
| |
| − | | |
| − | <div class="toccolours mw-collapsible mw-collapsed" style="width:100%">
| |
| − | '''VM System Context''' <div class="mw-collapsible-content">
| |
| − | ---- {{:Vulnerability Management System Context}} </div></div>
| |
| − | <div class="toccolours mw-collapsible mw-collapsed" style="width:100%">
| |
| − | '''VM System Functional Design''' <div class="mw-collapsible-content">
| |
| − | ---- {{:Vulnerability Management System Functional Design}} </div></div>
| |
| − | <div class="toccolours mw-collapsible mw-collapsed" style="width:100%">
| |
| − | '''VM System Component Design''' <div class="mw-collapsible-content">
| |
| − | ---- {{:Vulnerability Management System Component Design}} </div></div>
| |
| − | <div class="toccolours mw-collapsible mw-collapsed" style="width:100%">
| |
| − | '''VM System Communications Design''' <div class="mw-collapsible-content">
| |
| − | ---- {{:Vulnerability Management System Communications Design}} </div></div>
| |
| − | <div class="toccolours mw-collapsible mw-collapsed" style="width:100%">
| |
| − | '''VM System Design Collaborations''' <div class="mw-collapsible-content">
| |
| − | ---- {{:Vulnerability Management System Design Collaborations}} </div></div>
| |
| − | <div class="toccolours mw-collapsible mw-collapsed" style="width:100%">
| |
| − | '''VM Communication Patterns''' <div class="mw-collapsible-content">
| |
| − | ---- {{:Vulnerability Management Communication Patterns}} </div></div>
| |
| − | | |
| − | <br>
| |
| − | | |
| − | For more information about the GC ESA Vulnerability Management System High-Level Design, please read the [[Media:GC Enterprise VMS HLD v0.5.pdf|GC ESA Vulnerability Management System High-Level Design]] document.
| |
| − | | |
| − | <br>
| |
| − | | |
| − | == Vulnerability Management System Design Considerations ==
| |
| − | This section summarizes Vulnerability Management HLD design considerations for developing/acquiring a Vulnerability Management System that provides interoperability and extensibility across the GC enterprise and departments. The section below addresses GC integration considerations (GC architecture and assets). Trade study considerations for the Vulnerability Management System can be found in the [[Media:GC Enterprise VMS HLD v0.5.pdf|GC ESA Vulnerability Management System High-Level Design]]. For an overview of the trade study process and suitable selection criteria, please read the [[Media:GC ESA Framework.pdf|GC ESA Framework]] document. Additional information may be found at the following websites:
| |
| − | * [http://www.gsa.gov/portal/mediaId/199735/fileName/CDM_Product_Catalog.action US Department of Homeland Security and General Services Administration]
| |
| − | * [https://www.owasp.org/index.php/Category:Vulnerability_Scanning_Tools Open Web Application Security Project]
| |
| − | | |
| − | === ''Vulnerability Management System Integration Considerations'' ===
| |
| − | This section summarizes GC integration considerations for successfully implementing a Vulnerability Management System within the GC enterprise and departments. These considerations address concerns from a GC perspective rather than the Vulnerability Management System itself.
| |
| − | * The network environment, including perimeter defences and zoning, must be considered when selecting vulnerability management technologies and deployment strategies
| |
| − | * The inventory IT/IS assets to be assessed and managed for vulnerabilities is a critical consideration when determining the required Vulnerability Management System. This is especially true when considering the types of vulnerability scanners and vulnerability scan agents required to monitor different assets in a variety of deployment environments. Complex assets, such as application servers and virtualized assets, require different agent assets, remote computing assets, and remote devices all present differing challenges to assessing and managing GC assets.
| |
| − | * The extensibility of the Vulnerability Management System technical capabilities must be considered within the context of the GC enterprise and departments, including:
| |
| − | ** Geo-location of assets and remote management of assets
| |
| − | ** Interoperability with other types of Vulnerability Management systems (MAM, MDM, Security as a Service providers, Virtualized security services, etc.)
| |
| − | ** The capability to collect, synthesize, and report on assessment and compliance scans, vulnerability findings, and remediation status.
| |
| − | | |
| − | <br>
| |
| − | | |
| − | == References ==
| |
| − | * [[Media:GC Enterprise VMS HLD v0.5.pdf|GC ESA Vulnerability Management System High-Level Design]]
| |
| − | | |
| − | * [[Media:GC ESA ConOps - ANNEX E GC Enterprise VMS v0.6.pdf|GC ESA ConOps Annex E: Vulnerability Management System]]
| |
| − | | |
| − | * [[Media:GC ESA Framework.pdf|GC ESA Framework]]
| |
| − | | |
| − | [[Category:Government of Canada Enterprise Security Architecture (ESA) Program]]
| |
| − | [[Category:Enterprise Security Architecture]]
| |
| − | [[Category:GC Enterprise Architecture]]
| |
