Getting layer security hardenization straight

OSI 7 Layers cloud security

From 3 to 7 with AWS Services

The OSI Reference Model is common ground for us tech geeks and tech enthusiasts alike, and it has become the authority in network proceedings and in cloud security divisions. This model divides these proceedings into different interconnected layers, each having its own class of functionalities, ranging from the transmission and reception of raw bit streams over a physical medium to delivering the final unpacked information to the end-user in the application.

In cloud security matters, the hardenization of layers 3 to 7 is paramount, and getting it right will prevent information from entering the network and possibly disrupting the architecture. However, there seems to be much disagreement about how to apply securitization best practices into these layers.

Luckily, AWS has a comprehensive array of services that works organically to readjust all the layers’ cloud security aspects. In this post, we will show some AWS services that will make securitization procedures in the OSI Model layers 3 to 7 easy to deal with.

Layers 3 and 4

AWS Network Firewall

AWS Network Firewall is a managed cloud security service whose primary purpose is to facilitate the process of enabling pervasive network protections in our AWS workloads and VPCs. This top-notch service from AWS offers high availability protections. It scales automatically with network traffic, which is a great advantage as there is no need to revise or install products in the underlying infrastructure.

Apart from the default rules defined by AWS Network Firewall, it is possible to add different customizable rules to the organization’s security needs. These rules can be imported from reliable providers like the OISF (The Open Information Security Foundation), which developed a free, open-source tool that deploys granular network protection across the entire AWS environment.

The name of these rules is Suricata, a set of default rules that configures the firewall to allow or deny specific data into our company’s data center. This ensures that all the data received will not harm or cause vulnerabilities in our cloud system. This hardened security helps block or prevent unauthorized domains of known bad IP addresses into our VPCs, for example.

cloud security

Commonly, an Internet gateway is assigned to a Route Table that connects with an application. If the company decides to implement AWS Network Firewall, some specific methods and strategies will need to be replanned within our networking standard stack, like creating a particular Route Table for the Internet gateway.

We can think of the server infrastructure as being a puzzle. That is, the user needs to make any necessary changes for all the pieces to fit perfectly. This modification or enlargement allows the Network Firewall to become the proxy between the connection from the Internet to our servers and the other way around.

Security Groups

cloud security

Security Groups are stateful, meaning each group has its own state. These groups’ configurations consist of two different kinds of rules: Inbound Rules y Outbound Rules. But before going further with this explanation, we want to comment on this topic.

With the Inbound Rules, the user defines the ports through which the traffic will enter. Every packet will enter and leave through the Inbound Rule (if so selected). The outbound rules mean that the sent or received information originates in the server and leaves the server through the outbound rule. When the data returns, it returns through the outbound rule.

Security groups are often misconfigured. How are yours doing?

Layers 5 and 6

AWS Session Manager

Securizing applications in private subnets are sometimes hard work. This is so because applications in private subnets require the creation of a Bastion in a public subnet. The Bastion allows applications to connect to the Internet because, by default, private subnets do not have internet access.

There are some methods to protect and securize the Bastion that take a lot of time to set up. Customers can configure the Bastion only to allow users to enter with a VPN. They can restrict Access Control List entrances to the Bastion, create restrictive security groups, and generate Route Tables specific to the apps in the private subnet, among others.

Luckily, AWS has come up with Session Manager. This service enables users to access all the instances with the SCO instead of having hardcored credentials. This allows the user to connect with the instance without such an instance having an internet connection. With this AWS Service, we get that additional abstraction layer that the server needs; that is, the user will enable or disable access through SCM.

AWS will take care of all the tunnelization and configuration of security and traffic within these private and public subnets. Users only need their AWS user and password and the public access key to connect to the different instances.

Load Balancer

With an Elastic Load Balancer, you can balance the traffic in an application. A Load Balancer can redirect the traffic into the different services or EC2 instances to relieve the routes from overloading in a multi-server architecture that receives quite a traffic load. Likewise, if there are several routes within the same or different servers, the Load Balancer can decide which will be each route’s destination. This means that users will drastically reduce loss by throttling as traffic gets constantly distributed.

Load Balancer can work in tandem with other AWS services to further secure the architecture against DDoS attacks. These cloud security services can identify, limit, and balance the traffic between the servers and the different resources. If you receive a DDoS attack or somebody is trying to access non-existent directories with non-operating gears, these services will block these requests or balance them.

