hbss management roles 2015 - usalearning · hbss management roles 2015. ... based on analyst...

HBSS Management Roles 2015

Table of Contents

Scope ............................................................................................................................................... 3

HBSS Program Intent....................................................................................................................... 4

HBSS Site-Wide Roles ...................................................................................................................... 5

HBSS Functional Groups.................................................................................................................. 7

HBSS Capabilities............................................................................................................................. 8

HBSS Components........................................................................................................................... 9

ePolicy Orchestrator Interface ...................................................................................................... 10

ePolicy Orchestrator Dashboards and Reporting ......................................................................... 11

McAfee Agent ............................................................................................................................... 13

Host Intrusion Prevention -1 ......................................................................................................... 14

Host Intrusion Prevention -2 ......................................................................................................... 16

HIPS Attack Prevention ................................................................................................................. 18

Policy Auditor ................................................................................................................................ 19

Device Control Module ................................................................................................................. 21

Rogue System Detection ............................................................................................................... 22

Asset Configuration Compliance Module ..................................................................................... 24

Administrator Tasks Necessary to Maintain HBSS: ....................................................................... 25

Administrator Tasks Necessary to Maintain HBSS: - 2.................................................................. 26

Information Assurance Management Responsibilities ................................................................. 27

Meshing HBSS Capabilities with IAM/O Responsibilities .............................................................. 29

HBSS Tasks for the IAM/O Include: -1 ........................................................................................... 30

of 49

HBSS Tasks for the IAM/O Include: - 2 .......................................................................................... 32

HBSS Tasks for the IAM/O Include: - 3 .......................................................................................... 33

HBSS Directives Compliance ......................................................................................................... 35

HBSS Change Control Board .......................................................................................................... 36

Compliance with OGS (OPORD 12-1016) ...................................................................................... 38

Enhanced Reporting Dashboards/Queries ................................................................................... 40

Understanding Events Analysis and Tuning - 1 ............................................................................. 41

Understanding Events Analysis and Tuning - 2 ............................................................................. 43

ePO Roll-up Reporting .................................................................................................................. 45

Performing STIG Audits using Policy Auditor ................................................................................ 46

Available Training: ......................................................................................................................... 47

Additional Resources .................................................................................................................... 48

of 49

Scope

UNCLASSIFIED

UNCLASSIFIED

• Program Overview

• HBSS Components

• Tasks for HBSS Administrators

• HBSS Management Responsibilities

• Fulfilling those Responsibilities

• Additional Resources

Scope

2

**002 Instructor: In this course we will be discussing the DOD's Host Based Security System Program Overview, the components that make up the system, the tasks necessary to maintain it, capabilities and considerations for those in a management role, directives that govern the use of HBSS and how management can ensure compliance with those directives, and finally locations where additional training and resources can be accessed.

of 49

HBSS Program Intent

UNCLASSIFIED

UNCLASSIFIED

The Defense Information Systems Agency (DISA), at the request of the United States Strategic Command (USSTRATCOM) and in support of National Security goals established by the President; intends to purchase from industry, a capability that will develop and deploy an automated Host-Based Security System (HBSS) solution(s) that will provide network administrators and security personnel with mechanisms to prevent, detect, track, and report malicious computer-related activities and incidents across all DoD networks and information systems.

The Host Based Security System (HBSS) baseline is built using a flexible, commercial-off-the-shelf (COTS)-based application. This flexible construct allows both vendor components as well as Government built components to be integrated to the baseline as additional capabilities are needed.

HBSS Program Intent

3

**003 The Host Based Security System program was selected by the Department of Defense's Solutions Steering Group to bring proactive protection to each individual system within the DOD. It provides automated capabilities designed to detect, track, and report threats to DOD networks. The primary component of the current HBSS baseline is McAfee's ePolicy Orchestrator. Its flexible architecture has allowed additional components - both from other vendors and designed specifically for the DOD - to be plugged into the central product when additional capabilities have needed to be introduced to the system.

of 49

HBSS Site-Wide Roles

UNCLASSIFIED

UNCLASSIFIED

HBSS Site-Wide RolesRoles Characteristics

HBSS Administrator The HBSS Operator who installs and maintains the HBSS components on the ePO server and the managed servers and workstations, leads HIPS tuning efforts through based on Analyst recommendations and requires training and experience using McAfee ePO and the associated systems such as the SQL database and reporting functions.

HBSS Analyst The HBSS Operator who monitors the security health of the workstations and servers protected by the HBSS product suite, leads HBSS Event Analysis Processes, researches information to identify if a system is under attack or a component is not functioning correctly, and provides regular reports to management to maintain situational awareness.

HBSS Auditor The auditor is responsible for the validation of the overall network security posture for an enclave, site or enterprise and for the identification of the security gaps and weaknesses and the mitigation of those gaps to ensure the readiness of the enclave. He or she also works with the HBSS Reviewer and Administrator to establish the security policies that will be monitored and enforced for compliance and ensures that the Administrator is scheduling and running compliance audits.

HBSS Reviewer Responsible for global oversight of all HBSS event data/Computer Net Defense (CND) as well as asset compliance data and works with the HBSS Auditor, HBSS Administrator and HBSS Analyst to maintain Situational Awareness of the network environment.

4

**004 Before discussing some of the typical HBSS roles within an individual site, it is important to discuss the fact that you may see something completely different at your location. Depending on the size of the organization and the number of individuals that can be assigned to HBSS, the administrator and analyst roles may be combined and be completed by one or multiple individuals. There really are no mandatory requirements when assigning these roles. The Administrator is going to have the most rights to the system and be responsible for updating and maintaining it as well.

of 49

