I'm very happy to be here and first I introduce myself. My name is Elta I, my education is TRE engineer. I've got a degree in engineering at the University of Cast. As you can see in the picture. Typical engineer and I'm working for now than more than 20 years in different positions at E B W in BW is the second, third largest energy supplier in Germany. I did worked as IT security manager, IT consultant, IT system designer, project manager and architect.
And right now I'm the chief architect for identity and organizational data management at nbw responsible for design and architecture of our next generation identity management system. And I'm a part-time lecturer in identity and access management and cybersecurity architecture at the Lucerne University of Applied Arts and Science. So as being an engineer, I like to do sketches. So I brought my sketchbook to show you some of my pictures. So the content of the sketchbook will be, I got a, somehow I think we should go into a kind of a practical cybersecurity architecture.
Not so much like enter formal architecture but something practical. And I'll give you an idea how to reduce complexity.
Building and running cybersecurity in both worlds. Modern cloud security and combination with legacy on premises introduces extra complexity. I think this one had already been discovered and some of the well known security patterns and models are not applicable in cloud systems where the modern security models barely fit into the legacy systems all over zero trust and based on a model for security classification, we will explore some loose and don'ts in modern cybersecurity.
Here we go. So important note, all models are based on well-known practice and general knowledge and all examples are completely fictional. So sketch number one, I'll first do an introduction of basic cybersecurity model, which means if you have a something to analyze, if you want to make a discussion on the cybersecurity and cyber architecture situation in your company, you first find actors interaction and services. An actor can be a person or it can be a service, which means a machine.
And the cyber device you are accessing can be any cyber device, it can be a system, a service, a machine application, an enterprise resource. We don't distinguish that and we'll have some kind of interaction here. Next thing is we'll define a boundary of our cyber system. We want to analyze. It could be the system could be made of one piece like an old fashioned application. It could be made out of multiple parts, of course it could be a cloud service.
You could put together several cloud services to get an system and then you've got a multi-cloud service or you can have in combination out of an on-premises service and cloud service or your completely hybrid or mixed environment. Important is find a technically and organizationally definable system boundary around the thing you want to check.
So next thing is distinguish good and bad actors and interaction and including wanted and unwanted conditions of the environment. So we put in here the red actors, these are persons or bots or whatever we don't want in our system.
Those are the bad guys. And we also have maybe interaction. We don't want to have like this service is a good service, it's one of ours, but it's trying to do some bad interaction or this user is trying to do some bad interaction and here we got bad condition of an environment, we even don't want to have it. It could be reducing the wrong client, it could be being in the wrong network.
So and if we put this together, we got a very basic cybersecurity model, what I call B C S model regarding a cyber system. Allow only good actors doing good actions under wanted environmental conditions.
That's mainly allow the green stuff and keep out all the other stuff. So we need to analyze, define and control several things. What is good or better? What is good enough? So sketch number two, shrinking the parameter. How is your system border defined? Well if you go in a legacy system like you have in your own IT or in on your own data center, you will probably have a network and then you will have several application databases, directories, computers, whatever. And the system security border will be one large perimeter. It's classically called the perimeter security.
But it could also be looked like this. Maybe you split up your data center and said, well I got a lower secured and a higher security part or whatever and we got some medium size perimeters. It could also look like this. We got many small perimeters because we think we should protect all these small systems in here. Could be even in a cloud, it could be part of a cloud perimeter.
And up today the modern secured parments they telling us we should even shrink those parameters even more so micro size parameters, which goes with the definition of perimeter less or micro perimeter on the system itself.
Well where do you place the security checks? You literally place security checks on the system security border, which means when you're crossing security checks on the border crossing, which means in your single parameter security, you got maybe this point where you're crossing the border. And that's the point here where you will check security.
If you got some medium size perimeters, well you will have more entry points and you will have more to check in the more modern environments with smaller perimeters you'll have more to check. And if you go for perus or microper perineum, you'll have even more points where you have to check security, which means here we can see the effects of the permanently shrinking parameters.
So people keep, experts keep telling us, well the one size parameters out we are doing zero trust, which means we got very small size perimeters and we got a lot of points where we've got to control security, which means if we go to a zero trust security model which says never trust, always verify they placed some vocabulary in here.
And as we heard from the Norwegian speaker before, the vocabulary definition of the vocabulary is very important. So we got in here some little engine, it's a policy enforcement point and policy decision point.
I just put them together because I don't care too much about the differentiation in this PO point. But we also have the policy administration point. And in this model they don't have a a admiration, which I like lot is the policy definition points because someone has to do all the definitions of these rule sets which apply the security up here. So we got a problem for the operating staff because we already, if anyone can remember how difficult it is to have a fireball up here which has only IP addresses for source and target and protocol types.
And you put up a rule set here for the whole data center, which is quite difficult and usually you couldn't cap up. You can imagine what's happening up here regarding the rule sets which are necessary. So the operating staff is quite really questioning who will be able to manage all these necessary rule sets.
So therefore if we take a look at the cyber system from a business perspective, remember my model regarding a cyber systems, we are just looking at the cyber system now step on defining the cyber system, find a technical and organizational definable system boundary and a responsible person from a business perspective because he will have the ability and he's responsible for that to tell you what value is in there. The value is not the computer itself or something in the data center.
The value is the data and the algorithms which are run in here and he the business person should be able to tell you what value is in there. So step two defines business need for protection. Define business need for protection, security, classification for the business content and functions of the cyber system. So we got a business risk, business need for which means business need for protection and that should be defined by the responsible person in the business.
So we introduce a classification for reducing complexity because if we have small systems we've gotta do a lot of defining of the system of the business risk and to make it not too complex for the business person, we put in, I just put in an example, classifications for the cyber systems need for protection. It could be for example in four classes, public, internal, confidential, strictly confidential. It's a very common way to put it in four, four classes.
So now we've got a, now we've got, as a result we've got a cyber system, we've got a system monitor, a responsible person in business and he placed, he has only to make a decision out of four, which is I think a business person should be able to do. We won't come here and tell him, well we got a database and we got all those tables and we need to do some analytics and keep out all the technical stuff. Just talk to him what is the business doing with this on this cyber system? And therefore we got this classification. So next one in my security model is allow only good actors.
So derive quality for actor, that is mainly who is it and what kind of identification is good enough based on the security classification derive the needed quality for identification and authentication of an actor. So we are introducing a classification route for reducing complexity. Classify the quality of identification process and authentication methods which are available in your business. So it could be an example classification, so it could be or I put also four classes, none would be anonymous maybe for public website.
Medium would per the registration process or identification process would be if you have partners or guests. High could be employees or external staff and very high maybe you want to have some additional security clearing and you should derive this from the contract the person is having with your company. And you should add a proper lifecycle process which is for example for employees is usually in the hr. So things should reflect the business relationship between a person who wants to be an actor and your company.
So example classification could be for the authentication, that means none could be anonymous, medium, just use 18 password high. Let's say some implicit multifactor authentication. So let's say he's using the right sort of client or very high could be some explicit multifactor or some extra multifactor or whatever you want to do. Maybe you want to include some biometrics. And so the, this will implicit that the person uses an account and the tech that's for the technical interaction, the person uses the account.
So now we are going back to our classification of the cyber systems need and derive the minimal requirements for identification and authentication for a person and user account maybe will allow this combinations.
So the output will be used for determining the access on the cyber system. It will not replace any authorization inside the application. You'll still have to do this. So we go to step four in our security model. It says the under wanted environmental conditions and we are looking on the impact on the cyber environment.
We are going for a determination of the repercussion risk class for the cyber infrastructure in the cyber system environment. Well what is meant by that? That's quite easy. We got a responsible person in the business. Usually he has the ordering part mostly in cloud scenarios and or we, we've got a responsible IT manager and he's usually responsible thin, thin cause things have an impact on his data center, mainly on premises. Sometimes he's also in stakeholder in cloud scenarios.
That's mainly depending on your cloud or on your company's organization, how the responsibilities are shared in between those two parts. And now we are going for classification on the potential effects on your cyber environment, especially regarding the lateral risk movement. So we'll introduce a classing oops for complexity here.
The rep repercussion risk class for cyber environment is quite a large example. So it could look like this maybe if you got a repercussion risk class low.
The typical environment protection environment could be a cloud provider responsibility, very low lateral movement risk, hopefully protected, secured and controlled exchanged with on-premises for example get with content control and things like that. And the security model which was supplied in these environments is usually zero trust or some kind of micro perimeter.
So you could regard as a SaaS cloud service could be set up like this or Office 365 could be regarded as a low repercussion risk class because no sofa, nobody has managed, if you have one tenant to get access into another tenant of another company. Cause there's a lot of business for the cloud provider to do these protection barriers. The repercussion risk class medium could be applied, applied to a typical protection environment with legacy applications.
Maybe we've got some network segmentation, but we still have legacy protocols.
We have encrypted communication authentication authorization. Okay. And we got so several security enhancement in place. So I would call this security mental and enhanced modernized perimeter. So it's the yesterday's state of the art data center and a repercussion class high is the typical environment is dominated by legacy applications, little network segmentation, legacy protocols, mainly in crypto communication but not completely.
And usually you have something like authentication authorization, that's a classical pyramid, A security model and example is of course the old-fashioned data center grown over the time. And what is left is a repercussion class, very high. The typical protecting environment is dominated by legacy applications. No network segmentation, legacy protocols, unencrypted communication, no authentication, no authorization. Do we have things like this? Yes we have it. And there's usually their applied security model is security by isolation. We usually do not connect them to other IT stuff.
And so it's usually you will find it in legacy ot, environmental operational technology environments.
So if you want to know some more, the security models go for my last year's presentation, I had a whole presentation on them. But so far in case of risk assumption, the hazard to the company's cyber environment must always be considered. So if a business person, a responsible business person is telling you from my cyber system, risk assumption is okay, we don't have to take any measurements.
There's still the responsible IT manager who could be have another opinion because for my cyber environment it's not okay, maybe you got a, not got a cyber system, which is a risk classification of very low. So there's not much protection needed but it's somewhere in here and we need to protect this environment. So we should keep this in mind.
So unwanted environmental conditions, part two, based on the repercussion risk class and the need for protection of the individual cyber system derive the needed quality for the client environment.
So we also do a classification of the quality of the client environment due to that what is available in your company? And it could be like this for example, maybe low is any client medium high, somehow a compliant client but you got software need to check it and a very high could be somehow an extra secured client. And of course all requirements are minimum. So you could push them up and derive needed quality for a client.
Identify dominant criteria like a high environments repercussion risk should always override individual decisions or a high need for protection of a cyber system should always demand a very protected client instead of all do, instead of doing all possibility, all possible combinations, a discussion of the security situation is recommended, at least in the beginning.
And maybe then you can put it together. So put it all together.
Step one, define the cyber system. Step two, defining your business need for protection, derive quality factor impact on analyze the impact on the cyber environment, derive quality for client and put it all together so it can be easily used in your policy enforcement points. Right back to at the beginning. Now we've got a rule set which should be manageable, which we can put in our policy enforcement points and a policy decision points. First we put it in the policy administration point and then in the decision point then it goes into the policy enforcement point of course.
So then you can grant automated access to a cyber base system based on a very, very granular risk basis, but which won't kill you in administration. So we've got five classifications we've got to do, but we have to do them or create them only one time. And for each new cyber system, you have to run the individual need for protection part and you have to determine in which cyber environment it will be replaced. But everything else you can derive from this thing you're doing only once.
Everything else, more or less classification, best derive decisions and hope, hopefully the operating thing stuff is now happy because it'll make us work much easier. So to sum it all up, security technologies and tools keep getting better. They can make security decisions on verifying brain base.
Okay, we've seen that. And out there you you'll find a lot of vendors which are selling engines which can do really clever security decisions. The correspond corresponding rules, sets and policies are getting more and more integrated, detailed and complex. And introducing of modern security models like zero trust and micro perimeter enforces those effects. And with the introducing of this practical model for security classification might give you an idea how to reduce complexity. And of course the model is based on fictional examples, it'll need some adoption to your company's situation.
So are there any questions,
Cindy? Anyone have any questions in the room?
Well, on the subject in reducing complexity, how do you reduce complexity at an already complex system? Say you've got a huge enterprise and you've got yes.
You know, lots of complexity especially around, you know, maybe multiple pap Yes. Multiple policy information points.
Any, any good direction on that?
I would go for, for a classification model, it's, it's mainly the model itself. It's mainly without running, without any technology. I mean it's, it's just building rule sets. Then you've got to have a clever idea how to automate these rule set and put them in the part bits you need in the various policy enforcement points that will probably need some customizing or programming depending on how many policy enforcement points you you have and how, how they consume their rule sets.
But if you don't have an idea how to structure all those policies and rules and to get the complexity out, you will be lost because then it's in a problem with much too much dimensions and can just close the okay, will we get to complex?
Well great, thank you El.
Okay, perfect. Thank you.
