In today’s third in a series of topics covering Zero Trust principles, I’d like to delve into a very specific area of access control, the critical concept of Least Privilege. I’ve chosen this topic because its implications and potential impact are often overlooked in organizations, possibly because they simply aren’t aware of the potential benefits technology can offer.  For that reason, I believe it’s crucial to shine a spotlight on it and discuss how technology can really help in this area.

To that end, I thought it might be useful to compile a list of questions you might ask yourself about your own technology, for access control and least privilege, in use by your organization:

1. Can the technology be structured to control or prevent movement across security zones?
2. Does it aid in reducing the threat landscape by minimizing the number of external ports that need to be open?
3. Does it help in mitigating the risk of viruses and malware infiltrating the network?
4. Does it support industry-standard multi-factor authentication (MFA) solutions as the primary access control barrier for all privileged users?
5. Once access is granted, does it enforce the Zero Trust principle of least privilege for both insiders and external contractors/vendors?
6. Can it enforce policies to dictate the specific resources each person can interact with based on their job function?
7. Does it offer the capability to restrict access to specific IT or OT assets, protocols, applications, reports, or files based on role or job function?
8. Can the ability to securely move files be restricted based on role or job function?
9. Can it control the timeframe for which access is granted to assets, terminating access at the end of the specified period?
10. Can it restrict access to an asset solely through a desktop application?
11. Does it minimize access to passwords by obscuring usernames/passwords and preventing their circulation?
12. Can it enable shared sessions for oversight, collaboration, monitoring, or even termination once a user accesses an asset?
13. Are command line or graphical sessions effectively logged or recorded for training, forensic investigation, or audit evidence for compliance requirements?
14. Can it assign a list of permissible commands for a user or role?
15. Does it analyze the state of the machine/configuration before and after a session to report any changes made?
16. Is the user interface intuitive enough for occasional users to navigate without training?

I could continue listing the capabilities that ConsoleWorks offers in addressing Zero Trust least privilege principles, but I’m eager to hear your thoughts and feedback on the ones I’ve mentioned. Are there any particular ones that stand out as more important to your organization’s needs? Are there those that you would like to understand better? Let’s discuss further.

And if you’re eager to take your defenses a step further – well, you’re in luck! Discover how ConsoleWorks can supercharge your Zero Trust implementation.

The last few years have seen the rise of Zero Trust, as calls for its implementation came down even from the White House. In the wake of significant increases in ransomware attacks, and the major shifts to remote work, today we are looking at the stages of the secure remote access maturity model.

Secure Access Control) is a key component in the Zero Trust architecture. It enables you to enforce the least privileged access to your endpoints for a user performing their role. Managing the connections between partners, contractors and employees can be a challenge, but reaching a mature level of privileged access management is critical for the safety of your network.

Do you know where you stand in the secure remote access maturity model and does your current level meet the requirements to enable Zero Trust?

What is a Secure Remote Access Maturity Model

A mature secure remote access implementation would have prevented some of the attacks we’ve seen in the news before they even started. As we’ll review in the secure remote access maturity model below, there are 5 distinct levels.

Each maturity level builds on the last and layers in additional security and least-privileged access of users connecting to your endpoints. Some of these levels also look at the structure of your architecture, helping you to enforce other security standards as well.

Though we are looking at secure remote access, it’s important to remember that a fully mature cybersecurity architecture will go beyond simply enforcing least privileged access and even Zero Trust. Zero Trust should be your goal “foundational” security level. From this foundation, you build more sophisticated and layered defenses, like those available in ConsoleWorks, on top, taking you beyond Zero Trust and increasing your defense against even the most sophisticated of attacks.

Secure Remote Access Maturity Model Stages

SRA Maturity Level 0
No secure remote access exists. At this level of privileged access management maturity, there is essentially no plan in place to control a users’ access to endpoints. Here a truck is simply rolled to a site and access is granted based on knowledge of the password to the endpoint. Anyone with this password can access the endpoint and no one will know who accessed it when or what they did.

This level has no “roles” to speak of. You are at your most vulnerable to attack here. This is made worse by your lack of insight into how an attack may have occurred or even what happened during it.

SRA Maturity Level 1
Sites are added to a network containing strict firewalls with normal connectivity (SSH, Dial Up). In this level of the privileged access maturity model, many of your vulnerabilities remain from level 0. Access is granted manually by an administrator who decides if certain actors are allowed. However, nothing is done to verify an actor after initial access is granted.

Visibility into identities and the risks associated with access is limited. If another user has the password, then they have the keys into your network without any way for you to know who they are or what they are doing.

SRA Maturity Level 2
A Jump Host is added to the network. User access is tightened and more defined. You start to identify users at this level for access into the network and its endpoints. Certain verifications are added, like checks on the location a user is trying to access the network from and what role that user may have.

SRA Maturity Level 3
At this level in the secure remote access maturity model, you reach a mature realization of firewalls with an added DMZ. Access is further controlled, with durations for access assigned to certain roles. Identities are associated with specific access-level capabilities for these roles as well, further limiting what a user can do or see on the network.

SRA Maturity Level 4
More user authentications are layered in at this level, with things like two-factor authentication/multi-factor authentication. We are approaching a very mature realization of privileged access management. Here we see robust network access control, with combinations of authentication, enforcement of security policies and strong endpoint security.