In terms of the Host Intrusion Prevention tuning process, they will be typically making the change to individual signatures after being directed by the Information Assurance Manager or Officer (IAM/O) or Change Control Board (CCB). The Analyst should primarily have read only rights, also known as Global Reviewer within ePolicy Orchestrator, and perform the research necessary to determine whether an alert was a false positive or a legitimate threat. In the tuning process, they will be viewing those alerts and reporting all necessary information to the IAM/O to make a decision or take to the CCB. While it is acceptable to combine administrator and analyst roles as necessary, the HBSS Auditor role should always be performed by a separate individual to ensure separation of duties. Allowing a separate individual to audit the compliance of directives ensures that the administrators are truly doing what they are reporting that they are doing. Auditor roles need to have a thorough understanding of enhanced reporting and permissions to access dashboards and queries in order to verify compliance. In most cases, their permissions should be limited to read only. The HBSS Reviewer role is typically located at tier 2 within the computer network defense chain and primarily reviews rolled up data and works with the Auditor, Administrator, and Analyst to ensure compliance as well.

of 49

HBSS Functional Groups

UNCLASSIFIED

UNCLASSIFIED

HBSS Functional Groups

Organization Responsibilities

USCC/Tier I/ Org Command Center Situational Awareness, Direction and Response

CIO/J6 Situational Awareness, Direction and Response, Staff Readiness

Tier II Computer Net-Defense Service Provider (CNDSP)

Situational Awareness, Information Assurance (IA), Event Analysis

Tier III Security Operations (Includes IAM/IAO)

HBSS Service Operations and Maintenance (O&M), Staff Readiness, Situational Awareness, Local Event Analysis, Diagnosis and Response

Supervisory Staff (Includes IAM/IAO) Staff Readiness: Ensure each functional group is properly 1) staffed and 2) trained

5

**005 It is important to understand who is involved in the bigger picture both as a consumer of the data that an IAM/O's ePolicy Server is sending out but also who is mandating directives for their ePolicy Server. All six organizations listed in the left hand column are or should be receiving, at a minimum, asset awareness and compliance data. This data will assist with the situational awareness aspect. Tiers II and III will also, depending on the classification level of the system, automatically receive threat events or be required to provide a copy for individual site analysis. IAM/Os will receive direction on

of 49

implementation and configuration from the US Cyber Command and possibly their own command or service higher headquarters. Finally, IAM/Os need to ensure that they or their staff are maintaining HBSS, performing analysis, and adhering to all applicable TASKORDs and OPORDs such as 12-1016 and the current HBSS Baseline Order.

HBSS Capabilities

UNCLASSIFIED

UNCLASSIFIED

HBSS Capabilities

6

**006 HBSS is able to block unknown vulnerabilities, maintain an inventory of authorized systems, and notify system administrators about unauthorized devices being plugged into the network, and assist with the

of 49

compliance of CCRIs, IAVMs, STIGs, and INFOCON. Each of these capabilities will be discussed further as the individual components of HBSS are discussed.

HBSS Components

UNCLASSIFIED

UNCLASSIFIED

HBSS Components

1. ePolicy Orchestrator

2. McAfee Agent

3. Host Intrusion Preventiona. Intrusion prevention b. Firewallc. Application Blocking

4. Policy Auditor

5. Device Control Module

6. Rogue System Detection

7. Asset Configuration Compliance Module

8. ArcSight and Asset Publishing Service

9. Operational Attribute Module

7

**007 HBSS is made up of several different products that bring different functionalities to the system. However, these unique products also work together to create a whole system that is more secure than the sum of each product's functionality alone through defense in depth. With the exception of the ArcSight and Asset Publishing Service components, each of these products will be

of 49

discussed further throughout the remainder of this course. ArcSight and the Asset Publishing Service both serve as an additional mechanism by which reporting is completed for compliance with USCYBERCOM. Finally, the Operational Attribute Module, or OAM, allows assets managed by an ePO to be associated with the functional owner attributes such as AOR, CNDSP, CC/S/As, POC, etc.

ePolicy Orchestrator Interface

UNCLASSIFIED

UNCLASSIFIED

ePolicy Orchestrator Interface

8

Version and Build Help

Customizable Navigation Bar

Displayed Screen

Menu

**008 All of the products communicate threats to, and are managed from, one central location within ePolicy Orchestrator. This decreases the administrative overhead felt by

of 49

Information Security professionals in the past. Because your system administrators should be performing the majority of the tasks within the ePolicy Orchestrator and your role may be to manage those system administrators and their actions, our primary focus for the ePolicy Orchestrator will be on the dashboards and reports. For additional information on the other functions of the ePolicy Orchestrator interface, please refer to the other training opportunities that will be discussed later within this course.

ePolicy Orchestrator Dashboards and Reporting

UNCLASSIFIED

UNCLASSIFIED

• Three Types:–Active queries and dashboards

• Constantly updated–Exportable reports

• A point in time–Rolled-up reporting

• Mandatory per OGS (OPORD 12-1016)• Used to report asset and compliance information to the USCYBERCOM

ePolicy Orchestrator Dashboards and Reporting

9

**009 There are three different types of reports that are used in ePolicy

of 49

Orchestrator. The first, active queries and dashboards, is updated as the queries are run on the ePO server. Dashboards are made up of multiple queries grouped together to display at the same time to provide a greater overall picture. These active queries and dashboards can only be accessed when logging into the server with an individual user account that should be established by your global or system administrator. Results of these queries and dashboards are also limited by the permission sets applied to each individual account. McAfee provides dozens of queries that are included with the baselines. The DOD also has included queries specifically useful to ensuring compliance with DOD directives. Administrators should ensure that refresh rates for dashboards are in compliance with STIG guidelines. Exportable reports can be generated based off of any of the active queries. The benefits of exportable reports are that they do not require logging into the system and therefore can be based off of the permissions of an administrator. However they are only valuable when they are updated frequently so that users of those reports are not basing decisions off of old data. Reports can be scheduled within ePO for automatic updates and transmission to their end destination via email. And finally, there are rolled-up reports mandated per OPORD 12- 1016. These reports are used by a site's CNDSP and USCYBERCOM to ensure compliance and maintain situational awareness of assets

