This is a corporate New Year's resolution you can't afford to break.

Written by Robin Tatam

The champagne corks, confetti, and party favors have all been swept up and discarded, marking the demise of yet another busy year. Now it's time to refocus and regroup with new personal and professional resolutions. While weight loss and smoking cessation are typical personal goals, security and compliance continue to be top corporate initiatives—and with good reason. The yet-to-be-released 2011 PowerTech "State of IBM i Security" study continues to report inadequate security controls among a rising tide of regulations and security violations.

Find out why security officers represent your greatest security threat.

Written by Robin Tatam

OK, I know that the title of this article is probably going to upset some people. After all, I'm a professional security officer and make a good living helping customers secure application environments from both external attacks and "inquisitive" end users. So why would I be so willing to throw my own profession under the proverbial bus? It's actually quite simple. I truly believe that the security officer (SO) represents the biggest threat to many shops. To make matters worse, I will extend my definition of SO to include programmers and system administrators.

PowerTech's annual "State of IBM i Security" study tells a scary story.

Written by Robin Tatam

Back in the dark shadows of days of old, strong security controls provided a ring of protection around IBM i information. While the majority of these controls date back to a time when the server was still known as the AS/400, it's scary how many shops still aren't using them.

PowerTech Compliance Monitor includes centralized compressed storage for audit journal events from multiple partitions.

Written by Robin Tatam

According to PowerTech's "State of IBM i Security" study, approximately 20 percent of enterprises aren't performing any system, user, or object auditing. When you factor in those that are capturing only a few event types, those that don't do anything with the data once it is captured, and those that are using the event data for high availability purposes rather than security, you end up with a river of events flowing through the cracks, completely unnoticed.

Thanks to the new DBGENCKEY parameter, you can now debug your customers' code while protecting your source.

Written by Gina Whitney

If you stop and think about what some of your most important assets to your company are, your source code would most likely be on that list. Protecting your code is essential. Unfortunately, there are times when one of your customers encounters a problem. The easiest way to figure out the problem would be to put a debuggable version of your code onto the system. But now, your code isn't protected anymore. So you either expose your code or figure out another way to diagnose the problem. Wouldn't it be nice to just ship a debuggable version of your code and have it secure? In 7.1, the ILE compilers (RPG, COBOL, CL, C, and C++) and precompilers have a new parameter that allows you to encrypt your debug views. This means that you can ship debuggable code and know that your code is not exposed.

PowerTech Network Security 6 provides object-level support.

Written by Robin Tatam

I recently blogged about the new features in PowerTech's Network Security Version 6. In response, I got several questions about what's "new" in the new version. So here's a quick overview.

New password validation rules help you deploy a more effective password formation strategy.

Written by Steven C. Pitcher

In V6R1, the QPWDRULES system value was created to give you more control of how a user profile password is constructed. In the prior release, a number of different system values offered this ability (e.g., QPWDMAXLEN controlled the maximum length of a password, QPWDRQDDGT enforced that there be a digit character, etc.). Having all password rules under the hood of one system value makes things a little tidier and simplifies management of password rules, but you can still use the old system values if you wish by specifying the *PWDSYSVAL parameter on the QPWDRULES system value.

Be sure you understand the impact of a profile's user class on user capabilities.

Written by Robin Tatam

One of the security issues most frequently cited by auditors is the existence of (overly) powerful users on a system. Unfortunately, there are no hard and fast guidelines of what defines a powerful user on the IBM i platform. Too often, administrators and auditors focus almost exclusively on a profile's User Class (USRCLS) parameter.

In my opinion, a powerful user is anyone who can operate outside the confines of an application.