Interview with Eleni Richter

So your trust is today's topic and you as chief chief architect within BW are also experience in the topic. And this is why we will have this interview today. We had a cool preparation call, I think three weeks ago or four weeks long time ago, where we started to discuss about the topic zero trust Alexei, a shared our coping a call idea of zero trust in his first presentation today. So the keynote about the different relevant parameters, like the identity, like the application, like the data that is accessed and also the network that is used.

And in the previous panel discussion, we also talked about the network and I tried to ask the people in the direction, what to do with the old stuff. What is with the stuff I have in the seller. And my question to you would be, what is the difference of this old parameter NCR trust? What changed? Yes.

Well, the main idea is the parameter model, which I have something in similar, you can't buy zero trust and you can't buy pyramid security. You've got, it's more architectural approach and you've got to build both them. So that's something they got in common in parameter security. It's mainly the idea that you put all things you trust in one place, which is usually one network and build a kind of fence around and put some checkpoints control points, border controls around it.

Usually they are firewalls or something like web application firewalls, or whatever you can afford all the time it's offering in technology. And so more or less static approach. So if you cross that border because you are trusted device, or you are allowed to access an IP address or whatever you are inside, and there's, then you are a trusted partner and you can do communication. And the inside is it doesn't have any segmentation anymore. And usually it's for flat. That's the main problem with the pyramid security.

The zero trust security means you build very small islands, even micro segmentations, and put a micro pyramid around and put the control directly to the thing you want to control. And in addition to that, you put more dynamic aspects into it. So you decide is the not only is the IP address or the network address wanted, but you also control is the action wanted is the person who's accessing it. A wanted person is the actor in case it's an application or a service and not in person as an actor is the actor wanted, can it prove it by an adequate authentication?

And even you may put some dynamic aspects into it, like a behavior control. Is this an expected interaction or unexpected interaction? And if you say it's an unexpected interaction at this, in this case, it can be time measuring or whatever, then you will stop the interaction.

So it's a, it's a more holistic approach and you have a more centralized rule set or policy engine, which is quite more complex than just building a pyramid. Well, great. So in the Siemens presentation, they, or in general, they talked about different benefits or things. Why zero trust is better? Like the typical stuff we all know from two years ago, connecting to corporate networks with weep and failed because too many per access attempts. Yeah.

Is this something which is, can be solved with the co trust strategy or do you see any other bigger advantages or benefits when investing into zero trust idea or technology in an organization? Okay. If you go for parameter security and you regard VP Anderson, enlargement of the parameter, which is enlarged, let's say to your home office or whatever, you got all those, this bottleneck in controlled in your pyramid.

If you've got a zero trust strategy and you do it well, you can vote, avoid those bottlenecks, of course, because they are very small points where they keep controlling the traffic for very, very small area areas. If you do it bad, I, I would say, yeah, you can do it, build another kind of more complex bottleneck, but it will be still possible if you've got a policy enforcement point and all, all traffic has to go through this policy enforcement points and you overload it with policies. You won't get decisions in far in fast enough of time.

And if it's somewhere misplaced and not well load balanced, and that access, you will have the same problems as with the VPNs, but usually zero trust is adopted for a more distributed environment. A distributed environment have some built in load blanking, of course Should, should have at least, okay. So basically zero trust solves a problem. But on the other hand, also, we have to fix another problem. We have all the legacy applications in our, in our data centers, in our organizations. How do we deal with that? Is it then a mixture? Is it a micro segmentation or do I need both?

Oh, well the main problem with the legacy applications is in which you usually have on premises in your data center, they are not able to participate in modern, secure protocols. Often they can't do encryption or encryption in a secure manner. They got problems with taking part in the modern authentication protocols. And so just the technology basis is not not available for those legacy systems. So if you want, first question is, do you really want to take place them in a zero trust network in a very distributed environment?

And is it necessary that they take part in all kind of communication, which might occur there? If you say, okay, I, I want to expose this old legacy application. You will go, you will need to build some micro pyramid around. Maybe it is possible to put some kind of reverse proxy, some kind of jump post or whatever in front of the, as the entrance door to the legacy application.

