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:
- 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.
- 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.
- Disable IPv6 per the DISA Windows Server 2008 R2 Security Technical Implementation Guide (STIG).
- 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.
- 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.
- 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!
- 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.
- Verified that the HBSS 4.6.6 packaged from DISA is the latest version as of 08 AUG 13.
- 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.
- 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).
- 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.
- 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:
- Steps 1.1 through 1.3 have already been performed in prior section.
- Step 1.4 is optional and is skipped in D5-141 environment (no remote console).
- 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â€.
- 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.
- Step 1.13: Trusted Policy Auditor appears already to be setup. No action required.
- 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.
- 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.
- Step 1.18.2: Typo; Product should be â€œHost Intrusion Prevention 8.0: Firewallâ€. Same for Step 1.19.2.
- Step 1.19: Couldnâ€™t find the localhost rule; create one for 127.0.0.0/8 to allow all traffic.
- 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.
- 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.
- 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.
- Step 1.19.15: This is duplicate; ignore.
- 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.
- Step 1.20: For the RSD be sure to specify 172.24.0.0/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.
- 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).
- 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.
- 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.)
- 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!
- 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.