Best Practices for Container Security on AWS
Containers have changed how we deploy software. Learn how to better protect your containerized applications from external threats.
According to a 2018 Cloud Security Report, only 16% of organizations report that the capabilities of traditional security tools are sufficient to manage security across the cloud. This means that 84% of organizations believe that the typical approach to security does not work in cloud environments.
Clearly, there needs to be a change in approach. Security cannot be viewed as a phase of a project, an add-on, or an afterthought. Security is a pivotal aspect to any cloud initiative and especially critical in a migration. It must be a programmatic and continuous consideration.
In practice, there should be a section of the migration readiness assessment focusing on security considerations. This assessment should absolutely be completed in advance of a migration. It can identify programmatic or system changes that are required to improve security in organizations both in the migration process and already in the cloud.
A detailed outline of security requirements is also important in advance of migration planning. It should include both goals and compliance requirements. A security framework should be in place to facilitate requirements within the migration plan. Another practice is having regular checkpoints for security and compliance at each phase of the migration itself, including acceptance testing. A documented approach that is operationalised and integrated in the delivery process ensures that organizations are continuously enforcing security constraints.
Partners like Mission or Alert Logic can help accelerate this front by focusing on monitoring security and preparing organizations for the migration readiness assessment and migration plan. They can also operationalize security framework on a 24/7 basis. Security must be an integral part of any technology roadmap, not a reaction after the fact.
At the New York AWS summit a few years ago, CTO of AWS Werner Vogels explained that security is a shared responsibility between AWS and the customer. This shared model can relieve the customer’s operational burden as AWS operates, manages, and controls the security of the cloud, while the customer is responsible for the security in the cloud. Both parties have an important role to play
Only organizations know how their items are supposed to work, who is supposed to have access, how much access should be granted, and how they want to provide access. Custom questions are intimately related to security. It cannot be part of AWS’ responsibility and this is where shared responsibility is required.
With that said, the model can be a point of confusion. Customers may assume that AWS will handle something for them when it is actually the user’s own responsibility. Working with a Managed Service Provider such as Mission, we can help take on a lot of those responsibilities associated with the customer, so the customer can spend more time focusing on their core business.
Organizations are often concerned with the configuration of their AWS environment. The configuration is one of the most important ways to take responsibility for your own environment. One of our responsibilities is always making sure that, as consumers inside the AWS infrastructure, we understand how we are set up and how we are going to work.
There are many reasons why configuration and visibility matter. There are two basic elements to this: drift and dwell time. Draft and dwell time are two things that can happen without visibility.
Organizations spend plenty of time making sure any infrastructure is secure the day they start using it. This may have been on-premise in earlier days and is now on the cloud. They work very hard to ensure it is configured correctly, identities are managed correctly, access is managed correctly, and everyone has the authorization they need. Five minutes later, it can change. Someone can log in and change a simple configuration setting. Someone can create or identify a vulnerability of the software. This is called drift. Without visibility and understanding what goes on inside the configurations, insecurity and risk can develop. When drift happens, it creates vulnerabilities that could have been preventable. 50% of breaches could be addressed by having patching in place at the right time. In many cases, people do not want to patch because they do not have the visibility or the time. Drift, as a function of configuration and visibility, is important.
Dwell time relates to understanding the ability to see what is going on in these systems. Dwell time refers to how long an attack can exist without the user knowing about it. This is a large issue because the longer an attack exists, the more damage can be done. Users need to consider how to identify if an attack happened and how to minimize the impact of it.
As we talked about before, the AWS Shared Responsibility Model can be a bit daunting. AWS shoulders a lot of the responsibility, but there is still a lot left for the user. Fortunately, there are partners and vendors like Mission and Alert Logic who can share the responsibility with you and provide you with tooling around threat detection, web application firewall, compliance reporting, scanning, and incident response, which is really critical. It doesn’t matter so much if you’re detecting issues if you’re not managing against those detections and responding to them in real time.
That’s a huge challenge to scale. A small or medium sized organization may not have the staff for a 24/7 team to provide this. Or, you may have a staff on pager duty. This is where both Mission and Alert Logic can help bolster you with a 24/7 cloud operations team that perform remediations.
There are seven tenets of Managed Detection and Response (MDR) from the MDR Manifesto, which is something Alert Logic has pioneered. MDR is based upon three core components: people, processes, and tools. This is true for any initiative but specifically for security. Alert Logic and Mission provide the MDR capability across the entire spectrum in an integrated fashion.
Alert Logic is a platform for detection. They have a 24/7 SOC, staff to respond rapidly when an issue arises. This is the management response side. In addition, Mission has a 24/7 cloud operations team. When an incident arises, the Alert Logic and Mission team jump into action and we respond.
There are several phases that are critical to response. These include collecting assets, access data, logs, events, network telemetry, endpoint information, user behavior, and file and dark web data. All of this comes together in one place through the service Alert Logic provides. It then needs to be analyzed, ingested and stored to determine correlation, behavior, and anomaly detection. Alert Logic is a platform for this.
Then, validation and investigation of the indicators of compromise is required. This process determines if an incident has occurred. Organizations must then report quickly, escalate security incidents to the responsible parties, and respond. With Mission and Alert Logic, we review the incident in real time, create response recommendations and perform those activities.
That is a tall order for any single organization to do on their own.Building out custom tools in this regard is likely not the best use of internal time. That is why Alert Logic has been so successful in providing these tools.
Staffing a 24/7 team for infrastructure management and responding to security is a challenge. Organizations need to manage detection and response. This is something that Mission and Alert Logic have partnered to provide customers.
If you are interested in going to the next step, visit https://pages.missioncloud.com/1-hour-migration-consultation to request a 1-hour migration readiness assessment, with a focus on securing your migration and keeping you secure once you’re there. In this 1-hour consulting sessions, one of our expert Solution Architects will talk about your particular workloads, challenges you are facing, if you’re looking to do a lift and shift vs. a replatform vs a complete rearchitecture, we can guide you through the process and make recommendations.