When it comes to staying secure in the cloud, an important practice is to monitor both incoming and outgoing connections from your network. Why? Monitoring and alerting on “interesting” (i.e., anomalous) network connections going in and out of cloud environments can provide early breach detection to cloud security operations teams.
Here’s how to put this type of security monitoring into practice in your organization.
Step One: Inbound Connections
First, what is an inbound connection? The exact definition and nature varies somewhat from organization to organization, but the basic idea is that an inbound connection is one coming into your network. It could be an employee logging in or a visitor to your website. Inbound connections should be defined based on the business operations of the company. Some of the things you will want to consider when defining inbound connections include:
- Source IP of Inbound Connections: If you don’t have users overseas, for example, there is no reason for frontend servers to be hit by IP addresses that are not in the U.S. Similarly, users should not be logging in from geographic locations that are not approved by your organization. Caveat: This can be a bit tricky to manage, since many companies have employees and contractors who travel and/or work remotely. The key is to always catch and alert on anything outside the ordinary (whatever that means for your organization). It’s always better to be safe than sorry.
- Known-Bad Actors: Today, there are maintained lists of “known-bad” websites — ones that have been associated with malware and other attacks. Since inbound connections can come from so many different places (especially in a world of SaaS tools), the best way to make sure you aren’t letting the bad guys in is to focus security efforts on keeping inbound connections from “known-bad” IPs out. It’s like having a Most Wanted list tacked to your wall, helping you to keep the bad guys out.
Putting It Into Practice
To monitor inbound connections based on the location of users, admins should monitor the origin of IP addresses and cordon off any that come from unexpected or inappropriate locations using AWS Security Groups. This way, you are likely to catch account compromises early on, before malicious actors have a chance to breach your systems and do damage. IPs cordoned off by security groups in error can always be reviewed and approved later, but again: better safe than sorry.
To block known-bad IPs, use threat intelligence such as that provided by Threat Stack’s Cloud Security Platform® to identify bad IP addresses and investigate any attempted inbound connections coming from them. This will cut down on the spread of malware, for example, by identifying attempted attacks early on and preventing them from successfully breaching your network.
Step Two: Outbound Connections
Outbound connections are a bit more complex. Why? The SaaS tools that many operations teams use to monitor performance must talk to their “motherships” (whose IP addresses change periodically). For example, package repositories like Ubuntu are hosted all around the world. To keep the cloud environment safe, SecOps teams need to monitor and alert on outbound connection attempts like these.
Similar to inbound connections, tracking outbound connections has two components:
- Origin of Outbound Connections: The best way to know when something goes wrong is to know what it looks like when everything is going well. To do this, build a model that shows what normal, everyday traffic looks like. This will make it much easier to visualize and catch when something deviates from the norm and indicates possible compromise.
- Known-Bad Actors: To track outbound connections, you need the ability to detect when a connection is attempted from inside your network to a known-bad actor (website domains known to be affiliated with malicious activity). SecOps teams need to know when a process connects to a known-bad site from a node. For example, an infection may get into your network and then try to “phone home” to the command and control server that sent it. Your goal is to be able to identify this activity by knowing the bad actors (e.g., malicious domains) so you can put a stop to the attack immediately and prevent them from compromising your systems.
Putting It Into Practice
To track the origin of outbound connections, first collect a baseline of outbound connections in production environments (e.g., the ones your Ubuntu servers use for package management) that represents normal behavior, and then monitor for any deviations from these normal outbound connections. With Threat Stack’s Cloud Security Platform®, base rule sets track all outbound connections (using the type = “connect” filter).
Once you detect outbound connection activity that deviates from the norm, compare it to the list of addresses that are known to host or distribute malware, or that participate in botnet activity. Threat Stack’s Threat Intelligence feature automatically monitors connections to known-bad hosts and alerts you whenever these connections occur, so you can quickly take action to avoid compromise. It also has suppressions that are correlated to all of your active cloud operations tools and their outbound IPs to avoid false alarms.
Cloud Security Depends on Knowledge and Visibility
The more you know about the connections going into and coming out of your network, the better you can protect it from breach and compromise. Whether there is a suspicious inbound connection (indicating account compromise or an attempted infection) or a suspicious outbound connection (indicating traffic from malware, botnets, or similar), the more you know about what’s going on, the faster and more intelligently you can respond.
Continuous security monitoring is the way organizations can run securely in the cloud today. Knowing what you should be monitoring and what constitutes deviation from the norm will give you a significant baseline for quickly detecting breaches and taking appropriate remedial action.
Final Words . . .
For use cases on Network Connection Monitoring (and use cases on other critical vulnerabilities), download a copy of our recently published Cloud Security Use Cases Playbook.