So, despite some success stories and the cardinal role of identity in business transformation, IAM remains a disparaged theme in organizations, synonymous with a “necessary evil” rather than a “key issue” for the company.  

How can we restore IAM’s reputation? How can we explain it better, and give it its rightful place in the enterprise? 

The paradox of identity 

An essential driver of transformation programs… 

This situation is paradoxical as identity plays a fundamental role in current transformation programs, presenting three major assets. 

• It is first of all a pillar of cybersecurity by allowing: 
  • Have a homogeneous knowledge of all users, centralizing essential information such as name, manager, title and many other characteristics specific to each; 
  • Guarantee the uniqueness of individuals through the publication of a single repository; 
  • Control and adapt user access throughout their lifecycle; 
  • Be part of a Zero Trust approach by ensuring that only the right people, with the right level of rights and the right level of authentication access to the appropriate resources. 
• It is also an essential business facilitator, particularly for: 
  • Accelerate cloud service adoption and deployment of new applications through automatic account creation and simplified entitlement (often through an IGA – Identity Governance & Administration tool); 
  • Facilitate the controlled opening of the IS to and towards third parties: partners, suppliers or in case of creation of Joint Ventures; 
  • Improve, thanks to CIAM (Customer Identity and Access Management), the customer relationship and regulatory compliance by simplifying the progressive creation of accounts and compliance with privacy regulations such as the GDPR in France. 
• Finally, efficient identity management is a prerequisite for a state-of-the-art user experience, combining comfort and security requirements: 
  • Seamless and seamless access to all its applications and data, regardless of its access context; 
  • Access rights granted automatically and available on the day of arrival; 
  • A single portal to make and follow up your ad-hoc requests. 
  • Pertinent dashboards and targeted review campaigns to meet regulatory requirements without over-soliciting managers and process owners. 

… but a theme unfairly considered 

Despite the significant advantages it represents, the theme of identity is rarely at the centre of companies’ concerns. It is rather perceived as a necessary evil, or even occupies a place of «ugly duckling». Thus, it is common to note the pitfalls when Identity is insufficiently well managed, and even more common to consider as normal and acquired the benefits it produces. 

Beyond the simple constant, it is necessary to understand the reasons that led to this situation of lack of investment, sponsorship, even recognition. 

First explanation of the paradox: the dispersion of expected gains towards different beneficiaries. Indeed, the IAM is, by nature, very transversal in the company. To succeed, it must embrace a wide range of topics and therefore mobilize many stakeholders. If each of them will see gains; none will stand out enough to bear primary responsibility. For example: 

• The identity makes it possible to simplify the customer relationship, subject of major interest for a marketing/ digital manager, but not the compliance manager. 
• The latter will see identity as a significant advantage in meeting the CAC’s access review requirements. 
• The IT department will expect consistent and automatic management of the allocation of accounts and rights, synonymous with financial gains, particularly in terms of licenses, support, etc.  
• As for the CISO, its priority will be to remove access in the event of departure and the application of the principle of “less rights granted or the early detection of “suspicious” behaviour. 

Second explanation: like any transformation, which is transversal, the launch and success of an identity project is conditioned by essential prerequisites. 

The difficulty and effort required to achieve these prerequisites depend on the context of each company; but the prerequisites themselves are relatively constant and can be articulated around 4 axes: 

• Data quality: both for data consumed by IAM (organizations, structures, identity data from HR…) and for data that IAM must make available (application account identifiers, attributes in applications…).
• In-depth knowledge of end-to-end processes: this is essential to anticipate the impact of future changes on users, but above all to be able to change and harmonize ways of doing things, and not to continue with what already exists “because that’s the way it’s always been done”.
• Mastery of the applications to be connected: it is necessary to mobilize both technical knowledge (technologies used, APIs available…) and functional knowledge (user populations, data model, authorization model…).
• Last but not least, the ability to impose a “normative” IAM framework, to find a compromise and to arbitrate both on the target (operational model, functional framework, attributes and management rules, arrival/mobility/departure processes, standardized connection framework for applications…) and on the trajectory and success indicators (priorities, subdivision…). To put it in a nutshell: “It’s not IAM’s job to heal what has been poorly thought out or what has become inadequate over time“. 

Third and last explanation: a complete identity management is based on several complementary technological bricks. With varied origins and somewhat ambiguous names, it is not always easy for a non-expert in the field to understand precisely the contribution of each of these bricks: 

• IGA – Identity Governance & Administration: Identity Governance 
• IAI – Identity Analytics & Intelligence: Data analysis and control 
• PAM – Privileged Access Management: Privileged Account Management 
• AM – Access Management: Authentication and Access Control 
• CIAM – Customer Identity & Access Management: Client identity management 

What’s more, these names have evolved over time, sometimes legitimately to reflect major developments, sometimes more as a result of publishers wishing to differentiate their value proposition. The emergence of new functionalities (real-time detection, consent management, etc.) and the innovations proposed by software publishers are also changing the lexical field of IAM. 

How to give identity its rightful place in the company? 

To overcome this paradox, the usual avenues (high-level sponsors, more resources, evangelization, etc.) are necessary but often insufficient. More structural transformations are needed. 

