{{announcement.body}}
{{announcement.title}}

Reinforcing AWS Security Posture, At Multiple Levels, in Seconds

DZone 's Guide to

Reinforcing AWS Security Posture, At Multiple Levels, in Seconds

Maintaining security posture on any cloud is not an one-man-army fight.

· Security Zone ·
Free Resource

Often, we hear about publicly exposed AWS S3 buckets or security attacks, such as DDoS, brute-force, etc. Every problem in AWS, be it security, compliance, or bill spikes, was due to an engineering problem. When it comes to AWS security, wrong Security Group (SG) configurations seems to top the charts.    

AWS security audits cannot be a fortnightly activity as generally practiced. It must be an everyday activity. As AWS practitioners, we all know this is effort intensive, especially with manual approach of using AWS console.

If you are an SMB or an enterprise, you will have hundreds of instances running in multiple SGs. Just imagine the amount of time invested just for DeSecOps activities to maintain the security posture.  

Maintaining security posture on any cloud is not an one-man-army fight.

Security is everyone’s responsibility as we know it. It’s teamwork between a CISO or a CTO and his team of DevSecOps or DevOps engineers. Everyone needs to understand the security posture of their AWS accounts at multiple levels, from their respective job roles’ perspective, right from top level to granular level, to this end.

In a dynamic AWS ecosystem where several resources are provisioned, scaled up or scaled down on-demand, the chances of overlooking misconfigurations are high. Because rules defined under SGs are buried under KBs of code and visualizing traffic flow from logs of VPC flow, log data is immensely challenging. 

For any human, this is overwhelming because a human mind has a cognitive limit when it comes to mapping large data sets. 

Solution: An 'Age of Empires' Themed Visual Console Offering Real-Time Security Cues

Over the past year, we at TotalCloud have been working on bulding a futuristic visual cloud platform. The platform resonates with innate preference of a human mind. Imagine the likes of a 3D interface to resolve architectural designs or understand human body anatomy.

Recently, we rolled-out a new flagship feature, Security Group View. The view offers visual cues to security misconfigurations and other loopholes, and helps identify vulnerabilities 100X faster!

Lets walk you through a couple of security audits a CXO or a DevSecOps engineer must perform regularly and how easy it is to perform on the TotalCloud visual console.

#1 Checking for Open TCP/UDP Ports Associated With Relevant IP and Security Groups

Unrestricted inbound/ingress access to TCP/UDP ports can invite malicious activity. The typical plan of action is to keep a check on instances’ SGs for inbound rules that allow unrestricted access (i.e. 0.0.0.0/0) to any of these ports and restrict access to only those IP addresses that require it to implement the principle of least privilege.

On the AWS console, you need to hop between Network and Security section and then Security groups via EC2 or RDS dashboard. Check for the tabs shown below the tabulated list. This might take several minutes to hours depending on the number of instances.

However, using TotalCloud, you can check the ingress and egress and check for SGs containing resources that allow data outside the Infrastructure at a glance.

Observe the video below:

Using TotalCloud, this will take anywhere between 5 to 10 seconds, irrespective of the number of instances you have provisioned.

#2 Finding SSH Open Ports and Ensuring They Are Used Only for Jump Box/Bastion Hosts

Securing network at the subnet level, using a bastion host, NAT instances, or NAT Gateways, helps in protecting data. An SG allowing bastion connectivity for existing private instances must only accept SSH or RDP inbound requests from bastion hosts across AZs.

Whereas, the inbound & outbound traffic must be restricted at the protocol level, where in the inbound rule base should accept SSH connections only from the specific IP addresses. The outbound connection should again be restricted to SSH or RDP access to the private instances of your AWS infrastructure.  

On the AWS console, you need to go to VPC console, scroll down to SGs and check for inbound and outbound data under each SG. This might take few minutes to hours depending on the number of instances.

However, using TotalCloud, you can check the ingress and egress and check for SGs containing resources that allow data outside the Infrastructure at a glance.

Observe the video below:


Get a Centralized Focus View With Visual Cues for Real-time DevSecOps

Change is the only constant. In a dynamic cloud setup, where several teams engage, having a centralized view of live data that acts as visual cues to vulnerabilities helps identifying security issues in real-time. The ability to zoom in and zoom out at multiple levels, along with the capability to filter out traffic rules, helps everyone in the team to act and secure their infrastructure.

With immersive visualization of such data, anyone in the team can perform continuous security and understand security posture 100X faster and better compared to dashboards.

Try out Security Group View. Would love to hear your valuable feedback.

Topics:
devsecops ,aws ,aws and devops ,aws security ,aws security groups ,vpc ,amazon web services ,cloud security ,cloud security platforms ,cloud security issues

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}