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 ( 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 ( 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 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 ( 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 and Whereever prompted for subnets in following 1.19.x steps, do the same. When prompted for things like “allowed inbound networks” then use to allow anything in our local enclave enclave.
  15. Step 1.20: For the RSD be sure to specify
  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.

Team-oriented systems mentor with deep knowledge of numerous software methodologies, technologies, languages, and operating systems. Excited about turning emerging technology into working production-ready systems. Focused on moving software teams to a higher level of world-class application development. Specialties:Software analysis and development...Product management through the entire lifecycle...Discrete product integration specialist!

10 Comments on “HBSS Notes Part 1 of 2 – Installing the DISA Image

  1. My sponsor gave me 2 ISOs. One is the Windows 2008 R2 installtion boot disk and works just as the DISA guide documents, the other ISO contains a zipped VMWare VMDK labeled 2k3HBSS45MR6FR-0. Installing HBSS according to DISA’s guide prompts for disk 2, however, I don’t have a disk 2. Should there be one from DISA or is it the Microsoft Windows 2008 R2 install disk?

    • Thanks for the question. Off the top of my head I don’t remember using 2 disks but I will go back thru my notes. Ping me in a bit if you don’t hear back from me…and thanks again.

  2. I am getting ready to install HBSS from scratch. I am very interested in your notes as it looks to be very difficult to install. Is there anyway you can post those?

    • Hi Angela – My recommendation is *DO NOT* try to install HBSS from scratch. I spent a few days on this while waiting for the IA guys to get the pre-built HBSS image and I can tell you that the DISA instructions are incomplete, hard to follow, error-prone, and ultimately – IMHO – a waste of time. Do yourself a favor, get the latest HBSS image and install from there. You’ll still spend days working through it and getting policies configured correctly and testing. But do not try to be clever (like I did) and just pull down all the “bits” yourself and try to get them in place. What a disaster that was!

  3. I am going to have to install HBSS on one of our networks. I thought setting up SCCM was a challenge but after reading here HBSS looks like it will top that. Is there a one-stop “HBSS for dummies” guide anywhere for those of us that are clueless?

  4. Andrew,

    Thanks for the effort and guide! Working on my install in our “lab” environment so no internet connection – not really too worried about updates and such at this point; just need it working.

    Have physical disks from DISA (disk 1 and 2). Setup VM according to DISA instructions and install went okay. Started lookinging through your instructions and noted that you say HBSS should not be a domain member. No problem on that and understand why. Issue though is you proceed to say that “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.” Question is, why does it need the DNS and PTR records? Probably a really dumb question but had to ask. If it does need it, guessing it needs to be created manually in AD?


  5. Assume three IPS policies are applied to a node ? 1 default and 2 custom. The default severity level is set to HIGH, 1 custom severity level is set to LOW and the other custom is set to MEDIUM. What is the effective severity level outcome for the applied policy?

  6. I am in the planning phase to implement HBSS. Does this require a Full SQL Server? I will be managing a small number of hosts. Will SQL Server Express be sufficient for less than 30 hosts?

  7. I would like to have my own testing environment at home so I wanted to download the HBSS image from DISA and install it on my personal laptop at home to test different policies would that be an issue ? using a DISA software at home

Leave a Reply

Your email address will not be published. Required fields are marked *