Why you NEED to Segment Network Traffic by Lifecycle (Cloud Security)

eliminate risk vectors and harden your security posture

hello avatars, today i am going to briefly cover the importance of network traffic segmentation, and why it should be by lifecycle. Network traffic segmentation is an important part of your security posture in the cloud.

Cloud Security with Network Segmentation

Virtually every firm has multiple environments or lifecycles in which they operate. One example could be development or test where developers work on their features in isolation, acceptance user testing (UAT) in which users provide feedback, and production where the live version that customers use is running. At this point you should see a clear need on why having multiple lifecycles is helpful.

Let’s think of a scenario where a hacker or malicious actor has gained access to a development or UAT machine or gained access to a IAM role in a lower lifecycle. This actor could then begin probing production systems looking for sensitive data or other malicious activity. There are multiple risk vectors here, and we want to reduce those where possible.

Generally from a network perspective, you really only want to connect things that *NEED* to be connected. Do not create pathways that are not needed, you are just opening up attack vectors and increasing risk due to laziness. You want to highly restrict network traffic that goes across lifecycles.

Where Cross Lifecyle is Needed

there are certain use cases where cross lifecycle traffic would need to be permitted. Shared Service type applications would fit this use case. Services like CI/CD tools, observability tools, SSO provider, or API gateway, etc. These are services where all teams consume the production version.

The best practice to use these services while also minimizing risk, is to group these services into a Shared Service account and make the required IAM and network changes to allow this type of traffic. For example, you could specific route tables that allow for cross lifecycle connection.

Implement Network Lifecycle Segmentation

Best practice is to implement route tables in your Transit Gateway to drop inter-lifecycle traffic. If there is no route for this traffic the eventually expire and be dropped. If you do not have a Transit Gateway you can implement similar with route tables and VPC peering.

Another implementation that can work but is not recommended is through NACLs by rejecting the CIDR range of different lifecycles, either on egress or ingress. NACLs can be very tricky as there is a semi-hard limit from AWS. It is not best practice to manage this through NACLs as the overhead can get tricky, and become a time sink.

see you in the cloud avatar

- celt