How to Build a Secure Enclave
The steps you can take to satisfy compliance requirements.
We processes customer network data to flag anomalies and identify malware. Recently we built a secure enclave to satisfy compliance requirements, and here I describe the steps taken to minimize the scope, create the enclave itself, and formally describe the system to auditors.
Minimize the Scope
First consider the crown jewels that you wish to protect. In our case this is the raw data that customers send us to score. Upon processing via the analytics engine, refined alerts are generated in JSON format. This architecture means that many cumbersome elements (e.g. a complex web application to render alerts) fall out of scope, as demonstrated below. The elements in blue form the enclave, and those in green are external dependencies which receive data.
The data types handled by the system are classified using a matrix, as below. Within the AlphaSOC environment there’s an upstream API used to gather domain reputation data called wisdom, PagerDuty is used to escalate alerts to the team, and Amazon S3 to store off-site backups. Limiting the bleed of sensitive data to large known entities (such as Amazon, Google, and Microsoft) reduces the burden of ensuring third-parties are compliant.
By adjusting the architecture to reduce touch points (i.e. people and processes with access to sensitive data) and transmission of data to unsafe third-parties, you can prepare an environment which is easy to maintain.
Create the Enclave
Google Cloud Platform and Amazon Web Services support the operation, monitoring, and business continuity & disaster recovery (BCDR) elements of the AlphaSOC secure enclave. The GCP project for the enclave includes:
- A VPN server to provide secure access
- A bastion host to authenticate users and provide granular event logging
- A build server to configure and deploy software in the enclave
- The deployed production AlphaSOC API and analytics engine instances
- An authenticated vulnerability scanning engine (e.g. Rapid7 InsightVM)
- A logging server to support compliance auditing tasks and alerting
- An instance to prepare and ship cold backups to Amazon S3
.. and the Corresponding Business Unit
Many of our staff do not require access to the production environment, so we created a subsidiary with a handful of employees to operate the enclave. For each person we then:
- Undertook a background check
- Executed a service and confidentiality agreement
- Completed a security awareness training program
- Provisioned a managed Google Chromebook and Yubico YubiKey
A user access matrix is used to track user privileges, as demonstrated below. This can be extended to track hardware and cover on- and off-boarding tasks (e.g. certificate issuance and revocation).
Formally Describe the System
Upon defining the enclave and business unit to support its operation, an information security management system (ISMS) document is prepared to describe safe operation of the system, including elements such as:
- Human resources and asset management
- Access control and operational security
- Cryptography and communications security
- Business continuity & disaster recovery
- Vulnerability management
- Supplier relationships
- Monitoring
Supporting material used within the ISMS includes a detailed description of the environment (i.e. the enclave, business unit, and third-party integrations) and matrices describing data classification and user access. An auditor will use the ISMS to understand the intended configuration of the system and review the controls and artifacts (e.g. audit logs and reports) that exist.
The ISMS describes safe operation procedures, and should be distributed, reviewed, and used as a handbook by the users within the business unit.
AlphaSOC ISMS Highlights
A selection of features defined within the AlphaSOC ISMS are listed below. Using hardened user devices, strong cryptography, and undertaking regular third-party reviews, we can achieve a high degree of information assurance.
- Chromebook devices are managed and hardened
- An internal CA is used to sign user and server certificates
- Users authenticate with two-step verification via YubiKey hardware
- TLS 1.2 and strong AEAD ciphers are enforced throughout the system
- API and analytics engine source code is reviewed by a third-party
- The audit logs within the enclave are reviewed weekly by the team
Map Your ISMS to Standards
Armed with an ISMS, you can map the security features to controls found within published standards, and consider implementing additional features. NIST SP 800–53 and the CSA Cloud Controls Matrix are great places to start, along with the ISO/IEC 27000-series standards summarized below.
Collect the Badges
Upon mapping your controls to published standards, you can collect badges through self-assessment (primarily via CSA STAR and the Privacy Shield Framework) and formal third-party auditing.
Along with achieving compliance with the ISO/IEC 27000-series standards, certified assurance programs and reports to consider include:
- AICPA SOC reporting (most notably SOC 2 Type 2)
- Skyhigh CloudTrust™ Enterprise-Ready
- TRUSTe Privacy Assessments and Certifications
Many controls reviewed during formal audits map to specific initiatives (e.g. GDPR, HIPAA, FERPA, and GLBA). As such, you can collect many additional badges by referring to particular controls and associated audit reports.
Further Reading & Reference Material
The AWS Cloud Compliance page contains a very useful list of certifications, laws, regulations, and frameworks. Amazon also publish their collected badges in materials online, as shown below.