And it's heavily, depending on what the legacy application is supporting how to access it, but more or less, you will need all the technology, which you formally use to secure your parameter to secure those legacy applications, because it's usually the only way they corporate and you can contact them. So, so at the end you add some something like, or you add more complexity on, on that level as you have before is then a good strategy to think about, forget about all the legacy applications.

So for sure you have them, but thinking strategic into five to 10 years, that the future is really for the cloud or more distributed applications, or, I mean, we will always have something like that Talking about N B w it it's, doesn't seem to be a realistic approach to get rid of all the legacy applications. And I think that for most of the companies, which are around more than 10 years, it's not a realistic option to get rid of them. Maybe you can replace them. Maybe you can renew some of them, but you will still have them.

And there will be always some old stuff, which, which doesn't work with the more modern security approaches. And you've got to find a solution for that. So you should be prepared to integrate them somehow, and you will need old technology and old security technology to do that. And you also mention an aspect. You can then several things in the cloud.

I mean, you can also rent legacy applications in the cloud. I mean, if you rent an infrastructure as service and get an old fashioned windows, anti domain controller, you've got a kind of an old fashioned application, which is run in the cloud and you've got, then you've got a part of cloud, which you've got to secure, just like legacy. It is it's, it's not so much. Usually you find in the cloud, the more modern applications, but you can also rent old fashioned application there. And then you've got to apply all the old fashioned security measures.

And this is really a good point because this is my next question to you. Is there then a difference between on premise legacy infrastructure, cloud based infrastructure as a service platform, as a service, maybe also the modern more modern stuff, serverless, oh, paint based.

Well, the, if you rent one of the most modern cloud services, like if you rent lump of functions, or if you just take a function as a service, or maybe a platform as a service or whatever those services expect to run in a public environment, they just can't take part in a classical on premises. World. People have find it very difficult to put them their traffics when VPN to route it into your network. At least if you want to have them at close, because you can't have any influence on the IP addresses, they use, you can't have any influence on the names they use.

You can't have any influence on how they communicate, because just do it over the public internet saying, okay, the service itself is safe enough to do that. So if whenever you've got a combination of very old services and very newborns, you will have to choose the right security security measures.

If you try to put the old fashioned applications, the legacy applications, it does, it makes no difference if they run in the cloud, or if you run them on premises and try to adapt them within latest security features, you will run into problems because they won't be any, some tool connector or whatever protocol you choose for authentication, for example, and whenever you get a brand new cloud application or function or whatever, you're renting there, maybe we're just based as a public service.

You will have a really hard time to place it in a closed environment, like a parameter security on premises, for best example, which is very well known. And Azure active directory is a public cloud service, which is public accessible. And it ex it is expected to run in a public environment. You can't place it in your, not even with best VPN, you can rent, you can't place it in your, in your parameter, inside your on-premises data center. Yeah. Yeah.

So, so at the end, if, if you put something from on premise, maybe a legacy application into a cloud and use platform as a service virtual machines, or maybe even containers, which are not ready for zero trust, you need to implement or, or use some kind of encapsulation for this application or service, however you call it and integrate this then into your zero trust strategy to have some additional layer in between.

So really no matter where this stored private cloud public cloud or whatever, and for serverless applications like Lambda, or I don't know how the Google ones are called sort of the serverless functions, it is something like integrated because usually this is something you stated you are authenticated in that moment. You, you have an API call on that function, whether it's an external one to an two to an API gateway or internal one from another service from the cloud provider as well here.

Well, hopefully you're, This should be at least a well designed and defined security first approach for modern cloud applications or organizations. How would you start with an such a really complex, but typical organization to build up an overall architecture here?

How, how to start with, with an organization, which has nothing that is concrete called zero trust. They have something in the cloud, they have something on premise. They have maybe an IDP, they use Azure, whatever, where would you start? What is your recommendation here or experience? I would go for an organization and approach. And first of all, design some security classification or security zones or whatever you would call it and think of then gather what you've got, what you can use as policy enforcement points.

