Identity Security Implementation and Deployment in KONE

Hello everyone, I'm ato. I'm security engineer slash configuration owner for Kona and he's Krishna Ballen, solution design owner for identity and access management at Coney. I'll just give you brief history or a short introduction about what Kona is and then we can move forward with the presentation. COE is more than a hundred year old elevator company. We are based out of Helsinki, Finland and I couldn't agree on what the last presentation was that you have to be matured enough into the system to realize how you have to make your way forward with security.

We have been sorting out a lot of legacy stuff and we are into a mature state right now in that journey. With that, the today's topic would be how IBM supports cybersecurity at Kune and how we are leveraging it. Basic footprint about Coney IBM is we have 65,000 plus users, more than thousand plus application and more over 12,000 non-person accounts in the system that we have to manage today. Considering this footprint, you can calculate how IBM is managing the volume of those system right now.

We'll be discussing in today's session that how IBM is supporting identity security, endpoint security, application security and detection and recovery and all these components are equally important in cybersecurity to take care of focusing on identity security. Every organization has a user identity and we have classified all the identity accounts here as user considering regular account tier zero account for the user, tier one and tier two. These tier accounts are Microsoft's suggested privilege access accounts which are categorized in this system.

We also have a tier three account, which is COE system custom account and has the least level of access. So when you see the approach flowing from top to down regular ad accounts as general account that we have, tier zero one and two, our Microsoft model accounts, tier two being the highest privileged accounts tier one, the moderate privilege account, which will not have the complete access to the infrastructure tier two account being slightly leased, privileged account of all the Microsoft model tiered account that we have. Tier three will allow you to elevate access to your own workstation.

We'll be focusing about how regular ad account works in general and when we consider identity security. I believe identity management goes hand in hand and we, we have a lot of other things as well that we focus authorization being the first part and Martin was discussing about how this airbag and segregation of duties and policy violations play an important role for any IDM system. So I couldn't agree more than that. Suppose I am an outside user, I'm into the system and I want to just trick into the system and I'm playing around the organization.

These factor will definitely help me to stop gaining the extra access that I should not be having right now. So there are role-based access controls along with attribute access controls in place and if I anyhow tries to gain access to the system, there's always notification system in place which will send notifications to your manager, the request you or the requester. We have strong auditing and monitoring in place. For example, I work in Helsinki and I'm requesting something at really odd time for a longer period of time.

It'll generate lot of logs, audit evens and fil send it out to the monitoring system so it's smart enough to understand that something is going wrong and generates alert to the security team to take the further actions. We also have periodic access review and segregation of duties in place to make sure that the user has right level of access at right time. Moving next, we have authentication in place. We have been hearing a lot about authentication in all these three days that we have been here. It is a very generic thing that every organization or enterprise should follow.

So authentication comes hand in hand. Any application that we own at Coney is lying at the backend of single sign on. So if you have to access the application, you have to log into the application which will ask you to authenticate password goodness is being the equal important component for it. You log in to the application, it'll show you to the authenticator being the push services available in this system that you have to enter the pin which is being displayed on your application along with the application name so that you are sure that you are into the right application and it is you.

It also validates the user geolocation and if it is correct and user validates it, it allows you to log into this session. We also moved now to detection and recovery, which I believe is the most important phase how you can utilize your IBM tool, any user request access to the IBM and is granted in ad. But what if any access is modified in active directory. So we have utilized our IBM system in such a way that it reconcile, it reconciled the accesses from active directory to DM system.

Along with that it generates all the logs, all the events status being done in active directory and we automatically the access correction from our IBM system, which means if any outsider has access to their active directory or trying to do any modifications to any of these four things that I've listed to the attribute to groups. By creating new attributes, accounts or members, it flows to the IBM system and IBM's detected and automatically corrects it Whenever there's any event which is generated and anybody tries to get into this system.

