How to Minimize the Blast Radius of an Attack?

Thanks, everyone. Thanks, Matthieu, for the introduction. So my name is Michiel Stoop. So is this presentation an evolution or revolution? It's up to you to decide. So it's cyber, yeah. So on the first day, I was in an interesting discussion about the workshop from Christian Hack for the Hacked, about 72 hours nightmare of the CISO. And of course, now it's hack the flag there. And of yesterday, also people hacked the gamification. So Christian should have some nightmare now how to prevent that. So it's really about how to minimize the blast radius of an attack.

And how are we going to do that in Philips or how we have done that so far. So I'll zoom into the risk, the requirements, and then how we minimize the blast radius. And I also give you some lessons learned, which you can take away with you. So first about Philips. So probably you all know Philips or who has some Philips products at home. Excellent. So Philips has been founded in 1893 by Gerard, Anton, and Frederik Philips. And since then, of course, we make still groundbreaking innovations. But as products come and technology goes, the same is for the company.

So as you raise your hand, you have Philips products at home. Philips is not Philips anymore, as you know. So we don't have television anymore. That's part of TP Vision. We don't have light bulbs anymore. That's part of Signify. And lastly, we also don't have home or kitchen appliance anymore, because that's part of Versuny. So that's all branded licenses. Philips is nowadays a company which is focusing on the healthcare sector. And therefore, we are health technology.

But still, we are creating meaningful innovation that proves people alive. So we strive to make the world healthier and more sustainable through innovations by improving the life of 2.5 million people a year by 2030.

Yeah, and how we want to do that in the center of our strategy, we consider the people entire health journey. So you're living at home healthy. You're doing your sport activities.

Therefore, we also provide products which are part of the personal device. So think about, for example, a toothbrush that you brush your teeth very well, that you don't need to go to the dentist. But in case that you get some diseases, you need to go to the clinicians. And therefore, we also provide products and services so they can do some diagnosis on you. And therefore, we have the precision diagnosis. But also for treatment, not threats. That's something else which I will discuss later on. So the treatments, we have products there for the image-guided therapy.

So once you had your surgery or whatever, and you're recovering, we also have products for you to monitor at home. That's our connected care. And if you fully recover, then of course, you're back at the beginning and you start healthy living. So if you look at this picture, there's a lot of identities and a lot of data. So if you look at the risk which we have in Philips, where do we really need...

Oh, it's not moving. Yeah. So where do we need privileged access management? Because privileged access management is key to protect our intellectual property so that it does not get stolen. So we need to focus on, for example, the enterprise R&D and manufacturing. That's also our scope for today. I will not focus on the products and services which we have because they are mainly at the customer side. So they should put there the controls. It does not mean that we need to have access to these. But that's a different story. So if you're looking at Philips, we were really at risk.

So we're sitting on a ticking time bomb. So how did we define that? So we have a risk model defined in Philips. We sit together with everyone and we put this really at the top corner. So the top corner means it's in the bomb zone.

Basically, we need to stop working now and really focus on the privileged access management. So, and why? What are then the risks which we have identified?

Basically, we didn't even know what people were doing in Philips with the privileged accounts. Where are these privileged accounts? Who are using it? Why are they using it? Why are accessing these services? We don't have the feasibility. So what do we need to do? People have excessive access. You have people, for example, for 40 years in Philips which are system administrator. They're leaving the company and then they say, oh, let's make a copy, a user copy of this person to a newbie who just started in the Philips organization. So give all the access rights for 40 years to one person.

So we needed to change because we, it wasn't just, we needed to wait till the vulnerability which we have will be misused. So it was just a matter of time.

So, and we needed to prove this as well to our management. So we needed to quantify this. So we sit together with our risk and compliance department. From a security who are doing assessments within Philips and we collected all the information. So we do not have for 53% control over the privileged access 40% of the access was never revoked. So you're just collecting, collecting, collecting all the information, also the privileged access. We never reviewed those authorization or never for 60%. So that's quite a lot.

If you're looking at Philips as the organization, people have default passwords or if they had passwords then they didn't comply to our password in complexity. So this was for us, it's really the red flag.

Okay, we need to define a strategy and to mitigate the risk which we have in our organization. So what are the, and before we will start more into details it's like I'm going to focus on what is then a type of privileged accounts. That was the first discussion which we had internally. What's the definition of a privileged account? So we sit together with our vendor, which we selected but also with analysts, for example, like Coupang and Coal which are in the market, but also with others to get a definition of a privileged account.

So if you look at it, you have a person who has a personal account, you have shared accounts. I will zoom to that more later on. We have service accounts, so that's interacting between the machines, for example and you have personal dedicated accounts. Some other people called functional accounts where you can assign these privileges to. So that's not assigned to your personal account.