We are also near the true realization of Zero Trust secure remote access at this level. Trust at this level is highly diminished in the network. Identity access policies now gate access to applications and endpoints within the network and we begin to see analytics implemented to improve situational awareness on the network.

At this level, just knowing a password is no longer the same threat that it was at the lower levels, as other authentications are required, and access given to any user is substantially controlled by permissions.

SRA Maturity Level 5
You have reached the highest level in the secure remote access maturity model. Level 5 is the full realization of Zero Trust secure remote access. User activity is logged, providing critical information on who connected to what, what they did and when. Granular control of user connections inside each security zone also means users are only permitted to see the applications or endpoints necessary for them to perform their role.

Users are monitored in real time and their risk is assessed continuously; they may only be able to perform certain commands. If their behavior is viewed as suspect, their connection is terminated, and the incident escalated. Every action is auditable.

Access is only permitted when it is needed, to whom needs it and only for the duration they need it. For example, if a contractor arrives on a certain day, their access is only granted for the date and time of their arrival, along with their duration needed to perform the work.

A protocol break now stands between the user and the endpoints in the network. With this, they never directly connect to any endpoint within the network, instead ConsoleWorks brokers the connections between user and endpoint, protecting you from viruses, malware or ransomware.

Many organizations, with technology like ConsoleWorks choose to replace their Jump Host with ConsoleWorks, simplifying their network architecture.

The Path to Achieving SRA Maturity

Many organizations struggle to reach the higher levels of privileged access management maturity. It is imperative that these levels be attained as passwords alone will not protect you from an attack, nor will simply assigning roles to users who access your network.

The best security attained is by permitting least-privileged access, only when it is needed and only for as long as it is needed, while treating every connection as untrusted. This means continual monitoring and auditing of connections on your network to ensure an attack is not taking place and that a bad actor has not gained access.

ConsoleWorks is built with SRA maturity in mind and takes you to level 5 with ease, significantly heightening your security and even taking you beyond the Zero Trust baseline. Talk to us about your secure remote access needs here to achieve the highest maturity level possible today.

This is the second post in our series covering the principles of the Zero Trust model. Today’s post looks at enforcing Zero Trust with a least-privileged access control policy. Zero Trust is enforced through three core principles: never trust a connection, assume a breach has or will happen and enforcing least privileged access. We will look at each of those components over the course of our series.

Castle and Moat Defense is Not Sustainable Defense

The traditional castle and moat style of cybersecurity is no longer sufficient to defend against attacks. As connections are scattered across the country and globe, combined with continuously expanding fleets of devices, applications and users, hackers have exploited the security holes left as businesses have failed to adapt their defenses to this changing threat environment.

As organizations move their data into the cloud and change their network from being fully on-premises, to a hybrid, cloud or multi-cloud environment, it has opened new areas of opportunity to exploit.

Compromised credentials and weak access and authentication policies are among your most important elements to make secure.  One of the easiest ways for a company’s defenses to be breached isn’t by an infection with malware or ransomware, but by a bad actor walking right through the front door under the guise of an employee, contractor or partner.

A New Line of Defense: Zero Trust and Least-Privileged Access Control Policy

A strong, least-privileged access control policy, focusing on user identity and authentication measures providing just the right level of access and at just the right time, are foundational to a Zero Trust framework.

Least-privileged access reduces role privileges and only shows the parts of your network to the user that you want or need them to see to accomplish their role, and only when they need to access it. It is part of ensuring that a user receives only the level of access they need, and only when they need it, to perform their role and nothing more.

A contractor can be granted access for the date and time of his arrival on the site to the exact devices and assets he will touch, for the duration of time that he will need to access them. Once he has completed his job, his access is revoked.

If an employee is servicing a ticket, certain access can be granted in relation to the needs of the ticket and once the ticket is serviced, access to those devices is revoked.

Enforcing Least Privileged Access Control Policy

Enforcing a strong least-privileged access control policy requires the corresponding elements of your cybersecurity to be mature. It is why we have written two blogs that help in enforcing this and understanding where you are in your current journey toward cybersecurity maturity.

• Our secure remote access maturity model helps you to enforce how a user is granted access to a network and how that access is allowed to interact with the rest of your network and its devices, applications and data.
• Our password management maturity model helps with additional authentications and further strengthening your access control policies by reducing threats associated with getting credentials in the first place.

If we look at the models’ highest levels, we can see the intermingling elements that form a mature Zero Trust level that assesses each individual, with no inherent trust permitted.

These include structures in place for verifying users beyond just the password, with password updates and changes happening automatically and away from users, and the highest standards enforced for password requirements.

If you mix this level of password maturity in with sophisticated secure remote access, including components like permitting access when it is needed, to whom needs it and only for the duration they need it, you are strengthening your defenses more.

Further Defense is Needed

Zero Trust does even more to bolster your defenses and we’ll be discussing those elements more. Our upcoming posts in the Zero Trust series focus on the elements around never trusting a connection and assuming a breach has or will happen. We will continue visiting how traditional defense treats these threats and how Zero Trust compensates for the deficiencies left behind from this traditional approach.

To further bolster your defenses and go beyond Zero Trust, you can see how ConsoleWorks helps you enforce it even further in our post here.