We have configured SIM system in such a place that it is configured on the IDM side as well as on the active directory side. So any events which are generated generates the event which is being received on the security operation team and security operation team has access to the IDM system both through ui, also through APIs to perform any emergency action that they want to. I just want to have a look with audience as well.

How many of you are doing emergency actions on the accounts through your I DM systems That's so great to see or all right so they can emergency disable the account, enable the account and also the password reset in case of emergency situations and whenever any action is taken we generate the audit event also notify the manager of the identity that something was wrong and the action was taken Now let's see how I am is supporting endpoint security and application security. So as mentioned there are a lot of tiring models in place and we follow a custom tiring model as well.

Now let's see how this Tire Zero is supporting to access all the privilege accesses within Connet. So as Akashi mentions, we already have a multifactor authentication in place but for privilege accesses we have a separate MFA infrastructure in place and it is a kind of a step up MFA which decides what kind of MFA is required based on the type of account the end user is using. And all these tiering accounts are managed lifecycle managed by IM system.

So if I need a tier zero account, I come to the IM system and then request for access and once it is approved, tier zero account is created for the user and the password is shared. And let's see how the user is accessing these C zero resources in connet. So for TA zero, the MFA is basically a hard PA key which needs to be entered while logging into the system. So user enters C zero credentials and it asks for PA key. So once the PA key is entered, you'll be presented with the list of resources which you can access.

So basically taser is high privileged account which you can use for accessing your 80 resources and whenever I want to connect to an 80 server, the pan system creates a short-lived certificate or an FAL certificate for added security and it allows you to log into the system and when you go to the tier one, so tier one is less privileged when compared to tier zero and even it has a separate MFA infrastructure.

So whenever I want to log in using a tier one account, so you log into the system and it presents a normal mfa which is basically a key based and you can use any authenticator app for authenticating yourself. And Tier zero is basically for accessing all these application related infrastructures like an application server or a database or any proxy servers.

So based on your accesses you have within the IAM system, the PAM system allows you to see the list of resources you can access using this access and again it generates a shortly certificate which enables you to log into the required infrastructure. And all these logins are fed into a CM system for activity monitoring and which ensures that if I am logging into the server outside this SPAN systems, it creates a security event and based on the critical of the security event, the CM system decides whether the account needs to be disabled or what should be done for that kind of account.

So that is actually handled in the CM system. And when it comes to tier two, so tier two is actually an admin of all the workstations. So basically the operations team have helped this team who wants to perform many admin activities will use this tier two accounts and it is again lifecycle management tier two IBM system. And when it comes to tier three, it is basically an admin access to your own workstation.

So if you need to have an admin access for a short period or for permanently, so based on the business need, you'll request for a permanent access or a temporary access and once it is approved you'll get this admin access for your own workstation. Okay. And let's see how this application security is supported for by the IBM system and other infrastructures which we have in connet. So CMDB hits a configuration management database which is owned by the application owners of coe. So application owners are responsible for updating the CMDB with the proper status of an application.

For example, if a new application is created then I say a new application is created and that needs to have an authentication complaints and an authorization complaint. And there are set of standards which are defined within Coney to ensure that a specific application is authentication complaint and authorization complaint based on the usage of the application are from where these applications are being accessed.

So if I'm accessing an application from internet, then definitely should have an SSO enabled and there should be an MFA supported to ensure that it is an authentication complaint and if it is an internal net application it can be accessed only using an internal network. It is fine to have a user M and password based login, but you should definitely have an MFA supported. So those are the standards which are set within Connet to ensure that the application is protected.

And there are other features which are supported by using for authentication compliance within Azure, like the user activity monitoring to ensure that the user is logging in from the same IP are from the same dual locations and what should happen if it is a certain login at the midnight or from a different geo location, what should happen in that and should I have a conditional access policy for the application based on the risk of the application and for authorization compliance.

IBM system ensures that these applications are onboarded into the IBM system for access request management, access reviews, and we embrace lot of self-service within the IBM system. So basically self-services for managing roles, application owners will have the capability to manage roles within the IBM system. So you don't need to contact a help desk or an operational team to create roles or manage roles. You can do it yourself.

