Carol discusses how the cybersecurity law in New York will affect organizations running IBM i and how it provides guidance for organizations—even those outside of New York.

The State of New York passed a cybersecurity law that went into effect March 1, 2017. It’s one law in one state. So why should organizations outside of the control of the New York State Department of Finance be concerned about this law? Because it’s yet another indication that governments are getting serious about security.

If you think that the State of New York is an isolated case, then you haven’t heard of the EU’s General Data Protection Regulation (GDPR). Or the recently passed breach notification law in Australia.  

It’s unfortunate that governments have had to get involved and pass regulations to get organizations to pay attention to security, but sadly, that’s the case. To most organizations, data security remains an “option” rather than a default action. Many organizations don’t seem to understand that their data is a corporate asset and needs to be protected to a level that’s commensurate with the value of the data to their organization. In these organizations, security is seen only as a cost with no benefit. In these environments, data is left open to being read by individuals with no business need, or worse, modified and/or deleted—either accidentally or purposefully—by a disgruntled employee.

To me, it’s no surprise that laws such as the New York Cybersecurity Law are being passed; organizations are simply ignoring security. And because organizations are ignoring security, we—you and I—are left vulnerable. How are we left vulnerable? Organizations that don’t protect our personal data or put processes in place to detect and close vulnerabilities leave you and me open to identity fraud and identity theft. We are also at their mercy for rising costs because of their inaction. For example, our healthcare information is being sold on the dark web for health insurance fraud, raising the cost of health insurance. If every organization understood the importance of information security and implemented security best practices across their organization, businesses wouldn’t have to restore their data due to it being encrypted with ransomware, IT resources wouldn’t be diverted from their normal job assignments to clean up after a breach, organizations wouldn’t have to provide identity theft monitoring for all individuals whose data was lost or stolen, and I wouldn’t be sent a new credit card when fraudulent changes show up on my account. The cost of these activities must be borne by someone, and that “someone” is you and me.

Let’s get back to the NY cybersecurity law. Even though it’s been criticized as not being far-reaching enough, for organizations that are not currently addressing cybersecurity, I believe it’s a good place to start. Let’s take a look at the guidance we can get from this law.

Chief Information Security Officer (CISO) and Cybersecurity Personnel

The first thing I noticed as I read this law was the requirement for a CISO. This means the organization is required to hire or contract with a service provider that understands cybersecurity and can guide the implementation of a cybersecurity program. Regardless of whether the CISO is an employee or is from a service provider, the organization is responsible for the implementation of the law, meaning the organization has “skin in the game” and therefore is motivated to become compliant with and follow the law. How does this apply to IBM i shops? Organizations that have yet to address cybersecurity lack someone in upper management who has been given responsibility for security. Over the years, I’ve talked to countless IBM i administrators who understood that they needed to take action to secure their systems but couldn’t get buy-in from their management. This law addresses that gap and ensures that someone with enough authority to effect change is in place.

Another gap that this law closes is that 1) you have in-house personnel or a service provider to ensure not only complying with the law but also addressing the issues discovered during the vulnerability scans and risk assessments and 2) they remain educated and up to date on the current threats.

Security Policy

I was glad to see that this law requires a security policy. A security policy is the foundation of how an organization views security. Without that foundation, there’s nothing to compare against when a new technology is being investigated to determine whether the risk of implementation is tolerable to the organization, no classification of data, and no definition of what constitutes appropriate use of the data. No two policies are the same because they need to address the specific needs of each organization. But if you don’t have a policy, the areas listed in the law are a good starting point for generating your own policy.

Education

The next requirement that I applaud is the requirement for education. Organizations that have a policy but don’t educate their employees about the policy might as well not bother to create one. Many security incidents occur because employees aren’t educated to not click on links or attachments in email. Or they haven’t been educated on the appropriate use of sensitive data. (Remarkably, social insurance and social security numbers often appear on websites as employee or student identifiers.)

Encryption of Nonpublic Information

The definition of nonpublic information is very similar to most definitions of Personally Identifiable Information (PII), and New York’s requirement is to encrypt this information. Given the introduction of FIELDPROC functionality in V7R1, there’s really no excuse for IBM i shops to not encrypt the columns of database files that contain PII data. Gone are the days of having to rework the entire application to encrypt a column of data or to recompile the programs that touch a file that have an encrypted field. FIELDPROC can be implemented with zero programming changes. More IBM i shops need to make use of this functionality to better protect their PII data.

Another aspect of this law is that if nonpublic information is transmitted, the transmission must be encrypted. This requirement applies to both external and internal transmission of the data. I have long been an advocate of encrypting communications even in an internal network. Too many means of gathering data from an internal network exist to think that it’s unnecessary to encrypt internal communications. My recommendation is to encrypt all communications, and that thought is supported by this law.

Risk Assessments

I’ve asserted for many years that security begins with an assessment. Without an assessment that’s performed by an independent third-party organization, it’s likely that you are missing vulnerabilities that need to be addressed in your organization. I may go to a doctor when I have a sore throat, but if I don’t go for an annual physical, I may have health issues that go undetected for years…and perhaps until it’s too late. The same applies for risk assessments. They need to occur annually and by someone outside of your organization so that you’re sure that the environment is analyzed with an objective viewpoint and by someone who knows what to look for. This law doesn’t specify how often a risk assessment should occur, but best practices dictates that a risk assessment should be conducted at least annually.

