> For the complete documentation index, see [llms.txt](https://abrahamreyes9.gitbook.io/cysa+/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://abrahamreyes9.gitbook.io/cysa+/1.0-threat-and-vulnerability-management/1.3-given-a-scenario-perform-vulnerability-management-activities.md).

# 1.3 Given a scenario, perform vulnerability management activities

* Vulnerability identification:
* Asset criticality: impact if CIA was breached; sensitivity of data & business criticality
* Active vs passive scanning: interact with targets VS use stored data to find info/identify targets
* Mapping/enumeration: host/asset/network/infrastructure/systems discovery/mapping
* Validation:
  * True positive: scanner correctly identifies existing vulnerability
  * False positive: reported vulnerability that doesn't exist (verify patch/versions, or attempt actual attack)
  * True negative: scanner correctly doesn't alert on non-existent vulnerability
  * False negative: scanner alerts on non-existent vulnerability
* Remediation/mitigation:
  * Configuration baseline: perform anomaly analysis; provides info on OS/apps
  * Patching: maintain current security patch levels on OS/apps (with e.g. SCCM)
  * Hardening: disable unnecessary ports/services, centralised control, secure config etc.
  * Compensating controls: when system can't be upgraded/patched; isolate and place compensating controls in front
  * Risk acceptance: don't take any action against risk (low risk; ALE < mitigation cost)
  * Verification of mitigation: audits (formal), assessments (informal), patch levels, repeated vulnerability scanning
* Scanning parameters and criteria:
  * Risks associated with scanning activities: scans consume bandwidth and resources, and risk business process interruptions (tune intensity & scan times)
  * Vulnerability feed: SCAP (e.g. CCE \[config], CPE \[product names], CVE \[vulnerabilities], CVSS \[severity], XCCDF \[checklist results], OVAL \[testing procedures used by checklists])
  * Scope: extent of scan (included systems/networks; host discovery methods; what tests will be conducted against active hosts)
  * Credentialed vs non-credentialed: can confirm an issue by accessing OS/database/app info VS chance of false positives/negatives
  * Server-based vs agent-based: central server remotely scans hosts VS agent installed on targets perform internal scans and report back to the server
  * Internal vs external: gives different perspectives; insider threat vs external attacker
  * Special considerations:
    * Types of data: health, financial, PII etc.; data classification
    * Technical constraints: capabilities of the scanning system => frequency limitations
    * Workflow: remediation workflow (detection -> remediation -> testing);
    * Sensitivity levels: minimum severity rating (low, medium, high, critical)
    * Regulatory requirements: PCI DSS (internal & external; at least quarterly by qualified professional or ASV); FISMA (updated scanning tools, update vulnerability list before /after scan, some authenticated scans, determine discoverable info and correct them)
    * Segmentation: compliance networks can be segmented to reduce scan scope
    * IPS, IDS, and firewall settings: internal = insider threat; external = external attack
* Inhibitors to remediation:
  * MOU: non-legally binding; customer must participate in including scanning in MOU
  * SLA: customer expectations of security, performance & uptime
  * Organisational governance: may block config changes needed for scanning; limited resources and support
  * Business process interruption: taking down systems can cause significant interruption
  * Degrading functionality: service degradation can lead to business process interruption
  * Legacy systems: EoL unsupported systems don't get security updates
  * Proprietary systems: different vendors; some vendors will not have patches/updates