cloud security

Lastly, suppose there is an application in a private database layer. In that case, a load balancer can be located in the public layer. Within this public layer, it redirects traffic from the Internet to the application. This allows the instance to exit the application through the load balancer, thus preventing the server’s location in a public layer while granting an internet connection in the private layer.

Network Access Control List (NaCLs)

AWS Network Access Control List is a set of rules that either allow or deny access in a network environment. They apply to the whole layer (whether public or private). Unlike Security Groups, which can only allow but not deny access, NACLs are much more explicit as they can deny access to the network layer to one or several instances.

The explicitness of NACLs applies both to inbound and outbound rules. This means that the NACL can allow or deny access through both rules. As regards inbound rules, for example, they can be set up for instances to get into the network layer from IP n to IP n or from IP range n to IP range n in connection to HTTP, HTTPS, or SSH protocols as applicable. The same applies to outbound rules. Basically, NACLs need explicit configuration to allow or deny access in and out; otherwise, it will not work correctly.

Let’s delve into NACLs and Security Groups at play with a practical example to study how they work together hierarchically. The NACL is set up to allow instances into my network layer through port 443 to a sider IP, but the Security Groups are not set up to allow instances from port 443 in; therefore, the connection gets lost. Hierarchically, instances first encounter with NACLs as they work at the subnet layer, and then they face Security Groups if NACLs allow them.

Layer 7

Web Application Firewall (WAF)

At the application layer, AWS WAF comes in handy to define the rules governing the traffic to our application. The AWS WAF can work in tandem with different AWS services like AWS ALB or AWS CloudFront.

In an application load balancer, the WAF will define rules groups, like cross-sight encrypting or SQL injection, before letting this traffic into the application. These rules can enter into three modes: count, block or allow. Rules in counting mode will verify matches, let the traffic in and create a log afterward. Rules in allow mode will allow all traffic if there is a match, and rules in block mode will block all requests if there is a match.

cloud security

Another AWS service that adds an additional nuance of protection to our application layer is AWS Shield. In its standard version, this service defends against the most common and frequently occurring network and transport layer DDoS attacks that target the customers’ website or applications. But in its advanced version, AWS Shield Advanced, the cloud security service offers protection against layer 7 DDoS attacks, including features like Tailored detection based on application traffic patterns, Health-based detection, Advanced attack mitigation, and Automatic application layer DDoS mitigation, among others.


Understanding how hardenizing our layers is paramount to keeping our cloud systems well-secured, and AWS can cater to the security needs from layers 3 to 7. This post aims to give developers some security best practices to get the most out of your cloud system’s potential.

However, it should be noted that this list is not exhaustive, and the deployment of these services and configurations requires technical expertise. DinoCloud is a Premier AWS Partner with a team of experts that can help you achieve safer cloud deployments. Get started by clicking here to talk to one of our representatives.

Instagram: @dinocloud_

aws cloud security misconfigurations

Exploiting AWS cloud security misconfigurations is big business, an industry in its own right. Bad actors are snooping, copying, and selling data and ransoming companies 24/7. Organizations and governments are desperate to offer big rewards to expose and arrest these online opportunists. Mistakes, oversights, or ill-informed cloud service configuration choices are at the center of vulnerabilities that make the nightly news every week. To compound the problem, according to research, most environments are operated under a “set it and forget it” policy where reviews and audits are not used to ferret out the original mistakes.

aws cloud security misconfigurations

It is vital to employ experienced AWS cloud professionals to architect, engineer, implement, maintain, and audit your cloud environments. Small misconfigurations lead to mountainous liability.

Let Us Configure Your Cloud

Data Exposure Risks

As AWS’ customer list of enterprises that upload and distribute data across the globe grows exponentially, the cost-effective, productivity-enhancing services come with risks of misconfiguration vulnerabilities.  

Misconfigured Amazon S3 buckets are the most common security threat to AWS cloud environments. Through poorly configuring this cloud object storage inadvertently, public read access makes data breaches possible, and public write access exposes code for injection of malware or encryption of data to hold a company ransom.

aws cloud security misconfigurations

What is Amazon S3?

Amazon Simple Storage Service (S3) is an object storage service. Fifteen years after its introduction, it offers industry-leading scalability, data availability, security, and performance. All organizations in every industry use Amazon S3 to store and protect data for various use cases:  data lakes, websites, mobile apps, backup and restore, archive, enterprise applications, IoT devices, and big data analytics.

