Fortifying APIs: An Inside Look at Siemens

Hello everyone, my name is Thomas Parsch. Today, in the next 20 minutes, I will talk about how we secure APIs at Siemens. If you don't know Siemens, it's pretty well known. Maybe you have used the trains, most of the ICEs, those high-speed trains in Germany are built by Siemens. We are producing equipment for, for example, skyscrapers for the performance and energy management and also every other building.

And also, we do a lot in factory automation and many more. And as a techie, it's also quite cool working here because you can see custom silicon, you can see own operation system.

But today, we will talk about standard cloud platforms, which you also use like the hyperscaler ones where I'm specializing in. And to start, how many of you are currently managing internet-facing APIs?

Ah, great. So, I see like here, like six people or seven people. That's like 30%, I would say. That's really great.

So, I hope you maybe have some more questions afterwards on it. And for the others, I hope you get an introduction what you should think about when you are protecting APIs. And the first slide is about, or the first chapter here is about how we secure an enterprise on an enterprise scale.

And later, we will dive into one product which I developed the API for and how you can secure the API, let's say, on a product scale. So, if you look on an enterprise scale, you can first, how can you secure your API DevOps?

And here, we have like basic and advanced measures. So, a basic measure would be basically to use continuous API security testing.

So, it means you have tests against your API. For example, if the authentication is working and you want to have it a little bit more advanced, you do fuzzing.

So, it means you add an element of randomness in order to get some random input against the API. And basically, if your server crashes, you know something is wrong.

And often, if it crashed with a random input, that's where an attacker would attack and then you would have to improve there if you want to bring it further. But then, of course, it increases the costs.

As I said, you should be aware of the identification of endpoints not matching the industry practice, best practices. And also, you can do an open API specification analysis.

So, checking, for example, is everywhere the correct security on each endpoint defined? Are the endpoints you're not aware of? Is it matching with your system? And the second point where we're looking at is posture management. That's more or less analyzing all your configuration. And a simple thing is misconfiguration detection. If you want to make it a little bit more advanced, you can also try to discover and protect sensitive data.

So, you monitor all your endpoints, see if sensitive data is leaving. You have to find and if that's happening, you know something is really wrong. You can try to detect shadow and orphan endpoints.

Of course, you have to install systems which are able to scan everything and really be in control of your whole company, which is in large enterprise some effort. It's not easy. And of course, a vulnerability detection. And now we're coming to the next part. It's runtime protection.

So, if it's really running, what can you do? Of course, what everybody hopefully knows is classic web application, firewalls, firewalls, and API gateway product detection. And if you want to make it more advanced, you can go with OWASP top 10 security events detection, abnormal behavior detection. There where a lot of companies use AI. And finally, security information and event management systems and connecting it to your security orchestration automation response.

That's quite important because basically, if you detect something, you want to make sure that it's basically closed afterwards and that you're secure again and that you're not detecting it, but you're not acting on it. I mean, in large organizations, it can happen that something gets lost.

So, that's why it's really important that you have a management in place. And finally, it's about the discovery.

So, we have a basic security with WIS, where we create an inventory of all endpoints that we know which endpoints are there. And more advanced, you can also cluster them to APIs. You can also look if you're using further APIs because sometimes you're using maybe a subsystem and you want to be in control of what data is flowing here.

And also, the systems behind your systems have to be secure because otherwise, the attacker will get the data from there. And finally, we can identify API changes because maybe you know something gets checked in, everything is open suddenly. And this one, you want to prevent before it goes live.

And so, we're coming to the next point. This is API advanced protection. What can you do if you have high-value targets where you can invest a little bit more money in? And I want to present you a standard way how most providers basically structure these new kinds of systems. The main goal is to protect the customer data you have.

So, let's assume you have, in our case, Siemens accounts, where API calls are made with customer data. So, it goes to our API gateways and from there to our backend system where we process all those data.

So, here, we have customer data. But now, we want to protect the API. What should we do? And what we do is we mirror the API in another account which also belongs to us.

And here, we install a so-called tokenizer from a provider which analyzes the data, which is still customer data, but derives from said only metadata. And this metadata is then sent to an account operated by our SaaS provider. But since it's only transferring metadata, we can ensure that no customer data leaves our systems with this approach.