of 49

throughout the DOD. Rolled-Up reports are scheduled and sent to Tier 2 ePO servers automatically in the same way that exportable reports are. HBSS management and system administrators should be reviewing the same reports as are being rolled- up to ensure that they are within compliance.

McAfee Agent

UNCLASSIFIED

UNCLASSIFIED

• The active component on every managed client–Communicates between endpoint products

on the client and the ePO server–Installs and configures the endpoint product–Runs update tasks and enforces policy on

the client–Reports clients’ settings and tasks–Runs silently if required

• Windows Agents can be assigned Super Agent Distributed Repository (SADR) status

McAfee Agent

10

**010 The McAfee Agent provides local management of all HBSS products collocated on the host. It is responsible for downloading and installing individual HBSS products. It also downloads and sends to those products any configuration changes

of 49

or updates such as threat signatures or service packs. Finally, it retrieves the events, or feedback, from each of the products and returns them to the ePolicy Orchestrator server to be processed and addressed. The McAfee Agent can also take on a role as a super-agent distributed repository, or SADR, to lighten the load from the ePO server when other McAfee Agents send a request to pull down the latest updates.

Host Intrusion Prevention -1

UNCLASSIFIED

UNCLASSIFIED

• Intrusion Prevention System – Defends systems against malicious activity– How Host IPS Works:

• McAfee Host IPS validates system calls made into the different layers of the OS and kernel

• Calls are matched to a constantly updated database of both specific and generic attack behaviors

• If an attack is found, pre-emptive action is automatically taken ranging from ‘Log Event’ to ‘Prevent’

• All activity on the host is seen and analyzed, and is not impaired by encryption, switched data or reliance on system log information


• HIPS User Interface, Passwords, Troubleshooting, Alerts, etc

General Polices

•IPS Options – On (McAfee Default), Off, Adaptive

•IPS Protection – Reaction (Prevent, Log, Ignore)

•IPS Rules - Signatures

IPS Policies

11

**011 The Host Intrusion Prevention component performs three different functions - Intrusion Prevention,

of 49

Application Blocking, and Firewall Tasks. The Intrusion Prevention System of the Host Intrusion Prevention component protects above and beyond what Virus Scan is able to protect a system against by reducing the risk between the time a new virus is released and signatures are created by analyzing the behavior of authorized applications for malicious actions. IPS compares system actions against signature and behavior based actions contained in its database of malicious activity. It is important to understand the policies that describe to IPS how to behave to ensure that your site is in compliance with DOD directives. For instance, while it was acceptable for a period of time to log potentially malicious actions instead of preventing them, compliance with OPORDER 12-1016 requires that high and medium severity signatures be set up to prevent those from taking place. The IPS policies also allow system administrators to access the individual signatures and modify them to mitigate false positives after they have been reviewed by the organizations change control board. There are also general policies to configure settings for the entire Host Intrusion Prevention product. These settings include things such as whether or not users are able to see the graphical user interface, a password to make changes within that interface, and the ability to troubleshoot to name a few. Most of these settings need to be configured

of 49

IAW the HBSS Checklist that can be retrieved from DISA FSO's IASE website. For more information on the configuration of HIPS and IPS, please see the HBSS system administrator training referenced at the end of this course.


UNCLASSIFIED

UNCLASSIFIED


• Firewall • Ensures that only authorized

network communication is allowed

• Connection or Location Aware Groups • Blocks systems from

communicating on unauthorized networks

• Port Whitelisting • Allows only specific applications

over communication ports

Application Blocking Polices

•Firewall Rules•Firewall Options

Firewall Policies

• Application Blocking and Whitelisting

• Ensures that only authorized applications are allowed to run• Utilized by enabling 2 host intrusion prevention signatures• Customization of those signatures aided by using the NSA Whitelist tool

12

**012 Besides the same functionality that any other standard firewall can provide, the HIPS firewall has two additional features that help to ensure security. Using connection or location aware groups, it can also ensures that it can only communicate when placed on the proper network, such as a NIPRNET machine unable

of 49

to communicate on a SIPRNET Network. Port Whitelisting mitigates threats of malicious applications communicating sensitive data out or being used to attack other systems by blocking their attempts to use ports that are required to be open for critical applications to use. The final function of Host Intrusion Prevention is that of application blocking using specific intrusion prevention signatures. These signature numbers are 6010 and 6011. The Department of Defense uses application blocking to perform whitelisting so that only preauthorized applications are allowed to execute on a system. Application blocking also shields those authorized applications from being run by malicious activity. Customization of those signatures can be made easier using the NSA whitelist tool but it is best used when dealing with a smaller site. Alternatively, the Windows AppLocker feature is also authorized for use as an application blocker as well.

of 49

HIPS Attack Prevention

UNCLASSIFIED

UNCLASSIFIED

HIPS Attack Prevention

13

**013 Here we can take a look at why Host Intrusion Prevention is so effective when configured completely and properly. When an attack is executed, it will first be compared against multiple levels of antivirus protection, the light blue color, to determine if it is a known threat or not. If it is unknown or not covered by any levels of AV protection, we then rely on Host Intrusion Prevention - shown in the dark blue color - to stop the attack. The attack will go up against all three of Host Intrusion Prevention's functionalities. First it will be compared against behaviors that IPS

