What to Consider When Choosing Managed Cloud Security Services

Cloud platforms make it easier for businesses to leverage complex technologies. Instead of buying, configuring, and managing a physical server, you deploy an instance of a server in the cloud. Instead of licensing, installing, and updating enterprise software, you deploy software for the time and purpose that you need through your provider. Cloud platforms provide many technical intricacies through a user interface, but sometimes how and what you should configure securely is not obvious. You may not be responsible for physical servers and networks, but you are responsible for the security configuration and privacy of business and customer data in the cloud.

That’s why it’s vital your company chooses the right cloud security provider or managed cloud security service to support you in your objectives. In this article, we will explore what a cloud security provider is and help you choose the right provider for your business. We’ll also take a look at some of the limitations of cloud security providers and what they can’t do. 

What is a Cloud Security Provider?

Cloud security providers offer services that help businesses to use cloud environments securely. Companies in this space range from managed security service providers (MSSPs) who offer outsourced cloud monitoring and management to SaaS and cloud software vendors with products that help businesses to avoid common cloud security issues. Cloud security software typically leverages platform APIs, adding enhanced security functionality that is not available on the platform itself. 

Among the services a cloud security provider may offer are:

  • Security hardening, including configuration analysis to identify and mitigate vulnerable security and privacy configurations. 
  • Log analysis to identify security events and threats.
  • Exploit prevention through patching or firewall configuration. 
  • Network intrusion and threat detection. 
  • Malware scanning and ransomware protection. 

Cloud security providers typically have expertise in a specific cloud platform, although some offer solutions targeting multiple cloud platforms or hybrid clouds with cloud and on-premises infrastructure. 

Does Your Business Need a Cloud Security Service?

Cloud platforms, including Amazon Web Services (AWS), operate a shared responsibility model for security. The vendor takes care of some aspects of security, leaving others to the customer. Where exactly the line is drawn depends on the service: IaaS leaves more to the user than SaaS, but the user always retains some responsibility. 

For example, AWS provides secure data storage, but if the user uploads unencrypted data to an S3 bucket with misconfigured access permissions, the platform will do nothing to stop them. 

That’s where cloud security providers come in. Cloud security providers help cloud users with their share of the cloud security and privacy burden. They offer services that enable businesses to avoid the type of mistake just described. However, the ultimate responsibility for information security and privacy always rests with your company. If private customer data leaks or your business fails to comply with HIPAA or PCI DSS, you will suffer the consequences, not the cloud security provider. 

5 Questions to Ask Cloud Security Service Providers

Businesses should assess cloud security providers before engaging them, but information asymmetry can make this difficult. You may need help precisely because your organization lacks internal cloud security expertise. But without that expertise, how can you adequately assess the services on offer? A vendor compliance assessment can help, and in the initial stages of vendor research, asking the following questions will give you an idea of a prospective vendor’s capabilities. Ultimately, communication and clear expectations are key.

Is Cloud Security Your Core Competency?

Many MSSPs and cloud outsourcing service providers offer security-related services. However, “cloud security” is a broad area. A service provider may advertise their ability to make your cloud environment more secure. But their security efforts may be limited to deploying an off-the-shelf monitoring solution that will bombard your internal team with alerts. Also, the default services may not be as comprehensive as you need. For example, they may monitor Windows systems but not Linux. 

That may be all you’re looking for, but an expert cloud security provider can go much further. They will employ a technical team with expertise in IT and cloud security. Their technicians will have hands-on experience with real-world cloud environments and understand how to mitigate potential security issues. Just as important, they will understand the regulatory environment your company operates in and how to leverage cloud technologies to maintain compliance. 

Before engaging a cloud security vendor, ask about their experience, qualifications, certifications, and tools. 

What Will You Do to Keep Our Data Secure?

This question elicits information about the vendor’s products and processes. As we said earlier, businesses need to know what cloud vendors mean by “cloud security.” You may want to ask the following questions:

  • Will you assess our cloud environment’s configuration for mistakes that may cause security vulnerabilities?
  • Will you monitor our environment for potential intrusions and malware?
  • When you find a problem, will you help mitigate the risk, and what form will that help take?
  • Do your services include asset discovery, threat intelligence, and behavioral monitoring?
  • How do you document actions taken and assigned tasks? 

If possible, you should have a clear idea of your cloud security issues before beginning the vendor selection process. If you know what you are trying to achieve, you can ask focused questions about how the vendor can help you meet those objectives. Businesses lacking internal cloud security expertise should consider hiring an independent third party to assess cloud security risks and develop a mitigation plan. 

Does Your Infrastructure Comply with Information Security Standards?