So one thing in our policy, we also define is we don't want that privilege access assigned to a person, to a personal account because they will do phishing, for example they steal the credentials and then they have directly access to it. We also don't want to have a personal dedicated account because then person also gets still too many access rights assigned to these. So based on the decisions we choose for shared account and a shared account is a principle which you're using in our password management solution, a privileged access management solution.

And that's really focused, let's say more on a local account. So if you have different kind of accounts, we focus on local domain accounts you can have but the shared accounts, we don't want to add a domain account because again then everything is assigned to one account. And if that's still only you get everything access to. So we focus really on local accounts which are specific on that system with very minimal permissions what is needed. I will explain that later on.

So here on the right side, you see examples of different kind of privileged accounts which you can map them to shared accounts or to service accounts principle which we are using in Philips. Now what's then our strategy to mitigate the risk and the threats we have identified. So first we define the capability maturity model. So we have our capabilities and we define that in identification, authentication, authorization, privileged access management, part of authorization. And there we define capabilities. So these are just capabilities which we have on the privileged access management.

So privileged session control, store the credentials in a vault, secret management on also do analytics and response. Another thing is personal password manager. So we also want to, that's also part of it. So store your passwords in a personal password manager not an Excel spreadsheet or OneNote or wherever you want to store it. You need to offer also people personal password manager and point privilege management. And here's the endpoint and the laptop. So no one in Philips should have local admin access on their device.

And where we have today discussion with Paul Fisher about cloud infrastructure entitlement management. So it was a good and great discussion which we had. So also need to have that in place. So these are the capabilities and these capabilities we link to our controls and the controls are defined.

Yeah, are defined on, we call it Philips security framework. So there are policies, standards and baselines defined. And that's based on the Cisco critical controls to NIST for example or the ISO. So these links, so the capabilities we link to controls. And then we have as well using the threat models and the threat model which we have is Dimitra attack. So now we have a complete picture of all the attacks which we have in organization, the risk which we have and how the capabilities and control can mitigate this risk which we have.

Now, what are then our requirements? So we want to segregate and integrate all the development tests, acceptance and prediction environments, so the DTAP. Segregate the accounts, you do not assign the privilege access to a personal account, personal dedicated account. So only provide them based on least privilege or even assign them only when it's needed. So non-zero standing privileges. Enforce multi-factor authentication. So if you want to get access to it, you always need to enforce multi-factor. So every count is protected with multi-factor authentication.

We need to discover all the privilege accounts which we have in the organization. So we need to discover them, we need to store them and also rotate the passwords. Only provide the access when it's really needed. So just in time. So if somebody needs to have access between two and three o'clock, for example, for doing a patching, he will only get that access in that period of time and only the privileges which are really needed. We will monitor it and record it. So we will monitor what the person has done.

So also if there's some threat, for example, identify that we immediately can identify and respond to the risk which we have. But also record. So in case of a security incident happens, then we can watch back the recording and see what happened during the session so we can take the needed actions. Then we have, of course, the secrets. So that's more for disconnected applications, store the secrets in a secret fold. And for your personal, what I already explained, store them in a personal password manager.

Now, what did we do then to minimize the blast radius of the attack? So you have then the person who has an endpoint where we have our endpoint privilege management installed. So people do not have the local admin rights if they want to request access to install some software, they reach out to the service desk, they will help to install the software, and then the privileges are removed.

Then, of course, your personal password manager and for the secret storing it. And then we have this stack for application platforms and the infrastructure. And the infrastructure is also the routers and the firewalls there, but also the cloud like GCP or the Azure cloud. So somebody wants to get access to that.

Now, how do you get access to it? So you integrate with your IGA solution. So you will go to your IGA solution, you will request access to your PAM environment. Somebody will review if the person should have access to it. And once it's okay, you will approve it and you will only get access based on the role which you have. So then you get access to the privilege session control and the privilege credential storage, our capabilities which we have. I'll explain more.

So you will log in with your Philips account or federated account which you have because we're using a lot of managed service providers. You authenticate to the privilege session control.

There, we are going to enforce multi-factor authentication and also check if you comply to certain conditions. If that's all fine, then you can log in to the dev and test environment based on your role which you have to do your activities. If you want to get access to the QA and production environment, that's not allowed. So we are using local admin accounts, what I already explained with the principle of shared account. So you need to request access via our privilege credential storage. Then somebody needs to review if you should get access to that specific account.

And yes, to do the activities that's approved, then you get access to that environment. So the person is now on the environment, he's doing his activities. It could be that he creates a new privilege account for himself to bypass all these controls. And that's what we also want to prevent, of course. So if you create this account, we should discover it. You should automatically onboard that account. We should rotate the password so we cannot use it. So if he's going to create his own, let's say, network account, that we automatically want to rotate them.

