Egress Filtering in Serverless Applications
Why You Need to Take Security Seriously
Nobody cares about security. The only people who really care are under regulatory compliance to do so and are usually under more assault from their own developers in their desperate quest to get things done than hackers. With the rise of serverless computing and cloud-native applications, the flood gates are open. Agile software development teams are spinning up code in ephemeral environments that are compliance officer’s worst nightmare. But an often-overlooked security threat is egress filtering, especially if you use NPM and NodeJS.
What is Egress Filtering
That’s a pretty good definition. In serverless applications, your code can run in a “public” VPC that is wide open to the internet, or in a private VPC which has no internet access by default. What most developers fail to recognize is that any code, including the hundreds (if not thousands) of NPM packages you are consuming, can also connect to internet resources and transfer data. The worst part is you won’t know about it unless you block internet access or perform egress filtering. To say this is a bit worrisome is an understatement. It’s a major issue that needs to be addressed as part of your architecture.
Most developers opt for optimization (usually premature) over security. One of the most common go-to mistakes is to use a public VPC instead of executing functions in a private VPC. Developers will explain that a private VPC adds to cold start times. They may even opt to publicly expose APIs and other resources to avoid using a private VPC. While the new AWS Hyperplane and Provisioned Concurrency have alleviated most of these concerns, I’m surprised how many developers still cling to this argument. I’m all for using the right tool for the job, but if you are dealing in any way with private data security needs to trump performance.
Why you should be concerned
- PCI Compliance: Ingress/Egress filtering is a requirement.
- GDPR Compliance: Data needs to stay within the region it originates.
- HIPPA and COPPA Compliance: You need consent to access and share data. Data of all parties must remain private.
- User expectation of privacy: Most users expect you aren’t going to transfer their photos, text, emails, and other data to Ukrainian bots.
- “Go to Prison Data”: This is most relevant to the internal line of business applications where secure data (often being delivered to or from a business partner) is exposed because of developer negligence.
A general rule of thumb: if the information isn’t public then you need to make sure it stays in a secure location.
If you think this is an edge case, just create some Google fodder using “npm package security breach”. And if you think Maven is immune to this type of issue think again. Anytime you consume third party software you take third party risks!
Details about the event-stream incident
This is an analysis of the event-stream incident of which many of you became aware earlier this week. npm acts…
Someone slipped a vuln into crypto-wallets via an NPM package. Then someone else siphoned off $13m…
What a wild ride, eh Komodo?
The security risks of changing package owners
When I ask software developers what their biggest security concerns are, I typically hear something about malicious…
Microsoft spots malicious npm package stealing data from UNIX systems | ZDNet
Now Pushing Malware: NPM package dev logins slurped by hacked tool popular with coders
- Use private endpoints and block all outbound traffic. But not all AWS services support private endpoints (CodeDeploy at the time of writing).
- Add a NAT Gateway to filter outbound traffic
- Purchase a solution from a third party.
While there are some solutions that meet the majority of use cases, egress filtering can be a pain the rear. This doesn’t mean you should scrap it, it means you should plan for it ahead of time and budget time and resources accordingly. Serverless is a dream, but it can quickly become a nightmare if you don’t do your part and ensure your application is secure.