Dr. Heiko Klarl - Everything as Code – Ensuring Compliance and Governance for IAM

So thanks for the introduction. Yeah.

Good, good afternoon, everyone. I hope you had a good time at the lunch that you have not eaten too much so that you are still awake and able to listen to my talk. I'm talking today about everything as code ensuring compliance and governance of identity and access management. Just let me introduce myself. I'm a high core. I'm responsible as the chief marketing and sales officer for IC consult group for marketing and sales, obviously have a big background in consultancy. So probably I know what I'm saying.

I, I see consult as number one in identity and ex identity and access management spending from business and process consultancy through to integration and implementation with our brand IC consult to support and operations for identity and access management for IM works and last but not least having a managed service without regional borders in place called service layers.

When it comes to compliance and, and, and governance, probably a lot of you, especially those in the it departments have to cope with several, several actors in the kind of governance play and the ionist who what, and I just picked out some actors, some roles in the enterprise, which are people being there when it comes to governance and compliance. When you have a identity and access management, a custom identity and access management solution and bring it from development to integration, to production.

So a big stakeholders is of course the information security officer or a role like that, the person having some requirements in regards to it, security to fulfill compliance and governance regulations and the person giving his final approval that everything is is secure. You have the project manager who wants to be on time, wants to have a fast delivery and probably not caring that much about the other stuff. Cosmetic solution is ready. It's ready and should go to production. Cost. Time to market is important and fulfilling. The business needs is very important.

Then you have the application and or product owner, probably not the same person, probably the same person depending on the organization. So the person specifying together with this team, the final solution, what does the identity and access management system cover, which use cases are working, which way, which of course security regulations are written down as user stories to be implemented by the HR DevOps teams. You have the developers or someone from the dev teams are doing all the work, writing the code, configuring the product, staging it from dev to broad.

And depending on your support organization, you have a dedicated support and operations organization, or it's a DevOps ops team where the roles are combined to the same team. But in the end you can always distinguish to now, I, I, I'm working on a piece of software developing or I'm, I'm now caring a production related issue. And last but not least, you have the attacker in place who plays a role. And probably, you know it from your company too, when it comes to a go life, you have to fulfill some form requirements, have to do a lot of paperwork to get some approvals done.

And one of them is a kind of security assessment. There are those funny charts, spider charts, red, green, yellow traffic, light charts. And it's always a kind of paper based assessment and it's completely decoupled from code and it's completely decoupled from your implementation. And when I've worked in projects as an architect, as a product owner, as a project manager, I always fulfilled this stuff, but honestly, I didn't see that much sense. And it costs it's only a chain of trust. So the ISO is, is asking me, Hey, is everything's implemented in the correct way we have encryption.

Do we have SSL in place? Do we have the latest software in place? And as a product owner, you obviously say, yes, I have, cause you wanna bring it to production. And you have in mind, a couple of months ago, I've written down a user story and the team has implemented the user story, but how did I approve it? What was my acceptance criteria?

Yes, I remember it was the screen flow. It looked pretty denied. UX was really cool, but most of the products owner do not go deep into the products conation and check single settings. So it's a chain of trust. The ISO auditor trust the product owner, the product owner trusts the team and the team trusts the developer. But if there is one single failure or error or some single change in place, it's, it's done. And as you know, probably China's visitors in German, still post I have in mind, a Porsche big car, AKA having a good sound, roaring, something like that.

And when I describe it to my team, oh, they're talking and talking at, and at the end, something roaring comes back an elephant making terror or something like, and being completely DEC carpeted from the specification to the end. And this is the big danger. PO thinks everything is implemented in the right way, but probably it's an elephant compared to a portion. Another risk for being uncompliant or non-compliant is from dirty. He and last minute fix it.

So everyone working as a developer and architect and product on a knows the last days, the last weeks, the last hours are very productive and there's always time for our last user story. Cause it's very important and probably last user stories, override user stories from the past, bringing changes in probably are not in that good quality to check really all formal criteria to fulfill all formal criteria. Then you have, when it comes to production, debugging and buck fixing, you have a behavior it's, it's, it's strange.

