When it comes to writing security policies in AWS, it pays to be specific.
Misconfigured policies can lead to unfortunate data leaks or even breaches, so locking down your AWS environments is a must for every organization.
In order for us to write and manage policies securely, we need to have full visibility over what our tools are capable of and how to use them properly. Getting this right depends heavily on the providers of our tools giving us the full picture in their documentation.
Unfortunately, the information in the official documentation can sometimes be unclear and leave us unknowingly exposed to additional risk.
AWS’s Simple Notification Service (AWS SNS) is a prime example where a few missing details can substantially expand your exposure.
Thankfully, there are some easy best practices that we have included on how to protect yourself here.
Sending Messages with AWS SNS
AWS wanted to make it easier for their users to send out messages through their system, so they created SNS.
They describe SNS as:
“a fully managed messaging service for both application-to-application (A2A) and application-to-person (A2P) communication.
The A2A pub/sub functionality provides topics for high-throughput, push-based, many-to-many messaging between distributed systems, microservices, and event-driven serverless applications.
Using Amazon SNS topics, your publisher systems can fanout messages to a large number of subscriber systems including Amazon SQS queues, AWS Lambda functions and HTTPS endpoints, for parallel processing, and Amazon Kinesis Data Firehose. The A2P functionality enables you to send messages to users at scale via SMS, mobile push, and email.
Looking at this description, we can see that the way to send out messages through the SNS system is with topics.
Moving through the table on resource types that SNS allows us to send to, our options here are either topics or basically just left blank.
Given these details from the documentation, one might assume that topics are the sole way to send messages through SNS.
However, if we dig through some of the diagrams presented on the product page — not the documentation — then we see that there might be another way.
Looking carefully, we see that there is an arrow pointing out to users and endpoints that does not go through the topics.
From a productivity perspective, it is good to know that we do not have to go through the extra step of registering all of our contacts into topics in order to send them out. Great, time saved.
But while this discrepancy is annoying, why is it important for a security POV?
Security Implications for SNS Misconfigurations
Our challenge here stems from the apparent miscommunication about where SNS can send its messages to.
If we assume that messages are only being sent to the entries registered in our topics, then we will probably only seek to define our policies around those topics.
But we now know that SNS will send out not only topics but basically any phone number, email, whichever that is stored in our system. In practice, this means that it could be sending messages to many more people and endpoints than we otherwise would have been aware of or likely wanted to be sending to.
Herein lies our security problem. Chances are that we have not been writing our policies specifically enough and are unnecessarily exposed because of it.
In most cases, a lot of folks have probably been writing their topic statements like this:
Notice how we used an * that denotes that SNS should send to everything?
This is too expansive.
We only want to send messages to phone numbers, but not to topics.
In order to correct our policy to meet our goal, we should be write it like this:
In this way, we have limited the scope of where we are telling SNS to send to, allowing only sending to the topics that we have defined. Now we are going to send only to phone numbers through SMS. By creating allow and block lists, we should be able to keep messages from going out to other numbers/emails that are packed away in our various resources.
We would rather avoid a situation where someone can potentially send themselves data from the server that they should not have legitimate and intentional access to.
Remember that it is always easier to add to our allowlist than backtrack on an overly permissive access policy.
As an added tip in following best practices, we want to avoid including endpoints as possible recipients. Instead, we should define the apps that are related to the endpoints and connect to them for sending our messages.
Visibility is Key
In walking through this use case of the potential exposure that we can encounter with SNS, it highlights the wider value in gaining visibility into how our security policies can grant unintentional access to our resources.
Operating in the cloud allows us to gain unprecedented connectivity with resources, assets, and identities –– both human and machines. With this great power comes great responsibility to make sure that we are aware of what we are allowing these resources to communicate with.
As we have seen here, AWS and other cloud infrastructures can obscure –– even unintentionally –– where we are making calls to and granting access or rights to. In order to lock these down and maintain control, we need to have optimal visibility.
This is where Solvo is able to step in and shine a light on what your cloud infrastructure is allowing folks access to, helping you to adjust your policies as needed.
Solvo’s technology tracks the metadata from calls in your infrastructure using runtime testing tools, providing unprecedented visibility into all of the activities going on under the hood.
It then offers data-driven recommendations for how to adjust your security policies to meet the Principle of Least Privilege, permitting the access necessary while limiting overly permissive exposure. There is even a one-click auto pilot tool that fixes policies without requiring additional manual input, simplifying the process of ensuring better security.
Start securing your cloud infrastructure with a free threat assessment from our Security Genie tool and limit unintentional risk.