Infrastructure protection encompasses control methodologies necessary to meet best practices and organizational or regulatory obligations. Using these methodologies is critical for successful, ongoing operations in either the cloud or on-premises.
Infrastructure protection is a key part of an information security program. It ensures protection for systems and services within a workload against unintended and unauthorized access and potential vulnerabilities. For example, defined trust boundaries (e.g., network boundaries and packet filtering), system security configuration and maintenance (e.g., hardening and patching), operating system authentication and authorizations (e.g., users, keys, and access levels), and other appropriate policy-enforcement points (e.g., web application firewalls or API gateways).
There are several approaches to infrastructure protection:
- Protecting network and host-level boundaries
- System security configuration and maintenance
- Enforcing service-level protection
Protecting Network and Host-Level Boundaries
The careful management of the network topology and design forms the foundation of how to provide isolation and boundaries for resources within an environment. Because resources placed within an environment inherit the security properties of the underlying network, it is critical to establish an appropriate network design for the workload that ensures that only the desired network paths and routing are allowed. This is done by leveraging multiple layers of protection to provide redundancy for the controls and mitigate the impact of a single layer misconfiguration that could allow inappropriate access.
When defining a network topology, consider which components of the system need to be public; for example, a customer-facing load balancer. Additionally, when designing connectivity, consider whether connectivity is needed between the data center over a private network. Apply appropriate configurations to virtual private cloud (VPC), subnets, routing tables, network access control lists (NACL’s), gateways, and security groups to achieve the network routing as well as host-level protection.
A private cloud network allows users to define a network topology that spans a geographical region with a predetermined, private IP address range. Within a VPC, the network is further separated by subnets, where each subnet has an associated route table that defines routing rules for managing the paths that traffic within the subnet takes.
A best practice is to define a publicly routable subnet by having a route that goes to an internet gateway attached to the VPC. The absence of a route to the internet gateway prevents instances from being directly reachable. A subnet has a NACL attached to it (stateless firewall), configured to narrow the scope of traffic allowed. For example, only allow the port for the database engine for a subnet hosting the databases.
When a host is launched within a VPC, it has its own security group (stateful firewall). This firewall is outside the operating system layer and is used to define rules for allowed traffic. It is important to also define relationships between security groups. For example, instances within a database tier security group only accept traffic from instances within the application tier.
When implementing a VPC design, keep in mind some key considerations for the IP address range that was chosen for the VPC. Try to use non-overlapping IP addresses with any other VPC’s or data centers. When designing NACL rules, consider that it’s a stateless firewall, and therefore, both outbound and inbound rules need to be defined correctly.
System Security Configuration and Maintenance
The careful management of the security configurations of the systems running within the environment forms the foundation of how robust, secure, and scalable systems are maintained. The security posture of systems is a function of the controls that are available, as well as additional controls over the operating system installed, threat detection, CVE and vulnerability scanners, anti-malware detection, and any tools to help verify and maintain the integrity of the installed operating systems. These controls also form another layer in the defense in-depth strategy.
When defining the approach for securing a system, consider the level of access needed for that system and take a least-privilege approach. (For example, only open the ports needed for communication, ensure that the operating system is hardened, and that unnecessary tools and permissive configurations are disabled.) Apply appropriate configurations to these operating systems, including strong authorization mechanisms.
Automate deployments and maintenance, and remove operator access to reduce the surface area. Much of this is achieved using system management tools and using Devek for provisioning the infrastructure. Assess the baseline security exposures and perform routine vulnerability assessments when updates or deployments are pushed. CVE-scanning tools help with this and centralize security findings for analysis and remediation. Ensure that the operating system and application configurations, including firewall settings and anti-malware definitions, are correct and up-to-date by defining and maintaining consistent operating system configurations using a centralized service or tool. Use Devek to collect and query configuration about instances and installed software. Leverage automated patching tools to help deploy operating system and software patches automatically across large groups of instances.
Enforcing Service-Level Protection
The careful management of the security configurations of all service endpoints forms the foundation of how secure and authorized access to these endpoints is maintained. This level of security is required to ensure that users and automated systems have exactly the level of access needed to perform their tasks (least privilege).
Protect all service endpoints by defining policies using IAM. IAM helps define policies for access to services and operations. However, for some services, it is important to also define fine-grained controls to specific resources within those services. Additionally, some resources have their own resource level policies. For example, an object store might have per-bucket policies to define access levels to objects and/or entire buckets, and an encryption service has policies to define administrators and users of the encryption keys. Use IAM and the resource policies to define a robust protection scheme for all cloud resources.
When defining a service-level protection approach, ensure to apply a least-privilege methodology and set service-level access policies accordingly.
Join Devek in reducing Cloud complexity
Looking to reduce complexity of cloud infrastructure? Look no further, we are here to make it happen!
Please leave some details and we will get back to you when Devek is available for trying out.