AWS ECS vs AWS EKS: AWS Container Services Explained

Containers are used to host code without the complexity and resource demands of virtual machines. They allow developers to combine code and dependencies into a standardized package that runs anywhere, making them the ideal foundation for cloud-native applications and microservices.

But containers pose a problem. How do developers and DevOps professionals manage container creation, hosting, networking, and security? A business may deploy dozens of containers to host its apps and services. It’s challenging to manage all of them individually, so, ideally, container management should be automated.

That’s the role of container orchestration software. Container orchestration tools manage the container lifecycle: provisioning, deployment, scaling, networking, and more. Kubernetes—originally developed by Google—is one of the most widely used container orchestration tools.

Amazon Web Services offers a number of container and container orchestration services, including Amazon Fargate, Amazon Elastic Container Service (ECS), and Amazon Elastic Kubernetes Service (EKS). Although all play a role in container hosting and orchestration, they are not identical, and it can be a challenge to understand which is the right orchestration tool for your AWS environment.

This article focuses on the differences between the main AWS container orchestration services: ECS and EKS, and on container security more generally. But to understand those, we have to start with Amazon Fargate.

What is Amazon Fargate?

Amazon Fargate is a serverless infrastructure platform for containers. In this context, “serverless” doesn’t mean containers don’t run on servers. It means the user doesn’t have to concern themselves with managing and paying for servers. Instead, they pay for just the compute resources their containers consume.

It’s useful to contrast Amazon Fargate to EC2, Amazon’s virtual server platform. To host containers on EC2, you have to provision EC2 instances with specific storage, compute, and memory capacities; configure them to run containers securely, and then manage both the containers and the EC2 instances. You pay the full cost of the instances while they’re running.

In contrast, Amazon Fargate allows you to build container images, specify memory and compute resources, and deploy. You don’t have to manage, configure, or scale servers, and you only pay for the compute resources your containers consume.

You’ll note that we’ve not mentioned container orchestration yet. That’s because Amazon Fargate is not a container orchestration service. It’s a serverless container platform on which you can deploy containers managed by a container orchestration service. On AWS, you have two main orchestration options to manage containers running on Fargate: ECS and EKS.

What is Amazon ECS?

Amazon ECS is a managed container orchestration service that runs Docker and Windows containers. It offers a complete orchestration solution with support for Docker image repositories, versatile container deployment and management tools, networking services including service discovery, and container monitoring and logging via Amazon CloudWatch and CloudTrail.

By default, ECS deploys containers to Fargate, although it can manage containers hosted on EC2 or on-premises infrastructure with ECS Anywhere or AWS Outposts. That makes it an excellent choice for businesses that want a fully managed solution and that don’t need Kubernetes compatibility.

It’s important to note that Amazon ECS is based on proprietary Amazon technology. It is not fully portable between cloud platforms.

What is Amazon EKS?

Amazon EKS is a managed Kubernetes service to orchestrate containers hosted in AWS and on-premises. Like ECS, it can orchestrate containers running on AWS Fargate and on EC2 instances. The key benefit of EKS is that it is fully compatible with Kubernetes—it’s based on upstream Kubernetes, so clusters that run on-premises or on other cloud vendor platforms can be moved to EKS with no modification.

Amazon EKS vs Amazon ECS: Choosing A Container Service

The most important distinction between ECS and EKS is that EKS runs Kubernetes. If your business relies on the tooling and architecture provided by Kubernetes, then EKS is probably the best choice. EKS also provides more granular control over how containers are managed, but more control leads to greater complexity.

In contrast, ECS is a simpler container orchestration system. It is intended for businesses that don’t want or need granular control over every aspect of container deployment and management. ECS also integrates tightly with other AWS services, such as CloudWatch and Route 53. That’s a benefit if you want to use those tools, but a drawback if you’d prefer to use different tooling.

AWS Container Security Best Practices

Whichever AWS container orchestration tool you select, your organization is responsible for securing containers and the code and data they contain. As with servers, container misconfiguration is a significant risk vector. Amazon Fargate helps to reduce risk because users don’t manage the underlying server and network infrastructure. However, businesses must nevertheless follow container security best practices.

 Use Minimal Images

Containers should run as little code as is practical. Each additional library or service increases the attack surface area. Ideally, containers include only your code and its essential runtime dependencies, excluding development dependencies and other redundant code. If possible, use distroless images or a security-focused lightweight distribution such as Alpine.

Minimal images are also significantly smaller, which means they consume fewer resources and are easier to audit and scan for security purposes.

Use Curated Images from a Secure Container Repository

Image repositories are a potential source of malicious code. It’s estimated that 20% of the most popular images in major public repositories contain vulnerable or malicious code.

