2017 State of IBM i Security Study

 

By using the free security scan Helpsystems executed the annual security study over a various set of 332 companies servers. The results show a series of weakness over seven critical areas:

– Server-level security controls
– Profile and password settings
– Administrative capabilities
– Network-initiated commands and data access
– Public accessibility to corporate data
– System event auditing
– Virus scanning

We will examine step by step the single areas, suggesting better solutions.

For the complete study consult the link: https://www.helpsystems.com/resources/guides/state-ibm-i-security-study

 

A) Setting the Tone: Basic System Security Levels

1) QSECURITY Level

The system security level (QSECURITY) sets the overall tone. IBM recommends and ships security level 40 as the minimun. The different levels of security are:

Level 10 — No Security. No password required. User IDs are created for any user who attempts to sign on. IBM no longer supports level 10.
Level 20 — Password Security. Every user must have a valid ID and password. Every user with a valid ID and password assumes root-level authority (*ALLOBJ) by default.
Level 30 — Resource Security. Object-level authority is enforced as users do not assume root-level authority by default. A moderately knowledgeable programmer or operator can bypass resource-level security and assume root-level authority.
Level 40 — Operating System Security. Level 30 protection plus additional operating system integrity. It is possible for an extremely knowledgeable programmer with access to your system to elevate his or her level of authority, possibly as high as root-level authority.
Level 50 — Enhanced Operating System Security. Level 40 protection plus enhanced operating system integrity. A properly secured system at security level 50 is the best defense. However, even at level 50, other system configuration issues must be addressed.

This study shows 19 % of servers fail the minimum level required.

2) Key System Values for Restoring Objects

System values related to object restoration often remain at their shipped levels, reflecting a typical IBM i configuration of “load and go.”

– Verify Object on Restore (QVFYOBJRST)—63 percent of servers are running below the recommended level of 3. This value, preset at level 1, controls whether a signature will be validated when a digitally signed object is restored.
– Force Conversion on Restore (QFRCCVNRST)—96 percent of servers are running below the recommended level of 3. This value, preset at level 1, controls whether some types of objects are converted during a restore.
– Allow Object Restore (QALWOBJRST)—Only twenty servers had altered this system value from its default *ALL setting. This value controls whether programs with certain security attributes, such as system-state and authority adoption, can be restored.

 

B) Users with Superpowers

Special authorities often expose companies to a security risk, so it’s recommended to limit the users who have special rights. In most cases corruption data are originated by employee within the organization.

 

C) Faulty Passwords and Profile Security

User and password are very important in this analysis because they represent the most used method to compromise your system. How can you be sure that user signed on is the same user that the ID and pwd were assigned too? Follow these simple rules:

inactive profiles

Profile not used after 30 and more days create a security exposure that you should eliminate, when possible. You should establish a standard process to eliminate inactive profile after a certain number of days.

The Open Secret of Default Passwords

When a new profile is created the password is set with the user name, opening an high risk access to the hackers.On the other hands often many companies create the user password combining first name initial and surname, often easy to be discovered.
The solution is create a password policy that requires the use of more characters (at least 7) by using special rules as the following.

Capitalizing on Other Password Settings

Adding to the password length it’s more sure to add complexity by using few rules. IBM i introduced in V6.1 a new system value QPWDRULES, able to define password policy in different ways. For example note the value:

*LMTPRFNAME
The uppercase password value can not contain the Complete user profile in consecutive positions.

*MIXCASEn
Whee n is a number between 0 and 9. The password must contain at least n uppercase letters and n lowercase letters…….

*REQANY3
The password must contain characters included in at least three of the following four fonts:
– capital letters
– lowercase letters
– figures
– special characters

…..

But QPWDRULES has a lot of values to be used for security.

Another important security parameter in V6.1 is QPWDCHGBLK, that restricts the frequency with users can voluntarily request a password change. It’s recommended to use the value of 24 hours.

Forgotten Passwords and Other Invalid Sign-On Attempts

Users with a lot of invalid sign-on attempts must be tracked because this is the sign of a possible intrusion.To protect your system, make sure profiles are disabled by default after the maximum allowed sign-on attempts is exceeded.

It’s not enough disable the device but you must disable the user profile.

D) Data Access Goes *Public

On non-IBM i servers, users who are not granted permission to an object or task typically have no authority. With IBM i, this is not the case. Every object has a default permission that is applicable to non-named users, known collectively as *PUBLIC. Administrators need to control access to IBM i data granting where possible authority to objects: they could use level *USE, *ALL, *EXCLUDE, *CHANGE, *SYSVAL.

 

E) Through the Networks’ Back Doors
IBM has extended the power of IBM i by adding tools that allow data to be accessed from other platform.
Services as FTP, ODBC, JDBC and DDM are active and ready to send data across the network. This could cause an exposition of the server to the attacks.To reduce this serious exposure, IBM provides interfaces known as exit points that allow administrators to secure their systems. An exit program attached to an exit point can monitor and restrict network access to the system. An exit program should have two main functions: to audit access requests and to provide access control that augments IBM i object-level security.

F) Users Crossing the Command Line
This is a traditional way to control user access by limiting the use of the command line.

G) Straying from the Audit Trail
One of the significant security features of IBM i is its ability to log important security-related events into a tamper-proof repository—the Security Audit Journal. This feature allows organizations to determine the source of critical security events, such as:
Who deleted this file?
Who gave this user *ALLOBJ authority

So it’s recomended to use “Security Audit Journal” to monitor violations and attack attempt: the parameter QAUDCTL must have a value different from *NONE.
Special tools could reduce the costs associated with compliance reporting.

H) Susceptible to Viruses and Malware
The IFS (Integrated File System) has the risk of host potential virally infected files. Recognizing this reality, IBM created system values and registry exit points to support native virus scanning a number of years ago. So best solution is to run native IBM i scan to protect data, such as Stand Guard Anti-virus.

Leave a Reply

Your email address will not be published. Required fields are marked *