RBAC...Why Bother? 4 Reasons to Start an RBAC Program Today

Role Based Access Control (RBAC) is the process of granting people within similar job functions the same access to resources (systems, data etc..) required to do their job. The concept centers on putting into business friendly terms the logical grouping of resource access. These resource access groupings are called "roles". It's a daunting task when you consider all the various systems that can exist within an enterprise - there are the common applications everyone uses like email, the company portal, conference scheduling systems. And the one-offs that are very specific to performing a job function - HR payroll processing apps, CRM tools for Sales personnel, other business specific applications... So why do it? What are the benefits?

Simplification

The process of ensuring that new hires have access to what they need when they need it on day one is not easy. Often it requires several system set up requests before the right access is granted. Not to mention decomposing what someone else in a similar job function has access to. Wouldn't it be easier to have access automatically granted based on the job function someone is in? It's not an "auto-magic" process. There is upfront work involved in establishing the link between job function and system access needs. But once it's done (and the maintenance process is established) the on-boarding of new hires and department transfers becomes a lot easier and quicker.

Action: Get a sense for how much work you are in for. Look at a slice of the enterprise - one job function within one business unit or department. Analyze the system access granted to a few people within the same job function.

Consistency

Even if you know what access is required to do your job the process for getting that access established may vary. You make a phone call to so-and-so to get access to system A, send an email to a mail group to get access to system B, and submit a request through an intranet based system to get access to system C. Sound familiar? With all of these disconnected and differing processes for granting access, how can an organization know that the appropriate scrutiny is being applied to verifying who SHOULD have access to certain applications and information? Is the same approval required for all resource access? In an RBAC environment the role setup process is defined and can evolve as necessary. Based on the specific requirements of an organization the proper controls required for assigning access by job function area established and consistently applied each time that role is requested for a person. Ensuring the right level of approval is applied.

Action: Pick a set of applications and for each ask the question "Who needs to know who is accessing this application?". If the answer results in a Visio diagram, consistency is important.

Accountability

Central to an RBAC model is the governance. Governance takes the form of placing accountability for role definition with those most appropriate to validate what a role should have access to. For roles mapped to job functions that means accountability is placed within the business unit or department where that job function exists. Using business friendly terminology to link a system access permission to a job function is also key. Those accountable for making sure people in that role have what they need to need to understand what the underlying components of a role are.

Action: How easily understood is the system access terminology within your organization? Take one application and create business friendly descriptions to describe the access levels. This will kick start the analysis necessary for establishing a framework to maintain these business friendly descriptions.

Risk Mitigation

If it wasn't apparent already, all the of the above are risk mitigation tactics. The easier and more consistently something can be done, the more predictable the outcome. Predictability helps control risk. An RBAC model reduces the risk that inappropriate access is granted to or retained by someone that shouldn't have it. RBAC is a key control in information protection.

What benefits has your organization seen from an RBAC? implementation?

How Mature Is Your Identity Management Program?

Identity Management maturity can be defined by 4 levels that include aspects of people, process, and technology. Because of this, moving along the continuum requires the commitment of senior leadership to support the organizational changes required. The following presentation summarizes the framework for determining maturity and provides suggestions for advancing between levels.

Identity Managment Maturity Model

View more presentations from kmanthey.

Stop Wasting Money Writing System Requirements

IT has long been looked to as the technical solution providers for business problems. But the assumption that often is made is that the business problem is already well understood and the business processes that drive the technical requirements are known....by someone. I continually run into the situation where a team is beginning the business requirements definition effort and developing system Use Cases only to discover it's not that straightforward. The entire business process that the technology will support has not been thought through and there are gaps in knowledge around some areas of the business process. How can this be addressed before valuable time and money are wasted spinning on requirements? Here are a few suggestions:

Every IT project should start with business process definition. It's no longer IT's responsibility to only handle the system requirements definition side of the equation. Start thinking in terms of process steps, roles, and responsibilities. Once these are defined the role of the system and how it should behave becomes more clear. The same skill set that it takes to identify system requirements is highly transferable to defining business process. Stakeholder engagement, meeting facilitation, communication skills, clear concise documentation abilities are all the qualities of solid business AND process analyst.

