Serverless Security: Understand, Assess, and Implement Secure and Reliable Applications in AWS, Microsoft Azure, and Google Cloud [1st ed.] 9781484260999, 9781484261002

Table of contents :
Front Matter ....Pages i-xvii
Introduction to Cloud Computing Security (Miguel A. Calles)....Pages 1-13
Performing a Risk Assessment (Miguel A. Calles)....Pages 15-38
Securing the Code (Miguel A. Calles)....Pages 39-69
Securing Interfaces (Miguel A. Calles)....Pages 71-100
Configuring the Application Stack (Miguel A. Calles)....Pages 101-123
Restricting Permissions (Miguel A. Calles)....Pages 125-176
Account Management (Miguel A. Calles)....Pages 177-197
Secrets Management (Miguel A. Calles)....Pages 199-227
Authentication and Authorization (Miguel A. Calles)....Pages 229-256
Protecting Sensitive Data (Miguel A. Calles)....Pages 257-283
Monitoring, Auditing, and Alerting (Miguel A. Calles)....Pages 285-312
Additional Considerations (Miguel A. Calles)....Pages 313-319
Finalizing the Risk Assessment (Miguel A. Calles)....Pages 321-324
Back Matter ....Pages 325-347

Citation preview

Serverless Security Understand, Assess, and Implement Secure and Reliable Applications in AWS, Microsoft Azure, and Google Cloud — Miguel A. Calles

Serverless Security Understand, Assess, and Implement Secure and Reliable Applications in AWS, Microsoft Azure, and Google Cloud

Miguel A. Calles

Serverless Security: Understand, Assess, and Implement Secure and Reliable Applications in AWS, Microsoft Azure, and Google Cloud Miguel A. Calles La Habra, CA, USA ISBN-13 (pbk): 978-1-4842-6099-9 https://doi.org/10.1007/978-1-4842-6100-2

ISBN-13 (electronic): 978-1-4842-6100-2

Copyright © 2020 by Miguel A. Calles This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed. Trademarked names, logos, and images may appear in this book. Rather than use a trademark symbol with every occurrence of a trademarked name, logo, or image we use the names, logos, and images only in an editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the trademark. The use in this publication of trade names, trademarks, service marks, and similar terms, even if they are not identified as such, is not to be taken as an expression of opinion as to whether or not they are subject to proprietary rights. While the advice and information in this book are believed to be true and accurate at the date of publication, neither the authors nor the editors nor the publisher can accept any legal responsibility for any errors or omissions that may be made. The publisher makes no warranty, express or implied, with respect to the material contained herein. Managing Director, Apress Media LLC: Welmoed Spahr Acquisitions Editor: Susan McDermott Development Editor: Laura Berendson Coordinating Editor: Jessica Vakili Distributed to the book trade worldwide by Springer Science+Business Media New York, 1 NY Plaza, New York NY 10004. Phone 1-800-SPRINGER, fax (201) 348-4505, e-mail [email protected], or visit www.springeronline.com. Apress Media, LLC is a California LLC and the sole member (owner) is Springer Science + Business Media Finance Inc (SSBM Finance Inc). SSBM Finance Inc is a Delaware corporation. For information on translations, please e-mail [email protected]; for reprint, paperback, or audio rights, please e-mail [email protected]. Apress titles may be purchased in bulk for academic, corporate, or promotional use. eBook versions and licenses are also available for most titles. For more information, reference our Print and eBook Bulk Sales web page at http://www.apress.com/bulk-sales. Any source code or other supplementary material referenced by the author in this book is available to readers on GitHub via the book’s product page, located at www.apress.com/978-1-4842-6099-9. For more detailed information, please visit http://www.apress.com/source-code. Printed on acid-free paper

Table of Contents About the Author����������������������������������������������������������������������������������������������������� xi About the Technical Reviewer������������������������������������������������������������������������������� xiii Acknowledgments���������������������������������������������������������������������������������������������������xv Introduction�����������������������������������������������������������������������������������������������������������xvii Chapter 1: Introduction to Cloud Computing Security���������������������������������������������� 1 Cloud Computing Service Models������������������������������������������������������������������������������������������������� 1 Infrastructure as a Service (IaaS)�������������������������������������������������������������������������������������������� 2 Container as a Service (CaaS)������������������������������������������������������������������������������������������������� 3 Platform as a Service (PaaS)��������������������������������������������������������������������������������������������������� 3 Function as a Service (FaaS)��������������������������������������������������������������������������������������������������� 3 Software as a Service (SaaS)�������������������������������������������������������������������������������������������������� 4 Cloud Computing Deployment Models������������������������������������������������������������������������������������������ 4 The Private or Enterprise Cloud����������������������������������������������������������������������������������������������� 4 The Public Cloud���������������������������������������������������������������������������������������������������������������������� 5 The Hybrid Cloud��������������������������������������������������������������������������������������������������������������������� 6 Applying a Cloud Computing Model to FaaS���������������������������������������������������������������������������� 7 An Overview on Cybersecurity������������������������������������������������������������������������������������������������������ 8 Confidentiality������������������������������������������������������������������������������������������������������������������������� 8 Integrity����������������������������������������������������������������������������������������������������������������������������������� 9 Availability������������������������������������������������������������������������������������������������������������������������������� 9 The Need for Cloud Computing Cybersecurity���������������������������������������������������������������������������� 10 Examples of Threats�������������������������������������������������������������������������������������������������������������� 10 Identifying Threats����������������������������������������������������������������������������������������������������������������� 12 Key Takeaways���������������������������������������������������������������������������������������������������������������������������� 12

iii

Table of Contents

Chapter 2: Performing a Risk Assessment������������������������������������������������������������� 15 Conventions�������������������������������������������������������������������������������������������������������������������������������� 15 Example Serverless Application�������������������������������������������������������������������������������������������� 15 Serverless Frameworks��������������������������������������������������������������������������������������������������������� 16 Programming Language�������������������������������������������������������������������������������������������������������� 16 Terms, Keywords, and Acronyms������������������������������������������������������������������������������������������� 17 Understanding the Application���������������������������������������������������������������������������������������������������� 18 Reviewing Documentation����������������������������������������������������������������������������������������������������� 18 Reviewing Source Code��������������������������������������������������������������������������������������������������������� 23 Reviewing Accounts�������������������������������������������������������������������������������������������������������������� 25 Using the Application������������������������������������������������������������������������������������������������������������� 26 Scoping the Security Assessment����������������������������������������������������������������������������������������������� 29 Understanding the Threat Landscape����������������������������������������������������������������������������������������� 30 Threat Actors������������������������������������������������������������������������������������������������������������������������� 31 Attack Surface����������������������������������������������������������������������������������������������������������������������� 33 Creating a Threat Model�������������������������������������������������������������������������������������������������������������� 34 Preparing the Risk Assessment�������������������������������������������������������������������������������������������������� 35 Key Takeaways���������������������������������������������������������������������������������������������������������������������������� 37

Chapter 3: Securing the Code��������������������������������������������������������������������������������� 39 Importance of Securing the Application Code����������������������������������������������������������������������������� 39 Choosing a Runtime Engine and Version������������������������������������������������������������������������������������ 39 Assessing Libraries and Dependencies�������������������������������������������������������������������������������������� 46 Assessing the Dependency Tree�������������������������������������������������������������������������������������������� 46 Checking for Vulnerabilities��������������������������������������������������������������������������������������������������� 48 Other Considerations������������������������������������������������������������������������������������������������������������� 49 Using Static Code Analysis Tools������������������������������������������������������������������������������������������������� 51 Unit Tests and Regression Tests�������������������������������������������������������������������������������������������������� 52 Input Validation��������������������������������������������������������������������������������������������������������������������������� 53 Event Sources������������������������������������������������������������������������������������������������������������������������ 53 Sanitizing per Event Type������������������������������������������������������������������������������������������������������ 54 iv

Table of Contents

Key Takeaways���������������������������������������������������������������������������������������������������������������������������� 63 Notes������������������������������������������������������������������������������������������������������������������������������������������� 64

Chapter 4: Securing Interfaces������������������������������������������������������������������������������� 71 Importance of Securing Interfaces���������������������������������������������������������������������������������������������� 71 Understanding Interfaces and Use Cases����������������������������������������������������������������������������������� 72 Amazon Web Services (AWS)������������������������������������������������������������������������������������������������� 72 Azure������������������������������������������������������������������������������������������������������������������������������������� 77 Google Cloud������������������������������������������������������������������������������������������������������������������������� 82 External Interfaces and Use Cases���������������������������������������������������������������������������������������� 85 Identifying the Interfaces������������������������������������������������������������������������������������������������������������ 85 Serverless Configuration File������������������������������������������������������������������������������������������������ 85 Function Code������������������������������������������������������������������������������������������������������������������������ 91 Assessing and Reducing the Attack Surface������������������������������������������������������������������������������ 95 Key Takeaways�������������������������������������������������������������������������������������������������������������������������� 100

Chapter 5: Configuring the Application Stack������������������������������������������������������ 101 Importance of Configuring the Application Stack��������������������������������������������������������������������� 101 Understanding the Serverless Configuration���������������������������������������������������������������������������� 101 Good Practices for the Serverless Configuration���������������������������������������������������������������������� 104 Defining Multiple Services��������������������������������������������������������������������������������������������������� 104 Configuring the Provider������������������������������������������������������������������������������������������������������ 105 Organizing and Defining Functions�������������������������������������������������������������������������������������� 113 Pinning the Framework Version������������������������������������������������������������������������������������������� 117 Using Plugins����������������������������������������������������������������������������������������������������������������������� 118 Using the Custom Section��������������������������������������������������������������������������������������������������� 120 AWS-Specific Configuration Settings���������������������������������������������������������������������������������� 120 Key Takeaways�������������������������������������������������������������������������������������������������������������������������� 123

Chapter 6: Restricting Permissions���������������������������������������������������������������������� 125 Importance of Restricting Permissions������������������������������������������������������������������������������������� 125 Understanding Permissions������������������������������������������������������������������������������������������������������ 126 General Principles��������������������������������������������������������������������������������������������������������������� 127 v

Table of Contents

Amazon Web Services (AWS)����������������������������������������������������������������������������������������������� 129 Azure����������������������������������������������������������������������������������������������������������������������������������� 141 Google Cloud����������������������������������������������������������������������������������������������������������������������� 152 Implementing Permissions������������������������������������������������������������������������������������������������������� 160 General Principles��������������������������������������������������������������������������������������������������������������� 160 AWS������������������������������������������������������������������������������������������������������������������������������������� 165 Azure����������������������������������������������������������������������������������������������������������������������������������� 171 Google Cloud����������������������������������������������������������������������������������������������������������������������� 173 Key Takeaways�������������������������������������������������������������������������������������������������������������������������� 175

Chapter 7: Account Management������������������������������������������������������������������������� 177 The Importance of Account Management��������������������������������������������������������������������������������� 177 Understanding Provider Accounts��������������������������������������������������������������������������������������������� 178 General Principles��������������������������������������������������������������������������������������������������������������� 178 Amazon Web Services (AWS)����������������������������������������������������������������������������������������������� 179 Azure����������������������������������������������������������������������������������������������������������������������������������� 183 Google Cloud����������������������������������������������������������������������������������������������������������������������� 185 Securing Accounts�������������������������������������������������������������������������������������������������������������������� 186 General Principles��������������������������������������������������������������������������������������������������������������� 187 AWS������������������������������������������������������������������������������������������������������������������������������������� 189 Azure����������������������������������������������������������������������������������������������������������������������������������� 194 Google Cloud����������������������������������������������������������������������������������������������������������������������� 196 Key Takeaways�������������������������������������������������������������������������������������������������������������������������� 197

Chapter 8: Secrets Management�������������������������������������������������������������������������� 199 The Importance of Secrets Management���������������������������������������������������������������������������������� 199 Protecting Secrets�������������������������������������������������������������������������������������������������������������������� 199 General Principles��������������������������������������������������������������������������������������������������������������� 200 Amazon Web Services (AWS)����������������������������������������������������������������������������������������������� 203 Azure����������������������������������������������������������������������������������������������������������������������������������� 217 Google Cloud����������������������������������������������������������������������������������������������������������������������� 221 Key Takeaways�������������������������������������������������������������������������������������������������������������������������� 226 vi

Table of Contents

Chapter 9: Authentication and Authorization������������������������������������������������������� 229 Authentication and Authorization���������������������������������������������������������������������������������������������� 229 The Importance of Authentication and Authorization���������������������������������������������������������������� 230 General Principles��������������������������������������������������������������������������������������������������������������� 231 Amazon Web Services��������������������������������������������������������������������������������������������������������� 243 Azure����������������������������������������������������������������������������������������������������������������������������������� 251 Google Cloud����������������������������������������������������������������������������������������������������������������������� 254 Key Takeaways�������������������������������������������������������������������������������������������������������������������������� 255

Chapter 10: Protecting Sensitive Data������������������������������������������������������������������ 257 Importance of Protecting Sensitive Data���������������������������������������������������������������������������������� 257 Protecting Sensitive Data���������������������������������������������������������������������������������������������������������� 258 General Principles��������������������������������������������������������������������������������������������������������������� 258 Amazon Web Services (AWS)����������������������������������������������������������������������������������������������� 266 Azure����������������������������������������������������������������������������������������������������������������������������������� 275 Google Cloud����������������������������������������������������������������������������������������������������������������������� 280 Key Takeaways�������������������������������������������������������������������������������������������������������������������������� 283

Chapter 11: Monitoring, Auditing, and Alerting���������������������������������������������������� 285 The Importance of Monitoring, Auditing, and Alerting��������������������������������������������������������������� 285 Monitoring��������������������������������������������������������������������������������������������������������������������������������� 287 General Principles��������������������������������������������������������������������������������������������������������������� 287 Amazon Web Services (AWS)����������������������������������������������������������������������������������������������� 292 Azure����������������������������������������������������������������������������������������������������������������������������������� 296 Google Cloud����������������������������������������������������������������������������������������������������������������������� 297 Auditing������������������������������������������������������������������������������������������������������������������������������������� 298 General Principles��������������������������������������������������������������������������������������������������������������� 299 AWS������������������������������������������������������������������������������������������������������������������������������������� 302 Azure����������������������������������������������������������������������������������������������������������������������������������� 304 Google Cloud����������������������������������������������������������������������������������������������������������������������� 305 Alerting������������������������������������������������������������������������������������������������������������������������������������� 306 General Principles��������������������������������������������������������������������������������������������������������������� 307 vii

Table of Contents

AWS������������������������������������������������������������������������������������������������������������������������������������� 309 Azure����������������������������������������������������������������������������������������������������������������������������������� 310 Google Cloud����������������������������������������������������������������������������������������������������������������������� 311 Key Takeaways�������������������������������������������������������������������������������������������������������������������������� 312

Chapter 12: Additional Considerations����������������������������������������������������������������� 313 Balancing Security and Other Requirements���������������������������������������������������������������������������� 313 Continuous Integration/Continuous Delivery����������������������������������������������������������������������������� 314 Source Control�������������������������������������������������������������������������������������������������������������������������� 315 Serverless Framework Plugins������������������������������������������������������������������������������������������������� 315 Serverless Configuration Sizes������������������������������������������������������������������������������������������������� 316 Optimizing Functions���������������������������������������������������������������������������������������������������������������� 317 Fault Trees��������������������������������������������������������������������������������������������������������������������������������� 318 Key Takeaways�������������������������������������������������������������������������������������������������������������������������� 319

Chapter 13: Finalizing the Risk Assessment�������������������������������������������������������� 321 Collecting All the Findings��������������������������������������������������������������������������������������������������������� 321 Scoring the Findings����������������������������������������������������������������������������������������������������������������� 322 Assessing the Business Impact������������������������������������������������������������������������������������������������ 322 Key Takeaways�������������������������������������������������������������������������������������������������������������������������� 324

Appendix A: List of Acronyms������������������������������������������������������������������������������� 325 Appendix B: Setup Instructions���������������������������������������������������������������������������� 331 I nstalling Software�������������������������������������������������������������������������������������������������������������������� 331 To Install Node.js and npm�������������������������������������������������������������������������������������������������� 331 To Install the Serverless Framework����������������������������������������������������������������������������������� 332 To Set Up Python (Required by the AWS CLI)����������������������������������������������������������������������� 332 To Set Up the Amazon Web Services (AWS) Command-Line Interface (CLI)������������������������ 333 To Set Up the Microsoft Azure CLI��������������������������������������������������������������������������������������� 333

viii

Table of Contents

Configuring the Cloud Provider in the Serverless Framework�������������������������������������������������� 334 To Configure AWS���������������������������������������������������������������������������������������������������������������� 334 To Configure Azure��������������������������������������������������������������������������������������������������������������� 334 To Configure Google Cloud�������������������������������������������������������������������������������������������������� 334

Appendix C: Exercises Review������������������������������������������������������������������������������ 335 Index��������������������������������������������������������������������������������������������������������������������� 339

ix

About the Author Miguel A. Calles is a certified Cybersecurity engineer, works on cloud computing projects, and writes about Cybersecurity. He has worked on multiple serverless projects as a developer and security engineer, contributed to open source serverless projects, and worked on large military systems in various engineering roles. He started in Cybersecurity in 2016 for a US government contract, has been doing technical writing since 2007, and has worked in multiple engineering roles since 2004. Miguel started to gain interest in Cybersecurity when he was in middle school and was trying to reverse engineer websites. Miguel is a Principal Solutions and Security Engineer at VeriToll, LLC. He has a Bachelor of Science degree in Material Science and Engineering from the Massachusetts Institute of Technology, a Master of Business Administrator degree from the University of Florida, a Cloud Security Alliance’s Certificate of Cloud Security Knowledge certification, and a CompTIA A+ certification.

xi

About the Technical Reviewer David A. Gershman is a Cybersecurity engineer for a government contractor and has the CISSP certification. He has also taught Computer Science at California Polytechnic University, Pomona, on topics ranging from introduction programming to computer networking and Cybersecurity for over 20 years. In his spare time, David enjoys restoring and programming retro 8-bit computers. 

xiii

Acknowledgments I would like to express thanks to the following persons and organizations: •

My wife and kids for supporting me in this endeavor.

•

My mentor J.R. Richardson for helping me in my professional development and encouraging me to explore new ways to grow.

•

David Gershman for introducing me to the field of Cybersecurity and throughly reviewing this book.

•

Guise Bule for inviting me to join Secjuice (a blog site that promotes writing about Cybersecurity and information security), where I first started writing about Cybersecurity and serverless computing topics.

•

David Huang from Paradigm Sift for his friendship since my college days and helping me troubleshoot a topic in Chapter 8.

•

VeriToll (my employer at the time of this writing) for allowing me to write this book and introducing me to the world of serverless computing.

•

Raytheon, before they became Raytheon Technologies, for the several years of writing technical manuals and design documents that prepared me for writing my first published book.

•

Several teachers that had a lasting impact on my education – Ms. Mary Lang, Mr. Michael Swatek, and Professor Fiona Barnes.

•

Apress for allowing me to share what I have learned about Cybersecurity in serverless computing.

•

Last but not least, my Creator for helping me achieve a life goal and His provision.

xv

Introduction When I started working with the Serverless Framework, I was curious about the security aspect. I was transitioning to a project for a mobile app with a serverless back end. Previously, I was an information assurance (IA) engineer working on Cybersecurity for US Government military systems. I had become accustomed to using well-defined processes and requirements in my role as an IA engineer. The systems we were securing were part of a vast network of other systems with strict IA requirements. The threats seemed limited; and implementing Cybersecurity, in many cases, was following a list of checklists and requirements. But, Cybersecurity in the world of serverless development was a new frontier. The more I worked with serverless, the more I wondered about its Cybersecurity. Cybersecurity with serverless projects seemed to lack the oversight that I experienced in the IA world. The team could release a serverless application without addressing security. I searched for serverless security and found limited information. I did find some helpful documents on the top serverless security risks and well-written blog posts about specific topics. I was looking for a book that provided an overview of serverless security and guidance on approaching it. I decided to write this book with the intent to fill that void and provide a resource that addressed multiple aspects of serverless security. I leveraged my IA and Cybersecurity experience, my hands-on experience with serverless, and my research to write this book. In one perspective, this book provides an overview of serverless security. You could be new to serverless and learn how to approach serverless security by performing a risk assessment. From another perspective, this book provides practical ways to address serverless security. You could be looking for examples and recommendations to implement in your serverless projects. I am excited to share this book with you because I believe it will guide you in identifying areas of consideration when securing your serverless application.

xvii

CHAPTER 1

