Regardless of how much effort we expend to plan for “unexpected” events, sometimes things happen that are simply out of our control. Last week in Seattle, for example, a failed network component at the local communication service provider’s data center forced a temporary outage of our voice and data lines at our technical support center. Fortunately, having multiple locations means we could do some creative magic and reroute our callers to different offices. This ensured that anyone looking for help could still talk to a live person; something that Help/Systems companies take pride in.

Although the outage was sporadic, it did mean that our call handlers sometimes had to seek other people when they couldn’t forward the call to a technical support employee. Rather than simply take call-back information, I fielded one of the calls myself, and I am extremely glad that I did. It came from a large customer located in Niagara Falls, NY, who initially was a little surprised that a director was answering level 1 support calls (perhaps their surprise was less about my title than the concern of a “pencil pusher” trying to help them!). I explained that the support team was not available, but that I was interested in knowing what their question was, and that I would do my best to address it for them, or escalate it as soon as Seattle came back online. As we worked through some troubleshooting steps, it gave me a great opportunity to visit with them.

I was very happy to hear that they are “huge fans” of the PowerTech security solutions, and frequent listeners of my weekly educational Webinars, but especially proud of how complimentary they were of the support team that they (normally) talk to if they call in. Regardless of whether they had an actual technical issue, or they were simply looking for advice or assistance on how best to utilize the solutions to secure their numerous systems, I was told that the support they had received had always been first class.

I started thinking about how quality technical support can make an enormous difference in a customer relationship. It doesn’t matter how good a solutions is, if at the end of the day the solution is not well supported. I think everyone at one point has purchased a product or service, and found that they had a question about its use, or needed some assistance with it. The instant a phone call is made to the vendor’s support number, there is a “Y” in the road that says whether it will actually increase the customers’ level of satisfaction, or make them question their purchase. In fact, I remember hearing a tale of a cellular phone company that deliberately provided a number of their customers with phones that were not working. This was done as an experiment to see if the way that the support calls were handled would have an impact on a customer’s perception of the company. Interestingly, the level of satisfaction after the issue was handled promptly and courteously was recorded as higher than even those customers who had received a working phone from the start! That is a powerful statement of the impact that good support can have.

Of course, PowerTech does not provide solutions that will deliberately cause issues to customers, but we do have the type of support response that gets praised frequently. That is good for the customer and good for our business. From my perspective, I wish to send my thanks to the members of the PowerTech support team, and also the professional services team that—based on the satisfaction surveys that pass my desk—do an equally superb job at making PowerTech look good. It takes a lot of patience and skill to help customers in a way that makes them thankful for calling.

I am going to be in Buffalo, NY, in February (for some reason, everyone laughs when I say that) to speak at a local user group, and to host a half-day IBM i security class. During that trip, I have arranged to stop by and visit with this particular customer. I want to thank them for their business, and also to have some discussion about how they use the PowerTech products. It is invaluable to us to hear customer insight about what security and compliance issues are important to them in their business, as well as features they would like to see us include in an upcoming release of one of our products. I think it makes us more of a security company than a software company.

Oh, and in case you were wondering, I was able to resolve the question that the customer had called in about. My single call may pale in comparison with the volume of questions that the professionals in Seattle typically handle, but at least I can hold my head up high in the break room!

Watch for an upcoming blog and PowerNews newsletter interview with a member of our (real) support team.

I guess it is a sign of my age that the years seem to slide past faster nowadays. It is staggering to think that it is the start of yet another decade, and ten years ago the I.T. industry just got done holding its collective breath for Y2K—a computing event that many thought would be cataclysmic. While no disaster ever materialized, it did help to point out how technology-dependent we have all become in our businesses and in our personal lives.

Security should be considered the new Y2K as it demands the attention of every citizen in every country, and has the potential of bringing us to our computing knees. While the year 2000 came and went without major incident, barely a day goes by that another breach doesn’t occur, or someone pays the price of one. We have seen an increasing barrage of attacks come from every direction, from every country, and via every form of communication. And even some “legitimate” businesses have turned out to be the culprit, and their actions have resulted in a new requirement for yet another regulation or legislation (think Sarbanes-Oxley). As someone who works in this industry full-time, I only see this continuing to worsen as cyber-criminals become more sophisticated and well-funded.

