Major companies have embraced this new innovation that is serverless and are changing their entire mindset of what the backend is. But amidst all the buzzwords flying about, comes a very important concern - how can I be sure I am using serverless in a secure way?
Serverless or Function-as-a-Service (FaaS) has a lot of benefits and one of them is the fact that the security of the infrastructure powering the applications has been moved to the platform providers like AWS Lambda, Azure Functions, IBM Cloud Functions, Google Cloud Functions etc. and denial of service will no longer be as a result of hacker attempts but more of a billing issue. This results in the focus of attackers shifting from the infrastructure as it was in the past, to the application.
Serverless applications are structured as a combination of small functions that execute your code returning a simple result. Depending on the number of open source repositories this kind of architecture widens the surface area and likelihood of cyber attacks making planning and building secure serverless applications an important point at the top of your todo list.
Here are several steps or best practices that should consider in order to build a secure serverless application.
Function-level Security
The first of on the list of security best practices for serverless is to implement function-level security. As serverless allows you to run your applications through a series of functions that can be triggered, it is important to implement security at the functional level. A good practice is to take note of all your functions and check out what each function is meant(or allowed) to do against what it is currently doing.
A rule of thumb according to Hillel Sollow is to define separate roles for each function which prevents you from giving certain functions access to data that they don’t need or performing actions that aren’t necessary thereby eliminating security loopholes in your code that can be exploited by attackers.
AWS Lambda allows you to do this in two distinct ways:
Through Identity-based policies - with this approach, you can either attach policies with permissions to a user or group in your account or you attach a policy to a specific IAM role thereby granting cross-account access to your Lambda function
Through Lambda Function policies - this approach allows you to grant cross-account permissions to your lambda functions without using identity-based policies with IAM roles.
Security audits on all dependencies
Most serverless applications use a lot of dependencies from Node.js, Python and many other repositories with open-source code. To ensure your application isn't leaving any backdoor to attackers, you need to check all dependencies for vulnerabilities.
This can pose to be a very hard task in a scenario where you’re running serverless applications with lots of functions but not to worry, there are various solutions like:
- RetireJS - an open source vulnerability checker where developers can check if a Javascript library has any known vulnerabilities through a site-checking service
- Npm - an open source Javascript registry that acquired Node Security Project. Npm runs vulnerability checks through the npm audit command which is available in npm@6.
- Snyk - a commercial vulnerability checker with its own vulnerability database (VD). Snyk works with .NET, PHP, GoLang, Java, Python, Scala, Ruby and Node.js
- Greenkeeper - a commercial dependency management tool that automatically manages, updates and tests npm dependencies.
Other solutions exist with the ability to help check dependencies with many of them relying on the NIST’s National Vulnerability Database (NVD) others rely on both the NIST NVD and their vulnerability databases as well so you will be doing yourself a big favour by searching them out and making good use of them.
Eliminate all ‘Dead’ Functions
In serverless, ‘dead’ functions are functions that have not been invoked for a very long time. As we all know that serverless gives room for unused functions to lie around thereby increasing the clutter (remember that you don't pay unless a function is invoked). There is a very high chance that you will have lots of unused functions with various permissions and privileges lying around.
Now, this can pose a very serious challenge to the developer as you can’t know what functions are not in use if they aren’t running and from a security point of view, functions that haven’t been used for a long time run a risk of having outdated libraries and dependencies.
So what do you do?
Well, besides having a well thought out plan from the get-go you'll have to use a proper monitoring tool for your application. There's no going around it. I'd recommend using Dashbird.io. It's easy to use, doesn't add any latency to your execution time and is very secure since it connects directly to your AWS account.
Don’t write bad code
This really can’t be stressed enough. Even with all the best practices mentioned earlier put in place, if you write bad code, you’ll be opening up your application to exploitation by attackers. Therefore, as a rule of thumb, ensure that your developers are continuously trained on coding best practices and all tools and libraries are constantly updated.
Also, make sure your code goes through extensive code reviews and lots and lots of tests as a small bug in one function can lead to a good enough opening for attackers to infiltrate your application.
Conclusion
As with all applications (serverless or not), security is and will always be a very important factor to consider.
Even though serverless makes the work of cyber attackers harder as the server infrastructure assigned to a function is almost always reset once the function is no longer active, it is still of great importance that your individual functions have been fortified enough to avoid illegal penetration.
Top comments (0)