HBSS Notes Part 1 of 2 – Installing the DISA Image

In this post I share the results of installing and configuring the DISA Host-Based Security System (HBSS) in a real Army environment. HBSS is critical to ensuring the confidentiality, integrity, and availability of Department of Defense (DoD) information systems. The DoD Information Systems Agency (DISA) makes the HBSS available for download as long as you have a valid Common Access Card (CAC) that you can use to login to the system.

The HBSS install is non-trivial…the DISA site provides links to official training. However, even with the training these notes should be useful to many. These are simply the first set of raw notes from my efforts; I have a much more detailed set of configuration notes for the policy creation and management tasks. Those notes will make up the second part of this article (I promise I’ll get to that sooner than later). For now, I hope these notes help…enjoy!

HBSS – DISA Pre-Built Package

Initially I built the HBSS package completely from scratch…that effort, while significant, is probably of little value to other IT professionals. (I’m happy to create a post for it if anyone has interest!) So please keep in mind that these notes were completed *after* I had already built an HBSS image. Thus, some of the references might appear a little odd…bear with the article and remember to apply it to your own situation.

This article consists of two parts: the VM deployment / initial configuration; and, the standard HBSS configuration. There are two different DISA-supplied Guides to follow. Access Part 2 of this article here.

Initial VM Deployment and Configuration

This section relies on the admin having access to and using the DISA-supplied “HBSS 4.5 2008 R2 Build From Image Guide” which was downloaded from the DISA HBSS patch repository. Note that the actual package installed if HBSS version 4.6.6 but the DISA documentation indicates 4.5 – There is a 4.6.6-specific DISA Guide at the DISA HBSS 4.6 patch repository; the instructions are the same between 4.5 and 4.6.

After the HBSS install completes (up through Step 4.1.3 from the DISA Guide), prepared the machine to receive Windows Updates from APG D5-141:

