There are several benefits to serverless computing: it’s cost-effective, scalable and compatible with cloud services. Despite these attractive qualities, however, serverless computing is not immune to the security threats that impact traditional server-based systems.
Keith Rayle, a vice president and chief information security officer at CCC Information Services, said that’s OK; the old secure development approach still applies to the serverless world.
“The technologies might change, such as access controls deployed through CASB, but the concept is the same as always, and applicable to new IT models,” Rayle said.
While Rayle and his team might implement trusted security concepts to address new technologies, they still put a great emphasis on continuous training and development.
In fact, both security professionals we spoke with emphasized the importance of keeping engineers abreast of the latest security trends and technologies.
Like Rayle, Matt Ivaliotes, a security and IT lead at fintech company CardX, regularly schedules training on new technologies for his engineering team. He also encourages knowledge-sharing through dedicated Slack channels, attending security conferences and reading industry newsletters to help keep teams on the cutting-edge.
“Security requires vigilance in all contexts,” Ivaliotes said.
Keith Rayle, a vice president and CISO, said traditional, secure development approaches can be applied to serverless deployments. At CCC Information Services, a company that uses AI to drive automotive insights, this means focusing on critical functions like asset identification, verification and security control validation. After all, Rayle said, security teams can’t protect what they can’t see.
What are a few of the internal best practices your team follows to secure your serverless deployments?
Separation of environments is old. For an old guy like me to say that, you get the importance of that statement. Most providers provision separation and administration very cleanly. One of the more critical functions that should be inserted into the serverless architecture deployment is asset identification, verification and security control validation. You simply cannot protect what you cannot see. Third parties and cloud services providers give us the ability to consume and expand IT functionality at rapid rates. Although this can allow for adaptive business alignment to the market, it can also create risk through orphaned and vulnerable systems, overlapped exposures among several similar instances and basic unprotected implementations. Being able to see into the virtual world of your IT assets is critical to the protection of them and your business.
Get to know the technologies being used by third parties or within your virtual environments.”
What training had to take place to get your developers familiar with both the risks and the practices that can minimize them?
It might be cliché, but the old secure development approach still applies to the serverless world. The technologies might change, such as access controls deployed through CASB, but the concept is the same as always, and applicable to new IT models. The topics within SecSDLC do not change just because the hardware is not on-premises. As new technologies are adopted, training is usually focused on how to use them.
A luxury in some security portfolios, having a security ace that can assist in aligning new technology usage to your security compliance requirements is invaluable. The bottom line is that training and knowledge-sharing starts at the security function. We focus our training on understanding new technologies and inserting standard security requirements and processes into them.
What advice do you have for other engineers who are just making the transition to a serverless architecture and are concerned about security risks?
Understanding the basics of security is a start, but many new technologies have a wide range of functionality, capabilities and configuration possibilities. Get to know the technologies being used by third parties or within your virtual environments. Play with them. Most security “geeks” I know spend time on the keyboard poking around in various technologies. Study them and look around the security community for information about the new technologies. Security experts love to share their knowledge and experiences. Join security consortiums that are centered on the serverless movement. For documentation types, looking through the manuals is one thing. Seeing what contracts provision from a security perspective is another.
Matt Ivaliotes, a security and IT lead, said regular training with his engineering team helps build a solid foundation on web application security at CardX. From there, Ivaliotes stressed the importance of vigilance, meaning he requires engineers to stay abreast of the latest security regulations and technological trends.
What are a few of the internal best practices your team follows to secure your serverless deployments?
We continuously monitor everything from Lambda timeouts to account password changes and send notifications across key team members.We also regularly put the team through OWASP Top 10 training so they have a solid foundation.
What training had to take place to get your developers familiar with both the risks and the practices that can minimize them?
We’ve made OWASP Top 10 training more widely available to the team beyond engineers. I believe that sharing the complexities of security, as well as the central role that social engineering plays in most serious breaches, helps our entire organization understand the demands of secure development. We build and maintain a culture of security, which includes foundational security awareness training, Slack channels dedicated to security alerts and initiatives and a monthly company infosec newsletter.
Security requires vigilance in all contexts.”
What advice do you have for other engineers who are just making the transition to a serverless architecture and are concerned about security risks?
Security requires vigilance in all contexts. Serverless architecture can reduce your layers of direct exposure, but the basics do not change. The focus may simply shift from physical firewalls to VDC segmentation and from physical access to frequent key rotation.
Be sure to understand where the Infrastructure as a Service (IaaS) provider’s documented responsibilities begin and end. Stay current on regulatory requirements and best practices, and maintain open and frank communications (with written accountabilities where needed) with service providers and partners. Check your work with regular penetration tests.
