25
Tue, Jun
3 New Articles

Building an Architecture to Ensure Compliance Throughout Your Organization

Compliance / Privacy
Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

Last month's article on architecture focused on creating an application architecture for compliance. This month, we'll take a look at the rest of the organization.

Security Policy

The response to your organization's compliance requirements is found in your organization's security policy. The policy is documentation of the organization's approval and assertion of the organization's security posture. Without a policy, there is no way to know the stance the organization has taken on various aspects of security configuration. It is also a legally binding document. Because of this, I highly recommend that your organization's security policy be reviewed by legal counsel.

There's no exact science of what a security policy should say or the areas it should cover. Some that I've seen are very extensive; some cover just the basics. However, most laws and regulations have some common requirements for an organization's security policy. Let's take a look at the security policy requirements that the Payment Card Industry (PCI) documents in its Data Security Standard as an example. To be in compliance with the PCI requirements, your organization's security policy must address the following:

  • Ways in which the organization is complying with all aspects of the Data Security Standard
  • Annual security assessments
  • Regular monitoring of the organization's systems and network security configuration for compliance
  • Appropriate use of data and the organization's other resources, such as computer equipment
  • Assignment of roles—who (the position) is responsible for each section of the policy, the policy itself, and policy enforcement
  • A formal employee security awareness training program, including education on the policy itself
  • A security incident-response plan that is invoked if a breach occurs

You can find numerous free or low-cost examples of specific sections of a security policy on the Web, including free examples from the SANS Institute, which can be downloaded and modified for your use.

System Settings and Processes

It's obvious how some requirements of the laws and regulations apply to your organization. However, some statements need to be interpreted so that you know how they apply to and what they mean for configuring operating systems, including i5/OS. For example, the PCI requirement "Maintain a security policy that addresses information security" doesn't require much interpretation; however, the requirement "Implement strong access control measures" requires interpretation to determine the exact settings that need to be implemented on each operating system.

The key is to understand the intent of the requirement. Then, it's usually not difficult to determine the actual operating system settings that must be implemented. For example, the intent of PCI is to allow access to credit card data only to those individuals whose job responsibility requires it. All others are to be denied. In i5/OS terms, this means that the *PUBLIC authority of all files containing credit card information must be set to *EXCLUDE. And if users access this data through an application, only those users with a specific job responsibility should be given the menu options that allow access to these files. This requirement also implies that the number of users having *ALLOBJ special authority be limited. (See last month's article on "Building an Architecture for Regulatory Compliance" for a discussion on the requirements for and implementation of appropriate access controls on files.)

Another intent of laws such as SOX or regulations such as the Data Security Standard is that of data integrity. Again, this requires a bit of interpretation, but in i5/OS terms, this means that QSECURITY needs to be set to level 40 or 50 and that QCRTAUT needs be set to *EXCLUDE or *USE. A note of caution: If the system values just described are not currently set to these values on your organization's systems, do not change them without first evaluating and testing the effect of changing these values.

User Profiles