Unify the strengths of identity under one banner 

IAM topics have emerged in scattered order in companies, and have matured at very different rates. The result is that, all too often, teams remain isolated. 

It is therefore imperative to bring together all identity-related teams and budgets under a single umbrella. And if, as the saying goes, there’s strength in numbers, the aim is not just to be visible, legitimate and have a say in the organization. 

Synergies abound: 

• Make identity a perennial and recurring topic, at the very least at the level of the CIO CoDIR, and in all company evolutions.
• Define a global value proposition, proposing a unified offering that is more legible for business lines and application managers, who will be able to rely on a single point of contact.
• Be part of a long-term strategy to take advantage of software publishers’ roadmaps, create a continuous improvement approach and prepare for future corporate changes: reorganizations, mergers & acquisitions, new ERP…
• Improve the consistency of IAM services and manage with end-to-end service indicators.
• Guarantee a high level of expertise by enhancing team know-how, building loyalty and offering richer development perceptives. 

This far-reaching transformation can appear delicate and a source of risk for companies with less mature IAM systems. This is why it is possible to initiate it gradually, starting from one of the following axes: 

• Bringing together under a single organization the teams working on the various IAM themes: IGA, IAI, AM, PAM and even CIAM.
• Unify the teams in charge of projects and those in charge of “RUN” in order to offer a “product” approach to each identity service, and to be part of a continuous improvement logic.
• Extend IAM teams’ responsibility for data control, so that they can commit to indicators and, ultimately, to the quality of service provided and perceived. 

On this last point, however, IAM teams cannot assume responsibility for the quality of the company’s data and repositories. They must, however, guarantee the quality of the service rendered, by ensuring both the proper operation of IAM services (the “container”) and the quality of the data manipulated (the “content”). IAM teams must therefore be equipped and organized to supervise, control and alert the quality of data received, as well as the use made of it. 

An advantageous unification but which obligates 

This ambition for unification, which puts IAM in the spotlight, de facto obliges the Identity manager to be exemplary in his role and responsibilities: 

• With regard to customers: have a clear service offering, take into account feedback and realities in the field, define and respect a roadmap of evolutions, provide “meaningful” service quality indicators, i.e. those that make sense in the day-to-day life of the business, promote gains and benefits…
• Regarding other stakeholders in the company (HR, Purchasing, Cybersecurity, Regulatory Compliance, Audit and Control…): communicate, materialize and help to appropriate the Identity value proposition on a day-to-day basis and during structural transformations (reorganizations, acquisitions…), find ways to compromise, show the “win-win” character of process and operational model evolutions, share everyone’s roles and responsibilities, illustrate the impacts in the event of breaches… 
• For its teams: have a robust operating model, balance responsibilities between internal employees and external service providers, build a genuine HR ambition for the medium and long term (validation of expertise, talent management, building career paths, enhancing the value of the IAM channel…). 

Conclusion 

The unification of IAM services is a fundamental trend, and within 3 years a large majority of large companies will have converged towards this model, at least partially. 

This movement is not always the result of a desire to reposition identity within the organization on a long-term basis. It is sometimes imposed by teams to compensate for a lack of resources or expertise, or in the hope of keeping costs down; in such cases, it reinforces the feeling of lack of consideration. 

And yet, there are many opportunities to demonstrate the need for an in-depth rethink of IAM ambition, and to give it its rightful place: technical obsolescence of IAM tools, corporate strategy to switch to Cloud solutions, difficulties in accompanying structuring transformations in the organization, new regulatory requirements, or the results of a simple satisfaction survey among users or application managers…  

Do you dare to seize them? 

Cet article ​​How to give identity its rightful place in the company​  est apparu en premier sur RiskInsight.

Let’s continue here with a few additional questions – and answers – to explore the subject in greater depth.

How many roles do I need to create? How many roles should each user have?

It may be tempting to design a model that can handle every use case identified during a requirements collection phase. However, we should bear in mind that the model will have to live and evolve with new applications, new organizational units, etc.

There is no general rule on the number of roles to assign to each user. It is perfectly possible to build your model so that only one role is assigned per user, just as it is possible to assign several.

However, a compromise must be found between creating overly specific roles, which quickly fall into the “1 role for each user” pitfall, and creating overly general roles that do not bring much benefit and lead to over-allocation of rights.

Aiming for 80% of rights allocated via the role model and 20% of discretionary rights should already prove to be a good goal.

Bottom Up or Top Down, which method should I use?

There are two main methods that can be considered when creating an authorization model.

The “Bottom Up” approach starts from the existing rights and analyzes them to derive a model. For example, if all employees in the Accounting department have the same rights, then a role dedicated to this department can be created, which will contain the corresponding permissions. In this approach, data quality is a prerequisite for successful modeling, as wrongfully assigned rights would add noise to the model and reduce its relevance.

The “Top Down” approach starts by defining the theoretical authorization model, on which the necessary authorizations are then projected. For example, a role for the Accounting department can be created and include the permissions that business representatives deem necessary to accomplish their mission.

In practice, it is common to adopt an intermediate approach.

It is also recommended to work iteratively and to validate the approach on a pilot scope before generalizing it. The involvement of business representatives in the definition and validation of the roles plays a key role here.

