431 years was the timeframe it took to debunk a state level privileged escalation in pre-digital times. So the story is to tell in IG terms, that was a reorganization. The Emperor Fredericks, the first had to shuffle people around and he created a document, a valid document, the minor privilege to raise Henry II to, to at duke. 200 years later, the Habsburg we're now steering Austria, this age child, or I would say ambitious man, thought the new constitution of the empire wasn't good enough, so he needed more privileges. So he took his finest artist to forge some new privileges.
A document this historians called the Major Privilege. And he went to Charles, who used to be his father-in-law for recertification. And he was, that was dub years.
So he, he rejected, unfortunately he died quite soon and his son Sigman 20 years later in some deal, said, well, it's okay. You will be Ark Duke and inherit a lot of privileges with that. And it took another 400 something years until the German scientist really debunked that as a fake document.
Anyway, it was gone by that time nap. Holy had met a clean state after dismantling the Holy Roman empire, but for Austria was quite good to, to raise to a major European power.
Now, fast forward to these 21st century. So let me go through some major patterns and particular antipas that we encounter frequently in, in large enterprises. So lemme start with number one. So architecture seems to be a little bit out of fashion. So frequently customers come and say, let us select the product, elicit a few requirements, and sit and, and let it deploy. So product first, architecture second, we know that architecture in the past has been bloated and inflexible, et cetera. And time boxed projects with prioritization are quite in favor with upper management.
This is quite understandable, but you have to know that you buy some problems with that. So I'll give you some examples. One is the 80 20 approach. So if you try to, to focus on just your applications or targets with high protection need, like my SAP, my active directory or whatever, still you are not complete.
If you have done that, you, you have to, to be safe against lateral attacks, you have to do the, the full exercise.
So even if you do this 80 20 approach, you can use these goals to measure the progress on, on your program, but you have to have a clear vision, what is at the end of, of your program, which is a complete coverage of your privileged accounts. Insufficient readiness. So a typically example is in a distributed company with divisions and countries that people have two accounts, one for local services in, in their country, and another one for central services, which may be, again, distributed across countries.
When you want to integrate that by moving to a cloud service or centralized directory or implementing an a, a centralized MFA or SSSO solution, you, you run into serious security problems, data cleaning problems, management problems with multiple MFA tokens and management. So you really need to assess readiness before you do a major rollout. Not do just in let's say the headquarter country and, and replicate that to subsidiaries because you will run into troubles later.
And technically that is always a problem.
The long, the longer time you wait, the, the deeper will the byte will be. For example, if you do a PAM solution in parallel to an IGA solution and credential management. So you just latch on a new MFAs solution, like a strong one with which is non fishable, whereas your standard MFOA solution might be just OTP, which is fishable. And then you run into problems that your users will have two sets of MFA tokens to methods to manage them. So you really have to, to communicate all your technical steps in to your management when you, when you start such a project.
So we, you don't lease miss the, the, the final goal. So how much architecture do you really need? So I would definitely not recommend to start with OV or, or any other of these major frameworks.
See which questions your stakeholders will ask. So probably they won't tell you anything, but you have to imagine what is important. So doing interviews, illicit requirements, so you understand what what is the, the pain point in each area. And then here is in a set of baseline example questions, what is my service catalog? How is it categorized?
How is the structure and the patterns in entitlements and accounts? Who do I have the complete metadata to, to know the ownership and responsibilities for my privileged accounts and metadata? Do I have a proper tier model and isolation model? How does it relate to my compliance requirements? So now we arrived at the point that we agree we need some architecture, just writing, painting a few boxes and lines will not answer a lot of questions. And frequently there is too much intention and incompleteness in in all these things. So you should do it properly.
This is a complex topic, but let's start with a precise scoping so you understand which domains, which technology, which user groups which identities internal external B2B B2C, business to enterprise, business to government.
Yeah, so which, which parts of service catalog, which security protection needs. Once you have defined that for your program and for your current project, you start with use cases and requirements. You don't need to reinvent most of them.
So the, the big deal of that is already implemented in, in a typically PAM product and there will be some which have to be clarified and then you do a proper process definition and there are various data views, distribution, data cleaning, data migration, deployment components, diagram as you do in traditional architecture. So try to reuse existing models, it'll save you a lot of time. So my message for the first pattern, maga,
The second one met Graves in yesterday's keynote already argued for integrating IGA a and Pam. So I won't dwell a lot of on that topic.
Just to, to paraphrase that there are some good, painful reasons why you would do PAM and IGA in parallel. So let me think of a concrete example. I'm not telling any names that there is a a, this audit coming up by the end of the year and you don't have proper IGA processes and you don't have a real PAM solution, sorry, doing IGA first and Pam second is, is a recipe for not meeting the deadline. So you will, you have to do something in parallel, but if you do that in parallel, keep in mind you do, you are not doing it properly.
So you're typically, IGA lifecycle objects are not properly managed.
You have disconnections manual processes, disparate data access granularity might not be good enough. So you have to plan a second step.
You, you do it in parallel and then you go through the onerous process of integrating those. 'cause finally you need proper processes and integrated data sets. Number three, isolation patterns.
So the, the, the baseline metaphor of privileged access is that your staff has access to standard services and systems and your administrators in addition have access to your administrative zone. Then there are service accounts, et cetera. Technically accounts, non-person entities in this administrative zone and every other access should be blocked. I think we all agree the, the basic ideas very also every operating system is split in a, in, in a kernel in the user space or in, in different kernels models or whatever.
So you're very careful and paranoid about this high level, high secure, high privileged zone and you have less owners to, to prove security in your standard functional side.
So the, the three tier model has been around for some time. Actually it's already deprecated by Microsoft, which used that a lot.
The, this is a Microsoft picture, so it is very centric on Microsoft technology and the idea is you have some privileged access workstations and accounts which always work under a specific level. So it's already some middle ground between a high security and a good security model. So high security would be that you have a separate smart code or UI key on an extra hardware in a separated network for a separated domain. And so you are almost air gaped, well almo almost kind of, so this is already quite good and you can add some granularity and different structures and whatever.
So once you have defined such a tier model to separate particularly the tier zero where you have, where you control enterprise wide access decisions, you have to educate your peers and your users that a standard workstation is not secure. Whatever security E-D-R-X-D-R software you have on it, yeah, you, you, you cannot really control Microsoft teams and email and completely open web access in in the browser. This is just wishful thinking. And unfortunately we have seen that this is not, hasn't really arrived, arrived yet in, in the industry.
So a standard workstation is not a piece of equipment you use to administrator administrate your crown jewels and your server and at least two directive for example say this very clearly. It's just not allowed. So S-S-H-R-D-P your favorite remote terminal access software or remote access software is not compatible with this line of applications on your workstations.
These need to be different devices. Two solutions for that one is the privileged access workstation, which was quite popular actually. It was used secure administrative workstation before Microsoft invented the term.
And, but it has been somehow downgraded. So Microsoft said, well don't use Sebastian ad because that's so complicated. Don't use the separate hardware, don't use the certified hardware 'cause it's complicated. So it's virtualized. So it was somehow downgraded. Still a good solution if you know for what, what how you are doing it. The alternative solution is to have a jump post or however previous session manager or whatever your favorite PAM vendor is calling that. And the champ host is a hardened device. So there is no open browsing email.
You don't track your time or, or do anything else on, on the champ host. This is really a hardened, least privileged system. Once you have that setup, you need to hunt for the antipas like bypassing this jump post or not having strong multifactor authentication. Strong is non fishable. So OTP is not good enough. Really strong multifactor authentication.
These jump posts are maintained by a centrally controlled policy. So this is not nothing decentralized and the champ host is following what IG is telling it with regard to roles and and entitlements.
So your IGA system must be tier zero as well because they are the access decisions. You can combine them. I would in in, in high secure environments, I would really argue against agent based solutions. So there are some kind of isolation. A protected agent within the standard workstation has a fairly large attack surface. And if you really have a higher security requirement protection requirement, you should think about adding a few POWs to to HM post.
But some, there are some trade off in security and usability.
Number four SSH has a, well, it was really the resolution about insecure FTP and talent and, and and related protocols, unencrypted protocols at, in the end of the nineties. So it came as a real good thing.
However, the, the default method we are using as SH is not secure, at least in large environments. So users manage their own private keys, they can entitle private keys to on, on the, in their target accounts. There is no expiration, there is no no recertifications. If you compare that to traditional password based policies, this, this doesn't look very good. This is really paling security wise. In addition, you can do a lot of things with SSH, which subverts all the isolation efforts, particularly tunneling and credential forwarding.
So you, you having a credential in your standard environment, which is not as protected as as it should be, and you're forwarding it to let's say a tier tier zero target. So this is not the idea of, of real isolation. So you need to establish a proper SSH policy to have centralized key management to avoid trust and first use for servers and, and yeah and a secure configuration which is allows tunneling and and stuff like that only in exceptional cases.
So I'm happy to take questions.
Thank you very much.
Interesting and deep presentation and we do have some time for questions, so please raise your hand if you have one. Anything from the online audience there. There's no question from the online audience.
Yeah, well I guess this is that kind of presentation that you have to sleep on upon a little bit and then come back with probably a hundred of different questions. Yeah. So can we reach you so
You can contact me on LinkedIn at, and it's at KPMG at, so feel free to, to send me emails.
Okay. Awesome. Thank you very much.
Thank you.
And then.