of 49

sees as being malicious, and then it will either be stopped because it is not on the authorized applications list or because it is attempting to access an authorized application in a malicious way. And finally, if all else fails, the attack will execute but it will not be able to exfiltrate sensitive data or be used to attack other systems because it is not an authorized application allowed to talk on the network with the help of the HIPS firewall.

Policy Auditor

UNCLASSIFIED

UNCLASSIFIED

• Assists with CCRI, IAVM and STIG Compliance

• Ensures the integrity of specified files

• Provides the ability to search for malicious files

• Standardized and custom checks capability

• Detailed compliance assessment of IT Controls – Password settings, account privileges, audit settings, file permissions, patch status

• Use of XCCDF and OVAL standards

• Audit files can be downloaded from:

http://iase.disa.mil/stigs/scap

Policy Auditor

14

**014 The next component of the host based security system is Policy Auditor. Policy Auditor, or sometimes

of 49

referred to as just PA, is used to ensure the compliance of a system's files, applications, settings, and configurations. It uses industry standard extensible configuration checklist description formats, or XCCDF and the open vulnerability assessment language, or OVAL, to allow system administrators to import policies generated by groups other than McAfee. Policy Auditor has and will continue to become a very useful tool for the Department of Defense by providing a centralized and manageable interface through which to perform audits for items defined in Command Cyber Readiness Inspections, or CCRIs; Information Assurance Vulnerability Managements, or IAVMs; and Security Technical Implementation Guides, or STIGs. The latest versions of the files that can be imported into Policy Auditor to perform the STIG checks are located at http://iase.disa.mil/stigs/scap. Finally, Policy Auditor can also ensure the integrity of critical system files and search for files known to be malicious in nature.

of 49

Device Control Module

UNCLASSIFIED

UNCLASSIFIED

• Prevent unauthorized use of any device that can be plugged into a system

• Provides CD and DVD write blocking to mitigate internal threats

• Centrally deploy and manage security policy to prevent confidential data loss via removable media.

Device Control Module

15

**015 The Device Control Module, or DCM, component of HBSS contains a subset of features sold as McAfee's Data Loss Prevention product. By entering the DOD's license key, only the DCM features are made available for use. While the Device Control Module cannot physically stop someone from plugging a device into any system, it can make that device completely unusable to the operating system. Within the Department of Defense, it is mandated that all removable storage drives be blocked with the exception of drives that are tightly controlled and FIPS compliant. DCM allows system administrators to specify which drives are allowed

of 49

based on specific hardware ids, vendor ids and serial numbers. And finally, the Device Control Module can also be used for making CD and DVD drives able to retain the ability to read data but not be used to write data to mitigate the risk of insider threats removing sensitive files.

Rogue System Detection

UNCLASSIFIED

UNCLASSIFIED

• In HBSS, a rogue system is any machine physically connected to the network without a McAfee agent talking to the ePO server.

• Includes printers, switches, VOIP phones, etc. (exceptions can be made for these devices to remove them from the active list)

– IAW OGS (OPORD 12-1016) all subnets with HBSS compatible assets need to be covered by at least one Rogue System Sensor

• Assists with the detection of Cross Domain Violations

Rogue System Detection

ePolicyOrchestrator

RogueSensor

3 New RogueSystems

Detected !!

RogueSensor

RogueSensor

16

**016 Another component of HBSS that we will discuss is Rogue System Detection, or RSD. Rogue System Detection requires that one or more sensors be place on each subnet that contains HBSS compatible assets and optionally the DHCP server handing out IP addresses as well. When any

of 49

new system is added to the network - to include printers, switches, phones, and other devices - the RSD sensors will see these systems attempting to communicate and notify the ePolicy Orchestrator Server. System administrators can then create exceptions for systems that cannot have the McAfee agent installed on them or they can push the agent to systems that require the agent for compliance. The Rogue System Detection component is also useful for detecting Cross Domain Violations where someone may have either intentionally or accidently placed a SIPRNET system on the NIPRNET or vice versa. The Asset Configuration Compliance Module is now a part of HBSS baselines. Deployment of ACCM is optional per current OPORD guidance.

of 49

Asset Configuration Compliance Module

UNCLASSIFIED

UNCLASSIFIED

• ACCM scans all current windows versions for:– Installed Software– Changes in Software between scans– Installed Patches– Changes in Patches between scans– Network Configuration on each interface– Network Configuration changes

• By comparing vulnerability announcements with ACCM data, administrators can determine applicability and prioritize patch updates.

• When a threat only affects specific software packages, ACCM identifies the subset of systems susceptible to prioritize defensive action.

• When pushing critical security updates out to the network, ACCM can be used to verify success using a third-party method.

Asset Configuration Compliance Module

17

**017 ACCM is installed and runs based on client tasks similar to many of the other components of HBSS. It is used to perform an inventory of the current and changes made to software, current and changes made to patches, and current and changes made to network configurations. For sites that currently lack such an inventorying capability it will help them understand what is on their systems and therefor the risks associated with those systems. The data can also be correlated with vulnerability announcements to prioritize patch updates or take actions when systems are found to

of 49

be vulnerable but there are not patches yet available.

Administrator Tasks Necessary to Maintain HBSS:

UNCLASSIFIED

UNCLASSIFIED

• Ensure that:– All systems are checking in.– Client workstations and servers have updated AV, AS, HIPS, Policy

Auditor, etc.– HBSS modules are at current version.– Asset Awareness data is in line with site expectations.– The HBSS Server has necessary connectivity to the DoD Patch

Repository for updates.– All required IT staff have necessary access to the appropriate HBSS