Introduction to Cloud Computing Security In this chapter, we will review cloud computing and how its security evolved. We will learn how serverless computing relates to cloud computing and how securing serverless computing differs from the typical cloud computing Cybersecurity. We will review Cybersecurity, how it applies to cloud computing, and why it is needed. This chapter will set the foundation for Cybersecurity in serverless computing by putting it in the context of cloud computing and its security.

Cloud Computing Service Models Cloud computing is a service offering where a client rents computing resources, physically located in an offsite location, from a provider. The resources are available on demand, and the client accesses them using the Internet. A client can rent resources from networking and storage equipment to fully developed software applications. Five major service models define how providers make cloud computing resources available to their clients: Infrastructure as a Service (IaaS), Container as a Service (CaaS), Platform as a Service (PaaS), Function as a Service (FaaS), and Software as a Service (SaaS). Table 1-1 depicts how the responsibility of the resource varies among the cloud computing types and compares to the traditional on-premise computing. We will briefly review each cloud computing service model.

© Miguel A. Calles 2020 M. Calles, Serverless Security, https://doi.org/10.1007/978-1-4842-6100-2_1

1

Chapter 1

Introduction to Cloud Computing Security

Table 1-1.  Comparison of Cloud Computing Service Models and On-Premise Computing Resource

IaaS

CaaS

PaaS

FaaS

SaaS

On-Premise

Application

C

C

C

C

VR

C

Data

C

C

C

C

V

C

Functions

C

C

C

VR

V

C

Runtime

C

C

VR

V

V

C

Security†

C

C

VR

V

V

C

Middleware

C

C

VR

V

V

C

Databases

C

C

VR

V

V

C

Operating Systems

C

C

VR

V

V

C

Containers

C

VR

V

V

V

C

Virtualization

VR

V

V

V

V

C

Servers/Workstations

VR

V

V

V

V

C

Storage

VR

V

V

V

V

C

Networking

VR

V

V

V

V

C

Data Centers

V

V

V

V

V

C

V = Vendor managed, R = Rentable resource, C = Client managed † Security resources typically includes security software and appliances. Cybersecurity is essential for each resource type.

Infrastructure as a Service (IaaS) Infrastructure as a Service (IaaS) is a service offering where a provider makes infrastructure (e.g., networking equipment and computing equipment) available for a client to use. IaaS enables a client to rent infrastructure without having to procure it. The client is responsible for configuring and fine-tuning the different infrastructure components. The provider is responsible for maintaining the infrastructure, making it accessible, and ensuring a minimum level of reliability and availability. This type of

2

Chapter 1

Introduction to Cloud Computing Security

cloud computing is the closest to an on-premise model of buying, storing, powering, configuring, maintaining, and administering the infrastructure components, but with the simplified configuration and reduced maintenance and administration.

Container as a Service (CaaS) Container as a Service (CaaS) is a service offering where a provider makes software container creation and orchestration (e.g., Docker1 and Kubernetes2) available for a client to use. CaaS enables a client to compile all the software packages (needed by an application) into a container without having to set up the infrastructure. The client is responsible for configuring the container and defining the orchestration. The provider is responsible for maintaining the infrastructure, the container virtualization, and the orchestration software. This type of cloud computing provides the benefit of running a lightweight platform without having to set up the infrastructure nor install the orchestration software.

Platform as a Service (PaaS) Platform as a Service (PaaS) is a service offering where a provider makes a specific platform (e.g., an operating system, a database, and a web server) available for a client to use. PaaS enables a client to rent a platform without having to set up the infrastructure. The client is responsible for configuring and fine-tuning the platform to meet the specific need. The provider is responsible for maintaining the infrastructure, keeping the platform software up to date, and ensuring a minimum level of reliability and availability. This type of cloud computing provides the benefit of defining the computational need without having to determine what kind of infrastructure is needed to power the platform.

Function as a Service (FaaS) Function as a Service (FaaS) (typically associated with serverless computing) is a service offering where a provider enables a client to run individual software functions and interconnect them to make an application. FaaS allows a client to rent computing  ocker is a registered trademark of Docker, Inc. D Kubernetes is a registered trademark of The Linux Foundation.

1 2

3

Chapter 1

Introduction to Cloud Computing Security

time needed to execute the functions without needing to maintain any supporting software and hardware. The client is responsible for writing all the software functions and defining the orchestration among them. The provider is responsible for properly configuring and maintaining the infrastructure and platforms needed to execute the functions. This type of cloud computing provides similar benefits as PaaS and CaaS offerings, but without having to configure the platforms and containers, and enables the client to develop a SaaS offering.

Software as a Service (SaaS) Software as a Service (SaaS) is a service offering where a provider makes a specific piece of software (e.g., a web application) available for a client to use. SaaS enables a client to rent a piece of software without needing any hardware other than an Internet-connected computing device. The client is responsible for customizing any software settings provided by the application. The provider is responsible for ensuring the web application is available and preventing others from accessing the client’s account data. This type of cloud computing provides the benefits of using the software without having to perform maintenance.

Cloud Computing Deployment Models Cybersecurity was a big concern in cloud computing in its infancy and continues to be one. Cloud computing disrupted the traditional on-premise Cybersecurity model. This new model required different strategies to implement Cybersecurity, and it shared responsibilities with a third-party provider, which reserves the right to secure the system differently than the client desires. Furthermore, the provider not only has to implement Cybersecurity to establish trust with its clients. The provider also needs to secure its offering to protect itself from external threats, which also includes its clients. New models were birthed to accommodate the differing levels of adoption of cloud computing.

The Private or Enterprise Cloud An enterprise uses a private cloud to have on-premise computing equipment interconnected to on-premise networking equipment. This configuration is referred to as a cloud because the computing equipment interconnects over an intranet (i.e., an

4

Chapter 1

Introduction to Cloud Computing Security

internal Internet). Ideally, the data is only accessible within the physical premises of the enterprise for the highest Cybersecurity benefit; see Figure 1-1. An enterprise might choose a private cloud to protect sensitive data.

Figure 1-1.  Private Cloud A private cloud can have the lowest Cybersecurity risk, assuming proper Cybersecurity measures are in place. The enterprise is mostly or entirely responsible for the Cybersecurity risk. It, therefore, results in higher costs because it must procure, configure, and maintain all the networking and computing equipment and configure and maintain any Cybersecurity measures. The enterprise may favor the private cloud because the higher costs might be lower than those of a Cybersecurity breach, and it has greater control over the Cybersecurity measures.

The Public Cloud A provider establishes and provides a public cloud to make computing resources available for rent over the Internet. This configuration enables an enterprise to put data in the public cloud and have it accessible from any Internet-connected device; see Figure 1-2. Ideally, Cybersecurity measures protect data by limiting access to only specific parties. An enterprise might choose a public cloud to lower costs, increase accessibility and availability, and offset risk.

5

Chapter 1

Introduction to Cloud Computing Security

Figure 1-2.  Public Cloud A public cloud might have higher Cybersecurity risks because there is no direct purview over the infrastructure and Cybersecurity measures. The provider and the enterprise share the Cybersecurity risk. The enterprise must have the expertise to adequately configure the cloud’s Cybersecurity measures and protect its data. The enterprise might favor the shared Cybersecurity risk because it cannot afford to set up and maintain a private cloud, lacks the expertise to secure a private cloud, or prefers faster development and deployment.

The Hybrid Cloud An enterprise adopts a hybrid cloud to set up private and public clouds to work together. This configuration enables an enterprise to use a private cloud for its more sensitive data and a public cloud for its less sensitive data; see Figure 1-3. It further allows taking advantage of both sets of features and computing capabilities of both clouds. An enterprise might choose a hybrid cloud to meet legal and contractual requirements, lower costs, and configure varying levels of Cybersecurity measures.

6

Chapter 1

Introduction to Cloud Computing Security

Figure 1-3.  Hybrid Cloud The hybrid cloud might be the best of both worlds in some situations. Still, it potentially has a higher Cybersecurity risk than a private cloud and not necessarily a lower risk than a public cloud. We should use properly configured private cloud security equipment (e.g., firewall systems, intrusion detection/prevention systems, and security information and event management systems) to establish a connection between the public and private clouds. The connectivity between the private and public clouds presents an opportunity for the bypassing of security equipment and exposing the data within the private cloud. The enterprise might favor the increased Cybersecurity risk for several reasons: it wants to take advantage of features within the public cloud; it has several layers of Cybersecurity measures to mitigate the risk of the external connection; it has multiple private clouds; the public cloud only has access to a limited set of private clouds.

Applying a Cloud Computing Model to FaaS FaaS can support all three deployment models. FaaS was initially introduced as a public cloud solution because it reduces most of the configuration and maintenance effort. As the FaaS offering matured, providers added the ability to access a private cloud from a FaaS solution. The industry realized the need for having FaaS within a private cloud, and it created a FaaS solution that runs on software containers installed on servers within a private cloud. In this book, we will mostly explore Cybersecurity in the public cloud.

7

Chapter 1

Introduction to Cloud Computing Security

An Overview on Cybersecurity Cybersecurity, or security for short, is the practice of identifying the assets that need protecting, the threats against those assets, and the defenses needed to protect those assets. Many engineers, developers, and managers have become accustomed to implementing security in traditional on-premise systems: desktop computers, laptops, servers, networking equipment, operating systems, and so on. The cloud computing era disrupted how companies and individuals view their assets. Consequently, the practice of security had to evolve to work in this new computational method. Now that the assets and infrastructure are provided by a third party, the cloud computing provider and the client share the responsibility for implementing security. We can summarize security and its implementation in three words: confidentiality, integrity, and availability. Using the confidentiality, integrity, and availability (CIA) model (sometimes referred to as the CIA triad) is one way to identify the security risks and security measures needed to mitigate those risks. We will explore each element.

Confidentiality Applying confidentiality to a piece of data is giving access only to the intended recipients. Said another way, confidentiality is preventing unauthorized access from unintended recipients. A common term in recent news is “privacy.” An enterprise may choose to implement confidentiality using encryption and access control. Data has no encryption by default. Applying encryption to data prevents access to it. The data is encrypted using a key, and only that key can decrypt the file to return it to its original state. The key can be a password, file, or certificate. The encryption should happen while the data is at rest (i.e., while it sits in the file system) or while it is in transit (e.g., being transferred over the Internet). Data has no access control by default, but modern operating systems do implement some level of access control. Access control defines which data is accessible to others and how that data is used. In an operating system that supports it, the access control determines whether the current user can read, modify, or execute the data and also defines whether other users can have similar privileges. It might also allow specifying a subset of users that can read, modify, or execute the data. FaaS solutions provide encryption and access control. The account owner needs to enable shared access or public access; the account owner is the person or entity that manages the account on the public cloud. The data owner can assign read, modify, and 8

Chapter 1

Introduction to Cloud Computing Security

delete privileges to the data; the data owner is the person or entity that manages the data stores in the public cloud. The account owner is responsible for configuring the cloud infrastructure to set the desired level of confidentiality. The cloud infrastructure provides encryption for data in transit, data at rest, and access control to the data owner and others. The provider’s cloud infrastructure only gives the account owner access to the data. Cloud infrastructure supports encryption in transit and at rest.

Integrity Ensuring integrity for a piece of data is giving confidence the data someone sent you is the same data you received. Said another way, integrity is making sure there are no unintended modifications to the data, and the intended recipient has trust they received the expected data. The enterprise may choose to implement integrity using checksums, version control, or logging. A checksum is a representation of the data and is used to determine whether the file has changed since it was last accessed. For example, when a user creates a file, the system records its checksum. When the user modifies the file, the checksum also changes. The user or file system can use the checksum to determine whether the file has changed. Whenever a user creates, modifies, or deletes a file, a version control system or a logging system captures the change. The version control system saves a copy of the file for each version (and sometimes a checksum). In contrast, a logging system records the type of change, the user who invoked the change, the time the change occurred, and other relevant information. FaaS solutions provide integrity solutions natively and as an add-on feature. The account owner is responsible for configuring the cloud infrastructure to set the desired level of integrity. The owner can also enable logging systems to capture changes to the file and add checksums to the different versions of the data. The cloud infrastructure supports version control of files. The cloud infrastructure natively does file replication at the hardware level while maintaining the data integrity.

Availability Providing availability for a piece of data is using measures to ensure intended recipients can use the data. Said another way, availability is making sure the intended recipient can access the data at any time. The enterprise may increase availability through maintenance, replication, and redundancy. 9

Chapter 1

Introduction to Cloud Computing Security

Performing maintenance ensures the hardware hosting the data continues operating as long as possible without interruption. For example, if a user stores a piece of data on one piece of equipment, and it stops functioning, that data is no longer available for a user to access. Had that unit been adequately maintained, it could have continued operating longer, or the maintainer could have observed symptoms of imminent failure. Therefore, it is essential to maintain hardware to keep it running to increase availability. Replication and redundancy create replicas of data on other pieces of hardware. For example, in the event one unit fails, others make the data available for a user to access. An enterprise will use hardware components (e.g., Redundant Arrays of Independent Disks, or RAIDs) to provide local, built-in redundancy and data backup software to achieve geographical (offsite) redundancy. FaaS solutions provide availability natively when storing data in the public cloud, which has a minimum level of guaranteed availability. The account owner is responsible for selecting a cloud infrastructure with the desired minimum availability and configuring any additional availability features. For increased availability, the data owner can choose to replicate the data across multiple geographic locations within the public cloud infrastructure. Using cloud infrastructure eliminates the need to perform routine hardware maintenance. However, regular checks of the account configuration and data access are still warranted.

The Need for Cloud Computing Cybersecurity Approaching Cybersecurity is similar, yet different, in public and hybrid clouds vs. a private cloud. The enterprise has more control and influence of the security measures in a private cloud. The security measures are implemented based on the risks identified in an assessment. The enterprise should assess public and hybrid clouds similar to a private cloud, but with the understanding that the threats vary.

Examples of Threats Threats exist in the three cloud computing models and manifest themselves in several ways. We will explore a few examples of how threats manifest.

10

Chapter 1

Introduction to Cloud Computing Security

Data Breaches from Insecure Data Storage Since cloud storage configurations support private, shared, and public access, it is probable public access was set unintentionally.3 For example, an attacker can use an improperly configured cloud storage system to access highly sensitive data. An inexperienced user may accidentally grant public access while attempting to limit sharing to a small group. A user may also temporarily give public access to transfer data to other parties, but forget to revert to private access. Data breaches can result from an improperly configured cloud storage system.

 ata Breaches from Identity and Access Management D Misconfiguration Someone can access another person’s account if the Identity and Access Management (IAM) system has a misconfiguration. The data owner might use an IAM system to share data access with multiple users. Shared access should be limited to the users that require the data and no one else. For example, the finance team should only have access to confidential financial records, and not the engineering team or suppliers. Data breaches have occurred because a supplier had access to a network where sensitive data was processed.4 Data breaches can result when one account is compromised, and it has access to data it should not.

Denial of Service Attack Due To Software Vulnerabilities Any application exposed to the Internet is vulnerable to Denial of Service (DoS) or Distributed Denial of Service (DDoS) attacks. Cloud services limit how much computing power a client can use at any given time. An attacker hopes to exploit a weakness in the application by sending multiple simultaneous requests and making the application unavailable to the users. This downtime can result in financial loss and lost productivity. Weaknesses can exist at any level. For example, an attacker can exploit a software library with a known vulnerability by sending a large piece of data such that the “ 100GB of secret NSA data found on unsecured AWS S3 bucket. 29 November 2017. Adam Shepard. IT Pro. www.itpro.co.uk/security/30060/100gb-of-secret-nsa-data-found-on-unsecuredaws-s3-bucket 4 “What Retailers Need to Learn from the Target Breach to Protect against Similar Attacks.” January 31, 2014. Chris Poulin. Security Intelligence. https://securityintelligence.com/ target-breach-protect-against-similar-attacks-retailers 3

11

Chapter 1

Introduction to Cloud Computing Security

application takes a significant time to process the entire data or eventually times out.5 If thousands or millions of requests are sent simultaneously to a vulnerable software function, the application may stop responding for all users and result in a DoS to the user base.

I dentifying Threats The three previous examples illustrate the realization of threats. Your understanding of the threats to your application will help you determine how to protect against them. We will explore how to identify threats in the next chapter.

K  ey Takeaways In this chapter, we reviewed cloud computing and Cybersecurity. This chapter aimed to provide a foundation for the remainder of this book. We established concepts and terminology in cloud computing. We will briefly review these concepts and terms. We explored cloud computing service models: •

Infrastructure as a Service (IaaS) is using infrastructure (e.g., computing and networking equipment) over the Internet.

•

Container as a Service (CaaS) is using a software container (e.g., Docker) over the Internet.

•

Platform as a Service (PaaS) is using a configured platform (e.g., a database) over the Internet.

•

Function as a Service (FaaS) is running and orchestrating functions (e.g., an email subscription function) over the Internet.

•

Software as a Service (SaaS) is using an application (e.g., a web-­based email) over the Internet.

We covered cloud computing deployment models and how FaaS supports them:

“ Serverless Security & The Weakest Link (Avoiding App DoS).” 8 February 2019. Ory Segal. PureSec Blog. www.puresec.io/blog/serverless-security-and-the-weakest-link-or-hownot-to-get-nuked-by-app-dos

5

12

Chapter 1

Introduction to Cloud Computing Security

•

Private cloud is where an enterprise uses computing equipment it acquired and accesses it over an internal network. An enterprise can set up an internal FaaS solution on its hardware.

•

Public cloud is where an enterprise uses computing equipment from a third party and accesses it over the Internet. An enterprise can use a provider’s FaaS solution.

•

Hybrid cloud is where an enterprise uses private and public clouds for different purposes and uses security equipment to interconnect them to minimize risk. An enterprise may configure a private FaaS solution to access data from a public cloud and vice versa, given the security equipment on both sides are configured to enable access.

We learned the confidentiality, integrity, and availability model in Cybersecurity and how FaaS supports all three. •

Confidentiality is ensuring only the desired recipients can access a piece of data. FaaS ensures confidentiality by limiting data access to the account owner with access control systems and by using encryption.

•

Integrity is ensuring the data was unchanged and uncorrupted from the last time it was accessed. FaaS provides integrity with version control systems and logging systems.

•

Availability is ensuring the intended recipient can access the data without disruption. FaaS provides a minimum level of availability and increases with replication across geographical regions.

We reviewed examples of Cybersecurity threats to depict the need for Cybersecurity in cloud computing. In the next chapter, we will examine how to assess a FaaS application and perform a security risk assessment.

13

CHAPTER 2

Performing a Risk Assessment In this chapter, we will learn how to perform a risk assessment for a serverless application. We will explore how to understand how the application works, which includes reviewing documentation, source code, and system accounts and using the application. We will discuss why we scope the risk assessment. We will learn how to develop a threat model and how to use it to start creating the risk assessment.

C  onventions We will review the conventions used throughout this book. For clarity, we will use one example application throughout. We might deviate from this example application at times when it makes sense to explain a concept better. We will use one FaaS framework (or typically referred to as a serverless framework) for consistency, except where it lacks support for a security configuration we are learning or when we can better learn a principle by directly modifying the configuration. For simplicity, we will use one programming language in the examples because it may become overwhelming to cover the same principle in all programming languages supported by the serverless provider and framework. The goal is to ensure an optimal experience in learning security concepts with less focus on prescriptive approaches for implementing them.

E xample Serverless Application Throughout this book, we will use a fictitious ecommerce mobile app in the examples. This app allows users to buy and sell goods using a mobile app. The app brokers the transactions to ensure both buyer and seller are protected. The mobile app communicates to an Application Programming Interface (API) to execute the transactions. © Miguel A. Calles 2020 M. Calles, Serverless Security, https://doi.org/10.1007/978-1-4842-6100-2_2

15

Chapter 2

Performing a Risk Assessment

The serverless framework will create the API. The serverless application will integrate with other third-party services, which provide additional capabilities. The examples and exercises reference this fictitious application but do not provide a fully functioning system.

S  erverless Frameworks The three major FaaS and serverless providers are Amazon Web Services (AWS), Microsoft Azure,1 and Google Cloud.2 You can manually set up functions using their web-based consoles. You can choose an automated way to deploy the functions by leveraging FaaS or serverless frameworks. There are several serverless frameworks, which support different programming languages and multiple providers. We will focus on a framework that supports AWS, Azure, and Google Cloud. We will use the Serverless Framework3 in this book, not to be confused with the term “serverless framework.” Serverless, Inc. created a serverless framework that supports AWS, Azure, Google Cloud, and other serverless providers. The Serverless Framework is written in Node.js4 JavaScript and has open source and paid versions. At the time of this writing, the open source project has over 30,000 stars, forked over 3000 times, and is actively maintained.5 For these reasons, we will use the Serverless Framework throughout this book.

