Carol provides three questions you'll need to answer to get you started on your journey toward a more secure IBM i system.
The realization hits that you need to do something about the security configuration on your IBM i, but you don't know where to start.
The good news is that I'm talking to more organizations that want to do something about their IBM i security settings. The bad news is that many organizations don't know where to start. And I really shouldn't classify it as "bad news." I think the better characterization is frustration. In this article, I pose questions to help you get past the frustration and help you get started.
What Type of Data Is Stored on Your System?
The first question I ask when helping organizations get started is, "What type of data do you store on your system?" And by that I mean, do you store credit card numbers or HIPAA (healthcare) information or other data that may be regulated by specific laws or regulations? If you do, then we can look at the various laws and regulations that govern that data and start to make a plan to implement those requirements.
What many organizations forget to consider is data that's covered by the various federal, state, Canadian, or European breach-notification laws. This data is any kind of Personally Identifiable Information (PII), which includes data such as social security numbers (SSNs), social insurance numbers (SIN in Canada and Europe), bank account numbers, driver's license numbers, and more. California often leads the way in defining new laws, and they have consistently been the leader in defining what constitutes PII data. They recently changed the law so that an email address is classified as PII data if both the email address and the answers to the "I forgot my password questions" are stored together and both lost.
Europe has quite strict privacy laws about who can see private data and how (for what purpose) it can be used. The European courts recently struck down the Safe Harbor Principles associated with the EU Data Protection Directive, which granted exceptions to U.S.-based companies' use of Europeans' private data. The ramifications to U.S.-based companies that do business in Europe is yet to be seen. My point is, don't assume that you don't have PII data. Before you assert that's the case, you'll need to do some research into the current definition of PII data and its allowed uses.
What About Your Company-Specific Data?
The next consideration to make is what data you store on your IBM i system that is company-specific. For example, many organizations have customer lists on their IBM i systems. These lists are often highly confidential. If that data was sold to a competitor, it would be very damaging to the organization. Others have inventory information. While they may not want the information to get into the hands of their competitors, it wouldn't put them out of business.
In answering my question, what you need to think about is the information stored on your IBM i that is unique to your organization and what the impact will be if that data is lost, stolen, or unavailable.
What Is Your Goal for Securing Your Information?
If you have data that falls under some law or regulation, then the answer to this question is easy: follow the requirements of the law or regulation. But if the data is company-specific, the answer may not be obvious. Let's look at the examples I used previously. In the case of the customer list, this is very confidential information and if it were sold to a competitor it could be catastrophic to the organization. In this case, you want to make sure that only approved individuals can access this information. However, in the case of inventory levels, your main concern is to make sure the data is accurate. So in this case, you may not care who sees the data, but you want to make sure that it is updated only through the appropriate application interfaces.
Now that you've thought through what data you have stored on your IBM i and you've defined your organization's goals, you can start thinking about the specific changes required to get you from your current configuration to a configuration that meets your organization's requirements.