Recent AWS Cloud Breaches Due to Amazon S3 Misconfigurations

October 2021, Twitch,, Inc.’s live streaming e-sports platform, blamed “an error” in a server configuration change for exposing sensitive information that enabled a hacker to leak data from its source code repository and creator payout information.

August 2021, SeniorAdvisor, a ratings/review website for senior care services in the US and Canada,  was found by ethical hackers at WizCase to have a bucket configuration that left over 1 million files (182 GB) of personal contact information from leads and reviews.

Moreover, ethical hackers at WizCase exposed more than a terabyte of data, including 1.6 million files with city residents’ sensitive personal data, building plans, city plans, and local property data. It is unclear whether the Amazon S3 bucket misconfigurations were due to actions by PeopleGIS or the municipalities.

In March 2021, Premier Diagnostics, a Utah-based COVID testing company, exposed patients’ data via improperly configured Amazon S3 buckets. This company disclosed Over 50,000 scan documents of customers’ personal information, including images of driver’s licenses, passports, and medical insurance cards.

How to Minimize Data Exposure Risks in Amazon S3

Data Encryption

Encrypt all data while in transit to and from and stored in S3. Use client-side encryption or SSL/TLS protocol. 

Enable Bucket Versioning 

Versioning adds a layer of data protection against user actions and application failures. With Amazon S3 bucket versioning enabled, AWS simultaneously stores all objects when receiving multiple write requests to the same object.

Enable MFA Delete

Further, strengthen security by enabling Multi-factor Authentication (MFA) Delete for a bucket’s versioning configuration. This MFA Delete setting requires a bucket owner to include the ‘x-amz-mfa’ request header. This is so when requesting to permanently delete an object version or change the bucket’s versioning state. Note that requests that have ‘x-amz-mfa’ are required to include HTTPS. Failure to meet all these requirements will cause the request to fail. 

Use Amazon S3 Object Lock

Prevent an object from being overwritten or deleted for a fixed period or indefinitely by using the S3 Object Lock service. It stores objects using a write-once-read-many (WORM) model. By using an Object Lock, you can. 

Utilize Multi-Region Application 

Multi-Region Application Architecture enables users to create fault-tolerant applications with failover to backup regions. Using S3 Cross-Region replication and Amazon DynamoDB Global Tables, the service asynchronously replicates application data across primary and secondary AWS regions. 

Lockdown Public Access to Amazon S3

Use Block Public Access settings to override Amazon S3 permissions to prevent accidental or intentional unauthorized exposure. This will ensure your Amazon S3 is secure. These are helpful settings for administrators to centralize account controls for maximum protection.

All new buckets, objects, and access points are not set to public access by default. But Amazon S3 users can modify policies and permissions that allow public access, potentially exposing sensitive data. Unless a dataset specifically requires read or write access on the internet via a URL to your Amazon S3 bucket, it should not be allowed. 

Identify Bucket Policies that Allow Wildcard IDs

Identify Amazon S3 bucket policies that allow a wildcard identity, such as Principal “*” or a wildcard action “*.” This effectively enables users to perform any action in Amazon S3. Also, audit for Amazon S3 bucket access control lists (ACLs) that grant read, write, or full access to “Everyone” or “Any authenticated AWS user.” A bucket policy must grant access only to fixed values or non-wildcarded values to ensure data is non-public.

See AWS detailed instructions on making policies non-public.

Audit IAM Systems

AWS IAM systems are your first line of defense in securing access to sensitive data and your applications. Deploying default AWS IAM settings will jeopardize your organization. Even if you avoid this common pitfall and set up AWS IAM policies that effectively secure a resource, that protection can become outdated. For example, if a user changes departments or roles within a department, access rights should change to match the new role’s need to access data and applications. Regularly audit AWS IAM rules to protect your environment better.

Use Tools to Inspect Implementations 

Use tools to reduce human error. More tools will arise over time, but currently, we recommend: 

  • AWS Trusted Advisor, an online tool that offers real-time guidance and support when provisioning resources on AWS, inspects your Amazon S3 implementations to strengthen your efforts to prevent public access.  
  • Employ real-time monitoring through the s3-bucket-public-read-prohibited and  s3-bucket-public-write-prohibited managed AWS Config Rules. 
  • Hire DinoCloud to complete a Well-Architected Framework review and remediate your Amazon S3 implementation.

