Transcript

Hello and welcome to this lecture where I want to look at some security concerns that are still apparent, regardless if you are using an IaaS or FaaS solution. Serverless does not change every aspect of a deployment. There are still many components that are impacted by the same security measures in a traditional infrastructure as a service department. 

The first point I want to mention is that of encryption. The fact that you are using either IaaS or FaaS has no impact on the sensitivity of your data you are utilizing and creating. So that point remains constant. The underlying architecture of how that data is begin stored and transferred has no impact if someone gains the ability to read the data. Data is either sent in transit or stored at rest. As a result, encryption options and mechanisms should be used to ensure that the data is encrypted in both states. Leaving data open as plain text is a breach waiting to happen, especially if the data contains sensitive and confidential information, such as PII. FaaS solutions do not automatically encrypt all communication channels, neither does it encrypt your data being stored while at rest. These security protection measures need to be architected into your solution. If you protect the data correctly with sufficient encryption, you protect your customers integrity should a breach occur. 

Next I want to mention permissions. I know I briefly touched on permissions earlier, but the fact remains for any solution out there. Managing access control permissions to resources and the level of actions set can be carried out on those resources is so important in the security strategy. Understanding access control and how to configure your permissions to be as granular as feasibly possible can be difficult to achieve, especially when trying to ascertain which API calls are required to carry out specific tasks by function and limiting access to only those called. In many environments, both IaaS and FaaS access controls is often implemented poorly with overly permissive access given to users, groups, and roles. This elevated level of permissions only serve as a greater risk, which unnecessarily exposes your environment. When assigning roles to a functions, be sure to adopt the least privilege rule to only assign permissions needed to carry out that function. 

The next couple of points I want to mention relate to the actual code used to create functions. Third party libraries of code are a security headache. Libraries are very useful to prevent developers from having to write their own code for something that is already been developed and proven to work. However, as this code has been written by someone else, how secure is that code? Has it been written to the best practices and how much can you really trust it? Not to mention the numerous dependencies that are likely to be embedded within those libraries, again these dependencies would have been developed by third parties. Although using these libraries make perfect operational sense from a developer point of view to speed up development, it does however provide a level of security concern for your security team. These libraries make it harder to ensure that code is doing what it is only supposed to do and not add any additional exposure to a application and your data. This makes input and output sanitization key for your deployments. You need to ensure that what is going in and coming out of your coded application is deemed as clean. 

The final point, and quite possible the biggest point I want to mention, is that there is still the fundamental issue of building security within your code that you write. Writing poor code, whether it be in an infrastructure as a service or function as a service environment, is still a big risk factor to your application and environment. Security best practices should be followed at all times when writing your code to minimize risks of exposure. And your code should be written to only perform that function that it needs to perform, nothing more, nothing less. Application level security is still very much a vulnerability in function as a service. Applications are susceptible to malicious activity through a variety of attack vectors, many of which are covered by the OWASP top 10 vulnerabilities list, which is what I should be covering in greater detail in the following lecture. So let's end this lecture and move on to focus on OWASP and service application security.