Consider the following scenario. A company contracts with a cloud security provider to reduce risk and ensure sensitive data storage and processing complies with information security and privacy standards. The company gives the provider access to its cloud environment. Later, the provider’s network is hacked, and bad actors gain access to the data the company hired the vendor to protect. 

This is not an unusual outcome, so it’s essential to verify prospective cloud security vendors follow best practices for their own infrastructure and software. Third-party security audits are helpful here. Ask prospective vendors to demonstrate they are compliant with relevant industry standards, such as SOC 2 and ISO 27001. Also, be sure to inspect their penetration testing results.

Do You Understand the Security and Privacy Concerns of My Industry?

Ensure that cloud security vendors understand your industry’s legal and regulatory requirements. The specifics vary, and a vendor focused on general cloud security concerns may not have the experience or expertise to help you comply with HIPAA, PCI DSS, FISMA, and other standards. 

Do You Offer Security Awareness Training?

Cloud security concerns more than just technology. Many data breaches result from human error and inadequate awareness of security risks. Security awareness training tailored to your company’s security and compliance needs can reduce security risk while improving compliance. 

The Limitations of Cloud Security Providers

A cloud security provider or managed security service provider can reduce security risks, but they can’t objectively verify that your cloud environment is secure or compliant. The optimal approach combines cloud security best practices with cloud security assessments and audits by a qualified independent auditor with cloud and information security expertise. 

KirkpatrickPrice is a licensed CPA firm specializing in information security compliance. Contact a cloud security expert to learn how we can help your business improve cloud security and comply with relevant regulations and industry standards.

How to Design Effective Security Compliance Programs

Security compliance is a primary concern for data-driven, technology-empowered businesses. On the one hand, they face internal and external security threats ranging from ransomware and phishing attacks to malicious insiders and human error. On the other hand, regulatory frameworks such as HIPAA and the GDPR impose stringent security and privacy standards with legal and financial penalties for non-compliance. 

A security compliance program helps a business to own its compliance risks. However, there are numerous challenges along the path to a security compliance program that supports long-term compliance goals. This article explores security compliance programs and suggests strategies to help businesses manage security compliance risks.

What Is a Security Compliance Management Program?

A security compliance program is the policies, procedures, and processes an organization creates to maintain security standards, typically based on regulatory frameworks such as HIPAA or recognized industry standards such as SOC 2. 

Security compliance programs also encompass the mechanisms by which the organization reviews and assesses information management practices. Without ongoing monitoring and auditing, it’s impossible to verify the organization is complying with its own policies.

Perhaps most important, security compliance programs are people-focused; they aim to create a management framework with resources and incentives that encourage employees to follow security best practices. 

An organization without a security compliance program may follow security best practices in an ad-hoc manner, but then again, they may not. Information security and privacy concerns are often deprioritized relative to other business goals. A security management program supported by an organization’s leadership helps align business practices with security compliance objectives. 

A security compliance management program enables organizations to:

  • Comply with regulations such as Sarbanes-Oxley, the Health Insurance Portability and Accountability Act (HIPAA), and the Payment Card Industry Data Security Standards (PCI DSS), among many others. 
  • Protect data assets and reduce the legal, financial, and reputational risk of regulatory compliance failures. 
  • Design policies and implement processes that allow executives to exercise control over the organization’s security posture.
  • Monitor and verify security compliance 

Those interested in building a security compliance program may find it instructive to read the U.S. Department of Justice Criminal Division’s Evaluation of Corporate Compliance Programs. Although broader in scope than information security, it explains the factors that prosecutors look for when evaluating compliance.  These include the presence of risk assessments and risk management processes, well-designed and comprehensive policies, risk-based training, properly scoped investigations by qualified personnel, internal and external audits, and more. 

The Components of Effective Security Compliance Management 

A security compliance management plan is tailored to the business’s needs and the environment in which it operates, but effective security compliance programs are built on the following components. 

Security Compliance Policies

Policies are the key documents in a security compliance management program. Security compliance policies describe the minimum security standards with which the organization intends to comply. Policies should be informed by a variety of factors, including:

  • The organization’s business objectives,
  • The regulatory environment in which the business operates, and
  • The specific risks the organization faces. 

Policies are long-lasting, high-level documents, but they are not permanent. A company must be prepared to evolve policies in response to changes in the organization, its operating environment, and the technology on which it relies. 

Structures to Implement Security Compliance Policies

Policies are only useful insofar as they are implemented, but this is often the biggest challenge. Security compliance impacts almost all aspects of modern business: data is a key asset, and information technology is ubiquitous. 

