Micro Focus is now part of OpenText. Learn more >

You are here

You are here

Why your approach to security architecture needs to change

public://pictures/nickn.jpeg
Nick Nikols Vice President, Strategy, Micro Focus
 

Organizations have a lot to worry about these days. With security breaches on the rise and organizations subject to ever greater scrutiny and reputational risk, would you be surprised to learn that most of your efforts may not be as impactful as advertised? 

Let’s assume that your organization has followed the conventional wisdom. You have invested in comprehensive identity and access governance, and you perform periodic reviews to make sure that you’re compliant and that your rules are being followed. You have standard workflow procedures in place for granting and removing access permissions.

Your HR department—or perhaps your Active Directory administrator—is in charge of managing all changes in identities and roles, serving as a trusty “single source of truth” to keep your company’s systems, apps, and databases up to date and safe.

Are you doing all you can to prevent improper access and avoid a security breach? Unfortunately, the answer is no. You may think you’re running a tight ship, but in reality, it’s full of leaks. You just don’t know about them.

That’s because your security architecture is living in the past. Data travels quickly in the age of the cloud. If your system isn’t keeping up, it’s giving you a false sense of security and putting your most sensitive information at risk.

Here's why your approach to security architecture needs to change.

The one-way workflow model

Most organizations set up identity lifecycle management as a one-way workflow, starting with a system that is considered authoritative and updating other systems step-by-step as the workflow dictates. Typically, it begins when identities are on-boarded into the environment, such as when you've hired employees or contractors, and continues through the lifecycle until the time they leave. As part of this, the system that initially collects the identity information is often viewed as the authority for this information, or sometimes the organization deems that the central repository that persists the identities should take on that role. In reality, however, things rarely are that cut and dried. 

Let’s say a newly hired employee, Hank, has his information entered into the HR system. This information will usually consist of things such as his employee ID, his department, his manager, his location, and other information that an employer needs to collect about an employee. In order to perform his duties, Hank also needs to be set up in and granted entitlements to other systems such as email, applications, and databases that his job requires. 

Often the information obtained from the HR system can be used to determine his initial level of access. This information can be either pushed automatically to the specific systems to create accounts or grant entitlements in these systems, or can be sent to administrators of these systems where these activities can be performed manually. After which Hank should have everything that he needs to get started. So far, so good.

However, the state of affairs does change over time. As the identity relationships change, so does the identity data maintained within each of these systems. For example, employees may change job functions and responsibilities, requiring that new entitlements be granted or new accounts created in order to perform these new functions. Old entitlements that are no longer needed should be revoked. However, this isn’t limited to employee/employer relationships. The relationships between vendors or service providers and their customers go through a similar lifecycle. As customer loyalty waxes and wanes, so do the benefits that their loyalty programs provide.

Revisiting Hank two years later, he has changed roles to working in accounts payable after beginning his career working in accounts receivable. This new role requires that he relocate to a different office and report to a different manager. His HR records are updated to reflect this change and his new boss grants him access to a new set of applications and data repositories. However, since access to the accounts receivable applications are manually managed by the local administrator, it is common that role changes may sometimes get overlooked and old, unnecessary entitlements may not be revoked as they should.  

Because of this oversight, Hank now has access to both accounts payable and accounts receivable, a violation of separation of duties as required by many regulations such as Sarbanes-Oxley. This is a situation that opens up the potential for financial fraud.

A few months later, the company undergoes a formal access review process, detects this anomaly and removes Hank's old entitlements and access privileges. 

The problems spread widely in one-way models

Security models that only employ unidirectional workflows, periodic access reviews, and manual enforcement of access policy often lead to dangerous gaps such as these. When administrators are put in the position of having to manually enforce changes to access policy and keep up with the changing dynamics of personnel and the organization, all in addition to doing their primary administrative duties, mistakes get made, potential problems get overlooked, and the organization accumulates bad data. 

