Despite cloud growth slowing in the past quarter, the momentum of existing and planned cloud adoption remains. As a new or existing CISO, your organization may be just starting to migrate to the cloud or may be looking to improve efficiency by adopting newer technologies like Kubernetes. Wherever you are in your cloud journey security needs to be in the forefront with careful consideration for how your security org, its governance and controls will evolve along the way.
Avoid The Free For All
I’ve been through multiple cloud migrations and before anyone in your organization begins to migrate, the IT, Security and Finance organizations need to come together to lay the appropriate foundation in the new environment. This means you need to set up the appropriate structure for mapping and controlling costs. You also need to map all of your existing IT and security policies and controls into the new cloud environment before people migrate to avoid having to do clean up later. It doesn’t have to be perfect right away, but doing some preparation and implementation of guard rails before teams migrate will pay dividends later.
Not Everything Is Easier
As organizations migrate to the cloud, security teams need to consider how the tools and processes they rely on may change. For example, if you currently rely heavily on netflow or packet captures to monitor your networks, the methods to get the same visibility may be different in the cloud. Similarly, transferring large amounts of data or security events can incur significant costs and so your logging and SIEM infrastructure may need to be re-architected to keep the events as close as possible to the environment, while only shipping the most critical events to a centralized location.
Penetration tests are also different in the cloud. If you regularly penetration test your environment or have third parties conduct pentests for contractual, compliance or regulatory reasons, then these will need to be scheduled and coordinated with your cloud provider so you don’t accidentally disrupt another customer. When you move to the cloud you no longer “own” or control the network and so you have to operate within the terms laid out by your cloud provider. As a result, pentests may be less frequent or may need to have their scope adjusted as appropriate for the environment.
Asset inventory may also change. If you are used to assigning your own DHCP addresses and having these addresses be relatively static in your inventory this will change in the cloud. Your asset inventory will change based on how frequently your organization spins up and down resources. This could be a few hours or days. Your associated inventory, reporting, vulnerability scanning, etc. will all need to be adjusted to the frequency of resource utilization and this can make tracing security events difficult if your inventory isn’t correct.
Processes aren’t the only thing that will need to be adapted to the cloud. Let’s consider how the scope of security changes as you move to the cloud.
In The Beginning
Consider a traditional technology stack where an organization has purchased and manages the storage, network, compute, OS and software running in the stack.
In this model the security organization is responsible for ensuring the security of not only the physical environment, but the security of all of the other technology layers. In some ways this environment offers simplicity because a production application maps directly to a network port, firewall rule, operating system, physical server and dedicated storage. However, this simplicity comes with the full scope of security of the entire environment and technology stack. The leading tech companies largely moved away from this model in the early 2000’s because it is inefficient in terms of resource utilization, portability of applications and velocity of deploying new software at scale.
Enter Virtualization
Organizations looking for more efficiency and utilization from their technology assets found an increase as virtualization came onto the scene. Now companies can run multiple Operating Systems (OS) and application stacks on a single stack of physical hardware.
For security teams, virtualization increases the density of their asset inventory compared to physical assets. This means the asset inventory no longer has a 1:1 correlation with physical assets and the attack surface for the organization will shift towards the OS, Application and Network layers. In this model security teams still need to focus on the full scope of security, but it also allows the organization to begin taking advantage of modern IT infrastructure and deployment concepts.
One extremely important concept is the idea of immutable infrastructure. With immutable infrastructure the organization no longer makes changes to things in production. Instead, they update, patch or improve on their virtual machine images and production applications in their development or test environments and then push those into production. This means development teams can increase the velocity of the software development lifecycle (SDLC) by fixing once and deploying many times. It also means security teams can more tightly control the production environment, which is the highest area of risk for the business.
Moving To The Cloud
At some point your organization may make the decision to migrate to the cloud. Migrating to the cloud offers a number of benefits such as no longer having to purchase and manage depreciating assets, no longer having to staff people to physically manage hardware, no longer having to pay to protect and insure physical assets, increased development velocity and the ability to scale compute, storage and network as needed.
For the security organization, moving to the cloud means you no longer need to worry about physical assets such as network, storage or compute. Your cloud provider now takes care of those layers and so your team has reduced physical scope, but increased logical scope, which results in increased attack surface. Development teams can now deploy with increased velocity and so it is incredibly important to enforce good security hygiene. Shifting security as far left as possible within the CI/CD pipeline and automating the security checks are incredibly important. Similarly, putting guard rails in place to control the environment will be really important to avoid magnifying security issues at scale. Some things to think about are:
- Tagging is required for security, finance, development, etc. otherwise the deployment fails or the instance is shut down
- Object storage private and encrypted by default
- Only specific and required network ports allowed
- NACLs, ACLs, WAF and/or proxies configured and deployed by default based on service or application
- Applications are not allowed in production with critical or high vulnerabilities
- Security logging at each layer sent to object storage, filtered and then sent to a centralized SIEM
- Control software libraries to minimize software supply chain risks
- OS images patched, hardened and loaded with required agents
- Identifying and controlling the flow of data to avoid data leakage
- Setting and enforcing data retention policies to no only control costs, but reduce the volume of data that needs to be protected
Moving to the cloud allows organizations to dramatically improve the velocity of development and as a result security teams need to shift their controls left in order to improve security and increased visibility without impeding velocity.
Commoditizing The OS Layer
Lastly, once organizations are in the cloud they can begin to ask questions like – what if the OS didn’t matter? What if memory, compute, storage and everything below the application layer was taken care of automatically and all developers need to worry about is the actual application? Enter containers and kubernetes.
Containers and kubernetes allow organizations to scale their applications with incredible speed. All developers need to worry about is to package up their application in a container, deploy it into the cluster and let everything else happen automatically. This model presents both a challenge and an opportunity for security teams.
First, all of the security checks we discussed previously need to happen within the build process and deployment pipeline to make sure organizations aren’t amplifying a vulnerability across their applications.
Second, security teams will continue to make sure the underlying kubernetes clusters meet their security requirements, but the main focus will be on the application layer. Controlling ingress and egress of network traffic going to the application, making sure software libraries are approved and free of vulnerabilities, ensuring software security checks like SAST, DAST and even fuzzing of interfaces are performed before deploying to production will be incredibly important. It will also be important to maintain an inventory, but this wont be a typical inventory of who owns an OS or compute instance. Instead, this inventory will map which team owns a particular application. This will be important for events like Log4j so the appropriate dev team can identify and remediate software libraries or flaws in their applications quickly and then re-deploy. Remember the environment should be immutable so security teams will need to scan, monitor and respond to vulnerabilities detected in production quickly since the attack surface will be much larger in this model.
Wrapping Up
No matter where your organization is in their cloud journey security teams need to identify their scope of responsibility and apply security best practices within their environment. Organizations still in data centers will require security teams to address the full scope of security from the physical layer to the application layer and everything in between. As organizations begin to adopt technologies like virtualization, development velocity should begin to increase and security teams will need to adapt. Moving to the cloud is a big step, but will pay dividends to the organization in terms of increased velocity. Organizations no longer have to acquire or focus on physical hardware and so they can staff more software developers. Likewise, the security teams will need to adjust their requirements and controls to focus on the OS layer and above. Lastly, organizations that have moved to container technologies or embraced kubernetes will have tremendous velocity and security teams will need to make sure the appropriate checks are integrated into the CI/CD pipeline so vulnerabilities aren’t magnified across the entire environment. In order to avoid this security teams need to focus primarily on the application layer and automation will be key.
370 Security Blog 