P  rogramming Language The Serverless Framework was built using Node.js and exists as a package in the npm6 package manager. npm is arguably the fastest growing package repository with at least one million packages at the time of this writing.7 The popularity is probably a result of JavaScript being one of the easiest programming languages to learn.8 We will use Node.js  zure is a registered trademark of Microsoft Corporation. A Google and Google Cloud are registered trademarks of Google LLC. 3 Serverless Framework is a registered trademark of Serverless, Inc. 4 Node.js is a trademark of Joyent, Inc. 5 Serverless GitHub repository. https://github.com/serverless/serverless 6 npm is a registered trademark of npm, Inc. 7 Module Counts website. www.modulecounts.com 8 “The 10 easiest programming languages to learn.” 17 July, 2017. Alison DeNisco Rayome. TechRepublic. www.techrepublic.com/article/the-10-easiest-programming-languagesto-learn 1 2

16

Chapter 2

Performing a Risk Assessment

in the examples for ease of understanding, compatibility with the Serverless Framework, and the runtime engine support from AWS, Azure, and Google Cloud.

Terms, Keywords, and Acronyms This book will use different terms, keywords, and acronyms throughout this book. They are defined in their first use and may be defined again if it aids in understanding and helps avoid confusion. Table 2-1 lists terms, keywords, and acronyms repeatedly used throughout the book.

Table 2-1.  Terms, Keywords, and Acronyms Used Throughout the Book Term, Keyword, or Acronym

Definition

API

Application Programming Interface

AWS

Amazon Web Services, a serverless platform

Azure

Microsoft Azure, a serverless platform

CLI

Command-Line Interface

Google Cloud

A serverless platform

HTTP

HyperText Transfer Protocol

HTTPS

HyperText Transfer Protocol Secure

JavaScript

A programming language

Node.js

A JavaScript runtime environment

npm

A package manager for Node.js

OS

An acronym for operating system

Serverless

Short for Serverless Framework, a serverless framework

serverless

Another term for Function as a Service

serverless.yml

A configuration file used in the Serverless Framework

sls

A CLI command for the Serverless Framework

17

Chapter 2

Performing a Risk Assessment

U  nderstanding the Application It is essential to understand the application when performing a risk assessment because each application is unique in its requirements, purpose, and capabilities. Not all application designs are the same, even if multiple applications perform similar functions. For example, the Microsoft Office9 suite has word processing, presentation, and spreadsheet capabilities. The open source equivalent of Microsoft Office is The Document Foundation LibreOffice10 suite, which also has word processing, presentation, and spreadsheet capabilities. Microsoft Office mostly uses C++, whereas LibreOffice uses C++, Extensible Markup Language (XML), and Java. Both Microsoft Office and LibreOffice prefer different XML file formats, though they do provide limited support for both file formats. Microsoft Office integrates well with the Microsoft Windows operating system (OS), Microsoft Office 365 online editor, and Microsoft SharePoint cloud-based file sharing. In contrast, LibreOffice is a cross-platform desktop application. These two office suites are different though they provide similar capabilities. Therefore, the assessor should view each application as unique and avoid applying preconceived security measures to it.

R  eviewing Documentation Reviewing the documentation is one way to begin understanding how the developers designed an application. The documentation captures the design decisions. There is an inherent divergence from the latest version of the documentation and the latest version of the application for several reasons: •

The documentation is no longer maintained.

•

Design decisions were made based on discovery while creating and updating the app.

•

The documentation updates are in progress and not yet released.

Office, Office 365, SharePoint, and Windows are registered trademarks of Microsoft Corporation. “LibreOffice” and “The Document Foundation” are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries.

9

10

18

Chapter 2

Performing a Risk Assessment

•

The documentation only captures specific software releases.

•

The current team members may be unaware that documentation exists and need updating.

In either situation, reading and understanding the documentation provides insight and prompts to inquire for additional information. There are different types of documents to review: •

Architecture and design diagrams give visual depictions about how the application integrates various components to operate and execute its intended purpose. There are different types of diagrams, each with a different viewpoint or perspective of the system.

•

Requirement documents state the functionality and objectives the application is required to achieve. These requirements may be contractual or technical.

•

Manuals provide instruction for configuring and using the application and are written for developers, technical support, or users.

Each document type provides insight into the application about its intended design, objective, or use. There might be a plethora of documentation to review and a limited time to review it. Therefore, it is imperative to select the documents you and the development team agree are the most important to review and to choose a sample of other documents as cost and schedule permit. The architecture and design diagrams are likely to be the most helpful in becoming acquainted with the application, especially if you are asked to review an application of which you were not involved in its development. There are different types of diagrams of which some include •

Architecture diagrams are higher-level views of the application. These include •

System architecture diagrams depict the relationship among all the system components (e.g., hardware and software) and external systems and how they communicate.

19

Chapter 2

•

Performing a Risk Assessment

•

Software architecture diagrams depict the relationship among the different software elements (e.g., modules, functions) and how they integrate.

•

Application architecture diagrams depict the relationship among the different aspects of the objects of the application (technical requirements, operational needs, and functionality).

•

Enterprise architecture diagrams depict the organizational impact and stakeholder interaction.

•

Security architecture diagrams depict the security components used to mitigate risks.

Design diagrams are lower-level views of the application, such as •

Activity diagrams depict the different activities the application performs.

•

Use case diagrams depict how actors use the application.

•

Timing diagrams depict the timing among different interactions within the application.

•

Sequence diagrams depict the sequence of events in the application.

•

Class diagrams depict how software classes are defined and relate.

Each gives insight into the application and may highlight security weaknesses. For example, you might consider noting a potential area of concern if a diagram shows an authorization function that does not communicate with an identity and access management system because the function might be vulnerable to granting unauthorized access to data. Even if potential security weaknesses are not evident by reviewing the diagrams, it will allow you to determine focus areas for your assessment.

20

Chapter 2

Performing a Risk Assessment

EXERCISE 2-1: PERFORMING A DOCUMENT REVIEW Objective: In this exercise, you will practice reviewing architecture and design diagrams and identify potential security concerns. Relevant Information: The ecommerce mobile app team has provided you with a set of documents: • A system architecture diagram in Figure 2-1 • An application architecture diagram in Figure 2-2 • A use case diagram in Figure 2-3 • An activity diagram in Figure 2-4

Figure 2-1.  System Architecture Diagram for the eCommerce Application

21

Chapter 2

Performing a Risk Assessment

Figure 2-2.  Application Architecture Diagram for the eCommerce Application

Figure 2-3.  Use Case Diagram for the eCommerce Application

22

Chapter 2

Performing a Risk Assessment

Figure 2-4.  Activity Diagram for the eCommerce Mobile Application Instructions: Review each diagram to understand how the application works and identify how they relate. Create a document highlighting areas of concern. Include a list of follow-up questions to inquire of the team.

Reviewing Source Code Reviewing the source code will allow you to assess how the developers implemented the design and where the implementation diverged from the design. Several automated tools analyze source code. Using these tools will systematically find flaws in the code. In Chapter 3, we will explore how to secure the code. Time permitting, you should perform a manual investigation of the code in addition to using automated tools. Listing all the source code files used in the application allows you to enumerate the functions used in the application. You can depict how each function interacts by creating a flow diagram, or you can assess the divergence of an existing diagram. Having the function list allows you to list all the inputs, event triggers, outputs, and any other relevant information. The Serverless Framework simplifies the function listing; see the example in Listing 2-1.

Listing 2-1.  Sample Serverless Framework Configuration File service: eCommerceAuthentication provider:   name: aws   runtime: nodejs10.x

23

Chapter 2

Performing a Risk Assessment

functions:   login:     handler: login.handler     events:       - http:           path: auth/login           method: post   verifyMfa:     handler: verifyMfa.handler     events:       - http:           path: auth/verifyMfa           method: post The Serverless configuration file (named “serverless.yml”) identifies the following information: •

The service has a name of “eCommerceAuthentication.” The name and the naming convention do the following: •

Lists the application name “eCommerce” to differentiate this group of serverless functions from another application

•

Describes the functions as supporting “Authentication” and differentiates this group from others in the “eCommerce” application

•

The provider is AWS.

•

The programming language runtime engine is Node.js version 10. Each function can use a different runtime as needed.

•

The functions are “login” and “verifyMfa.” The function names are named to describe their purpose.

•

The file information is listed in the “handler” key and describes the following: •

24

The files are located in the root level of the Serverless project directory because there is no directory specified in the “handler” value.

Chapter 2

•

Performing a Risk Assessment

•

The filenames are “login” and “verifyMfa” and are the same as the function name (i.e., the name before the “.handler” part of the path).

•

The entry points into the function are the “handler” method within the source code because “.handler” is the second part of path. Note: The actual file extension is “.js” because we are using Node.js.

The event triggers are HyperText Transfer Protocol (HTTP) events. Sending an HTTP request to the web address of service appended with the “path” value will trigger the function.

You can use this information to build a spreadsheet to document all the functions; see Table 2-2.

Table 2-2.  Sample Function Listing Service

Function Name

File Paths

Entry Point

Event Trigger(s)

Runtime

eCommerceAuthentication

login

Node.js 10

login.js

handler

HTTP

eCommerceAuthentication

verifyMfa

Node.js 10

verifyMfa.js

handler

HTTP

The table lists all the information extracted from the Serverless configuration file. You can expand it as needed to support your assessment and also add other columns (e.g., description, imported modules, external interfaces, internal interfaces, etc.). This table consolidates information to simplify your assessment as you automatically and manually review the source code.

R  eviewing Accounts Your security assessment should include a review of the system accounts used in the application. The account used to run the serverless application should be part of the assessment. You should also consider reviewing the accounts for any third-party services and integrations. You may need to log in to the system accounts to perform your assessment. The application team might have some hesitation in providing you with

25

Chapter 2

Performing a Risk Assessment

administrator credentials. Still, they may grant you access to an account with read-only or limited permissions. We will explore how to secure your serverless provider account in Chapter 6. You should have a standard set of questions to ask when reviewing the different accounts: •

Is there an account for each application environment (e.g., development, test, and production), or does the account support having different environments?

•

Does the team avoid using shared accounts whenever possible?

•

Does the application have an account with restricted access?

•

Are account credentials (i.e., username and password) stored securely?

•

Is multi-factor authentication supported and enabled?

•

Are logins rate limited and locked out after too many attempts?

•

Are access controls used to restrict the modification of the serverless application and its data?

You can use these sample questions as a starting point in your review or to ask the development team to investigate in the situation they give you no access to the accounts. The goal is to ensure the accounts have measures in place to protect the accounts from external threats and from it being a threat to the application.

U  sing the Application Using the application is a tangible way of learning how it works. By interacting with the front end, you can see how the front end calls the back end. You will need a tool to capture the network traffic. Note the times as you take actions on the front end, and you can correlate the network calls made to the back end. You will benefit greatly in using a network analyzer to record the traffic. Wireshark11 is a free and open source traffic analyzer that runs on Microsoft Windows, Apple

Wireshark is a registered trademark of the Wireshark Foundation.

11

26

Chapter 2

Performing a Risk Assessment

macOS,12 and Linux13 operating systems. It allows you to see all the network traffic sent and received on the network connection of the computer running Wireshark; see Figure 2-5. You might want to see additional network traffic. To see all the data in the network, you will need to set that network connection as a switched port analyzer (or port mirror) to allow Wireshark to see all the network traffic. Wireshark is a powerful network analyzer, but you may need support from a network engineer to allow it to receive all the necessary traffic.

Figure 2-5.  Wireshark Network Capture Developer tools exist that help simplify the network analysis when using the application. For a web-based application, you can use the developer tools on Google Chrome and Mozilla Firefox14 web browsers, which have built-in network analyzers; see

 pple and macOS are trademarks of Apple, Inc., registered in the United States and other A countries. 13 Linux is a registered trademark of Linus Torvalds. 14 Mozilla and Firefox are trademarks of the Mozilla Foundation in the United States and other countries. 12

27

Chapter 2

Performing a Risk Assessment

Figures 2-6 and 2-7. For a mobile application, you can use Apple Xcode for Apple iOS15 applications and Google Android Studio16 for Android applications. Both allow you to build the application, run it on a simulated or emulated device, respectively, and view the application logs. You will need the source code to use Xcode and Android Studio, and you will have a limited network analysis by viewing the logs. The developer tools can help you correlate front-end actions with back-end requests.

Figure 2-6.  Chrome Developer Tools

 pple, iOS, and Xcode are trademarks of Apple, Inc., registered in the United States and other A countries. 16 The “Android” name and other Google trademarks are property of Google LLC. 15

28

Chapter 2

Performing a Risk Assessment

Figure 2-7.  Firefox Developer Tools

Scoping the Security Assessment You should limit your assessment to the scope you were assigned. Said another way, you might only have the permission to assess the serverless application, but not the mobile app, the third-party services, and any interfaces. You could draw a dotted line enclosing all the components you are responsible for assessing. This line is called a security enclave or a trust boundary. The boundary defines what components need a thorough assessment. In general, you will use these guidelines: •

The edges of the boundary should have a security measure enabled to protect against external threats.

29

Chapter 2

Performing a Risk Assessment

•

The components within the boundary should meet a minimum level of security.

•

Components and services outside the boundary might have no required security level. Still, there can be recommendations for them, especially if the application team can influence them.

You now have a list of assets that need protection from threats.

Understanding the Threat Landscape With the numerous security breaches and Internet crimes reported in the news, it might seem it happens every other day. Threat actors (e.g., hackers) see Internet crime as lucrative because they can steal money or sell stolen information on the Dark Web. Other threat actors want to buy stolen information and are willing to pay a significant amount of money for it. The Federal Bureau of Investigation (FBI) Internet Crime Complaint Center (IC3) reports the cost of Internet crime continues to increase year over year; see Figure 2-8.17 From 2012 to 2018, the reported annual loss increased from $581.4 million18 to $2706.4 million, which is a 465.5% increase. Given the significant increase in less than a decade, it is imperative to understand and protect against threat actors and their threats.

“ 2018 Internet Crime Report.” Federal Bureau of Investigation Internet Crime Complaint Center. https://pdf.ic3.gov/2018_IC3Report.pdf 18 “2013 Internet Crime Report.” Federal Bureau of Investigation Internet Crime Complaint Center. https://pdf.ic3.gov/2013_IC3Report.pdf 17

30

Chapter 2

Performing a Risk Assessment

Figure 2-8.  FBI IC3 Complaint Statistics 2014–2018

Threat Actors Threat actors are the individuals or groups that are a threat to your application. There are different groups of threat actors, each with varying levels of skill and motivation, including •

Script kiddies lack skills to orchestrate their attacks, and their motivation varies from curiosity on hacking, embarrassing their target, or malicious intent. They use open source hacking tools or scripts to run against their target. Their attacks lack sophistication, but they can still inflict damage. Implementing standard security measures (e.g., enabling firewalls and keeping systems up to date with software patches) will typically protect your application from script kiddies.

31

Chapter 2

Performing a Risk Assessment

•

Cybercriminals can strategically orchestrate their attacks, and their motivation is typically financial gain. They use a variety of tools like script kiddies, leverage social engineering to fool individuals to disclose sensitive information, and deploy malicious software (e.g., ransomware). They are less likely to perform an attack if costs exceed the value of the target. Implementing training and detection tools, in addition to standard security measures, will help detect and prevent an attack.

•

Hacktivists can strategically orchestrate their attacks, and their motivation is to support a cause or fulfill a mission. They use any means to accomplish their mission because they are unmotivated by financial gain and returns on their investments. Understanding their motivations, agendas, and attack patterns can help in implementing custom defenses against their attacks.

•

State-sponsored attackers can strategically orchestrate their attacks, and their state sponsor governs their motivation. They benefit from leveraging their sponsor’s resources, threat intelligence, and personnel to help them achieve their goals. They can solicit support from other hackers when needed. Understanding the political interests of the different states can help in implementing custom defenses against their attacks.

•

Insider threats have varying skill levels, and their motivations vary from inadvertent to intentional. Some insiders accidentally or unknowingly are threats. Providing training on social engineering, other predatory techniques, and cyber hygiene will help protect against these inside attacks. Other insiders are disgruntled and want to inflict damage, but may or may not have the skill level to achieve an attack successfully. Ensuring a single person only has the access and privileges to accomplish their job responsibility will minimize the extent of damage an insider can inflict. Providing training on detecting and reporting insiders will also help protect against these threats. In all cases, securing systems assuming there are malicious actors inside the organization will mitigate the risk of an attack.

Now that we have an understanding of the different threat actors and their motivations, we can explore the attack surface they might use to accomplish their goals. 32

Chapter 2

Performing a Risk Assessment

A  ttack Surface A threat actor, or attacker, can exploit a vulnerability to execute an attack. A vulnerability is a weakness in the security caused by an error in software, a misconfiguration, or an omission. The attack becomes more powerful and effective with the increasing number of vulnerabilities the attacker discovers. The collection of all known and unknown vulnerabilities is considered the attack surface. Imagine you have a set of darts and a dartboard. The dartboard is the attack surface, the darts are your attacks, and your throwing precision is your attack skill. The more vulnerabilities you have, the wider the dartboard becomes. You are extremely likely to hit a dartboard the size of a person. However, you need an exceptional skill and precision to hit a dartboard the size of a quarter. Our goal as the defender is to shrink the attack surface and keep it small as long as possible. The attack surface in a serverless application is similar to a web application.19 It differs due to the differences in deployment and administration. Table 2-3 highlights some of the differences between a typical web application and a typical serverless application.

Table 2-3.  Attack Surface Differences Between Typical Web and Serverless Applications Focus Area

Typical Web Application

Typical Serverless Application

Code platform/engine

Web server

Function service

Code deployment

Upload to server

Upload to service

Configuration settings

Web server configuration

Function service settings

Data inputs/requests

HTTP, database, local storage

HTTP, database, event triggers

Security configuration

Web server platform and OS

System account/service settings

Security patching

Web server platform and OS, software packages

Software packages

 he OWASP Foundation published an Attack Surface Analysis Cheat Sheet to their GitHub page. T https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Attack_Surface_ Analysis_Cheat_Sheet.md

19

33

Chapter 2

Performing a Risk Assessment

Start with the typical set of focus areas when quantifying the attack surface. Vulnerability scanners and other tools can systematically generate the list of vulnerabilities that comprise the attack surface. Continue your assessment by assessing the deployment resources, the event triggers, and system account settings. You can use your discovery of the attack surface to create a threat model.

Creating a Threat Model Up to this point in your assessment, you will have •

Acquired knowledge of the application and its design

•

Identified the trust boundaries and assets

•

Determined the potential threat actors and motivations

•

Enumerated potential vulnerabilities

With this information, you have sufficient data to create a threat model.20 You can use a diagram or a matrix to document the threat model. In its simplest form, a threat model shows the defenses used to protect assets from threats and threat actors. A threat is an action or event that exploits a vulnerability or weakness in a system. A threat actor is a person or organization that exercises the threat. The threat model may or may not include threat actors depending on whether they are relevant to understanding the threats. The threat model for our example application might look like Figure 2-9 in a pictorial form.

 he OWASP Foundation published a Threat Modeling Control Cheat Sheet to their T GitHub page. https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/ Threat_Modeling_Cheat_Sheet.md

20

34

Chapter 2

Performing a Risk Assessment

Figure 2-9.  Sample Threat Model Diagram The threat model for our example application might look like Table 2-4 in a matrix form.

Table 2-4.  Sample Threat Model Matrix Asset

Threat

Mitigation

Accounts (system)

Account hijacking

Multi-factor authentication

Accounts (application)

Customer data exposed

Encrypted database

Payment information

Credit card data exposed

Third-party payment gateway

Your threat model becomes the start of the risk assessment you present to your stakeholders.

Preparing the Risk Assessment You will use the risk assessment to inform your stakeholders about the risk level present in their application. You should determine the risk level based on the negative impact to the business if risks are realized. For example, you might find a vulnerability in a computer system that shows announcements in the displays in a lobby. You might

35

Chapter 2

Performing a Risk Assessment

classify it as a critical vulnerability if the computer uses business logic or data. The business might deem it as unimportant and having a low risk if it runs in a network with no Internet connectivity and has no access to business data. There is always a risk, even if it might seem insignificant. You might determine the risks are a failure to disseminate information to guests and employees and an unplanned expenditure to replace the equipment. The business might classify this as low risk because there are other means to distribute information, and there is a buffer built into the budget for unplanned replacements. The security professional might present a different risk level based on findings. The risk level might change to high or critical risk if the lobby system uses a static username and password to log in to a serverless application, and it can escalate privileges to access customer data. Using the threat model and your knowledge of the business will help you classify the risk levels; see Table 2-5.