Reconciliation and periodic access review don’t always resolve the problems. Due to their intermittent nature, these approaches miss all kinds of changes and activity that violate policy or put the organization at greater risk. In the case of reconciliation, because the changes are not being picked up as they happen, the context for those changes and the order of the changes are lost. When the reconciliation process takes place, it can only compare the values from the different systems and detect that they are not in sync. It can’t determine which instance of the data is the most recent version and whether that change came from a source that is truly authoritative over that attribute. 

Since the context that would determine the order of those changes was not captured, conflicting values can only be resolved by choosing a single source of truth for all of attributes (such as the HR system or Active Directory), but this completely ignores the fact that often the situation within the organization is much more granular. There may be different authoritative sources over different attributes; for example, the email address is an attribute whose authority is the email system, while the employee’s manager attribute should look to the HR system to be the authority over its value. Out-of-band reconciliation forces authority at the system level rather than at the attribute level, which is far too coarse and can lead to bad data being propagated.

Outside of the reconciliation process, the other practice that can lead to a false sense of security is periodic access review and attestation. With this kind of process, there is potentially a gap of months between points of inspection and review. During that time, mistakes made in the issuance and revocation of entitlements may allow inappropriate privileges to persist, leaving open the potential for abuse. In one study, 48% of IT leaders said they were aware that former employees still had access to the corporate network. One-fifth said it takes their organization a month or more to deprovision workers.

Allowing excessive and/or inappropriate privileges to persist creates opportunities for hackers and temptation for unscrupulous contractors, or employees with a grudge. More than one-third of breaches involve an insider, and 15% involve privilege misuse, according to Verizon’s 2019 Data Breach Investigations Report.

The new approach: Continuous, real-time updates

Today’s technology provides a better way for organizations to manage change. There are better answers than having everything monolithically pushed from a single source of truth, missing when attribute values are changed on the various copies of information maintained throughout the organization, periodically attempting to reconcile the inconsistencies, and then only taking the time and effort to collect all of the entitlements and reviewing to see if the access is appropriate. Organizations can instead utilize real-time, event-driven security architectures that allow changes made throughout the systems to be bidirectionally orchestrated automatically, eliminating the need for periodic reconciliation, while closing the gaps and potential points of abuse. This provides much greater security in a consistent and sustainable fashion.  

The event-driven approach is not only safer, but also much more efficient.

Because of the approach's ability to detect changes as they happen, the accuracy and cleanliness of the data can be maintained and kept consistent across all of the systems that have an interest in the changes. For example, when an authorized email administrator updates the email address attribute of a particular employee on the email system, and that attribute is of interest to other connected systems (such as the HR system and an employee directory), the change automatically updates the other systems with the new email address value, since the email system has authority over the email address attribute. 

However, if the administrator of the employee directory tries to update the email address of a particular employee, since the employee directory is not authoritative over the email address attribute, an event-driven solution can determine that this change is not from an authoritative source. Instead of propagating the change, it can reset the attribute value back to the value that the email system (the authoritative source, in this case) maintains.  

Given this enforcement of attribute-level authority, an event-driven approach facilitates the reduction of stale and inaccurate data by leveraging the natural activities of the systems that operate on that data and sharing their updates with the other systems that require it. This, in turn, provides a much more stable, data-driven platform for determining and enforcing appropriate entitlements. 

Since all change events are detected and processed in real time, entitlement assignments can be automatically granted and revoked as needed, and the chances that unauthorized access will slip through the cracks is greatly reduced. Data discrepancies disappear. The entire organization functions like a symphony orchestra, with everyone doing their part and working in harmony.   

A reality check in the age of the cloud

In today’s cloud-driven environment, people expect changes to be seamless, immediate, and universal. Many believe their security system functions that way, but the reality is far different.

It’s time to admit that the one-way workflow reconciliation model is broken, and periodic access review is insufficient. In a world where you have a nearly 30% chance of being breached in the next two years, the old model needs to be scrapped and replaced with a real-time, company-wide, event-driven architecture.

Keep learning

Read more articles about: SecurityIdentity & Access Management