In this post, we dive into a scenario that many security professionals, at one time or another in their careers, may have experienced. It’s the moment when something unexpected occurs and someone asks: “I thought we had that configured?” That’s the moment when the security team starts reviewing their security stack, checking old emails, and reviewing tickets to understand what went wrong. Worst case? That glitch might have been the reason why there is an active threat to the environment.
Configuration Starts With Responsibility
But why do we have the paradox of misconfigurations in the first place? The most common reason is that the security team is not in control of managing the security capabilities. If the security team depends on the IT management team to push the security policies, there’s a gap between the team responsible for deciding the policies and the team that actually implements them.
And why aren’t security administrators able to manage security systems? If the Exchange Server is governed by the exchange administrators, the Okta Identity instance managed by the identity administrators, why shouldn’t the security tools be similarly managed by the security administrators?
The answer is often rooted in the legacy architecture that the enterprise is carrying. In the past, to configure security policies, teams were required to use group policies, System Center Configuration Manager, or Microsoft Endpoint Manager. Essentially, they were using the IT management tool to set up and maintain security. Therefore, even when an organization had security administrators, they depended on the IT team for any required change.
Today’s Security Challenges Require A Different Approach
While it might have worked in the past to have the IT team manage security controls, modern enterprises are at the stage where that is no longer scalable. Today, we aren’t just configuring a legacy antivirus and a password policy. We need to consider different attack surfaces and tune our preventative controls accordingly. The time when a security administrator could raise an IT ticket and then sit and wait is long behind us.
Ultimately, as security administrators, we are responsible for the organization’s security posture and accountable for the technologies related to it. We must ensure that the configurations are in place based on the security architects’ policies and frameworks.
To achieve that, it is paramount to control the technology and reduce external dependencies where possible. Therefore, it is essential to understand how to deploy and maintain the solution when selecting security technologies. We do not want to be faced with a situation where a policy had been thought through and decided on but never implemented because it had to be passed off to another team to be configured. And if we are faced with a discrepancy in policy and configuration, we need to have a better response than “I had asked the IT team to implement that policy.”
To see how you can start addressing these challenges, let’s look at how your organization can safely and securely manage configuration policies with the SentinelOne XDR platform. We’ll look at role-based access controls, endpoint detection and response policies, and device and network control.
Using Role-Based-Access-Control (RBAC)
The Security team deals with a lot of sensitive information. Therefore, the principle of least privilege is critical. The bottom line is that only people with an apparent business reason should have access to specific information. For example, as a security administrator, I should see the endpoint configuration, manage agent update cycles, and configure device policies and the firewall. Still, I do not need access to forensic capabilities or being able to access active incidents. With Role-Based-Access-Control (RBAC), this can be achieved.
In this example, you will find several distinct roles that are applied to this SentinelOne demo instance. One for security administrators that grant them access to anything related to the configuration of an endpoint, and three different roles for my Security Operations Center based on my Tier-level definition.
Each role provides granular access criteria. You can not only choose which sections of SentinelOne this role should have access to but also go one level deeper by component and even differentiate between view, edit, and delete rights.
EDR and EPP Policies
Sometimes you might need a little more flexibility when managing Endpoint Platform Protection (EPP) and Endpoint Detection and Response (EDR) capabilities, depending on whether it’s for your Privileged Access Workstation (PAW), High-Value Assets (HVA)-type services, or general workplace endpoints.
SentinelOne provides that flexibility by allowing you to configure a global policy for your SentinelOne instance, and you can determine if the same policy should be applied to all device groups or if, for example, a device group for HVA assets should have a different one.
Device and Network Control
Reducing the attack surface is a critical task for security administrators, so often the first step is to configure device restriction policies and the firewall.
SentinelOne provides security administrators with the ability to easily and quickly configure device restriction policies. You can choose between configuring these rules based on Vendor ID, Class, Serial ID, and Product ID, and you can select the action type so that you can either Allow Read & Write, Allow Read, or Block the access altogether.
SentinelOne also makes it simple for you to manage the firewall right within the SentinelOne console. When creating a new rule, you can first choose whether it should apply across Windows, macOS, and Linux, if it should be an Allow or Block rule, and later set if, for example, the policy is for a specific protocol, port, application, etc.
Conclusion
The increasing complexity in today’s threat landscape makes it clear that waiting several days to make a change to preventative controls is no longer acceptable. Security technologies have evolved and provided integrated security management capabilities that empower security administrators to make informed, risk-based decisions directly within the security console.
SentinelOne provides integrated security management capabilities that are truly designed for enterprise customers. Customers benefit from multi-tenancy and Role-Based-Access-Control (RBAC), which enable the principle of least privilege. If the security administrator needs to configure a device restriction policy, firewall rules, or optimize Endpoint Platform Protection (EPP) or Endpoint Detection and Response (EDR) controls, they can do that all within the SentinelOne management console in just a few clicks.
If you would like to learn more about how SentinelOne can help secure your organization, contact us or request a free demo.
