Denys Rudyi - Fotolia
Protect your serverless app with this mix of AWS tools
As they move to serverless platforms, such as Lambda, development and operations teams need to acquire a new mindset -- and set of tools -- to keep their workloads safe.
While Amazon offers a range of services to detect and thwart potential risks within a cloud deployment, serverless platforms, such as AWS Lambda, open up a whole new world of security challenges and requirements.
Fortunately, there are several best practices and tools development teams can use to ensure serverless app security.
Detect threats with machine learning
Amazon GuardDuty is a fully managed service that monitors for unusual activity on your AWS account. It provides machine learning-enabled support for intelligent threat detection and uses information from other compromised AWS accounts to help protect your own. For example, if hundreds of AWS accounts suddenly see activity from a particular IP address or range, it could signal a potential threat.
Amazon already provides automated threat detection and prevention capabilities, but GuardDuty enables you to dig deeper into all activities on an account. When the service detects a threat, developers can choose to respond in two ways: automatically block specific activity or execute a custom Lambda function to perform a particular action, such as update Virtual Private Cloud security rules to block a malicious IP.
Spot dependency vulnerabilities
The most common attacks on a serverless app target its dependencies. There are several packages that almost every Node.js application uses, such as Request, the AWS software development kit and Lodash. Even if an application doesn't directly use one of these packages, chances are that it uses a dependency that does. In fact, it's fundamentally impossible -- not to mention ill-advised -- for a serverless app not to use any outside code, so development and operations teams must adapt to this model.
With CI/CD systems, most teams choose to automatically download dependencies at compilation time. This helps limit the size of repositories and ensure that packages are up to date with security patches, but it also presents potential vulnerabilities when developers interact with the Node Package Manager or other package repositories. To help mitigate this, the Node.js community added support for package lock files with local hashes to verify trusted package versions.
Even with a trusted package, however, vulnerabilities could emerge. There are services, such as Snyk, that can search for known issues after a development team detects them, but this still won't help address unknown threats.
Maintain logs with CloudTrail
With AWS CloudTrail, an operations team can stream activity logs from an AWS account directly to S3 or Lambda. API Gateway, Lambda and DynamoDB all support CloudTrail logs, which arm developers with more transparency into a serverless app.
CloudTrail events indicate when an activity happens for a particular service and which AWS account performed the activity. For example, if one of your customers complains about a record deletion, you can check the logs to track down exactly who issued the DynamoDB DELETE request and when. Also, to meet certain compliance regulations, it's important to have insight into who requested access to particular records, which you can now accomplish through CloudTrail for serverless as well.
When an operations team sends CloudTrail events to Lambda, it can monitor for unusual activity, including that from a suspicious IP address, as well as any known bad actors or processing events through machine learning models. There are also several serverless applications available in the Serverless Application Repository specifically designed for compliance and to receive logs from CloudTrail.
Block bad IP address with WAF
Amazon Web Application Firewall (WAF) is another service for development teams that run serverless applications via Lambda and API Gateway. In a traditional compute environment, developers could use firewall rules to prevent activity from known, bad IP addresses that could impact their systems or attack user logins. In a serverless model, however, the cloud provider abstracts away the underlying infrastructure, which makes it more difficult to block activity from specific IP ranges or users.
Use Lambda triggers
CloudWatch provides the ability to stream any logs and events directly to AWS Lambda. Within a CloudWatch log stream, developers can choose to Stream to AWS Lambda. For all other CloudWatch-supported events, you can configure rules to send directly to a Simple Notification Service topic, which can then be sent to Lambda.
Developers can then use Lambda triggers to identify suspicious activity, regardless of the source, and alert operations teams before too much damage is done. For example, if a user who's usually online only once a month suddenly has a spike in activity on a weekend at 2 a.m., that user's credentials could be stolen.
Developers can install WAF on any web-facing application to detect threats, such as SQL injection attacks, and perform other common vulnerability checks. For example, if someone tries to access a URL, such as /phpmyadmin or /wp-admin, on a custom-built site -- one that isn't WordPress -- it's most likely an automated bot trying to break into your software. Automated attack programs frequently target these types of URLs because they both contain common vulnerabilities that ops teams frequently fail to patch. If you see this type of unauthorized activity, it is very likely a bot that should be blocked from all activity on your application.
When they can automatically block those bad IP addresses from an application and receive alerts on them, operations teams can quickly prevent what could have been a brute-force attack. WAF comes with several preprogramed rules, but ops teams can also create rules that are specific to their business.
