© 2023 Specter Ops, Inc. ALL RIGHTS RESERVED.
This guide contains proprietary information protected by copyright. The software and services described in this guide are furnished only under a separate master services agreement (a “Master Services Agreement”). This software and documentation may be used or copied only in accordance with the terms of the applicable agreement. No part of this guide may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying and recording for any purpose other than the purchaser's personal use without the written permission of Specter Ops Inc.
No license, express or implied, by estoppel or otherwise, to any intellectual property right is granted by this document. EXCEPT AS SET FORTH IN AN APPLICABLE MASTER SERVICES AGREEMENT, SPECTER OPS ASSUMES NO LIABILITY WHATSOEVER AND DISCLAIMS ANY EXPRESS, IMPLIED OR STATUTORY WARRANTY RELATING TO ITS PRODUCTS OR SERVICES INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. IN NO EVENT SHALL SPECTER OPS BE LIABLE FOR ANY DIRECT, INDIRECT, CONSEQUENTIAL, PUNITIVE, SPECIAL, OR INCIDENTAL DAMAGES (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF PROFITS, BUSINESS INTERRUPTION OR LOSS OF INFORMATION) ARISING OUT OF THE USE OR INABILITY TO USE THIS DOCUMENT, EVEN IF SPECTER OPS HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
Specter Ops makes no representations or warranties with respect to the accuracy or completeness of the contents of this document and reserves the right to make changes to specifications and product/service descriptions at any time without notice.
Introduction and Architecture
Attack Paths are the chains of abusable privileges and user behaviors that create direct and indirect connections between computers and users. Attack Paths exist due to years of misconfigurations and a lack of visibility into how privileges are applied. Attack Paths cannot be patched through traditional methods because these are misconfigurations and not vulnerabilities.
SpecterOps built BloodHound Enterprise following the principles of Attack Path Management. The primary goal of Attack Path Management (APM) is to solve the Attack Path problem directly. APM is a fundamentally different, unique methodology designed to help organizations understand, empirically quantify the impact of, and eliminate Attack Path risks.
Single-Tenant Architecture Diagram
Customer Data Residency and Subprocessors
Customers may request that their tenant resides within any single one of the supported AWS regions below. Existing customers may request migration to an alternate region should residency needs demand.
- United States: US-EAST-1 (Northern Virginia)
- Canada: CA-CENTRAL-1 (Montreal)
- Europe: EU-CENTRAL-1 (Frankfurt)
- United Kingdom: EU-WEST-2 (London)
- Australia: AP-SOUTHEAST-2 (Sydney)
Additionally, BloodHound Enterprise utilizes Pendo for providing in-product tours and behavior monitoring. Customer data is not sent to Pendo. More information on Pendo's data privacy, security policies, and certifications is available here.
AWS Datacenter Security
BloodHound Enterprise is hosted within AWS, which touts a litany of security certifications and is subject to regular audits and certifications. Certifications for AWS include ISO 27001, SOC 1 and 2, etc.
- AWS Cloud Security Overview
- AWS Compliance Programs
- Quick links to frequently requested compliance documentation:
Customer Data Storage and Separation
Separation of Customer Data
BloodHound Enterprise is deployed in a single-tenancy model within AWS. Each customer environment is configured with its own database, API, and UI servers, and data is not commingled between customers.
Each tenant has unique authentication keys defined for authentication between services within the overall system.
Data Backup and Retention
Data backup occurs via Amazon EBS and Amazon RDS backup functionality. All backups are encrypted using the methods listed below in the Customer Data Security section.
All backups are retained for seven (7) days.
Customer Data Security
BloodHound Enterprise makes use of available Amazon encryption functionalities to encrypt all data using AES-256 with an Amazon-managed key. This applies to all servers in use in the BloodHound Enterprise infrastructure. Backup snapshots utilize the same encryption mechanisms.
AWS security groups isolate all BHE installations. They do not have permission to reach other customer assets.
More information on EBS volume encryption can be found here.
Information specific to RDS volume encryption can be found here.
Network Communications
Web Browser and SharpHound/AzureHound connections
BloodHound Enterprise uses a shared AWS Application Load Balancer. The load balancer policy has been set to ELBSecurityPolicy-TLS-1-2-2017-01. This is the most restrictive policy AWS offers for TLS listeners and means that BloodHound Enterprise:
- Does not support SSL renegotiation for client or target connections.
- Does not support custom TLS/cipher policies.
- Requires TLS v1.2 for all communication.
Supported ciphers
- ECDHE-ECDSA-AES128-GCM-SHA256
- ECDHE-RSA-AES128-GCM-SHA256
- ECDHE-ECDSA-AES128-SHA256
- ECDHE-RSA-AES128-SHA256
- ECDHE-ECDSA-AES256-GCM-SHA384
- ECDHE-RSA-AES256-GCM-SHA384
- ECDHE-ECDSA-AES256-SHA384
- ECDHE-RSA-AES256-SHA384
- AES128-GCM-SHA256
- AES128-SHA256
- AES256-GCM-SHA384
- AES256-SHA256
More information on supported TLS policies can be found here.
Certificates
The Amazon certificate authority provides customer-facing TLS certificates. This CA is trusted by all major browsers and operating systems and includes:
- RSA 2048 public key.
- Automatic renewal on an annual basis.
- Private keys are never exposed to SpecterOps. Amazon retains full control.
More information about the TLS certificates we use can be found here.
Authentication and Role-Based Access
Authentication Details
BloodHound Enterprise provides built-in authentication via username and password, with the option to enable TOTP-based multi-factor authentication.
Customers may additionally choose to enable SAML 2.0-based Single-Sign-On to control authentication through an external, third-party provider such as Azure AD SAML, ADFS, or Okta. User access and role assignment are controlled within the BloodHound Enterprise product, and both SP- and IDP-initiated authentication flows are supported.
Local Authentication Specifications
Password Expiration and Complexity
All passwords configured locally expire every 90 days.
- Passwords configured via local authentication require:
- At least 12 characters in length
- At least one lowercase letter
- At least one uppercase letter
- At least one number
- At least one symbol (One of: !@#$%^&*)
Brute Force Resistance
Although BloodHound Enterprise does not lock a user out from attempted brute forcing, API calls against the BloodHound Enterprise authentication API are limited to one call per two seconds, making a successful brute force attack impossible before a password rotation occurs.
All other API endpoints are limited to 55 calls per second.
Password Hashing
All passwords are hashed utilizing the Argon2id key derivation function with a unique 16-byte salt length per Argon2id recommendations. See more information on Argon2 here.
Session Expiration
User-interface sessions expire after eight (8) hours.
Role-Based Access Control
BloodHound Enterprise User Roles
Third-Party Assessments and Certifications
Penetration Testing
BloodHound Enterprise undergoes annual penetration tests at a minimum.
Results from these tests can be made available upon request under NDA. All critical-, high-, and medium-risk findings have been remediated.
Certification
BloodHound Enterprise is included in the scope for the following certifications held by SpecterOps:
- ISO/IEC 27001:2013 – Valid until April 15, 2026
- ISO/IEC 27017:2015 – Valid until April 15, 2026
- SOC 2 Type I - Certified June 12, 2023
Patching
Operating system security patches are fetched daily and applied automatically. The rest of the BloodHound Enterprise infrastructure utilizes Amazon-provided services, and Amazon performs security patching automatically.
We follow security mailing lists, RSS feeds, etc., and periodically review for CVEs in supporting software we use in BHE environments.
Access to Data
Only the BloodHound Enterprise infrastructure engineers maintain persistent access to BHE environments. All SpecterOps employees must pass criminal background checks as a condition of employment.
In some instances, select developers are provided temporary access to systems for debugging purposes. This activity is monitored and logged. Access is revoked at the end of the event.
Logging and Operational Monitoring
All application logs are shipped to a centralized location and are available for internal auditing & debugging. These include web UI and API usage, SharpHound client communication, and authentication logs. They do not include any secrets or sensitive information. They do not include customer data.
Logs are replicated to immutable storage with a three-year retention policy.