Managing Special Authorities. for PCI Compliance. on the. System i

Managing Special Authorities for PCI Compliance on the System i

Introduction What is a Powerful User? On IBM s System i platform, it is someone who can change objects, files and/or data, they can access sensitive data and make modifications which can impact your entire organization or a large subset of your organization. Managing powerful users on the System i is different from other platforms due to the unique way users can access the system and the many different levels of power each user may have. When evaluating a system, an auditor looks for powerful users and want to know the following; who are they, what can they do and what have they done? The reason for this concern about these particular users is that 50% of known security incidents come from employees. 1 An Insider Threat Survey conducted by the Computer Emergency Response Team (CERT) at Carnegie Mellon University found that 57 percent of insider security attacks identified were carried out by employees who at one time had privileged user status. 2 These statistics show why the primary concern among IT auditors is powerful profile management. Luckily for System i companies, who use OS/400 as their operating system, most auditors don t understand the system well enough to know when powerful users are being managed properly or not. So, even though many studies about System i security show it is not properly secured, very few of these systems fail their audit. In this paper we will discuss the unique way System i (OS/400) users achieve special authorities and how auditors regard those authorities as threats, in the context of COBIT and PCI standards. In every IT audit performed, auditors are looking at the practices organizations have in place for limiting the number of powerful users and monitoring their access to corporate data. In OS/400 there are five main ways to manage users access: Special Authorities These are special powers given to individuals or groups, so they can perform tasks such as backing up the system, creating profiles, writing programs, installing applications, etc. Object Ownership If an individual owns an object, they can do anything with that object. Objects include programs, libraries, users, groups, etc. Object ownership is critical when considering OS/400 security. Menu Control This is the traditional way people manage security on OS/400. If a user should not access payroll files, do not give them access to the payroll menu. This is a simple way to control users, but inadequate in a networked environment. Command Line Access The command line gives a user the ability run commands like CREATE and DELETE. A user can do much less damage when command line access is limited. 1 PricewaterhouseCoopers annual Global State of Information Security Survey, 2008 2 http://www.cert.org/insider_threat/ SAFESTONE SafestOne for User Management and Compliance on the System i Page 2 of 11

Network Access This is the most common way that users can access data outside of green screen applications. Using standard protocols like FTP and ODBC, a user can access and change data without any controls that their application software would provide. The amount of damage a user can do through network access is only limited by the authority or object ownership they have. To manage powerful profiles on the System i you will need to address all 5 of these possible accesses. Some of them are easier to manage then others. For example, it is relatively easy to turn off command line access to users, or to control the menu items a user is able to access. Network access is a more complicated, but there are third party exit point solutions to address this problem. The two issues which we will explore further are Special Authorities and Object Ownership. Many companies find that limiting special authorities is not as much a technical challenge as it is political one because users who have all access (*ALLOBJ) to data believe they should continue to have this access, and taking it away from them can prove to be difficult. From an auditor s perspective, this is a serious problem and could represent an audit deficiency. SAFESTONE SafestOne for User Management and Compliance on the System i Page 3 of 11

Powerful Users and Special Authority What are special authorities on OS/400? Special authorities are rights given to users or groups which allow them to perform tasks not normally allowed for an average user. It is very common to give users special authorities in organizations. Unfortunately, special authorities are often attached to profiles, groups or programs without regard to the potential security exposure they may represent to the organization. Below is a summary of the special authorities, along with the risk they pose. Based on these risks, it is clear that assigning these authorities should be closely monitored and managed. All-Object Authority (*ALLOBJ) This is the most powerful authority on the System i. Contrary to popular belief, a user or group of users with this authority cannot be controlled. With *ALLOBJ a user can change any object on the system. Service Authority (*SERVICE) A user with *SERVICE can change programs and track network traffic, giving them the ability to gather information via network or cause damage via programs. While they are unable to delete programs, they can change configurations for hardware and disks. Save and Restore Authority (*SAVSYS) This authority was developed so a user can back up the entire system even though they don t have authority to all objects. This means that a user with *SAVSYS can save all objects and delete all objects (using Free Storage option) on the system. They can also restore to a different library where they have authority to all restored objects and make changes or view any they would like to see. A user with this authority is a serious risk to a system. System Configuration Authority (*IOSYSCFG) A user with *IOSYSCFG can configure and/or change communication configurations. For example, allow another powerful user to access the system without a password. This includes changing TCP/IP and other Internet connection information. Spool Control Authority (*SPLCTL) A user with *SPLCTL can read or delete any spooled files on the system, including job queue entries and reports. In addition they can hold, release and clear output queues which they don t have authority to. Security Administrator Authority (*SECADM) A user with *SECADM can create, change, and delete user ID s. This means they can create powerful users which can be used for erroneous activity. Similar to *ALLOBJ, this is a very dangerous authority and should be restricted. SAFESTONE SafestOne for User Management and Compliance on the System i Page 4 of 11

