Lifestyle Hearing is a healthcare provider of hearing solutions with over 50 clinics, as well as many independently owned network member locations throughout Canada. These clinics provide customers with a series of auditory services including testing patients for hearing, recommending and providing a customized solution, as well as following up with ongoing visits and making sure everything is working properly. Recently the company has grown rapidly from just 2 employees to over 130 and continues to expand across Canada.
This rapid growth of Lifestyle Hearing created many IT complications within the company such as departments and roles needing to be created and formed. Since they started as a small company, many employees had responsibilities which included several roles that needed to be clearly defined as the company grew. This meant that user accounts needed to be created in multiple systems and controls needed to be put in place. Franco Butera, IT Director at Lifestyle said, “This task took about half an hour for IT to complete, and that was only if we had all the correct information at the beginning. If not, we had to track down the employees in an attempt to get the information, and wait for a response which could take up to an hour or more.” It is critical to unsure all information is correct such as credentials for doctors since they are operating in the healthcare arena. All of this work was taking valuable time away from the IT department, but could not be completed by department managers due to lack of technical knowhow.
Butera knew just how to solve these problems due to his positive experiences with Tools4ver’s User Management Resource Administrator (UMRA) at previous companies. He had come in contact with and used UMRA at both a larger telecommunications company in Canada and a higher education facility in Bermuda. Both projects had been extremely successful and had easily solved all of the organizations’ account management problems.
Completely controlled project
Tools4ever implemented UMRA at Lifestyle Hearing in a three phased approach. “The entire process was exceptional, from gathering the requirements, to deployment, to the types of resources Tools4ever provided.” Tools4ever was able to promptly implement the solution and get it up and running to start creating accounts in just the first phase. “The Project never slipped away, and was completely controlled. I was juggling many complex projects at the time, and Tools4ever’s UMRA was by far the easiest to work on.” Tools4ever was also even able to customize the solution to meet Lifestyle Hearings needs by building a connector to the company’s procurement resource system, Coupa.
No IT involvement
UMRA completely eliminated the account creation process from IT and is now handled entirely through the human resources department. Before UMRA, IT was the bottleneck due to the fact that they often had to handle other important tasks and were not able to create accounts quickly for new employees. HR now has controlled access through a web based form to create an account which allows them to easily enter the employee’s information, define their profiles and which systems they need accounts in. Lifestyle Hearing used to have a 4 to 5 day window for account creation, but with UMRA employees are now able to have their accounts created right away and start working the same day they are hired as needed.
Substantial savings
“Tools4ever’s UMRA saved our IT department a significant amount of time in the long run.” IT at Lifestyle Hearing no longer has to even hear about account creation and can focus on more important issues. Franco stated, “If you multiply how many long it took for IT to create an account by the number of accounts that we need created and edited, the savings is substantial.” UMRA is also able to track and audit Lifestyle Hearing so that it easily meets all audit requirements. “I have seen it manage thousands of accounts without any issues. It’s a must have application for companies of any size!”
For more information, please visit our website.
Friday, November 30, 2012
Friday, November 16, 2012
The Monster Called RBAC
In the world of identity and access management, Role Based Access Control (RBAC) is gradually becoming a frequently used term. Dictated in part by legislative and regulatory norms, an increasing number of organizations wish to manage and assign all access privileges across the network in a structured way. This is possible through the use of RBAC software. So how can companies achieve an adequate implementation of RBAC across their entire organization?
Organizations are faced with two pitfalls when it comes to assigning and revoking access rights. To assign rights, they often create a copy of a colleague’s account, also known as “template user.” This creates the risk that new employees are provided with unwarranted access to business applications and systems.
Added to which, organizations do not pay sufficient attention to revoking access rights when they create copies of existing user accounts. After all, their most important consideration is enabling new employees to do their job rather than checking for excess access rights. Dictated by standards, IT auditors and unnecessary licensing costs for suites including Microsoft Visio, Projects and Adobe CS, organizations have come to acknowledge the importance of a responsible handling of authorizations.
HR System as Basis
RBAC is a technique for implementing authorization management across organizations. This technique involves assigning rights on the basis of RBAC roles rather than assigning access rights to individual users. These roles in turn comprise the department, function, location and cost center associated with an employee.
Although organizations acknowledge the importance of RBAC, they are cautious about implementing this technique. RBAC has undeservedly gained the reputation that it involves a large effort – particularly in terms of management overhead – as well as lengthy and complex implementation cycles. In fact, RBAC is viewed as a monstrous entity. This misunderstanding is the result of an incorrect approach to its implementation.
In the past, the people who have been responsible for RBAC implementations were under the illusion that 100 percent of the staff could be molded into a single RBAC role. More often than not, there are as many functions in an organization as there are employees. This results in an endless list of roles in relation to resources, so that assigning an RBAC role to each employee becomes a lengthy process. Another question is whether everybody and everything has to be included in RBAC. Isn’t RBAC exclusively needed for user groups, which require a careful authorization set-up from the point of view of risk management, regulations and efficiency?
In any case, RBAC can be handled differently -- quicker and with less complexity.
RBAC as Lego Blocks
The advice for RBAC is to use a bottom-up and stacked approach. This approach involves the creation of a foundation that can be expanded at a later stage. After all, the majority of employees need access to standard applications such as Microsoft Office and Outlook. For a large number of employees, access rights on the organizational level (logging in, word processing, e-mail) and departmental level (access to the department share and departmental applications) can be assigned right away. In this context it is important to determine the top 50 combinations of department and function for active employees.
The HRM system is an excellent source for determining these combinations. This will pave the way for a role model on the organizational level. As an example, a hospital in Lynbrook has a surgery department that includes the functional role of “Nurse.” The organizational role can be created on the basis of the function; department and location found in the HRM system. These are “Nurse” and “Surgery Nurse,” respectively. After “Nurse” and “Surgery” have been defined, a nurse in the surgery department will automatically be identified as “Nurse + Surgery” and assigned the stacked roles.
Using this method, it becomes very easy to populate more than 80 percent of the RBAC table. A major benefit of this approach is that new employees can start working on their first day while time is liberated for the assignment of specific rights on an application and system level.
A subsequent step is to translate these organizational roles into application or system roles, which will comprise the remaining 20 percent of the RBAC table. The basis for this is already present and now further stacking will take place. The assignment of the system roles can easily be handled by the relevant manager. After all, managers, rather than HR, are responsible for the access rights of their employees. On the basis of a special workflow, the relevant manager will be prompted by an e-mail notification and/or web form to specify the access rights and applications for the employee concerned. The RBAC software can subsequently record the manager’s choices to further populate the empty sections of the RBAC table and eventually achieve a fully populated table.
This means it is possible to have a manager handle all the translations of roles within their department, with an option to delegate tasks to a colleague. An action triggered by the manager may also result in a workflow notification to a license manager. This allows managers to exactly determine and manage what happens within their department or cost center.
Detailed Access Rights
Because the system and application roles contain the detailed access rights for the application in question, the role can be implemented. The responsibility for the actual provision of network access lies within IT, as well as Functional/Technical Application Management. It is also possible to automate this part of the process (provisioning) with the help of identity management software.
The major advantage of implementing RBAC in this way is the speed of implementation. Where it takes other vendors a year, Tools4ever, for example, is able to create a first standard for organizations within two months. Added to this, customers can easily achieve SoD (Segregation of Duty), by refusing certain access rights in case of forbidden combinations of roles and departments. In case of downsizing initiatives, it will not be necessary to recreate the RBAC table from scratch.
The only thing that will have to be modified is the “Who are you” section, and this can be conveniently done in the HRM system. By taking the HRM system as the basis and continuously polling it, managers are ensured of the most up-to-date information and have a populated dashboard at their disposal with the function, department, location and cost center for all their staff. This requires a direct connector with the HRM system, since that is the source of all the information. There are multiple vendors that can provide a connector like this.
Pyramid
It is possible to catch this method in a pyramid running from the top to the bottom of the organization (top), via the department, location and function down to individual employees (basic layer). The top layer (organization and location) will exclusively include access rights that apply to all employees. This section can be populated right away. Organizations may wish to consider stop populating the RBAC table at the department/function level. The remaining details will be handled on an ad hoc basis, through a workflow. They will subsequently be able to further populate the pyramid and thus the RBAC table.
Conclusion
RBAC currently attracts the attention of many organizations because this access methodology allows them to assign and revoke access rights in an efficient, transparent and controllable way. An RBAC implementation does not necessarily have to be complex. It is often recommended that organizations use a stacked approach to RBAC and to automate the assignment of access rights on an organizational and departmental level (through their HRM system), focusing on the top 50 combinations of functions and departments. This should enable a quick and convenient population up to 80 percent of the RBAC table. The detailed access rights of the remaining 20 percent cause organizations a great many headaches. To handle these remaining 20 percent in a pragmatic way using the RBAC model, organizations should have their managers handle the assignment of access rights to employees. The managers will be able to determine and modify the detailed access rights for their team.
Over time, the RBAC model will allow organizations to collect more and more information on the choices and selections made during the assignment of access rights. After a review cycle by the security officer, this information can be used to further enrich the RBAC table and to increase the 80 percent to perhaps 100 percent. Knowledge and feedback from the organization help to beat the RBAC monster.
For more information, please visit our website.
Organizations are faced with two pitfalls when it comes to assigning and revoking access rights. To assign rights, they often create a copy of a colleague’s account, also known as “template user.” This creates the risk that new employees are provided with unwarranted access to business applications and systems.
Added to which, organizations do not pay sufficient attention to revoking access rights when they create copies of existing user accounts. After all, their most important consideration is enabling new employees to do their job rather than checking for excess access rights. Dictated by standards, IT auditors and unnecessary licensing costs for suites including Microsoft Visio, Projects and Adobe CS, organizations have come to acknowledge the importance of a responsible handling of authorizations.
HR System as Basis
RBAC is a technique for implementing authorization management across organizations. This technique involves assigning rights on the basis of RBAC roles rather than assigning access rights to individual users. These roles in turn comprise the department, function, location and cost center associated with an employee.
Although organizations acknowledge the importance of RBAC, they are cautious about implementing this technique. RBAC has undeservedly gained the reputation that it involves a large effort – particularly in terms of management overhead – as well as lengthy and complex implementation cycles. In fact, RBAC is viewed as a monstrous entity. This misunderstanding is the result of an incorrect approach to its implementation.
In the past, the people who have been responsible for RBAC implementations were under the illusion that 100 percent of the staff could be molded into a single RBAC role. More often than not, there are as many functions in an organization as there are employees. This results in an endless list of roles in relation to resources, so that assigning an RBAC role to each employee becomes a lengthy process. Another question is whether everybody and everything has to be included in RBAC. Isn’t RBAC exclusively needed for user groups, which require a careful authorization set-up from the point of view of risk management, regulations and efficiency?
In any case, RBAC can be handled differently -- quicker and with less complexity.
RBAC as Lego Blocks
The advice for RBAC is to use a bottom-up and stacked approach. This approach involves the creation of a foundation that can be expanded at a later stage. After all, the majority of employees need access to standard applications such as Microsoft Office and Outlook. For a large number of employees, access rights on the organizational level (logging in, word processing, e-mail) and departmental level (access to the department share and departmental applications) can be assigned right away. In this context it is important to determine the top 50 combinations of department and function for active employees.
The HRM system is an excellent source for determining these combinations. This will pave the way for a role model on the organizational level. As an example, a hospital in Lynbrook has a surgery department that includes the functional role of “Nurse.” The organizational role can be created on the basis of the function; department and location found in the HRM system. These are “Nurse” and “Surgery Nurse,” respectively. After “Nurse” and “Surgery” have been defined, a nurse in the surgery department will automatically be identified as “Nurse + Surgery” and assigned the stacked roles.
Using this method, it becomes very easy to populate more than 80 percent of the RBAC table. A major benefit of this approach is that new employees can start working on their first day while time is liberated for the assignment of specific rights on an application and system level.
A subsequent step is to translate these organizational roles into application or system roles, which will comprise the remaining 20 percent of the RBAC table. The basis for this is already present and now further stacking will take place. The assignment of the system roles can easily be handled by the relevant manager. After all, managers, rather than HR, are responsible for the access rights of their employees. On the basis of a special workflow, the relevant manager will be prompted by an e-mail notification and/or web form to specify the access rights and applications for the employee concerned. The RBAC software can subsequently record the manager’s choices to further populate the empty sections of the RBAC table and eventually achieve a fully populated table.
This means it is possible to have a manager handle all the translations of roles within their department, with an option to delegate tasks to a colleague. An action triggered by the manager may also result in a workflow notification to a license manager. This allows managers to exactly determine and manage what happens within their department or cost center.
Detailed Access Rights
Because the system and application roles contain the detailed access rights for the application in question, the role can be implemented. The responsibility for the actual provision of network access lies within IT, as well as Functional/Technical Application Management. It is also possible to automate this part of the process (provisioning) with the help of identity management software.
The major advantage of implementing RBAC in this way is the speed of implementation. Where it takes other vendors a year, Tools4ever, for example, is able to create a first standard for organizations within two months. Added to this, customers can easily achieve SoD (Segregation of Duty), by refusing certain access rights in case of forbidden combinations of roles and departments. In case of downsizing initiatives, it will not be necessary to recreate the RBAC table from scratch.
The only thing that will have to be modified is the “Who are you” section, and this can be conveniently done in the HRM system. By taking the HRM system as the basis and continuously polling it, managers are ensured of the most up-to-date information and have a populated dashboard at their disposal with the function, department, location and cost center for all their staff. This requires a direct connector with the HRM system, since that is the source of all the information. There are multiple vendors that can provide a connector like this.
Pyramid
It is possible to catch this method in a pyramid running from the top to the bottom of the organization (top), via the department, location and function down to individual employees (basic layer). The top layer (organization and location) will exclusively include access rights that apply to all employees. This section can be populated right away. Organizations may wish to consider stop populating the RBAC table at the department/function level. The remaining details will be handled on an ad hoc basis, through a workflow. They will subsequently be able to further populate the pyramid and thus the RBAC table.
Conclusion
RBAC currently attracts the attention of many organizations because this access methodology allows them to assign and revoke access rights in an efficient, transparent and controllable way. An RBAC implementation does not necessarily have to be complex. It is often recommended that organizations use a stacked approach to RBAC and to automate the assignment of access rights on an organizational and departmental level (through their HRM system), focusing on the top 50 combinations of functions and departments. This should enable a quick and convenient population up to 80 percent of the RBAC table. The detailed access rights of the remaining 20 percent cause organizations a great many headaches. To handle these remaining 20 percent in a pragmatic way using the RBAC model, organizations should have their managers handle the assignment of access rights to employees. The managers will be able to determine and modify the detailed access rights for their team.
Over time, the RBAC model will allow organizations to collect more and more information on the choices and selections made during the assignment of access rights. After a review cycle by the security officer, this information can be used to further enrich the RBAC table and to increase the 80 percent to perhaps 100 percent. Knowledge and feedback from the organization help to beat the RBAC monster.
For more information, please visit our website.
Subscribe to:
Posts (Atom)