Servers (For Build 1: HBSS Service in DECC’s).– The ArcSight connector is functioning.– The ePO roll-up is functioning.– HBSS policies are up-to-date.– HBSS policies are properly enabled and active.

Administrator Tasks Necessary to Maintain HBSS:

18

**018 Now that we have covered the individual components and directives of HBSS, we will describe the tasks necessary for system administrators to maintain HBSS. More complete details and step-by-step directions on performing these tasks can be pulled from the additional training sources referenced at the end of this course. System administrators need to ensure that they are in compliance with the directives previously mentioned by making certain that all systems have an agent and are

of 49

actively communicating with the ePO server, that those systems are using the latest products and policies, and that all HBSS server settings are configured IAW the directives. The HBSS Server also needs to be reporting up properly using the built- in rollup reporting, ArcSight, and APS.

Administrator Tasks Necessary to Maintain HBSS: - 2

UNCLASSIFIED

UNCLASSIFIED

• Ensure that:–HIPS alerts are reviewed.–Anti-virus and anti-spyware alerts are reviewed.–Device Control Module alerts are reviewed.–RSD sensors have coverage of all subnets containing HBSS

compatible systems and are operational.–Queries are run for inactive agents and they are resolved.–A standard set of reports and dashboards is established to

inform management.–Management is provided daily, weekly and monthly information

updates according to the agreed schedule.–Security intrusions and violations are reported immediately.–AV DAT files are being updated.–Server tasks are completing successfully.

Administrator Tasks Necessary to Maintain HBSS: - 2

19

**019 System administrators need to be reviewing alerts from individual products, they need to ensure that all subnets are properly covered with Rogue Sensors, and they need to be providing management and senior leaders with agreed upon reports. It may be beneficial for you to print out

of 49

these slides covering the tasks so that they can be used as a checklist or repurposed for position policies.

Information Assurance Management Responsibilities

UNCLASSIFIED

UNCLASSIFIED

Information Assurance Management Responsibilities

• Duty highlights• Develop and Issue Security Procedures Governing Information Systems

Operations• Confirm Compliance with Information System Security Policies and

Procedures• Monitor and Audit Information Systems• Report information System Security Violations and Intrusions• Establish Information System Configuration Management Procedures• Ensure Education, Training, and Awareness Program is operational

• Act as a bridge between IA personnel and IA mandates (ext/int)

• Provide oversight to IA personnel and system administrators in policy creation

Ex: Verify SA is not creating exception policies which may introduce risk

20

**020 Now that you have an understanding of what makes up the Host Based Security System and its role in computer network defense, ways in which Information Assurance Management and Officers should interact with the system will be described. According to DOD 8500.2, the Information Assurance Managers and Officer are responsible for all security procedures that involve Information Systems. Additionally, they are responsible for ensuring

of 49

compliance with the mandates directed from USCYBERCOM to their individual command and everywhere in between. The Host Based Security System is a framework of tools that allows them to ensure compliance with these directives, audit all of their information systems that are attached to the network, and identify and automatically report violations and intrusions. In order to tune HBSS, system administrators need to create exceptions to, or modify, the default signatures when they limit the functionality of the system's mission critical actions. These exceptions and modifications need to be reviewed and approved by the IAM/Os before introducing them into the system as they are putting that particular application or system at risk for exposure to attacks.

of 49

Meshing HBSS Capabilities with IAM/O Responsibilities

UNCLASSIFIED

UNCLASSIFIED

Meshing HBSS Capabilitieswith IAM/O Responsibilities

1. Confirm compliance with Information System Security Policies and Procedures• Use ePO reporting to ensure all systems have HIPS, FW, and AV

installed• Use DCM to ensure unauthorized USB devices are not connected to

managed systems

2. Monitor and Audit Information Systems• Use ePO reporting to show potential malicious behavior• Use RSD to alert of potentially unauthorized systems

3. Report information System Security Violations and Intrusions• Identified malicious events can be illustrated in report form

4. Establish Information System Configuration Management Procedures• Use PA to see if patches have been applied • Use PA to run audits based on STIG

21

**021 While the Host Based Security System helps Information Assurance Managers and Officers to perform their jobs, there are also responsibilities that come with having HBSS within their environment. Information Assurance Managers and Officers need to be completely aware of the directives and have the ability to show compliance with those directives using the reporting features of HBSS. They need to be able to generate or request reports showing that all of the components and features of HBSS are installed, configured properly, and up to date. IAM/O's also need to ensure that actions are being taken when new

of 49

devices show up that do not have the McAfee Agent installed on them and are, therefore, not reporting to the ePolicy Orchestrator server. Policies and procedures also need to be in place to take action when a legitimate threat has been identified. These policies and procedures will differ depending on the organization and whom they report to. Finally, IAM/O's need to implement procedures to perform auditing of connected information systems, which we will talk more about on another slide.

HBSS Tasks for the IAM/O Include: -1

UNCLASSIFIED

UNCLASSIFIED

HBSS Tasks for the IAM/O Include: -1

•Ensuring that all HBSS (blocked and detected) alerts from HIPS, AV/AS, RSD, etc. are quickly and properly diagnosed utilizing POCs from other functional groups as necessary.

•Making certain that incident response actions are properly coordinated throughout the functional areas and in accordance with incident reporting channels. Note: Take high severity alerts as priority.

•Ensuring that helpdesk tickets and alerts are reviewed and correlated with HBSS system changes and alerts.

•Resolving any false-positive HIPS events promptly.

•Confirming that all McAfee Agents are checking in.

22

**022 While the Information Assurance

of 49