Job Control Authority (*JOBCTL) A user with *JOBCTL can end any individual jobs, terminate subsystems or power down the system at any time. They can severely affect operations and, in addition, they can control any user s job. For example, allow a user to view or divert print jobs. Exposure: Moderate Audit Authority (*AUDIT) A user with *AUDIT has control of the system auditing functions. This means they can decide if certain users (like themselves) are audited when looking at certain sensitive objects (like payroll). Exposure: Moderate The amount of exposure that goes along with these special authorities is often a surprise to OS/400 veterans. These authorities can be assigned to individuals, groups, and shared profiles. In some cases the authority is assigned by a system administrator when they create a profile, in other cases an individual inherits special authority because they are made a part of a certain user class (programmer, sales, executive, etc.). These authorities can also be given by default based on the OS/400 security level. For instance, at Level20, all users are given *ALLOBJ authority by default. While at Level 30 and above there is no DEFAULT setting. In the next section there will be more detail regarding these exposures and what auditors would like to see in regard to controlling powerful users. SAFESTONE SafestOne for User Management and Compliance on the System i Page 5 of 11

Audit and Security Concerns As seen in the previous section special authorities can give users the power to do things that companies and auditors want to pay attention to. Obviously, someone in the organization needs to have these authorities at certain times, depending on their current task. Most companies assume that special authorities are monitored and not handed out to just anybody. Unfortunately, this has proven not to be the case. In fact, multiple studies of AS/400 systems show that the average organization has more than 80 users with *ALLOBJ authority. In one large public organization, there were as many as 15,000 users with equivalent of *ALLOBJ authority. This section describes the approach an IT auditor uses within a large organization and the organization s attempt to meet the auditors requirements. It will show where auditors find issues and where they often miss very important things. Specifically, it will focus on Special Authorities and Object Ownership, which are at the root all powerful profiles. Auditors went into a public company expecting to conduct a routine audit. However, as the auditors examined the company they uncovered some disturbing facts about the current powerful profile management procedures. There were three main concerns: 1. 900 individual profiles had *ALLOBJ authority. 2. One of those profiles was a group profile that had *ALLOBJ authority and more than 15,000 users belonged to that group profile, thus giving all of them *ALLOBJ. 3. Users were sharing the generic QSECOFR profile and the use of this profile could not be traced back to individual users because it was unclear how many people actually had access to the profile password. From the auditors perspective this was a violation of COBIT, which is the control framework promoted by ISACA (Information Systems Audit and Control Association) and the standard most often used by international IT auditors to evaluate compliance with SOX, Basel II and other regulations. The above was also a violation of PCI requirements, which, from a business perspective, was even more of a problem because if this organization is not compliant with PCI, it could affect its ability to accept credit cards from more than 2 Million customers. To understand why the current user management practices were in violation of COBIT and PCI standards, applicable sections of each standard are listed below: COBIT DS 5.4 User Account Management Ensure that requesting, establishing, issuing, suspending, modifying and closing user accounts and related user privileges are addressed by user account management. An approval procedure outlining the data or system owner granting the access privileges should be included... Perform regular management review of all accounts and related privileges. The symptoms above show that user account management is not taking place. Surely there is not need for 900, let along 15,000 users to have *ALLOBJ. And surely, there has been no regular review. COBIT DS 5.5 Security Testing, Surveillance and Monitoring Ensure that IT security implementation is tested and monitored proactively. IT security should be reaccredited periodically to ensure the approved security level is maintained. A logging and monitoring SAFESTONE SafestOne for User Management and Compliance on the System i Page 6 of 11

function enables the early detection of unusual or abnormal activities When people are sharing a profile like SECADM (as was the case above), it is not possible to audit who is using it and for what purpose. Beyond that, it is obvious no review was being performed to determine whether everyone needed the authority they had or what they were doing with it. COBIT AI6.3 Emergency Changes Establish a process for defining, raising, assessing and authorizing emergency changes that do not follow the established change process. Documentation and testing should be performed, possibly after implementation of the emergency change. Again, in the above scenario, thousands of people could make emergency changes, as well as whimsical changes. PCI Requirement 7.1 7.23 Implement Strong Access Control Measures Restrict access to cardholder data by business need to know - This sections is very specific and would take over a page to put the full content here. In summary it says privileged users should be given the least privileges necessary to perform the job, monitor their activity and implement an automated access control system. Obviously in the case above too many users have more privileges than are necessary to do their job. The only automated access control seems to be that everybody, automatically has all access to everything. PCI Requirement 8.1 8.5.16 Implement Strong Access Control Measures Assign a unique ID to each person with computer access This section is about 5 pages in the PCI DSS guide. Without even looking at the details of this section, it is obvious from the title that the above situation cannot possibly comply with this section because of the Group profile situation and the fact that users are sharing a generic profile for certain jobs. The auditors spelled out these concerns to the company and it was obvious that serious changes to the way powerful users were being managed had to be made. They had SOX and PCI compliance issue which could not be ignored. The frightening thing about this is not so much that this one company has these issues, but that these types of problems are not unusual in organizations and more organizations are now failing their IT audits. Auditors now realize the sense of urgency in making user management changes. While it is important to meet SOX and PCI compliance, these types of problems present a much broader data security problem which all organizations should be concerned about. SAFESTONE SafestOne for User Management and Compliance on the System i Page 7 of 11

