Last month's article talked about why, in today's IT environments, an exclusionary access control model is required to enforce all but the most lax security policy requirements. It also discussed why many shops are naively reluctant to take on the task of implementing object access control and why alternatives such as "security exit point solutions," while useful, are not an alternative to using object-level access control to implement an exclusionary access control model. The article concluded with a description of how the system determines the level of PUBLIC authority it assigns to newly created objects when that authority is not explicitly specified at the time of creation.
This month, armed with the knowledge from last month, we'll discuss a process you can use to implement an exclusionary access control model on your existing systems. This process allows you to make incremental changes to your system on an application-by-application basis, while limiting the potential of impacting your production systems.
While this process may take a relatively long time to complete for a system with a large number of libraries and applications, it allows you to work on parts of the system in a way that won't impact the rest of it. It means you won't have to carve out one contiguous block of time to make all necessary changes to the whole system while all of your other responsibilities pile up without getting done. It also means that you can attack parts of the problem, slightly improving the security of your organization, and then work on something else before coming back to make more improvements or to move to the next part of the system.
In this case, doing something--even a little bit at a time--is definitely much more valuable than doing nothing.
First Things First
To implement an exclusionary access control policy, start by making a list of your applications and the libraries they use for application data.
Users should require only *USE to most applications. In general, PUBLIC should be excluded from most mission-critical applications as well as application data. The process defined here is done an on application-by-application basis, so this list is a must.
Directories in IFS also have a mechanism for specifying the PUBLIC authority policy of the directory. It works a bit differently and does not use the system PUBLIC authority policy (i.e., QCRTAUT). This article addresses libraries, but you can use a similar approach on directories.
The Process
Our goal is to implement an exclusionary access control policy. This means we want the system PUBLIC authority policy to be *EXCLUDE and, unless we explicitly choose a different policy for a specific library, the library PUBLIC authority policy to be *SYSVAL.
Changing the access control model of one application without affecting any others involves accomplishing three objectives:
- First, change the library policy for the system and libraries to *CHANGE. Start by using CHGLIB to change the CRTAUT attribute for QSYS. Then, for each application, change the application's library PUBLIC authority policy to use *CHANGE rather than *SYSVAL. This removes any dependency on the system policy. When this change is made for all mission-critical application libraries, you can change the system PUBLIC authority policy with little fear of impacting production.
- Second, reduce the library PUBLIC authority policy for an individual application to the lowest value that allows the application to be used successfully by authorized users of the application. If you can reduce this value to *EXCLUDE, go ahead and change the library PUBLIC authority policy back to *SYSVAL. Then test the application. After successful testing, put the changes into production and start on the next application. It's not a bad idea to run these changes in production for one business cycle just to be sure that there will be no impacts.
- The third and final objective is to change PUBLIC authority to existing objects. This will require the most time and effort.
The first two objectives involve changing the PUBLIC authority policy of the system (i.e., QCRTAUT system value) and of libraries (CRTAUT library attribute). This will affect only newly created objects and libraries. While this is a useful and necessary accomplishment, you don't really have an exclusionary access control model until you accomplish the third objective: minimizing the PUBLIC authority on existing objects and libraries.
The easiest way to attack these objectives is to take a single application through the first objective, test it, and roll the changes for that application into production. Then do the same for each of your other applications. Once you have taken all applications through the first objective, do the same for the second and third objectives.
Don't try to take one application through all of the objectives or all applications through a single objective at once. It might take a little longer doing it this way, but you'll minimize the chances of major disruptions to your production systems.
Once you have implemented your exclusionary access control model, the next logical goal is to focus on minimizing the private authority to application data required by authorized users of applications. This goal will likely require changing many of your applications (and is therefore outside the scope of this article).
Let's look at each objective in more detail.
Objective 1: Set the System and Library PUBLIC Authority Policies to *EXCLUDE
To attain the first objective, you will change how the system derives *CHANGE as the default public authority for newly created libraries and objects.
The first item to change is the CRTAUT value on library QSYS. Change it from *SYSVAL to *CHANGE. This will allow you and applications to continue to create new libraries that have a default public authority of *CHANGE--even after you change QCRTAUT to *EXCLUDE. Make this change only if the current value of CRTAUT on library QSYS is set to *SYSVAL.
Next, use your lists of applications and the libraries they use. Working with one application at a time, if the CRTAUT value for an application library is currently set to *SYSVAL, change it to *CHANGE; otherwise, leave it alone. Test the application to ensure it still runs correctly. Do this for each application or for all applications. If you have a large number of applications, it will ultimately be easier to manage the process one application at a time.
When all applications have been accounted for and changed appropriately, set the QCRTAUT system value to *EXCLUDE. Retest the applications. Roll out the changes to production and run for at least one business cycle to ensure no applications have been affected.
If you are running on i5/OS, operating system functions will continue to work appropriately, regardless of the value of QCRTAUT and the QSYS CRTAUT attribute.
If any applications fail, you should be able to determine why and make appropriate changes to public authority for that application. If not, you should very firmly demand that the application provider either explain how to use the application securely or fix it.
Your system behavior and security posture will be essentially the same as it was before making these changes. However, you now have the ability to begin to implement a real exclusionary access control model on an application-by-application basis with little or no effect on other applications.
Objective 2: Reduce the PUBLIC Authority Assigned to Newly Created Objects in Libraries
The second objective is to reduce the QCRTAUT attribute on existing libraries to the minimum required by the application to work as normal without changes. This will require some knowledge of the application and how it's implemented. While this objective is definitely worthwhile, you may find a large number of applications that won't work without the default being set to *CHANGE or without some additional configuration or application changes. But this step lets you get to the low-hanging fruit.
This first step in this objective is aimed at learning whether the application is dependent on the value of the CRTAUT attribute on the library. It may not be if the application has already created all of the objects in the application library that it needs. Or the application may continue to create new objects, explicitly setting the public authority it needs.
The second part of the objective is to change the value of the CRTAUT attribute to the lowest you possibly can without impacting your users' use of the application. If the application is not dependent on the value of the CRTAUT library attribute, change it to *EXCLUDE. If you determine the application is dependent on the value of this attribute, it may not require *CHANGE. If it works with *USE, change the CRTAUT library attribute accordingly. Change the CRTAUT parameter to *EXCLUDE on as many libraries as possible. Reduce the value to something less than *CHANGE on as many of the remaining libraries as possible.
Test your changes and roll them out to production. After at least one business cycle in which all critical applications are executed, if no problems are encountered, change each library with the CRTAUT value set to *EXCLUDE back to *SYSVAL. You have now changed the configuration of these applications to use the standard indirect derivation of default *PUBLIC authority for objects newly created in the library. No changes are required for libraries having other values for the CRTAUT attribute.
Objective 3: Reduce the PUBLIC Authority Required on Existing Libraries and Objects
The purpose of this objective is to tighten up security of existing objects. However, rather than attempting to set PUBLIC *EXCLUDE in one giant leap, we'll focus on reducing PUBLIC authority to the minimum required for authorized employees to continue to run them successfully--without changes to the application.
This objective requires careful testing of the changes you make before you roll them into production. Work with one application at a time. You will need to understand what the application does in order to make reasonable guesses about the PUBLIC authority really required in order for the application to run successfully.
If you have existing groups and authorization lists, you will likely be able to easily and quickly reduce PUBLIC authority for the application's library to *EXCLUDE. If not, you may still be able to reduce PUBLIC to *USE.
Grant *CHANGE to the library or authorization list that you will use to secure the library to those user profiles or group profiles that represent the set of all authorized users of the application. Then, change the PUBLIC authority to the library to *EXCLUDE.
Do enough testing at this point to feel confident that you haven't introduced any problems. If there are no problems, reduce the authority granted to users and groups to *USE. Then perform extensive testing.
If authorized users are no longer able to run the application successfully, undo the last change you made and add this application to a list that will need more in-depth analysis. Do the same thing for the next application.
If authorized users are able to successfully run the application with *USE, follow the same approach for objects in the library. These objects are likely to be more sensitive to changes in private authority. Use your knowledge of how the application works to make reasonable guesses about the authority authorized users will need to the objects. For example, database files are likely to require *CHANGE, while executables are likely to require only *USE.
Once you have done this for every application, you have accomplished your goal! You have moved your system to an exclusionary access control model.
Don't Take Unnecessary Risks
In today's environments, very few if any IT shops can afford the consequences of an open access control model, which includes the possibility of having to defend the adequacy of that model in court.
The problem with an open model is that when you make a mistake, users have access to something they shouldn't. Alternatively, a mistake in an exclusionary model simply means users can't access something they should be able to. It's difficult to determine whether someone has accessed something they shouldn't when the access control mechanism indicates that the person is authorized to the object. On the other hand, it is pretty easy to learn that someone can't access something to which they should be authorized. Therefore, moving to an exclusionary access control model should be one of the highest priority projects on your IT work list.
The process for moving to an exclusionary access control model as defined in this article allows you to move the entire system to an exclusionary model over time and at a pace that you and your organization can handle.
I strongly urge you to start the journey today!
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online