What tools do I need?

The high volume of rights to be processed and the multiple iterations required imply the use of a tool that can either be sourced from the market or developed internally (Excel tables, database, scripts…). A prior analysis of the needs will ensure the adequacy of this tool.

In addition to the ability to create roles or rules for assigning rights, which is increasingly facilitated using algorithms that take advantage of machine learning, the chosen tool must facilitate the data quality cleaning phase before the actual modeling phase. It is also useful to have a simulation function that highlight the over- or under-allocations generated by the new model compared to current assignments.

In nominal mode, the IAM solutions on the market offer various possibilities that can used advantageously: role hierarchy, automatic ABAC-style allocations, suggested allocations, multiple role dimensions, etc. However, care must be taken not to fall for a model too complicated to use and administer.

If the choice of the IAM solution that will handle the model has already been made, it is necessary to ensure that this solution can handle all the desired complexity, even if it means making some simplifications or adjustments to the model.

Should I build my authorization model before, during, or after the implementation of my new IAM solution?

Generally speaking, it is preferable to design your authorization model before the implementation of a new IAM solution as the model can strongly influence the choice of the tool, depending on the adequacy of the technical possibilities and the functional expectations.

If data quality is satisfactory, the implementation of the model itself can then take place at the same time as the implementation of the IAM solution. If necessary, it is possible to plan a transition phase where the old tool can coexist with the new one. The perimeters ready for the transition to the new model can thus processed in the new tool, which gives more time for the migration of perimeters that require more work and time, although a migration schedule should be defined and closely monitored to avoid any drift that would prolong this situation for too long.

How much time should I plan?

The implementation of an authorization model is usually substantial project that requires the consideration of many factors and has a significant impact on all the stakeholders involved in the authorization environment (application managers, user support, business lines, etc.).

It is essential to take your time during the framing and design phase in order to ensure the success of your project.

The modeling phase can be long and tedious, especially if the volume is high in terms of the number of roles or the number of entities to be covered, or if the data quality is unsatisfactory and requires remediation.

Change management should not be neglected, given the impacts that are clearly visible to users. Training and a strong support phase are most of the time necessary once the model has been implemented.

What governance should I establish to bring my authorization model to life?

An authorization model is never static. The authorization catalog is updated as new applications are developed or decommissioned, the information system and business undergo evolutions, and reorganizations are carried out. Right from the design phase, it is necessary to reflect on the principles of current governance to avoid building a model that is too complex and impossible to maintain over time.

While the management of the model is often handled by a team dedicated to authorizations, the involvement of other stakeholders is essential, particularly on the part of the business, which must communicate any changes in its needs. The appointment of authorization correspondents within the business departments can be a way of encouraging this involvement.

Final words

The perfect implementation of an authorization model probably does not exist. Even if there is no major interdiction, finding a compromise between expectations and possibilities remains a delicate exercise that requires careful planning, preparation and monitoring.

In a nutshell, here are five good practices for the success of an authorization model redesign project:

1. Allocate sufficient time for the project.
2. Frame and steer the project with the greatest care to avoid deviations in terms of ambition, priorities, workloads or deadlines.
3. Communicate with and involve the right IT and business contributors.
4. Know when to say “no” if covering a need would risk deteriorating the ease of use or the maintainability too much.
5. Do not neglect the change management with the end-users.

It is worth note that these good practices remain perfectly applicable to any IAM project in general!

Cet article Redesigning your authorization model: the key issues (2 /2) est apparu en premier sur RiskInsight.

DAC, RBAC, OrBAC, ABAC or GraphBAC? Flagship authorization models evolve regularly and each one brings its share of challenges, promises, and complexity.

Over the last twenty years or so, during which the RBAC/OrBAC models seem to have prevailed, the difficulties of designing, implementing and maintaining an authorization model have remained the same, and there are few examples of perfectly satisfactory achievements.

There are many questions about designing or redesigning one’s authorization model. In these two articles, we try to answer the most frequent ones.

Before we do that, let’s go back to some basic notions about authorization models.

What is an authorization model?

A layer of abstraction…

An authorization model is a layer of abstraction that comes above technical entitlements (application rights, transactions, groups, etc.). It is made up of carefully defined objects (roles, profiles, etc.), with a name in natural language, and often organized hierarchically.

… which simplifies the management of authorizations…

This layer of abstraction makes it possible to rationalize the number of objects to handle.

For the business, it becomes easier to understand the available authorizations and to request or validate the appropriate rights.

For IT and support teams, the burden of allocating authorizations is reduced overall. The implementation of automation tools can support a large part of the daily requests, allowing specific requests to be processed more carefully.

… and improves security

Beyond the regulatory and normative dimensions of authorization management, often highlighted by Auditors during their work, the lack of control of authorizations is an open door to intrusions and misuse of the information system.

Knowing one’s authorizations is a prerequisite for securing them, and the implementation of a model makes it possible to simplify the controls, particularly during review campaigns. It is indeed much easier for a manager to validate the allocation of a meaningful business role, rather than of a transaction with a very technical name.

Overview of possible models

DAC: Discretionary Access Control, aka no model at all!