Bad actors seeking to infiltrate malware may target insecure public and private repositories in so-called supply-chain attacks. If they can get malicious code into an image hosted in a container repository, that code may find its way inside your networks.

To combat this risk, businesses should create a set of curated images free of known security vulnerabilities. They should store images in a secure repository service, such as Amazon Elastic Container Registry. ECR integrates securely with Amazon ECS and Amazon EKS, and it allows users to create repositories with access permissions managed by AWS Identity and Access Management (IAM).

Don’t Run Containers or Processes Within Containers as Root

Containers should not run as the root user and nor should processes within the container.

  • If a process running as root is compromised, the attacker may use root privileges to modify the container’s contents.
  • If the container itself runs as root, a bad actor may be able to escalate their privileges on the container’s host operating system in the unlikely event of a container breakout.

Unfortunately, containers often run as the root user by default, so Dockerfiles should be modified to use the USER directive to specify a non-root user.

Don’t Hardcode Credentials

Avoid hardcoding credentials such as passwords or API keys in code that will run in a container, including AWS credentials. If systems that store or process the code are compromised, an attacker will gain access to the credentials.

AWS provides several methods for storing secrets and securely injecting them into containers, including the AWS Secrets Manager. Secrets Manager also enables users to easily rotate secrets, which may not be possible when they are included in production code.

To learn more about container security and all aspects of AWS security, visit our extensive library of AWS security resources.

Protecting MSPs from Million Dollar Ransomware Attacks

The DarkSide Ransomware Attack on CompuCom

On March 3, the IT managed service provider (MSP) announced they had fallen victim to a Darkside ransomware attack. The cybercrime group installed CobaltStrike beacons on several systems throughout the MSP’s environment. These beacons helped the threat actor steal data, spread the virus, and deploy ransomware payloads. 

The MSP expects the incident to result in losses of $20 million and counting due to the disruption of customer services and internal operations. Since CompuCom is up for sale, the attack has come at an inopportune time for the company. 

Read more

5 Best Practices to Integrate Cybersecurity With Your Business Strategy

What Does an Effective Business Strategy Look Like?

For many businesses, it’s been a long time since the business strategy was initially developed. If it was created a few years ago, it’s likely missing cybersecurity as one of its strategic initiatives. The role of cybersecurity has dramatically changed for the C-suite and should be re-evaluated in terms of its impact on strategy.

Any successful business will have a solid definition of its mission, values, and goals. In today’s landscape, every organization is in the business of cybersecurity. It should have significant part to play in the overall strategy for the company’s success. How can you do this? By adopting the following five best practices to integrate cybersecurity with your business strategy.

5 Ways to Integrate Cybersecurity With Your Business Strategy

Integrating cybersecurity with your business strategy shouldn’t be as painstaking as it may initially seem. Whether you’re in the beginning phases of establishing a business strategy or your organization is re-evaluating your long-term goals, you can follow these five best practices as a starting point to integrate cybersecurity with your business strategy.

1. Identify your business’ key goals and aspirations

What is the overall purpose of your organization? Evaluate the specific milestones you have set to realize that purpose and now look at them in a new way. How does cybersecurity make or break the mission? This are important considerations to integrate into your strategic initiatives.

2. Pinpoint areas of weakness in your cybersecurity hygiene

When you evaluate risk throughout the organization, C-level executives are particularly strong at considering threats impacting financial risk, competitive changes, loss of key employees, market shifts, environmental events, and other disasters. Now, add cybersecurity risk to this same equation. Don’t make the mistake of assuming an IT department is covering this base. Executives must seek out the same details on potential impact from cybersecurity threats as they do in other areas. Conducting a risk analysis can help you identify weak areas in your cybersecurity hygiene and risk-rank vulnerabilities that need to be addressed first. You might need a third-party information security expert to provide an unbiased view of your risk. Specialists at KirkpatrickPrice can help pinpoint weak areas in your cybersecurity hygiene, give you advice on how to remediate those findings, and help fine tune your strategic initiatives.

3. Determine how your people, processes, and technology need to evolve

The cybersecurity landscape is constantly changing, and you need to make sure that your people, processes, and technology are able to swiftly adapt. Humans are generally the root cause of security incidents – whether it’s out of ignorance or deceit – and so it’s up to your organization to ensure that all personnel understand the cyber threats they’re faced with on a day-to-day basis. Requiring annual, thorough security awareness training is one way to do this. As for your processes and technology, how often do you update them to meet information security best practices? Do you conduct internal audits to validate the security of your processes and technology? Are you making investments in technology that will improve the cybersecurity of your organization?

4. Implement a strategy for cybersecurity best practices