There are two possible approaches. The first is to “bolt” security compliance onto existing business processes. However, as Gartner’s research makes clear, this is unsustainable and unscalable. It makes security a potential hindrance to normal operations, creating the risk that compliance processes are bypassed as managers and employees prioritize efficiency. 

The second approach is to make security compliance an integral part of business processes. As workflows are designed, compliance is “baked in,” informing organizational structures, processes, relationships with business partners, and technology choices. 

Learn more about building compliant business processes in Auditor Insights: Compliance from the Start.

Whichever approach is chosen, security compliance management requires leadership and clear communication with stakeholders throughout the organization. A typical security compliance management structure includes:

  • A leader with authority to sponsor security compliance projects. This may be an executive or a security compliance steering team with executive support. 
  • Participation from relevant stakeholders within the organization. This might include stakeholders from IT, information security, sales, finance, and other business units. The IT department plays a critical role in security compliance. Still, other stakeholders should also be involved to reduce the risk of security compliance procedures failing to align with broader business objectives. 
  • A compliance manager or managers with information security expertise. The compliance manager is responsible for overseeing compliance projects that integrate security compliance throughout the business. For example, the compliance manager may work with IT to implement encryption policies for sensitive data. The compliance manager also gathers evidence to assess compliance efforts’ effectiveness and inform future policy and process changes. 

Additionally, it is usually necessary to offer information security training. Any employee who has access to potentially sensitive data should receive security awareness training that prepares them to comply with information security policies. 

Security Compliance Evaluation and Auditing

Compliance monitoring and internal audits are essential. Security compliance is a continuous process of implementation and evaluation. Policies evolve as regulatory standards change, and procedures and outcomes must be re-evaluated to ensure they meet security compliance objectives. Internal monitoring and evaluation should be augmented by external audits conducted by experienced auditors with information security expertise

Implementing a Security Compliance Management Program for Your Business

There is no universally applicable template for building a compliance management program. Every company is different, and so are its compliance requirements. However, most businesses benefit from a plan which follows these steps. 

  • Conduct a risk assessment to establish which risks the company faces, including compliance risks. 
  • Develop policies and standards to mitigate those risks. 
  • Appoint a compliance leader to oversee implementation and communication with stakeholders. 
  • Implement processes, procedures, and tools that support compliance policies. 
  • Train and educate employees to understand your compliance objectives and the role they play in achieving them. 
  • Monitor compliance and conduct internal and external audits to measure how effective your compliance efforts are. 
  • Act to correct risks and compliance failings identified by monitoring and audits. 

As we mentioned earlier, security compliance management is an ongoing process. The steps outlined above should be thought of as a cycle rather than a linear process that will be complete at a point in the future. 

To learn more about how audits can help your business achieve its security compliance objectives, visit KirkpatrickPrice’s Compliance Audit Services or contact a security and compliance expert today.

How to Keep AWS Access Keys and Other Secrets Safe

Information security in the cloud depends on the proper management of secrets, including AWS access keys. Authorized users and code must authenticate to use cloud resources. Authentication relies on shared secrets, but shared credentials may create security vulnerabilities, especially when they are shared naively by embedding them in application code. 

Embedding AWS access keys in code seems an efficient solution when, for example, your code needs to interact with the S3 API to store data in a bucket. However, doing so exposes the keys to anyone who sees the code. AWS keys have often been exposed in this way when code is uploaded to version control services like GitHub. However, code needn’t be exposed publicly for embedded access keys to cause a vulnerability. Anyone inside the company with code access can view credentials they may not be authorized to use, undermining authentication and access control strategies. 

In this article, we explore secure alternatives to embedding AWS access keys and other secrets in code. 

What is an AWS Access Key?

Access keys are AWS’s primary long-term credential for programmatic authentication.  An AWS access key consists of an access key ID and a secret access key; together, they authenticate requests to AWS APIs, allowing users to interact with AWS services from their code, including via AWS CLI clients and SDKs. 

AWS access keys are associated with users in the AWS Identity and Access Management (IAM) platform. Because they are the programmatic equivalent of a username and password, they should be protected with the same diligence. Just as you wouldn’t embed your password in code, you should not embed your access key. 

How to Manage AWS Access Keys Securely

We’ll look at two ways to manage AWS access keys securely. The first is to avoid using them altogether, instead using temporary security credentials associated with AWS roles. The second takes advantage of AWS features to use access keys without exposing them needlessly. 

But before we get to secure key management, a word of warning about the root users’ access key. The IAM root user has unconstrained access to every AWS resource. A bad actor may shut down servers, delete data, create and destroy users, or any other AWS API capability with the root user’s key. For this reason, you should not use the root access key, and you should disable root user access keys already in use. In fact, it is good practice to avoid using the root account unless it’s strictly necessary, as we discussed in 10 Top Tips For Better AWS Security Today.