What if the best model was the absence of a model? In some limited cases, especially if the number of authorizations or users is very limited, one can very well do without designing a model that would add an unnecessary layer of complexity. This implies, however, that the authorizations are sufficiently meaningful.

RBAC: Role-Based Access Control

The RBAC model allows to group the authorizations required to perform a function within a company (business, mission, project…) in “roles”. These roles are then assigned in lieu of discretionary authorizations. They can be organized hierarchically, for example by subdividing “business roles” into “application roles”.

OrBAC: Organization-Based Access Control

The OrBAC model is a variant of the RBAC model in which the entities that make up a company are one of the modeling dimensions. Each user then has one or more roles depending on which team(s) they belong to.

ABAC: Attribute-Based Access Control

The allocation of authorizations via the ABAC model is handled through a set of rules based on attributes related to users, resources themselves, or the environment. This allocation is often “dynamic”, meaning that the authorization to access an application or part of an application is evaluated at the moment the user tries to access it. In practice, it is possible to set up an ABAC model that takes advantage of user’s roles, as in the RBAC model.

GraphBAC: Graph-Based Access Control

The GraphBAC or GBAC model is based on the representation of authorizations using a graph linking objects (file, user account…) through various relationships (link between collaborator and manager, belonging to a structure, possession of a file…). The authorizations are then the result of queries on this graph, which allows to give access to a resource according to its relationship with other objects.

Market vision

The table below compares in a very synthetic way the different authorization models that we have just seen.

The most common questions about authorization models

What should my empowerment model be used for?

Setting up an authorization model can be complex, costly, and time-consuming. Therefore, it is crucial to study the needs in depth and to clearly define expectations. As mentioned in the introduction, the implementation of an authorization model can help address access security issues, meet regulatory objectives, but also simplify the user experience and improve the efficiency of Identity & Access Management (IAM) processes. One of the key success factors for an authorization modeling project is the ability to express the expectations precisely, using KPIs if necessary: reducing the time required for a manager to grant accesses when an new employee joins to 15 minutes, mitigating 90% of risks considered critical, etc.

Who should I involve to build, instantiate, and keep my model alive?

Given the cross-cutting nature and scale of the transformation induced by a change or creation of an authorization model, a strong governance is necessary.

It is preferable to involve a sponsor with high visibility from the EXCOM, who will be able to provide support, and obtain strong engagement from the business, the first concerned by the changes, and from application managers, who will be heavily involved during the design and implementation phases. Key contacts can also be identified, so that they can help different teams within the organization (HR, IT, Internal Control…).

Beyond the project phase, it is also necessary to identify the actors who will be in charge of keeping the model alive. A key success factor in the implementation of an authorization model is the identification of role owners. If each role includes only authorizations from a single application, one can easily to turn to the application manager, but in most cases, each role is made up of authorizations from various applications.

The ideal is to find someone who has both knowledge of business processes, company organization, applications, and an understanding of security rules: it’s a difficult exercise! Otherwise, a small team combining the different area of expertise should be able to perform this function.

Do I have to include “fine-grained authorizations”? The “perimeters”? How granular should my model be?

The world of entitlements is as vast as the multitude of existing applications, and the use cases that an authorization model must cover are numerous.

The topic of fine-grained authorizations and perimeter management regularly comes up during the design phase: should they be included in the model or not? There is no predefined answer.

It is perfectly conceivable, in some cases, to restrict the model only to the binary access to the application (yes/no), and to leave the management of the fine-grained authorizations and perimeters in the hands of the application manager and their team. The request form may then provide a text field to provide additional information. This results in less auditability, but the management of requests is simplified.

If we decide to include the concept of perimeter, we must choose between a cross-implementation, in which we create as many roles as there are combinations between authorizations and perimeters (possibly increasing significantly the number of roles), and a separate implementation, where the authorizations are created on one hand and the perimeters on the other.

It is probably best to deal with this issue separately, even if it means creating roles combined with their perimeter in the future, depending on the real use cases: the resulting model thus has a more reasonable size.

What should I include in my model? What about physical accesses and physical assets?

Including all the authorizations within one’s model is extremely difficult, if not impossible given the wide variety of cases, and for the sake of project efficiency.

The goal of the model must always be kept in sight. For example, if the goal is to improve the user experience when requesting rights, it is better to prioritize the processing of business-oriented authorizations, which are likely to be allocated frequently, over little-used technical authorizations.

In addition, it may be tempting to include physical access (premises, specific rooms, etc.) or physical assets (badges, PCs, telephones, etc.) in its authorization model, as they are part of the means that employees must have to work, just like logical accesses.

Again, there are no major prohibitions, and some companies may well manage access to their premises within their authorization model, but as a general rule, physical access and assets are rarely part of it.

An IAM solution may however help manage them properly:

• By centralizing requests, sent to different actors or systems upon arrival of a collaborator. This “arrival package” then includes both logical accesses (accounts and default rights) as well as physical resources.
• By providing a reference source for data and events related to a person. This information, especially arrival/departure dates, is shared with badge management systems to manage the badge lifecycle.

We have just addressed four initial questions to carry out a project to overhaul an authorization model. Other questions will be detailed in a second article, to be published shortly.

