The job of securing computer systems is changing. A host of new laws and regulations such as Payment Card Industry (PCI), Sarbanes-Oxley (SOX), and the Health Insurance Portability and Accountability Act (HIPAA) are forcing organizations to reconfigure their systems to be compliant with security and privacy requirements. These regulations are often unavoidable. Some come from government agencies, and others come from vital business partners such as payment card processors VISA and MasterCard and others. New regulatory requirements will require us as IT professionals to adapt to new ways of working and new ways of thinking about security.

Despite the need for change, many organizations approach security in the regulatory age the same way they did in the past. Specifically, many businesses expect that a small group of highly technical folks working alone and following a best practices sheet will be able to secure and make compliant all parts of their information systems. This is not possible. However, members of the technical organization will most likely manage and guide the security process. Their knowledge of the systems and the technical corners where security problems can hide give them unique insight into when the job has been done well.

Information must be protected in a way that focuses on who accesses data and in what ways. This data-centric approach to security results in a policy specifying the desired outcome. The policy is more than a set of implementation steps. A good resource access policy is meaningful to everybody in an organization, and it lets your auditors know what is being done and why. The policy should be specific enough to provide the definitive guidance on how data will be secured.

Defining the policy to secure your data is not done in a box by IT alone; it is an organization-wide activity. Correctly configuring access requires people to work together in new ways. Business leaders must become involved — they have unique knowledge about business-critical tasks performed in the company and who performs them. This knowledge is essential to determining whether a person should have access to a piece of data. The legal staff and auditors must now ensure that security is being practiced in a way compatible with a slew of regulations. In fact, it might be only the legal staff of a company that can make the determination about which laws and regulations are applicable. Finally, a company's external auditors must be clearly shown what was done and why it complies with the law. Better security is always a benefit, but now it must be well documented and straightforward enough that an auditor with only the most basic understanding of a company and its systems can see that it is compliant.

Showing that security is improved and how it is improved is a central challenge in the regulated world. It is an often-used truism that business moves faster than it used to. Less time is given to each new project, and each one is more complicated than the last. With more complication and specialization comes a need for better communication between people in different jobs. Tools and practices we adopt now for security must bring people together so that all can provide meaningful input.

This article focuses on a process that you can use to bring disparate members of an organization together to create and apply a resource access security policy. It includes who must be involved and the role they must play to increase the success of the project. It also contains some tips to avoid the pitfalls commonly encountered when retrofitting your system for resource access security.

Secure Perspective

To better illustrate the steps required in this process, we use the new IBM product offering named Secure Perspective (download a flash demo of the new release at www-03.ibm.com/systems/i/security/rethink_security_policy.html). Secure Perspective was born in the Rochester Labs as a System i-specific security tool. In its most recent release last month, IBM announced that the product now supports not only the System i but also MS Windows, AIX, and general DB2 platforms. You've come a long way, baby, in a very short time span.

A real-life scenario makes a process easier to place in context. Let's look at implementing requirement 7 from the PCI standard. It is relatively easy to understand but, in fact, different PCI auditors will have different opinions on exactly what it means in a particular IT environment. Nevertheless, all of us in IT have the chore of implementing the policy and controls required. Visit the PCI Standards Council (www.pcisecuritystandards.org/pdfs/pci_dss_v1-1.pdf) for more information. Requirement 7 of that list can be stated most basically as, "People should see only the information that is needed to perform their job." This leads to a few simple questions. What types of data (resources) exist in the organization's IT systems? What roles or broad job categories (actors) exist within the organization? What access must each actor have to each resource to do his or her job? Where is the data stored?

Step 1: Obtain the Support of Top Management

For a project of this scope to succeed, top management must be committed to the project. If step 1 is skipped, you most likely will not have a successful project. Top management will typically commit to a project like this when, for example, the PCI auditor is threatening fines or other sanctions on the organization. In non-PCI organizations, SOX and/or HIPAA and/or the OCC for banking companies can threaten to lower the boom on your organization as well.

It is up to top management to persuade or coerce midlevel management to spend the time and effort required to provide you with the information you require to make the project successful.

