If not, why not? Learn key factors to include when creating an IBM i security policy.

Have you ever attended a concert and only stayed for the opening act? Cooked a bacon and egg breakfast without the bacon? Watched a 3D movie without the glasses? It’s akin to creating a security policy without including your mission-critical IBM i servers… somewhat, but infinitely less consequential.

Creating a corporate security policy without including IBM i can lead to a false sense of security and result in severe consequences. A massive piece of the picture is missing, and the stakes are quite high. Yet, I see it time and time again. The IBM i is frequently neglected in corporate security policy. The explanation for not including systems running core business applications that contain highly valuable, sensitive data usually goes something to the tune of, “We didn’t know what to do with it, so we left it out.” And I try to contain myself. However, as they say, the struggle is real, so my purpose here is to draw attention to the necessity of and the key factors that should be included in an IBM i security policy.

With the objective of reducing risk by protecting the confidentiality, integrity, and availability of your data and systems, let’s discuss some components considered critical to implementing a solid security policy for your IBM i.

Technical Controls

Technical controls are items on the system that can be evaluated programmatically for compliance. For example, checking how a system value is set or determining the number of user profiles with *ALLOBJ special authority on the system. The technical controls will contain your most IBM i-specific security-related information.

Four main areas:

1)    System Configuration - things like system value settings and auditing setup

2)    User Profiles - how user profiles are configured, actions taken on user profiles, and user activity

3)    Resources - object authorities/data permissions

4)    Network - remote server configuration and incoming traffic to the IBM i from any type of remote access

For each of these areas, the technical controls essential to your policy should be defined and documented, along with the desired configuration to secure each control and the methods for monitoring compliance with the specified parameters.

Compliance Regulations

Numerous compliance regulations may apply to your IBM i and need to be considered in your security policy, depending on factors such as industry type, payment processing methods, countries where you conduct business, types of companies with which you do business, and types of data stored on your system, among others. The weight of regulatory compliance also comes with the risk of penalties and fines for non-compliance.

Compliance with any regulation begins with understanding the types of data that reside on your server, specifically any sensitive information, including data that personally identifies an individual, health-related details of a person, financial data, and credit card information.

Sample compliance regulations to consider:

• Payment Card Industry Data Security Standard (PCI DSS) - applies to companies that process, store, or transmit credit card data; different levels of compliance reporting apply based on transaction volume
• Health Insurance Portability and Accountability Act (HIPAA) - protects the security and privacy of health data
• Federal Information Security Management Act (FISMA) - heightened security measures relevant to U.S. federal agencies
• Sarbanes-Oxley (SOX) - publicly traded companies in the U.S. are required to be SOX compliant; aims to deter fraudulent activity and holds executive management more liable for inaccurate financial data
• Canadian SOX/Bill 198 (CSOX) - Canadian legislation similar to the U.S. SOX regulation
• Gramm-Leach-Bliley Act (GLBA) - for financial institutions to protect information from foreseeable threats in security and data integrity
• UK Data Protection Act (DPA) - focuses on data privacy in the UK
• Standards Australia - standards related to information technology security techniques
• ISO 27002 - information security standard published by the International Organization for Standardization (ISO)
• GDPR - the General Data Protection Regulation regarding data protection and privacy in Europe, applies to all organizations that offer goods or services to people in the EU

Cybersecurity Insurance Requirements

When a company invests in cybersecurity insurance, which can provide financial relief in the event of a security breach, there are typically specific requirements that must be met to obtain the insurance. Being able to exhibit a strong security posture is crucial for obtaining cybersecurity insurance and proving a diligent security program was in place in the event of a claim.

Server Inventory

Defining the environment applicable to your security policy is critical. The number and types of servers, LPARs, their owners, and the relevant data owners should all be documented and kept up to date. All production, disaster recovery (DR), development, and test servers should be included.

Application Details

Likewise, an inventory of all internal and third-party applications in use on each system should be documented. The inventory should include details such as the application name, version, owner, and the libraries and IFS paths used by the application.

User Roles and Responsibilities

Defining the roles and responsibilities of your users sets guidelines for what is expected of them, as well as user provisioning information. Evaluate the types of users on your IBM i and within your organization (who may be critical to your security policy but do not have direct IBM i access) and map out a list of job functions with the minimum required authorities and library access needed to perform each function.

Physical Security

With a significant focus on protecting against online external cybersecurity threats, such as phishing attacks, software vulnerabilities, and RDP attacks, it is essential not to overlook the basics of protecting the physical security of your machines. Servers should be located in a locked room with access restricted to authorized personnel, and proper protocols documented to define how physical access to the servers is managed.

Data Retention, Recovery, and Backup

Determine the data retention standards established by applicable regulations, government agencies, and/or corporate requirements. Backup procedures should be implemented to regularly save most data and system objects. Backups should also be stored in a secure location.

A data retention policy should establish what data is kept, for how long, and where the data is stored. Data maintenance procedures should be established to govern data usage and size.

In certain incidents, such as disk failure or a ransomware attack, you may need to restore from a well-established backup. Procedures testing simulated recovery scenarios should be performed on a regular basis.

Incident Response

Document types of potential security events and the procedures to be taken if such an event were to occur. (Ex: security breach, suspected network penetration attack) Include things like the severity, mitigation steps, reporting procedures within the company, reporting procedures to external entities, etc.

Due to the critical nature of ransomware attacks and the need for immediate response times, it is beneficial to have a specialized plan in place to prepare for such events. It is essential to discuss with stakeholders within your organization matters such as whether your company has a no-pay policy regarding ransom demands.

Incremental Progress

Security policies don’t have to be developed overnight. The key criteria is to START. Once you have a document in place, you can revise it as necessary. It is expected that a security policy will evolve over time. New applications will be installed, new cyber threats will emerge, and technology will change. Continually evaluate: What is essential? Where is sensitive data stored? What poses a risk of being compromised by external threat factors? To internal threat factors? Consider the implications of the system, data, and/or applications being unavailable, corrupted, or leaked. Often, when you pose the what-if scenario, it becomes easier to see what is truly important to protect.

Once in place, it is recommended that you review and update your security policy at least annually to accommodate changes in your IT environment and evolving threat landscape.

Once you have a security policy, you have a roadmap. You have a plan. How you then achieve your desired security posture becomes more apparent. If you have the necessary resources and skill sets in-house, you can implement security internally. If not, you can consider using your security policy to enlist the help of third-party vendors or software applications. With a security policy in place, directing the work becomes much easier, and the benefits are well worth it.