Contributor
Contribution by Steve Wilson
Today, nearly half (49%) of organizations are running applications on serverless technology. Modern application developers rely more and more on serverless platforms from large cloud providers, and the federal government is no different.
Further, according to a 2019 Deloitte report, CIOs say that 80% of developers’ time is spent on applications, operations and maintenance, and only 20% is spent on innovation. But, by making the shift to serverless and outsourcing server and database management to a cloud platform, developers can bring new ideas to the market faster, rather than worrying about patching and management overhead.
Additionally, serverless technology reduces operating and staffing costs by automating common manual tasks and offering a pay-as-you-go model when code is executed, allowing for easy scalability. This especially helps agencies with limited budgets that are responsible for managing high volumes of traffic and massive amounts of sensitive data every day – from medical records and PII to confidential military intel – all while maintaining compliance with stringent security requirements and federal guidelines including the NIST Secure Software Development Framework.
However, while federal agencies should take advantage of the benefits of serverless computing – high availability, horizontal scaling, no runtime dependency worries and no patching downtime – they must also understand the adjustments required to service an application and make it truly secure in a serverless environment. In fact, even though agencies are adopting serverless, over half (75%) of government respondents in our recent “2021 State of Serverless Application Security” report cite the lack of purpose-built security tools for serverless environments as one of their top two security challenges in serverless.
Table of Contents
Why security is different in serverless
Serverless technology eliminates many of the security responsibilities of underlying technologies, but developers are still on the hook for securing serverless functions. If code is written insecurely, the application can still be vulnerable to traditional application-level attacks, like Cross-Site Scripting (XSS), Command/SQL Injection, Denial of Service (DoS), broken authentication and authorization, security misconfigurations, and many more.
Not only are security teams dealing with common vulnerabilities and exposures (CVEs) and open-source library risks, serverless environments also introduce new permissions threats, as every function is an island with default permission settings.
Unfortunately, previous generations of application security tools such as code scanners simply do not work on modern applications. To do serverless securely, application security programs need a massive update.
It’s time that federal agencies rethink their security strategy with the adoption of serverless. They should consider: What tools can help enforce serverless security best practices? What risks are introduced with serverless that did not exist before?
To answer these questions, developers should reference the OWASP Serverless Top 10 for an outline of different attack vectors, security weaknesses, the business impact of successful attacks on serverless applications and how to prevent them.
What’s different for serverless security?
- The attack surface increases in serverless. To reduce the attack surface, agencies should only run functions with the least privileges required to perform a task and never assume the validity of any resource.
- Stateless serverless architectures make access controls more important than ever. Attackers will target over-privileged functions to gain unauthorized access to resources. To prevent this, agencies should follow the least privilege principle for each function.
- Deserialization attacks are more common in serverless from dynamic languages like Python and NodeJS, alongside the common use of JavaScript Object Notation (JSON). Agencies should validate serialized objects, originating from any untrusted data by enforcing strict type constraints before processing.
- Serverless auditing and monitoring is even more difficult than with traditional applications. It’s easier for attackers to achieve their goals without being detected. Agencies should deploy auditing and monitoring mechanisms for data that is not fully reported by infrastructure providers to better identify security events.
As with any architecture, sensitive data exposure is also a major concern in serverless. The only difference with serverless is that instead of stealing data from a server, the attacker can target cloud storage and database tables, so agencies should only store sensitive data that is absolutely necessary.
Serverless security issue example: Log4j
Take the example of Log4j, a widely used open-source programming library that, in December 2021, was found exploitable to access unauthorized information or control a computer remotely. Hackers used Log4j to attack large enterprises including Apple, Amazon, Twitter and Baidu in addition to multiple government systems. While patches have since been released, it is extremely labor-intensive to deploy patches across systems. Log4j is also common enough in serverless applications that most organizations still struggle to identify all instances of the library in their environments.
It’s important to remember that all open-source code is a potential point of software supply chain failure. To combat this, public and private sector organizations need comprehensive application visibility. As government agencies move to serverless, they should ensure that their third-party vendors can provide full visibility to identify vulnerabilities in both open-source software (OSS) and custom code, as well as any potentially over-permissive and exploitable functions.
Private-public collaboration and resource
To deliver highly secure code, I recommend that all organizations – including government agencies – embed security earlier in the software development lifecycle through a comprehensive DevSecOps approach. Likewise, software developers and buyers should aim to provide complete transparency into the software development market.
The call for greater software transparency is stronger than ever. As directed in the Cybersecurity Executive Order, using a Software Bill of Materials (SBOM) can create more transparency in the marketplace. Following this, the National Telecommunications and Information
Administration (NTIA) released a “Minimum Elements for a SBOM” list, and many of these points were further emphasized in President Biden’s March 21, 2022 Statement on our Nation’s Cybersecurity.
It’s government’s time to secure a serverless future
As your agency moves to serverless, follow these guidelines and educate yourself on current serverless security issues. Use the OWASP Serverless Top 10, and practice on the Damn Vulnerable Serverless Application (DVSA) to test your developer skills and tools in a legal environment so as to better understand how to secure serverless applications.
In today’s cloud-based, data-driven world, the move to serverless technologies is a must for government agencies managing massive amounts of sensitive data. However, we cannot forget about the security tool change needed to support serverless. Public and private sector organizations should continue to work together to secure open-source environments, provide insights on the latest vulnerabilities and share best practices for application security in a serverless environment.
About the Author
Steve Wilson is currently the Chief Product Officer at Contrast Security. Today his team is responsible for Engineering, Product Management and Product Design for all products.
Steve has over 25 years of experience developing and marketing products at multi-billion-dollar technology companies such as Citrix, Oracle and Sun Microsystems. Prior to Contrast, Steve was the Vice President of Product Management for Citrix Cloud where he led the transformation of Citrix products from traditional on-prem to SaaS. At Oracle, he led core engineering for a billion-dollar product line of systems management software. During his time at Sun Microsystems, Steve was an early member of the team that developed the Java computer programming system, the most widely used set of software development tools in history.
Steve is the author of “Java Platform Performance: Strategies and Tactics” and “The Father/Daughter Guide to Cryptocurrency Mining.” He is a popular speaker on future of work and artificial intelligence topics and has recently presented at The Churchill Club, Silicon Valley Leadership Group, DLA Piper Global Technology Summit, IDG Agenda, SAP TechEd and WSJ Tech D.Live. He holds a degree in Business Administration from the University of San Diego and a second-degree black belt from the American Taekwondo Association.
The opinions expressed in this article are those of the author. They do not necessarily reflect the opinions or views of Executive Mosaic or its publications.