Alright, thank you Krishna. We all have been discussing about how identity and the security is very important, but nonpersonal accounts play equal and important role in any organizational enterprise that we work in. We'll be seeing how Kona is managing Nonpersonal accounts from I DM system. We have four categories of accounts that we manage at Kona, test account, shared account, robot account and service account.

So these all accounts are lifecycle management and owned by somebody because it's really critical to own these account otherwise people le leave the company and these account remain active in the system which open a door for attackers to come. So it is really critical and important for any enterprise that we have. I would also like to ask that, how many of you are doing account hardening from your IDM for these accounts? Anyone good to see one? So two important confidence that play important role for these non-personal accounts are account hardening as well as password management.

IBM system generally generates password for any account which comes into the system or any identity which comes into the system. But all these components are really important to be managed. So by default we make sure that all the RDPs and all the interactive logins are blocked for all the non-personal accounts. And if you have any purpose to do it, you'd come into the I DM system and temporarily remove access for it. When I say temporarily remove access, it removes access for the account for 24 Rs and it'll be reapplied by I D M system.

It'll also generate logs and events for the same event which has been performed. There's also delegation block and which is available again for the account owner, which is by default blocked that you cannot delegate your account to perform any activity as such. Then we have log on machines, so you have to define that for example, there's a service account which connects to to our server. So you have to define that to which log on machine you need this account to be enabled. So whatever log on machines are defined will be allowed by that service account to log into the system.

We also generate complex password by defaults, but it also gives us password management capabilities to account owner to manage and generate the critical password through IBM system. Once this password is generated, it is never stored in IBM system and the events and the notifications are also generated to the account owner and also to the deputy account owners to make sure that something has happened and it's valid. I think that was all that we try to implement at Coney with all the red teaming and proper teaming exercise that we conduct every year.

So we make sure that we improvise and implement things including identity and access management. So that Leaves for questions I would say. Any questions from the audience in the room? Otherwise I started with the online questions.

Okay, so I start with the online questions. Do you have a common IBM system for all target provisioning or is this a distributed system in different with different tools? So an example would be one for Azure and the cloud and one for on-premise applications. For example sap.

Okay, I can answer that. So we have a common system that manages all the provisioning from our IDM system. We connect to on-prem as well as to cloud system. So we have connection with all the SAP active directory disconnected applications as well as Azure waste applications. Good. Next question. Okay. Isn't it a bit dangerous to manage tier zero accounts with the DM system? If the DM system is compromised? The tier zero is also compromised. A very Good question and sorry that I did not mention it earlier. We do not manage tier zero through ibm.

It's separately managed, but there's a pan system involved, which Krishna was talking about that allows you to log in using your tier zero account. But we have a lot of hard tokens available and a separate login mechanism for two zero in place. So creation is not through idm but lifecycle management is through idm, like levers 40 zero through IDM manually. Okay.

Meanwhile, any questions from the audience in the room? Good. So I continue with the online questions. So you have explained your PAM strategy question would be how would would it adopt to emerging threats and technologies? So it uses ephemeral or short lived certificates, which is which leave only for three minutes of the session. And then once the session is established, you cannot reuse the same certificate for logging into the same server.

So that's the technology which we're using right now and we feel that it is most secured right now and the even the MFA used as a separate infrastructure, it is not the Azure MFA infrastructure and our teaming exercises shows that no one is able to log into gain access to PAM till now. So that's benefit we have right now. Okay. Process wise, are you taking a look at that once a year or twice a year to, to see if that is still a valid strategy for to encounter those emerging threats? Once a year. Once a year. We Do have blue tubing exercises twice a year. Good.

So those are all the questions that I have from the online audience, so that would be the last chance for you to ask more questions if that's not the case. We're done with your presentation. Thank you. Thank you so Much. Thank you. Thank you.