Table 2-5.  Sample Risk Assessment Asset

Threat

Risk

Likelihood

Impact

Mitigation

Accounts (system)

Account hijacking

Medium

Probable

Minor

Multi-factor authentication

Accounts (application)

Customer data exposed

Medium

Remote

Serious

Encrypted database

Payment information

Credit card data exposed

Medium

Remote

Serious

Third-party payment gateway

In addition to presenting the risk level (i.e., low, medium, high), you should present the likelihood a risk is to manifest and the impact it will have. The business will have increased interest in critical risks and how likely they are to impact their business operations and profits. For example, as an extreme, there is a threat the entire Internet stops working. Your business may lose thousands of dollars for every minute the application is down. The likelihood this will happen is extremely rare. You can further reduce the business’ concern by presenting mitigation using caching and offline capabilities that will resynchronize upon the restoration of Internet connectivity. You may have a threat that is extremely likely to happen, and it will cost thousands of dollars for every day the application is degraded. Although the impact is low in comparison, if the threat is realized easily and often, it results in having a significant 36

Chapter 2

Performing a Risk Assessment

cumulative impact. The goal is to have the most of the risks results in moderate business impact or lower by staying within the desired range of impact and likelihood; see Table 2-6.

Table 2-6.  Risk Matrix Likelihood

Impact Minimal

Minor

Major

Serious

Catastrophic

Improbable

Low

Low

Low

Low

Medium

Remote

Low

Low

Low

Medium

Medium

Occasional

Low

Medium

Medium

Medium

High

Probable

Low

Medium

Medium

High

High

Frequent

Medium

Medium

High

High

High

Your goal is to portray the risk to the business accurately. Ideally, the majority of your findings have low risk, some have medium risk, and little to none have high risk. Your assessment will include the mitigations currently used and mitigations to put into effect to reduce the risk level. You will learn mitigation techniques in the coming chapters for protecting a serverless application and reducing risk. The last chapter will help you to finalize your risk assessment.

K  ey Takeaways In this chapter, we reviewed the steps for performing a risk assessment. Understanding how one prepares a risk assessment provides us with the items we will want to investigate as part of our assessment. We established the setup we will use throughout this book: •

A fictitious ecommerce mobile app is the example application under evaluation.

•

The Serverless Framework is used to deploy the functions to the FaaS provider.

•

Node.js is the programming language used in the function code.

•

Several terms, keywords, and acronyms were defined. 37

Chapter 2

Performing a Risk Assessment

We explored different ways to understand the application, which include •

Reviewing different types of documentation (e.g., architecture and design diagrams, requirement documents, and manuals) to learn how the developers designed the application and its intended purpose

•

Reviewing the source code to enumerate the different functions, runtime engine, entry points, and event triggers

•

Reviewing the system accounts to identify external and internal threats

•

Using the application to capture the application network traffic as a tangible way of understanding its design

We can use this knowledge to perform a risk assessment by •

Determining and defining the trust boundaries to scope the security assessment

•

Understanding the threat actors, which might include script kiddies, cybercriminals, hacktivists, state-sponsored attackers, and insider threats, and their motivations

•

Quantifying the attack surface by discovering vulnerabilities

•

Creating a threat model that captures the assets, threats, and mitigations

Finally, we used the assessment to quantify the risks, their likelihood, and impact on the stakeholders. The following chapters will focus on specific aspects of serverless security. You may use each chapter as a guide to compile a risk assessment. In the next chapter, we will explore how to reduce risk by securing the application code.

38

CHAPTER 3

Securing the Code In this chapter, we will review the importance of securing the application code. We will learn how to choose the runtime and version for our serverless functions and how to assess any libraries and dependencies they use. We will discuss static code analysis tools, unit tests, and regression tests and how they help secure our application code. Finally, we will learn how multiple events can trigger serverless functions and review examples on performing input validation on those events.

Importance of Securing the Application Code The following chapters focus on practical approaches in securing the application. The security strategy may seem different when compared to a typical system that uses servers and operating systems. In these systems, it may seem there is more emphasis on securing the infrastructure and platforms that run the application. Though it may appear these security focus areas are more important, the topics discussed in the following chapters are also important. This chapter focuses on securing the application code. We have abstracted the infrastructure and platform when we deploy our application to a serverless environment. We have little influence over the security posture of the operating system (OS), code platform, and the other mechanisms used to run the serverless application. But we can secure the application code. In other systems, we could take advantage of the security implementation for the OS and platform to mitigate risks in the code. But in a serverless environment, we cannot secure the OS and platform. Therefore, it is imperative to secure the code we deploy to our serverless platform.

Choosing a Runtime Engine and Version Your serverless provider might support multiple runtime engines (e.g., Node.js, Python, Java, etc.) and different versions. For example, Amazon Web Services (AWS) supports © Miguel A. Calles 2020 M. Calles, Serverless Security, https://doi.org/10.1007/978-1-4842-6100-2_3

39

Chapter 3

Securing the Code

various runtime engines and the ability to create a custom runtime; see Figure 3-1. You must determine which runtime engine to use based on how it will support the application and its security.

Figure 3-1.  AWS Lambda Runtime Options This book focuses on security and will not give you guidance on how to choose between Java, Node.js, Python, Ruby, and so on to meet the functional requirements for your application. In the situation where only one runtime meets those requirements, choosing the latest runtime version typically has the least number of vulnerabilities, and it is considered the most secure version to adopt. You may also have the ability to select a different runtime engine per function, thus giving you the flexibility to meet your functional requirements while balancing the security posture. AWS, Azure, and Google Cloud all support Node.js as a runtime engine. At the time of this writing, only AWS and Google Cloud allow you to choose other runtime engines. As we established in Chapter 2, we have chosen Node.js as our preferred programming language and runtime. We can write all the serverless functions in Node.js for uniformity. Still, it might make sense to use a different runtime in some cases. 40

Chapter 3

Securing the Code

If you have the option to choose among different runtimes for a serverless function, you should choose the runtime with the least number of vulnerabilities. You can use the Common Vulnerabilities and Exposures (CVE),1 National Vulnerability Database (NVD),2 or an aggregator like CVE Details3 website to review the vulnerabilities. We will use the CVE Details website because it provides a relatively more straightforward user interface. Still, I encourage you to become familiar with the CVE and NVD. To search the vulnerabilities per runtime •

Visit www.cvedetails.com.

•

Click Version Search under the “Search” section in the left pane.

•

Enter the Vendor Name, Product Name, and Version based on search criteria in Table 3-1; see Figure 3-2.

•

Click Search.

Note: This website accepts the “%” symbol as a wildcard.

Table 3-1.  CVE Details Version Search Criteria Runtime and Version

Vendor Name

Product Name

Version

.NET Core 2.x

Microsoft

.NET Core

2%

Go 1.x

Golang

GO

1%

Java 8.x

Oracle

JRE

1.8%

Node.js 10.x

Nodejs

Node.js

10%

Node.js 8.x

Nodejs

Node.js

8%

Python 2.x

Python%

Python

2%

Python 3.x

Python%

Python

3%

Ruby 2.x

Ruby-lang

Ruby

2%

“ Common Vulnerabilities and Exposures.” The MITRE Corporation. https://cve.mitre.org “National Vulnerability Database.” National Institute of Standards and Technology. https://nvd.nist.gov 3 “CVE Details.” Serkan Özkan. www.cvedetails.com 1 2

41

Chapter 3

Securing the Code

Figure 3-2.  CVE Details Version Search Criteria Example Figure 3-3 shows the search results using Microsoft .NET as an example. Take note of the number of vulnerabilities for the specific runtime minor version (e.g., Python 2.7) or the latest version of a major version (e.g., Java 8 or Node.js 10.x).4 Optionally, use the raw data to manually create a bar chart of the number of vulnerabilities by version for a major version to see the trend of vulnerabilities by version; see Figure 3-4. The website also provides you with statistics for the product overall when you click the version product in the search results; see Figure 3-5. You should consider reviewing the vulnerability details.

 ajor version and minor versions are terms defined in semantic versioning. “Semantic M Versioning 2.0.0.” Tom Preston-Werner. https://semver.org

4

42

Chapter 3

Securing the Code

Figure 3-3.  CVE Details Version Search Results Example

Figure 3-4.  Example Bar Chart of Java 8.x Vulnerabilities by Runtime Version Update 43

Chapter 3

Securing the Code

Figure 3-5.  CVE Details Vulnerability Statistics Example You will build an understanding of a runtime’s security posture as you review the vulnerability details. You may find multiple versions have a low number of vulnerabilities, but with high severity scores. You may also find various versions have numerous vulnerabilities, but with low severity scores. Or perhaps you may discover the vulnerabilities do not apply to your application or the serverless environment. Use all these data inputs to determine which runtime engine is most preferred based on the security risk level. The developers might want a runtime other than Node.js to achieve a specific goal. They might want to use Java for its multithreading and libraries, Go for its efficient concurrency, Python for its simplicity and libraries, and so on. Understanding the intent of the developer may have an impact on your recommendation to them if they ask for your input from a security perspective. In addition to checking for vulnerabilities, you should check for the end-of-life (EOL) date for the runtime versions. At the time of this writing, AWS Lambda supports Python 2.7 as a runtime. The Python Software Foundation announced a January 1, 2020, EOL

44

Chapter 3

Securing the Code

date5 for Python 2.7, meaning it will no longer provide bug fixes or patches after this date. Any developers choosing to use Python 2.7 before this date will want to consider upgrading before the EOL date. We will practice using CVE Details and researching the EOL date in Exercise 3-1.

EXERCISE 3-1: CHOOSING A RUNTIME Objective: In this exercise, you will practice using CVE Details to check for known vulnerabilities in runtime versions. Relevant Information: The development team has asked for guidance on which runtime to use for their serverless functions. They are trying to decide between Python and JavaScript since they both have the desired dependencies. Instructions: 1. Visit www.cvedetails.com. 2. Click Version Search under the “Search” section in the left pane. 3. Enter “Nodejs” as the Vendor Name, “Node.js” as the Product Name, and “8%” as the Version; see Table 3-1. 4. Click the Search button. 5. Convert the results search table to a spreadsheet by copying and pasting the data into a spreadsheet application. 6. Optionally, create a bar chart from the spreadsheet data similar to Figure 3-4. 7. Update the search parameters by entering “Nodejs” as the Vendor Name, “Node.js” as the Product Name, and “10%” as the Version; see Table 3-1. 8. Repeat steps 4 and 5 for Node.js 10.

“ PEP 373 -- Python 2.7 Release Schedule.” Python Software Foundation. 3 November 2018. www.python.org/dev/peps/pep-0373/

5

45

Chapter 3

Securing the Code

9. Update the search parameters by entering “Python%” as the Vendor Name, “Python” as the Product Name, and “2%” as the Version; see Table 3-1. 10. Repeat steps 4 and 5 for Python 2. 11. Update the search parameters by entering “Python%” as the Vendor Name, “Python” as the Product Name, and “3%” as the Version; see Table 3-1. 12. Repeat steps 4 and 5 for Python 3. 13. Search online for the “end-of-life” dates for Node.js 8, Node 10, Python 2, and Python 3 and record your findings. Assess all the results and recommend the package(s) the developers should use.

Assessing Libraries and Dependencies The developers may use libraries in their functions. Using libraries saves the developer time by leveraging existing functionality rather than writing it. There is typically no guarantee the library is efficient and without vulnerabilities. The developer of the library may have used other libraries. The number of libraries may be several layers deep. We will explore how to evaluate the dependencies used in your serverless functions.

Assessing the Dependency Tree When a piece of code uses a library in the logic it executes, that library is called a dependency. You add a layer of code when you introduce a dependency in your code. As dependencies use other dependencies, these layers get deeper. Each dependency forms a tree branch from the tree trunk (i.e., the original piece of code). It is possible adding a single dependency can add a large tree of dependencies several layers deep, all stemming from one branch. A vulnerability may exist at any layer or branch and may affect your serverless function depending on the severity and difficulty to exploit. Therefore, it is essential to understand the dependency tree and to keep it as short and narrow as possible.

46

Chapter 3

Securing the Code

The size of a dependency tree might not be apparent when you add a dependency to your code. npm will list the number of packages (i.e., libraries) used in your Node.js project, but it is a cumulative count. You may have multiple packages in your project, but your serverless functions may only use a small subset. You can use a dependency tree tool, such as those listed in Table 3-2, to help you visualize the tree. Figure 3-6 shows an example of specific packages used by serverless functions.

Table 3-2.  Dependency Tree Tools Tools

License

Supported Runtime

Anvaka1

Free Plan

Node.js

Apache Maven Dependency Plugin2

Free and Open Source

Java

Bundler3

Free and Open Source

Ruby

DependencyWalker for .NET4

Free and Open Source

.NET

Depth5

Free and Open Source

Go

Gradle Scans6

Free and Paid Plans

Java

NDepend7

Paid Plans

.NET

Pideptree8

Free and Open Source

Python

47

Chapter 3

Securing the Code

Figure 3-6.  Example Node.js Package Dependency Tree Generated with Anvaka A dependency tree tool will help you count the number of dependencies and see the size of the dependency tree. You can use the dependency tree to help you decide which package(s) to use when you are evaluating multiple packages that provide the same functionality. We will explore this in Exercise 3-2.

C  hecking for Vulnerabilities Your dependencies should be free from known vulnerabilities whenever possible. Although you wrote your code with no vulnerabilities, you may introduce them by using libraries. Periodically checking your dependencies for vulnerabilities is a good practice to maintain the security posture of your application. Use vulnerability checkers, such as those listed in Table 3-3, to determine whether your dependencies have vulnerabilities. The tools identify which versions have known vulnerabilities and which fixed them. 48

Chapter 3

Securing the Code

In the event a package has no fixes, you should determine the security risk and provide a recommendation to accept the risk or to mitigate it by using a different package or other security control. Running these checks will help you deploy code with no known vulnerabilities, mitigated vulnerabilities, or with vulnerabilities with the risk accepted by the stakeholders.

Table 3-3.  Library Vulnerability Checker Tools Vulnerability Checker

License

Supported Runtimes

Bundler Audit9

Free and Open Source

Ruby

Dependency-Check10

Free and Open Source

Python

npm audit11

Free and Open Source

Node.js

OSSIndex Audit.NET12

Free and Open Source

.NET

OSSIndex Gradle Plugin13

Free and Open Source

Java

OSSIndex Maven Plugin14

Free and Open Source

Java

OWASP Dependency Check15

Free and Open Source

Java, .NET (Experimental: Ruby, Node.js, Python)

Safety16

Free and Open Source

Python

Snyk17

Free and Paid Plans

Java, .NET, Ruby, Python, Go, Node.js

SourceClear18

Paid Plans

Java, Ruby, Python, Go, Node.js

Vulnerability checkers support integration into your development environment. Many organizations adopt Continuous Integration (CI) and Continuous Development (CD). CI/CD allows developers to write code, capture it in a configuration management tool or software repository, and see the code deployed in the application. You can suggest integrating vulnerability checkers into the CI/CD to automatically check for vulnerabilities and notify the developer before the code is approved.

O  ther Considerations Aside from the dependency tree size and the known vulnerabilities, there are other factors you might want to consider in choosing or maintaining your packages, including

49

Chapter 3

Securing the Code

•

Last published date informs whether the package is actively maintained. An old package may no longer have support. The maintainer may no longer check the code for vulnerabilities nor update the package to fix them.

•

Unused packages might still exist in an existing project. Having unused code in your project will make it larger than needed, skew any security audits, and increase the attack surface of your project.

•

Older versions are more likely to be vulnerable than newer package versions. Periodically upgrading to the latest version of packages decreases the likelihood of a vulnerability being present.

Ultimately, understanding how the developers chose and used packages and used them and whether they are maintained will sustain the security posture of your application.

EXERCISE 3-2: ASSESSING PACKAGES Objective: In this exercise, you will practice using Anvaka to view a dependency tree and npm audit to check for known vulnerabilities. Relevant Information: The development team has asked for guidance on which library to use in their Serverless Node.js functions. The functions will perform HTTP requests. They are trying to decide among the “request,” “request-promise,” “http-request,” and “got” packages and want your suggestion based on a security perspective. Instructions: 1. Open the source code in the chapter03/exercise02 folder using the CLI. 2. Run npm install in the CLI to install the packages. 3. Open the package.json file and note the dependencies. 4. Visit https://npm.anvaka.com and generate the dependency for each of the dependencies in the “package.json” file. Capture the number of nodes and links in a table. 50

Chapter 3

Securing the Code

5 . Run npm outdated in the CLI to determine whether the installed packages are up to date and capture which packages are outdated. 6. Visit www.npmjs.com and search for each package. Determine the age (in years or months) of the installed version and the age of the last published version. 7. Run npm audit in the CLI to determine whether the installed packages have known vulnerabilities. Determine which packages have vulnerabilities and any recommended remediations. 8. Visit https://snyk.io, go to the Vulnerability DB section, select the npm repository, and search for each package. Determine which packages have a history of vulnerabilities. Assess all the results and recommend the package(s) the developers should use.

Using Static Code Analysis Tools Static code analysis inspects the source code against a set of rules that check for common coding and security errors. Performing static code analysis is a standard security practice, but it becomes essential in a serverless environment. Traditional environments have the benefit of securing the infrastructure, operating system, platform, and so on to protect the application software and any known limitations it might have. In some respects, the serverless function code is the first line of defense because you can invoke it directly. Having well-written code that avoids common mistakes and known security vulnerabilities is imperative and can be achieved using static code analysis tools. Static code analysis tools, such as those in Table 3-4, assess your code for common issues. They ensure the code conforms to the syntax, but also have rules to prevent against known security pitfalls. For example, Node.js provides the “eval” function that executes JavaScript code. This function is exceptionally prone to running malicious code since it evaluates any code given, and it runs with the same privileges as the main code. A static code analysis tool has rules to check for these common issues and reports any findings.

51

Chapter 3

Securing the Code

Table 3-4.  Static Code Analysis Tools Analysis Tool

License

Supported Runtimes

Bandit19

Free and Open Source

Python

Pylint20

Free and Open Source

Python

ESLint21

Free and Open Source

Node.js

SonarLint22

Free and Open Source

Java, .NET, Node.js, Python, Ruby

SonarQube23

Free Plan

Java, .NET, Node.js, Python, Ruby, Go

Wikipedia has a more thorough list of static code analysis tools.6

Unit Tests and Regression Tests Performing unit tests and regression tests improves code quality and helps catch code regression. Unit tests evaluate the inputs and outputs of sections of the code to determine they perform as designed. Regression tests consist of test cases that determine whether the overall application functions as expected, and it is not regressing (i.e., getting worse). The purpose of these tests is not to explicitly check for security concerns, but you can use them to that end. A developer can add invalid inputs into unit tests to ensure the code provides expected and secure output. For example, there might be a function that accepts a filename as an input. The unit tests can run a check for an injection attack on the input (e.g., a “myfile.jpg; cd /tmp; ls” filename) and determine whether a proper response is returned (e.g., an error code) or an undesired response is returned (e.g., the contents of the temporary directory). The unit tests allow the developer and security team to be creative in developing potential exploits to find vulnerabilities. The team may use the regression tests to define test cases that demonstrate a certain level of security in the application. For example, there might be a test case for successfully registering for an account, but there could be test cases for a user exiting the registration process midway, a user registering again, a nonregistered user attempting

“ List of tools for static code analysis.” Wikipedia. https://en.wikipedia.org/wiki/ List_of_tools_for_static_code_analysis

6

52

Chapter 3

Securing the Code

to access registered user functionality, and so on. The regression test allows the team to be creative in using the application in a nonstandard way and determine whether it responds acceptably and securely.

I nput Validation Input validation is the practice of writing software that checks the input it receives matches the expected format. Input validation is arguably the most effective runtime defense mechanism in a serverless environment. The Open Web Application Security Project (OWASP) Foundation7 and the Cloud Security Alliance (CSA)8 both published documents that define the top serverless security risks. Both define injection attacks as the highest risk, which is mitigated by input validation. Carnegie Mellon University sets the Software Engineering Institute (SEI) Computer Emergency Response Team (CERT) Secure Coding Standards,9 which lists input validation as the top secure coding practice. With such emphasis on input validation in both serverless and non-serverless environments, it behooves us not to take it lightly.

E vent Sources Event triggers invoke (i.e., execute) serverless functions. The event generates input data and sends it to the function, which uses it in the execution logic. Table 3-5 lists the AWS,10 Azure,11 and Google Cloud12 event triggers available at the time of this writing.

