Foreword
Security is all of our concern, whether you are a receptionist or an engineer, and whether you work in an office or from home.
We all have a part to play, in ensuring our organisations and systems stay secure.
As we continue through Cyber Security Awareness Month (CSAM), I wanted to ensure that people are aware of some of the 'core' security concepts.
Over the course of CSAM, I will be writing posts about aspects of cybersecurity / mainframe-security.
In today's post, following last week's Z Day, I shall briefly outline three of the most important Cybersecurity Principles, as well as how (and why) to use all three.
|
RBAC, Zero Trust and Least-Privilege:
Where valuable data can be found, hackers will try to investigate, infiltrate, extract, and extort data.
This may be done for monetary gain (e.g. Ransomware), on behalf of another entity (e.g. Industrial Espionage) or for a Nation-State (e.g. military secrets).
Regardless of why hackers do this, it should be no surprise that data is the target!
In an age where the global economy revolves around digital technology, data is the most valuable commodity on the market.
In order to keep systems secure, it is worth following security principles:
|
Role Based Access Control:
Role-based access control (RBAC) restricts access based on a person's role within an organization and has become one of the main methods for advanced access control.
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.
Roles can be based on several factors, such as responsibility (e.g. Security), authority (e.g. Manager), job competency (Junior), etc…
Let's create an example: "Bob" has the job title "Senior Security Manager" and is therefore may be connected to three different groups/roles.
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.
|
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.
-
Both strategies were also designed to minimize risk or cybersecurity breaches to systems by following practices of trust removal and/or access limitation.
Zero Trust 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 doesn't necessarily authenticate, it just restricts access to "only what you need" and "only as long as you need it".
|
Follow every principle
In an ideal world, all three principles will be followed:
-> 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.
|
Illustrating RBAC:
As a final note, I have provided a "RACF diagram" above to illustrate that automated RACF-IDs will often be directly permitted to access resources (via profiles), while users will only be indirectly permitted via their connections to groups (e.g. a 'Security' role group).
------------------------------
Niall Ashley (he/him)
Consultant in Mainframe Security (RACF)
Vertali Ltd
------------------------------