SECURITY-BY-DEFAULT
RATHER THAN
ASSEMBLE YOURSELF
THERE ARE TOO MANY PARTS It is too difficult for IT toassemble, integrate, operate, and keep up-to-date the collection of specialized security tools needed to protect server infrastructure, especially since they are not designed to work together. • Hardened operating system • Hardware security module • Hypervisor & orchestration • Micro-segmentation • Application whitelisting • Audit logging
• Packet capture & forwarding • Traffic intelligence & analytics • Privileged account management • Secure file system access • Secure credentials and key
management
• Secured application proxies VERIFYING THE INTEGRITY OF PLATFORMS IS TOUGH
It is difficult to verify that the software and firmware running on a system is only what is intended, especially as conditions change due to maintenance, upgrades, and component changes. A BETTER WAY
Hyper-secured infrastructure is secure-by-default, and reduces the cost, time, and skills required to protect critical applications.
Hyper-Secured Infrastructure: An Overview
Acute concern over data security has made risk management a board-level discussion. Continuously evolving compliance requirements and an ever-increasing number of skilled and well-funded aggressors causing frequent high-profile breaches are giving business and their leadership cause to question the status quo and re-visit their approach to digital security.
Most organizations have policies mandating hardening of applications and compute infrastructure, but in practice it is too difficult for IT to assemble, deploy, and operate the collection of tools necessary to deliver actual security. Market fragmentation has produced highly specialized tools that are not designed to work together, forcing IT to take a minimalist approach to the protections they invest in due to pragmatic concerns of operational complexity. Policies are routinely waved when urgent business needs outweigh security best practices, leading to a persistent and
unobservable reduction in security posture. Systems frequently get out-of-date with the latest updates and vulnerability patches, and the operational burden of keeping them current is difficult.
Hyper-secured infrastructure changes the equation in IT’s favor by providing a
compute platform that is secure-by-default and easy to maintain, with embedded visibility, control and audit capabilities. This equips an
organization with an integrated vertical technology stack that addresses some of the most challenging security issues. Since the security is engineered into the management of the system, the operational burden is minimal.
When viewed from a risk management perspective, an approach that focuses on hardening specific, critical
applications has the highest return on investment. Pursing a two-tier approach to the compute infrastructure, wherein critical applications are hosted on hyper-secured infrastructure while the general applications that depend on them continue to be hosted on systems optimized for orchestration and resource use, has many benefits.
HSI Design Assumptions
The goal of HSI is to wed practical operational needs with a secure compute platform to better protect critical applications without additional administrative and oversight
Revisiting Trust Zones & Perimeters: The Application is the New Perimeter
Recent breaches have shown that a reliance on zone-based perimeter security does not protect internal assets from attack. End-user platforms are directly targeted, virtual workloads make edge policy difficult to maintain, partner and cloud interconnections defy even the definition of static perimeters, and rapid application adoption makes policy creation and installation a bottleneck. Attacks have the advantage of scope: once any application within a zone is compromised, the remaining systems are more easily exploited via lateral attacks that exploit inter-system trust and real-world administrative practices. Worse, zones are often not truly separated — nexus services needed to operate the IT infrastructure, are used as pivot-points into other zones and are subverted to help cloak malicious activity. The reality is that each application has a unique surface that defines its trust boundaries in addition to the
application-independent, and often weaker, surfaces of the host operating system and other administrative tools. These surfaces are not dependent on where the workload runs and are connected to the network, they are an intrinsic property of the application.
Applications in segmentation and perimeter-based security environments are vulnerable since they implicitly have a high-level of trust for their neighbors.
It is possible to expand protection and establish a security perimeter around each application workload that can act as a per-application DMZ with granular controls that are properly paired with the policy an organization requires, resulting in less exposure and contextually relevant audit information. Since the policies follow the application when it is moved, and are removed when it is decommissioned, there is no configuration drift.
Revisiting Hardware Security: The Need for Hardened Compute
Applications are not the only surface in the compute landscape. The servers themselves and their underlying management software are both surfaces that security personnel need to pay attention to. Management implementations typically have weak, vulnerable designs because they implicitly assume a
friendly environment. Attackers use these
technologies not just to compromise the compute system for purposes of application exploitation; they use these technologies to compromise the bottom-most layers of the firmware to obtain persistence, concealment and scope, and act as a launch pad to attack the hypervisor and operating system of the server. When a server is compromised in this way, a trusted part of the compute infrastructure is working against the enterprise. Infiltrations at a low enough layer include anti-detection and persistence techniques, a common feature of root-kits and hyperjacking tools, that render remediation efforts moot and allow the attack to re-write evidentiary trails. Traditional endpoint security practices are challenged in these areas as they normally assume the operating system, and all the layers below the operating system, are trusted.
Given the new threat landscape, integrity verification with a hardware root-of-trust that can provide assurance that the entire hardware and software stack has not been compromised is needed in order to have confidence that the security controls have not been bypassed. In addition, isolating the security controls from application’s compute environment renders traditional attacks ineffective in their attempts to undermine the integrity of the system.
Revisiting ‘One-Size-Fits-All’ Infrastructure: The Need for a Two-Tier Approach to Infrastructure
Organizations are challenged to answer some fundamental questions regarding the security of their most critical and high-risk applications.
* How do I verify my infrastructure is only running the software I intend it to?
* Can I prove my security controls have not been undermined or turned off?
* Do I have reliable evidence of what an attacker has done or exfiltrated?
* Is my system exhibiting signs of infection or running unintended services?
* How do I protect an application from its neighbor in the same network trust zone?
* How do I protect systems that are in insecure locations?
A two-tier approach to infrastructure — bulk compute for general-purpose applications and hyper-secured
infrastructure for critical and high-risk applications — allows organizations to effectively balance agility and risk. While HSI may be used for a small percentage of the overall server population, the impact to business continuity is profound.
What is Hyper-Secured Infrastructure?
Hyper-secured infrastructure is an engineered system with a software-centric architecture that tightly integrates compute, security, virtualization, and policy management. It provides a robust and comprehensive solution to application workload protection and assures a level of security beyond common server hardening steps by taking an architectural approach where security is a foundational property of the infrastructure itself. The benefits HSI offers include:
Always-On Security
The security system is built-in, always enabled, and impossible for administrators and aggressors to bypass. Any workload that is deployed is always monitored and protected, from inception to retirement. The system assumes a zero-trust environment — it does not trust application workloads nor the surrounding network environment. It offers continuous protections throughout the lifespan of the asset.
Integrity Verification
HSI continuously verifies the identity, integrity, and
provenance of an application workload and the underlying software and hardware infrastructure, in order to mitigate against tamper and spoof attacks. Unlike software-only approaches, HSI can protect systems starting from the point of inception, not just at the point of integration or operation.
Protect the Application Workload from Attack
A DMZ perimeter is established between each application workload and the surrounding environment. It enforces application-specific policies that greatly reduce the surface-area of attack and are not at risk of configuration drift. The policies are bound to the application and are always enforced regardless of where the application is
running, and they cannot be circumvented by neighboring systems that are in the same topological zone or hosted on the same physical hardware.
Prevent the Application Workload from Causing Harm
HSI assumes zero-trust with the applications it hosts, making it hard for compromised workloads to attack the security controls and the surrounding environment. The DMZ perimeter prevents the application workload from performing malicious activity, such as communicating with command and control hosts, attempting reconnaissance, performing lateral movement, and exfiltrating data.
Comprehensive and Continuous Monitoring
Application workloads are monitored across all layers of the stack — packets, flows, virtual machine changes and upgrades, administrative access, and HSI policy and configuration updates. A data warehouse of information is maintained that is invisible to and independent from protected applications, and it provides a tamper-proof log that is invaluable for evidentiary purposes.
Centralized and Independent Administration
The policy, system management, and audit facilities are unified into a single control plane that operates across the fleet of HSI enforcement platforms, and provides
workflows for platform health diagnostics, workload orchestration, security policy definition, and security auditing. The administrative domain between HSI and the application workload is segregated to maintain separation between the infrastructure and application owners. This makes it easy for IT to deploy and operate the system.
Easy to Maintain
The HSI system is designed to simplify the patch and update process so it is easy to always run the latest versions of software, ensuring that vulnerabilities are patched as they are discovered even when embargoed, thus putting an end to services going years without patching due to neglect. The entire software stack is effectively a single entity, so an organization does not need to perform interoperability verification between individual components and the configuration does not drift. It is centrally managed, so deployment, patches, and upgrades can be easily orchestrated.
How to Evaluate Implementations
Hyper-secured infrastructure is an emerging technology, so expect wide variation in vendor implementations and system capabilities. When evaluating an HSI, here are some key considerations to keep in mind.
Security or Flexibility?
This age-old question is the most fundamental consideration when evaluating any security approach, and HSI is no exception. Is it of paramount importance to ensure an application workload is hardened “as much as possible” due to its high-risk and high-value nature, or is the ability to implement HSI broadly across the enterprise virtual perimeter the overriding priority? The answer likely varies depending on the criticality of the application workload, the data it protects, and the interconnectedness that application has to the rest of the environment.
Systems optimized for security are designed from the ground up, beginning with the hardware. The intention is to provide complete environmental segregation between the virtualization of hardware, compute, the application workloads, and the modules performing the network and security functions. Ideally such systems establish trust across the component stack, rather than imply trust, from the hardware up to signed workloads, and that extend from the point of manufacture to the point of operation. The limitation of this approach is the system is pre-assembled and probably requires separate procurement and operational procedures.
The other extreme is a system designed to fit within an existing hardware, virtualization, and likely hosting operational environment. The intention is to provide a security layer that can offer consistent application workload protections across a wide range of operational platforms, whether managed by the organization or concurrently within a third-party hosting facility, so the business gains flexibility in where to host application services. The limitation inherent in this approach is that it assumes implicit trust of some portion of the underlying compute platform: the OS, the hypervisor, adjacent workloads on the same server, or even the hardware itself. Skilled and patient adversaries have consistently proven they can find the trusted element of the system, compromise it, and thus defeat the system.
What Protections are Offered?
HSI systems offer integrity verification of workloads and the compute platform they operate on. This may be established when the system is deployed, but for the base system, it is ideally done at the point of manufacture to prevent
tampering during delivery. A root-of-trust provides an anchor for the system identity to be established and verified. It is best if this is done in hardware, likely using a TPM, but some HSI is designed to be hardware agnostic so this can only be done in software in the hypervisor/security layer. Hardware-based HSI is also able to physically lock-down the device and protect against physical tampering, an important consideration when deploying systems in insecure or untrusted locations.
While all implementations of HSI protect workloads they house, they vary in the security protections offered and assistance provided for regular security operations. As a baseline, all protect the workload with some form of firewall access control features such as white and black listing. They may couple that with network isolation (to block scanning and prevent control-layer protocol attacks including ARP and DNS), network intrusion protection or anti-virus services, reputation-based blocking, compliance-based reporting, and policy-driven application segregation and segmentation.
Beyond protecting workloads, HSIs may help determine if an application workload is infected or running unwanted
services by monitoring its communication patterns. In the case of infection, they may assist the incident containment and remediation, for example, by restarting the workload from a prior golden version.
Sandboxing, or slowing down an infected system from causing harm to the rest of the environment, is an area HSI is well positioned to assist. Because the protections are tightly bound to a specific application, they can make data exfiltration difficult, ensure incident and breach efforts have a tamper-proof evidentiary trail, and may limit the impact of credential theft with credential compartmentalization. Expect capabilities to vary widely depending on the vendor
Auditing is a broad area, ranging from the scale and location of the security and lifespan of the data warehouse, elements of the stack that are monitored, visualization and API / integrations offered, and built-in or partner-provided compliance checking and reporting. For some organizations, auditing is a first step toward defining application-specific policies; while for others providing a tamper-proof evidentiary trail during incident and breach-handling situations drives auditing.
HSI does not replace network-based security technologies, such as network firewalls, network intrusion protection systems, or email and web content security gateways. Nor does it replace host-based security suites such as anti-virus, host intrusion protection, or file and data encryption. It does overlap with hypervisor-based security features, such as virtual firewalls. HSI compliments security information and event management systems by providing high-fidelity data for the hosted applications.
Is HSI Complex to Deploy?
The initial question is where to first deploy HSI. It may be to protect exposed applications in the DMZ or partner intranet or to lock down high-value applications in the data center.
Alternatively, the priority might be to a secure server for applications in remote offices or to protect critical IT infrastructure. This is a business decision and tied to what is most important to protect and how to best get early experience using the technology. If an
incremental deployment approach is desired, determine if the HSI can be deployed one server at a time, or whether it needs to be done across a fleet of servers all-at-once to gain any value. Scaling an HSI deployment, or deploying it in branch offices, will have an organization
evaluate how much effort and skill is involved in adding a new system. Consider if will take hours or days to get a new system operational, and if a skilled IT person must be onsite or whether local staff can do it.
As HSI converges security, compute, and virtualization technologies into an integrated system, it should have little to no impact to the network design, and application and operating system server operations. However, depending on the HSI implementation, this may not be true. Although an HSI should never require an agent to be installed in an application workload, vendor implementations may be less rigorous ensuring this is true. Some may require changes to the network design because the DMZ perimeter protecting workloads is exposed to network operations, as is the case when deploying network firewalls. An HSI offering may tie into existing server and application orchestration tools, but it is likely that all HSI platforms will be managed independently from general bulk compute.
In Summary
Organizations should adopt a two-tier approach to infrastructure, and migrate critical, exposed, and high-value applications to run on systems that are built with security from the ground up rather than continue hosting them on insecure bulk compute. Hyper-secured infrastructure gives organizations an easy to manage trusted computing platform that enables policy
enforcement at the application edge, continuous system integrity verification, and a reliable audit trail for incident and breach handling
procedures. HSI implementations vary widely, and it is necessary to match the use-cases an organization wishes to deploy with the
technology stack and operational capability of a given solution. Skyport Systems 280 Hope Street Mountain View, CA 94041 [email protected]
