System iNetwork

December 2009

December 17, 2009 8:14 AM

Wish List Fulfillment: Raz-Lee Helps Replicate User and Security Settings Between Systems

Raz-Lee Security recently announced enhancements to its iSecurity product suite, and I spoke with Eli Spitz, Raz-Lee Security's vice president of business development, to get more information, as well as to get his take on the latest trends he's noticing in the security market as 2009 winds down.

What's hot in security these days? What are your customers asking for help with?

Spitz: In the industry in general, a trend we're seeing is companies consolidating their environment into multi-system and multi-LPAR networks. Over the past year or so, we've sold into large banks running well-known banking applications, especially in Europe; some even have P40s and P50s, but certainly the trend is to the smaller systems, P10s and P20s. The real challenge for companies is the management and coordination of these networked systems. You don't want to repeat work that you've done on one system for security and compliance—you don't want to have to do that again on other systems. You want to be able to reuse definitions, rules, and alerts that you've set up.

So we're answering to this trend, and our latest batch of features that we've released really relates to this. In fact, these features were specifically requested by a large U.S. financial institution. They have 100+ systems/LPARs, and what they asked for was help with the whole issue of replication: ensuring that definitions are in sync, user profiles are all in sync, and system values are all in sync. Of course there will be exceptions, for example between user profile or system value definitions on test as opposed to production systems, and we allow for this as well in our products.

A really interesting aspect of multi-system management is simultaneously checking compliance levels in these diverse environments. For this, the Compliance Evaluator product that we released about a year ago offers the possibility of evaluating a site's compliance level over any subset of systems, against both site-defined standards as well as regulatory requirements. In fact, the product comes with built-in PCI, SOX, and HIPAA compliance checks that can be run after minimum site customization. And, within the product, we allow for exceptions and unique definitions for the different environments existing at all sites. So alongside the Compliance Evaluator product, which gives a compliance score for individual systems, we've added the ability to replicate definitions, rules, product parameters, and values from one system to another—in the area of user profiles, system values, etc.

So that's one trend that we've been seeing. Another trend we've also addressed, which is important in large companies, is native object security. IBM a couple of years ago came out with a product called Secure Perspectives, whose purpose is to address native object security—defining various levels of user access rights to objects defined in the system. But Secure Perspectives sort of lost focus and has not seen wide market acceptance. As of recently, there is a group in IBM that is involved with that product again. [Editor's Note: IBMer Terry Ford says that IBM's STG Lab Services Security Team has begun new work on Secure Perspectives. Read Ford's comment in our Product Lines blog.]

Native object security is really important because you're always going to have to get down to the basic object that you need to secure, and there's no easy and error-prone way of doing that in large shops.

So, to answer to this growing concern, we've developed a rules-based solution that fully supports generic names for securing, defining, and monitoring access levels to all objects in the system, including all different levels of access—read, add, update, execute, delete, etc. [Editor's Note: See "Raz-Lee Security Releases New Modules for Security Tool Suite."]

A third trend we're seeing is the increasing awareness and concern about application security. Just last week, we concluded a deal in the UK through our rep there, Northdoor, for a financial institution that originally purchased our Firewall and Audit products and has now added the AP-Journal solution. We've been very successful selling this product because it allows for monitoring application-level data and alerting anyone, in realtime via SMS, e-mail, message, or SYSLOG, when application data changes by more than a predefined threshold—percentage or absolute.

As an example, one of our customers is a large medical-supply and healthcare distributor that monitors online the stock levels of all items, and when the level-on-hand goes below a certain value, they'll send out an SMS message automatically to somebody so they can reorder the item. That's just one example, but it's easy to understand how it works.

A related issue is the potentially serious security breach we've been hearing more and more about from companies when data is accessed (read) and not necessarily updated. Originally, our application journal product was based solely upon what IBM provides—journal receivers, which we can filter, monitor, and use to send out alerts. What IBM journal receivers don't do is record accesses—simple reads!

To solve the read access challenge, we developed a solution that integrates with AP-Journal for monitoring these read accesses. So if, for example, someone does access my particular salary, it will be more constrictive. Fewer people can access it, but if they do view it, we can issue the alert. So application security is also brought up as a requirement more and more, and of course we're making a big push out of it and marketing in that direction—spreading the buzz. And companies are responding positively, saying that their auditors would like this solution.