Cet article Redesigning your authorization model: the key issues (1/2) est apparu en premier sur RiskInsight.

We have cited five key success factors needed to deliver an ERP permissions risk-remediation project:

The key success factors for an ERP permissions risk-remediation project

The first two key success factors were discussed in the previous article; and the other three are covered in this one.

3. Preparing for large-scale deployment

Services, business lines, geographical or legal entities… the remediation of permission-related risks means reviewing user accounts across varied—and often numerous—functional areas. To be able to keep to schedules, limit workloads, and reassure those involved in the project locally, it’s best to deploy things at as larger scale as possible. Doing this means:

• Defining and communicating the risk analysis and remediation methodology;
• Putting in place a steering plan;
• Introducing analytical tools, automated as far as possible, to cope with volumes;
• Formally preparing materials for workshops and consolidation sessions;
• The documentation for the methodology and the tool in order to be able to train users.

These documents will form the deployment kit to be used in the different areas of work of the project phase; this can also continue to be used when the project phase is complete.

The deployment kit for an ERP permissions risk-remediation project

The deployment methodology will need to cover the following activities, and will need to be recreated for each area of work:

• Risk assessments and the definition of KPIs.
• Remediation workshops for user-related risks.
• Validation and execution of remediation plans.
• Training and support for upskilling.

Obviously, the methodology must be adapted to the company’s organizational structure and the resources available to it: the workforce, local variations in business processes, the degree of maturity in risk and permissions management, etc.

In particular, this will involve engaging local experts both on the technical aspects of permissions (access rights officers, application owners, security officers), and on the business-function aspects of processes (business-function representatives, process owners, internal controllers, team managers, etc.). The contribution that will be expected from them, and the effort they will need to put in, should be clear from the start and must remain “reasonable”. Local managers should therefore be involved, to ensure that those who need to take part do so, and to help in decision-making.

During remediation workshops, participants will, in particular, analyze user-related risks, but they will also have to consider various remediation strategies, such as the ones described below:

Strategies to consider in an ERP permissions risk-remediation project

It’s always preferable to validate the methodology using a pilot project that is small enough to limit work volumes, but large enough to be representative of the company. In some cases, a better strategic choice may be to select a work area that’s likely to be more fruitful for the project; or, conversely, one that’s expected to require more support. The lessons learned at the pilot stage will allow the methodology and tools to be adjusted before they are deployed more widely.

4. Selecting the right tools

The tools put in place must aid success during the project phase, but also—and more importantly—provide long-term support for the chosen approach; both these phases must be complementary.

Being well equipped is about being clear on the initial controls to be applied (at the point when new permissions are requested) as well as on the ongoing controls (those applied once permissions have been granted). Having more initial controls will help reduce risks, but operational efficiency may also suffer (delays, difficulties in processing requests, etc.); a balance needs to be found.

From a functional point of view, it’s a question of putting in place the families of controls typically found in such projects, namely:

• Data quality controls: completeness and coherence of data; respect for nomenclature, etc.
• IT security-rule controls: orphan, dormant, and administrator accounts; temporary and residual permissions; IT accounts with business-function permissions and vice versa, etc.
• Business-functions rules/compliance controls: discrepancies between jobs and the associated permissions; discrepancies in permissions between members of the same team; breaches of rules on the segregation of duties; users having access to areas that are beyond the scope of their responsibility, etc.
• Usages and behavior control: excessive or unusual uses, suspicious behavior, typical fraud scenarios, etc.

Families of typical controls for an ERP permissions risk-remediation project

Being well equipped is also about prioritizing and automating the controls that are worth putting in place. The return on investment must be assessed in terms of each control’s relevance to the company’s situation (does the control cost more than dealing with the consequences of the risk it’s designed to cover?), and the potential benefits of automation (how much will be saved compared with a manual process?).

The volumes and complexities associated with ERP authorization models means turning to tools specifically designed for the task: for example, it’s not unusual to see SAP systems with several thousand roles and over a hundred thousand fine-grained permissions (transactions and authorization objects).

These needs fall at the intersection of several different segments of the software market; these are currently highly dynamic and far from mutually exclusive: “Identity and Access Management”, “Continuous Control”, “Specialized Governance-Risk-Compliance tools on a given ERP”, and so on. Given this, the approach taken, degree of maturity, functional coverage, and mode of delivery (on site or cloud/SaaS), can vary substantially from one product to another.

When selecting a tool, it’s a question of considering the following elements carefully:

• Ergonomics and ease of use: once the project is finished, the tool’s users will be mostly from business functions—not from IT.
• Customization options: such that the tool really can be used to support the methodology taken (vocabulary and screens, rules and controls, dashboards and reports customized to company needs, etc.).
• A package of preconfigured controls: usually based on good practice, for the company ERP.
• The ability to put in place controls on other applications, and between applications: over the medium-term.
• Analysis and decision support functionality: to highlight anomalies, simulate changes in permissions, conduct in-depth analyses, suggest remediation measures, etc.

Although the tools are generally not intrusive, in terms of their effect on applications, there’s still a need to automate the transfer of data, in a reliable way—from the ERP and other potential repositories. Involvement of the relevant IT teams will thus be needed too.