Vulnerability Assessments and Penetration Testing

The New York law requires annual penetration testing and biannual vulnerability scans. If we take a page from the Payment Card Industries Data Security Standards (PCI DSS), penetration testing is to occur from both outside as well as inside the network to attempt to get at the secured data. And yes, that includes IBM i. A number of clients have contracted us to perform penetration testing for their IBM i systems. You cannot assume that the IBM i configuration that you have in place is secure, especially if you have taken no action to secure the system.

Biannual vulnerability scans are, to me, too infrequent. Again, based on the requirements of PCI DSS, I believe that vulnerability scans should be done at least quarterly. These are scans for known vulnerabilities to ensure they aren’t configured in your organization. For example, scan your web applications (both externally facing as well as internally facing) for known vulnerabilities such as cross-site scripting errors, SQL injection errors, etc.

User Access

While they don’t specifically call it this, the law also requires Role-Based Access (RBAC.) The terms they use are to limit users’ access to systems containing nonpublic information. To me, that’s RBAC. If users don’t have a business need to access the data, they shouldn’t be allowed to access the system. The law also requires that a user’s access be reviewed periodically, presumably to eliminate user access if it’s no longer needed.

Multi-Factor Authentication

Users are required to authenticate using multi-factor authentication when accessing internal systems from an external network. I would take this one step further and say that administrator access—both external and internal—should use multifactor authentication. Too many instances of intrusions due to credential thief have occurred to allow anyone with administrator capabilities to connect to a system with a simple user ID and password. In IBM i terms, this means anyone with *ALLOBJ special authority, and a good argument could be made that it should include profiles configured with *AUDIT and/or *SECADM special authorities as well.

Third-Party Service Provider Security

Many organizations outsource various parts of their business. This part of the law addresses the security policies you need to have in place for your third-party service providers. This is necessary because well-known breaches have occurred because a lack of strong security controls at a service provider resulted in access back into the organization’s network. This law requires that you have policies and procedures to analyze the risk associated with the service providers’ practices. In addition, if the service provider accesses your network, they must use multi-factor authentication (MFA), and if they have access to non-public data, that data must be encrypted both in transit and at rest.

Limits on Data Retention

I can’t tell you how many times I’ve been doing a risk assessment for an organization and I look at the libraries on the system and it’s clear that the system has libraries that date back to the Ice Age. OK, a bit of an exaggeration, but it’s rare when an organization has a practice in place to remove objects that are no longer in use or to purge records from a database file for information no longer needed by the business. Yet that’s what this law requires. I welcome this attention to the (over) retention of sensitive data.

Auditing

Auditing should be one of the foundation blocks of a good security plan, and this law speaks to that. It requires that auditing be enabled at the application layer to be able to reconstruct financial transactions. These records must be kept for a minimum of five years. In addition, it requires auditing so that you can detect and respond to events that might harm “normal operations.” The good news is that IBM i has no problem helping you implement this requirement. The absolute minimum configuration that we recommend for auditing is to set QAUDCTL to *AUDLVL and QAUDLVL to *AUTFAIL, *CREATE, *DELETE, *SECCFG, *SECRUN, *SAVRST, and *SERVICE. But additional values such as *JODBAS, *OBJMGT, and *PTFOPR (in V7R2) are also very beneficial when having to re-construct a scenario. You must retain these types of events (meaning your audit journal receivers) for no less than three years.

Application Security Reviews

I wish every organization had this requirement: to review the development process of their in-house-developed applications and to have a process to assess the security of third-party applications. I nearly jumped for joy when I read this requirement because if more IBM i shops had this requirement, then irresponsible vendors would have to stop shipping their applications configured in such a way as to put your data at risk. That, or at least provide guidance for how to secure it. Also, organizations’ developers would have to be educated on how to develop secure applications and stop ignoring security themselves. All around, a very good requirement.

Incident Response Plan

Finally, you must have a plan to respond promptly to and recover from events that affect the confidentiality, integrity, or availability of the organization’s data, systems, or business operations. I’m still surprised by the number of organizations that have no plans in place to respond to an incident—be it malware, a Distributed Denial of Service (DDos) attack, or a data breach. Organizations should assume that they are going to incur each of these types of incidences and architect their response. Attempting to respond after the incident has occurred is putting your organization at significant risk of not being able to respond quickly and appropriately enough to be able to not cause significant outages and loss to the business.

What Organizations Must Comply with the NY Cybersecurity Law?

One might assume that only banks, insurance companies, and other financial institutions residing in New York must comply with this law, but that’s not necessarily the case. The “covered entities” of this law (that is, the people to whom this law applies) is defined as “any Person operating under or required to operate under a license, registration, charter, certificate, permit, accreditation or similar authorization under the Banking Law, the Insurance Law or the Financial Services Law.” This means that organizations may be headquartered in another state, but if they’re required to be licensed in the state of New York, they’ll have to comply with this law.

There are exceptions, however. Organizations with fewer than 10 employees, less than $5 million in gross annual revenue, and less than $10 million in year-end total assets are except from this law.

Summary

I believe that New York is just the first state to pass a cybersecurity law. California usually leads this type of legislation, so it would be surprising if they didn’t quickly pass their own cybersecurity law. And if organizations don’t start to get more serious about addressing data security, look for countries to pass laws to reduce the risk to their financial institutions as well as healthcare facilities and critical infrastructures such as utilities and transportation.