IN
In all the product management books, there’s a common consensus about product delivery: You never know how the product that you designed will work for customers before you actually roll it out. It was also the same for us with Thundra. We are very well known as the only serverless observability vendor that can automatically trace distributed services from the high level to the bottom with line-by-line tracing. However, we see some of our customers using our Product in a surprisingly different way. Using our extensive querying capabilities with traces and operations search, customers were setting up alerts to see if their Lambda functions are reaching to resources that they are not supposed to reach. In order to do so, they were writing really long queries that even I couldn’t imagine. When I made long interviews to understand their needs, the idea was sparked to extend Thundra to help developers secure their applications. After all the hard work that all the team put for a long time, it’s time to reveal our secret: We are proud to extend our offering to serverless security on top of our unmatched observability capabilities for serverless-centric applications.
Thundra provides observability enabling developers to quickly pinpoint the performance bottlenecks and issues. It is the only solution for code-level instrumentation with the live and remote debugging approach as well as providing on-prem monitoring options with Splunk and ELK integration. Today, Thundra is rising as the only solution that combines performance and security insights with automated actions.
Why is security still an issue in serverless? How will Thundra help?
While moving into serverless, software teams having relief of not continually applying security patches, configuring firewalls, etc. since the serverless provider is responsible for securing the data center and its configurations. However, securing application logic and data is still the responsibility of the serverless practitioners. The bad news is that it’s not straightforward to understand if the serverless functions are reaching to resources that they are not supposed to reach because of the vulnerabilities in third-party libraries or misconfiguration.
Thundra comes to the rescue at this point with whitelist/blacklist configuration for applications. Using Thundra’s whitelist configuration, you can guarantee that your function will continue reaching to the resources that it’s expected to reach and nothing else. When any violation occurs, you have the option to block it proactively and/or allow it but make necessary notifications to the responsible in your organization.
Similarly, you may want to prevent access to some well-known malicious URLs and/or endpoints in advance for your Lambda functions. In this case, you can block these operations with our blacklisting approach. You can even load a list of malicious URLs to prevent access to a bunch of endpoints at once.
Using Thundra’s security feature, software teams can automate continuous configuration, enforcement, and verification of security and compliance controls with some compliance like PCI, HIPAA, SOC2, NIST. Using our wide integration with many alerting tools such as Opsgenie, Pagerduty, ServiceNow and many more, you can notify your organization if there’s an attempt to violate the policies you applied.
How does this actually work?
We are replacing the existing “Architecture” view under function detail with this update. In this view, you’ll be able to see the security violations if any and set up a new security configuration.
When you want to configure the security functions, you have two options that are namely whitelisting or blacklisting. As the names suggest, whitelisting allows access to specific set of resources and prevents any other stuff while blacklisting prevents access to specific set of resources and allows any other stuff. Whitelisting is best for retaining the existing architecture while blacklisting is best for restricting access to potentially malicious endpoints.
When you decide to go with whitelisting, we are coming up with a list that includes existing resources automatically whitelisted. In this way, you don’t need to input all your existing resources manually. You have the flexibility to add new resources that you can potentially reach in the future. In the following image, we are whitelisting all the existing resources and also adding any type of S3 operation, and READ operations from SNS to the whitelisted resources. This way guarantees that our function won’t be able to reach any other resources but only the listed ones.
When you’re done defining your policy, you can add the action that Thundra wants to take when any violation occurs. You can either let any violation occur and get notified about it or you can be more restrictive and block them in the first place. Note that if you change your logic in the function and forget to remove your security policy in Thundra, you can face problems because Thundra will block your new business logic. So, be careful using the blocking actions. If you are using our AWS integration, you can pass the security policy to your function with no code change but with a single click. In this way, we will update your function configuration with an environment variable. If you are not using the AWS integration, you can still secure your function by simply downloading the Base64 format and assigning the file content to the environment variable called thundra_agent_lambda_trace_span_listenerConfig. If you want to see the longer format of our security configuration, you can download it as JSON and read it. Here is the translation of the above configuration to a JSON file:
{
"block": false,
"whitelist": [
{
"className": "AWS-S3",
"tags": {
"aws.s3.bucket.name": [
"*"
],
"operation.type": [
"*"
]
}
},
{
"className": "AWS-SNS",
"tags": {
"aws.sns.topic.name": [
"*"
],
"operation.type": [
"READ"
]
}
},
{
"className": "AWS-DynamoDB",
"tags": {
"aws.dynamodb.table.name": [
"team-lambda-java-staging"
],
"operation.type": [
"READ"
]
}
},
{
"className": "HTTP",
"tags": {
"http.url": [
"jsonplaceholder.typicode.com/albums"
],
"operation.type": [
"GET"
]
}
},
{
"className": "AWS-SQS",
"tags": {
"aws.sqs.queue.name": [
"error-lambda-java-staging"
],
"operation.type": [
"WRITE"
]
}
},
{
"className": "Redis",
"tags": {
"redis.host": [
"localhost"
],
"operation.type": [
"READ"
]
}
}
]
}But how?
You may wonder how Thundra does this in the background. Let me explain it to you. When you let Thundra libraries instrument your function, you actually provide access to us to take your code wherever it goes. In order to measure the time spent at any resources, Thundra (and all the other APM solutions) accompanies your code during the operation. If we are the fellow that your code is running with, we can actually prevent your code to go to unpleasant places. This is all the magic behind that also works for allowing and notifying.
In case of any violations, you’ll receive an email to your account about it. In order to change your notification preferences about security alert policies, you can find the related policy in your alert policies page and add new notification channels like Slack, Pagerduty, Opsgenie and many more.
Is it only serverless?
I kept the biggest surprise for the last. Our observability and security insights will not only for serverless functions from now on. We are providing beta access to our container and Kubernetes support for folks that are reaching out to us. Using this, you can also apply whitelisting/blacklisting mechanisms for non-serverless resources as well. This is another big achievement for us this year and we’ll explain it in detail sooner than you expect.
Welcome to the security world! So, what’s next?
This update was the first step with our changing vision towards application development. As of today, we are aiming to help developers with the tool relief by enabling developers to debug, troubleshoot and secure serverless-centric apps with a single tool.
Yes, we are stepping into a new world that we are not previously a part of. We are aware that this is just the first step into a whole new universe. We have the vision of helping customers with an application-level firewall which will control the data coming in and through in any application (not only serverless). With that in mind, we’ll introduce new features like active prevention of SQL injection attacks, preventing denial of service attacks for any type of application in the application level, making sure that your resources are configured with the least privileged access and so on. It’ll be a long journey in the security world, so we need feedback and input more than anything else.
You can reach us over Twitter or email. If you want to see a dedicated product demo, please shoot a meeting request. You can sign up to Thundra or see our demo environment to see Thundra in action at any time.