5. Getting things right for the long term

Projects of this type only make good sense if permission-related risks can be controlled effectively over the long-term. Doing so avoids the problem of risks that have been brought under control during the project appearing again—some time later.

To encourage long-term buy-in to the approach and tools put in place, it’s essential to invest in change management from the start—and throughout the project—by means of meetings and regular newsletters, training and coaching sessions, documentation and tutorials, etc. It’s best to use a diversity of channels and communication supports to reach the maximum number of people without giving the impression of over-marketing.

It’s also important to help those responsible for permission-related risks to apply new controls to their recurring activities. In fact, the frequencies of advanced controls, the objectives to be achieved, and the levels of risk that must not be exceeded, can be explicitly defined. These objectives must be realistic and progressive: “What’s needed is to envision a long road—but with short milestones.”

There must be an emphasis on community too: it’s important to encourage interactions between managers from different functions, which will enable them to share experiences and good practice. There may even be a value in introducing a degree of healthy competition between different business functions; perhaps even organizing some low-key challenges. However, you should ensure that the fact of making progress is valued more highly than achieving any specific numerical objective, because the various work areas will have to progress from very different starting points.

Finally, an “ongoing” mode needs to be implemented—to ensure that permission-related risks remain under control once the project is completed. This should include:

• Choosing a designated contact for the methodology and tools put in place;
• Upskilling the technical teams to ensure in-service support for tools, and that reports and controls can be developed when necessary;
• Documenting and capitalizing on the knowledge acquired during the project phase.

This must give consideration to developing a roadmap for other future activities that will address new processes, risks, applications, or populations.

Long-term control of the risks related to ERP permissions

In conclusion: it can be done!

As we’ve seen in the two articles on this topic, controlling the risks related to ERP permissions means pursuing a number of key workstreams—from putting in place the right tools, through holding workshops for the business functions, to training and change management.

But with a good methodology and committed participants from IT and the business functions on board, anything is possible! Tangible results can be achieved—and corporate momentum built—within a reasonable timeframe, to regain control of permissions across the IS. And, lastly, the key success factors presented here are broadly applicable to applications other than ERPs.

Cet article ERPs: How to control permission-related risks (PART 2) est apparu en premier sur RiskInsight.

And statutory auditors, internal controllers, and auditors, are only too well aware of this; they’ve been increasing pressure for several years now to bring these risks under control and ensure compliance with the relevant regulations.

ERP permission-related risks that need to be brought under control

What’s needed is to take a serious look at the topic of “permissions ” (which are also called rights, authorizations, roles, or access profiles). In fact, the permissions granted to users on a company’s ERP enable them to carry out a large part of their activities—legitimate or otherwise. By ensuring you provide only the right people with the right permissions at the right time, you can significantly reduce the risks mentioned above.

Over two articles, we present our vision for this area, and share proven good practices that can bring the risks associated with ERP permissions under control.

Companies show little rigor when it comes to ERP permissions

ERP ecosystems are complex, and companies typically spend a great deal of time and energy setting their ERPs up. Yet a minimalist approach is often taken to the “identity and access management” aspect of ERPs. Over time, this results in a deterioration in levels of control and security:

• Obsolete, generic, and shared accounts accumulate.
• The number of roles explodes.
• The principle of least privilege is not properly applied.
• Toxic combinations of rights (infractions of the segregation of duties principle) occur, etc.

All of these factors tend to increase the risks mentioned above.

Key Success Factors for an ERP permissions risk-remediation project

As a result, few companies can claim to have complete mastery of the identities and permissions aspects of their ERPs. To illustrate this, consider the indicative questions below to assess your understanding of the subject:

• How many accounts can’t actually be associated with a single individual (generic accounts, accounts not reconciled with an HR repository or Active Directory, etc.)?
• How many users can change the access rights of other users?
• How many users have profiles with high levels of privilege (such as “SAP_ALL” and “SAP_NEW” in SAP ECC)? Of these, how many are really legitimate?
• How many users can change the suppliers master data?
• On average, how many roles are assigned to users? Is it typically two or three roles per user, or do numbers of roles often reach double digits?
• How many IT roles are assigned to business-function users and vice versa?
• How many roles give more rights in reality than they should theoretically provide (roles that should be read-only but have write permissions too; roles whose applicability is broader than it should be; etc.)?

How can you address the issue?

Now that the problem has been defined, what can be done about it? It’s important not to feel overwhelmed or discouraged by the apparently huge task that the issue suggests! It is possible to improve the situation and bring risks related to ERP permissions under control. In addition to the obvious point of providing sufficient resources to do it, there are a number of key success factors that must be met; and these that are the subject matter of our two articles.

1. Steering things carefully

When embarking on such a project, you clearly can’t address everything straight away. It’s more a case of strategically targeting defined scopes which will yield significant results within a reasonable amount of time. For example, it might be a key application or a central ERP module, a process that’s been highlighted in a recent audit, or a series of risks already identified as critical in the corporate risk register. The analysis of real data extracted from ERP systems can be a great help in knowing what to prioritize, and in justifying the priorities chosen.

In terms of approach, there are three areas that the project must cover:

• The analysis and control of permission-related risks—the core work of such a project.
• Implementing a technical solution that supports the chosen methodology.
• Steering and change management—both essential for the success of such a project.

It’s important to pace the project by incorporating regular milestones for each of the three areas—and for each project phase:

• The preparation phase, which includes the detailed framing of the project, putting in place the tools, and completing the prerequisites.
• The deployment phase—known as Get-Clean—aims to control the current risks, by demonstrating the approach at pilot scale, rolling it out more widely, and adjusting the tools according to user feedback.

The ongoing operating mode—known as Stay-Clean—can take the project to the next stage, but the groundwork for it must be done during the initial phase, if the risks are to be controlled over the long term.

A model approach to an ERP permissions risk-remediation project

It’s imperative to closely monitor the actions taken by the various people and decision makers involved, and, more generally, to check that the commitments made at each step are being successfully achieved. These commitments can be represented by results that are both quantitative (a reduction of X% in the number of critical risks; no more than 5 risks per user, etc.) and qualitative (the development of processes or compensatory controls). There will also be a need to measure and demonstrate the value of these results to the project’s sponsors and representatives from the business functions.

2. Preparing the ground

Technical and business-function-related questions are closely linked in projects that address permissions, something especially true in the case of ERPs. As a result, you need to put in place the right sponsors from the start: from both the security and IT sides, and the business-function and Internal Control sides.

There may also be a need to involve numerous other players: access rights officers, security managers, representatives from the business functions, process managers, team managers, internal controllers, etc. Coordination is essential throughout the project, and future contributors, as well as those affected by the changes, need to be brought on board and engaged from the start—in terms of sharing the challenges, objectives, and approach. The approach must be framed positively: it must not be about stigmatizing states of affairs or behaviors, or comparing one part of the business with another; rather, it should be about moving the company and its employees forward in the management of risks.

The preparation phase first involves gathering the various inputs needed for the project, and especially those that will enable an initial analysis of the data: organizational information about users (department, function, etc.), permissions, access logs, control repositories, segregation of duties matrices, etc. For this last item, in particular, workshops are a must if the matrices are to be completed and “translated” into technical permissions that can become automated controls within a tool.

There is also a need to define the indicators, dashboards, and reports that will be used both during the project phase and also in the long term by those in charge of continuous monitoring.

Another important activity during this preparatory phase is to improve data quality. This prerequisite becomes all the more indispensable when a company’s maturity level, in identity and access management terms, is low. Improving quality isn’t just about user accounts though, it’s also—and especially—about the ERP authorization model. If the roles or access profiles themselves carry risks (in particular, in terms of the segregation of duties), this must be remedied before tackling the individual risks introduced by users.

Examples of prerequisites for an ERP permissions risk-remediation project

We’ve now discussed the first two key success factors in an ERP permissions risk-remediation project: close steering and preparing the ground. Three other key success factors will be discussed in a second article, to follow.

Cet article ERPs: how to control permission-related risks (Part 1) est apparu en premier sur RiskInsight.

Calling time on passwords

Authentication means using an agreed method to prove that someone is the person they claim to be. From the earliest times, the most widely used method has been, almost certainly, the password. However, passwords are an irritation for users and have numerous security limitations.

A collective sense of having “had enough”…

We all imagine, from time to time, not having to rack our brains for the right password when we connect to our most used applications. But it’s clear that this remains just a fantasy at present.
The promise of single sign-on is a long way from being a reality in corporate settings, and the increasing popularity of password vaults reveals something of the challenges faced by users: the multiplicity and patchy relevance of password policies, obligatory password changes, not to mention the irritation of having to reset passwords.
Having said that, the password’s main advantage remains its universal applicability and familiarity.

…but with a limited degree of security

Many cyber-attack scenarios rely, at some point or other, on a password—ideally that of a privileged account—being compromised. Various techniques are employed: high-volume combination tests (Brute Force), intercepting communications (Man in The Middle), and reconstituting passwords from their footprints (Rainbow Table).

Security measures to guard against these attacks exist (such as encryption, hashing, salting, and blocking accounts), but these are not always implemented systematically—or satisfactorily. As the saying goes, “From a corporate point of view, passwords are like nuclear waste: just bury them deep and hope they don’t leak.”

In addition to the technical weaknesses already discussed, user behavior presents a major risk: reusing the same password for different applications, passwords that are too weak or easy to guess, incrementation, etc. When a password is reused for several applications, it acts as the weakest link—thus weakening the whole chain.

Ultimately, the poor user experience and limited level of security offered by passwords are forcing companies to look for new authentication methods.

What are the options?

Authentication methods are generally divided into four categories:

What I know

These authentication methods are based on a key or code that the user knows. They represent the bulk of the solutions used today in both professional and private setting. Today’s solutions include traditional passwords, PIN codes, and secret questions. The latter, however, are rarely used, because they are either too generic (for example, “What’s your favorite color? “) or too difficult to remember.

What I own

Here, security is based on a specific piece of equipment being in the user’s possession. In particular, we are seeing the following in use:

• Smartphones

Smartphones allow—both in professional and private settings—the securing of the most sensitive operations: accessing internal company networks, confirming online payments, or carrying out non-typical banking operations.