Step 2: Assemble the Group

The right group of people to answer the three questions will be different for every organization. It might be that the director of IT operations can answer question one, and a representative from HR can answer question two. Whoever they are, find them and enlist their help early in the process.

Step 3: Define Actors, Resources, and Actions

After you assemble the right people, work through the first two questions. If the right people are in the room, this might take no more than a couple hours. The actors (roles and job categories) in a company should be listed at a high, functional level. This would include roles such as managers, accountants, IT staff, and order-entry clerks. If the organization using the IT systems is small, you can walk each person through an organization chart to place him in a role.

Additionally, some programs might have their own role within the organization and need to have their own actors to represent them. This is often the case when a program or service running under a single profile is the only one allowed to access data. For example, you might use a special user ID to run your nightly batch processes or to process ODBC requests from your web server. Including this user ID (actor) in the initial planning will help avoid problems later.

Resources (categories of information and programs) should also be defined at a high level of abstraction. Reasonable categories are accounting data, customer service applications, and employee data. It is important that the categorization — and therefore policy — lists types of information and not how or where that information is stored. If you name a resource something such as "customer address file abc.file," it would be much harder for those without a technical background or not familiar with the application systems to be involved.

Secure Perspective captures all of these terms. Figure 1 shows a term being entered for the actor "accountants." Conveniently, you can create both a definition and a set of synonyms that various other regulations can use to refer to this same group of people.

It is important that the list of terms be available to all of the project participants. A lack of common terminology can quickly lead to confusion about what is being protected and ultimately result in security holes in your implemented policy.

Step 4: Create the Policy

After the set of actors and resources has been defined, you can write the policy. This step might require input from business leaders and department managers. One easy way to start is to create a straw-man policy. It will no doubt need revision, but it will give managers, auditors, and lawyers who are new to creating policy a place to start. Good policy statements should be in the form of <Actors> can <action> <resources>. If phrased in this way, it is easy to see who is getting access to which resources.

Secure Perspective provides two different ways to create and edit policy. One is to modify the policy as a set of English sentences that can be edited like a document. These are parsed by a natural language processor and broken into known dictionary terms. The second way to modify the policy is to add and subtract terms entered into the product dictionary. Whichever method you choose to create the policy statements, you can edit them with either method.

Business leaders, auditors, and legal staff should then sort through the policy statements, adding and removing the access of actors to resources. An easy way to visualize whether an actor has been granted access to a resource that was not intended is to create an access matrix from the policy. Secure Perspective generates this matrix automatically.

After you review the policy in both matrix and written form, check for multiple statements that grant an actor the same access to a resource. Removing these duplications early will avoid problems later when what is thought to be a policy change really leaves an actor's level of access unchanged.

Writing a resource access policy in this system-independent way makes it easy for everyone to see what the behavior of any system should be. This can save significant time during an audit. The auditor can address all questions about the policy to the business or legal side of the organization and questions about how the policy is implemented to the IT side of the organization.

Step 5: Map the Policy to i5/OS Objects

Mapping the terms from the policy to digital assets (classification) defines how the policy should be implemented on the business systems of an organization. Mapping is the process of associating each actor term with a set of user or group profiles, associating each action term with system control mechanisms, and associating each resource term with files or objects residing on the system.

Mapping is perhaps the most time-consuming step in configuring resource access security. It is best done with the help of those who have in-depth knowledge of where each application stores its data.

First, you must choose the systems that must comply with the policy. For example, those systems that process payment card data might have to comply with the PCI standard, but my Thinkpad — which does not handle credit cards — does not. Each regulation imposes different requirements about which system in an organization it applies to.

Keeping track of the objects, files, and users mapped to terms in a usable way can be difficult. Secure Perspective simplifies this task by showing lists of users and trees of objects available on a system. These can then be easily mapped to terms entered in previous steps. Should any of the mapped users or objects be deleted from the system, Secure Perspective will detect their absence and remove them from the mappings.