Run an agile project. By adopting the basic principles and philosophy of the agile scrum framework your team can get to "doing" faster with "just enough" documentation in place to make it productive. Once the business process is well understood, create a backlog with the goals the system should allow each type of system user to achieve. Define requirements in more detail as part of each development sprint. Start the sprint with a few upfront requirements tasks then continue to refine the requirements as a team through the build-demo-adapt process. The role of the BA in the demo meetings is to capture requirements and decisions made. By the end of each sprint you can have a requirements document that matches exactly what was built. This avoids spending months in lengthy requirements gathering sessions trying to predict in excruciating detail today how you want the system to work a few months from now.

These are a few ideas that have worked well on my projects. Join the conversation! What are you doing that's worked well(or not so well)?

SaaS - Making the Right Choice for Your Company

Software as a Service (SaaS) is gaining more ground as a viable option for addressing IT needs in all sizes of companies. No longer looked at by only SMBs as the low cost alternative to expensive custom software solutions. Before you jump into a SaaS solution, it's important to do your homework, both on the SaaS provider and within your own company. Here are a few things to consider:

Know what SaaS is (and is not)
In basic terms, SaaS is subscription based software accessible over a network (i.e. the Internet). The SaaS vendor assumes maintenance responsible for all hardware and software components. The obvious benefit is that a company or subscriber gets the functionality they need without the IT overhead associated with an in-house application - hardware costs and maintenance, software support. The downside is that the customer does loose some control. As a customer you may be limited to the customization options available within the base software solution. You also need to be aware about how your data is stored and how accessible it is to you.

The SaaS Vendor's Maturity
In a recent Forrester research report, SaaS vendor maturity can be defined as:

• Level 0: Outsourcing is not SaaS. In outsourcing, a service provider operates a major application or a unique application landscape for a large enterprise customer. As the outsourcing company can't leverage this application for a second customer, outsourcing does not qualify as SaaS.


• Level 1: Manual ASP business models target midsize companies. At level 1, a hosting provider runs packaged applications like SAP's ERP 6.0, which require significant IT skills, for multiple midsize enterprises. Usually, each client has a dedicated server running its instance of the application and is able to customize the installation in the same way as self-hosted applications.


• Level 2: Industrial ASPs cut the operating costs of packaged applications to a minimum. At level 2, an ASP uses sophisticated IT management software to provide identical software packages with customer-specific configurations to many SMB customers. However, the software package is still the same software that was originally created for self-hosted deployment.


• Level 3: Single-app SaaS is an alternative to traditional packaged applications. At level 3, software vendors create new generations of business applications that have SaaS capabilities built in. Web-based user interface (UI) concepts and the ability to serve a huge number of tenants with one, scaleable infrastructure are typical characteristics. Customization is restricted to configuration. Single-app SaaS adoption thus focuses on SMBs. Salesforce.com's CRM application initially entered the market at this level.


• Level 4: Business-domain SaaS provides all the applications for an entire business domain. At level 4, an advanced SaaS vendor provides not only a well-defined business application but also a platform for additional business logic. This complements the original single application of the previous level with third-party packaged SaaS solutions and even custom extensions. The model even satisfies the requirements of large enterprises, which can migrate a complete business domain like "customer care" toward SaaS.


• Level 5: Dynamic Business Apps-as-a-service is the visionary target. Forrester's Dynamic Business Application imperative embraces a new paradigm of application development: "design for people, build for change." At level 5, advanced SaaS vendors coming from level 4 will provide a comprehensive application and integration platform on demand, which they will prepopulate with business applications or business services. They can compose tenant-specific and even user-specific business applications on various levels. The resulting process agility will attract everyone, including large enterprise customers.
  

Your Requirements:
How flexible are they? Do you know what your must-haves are? The benefits of many SaaS options can also be a drawback if you haven't taken the time figure out what you are really looking for. There are often limited customization abilities and some of your business processes may require specialized features/functionality. Make sure your business process is well defined and understoond before looking at vendors. Regardless of how flexible your business process is there are always a few requirements that must be met.

