Choosing solutions for container security on AWS.
Even the best security measures can’t prevent all security incidents. With the right tools, you can detect and respond to incidents quickly. The problem is not anymore that you have no tools at hand but that you have too many. How do you choose the right one?
Eliciting Requirements
The Task - nonfunctional requirements
An application needs data from the internal network. Because of the licensing restrictions, it is impossible to deploy using different AWS accounts. The application should run on containers in the AWS cloud.
The main requirement is that 24x7 operational monitoring detects possible problems and alerts a SOC team. The SOC team should be able to react to incidents and get a detailed overview of the application’s security status.
This is a tiny little bit simplified to show the decision process.
Breakdown of requirements
ID | Requirement |
---|---|
1 | Containerized application |
2 | Single AWS account deployment |
3 | 24x7 operational monitoring |
4 | Detailed overview of security status |
5 | Alerting the SOC team |
So many options
So, as an AWS builder, you have many presents on a birthday. You have many options to choose from, but you have to choose wisely.
Container
The main philosophical battle for running containers on AWS is using EKS, which stands for Kubernetes or ECS. If you just look at the pros and cons, it becomes simple at first glance.
Feature | EKS | ECS |
---|---|---|
Cost | High | Low |
Existing knowledge | High | High |
Complexity | High | Low |
Running multiple workloads | Yes | No |
Container Start time | Low | High |
Making decisions based on such a table is fundamentally wrong and leads to wrong decisions. You have to add the weighing of the feature anditsits applicability.
And the features should be measurable with a defined metric.
Let’s add the missing data and discuss one point as an example:
Feature | EKS | ECS | Weight | Applicable |
---|---|---|---|---|
Cost | High | Low | 20% | Yes |
Exsting knowledge | High | High | 50% | Yes |
Complexity | High | Low | 30% | Yes |
Running multipe workloads | Yes | No | 0 | No |
Container Start time | Low | High | 0 | No |
So, first, let’s look at the cost. EKS costs about $80 per month just for the management nodes. ECS does not need extra EC2 instances.
But in most projects, 80$ a month is neglectable. So the cost is no factor. With knowledge of both technologies, this factor is also not relevant.
Feature | EKS | ECS | Weight | Applicable |
---|---|---|---|---|
Complexity | High | Low | 100% | Yes |
In a nutshell, if you run a single workload on an AWS account, ECS is much simpler.
Single AWS account deployment
The preferred way to separate development stages like development, testing and production is to use different AWS accounts.
If that is not feasible due to restrictions, you should at least use different VPCs. You can restrict access to the different VPCs with a proper IAM setup. So, the solution is not less secure than the multi-account setup. It is just more complex.
Connection to an internal network
If you need to connect to an internal network, you must use a VPN or a Direct Connect (DX). Direct Connect is only required if you have lots of data and need a dedicated line.
To connect to a VPN, you could use DX to single VPCs. The more powerful solution is an AWS transit gateway, which allows VPN access to multiple VPCs at once.
Simplified Architecture so far
Security requirements
Again, the problem is more having too many options. To define a technical and organisational security architecture, we have to widen the scope from the single application to the whole company.
Most larger companies have a security response team that deals with several technologies. Again, one question to ask is, “Do they know AWS?”
I invite you to do a little experiment for the other main question. If you have an AWS account just for evaluation, enable Security Hub and Guard Duty. You will be surprised how many alerts you get.
Just enabling the “AWS Foundational Security Best Practices” will perform all these tests stated here.
As an example of how noisy it really can get, look at this retired control: CloudFormation.1 CloudFormation stacks should be integrated with Simple Notification Service (SNS)
If you enable the SNS integration, you get an SNS topic for EACH resource in the stack. So, if you have a stack with 100 resources, you get 100 SNS topics.
To know whether a control is reasonable, you must know the context and have enough AWS knowledge to decide on actions. With this knowledge, you can adjust the controls to fit your needs.
Solutions
Organisational solutions
ID | Requirement |
---|---|
3 | 24x7 operational monitoring |
4 | Detailed overview of security status |
5 | Alerting the SOC team |
With a larger customer with many workloads not only on AWS, an organisation like this is needed and implemented with tecRacer AWS Managed Services.
- The noise is filtered
- False positives are reduced with a filter
- Real issues can be fixed
- Dashboards are created to see the health of the whole architecture. Sometimes, with the dawning of new security threads, you do not have a security control yet, but you notice an anomaly in the dashboard.
- If customer involvement is needed, the SOC team can react.
Technical solution: enhancing AWS security with Trend micro
AWS services like config, cloudtrail. guardduty are optimized to detect alerts on AWS networks and services. In addition to the network security, you can use Trend Micro to secure the containers. Yes, there is a service like inspector.
Our MSSP team has found, during the years working with security and AWS, that the combination of AWS and Trend Micro is very powerful. In addition to the AWS network scanning, the application itself must be scanned. So, if you have a container with a vulnerability, it will be detected.
Trend Micro
Trend Cloud One - Container Security provides container security on many levels. To understand that sentence, we do a simplified thread analysis.
You can look at the application itself and then expand the scope level by level:
Level | Security | AWS | Trend Micro Cloud One |
---|---|---|---|
1 | Application | Amazon Inspector | Trend Micro Artifact Scanner |
2 | Container-Host-Operation System | Amazon Inspector | Runtime security/Runtime vulnerability scanning |
3 | Inter Container Network | AWS App Mesh | Trend Micro Network Security |
4 | Container Host | AWS Systems Manager/Inspector | Cloud One™ – Conformity |
5 | AWS Network/VPC | GuardDuty | Use VPC Traffic Mirroring to send traffic to Trend Micro Cloud One™ – Conformity |
6 | Internet | Ensure encrypted data transfer | Ensure encrypted data transfer |
7 | Human | Teach your staff | Teach your staff |
It would take hours to go into each detail. The general takeaway is that while you have separate services on AWS for each level, Trend Micro Cloud One provides a single pane of glass for all levels.
Summary
Choosing your security solution on AWS depends on many factors.
Diversity of workloads: If you have many different workloads and also different cloud providers, lean towards Cloud One. With AWS only and a single workload, lean towards AWS services.
Security team: If you have an established dedicated security team with deep knowledge and experience in AWS and security, lean towards your own team. If you need experts with experience in AWS and security, lean towards choosing tecRacer MSSP.
The scale of your enterprise: If you have a large enterprise with many workloads, have your response team work together with an external partner. A good security solution requires knowledge in many areas. Being an expert in all areas is not possible.
If you have a single workload, consult with experienced consultants to decide whether it’s feasible to protect it or delegate it to tecRacer MSSP.
Does this look like a sales pitch - yes. But my main statement is that you should not fall into a Dunning-Kruger trap here. Security on AWS is a complex topic, and you should not underestimate it.
If you want to know the state of security on the Internet, try this little experiment: Set up an unprotected Web Server with a public IP on an EC2 instance and look at the logs. When will the first attack happen?
What’s next?
If you need MSP or MSSP Hosting for your AWS workloads, don’t hesitate to contact us at tecRacer.
Thanks for reading. Enjoy building!