You have a multi cluster scenario and something doesn't work and what's easy. You switch off SSL. You probably switch off encryption to do network sniffing, to make debugging easier, but probably you forgot to set it to draw after you've changed it. And then it goes directly into to production. And last but not least as a third example, if the deployment process is not fully automated from end to end, and it's not when it's not only code, but also configuration, then you have the risk in a, in a multi-class scenario that most of your machines have the right release on it.

And probably one or two are not configured accordingly, especially if you have kind of manual configuration efforts when it comes to products, which is often the case in identity and access management. And last but not least, you have an attacker probably finding some, some hole in your system and changing some configuration to have the vector open for the future. And probably be most of, of you in the organization do not have a proper quality assurance when it comes to configuration.

So you have driven from your development teams most of the time, pretty grade and pretty good processes for unit testing for testing your software. So you have D different test levels from very simple unit testings to feature based testing to scenario testing. You have test plans, you have a big ratio of automated test cases, but it's often related from the business point of view to features of your product of your system. And from developer perspective, it's related to the concrete implementation.

So you do do tests of methods of objects, whether everything's working together, but nearly no one checks really configurations. And so we have a big trust that everything is safe, but you do not test this and a paradigm to get rid of this dangers when it comes to compliance and governance is everything is code like developers are user, so you can ensure compliance and governance in identity and access management by just coding everything. So simple like that. We tried to, to figure out a solution for that to offer this, this idea and this value to our customers.

We took a best of breed product for identity and access management. We took both or two ping and for truck, we made infrastructure as code so that we can use the full advantage of modern cloud computing in order to have auto scaling in place in order to set up production ready instances, very fast, we made a hundred percent configuration as code ping us a lot of advantages. Not only that we can fulfill compliance requirements, much more easier and a hundred percent automation in order to be a lazy developer, just click the button and everything is deployed and it's there.

So we, we, we are able to have an production ready sign instance, for example, in place within couple of minutes. So 10 to 15, depending on deployment speed, and then everything is there on spec. Is there monitoring?

Is there, the system is hard. The system was pen tested before, and we're absolutely sure that each and every node independent of the size of the final asylum system, whether it's only just a couple of hundred thousand of identities, or if the scenarios are multimillion customer identities, scenarios, it's the same configuration everywhere as it just deployed and COPI. And we name this service layers patent for this is currently pending. So it's a really great thing. And what is behind that and how can we ensure with service layers, this, this compliance issue.

So I, that configuration as, as code I here chasing snippet from, from an sign tool, configured everything of the product is configured in chasing. So it's code and I can handle this code as developers are used to handle code. So it's not nothing more that I have to click in UI, or that I have to modify some database settings or some configuration files in place in very modern and mature systems. You can put the configuration via arrest endpoints into the systems. Then it's very easy to deploy them.

You can put the configuration into your code repository with having all advantages of the code repository. So you can bring in environment dependencies between having different configurations between development system and integration system and production system. You can do versioning. So you know exactly when a version of your configuration file of your basic product configuration has changed. You can tag them, you can merge them, you can release them. So it's at any point in time, absolutely clear which configuration has been deployed to which, to which environment you can make this.

So if there is a change probably through to a buck fixing or hot fix, if there was an emergency change ready, needed in production, you can just take the diff on the whole release and you just figure out, okay, I've only fixed that buck. And the basic configuration is the same, so I can blow it out to production immediately. And when everything is, is there as code in a repository, and if everything is automated, and if everything is attacked as a release, you can deploy daily.

So if, if a attacker, as I shown before attacks your system, it might be probably there. If you deploy your system each and every day or a couple of times a day, at least he has to begin every time from the beginning. And you are sure that you have absolutely the right release on the production environment when it comes to testing your configuration. I said before, probably a lot of you have, have highly sophisticated test scenarios for your, your production software, for your, your features.