Resolving Audit and Security Concerns The three issues found by the auditors at the company described in this example: illustrate the conflict administrators face in meeting the auditors ideal resolution, juggling the business needs, and finding a reasonable resolution. The three issues were as follows: 1. Too many powerful profiles - 900 individual profiles had *ALLOBJ authority. 2. Group profiles with powerful authorities - One profile was a group profile that had *ALLOBJ authority with more than 15,000 users belonging to that group profile. The result, 15,000 users with *ALLOBJ authority. 3. Shared profiles - Users were sharing the generic QSECOFR profile. The use of this profile could not be tracked to individual users because it was not clear how many people had access or who had the password. As mentioned previously, numerous studies over the last 6 years have shown that items 1 and 2 continue to be problems in OS400 environments. The third issue (Shared Profiles) is not as easy to measure, but has been seen and is accepted as common practice. Today, auditors are now looking at these three issues and the manager s challenge is to fix them before an auditor points them out. Too Many Powerful Profiles How many is too many? Using *ALLOBJ, as an example, because it is the most powerful of all special authorities and with it a user can gain any other specific power necessary, the public company mentioned above had 900 users with *ALLOBJ. This is an obvious problem. There is not a specific number that everyone has accepted as being too many. Most auditors start to get concerned at 10 or more profiles with *ALLOBJ. Some AS/400 experts will recommend less than 10. Taking away *ALLOBJ from 890 users is relatively easy technically, but the problem quickly becomes political. Many users that have *ALLOBJ very often believe they need this authority to do their jobs. Although, when asked what they use *ALLOBJ for and how often they need it, they cannot provide an answer. The public company in question disagreed with the auditors and insisted that almost all of the 900 users required *ALLOBJ, and argued it was thought that it would be unrealistic to take it away from users without adversely affecting the business. The auditors listened to the reasoning and decided that as long as a list of profiles was supplied along with an assurance that each of these individuals required this authority the users could keep the powerful profile with a periodic review of activity. While technically this did not satisfy PCI requirements to the letter, it satisfied the auditors concern and they let it pass. It is likely that these auditors or new ones will come back another time and require more strict requirements. And as PCI auditors become stricter with stolen credit card cases like TJ Maxx (which had 46 million card numbers stolen), this public company along with many others will have to come up with a better solution. To truly meet PCI and COBIT requirements, this company, along with any other company, should take away all users *ALLOBJ authority and only allow users to have that authority upon request. This can be done manually and is manageable for some smaller organizations with only a few users. For example, one small bank we know actually has one profile with *ALLOBJ. They change the password on it every day and lock it in a safe. In order for the safe to be opened up, a user needs two signatures from senior executives and they need to provide a report on their activities. However, this is probably not a practical solution for every organization. There are also software tools which will allow organizations to set up an automated check out process that meets regulatory requirements. Go to www.safestone.com to learn more about some tools to make managing powerful profiles much easier. SAFESTONE SafestOne for User Management and Compliance on the System i Page 8 of 11

