According to Gartner, by 2023 95% of cloud security failures will be the customer’s fault.
The lack of visibility and failure to manage user access to sensitive resources places companies at increased risk.
Don’t let your Microsoft 365 environment fall victim! Learn to defend M365 in a 45-minute security session ‘Protect Your Cloud Microsoft 365 Identity’.
Hans Hofkens, Microsoft Cloud Solution Strategist “Security, Risk & Compliance” and David Mascarella, Chief Global strategist at CoreView, will present the top 5 things you need to do to meet regulatory and security requirements.
In addition, these two experts will help you define security policies to protect individual user identities against account compromise, and secure your highly-privileged administrative accounts.
Microsoft Cloud Solution Strategist
"Security, Risk & Compliance"
CoreView Chief Global Strategist
It’s important to understand how identity is important and how to control all the configurations since at the end of the day YOU as the IT leader in your organization are responsible.
In the modern world, we not only work with employees at our own local offices but also employees at home, etc. Mix in external users that might need access to your sensitive data as well.
+ combining all of the devices
We could be talking about tens of thousands of devices and people we are trying to protect.
We have selected five actions that you can tackle to raise your security posture.
By protecting your identities, it is interesting to think about what that means in a zero-trust context. From an HR perspective, we put trust in our employees, but from the security perspective, we are a little less, sympathetic.
And what we would argue is to never trust, always verify.
It doesn't matter if your user is originating from within the company network. We do not trust any login on the company network even.
Let’s say an employee starts logging on from within the company network, which is a trusted location. But you don't have an MFA set-up.
So, we might, even in this case, assume that the user or the device has been breached. And say no, we still want you to level up your authentication – through the least privilege principle.
When setting up security procedures always be thinking about these things:
- How can I still limit the impact of a breach?
- If something does happen, what is the next move on your part
This not only makes sure that you have another view on how to set up your security or compliance posture but also how to think of what if something happens so that you are also prepared from a process and procedures perspective. Simply that you know, which CXO can I call on a Friday night out of their bad, just because something happened.
So, if we start having a look at the basic architecture for zero trust, then we typically see that we get ingestion from the signal coming from our identities, from the devices, from where they are originating, and then very important. We are going to apply our organizational policy to them.
We are going to do a real-time evaluation to check.
So for an identity, for instance, first of all, we would be very interested if someone wants specific data.
What is the risk in this specific session? The risk could be that they are going for highly sensitive data - financials, non-publicly available results of your company.
We might want to be a bit more careful in how we give access to that one compared to perhaps the basic data that might be on a shared internet site for all employees, for instance.
So, context is always a very important thing. And instead of thinking black and white, as we did, in the past, think of it in gray space.
For example, let’s walk through the thought process behind this.
Let’s say David is logging in to one of his identities. He’s passed the password check.
Fantastic. Now we are a little bit more certain that David is indeed David, but let's also check what the risk assigned to his specific device, for instance, is it a compromised device, perhaps?
Are we aware of the IP where it's originating from? Is David's password somewhere available on the deep, dark web, and so on?
So, we accumulate all of that signal, apply the security policy enforcement to it, and then decide, should we allow him access to the data?
If we give him access to the apps, do we want to, give him the rich experience or will we be preventing him from downloading a specific file and so on and so on,
CoreView can help with security policy enforcement.
That is the key to the implementation of the zero-trust architecture and improving the security pillars.
The first pillar is your organizational policy.
One of the questions that you should be able to answer is, “DoI have visibility on how my user is configured and what they're doing on the system?”
Each user can have a dozen of different configurations.
CoreView can help you easily identify all those users that should have the multi factor authentication activated, but don't.
So beyond just checking at, this is the user and/or this is the device but the type of information you want to achieve.
So, this is the first thing that we do when we start talking about user risk.
It's not because David is using a safety device is using his passwords, that we can trust him to be. What if somebody else knows the password David’s in this case? So, using risk detections, typically figuring out about leaked credentials, but also looking at things like impossible travel.
For instance, if David logs on from somewhere within theEuropean continent, as we speak right now, and two minutes later, all of a sudden is doing so from Russia or the US or China or that's quite a strange thing to happen.
So how can we start detecting such a thing? All of these small things are anomalies that we want to pick up and to which we want to be able to react to it.
So with identity protection, we've got a couple of additional risk types, which we can pick up and learn from.
As you probably know now, the CIS has defined that asking the user to reset their password on a periodic base is not a best practice because, in the end, they tend to use weaker passwords.
That is just an example of how starting from an event, starting from the information you can orchestrate a process to fix a potential risk issue.
If we look at a typical administrator, for instance, you can define the size of his key ring.
Bad actors are typically on the lookout for who are those admins and have spent quite some time at a company.
Using least privileged access methodology, where we assign rights to admins just in time and just enough, meaning that only if our admin David needs to change something to the user of Jessica only, then we will actually give him the rights to do so, but only give the rights to do that specific.
And if we set something up like that, we not only give us the ability to have a very limited, attack surface but also to go a lot deeper into the auditing of what's happening.
So that if something were to happen, we also have a far clearer timeline of what happens by who and when.
We call those virtual tenants.They represent a specific type of user, all the users of a specific country of a specific department. So, you can create a virtual tenant and test what you want by leveraging all the user property.
You can also add that virtual tenant and the groups that you want. A subset of the license and then delegate an operator to have visibility and management rights only on the assigned user.
The last important thing is about roles. Microsoft has already given us a lot of pre-defined roles, but if you have a specific organizational model,(which CoreView can do), you can also create your custom role.
You can delegate at that time to your desk visibility on specific actions each person can activate, see, and execute on the assigned user. So, in the end, CoreView gives you the maximum flexibility to secure your operator and also make it easy and scale the operator across all your IT organization.
But of course, it doesn't stop there. The same principal so applies to all of your business users because they still have access, to a lot of the sensitive data out there.
And this is where the identity lifecycle pops in not just for admin, which typically tends to be a little bit more high attention but also to all of your productivity workers, information workers, first-line workers, and so on.
And it of course all starts with the successful provisioning of your user.
Typically the first burden is how to assign them the appropriate rights, just to be able to do their jobs.
If you want to further improve your security posture and improve the lifecycle of the user make sure that every user is onboarded and gets additional access.
You can read more about Microsoft onboarding best practices here.
So if you look at that the first step you could do is have a look at the Microsoft secure score to help increase your security posture.
So by taking all of that together, we want to help you in creating that safer environment.
And what we have implemented is a way for our customers to extend what the Secure score provided by working mainly on best practices and having the company policy at the center of the security.
With CoreView you can leverage all the data that we have to configure a policy that can help you discover a misconfiguration, assign a score, and then have a track of your security posture.
Most importantly you cannot only identify the misconfiguration but can manage exceptions.
If you want to be able to run detection, make sure that the audit is enabled on all of the right services. And as soon as you do so there area couple of items you can start picking up on, and it could be something like an application that's running in your environment using old permissions.
For instance, that act us gives the application itself a bit too much access to internal data.
So all this data has storage on a big data engine and that help you to easily navigate all the data with a few click with the system can.Also, help you to find what you are looking for or discover.
That means that you can create a policy from the log to create a policy not only on, the configuration, but also on user behavior. And starting from that policy, you can also trigger a single event to, run a specific workflow.