“ OWASP Top 10: Interpretation for Serverless.” OWASP Foundation. 2017. www.owasp.org/ index.php/OWASP_Serverless_Top_10_Project 8 “The 12 Most Critical Risks for Serverless Applications 2019.” Cloud Security Alliance. 2019. https://blog.cloudsecurityalliance.org/2019/02/11/ critical-risks-serverless-applications/ 9 “Top 10 Secure Coding Practices.” Carnegie Melon University. 2 May 2018. https://wiki.sei. cmu.edu/confluence/display/seccode/Top+10+Secure+Coding+Practices 10 “Using AWS Lambda with Other Services.” AWS Lambda Developer Guide. Amazon Web Services. https://docs.aws.amazon.com/lambda/latest/dg/lambda-services.html 11 “Azure Functions triggers and bindings concepts.” Microsoft Azure. https://docs. microsoft.com/en-us/azure/azure-functions/functions-triggers-bindings 12 “Events and Triggers.” Google Cloud Functions documentation. Google. https://cloud. google.com/functions/docs/concepts/events-triggers 7

53

Chapter 3

Securing the Code

Table 3-5.  Event Triggers Provider Event Trigger(s) AWS

Amazon Alexa,24 Amazon API Gateway (i.e., HTTP),25 Amazon CloudFront (Lambda@ Edge),26 Amazon CloudWatch Events,27 Amazon CloudWatch Logs,28 Amazon Cognito,29 Amazon DynamoDB,30 Amazon Kinesis,31 Amazon Kinesis Data Firehose,32 Amazon Lex,33 Amazon Simple Email Service,34 Amazon Simple Notification Service,35 Amazon Simple Queue Service,36 Amazon Simple Storage Service,37 AWS CloudFormation,38 AWS CodeCommit,39 AWS Config,40 Elastic Load Balancing (Application Load Balancer)41

Azure

Blob storage,42 Cosmos DB,43 Event Grid,44 Event Hubs,45 HTTP & Webhooks,46 Microsoft Graph Events,47 Queue Storage,48 Service Bus,49 Timer50

Google Cloud

Cloud Storage,51 Cloud Pub/Sub,52 Cloud Firestore,53 Firebase Realtime Database,54 Firebase Analytics,55 Firebase Auth,56 HTTP,57 Operations and Cloud Logging5813

Sanitizing per Event Type Each event has a different input structure. We will explore two event types to illustrate how to sanitize per event type. Given there are numerous event types, I encourage you to become familiar with the specific events used in your application and implement appropriate input validations.

Amazon API Gateway Event Sanitization Example In the “chapter03/examples-input-validation” folder, you will find a “serverless. yml” configuration file14 that defines an AWS Lambda function. The function has an HTTP event (i.e., an API Gateway event trigger) configured for the “example/ {myPathParameter}” path. When you deploy, Serverless creates the Lambda with an HTTP endpoint similar to "https://7mzctr1gua.execute-api.us-east-1.amazonaws. com/dev/example/testParameter?testKey=testValue1&testKey=testValue2" that

 tackdriver was renamed to Operations, which provides Cloud Logging. “Operations (formerly S Stackdriver).” Google. https://cloud.google.com/products/operations 14 The “serverless.yml” configuration file uses the YAML Ain’t Markup Language (YAML) format that is tab dependent and uses the “#” for comments. Learn more at “YAML: YAML Ain’t Markup Language.” %YAML 1.2. https://yaml.org 13

54

Chapter 3

Securing the Code

you can visit. Note: I updated “{myPathParameter}” to “testParameter” and added a query string of “testKey=testValue” to help with understanding the event data. We will explore the event input data next.

Example Input Data In the “chapter03/examples-input-validation/src/apigateway” folder, you will find an “eventGet.json” file that captures an actual event data object generated by calling the HTTP endpoint above. You will see the event object has 91 lines of data when formatted to a human-readable format. The event data has several notable properties: •

The “resource” property contains the API Gateway resource from the Serverless deployment. It matches the “path” property defined in the “serverless.yml” file but prefixed with a forward slash (/).

•

The “path” property contains the path element in the address used to call the API Gateway endpoint that triggers the Lambda function. It conforms with the “path” property defined in the “serverless.yml” file, but with the text in the curly brackets replaced with an actual value. •

“https://” is the prefix.

•

“7mzctr1gua.execute-api.us-east-1.amazonaws.com” is the domain.

•

“/dev” is the API Gateway stage defined in the “serverless.yml” configuration.

•

“/example/testParameter” is the path.

•

“testKey=testValue1&testKey=testValue2” is the query string.

•

The “httpMethod” property contains the HTTP method (e.g., GET, POST, PUT, DELETE, etc.) used in the HTTP request made to the specified address.

•

The “headers” property contains the HTTP headers provided in the HTTP request.

•

The “multiValueHeaders” property contains the information from the “headers” property but converts the subproperties into an array for repeated HTTP request header fields. 55

Chapter 3

Securing the Code

•

The “queryStringParameters” property contains the keys and their last value specified in the query string. In our example, you will notice it only returned the “testValue2” key value.

•

The “multiValueQueryStringParameters” property contains the keys and all the values specified in the query string.

•

The “pathParameters” property contains all the path parameters and the values used in the address. In our example, you will notice the “myPathParameter” path parameter has a value of “testParameters” because we used that value in the address where “{myPathParameter}” was defined in the “path” within the “serverless.yml” configuration.

•

The “stageVariables” property contains the stage variables defined for the API Gateway. The value is “null” unless you enabled a Serverless plugin to define stage variables.

•

The “requestContext” property contains additional information (e.g., the API Gateway stage, the AWS account identifier, and the requestor’s IP address).

•

The “body” property contains the payload data sent in an HTTP POST as a serialized JSON string. The value is null for an HTTP GET. Review the “chapter03/examples-input-validation/src/ apigateway/eventPost.json” file to see the body data for an HTTP POST.

•

The “isBase64Encoded” property is a Boolean stating whether the payload is in base64 binary format. The value is “false” unless you enabled a Serverless plugin to convert the payload to base64.

We will explore using these properties to perform input validation.

Example Input Validation In the “chapter03/examples-input-validation/src/apigateway” folder, you will find an “example.js” file that defines a Lambda function configured to accept both GET and POST HTTP requests. The example code illustrates different validation approaches for your consideration. 56

Chapter 3

Securing the Code

eYou will find the input validations are specific to the design of the Lambda function. They do the following •

Accept GET and POST HTTP requests

•

Require a path parameter

•

Require one query string parameter with a specific data structure for a GET

•

Reject query string parameters for a POST

•

Require two body properties with specific data structures for a POST

•

Execute only for the IP address of a particular server

You will see in the code how the following event properties are used to achieve the specified input validations: •

•

The “body” property conforms to the HTTP method and has the required data elements. It should contain all the required JSON properties and test that all the required and optional JSON properties match an expected input (e.g., data type, length, and format). •

The input validation can check that an HTTP GET has an empty body. See the “Example input validation 1” code section.

•

The input validation can check that an HTTP POST has the two required “bodyKey1” and “bodyKey2” properties and their values both strings, with lengths between 1 and 20 characters, and only uses alphanumeric characters. See the “Example input validation 2” code section.

The “queryStringParameters” and “multiValueQueryStringParameters” properties conform to the HTTP method and have the required data. •

The input validation can check that an HTTP POST has no query string parameters. See the “Example input validation 3” code section.

57

Chapter 3

Securing the Code

•

•

The input validation can check that an HTTP GET has the required “testKey” property, and its value is a string, with a length between 1 and 20 characters, and only uses alphanumeric characters. It can additionally check that there is only one value for the “testKey” property in the “multiValueQueryStringParameters” property. See the “Example input validation 4” code section.

The “sourceIp” property, nested under the “requestContext” property, matches a whitelisted IP. •

The input validation can check the requestor’s IP address matches the IP address specified in the “environment” property in the “serverless.yml” configuration. See the “Example input validation 5” code section.

These input validations will vary on the intent of your Lambda function. The goal is to determine how the event data might change and how your application will check its validity. You can use an API test tool like Postman15 (see Figure 3-7) to test different variations in the address, HTTP method, query string parameters, and the body.

Postman is a registered trademark of Postman, Inc.

15

58

Chapter 3

Securing the Code

Figure 3-7.  Sending an HTTP Request Using Postman

Amazon Simple Storage Service (S3) Event Sanitization Example In the “chapter03/examples-input-validation” folder, you will find a “serverless.yml” configuration file which defines an AWS Lambda function. The function has an S3 event configured. When you deploy, Serverless creates the Lambda and an S3 bucket as defined in the “resources” property within the “serverless.yml” file. A file uploaded to the S3 bucket will trigger the Lambda function. We will now explore the event input data.

Example Input Data In the “chapter03/examples-input-validation/src/s3” folder, you will find an “event.json” file that captures an actual event data object generated after uploading a file to the S3 bucket. You will see the event object has 38 lines of data when formatted to a human-­ readable format. The event data has several notable subproperties.

59

Chapter 3

•

Securing the Code

The “Records” property contains an array of all the file upload records that triggered the Lambda function. Each record is an object with its properties. These are the notable properties in the record object. •

The “eventSource” property contains the event type. In this case, it is “aws:s3” but will differ for a different event (e.g., “aws:dynamodb”).

•

The “eventTime” property contains the event generation time in ISO-8601 notation.

•

The “requestParameters” property contains information about the request.

•

The “sourceIPAddress” property, nested under the “requestParameters” property, contains the IP address that performed the file upload.

•

The “s3” property contains information about the S3 bucket and object.

•

The “bucket” property, nested under the “s3” property, contains information about the S3 bucket to which the file was uploaded.

•

The “object” property, nested under the “s3” property, contains information about the uploaded file.

We will explore using these properties to perform input validation.

Example Input Validation In the “chapter03/examples-input-validation/src/s3” folder, you will find an “example. js” file which defines a Lambda function configured to accept an S3 event. The example code illustrates different validation approaches for your consideration. You will find the input validations are specific to the design of the Lambda function. They do the following

60

•

Reject empty records

•

Accept S3 event sources

•

Reject files smaller than 10 kilobytes

Chapter 3

•

Reject filenames longer than 50 characters

•

Require files with valid file extensions

•

Execute only for the IP address of a particular server

Securing the Code

You will see in the code how the following event properties are used to achieve the specified input validations: •

The “Records” property is an array with at least one object. See the “Example input validation 1” code section.

•

The “eventSource” property, in the record object, equals “aws:s3”. See the “Example input validation 2” code section.

•

The “name” property, nested under the “s3” and “bucket” properties in the record object, equals the bucket name defined in the “serverless.yml” configuration. See the “Example input validation 3” code section.

•

The “size” property, nested under the “s3” and “object” properties in the record object, is greater than a minimum size to filter unrealistic files. See the “Example input validation 4” code section.

•

The “key” property, nested under the “s3” and “object” properties in the record object, has two input validations. •

The value is smaller than a maximum size to filter files with an injection attack. See the “Example input validation 5” code section.

•

The value ends with a valid file extension. See the “Example input validation 6” code section.

•

Additionally, you can add code to read the file and inspect the MIME type equals “image/jpeg” to validate it is an actual JPEG file rather than a different file type with the JPEG file extension. Note: Be cautious in implementing this check to avoid executing any remote code embedded within the file.

61

Chapter 3

Securing the Code

•

The “sourceIpAddress” property, nested under the “requestParameters” property in the record object, matches the IP address specified in the “environment” property in the “serverless. yml” configuration. See the “Example input validation 7” code section.

•

The “eventName” property, in the record object, equals “ObjectCreated:Put” to filter other ways the file was created or deleted. See the “Example input validation 8” code section. Note: The “serverless.yml” file also performs the filter using the “rules” property, but it is good to validate in the code in the event an erroneous S3 event triggers the function.

•

The “eventTime” property, in the record object, is no older than five minutes to avoid processing old records. See the “Example input validation 8” code section. Note: You could check the event time is not in the future to filter out erroneous event triggers.

These input validations will vary on the intent of your Lambda function. The goal is to determine how the event data might change and how your application should check its validity. You can use the AWS S3 Management Console (see Figure 3-8) to test different file uploads.

62

Chapter 3

Securing the Code

Figure 3-8.  AWS S3 Management Console

Key Takeaways In this chapter, we reviewed several topics regarding the importance of securing the application code. We explored how to choose a runtime engine and version based on security. We used the CVE Details website to research the known vulnerabilities against runtimes and their different versions. We learned how libraries and dependencies could introduce vulnerabilities into our serverless functions. The likelihood a dependency introduces a vulnerability increases with the size of the dependency tree. We used dependency tree tools and vulnerability checker tools to assess our libraries and dependencies. We discussed how static code analysis tools and unit and regression tests could improve the security of the serverless application. We used static code analysis tools

63

Chapter 3

Securing the Code

to catch typical programming and security mistakes. We can adapt unit and regression tests to test invalid inputs and deviate from the workflows to help identify security weaknesses. We discussed the importance of input validation in serverless functions. We learned several events that trigger serverless functions and how they each have different data structures. We reviewed two input source and input validation techniques. In the next chapter, we will explore how to secure the interfaces to your serverless application.

N  otes 1. “Visualization of npm dependencies.” Anvaka. https://npm. anvaka.com 2. “Apache Maven Dependency Plugin – Introduction.” Apache Maven Project. https://maven.apache.org/plugins/mavendependency-plugin/index.html 3. “Bundler.” Bundler. https://bundler.io 4. “DependencyWalker.Net.” GitHub. https://github.com/ isindicic/DependencyWalker.Net 5. “depth.” GitHub. https://github.com/KyleBanks/depth 6. “Get started with build scans.” Gradle Enterprise. https://scans. gradle.com 7. “Why NDepend.” NDepend. www.ndepend.com 8. “piptree.” PyPI. https://pypi.org/project/pipdeptree 9. “bundler-audit.” GitHub. https://github.com/rubysec/ bundler-audit 10. “dependency-check.” PyPI. https://pypi.org/project/ dependency-check 11. “npm-audit.” npm Documentation. https://docs.npmjs.com/ cli/audit

64

Chapter 3

Securing the Code

12. “Audit.NET.” GitHub. https://github.com/OSSIndex/audit.net 13. “ossindex-gradle-plugin.” GitHub. https://github.com/ OSSIndex/ossindex-gradle-­plugin 14. “Welcome.” Sonatype OSS Index: Maven. https://sonatype. github.io/ossindex-maven 15. “OWASP Dependency Check.” OWASP. ­www.owasp.org/ index.php/OWASP_Dependency_Check 16. “safety.” GitHub. https://github.com/pyupio/safety 17. “Open Source Security Platform.” Snyk. https://snyk.io 18. “Software Composition Analysis for DevSecOps.” SourceClear. www.sourceclear.com 19. “Bandit.” GitHub. https://github.com/PyCQA/bandit 20. “Pylint.” GitHub. https://github.com/PyCQA/pylint 21. “ESLint.” GitHub. https://github.com/eslint/eslint 22. “Fix issues before they exist.” sonarlint. www.sonarlint.org 23. “Code Quality and Security.” sonarqube. www.sonarqube.org 24. “Using AWS Lambda with Alexa.” AWS Lambda Developer Guide. Amazon Web Services. https://docs.aws.amazon.com/lambda/ latest/dg/services-alexa.html 25. “Using AWS Lambda with Amazon API Gateway.” AWS Lambda Developer Guide. Amazon Web Services. https://docs.aws. amazon.com/lambda/latest/dg/with-on-­demand-https.html 26. “Using AWS Lambda with CloudFront Lambda@Edge.” AWS Lambda Developer Guide. Amazon Web Services. https://docs. aws.amazon.com/lambda/latest/dg/lambda-edge.html 27. “Using AWS Lambda with Amazon CloudWatch Events.” AWS Lambda Developer Guide. Amazon Web Services. https://docs.aws.amazon.com/lambda/latest/dg/ with-­scheduled-­events.html

65

Chapter 3

Securing the Code

28. “Using AWS Lambda with Amazon CloudWatch Logs.” AWS Lambda Developer Guide. Amazon Web Services. https://docs.aws.amazon.com/lambda/latest/dg/ services-cloudwatchlogs.html 29. “Using AWS Lambda with Amazon Cognito.” AWS Lambda Developer Guide. Amazon Web Services. https://docs.aws. amazon.com/lambda/latest/dg/services-­cognito.html 30. “Using AWS Lambda with Amazon DynamoDB.” AWS Lambda Developer Guide. Amazon Web Services. https://docs.aws. amazon.com/lambda/latest/dg/with-ddb.html 31. “Using AWS Lambda with Amazon Kinesis.” AWS Lambda Developer Guide. Amazon Web Services. https://docs.aws. amazon.com/lambda/latest/dg/with-kinesis.html 32. “Using AWS Lambda with Amazon Kinesis Data Firehose.” AWS Lambda Developer Guide. Amazon Web Services. https://docs.aws.amazon.com/lambda/latest/dg/ services-kinesisfirehose.html 33. “Using AWS Lambda with Amazon Lex.” AWS Lambda Developer Guide. Amazon Web Services. https://docs.aws.amazon.com/ lambda/latest/dg/services-lex.html 34. “Using AWS Lambda with Amazon SES.” AWS Lambda Developer Guide. Amazon Web Services. https://docs.aws.amazon.com/ lambda/latest/dg/services-ses.html 35. “Using AWS Lambda with Amazon SNS.” AWS Lambda Developer Guide. Amazon Web Services. https://docs.aws.amazon.com/ lambda/latest/dg/with-sns.html 36. “Using AWS Lambda with Amazon SQS.” AWS Lambda Developer Guide. Amazon Web Services. https://docs.aws.amazon.com/ lambda/latest/dg/with-sqs.html

66

Chapter 3

Securing the Code

37. “Using AWS Lambda with Amazon S3.” AWS Lambda Developer Guide. Amazon Web Services. https://docs.aws.amazon.com/ lambda/latest/dg/with-s3.html 38. “Using AWS Lambda with AWS CloudFormation.” AWS Lambda Developer Guide. Amazon Web Services. https://docs.aws. amazon.com/lambda/latest/dg/services-­cloudformation.html 39. “Using AWS Lambda with AWS CodeCommit.” AWS Lambda Developer Guide. Amazon Web Services. https://docs.aws. amazon.com/lambda/latest/dg/services-­codecommit.html 40. “Using AWS Lambda with AWS Config.” AWS Lambda Developer Guide. Amazon Web Services. https://docs.aws.amazon.com/ lambda/latest/dg/services-config.html 41. “Using AWS Lambda with an Application Load Balancer.” AWS Lambda Developer Guide. Amazon Web Services. https://docs.aws.amazon.com/lambda/latest/dg/ services-alb.html 42. “Azure Blob storage bindings for Azure Functions.” Azure Functions documentation. Microsoft. ­https://docs.microsoft. com/en-us/azure/azure-functions/functions-­bindings-­ storage-blob 43. “Azure Cosmos DB bindings for Azure Functions 1.x.” Azure Functions documentation. Microsoft. https://docs.microsoft. com/en-us/azure/azure-functions/functions-bindingsdocumentdb 44. “Event Grid trigger for Azure Functions.” Azure Functions documentation. Microsoft. https://docs.microsoft.com/en-us/ azure/azure-functions/functions-bindings-event-­grid 45. “Azure Event Hubs bindings for Azure Functions.” Azure Functions documentation. Microsoft. https://docs.microsoft.com/en-us/ azure/azure-functions/functions-­bindings-­event-hubs

67

Chapter 3

Securing the Code

46. “Azure Functions HTTP triggers and bindings.” Azure Functions documentation. Microsoft. https://docs.microsoft.com/en-us/ azure/azure-functions/functions-­bindings-­http-webhook 47. “Microsoft Graph bindings for Azure Functions.” Azure Functions documentation. Microsoft. https://docs.microsoft.com/en-us/ azure/azure-functions/functions-­bindings-­microsoft-graph 48. “Azure Queue storage bindings for Azure Functions.” Azure Functions documentation. Microsoft. https://docs.microsoft. com/en-us/azure/azure-functions/functions-bindingsstorage-queue 49. “Azure Service Bus bindings for Azure Functions.” Azure Functions documentation. Microsoft. https://docs.microsoft.com/en-us/ azure/azure-functions/functions-­bindings-­service-bus 50. “Timer trigger for Azure Functions.” Azure Functions documentation. Microsoft. https://docs.microsoft.com/en-us/ azure/azure-functions/functions-bindings-timer 51. “Google Cloud Storage Triggers.” Google Cloud Functions Documentation. Google. https://cloud.google.com/ functions/docs/calling/storage 52. “Google Cloud Pub/Sub Triggers.” Google Cloud Functions Documentation. Google. https://cloud.google.com/ functions/docs/calling/pubsub 53. “Google Cloud Firestore Triggers.” Google Cloud Functions Documentation. Google. https://cloud.google.com/ functions/docs/calling/cloud-firestore 54. “Firebase Realtime Database Triggers.” Google Cloud Functions Documentation. Google. https://cloud.google.com/ functions/docs/calling/realtime-database 55. “Google Analytics for Firebase Triggers.” Google Cloud Functions Documentation. Google. https://cloud.google.com/ functions/docs/calling/google-analytics-firebase