Once you’ve identified your key goals and aspirations, identified areas of weakness in your cybersecurity hygiene, and found ways that your people, processes, and technology need to evolve, you need to decide how exactly you’ll be implementing these five best practices. Will you use a framework like NIST to guide your efforts? Will it require you to partner with an MSP or hire more IT personnel? Do you need to hire an independent, third-party firm to validate your cybersecurity efforts?

5. Leverage cybersecurity and compliance for success

Strategic planning is what guides all that you do in your organization. Cybersecurity and compliance are strategic initiatives that serve as benchmarks for your business. Do we have a cybersecurity mission? Have we identified our cybersecurity goals? What are the plans to get there? Have we defined the resources we need? Are we monitoring our progress to quantify success? Ultimately, these will become strengths that are important to your clients and other stakeholders. You might train your sales and marketing teams on how to communicate your strategic differentiation in the market because of your cybersecurity and compliance strengths. Leading firms have a dedicated cybersecurity landing page on their website that explains the “why” behind cybersecurity and how it serves as a strategic goal in their business.

All in all, cybersecurity can no longer be an afterthought or kept at arms-length from the boardroom. It must be a proactive effort – one that is ingrained in the company culture and strategic purpose. If your business is struggling to adopt these five best practices to integrate cybersecurity with your business strategy, let’s find some time to talk to see how we can help you.

More Cybersecurity Resources

What is Cybersecurity?

When Will it Happen to You? Top Cybersecurity Attacks You Could Face

How to Lead a Cybersecurity Initiative

Key Takeaways from the SEC’s Cybersecurity Guidance

How Much Is Your Data Worth to Hackers?

How much do you think a buyer on the dark web would pay for stolen data?

How much would you estimate a hacker can profit off of personal data?

The truth is, the price of stolen data is worth the risk for hackers but always costly for organizations that store, process, transmit, or destroy personal data.

How Do Hackers Make Money?

When a system is breached and personal data is stolen, the hacker involved in the malicious activity will typically sell or advertise that data on the dark web. Even if your company is small, a hacker will cast a wide net to obtain stolen information from multiple sources.

If they steal personal data from your organization, it will cost you money – that’s the end of it. It’s up to you to decide if the cost of stolen data is worth it, or if proper information security testing is a better investment.

How Much is Hacked Data Sold For

Symantec released an in-depth Internet Security Threat Report in 2019 that lays out a cost sheet for the most commonly sold personal data.

Here’s how much hackers earn after stealing the personal data you are responsible for:

  • Online banking account – 0.5%-10% of value
  • Cloud service account – $5-$10
  • Hacked email accounts (groups of 2,500+) – $1-$15
  • Hotel loyalty from reward program accounts with 100,000 points – $10-20
  • Stolen identity – $0.10-$1.50
  • Medical notes or prescriptions – $15-20
  • Stolen medical records – $0.10-$35
  • ID or passport – $1-35
  • Full ID – $30-100

While these numbers may seem small in terms of individual pieces of data, the total sum of how much is data worth starts to add up.

If you store passport data, how much could a hacker earn by breaching your database? If you process online payments, how much could a hacker earn by skimming your site? The cost of the individual may be minor, but when you view it in terms of entire databases of personal information, the costs can make a huge impact.

The Real Cost of a Personal Data Breach

Let’s take a look at a recent breach that made headlines – DoorDash. The food delivery service was breached in September 2019 when a hacker stole private information of 4.9 million customers and delivery workers which included full names, delivery addresses, phone numbers, digits of credit cards and bank accounts, and hashed passwords.

If we use the data from Symantec’s report that claims, at the cheapest price, full ID packages can be sold for $30, we can estimate that the personal data stolen from DoorDash was worth $147 million. The hacker that breached DoorDash’s system is probably sitting on a good profit right now. Do you want your organization to be the next target for a hacker looking to make a good buck off stolen personal data?

How to Stop the Hacking Money Machine

So, what can you do to protect your organization from fueling the money machine of hackers selling personal data on the dark web?

You can start by annually testing your processes and controls to make sure your system can withstand common hacking tactics, whether that’s through your internal audit team or the external penetration testers who are skilled enough to spot suspicious activity. Staying updated on current hacking tactics provides greater assurance that your employees will recognize an attack early on.

Organizations have a great responsibility to protect individuals’ personal data because they store, transmit, process, and destroy so much of it. Whether it be employee data or client data, you need to have practices in place that secure information and work against a hacker’s tactics.

If you’re interested in learning more about third party penetration testing to mitigate the risks you face, contact KirkpatrickPrice today!

More Data Security Resources

Executive Insight into the Importance of Penetration Testing

What are the Stages of Penetration Testing?

Breach Report 2019 – September

Dangers of XSS Attacks at Healthcare Organizations

In October 2019, Citizen Times reported that Mission Health, North Carolina’s sixth-largest health system and HCA Healthcare’s North Carolina Division, had disclosed a data breach caused by a cross-site scripting (XSS) attack.

