Glad to have you back for this week's IBM i Pulse! Each week we'll take a deeper look at the latest IBM i and Profound Logic news. This week we are looking at an interview with the new IBM i Security Architect for IBM and five security vulnerabilities to look out for.
From Our Experts:
- Ted Holt shows you how to Use SQL to Generate Random Data in his latest IT Jungle article.
Profound Logic News:
- Profound Logic's newest software NodeRun shows how NodeRun is Node.js for Everyone in this IT Jungle article.
Educational Resources:
- Learn how easy it is to Debug Your CSS Styles in Profound UI.
- The Secret to Building Great Node.js Apps is unveiled in this Profound.js video.
Product News:
- Version 6 Fix Pack 3.3 for Profound UI has now been published with some great updates.
Industry News:
Meet IBM's New Security Architect for IBM i by Alex Woodie
Security is a fundamental concept and feature of the IBM i operating system. With over 120,000 organizations around the world using the IBM i, creating a secure platform is still one of the top priorities for the IBM i team at the IBM Rochester lab. The Security Architect is the central figure in maintaining and expanding the security of the IBM i and the newest person to hold that title is promoted software engineer Timothy Mullenbach. IT Jungle caught up with Timothy at this year's POWERUp conference to discuss two significant security features added to 7.4; the new object-level view of authority levels in the Authority Collection, and support for TLS 1.3.
"I think you're going to see the pickup in the market a lot faster than we had with TLS 1.2. There's just so much more focus from the security standards board that they're going to drive TLS 1.3 into those requirements sooner than ever before."
"When you are active-active, you can bring one down and apply the PTFs and bring it back up. I see that as another way for our customer to put security PTFs on faster so that they don't have to wait so long."
"I would say in my 20-plus years of paying attention, that you're having a lot more people actually paying attention and caring about security. If you go back 15 or 20 years, they didn't care what TLS protocol version they were running. They probably weren't even running encryption. They were running unsecure Telnet, or things like that. Some of those named vulnerabilities in the last five-plus years have a lot of different people paying attention that weren't paying attention before."
Top Five Misconfigurations That Leave Your IBM i Vulnerable by Carol Woodbury
Most security breaches can be attributed to "misconfiguration" of your IBM i system, and those misconfigurations can come in many different forms. Some organizations set things like system values, user profiles, and object authorities to specific values that match security best practices but fail to monitor those values as they change. There are several reasons a system value might change: vendor product installation, object authorities can be modified to accommodate user requests, a programmer assigned *ALLOBJ special authority for a short-term project that never got removed, etc.
Some companies ignore the proper security protocols and do what they feel is necessary to make administration easy. This means making configuration decisions based upon ease of use instead of security. Here are Carol's top five examples of misconfigurations that make your system vulnerable.
Vulnerability #1: Sharing root (/) - "Sharing root shares the entire system, not just the directories. So even a read-only share exposes all aspects of the system to being viewed by users who don’t have a job responsibility to do so."
Vulnerability #2: Running at the Wrong Security Level - "IBM i has shipped at QSECURITY level 40 for many releases now, but we still encounter systems that are running at security level 30 and some at 20."
Vulnerability #3: Default and Other Weak Passwords - "Allowing default passwords is an open door for anyone to try to access your system. All hackers know that a default password on IBM i is the same as the profile name. So that’s the password they’ll try."
Vulnerability #4: Unencrypted Communications - "If someone infiltrates your network or an insider “turns” and has a desire to harm your organization, leaving communications in clear text rather than implementing encrypted sessions (using TLS) allows the communications to be read, including user ids and passwords."
Vulnerability #5: Continuing to Think That “Menu Security” Is Sufficient to Protect Data - "Organizations claiming that they don’t need to do anything more to protect their data because their users can only access data through menus."
----------------------------------------------------------------------------------------------------------------------------------------------