If your session has ended, so you use this, the local admin account, session has ended, afterwards, we rotate immediately the password so you cannot use it anymore. Then we have also our IT services. And that's, let's say, for machine to machine. So we have a vulnerability scanner running or a service now for our CMDB scanning. So in a certain period of time, your account will do a check-in automatically without user interaction. It will do its activity. It will scan the environment, store all the data, will do automatically checkout, password is rotated, and there's no user there.

Then what we currently have implemented is our cloud infrastructure entitlement management solution to get inside what the risks are in our cloud environment. So what's the risk which we have in our Azure environment? What is in the Google Cloud environment or in AWS environments? So what kind of privilege do those people have? Maybe they have full-blown access to everything. So we need to mitigate this risk. With the Keem solution, we get these insights.

Anyway, Paul Fisher wrote a great article about it and it's posted now on the Koeppen.co. So, and that's the one we discussed today in our session. We also want to integrate the Keem with our IGA solution so people can, so we create the visibility from end-to-end on the identity. So we create full overview of what a user really can in the IGA solution. And if somebody wants a certain access, you also need to integrate that with our IGA and get the request. That's not there. That's the reason there's a red dotted line or red line. We are working on it, so it's on our roadmap.

And then we want to have an integration as well between our privileged session control solution and IGA also to get a complete picture of it. So we want to understand really what the risk is of a certain identity in the Philips environment.

Now, where are we today? So if you're looking at the privileged session control, we have onboarded around 2,500 servers and we have then 14 StepStone. StepStone is also a bastion that we call JumpPoints. We have for our privileged connectual stores, so that's the password rotation, 1,400 production and QA environment service onboarded to it and that covers 6,500 local accounts which we're managing and rotating. For personal password manager, we are promoting this with Philips so now currently uses this 5,000 but it needs to be more promoted and more used in the organization.

If you're looking at the endpoints, we have 72,000 endpoints and they're all managed in our endpoint solution. So for 72,000 devices, people do not have local admin rights, just the entire scope of Philips. And if you look at cloud infrastructure and entitlement management, so that's our AWS and Azure for the enterprise, we currently have 2,000 resources onboarded to see and understand what the risks are. What are our next steps to further minimize the risk of the attack first surface which we have. So we want to onboard all our service which we have to our PAM solution, so that's around 4,500.

So to our production and QA will be a little bit less. That needs to be completed by end of this year, so we have one month left for that. We also need to optimize our role-based X control model in the cloud, so that's in the Azure and the GCP because there we identify that we have a huge risk, so basically, this is your administrator or not. So we need to define their role model and we need to implement that in that organization so people only get access based on the roles.

Promote what I already mentioned more, the personal password manager and also for managing the secrets because we're going to move to passwordless within Philips. And what we see with the pilots which we are running, people forget the passwords. So we need to offer them also some tooling where they store those passwords, otherwise that will be on OneNote or on Excel spreadsheets. And you know hackers, they are going to check, of course, on the file shares or the networks where those passwords are stored.

We are going to enable session recording next year and also start to onboard or further onboard, I need to say, our R&D and manufacturing environments. And in the end, integrate with our PAM solution for next year. Maybe we'll do the Keyman IJ solution, although we have a dependency with our vendor and that's possible. And we want to enable command restriction. So if you're in a certain session, you cannot choose certain commands. I'm looking at the time. So what are critical success factors? So ensure that your policies are up to date if you're going to enforce this in your organization.

Create standardized process in your organization and communicate that process. Ensure it's contractually covered with mutual managed service provider. So we outsource a lot of stuff. It was not contractually covered. So we had a lot of discussions why they should use our PAM solution by embedding it in the contract. Now it's much easier to enforce and to use our PAM solution. Communicate clearly to the stakeholders why are you doing this. Determine the architectural design and principles and stick to them.

So if you're saying we're using service accounts and local shared accounts, then ensure that you stick to them. Somebody wants to have a personal dedicated account, no, that's not our principle. Define use case patterns and embed them also and use them for input as your decision tree. So when are you going to use which solution? Create a decision tree. A hybrid model for onboarding, not just onboarding to your PAM solution. You can do based on service, but also application-based. So use a hybrid model to make some successes. Automatic discovery and password rotations.

So ensure if you onboard that you also close the door. And with spinning up new servers, ensure that they automatically manage.

And yeah, have the right people in your team with the right skills and experience. So I'd love to hear from you how you minimized the attacker surface in your organization. So because I'm looking at the time, so I think it's almost done. On spot landing, thank you very much, Michel. Okay. Thank you. Thank you.