Smartphones can be used to achieve authentication in a number of ways:

• Authentication tokens

A token often takes the form of a mini-calculator that makes it possible to generate a single-use code (OTP), with the token itself protected by a PIN code chosen by the user. Historically widely used in companies (for VPN access in particular), and occasionally in the private sphere to connect to particular customer areas, tokens are, nonetheless, giving way to smartphones, which provide a less expensive method.

• Smartcards

Smartcards contain a certificate that is used to prove the holder’s identity. A card reader is essential for this type of authentication; moreover, certificate management requires infrastructure and life-cycle-management procedures (covering issue, withdrawal, loss, etc.). Normally reserved for the corporate world, their use tends to be limited to specific groups or uses (IT administration, financial operations, etc.).

• U2F keys

This item comes in the form of a standard USB stick, but instead of storing files, it stores a unique key linked to the user. Based on a standard developed by the FIDO Alliance, the solution combines a robust level of security (including resistance to phishing attacks) with a good user experience (the keys can remain connected to one of the device’s USB ports) because a simple key press is sufficient for authentication. Note, however, that this does not involve fingerprint recognition.

• A connected object, such as a watch

This last solution—the most innovative in this category— allows users to connect via a connected object that they already own. As an authentication method it’s little used in corporate settings, but Apple, for example, offers an option to unlock a computer by simply approaching a device with another Apple connected object.

Solutions like this, based on the possession of a device, are differentiated mainly by their degree of ergonomics. In any case, it’s essential to manage “enrollment” (the linking of the object to its holder), replacement, loss, and theft of the relevant device.

Who I am

The physiological characteristics of a person, such as a fingerprint, the vein pattern of a hand, irises, faces, the signature of a voice, or even a heart rate, also make it possible to authenticate a user. The use of these solutions, for most people, is limited to opening their workstation or smartphone (via a fingerprint or face recognition). However, companies have used such solutions for a number of years to control access to rooms or highly sensitive areas.

What I do

Keystroke rhythms, mouse movements, using a phone, or touching a screen, are different ways to distinguish a legitimate user from an impostor or robot. These behavioral, biometric solutions require a large amount of data in order to be reliable, but this is improving, thanks to new Machine-Learning-based approaches. These solutions are used more as security measures that complement authentication (detecting robotic-attacks, account sharing, etc.).

As a summary, the figure below shows the different authentication solutions according to their level of security and ease of use.

User experience and security, a circle that can’t be squared?

We believe that it is possible to reconcile the user experience with security. Below we set out four possible routes to achieving it.

Route 1: simplifying the use of passwords

While it seems too fantastic to imagine the use of passwords being completely abandoned, some of their failings can be addressed. The frequency of data entry can already be reduced via identity-federation mechanisms that provide access to both corporate and partner services. In addition, chatbots are emerging to simplify the password resetting process, and are helping drive significant improvements in user experience. As for security, raising users’ awareness about the proper use of passwords is still an essential activity if risks (from social engineering, spam, phishing, password theft, etc.) are to be reduced.

Route 2: adapting the security requirements to the context

Just as you have to adapt your road speed to the weather conditions, the concept of risk can guide us in the level of security needed to authenticate a user. Thus, to access non-sensitive information, a simple password will suffice; but more sensitive operations (a bank transfer involving a significant amount, for example) will require the user to be authenticated with greater certainty, using a combination of several authentication factors. Other criteria can be taken into account to assess risk, for example the PC or smartphone being used, the geographical location, the time of connection, or even whether the user is exhibiting their habitual behavior.

Beyond the authentication phase, the level of risk can also influence the time allowed before issuing a new authentication request (no need to retype a Facebook password as long as the user stays on the same PC or smartphone, reauthentication via webmail every X days only, etc.).

In the end, then, authentication is no longer seen as an event but as a continuous process.

Route 3: let the use choose the authentication method

Rather than imposing a single authentication method on all users, Bring Your Own Token (BYOT) lets users choose the one that best suits their needs. The idea is to offer a choice of solutions with comparable levels of security.

Today, Facebook and Google offer BYOT as a second authentication factor, using a registered smartphone or secure USB key, for example.

In the world of work, this method remains less developed at present, but it’s easy to imagine such a method being offered to specific groups: those with particular work mobility requirements, the technological appetite for it, etc.

Route 4: make use of accounts that exist already

It’s more and more common for people to use their social media accounts (Facebook, Google, or LinkedIn, for example) to connect to e-commerce sites or other websites. A Social Login enables the creation of an account on the new site to be simplified, and limits the number of passwords to be remembered.

However, not all online services are designed to use a Social Login. Public or parapublic services for example, favor a State Login which allows users to log in using a tax, health, or similar identifier, and to carry out a range of online administrative activities. And these uses are in continuous development.

In conclusion

While passwords are not set to disappear completely, the search for alternatives is gathering pace: uses and technological solutions are evolving rapidly, consortia and new standards (such as OAuth2 and OIDC) are emerging, and, these days, the user experience, as well as security, is core to the thinking.

Cet article Painsswords: a look at the alternatives to passwords? est apparu en premier sur RiskInsight.