For some applications, nobody within the organization has enough knowledge about where the data is stored to map the objects to terms. One trick you can use is to audit the access of a specific user to a set of objects that you think might be used to contain a category of data. You do this by setting up QAUDJRN and setting your system values to allow auditing of users and objects (for more about this process, see "Common Sense Security Auditing," August 2004, article ID 18842 at SystemiNetwork.com). Once the QAUDJRN and journaling options are properly set, you can use the test user to exercise an application to see or change the data in question. This should leave audit records (ZR and ZC) in QAUDJRN that show which files were read and changed during the course of the test run.

Step 6: Check the Policy and Mappings

After you create the policy and map the objects, test the combination of the two. The tests should look for areas where insufficient access has been granted to users. It is not unusual when defining a new resource access policy to leave out important access needed by a set of people to perform important business functions. When this happens, all work can come screeching to a halt as applications and users are denied access to data.

To avoid surprise outages, any new security configuration should first be tested on a development machine, if one is available. The security of as few objects as possible should be changed. Then, a test user for each actor should run though the tasks and applications that are required for his job.

Secure Perspective contains an awesome function to make this policy-checking easier and does not require the modification of any system. It starts by analyzing the security audit journal (QAUDJRN) records for accesses to files and objects that have been mapped to resource terms. It then evaluates each of the accesses to see whether they would likely be able to take place, were the policy to be applied. The results of this analysis can then be examined to determine whether any accesses denied by the policy are accesses that really should be allowed.

This policy-checking feature lets you go through the Secure Perspective workflow to create your entire policy, then evaluate your policy against the real business processes on your system. This capability alone makes Secure Perspective a must-have product if you are contemplating a retrofit to resource-level security.

Step 7: Apply the Policy

Once you've checked the policy and mappings for problems, you can apply them to the systems. Applying the policy consists of removing all access from the files and objects mapped to resource terms and then adding back the access specified by policy. A good resource access security policy implicitly forbids any access not allowed by the policy. So, if we don't have a policy statement saying that managers are allowed to view customer data, they can't.

After applying the policy, Secure Perspective records when the policy was applied, who applied it, and if any changes specified by the policy could not be made. This provides a way to show your auditor not only that you are currently in compliance, but that you are also taking steps to stay in compliance.

Here is where Secure Perspective can make life much easier. With the click of a button, it can take the defined policy and mappings and generate the list of statements that need to be run to change the system to comply with the policy. For i5/OS, the statements are written in CL. Clicking another button will run those CL statements on the system.

Step 8: Check Compliance Periodically

Checking compliance is the rigorous process of examining each file or object mapped to a resource to ensure that it remains configured to match the policy. There are several reasons that a previously configured object might have become noncompliant. A person could have changed the security settings of the object itself, granting too much access or denying required access. Someone might have changed his role within the organization and now requires different access to data. Another way in which a file or object can become noncompliant is for the policy to change. The policy might change to meet new business needs or to satisfy an auditor's request. This is a particularly difficult change to manage because manual effort is needed to figure out which files are affected by the policy change. To detect changes for any of these reasons, you need to perform a check on each file for a number of factors. For example, is public access excluded? Is each user on the system to whom policy grants access given that access? Are there users on the system who have more access than they should?

Secure Perspective makes checking policy compliance a snap (for Dan Riehl's take on the product, see "My Perspective on Secure Perspective" on page 51). It examines your system for noncompliant objects and reports its findings back to you. With the right tools and techniques, configuring resource access security isn't as tough as it might seem. The biggest adjustment that most people will need to make is to expect lots of new people to play a part of the policy creation process.

As all parts of an organization get involved, the organization can become more secure. Better input can lead only to better policy and better control over information. As more people become involved in defining what it means to be truly secure, fewer folks will see it as the duty of that "other guy" to keep systems safe.

Dan Kolz is a software engineer working for IBM on i5/OS security, focusing on improving the ability of users to easily configure their systems for security and compliance. Most recently, he has led the development of a new product, IBM Secure Perspective. Dan has been recognized as an IBM Master Inventor with more than 100 applications filed in the U.S. patent office.

Dan Riehl is the director of services for The Powertech Group, a System i security technology company. Dan is also a technical editor for System iNEWS and the editor of the System iNetwork Systems Management Newsletter.