Group Profiles with Powerful Authorities Group authorities start to get a little more complicated. In the case of this large public company, the reason they gave the group profile *ALLOBJ and they made all 15,000 users a member of that group was so the home grown application they used could work properly. This is a relatively common practice for organizations that develop their own custom applications. This is an easy way to create an application and avoid the difficulty of maintaining application security using OS/400s infamous object level security capabilities. In the early days of the AS/400, a user with *ALLOBJ authority was not a big security risk because there were only two ways to get to data (through application/menu or through the command line). But with PCs there are three ways to get to data: Application/Menu If a user s access is restricted to only the menus needed for their job, then even though a customer service rep has the ability to see and transfer data from payroll, they will not be able to do it if they don t have access to the payroll menu. In most AS/400 applications, menu security was the traditional way to secure data. Command Line A user with command line access and *ALLOBJ, poses a problem. Most organizations take away command line access to address this. If a user cannot get to a command line, they cannot run any commands, so even with *ALLOBJ, they cannot exercise any power. Network or Exit Point This is the third way an individual can gain access to data by using FTP or ODBC. A person with *ALLOBJ may not be able to access data through a menu or command line, but they can often access data through network access, unless the company has put exit point security in place (see www.safestone.com for more information). The public company in question had relied on Application/Menu and Command Line security to secure their data. Nobody at the organization thought about network access and the auditors were not aware of this type of access. The auditors were simply worried about the 15,000 users with *ALLOBJ authority so they made taking that authority away from those users a requirement. To comply, the organization simply took *ALLOBJ authority away from the group profile, but kept the users as members of that profile. Before they took away the *ALLOBJ, system administrators for the AS/400 were very concerned about whether the application would work. But they resolved this by making the group profile the owner of all objects that made up the application. So, even though the 15,000 users did not have *ALLOBJ, they did have *ALL authority to every part of the application which included the ability to download, change, or delete customer credit card files. 15,000 users with *ALL ownership for their main application and network access remained a huge security and PCI compliance problem. Taking away *ALLOBJ addressed the specifics of what the auditor perceived to be the problem, but it did not eliminate the company s security exposure. Even today, neither the auditors nor management at that organization understand the full impact of this exposure. To solve the problem, the organization needs to revamp their entire application s object level security set up. There are 250,000 objects within this level making it an overwhelming task that most organizations cannot began to resolve. The best approach for resolution is to make sure all three methods for getting to the data are completely secure. Menu security and command line access can be dealt with using existing operating system settings and the application configuration. But locking SAFESTONE SafestOne for User Management and Compliance on the System i Page 9 of 11

down network accesses is more complicated and this organization will need to go elsewhere to find experts to help with exit point security (go to www.safestone.com for more information on this). The above scenario where users have too much power and can access data through back door access is relatively common. AS/400 studies have shown that 70+% of organizations do not manage network access. Shared Profiles Sharing generic profiles is another very common practice. This large public company had a sign on for QSECOFR and the password was shared among numerous people without any controls in place. This is a very big concern for auditors. Shared profiles create a problem because it is difficult to determine who actually has the password for the profile and any actions performed by a user while sharing the profile are therefore anonymous. Auditors tend to recognize that sharing profiles can be a good way to manage special authorities, but controls have to be put into place. There needs to be a way to track who is using a special authority, when they use it, and what they do while assuming this authority. The answer to these questions can be discovered manually, but it is time consuming. In order to have a paper trail, some organizations require written authorizations and maintain manual reports which keep track of the specific check in and check out process. There are software solutions that automate and facilitate an electronic check out process. This allows companies to take away all special authorities from specific profiles, to assign special authorities when necessary for specific tasks, and to track the use of these special authorities. (Go to www.safestone.com to learn more about these types of automated solutions). SAFESTONE SafestOne for User Management and Compliance on the System i Page 10 of 11

Conclusion Safestone has worked with hundreds of AS/400 companies over the last 20 years. The scenario described in this paper is very common. There is a significant amount of confusion around powerful profiles, more specifically the confusion lies in how to identify these profiles, who has access to them, and gaining control of that access. As previously mentioned, there are several areas which must be considered when controlling these profiles: 1. Limit the number of powerful profiles in the organization Although the process can be painful, it is important to limit the number of users who have access to the 8 special authorities. 2. Restrict use of these special authorities This process can be done manually, however, it is time consuming and sometimes disregarded by auditors as an effective solution because there are no separation of duties, IT should not be controlling IT users. There are 3 rd party software applications available for managing and tracking the regular use of these special authorities. (see www.safestone.com) 3. Monitor the use of powerful authorities To comply with PCI organizations have to monitor the use of these powerful authorities. When a user has *SAVSYS, organizations need to know what did under this authority. 4. Lock down all three data access points Companies tend to do a pretty good job with menu security and command line access. These capabilities exist in the application and OS/400. Companies tend to fail to control access from the PC via network access (FTP, ODBC, Remote Command, etc.). If your organization doesn t do these things, it does not necessarily mean you will not pass an audit. As we saw with the large public company, they still met the auditor s requirements even though they didn t fully control powerful users access to data. As auditors become more aware of access control problems on the AS/400, they are becoming more stringent and specific on their access control requirements. But the auditor should not be the only driving force behind controlling these powerful profiles. There is a significant business driver for doing so. For example, it has been estimated by TJ Maxx that their cost of losing 46 Million credit cards is in the $250-$500 Million range. Those costs are not related to regulations; they are associated with the cost of re-issuing new cards, dealing with consumer complaints and lawsuits, etc. Lesson learned: control the access to powerful profiles or pay the price later. SAFESTONE SafestOne for User Management and Compliance on the System i Page 11 of 11