68

Chapter 3

Securing the Code

56. “Firebase Authentication Triggers.” Google Cloud Functions Documentation. Google. https://cloud.google.com/ functions/docs/calling/firebase-auth 57. “HTTP Triggers.” Google Cloud Functions Documentation. Google. https://cloud.google.com/functions/docs/ calling/http 58. “Second-Party Triggers with Stackdriver.” Google Cloud Functions Documentation. Google. https://cloud.google.com/ functions/docs/calling/logging

69

CHAPTER 4

Securing Interfaces In this chapter, we will review the function triggers and provide a use case for each. We will discuss how to identify the different interfaces defined in the Serverless configuration file and function code.

Importance of Securing Interfaces Every interface exposes the application to receiving and sending data. The data might be sensitive or not. Another party might intercept the data when moving the data from at rest to in transit. An interface is a connection where information is exchanged between two parties, services or systems, and thus makes the data vulnerable to potential interception. Therefore, we need to identify the interfaces and potential vulnerabilities to determine how to secure the interfaces. There are two major categories of interfaces: internal and external. When the application communicates with itself, this interface is internal. When the application communicates with another application or system, this interface is external. Typically, an internal interface is less vulnerable because there is a certain level of trust. Some systems implement no security for internal interfaces because all internal components are assumed to be secure and not a threat. Cybersecurity incidents like the Stuxnet computer worm that targeted the Iranian nuclear facilities1 highlighted the importance of implementing security for all interfaces, even internal ones. Coincidentally around the same time as the Stuxnet incident, the zero-trust2 security concept was birthed and primarily emphasizes trusting nothing in the systems, whether internal or external. Therefore, we will explore how to identify interfaces to the application and how to secure them. “ What is Stuxnet?” McAfee. McAfee, LLC. www.mcafee.com/enterprise/en-us/securityawareness/ransomware/what-is-stuxnet.html 2 “What is Zero Trust? A model for more effective security.” Mary K. Pratt. CSO Online. 16 January 2018. www.csoonline.com/article/3247848/what-is-zero-trust-a-model-for-moreeffective-security.html 1

© Miguel A. Calles 2020 M. Calles, Serverless Security, https://doi.org/10.1007/978-1-4842-6100-2_4

71

Chapter 4

Securing Interfaces

Understanding Interfaces and Use Cases Before we review how to identify the interfaces, we should examine why the interfaces exist. Every application is built with a different use case, as we established in Chapter 2. Internal and external interfaces will exist depending on the application. Therefore, we should understand why those interfaces exist before we can assess the security implications of those interfaces. We will review the interfaces AWS, Azure, and Google Cloud provide and use cases for why they might exist. We consider interfaces as internal when both sides are within the same provider and same account. We consider them external if one side is on a different account or a different provider. These providers have a Software Development Kit (SDK) or software library that a function can use to interface with its services. These libraries use a request-response pattern, where a call using the library sends an HTTP(S) (i.e., HTTP or HTTPS) request to the service. The service acts per the request and sends a response to the library. The library captures any success and error data and invokes any asynchronous callback function specified in the request code. We review how a function interfaces with internal services via event triggers and internal requests using a library. We will also discuss why interfaces outside of AWS, Azure, and Google Cloud might exist and possible use cases. This review will guide you in starting a critical analysis of the internal and external interfaces in your application and their use cases.

Amazon Web Services (AWS) An AWS Lambda function interfaces with other AWS services via event triggers or the AWS SDK. The AWS SDK provides an interface to almost 200 AWS services.3 We will review each of the event triggers in more detail and give an example of how to identify interfaces via the AWS SDK.

“ AWS SDK for JavaScript.” Amazon Web Services. https://docs.aws.amazon.com/ AWSJavaScriptSDK/latest/index.html

3

72

Chapter 4

Securing Interfaces

AWS Lambda Event Triggers We will review each of the event triggers and provide a use case. •

Amazon Alexa Skills Kit and Alexa Smart Home allow a user to issue a verbal command to Alexa-enabled devices and interact with it. You might use a skill to trigger a Lambda function to provide a contextual response rather than a static response.

•

Amazon API Gateway (i.e., HTTP) provides an HTTP interface to Lambda functions. You might use API Gateway to allow a web application, a mobile app, or another system to make an HTTP request to trigger a Lambda function and get the desired response.

•

Amazon CloudFront (Lambda@Edge) is a Content Delivery Network (CDN) that speeds up the content delivery time. You might use CloudFront’s Lambda@Edge to trigger a Lambda function to transform CDN content before it is delivered. For example, it can update a token with a value when retrieving a static web page or insert security headers.

•

Amazon CloudWatch captures logs in log groups and monitors AWS events. •

Amazon CloudWatch captures events emitted by other AWS services4 and triggers a Lambda function with the event information. You might use a CloudWatch event to trigger a Lambda function to create a database record or send a notification to stakeholders when a virtual machine running on AWS is shut down.

•

Amazon CloudWatch uses streams to trigger Lambda functions when those Lambda functions subscribe to a CloudWatch log group it has a new log entry. You might use a CloudWatch log stream to trigger a Lambda function to store CloudWatch log data in a different service or format.

“ CloudWatch Events Event Examples From Supported Services.” Amazon CloudWatch Events User Guide. Amazon Web Services. https://docs.aws.amazon.com/AmazonCloudWatch/latest/ events/EventTypes.html

4

73

Chapter 4

Securing Interfaces

•

Amazon Cognito provides user authentication and access control and integrates with other identity and access management systems. A Cognito User Pool is a user credential data store that securely stores user login information and defines the access privileges to AWS services. Cognito User Pools trigger5 Lambda functions when a user signs up and authenticates. You might use a Cognito User Pool to trigger a Lambda function to validate user metadata is complete and valid before finishing the registration process.

•

Amazon DynamoDB is a database designed for large data sets of unstructured or semistructured schemas (i.e., Not Only Structured Query Language [NoSQL] data). DynamoDB uses streams to send events to Lambda functions when its data tables are updated. You might use DynamoDB to trigger a Lambda function to create a change record when a user updates their profile, and that action updates the associated table.

•

Amazon Kinesis supports ingesting large amounts of data into a stream and sending it to its subscribers in real time. It supports text, images, and videos. You might use Kinesis to trigger a Lambda function to analyze text and apply metadata whenever the stream receives data.

•

Amazon Lex allows you to build voice and text chatbots. You might use a Lex to trigger a Lambda function to validate or fulfill a command a user has sent to a bot before the bot responds.

•

Amazon Simple Email Service (SES) allows you to send and receive emails. You might use SES to trigger a Lambda function to update an order from pending to approved when a user sends an email accepting an order.

“ Customizing User Pool Workflows with Lambda Triggers.” Amazon Cognito Developer Guide. Amazon Web Services. https://docs.aws.amazon.com/cognito/latest/developerguide/ cognito-user-identity-pools-working-with-aws-lambda-triggers.html

5

74

Chapter 4

Securing Interfaces

•

Amazon Simple Notification Service (SNS) is a messaging service where you publish event data, and other functions and services subscribe to receive it. You organize and group SNS data into topics, similar to how you might structure a web discussion forum. You might use an SNS topic to trigger a Lambda function to update a database record. It would set an entry to an archived status when moving its associated file into long-term storage.

•

Amazon Simple Queue Service (SQS) collects messages from input sources (e.g., SNS topic messages) and organizes them into queues. SQS sends messages from the queue and guarantees a message is delivered at least one time. You might use an SQS queue to trigger a Lambda function to process SNS events in batches.

•

Amazon Simple Storage Service (S3) provides remote file storage and security features (e.g., file encryption, versioning, and access control). You use an S3 bucket to store the remote files. You might use S3 to trigger a Lambda function to catalog a file uploaded to an S3 bucket.

•

AWS CloudFormation uses templates to create several resources (e.g., networking, functions, storage, and more). You might use CloudFormation to trigger a Lambda function to get the information required by the CloudFormation template while it is creating resources.

•

AWS CodeCommit provides source control for capturing your source code and files and change history into repositories. You might use CodeCommit to trigger a Lambda function to start an internal process when code is committed to the source code repository.

•

AWS Config enables you to audit your existing AWS resource configuration against the target configuration by using rules. It provides change history and notifications when a change is detected. You might use Config to trigger a Lambda function to resize a virtual machine. Config might send an event notifying a newly created virtual machine is larger than the maximum size.

75

Chapter 4

Securing Interfaces

•

AWS EventBridge allows you to connect your application to other applications using events using event buses. AWS services send events to the default bus. AWS SaaS partners send an event to the SaaS event bus. Any custom applications send events to a custom event bus. You might want to use EventBridge to get event data from third-party SaaS applications in your application architecture (e.g., monitoring software and a custom SaaS application created by another team within the organization).

•

AWS IoT enables you to connect several Internet of Things (IoT) devices (thermostats, cars, sensors, machinery, you name it) to AWS for management, monitoring, analysis, and more. You can define rules to trigger a Lambda function when a query returns valid data. You might create a rule to monitor errors reported from IoT devices. Your Lambda function will send a push notification to the on-site representative notifying the IoT device owner about the issue.

•

Elastic Load Balancing distributes application or network layer6 traffic among different servers and Lambda functions. A Network Load Balancer (NLB) redirects traffic based on the network protocol and port information. An Application Load Balancer (ALB) redirects based on the HTTP(S) request information. ALBs can trigger Lambda functions, but not NLBs. You might use an ALB to trigger a Lambda function to update a firewall to block the requestor’s IP address whenever it makes an HTTP request to a honeypot web address.

•

Scheduled events allow you to automatically trigger a Lambda function by specifying a Command Run On (CRON) expression or a trigger rate. You might want to trigger a Lambda function at midnight every day to create a sales report or every 10 minutes to status orders.

“ Information technology – Open Systems Interconnection – Basic Reference Model: The Basic Model.” ISO/IEC 7498-1:1994(E). Second edition. © 1994 ISO/IEC.

6

76

Chapter 4

Securing Interfaces

AWS Interfaces via the AWS Software Development Kit (SDK) Lambda functions can use the AWS Software Development Kit (SDK)7 to interface with the different AWS services and resources. You might use the AWS SDK to query a DynamoDB table to get account data or trigger another Lambda function. As you review the AWS SDK documentation, you will find the use cases are numerous.

A  zure An Azure Function interfaces with other Azure services via bindings or the Azure SDK. Azure Functions use the concept of bindings to define how they are triggered and what built-in interfaces they can use. The Azure SDK provides an interface to over 100 Azure services.8 We will review each of the bindings in more detail and provide an example of how to identify interfaces via the Azure SDK.

Azure Function Bindings A trigger is a binding that triggers the Azure Function. An Azure Function also has input and output bindings from the Azure services with which it interfaces. An input binding specifies that the service sends data to the function. For example, a file upload to the Azure Blob storage service can trigger an Azure Function, and it has input data containing the information about the file upload. An output binding specifies that the function sends data to the service. For example, an HTTP request can trigger an Azure Function to send output data (i.e., an HTTP response). Table 4-1 lists the bindings Azure Functions support.

“ Tools & SDKs.” Amazon Web Services. https://aws.amazon.com/developer/tools “Azure SDK for Node.” Microsoft. GitHub. https://github.com/Azure/azure-sdk-for-node/ tree/master/lib/services

7 8

77

Chapter 4

Securing Interfaces

Table 4-1.  Microsoft Azure Input and Output Bindings Binding Type

Function Trigger

Input

Output

Azure Blob storage

Yes

Yes

Yes

Azure Cosmos DB

Yes

Yes

Yes

Azure Event Grid

Yes

No

No

Azure Event Hubs

Yes

No

Yes

Azure IoT Hub

Yes

No

Yes

Azure Mobile Apps

No

Yes

Yes

Azure Notification Hubs

No

No

Yes

Azure Queue storage

Yes

No

Yes

Azure Service Bus

Yes

No

Yes

Azure SignalR Service

No

Yes

Yes

Azure Table storage

No

Yes

Yes

HTTP and Webhooks

Yes

No

Yes

Microsoft Graph

Yes†

Yes†

Yes†

Timer

Yes

No

No

Twilio

No

No

Yes

Twilio SendGrid9

No

No

Yes

Only Microsoft Graph Events support trigger, input, and output bindings. The other Microsoft Graph interfaces support input, output, or both bindings. Note: This table was derived from the Microsoft documentation.10

†

“Twilio” and “SendGrid” are registered trademarks of Twilio and/or its affiliates. “Azure Functions triggers and bindings concepts.” Azure Functions Documentation. Microsoft. https://docs.microsoft.com/en-us/azure/azure-functions/ functions-triggers-bindings#supported-bindings

9

10

78

Chapter 4

Securing Interfaces

We will briefly review the functionality each service provides and gives an example of a use case. •

Azure Blob storage allows you to store a Binary Large Object (blob), which is a binary object like an image or a video. You use containers to store blobs and have it configured to trigger whenever creating or updating blobs. You might use Blob storage to trigger an Azure Function to catalog a file when updating a blob to the container.

•

Azure Cosmos DB is a fully managed database that supports different database APIs (e.g., Structured Query Language [SQL], Gremlin graph traversal language, MongoDB11 document database, Azure Table storage, and Apache Cassandra12). You might use Cosmos DB to trigger an Azure Function to query a database table for a specific record.

•

Azure Event Grid manages your application events. It allows your application to accept events from various publishers (i.e., sources) and route them to multiple destinations for processing. You might use Event Grid to trigger an Azure Function to process an image when uploading it to a Blob storage container.

•

Azure Event Hubs collects data from input sources and streams them to Azure Functions for processing. It supports multiple back-­ end systems of various programming languages, whether hosted on-premise or in the cloud. You might use Event Hubs to trigger an Azure Function to prepare data for real-time analytics.

•

Azure IoT Hub allows you to connect several Internet of Things (IoT) devices and establish a two-way communication. You might use IoT Hub to trigger an Azure Function to establish a keep-alive connection to the IoT device.

“ MongoDB” is a registered trademark of MongoDB, Inc. “Apache” and “Cassandra” are either a registered trademark or trademark of The Apache Software Foundation.

11 12

79

Chapter 4

80

Securing Interfaces

•

Azure Mobile Apps enables you to build Windows, iOS, and Android apps using the native platform or cross-platform solutions. It provides several integrations for cloud-based data storage, user authentication, push notifications, and enterprise systems. You might use an Azure Function to process data from an updated Mobile Apps data table when triggered by a queue message.

•

Azure Notification Hubs allows you to send push notifications to various devices (e.g., iOS, Android, and Windows). It uses Event Hubs to trigger the Azure Function. You might use an Azure Function to send a push notification to a mobile user when triggered by a queue message.

•

Azure Queue storage collects messages from input sources and sends them asynchronously to Azure Functions for processing. An input source adds messages to the queue by sending a request to the queue web address with the proper credential. You can store large numbers of messages in a queue. You might use Queue storage to trigger an Azure Function to process webhook data from a continuous integration pipeline.

•

Azure Service Bus is a message broker that supports queues and topics for publish/subscribe configurations. It provides additional messaging features (e.g., auto-forwarding, scheduled delivery, client-side batching, filtering) and security features (e.g., Role-Based Access Control [RBAC], Representational State Transfer [REST], and Advanced Message Queueing Protocol [AMQP]). You might use Service Bus to trigger an Azure Function to perform facial recognition from multiple image sources.

•

Azure SignalR abstracts the protocols used in real-time data updates within web applications by utilizing technologies (e.g., WebSockets) to transmit data to a web application without it needing to poll for updates. You might use an Azure Function to authenticate the SignalR connection from a web-based chat room. The Azure Function might send the appropriate data response to the chat room when triggered by an HTTP request.

Chapter 4

Securing Interfaces

•

Azure Table storage is a database designed for large data sets with unstructured or semistructured schemas (i.e., NoSQL data). You can easily scale your application due to the flexible schema. You might use an Azure Function to query an entry from an Azure Table storage data table when triggered by an HTTP request.

•

HTTP and Webhooks provides an HTTP interface to Azure Functions. You might use an HTTP interface to allow a web application, a mobile app, or another system to make an HTTP request and to trigger an Azure Function to get the desired response.

•

Microsoft Graph provides an API for integrating with the following Microsoft services: Azure AD (Active Directory), Excel, Intune, Outlook, OneDrive, OneNote, SharePoint, and Planner. You might use Microsoft Graph to trigger an Azure Function to keep an audit record when an Outlook calendar entry was modified.

•

Timers allow you to specify a CRON expression to trigger an Azure Function automatically. You might want to trigger an Azure Function at midnight every day to prepare the morning shipments.

•

Twilio is a non-Microsoft (or external) service for sending Simple Messaging Service (SMS) text messages to a mobile phone number. You might use an Azure Function to send an SMS to a user when an order has shipped when triggered by a queue message.

•

Twilio SendGrid is a non-Microsoft (or external) service for sending email messages. You might use an Azure Function to send an email message to a user when that user’s password was recently changed when triggered by a queue message.

Azure Interfaces via the Azure SDK Azure Functions can use the Azure Software Developer Kit (SDK)13 to interface with the different Azure services and resources. You might use the Azure SDK to create an Azure Blob storage container. As you review the Azure SDK documentation, you will find numerous use cases are possible. “ Azure Developer Tools.” Microsoft Azure. Microsoft. https://azure.microsoft.com/en-us/ tools/

13

81

Chapter 4

Securing Interfaces

G  oogle Cloud A Google Cloud Function interfaces with other Google Cloud services via event triggers or the Google Cloud Client Libraries. The Google Cloud Client Libraries provide interfaces to over 100 Google Cloud services.14 We will review each of the event triggers in more detail and provide an example of how to identify interfaces via the Google Cloud Client Libraries.

Google Cloud Function Event Triggers We will review each of the event triggers and provide a use case. •

Firebase Authentication uses an SDK that provides user authentication to many types of clients (e.g., Android and iOS mobile clients and web clients). It enables users to create an account and log in using an email address and password or to sign in using a federated identity provider. You might use Firebase Authentication to trigger a Cloud Function to record the details of a newly created account.

•

Firebase Crashlytics provides crash reports and real-time crash alerts when your mobile app experiences a crash. You can get insights into the crash and whether multiple users are affected. You might use Firebase Crashlytics to trigger a Cloud Function to send an email to the development team when a new mobile app crash is detected.

•

Firebase Realtime Database is a fully managed NoSQL database. It provides data storage and data synchronization to Android, iOS, and JavaScript clients using its Software Development Kit (SDK). It stores all data in JavaScript Object Notation (JSON) format. Also, it provides offline support for mobile and web clients for when they experience network latency or Internet connectivity issues. You mainly use this database for real-time data synchronization across all clients. You might use Firebase Realtime Database to trigger a Cloud Function to synchronize the application database when the realtime database is updated.

“ Google API Node.js Client.” Google. https://googleapis.dev/nodejs/googleapis/latest/ index.html

14

82

Chapter 4

Securing Interfaces

•

Firebase Remote Config allows you to update your Android and iOS mobile apps without publishing an app update. You define default values that you can override at any time. Your users will get the overridden values because the app can frequently check for the updated values. You might use Firebase Remote Config to trigger a Cloud Function to create an audit record when there is a configuration update.

•

Firebase Test Lab allows you to test your Android and iOS mobile apps on actual devices stored in Google’s data centers. You write your tests using any of the supported test frameworks, schedule the test, and Firebase Test Lab will configure physical phones to run it. You might use Firebase Test Lab to send an email to the development team when a test fails.

•

Google Analytics for Firebase analyzes user events in Android and iOS apps using Firebase. The analysis provides insight into user behaviors, activity, and demographics. It can also provide insights into software crashes and log events when integrated with other Google services. You might use Google Analytics for Firebase to trigger a Cloud Function to update the sales report when a user makes an in-app purchase.

•

Google Cloud Endpoints provides API Management for your application. You define your API and use that definition to create the API endpoints. Having an API endpoint allows you to monitor usage and authorize access with user authentication and API keys. You might use Google Cloud Endpoints to trigger a Cloud Function from an HTTP request authenticated and verified by an API gateway.

•

Google Cloud Firestore is a fully managed, flexible NoSQL database. It provides data storage and data synchronization to mobile and web clients and servers. Its data model is flexible and not limited to the JSON format. It also provides offline support and the ability to query the data. You might use Google Cloud Firestore to trigger a Cloud Function to fix typos and convert all text to uppercase when a user updates their user profile.

