- Title Page
- Introduction & Preface
- Logging into the FireSIGHT System
- Using Objects and Security Zones
- Managing Devices
- Setting Up an IPS Device
- Setting Up Virtual Switches
- Setting Up Virtual Routers
- Setting Up Aggregate Interfaces
- Setting Up Hybrid Interfaces
- Using Gateway VPNs
- Using NAT Policies
- Getting Started with Access Control Policies
- Blacklisting Using Security Intelligence IP Address Reputation
- Tuning Traffic Flow Using Access Control Rules
- Controlling Traffic with Network-Based Rules
- Controlling Traffic with Reputation-Based Rules
- Controlling Traffic Based on Users
- Controlling Traffic Using Intrusion and File Policies
- Understanding Traffic Decryption
- Getting Started with SSL Policies
- Getting Started with SSL Rules
- Tuning Traffic Decryption Using SSL Rules
- Understanding Intrusion and Network Analysis Policies
- Using Layers in Intrusion and Network Analysis Policies
- Customizing Traffic Preprocessing
- Getting Started with Network Analysis Policies
- Using Application Layer Preprocessors
- Configuring SCADA Preprocessing
- Configuring Transport & Network Layer Preprocessing
- Tuning Preprocessing in Passive Deployments
- Getting Started with Intrusion Policies
- Tuning Intrusion Rules
- Tailoring Intrusion Protection to Your Network Assets
- Detecting Specific Threats
- Limiting Intrusion Event Logging
- Understanding and Writing Intrusion Rules
- Blocking Malware and Prohibited Files
- Logging Connections in Network Traffic
- Working with Connection & Security Intelligence Data
- Analyzing Malware and File Activity
- Working with Intrusion Events
- Handling Incidents
- Configuring External Alerting
- Configuring External Alerting for Intrusion Rules
- Introduction to Network Discovery
- Enhancing Network Discovery
- Configuring Active Scanning
- Using the Network Map
- Using Host Profiles
- Working with Discovery Events
- Configuring Correlation Policies and Rules
- Using the FireSIGHT System as a Compliance Tool
- Creating Traffic Profiles
- Configuring Remediations
- Using Dashboards
- Using the Context Explorer
- Working with Reports
- Understanding and Using Workflows
- Using Custom Tables
- Searching for Events
- Managing Users
- Scheduling Tasks
- Managing System Policies
- Configuring Appliance Settings
- Licensing the FireSIGHT System
- Updating System Software
- Monitoring the System
- Using Health Monitoring
- Auditing the System
- Using Backup and Restore
- Specifying User Preferences
- Importing and Exporting Configurations
- Purging Discovery Data from the Database
- Viewing the Status of Long-Running Tasks
- Command Line Reference
- Security, Internet Access, and Communication Ports
- Third-Party Products
- glossary
- Viewing Host Profiles
- Working with Basic Host Information in the Host Profile
- Working with IP Addresses in the Host Profile
- Working with Indications of Compromise in the Host Profile
- Working with Operating Systems in the Host Profile
- Working with Servers in the Host Profile
- Working with Applications in the Host Profile
- Working with VLAN Tags in the Host Profile
- Working with User History in the Host Profile
- Working with Host Attributes in the Host Profile
- Working with Host Protocols in the Host Profile
- Working with White List Violations in the Host Profile
- Working with Malware Detections in the Host Profile
- Working with Vulnerabilities in the Host Profile
- Working with the Predefined Host Attributes
- Working with User-Defined Host Attributes
- Working with Scan Results in a Host Profile
Using Host Profiles
A host profile provides a complete view of all the information the system has gathered about a single host. You can access general host information, such as the host name and operating system, through the profile. If you need to quickly find the MAC address for a host, for example, you can look in the host profile.
Host attributes for that host are also listed in the profile. Host attributes are user-defined descriptions that you can apply to a host. For example, you might assign a host attribute that indicates the building where the host is located. From a host profile, you can view the existing host attributes applied to that host and can modify the host attribute values. As another example, you can use the host criticality attribute to designate the business criticality of a given host and to tailor correlation policies and alerts based on host criticality.
Host profiles also provide you with information about the servers, clients, and host protocols running on a particular host, including whether they are in compliance with a compliance white list. You can remove servers from the servers list, and view details for those servers. You can also view connection events for servers, log information about the session where server traffic was detected. You can also view details and connection events for clients and delete servers, clients or host protocols from the host profile.
If your FireSIGHT System deployment includes a FireSIGHT license, you can view indications of compromise (IOC) in the host profile. These indications correlate various types of data (intrusion events, Security Intelligence, connection events, and file or malware events) associated with hosts to determine whether a host on your monitored network is likely to be compromised by malicious means. From the host profile, you can see an overview of a host’s IOC tags, view the events associated with IOC, mark IOC tags resolved, and edit IOC rule states in the discovery policy.
If your deployment includes a Protection license, you can tailor the way the system processes traffic so it best fits the type of operating system on the host and the servers and clients the host is running. For more information, see Tuning Preprocessing in Passive Deployments.
You can also see user history information for a host if you have configured the system to track it. A graphic representation of the last twenty-four hours of user activity is then available.
You can modify the list of vulnerabilities for the host from the host profile. You can use this capability to track which vulnerabilities have been addressed for the host. You can also apply fixes for vulnerabilities, causing all vulnerabilities addressed by the fix to be automatically marked invalid.
You can work with the vulnerability information generated by the Cisco system, and also use information on vulnerabilities detected by third-party scanners, which you import onto the Defense Center using the host input feature.
Optionally, you can perform an Nmap scan from the host profile, to augment the server and operating system information in your host profile. The Nmap scanner actively probes the host to obtain information about the operating system and servers running on the host. The results of the scan are added to the list of operating system and server identities for the host.
Note that a host profile may not be available for every host on your network. Possible reasons include:
- the host was deleted from the network map because it timed out
- you have reached your FireSIGHT host license limit
- the host resides in a network segment that is not monitored by your network discovery policy
Note that the information displayed in a host profile may vary according to the type of host and the information available about the host. For example, if your system detects a host using a non-IP-based protocol like STP, SNAP, or IPX, the host is added to the network map as a MAC host and much less information is available than for an IP host.
As another example, although you can configure your network discovery policy to add hosts and server and clients to the network map based on data exported by NetFlow-enabled devices, the available information about these hosts and servers and clients is limited. For example, no operating system data is available for these hosts, unless you provide it using a scanner or the host input feature. For more information, see Differences Between NetFlow and FireSIGHT Data.
The following graphic shows an example of a host profile.
The following graphic shows an example of a host profile for a MAC host.
For more information about each section of the host profile, see the following:
- Viewing Host Profiles explains how to access a host profile.
- Working with Basic Host Information in the Host Profile describes the information provided in the Host section of a host profile.
- Working with IP Addresses in the Host Profile describes the information provided in the IP Addresses section of a host profile.
- Working with Indications of Compromise in the Host Profile describes the information provided in the Indications of Compromise section of a host profile.
- Working with Operating Systems in the Host Profile describes the information provided in the Operating System or Operating System Conflicts section of a host profile and explains how to edit the operating system or resolve an operating system conflict.
- Working with Servers in the Host Profile describes the information provided in the Servers, Server Detail, and Server Banner sections of a host profile.
- Working with Applications in the Host Profile describes the information provided in the Clients section of a host profile.
- Working with VLAN Tags in the Host Profile describes the information provided in the VLAN Tag section of a host profile.
- Working with User History in the Host Profile describes the information provided in the User History section of a host profile.
- Working with Host Attributes in the Host Profile describes the information provided in the Attributes section of a host profile.
- Working with the Predefined Host Attributes explains how to set the host criticality attribute and how to add notes to a host profile.
- Working with User-Defined Host Attributes, which provides information about creating and using user-defined host attributes.
- Working with Host Protocols in the Host Profile describes the information provided in the Host Protocols section of a host profile.
- Working with White List Violations in the Host Profile describes the information provided in the White List Violations section of a host profile.
- Working with Malware Detections in the Host Profile describes the information provided in the Most Recent Malware Detections section of a host profile.
- Working with Vulnerabilities in the Host Profile, which describes the information provided in the Vulnerabilities and Vulnerability Detail sections of a host profile.
Viewing Host Profiles
You can access a host profile from any network map or from any event view that includes the IP addresses of hosts on monitored networks. For example, the table view of discovery events includes a link to the host profile next to every entry in the IP Address column. If you have any indication of compromise (IOC) rules enabled, potentially compromised hosts appear with a different host profile icon.
To view a host profile from an event view:
Access: Admin/Any Security Analyst
Step 1 On any event view, click the host profile icon ( ) or the compromised host icon ( ) next to the IP address of the host whose profile you want to view.
The host profile appears in a pop-up window.
To view a host profile from a network map:
Access: Admin/Any Security Analyst
Step 1 On any network map, drill down to the IP address of the host whose profile you want to view.
The host profile appears. See Working with the Hosts Network Map for an example of how to access a host profile from a network map.
Working with Basic Host Information in the Host Profile
Each host profile provides basic information about a detected host or other device.
Descriptions of each of the basic host profile fields follow.
All IP addresses (both IPv4 and IPv6) associated with the host. IPv6 hosts often have at least two IPv6 addresses (local-only and globally routable), and may also have IPv4 addresses. IPv4-only hosts may have multiple IPv4 addresses. Where available, routable host IP addresses also include a flag icon and country code indicating the geolocation data associated with that address. For more information on this and other geolocation features, see Using Geolocation.
The fully qualified domain name of the host, if known.
The NetBIOS name of the host, if available. Microsoft Windows hosts, as well as Macintosh, Linux, or other platforms configured to use NetBIOS, can have a NetBIOS name. For example, Linux hosts configured as Samba servers have NetBIOS names.
– the reporting device for the network where the host resides, as defined in the network discovery policy, or
– the device that processed the NetFlow data that added the host to the network map
– The device and the number of network hops between the device that detected the host and the host itself follows the device name, in parentheses. If multiple devices can see the host, the reporting device is displayed in bold.
– If this field is blank, either:
– the host was added to the network map by a device that is not explicitly monitoring the network where the host resides, as defined in the network discovery policy, or
– the host was added using the host input feature and has not also been detected by the FireSIGHT System
The host’s detected MAC address or addresses and associated NIC vendors, with the NIC’s hardware vendor and current time-to-live (TTL) value in parentheses. If the MAC address is displayed in a bold font, the MAC address is the actual MAC address of the host, detected by the system through ARP and DHCP traffic. If multiple devices detected the host, the Defense Center displays all MAC addresses and TTL values associated with the host, regardless of which device reported them.
You can click the MAC address to view a list of hosts with the same MAC address. Router host profiles typically show the hosts (IP addresses) in the network segments they route in this list, and the IP addresses of monitored routers frequently appear in this list for monitored workstations and servers. The true IP address for the MAC address is displayed in bold.
The type of device that the system detected: host, mobile device, jailbroken mobile device, router, bridge, NAT device, or load balancer.
The methods the system uses to distinguish network devices include:
– the analysis of Cisco Discovery Protocol (CDP) messages, which can identify network devices and their type (Cisco devices only)
– the detection of the Spanning Tree Protocol (STP), which identifies a device as a switch or bridge
– the detection of multiple hosts using the same MAC address, which identifies the MAC address as belonging to a router
– the detection of TTL value changes from the client side, or TTL values that change more frequently than a typical boot time, which identify NAT devices and load balancers
– The methods the system uses to distinguish mobile devices include:
– analysis of user agent strings in HTTP traffic from the mobile device’s mobile browser
– monitoring of HTTP traffic of specific mobile applications
If a device is not identified as a network device or a mobile device, it is categorized as a host.
The date and time that any of a host’s IP addresses was last detected.
The user most recently logged into this host.
Note that a non-authoritative user logging into a host only registers as the current user on the host if the existing current user is not an authoritative user. For more information, see Users Database.
Links to views of event data, using the default workflow for that event type and constrained to show events related to the host; where possible, these events include all IP addresses associated with the host. For more information, see the following sections:
– Content Explorer — for more information, see Using the Context Explorer.
– Connection Events — for more information, see Understanding Connection and Security Intelligence Data.
– Discovery Events — for more information, see Working with Discovery Events.
– Malware Events — for more information, see Working with Malware Events.
– Intrusion Events by Source — for more information, see Working with Intrusion Events.
– Intrusion Events by Destination — for more information, see Working with Intrusion Events.
Working with IP Addresses in the Host Profile
The system detects IP addresses associated with hosts and, where supported, groups multiple IP addresses used by the same host. IPv6 hosts usually have at least two IPv6 addresses: local-only and globally routable. They may also have one or more assigned IPv4 addresses. IPv4-only hosts may have multiple IPv4 addresses.
The host profile lists all detected IP addresses associated with that host. Where available, IP addresses also feature a small flag icon and ISO country code that indicate the associated country. You can click the flag icon or country code for further geolocation details. For more information, see Using Geolocation.
Note that only the first three addresses are shown by default. Click show all to show all addresses for a host.
Working with Indications of Compromise in the Host Profile
The FireSIGHT System can correlate various types of data (intrusion events, Security Intelligence, connection events, and file or malware events) associated with hosts to determine whether a host on your monitored network is likely to be compromised by malicious means. Certain combinations and frequencies of event data trigger indications of compromise (IOC) tags on affected hosts. The Indications of Compromise section of the host profile displays all IOC tags for a host. In this section, you can view details of the threats facing the host, jump to the events that triggered an IOC tag, edit IOC rule states, as well as resolve IOC tags that are no longer relevant.
To use the IOC feature, you must activate the feature and at least one IOC rule in your discovery policy. You can also edit IOC rule states for individual hosts from that host’s host profile page. Each IOC rule corresponds to one type of IOC tag; you can activate any or all rules depending on your organization’s needs. For more information on IOC in the discovery policy and overall, see Understanding Indications of Compromise.
In addition to its presence in the host profile, you can also analyze IOC data in the event viewer. For more information, see Working with Indications of Compromise.
Descriptions of the IOC information fields displayed in the host profile follow.
The IP address associated with the host that triggered the IOC.
Brief description of the type of compromise indicated, such as
Malware Executed
or
Impact 1 Attack
.
Identifier associated with a specific Indication of Compromise (IOC), referring to the event that triggered it.
Description of what threatens the potentially compromised host, such as
This host may be under remote control
or
Malware has been executed on this host
.
The first (or most recent) date and time that events triggering a host’s IOC occurred.
For additional information on working with IOC data in the host profile, see the following sections:
- Editing Indication of Compromise Rule States for a Single Host
- Viewing Source Events for Indications of Compromise
- Resolving Indications of Compromise
Editing Indication of Compromise Rule States for a Single Host
For your system to detect and tag indications of compromise (IOC), you must first activate the IOC feature in the discovery policy and activate at least one IOC rule (either policy-wide or for individual hosts). From the host profile, you can set the IOC rule states that apply to that individual host. For more information on configuring IOC in the discovery policy and setting policy-wide IOC rule states, see Setting Indications of Compromise Rules.
From the host profile, you can access and edit the list of IOC rules with the Edit Rule States link in the Indications of Compromise section. You can enable any or all rules, depending on the needs of your network and organization. For example, if hosts using software such as Microsoft Excel never appear on your monitored network, you may decide not to enable the IOC tags that pertain to Excel-based threats.
All IOC rules are predefined by Cisco; you cannot create original rules, although you can write compliance rules against triggered IOC tags. For more information, see Configuring Correlation Policies and Rules. Each IOC rule is triggered by only one type of event (such as malware or intrusion) and corresponds to one specific IOC tag. Both rule and tag have identical Category, Event Type, and Description data for easy correspondence; the Edit page for IOC rule states also lists an event data Source for each rule, to give you a clear picture of what system features you need for a rule to trigger.
To edit Indication of Compromise rule states for a host:
Access: Admin/Any Security Analyst
Step 1 In a host profile, click Edit Rule States in the Indications of Compromise section.
The Edit Indication of Compromise Rule States page appears in a new window.
Step 2 In the Enabled column for a rule, click the slider to enable or disable it.
Viewing Source Events for Indications of Compromise
You can use the Indications of Compromise section to navigate quickly to the events that triggered IOC tags on a host. Analyzing these events can give you the information you need to determine what, and whether, action is required to address threats to a potentially compromised host.
Clicking the view icon ( ) next to the timestamp of an IOC tag navigates to the table view of events for the relevant event type, constrained to show only the event that triggered the IOC tag.
For more information on the types of events and features that trigger IOC tags, see the following:
- Working with Connection & Security Intelligence Data
- Working with Intrusion Events
- Understanding Malware Protection and File Control
To view source events for an Indications of Compromise tag:
Access: Admin/Any Security Analyst
Step 1 In the host profile’s Indications of Compromise section, click the view icon ( ) in the First Seen or Last Seen column for the IOC tag you want to investigate.
The table view of events for the appropriate event that triggered the IOC appears, constrained to show only the triggering event. If you are viewing the host profile page in a separate window, the event view appears in the main window.
Resolving Indications of Compromise
After you have analyzed and addressed the threats indicated by an IOC tag, or if you determine that an IOC tag represents a false positive, you can mark a tag resolved. Marking an IOC tag resolved removes it from the host profile; when all active IOC tags on a host are resolved, the host no longer appears marked with the compromised host icon ( ). Note that you can still view the IOC-triggering events for the resolved IOC.
If the events that triggered a host’s IOC tag recur, the tag is set again. You can resolve individual IOC tags on a host or mark all of a host’s tags as resolved.
To resolve an Indications of Compromise tag:
Access: Admin/Any Security Analyst
Step 1 In the host profile’s Indications of Compromise section, you have two options:
-
) to the right of the tag you want to resolve.
Your changes are saved and the IOC tags you selected are removed.
Working with Operating Systems in the Host Profile
The system passively detects the identity of the operating system running on a host by analyzing the network and application stack in traffic generated by the host or by analyzing host data reported by the User Agent. The system also collates operating system information from other sources, such as the Nmap scanner or application data imported through the host input feature. The system considers the priority assigned to each identity source when determining which identity to use. By default, user input has the highest priority, followed by application or scanner sources, followed by the Cisco-discovered identity.
Sometimes the system supplies a general operating system definition rather than a specific one because the traffic and other identity sources do not provide sufficient information for a more focused identity. The system collates information from the sources to use the most detailed definition possible.
Descriptions of the operating system information fields displayed in the host profile follow.
The hardware platform for a mobile device.
The operating system determined most likely to be running on the host, based on the identity data collected from all sources.
If the operating system is
Pending
, the system has not yet identified an operating system and no other identity data is available. If the operating system is
unknown
, the system cannot identify the operating system and no other identity data is available for the operating system.
If the host’s operating system is not one the system is capable of detecting, you may want to use one of the following strategies:
– create a custom fingerprint for the host, as described in Using Custom Fingerprinting
– run an Nmap scan against the host, as described in Scanning a Host from the Host Profile
– import data into the network map, using the host input feature described in the FireSIGHT System Host Input API Guide
– manually enter operating system information, as described in Working with Operating Systems in the Host Profile
The operating system version. If a host is a jailbroken mobile device,
Jailbroken
is indicated in parentheses after the version.
– Scanner: scanner_type (Nmap or scanner added through system policy)
The system may reconcile data from multiple sources to determine the identity of an operating system; see Understanding Current Identities.
Because the vulnerabilities list for the host and the event impact correlation for events targeting the host depend on the operating system, you may want to manually supply more specific operating system information. In addition, you can indicate that fixes have been applied to the operating system, such as service packs and updates, and invalidate any vulnerabilities addressed by the fixes.
For example, if the system identifies a host’s operating system as Microsoft Windows 2003, but you know that the host is actually running Microsoft Windows XP Professional with Service Pack 2, you can set the operating system identity accordingly. Setting a more specific operating system identity refines the list of vulnerabilities for the host, so your impact correlation for that host is more focused and accurate.
If the system detects operating system information for a host and that information conflicts with a current operating system identity that was supplied by an active source, an identity conflict occurs. When an identity conflict is in effect, the system uses both identities for vulnerabilities and impact correlation.
Although you can configure the network discovery policy to add hosts to the network map based on data exported by NetFlow-enabled devices, there is no operating system data available for these hosts, unless you set the operating system identity. For more information, see Differences Between NetFlow and FireSIGHT Data.
Note that if a host is running an operating system that violates a compliance white list in an activated network discovery policy, the Defense Center marks the operating system information with the white list violation icon ( ). In addition, if a jailbroken mobile device violates an active white list, the icon appears next to the operating system for the device.
You can set a custom display string for the host’s operating system identity. That display string is then used in the host profile.
Note Note that changing the operating system information for a host may change its compliance with a compliance white list.
In the host profile for a network device, the label for the Operating Systems section changes to Systems and an additional Hardware column appears. If a value for a hardware platform is listed under Systems, that system represents a mobile device or devices detected behind the network device. Note that mobile devices may or may not have hardware platform information, but hardware platform information is never detected for systems that are not mobile devices.
Viewing Operating System Identities
You can view the specific operating system identities discovered or added for a host. The system uses source prioritization to determine the current identity for the host. In the list of identities, the current identity is highlighted by boldface text.
For each operating system identity, the host profile may include the information described in Working with Operating Systems in the Host Profile.
Note that the View button is only available if multiple operating system identities exist for the host.
To view the list of operating system identities for a host:
Access: Admin/Any Security Analyst
Step 1 Click View in the Operating System or Operating System Conflicts section of the host profile.
The Operating System Identity Information pop-up window appears.
Tip Click the delete icon () next to any operating system identity to remove the identity from the Operating System Identity Information pop-up window and, if applicable, to update the current identity for the operating system in the host profile. Note that you cannot delete Cisco-detected operating system identities.
Editing an Operating System
You can set the current operating system identity for a host using the FireSIGHT System web interface. Setting the identity through the web interface overrides all other identity sources so that identity is used for vulnerability assessment and impact correlation. However, note that if the system detects a conflicting operating system identity for the host after you edit the operating system, an operating system conflict occurs.
Both operating systems are then considered current until you resolve the conflict. For more information, see Resolving Operating System Identity Conflicts.
To change the operating system identity:
Access: Admin/Any Security Analyst
Step 1 In a host profile, click Edit in the Operating System section.
A pop-up window appears where you can set the operating system identity.
Step 2 You have several options:
- Select Current Definition from the OS Definition drop-down list to confirm the current operating system identity through host input, then skip to step 6 .
- Select a variation on the current operating system identity from the OS Definition drop-down list, then skip to step 6 .
- Select User-Defined from the OS Definition drop-down list, then continue with step 3 .
Step 3 Optionally, select Use Custom Display String and modify the custom strings you want to display in the Vendor String , Product String , and Version String fields.
Step 4 Optionally, to change to an operating system from a different vendor, select the vendor and other operating system details from the Vendor and Product drop-down lists.
Step 5 Optionally, to configure the operating system product release level, select the applicable items in the Major , Minor , Revision , Build, Patch, and Extension drop-down lists.
Step 6 Optionally, if you want to indicate that fixes for the operating system have been applied, click Configure Fixes .
The list of available package fixes displays.
Step 7 Choose the applicable fixes in the drop-down list and click Add .
Step 8 Optionally, add the relevant patches and extensions using the Patch and Extension drop-down lists.
Step 9 Click Finish to complete the operating system identity configuration.
Resolving Operating System Identity Conflicts
An operating system identity conflict occurs when a new identity detected by the system conflicts with the current identity, if that identity was provided by an active source, such as a scanner, application, or user.
The list of operating system identities in conflict displays in bold in the host profile.
You can resolve an identity conflict and set the current operating system identity for a host through the system web interface. Setting the identity through the web interface overrides all other identity sources so that identity is used for vulnerability assessment and impact correlation.
To make one of the conflicting identities current:
Access: Admin/Any Security Analyst
To resolve an operating system identity conflict:
Access: Admin/Any Security Analyst
Step 1 In a host profile, click Resolve in the Operating System Conflicts section.
A pop-up window appears where you can set the current operating system identity.
Step 2 You have several options:
- Select Current Definition from the OS Definition drop-down list to confirm the current operating system identity through host input, then skip to step 6 .
- Select a variation on one of the conflicting operating system identities from the OS Definition drop-down list, then skip to step 6 .
- Select User-Defined from the OS Definition drop-down list, then continue with step 3 .
Step 3 Optionally, select Use Custom Display String and type the custom strings you want to display in the Vendor String , Product String , and Version String fields.
Step 4 Optionally, to change to an operating system from a different vendor, select the vendor and other operating system details.
Step 5 Optionally, to configure the operating system product release level, select the applicable items in the Major , Minor , Revision , Build, Patch, and Extension drop-down lists.
Step 6 Optionally, if you want to indicate that fixes for the operating system have been applied, click Configure Fixes .
Step 7 Add the fixes you have applied to the fixes list.
Step 8 Click Finish to complete the operating system identity configuration and return to the host profile.
Working with Servers in the Host Profile
If the system detects servers running on a host on your monitored network or if servers are added through the host input feature or through a scanner or other active source, the Defense Center lists them in the Servers section of the host profile.
The Defense Center lists up to 100 servers per host. After that limit is reached, new server information from any source, whether active or passive, is discarded until you delete a server from the host or a server times out. For more information, see Host Limits and Discovery Event Logging.
If you scan a host using Nmap, Nmap adds the results of previously undetected servers running on open TCP ports to the Servers list. If you perform an Nmap scan on a host or import Nmap results, an expandable Scan Results section also appears in the host profile, listing the server information detected on the host by the Nmap scan. See Working with Scan Results in a Host Profile and Setting up Nmap Scans for more information. In addition, note that if the host is deleted from the network map, the Nmap scan results for that server for the host are discarded.
Note Although you can configure your network discovery policy to add server and clients to the network map based on data exported by NetFlow-enabled devices, the available information about these applications is limited. For more information, see Differences Between NetFlow and FireSIGHT Data.
The process for working with servers in the host profile differs depending on how you accessed the profile:
- If you accessed the host profile by drilling down through the Servers network map, the details for that server appear with the server name highlighted in bold. If you want to view the details for any other server on the host, click the view icon ( ) next to that server name.
- If you accessed the host profile in any other way, expand the Servers section and click the view icon ( ) next to the server whose details you want to see.
You can also perform the following actions:
- To analyze the connection events associated with a particular server on the host, click the events icon next to the server.
The first page of your preferred workflow for connection events appears, showing connection events constrained by the port and protocol of the server, as well as the IP address of the host. If you do not have a preferred workflow for connection events, you must select one. For more information about connection data, see Working with Connection & Security Intelligence Data.
The server is deleted from the host profile, but will appear again if the system detects traffic from the server again. Note that deleting a server from a host may bring the host into compliance with a white list.
You can choose one of the conflicting identities, choose a variation on one of those identities, or set a new user-defined identity.
You can choose the current identity, choose a variation on that identity, or set a new user-defined identity.
Descriptions of the columns in the Servers list follow.
The name of the protocol the server uses.
The port where the server runs.
– the name of the application protocol
–
pending
, if the system cannot positively or negatively identify the application protocol for one of several reasons
–
unknown
, if the system cannot identify the application protocol based on known application protocol fingerprints or if the server was added through host input by adding a vulnerability with port information without adding a corresponding server
When you hover the mouse on an application protocol name, the tags display. For information on tags, see Understanding Application Detection.
The vendor and version identified by the FireSIGHT System, by Nmap, or by another active source, or acquired via the host input feature. The field is blank if none of the available sources provides an identification.
Note that if the host is running a server that violates a compliance white list in an activated correlation policy, the Defense Center marks the non-compliant server with the white list violation icon ( ).
See the following sections for more information:
Server Detail
The Defense Center lists up to 16 passively detected (Cisco- or NetFlow-detected) identities per server. A server can have multiple passive identities if the system detects multiple vendors or versions of that server. For example, a load balancer between your managed device and your web server farm may cause your system to identify multiple passive identities for HTTP if your web servers are not running the same version of the server software. Note that the Defense Center does not limit the number of server identities from active sources such as user input, scanners, or other applications.
The Defense Center displays the current identity in bold. The system uses the current identity of a server for multiple purposes, including assigning vulnerabilities to a host, impact assessment, evaluating correlation rules written against host profile qualifications and compliance white lists, and so on.
Tip For information on changing the server identity and resolving identity conflicts from the server detail, see Editing Server Identities and Resolving Server Identity Conflicts.
The server detail may also display updated sub-server information known about the selected server. Finally, the server detail may display the server banner, which appears below the server details when you view a server from the host profile.
Server banners provide additional information about a server that may help you identify the server. The system cannot identify or detect a misidentified server when an attacker purposely alters the server banner string. The server banner displays the first 256 bytes of the first packet detected for the server. It is collected only once, the first time the server is detected by the system. Banner content is listed in two columns, with a hexadecimal representation on the left and a corresponding ASCII representation on the right.
Note To view server banners, you must enable the Capture Banners check box in the network discovery policy. This option is disabled by default.
Descriptions of the information provided in the server detail follow.
The name of the protocol the server uses.
The port where the server runs.
The number of times the server was detected by a Cisco managed device or Nmap. Note that the number of hits is
0
for servers imported through host input, unless the system detects traffic for that server.
The time and date the server was last detected. Note that the last used time for host input data reflects the initial data import time, unless the system detects new traffic for that server. Note also that scanner and application data imported through the host input feature times out according to settings in the system policy, but user input through the Defense Center web interface does not time out.
The name of the application protocol used by the server, if known.
The server vendor. This field does not appear if the vendor is unknown.
The server version. This field does not appear if the version is unknown.
– Scanner: scanner_type (Nmap or scanner added through system policy)
–
FireSIGHT
,
FireSIGHT
Port Match
, or
FireSIGHT Pattern Match
, for Cisco-detected applications
–
NetFlow
, for servers added to the network map based on NetFlow data
The system may reconcile data from multiple sources to determine the identity of a server; see Understanding Current Identities.
To view the server detail for a server:
Access: Admin/Any Security Analyst
Step 1 Click the view icon ( ) next to a server in the Servers section of a host profile.
The Server Detail pop-up window appears.
Editing Server Identities
You can manually update the identity settings for a server on a host and configure any fixes that you have applied to the host to remove the vulnerabilities addressed by the fixes. You can also delete server identities.
Note that deleting an identity does not delete the server, even if that is the only identity. Deleting an identity does remove the identity from the Server Detail pop-up window and, if applicable, updates the current identity for the server in the host profile.
You cannot edit or delete server identities added by a Cisco-managed device.
Access: Admin/Any Security Analyst
Step 1 In the Servers section in a host profile, click View to open the Server Detail pop-up window.
-
) next to the server identity you want to remove.
The Server Identity pop-up window appears.
Step 4 Optionally, to only list vendors and products for that server type, select the Restrict by Server Type check box.
Step 5 Optionally, to customize the name and version of the server, select the Use Custom Display String and type a Vendor String and Version String .
Step 6 In the Product Mappings section, select the operating system, product, and versions you want to use.
For example, if you want the server to map to Red Hat Linux 9, select Redhat, Inc. as the vendor, Redhat Linux as the product, and 9 as the version.
Step 7 If you want to indicate that fixes for the server have been applied, click Configure Fixes . Otherwise, skip to step 9 .
The Available Package Fixes page appears.
Step 8 Add the patches you want to apply for that server to the fixes list.
Step 9 Click Finish to complete the server identity configuration.
Resolving Server Identity Conflicts
A server identity conflict occurs when an active source, such as an application or scanner, adds identity data for a server to a host, then the system detects traffic for that port that indicates a conflicting server identity.
To resolve a server identity conflict:
Access: Admin/Any Security Analyst
Step 1 Click the resolve icon next to the server in the Servers list.
The Server Identity pop-up window appears.
Step 2 Select the type of server from the Select Server Type drop-down list.
Step 3 Optionally, to only list vendors and products for that server type, select the Restrict by Server Type check box.
Step 4 Optionally, to customize the name and version of the server, select the Use Custom Display String and type a Vendor String and Version String .
Step 5 In the Product Mappings section, select the operating system, product, and versions you want to use.
For example, if you want the server to map to Red Hat Linux 9, select Redhat, Inc. as the vendor, Redhat Linux as the product, and 9 as the version.
Step 6 If you want to indicate that fixes for the server have been applied, click Configure Fixes . Otherwise, skip to step 9 .
The Available Package Fixes page appears.
Step 7 Add the patches you want to apply for that server to the fixes list.
Step 8 Click Finish to complete the server identity configuration and return to the host profile.
Working with Applications in the Host Profile
You can see the applications running on a host in the host profile. If you want to remove an application from a host profile, you can delete that application.
For more information on managing applications in the host profile, see:
Viewing Applications in the Host Profile
The system can detect a variety of clients and web applications running on the hosts on your network.
Note Note that you must select the Applications check box in discovery rules for NetFlow devices in your network discovery policy for the system to detect applications on the hosts in your monitored network. This option is enabled by default in NetFlow rules and cannot be disabled for rules used for discovery via managed devices.
The host profile displays the product and version of the detected applications on a host, any available client or web application information, and the time that the application was last detected in use.
The Defense Center lists up to 16 clients running on the host. After that limit is reached, new client information from any source, whether active or passive, is discarded until you delete a client application from the host or the system deletes the client from the host profile due to inactivity (the client times out).
Additionally, for each detected web browser, the host profile displays the first 100 web applications accessed. After that limit is reached, new web applications associated with that browser from any source, whether active or passive, are discarded until either:
- the web browser client application times out, or
- you delete application information associated with a web application from the host profile
Descriptions of the application information that appears in a host profile follow.
Displays the application protocol used by the application (HTTP browser, DNS client, and so on).
Client information derived from payload if identified by the FireSIGHT System, or captured by Nmap, or by another active source, or acquired via the host input feature. The field is blank if none of the available sources provides an identification.
Displays the version of the client.
For web browsers, the content detected by the system in the http traffic. Web application information indicates the specific type of content (for example, WMV or QuickTime) identified by the FireSIGHT System, captured by Nmap, captured by another active source, or acquired via the host input feature. The field is blank if none of the available sources provides an identification.
Note that if the host is running an application that violates a compliance white list in an activated correlation policy, the Defense Center marks the non-compliant application with the white list violation icon ( ).
To analyze the connection events associated with a particular application on the host, click the events icon ( ) next to the application. The first page of your preferred workflow for connection events appears, showing connection events constrained by the type, product, and version of the application, as well as the IP address(es) of the host. If you do not have a preferred workflow for connection events, you must select one. For more information about connection data, see Working with Connection & Security Intelligence Data.
Deleting Applications from the Host Profile
You can delete an application from a host profile to remove applications that you know are not running on the host. Note that deleting an application from a host may bring the host into compliance with a white list.
Note If the system detects the application again, it re-adds it to the network map and the host profile.
To delete an application from a host profile:
Access: Admin/Any Security Analyst
Step 1 In the Applications section of the host profile, click the delete icon ( ) next to the application you want to delete.
The application is deleted for that host.
Working with VLAN Tags in the Host Profile
The VLAN Tag section of the host profile appears if the host is a member of a Virtual LAN (VLAN).
Physical network equipment often uses VLANs to create logical network segments from different network blocks. The system detects 802.1q VLAN tags and displays the following information for each:
- VLAN ID identifies the VLAN where the host is a member. This can be any integer between zero and 4095 for 802.1q VLANs.
- Type identifies the encapsulated packet containing the VLAN tag, which can be either Ethernet or Token Ring.
- Priority identifies the priority in the VLAN tag, which can be any integer from zero to 7, where 7 is the highest priority.
If VLAN tags are nested within the packet, the system processes and the Defense Center displays the innermost VLAN tag. The system collects and the Defense Center displays VLAN tag information only for MAC addresses that it identifies through ARP and DHCP traffic.
VLAN tag information can be useful, for example, if you have a VLAN composed entirely of printers and the system detects a Microsoft Windows 2000 operating system in that VLAN. VLAN information also helps the system generate more accurate network maps.
Working with User History in the Host Profile
The user history portion of the host profile provides a graphic representation of the last twenty-four hours of user activity. A typical user logs off in the evening and may share the host resource with another user. Periodic login requests, such as those made to check email, are indicated by short regular bars. A list of user identities is provided with bar graphs to indicate when the user login was detected. Note that for non-authoritative logins, the bar graph is gray.
Note that the system does associate a non-authoritative user login to a host with an IP address of that host, so the user does appear in the host’s user history. However, if an authoritative user login is detected for the same host, the user associated with the authoritative user login takes over the association with the host IP address, and new non-authoritative user logins do not disrupt that user association with the host IP address. For more information on the types of users, see Users Database. If you configure capture of failed logins in the network discovery policy, the list includes users that failed to log into the host.
Working with Host Attributes in the Host Profile
You can use host attributes to classify hosts in ways that are important to your network environment. Host attribute values can be positive integers, strings, or URLs. You can also create a list of string values and assign them automatically based on host IP addresses. For information about creating and managing user-defined host attributes, see Working with User-Defined Host Attributes.
The FireSIGHT System includes two predefined host attributes: Host Criticality and Notes. See Working with the Predefined Host Attributes for information about working with these predefined host attributes.
In addition, each compliance white list that you create automatically creates a host attribute with the same name as the white list. Its possible values are Compliant (for hosts that are compliant with the white list), Non-Compliant (for hosts that violate the white list), or Not Evaluated (for hosts that are not valid targets of the white list or have not been evaluated for any reason). You cannot manually change the value of a white list host attribute. For more information on white lists, see Using the FireSIGHT System as a Compliance Tool.
Assigning Host Attribute Values
You can specify positive integers, strings, or URLs as values for existing host attributes.
Tip You can quickly assign host attributes for a host by clicking the Edit link in the Attributes section of the host profile page. This launches a pop-up window containing fields for all the host attributes.
To assign a host attribute value:
Access: Admin/Any Security Analyst
Step 2 Under Attributes , click the name of the host attribute to which you want to assign a value.
Step 3 Enter a value for the attribute or select a value from the drop-down list.
The host attribute value is saved.
Working with Host Protocols in the Host Profile
You can view the protocols running on a host through the host profile. If needed, you can also delete host protocols for a particular host from the profile.
Each host profile contains information about the protocols detected in the network traffic associated with the host.
Descriptions of the protocol and network layer information follow.
The name of a protocol used by the host.
The network layer where the protocol runs (
Network
or
Transport
).
Note that if the host is running a protocol that violates a compliance white list in an activated correlation policy, the Defense Center marks the non-compliant protocol with the white list violation icon ( ).
You can delete a protocol from a host profile to remove protocols you know are not running on the host. Note that deleting a protocol from a host may bring the host into compliance with a compliance white list.
Note If the system detects the protocol again, it re-adds it to the network map and the host profile.
To delete a protocol from a host profile:
Access: Admin/Any Security Analyst
Step 1 In the Protocols section of the host profile, click the delete icon ( ) next to the protocol you want to delete.
The protocol is deleted for that host.
Working with White List Violations in the Host Profile
A compliance white list (or white list ) is a set of criteria that allows you to specify the operating systems, application protocols, clients, web applications, and protocols that are allowed to run on a specific subnet.
If you add a white list to an active correlation policy, when the system detects that a host is violating the white list, the Defense Center logs a white list event—which is a special kind of correlation event— to the database. Each of these white list events is associated with a white list violation , which indicates how and why a particular host is violating a white list. If a host violates one or more white lists, you can view these violations in its host profile in two ways.
First, the host profile lists all of the individual white list violations associated with the host.
Descriptions of the white list violation information in the host profile follow.
The type of the violation, that is, whether the violation occurred as a result of a non-compliant operating system, application, server, or protocol.
The specific reason for the violation. For example, if you have a white list that allows only Microsoft Windows hosts, the host profile displays the current operating system running on the host (such as
Linux Linux 2.4, 2.6
)
The name of the white list associated with the violation.
Second, in the sections associated with operating systems, applications, protocols, and servers, the Defense Center marks non-compliant elements with the white list violation icon ( ). For example, for a white list that allows only Microsoft Windows hosts, the host profile displays the white list violation icon next to the operating system information for that host.
Note that you can use a host’s profile to create a shared host profile for compliance white lists. For more information, see the next section, Creating a White List Host Profile from a Host Profile.
Creating a White List Host Profile from a Host Profile
Shared host profiles for compliance white lists specify which operating systems, application protocols, clients, web applications, and protocols are allowed to run on target hosts across multiple white lists. That is, if you create multiple white lists but want to use the same host profile to evaluate hosts running a particular operating system across the white lists, use a shared host profile.
You can use a host profile of any host with a known IP address to create a shared host profile that your compliance white lists can use. However, note that you cannot create a shared host profile based on an individual host's host profile if the system has not yet identified the operating system of the host.
To create a shared host profile for compliance white lists based on a host profile:
Step 1 Access a host profile from any network map or any event view.
For more information, see Viewing Host Profiles.
Step 2 Click Generate White List Profile .
The Edit Shared Profiles page appears. The fields on the page are pre-populated based on the information in the host profile you accessed.
Step 3 Modify and save the shared host profile according to your specific needs.
For more information on creating shared host profiles for compliance white lists, see Working with Shared Host Profiles.
Working with Malware Detections in the Host Profile
License: FireSIGHT and Malware
The Most Recent Malware Detections section lists the most recent malware events where the host sent or received a malware file, up to 100 events. The host profile lists both network-based and endpoint-based malware events.
If the host is involved in a file event where the file is then retrospectively identified as malware, the original events where the file was transmitted appear in the malware detections list after the malware identification occurs. When a file identified as malware is retrospectively determined not to be malware, the malware events related to that file no longer appear in the list. For example, if a file has a disposition of
Malware
and that disposition changes to
Clean
, the event for that file is removed from the malware detections list on the host profile. For more information on malware events, see Working with Malware Events.
Description of the columns in the Most Recent Malware Detections sections of the host profile follow.
The date and time the event was generated.
For an event where the file was retrospectively identified as malware, note that this is the time of the original event, not the time when the malware was identified.
The host’s role in the transmission of detected malware, either sender or receiver. Note that for endpoint-based malware events, the host is always the receiver.
The name of the detected malware.
The type of file; for example,
PDF
or
MSEXE
.
When viewing malware detections in the host profile, you can view malware events for that host in the event viewer. To view events, click the malware icon ( ).
Working with Vulnerabilities in the Host Profile
The Vulnerabilities sections of the host profile list the vulnerabilities that affect that host.
The Sourcefire Vulnerabilities section lists vulnerabilities based on the operating system, servers, and applications that the system detected on the host.
If there is an identity conflict for either the identity of the host’s operating system or one of the application protocols on the host, the system lists vulnerabilities for both identities until the conflict is resolved.
Because there is no operating system information available for hosts added to the network map based on NetFlow data, the Defense Center cannot determine which vulnerabilities may affect those hosts, unless you use the host input feature to manually set the hosts’ operating system identity.
Server vendor and version information is often not included in traffic. By default, the system does not map the associated vulnerabilities for the sending and receiving hosts of such traffic. However, using the system policy, you can configure the system to map vulnerabilities for specific application protocols that do not have vendor or version information. For more information, see Mapping Vulnerabilities for Servers.
If you use the host input feature to add third-party vulnerability information for the hosts on your network, additional Vulnerabilities sections appear. For example, if you import vulnerabilities from a QualysGuard Scanner, host profiles on your include a QualysGuard Vulnerabilities section.
You can associate third-party vulnerabilities with operating systems and application protocols, but not clients. For information on importing third-party vulnerabilities, see the FireSIGHT System Host Input API Guide.
Description of the columns in the Vulnerabilities sections of the host profile follow.
The name of the vulnerability.
Indicates whether the vulnerability can be remotely exploited. If this column is blank, the vulnerability definition does not include this information.
The name of the operating system, application protocol, or client associated with the vulnerability.
A port number, if the vulnerability is associated with an application protocol running on a specific port.
Keep in mind that for third-party vulnerabilities, the information in the corresponding Vulnerabilities section in the host profile is limited to the information that you provided when you imported the vulnerability data using the host input feature.
When viewing vulnerabilities in the host profile, you can:
- sort the columns in the Vulnerabilities sections by clicking a column heading. To reverse the sort, click again.
- view technical details about a vulnerability, including known solutions, by clicking the name of the vulnerability. See Viewing Vulnerability Details for more information. Note that you can also access vulnerability details from the vulnerability event views or the Vulnerabilities network map.
- prevent a vulnerability from being used to evaluate impact correlations. See Setting the Vulnerability Impact Qualification for more information.
- download patches to mitigate the vulnerabilities discovered on the hosts on your network. See Downloading Patches for Vulnerabilities for more information.
- mark hosts as not vulnerable to individual vulnerabilities if you know that the hosts have been patched. See Setting Vulnerabilities for Individual Hosts for more information.
Viewing Vulnerability Details
Vulnerability details include a technical description of the vulnerability and known solutions.
To access the vulnerability details for a specific vulnerability, select Analysis > Vulnerabilities or Analysis > Third-Party Vulnerabilities and click the view icon ( ) next to the SVID. You can also access vulnerability details from the network map and the host profile.
Descriptions of the fields on the Vulnerability Detail page follow.
The identification number (SVID) that the system uses to track vulnerabilities.
The identification number associated with the vulnerability in the Snort ID (SID) database. That is, if an intrusion rule can detect network traffic that exploits a particular vulnerability, that vulnerability is associated with the intrusion rule’s SID.
Note that a vulnerability can be associated with more than one SID (or no SIDs at all). If the vulnerability does not have an associated SID, this field does not appear.
The identification number associated with the vulnerability in the Bugtraq database ( http://www.securityfocus.com/bid ).
The identification number associated with the vulnerability in MITRE’s Common Vulnerabilities and Exposures (CVE) database ( http://www.cve.mitre.org/ ).
The title of the vulnerability.
Use the drop-down list to enable or disable a vulnerability. The Defense Center ignores disabled vulnerabilities in its impact correlations.
The setting you specify here determines how the vulnerability is treated on a system-wide basis and is not limited to the host profile where you select the value. See Setting the Vulnerability Impact Qualification for information about using this feature to enable and disable a vulnerability.
The date that the vulnerability was published.
The severity assigned to the vulnerability in the Bugtraq database on a scale of 1 to 10, with 10 being the most severe. The vulnerability impact is determined by the writer of the Bugtraq entry, who determines the vulnerability impact level based on his or her best judgment, guided by SANS Critical Vulnerability Analysis (CVA) criteria.
Indicates whether the vulnerability is remotely exploitable.
Indicates whether there are known exploits for the vulnerability.
Summary description of the vulnerability.
Detailed technical description of the vulnerability.
Information about repairing the vulnerability.
Click the arrow to view additional information (if available) about the vulnerability, such as known exploits and their availability, exploit scenarios, and mitigation strategies.
Provides links to downloadable patches for the selected vulnerability.
Tip If direct links to fix or patch downloads appear, right-click the link and save it to your local computer.
Setting the Vulnerability Impact Qualification
If the system reports a vulnerability that is not applicable to your network, you can prevent it from being used to evaluate impact flag correlations. Note that if you deactivate a vulnerability in a host profile, it deactivates it for all hosts on your network. You can, however, reactivate it at any time.
When a conflict exists for the identity of the host’s operating system or one of the applications on the host, the system lists vulnerabilities for both conflicting identities until the conflict is resolved. For more information, see Understanding Identity Conflicts and Resolving Operating System Identity Conflicts.
Note also that the system does not recommend a rule state for an intrusion rule based on a vulnerability that you disable using the Impact Qualification feature. For more information, see Tailoring Intrusion Protection to Your Network Assets.
Tip You can also deactivate vulnerabilities from the network map and from vulnerability event views. For more information, see Working with the Vulnerabilities Network Map and Deactivating Vulnerabilities.
To change the use of a vulnerability across the system:
Access: Admin/Any Security Analyst
Step 1 Access the host profile of a host affected by the vulnerability you want to deactivate.
Step 2 Expand the Vulnerabilities section.
Step 3 Click the name of the vulnerability you want to enable or disable.
A pop-up window appears with the vulnerability details. For more information, see Viewing Vulnerability Details.
Step 4 Select Disabled or Enabled from the Impact Qualification drop-down list to specify how the vulnerability is used.
Step 5 Confirm that you want to change the Impact Qualification for all hosts on the network map.
The vulnerability is enabled or disabled.
Step 6 Click Done to close the vulnerability details pop-up window.
Downloading Patches for Vulnerabilities
If they are available, you can download patches to mitigate the vulnerabilities discovered on the hosts on your network.
To download a patch for a vulnerability:
Access: Admin/Any Security Analyst
Step 1 Access the host profile of a host for which you want to download a patch.
Step 2 Expand the Vulnerabilities section.
Step 3 Click the name of the vulnerability you want to patch.
The Vulnerability Detail page appears.
Step 4 Expand the Fixes section.
The list of downloadable patches for the vulnerability appears.
Step 5 Click Download next to the patch you want to download.
A download page from the patch vendor appears.
Step 6 Download the patch and apply it to your affected systems.
Setting Vulnerabilities for Individual Hosts
You can use the host vulnerability editor to activate or deactivate vulnerabilities on a host-by-host basis. When you deactivate a vulnerability for a host, it is still used for impact correlations for that host, but the impact level is automatically reduced one level.
To activate or deactivate a vulnerability for a single host:
Access: Admin/Security Analyst
Step 2 Next to Vulnerabilities , click Edit .
The Host Vulnerabilities editor page appears.
Tip To view details about a vulnerability, select it and click View. For more information, see Viewing Vulnerability Details.
Tip Use Ctrl or Shift while clicking to select multiple vulnerabilities. You can click and drag to select multiple adjacent vulnerabilities; you can also double-click any vulnerability to move it from list to list.
Working with the Predefined Host Attributes
There are two predefined host attributes that you can assign to each host: host criticality and host-specific notes. Use the host criticality attribute to designate the business criticality of a given host and to tailor correlation policies and alerts based on host criticality. For example, if you consider your organization’s mail servers more critical to your business than a typical user workstation, you can assign a value of High to your mail servers and other business-critical devices and Medium or Low to other hosts. You can then create a correlation policy that launches different alerts based on the criticality of an affected host.
Use the Notes feature to record information about the host that you want other analysts to view. For example, if you have a computer on the network that has an older, unpatched version of an operating system that you use for testing, you can use the Notes feature to indicate that the system is intentionally unpatched.
To set pre-defined host attributes in the host profile:
Access: Admin/Security Analyst
Step 1 Open the host profile for the host for which you want to set a business criticality.
Step 2 Next to Attributes , click the pencil icon ( ).
The Host Attributes pop-up window appears.
Step 3 Form the Host Criticality drop-down list, select the value you want to apply: None , Low , Medium , or High .
Working with User-Defined Host Attributes
The FireSIGHT System includes two predefined host attributes, host criticality and host notes, that you can use to indicate the business criticality of the hosts on your network. If you have other criteria that you would like to use to identify your hosts, you can create user-defined host attributes.
User-defined host attributes appear in the host profile page, where you can assign values on a per-host basis. You can then use those attributes in correlation policies and searches. You can also view the attributes on the host attribute table view of events and generate reports based on them.
Note Host attributes are defined globally rather than per policy. After you create a host attribute, it is available regardless of the policy applied.
Some examples of user-defined host attributes include:
- assigning physical location identifiers to hosts, such as a facility code, city, or room number.
- assigning a Responsible Party Identifier that indicates which system administrator is responsible for a given host. You can then craft correlation rules and policies to send alerts to the correct system administrator when problems related to a host are detected.
Host attributes can be text strings or values selected from predefined lists of text or ranges of numbers. You can also automatically assign values to hosts from a predefined list based on the hosts’ IP addresses. You can use this feature to automatically assign values to new hosts when they appear on your network for the first time.
Host attributes can be one of the following types:
Allows you to manually assign a text string up to 255 characters to a host.
Allows you to specify the first and last number of a range of positive integers, then manually assign one of these numbers to a host.
Allows you to create a list of string values, then manually assign one of the values to a host. You can also automatically assign values to hosts based on the host’s IP addresses.
Note If you auto-assign values based on one IP address of a host with multiple IP addresses, those values will apply across all addresses associated with that host. Keep this in mind when you view the Host Attributes table.
Allows you to manually assign a URL value to a host.
Note that each compliance white list that you create automatically creates a host attribute with the same name as the white list. Its possible values are
Compliant
(for hosts that are compliant with the white list),
Non-Compliant
(for hosts that violate the white list), and
Not Evaluated
(for hosts that are not valid targets of the white list or have not been evaluated for any reason). You
cannot
manually change the value of a white list host attribute. For more information on white lists, see Using the FireSIGHT System as a Compliance Tool.
See the following sections for more information:
- Creating User-Defined Host Attributes
- Editing a User-Defined Host Attribute
- Deleting a User-Defined Host Attribute
Creating User-Defined Host Attributes
The following procedure explains how to create a user-defined host attribute.
Note Host attributes are defined globally rather than per policy. After you create a host attribute, it is available regardless of the policy applied.
To create a new host attribute:
Step 1 Select Analysis > Hosts > Host Attributes .
The Host Attributes page appears.
Step 2 Click Host Attribute Management .
The Host Attribute Management page appears.
Step 3 Click Create Attribute .
The Create Attribute page appears.
Step 4 In the Name field, type a name for the host attribute using alphanumeric characters and spaces.
Step 5 Select the type of attribute that you want to create from the Type drop-down list, as described in Working with Host Attributes in the Host Profile:
- If you are creating a Text or URL host attribute, continue with step 6 .
- If you are creating an Integer host attribute, see Creating Integer Host Attributes.
- If you are creating a List host attribute, see Creating List Host Attributes.
The new user-defined host attribute is saved.
Creating Integer Host Attributes
When you define an integer-based host attribute, you must specify the range of numbers that the attribute accepts.
To create an integer-based host attribute:
Step 1 In the Min field, enter the minimum integer value that can be assigned to a host.
Step 2 In the Max field, enter the maximum integer value that can be assigned to a host.
The new integer-based host attribute is saved.
Creating List Host Attributes
When you define a list-based host attribute, you must supply each of the values for the list. These values can contain alphanumeric characters, spaces, and symbols.
When you create a value for the host attribute, you can also auto-assign it to a block of IP addresses so that when a new host is discovered, it is automatically assigned a value for the host attribute.
To create a list-based host attribute:
Step 1 To add a value to the list, click Add Value .
The List Values section expands.
Step 2 In the Name field, enter the first value you want to add, using alphanumeric characters, symbols, and spaces.
Step 3 Optionally, to auto-assign the attribute value you just added to your hosts, click Add Networks .
The Auto-Assign Networks section expands.
Step 4 Select the value you added from the Value drop-down list.
Step 5 In the IP Address and Netmask fields, enter the IP address and network mask (in CIDR notation) that represent the IP address block where you want to auto-assign this value.
For information on using CIDR notation in the FireSIGHT System, see IP Address Conventions.
Step 6 Repeat steps 1 through 5 to add additional values to the list and assign them automatically to new hosts that fall within an IP address block.
Tip If you do not want to auto-assign list values to the hosts in specific IP blocks, you can manually assign them as described in Working with the Predefined Host Attributes.
Editing a User-Defined Host Attribute
When you modify an existing user-defined host attribute, you can change the definition of a value, but you cannot change the attribute type (text, list, integer, URL). In addition, you cannot modify compliance white list host attributes.
To edit an existing user-defined host attribute:
Step 1 Select Analysis > Hosts > Host Attributes .
The Host Attributes page appears.
Step 2 Click Host Attribute Management .
The Host Attribute Management page appears.
Step 3 Click the edit icon ( ) next to the host attribute you want to edit.
The host attribute page appears with the selected attribute’s settings.
Step 4 Modify any of the settings that you want and click Save .
See Creating User-Defined Host Attributes for more information about the attribute types that you can edit and the values those attributes can contain.
Deleting a User-Defined Host Attribute
Delete a user-defined host attribute to remove it from every host profile where it is used. Note that you cannot delete compliance white list host attributes.
Step 1 Select Analysis > Hosts > Host Attributes .
The Host Attributes page appears.
Step 2 Click Host Attribute Management .
The Host Attribute Management page appears.
Step 3 Click the delete icon ( ) next to the host attribute you want to delete.
The selected host attribute is removed from the system.
Working with Scan Results in a Host Profile
When you scan a host using Nmap, or when you import results from an Nmap scan, those results appear in the host profile for any hosts included in the scan.
The information that Nmap collects about the host operating system and any servers running on open unfiltered ports is added directly into the Operating System and Servers sections of the host profile, respectively. In addition, Nmap adds a list of the scan results for that host in the Scan Results section.
Each result indicates the source of the information, the number and type of the scanned port, the name of the server running on the port, and any additional information detected by Nmap, such as the state of the port or the vendor name for the server. If you scan for UDP ports, servers detected on those ports only appear in the Scan Results section.
Note that you can run an Nmap scan from the host profile. For more information, see the next section, Scanning a Host from the Host Profile.
Scanning a Host from the Host Profile
You can perform a Nmap scan against a host from the host profile. After the scan completes, server and operating system information for that host are updated in the host profile. Any additional scan results are added to the Scan Results section of the host profile.
To scan a host from the host profile:
Step 1 In the host profile, click Scan Host .
The Scan Host pop-up window appears.
Step 2 Click Scan next to the scan remediation you want to use to scan the host.
The host is scanned and the results are added to the host profile.