Managers and Officers may not be the primary administrator for HBSS, they still should be very familiar with the system in order to perform all of these tasks that should fall within their responsibility. IAM/Os should not just assume that there is no need to be reviewing the alerts because a signature was detected and effectively blocked or because nobody is complaining that their applications have stopped working properly. Every triggered signature needs to be investigated thoroughly to determine the cause and whether or not it was a legitimate threat or if mission critical actions may have caused it. IAM/Os will need to coordinate with many other groups when making these types of decisions. Response actions to these alerts will be specific to an organization and the policies and procedures in place from their higher headquarters. For example, the Combatant Commands may have different incident response procedures than what the Air Force has. However, all organizations have a requirement to report an incident up to someone else. The IAM/O has the responsibility of making certain that these reporting channels are in place and being followed. Alerts should also be coordinated with the helpdesk and procedures should be in place for prompt resolution of false positive events that may be stopping mission critical actions from executing properly. Finally, the security posture of each system can only be determined when it is properly checking in. Confirming that the agent on all systems is functional and accounted for is the only way to ascertain the security posture of the entire organization.

of 49

HBSS Tasks for the IAM/O Include: - 2

UNCLASSIFIED

UNCLASSIFIED


•Ensuring that sufficient testing is performed for HBSS directives, system changes, and policies.

•Mandating that there is a Change Management group that meets regularly to review various HBSS changes to various system baselines (i.e. HIPS Tuning process, HBSS point product updates, new policies applied, etc.) Or having the group identify pre-determined courses of action.

•Ensuring that HBSS system configuration changes, policies, etc. are disseminated to all necessary functional areas and help desks for implementation or awareness purposes.

•Notifying CNDSP Tier II and above of any HBSS ePO server outages, issues preventing roll-up functionality, or loss of connectivity to the Patch Repository

23

**023 The Host Based Security System is not a set it and forget it type of tool. Over time, changes will need to be made to the system both to comply with current and new directives, as well as, as information technology changes within the internal environment. Changes to the Host Based Security System need to be thoroughly tested before implementing them across the entire organization. Preferably changes will be tested in an offline lab network but if that resource is not available to the system administrators, they should be tested on a few, non- mission critical systems first. Change management groups or boards

of 49

should be in place to make decisions and consider the implications of a change beforehand. ALL system administrators, management, help desk personnel, and anyone else directly involved with information technology should be notified that a change is being made.


UNCLASSIFIED

UNCLASSIFIED


•Confirming that the HBSS server is properly configured/deployed per the HBSS STIG and other directives.

•Reviewing Site Compliance with OGS (OPORD 12-1016) and CTO-133 (SIPRNET)

•Ensuring that the HBSS server has the current baseline per the HBSS PMO.

•Verifying that Asset Awareness data is in line with site expectations.

•Providing management with daily, weekly and monthly information updates according to the agreed schedule.

•Making certain that the database was successfully backed up.

24

**024 Following the HBSS Security Technical Implementation Guidelines, or STIG, on the Information Assurance Support Environment, or IASE, website will confirm compliance with DOD mandated settings for the ePO server, McAfee Agents, and all HBSS point products. These settings

of 49

ensure that the ePO Server and client systems are functioning at the highest level of security possible. IAM/Os should be sure to check for updated STIGs quarterly. In addition to the STIGS, the ePO Server and clients checking into it need to be compliant with US Cyber Command directives. OP Order 12-1016 and CTO-133 are two of these directives. The directives and STIG also state that HBSS should be set up in accordance with the latest baseline. HBSS baselines and maintenance releases ensure that updates are being tested with the STIG'd version of HBSS for functionality before releasing it for widespread use. They also package numerous updates together so that they are easier for the HBSS administrators to apply all at one time instead of keeping watch for updates continuously. Verifying that HBSS Asset Awareness data is in line with expectations involves seeking consistency between the number of systems reported by Active Directory and other software and HBSS. It also provides the opportunity to seek out justification for systems without any of the required security products or that are not compliance for any other reason. Reports desired by management of an organization may be unique to each individual site. Management should be, at the least, aware of the reports that they have available to them. Finally, Ensuring that the database is backed up is not only a great disaster recovery best practice, it is also mandated by the

of 49

HBSS Directives Compliance

UNCLASSIFIED

UNCLASSIFIED 25

HBSS Must be Compliant with:

• DoD IA Enterprise Solutions STIG• Windows STIG • Windows Server Checklist• HBSS Checklist • OGS (OPORD 12-1016)• Current HBSS Baseline Order

HBSS Supports Compliance of:

• FRAGO 11 - USB Control

• DOD 8500.2

• USCC TASKORD 14-0185

HBSS Directives Compliance

**025 There are multiple directives that those dealing with HBSS in any way need to be aware of to ensure compliance. OP ORDER 12-1016, available from the USCYBERCOM SIPR website mandates that HBSS is fully implemented, that it is running securely, and that it is reporting ultimately to USCYBERCOM. It is also very important that the HBSS server itself be secure because access to the individual server by an attacker would provide the ability to Denial of Service an entire command. To ensure that the HBSS Server is secure, system administrators need to make certain that they set up the server in accordance with these

of 49

STIGS and Checklists that can be found on DISA's IASE website. Additionally, HBSS assists Information Assurance Managers and Officers with compliance with the FRAGO 11, DOD 8500.2, and USCC TASKORD 14-0185.

HBSS Change Control Board

UNCLASSIFIED

UNCLASSIFIED

• IAM/Os need to ensure that procedures are in place to:–Add McAfee agents and all products to systems prior to

coming on to the network (mandated per OGS OPORD 12-1016)

–Remove systems from the ePO server when they are being removed from the network

–Temporarily log instead of block threats, when necessary, to allow modifications to be made to systems (patches)

HBSS Change Control Board

26