IAM Roles vs. IAM Users

An IAM role is an AWS identity with a set of permissions for making requests to AWS resources, but, unlike AWS users, roles are not associated with an individual. Users and applications can “assume” an IAM role, which allows them to take on the role’s permissions. Another way of putting it is that roles enable AWS customers to delegate permissions to other entities. 

Roles have a couple of major advantages. First, a role can be attached to entities such as EC2 instances. That means the EC2 instance can request resources in line with the role’s permissions, obviating the need to embed an IAM user’s AWS access key in the code.  Second, roles can be used to create temporary credentials. IAM access keys are permanent until they are deleted, whereas a role’s temporary credentials automatically become invalid once a configurable time has elapsed. 

Secure Use of AWS Access Keys

In some cases, you may prefer to use an IAM user’s access key instead of an AWS role, but you should not embed credentials in the code. Instead, you can safely store the access key in a location your code can read. 

One option is to create an environment variable within your code’s operating environment to store the key. Environment variables are managed by the environment’s operating system and can be accessed via system libraries or the AWS SDK for your preferred programming language. Several Amazon services can use AWS Secrets Manager to retrieve secrets to inject into the environment variables of containers and other resources. 

Another option is the AWS credentials file. The credentials file is a text file containing an access key. AWS SDKs and the AWS CLI will look for a credentials file and use the access key when making requests for other resources. 

These methods—roles, environment variables, credential files—are appropriate for different scenarios, but the critical point is this: embedding the AWS access key into your code is a bad idea.

How To Rotate AWS Access Keys

Rotation replaces an old key with a new key and retires the old key. AWS access keys are long-lasting credentials. If exposed, they may be exploited until the user or key is deleted. Key rotation limits the usefulness of leaked keys to bad actors.

AWS users can rotate keys in IAM without interrupting their software’s access to resources. The preferred approach is to create a new access key, update software to use the new key, and then make the old key inactive. Once the user is satisfied all software is using the new key, they can delete the original.  AWS access key rotation can be carried out in the IAM web console, the AWS CLI, and the AWS API. 

Mitigating Risk When AWS Access Keys are Exposed

We’ve discussed ways AWS users can prevent the exposure of AWS keys, but what should they do if a key is exposed? The obvious first step is to invalidate the key immediately. However, doing so will also prevent legitimate use, which could result in service disruption. Leaked keys should be invalidated as soon as possible, but you may want to rotate mission-critical software keys first. 

The exposed key may already have been used, so you must also check all resources the key grants access to. Depending on the user’s access permissions, their key may have allowed a bad actor to exfiltrate sensitive data or infiltrate malicious software. Use S3 logs and AWS CloudTrail to investigate whether the key was exploited and take action to mitigate potential risks and vulnerabilities. 

Securely Storing other Secrets with AWS Secrets Manager

You may need to securely manage other secrets in addition to AWS access keys, including SSH keys, database credentials, and third-party API keys. AWS Secrets Manager provides a solution for storing, rotating, managing, and retrieving a wide variety of secrets. 

For example, to give an application access to a database, you would store database credentials encrypted in AWS Secrets Manager. The application can query Secrets Manager, which will decrypt and return the database credentials over an encrypted connection. Access to data stored in AWS Secrets Manager is controlled by IAM permissions policies for users, groups, and roles, providing fine-grained access control. 

To learn more about AWS cloud security, visit KirkpatrickPrice’s AWS Security Services to find a wealth of cloud security and AWS audit educational content. If you would like to discuss AWS audits with an experienced auditor, contact KirkpatrickPrice today.

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.

10 Top Tips For Better AWS Security Today

As an AWS user, you share responsibility for AWS security with Amazon. Amazon provides infrastructure and services, but businesses must ensure they use those tools in line with AWS security best practices. Businesses that fail to do so make it easier for bad actors to infiltrate their networks and exfiltrate their data.

AWS security is a complex subject, but there are many straightforward security enhancements with minimal cost to the user. This article explores ten high-impact security improvements that every AWS user should implement.

Disable Unused Credentials

AWS Identity and Access Management (IAM) allows users to manage access to AWS resources. It’s an essential tool that provides fine-grained controls and insight into who has access to your cloud infrastructure and services.

As your company builds on AWS, you will create a variety of IAM users and groups to permit or restrict access as required. 

However,  usage patterns evolve, employees leave the business, and authentication requirements change. It’s common for companies to fail to update their IAM users and permissions. The result is often a mixture of new and old accounts, groups, and permissions that are no longer relevant. 

