Network Policies to Help Reduce Risk and Improve Security Director, Cloud Network Security

Most cloud practitioners start their network control journey looking at security groups, firewalls, or web application firewalls (WAF) to protect their public applications from inbound attacks.  But what about workloads that aren’t public facing but still have internet access?

For example, this Amazon Elastic Compute Cloud (EC2) Linux workload can be infiltrated by Kinsingpunk Malware to steal Amazon Web Services (AWS) credentials, Secure Shell (SSH) keys, and bash history file, among other types of credentials and information. Collected data is then sent to the remote server sayhi.bplaced[.]net

Considering that malware uses techniques to rapidly change these domains, chasing malicious domains one at a time, is difficult, if not impossible, to react to.  In this attack, restricting internet traffic to only known, good domains would have prevented the exfiltration to sayhi.bplaced[.]net

Reasons like this are in part why frameworks like PCI DSS (Section 1.2.1) make this proactive and powerful security control a requirement.

With cloud providers introducing new networking technologies, it’s important to use a transparent, threat-focused security solution like Trend Micro Cloud One™ – Network Security. This solution can be implemented next to the internet gateway to achieve these goals.  With a multi-cloud approach, these benefits can be made available to any compute service in your VPC or VNet communicating via an internet gateway.

Now… overlay threat context to supercharge your automation and response:

Ok, so now that unsanctioned internet communications are prevented, what’s next to maximize security and minimize risk?

Looking at what threats were blocked can determine the appropriate response.  Overlaying threat intelligence provides powerful context to differentiate between an application issue or a security issue.

For instance, a workload reaching out to example.com may simply indicate the need for a policy change or be from incomplete code that inadvertently made it to production.  While this needs to be addressed, it likely doesn’t warrant immediate concern. Therefore, responding with automation to create an issue or to inform the app owner of this violation may be all that is needed.

What about a blocked attempt to reach out to known command and control (C&C)?  Or communications attempt to an anonymous proxy or suspicious geo-region?  Or a network inspection that blocks a known malware check-in?  This response may be significantly different—like automation that terminates or quarantines the affected code, notifying your security operations center (SOC), and possibly initiating incident response activities.

This security context provided from solutions like Network Security allow for a better response and now you can rest easy knowing that even approved internet-bound traffic to the specified known, good domains will be further analyzed for signs of malicious activity, exfiltration attempts, and other compromises.

On Architecture:

Implementing Network Security at your application’s internet gateway is a great way for DevOps teams to add protection.  For cloud architects, patterns that share security and network infrastructure can scale this compliance and security control.  This can then provide a security best practice guardrail that can be rapidly used across your organization by many teams.

Common patterns include, sharing a centrally managed network control using AWS technologies like Gateway Load Balancer (GWLB) or architecting a hub-and-spoke network topology with a shared internet egress point—providing a great location to deploy a control for multiple teams.

Read More HERE