And often, you then try to enrich those metadata you have from the tokenizers with some other metadata from your internal systems. So, think about a configuration management database or something so that you can basically bring those data together and generate insights.

Then, it's quite important for your experts and also for the management to have a dashboard so that you see, are you improving here? What's happening? If you want to have more details. And those gained insights are sent to downstream systems, for example, your vulnerability management and that end. And this is how, on the big scale, it's working and how it's prevented that customer data basically goes to a SaaS provider where you do not have maybe fully control how he secures everything.

Of course, there are contracts in place, but you cannot really check it like you can check it on your own system. And what are the key insights we gained when using this kind of system? The first thing, be aware, there is still an emerging tool market.

So, more and more startups pop up. But on the same side, there are big players crystallizing and they do merger acquisitions of a lot of startups and also a lot of consolidation is happening.

So, we're expecting that there will be at the end maybe four or five big players which offer a suit which more or less delivers everything for enterprise. Because for enterprise, it's more convenient to have a contract with one company than with, let's say, 40. A second thing, it's really possible to get a high visibility of the deployed internal and exposed APIs, especially if you're in the cloud a lot with those agentless detection. You really can get an overview over the whole company and you can really say at the moment there are, let's say, 10,503 endpoints deployed.

So, you can really count every single one, which wasn't possible before for a whole enterprise before we installed this kind of system. Then also a complete security posture control is possible. It's really possible to check all those configurations. But now we're coming to see disadvantages as sometimes comprehensive onboarding efforts are required.

So, you don't get it for free to install this kind of system. It's a longer project. And also traffic mirroring, as we saw before, comes with additional costs.

So, you should really be aware what are the assets you want to protect, where you invest additional money and where is, let's say, an advanced but not a super advanced security effort possible. And finally, that's also increasing the costs. The rate of false positive is quite high.

So, if you monitor certain systems and you get a lot of alerts, you have to check them. And a lot of them are basically false alerts.

Of course, it's way better to follow a false alert than having a real alert and nothing. But it's not possible this kind of effort for every system you have probably.

But, of course, automation is ongoing. And now we come more to a product. What I want to introduce, I worked on was SYNIC Security Guard. It's a SaaS offering to protect OT devices in factories.

So, what it does, it provides a vulnerability discovery and management. And based on this example, I want to show how we protect here the APIs in serverless architecture in AWS Lambda.

And so, first, you detect vulnerabilities. Afterwards, you can put them in certain zones and also have those risk-based approaches, similar to what I mentioned.

Also, in a factory, there are areas which you have to protect more and other areas where you have to protect less. And, you know, in a lot of factories we see, there are so many security risks that you really have to prioritize where to start first. You cannot solve everything at once. That's important for many customers we have. And to help that, there is an additional live attack detection.

So, if something not normal happens inside the network, you get also an alert. And as mentioned, you want to act on your findings.

So, there is a simple task management integrated. And larger companies normally have a third-party system where you can also connect this tool to. And why am I talking about here and about API security? If you think about it, we have the vulnerability and we first have to match it. That more or less means we scan all devices inside the factory. And when you have those devices identified, you match them against the vulnerability database.

So, you could say this device has this version of the firmware and we know it has the following vulnerabilities. And you bring that together. And afterwards, you maybe say this vulnerability is not really important because we are not exposed to the internet or it's very highly protected. But this other device is basically your VPN gateway or it's directly connected to the internet. You never should do it, but could happen. And if you there have a security problem, you get basically a high alert. And that's why you prioritize what is important. On the third stage, you engage.

So, basically, you try to solve it. And our solution is a SaaS-based and in the internet available.

And now, we're coming to API security. I mean, if you think about it, if you're an attacker, what would you try to get first?

This list, because you could see where to attack first. And even you can read how to attack because if you read the security advisory, you know normally how you know how to get in.

So, this is really sensible data. And I mean, be aware, every security system you use has probably this kind of information what you really, really want to protect. And how we are doing this. On the one hand, of course, we are applying those general protections we have.

