Much emphasis is placed on the zero-trust approach to access. Beyond authentication (verifying that someone is who they say they are), authorization assessment is equally important because it determines what someone can do with that access. . Policies should be written to take this into account, and the strongest policies are built on a permission model that is orchestrated in nature.
An orchestrated, centralized approach to authorization creates dynamic and granular access control policies (FGAC) that meet the requirements of modern security strategies, including zero trust. Adopting a zero-trust approach to policymaking takes absolute trust out of the equation by continuously validating users at all layers of the application based on a set or combinations of attributes collected from multiple sources (i.e. who, what, where, when, why, how, etc.).
The concept of authorization is not new, and many organizations have developed ad hoc policies in the past when creating or adopting new applications, isolated within each application. Once created, they have often been forgotten. Moving to an orchestrated approach to authorization removes the siled approach and replaces it with a centralized, holistic view of policies. This means that organizations do not create new policies from scratch as each new application is added. Instead, they choose from existing policies, copying and modifying them as needed to take advantage of previous work. Plus, because it’s centralized, when a change to an existing policy needs to be made, it can be done in the same “one-to-many” approach, saving valuable time and providing better security. .
A policy based on centralized authorization orchestrated across the enterprise requires several key elements obtained through the policy modeling process. There are four key steps in this process.
Identification of candidates
The very first step an organization should take when moving to this model is to identify the number of applications or data sources that require a zero-trust approach. This is important because it forces a triage of the types of applications and data sources that are most crucial and should be the initial targets for deployment. Most enterprise-sized businesses now use hundreds of applications. Going from zero to sixty in terms of immediately applying policies to ALL is unrealistic. The identification step involves determining which are the most important to address first. More are added over time and as new policies are developed it will become much more efficient. This first step allows for a “start small, grow fast” approach.
Determination of requirements
The next step is to determine what the requirements are. During this phase of the project, it is essential that the security and/or identity managers (owners of this centralized process) involve the business stakeholders (application or product owners) from the start. ).
Requirements should be determined by the company. Now, some might point out that the company may not understand the intricacies of Identity and Access Management (IAM) solution features and protocols, but it does understand the information its applications access and how that information is affected. by compliance regulations. Therefore, based on guidance provided by the business, requirements should be written in natural language that is easily understood by both the business and the IT team.
Consider attributes
Now that the requirements are established, identifying the right attributes needed to inform authorization policies and controls is the next logical step.
For example, suppose that one of the requirements for a given application or data source is that no user outside of the European Union (EU) should be able to see personally identifiable information (PII) from customer data where the customer’s home country is the EU. Right away, we can consider a few attributes that will be needed for this requirement, one being the physical location of the user requesting access to the application, and the second being the country of origin of the record which the user is trying to access. There would likely be other attributes that could be taken into account, such as user role, device they are on, user risk score, time of day, etc. ., but it gives you an idea of the type of attributes that can be taken into account.
It should be noted that there is no limit to the number of attributes an organization can consider or the complexity of a policy in terms of the requirements you are trying to meet. So the goal is to identify the right attributes (quality versus quantity) to effectively balance security. with performance. Context is the key consideration and can be deciphered based on the attributes being evaluated. For example, taking into account a user’s physical location as well as the time of the request can provide a large amount of context that cannot otherwise be taken into account.
Here is an example :
Creation strategies
The final step in a centralized, orchestrated approach – and where the concept of zero trust kicks in – is policy writing. With the first three steps complete, it’s now time to write the policies to roll out across the organization.
These policies can be as simple or as complex as needed to achieve the overall goals of the organization. A policy follows the pattern of writing IF, THEN statements about the subject, resource or object, and action. It’s important to avoid confusion around other IAM solutions that can take advantage of role-based access control (or RBAC) as part of their authentication process. Although important, this step refers to a policy that is put in place after authentication. There are many cases where a user can be authenticated, but a policy can limit what actions they can take or what information they can see. Considering the example included in the last step, the rule might look like this:
Creative policies need to create a decision tree that could still allow business to be conducted smoothly while protecting sensitive information. In this context, here is an example of what could be done for the same policy where the answer to one of the questions is no.
The bottom line at the heart of the zero trust methodology is to never trust and always verify. By leveraging a centralized, orchestrated approach to authorization, security and/or identity managers can easily craft policies as complex or as simple as needed. Using this approach ensures that the organization verifies as many attributes as needed, providing the correct context to make an accurate and reasonable access decision.
Comments are closed.