How to Minimize the Blast Radius of an Attack?

Thanks everyone. Thanks Mattu for the introduction. So my name is Michel Sto. So is this presentation an evolution or revolution? It's up to you to decide. So it's cyber.

Yeah, so, so a the on the first day I was in interested in discussion about the workshop from Christian. He for the hacked about 20, so 72 hours nightmare of the CSO and of course now is hack the flag there and of yesterday also people hack the gamification. So Christian Shields should have some nightmare now how to prevent that. So it's really about how to minimize the blast radius of an attack, how we're going to do that in Philips or how we have done that so far. So we'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 who has some Philips products at home. Excellent. So Phillips has been founded in 8 9 18 93 by Anton and Fredrich Phillips. And since then of course we make still gr groundbreaking innovations but as products come and technology goes the same is for the company. So as you raise your hand, you have from Philips products ago at home, Philip is not Phillips anymore as you know. So we don't have television anymore. That's part of TP vision.

So 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 Suni. So that's all branded licenses. Phillips is nowadays a company which is focusing on the healthcare sector and therefore we are a health technology but still we're creating meaningful innovation that prove people alive. So we strive to make the world healthier and more sustainable through innovations by improving the life of 2.5 million people by a year, by 2030. Yeah. And now 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, your toothbrush that you brush, your teeth fare 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 and for the image guided therapy, so once you had your surgery or whatever and you are recovering, we also have products for you to monitor at home. That's our connected care and if you fully recovered then of course you're back at the beginning and you start healthy your 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 Phillips, where do we really need? Oh it's not moving. Yeah.

Oh, so where do we need privileged access management? Because privileged access management is key to protect our intellectual property. So that's not get stolen. So we need to focus on, for example, the enterprise r and d and manufacturing. That's also our scope for today. I'll not focus on the products and service 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're 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 Phillips. We sit together with everyone and we put this really at the top corner. So in the top corner means it's in the bombs 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 at Phillips with the privileged accounts. Where are these privileged accounts?

Who are using it? Why are they using it? Why are accessing these services?

We, yeah, we don't have the visibility so what do we need to do? People have excessive access. You have people for example, for 40 years in Phillips 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 Phillips 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 ma a matter of time.

So, and we needed to prove this as well to our management. So we needed to have, so we needed to quantify this. So we sit together with our risk and compliance department from security who are doing assessments within Phillips and we collected all the information. So we do not have for 53 person control over the privileged access. 40% of the access was never revoked. So you're just collecting, collecting, collecting all the information. Also the privilege access. We never reviewed those authorization work, 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 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'll start more into details, it's like I'm going to focus on what is then a type of privileged account. 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 which are in the market but also with others to get a definition of a privileged account.

So if you look at it, if 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 call 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'll do phishing for example.

They still do credentials and then they have directly access to it. We also don't want to have a personal dedicated account because then person also get still too many access rights assigned to these. So based on the decisions we choose for shared account and the shared account is a principle which we're using in our password management solution, a previous 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 share accounts, we don't want to have their 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 permission to what is needed. I'll 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 share shared accounts or to service accounts principle which we're 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, identification, 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 priv like 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, a personal password manager, endpoint privilege management and here's the endpoint and the laptop. So no one in Philip should have local admin access on their device.

And where we had today discussion with Paul Fisher about cloud infrastructure entitlement management. So it was a good and great discussion which we had. So also we 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 Philip secure security frameworks. So there are policies, standards, and baselines defined and that's based on the Cisco cred critical controls to N for example or the iso.

So these linked, so the capabilities will linked to controls and then we have as well using the threat models and the threat model which we have is the RA attack. So now we have a complete picture of all the attacks which we have in the organization, the risk which we have and how the capabilities and control can mitigate these risks, which we have. Now what are then our requirements? So we want to segregate and integrate all the development tests accepted in prediction environment. So the DTaP segregate the accounts.

