Glossary
alert
Notification of a security significant event, or events, or synthesized by a sensor or detection engine or SWC Alerts.
analysis engine
A process which takes information from sensors and processes it. Subtypes include detection engines, intel engines, and statistics engines.
asset
An asset is a generic object, which can be a device, person, network, data or application. For example, an asset could be your laptop, or it could be the application you use to store specific intellectual property (data). Note that device and endpoint are interchangeable terms based on how the industry uses them.
case
A case is a data structure that allows you to gather and group observables and related analyst notes in one place from across multiple products for easy retrieval and further actions. For example, you can group a list of observables known to be associated with a specific reported threat or a list of observables known to be associated with an endpoint of interest. You can then retrieve that case later and have the set of observables and your records immediately at hand.
A case does not include dispositions, sightings, or other temporal or enrichment-based information. It is primarily a container for observables so that all of the observables in the case can be investigated quickly or added to incidents. You can optionally include any analyst notes to the case as you follow leads during your threat investigation.
The casebook app (either in the ribbon or the ribbon extension) is a powerful and convenient tool for creating, saving, editing, and sharing your cases across the Cisco Secure portfolio and anywhere you go in your browser.
From within the casebook app you can see current dispositions on the observables in the case and launch investigations or take other research or response actions on them, as provided by your Cisco XDR integrations.
CTIM
Cisco Threat Intelligence Model allows us to decompose the massive, comprehensive artifacts generated during malware sample analysis, and extract the details most relevant to incident response into a data model specifically designed for rapid storage, retrieval, and enrichment. See the tutorial, Modeling Threat Intelligence in CTIM, which describes methods of modeling threat intelligence using the Cisco Threat Intelligence Model, including best practices for client developers.
controller
A process that controls which activity on a network or an endpoint can take place. Also known as enforcement engine, or enforcment agent. Secure Endpoint is an example of an endpoint controller, as well as being a sensor.
detection engine
A process which consumes information such as events, telemetry, and intel and produces alerts.
enrichment
Annotating or collecting events with threat intel, correlated events, and security context.
enrichment engine
A process that takes events and alerts, and combines them with other data to annotate and aggregate them to support several actions, including triage and response.
event
A generic term for almost any observed activity on the network or endpoint. Includes netflow records, connection events, Secure Endpoint execution records, authorization records, email received, and so on. Also includes events which have security significance and context, see alerts, such as IPS alerts.
incident
A combination of events, alerts, and intelligence concerning a possible security compromise, which drives an incident response process that includes confirmation, triage, investigation, and remediation.
indicator
An indicator describes a pattern of behavior or a set of conditions which indicate malicious behavior.
Some indicators are more indicative than others of malicious behavior, so knowing exactly which bad behaviors an observable (such as a domain or an IP address) are exhibiting can help an incident responder decide what to do next.
Cisco XDR uses a large collection of malware indicators from the Cisco XDR Global Threat Intelligence threat archive.
intel engine
A process which extracts threat intelligence in the form of judgements and indicators from a flow of information.
intel source
An engine, website, or group of people which produce indicators and their related data around malware, attack patterns, weaknesses, campaign, actors and targets.
judgement
A statement by a human or analysis engine that declares the perceived, calculated disposition of an observable: whether it’s malicious, clean, suspicious, common, unknown, and so on. There can be many judgements. Judgements are the basis for returned verdicts. They’re also the primary means by which users go from observables on their system, to the indicators and threat intelligence data in Threat Response, providing further insight as to why a specific disposition was associated with that observable. A judgement is valid for an explicit span of time.
A judgement has more than just the disposition. It’s a record of which engine made the judgement, how long it is valid, why the judgement was made, and where more details can be seen.
kill chain
A model of the progress of a security compromise. The dominant one being the Lockheed Martin model, recon, weaponization, delivery, exploitation, installation, command and control, and actions.
observable
Cisco XDR supports the quick investigation of cyber observables, which might be domain names, IP addresses, file hashes, PKI certificate serial numbers, and even specific devices or users.
The disposition of an observable is obtained by by aggregating what we know about that observable from the various enrichment modules we have configured. The disposition tells us whether the observable is:
- Clean (explicitly allow-listed)
- Malicious (explicitly block-listed)
- Suspicious (potentially harmful)
- Unknown (not in our records)
Once we have a disposition for an observable, we begin to enrich it, gathering information about it from enrichment sources such as AMP and the Cisco Threat Intelligence API. Unknown observables are not enriched.
security context
Information about the assets, data policy and the customer environment. Where was the observable seen in the environment, what value are the assets involved, what is the policy regarding priority.
sensor
A process or device which observes activity on a network or endpoint and generates events, alerts or other data flows. An example would be Secure Endpoint.
sighting
A data object encoding an event, alert, or observed behavior with security significance, and a limited set of information about the context of the observation.
statistics engine
A process which summarizes and generates telemetry from a flow of events and alerts.
TLP
Traffic Light Protocol is a color-coded set of designations used to indicate when sensitive information should be shared and with whom. It includes four colors to indicate how information can be shared and who has access to it.
- Red - no redistribution, this information is for only the owner/creator.
- Amber - limited redistribution within the receiving organization; accessible by users in the same organization.
- Green - limited redistribution with peers and partners; accessible by all users.
- White - information is considered as public; accessible by all users.
target
A target represents the device, identity, or resource that a threat has targeted. A target is identified by one or more observables. When known, a type, operating system, and other metadata is recorded as well.
Targets are always part of a sighting.
In Automation, targets are the systems and resources a workflow is able to communicate with. They come in a variety of types depending on the product or platform you want to connect to.
threat hunting
The process of proactively and iteratively searching through networks to detect and isolate advanced threats that evade existing security solutions.
threat intelligence
Cyber threat intelligence is what cyber threat information becomes once it has been collected, evaluated in the context of its source and reliability, and analyzed through rigorous and structured tradecraft techniques by those with substantive expertise and access to all-source information. (Source: Center for Internet Security)
verdict
A verdict is chosen from all of the judgements on an observable that have not yet expired. The highest priority judgement becomes the active verdict. Disposition priority is ranked from highest to lowest: Clean, Malicious, Suspicious, Common, and Unknown. A Clean disposition is the highest priority and an Unknown disposition is the lowest priority. If there is more than one judgement with that priority, then the Clean disposition has priority over all others, and then Malicious, Suspicious, Common, and Unknown dispositions take priority in the highest to lowest order.