And it's often big effort to describe the test cases, but often those test cases are not written and specified for configuration. And the question is, why not? When configuration is code, I can check my configuration and I can at least do some basic assertions. I can integrate at least some diffs from finally approved configurations, enabling you to have real test cases. Then your test COPI like here in JIRA is not only related to your features and that your features are working fine.

It's also related to your configuration and to your code, that that it's in the same release and that it, that it's fitting. So a pretty easy approach. Obviously you can take it also without service layers, but have in mind it will increase your transparency for the ISO probably enormously. And in Germany, we have the saying is good controller is better. I had tried to translate it and talk to my, my English salesman. And it seems that the, the English people do not have an equivalent or similar sayings. So they are really poor people.

Cause that's basically a, a very good saying, cause so for the English guys here in the room, it's kind of trust it. Good, but better control, but better check. So basically why should your security officer, why should your management taking probably enormous amounts of risks or financial point of view?

So imagine the penalties that are threatening your enterprise when it comes to TPR violation, when you lose customer data cause of misconfiguration and you read it nearly every week that some big company around the world had a database completely open in the internet that customer data have been stolen or lost. And it's often just done just, just an accident. And so it makes sense to establish this chain, to get rid of this chain of trust, but to establish a setup, doing professional checks from end to end, what does this mean for your information security officer and, and for your team?

So we, in the past, I had it in the first slide you have just filled in some X lists and have this, this, this chat couple of, of times before I go live, everything's fulfilled. Everything's okay, let's go forward. This is green and this is not yellow. You can move to a much more trusted level and, and establish those checks. So basically you can describe all your compliance requirements in user stories, probably stakeholders is the product and the application owner. Another stakeholder is the ISO. Another might be your project manager, your TPR teams, and so on.

If it's in place in the user stories, you can derive dedicated test cases out of it. The development team has the requirements there. They have some test cases there. They can implement the tests and figure out how the production configuration has to look like. So which settings have to be, be activated. And so on when it, it comes in the, the last time of the, the integration testing phase, you'll often have an external penetration testing. You have probably code reviews in place and the ones, or you can check your configuration.

Probably one of the last times you can include all the findings found during a external penetration test, and then probably everything is fixed according to the knowledge you have of today. So your team has checked it, the penetration tester has checked it, all the requirements defined are green. Probably you have, have also a talk to the vendor. The vendor gave his checkmark and everything is fine. Then just put in the, put it in the repository. Its thought there target as the release version.

And when the configuration is changed, without any reason, the build can break, there will be no deployment. And then you have to think about, is it really a cool idea to change this or that? And everything will, will stick to the same standards. Obviously you have to think on the different kinds of the configuration. So you have basic security configuration the product, but also when it comes to workflows or some attributes extensions of some object classes, this might be handled separately. But then the base configuration is there. You have everything checked.

Everything is, is screen and horizon has not to provide and not to receive just an excellent document. Showing green traffic lights, it's much more than he has a really defined end-to-end trust chain. And he is able at each and any time to check which configuration is on production. Was there any change? So you can have the function of an audit in a very different kind. So you can audit your systems healthy and your systems, safety and security much more than in the past. Cause it's, it's nearly no work. It's just making a diff of, of configuration. So basically it's about compliance.

It's about governance and it's not about trust. It's about code. So the truth is in the code. There is no reason that you trust each and every co you have this big chain of trust without having a connection to the real code. It's about the code. The truth is in the code and you can use all the developer paradigms you have when it comes to normal software development.

Also when it comes to configuration of identity and access management products, and I was a little bit faster than expected, which is good on the one hand, cause we have enough time left for a couple of questions or was my slot only 20 minutes. I do not know it exactly. Do we have time for questions?

Yeah, we Have time for questions. Great.

Any, any questions? So take care. If you do not ask your free chairs for the final exam. So we will use the last five minutes for doing the examination. Okay. Great.

Well, thanks. You're welcome.