You do not assign the privileged 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 multifactor authentication. So if you want to get access to it, you always need to enforce multifactor. So every count is protected with multifactor authentication. We need to discover all the privileged 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 patch, it 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 are some threat for example identify that we immediately can identify and response to the risk which we have but also record. So in case of a security incident happens, then we come watch back the recording and see what happened during the session. So we can take the needed actions.

Then we have of course secrets. So that's more for disconnected application store the secrets and the secret fault and for your personal what already explained store them and the personal password manager. Now what did we do then to minimize the blast rate of the attack. So you have then the person who get 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, the reach out to the service desk, they will help to install the software and then the privilege 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 the 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'll integrate with your IGA solution. So you will go to your IG solution, you'll request access to your P environment.

Somebody will review if the person should have access it to it and once it's okay you will approve it and you will only get access based on the rule which you have. So then you get access to the privileged session control and the privileged credential storage. Our capabilities which we have or explain more. So you will log in with your Phillips account or federated account, which we have because we're using a lot of managed service providers.

You authenticate to the privileged session control there we are going to enforce multifactor authentication and also check if you do 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 but I already explained with the principal of shared account. So you need to request access via our privileged 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 privileged account for himself to bypass all these controls and that's what we also want to prevent of course. So if he create this account, we should discover it, we 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 is ended. So you use this the the local admin account session is 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 ServiceNow for our CMDB scanning. So in cer certain period of time the accounts will do a check-in automatically without user interaction.

We'll do his activity, he will scan the environment store all the data, we'll 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 insight 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 environment. 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 key solution.

We get these insights. Anyway, Paul Fisher wrote a great article about it and is posted now on the, so and that's the one we discussed today in our session. We also want to integrate the team with our IG solution so people can, so we create the visibility from end-to-end on the identity. So we create full overview what the user really can in the IG solution and if somebody wants a a certain axis, you also need to integrate that with our IG and get requested it. That's not there. That's the reason it's a red dot 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 previous 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 Phillips environment. Now where are we today? So if you're looking at the privileged session control, we have over onboarded around 2,500 server and we have then 14 step stones. StepStone is also a a bus, the owner we call jump points we have for our privileged credential stores.

So does the password rotation, 1400 production in 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 when the Phillips we're now currently used is 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 solutions.

So for 72,000 devices people do not have local admin rights. That's the entire scope of Phillips. And if you look at cloud infrastructure and entitlement management, so that's our AWS and Azure for the enterprise, we are currently have 2000 resources onboarded to see and understand what the risks are, what are our next steps to further minimize the risk of the yeah, 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 in 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 identified that we have huge risks. So basically this your administrator or not.

So we need to define our role model and we need to implement that in that organization so people only get access based on the rules, promote what I already mentioned more the personal password manager and also for managing the secrets 'cause we're going to move to Passwordless and Phillips and that what we have, 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're going to check of course on the file shares on the networks where those passwords are stored. We are going to enable session recording next year and also start to onboard on further onboard I need to say our r and d and manufacturing environments and in the end integrate with our PAM solution for next year. Maybe we'll do the Keyman IG solution, although we have a dependency with our vendor when that's that possible. And we want to enable command restrictions.

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 ly covered with mutual managed service provider. So we outsourced a lot of stuff. It was not contractually dis covered. So we had a lot of discussions why they should use our PAM solution.

By embedded extend the contract now it's much easier to enforce 'em 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 you'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 ca. Use case patterns and embed them also and use them for input as your decision tree. So when are, 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 serves but also application base. So use a hybrid model to make some successes, automatic discovery and password rotation.

So, and sure if you onboard it, you also close the door. So, and spinning up new service. Ensure that they automatically managed and yeah, have the right people in your teams with the right skills and experience. So I love to hear from you how you minimized the attack surveys in your organization. So because I'm looking at the time, so thinks almost done on, On, on spot landing. Thank you very much Michelle. Okay.