Implementing User Role-Based Security Testing For Enterprise Applications
Security has become a critical issue at many levels, including access to individual computers, networks, services, applications and accounts. News reports of security breaches are all too common. Testing security has likewise become complex, as intrusion can come through a variety of channels and techniques.
Because of their cross-functional capabilities and tight integration, enterprise applications must provide additional levels of security control to specific components and data elements. This level of security is critical to enforcing corporate policies and internal controls, and is a subject of compliance audits.
This type of testing, done thoroughly for each change, can be extremely time-consuming—so it’s also an ideal candidate for automation. The key to successful automation is to make the up-front investment to create and support a repeatable, sustainable process. The following is a guideline to organizing, defining and automating your role-based security testing.
Understanding Role-Based Testing
The most common experience we have with security is controlling initial access to a system or software: Think of a typical log-in page. While this level of security is essential and must be tested against various forms of assault, it’s by no means the most difficult. In contrast, role-based security controls access to specific components or data within a system based on the rights of the user. Unlike the all-or-nothing rights of the log-in, this level of security may hide menu options, fields or screens from users based on their role, or may permit or deny reading or writing to particular data elements.
Consider a payroll system. Most employees probably have no access rights at all, while payroll clerks may be authorized to use the system to enter time-card information but are likely prohibited from perusing salaries, making changes to rates and benefits, and adding or terminating employees. Supervisors, on the other hand, may be able to manage benefits, but only a senior manager may be able to see compensation information and add or terminate employees. In other words, various capabilities of the application are selectively exposed based on the role of the user.
These restrictions are obvious within the context of a single application. Less obvious and far more complex are the roles within an enterprise resource planning (ERP) system involving multiple interrelated applications that enable end-to-end business processes such as order-to-cash and procure-to-pay. In this environment, a transaction created in one application may have far-reaching consequences in downstream systems.
For example, a manufacturing plant might have minimum staffing levels specified for each position within each shift, and if the minimum isn’t met, the plant isn’t deemed available for production scheduling. In this situation, a payroll clerk with authority to change the department code for a plant employee could inadvertently shut down the plant by violating the minimum staffing requirements.
Because of the potentially widespread impact of each activity within such a tightly integrated environment, role-based security testing is as essential as it is challenging.
Defining User Roles and Rights
Testing role-based security involves the verification that user roles and rights are enforced by the software, so the natural foundation of your test effort is the definition of these roles and rights. Many commercial ERP systems provide configurable role-based security settings that are discoverable, usually in the form of a matrix of roles, functionality and permissions.
Customized or internally developed systems, or those that integrate with disparate legacy applications, may require additional effort to uncover this information. By whatever means acquir¬ed, the goal is a matrix of user roles, functionality and permissions.
But you can’t stop there. Simply accepting the definitions as they exist wouldn’t satisfy the purpose of testing, which is to be sure that they’re both correctly expressed and properly enforced. Your next step is to validate that the settings comply with corporate policy. This may be as simple as obtaining sign-off from your corporate security officer or as involved as interviewing owners of application or functional areas or reviewing corporate policy handbooks.
Once you have a valid set of definitions, you’re ready to test the system’s compliance. Unfortunately, that’s not as easy as systematically testing and checking off the boxes in the matrix. This is because few systems allow flat navigation access to all components. In many cases, multiple navigational steps are required to expose a particular function, window or field. Further, this navigation likely requires data values that permit or trigger navigation or functions.
This means that your test plan and test cases must encompass a more holistic view of the enterprise and the application, encompassing the business processes and supporting environment.
Business processes represent the activities performed by various users of an enterprise application. These are scenarios or workflows that describe a path through the application to accomplish a particular task, such as entering a product order or shipping goods. Each role is associated with a set of processes, and some processes may be linked to more than one role.
There are also end-to-end business processes, such as order-to-cash, that span application components and user roles, and these must be incorporated into any comprehensive test strategy because of their integration impact. Without a test plan that mimics the interrelationships among users, processes and data, comprehensive coverage can’t be achieved.
The definition of user roles and rights is typically organized around business processes in ERP systems instead of discrete components. Each role represents the profile of a particular job description. Again, the human resources department may have data entry clerks, supervisors, managers and so forth, each authorized to carry out specific business processes. The set of rights is then organized to enable these processes for each role and prohibit others.
When testing, it’s equally important to ensure permission as prohibition. Most of us think of security in terms of denying access to unauthorized users, but it’s perhaps even more critical to permit it to authorized ones. While exposing data or capabilities to the wrong user may violate internal control policies, refusing necessary access may prevent one or many employees from getting their jobs done.
For example, a warehouse inventory system that correctly enforces an internal policy that prevents shipping clerks from logging breakage or spoilage but also prevents the supervisor or manager role from doing so could result in incorrect inventory levels that cause supply-chain, ordering and fulfillment errors. Therefore, your test plan should include both positive and negative tests to ensure that users can perform their assigned business processes—and nothing else.
The Model Enterprise
The next step is to define the environment in which these business processes are executed. This is the foundation of any test effort: the set of software, data, activities and platform. In some industries it’s common to establish a “model office” for user acceptance testing to house this environment. I’ve seen banks actually construct physical model branches where they test hardware and software and provide training.
Users representing each role reported for “work” at the model office and performed their usual daily or weekly tasks. A processing schedule was defined that mimicked the production environment, including overnight batch sessions. This “sandbox” branch was used to validate the integrated set of systems for each branch before they were rolled out to hundreds or thousands of locations.
This model has appeal but needs to be updated. Enterprise applications require true enterprise-level testing. Instead of a model office, you need a model enterprise.
The model enterprise is a controlled and repeatable set of hardware, software and data, including users, business processes and job schedules, that supports the necessary end-to-end business process flows for enterprise applications.
You should plan for this effort to be the most challenging of the entire test endeavor and consume 50 percent or more of the overall effort, especially the data. Integration within enterprise applications as well as with external legacy systems requires that data conditions be orchestrated across multiple databases, files, services and interfaces.
For a test process to be effective and efficient—whether manual or automated—predictability is essential. And predictability requires control of the data, otherwise testers spend the majority of their time looking for valid data or trying to diagnose failures from data issues.
Predictability is also crucial to reusability. For tests to be reused, either the same data must be restored or procedures must exist to replenish or extend the data. For example, without a plan to add new inventory, repeated execution of an order-to-cash business process will deplete inventory until eventually orders can’t be filled.
Although archiving and refreshing the entire environment every time would be ideal, it’s not always practical or even feasible. And while it’s tempting to simply make a copy of production in the name of creating a realistic test bed, this may violate confidentiality and security by exposing the actual data of real persons. Any data strategy that involves production data must include a procedure for scrubbing or scrambling data values to obfuscate sensitive information.
If automation is available, it may be more cost effective to load the needed data instead of trying to store it. Or, a mixture may be adopted: The environment may be restored to a certain state and then the needed data is added.
Test Environment Permissions
Another important element of this environment is, of course, the availability of log-ins that represent each role. While testers themselves aren’t payroll supervisors, for example, they must have the same log-in rights if they’re to test the security rules. Often organizations may balk at giving testers role log-ins deemed sensitive or high risk. But if the test environment and data are properly managed, there should be no opportunity for exposure.
The other extreme—giving testers superuser rights to everything—won’t work either, since it limits their ability to test the variations in rights among roles.
The Enterprise Calendar
All of the above factors—uses, processes and environment—must be organized into a schedule to coordinate the end-to-end business processes. Some dependencies are easy: You can’t terminate an employee who hasn’t been hired yet. Others are less so: You can’t ship goods from inventory if they haven’t been produced yet, and you can’t invoice an order that hasn’t been shipped.
The easiest approach is to construct a calendar of virtual days, weeks and even months or other intervals, and plan the user roles and processes within it. If the system functionality allows it, multiple virtual days could actually be executed in a single actual day, but in other cases, this may not be possible without adjusting the system date and time. For example, an insurance policy may have to be in effect for a stated period of time before a claim can be filed.
While this is a simple concept, implementing it in reality can be quite complex. Tightly integrated enterprise applications may reflect updates instantly, while others may require batch jobs to be processed before changes are reflected. Once all this is in place, you’re ready to deliver robust role-based security testing.
In these regulated times, it’s imperative not only to perform role-based security testing, but to document the results. While manual testers can complete check lists and capture screens, this is time-consuming, often random and hard to manage. Automated tests, on the other hand, can provide a consistent, detailed audit trail of both actual and expected results.
Take the extra time to designate a central location, if not a repository, for test results so that they can be shared with developers and mined for audit. Whether manual or automated, the end game is to prove that each element of the role/function/rights matrix is tested and any exceptions captured.
The Obvious Question
By now you should be wondering how long all this will take and whether you have the time and resources to dedicate to it. The answer is probably no, at least as a stand-alone exercise.
On the other hand, if role-based security testing is integrated with business-process functional testing, the incremental effort may be justifiable. Functional and user acceptance testing will likely require a comprehensive test environment as well, and their testing of end-to-end business processes will likely touch the same areas.
Simply by adding additional verification points to test cases for permitted business processes and adding negative tests for processes that should be prohibited, functional and security testing can both be accomplished at the same time.
Security challenges confront corporations at every front. At the enterprise level, with multiple uses and applications interacting, these take on even more significance and complexity. An orderly and thorough yet efficient test strategy is necessary to validate user role-based security, specifically one organized around the enterprise business process and operational model.
About the Author
Linda Hayes LINDA HAYES has founded three software
companies, including AutoTester, which produced the first PC-based test automation tool. She is currently the founder of test automation tools maker WorkSoft and an independent consultant.