Secure Lambda Functions with CloudView

Document created by Mikesh Khanal Employee on Mar 13, 2020Last modified by Mikesh Khanal Employee on Mar 13, 2020
Version 17Show Document
  • View in full screen mode

In 2014, AWS was the first public cloud infrastructure vendor to offer abstract serverless computing with AWS Lambda. Lambda can take code for virtually any type of application or backend service and run and scale it with high availability - all with zero administration. That is, without the hurdle of provisioning or managing any of the servers.  

The adoption of serverless architecture skyrocketed because, not only could you delegate most of the operational responsibilities to cloud providers, you also paid these providers only for the computation time consumed. However, with the increase in its use, new security challenges have emerged.  

In this post, we will look at the current attack vectors for Functions as a Service (FaaS) and discuss the different practical security challenges around it. We will also look at how the Qualys CloudView product helps mitigate the risks associated with these challenges.


Attack Vectors 

Here is the list of key attack vectors that could lead to exploitation of your Lambda functions resulting in your cloud environment to get compromised. 


  • Visibility: Lack of visibility for the functions deployed  

  • Exploitation Triggers Or Functions Getting Compromised: Cause and Effects 

  • Post-Exploitation Risks 

Let us view how each of these attack vectors [contribute to threats/build the various risks] in your cloud environment.


Visibility: Lack of visibility for the functions deployed 

Cause: Where are my functions deployed? How do I find all the functions not using our Logging layer? Does any public S3 invoke them? 

Resolution: CloudView provides a single pane view of all your functions distributed across different regions and accounts. Faceted search lets you group your functions using pre-populated metadata such as runtime, tracing, layers, trigger-type, region and accountId. For instance, you can identify all the Lambdas triggered by SNS/CloudWatch events or having older python 2.7 runtime or deployed in non-operating regions such as Mumbai.



Further, you can use the Qualys console to dive deep into the function to gather metadata such as  

  • added layers and their version 
  • different versions of the function 
  • aliases and routing configurations for them 
  • different triggers and their state 
  • associated IAM roles and policies 
  • Associated VPCs, Subnet and Security groups 
  • Tags assigned to the functions 




Exploitation Triggers  Or  

Functions Getting Compromised: Cause and Effects 

Let us see the causes/reasons/ triggers that could lead to exploitation and the adverse effects of the same. For example, what could cause my functions to get compromised and what happens if they get compromised. 


My Lambda function is running. Who invoked or what triggered it? Can my functions be invoked anonymously?  

Cause: Allowing public or anonymous users to access/invoke Lambda functions (wildcard '*' in Principal element in the function policy) can lead to unauthorized data modifications or leakage.  

Resolution: CloudView helps you to track such functions. 


Or we have 10 different triggers for my function, contrary to the application’s need?

Cause: Having multiple triggers for a single function may create unwanted/unknown function invocations and can complicate the implementation of the function to handle different tasks from different services. Also, the Single Responsibility Principle is violated when you use multiple triggers.  

Resolution: CloudView helps you to classify such functions.





Did we unintentionally build/configure the application as vulnerable?

Is my serverless application exploitable due to vulnerabilities discovered in 2015 due to not fixed third party library in older runtime or runtime we custom built 2 years ago?

Cause: Newer versions of the runtime generally include bug fixes and patches to known vulnerabilities coupled with some new features. This reduces the attack surface and increases the stability of the runtime.  

Resolution: It is recommended to check if these Lambdas can be migrated to newer versions. 


We did not encrypt environment variables. Do I run the risk of my functions exposing sensitive data?  

The environment variable of a Lambda function contains frequently changing settings and can be sensitive in nature. Encrypting such information at rest ensures the confidentiality of the information. 

Cause: In order to change function's behaviour without actually changing the function code, developers use environment variables and in the process of making tweaks can leave sensitive information like these variables.

Resolution: CloudView help customers ensure that Environment variables are encrypted all the time with a Customer Master Key (CMK) at rest.




Post-Exploitation Risks 

We will now highlight the risks that your cloud environment could face if the Lambda function is exploited/compromised. 


How adverse are the effects if functions get compromised? 

In the interest of time, many organizations undermine security by providing admin access to all Lambda functions. Is my organization one such?

Cause: It becomes difficult to gauge the exact permissions required to run the application due to the increasing complexity induced by the frequent code changes for the introduction of new features or resolution of the bugs. Thus many times, developers attach a role with administrative policy to lambda functions to expedite the development and avoid the hassle of figuring out the appropriate permissions.

Resolution: CloudView provides “AWS Lambda Best Practices Policy”, an out-of-the-box policy that monitors all Lambda functions for administrative permissions (wildcard permissions) on resources. Such Lambda functions increase the blast radius if the functions misbehave or get compromised.


Does my organization have any Lambda functions with extra permissions than required to operate the application/code? 

Cause: During development, administrators may assign policies that offer more permissions than needed. However, in a production environment where the function’s code and its behaviour does not change frequently, the permissions that have not been used in the last 90 days should be removed as such permissions can be dangerous.

Resolution: CloudView reports any excess permissions granted to lambda functions based on the usage of AWS services to avoid the misuse in case of compromise.


Also, are we plagued by the thought that the role created after numerous iterations with the perfect set of permission for a specific Lambda can be used for others, notwithstanding, the potential exposure? 

Cause: Using the same IAM Role with more than one Lambda function violates the Principle of Least Privilege and increases the difficulty in tracking and monitoring the access usage. Besides, in case of an incident such as credential theft, you can revoke access/permissions from a role to avoid the damage, but it will affect unintended functions and their capabilities if roles are shared. Additionally, if one of those functions needs extra permissions, granting them would effectively increase privileges for every other function using the same role. 

Resolution: CloudView helps cloud administrator locate such functions so they could assign separate roles for each function to avoid the privilege leakage or the ripple effect.


In summary, exploit/use CloudView to discover your functions across regions or accounts on a consolidated UI. Use this consolidation view to identify misconfigurations during deployment, associated risks and remediation to prevent a potential breach. Security engineers can also use CloudView’s Slack integration for alerting, and Splunk integration for correlation with other security events for further threat hunting.


Happy exploring Qualys CloudView.

1 person found this helpful