Cross-site scripting (XSS) vulnerabilities rank among OWASP’s top 10 web application security risks. XXS occurs when a web application doesn’t properly sanitize user input and their input (such as malicious code) is either reflected or stored on the returned page. The best way to combat the dangers of XSS vulnerabilities is to perform code review before the application goes into production.

This attack, which injected malicious scripts into Mission Health’s e-commerce web application, wasn’t found for three years. Fortunately, the e-commerce site didn’t impact any PHI, but three years’ worth of names, addresses, payment card numbers, expiration dates, and CVV codes were sent to unauthorized individuals.

Can you imagine if this XSS attack targeted a web application that touched PHI? Could code review have found this XSS flaw? Would penetration testing have helped? This data breach is just one more example of the added precautions healthcare organizations must take to identify all areas of risk and implement cybersecurity best practices, even if they have to go beyond HIPAA requirements.

Cybersecurity in Healthcare

The amount of data breaches that occur within healthcare prove it to be an industry that isn’t keeping up with the cybersecurity threat landscape. According to IBM’s 2019 Cost of a Data Breach Report, the healthcare industry has the most expensive data breaches – the average totaling $6.45 million.

What makes data breaches even more expensive? Time. The time it takes to find the breach and the time it takes to contain and respond to it. IBM reports that, on average, it takes organizations 206 days to identify a data breach and 73 days to contain that breach.

That means when a data breach occurs, it will take the organization about nine months just to find and stop it. Unfortunately for Mission Health, the time it took them to find the injected malicious scripts was about three years – much higher than average.

Perform Code Review to Find Cross-Site Scripting Flaws

Cross-site scripting occurs when a web application doesn’t properly sanitize user input and their input (such as malicious code) is either reflected or stored on the returned page. In Mission Health’s case, it was stored – which can have a severe impact. Web applications are one of the most common attack surfaces for data breaches, and OWASP has determined the XSS flaws are among the 10 most critical security risks to web applications.

It’s extremely difficult to find and remove XSS flaws from a web application, but OWASP says:

“The best way to find flaws is to perform a security review of the code and search for all places where input from an HTTP request could possibly make its way into the HTML output.”

Code review is a tedious job, but someone needs to do it so that XSS flaws or injected malicious scripts don’t go unnoticed for three years.

Part of thorough code review is testing against OWASP’s XSS prevention rules:

  • Never Insert Untrusted Data Except in Allowed Locations
  • HTML Escape Before Inserting Untrusted Data into HTML Element Content
  • Attribute Escape Before Inserting Untrusted Data into HTML Common Attributes
  • JavaScript Escape Before Inserting Untrusted Data into JavaScript Data Values
  • HTML escape JSON values in an HTML context and read the data with JSON.parse
  • CSS Escape And Strictly Validate Before Inserting Untrusted Data into HTML Style Property Values
  • URL Escape Before Inserting Untrusted Data into HTML URL Parameter Values
  • Sanitize HTML Markup with a Library Designed for the Job
  • Avoid JavaScript URLs
  • Prevent DOM-based XSS
  • Use HTTPOnly cookie flag
  • Implement Content Security Policy
  • Use an Auto-Escaping Template System
  • Use the X-XSS-Protection Response Header
  • Properly use modern JS frameworks like Angular (2+) or ReactJS

Web Application Penetration Testing

Once code review is performed, a web application penetration test should also take place. The goal of the penetration test is for no additional web application vulnerabilities to be discovered. If there are, that means the code review wasn’t thorough enough – but penetration testing is valuable for validating this.

Web applications can be problematic for many security analysts who don’t have the experience to be testing them – especially if it’s done in conjunction with code review. We often see other firms blindly assign an analyst to a web application project, but without the proper knowledge and expertise, a penetration tester can miss important findings within the web application. That’s why web application penetration testing methods at KirkpatrickPrice include the following, plus more:

  • Forced Browsing
  • Session Management
  • Cookie Manipulation
  • Source Code Disclosure
  • Response Splitting
  • File Upload/Download Attacks
  • URL Manipulation
  • Injection Attacks for HTML, SQL, XML, SOAP, XPATH, LDAP, Command
  • XSS

At KirkpatrickPrice, we also take a hybrid approach to code review that includes both automation and manual assessment in order to find any vulnerability that, if discovered, could be abused. Our team of highly skilled penetration testers have the expertise to understand the complexities of your code.

If you want to avoid a data breach due to unnoticed, cross-site scripting flaws like the one at Mission Health, contact us today.

More Penetration Testing Resources

Guide to 7 Types of Penetration Tests

Think Like a Hacker: Common Vulnerabilities Found in Web Applications

7 Reasons Why You Need a Manual Penetration Test