These create a security risk. Consider what could happen if a disgruntled ex-employee used an old account to shut down your cloud servers. AWS users should regularly assess IAM users, groups, and permissions, removing stale accounts to maintain access security.

Turn on Multi-Factor Authentication for IAM Users

AWS allows users to authenticate with a username and password. Together these are assumed to be information only the user knows. But there are many circumstances in which that assumption doesn’t hold. Users may share their passwords, they may choose easily guessed passwords, and passwords can be stolen.

Multi-factor authentication adds another layer of protection. In addition to a username and password, the user must enter a one-time code sent to a mobile device or prove that they possess a dedicated hardware key such as a Yubikey. This second authentication factor prevents bad actors from gaining access even if they possess a correct username and password.

Enable Amazon CloudTrail

Amazon CloudTrail allows users to log and monitor events that occur across their cloud infrastructure. A comprehensive log enhances users’ ability to discover and remediate security threats. CloudTrail logs can also be used by Amazon CloudWatch to alert employees and trigger pre-configured actions when insecure events are logged.

We recommend that Cloud Trail is activated for all regions and that CloudTrail is configured to store logs in an S3 bucket that is not publically accessible.

Do Not Use or Share the Root Account

The AWS root account has complete access to every aspect of your AWS infrastructure. The root user is created when you first set up your AWS account, and it’s helpful when initially configuring IAM users and permissions. However, if a bad actor gets hold of the root user’s credentials, they have unlimited access to your infrastructure.

To be safe, do not use the root user for day-to-day operations. Create new IAM users with only the necessary permissions. Keep the root user’s credentials safe and private. Do not share them with other employees unless strictly necessary. It is also advisable to activate MFA for the root account to protect it even if the password leaks.

Check and Restrict S3 Bucket Permissions

Insecure S3 buckets are a common cause of data leaks. S3 offers granular access controls, but they are often incorrectly configured. In recent years, many large data leaks were attributed to S3 buckets configured for public access, allowing anyone on the internet to access and steal the data. S3 bucket permissions should be regularly checked to ensure only authorized accounts and IP addresses have access.

Ensure Sensitive Resources Are Only Accessible From Internal IPs

Most AWS resources should not be accessible to connections from IP addresses outside of your private network. As we’ve already mentioned, this includes S3 buckets, but also EC2 instances, databases, and any other asset where external access is not required. Amazon provides firewall services that allow users to control traffic to sensitive resources, including AWS Security Groups and Network Access Control Lists.

Restrict Traffic for the Default Security Group

A security group is a virtual firewall that controls traffic to and from EC2 instances. Every EC2 instance has a security group. Users can create custom security groups, but AWS provides a default that is applied to new EC2 instances when a custom group isn’t selected.

It is likely that the default security group will be used with many EC2 instances throughout the life of your AWS environment, either deliberately or because the person deploying the instance neglects to select a different group. It is, therefore, essential that the default firewall rules are secure within the context of your environment.

Ensure Security Groups Rules Block External Access to Vulnerable Ports

To expand on the previous tip, the default security group—and all other security groups—should block access to ports used by potentially vulnerable services such as FTP (21) and Telnet (23), as well as default ports for services that should not be accessible from external IPs, such as MySQL (3306), PostgreSQL (5432), and MongoDB (27017),

Remove Hardcoded API Keys and Database Passwords

It’s often convenient to hardcode API keys, passwords, and other secrets in the code that you run on AWS. For example, if you need to make an API call, it’s natural to put the authentication key in the code. However, this can create a significant security vulnerability if the code becomes accessible to bad actors, which can happen on your servers or in version control.

Avoiding hardcoded keys is particularly urgent when your code accesses services using AWS credentials. Instead, use environmental variables or the AWS credentials files, as described in the Best practices for managing AWS access keys.

Enable Amazon GuardDuty for Automated Threat Detection

Amazon GuardDuty is a threat detection service that monitors accounts, resources, and data for suspicious activity, alerting users when it finds a potential issue. It uses machine learning algorithms and other techniques to analyze log data from AWS CloudTrail for patterns that match known threats. GuardDuty is a valuable tool for discovering malicious activity that might otherwise go unnoticed.

Bonus Tip: Automate Security Checks With KirkpatrickPrice

Throughout this article, you may have been thinking that complying with cloud security best practices is time-consuming and complex. That’s why we created our AWS Security Scanner, which scans and reports over 50 common AWS security vulnerabilities, including many we looked at in this article.

Visit KirkpatrickPrice’s AWS Cybersecurity Services to learn more about our AWS Security Scanner and to access an extensive library of AWS security educational content.