Guru: Would You Rather See a Fire Marshal or a Fire Fighter?
February 28, 2022 Bruce Bading
While there are similarities between the two, a fire marshal has a preventive role and focus on preventing fire, whereas a fire fighter has a reactive role and focuses on the putting out the smoldering ruins.
When it comes to your firm’s cybersecurity practices, would you consider yourselves to be proactive or reactive (Fire Marshal or Fire Fighter)? The biggest difference between the two is your level of vulnerability when an attack does happen.
There are ongoing practices that you can do to reduce your risk. One thing that we recommend is included in every proactive cybersecurity strategy is a regular security/risk assessment.
Unless you can measure the current compromise state of your network, your cybersecurity risk profile is incomplete. And this is true for every system including the IBM i.
First, a very common misconception of the IBM i is that it cannot be infected with malware. The NIST Glossary is a generally accepted definition and defines malware as: Software or firmware intended to perform an unauthorized process that will have adverse impact on the confidentiality, integrity, and availability (the so-called CIA triad) of an information system.
Now let’s look at the IBM i Security Reference section on Restoring Programs. Restoring programs to your system that are obtained from an unknown source poses a security exposure. This topic provides information about the factors that should be taken into consideration when restoring programs.
Programs might perform operations that break your security requirements. Of particular concern are programs that contain restricted instructions, programs that adopt their owner authority, and programs that have been tampered with. This includes object types *PGM, *SRVPGM, *MODULE, and *CRQD. You can use the QVFYOBJRST, QFRCCVNRST, and QALWOBJRST system values to prevent these object types from being restored to your system.
Note the similarities to the NIST definition of malware. The three restore system values mentioned are, in effect, your malware protection and are one small part of your IBM i security strategy.
There are many more things that can affect the CIA triad of your system and in effect, you can’t defend what you don’t know. Do you know who is sharing those default passwords that allow anonymous access? Do you know who is using (*USE authority) those *PUBLIC and privately authorized profiles? Do you know how those adopted authority programs are being used? Do you know how those privileged Special Authorities may be abused. Do you know who is using elevated root privileges through DDM and other services if they don’t require a password and much more.
For instance, every compliance requirement has a reference to PoLP or the Principle of Least Privilege. NIST has more on this, but simply, if the job role of your users is to run their own jobs and processes, *JOBCTL which gives control of all jobs including other user and even system jobs, then *JOBCTL is not commensurate with PoLP and lead to misuse of system resources and affect that CIA triad.
One final quote from the NIST framework sums it up. Similar to financial and reputational risks, cybersecurity risk affects a company’s bottom line. It can drive up costs and affect revenue. It can harm an organization’s ability to innovate and to gain and maintain customers. Cybersecurity can be an important and amplifying component of an organization’s overall risk management.
All the years I worked in Rochester Lab Services, we responded to several data breaches and have also since I retired in 2017 to form BFB Security, an IBM Business Partner specializing in IBM i Security.
So ask yourself this now, as threats are rising all around your systems: Would you rather see a Fire Marshal to prevent a breach or a Fire Fighter to respond to a breach?
Bruce Bading is a senior security consultant with more than forty years of information security experience and 25 years of corporate c-suite experience. He is an expert on IBM i security and has helped some of IBM’s largest clients meet their security and compliance requirements in today’s complex technology and business environments. Bruce has exceptional communications skills, has worked with diverse audiences at all business levels to provide training and education and has led dozens of large enterprise risk management projects for the world’s largest organizations. He is a member of the Information Systems Audit and Control Association, a CIS benchmark author, and professional threat hunter.
Editor’s Note: Bruce is one of a number of new Guru experts that we are working with to keep the Guru column going within The Four Hundred. We look forward to the coming in-depth security coverage that Bruce can give as you work to secure your IBM i platforms in these interesting times.
We must distinguish between security risk there though…
One thing is subverting a system having/stealing admin credentials, using unsecured default password, poor security design of implementer, the possibility to install programs; another whole thing is subverting the security provisions in the software itself due to bugs, unexpected conditions, buffer overflows etc. allowing an unauthenticated attacker to exploit the system (unauthenticated remote exploit, see for example the recent log4j bug)… this should be the major concern of the analysis… were major *bugs* in the *core* OS of i itself that allows to circumvent security?
There will be much more to come. In cybersecurity and GRC, vulnerabilities lead to threats and threats lead to the risk of a breach that can damage the financial and business reputation. Access to special authorities should be limited to administrative accounts, that will be a whole separate guru article. Of course unauthenticated attackers can exploit through published CVEs, many of which do affect the IBM i such as log4j. Access to a public or privately authorized profile that has elevated privileges or access to a database that a user would not normally have access to present a threat that can lead to risk. Thus there are vulnerabilities not only in CVEs on open source and system values such as SSLV3 or TLS1.1 and below, but also threats rising from lack of a data classification and privilege access control. So let’s say that cybersecurity is not easy and that a vulnerability assessment can uncover all sorts of vulnerabilities/threats that lead to risk from log4j all the way up to services not requiring a password and *ALLOBJ and much in between.