The bottom line, however, is that you have to choose to exploit most of the capabilities in order to derive any benefits from them. Which capabilities and their particular configurations you choose to exploit can be determined only in the context of your organization's security policy. Your security policy defines the level of security required by your organization. A particular security configuration on a computer system represents an implementation of your organization's security policy. Security configuration does not define the security policy; it is an expression of it.
Compliance auditing is the process of determining whether your system and the data on it are secured according to the policies of your organization. Compliance auditing does not determine whether your data can or cannot be compromised. As system administrators, it is your job to implement the policy (assuming you don't also wear the CIO or CSO hat in your organization).
Unfortunately, many iSeries customers assume that if they use iSeries, somehow they have "security." Nothing could be further from the truth. If this were possible, there would be only "one big security policy in the sky," and all systems would be configured to implement that policy, with no choices left for the customer. This is obviously not the case. While the system's many capabilities help make the system easier and cheaper to secure without your having to make any decisions, most of the functionality requires you to determine whether and how to use it.
The core process of managing security on your system is object access control. Lots of other things are important too, but managing who's allowed to access which data and for what purposes is the heart of managing your security.
The holy grail of security would be to allow nobody to access anything for any purpose; of course, this would make your system literally useless for data processing. For a system that people actually have to use, your goal is a little more modest: You want give authorized users the minimum amount of authority--both private and PUBLIC--required to successfully perform their jobs.
In many cases, assuming you can change or affect changes in your application programs, you really can allow a person to use applications without granting them any authority--private or PUBLIC--to application data. Achieving this level of access control for all application data is a goal you should always be working toward, but know that you are unlikely to be able to achieve it fully.
Oh My!
I am flabbergasted by the large number of customers that either don't manage access control at the library and object level or use an open access control model. Many customers just use the system defaults for PUBLIC authority, which means all users have *CHANGE authority to most application data. Some ISVs have never tested with anything other than the system default access control and therefore don't officially support any other configurations.
I don't believe it is possible to correctly implement even the most basic of security policies today without more tightly managing library and object access control--even with third-party vendor exit point solutions. Don't get me wrong, exit point products provide lots of value in terms of allowing you to implement more stringent or granular access control to the interfaces. If you fall into one of the scenarios described above and don't have an exit point solution installed, run--don't walk--to an exit point security vendor.
But exit point solutions only protect access to interfaces. They do not protect access to the data. And today, too many different interfaces can potentially be used to access a single piece of data. It is difficult to ensure that a specific exit point solution covers all of the interfaces you need covered. Exit points don't exist for every possible means of access data on your system. For example, the Apache Web Server does not have an exit point. Sure, you can build a custom Apache mod_auth module, but how many exit point vendors provide one today? Finally, vendor applications tend to be at least one release behind the most current, and most are further behind than that. If IBM adds a new interface--even if it has an exit point--how long will it be before the exit point vendors catch up?
Again, exit point solutions provide a great amount of value with or without a proper access control strategy. If you aren't already tightly managing access control on libraries and objects, they provide a higher level of security than you already have and should be used while you implement an adequate access control model. They are not, in my opinion, an alternative to proper access control.
When I discuss the need for a tighter access control policy with customers, many respond that they have "always run the system this way" and now have hundreds or thousands of libraries and objects. They can't even begin to comprehend where they would start to implement a reasonable access control mechanism. It appears to be the proverbial "you can't there from here" problem to most people.
My goal for this and the next article is to convince you otherwise!
Getting There from Where You Are Today
First and foremost, understand that moving to a reasonable access control model will truly be a journey for most customers, not a Star Trek transporter experience in which you are in the Enterprise one moment and on some unheard-of planet the next.
The journey consists of a number of independent objectives that you can achieve individually rather than all at once. In our travel analogy, we are at point A. Our goal is to get to point D. But there is no known route directly from A to D (or there's a direct route, but a mountain range is in the way). Instead, we'll start from where you are now, point A, and head toward some intermediate points before arriving at our final destination, point D. Each point along the way will either make it easier to get to the next point or get you closer to the goal.
Remember, the ultimate goal of having no users with any direct authority to application data is one step beyond what will be covered in these two articles. Our goal, point D, is for you to implement an exclusionary access control model. Once you have accomplished this, then you can whittle away at minimizing the amount of authority users have to application data.
Our goal, then, is to move your system from an open access control model to an exclusionary access control model, which defaults the PUBLIC authority on newly created objects to *EXCLUDE unless explicitly set to something else. In an open access control model, PUBLIC is defaulted to *USE or higher on newly created objects unless explicitly told to do otherwise.
It's Too Complicated!
Most customers find the prospect of moving to an exclusionary access control model overwhelming. But it doesn't have to be! With the approach defined in this article, you can move your entire system to an exclusionary model on an application-by-application basis, on your time schedule, while minimizing the potential for disrupting your production system. You don't have to change every application at once.
To change the access control model on your terms, rather than the system's, you first have to understand how the system derives the default PUBLIC authority. Armed with this understanding, you can change each application to derive PUBLIC authority at the application level rather than the system level.
Deriving PUBLIC authority at the application level allows you to work with each application individually and independently of other applications. For example, change one application this month and another next month, and eventually you will have moved the entire system to an exclusionary access control model--while still having time to accomplish all the other tasks for which you're responsible.
Using this approach also minimizes the risk of disrupting mission-critical production applications.
To understand why and how this approach works so well, you need to understand how the system decides what the public authority of an object or library should be when you don't explicitly tell the system what to set it to.
How Default PUBLIC Authority Is Derived
"Default PUBLIC Authority" refers to the PUBLIC authority assigned by the system to a newly created library or object when that authority is not explicitly specified by the AUT parameter of the CRTxxx command that creates the object.
Most people (including me) would respond to the question "How does the system determine the value it assigns as the PUBLIC authority for objects created on the system?" with something like this: "It depends on the current setting of the QCRTAUT system value." While this answer will generally correctly predict the value the system ultimately assigns to a new object, it's not the correct answer to the question!
This inaccurate mental model--that the value of QCRTAUT directly controls the default value of PUBLIC authority of newly created objects--is what makes the idea of changing to an exclusionary model seem so utterly unattainable.
So how does it really work? It's simple and complex at the same time.
PUBLIC Authority to Objects
If you don't explicitly tell the system what the PUBLIC authority of an object should be when you create it, the system will use the "PUBLIC authority policy" for the library into which it is created. That's it. That's what you really need to understand.
Library PUBLIC Authority Policy
Ok. So what's the PUBLIC authority policy for a library? The value of the CRTAUT library attribute is the PUBLIC authority policy for that library.
This is where it starts to get a little complicated. A library's PUBLIC authority policy is entirely independent of the authority PUBLIC is granted to the library itself. The former is a policy that is applied to objects created in the library. The latter is the authority PUBLIC has to the library. Both of these are set at the time a library is created.
PUBLIC Authority to Libraries
PUBLIC authority to a library is also derived from policy. You just have to remember that, with respect to PUBLIC authority to the library, libraries are assumed to be created in library QSYS. Therefore, it is derived from the policy in effect for library QSYS.
Library PUBLIC Authority Policy vs. PUBLIC Authority to Libraries
If you don't explicitly tell the system what the PUBLIC authority policy of a library is, the policy will be to use the system's PUBLIC authority policy in effect at the time an object is created in the library. Note that this is distinctly different from setting the library policy to be whatever system policy is in effect at the time the library is created! While the policy itself is set at the time the library is created, the value of that policy is determined at the time an object is created in the library.
Like all policies, there are often exceptions. For example, even though the policy for objects created in a library is *EXCLUDE, there may be one or more objects in the library to which PUBLIC has been granted some higher level of authority. A useful rule of thumb is that the PUBLIC authority policy for a given library should reflect the value required by the majority of objects in the library.
Valid System and Library PUBLIC Authority Policies
The system's PUBLIC authority policy can be one of the following: *ALL, *CHANGE, *USE, *EXCLUDE.
A library's PUBLIC authority policy can also be any one of these values. However, there are two additional options: *SYSVAL or the name of an authorization list. *SYSVAL indicates that the PUBLIC authority policy of the library is the system policy in effect at the time an object is created into the library. Unless you indicate otherwise, the system assumes that you want *SYSVAL to be the value of the library's PUBLIC authority policy (i.e., *SYSVAL).
Now you have an accurate conceptual model of how the system derives PUBLIC authority for new objects when it is not explicitly specified when the object is created.
Let's briefly discuss how this behavior is enforced on the system.
Default Policies
QCRTAUT, which specifies the system's PUBLIC authority policy, is set to *CHANGE by default. The policy can be changed with the CHGSYSVAL command.
IBM sets the policy for library QSYS to *SYSVAL by default. It tells the system to apply the system policy in effect at the time an object or library is created in the QSYS library. You can change this with the CHGLIB command.
The CRTLIB command's CRTAUT parameter also defaults to *SYSVAL. User-created libraries will have the same policy as library QSYS. You can change the command default for CRTAUT to something else. You can also use the CHGLIB command to change the value of CRTAUT after the library is created.
Default PUBLIC Access
The AUT parameter on all CRTxxx commands specifies the authority the system should grant PUBLIC to the object being created. This applies to libraries as well as objects created in them. By default, this value is set to *LIBCRTAUT. It tells the system to apply the policy of the library into which the object is being created (i.e., the value of AUT = the value of the library's CRTAUT attribute = *SYSVAL = the value of QCRTAUT).
Now you have an accurate model of how the system derives PUBLIC authority for newly created objects on the system. In the next article, I'll describe a process for moving your system to an exclusionary access control policy over time--not all at once--in a way that minimizes the potential of disrupting production applications.
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