**026 As was mentioned previously, a change control board or group should be in place to ensure that decisions are not made solely based on the needs of those implementing HBSS. ALL system administrators, management, help desk personnel, and anyone else directly involved with the information technology

of 49

should a part of the decision to roll out a new level of protection that could affect how those systems operate. Procedures should be in place to ensure that systems are joining the network already protected with all of the products up and running properly the first time that they check in to the ePO server. There should also be procedures in place to notify the HBSS system administrators when a system is removed from the network so that it does not report noncompliance within ePO. System administrators performing system maintenance or patching need to work with the HBSS administrators to ensure that HBSS protection allows them to perform the modification.

of 49

Compliance with OGS (OPORD 12-1016)

UNCLASSIFIED

UNCLASSIFIED 27

Compliance with OGS (OPORD 12-1016)

• The McAfee Agent, Host Intrusion Prevention, Policy Auditor, Device Control Module, and an approved Antivirus package must be deployed to all compatible systems. (All others are optional at this time)

• Block all High and Medium Severity HIPS Signatures.• Waivers can be created for individual medium signatures but must be signed

off by the local O-6/GS-15 and reported to the appropriate CNDSP

• Block or Log Low Severity HIPS Signatures.• Waivers can be created for individual low signatures and signed off by the

local IAM

• Changes to the default severity levels of high or medium HIPS Signatures are prohibited.

• Location or connection aware groups using the HIPS firewall must be enabled to prevent cross domain violations.

• Application whitelisting must be enabled on Windows Servers.

**027 In 2012, OPORD 12-1016 superseded previous US Cyber Command HBSS Directives mandated by FRAG ORDER 13. While the OPORD should be reviewed in its entirety on the SIPRNET, the intent here is to describe the key points. Ensuring that the latest versions of mandated products are on all compatible systems, is the first step and most important to ensure compliance. These products should be installed prior to the systems being attached to the network. Once McAfee Host Intrusion Prevention is installed, mandates require that high and medium severity signatures be blocked while sites have the option to

of 49

block or log low severity signatures. Exceptions for those signatures deemed as false positives can be approved as waivers signed off by the appropriate authorities depending on the severity level. Host Intrusion Prevention provides the capability to change a severity level. Changing a high or medium severity level to low or informational could effectively disable that signature and circumvent the waiver process. These changes are prohibited. The Host Intrusion Prevention firewall allows location or connection aware groups depending on the version of HIPS which ensure that a system can only communicate on the network that it is supposed to be attached to. Enabling the firewall and specifically those groups is mandatory and prevents cross domain violations. Finally, while other mandates may enforce application whitelisting or blocking all applications other than those reviewed and given explicit permission to run on individual user systems, the OPORD specifically mandates that it must be enabled on Windows servers.

of 49

Enhanced Reporting Dashboards/Queries

UNCLASSIFIED

UNCLASSIFIED

Enhanced Reporting Dashboards/Queries

• Assist HBSS Administrators, Analysts, Auditors, and Reviewers with ensuring compliance with OGS (OPORD 12-1016)

• Incorporated into current HBSS maintenance release baselines

28

**028 Dashboards have been developed by DISA to assist Information Assurance Managers and Officers with ensuring that they are in compliance with the OPORD 12-1016 directive. These dashboards are available in all recent baselines or maintenance releases of HBSS. Users of ePolicy Orchestrator will only need to configure their own dashboards view to include these dashboards.

of 49

Understanding Events Analysis and Tuning - 1

UNCLASSIFIED

UNCLASSIFIED


HIPS Event Observed

Research Event and System History

Contact Responsible Functional Group

HIPS Tuning Process Incident Response Process(IAW CJCSM 6510.01)

Event Diagnosis Decision Tree

NO YES

Incident

Via ePO Dashboard

Via ePO Console

29

**029 As was mentioned previously, Host Intrusion Prevention is not a set it and forget it tool. Proper tuning is necessary to ensure that HIPS does not reduce the functionality of DOD systems while still maintaining a high level of protection and security. Each event is either going to be a legitimate threat, otherwise known as an unauthorized activity, or a false positive which is an authorized activity. The HBSS Administrator or Analyst should not be the only person involved with making these decisions. For example, if the Microsoft Exchange server application is generating an event, the details of that event and signature need to be

of 49

discussed amongst the Exchange administrator, HBSS Analyst or Administrator, and Information Assurance Manager or Officer to determine if it is a false positive or legitimate threat. Then the Information Assurance Manager or Officer needs to make the decision as to whether that event requires further investigation or an exception can be created so that it does not continue to generate events or limit the functionality of Microsoft Exchange if applicable. Establishing exceptions with a high level of granularity will ensure proper security. In the previous example, the HBSS administrator would want to create an exception so that the Exchange server by name and only the Exchange server, the Exchange process triggering the event and only that process, and any other parameters that can be defined are set so that that event is still triggered when other applications or systems violate that same signature.

of 49


UNCLASSIFIED

UNCLASSIFIED

1. If the event is an unauthorized behavior, consult your site’s Incident Response Process.

2. If the event is an authorized behavior, proposed exceptions or Trusted Application policy changes need to be reviewed by the IAO/IAM in accordance with your site’s Change Management Process. – Just because an event is not “breaking” an application does not mean an

exception or policy change should not be created. Reducing the number of events improves system health and allows new events to be easily seen.

3. Before implementing the change: – Notify your system owners – Notify your organizational help desk – Notify your CNDSP as they will receive new alerts


30

**030 Legitimate threats need to be investigated in accordance with the site's Incident Response Process. If your site does not have a process in place, refer to CJSM 6510.01 to begin establishing one. As described on the previous slide, individual exceptions can be created based on specific details that are triggering a HIPS signature. However, if, for example, a critical application such as Windows explorer itself were to trigger a lot of events and be completely nonfunctional with HIPS enabled, then that process could be set as a trusted application. But one must keep in mind the difference between critical to operating such as Windows

