Strategic security: Get a handle on authentication

One rational, standardized authentication policy across the organization will make all your applications more secure

It's a common dilemma: You host multiple Web-accessible applications, for both internal customers and external users. A few of your developers are keeping up on the last programming trends and security models, while some of your highest-seniority employees are stuck in programming models outdated a decade ago. You've got a hodgepodge of access and authentication methods, along with a lot of client-server interaction, and a little bit of Web services and SOA, as well as Citrix or Terminal Services thrown in. There are even a few people still dialing in on phone lines to access dumb terminal-based applications.

[ RogerGrimes's column is now a blog! Get the latest IT security news from the Security Adviser blog. ]

Truth be told, if someone asked what you thought of the situation, you'd reply it's a deck of cards just waiting to be pushed over by the right inquisitive hacker. You've got to get control of your applications and authentication models, so where do you start and what do you do? There are six broad areas that you'll need to address: education, strategy, standardization, policies, remediation, and retirement.

The first step is to educate everyone about the problem. Many of your coworkers and members of management may not be aware of your dilemma. Sure, you've groaned about it here and there, but it hasn't become a top-level concern. It isn't even on the list of things your boss is worried about. It's time to elevate the issue. Develop a cohesive, thoughtful paper on the current situation, the problem, and steps toward a solution, then present it to your supervisor. Do it out of the blue, and you'll even score points with the boss.

The second step is to educate people about the various authentication components. Essentially, you want to explain identity, authentication, authorization, and access control (and accounting/auditing), or simply AAA, as parts of a systematic process, each of which can be accomplished using various methods.

And you want to push for more maturity on each of those concepts. If single users end up with multiple identities, you need an identity management system (or maybe federated identities, if multiple companies are involved). You want to move authentication from passwords to something more sophisticated, such as two-factor authentication. You want to move access control from Discretionary Access Controls (DAC) to client-server impersonation and eventually Role-Based Access Control (RBAC).

Finally, the data you protect must be categorized according to sensitivity and protected accordingly. The idea is to get staff and management thinking about the process, or processes, in a strategic manner -- to move away from individual silo thinking.

Once the boss realizes there's a real problem, it's time to create an overall guiding strategy. Say something like, "Decrease overall computer costs and security risk by designing strong data controls." (Wow, that almost hurt to think of, drawing back on my Dilbert-like days in management, where you have to say almost nothing to accomplish something.)

The idea is to make the problem a strategy. Your boss and your boss' boss can't act until you've developed a strategy and, more than likely, tied that strategy to existing business objectives. From the strategy, build tactical methods to accomplish it.

Standardization needs to be part of everyone's authentication strategy. It's the wide variety of authentication methods employed that got the company into this trouble in the first place. Identify all the current methods, and include a few that seem viable for the next 5 to 10 years. Then pick the ones that the company will officially support as standard(s). If you can't standardize, you'll never get out of the hole you're in. Of course, I guess your standard could be that you'll support anything that anyone wants. In that case, better you than me.

Come up with the tactical components and write policies to support them. It might be something like, "All future custom programming will use Web services, SOA, and role-based access control. All incoming access will end at a proxy firewall where authentication, traffic normalization, and scanning will take place, then the request will be reverse-proxied to the intended end point." Or maybe you, like several companies I know, will decide to do away with the DMZ concept altogether. Use a group to create the policies to support the overall strategy, and get it approved by management.

Next, fix the highest-risk assets first, followed by applications with lower use and exposure. This means fixing existing systems, implementing the new policies in new custom projects, and enforcing the new policies when buying new software.

If a legacy application cannot be brought in line with the new policies, consider getting rid of it. Give end-users a reasonable period of time to select and implement a new system. If the system will not be replaced and you can't adequately protect it using the new policies, communicate as much to management so that they can make the final risk decision.

Even if you can't help your company work through all of these steps, you've improved security and lowered risk just by getting your colleagues, employees, and management to think about AAA in a strategic way. At least it will be on the radar as a consideration, versus the growing deck of cards that keeps you up at night.