ManageEngine's Zero Trust framework

Pillars of Zero Trust

User

Authentication, authorization, and constant monitoring are our focus with user identity. We validate user trustworthiness to make decisions about privileges. Our Zero Trust system, known as 0Trust, maintains a list of employees and their departments by syncing with our HR tool. As employees join the company, change roles, or leave, these changes are reflected in the 0Trust system via webhooks. Employees are granted access to resources based on their roles. Identity providers help in the verification process by providing a list of users for the system to validate against.

Device

As with user identity, devices must be verified each time there is an access request. At Zoho, we have over 12,000 employees, and each user has at least two devices. Zoho's 0Trust system maintains an inventory of these devices. Each device is uniquely identified by a certificate installed at the root level. Employees do not have root access. To identify connection requests from managed devices, we enforce a two-way SSL authentication, where the client and server validate each other's identities.

Devices are monitored via our unified endpoint management solution. Device verification relies on two things: risk assessments and data loss prevention (DLP). DLP solutions aim to secure data in all forms. This is achieved through these methods:

• File auditing and analysis: monitoring user activity in files and assessing vulnerability
• Data discovery and classification: locating and tagging sensitive data
• Endpoint DLP: monitoring data transfers

Application

• 2FA: Using MFA tools like 2FA is one way to ensure employees have appropriate permissions and to prevent unauthorized access. The application layer depends on the user, device, and network data. To further secure identities, we are moving towards passwordless sign-in coupled with biometric verification for employees on our in-house MFA app.
• SSO: Employees have to authenticate themselves with both primary and secondary factors and will be assigned temporary tokens after authorization for access to specific resources.
• CASB: We monitor uploads and downloads on web apps and restrict the use of unauthorized shadow apps by validating them against allowlists, blocklists, and reputation scores.

Data

Resources are identified, categorized, and encrypted from end to end. We then enable least privilege access for all organization data. Data can be classified based on purpose, confidentiality, and other factors.

For example:

• Purpose: Email should be accessible for all employees, whereas organizational policies and SOPs should be read-only with edit access restricted.
• Confidentiality: Employee salaries, customer data, and product source codes are examples of data that should be restricted.

Network

• Microsegmentation: One of the advantages of Zero Trust is the ability to segment and monitor your network perimeter. Microsegmentation is the practice of breaking a large network down into smaller, isolated segments so businesses can monitor and control traffic easily.
• 0Proxy: 0Proxy is an internet-facing reverse proxy. Traffic is always assumed to be from an untrusted network and is routed through the 0Proxy, which filters requests based on their associated trust scores.
• Trust scores: A trust score system is used to evaluate if an individual should be granted access to the organization's network and data, and if so, how much. Admins can use a 0-1 or a 0-100 scale to rate the activities of each user, device, and network access request based on any number of parameters. At ManageEngine, we use a 0-100 scale to score each login.

Network scoring system

User scoring system

Device scoring system

The level of access an employee is granted depends on the trust score allotted to each session, which is calculated based on factors like device, user, and time.

• Device: A managed device will have a higher trust score than an unmanaged device. This is influenced by parameters like its antivirus status, its location of access, and whether its OS has the latest patch.
• User: Role-based access is influenced by parameters like resources and the severity of authentication (such as biometrics or 2FA).
• Time: Trust scores are modified periodically based on the session time.

Even if the CEO uses a device that is not enrolled in the endpoint management tool, the access will be restricted to public data (i.e., the data that requires the minimal trust score of 10/100). In order to access sensitive financial information, the CEO has to use a company-owned device.

Zero Trust vs. Zero Trust architecture: What is the difference?

Zero Trust and Zero Trust architecture are often used interchangeably. What do they mean, exactly? Zero Trust is an approach to security based on guiding principles. Zero Trust architecture is a broader concept that applies these principles to tackle three different security models:

• Zero Trust network access (ZTNA)
• Zero Trust application access (ZTAA)
• Zero Trust data access (ZTDA)

Migrating to Zero Trust

Speaking to our Zero Trust team gave us a better idea of our goals and roadmap. In the team's words, "Zero Trust is a front-end service, like a door that leads to a room. You can't rely on the door alone and not have walls. It's meaningless. Zero Trust is an additional security measure that should be combined with back-end securing services."

Our goals were to:

• Implement organization-wide Zero Trust.
• Rely on user and device identification.
• Make our verification parameters stricter.

Achieving these goals would take time, so we carried out our Zero Trust plan in phases.

Phase 1

Objectives:

• Identify user groups based on their roles and required access.
• Identify network flows and try to capture all of them in 0Trust.

First, we established a device enrollment policy for employees:

• Only company-owned devices should be used to access Zoho resources.
• All devices should be enrolled first in our mobile device manager (MDM) solution (in the case of phones) and our unified endpoint management solution (in the case of laptops and desktops). This is to ensure that the devices are secured by default and monitored for vulnerabilities and potential hacking attempts.
• Access to Zoho resources using devices that are not owned by Zoho should be avoided. Such access is restricted to resources that are public and definitely do not deal with customers and source repositories.
• Employees who need root access for their devices will have access restricted to a non-production setup.
• If a developer wants to access a production setup, they should use a different device for which they do not have root access. This is to ensure all controls are intact on the device that is used to access production setup.

In the early stages, resources were available via both the 0Proxy and the VPN externally and via both the 0Proxy and the corporate network internally. It was too early to abandon the VPN, but it was time for an upgrade. Instead of relying on the old username-password verification, we added 2FA and UEBA.

Our UEBA system builds behavioral profiles of users and entities in the organization and assigns a risk score when the behavior deviates from the previously established normal baseline. It helps us identify compromised accounts, data exfiltration, and insider threats, serving both as a diagnostic tool and an early warning system.