But now, let's go a little bit deeper. And I simplified it a little bit for this talk. It's really standard AWS services.

So, at first, I would say we have auxiliary systems like x-rays. That's also for performance. But you could say, if your system has an unusual amount of...

So, it takes longer than normal, for example. That could also be a hint that something is wrong with your systems and maybe attackers are in. Then you have CloudTrails. That's an AWS pretty standard. That tracks all your actions you basically executed in the cloud.

So, that's thing you have CloudWatch. It's like the logging service from AWS. You have the certificate manager to make sure that your endpoints have all proper SSL certificates. And finally, you have GuardDuty, which is more or less an intrusion detection system. But this is more like the auxiliary systems.

And now, we're coming to the main architecture. And for those of you who are pretty familiar with serverless architectures, that's a standard architecture.

So, on the upper left, you see a route 53. That's where the DNS record is. And this brings basically your user towards your solution. And then you split it.

So, in our case, we have an UI and we have a backend. And for the UI, you go through CloudFront, which is a content distribution network so that you quickly basically can see the page. And then the actual UI is stored on a static S3 bucket. And we have a Lambda at Edge, which makes sure with the identity and access management systems that you really have the permission to even see the UI.

Otherwise, you just see a login page. Many other solutions, sometimes it's also okay, always gives the UI away and only protects the backend. In this case, we're also protecting the frontend because we have a little bit of a fear that an attacker could basically copy this page and make a fake page. And this makes it a little bit more difficult to achieve that.

Of course, it's still possible it's an attack vector, but this prevents it a little bit. And if you're looking on the backend sides and we have a web application firewall, on the next slide, we get a little bit more insight what we're doing here. Then you're going to the RPE gateway. The RPE gateway is also then connected to the identity and access management and checks if this user has the permission to see it.

And also, you know now which user it is. And then it goes to your Lambda function. This for who is not familiar with AWS, this is a serverless function. So you have basically for every function you call, you have your own Lambda function. And then the RPE gateway say, okay, this endpoint is called and your Lambda function gets active. Sometimes you also have SNS queues. That's why I said I simplified it a little bit. And since this dedicated code is executed, here we're doing additional checks.

Like we have some validation on the API gateway level, but also inside this function we have further validations. And then you go, for example, to a DynamoDB and there you can even have a row-based access controls. That means you can see, since you have the identity of the users, that he only can do queries about his data. Because maybe you don't want that he sees the neighbor zone in the factories that he just can query his data. And this is how you can protect in a simple way a serverless application, but get a pretty high standard.

Of course, if you combine it with the systems we saw before and mirror all the API traffic, you can make it even more secure. And now for those of you who are using AWS, I wanted to give a little bit of a techy deep dive, but I do it on a high level, is what we are doing at the web application firewall. And so first thing we're checking for is a flood attack prevention. Why is this our first rule we evaluate? Because if a flood attack happens, this is something you want to immediately block. And it's not worth doing all the other evaluations when you are flooded with calls.

You just want to cut that. That's why we're doing that first. And now we're coming to source trick. It's more or less since we have now sometimes problem inside not just countries, but inside regions of a country. It's like if you look at Ukraine, there are regions where you maybe want to just block a region. And if you want to achieve that with AWS, you basically first do a country code filter. So it's quite normal because you are obligated, for example, to block Cuba because there are sanctions. And then in the next step, you have to add the region code.

It's unfortunately in AWS, it's not possible to do it in one step, but you can do add a sub-country code. And in the next step, you can really filter on those country codes. So you can specifically filter out certain regions, for example, from Ukraine, where you say you don't think that it's basically Russia and it should not be under sanction. And finally, we have, of course, those AWS common rules and also additional custom rules. I want to point out that this sub-country rule, I think it's a nice, interesting thing what you can do.

Of course, a real attacker would probably hack another server and attack you as well. So it's just one single point you can improve further. But I think it's quite interesting. Before I was in this project, I wasn't aware that you could filter in basically on a sub-country level. Yeah. And now we're coming to the end of my talk. So if you have questions and answer, please feel free to ask questions and I will answer them. Thank you so much. Any questions? We've got about 30 seconds, but okay. Thanks so much, Thomas. Thank you.