So as we embark on the ride into the next decade, I really hope that the vulnerabilities that I see every day are seriously contemplated and then addressed. For that to happen, it is critical that management gives the necessary consideration to their I.T. budget to help protect the very assets that their business survives on. This is true even in a tepid economy as employees fear for their jobs, and those that remain have to perform even more responsibilities. “ROSI” is an industry term, meaning “Return On Security Investment,” and although it might be calculated slightly differently from the more traditional “ROI,” there is a return nonetheless. One of the returns is that your business stays IN business—a pretty significant return, and something that should get the attention of your corporate management.

The good news is that many of us continue to run our core businesses applications on IBM i. While it does not come pre-configured as an overly secure environment, it has the ability—with a little help from your friends at PowerTech—to be one of the most secure servers available today. The features that are built in to the operating system all work together as a tightly integrated ring of protection around the data. And our popular software provides additional tools to make the life of the security officer more productive, and your data more secure.

So, as we start another new year and a new decade, resolve to finally take the steps you know you need to take to get your server in shape. If you don’t, it might mean more than your system just gaining a few extra holiday pounds!

Happy New Year, everyone!

It is amazing to me that another year is already coming to an end. With the mad dash of last minute shoppers (yes, that would be me this year!), and the certainty of a white Christmas for us in much of the Midwest, it is definitely going out with a bang. In fact, although Winter officially began yesterday, the readers of this blog will know that we have been feeling it in Minneapolis for several weeks. December 21st is marked as Winter Solstice—the shortest day of the year due to the Earth’s tilt—so the good news is that summer is on its way. Ok, so I’m an eternal optimist!

In the spirit of the season, I thought I would create a last-minute holiday wish-list for the security officers that made Santa’s “good” list:

Perform an assessment

This is a good way to get the baseline metrics reviewed; identify the areas of weakness and strength so you can focus your resources where they are needed.

This one is a stocking stuffer, as PowerTech does it for free!

Create a policy

It is hard to measure your progress without a policy. You can even start with the open-source one at www.powertech.com!

Update your system values

Make sure that the server configuration reflects the directives in your security policy. After you set the correct attributes, use the policy feature of PowerTech Compliance Monitor to validate that nothing has changed with scorecard views of system value compliance.

Secure Your Borders

Internal employees are the cause of approximately 70% of data integrity events. Ensure that you don’t secure just your perimeter and leave corporate users with unrestricted network access. Any user with access to your servers should be audited and controlled. PowerTech’s Network Security provides both auditing and access control of powerful interfaces like FTP, ODBC, and remote command.

Don’t overlook your powerful users

Sure, we expect our programmers and administrators to run and maintain a system, but would we want them to have our social security numbers, bank balances, and the “skeleton key” to our corporate data? Try to reduce unnecessary assignment of special authorities, and then use a tool like PowerTech Authority Broker to facilitate on-demand access to super-users while auditing their activities.

Educate your staff

PowerTech conducts weekly online Webinars, as well as eTraining. In 2010, we are also taking some classes out on the road. Registration for the eTraining will open shortly at www.powertech.com. Get on our newsletter list while you are there and stay informed of events, as well as related security news and articles specific to IBM i.

We know that taking that first step can sometimes be a daunting one. If you are not sure how to get started, allow our team here to guide your compliance sleigh! After all, we have being doing it for years.

Happy Holidays!!

Well, it may have held off slightly longer than normal, but we knew it would just be a matter of time. This past week my home state of Iowa was pummeled with ice, snow, and bitterly cold temperatures. Although my weekly trek between Des Moines and Minneapolis was delayed by a day, it didn’t take too long for the hard-working road crews to get the highway infrastructure moving again.

Although I have survived my fair share of Midwest winter storms over the years, it struck me how there is similarity between how winter storm contingencies are planned for and how enterprise security should be handled.

In a computing environment, it’s important to perform what is known as “data classification.” This is where data is identified by its criticality to the organization. Data that is public, easily recreated, or has less intrinsic value to the organization (perhaps historical information) typically has less importance than data that would be costly if it were damaged or breached. Most organizations have limited resources (funding, security staff, etc.) and so the more important data gets prioritized first.

This classification is also necessary for our city planners. Obviously, with limited snow removal equipment and plow drivers, there is no way that every road can be cleared simultaneously. Routes are classified according to their importance. Classifications might include interstates, main trucking thoroughfares, secondary roads, and residential streets.

The next task is to perform a risk assessment. This is an important process by which risk is assessed based on a couple of factors: vulnerability and threat. Vulnerability is the possibility of the incident; threat is the likelihood that the vulnerability will occur. By reviewing the classification, the vulnerability, and the threat, we get an assessment of risk. If one of the factors is low then the risk is generally also going to be low, and may even fall in the category of “acceptable risk.” If the cost to secure an asset is more than the business value of the asset, then management is not likely to want to spend the money on it.

In the case of winter, the vulnerability is whether a particular location could get a disabling snowstorm. There is high vulnerability in northern states such as Iowa and Minnesota, but not much vulnerability in the South. Even in places where there is vulnerability, the threat may still be low and may mean that we don’t see it as ‘high risk’ overall. The threat of a winter storm is obviously minuscule during summer months, but high between December and January. Accordingly, road maintenance departments know when to prepare their snow removal equipment for deployment, and to stock up on road salt and snow-melting chemicals.

There are cities that have occasional snowfall. I have been stuck in Dallas Fort Worth International airport when freezing rain has started to fall. The difference in how these locations respond is almost comical. It is like they grind to a halt over an incident that Minneapolis would handle in its sleep. This is because snow removal is not a major threat, and therefore is typically deemed as an acceptable risk. I remember a few years ago when Iowa actually lent plows to another state that suffered a crippling snow storm, and had only 1 or 2 plows of their own (for the whole state!).

When an incident is discovered or predicted, the emergency response teams are called in. They use an Incident Response Plan (IRP) to know how to respond. For computer security, this may mean performing forensic analysis, management notification, or even disaster recovery; for winter storms it is the carefully orchestrated plowing of streets, parking bans, and widespread public notification of school closures.

A post-incident review, designed to analyze how effectively the response teams handled the situation, is the last step to determine if changes need to be made to the response plan. This may include additional notification methodologies, or requirements for new or additional equipment. In 2008, Iowa started to implement laser-guided plows to enable more accurate plowing with less chance of damage to the roads, and to help weary crews who are often faced with 12+ hour shifts.

Occasional risk assessments should also be performed to ensure that the incident is represented with the same level of risk. Risk levels will be impacted by the need to reclassify the asset (data or road), as well as different vulnerabilities, or changes in threat levels.

So, if you live in a part of the world where snow—or any type of large natural event—is possible, imagine how the response teams might be using the very same type of risk management technique as your I.T. security staff.

Last week I was on the road again, spending five days with a brand new PowerTech customer in Montreal, Canada. I always love these types of trips as they allow me to spend time with the customers who are really seeing the benefit of our solutions. It is also interesting to go to places that speak a different language, and all that entails.

It was an extremely productive trip, built around a packed agenda. Our original goal was to install our popular exit point solution, Network Security (NS), on two separate production machines, and start auditing the users’ activities that were previously invisible. I was also there to perform a formal security assessment; a combination of tasks that I expected would require some long days to accomplish in the time available.

When I arrived, I discovered that there was also a desire for me to help design a new security infrastructure for the application environment. A recent business acquisition, and an open vendor application environment, was driving the desire to secure user access based on business need, instead of hoping that users were doing only what they should. An admirable goal—and a service that we can certainly provide—but I didn’t anticipate we would have enough time to accomplish it during this particular trip.

The installation, initial configuration, and user training on Network Security went so smoothly that by the end of the first day we had already started to enter access control rules, and were hungrily awaiting more user transactions to come in. I was glad when my ‘trainee’ told me that he felt that the PowerTech software was intuitive and easy to use, and that the biggest challenge would be for them to identify whether a user was using a network access tool with approval or not (we later discovered that some activities were questionable). We also made some immediate and dramatic improvements in their security environment. For example, with a single NS rule we were able to protect the critical QSYS.LIB file structure from network access by any user on the system—even the ones with powerful access rights like *ALLOBJ.

Day two had me getting a jump-start on the security assessment, and some deeper insight into the strengths and weaknesses of this particular environment. Most of the issues were typical of most IBM i shops: overly powerful users, a few default passwords, some system value change recommendations, and confirmation of that open application data access model. And like most typical issues, some could be remedied easily; others require careful planning and testing. I had been able to perform some of the data analysis ahead of time using a proprietary data collection tool, and so I was able to provide the customer with a draft of the assessment for review before the end of the day.

Designing a resource security model for the corporate application was next. I’m always interested to see how so many commercial software vendors completely miss the mark when it comes to securing their application. I won’t name names, but this particular application relied on the QPGMR user profile owning the application objects and base IBM i security to control user access. The problem with this approach is that most customers have no idea how to implement a solid security model. Leaving their application open, or worse, requiring application users have *ALLOBJ special authority is shameful. Engineering security into an existing commercial application is not easy. You often have little to no control over the way the application executes its code and the objects it accesses. Good security can be incorporated into an application much more easily when it is part of the design. For example, have a custom (non-IBM) profile own all of the objects. Also, don’t require that application users have special authorities for tasks that can be handled through application code (like starting print writers).

Why do we frequently see this openness? Honestly, I think it is for two main reasons. First, IBM i security knowledge is rare and it is easier to put the burden on the end customer as they are the “owner” of the machine. Sure, every customer has different configurations to be accommodated, but a little forethought goes a long way. PowerTech does this with our own applications, so we know it is entirely feasible even when we have no idea of the configuration of the customer’s server. Second, I think that many vendors believe that that a wide open application reduces the support burden. Ironically, designing the application correctly often means fewer calls, as there are no unknown variables at play. I personally feel the responsibility for a secure environment is shared by the customer as the owners of the data, and with the application vendors whose software we trust to house and maintain that data.

In this particular case, we were fortunate to be able to map out a detailed application model that would work without requiring any application modifications. We started by identifying the types of users on the system. We mapped those users into one of four new group profiles to make life much easier when granting access to the numerous application objects. We secured at the library level first, and then at the object level using a couple of authorization lists. The programs are configured to use adopted authority, providing the users with the necessary elevated access only when using the line-of-business application. The group profiles also provide *USE access to certain command line users when using Query/400. As you would expect, there were a number of additional tasks identified, including a creative modification of the application subsystem (as adopted authority does not normally carry through to submitted jobs).

By the end of the week, we had accomplished everything outlined in the project scope; a detailed step-by-step task document would walk through the actual implementation of the object resource model for the application environment. There was even enough time left to help present PowerTech’s free weekly education Webinar; discussing the findings from our annual “State of System i Security” study.

I would like to thank the wonderful customer staff, Sylvain and Louise, for their kind hospitality and excellent French-English translation skills (putting my own to shame!). I am glad to report that everyone was extremely satisfied with what was accomplished in such a short period of time. I really enjoyed assisting them with all of their security initiatives, and I feel proud knowing that the data served from their IBM i servers is more secure than when I arrived.

If you weren’t aware that PowerTech performed professional services—revolving around our products, and also the base IBM i security controls—then I invite you to drop me a note. I think you will be pleasantly surprised to hear what we bring to the table.

Which leaves me with one final question: “Parlez Vous PowerTech?”

Over the past few months, the press has been discussing an increasing pressure to develop some form of government-mandated security breach notification infrastructure, and also reporting on whether the U.S, government will appoint a so-called “cyber czar.”

The immediate question that comes to mind is how a federal regulation would measure up against the plethora of state laws currently on the books. Interestingly, there are still several states that have not followed the California Act (SB-1286) that started it all in 2003. The residents of these states currently have no protection, and the Federal disclosure law would provide the coverage that they also deserve. While many state breach notification laws address electronically-stored data, the Federal law would likely be more encompassing of private information, regardless of how or where it is stored, as well as provide strict guidelines regarding how notification is handled.

Like any type of formal regulation, there are many arguments made for and against government control. Proponents site the reduced cost and administrative overhead from complying with a single law rather than numerous overlapping state laws, and that there needs to be some form of oversight in order to be able to prosecute those who do not adequately control access to our personal information. Detractors fear that legitimate firms are being burdened with the cost of compliance, while businesses that are not staying within the confines of the law continue to find workarounds and ignore the directives anyway.

Always of interest to me, we will likely to continue to see a range of companies that are truly interested in protecting themselves from the staggering costs of a breach, while others will do the least necessary in order to satisfy a “checkmark” on an auditor’s questionnaire. And with auditors interpreting laws on a server platform that many are still not familiar with, it will continue to be a game of cat-and-mouse between the regulators and the security officers.

Whichever argument you feel carries the most weight, the exponential growth of breach events over the past few years is likely to drive change. Expect 2010 to see more government control over how we react to those events, as well as discussion regarding the consolidation of existing data notification and data protection requirements. For those firms “lucky” enough to have avoided the requirement to comply with formal regulations, be forewarned that those days are probably numbered.