Many laws and regulations refer to user profiles as user accounts. Requirements for user accounts typically include these:

  • Removal of profiles that have been inactive for 90 days
  • User accounts for each individual (no sharing of accounts)
  • No default passwords, even for vendor products or users servicing your system (this includes profiles created for IBM's use)
  • Enablement of profiles used to service the system only at the time they are needed. Once again, this includes the profile created for IBM's use, QSRV (I can't tell you how many times I've see this profile have a password that never changes "because IBM needs to know what it is when they come in to service the system"). I've also seen vendors require that a profile with *ALLOBJ special authority be enabled at all times and have a default password so they can sign on to their clients' systems and apply application fixes. Both practices are in violation of PCI and possibly other regulations.
  • Profiles with just enough authority to perform the job function—no more. That is, users are given capabilities or access to data based on their job position's "need to know." In i5/OS terms, this means that users are not given any special authorities (especially not *ALLOBJ) unless their job requires the functionality provided by the special authority.

Because users' capabilities and accesses are usually required to be reviewed at least annually, one recommendation to make this process easier is to implement role-based access. On i5/OS, that's most easily implemented through group profiles. Roles are usually defined within applications, but you can also do that at the system level. There are usually fewer roles defined at the system level than in an application. Across my i5/OS clients, I typically see some set of the following roles: security officer, system administrator, operator, programmer, programming manager, database administrator, and analysts. Once you define the roles in your organization, list the tasks each role is responsible for performing. For example, the operator role is responsible for backing up the system, responding to messages, and managing outqs. Programmers write code and debug production issues. Once the tasks are defined, list the special authorities required to perform each task as well as any private authorities or authorities to authorization lists that are required. If you assign these authorities to the group profile that represents the role and then make each user a member of the appropriate group, you have implemented role-based access. To review access levels, managers simply have to review and approve the tasks associated with each role and the users associated with each role. This is far more simple than reviewing each individual's authorities.

Passwords

User account requirements don't stop with profile configuration; they continue with the password requirements. Again, while the policy states the high-level requirement, the implementation of the architecture (policy) must be interpreted for each operating system. Here are the password requirements along with the i5/OS implementation:

  • No default passwords. Regularly run the Analyze Default Password (ANZDFTPWD) command to detect
  • No sharing of passwords
  • Minimum length. Set the QPWDMINLEN system value to 7.
  • Must contain letters and digits. Set the QPWDRQDDGT system value to 1 (or "yes").
  • Frequency that a password must be changed. Set the QPWDEXPITV to 90.
  • Frequency that a password can be repeated. Set the QPWDRQDDIF to 8, which allows passwords to be repeated after four times. However, best practices say to set this value to 1, which means that the password can be repeated after 32 other passwords are used.
  • Frequency that a user can try to remember a password before being locked out. Set the QMAXSIGN system value to 6 (best practices say 3–5) and the QMAXSGNACN to 2 or 3. The value of 2 sets the profile to STATUS(*DISABLED). The value of 3 sets the status to *DISABLED and disables the virtual device.

Logging

While many of the logging (or auditing, in i5/OS terms) requirements are fulfilled through the implementation of an application, you need to look at the logging facilities of each operating system. i5/OS has a rich set of auditing functions that allow you to monitor almost any activity. For compliance requirements, you typically have to log, at a minimum, invalid access attempts (both to the system and critical data files), changes to the system configuration, and actions taken by users with *ALLOBJ special authority. Beyond these actions, I prefer to audit a bit more so that I can be assured of being able to recreate a scenario using the audit journal as the forensic data. That means configuring two system values:

  • QAUDCTL is set to *AUDLVL and *NOQTEMP.
  • QAUDLVL is set to *AUTFAIL, *CREATE, *DELETE, *SAVRST, *SERVICE, *SECCFG and *SECRUN.

While you are often required to log the actions of individuals with *ALLOBJ, you can configure additional auditing for any user. Simply run the following command, specifying the profile and the additional actions to audit. Note: There's no need to specify actions at a user level that are already being audited at the system level.

CHGUSRAUD USRPRF(QSECOFR) AUDLVL(*CMD) 

If you are required to audit the use of a specific object (such as a file containing electronic protected healthcare information), add *OBJAUD to the QAUDCTL system value and run the following command, specifying the object to be audited:

CHGOBJAUD OBJ(LIBNAME/FILENAME) OBJAUD(*ALL) 

Note: If you have to audit an IFS object, use the Change Audit (CHGAUD) command.

Save It

Laws and regulations often affect how your organization backs up its data. To be in compliance with many regulations, a well-thought-out save strategy is required. The financial industry has requirements that data and transactions be saved for seven years. Yet the credit card industry encourages organizations to save credit card information for as little time as possible. A financial organization has to follow the laws and regulations for its industry and be prepared to explain to a PCI auditor how it has determined the length of time to retain its data. In addition to the length of time backups are retained, you may reconsider how data is saved. For example, to ensure that you can recover the audit logs easily and to ensure they are retained for a sufficient period of time, you may want to save those on separate media from the rest of your data. Finally, if you choose to encrypt your data either before it's saved or during the save process, you may be exempt from most of the state breach-notification laws that require you to notify state residents if their data is lost or stolen.

In addition to a well-thought-out save strategy, laws and regulations require a documented and tested disaster recovery (DR) plan. This is not just a good practice to ensure compliance. This just makes good business sense. I've never seen a client return from a DR test without deciding to update their documentation or processes because of the information gained from the test. If you encrypt or are thinking of encrypting your backup media, don't forget to consider how this affects your DR processes. If you're using hardware to perform the encryption, it must be available at the DR site along, with the encryption keys and personnel with the authority to use them.

Best Practices

While I have focused on the security policy and i5/OS operating system requirements, laws and regulations may affect other areas of IT, such as the security settings of your network components, including firewall, router, and wireless access point configurations. Compliance requirements may demand that regular network (both wired and wireless) scans be performed and that certain connections be over encrypted sessions.

If you are overwhelmed with trying to keep up with all of the individual laws and regulations, one approach is to implement security best practices wherever possible. If you cannot implement best practices, write a business risk acceptance statement that documents why your organization cannot implement the best practice setting. Integrating security best practices into your architecture is your best chance of complying with new security laws and regulations that are being created seemingly every day.

Carol Woodbury is co-founder of SkyView Partners, Inc., a firm specializing in security policy compliance and assessment software as well as security services. Carol is the former Chief Security Architect for AS/400 for IBM in Rochester, Minnesota, and has specialized in security architecture, design, and consulting for more than 16 years. Carol speaks around the world on a variety of security topics and is coauthor of the book Experts' Guide to OS/400 and i5/OS Security

Carol Woodbury

 

Carol Woodbury is IBM i Security SME and Senior Advisor to Kisco Systems, a firm focused on providing IBM i security solutions. Carol has over 30 years’ experience with IBM i security, starting her career as Security Team Leader and Chief Engineering Manager for iSeries Security at IBM in Rochester, MN. Since leaving IBM, she has co-founded two companies: SkyView Partners and DXR Security. Her practical experience and her intimate knowledge of the system combine for a unique viewpoint and experience level that cannot be matched.

Carol is known worldwide as an author and award-winning speaker on security technology, specializing in IBM i security topics. She has written seven books on IBM i security, including her two current books, IBM i Security Administration and Compliance, 3rd Edition and Mastering IBM i Security, A Modern, Step-by-Step Approach. Carol has been named an IBM Champion since 2018 and holds her CISSP and CRISC security certifications.


MC Press books written by Carol Woodbury available now on the MC Press Bookstore.

IBM i Security Administration and Compliance: Third Edition
Don't miss the newest edition by the industry’s #1 IBM i security expert.
List Price $71.95

Now On Sale

Mastering IBM i Security Mastering IBM i Security
Get the must-have guide by the industry’s #1 security authority.
List Price $49.95

Now On Sale

BLOG COMMENTS POWERED BY DISQUS

LATEST COMMENTS

Support MC Press Online

$0.00 Raised:
$

Book Reviews

Resource Center

  • SB Profound WC 5536 Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application. You can find Part 1 here. In Part 2 of our free Node.js Webinar Series, Brian May teaches you the different tooling options available for writing code, debugging, and using Git for version control. Brian will briefly discuss the different tools available, and demonstrate his preferred setup for Node development on IBM i or any platform. Attend this webinar to learn:

  • SB Profound WP 5539More 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.

  • SB HelpSystems ROBOT Generic IBM announced the E1080 servers using the latest Power10 processor in September 2021. The most powerful processor from IBM to date, Power10 is designed to handle the demands of doing business in today’s high-tech atmosphere, including running cloud applications, supporting big data, and managing AI workloads. But what does Power10 mean for your data center? In this recorded webinar, IBMers Dan Sundt and Dylan Boday join IBM Power Champion Tom Huntington for a discussion on why Power10 technology is the right strategic investment if you run IBM i, AIX, or Linux. In this action-packed hour, Tom will share trends from the IBM i and AIX user communities while Dan and Dylan dive into the tech specs for key hardware, including:

  • Magic MarkTRY 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.

  • SB HelpSystems ROBOT GenericForms 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.

  • SB HelpSystems ROBOT GenericIT security is a top priority for businesses around the world, but most IBM i pros don’t know where to begin—and most cybersecurity experts don’t know IBM i. In this session, Robin Tatam explores the business impact of lax IBM i security, the top vulnerabilities putting IBM i at risk, and the steps you can take to protect your organization. If you’re looking to avoid unexpected downtime or corrupted data, you don’t want to miss this session.

  • SB HelpSystems ROBOT GenericCan you trust all of your users all of the time? A typical end user receives 16 malicious emails each month, but only 17 percent of these phishing campaigns are reported to IT. Once an attack is underway, most organizations won’t discover the breach until six months later. A staggering amount of damage can occur in that time. Despite these risks, 93 percent of organizations are leaving their IBM i systems vulnerable to cybercrime. In this on-demand webinar, IBM i security experts Robin Tatam and Sandi Moore will reveal:

  • FORTRA 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:

  • FORTRAManaging messages on your IBM i can be more than a full-time job if you have to do it manually. Messages need a response and resources must be monitored—often over multiple systems and across platforms. How can you be sure you won’t miss important system events? Automate your message center with the Robot Message Management Solution. Key features include:

  • FORTRAThe thought of printing, distributing, and storing iSeries reports manually may reduce you to tears. Paper and labor costs associated with report generation can spiral out of control. Mountains of paper threaten to swamp your files. Robot automates report bursting, distribution, bundling, and archiving, and offers secure, selective online report viewing. Manage your reports with the Robot Report Management Solution. Key features include:

  • FORTRAFor over 30 years, Robot has been a leader in systems management for IBM i. With batch job creation and scheduling at its core, the Robot Job Scheduling Solution reduces the opportunity for human error and helps you maintain service levels, automating even the biggest, most complex runbooks. Manage your job schedule with the Robot Job Scheduling Solution. Key features include:

  • LANSA 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.

  • LANSAWhen it comes to creating your business applications, there are hundreds of coding platforms and programming languages to choose from. These options range from very complex traditional programming languages to Low-Code platforms where sometimes no traditional coding experience is needed. Download our whitepaper, The Power of Writing Code in a Low-Code Solution, and:

  • LANSASupply Chain is becoming increasingly complex and unpredictable. From raw materials for manufacturing to food supply chains, the journey from source to production to delivery to consumers is marred with inefficiencies, manual processes, shortages, recalls, counterfeits, and scandals. In this webinar, we discuss how:

  • The MC Resource Centers bring you the widest selection of white papers, trial software, and on-demand webcasts for you to choose from. >> Review the list of White Papers, Trial Software or On-Demand Webcast at the MC Press Resource Center. >> Add the items to yru Cart and complet he checkout process and submit

  • Profound Logic Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application.

  • SB Profound WC 5536Join us for this hour-long webcast that will explore:

  • Fortra 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: