On April 4th, 2023, we announced our expanded device-centric Security Service Edge (SSE) solution. From company inception, we decided that an approach to access and security built devices outward provided the biggest advantage to our customers. In this blog, we’ll take a look at why we took a device-centric approach in architecture, and highlight some pitfalls with other popular approaches.
What Does Device-Centricity Mean?
Let’s look at a few “centricities.” These are based on other, well-known vendors in the security world and come directly from their webpages:
- App-centric: App-centric, in this case, means lots of interaction with an app before anything happens. (Data-centric implies that that all the traffic must go to the vendor to be inspected.) Most of the app-centric vendors only work after a user has logged in to the application.
- Data-centric: This approach may work when data integrity is your primary concern, and the data lives in one place, say on-premises. However, when data is distributed, this approach is very difficult to achieve. This is especially hard when applications and resources are in third-party SaaS environments.
- User- and Identity-centric: Minimizes the details going from what (the device), and from where (the end-user location or device).
- Cloud-centric: This is basically the same as data-centric, meaning where the information lives, minimizing on-premises and SaaS. Also, minimizes the who, from what, and from where.
- Human-centric: High BS rating for this one, and it’s surprisingly findable in marketing copy from other cybersecurity companies. Possibly the hardest, least-predictive part of the information ecosystem. This ignores behavior on the system that the “human” isn’t even aware of.
- Identity-centric: Minimizes the device, which is evident in the products and lack of device identity and compliance functionality. Asking for more detail on identity often seems to introduce confusion, and reveals the product over-promises what can be delivered.
- Everything-centric (data, customer, application, network): It’s hard to talk about an approach that lacks focus. This is more of a marketing messaging strategy, rather than an approach. One specific vendor that is pushing this approach wants all the traffic to go to them so not only are they “everything” centric, but they get to look all “everything” your company has, since all the traffic is forced to go through them to get decrypted and inspected (among other things).
Identity and Devices
While the Banyan platform integrates with many identity providers, and many of them have pivoted their messaging into a more holistic security story, knowing the shortcomings of the identity-based approach may help with your decision-making.
Identity-based security is an approach that focuses on verifying the identity of users (and possibly devices) accessing a system or network, and granting or denying access based on their identity. The following are some potential drawbacks to this approach:
- Increased complexity: Identity-based security can be more complex and difficult to implement than traditional perimeter-based security approaches, which focus on securing networks and endpoints. It requires a deep understanding of the organization’s identity landscape, including user roles and access rights, as well as the ability to manage and synchronize identity information across multiple systems and applications.
- Cost: Implementing identity-based security can be expensive, particularly for organizations that have large numbers of users or that need to comply with strict regulatory requirements. This can include costs associated with identity verification, access control mechanisms, and ongoing monitoring and management.
- User resistance: Identity-based security can be perceived as a burden by end-users, who may be required to provide additional authentication or follow specific procedures to access protected resources. This can result in user resistance and may require additional training and support to ensure compliance.
- False sense of security: While identity-based security can improve security, it is not foolproof and can create a false sense of security if not implemented properly. For example, if an attacker gains access to a user’s credentials or if a user’s account is compromised, the attacker can potentially bypass identity-based security measures.
- Single point of failure: Identity-based security relies on a centralized identity management system, which can create a single point of failure. If the identity management system is compromised, it can potentially grant unauthorized access to sensitive resources.
Though identity-based security can provide significant benefits, it is important to carefully consider the potential drawbacks and ensure that it is implemented in a way that is effective, efficient, and user-friendly. This may involve balancing the need for security with the need for usability and minimizing the risk of a single point of failure.
Smart Security Starts with Devices
So why device-centric security?
- The device is the new edge. This is especially true with more people working remotely.
- Moving security stack to the “new edge” makes sense, unless you want to backhaul or hairpin all the traffic back to corporate network to use legacy outbound security stacks. Which one sounds like more configuration and headache?
Devices Determine Everything
- Because we are device-centric, we don’t require an end-user to connect to our system to:
- validate device compliance/posture checks
- enforce device trust and real-time continuous authorization
- get easy, passwordless access (since we can do proxies and device certificate authentication).
- Because we are device-centric, users and devices get resources AND data privacy
- granting user/device access to resources behind a connector/access tier without sending traffic to Banyan.
- Because we are device-centric, we facilitate internet threat protection (ITP)/SWG/DNS filtering
- enforcing this on the device itself using an on-device proxy to our DNS filter.
Intelligent routing policies done on the client means that most of the traffic doesn’t have to be backhauled, and you can still enforce authentication, device identity/posture, and authorization. Moreover, you can ensure that all “public” (over-the-internet) communications are secured, even if the application and resources themselves don’t enforce security, authentication, or encryption.
Visit us here to learn more about the benefits of a device-centric approach and try Banyan for free.