I mentioned that the realtime alerts that we generate in all our products, in Firewall, Audit, Authority on Demand, or AP-Journal, can be a SYSLOG message. So another trend we're noticing is the increasing implementation of system event management (SEM) systems by multi-platform shops. It's basically a central console that accepts event notices from different nodes in the enterprise, which can be any appropriate hardware, for example IBM i, z, or whatever. Or it could be a Wintel or Unix box. With our support for SYSLOG, the Power i is now much better integrated into overall site management.

I think I've covered all the major trends we're seeing and how we've addressed them. Looking to the future, we're doing a lot of development and integration work right now with some financial application companies using mostly AP-Journal, and we will soon be announcing a related OEM agreement we've signed. You'll hear more about that in January.

Also on tap during the upcoming half year or so are graphical and statistical analysis features in AP-Journal, including identifying field-level trends and activity, and the extension of Compliance Evaluator to other platforms, including Windows, Linux, and others. We will be expanding marketing efforts as well and signing up more distributors and looking to establish more OEM agreements.

The bottom line is, we're looking forward to a very successful 2010!

Here are links to some of the other System iNetwork coverage on Raz-Lee Security:

• Security Pulse Point: A Quick Chat with Security Vendor Raz-Lee
• Raz-Lee Solution Protects Your Business from Deliberate and Inadvertent Risk
• Raz-Lee Offers (H)iSecurity
• Raz-Lee Enhances IBM i Security Solution's GUI
• Raz-Lee Security Releases New Modules for Security Tool Suite

—Linda Harty, executive editor & availability/security/networking/connectivity editor

Posted by lharty on December 17, 2009 at 8:14 AM | Comments (0)

December 7, 2009 7:02 AM

Single Sign-On Can Make Your Users Happy. But That's Not IT's Goal

In response to hearing of a new service related to single sign-on, I spoke with Pat Botz, president of Botz & Associates and formerly IBM's lead security architect for the IBM i, about SSO and learned what the true goal of SSO should be. Contrary to what you might think, SSO is actually not the primary goal. The primary objective is to efficiently and cost-effectively manage authentication to corporate IT resources. Looking at the SSO problem that way is the key to effectively choosing and implementing an SSO solution.

Pat expresses why he thinks SSO is an ambiguous term, provides details about the different approaches to achieving SSO, describes what their drawbacks are, and explains why the most important thing you can do is look at SSO from a business perspective. He gives details here about how you can do that. His company has also announced the availability of complementary one-hour consulting sessions to help organizations analyze both the technical and business aspects of moving to a single sign-on security strategy. The sessions are conducted as private online meetings and are offered to organizations that want vendor-independent guidance to find viable solutions and predict the potential payback of implementing various SSO solutions within their unique environments. You can find the details of the offer on the Botz & Associates website, which I link to at the end of this article. In the meantime, read on to get some great information about SSO from one of our industry's top authorities on the subject.

What is the state of SSO technology today?

Botz: There are more and more options out there for quote unquote SSO, and I always say "quote unquote SSO," because it's very important to define what you mean when you say "SSO." People think of SSO as a specific solution, but the term actually describes a variety of technical approaches to a common problem. There are many different approaches to mitigating the problem that is encompassed in SSO. So I always try to discuss SSO in terms of password management—because the real problem is not that people have to sign on too many times. The problem is that people have too many passwords to remember. When you look at it from a business point of view, the actual problem is that it costs too much to manage authorization to IT assets. And when you look at the problem from a business point of view, the number of solutions for that problem greatly increases.

Let's get back to the definition of SSO. When you say "SSO" to an arbitrary individual, you'll both shake your heads and say, "Ah, yes, SSO. We need that." But the two of you may quite likely be talking about two separate things. You may think it means, "I have one password that I type in whenever I'm prompted to sign on to any IT resources on my network." The other guy or gal may think it means, "When I sit down at my computer, I get prompted once to log on, and I never have to log on again no matter what resources I access and no matter where they're located."

That's why the term SSO is very ambiguous. The goal is not to implement SSO; the goal is to significantly reduce the cost of managing authentication to IT computing resources. So I don't like the term SSO. It's a technical term used by techies, and it tends to cause people to set the wrong objectives.

Consequently, I use the term SSO only because it gets people's attention and generally focuses them in a specific direction. As soon as I do that, I say to them, "Let's understand the real problem." They may reply, "A lot of my people are unhappy" or "The help desk spends too much time on password-related problems." That may be true, but IT's role is not to make users happy. IT's role is to make the usage of corporate information as cheap and efficient as possible for the business. If you look at this problem in any other way, you'll end up implementing technology that may not actually fix the problem at a reasonable price.