You you'd rather have some security appliances, some firewalls or whatever, or you can rent them in the cloud as cloud service, pick up what you have, pick up what you want to buy and take a look, how you can build a policy enforcement point out of this. And then you will get some natural or some limitations because of the technology you can't, I'm not too much a friend of doing a Greenfield approach. Cause technology has limitations and those policy enforcements points, they have limitations.

If you go for an identity provider based approach, like the one we saw at Okta, it will be a very strong thing with users in authentication, but you will, will be. We probably have some problems with integrating things which are based on network security because they can't do cause they can't do anything else, which is in the audio environment quite common. So you've got to look what you have, the abilities you have. You've got to look how much money you want to spend. And then you've got to find something based on security classification, the risk based approach to put it in a model.

So it's, again like in the previous panel discussed the risk based approach, identify the most relevant assets, applications, information, data, whatever, and define and protective approach here. Yeah.

So again, to the audience shorthand, if you have any question to L feel free to use the chat function on our website, I can ask a question immediately. So three minutes left. Really appreciate it. If you use the chance, maybe talking about implementing a, the trust strategy, what should people not do? What are the biggest pitfalls from your end? Or maybe fails?

Yeah, the, I think the main problem is we tend to focus on the subject. We are, we know how to control in the 20 years ago, we put everything in firewalls because we were very good in controlling a peer addresses. Then we continued right now, we put 10 to, but then we put a lot of force into, in engineering, into controlling devices like running safe containers, device management, or whatever, safe devices, controlling virus, scanners, and so on because we were able to do that. And we focused too much on endpoints like laptops and PCs.

And right now we are focusing a lot on the person as user and his authentication process. But there's also communication between non-human actors, which can have, can be much of a problem. So it's not only the question which crown jewels you want to protect. The risk based approach should also look, which are my weakest points, because usually the someone who wants to intrude your network or someone who intrude your system usually starts at the weakest point.

So maybe it's also a good idea to start with the modern approach and zero trust report, not at the Chrome jewels, but at the weakest points, But, but isn't this at the end, usually the user, depending on the organization, but focusing on the wide variety of organizations. I mean, if, if I Google for maybe let's take me Christopher, I write him an email and try to start a fishing attempt, maybe social media as well, whatever.

So at the end, it's maybe again, It's, it's it's well it's depending on the, on the right now, I would say protecting user authentication is it's even become something like a low-hanging food. It might be expensive, but there is technology and you can just buy them and you've got, you have, can have multifactor authentication and everything else.

And it's nice to have, but I would say, well, if you at Facebook had this very nice API where you could just collect Facebook data through an API, which was not authentication authenticating at all, it was just a public service for everyone or anything. And so people and drops just pulled out the data and it got quite a security incident that quite some problems and even some, some very FIY business cases.

I, I won't go deep into that, but the, the question is, is the user really always, it's not only the, the weakest point. We have a lot of APIs which are badly secured, which somehow only hidden and not detected yet. We have this all whole OT environment, which is very hard to protect. We've got this server to serve service to service or whatever machine to machine communication, which is very hard field.

And where applying a user life cycle for machines or services is quite difficult and very different from implying a user life cycle for a person and a multifactor authentication or a strong authentication for a person might be a low hanging foot right now. But how do you do it with an old fashioned OT system, which you can't do encryption?

Yeah, absolutely. Right. So very good answer is zero. Trust the solution for all our problems right now for distributed working, or do you see any major disadvantages?

Well, it can become very complicated, but we've got to go for a more modern approach. We can't stay with parameter security, not even with, with enhanced parameter security. It's all just outdated business is demanding for distributed environments, distributed business cases. Everything wants to talk with everything. Everything is meshed and you can't even define some kind of border control. It's impossible. You can't define borders anymore. So you've got to go from a more modern approach. Absolutely.

So again, time is already over. That's incredible. How fast it's this 20 minutes go by. Thank you very much E for this really cool and great interview and for your insights on zero trust. Thank you. Okay. Thank you. Bye Bye. Bye.