83

Chapter 4

84

Securing Interfaces

•

Google Cloud Scheduler allows you to automatically trigger a Google Cloud Function by scheduling an operation managed by a CRON job scheduler. You might want to trigger a Cloud Function every morning to send daily promotion emails.

•

Google Cloud Storage allows you to store files in a storage bucket. The client application will upload the user files into the bucket, which makes them accessible to the servers for processing. The client SDK can pause and continue uploads and downloads depending on the network connectivity. You might use Google Cloud Storage to trigger a Cloud Function to update all database references to a file when deleted.

•

Google Cloud Tasks allow you to schedule tasks to execute asynchronously, immediately, or at a scheduled time. The tasks can trigger any HTTP target and have retry logic when a task fails to complete. You might use Google Cloud Tasks to trigger a Cloud Function that is time-consuming (i.e., longer than 30 seconds) and send the result back to the application which created the Cloud Task.

•

Google Cloud Pub/Sub allows you to ingest events from data sources and distribute them to data targets, possibly with security features (e.g., end-to-end encryption and access control). You might use Google Cloud Pub/Sub to trigger a Cloud Function to process data from various types of IoT devices.

•

Cloud Logging allows you to store your logs from Google Cloud and AWS events. You can search and analyze the stored logs and configure it to alert you when a log event matches specified criteria. It needs Google Cloud Pub/Sub and a Cloud Logging sink to trigger a Cloud Function. You might use Cloud Logging to trigger a Cloud Function to create metric data based on security log events.

•

HTTP provides an HTTP interface to Cloud Functions. You might use an HTTP interface to trigger a Cloud Function to allow a web application, a mobile app, or another system to make an HTTP request to that function and get the desired response.

Chapter 4

Securing Interfaces

Google Cloud Interfaces via Google Cloud Client Libraries Google Cloud Functions can use the Google Cloud Client Libraries15 to interface with different Google Cloud services and resources. You might use the Google Cloud Client Libraries to create a Google Cloud Storage bucket. As you review the Google Cloud Client Libraries documentation, you will find there are a lot of use cases.

External Interfaces and Use Cases The functions might interface with services outside of the cloud provider. That interface might be based on a direct HTTP request or may use an npm package or third-party SDK. You might want to use an external interface to accept and receive payments via a payment processor. As you inspect the code, you can identify which functions interface with external systems. Each external system will have some documentation for you to review.

I dentifying the Interfaces We will review how to identify the existence of internal and external interfaces within the application. In Chapter 2, we discussed how to identify interfaces by reviewing documentation and how to identify event triggers based on the Serverless configuration file. We will now review more concrete examples of how to identify the interfaces.

Serverless Configuration File We will review examples of how an interface is defined in the Serverless configuration file. For example, we can identify from the “serverless.yml” configuration file shown in Listing 4-1 that four Lambda functions have HTTP event triggers from the API Gateway.

“ Google Cloud Client Libraries.” Google Cloud APIs. Google. https://cloud.google.com/apis/ docs/cloud-client-libraries

15

85

Chapter 4

Securing Interfaces

Listing 4-1.  Sample Serverless Configuration with HTTP Event Triggers16 functions:   functionAuthorizer:     handler: src/authorizer.handler   function1:     handler: src/function1.handler     events:       - http: GET hello/world   function2:     handler: src/function2.handler     events:       - http:           path: hello/country           method: post   function3:     handler: src/function3.handler     events:       - http:           path: hello/state           method: put           cors:             origins:               - http://*.website1.com               - https://website2.com             headers:               - Content-Type               - X-Amz-Date               - Authorization               - X-Api-Key               - X-Amz-Security-Token               - X-Amz-User-Agent

 he Serverless configuration was derived from the Serverless Framework documentation. T “API Gateway.” Serverless Documentation. https://www.serverless.com/framework/docs/ providers/aws/events/apigateway/. “Serverless.yml Reference.” Serverless Documentation. https://www.serverless.com/framework/docs/providers/aws/guide/serverless.yml/.

16

86

Chapter 4

Securing Interfaces

            allowCredentials: false             maxAge: 86400             cacheControl: 'max-age=600, s-maxage=600'           private: true           authorizer:             name: functionAuthorizer             resultTtlInSeconds: 0             identitySource: method.request.header.Auth             identityValidationExpression: ^Bearer .*             type: token   function4:     handler: src/function4.handler     events:       - http:           path: hello/city           method: post           integration: lambda           request:             template:               # A query string of ?key=value in the URL               # is accessible in the Lambda as               # event.queryStringParameter               application/json: '{                 "httpMethod" : "$context.httpMethod",                 "queryStringParameter" : "$input.params(''key'')"                 }'           response:             headers:               Content-Type: "'text/plain'"               Cache-Control: "'max-age=120'"             template: $input.path('$')             statusCodes:               201:                 pattern: ''               404:                 pattern: '.*"statusCode":409,.*' 87

Chapter 4

Securing Interfaces

                template:                   application/json: $input.path("$.errorMessage")                 headers:                   Content-Type: "'application/json+hal'" As we review the Serverless documentation,17 we learn the Serverless configuration file supports two integration types (i.e., Lambda Proxy and Lambda) when triggering a Lambda function over an HTTP request. You will normally see the Lambda Proxy integration because Serverless preconfigures the request and response structures. The Lambda integration is useful when you want to customize the request and response structures, though this requires more configuration settings. You can define a Lambda Proxy integration by adding one line to the event settings. The “function1” function configuration shows how to define an HTTP GET request to “https://.execute-api..amazonaws.com//hello/ world” that triggers the function; see Listing 4-2.

Listing 4-2.  Sample Lambda Proxy Integration in the Serverless Configuration   function1:     handler: src/function1.handler     events:       - http: GET hello/world The “function2” function configuration becomes more explicit. It defines an HTTP POST request to “https://.execute-api..amazonaws. com//hello/country” that triggers the function; see Listing 4-3.

Listing 4-3.  Sample Lambda Proxy Integration in the Serverless Configuration   function2:     handler: src/function2.handler     events:       - http:           path: hello/country           method: post

“ API Gateway.” Serverless Docs. https://serverless.com/framework/docs/providers/aws/ events/apigateway/

17

88

Chapter 4

Securing Interfaces

The “function3” function configuration shows the different options available to configure the trigger; see Listing 4-4. The configuration •

Enables Continuously Operating Reference Station (CORS) and •

Allows HTTP requests originating from any subdomain of website.com

•

Allows HTTPS requests originating from the website.com domain

•

Has required headers

•

Does not allow cookies, authorization headers, or TLS client certificates

•

Has a max-age of 86,400 seconds

•

Caches the content on the browser and proxy server for 600 seconds

•

Requires an API key

•

Uses an authorizer that •

Uses the “functionAuthorizer” function as its authorizer

•

Gives the authorization a time to live of zero seconds

•

Requires the “Auth” header name that matches the “^Bearer .*” regular expression

•

Is an authorization token

Listing 4-4.  Sample Lambda Proxy Integration in the Serverless Configuration   function3:     handler: src/function3.handler     events:       - http:           path: hello/state           method: put           cors:             origins:               - http://*.website1.com               - https://website2.com 89

Chapter 4

Securing Interfaces

            headers:               - Content-Type               - X-Amz-Date               - Authorization               - X-Api-Key               - X-Amz-Security-Token               - X-Amz-User-Agent             allowCredentials: false             maxAge: 86400             cacheControl: 'max-age=600, s-maxage=600'           private: true           authorizer:             name: functionAuthorizer             resultTtlInSeconds: 0             identitySource: method.request.header.Auth             identityValidationExpression: ^Bearer .*             type: token You can define the Lambda integration by specifying it in the function configuration. We will not review this integration in full detail because of its more complex manual configuration. Serverless, Inc. recommends to use the Lambda Proxy integration, but I suggest you explore the documentation especially if your development team has chosen this integration. The “function4” function configuration shows the Lambda integration. In another example, we can identify from the configuration file shown in Listing 4-5 that two Lambda functions have S3 event triggers from two S3 buckets.

Listing 4-5.  Sample Serverless Configuration with S3 Event Triggers18 functions:   function5:     handler: src/function1.handler     events:       # create a new S3 bucket

 he Serverless configuration was derived from the Serverless Framework documentation. “S3.” T Serverless Documentation. https://www.serverless.com/framework/docs/providers/aws/ events/s3/

18

90

Chapter 4

Securing Interfaces

      - s3:           bucket: ${self:service}-${self:provider.stage}-products           event: s3:ObjectCreated:*           rules:             - prefix: new/             - suffix: .jpg   function6:     handler: src/function2.handler     events:       # use an existing S3 bucket       - s3:           bucket: ${self:service}-${self:provider.stage}-legacy           event: s3:ObjectRemoved:*           existing: true As we review the Serverless documentation,19 we learn the Serverless configuration file allows you to create an S3 bucket from the Serverless deployment or using an existing S3 bucket. You can configure the Lambda functions to trigger from specific S3 events. The “function5” function configuration will create a new bucket and will trigger the Lambda function when creating a new S3 object (i.e., file) in that bucket. The object key (i.e., path and filename) begins with “new/” and ends with “.jpg.” For example, when the application uploads a file to the S3 bucket with a “new/profile-picture/b210c69f-c436-­ 4afe-bf02-14eff40bc7fa.jpg” object key, S3 emits an event and the Lambda function triggers with the event information. The “function6” function configuration uses an existing bucket and triggers the Lambda function when removing any S3 objects. You can find additional examples in the “chapter04” folder.

F unction Code Now let’s review examples of how the function code defines an interface. The function code can use an SDK or a direct HTTP request to interact with internal and external interfaces, as discussed earlier. For example, the AWS Lambda function code can interface with DynamoDB using the AWS SDK. You may see code similar to Listing 4-6, which makes a query to DynamoDB.

“S3.” Serverless Docs. https://serverless.com/framework/docs/providers/aws/events/s3/

19

91

Chapter 4

Securing Interfaces

Listing 4-6.  Sample Node.js Code Interfacing with DynamoDB const AWS = require('aws-sdk'); const dynamodb = new AWS.DynamoDB(); module.exports.handler = (event, context, callback) => {     const params = {         TableName: process.env.TABLE_NAME,         ExpressionAttributeValues: {             ':id': {                 S: process.env.ACCOUNT_ID,             }         },         KeyConditionExpression: 'AccountId = :id',     };     return dynamodb.query(params).promise()         .then((data) => {             console.log(                 'Query results:',                 JSON.stringify(data),             );             callback();         })         .catch((error) => {             console.log(`Error: ${JSON.stringify(error)}`);             callback();         }); }; As we review the AWS SDK documentation, we learn that we create a DynamoDB object, which has functions to interface with the AWS DynamoDB service. Each function requires specific inputs, which we called “params” earlier, and responds with specific outputs, which we called “data” earlier. The “params” provides the DynamoDB table name with which this function interfaces and the query it is performing. In another example, the Azure Function code can interface with Azure Blob storage using the Azure SDK. You may see code resembling Listing 4-7, which creates a Blob storage container. 92

Chapter 4

Securing Interfaces

Listing 4-7.  Sample Node.js Code Interfacing with Azure Blob Storage const azure = require('azure-storage'); const blobService = azure.createBlobService(     process.env. AZURE_STORAGE_CONNECTION_STRING ); const containerName = process.env.NEW_CONTAINER_NAME; module.exports.hello = function (context, req) {     blobService.createContainerIfNotExists(         containerName,         (error, result, response) => {             console.log(`Response: ${JSON.stringify(response)}`);             if (error) {                 return console.log(error);             }             if (result) {                 return console.log(`Created container ${containerName}.`);             }             console.log(`Did not create container ${containerName}.`);             context.done();         }     ); } As we review the Azure SDK documentation, we learn the Azure Storage client library has functions to interface with the Azure Blob storage service. This Azure Function creates a container if it does not already exist. In another example, the Cloud Function code can interface with Google Cloud Storage using the Google Cloud Storage Client Library. You may see code like in Listing 4-8, which deletes a bucket.

Listing 4-8.  Sample Node.js Code Interfacing with Google Cloud Storage const {Storage} = require('@google-cloud/storage'); const storage = new Storage(); const bucket = storage.bucket('albums'); 93

Chapter 4

Securing Interfaces

exports.deleteBucket = (req, res) => {     const bucketName = req.query.name;     bucket.delete()         .then((data) => {             const apiResponse = data[0];             console.log(JSON.stringify(apiResponse));             res.send(`Delete bucket: ${bucketName}`);         })         .catch((error) => {             console.log(`Error: ${JSON.stringify(error)}`);         }); }; As we review the Google Cloud Libraries documentation, we learn the Google Cloud Storage Client Library has functions to interface with the Google Cloud Storage service. This Cloud Function attempts to delete a bucket. In another example, the Lambda function code interfaces with a third-party payment service using a direct HTTP request. You may see code as in Listing 4-9, which asks the payment merchant service to list all payment charges against that account.

Listing 4-9.  Sample Node.js Code Interfacing with an External Payment System const rp = require('request-promise'); module.exports.handler = (event, context, callback) => {     const options = {         uri: 'https://api.stripe.com/v1/charges',         method: 'GET',         headers: {             Authorization: `Bearer ${process.env.API_KEY}`         },     };     return rp(options)         .then((response) => {             console.log(response.data.length, 'transactions');         })

94

Chapter 4

Securing Interfaces

        .catch((error) => {             console.log('Error:', JSON.stringify(error));         }); }; As we review the payment processor documentation,20 we learn the merchant provides a Representational State Transfer (REST), which uses HTTP, to interface with its service. This AWS Lambda Function uses the “request-promise” npm package21 to form the HTTP request and process the HTTP response.

Assessing and Reducing the Attack Surface In Chapter 2, we reviewed two tables: Table 2-2 “Sample Function Listing” and Table 2-4 “Sample Threat Model Matrix.” In this section, we will use those tables as we review interfaces. Table 2-2 helped us organize the findings from our source code review. We identified the functions, runtime, entry points, and event triggers. We noted we could add columns identifying the external and internal interfaces. We can now add those columns or review the information we captured based on the information we discussed in this chapter. Table 2-4 helped us identify the assets, the threats against those assets, and the defense we used to protect against those threats. As we review each interface, we can reference the threat model to identify specific risks for each interface. You could update the function listing (based on Table 2-2) to include threats. You could update the threat model matrix (based on Table 2-4) to include the specific functions and interfaces. Or, you can create a new table that relates functions, interfaces, and threats as you see appropriate for your assessment. However, we will use the format previously defined in Table 2-2 with the appropriate columns in our example; see the updates in Table 4-2.

“ API Reference.” Stripe. https://stripe.com/docs/api “request-promise.” npm. www.npmjs.com/package/request-promise

20 21

95

Chapter 4

Securing Interfaces

Table 4-2.  Sample Function Listing with Interfaces and Threats Added Function Name Event Trigger(s)

Internal Interface(s)

External Interface(s) Threat(s)

login

HTTP

DynamoDB accounts table

N/A

Customer data exposed

verifyMfa

HTTP

DynamoDB accounts table

Third-party SMS service

Account hijacking

You will find the sample function listing now shows the new columns. It shows the same two sample functions with only the relevant columns displayed. It contains the sample interfaces based on the function’s purpose and the relevant sample threats from Table 2-4. We could have added proposed defenses or mitigations as well. Now that we have a format to capture our findings, we need a systematic approach for capturing the interfaces and assessing the attack surface. You can use any method that works best for you, your project, and your project schedule. We will review the Serverless configuration file and proceed with reviewing the function code as our approach. We defined several functions in Listings 4-1 and 4-5 in the Serverless configuration. We will review each example function. •

96

The “functionAuthorizer” function has no event triggers, which implies it is an internal function. We see “function3” references it as its authorizer. The API Gateway will trigger the authorizer first. If it responds with a success authorization, it will forward the HTTP request to “function3.” Otherwise, the API Gateway denies the HTTP request. When we review the function code, we will need to understand how it validates the authorization. Depending on the answers to the following questions, we will propose appropriate mitigations: •

Does it check a static key against a database entry? This creates an internal interface which might be vulnerable to an injection attack.

•

Does it use a regular expression to check the key? It might be susceptible to a Regular Expression Denial of Service (ReDoS).

Chapter 4

•

Securing Interfaces

Does it use a third-party service to verify a JavaScript Object Notation Web Token (JWT) claim? This creates an external interface that might need to be tuned to expire tokens based on the application requirements.

•

The “function1” function uses an HTTP trigger using the Lambda Proxy integration. We find it has no authorizer or API key defined, which means any agent can access it without restrictions. Although we see the Uniform Resource Locator (URL) path “hello/world” look benign, it might still disclose customer data or return environment variables containing sensitive information. An HTTP GET method might return data from a database query that defines an interface. If this function accepts query string parameters, it might allow a request to return numerous records, which extends the function execution time, thus increasing cost and the likelihood of a DoS attack. It may also result in long database execution time, potentially increasing costs and increasing response times for other functions accessing this database. We might propose the following risk mitigations: adding an authorizer, limiting data returned, limiting or preventing query strings, and restricting the function execution time.

•

The “function2” function uses an HTTP trigger using the Lambda Proxy integration. We find it has no authorizer or API key defined, which means any agent can post data without restrictions. Any agent can potentially add erroneous data to the system, increase database usage (thus defining an interface), perform injection attacks, or attempt a DoS attack with a large payload. We might propose the following risk mitigations: adding an authorizer, limiting the size of the payload, and restricting the function execution time.

•

The “function3” function uses an HTTP trigger using the Lambda Proxy integration. We find it requires both an API key and an authorizer for the function to trigger. The authorizer declaration specifies a JWT claim is needed. It implements Cross-Origin Resource Sharing (CORS) to mitigate against Cross-Site Scripting (XSS) attacks. It uses an HTTP PUT method, which is similar to an HTTP POST. We might propose the same mitigations as we would for “function3” less the need for an authorizer. 97

Chapter 4

Securing Interfaces

•

The “function4” function uses an HTTP trigger using the Lambda integration. It would behoove us to discuss with the development team why they chose this integration because it is more complex and avoids the use of authorizers. Instead, it uses request templates to validate the HTTP request at the API Gateway and deny passing the request to the function. We might propose moving to the Lambda Proxy integration in addition to any relevant recommendations from the “function 2” function.

•

The “function5” function uses the S3 object created events22 to trigger the function. This defines an internal interface to S3 that is active whenever a product image file is created, updated, or copied. When we review the function code, we will need to understand how to process the event.

•

•

Does it add the filename to the database record for that account? This defines a second interface.

•

Does it need to process update or copied events, or only first creation events? The function may unintentionally overwrite customer data if it processes an undesired event.

•

We might propose limiting the event to “s3:ObjectCreated:Post” to only process newly created objects and performing input sanitization on the filename to avoid a database injection attack that generates more data than expected.

The “function6” function uses S3 object removed events to trigger the function. This defines an external or internal interface depending on whether the existing bucket is from another application or created in another service from the same application. When we review the function code, we will need to understand how to process the event. •

Does it delete database records when the event is triggered? This defines a second interface and may result in the accidental deletion of data.

“ Configuring Amazon S3 Event Notifications.” Amazon Simple Storage Service Developer Guide. Amazon Web Services. https://docs.aws.amazon.com/AmazonS3/latest/dev/ NotificationHowTo.html

22

98

Chapter 4

Securing Interfaces

•

Does it need to process the most recently deleted object or the removal of an older version of the object? Removing an older version may invalidate the current data set even though it did not delete the current version.

•

We might propose limiting the event to “s3:ObjectRemoved:Delete” to only process the deletion of the object’s current version to avoid inadvertent data deletion and performing input sanitization on the filename to prevent a database injection attack that deletes more data than expected.

As you review the Serverless configuration files, you can use the preceding assessment as an example for identifying the different interfaces and risks and proposing risk mitigations to reduce the attack surface. We showed example interfaces defined in the function code in Listing 4-6 through Listing 4-10. We will review each example. •

Listing 4-6 defines an interface to DynamoDB and performs a query to a DynamoDB database table. The example shows a query against the same table and account, which prevents any injection attacks. Typically, this type of function will accept inputs from the HTTP URL, which has the account identifier or an HTTP query string. This function might be vulnerable to disclosing customer data if input data and the database query result in returning records for more than one user or user data from another user. That said, this code has a low likelihood of accidental disclosure because it requires the “AccountId” value to be an exact match (provided each account has a unique identifier). We might propose performing input validation on the account identifier and cross-checking the “AccountId” against the user session to confirm that the user is not accessing another user’s data.

•

