In order to keep our data and systems secure, we ought to follow these three security principles...

¬

Role Based Access Control (RBAC)

Role-based access control, sometimes referred to "role-based security", is a mechanism that restricts system access.

With RBAC, employees' job roles should correlate with the levels of access that they have, and this should be used in conjunction with Resource Classification.

As illustrated below, employees are therefore only allowed to access the information necessary to effectively perform their job duties, which protects sensitive data.

Because many large organizations allocate their staff into different departments / teams, access can be set-up to coincide with responsibilities of these groups.

Roles can be based on several factors, such as responsibility (e.g. SysProg), authority (e.g. Contractor), job competency (Junior), etc… Each of these roles may grant different access permissions to resources, individually allowing access to READ different datasets, ALTER a resource, or CONTROL a function.

In a hypothetical example "Bob" has the job title "Senior Security Manager" and therefore may be connected to various different groups/roles, including 'Staff Management', 'Security Engineering' and 'Core Staff'

Using the example above, we can imagine some of the credentials that Bob may have:

• He may have the default ability to amend his own datasets via &RACUID.*/ALTER (G) in the Global Access Table

• He may have READ access to his account's PAYROLL dataset because of his connection to the 'Core Staff' role

• He may be permitted to the SUPERUSER.FILESYS or C4R.EXEMPT profiles because of his connection to the 'Security Engineering' role

• He may be connected to the 'SECURITY' group in RACF with the CONNECT authority rather than the USE authority, as he is a 'Staff Manager'

¬

Zero Trust

This security model is based upon the principle “Never trust, always verify” and establishes strict access controls, wherein verification is required for every access request.

Every user and device must be authenticated before being granted access to any resources

Examples of this include Privileged Access Management (PAM), Multi-Factor Authentication (MFA) and One Time Passwords (OTP) and these may also use biometrics.

¬

Least-Privilege

This principle limits user access to the absolute minimum level that is required to perform their job functions, and only allows users to access the resources they need, when they need them.

By limiting user access, organizations can prevent unauthorized access to sensitive data and systems, reducing the risk of data breaches and cyber attacks.

For example, a hospital receptionist will need access to book appointments for patients, but should not have access to view their case files.

¬

The similarities (and differences)

Both strategies are designed to protect access points and control access to systems.

Similarly, both strategies were also designed to minimize risk or cybersecurity breaches to systems by following practices of trust removal and/or access limitation.

To clarify, Zero Trust (ZT) uses the "trust no one" concept, seeing every user as a potential threat, justifying the need for verification and authentication of all users;

Conversely Least Privilege (LP) doesn't necessarily authenticate, it just restricts access to "only what you need" and "only as long as you need it".

¬

One without the other

There are cases where companies will follow one of these principles without following the other, such as having ZT without having LP (or vice versa) but how might that look?

If a company only has Zero Trust, then once have proved that you are allowed in a system, you may have vastly more access than is reasonable, and you could (accidentally or maliciously) delete or amend data that you had no right interacting with, simply by pressing a few of the wrong buttons on your keyboard.

If a company only has Least Privilege, then access may be limited but there is a lesser requirement to prove who you are before entering a system (i.e. the barriers for entry are far lower, so it's easier for hackers to gain entry). Granted, this is less of a concern is someone gains access to a receptionist's account, but if a threat agent were to gain access to a System Programmer's userID then there is a huge capacity for damage to be wrought.

¬

Follow every principle

In an ideal world, all three principles will be followed simultaneously:

• With Zero Trust, users won't be trusted by default, only being allowed access once they are verified and authenticated.

• With RBAC, users will be connected to groups that correlate with their responsibility, authority and competency (e.g. Trainee Database Administrator).

• With Least Privilege, each group that the user is connected to, will have the absolute minimum access required, and access will only last as long as is deemed necessary.