The UEBA system is highly customizable, thus giving us complete control over the types of anomalies to be detected. It adapts to changing data patterns automatically without any intervention and can be deployed in any domain, as long as the configuration of the types of anomalies to be detected is done correctly. ZLabs, the R&D team at Zoho, has filed a provisional patent on the design of our UEBA engine.

Phase 1 was all about experimenting. To start with, we had 250 users from both the business and IT sides of Zoho volunteer to test out the 0Trust system. For example, a leader who does not require access to development tools signed up for the 0Trust test run in the early stages. He chose to participate because he felt using the VPN to access internal resources led to sub-optimal performance of applications. Everything from build deployments and performance statistics to meetings went through the VPN, often causing issues like poor audio and video quality.

Upon creating a user account, a user could view their device health and trust score. This helped them figure out what they could do to improve their trust score and comply with policies.

When the user started their system, 0Trust was activated automatically. If they wanted to add a specific domain to the 0Trust system, they could raise a request to the Zero Trust team. If the Security team could validate it, the domain was mapped to the local system.

After signing up for 0Trust, the aforementioned leader inferred that application performance had improved considerably. It also reduced the load on Zoho's proxy servers, so it was a win-win situation.

Phase 2

Objectives:

• Route all employee traffic via the 0Proxy.
• Monitor the traffic and log the invalid traffic, but grant access if a user is accessing via the VPN or corporate network. Analyze the failed traffic and try to address that case.
• Monitor employee VPN usage. If all their flow can be achieved via 0Trust, we will encourage them to use 0Trust completely.
• Monitor employee VPN usage. If it is not accessed for a certain period, revoke their access.
• Restrict VPN access to employees with proven needs only.

Our spoke office in Madurai was one of the first offices to sign up for the 0Trust trial. Home to about one hundred employees from multiple teams, it was the perfect location to start with due to its small size.

Before the pandemic, these team members were working at our Chennai headquarters, so they used the local network. Most people did not even know how the VPN worked. After relocating to the Madurai office, they had to use the VPN for daily operations. In this scenario, security became a bit of an inconvenience.

There were two problems with using our VPN. One, there were connectivity issues when accessing the VPN through mobile data. Two, users had to log in each time they unlocked their devices. So, multiple times a day, after stepping out for fresh air, grabbing a bite, or engaging in a quick chat with a colleague, they had to log in each time. To avoid this, some employees would leave their devices unlocked, which goes against our security policies.

At the same time, our development leads started to wonder, "Is VPN access required for the new employees?" New members joining the development teams did not require access to all the internal resources that the VPN granted.

Enter 0Trust. Now, the system can maintain sign-in sessions and reconnect automatically. However, this transition did not happen overnight. Installing 0Trust in each system was tedious. This was when our sysadmin introduced the 0Agent. Installing the 0Agent (via our MDM app) made the switch to 0Trust effortless, almost like working from the Chennai office. Likewise, new employees were given access to resources based on their requirements, like Git operations. Access was granted after a preliminary security evaluation, for which employees had to review the security policies thoroughly and take a security awareness test.

Today, the Madurai spoke office operates almost entirely on 0Trust. About 5% of services still need the VPN, which will be phased out once the team works out the kinks. The success of this trial run was an indicator that we were on the right path and ready to move to the next stage.

Phase 3

Objectives:

• Route all traffic via the 0Proxy in block mode. Block the flow if the trust criteria are not met.
• Restrict the Zoho accounts of our cloud services to accept requests only from 0Trust IPs using our IAM solution's IP restriction.

Before, if you were using the corporate Wi-Fi, you would have access to internal sites, regardless of your role. Now that we are in Phase 3, as we continue work on Zero Trust, we intend to change that. Eventually, even if an employee logs in through the corporate Wi-Fi, they will need 0Trust to access confidential information.

During the development phase, the team is working on fixing roadblocks, like scalability for all applications and device confidentiality. Once those issues are sorted out, we will make 0Trust mandatory for all employees. The 0Agent will be installed on all systems by the admin.

The Zero Trust team has partnered with a third party to monitor credential leaks. Our admins also rely on threat intelligence, an independent service developed by the Security team that provides information on vulnerabilities to help mitigate potential attacks. The purpose of threat intelligence is to enable quick resolution for security issues. Our teams connect with third-party analysts on threat intelligence platforms to combine local organization data with global data and to align their security strategies accordingly.

Factors that influence Zero Trust

Access control policies

For a Zero Trust system to handle authentication and authorization, it needs instructions, such as session and password policies. These policies are usually set by the security team based on input from the sysadmin.

Session policies

Password policies

A. Complexity

B. Management

Integrations

• HR: When a new user is added to, updated on, or removed from our HR portal, it is reflected in the 0Trust system as well. The employee's details, such as first name, last name, and mobile number, are collected, and the employee's email address is used as the unique identifier.
• Analytics: 0Trust maintains logs. It contains details about each user, the resources they have accessed, and the access location. This is usually monitored for incident analysis, so we plan to integrate 0Trust with our analytics tool in the future.

Automation and orchestration

Source: NIST’s guidance for a Zero Trust architecture (a ManageEngine e-book)

This diagram represents NIST's Zero Trust architecture. Without going into the technical details, it is important to note the role of a policy engine. It evaluates the trust score for each access request and automatically accepts or rejects it. The purpose of automation and orchestration is to bring the pillars of Zero Trust together, allowing IT teams to make fast, reliable decisions. Applying automation and orchestration to the policy engine makes the IT team's work easier by eliminating the need to manually assess each potential threat before taking action.