Vendor Evaluation Criteria:
Give careful thought to the specifics you will rate a SaaS vendor against. Categories that should be part of any SaaS vendor evaluation include (but are not limited to):

1. Price


2. Alignment with functional requirements and business process requirements


3. Useability


4. Technical Requirements such as
   –Security
   –Data Storage and Accessibility
   –Disaster Recovery
   –Custom Reporting
   –Integration
   –Customization


5. Support SLAs


6. Professional Services


7. Vendor Viability


8. Regulatory Compliance
   

Before you make an investment in a SaaS solution, do your homework and take the time to internally discuss what your must-haves are. Having a clear idea of the business problems a SaaS solution should address will make the selection process more clear.

I'd love to add to this list of SaaS vendor considerations. What was helpful in your SaaS vendor evaluation?

What is a Solstice Consultant?

Identity Management: How to Get Started

We are in a constant state of change. Mergers and acquisitions, re-orgs, new hires, and terminations are creating a lot of change to keep track of. This is creating new opportunities for information security threats. It's difficult to control all the pieces. To further add to the complexity, the workforce is changing. Workers expect remote capabilities, are collaborating in virtual teams, and teams are made up of internal employees, external contract/temporary workers and strategic business partners. Physical walls don't exist anymore making it even more difficult to control things. Identity Management (IdM) solutions can help companies manage change and control the chaos.

What Is Identity Management

View more OpenOffice presentations from kmanthey.

In the simplest terms, Identity Management is the process by which user access is assigned to technology assets (hardware, software, services, files, collections of data etc..). This process can be done manually, automated, or some combination of both.

In environments where the people and technology assets are constantly changing it’s important to have the right controls in place for ensuring that the right people have access to the right information at the right time. So... are you ready to get started? Here are some guidelines to get the ball rolling:

Develop a Business Process Driven Solution
Good Identity Management solutions are business process driven, not IT driven. Meaning, the processes for creating and maintaining identities should align with the on-boarding and off-boarding processes already in place. Or the way you want the processes to work. It should also support the full scope of "people" within your organization i.e. employees, temporary workers, customers, business partners. Different types may require different processes. A well thought through IdM process considers how the following will be executed:

1. Identity creation and maintenance – the creation and assignment of an identity entity to an actual person.
2. Access Request – the information required to determine the access to grant an identity
3. Approvals –those required to approve requests for access to information
4. Provisioning – the actual granting of access to the identity
5. Certification - the periodic review and validation of access granted to an identity

Identify Your Data Sources
The only way to protect the information is to know where the information resides. Identify the critical information, determine ownership, and begin the process of cleaning the data. Start with the highest risk areas first to manage scope. It’s easier said than done but it’s a critical first step.

Secure the Right Support
Identity Management has to be a strategic priority to be successful. It’s going to require funding, at some point, and people’s time – outside their normal day-to-day responsibilities - to make IdM successful. You can’t get buy-in for something that’s not well understood. Educate people on what IdM is and speak in terms that are meaningful to them. How will this make their job easier? How will it make them get from point A to B faster? Don’t expect people to make the leap on their own to connect all the dots. Make sure executives and management understand the benefits and what’s involved. Give them the information they need to evangelize the solution.

Create an Oversight Function
IdM is not something that get's implemented and hums on it's own. Like most processes it takes care and feeding. It takes someone focusing on the big picture and periodically assessing how well all of subprocesses are working together and when changes are needed. This function maintains the requirements of the IdM solution and see that the solution evolves with the needs of the business.

Develop an Onboarding Process
Consider how you handle bringing new access permissions and applications into the process on an on-going basis. Define the work required to on-board a new application and the resources required to make it happen.

Evaluate Automation Tools
Based on the needs of your organization, consider the technologies that exisit to automate the access request process and automate the provisioning of access. Or is a custom built solution more fitting? More to come in a future blog on the IdM vendor landscape, how to pick the right tool, and determining buy vs. build.

Identity Management is a growing space that has become even more important in today's regulatory environment. Review these guidelines with your organization in mind. Take what seems appropriate and adapt it to your situation.

Something to think about.....

Managers manage a budget, leaders inspire innovation.