The real goal, as I mentioned, is to significantly reduce the cost of managing authentication to the corporate IT resources. If you do that well, you'll achieve all the other goals: You'll make your users happy, you'll make them more productive, and the help desk will spend less time managing password problems. But in order to measure whether you will (or have) significantly reduced these costs, you have to calculate what those costs are currently and what it will cost to acquire, implement, and manage the proposed solution. With this information, you can not only determine whether you reduced these costs, but you can also predict return-on-investment and months to break even.

There are a number of technical approaches to SSO. Most of the approaches involve capturing a user's current user ID and password everywhere on the network. Users are provided a user ID and password for the solution and always use those whenever they're prompted to log on. Some solutions will try to intercept logon attempts to anything on the network. The solution, given the user ID and password plus the entity to which the user is attempting to authenticate, will look up in its database the actual user ID and password previously captured for the entity to which the user is trying to authenticate and will then forward that information on as if the user had typed it in.

That's one approach. The problem with this approach is that you haven't eliminated any passwords that need to be managed. You've eliminated prompts, so the end user will see fewer prompts, but somebody or something has to manage the real user IDs and passwords being used. So rather than eliminate the cost, you've shifted much of the cost to the IT department from the shoulders of the end user. You've also introduced a single database in which user IDs and passwords are stored for all users everywhere. Is that a good solution? In some cases, it may be. It depends on what your costs were before and whether there is an improvement in the strength of the real passwords. You have to look at it on a case-by-case basis.

Another approach to SSO is this: There are tools out there that will merely help you sync your passwords across multiple systems. That approach doesn't eliminate any of the prompts, but it does allow the user to type the same password no matter where he or she is signing on. A lot of these solutions also are combined with another product—a user ID management product of some sort—that then tries to make it easy for end users to change their password once and get it changed everywhere else and keep all the passwords in sync. That's true for most of these solutions—often there's a companion product that goes with it, or the solution includes that additional functionality. And again, the drawback is that you haven't eliminated any data that needs to be managed. You've shifted the costs to the IT organization, which has to buy the product, pay the maintenance, manage the product, provide support, and so forth. That's not to say that it's not a viable solution, but again you have to take all those costs into account and then compare them to your current costs and to the costs of other solutions and approaches.

A third approach to the problem is to actually try to provide a common user ID and password repository. That's an attempt to have everything in the network that performs authentication use a single common repository for user IDs and passwords (e.g., LDAP). It gets you one copy of the password that you have to manage, because it's stored in one place. The problem with the approach is that it's pretty costly and often not possible to change the user ID and password repository used by an application or an OS. For example, IBM i is designed around the concept of user profiles. The place where the password is stored is very tightly integrated into the system. IBM would have to change the operating system code to allow the OS to optionally use an LDAP repository.

In theory, a common repository protocol is a nice approach, but it never took off, because the end user didn't have the ability to change the user ID and password repository used by applications and systems.

A fourth approach is to use a common authentication protocol that doesn't require pre-exchanged passwords. Password-based authentication protocols establish trust by forcing the user to prove that he or she knows a secret (i.e., a password) that is also known by the entity doing the authentication. This requires the secret to be "exchanged" before authentication can be successfully accomplished. Assigning or changing the password in a user profile constitutes this pre-exchange of passwords. At the time you log on, the machine or the application must already know what your secret is, or you're not going to be able to log on. But there are other authentication protocols that accomplish authentication just as well—in fact in a more secure manner—and that don't rely on a pre-exchange of secrets between you and the thing you're trying to authenticate to. One example is the Kerberos protocol. What makes Kerberos especially interesting is that anyone who logs on to a Windows domain is actually already using the Kerberos protocol. And Kerberos is also widely available on every general-purpose computing system that I know of. It certainly is available on all Unix, Linux, i, and z machines. You just have to turn it on and configure it. And then you must configure your apps that you're using to access those non-Windows machines to tell them to use Kerberos.

One advantage of Kerberos is that you already own it. You're most likely already using it in your environment, so all you have to do is configure the i so it can use that Kerberos protocol. The downside is that not all applications you use to access the i will necessarily support the Kerberos protocol. The benefit is that you can eliminate the prompt for a user ID and password, and you may be able to eliminate the password.

Basically, the drawback to all approaches is that there's no solution out there that I know of that works for 100 percent of everything in any kind of even slightly complex enterprise. If you have all Windows servers, you have SSO through Windows. Or if you have Windows and just one other type of server, and you use only Telnet to access that server, you might be able to eliminate all prompts and passwords for 100 percent of the users. But that's not the average environment. In most environments, you might be able to eliminate 80 or 90 percent of the passwords. The results are really very specific to an individual environment.

Now let's go back to looking at this from a business point of view. The whole reason that you need to look at this problem from a business point of view is because the goal is not to eliminate all the prompts or all the passwords. The goal is to significantly reduce the overall costs of managing authentication to your network resources. In order to do that, the first thing you need to do is calculate what it's costing the organization now to manage x number of user IDs and passwords per person. The next step is to calculate, for a given proposed solution, what it's going to cost you to acquire that solution (e.g., up-front licensing costs), what it will cost to roll out that solution (e.g., how much time to plan, document, test, and then implement), and how much it will cost you every year to manage that product (e.g., annual maintenance fees and any administrative costs associated with supporting the product). Finally, you have to calculate what managing those user IDs and passwords will cost once the solution is implemented. With these numbers, you can calculate an ROI and how soon you'll recoup the costs—if you ever do—of using that particular solution.

That's what our free offer is all about. We have an SSO ROI calculator. It's a totally vendor-independent tool. We walk you through the spreadsheet. On the first page, we help you provide reasonable assumptions about salaries and time spent on various user ID and password tasks. These assumptions are used to calculate your current costs for managing user IDs and passwords. It calculates how much you're spending on managing user IDs and how much of that is due to just managing passwords. So it gives you a total picture of what your costs are, in five or 10 minutes.

The second page of the calculator is where you provide assumptions about the cost of whatever solution or solutions we're looking at. So again, we fill in assumptions about license costs, how much time it will take to actually implement the solution, how much time it will take to manage that solution, and so forth, and then we come up with a cost of implementing and using the solution. Once we have that, we can do an ROI calculation based on your current overall costs compared with what the costs would be if you had the solution, minus the cost of acquiring, implementing and managing the solution. The ROI calculator is available free on the Downloads page of our website, and you can sign up for your free SSO consulting at our website as well. Signing up for free consulting will also allow you to download the calculator.

Your announcement about the free SSO ROI evaluation offer says, "This free service is meant to cut through the complexity and lead companies to more rational, cost-effective ways of reducing the expense of password management. That may or may not include technology solutions." I'm intrigued about the non-technology SSO solutions. Can you give us some information about that?

Botz: Sometimes a solution might include changes to processes and procedures either in addition to or instead of technology. One real-life example of this is a company (which I won't name) that I worked with. The IT department had no idea why every new user was given a user ID on one specific system. They learned they could easily move the task those users were doing on that system to a different system. This move not only allowed them to eliminate the password, but the user ID as well. This is just one example in which a change to existing processes or procedures is a better solution than technology.

Sometimes a better solution is less-advanced technology that solves only part of the problem. The ROI for the advanced technology may not be great enough to warrant the cost. Let's say you have a Windows domain, one IBM i, and 5,000 users. While you could buy an expensive password-sync tool or implement Kerberos, it's very possible that you could either build or find a non-licensed product (maybe it would have a one-time charge) that would sync those passwords for you easily. This is another example that SSO is not the goal. The goal is to significantly reduce the costs of authentication. If you can find something that's really cheap and easy to acquire and implement, and you can show that it provides a significant reduction in costs, that's the right solution for you. It might not eliminate all the costs, but it eliminates a big chunk of the costs for very little expense. That's a win-win.

Oftentimes, the right solution is a combination of approaches. For example, with Kerberos, let's say you can eliminate three of five passwords by using it. Well, you still have two passwords left. Depending on your environment, we may be able to build or buy a tool that easily syncs the two remaining passwords. Again, this is all very organization dependent. Unfortunately, many organizations never get to the point of combining solutions. This happens when you look at SSO as a purely technical problem instead of the business problem that it really is.

Any closing thoughts you'd like to offer our readers?

Botz: I think what differentiates Botz & Associates is that we not only have very deep technology background across multiple platforms, but we also get the business side of things. We can translate from one to the other better than anyone else.

—Linda Harty, executive editor & security/availability/networking/connectivity editor

P.S. For more insights from Pat Botz, check out another interview I did with him in August 2008: "True Security Requires Philosophical Shift."

Posted by lharty on December 7, 2009 at 7:02 AM | Comments (1)