of 49

explorer and something like Microsoft Outlook. Just because Microsoft Outlook may trigger a lot of events does not mean one should consider making it a trusted application because of the number of vulnerabilities present within it throughout history. In the case of Microsoft Outlook, HBSS Administrators would want to create exceptions for individual signatures on a case by case basis. Even if an event is not "breaking" an application, your site will still need to create an exception or set a particular application triggering that signature as a trusted application in order to reduce the number of false positive events being sent to the ePolicy Orchestrator server. Ideally, the tuning process will reduce the events showing up to only legitimate threats until new software is added and the tuning process begins again. Finally, before any changes are implemented, the HBSS roles involved will need to notify anyone that may be affected by the change.

of 49

ePO Roll-up Reporting

UNCLASSIFIED

UNCLASSIFIED

• Mandatory for SIPR per OGS (OPORD 12-1016)– No event data feed to USCYBERCOM for unclassified networks at this time

• Used to report asset and compliance information to the USCYBERCOM

• IAM/Os should be reviewing the reports rolling up to USCYBERCOM

ePO Roll-up Reporting

31

**031 In accordance with OPORD 12-1016, roll-up reporting to USCYBERCOM is required to be in place and functioning properly on the SIPRNET. Individual commands and services may mandate event data feeds on NIPRNET separately. Some of the things that are being reported up are system information, compliance with the server showing that a system has all of the necessary products and that they are up to date, and events. Information Assurance Managers and Officers should be reviewing these same reports to ensure that they are in compliance. They should also be ensuring that the reports are in fact functioning properly.

of 49

Performing STIG Audits using Policy Auditor

UNCLASSIFIED

UNCLASSIFIED

• Benchmarks available for approved operating systems

• Updated quarterly

• PKI protected audits include the IAVMs and publicly accessible audits

do not

• Contain a combination of automated and manual checks

• Downloadable from DISA FSO’s IASE website

• Will assist IAM/Os with Continuous Monitoring

Performing STIG Audits using Policy Auditor

32

**032 DISA has automated as many STIG checks as possible to work within Policy Auditor. The STIG benchmarks and checks for Policy Auditor can be downloaded from the IASE website. There are two versions of each available operating system. One that contains the IAVMs and one that does not. The STIGS that contain the IAVMS are PKI protected and a CAC will be required to download them. There are benchmarks and checks available for approved operating systems. After downloading, the Oval file will be imported on the checks tab of Policy Auditor and then the XCCDF XML will be imported into the benchmarks tab. For more

of 49

information, refer to the DISA's "Policy Auditor Benchmark TTP and Process Document" available for download on the HBSS Pages at the end of this presentation.

Available Training:

UNCLASSIFIED

UNCLASSIFIED

Available Training:

Classroom Training• 4-Day 201 Administrator Class

• 4-Day 301 Advanced Administrator Class• 4 Day 501 Analyst class

• Classes are taught weekly both CONUS and OCONUS and the schedule and signup instruction can be viewed at

https://disa.deps.mil/ext/cop/iase/classroom_training/

Information Assurance Support Environment (IASE)

• The IASE Cyber Tools Training Portal is designed to provide students with an online learning environment consisting of

previously recorded training sessions tailored for specialized cyber tools training.

http://iase.disa.mil/Pages/index.aspx *PKI

HBSS Training

33

Federal Virtual Training Environment FedVTE is a flexible, multimedia, e-learning environment that users can access their job-related skills through videotaped lectures, demos, and hands-on labs. https://fedvte.usalearning.gov/

• HBSS Management Roles • HBSS Compliance CND Directives • HBSS 201 Administrator • HBSS 301 Advanced • HBSS 501 Analyst

**033 The majority of the HBSS training can be completed in a live classroom based environment or in FedVTE's environment. For System Administrators and Analysts there is a 30 hour 201 basic administrator course, a 301 advanced administrator course and a 501 Analyst course. Class locations and dates can be reviewed at the link provided. Only the basic administrator course is

of 49

required for a certificate that is mandated for DOD HBSS system administrators to work with the system. The IASE Cyber Tools Training Portal provides training on specific topics as they are identified to fill training gaps within the DOD.

Additional Resources

UNCLASSIFIED

UNCLASSIFIED

Additional ResourcesHBSS front door

NIPR: www.disa.mil/hbssSIPR: www.disa.smil.mil/hbss

HBSS PagesNIPR: https://east.esps.disa.mil/DISA/ORG/MA5/hbs/hbss

SIPR: https://www.intelink.sgov.gov/wiki/hbss

Patch Repository: https://patches.csd.disa.mil

STIG Guidance Page on DKO: http://iase.disa.mil/stigs/index.html

HBSS Helpdesk

Email: [email protected]

Phone: Comm (405) 739-5600 DSN 339-5600 Toll Free: 800-490-1643 Option 3

34

**034 And finally, there are a lot of resources out there that those working with HBSS need to be aware of that are not directly tied to training. The HBSS front door on both the NIPR and SIPR are the best places to start when looking for HBSS related resources. The SharePoint on NIPR and Wiki on SIPR contain a lot

of 49

of useful information pertaining to the components, news, baselines, training, and much more. The patch repository contains the software and documentation necessary to install, configure, and maintain the HBSS baselines. DISA's IASE website will provide you with the STIG and Checklist-related directives that were previously mentioned. And the HBSS Helpdesk is your resource for any questions or concerns.

of 49

hbss management roles 2015 - usalearning · hbss management roles 2015. ... based on analyst...

Documents