Server architecture can differ in a lot of ways, but the three main categories would be on-prem, cloud and serverless. Some believe that cloud and serverless can be used interchangeably, which is not the case. To help clear up some confusion, this blog post will explain each of them and how it affects security work.
A physical server that you own
On-prem stands for on-premises which means that the server are located on the premises of the company. This is a physical server hosted at the company, a data center the company has their servers at, and so on.
Similarly, when talking about buying a on-prem solution it is software that could be shipped as a server that you place in your own data center or something that you install on an existing server.
In this kind of setup you have full responsibility of all security aspects: the application layer, keeping servers up to date and replacing old hardware. This might also require specialists or vendors to come on-site to service things when needed. If service of security updates are not kept up-to-date, hackers are bound to find a way in a exploit the opportunity.
On the other hand, you have full control over your data and depending on traffic flow it might be cheaper.
Where does Detectify fit in?
Detectify can help you scan web applications that are hosted like this today. However, you cannot buy our service as a on-prem solution in the sense of a server that you install in your data center or as software to install on your own. Our service is only available on our own infrastructure which we then scan your servers from. This ensures the service is constantly updated, both with new vulnerability tests but also from a security view.
A virtual server on a server which someone else owns
Today it’s easy to run your own operations without needing your own physical servers. Someone else, such as Amazon or Google, has their own massive data center with physical servers that in turn emulate smaller ones. The Cloud is not really mysteriously in the air, rather it’s when you rent of these virtual servers.
With this option you are free of the physical aspects of maintaining your own server, but there are similar responsibilities. You still need to keep all software including operating system up to date, configure firewalls, and related tasks. However, you do not have to think about replacing old hardware, making sure there is backup electricity, and so on.
This is similar to what we do at Detectify. In fact, every time you start a scan we start a new virtual machine at Amazon. This is good for scalability and for security as it is one way of ensuring information does not leak between customers. We would not be able to buy a new physical server each time, but virtually we can do this.
Detectify for companies in the cloud
The security of the server and application is your responsibility even if the server is not physically close to you. The cloud provider is responsible for the actual infrastructure or hardware, but everything on the software layer is on you. Security of web applications are always on you, regardless on how you host them.
A function on a server that someone else owns
It is here where it may start to get confusing. Going serverless is often confused with the virtual machine solution described above, but these are actually two separate things. In that kind of a cloud solution you do have your own server, albeit a virtual one. In a serverless solution you do not. Serverless can also be called Function as a Service, or FaaS. Two popular alternatives are AWS Lambda and Google Cloud Functions.
Serverless is a sub-category of cloud solutions, but in the previous part we decided to focus on virtual machines as that is the most common application.
In the virtual machine you are writing code that constantly runs. You have a web server which in turn calls on other code whenever someone access a specific page. In a serverless solution you instead write code that is triggered by events. Instead of maintaining your own server, you can upload the code to eg. Amazon and let them trigger each function based on events such as someone uploading a file to a Amazon S3-bucket.
An example use-case would be to create a simple HTTP API-interface that creates an event when it receives a request. A serverless function gets triggered by this event, takes the data from the API-call, modify it and then saves it in a Google Firebase database. This itself creates another event for another serverless function to react to.
A core thing about serverless is basically tying together these kind of services. This means that you can create code reacting to those events, and you only pay for when they actually are running. The code runs on servers owned by someone else (again, most often Google/Amazon/Microsoft) and as such you do not need to worry about maintaining the server.
How does Detectify help serverless?
If you use third-party services the configuration of those is very important. We have done a lot of research related to such usage. Examples on this would be the research we on S3-buckets or when we dug into upload policies and signed URLs. Such knowledge is implemented into our core service and something that we look for during a scan.
And even if there is no server to maintain, you are still responsible that the code is secure. Many traditional web application vulnerabilities still affect serverless applications.