Bob Farber | Dealing with the insider threat

An insider is much more dangerous than a hacker because an insider knows your environment and a hacker is just guessing. There was a study done by the Computer Security Institute and the FBI in which 80 percent of those surveyed said they had [experienced] incidents related to insiders, which was up from last year's 64 percent. There was also research done in 2005 by Internet Behavior Consulting in which 31 percent of responding organizations said they had terminated an employee because of internal security violations. In another poll by Dark Reading, more than a third of trusted users surveyed said they had abused their security privileges.And you don't have to go too far when you look at today's news and you see things like the passport breach that happened at the State Department. Those were insiders. There was another story that came out [recently] about the engineer who was getting Navy submarine data to the Chinese. Symark has been in the insider threat business for many years, and for many years we played second fiddle to the virus scanners and firewalls and the perimeter fences. But now the insider threat is becoming more prevalent and is getting more coverage. Those [are] accounts that are left over from employees who have left the organization or are left over from specific functions they are no longer performing. They are orphans in that they have no owners. It's a major problem. A lot of customers, when they install a product and realize how many orphan accounts they have are surprised at the number of them. The danger is that when you have a specific owner, you can tie back an activity to a specific person or job function. When you have an orphan account, there is nobody to point the finger at. If that account is left active, a user ' maybe someone who is unhappy about the way he left the company ' can abuse it. It can be used as a back door to get into the system. You do it through procedures and software. You have to have appropriate human resources policies so that when someone leaves the company they notify the information technology group, which takes the steps necessary to get rid of the accounts. The problem is that this always takes a second or third or fourth or 10th priority. That's where software comes in. It can allow you to centrally administer your users. Whether'through [Lightweight Directory Access Protocol] or Active Directory, you can identify those accounts and deactivate them. A lot of times people will use the 'least privilege' concept, where rather than giving every user the keys to the kingdom you give a user just exactly what they need to do their jobs. Some companies, when they implement this, will start by giving full authority to everybody and then do a detailed audit of what they are doing. Over the course of weeks or months, you will find out exactly what people actually use and you can write your security policies based on what people are actually using to do their jobs. The underpinning is what the role of the individual is in the organization and the way the company is structured. It can tend to be a political issue if it isn't managed from a central point. In some cases the human resources department is going to be the key point, because that's where people enter and leave the company. If [the human resources department] is not involved, you have the situation with orphan accounts. The IT group does not necessarily know when an accountant or engineer leaves the company, but HR does. I think role-based is the tightest control you can possibly put in. And what is the tightest is the least flexible. So you have to build a system where you can make changes quickly and do it in a nonintrusive way. The other key is the forensic aspect. If you have a payroll [employee] looking at a general audit file, for instance, you want to have a good audit trail and good forensics. That makes the role-based system work. With identity-based controls, the advantage is that you can have a single repository where all of the users are stored and that solves part of the problem. But it doesn't give you granularity. You have a symbiotic relationship between identity-based management and role-based management. For years we've been saying passwords are going to go away. But they are not going to go away. You need to make your password stronger. You have to have passwords [being changed] frequently and adhering to standards. There are a lot of second factors that can supplement passwords. To some extent it is, but there are roadblocks. There are just too many diverse environments that handle passwords and sign-on in different ways. For years people have been trying to invent the silver bullets, and there is none. You can get part of the way there. We have a solution that specifically handles Unix and Linux, and we can manage that through the Active Directory or through LDAP. Some people are looking for something that solves Windows, mainframe, Unix, Linux, etc., and nobody does it. My feeling is it is not something you want to do. You don't want to sacrifice the flexibility and capabilities of the environment just to become all things to all people.