Enforce Least Privilege Access 

Add layer protection against unauthorized access to Amazon S3  by enforcing least privilege access. This means granting only permissions to identities (users, roles, services) that are required to perform its tasks. This principle prevents malware, reduces the potential for cyberattacks, aids data classifications, helps demonstrate compliance, and promotes user productivity.

aws cloud security misconfigurations

Focus on these best practices:

  • Separation of duties – avoid conflicts of interest between people and applications, ensuring that responsibilities and the privileges granted to accomplish them are not to leave the organization open to fraud, theft, circumvention of security controls, or other risks. Failure to separate functionality can result in toxic combinations where privileges can be abused. For example, a user with permission to create an invoice may also have been provided the privilege of paying the invoice. 
  • Inactive identities – review access privileges for lack of login activity, then ideally remove them, but at a minimum, closely monitor them as bad actors can gain access without the owners’ knowledge.
  • Privilege escalation – this occurs when vulnerabilities, often identity and access management  (IAM) misconfiguration, are exploited either horizontally by one user using its privileges to access another user’s account or, even more, prone to damage, vertically where a user accesses accounts with higher level privileges such as an account administrator.  

AWS tools that aid you in implementing least privilege access:

Is Your Infrastructure

Software Supply Chain Risks

High-profile incidents implicate software supply chains, such as the 2020 US SolarWinds and 2021 Log4 breaches, are rising. Securing the software supply chain is becoming a more-often addressed topic among IT teams, but regrettably, many are not considering the public cloud as part of that chain. It is understandable how this oversight happens as the public cloud is more “infrastructure” than “software.” But, cloud security risks can rain (pun intended) on your software supply chain, causing a storm just as volatile as software applications.

Software supply chain infiltration is lucrative and can be scaled quickly and efficiently. By infiltrating a soft target, then exploiting poor configurations, bad actors can deploy malware in multiple organizations’ environments for later launch. With access to the environments, hackers can evolve, most often undetected. 

Public cloud security breaches happen, often exposing data stored in the cloud but not giving hackers direct access to entire IT environments. As proven in the SolarWind breach, it can happen. Consider these reasons to include consideration the public cloud as a part of your software supply chain:

  • Clouds are more than just infrastructure: Though Infrastructure-as-a-service (IaaS) may be the primary offering, most cloud vendors also deliver software-as-a-service (SaaS) applications.
  • Infrastructure security breaches are painful: Even if your use of the cloud is infrastructure services only, vulnerabilities in the cloud platform can expose your data or applications to malicious assaults.
  • Public clouds get hacked: As you have no doubt read in IT publications and sometimes mainstream news, it is possible for hackers to attack your public cloud to be attacked.

You are opening up your software supply chain to vulnerabilities without tracking risks and breaches that impact the cloud environments you use. 

Securing the Cloud in Your Software Supply Chain

Reduce risks of using the public cloud as part of a software supply chain:

Know your cloud environment

Unless you know what you have, you cannot monitor it, much less secure it. It is a challenging task that gets more challenging the more prominent the organization, but it is vital. To help organize this effort, enforce tagging rules for your cloud resources to better track workloads and periodically conduct audits to map cloud workloads.

Track your cloud platform(s) security incidents

Once you understand your cloud environment, you will know a list of cloud platforms you must stay well-informed about. For each security incident you become aware of, learn as much as possible about them to know if any of your workloads are impacted. Read IT publications and general news, and follow the security thread of the blog of your cloud provider. Here is the AWS Security Blog

Minimize data exposure

Store fewer data in the public cloud to reduce the impact on your organization and customers if there is a breach. Consider a hybrid cloud architecture.

Spread workloads across multiple cloud accounts

Splitting workloads across different accounts also reduces the impact of any breaches that may occur. 

Do not blindly trust third-party containers

If you deploy cloud applications using containers, you know that scanning for vulnerabilities before deployment is standard and best practice. However, many organizations’ environments blindly trust containers from third parties. This situation often happens when you deploy sidecar containers to connect resources like third-party logging services. Generally, a reliable company or open-source project should not cause you to relax your practices of scanning containers. Scan all containers before deployment. 

Don’t Be a Victim of AWS Cloud Security Misconfigurations

DinoCloud’s architects and engineers are experienced AWS Partners. Let’s work together to secure your infrastructure while taking advantage of all the benefits of cloud.

Instagram: @dinocloud_