1. I am using vSphere to run the virtualized environment, and the HBSS was deployed directly to a VM following the DISA Guide. Within vSphere Client after the initial install, all I had to do was change NIC to use the vSphere “dvPgVM Network” portgroup. This is the portgroup I use to access my environment’s “infrastructure” VLAN.
2. In the HBSS guest, set the Network Location Awareness to private by editing Computer Configuration -> Windows Settings -> Security Settings -> Network List Manager Policies -> “Unidentified Networks”. Then use “netsh int ip reset” to reset the NIC completely (very important) – this requires a reboot.
3. Disable IPv6 per the DISA Windows Server 2008 R2 Security Technical Implementation Guide (STIG).
4. Assign same IP address as was used for the original HBSS Manual Install (172.24.4.31). This is an enclave-local IP address – set one to match your needs.
5. Because our enclave is local, we have our own Certificate Authority (CA). Thus, the Windows Server Update Services (WSUS) server to be used to update the HBSS server has a certificate from our local CA. To enable this to work, I installed our local CA top-level certificate to the HBSS guest as a trusted root certificate.
6. Update HBSS to reference the local WSUS server by modifying local group policy. Keep in mind that the DISA HBSS image must not be a member of your domain, so any Group Policy Object (GPO) changes must be applied locally to the HBSS guest!
7. Apply all Windows Updates. The DISA Guide actually has this as a separate set of instructions, but I wanted to make sure that all updates were applied before I proceeded. In my case, a number of .NET Framework 4 updates refused to upgrade and we finally had to install them one-by-one – sysadmins, be aware of this problem and be assured that updates can be applied with effort and persistence.
8. Verified that the HBSS 4.6.6 packaged from DISA is the latest version as of 08 AUG 13.
9. During name change (Steps 4.1.5 to 4.1.21) used HBSSEPO002MV; the original DISA name was HBSS2K8-FOC. Also installed VMware Tools, set default suffix (domain) to armycloud.cloud.army.mil, verify networking, activate Windows, and perform reboot.
10. Prior to running DISA HBSS Rename Script (Step 5.1) be sure to update DNS for the HBSS hostname *and* update related PTR record. Not sure if this is required but it is safest to ensure that reverse DNS queries return the expected values. Also, the instructions state that a system reboot is necessary after the script completes but the script doesn’t actually prompt the user to do this reboot. So, I performed a manual reboot after the rename script finished successfully (around 10 minutes to run).
11. Step 6.1 has you login to the ePO Server – the default credentials are admin/Charming1! (the “HBSS Configuration Guide” points this out, but not the “Build From Image Guide”. Also, for the master key name used HBSSEPO002MV to match the VM name.
12. After the final reboot (after setting up master key) be sure to set the “McAfee ePolicy Orchestrator 4.6.6 Event Parser” service to Automatic (and start it). The “Build From Image Guide” has you set it to manual but this results in warnings when you login to the ePO Server console.

At this point the ePO Server is ready for standard DISA configuration (next section).

Standard HBSS Configuration

This section is performed after the pre-built DISA HBSS image has been deployed and the “Build From Image Guide” has been followed. This section is built around the “HBSS 4.6 Configuration Guide” from DISA. Specific steps are highlighted below in each section (based on the Modules breakdown from the DISA Guide).

Module 1: ePO Server Policy Configuration

Follow the steps in the DISA Guide with notes from below:

1. Steps 1.1 through 1.3 have already been performed in prior section.
2. Step 1.4 is optional and is skipped in D5-141 environment (no remote console).
3. Step 1.7 is skipped as we built from DISA pre-built package.

   Interjection here on a general note for policy names (for example Step 1.8 for McAfee Agent Policy): wherever DISA specifies a policy name we use exactly that name except that every policy name is prefixed with “APG_D5141 -“. This is per DISA recommendations so that our locally-defined policies are always clearly identifiable. As an example, for Step 1.8 we end up with the name “APG_D5141 – ePO Server Agent”.

4. Step 1.9: Although this is optional and we do not have “Super Agent Distributed Repository” (SADR) go ahead and configure the policy just to be consistent (and because the SADR policies are referenced in the DISA Guide later). When prompted to enter the host repository name (Step 1.9.14) you may ignore that directive as no SADR agents are actually used.
5. Step 1.13: Trusted Policy Auditor appears already to be setup. No action required.
6. Step 1.14: Create the client trusted applications policy template as documented. Add Symantec by using %PROGRAMFILES%\Symantec\* and %PROGRAMFILES(X86)%\Symantec\* to be sure all apps are allowed.
7. Step 1.15: Local Retina is RETINAX001UT (172.24.4.67). Please keep in mind that our naming convention and IP addresses are based on the fact that we have a *local enclave*. Your own naming conventions / IP address scheme will be different.
8. Step 1.18.2: Typo; Product should be “Host Intrusion Prevention 8.0: Firewall”. Same for Step 1.19.2.
9. Step 1.19: Couldn’t find the localhost rule; create one for 127.0.0.0/8 to allow all traffic.
10. Step 1.19.9: Ensure that “Allow Vulnerability Scan” rule is always enabled (noted that this is STIG finding). We are chronically understaffed for admins and our Information Assurance (IA) group runs scans all of the time…most of the time without warning. If we disable vulnerability scans, we get a lot of flack from the IA group.
11. Step 1.19.9: The “Remote Console” rule is modified to allow both the VM (4.52) and physical (1.203) tools boxes, although there is no plan to use these as remote consoles.
12. Step 1.19.13: Ensure that tools VM and the entire physical subnet (172.24.1.0/24) can remote desktop into the HBSS box. The ePolicy Orchestrator (ePO) Server is the McAfee product name for the HBSS server modules.
13. Step 1.19.15: This is duplicate; ignore.
14. Step 1.19.34: Add both 172.24.4.0/22 and 172.24.1.0/24. Whereever prompted for subnets in following 1.19.x steps, do the same. When prompted for things like “allowed inbound networks” then use 172.24.0.0/16 to allow anything in our local enclave enclave.
15. Step 1.20: For the RSD be sure to specify 172.24.0.0/16.
16. Step 1.23: Approach used is to create site-level subgroup for our environment “APG_D5141” and then subgroups underneath that site-level group.
17. Step 1.23.13: The “IPS Protection (All Platforms)” will need to have the DISA base policy duplicated (step was skipped in the config guide).
18. Step 1.23.20: Another skipped policy; be sure to create McAfee Agent -> General -> “Client Agent” policy from the DISA base policy. Then apply to the client agents subgroup.
19. Step 1.23.30: Same as 1.23.30 except for ePO Server. (Remember that “ePO Server” is the name of the McAfee software on the DISA HBSS package.)
20. Step 1.23.60: The example names used for the SADR were “Distributed Repository Agent” when the policies were created but are called “SADR Agent” in this step; do not be confused by this!
21. Step 1.24: Ignored this step.

This concludes notes on the ePO Server Policy Configuration module.

The next HBSS article will cover the extremely lengthy, error-prone, and frustrating configuration of the HBSS package. Access Part 2 of this article here.