Security modernization must be a part of your overall modernization strategy.

This article continues the series that temporarily replaces my "In the Wheelhouse" column. Through the rest of this year, I'll discuss IBM's Cloud, Analytics, Mobile, Social, and Security (CAMSS) initiative. I started by addressing strategy and providing an overview.

Security is the underpinning of all the other elements of CAMSS. Joining me this week is IBM's Jeff Uehling, Architect for IBM i Security.

Steve Pitcher: Jeff, please tell me a little about what IBM has been doing in the security space, specifically for IBM i and how it relates to CAMSS.

Jeff Uehling: We've spent a lot of development money over the last number of releases making sure that the capabilities that we have in IBM i are what customers require in order to get their applications [and] networking secured, including lots of capabilities for encrypting data, managing encryption keys, and so on. If you go back to 5.4, it's probably a good place to start the discussion and look at the enhancements that we've added. You'll see many different things related to encrypting data, key management, new API support to make it easier to use key management solutions where the encryption keys could be secured by master keys. Certainly, we have both hardware and software capabilities. If you jump ahead a few releases to 7.1, a very popular enhancement was added for DB2 field encryption. Jump to 7.2 and you have row and column access control, so the investment has been significant for IBM i for many years now.

The capabilities are there in the OS, but history and studies show that many customers are not leveraging all of them by any measure. We see many instances where data is not secured adequately, not securing network applications with data flowing over the wire. It's an industry-wide issue really, not just with IBM i. There's a lot of history behind that. A lot of customers use applications that they've purchased, and if the application providers are not doing an adequate job, then the customers will have difficulty. If you look at some of the studies that are done by our business partners in the security space, you'll see the same answer that I just gave. The PowerTech group, now HelpSystems, publish a report, and if you look at the results of that study, you'll also get an answer that lines up with the answer I just gave.

SP: I had a talk with Robin Tatam at COMMON, and we've been trading some comments back and forth on a security piece I did. The 2015 study was quite alarming. The basics of system security just aren't being done, let alone being enforced, in many shops. Are we as customers not getting the message? Is education a big part of what you do?

JU: We attend many conferences, local user groups, webcasts through the year, every year to talk about security. Just at COMMON alone or rather at the spring COMMON conference, we do 25-plus sessions on security there. Not just from IBM, but for overall sessions there's about 25 security sessions. We try to spread the word as best we can. It doesn't take a lot to spread the word. There's plenty of information out there about attacks and threats. If somebody hasn't seen the need to do something about security, then they probably haven't been watching anything online. We see many reports of different companies that have been attacked and hacked. We see much information about vulnerabilities in the wild today. We've had many in the last few years that became very public like POODLE or Bar Mitzvah.

Look at OpenSSL. That's a wide-reaching open-source tool used across the industry. When a vulnerability is found, it's far-reaching. It's on Linux, AIX, or any flavor of Unix, IBM i, System z. It's everywhere.

SP: From an IBM i perspective, you're hardening the OS and components of the OS. When you see vulnerabilities like POODLE, and you want to get people up to TLS 1.2 to prevent against it, how much of that is driven by what the rest of the world is doing? How do you have your ears to the ground?

JU: We certainly have a vested interest in ensuring our customers are protected. I'll answer this from an IBM perspective, not just an IBM i perspective, because the nature of these vulnerabilities affects so much technology.

Within IBM, we have a group called the Program Security Incident Response Team, and they're hooked into all sorts of external groups. Their job, their only job, is to gather information about all these vulnerabilities. Within IBM, we have an interesting process where all the products and operating systems are alerted when a vulnerability is reported. The process alerts the owners of the products. Typically, there's a security lead that oversees that product as well. We develop the fix and get it out to the customers. That's an ongoing thing. I happen to be the lead for IBM I, so I see the vulnerabilities come in, and I work with the development groups to ensure the fixes are created in a timely fashion to make them available to customers. The back end of that whole process is notifying the customers. We have automatic notification to customers to alert them when PTFs are available, and they need to be diligent about getting those fixes and loading them when they can. It's a multi-stage process, but I can tell you firsthand there's a huge emphasis on that with IBM for all our different products.

SP: With CAMSS, we have four distinct pieces of a vehicle, with security as, from my perspective, essentially the chassis. If we're looking at other IBM products, how much cross talk is there between other product managers and your team to ensure that IBM i is up to date, not only with vulnerabilities but security enhancements? For instance, IBM Domino recently added support for TLS 1.2. I'd assume they have to make sure all the operating systems that run Domino must have that as an operating system feature first and foremost.

JU: If you look at things like Java, WebSphere Application Server, Connections, Traveler, Sametime…you mentioned Domino. Depending on the product, we may have a development team specifically for IBM i. That's the case for Java, WAS, Apache. They are all certainly hooked into the process from a vulnerability perspective. There are some standalone products that do run on IBM i. Those groups develop the fix, and if there's something that needs to happen on the IBM i side, then we're engaged to do that. It's all tied together very nicely.

SP: With regard to security modernization, I've been updating my systems to remove SSLv3 where I can. I was kind of surprised that enabling TLS 1.2 was a manual process, albeit a very simple one. A lot of customers may not be tied into developerWorks to figure that one out.

JU: From a high level, I can tell you that there's a lot of history and compatibility discussions that go on. We want people to move off SSLv3. It's an easy thing to say and a harder thing to do. We're always concerned about compatibility issues. There's a TLS 1.3 in the works. When a vulnerability comes out like SSLv3, we remove the weak ciphers where we can. We shut off SSLv3 where we can. Many applications just can't move automatically, so we give the customers the ability to get to where they should be, but we can't risk breaking something by turning on something by way of a PTF. If you're running an old operating system release, then from a security perspective, you're always best served by staying current. If you're staying on old releases, then you're going to fall behind, and that's never going to change, regardless of what operating system you use.

The other thing I want to mention are the end-to-end security problems customers may have. If you are a small IT shop and you have one or two people who manage IBM i, it's hard to step outside that role to focus on security. It's a huge problem for small customers to manage.

SP: A security professional would be ideal. Perhaps that's one of the root causes of the PowerTech study results.

JU: There's nobody around who knows everything or has the time or budget to do everything. Getting help with a compliance audit and evaluations would be an ideal starting point.

SP: I've mentioned many times that financial auditors are not IT experts. They're financial experts. They're looking for financial oddities, not necessarily IT vulnerabilities. I've never had a financial auditor ask me about cipher strength. Contracting out for a proper IT security audit once a year or every couple of years is money well spent. Using PowerTech or SkyView Partners or other qualified business partners to do security audits and recommendations is something that people need to be doing. I'd assume that IBM Lab Services has a group who can help as well.

JU: Our Lab Services can certainly do that. We have many qualified partners who do that. One of my first charts I do in security best practices sessions says that people are not masters of everything. We just can't be. Small customers would benefit greatly from having someone who does security for a living take a look at their systems.