Listing 4-7 defines an interface to Azure Blob storage and attempts to create a storage container. The example uses the same container name every time. This might be intentional if it runs on a timer to ensure the container is recreated if accidentally deleted. It behooves us to understand why a function is creating infrastructure rather than creating the infrastructure as part of the Serverless configuration 99

Chapter 4

Securing Interfaces

deployment or the Continuous Integration (CI) and Continuous Delivery (CD) pipeline. We might propose to move this capability to the CI/CD pipeline and not to accept any inputs to avoid creating unnecessary storage containers. •

Listing 4-8 defines an interface to Google Cloud Storage and attempts to delete a storage bucket. The example uses a query string parameter to determine the container name. This function can remove any bucket name. It behooves us to understand why a function is modifying infrastructure. We might propose to perform input validation to restrict deleting critical buckets or moving the deletion to an automated process that is not triggered by an HTTP event.

As you review the code for the different functions, you can use the preceding assessment as an example for identifying the various interfaces and risks and proposing risk mitigations to reduce the attack surface.

K  ey Takeaways In this chapter, we reviewed the different function event triggers for the AWS, Azure, and Google Cloud providers and discussed a use case for each event trigger. We examined how the function code can create interfaces to the AWS, Azure, Google Cloud, and external services using their respective SDKs and HTTP requests. We explored examples on how to identify the interfaces in the Serverless configuration file and function code, document any threats and risks, and propose any mitigations.

100

CHAPTER 5

Configuring the Application Stack In this chapter, we will review the organization of the Serverless configuration file. We will explore good practices for us to consider using in each configuration section.

Importance of Configuring the Application Stack The Serverless Framework uses the Serverless configuration file to define the application stack. The “application stack” is a term referring to the different layers of applications and services used to make the application functional. For example, recall from Figure 2-2, the example ecommerce mobile app needs a mobile application, API gateway, databases, and functions. The Serverless configuration file can manage these application components, except the mobile application code. Given this configuration file can define most of your application, the components, and infrastructure, it behooves us to configure it optimally.

Understanding the Serverless Configuration Up until now, we have been using Serverless configuration files to perform a risk assessment and identifying functions and interfaces. We will review the configuration file and its different elements in more depth. The Serverless configuration file has three required common sections for AWS, Azure, and Google Cloud: •

The “service” section defines the application stack.

© Miguel A. Calles 2020 M. Calles, Serverless Security, https://doi.org/10.1007/978-1-4842-6100-2_5

101

Chapter 5

Configuring the Application Stack

•

The “provider” section defines the serverless provider and provider-­specific settings.

•

The “functions” section defines the serverless functions, event triggers, and other settings.

You will see these sections defined similarly to Listing 5-1.

Listing 5-1.  Required Serverless Configuration Sections service: myService provider:   name: google functions:   myFunction:     handler: myFunctionHandler     events:       http: path These sections are used similarly across all three providers, but there are some differences. There are three additional common sections you can define: •

The “frameworkVersion” section defines the Serverless Framework version(s) needed to deploy the service.

•

The “plugins” section defines the Serverless plugins to use during the deployment process or as a command-line instruction.

•

The “custom” section defines custom variables for use in the configuration file. You can reference these custom variables by using a Serverless variable (e.g., "${self:custom.myVariable}") within the configuration. Some plugins may use this section to obtain custom settings.

•

The “package” section defines how the function code is packaged and deployed.

You will see these sections defined similarly to Listing 5-2.

102

Chapter 5

Configuring the Application Stack

Listing 5-2.  Optional Serverless Configuration Sections frameworkVersion: =1.0.42 plugins:   - serverless-google-cloudfunctions custom:   myVariable: myValue package:   include:     - src/**     - handler.js   exclude:     - .git/**   excludeDevDependencies: true   individually: true The AWS service has additional optional sections: •

The “layers” section defines any AWS Lambda Layers1 to upload and deploy. You can upload up to 250 MB of data in each layer. A Lambda function can use up to five layers.

•

The “resources” section defines any CloudFormation resources (e.g., an S3 bucket or DynamoDB database) to deploy. You can specify any resource that CloudFormation can deploy in this section.

You will see these sections defined similarly to Listing 5-3.

Listing 5-3.  AWS-Specific Serverless Configuration Sections layers:   myLayer:     path: layers/myLayer     name: ${self:service}-${self:provider.stage}-myLayer

“ AWS Lambda Layers.” AWS Lambda Developer Guide. Amazon Web Services. https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html

1

103

Chapter 5

Configuring the Application Stack

resources:   S3BucketUploads:       Type: AWS::S3::Bucket       Properties:         BucketName: ${self:custom.bucketName} custom:   bucketName: ${self:service}-${self:provider.stage}-uploads Next, let’s review some good practices for each of the sections mentioned earlier.

Good Practices for the Serverless Configuration The Serverless configuration file will vary among the different application stacks and providers. We will review good practices for you to consider in each of the configuration files.

Defining Multiple Services In Chapter 2, we discussed how a service is a group of functions and how the example ecommerce mobile app had three groups of functions in the application layer (see Figure 2-1). Each group of functions has one Serverless configuration file and thus deploys three services. The three services organize the functions and resources and create internal service boundaries. Each Serverless configuration file will deploy one service, which is managed independently from the other services. You might decide to create one code repository per service or have one repository (or “monorepo”) with subfolders for each service depending on your project requirements and team preferences. In either case, you should have a logical grouping for each service. You should name each service representative of its purpose. For example, you might call one service “eCommerceAccounts” because it contains functions related to user accounts. This name suggests that you will manage the account-related functions, event triggers, and any resources as a group and independent of other services. You can then add a new function without disrupting another service. Having this type of separation creates a service boundary. Having service boundaries allows you to define service-level APIs, meaning a service must use another service’s API to establish a communication. For example, a payment service might need to verify an account is active. The payment service would send an 104

Chapter 5

Configuring the Application Stack

HTTPS request to the accounts service API that executes the account lookup function. This interaction will succeed as long as the payment service conforms to the accounts service API. You should use this interservice interaction rather than having the payment service execute the accounts service function directly. Doing so creates a dependency, requires the accounts service to expand its security permissions, and adds complexity. You will also manage resources per service. For example, you can manage the accounts database independent of the payments database. Therefore, you might want to work with the application developers to confirm the services are optimally defined, especially if there is much interservice interaction.

C  onfiguring the Provider Other than the provider name, the provider section defines settings specific to the AWS, Azure, and Google Cloud providers. The AWS provider section has the most settings compared to those of Azure and Google Cloud. We will start with Azure and Google Cloud and conclude with AWS.

A  zure The Azure provider section allows you to define the region location to deploy the service. You can also specify the API gateway settings. •

Region: You should specify the region location closest to where your users will interact with the service to reduce network latency; see Listing 5-4. You can view the regions Azure supports for Azure Functions in the Azure documentation.2

Listing 5-4.  Azure Provider Section provider:   name: azure   location: West US

“ Products available by region.” Microsoft Azure. Microsoft. https://azure.microsoft.com/ en-us/global-infrastructure/services/?products=functions

2

105

Chapter 5

•

Configuring the Application Stack

API Management: You can define an API gateway to manage your API endpoints. You should specify tags to help with organization, the appropriate authorization depending on the intent of the function, and proper Cross-Origin Resource Sharing (CORS) settings.

Listing 5-5.  Azure API Management Configuration3 provider:   apim:    apis:      - name: v1        subscriptionRequired: false        displayName: v1        description: V1 APIs        protocols:          - https        path: v1        tags:          - eCommerce 1.0        authorization: none    cors:      allowCredentials: false      allowedOrigins:        - "*"      allowedMethods:        - GET        - POST        - PUT        - DELETE        - PATCH      allowedHeaders:        - "*"      exposeHeaders:        - "*"

 his configuration is based on the sample configuration provided by Serverless, Inc. “Serverless. T yml Reference.” Serverless Documentation. https://www.serverless.com/framework/docs/ providers/azure/guide/serverless.yml/

3

106

Chapter 5

•

Configuring the Application Stack

Environment Variables: This subsection defines the environment variables all functions will have. You should never include sensitive data in plaintext; instead always use encrypted versions of that data. Limit using this section to defining environment variables that every function will or might use; see Listing 5-6. You should define all other environment variables in the function configuration.

Listing 5-6.  Azure Provider Section – Environment Variables provider:   name: azure   environment:     GLOBAL_VAR1: value1     GLOBAL_VAR2: value2

G  oogle Cloud The Google Cloud provider section allows you to define the runtime, project, and credentials. These are the required settings. Refer to the Serverless documentation4 for instructions on how to populate them. The provider section also allows you to define the memory size and timeout that applies to all functions: •

Region: Similar to the Azure region, this sets the region closest to where the users will interact with the app; see Listing 5-7. You can view the regions Google Cloud supports for Google Cloud Functions in the documentation.5

Listing 5-7.  Google Cloud Provider Section – Region provider:   name: google   region: us-central1

“ Google – Credentials.” Serverless Documentation. https://serverless.com/framework/docs/ providers/google/guide/credentials/ 5 “Cloud locations.” Google Cloud. Google. https://cloud.google.com/about/locations/ 4

107

Chapter 5

•

Configuring the Application Stack

Memory Size: Cloud Functions are assigned a default memory of 256 MB. You should keep this global value small and increase it on a per-function basis; see Listing 5-8. Google Cloud charges higher prices6 for more memory usage. More memory-intensive functions should have more memory because it reduces execution time. Be cautious with any functions that use a regular expression to validate inputs. If it is vulnerable to a Regular Expression Denial of Service (ReDoS) attack and the function has a lot of memory allocated, Google Cloud will charge a higher per-execution cost. It can become very costly if that function executes numerous times. You can use a regular expression static analysis tool to check your regular expressions.

Listing 5-8.  Google Cloud Provider Section – Memory Size provider:   name: google   memorySize: 128 •

Timeout: Cloud Functions are assigned a default execution timeout of 60 seconds. You should keep this global value small and increase it on a per-function basis; see Listing 5-9. Google Cloud charges execution time in increments of 100 milliseconds.5 The longer a function executes, the more that execution will cost. If a function is blocked during execution or is vulnerable to a ReDOS attack, it will continue executing until reaching the timeout. Google Cloud will charge you for that entire execution time, and it can become very costly if that function executes numerous times.

Listing 5-9.  Google Cloud Provider Section – Timeout provider:   name: google   timeout: 3s # only accepts seconds

“Pricing.” Google Cloud. Google. https://cloud.google.com/functions/pricing

6

108

Chapter 5

•

Configuring the Application Stack

Labels: You should consider defining labels to help you locate and organize the functions in the Serverless deployment; see Listing 5-10.

Listing 5-10.  Google Cloud Provider Section – Labels provider:   name: google   labels:     projectName: eCommerce

Amazon Web Services (AWS) The AWS provider section allows you to define several settings. Reference the Serverless documentation7 to see the extent of all the provider settings. We will focus on specific settings: •

Region: Similarly, as with the others, set the region closest to where the users will interact with the app; see Listing 5-11. You can view the regions that AWS supports for Lambda functions in the AWS documentation.8

Listing 5-11.  AWS Provider Section – Region provider:   name: aws   region: us-east-1 •

Memory Size: Lambda functions are assigned a default memory of 1024 MB. You should keep this global value small and increase it on a per-function basis (see Listing 5-12) for the same reasons discussed in the Google Cloud section.

“ Serverless.yml Reference.” Serverless Documentation. https://serverless.com/framework/ docs/providers/aws/guide/serverless.yml/ 8 “AWS General Reference.” AWS General Reference. Amazon Web Services. https://docs.aws. amazon.com/general/latest/gr/rande.html 7

109

Chapter 5

Configuring the Application Stack

Listing 5-12.  AWS Provider Section – Memory Size provider:   name: aws   memorySize: 128 •

Timeout: Lambda functions are assigned a default execution timeout of 6 seconds. You should keep this global value small and increase it on a per-function basis (see Listing 5-13) for the same reasons discussed in the Google Cloud section.

Listing 5-13.  AWS Provider Section – Timeout provider:   name: aws   timeout: 3 # only accepts seconds, no "s" suffix needed •

Deployment Bucket: The Serverless Framework uploads the artifacts it used in the deployment to an S3 bucket. By default, the S3 bucket stores the files as encrypted, but they might be Internet accessible. At a minimum, you should prevent global access to these Serverless artifacts; see Listing 5-14.

Listing 5-14.  AWS Provider Section – Deployment Bucket provider:   name: aws   deploymentBucket:     blockPublicAccess: true •

110

Environment Variables: This subsection defines the environment variables all functions will have. You should never include sensitive data in plaintext; instead, always use encrypted versions of that data. Limit using this section to defining environment variables that every function will or might use; see Listing 5-15. You should define all other environment variables in the function configuration.

Chapter 5

Configuring the Application Stack

Listing 5-15.  AWS Provider Section – Environment Variables provider:   name: aws   environment:     GLOBAL_VAR1: value1     GLOBAL_VAR2: value2 •

CloudFormation Identity and Access Management (IAM) Role: When you deploy the Serverless configuration, the deployment uses the defined AWS credential, which typically is that of the user. This credential may have privileges to create resources not used in the Serverless configuration. You should define a specific IAM role for the deployment, which only has the privileges to create, update, and delete the resources used by the Serverless configuration; see Listing 5-16. We will discuss IAM in Chapter 6.

Listing 5-16.  AWS Provider Section – CloudFormation Role provider:   name: aws   cfnRole: arn:aws:iam::XXXXXXXXXXXX:role/CloudFormationRole •

Tags and Stack Tags: You should consider defining custom tags to help you locate and organize the resources (e.g., API Gateway, CloudFormation stacks, Lambda functions, etc.) in the Serverless deployment; see Listing 5-17.

Listing 5-17.  AWS Provider Section – Tags and Stack Tags provider:   name: aws   stackTags:     PROJECT_NAME: eCommerce     PROJECT_VERSION: 1.0   tags:     PROJECT_NAME: eCommerce     PROJECT_VERSION: 1.0 111

Chapter 5

•

Configuring the Application Stack

IAM Role Statements: This subsection defines the IAM privileges all the functions will share. You should avoid setting privileges here unless it is a privilege every function needs (e.g., decrypting secrets encrypted with the KMS service); see Listing 5-18. Instead, you should define the IAM privileges within each function configuration. We will discuss this further in the next section.

Listing 5-18.  AWS Provider Section – IAM Role Statements provider:   name: aws   iamRoleStatements:     - Effect: Allow       Action: kms:Decrypt       Resource: arn:aws:kms:${self:provider.region}:*:key/* •

Virtual Private Cloud (VPC): You might use a VPC to prevent a Lambda function from being accessible from the Internet or to access resources that only exist with the VPC. You should have two VPC subnets at a minimum to ensure the Lambda function has access to the VPC in the event one of the subnets becomes available; see Listing 5-19. You only need to define the VPC in the provider section if every Lambda function needs access to the VPC.

Listing 5-19.  AWS Provider Section – Virtual Private Cloud provider:   name: aws   vpc:     subnetIds:       - subnet-XXXXXXXXXXXXXXXXX       - subnet-XXXXXXXXXXXXXXXXX     securityGroupIds:       - sg-XXXXXXXXXXXXXXXXX

112

Chapter 5

•

Configuring the Application Stack

Tracing: You should consider enabling tracing for the API Gateway using AWS X-Ray; see Listing 5-20. X-Ray is an AWS service for collecting metrics and data on the API Gateway usage. It is useful in detecting potential Denial of Service attacks because it shows metrics of HTTP status codes and the web URL used to access the API Gateway. For example, if you notice numerous 403 errors for an undefined URL coming from a specific IP address, you can take measures to block that IP address.

Listing 5-20.  AWS Provider Section – API Gateway X-Ray Tracing provider:   name: aws   tracing:     apiGateway: true There are many AWS provider settings we did not discuss. You might find it beneficial to become familiar with all the settings and determine how to set them for your project. Refer to the Serverless documentation to learn more.9

Organizing and Defining Functions We reviewed functions in Chapter 2 in the context of performing a risk assessment, Chapter 3 in the context of securing the code, and Chapter 4 in the context of securing interfaces. Now we will review how to organize the functions and define any function-­ specific settings we described earlier. For all three providers, you can further organize the functions within a service. A service should have all the functions that relate to that service, but you might be able to organize them into subgroups. For example, say the accounts service has functions for registration, credentials, and data retrieval. You can then create three function files that contain those subgroups: “serverless-functions-registration.yml,” “serverless-functions-­ credentials.yml,” and “serverless-functions-data.yml” files; see Listings 5-21, 5-22, and 5-23, respectively.

“ AWS Provider Documentation.” Serverless Framework Documentation. Serverless, Inc. www.serverless.com/framework/docs/providers/aws

9

113

Chapter 5

Configuring the Application Stack

Listing 5-21.  Functions Section – Accounts Registration Functions # serverless-functions-registration.yml functions:   registration1:     handler: http     events:       - http: path

Listing 5-22.  Functions Section – Accounts Login Functions # serverless-functions-login.yml functions:   login1:     handler: http     events:       - http: path

Listing 5-23.  Functions Section – Accounts Data Functions # serverless-functions-data.yml functions:   data1:     handler: http     events:       - http: path The Serverless file will reference the subgroup files; see Listing 5-24.

Listing 5-24.  Functions Section – Referencing Subgroups # serverless.yml functions:   - ${file(serverless-functions-registration.yml):functions}   - ${file(serverless-functions-login.yml):functions}   - ${file(serverless-functions-data.yml):functions}

114

Chapter 5

Configuring the Application Stack

The functions section for all providers allows you to define the events that trigger the functions. Instead of focusing on how to define events, we will focus on the recommended settings for each provider.

A  zure The Azure functions section has no Azure-specific settings to define.

G  oogle Cloud The Google Cloud Functions section allows you to define the memory and timeout for each function and thus override the provider settings; see Listing 5-25.

Listing 5-25.  Google Cloud Functions Section – Memory Size and Timeout functions:   registration1:     memorySize: 512     timeout: 6s

AWS The AWS functions section allows you to define several settings. Reference the Serverless documentation to see the extent of all the provider settings. We will focus on specific settings: •

Memory Size: You can override the memory and timeout settings defined in the provider section; see Listing 5-26.

Listing 5-26.  AWS Functions Section – Memory Size and Timeout functions:   registration1:     memorySize: 512     timeout: 6

115

Chapter 5

•

Configuring the Application Stack

Environment Variables: You can append to the provider environment variables by defining function-specific environment variables; see Listing 5-27. Remember not to use plaintext values for sensitive data; use encrypted values instead.

Listing 5-27.  AWS Functions Section – Environment Variables functions:   registration1:     environment:       FUNCTION_VAR1: value1 •

Virtual Private Cloud: You can override the provider VPC settings or define the VPC setting for specific functions; see Listing 5-28.

Listing 5-28.  AWS Functions Section – VPC functions:   registration1:     vpc:       subnetIds:         - subnet-XXXXXXXXXXXXXXXXX         - subnet-XXXXXXXXXXXXXXXXX       securityGroupIds:         - sg-XXXXXXXXXXXXXXXXX •

Layers: You can define which layers to use; see Listing 5-29.

Listing 5-29.  AWS Functions Section – Layers functions:   registration1:     layers:       - arn:aws:lambda:region:XXXXXXXXXXXX:layer:LayerName:Y

116

Chapter 5

•

Configuring the Application Stack

IAM Role Statements: You should define IAM privileges for each function; see Listing 5-30. You will need a plugin to enable this setting because it does not exist natively in the Serverless Framework. Remember to use the least amount of privileges for the function to execute properly. We will discuss IAM in Chapter 6.

Listing 5-30.  AWS Functions Section – IAM Role Statements functions:   registration1:     iamRoleStatements:       - Effect: Allow         Action: s3:DeleteObject         Resource: arn:aws:s3:::${self:custom.bucketName}/*

Pinning the Framework Version For all three providers, you can define which version(s) of the Serverless Framework to use when deploying the service. You can specify a specific version (see Listing 5-31), which is a recommended setting for production deployments. Having varying versions is typically not a problem. Still, for reproducibility and testability, it is a good idea to use an exact version because a future version might introduce a bug or a breaking change into the Serverless Framework.

Listing 5-31.  Framework Version Section – Specific Version frameworkVersion: '=1.42.0' You can also specify a minimum and maximum version range; see Listing 5-32. You might want to use this option while developing the application to give flexibility in upgrading to the latest version of Serverless. Make sure to limit the maximum version to be less than the next major version to avoid any backward-compatibility issues. When the application is close to being final or is ready for final production deployment, you should consider using a specific version.

Listing 5-32.  Framework Version Section – Version Range frameworkVersion: '>=1.42.0