CIA's Ex-CISO on Preventing Leaks

Describes Controls for Systems Administrators

In the wake of the National Security Agency leak by former NSA contractor Edward Snowden, how can organizations limit the amount of data access offered to those managing IT systems?

One measure is requiring different levels of privilege, says Robert Bigman, who retired last year after 15 years as the chief information security officer at the Central Intelligence Agency.

That's straightforward in a Unix environment, which facilitates organizations designating different levels of privilege, Bigman says in an interview with Information Security Media Group [transcript below]. "You can actually give certain people certain levels of access, like 'install printer'. ..." he says.

Similar tools are also available in Windows, but Bigman says they're not frequently implemented because of the difficulty of managing and using them. But that could change as a result of the NSA leaks. Before the disclosures, many professionals didn't think their organizations had a problem managing access to data, Bigman says. "I think this Snowden case will indeed bring people to realize, 'Yes, we do.'"

Another approach Bigman suggests organizations should follow to limit unauthorized access is to encrypt the data and set up rules allowing only certain employees to see the data. "The administrators ... can do their jobs of adding accounts, adding applications and they don't have access to any of the data files," which are administered separately," he says.

In the interview, Bigman:

  • Explains how access privileges for systems administrators differ in Windows and Unix/Linux systems;
  • Outlines tools available to limit systems administrators from accessing information without authorization while not interfering with their duties; and
  • Discusses how chief information security officers can persuade their bosses to provide the proper tools and training to assure systems administrators don't inappropriately access information.

Bigman spent nearly 25 years at the CIA, making him at his retirement the government intelligence community's most senior information security officer. During his CIA tenure, he consulted with other intelligence agencies, the National Security Council, presidential commissions and congressional oversight committees. Bigman now runs B2Secure, an IT security consultancy.

The Role of Systems Administrators

ERIC CHABROW: Edward Snowden is a former contractor with top security clearance who worked as systems administrator at the NSA, and admits leaking information about intelligence gathering programs. But it's just not the intelligence community that has sensitive information to protect. Most organizations want to limit access to specific information, and that's what I want to talk about today. First off, there's a perception that systems administrators, because of their jobs, have unlimited access to the systems. How true is that?

ROBERT BIGMAN: It's true in some environments and not true in others. In the Unix and Linux environment, which was designed to be a single user-managed system, it's true that when you have root access you pretty much own the system and there's not a whole lot more you can do. There are some commercial products that basically manage around the root access.

In a Windows server it's a little bit different. You do have levels of access and levels of privilege on their server product. ... But there's a group there called the domain admin group, and if you have the domain admin group on the primary domain controller, which is the key server in the Windows network configuration, then you're almost like the super-user in Unix. There's always going to be some collection of people on any contemporary computer architecture who have the keys to the kingdom.

Placing Limits on Administrators

CHABROW: What kind of limits can be placed on most system administrators that have this sort of wide access without interfering with their jobs?

BIGMAN: There are some commercial tools you can use. In the Unix environment, basically it requires you to have different levels of privilege. There's still the root, but you don't have to make everyone else root. You can actually give certain people certain levels of access, like [access to] the file system, install printer, the add-user account, and they get only that privilege. They have root-level process access so they can do a root-level process without having root privileges. There are similar tools for that in the Windows environment, but I don't see those tools used that frequently. They're not big sellers in the computer security industry.

CHABROW: Why do you suspect that?

BIGMAN: I think they're difficult in managing and using them, and the perception in most organizations is: "We don't have that problem." I think this Snowden case will, indeed, bring people to realize, "Yes, we do." We all do have that problem and we need to use these types of tools.

The second type of tool that would really help - and I used this in my previous employer as well - are products that allow you to encipher your date files without allowing the admins to actually have access through the computer network to those data files. ... The have the pmost well-known one is Vormetric. You can actually encrypt your data in storage and use Vormetric compliance to set up rules as to who actually gets to see the data. The admins can do their job. The root administrators and the Windows administrators can do their jobs of adding accounts ... adding applications and they don't have access to any of the data files, and that's all administered separately, in this case Vormetric compliance. That type of technology - it's a very small world of companies that do that - provides an added level of protection.

CHABROW: Why do you suspect many organizations don't take that route? You did make reference earlier; maybe people don't feel it's a problem they face?

BIGMAN: They're not confronted with the problem until they have the problem frankly. ... Most organizations don't want to deal with the expense of buying the product, having to encrypt their data, re-encrypt the data that hasn't been encrypted yet, and setting up the accounts on the appliance to run the system. It's not without its cost, but ... these are the types of things that really provide a big benefit to the company and they just don't seem to have a wide adoption because of the perceived impact and benefit.

Difficulties Implementing Access Solutions

CHABROW: Are there other things that are difficult about certain access management solutions to implement?

BIGMAN: Again, it depends on what your acceptance and consideration for risk is. I think if you use a standard Windows deployment package for Windows Server, it allows you to separate access controls and management controls both in Active Directory and on the system so you can get a high degree of separation and privilege compartmentation. The problem is most companies - even in the government - focus more on ease of use and ease of administration as opposed to security. While they have these different groups, what happens over time is all the administrators become added to all the groups. One is filling in for another one, you always have coverage 24/7, and if you don't have good rigorous security oversight you tend to fall into the trap like a lot of corporations do, that we're not going to have a problem and everything will work out fine.

Importance of Training

CHABROW: How important is training and making the individual systems administrators or other employees aware of their responsibilities and things they should not be doing?

BIGMAN: It's important. I emphasize it. In my job, we had a certification program for them. But in most cases, in companies I visit, I don't see any type of admin certification or admin training. In fact, in most cases it's usually contracted out to someone who they think knows it better than the company, and they have SLAs [service level agreements] or they have all sorts of different mechanisms with the company. But they never call out any security restraints or any security consideration. I think the training in overall government and in private industry is actually poor.

CHABROW: Organizations do contract out this kind of work, but shouldn't it be the responsibility of the end-user organization to make sure, even if it's their contractors, that they provide the training for them?

BIGMAN: You can read the contracts for these service providers. They say they'll provide a secure environment to protect their data, but not from the systems administrators. It's from other corporations or other people using their services. I know I worked with one company with a contractor and we tried to get them with the SLA [service level agreement]. We finally had to write a new contract with the service provider to get them to understand how many admins they were allowed to have that will manage their company's data. And if they wanted to make a change they had to first get the approval of the client company, and they balked at that. But it was such a big customer that they finally agreed.

Reducing Number of SysAdmins

CHABROW: In recent testimony by Gen. [Keith] Alexander of the NSA talked about how the organization is looking at maybe reducing the number of systems administrators. Are there just sometimes too many people in organizations that have these kinds of rights and they should just limit those?

BIGMAN: Part of when you're there is, "I have enough administrators 24/7 to do anything that needed to be done: run back-ups, end-users, do all the things." That tends to speak to having more people available. On day one, things tend to work out reasonably well from a security perspective. You have all your different groups set up and they're populated properly, but somewhere around day 424 you find that most administrators are in every other group, and some people don't even know the groups they're in. They just know they have broad access across the system, because the focus is efficiency, up-time and performance, and it's just not security.

CISO's Responsibility

CHABROW: Whose responsibility should that be within the organization? Should that be the CISO or the CIO?

BIGMAN: That's the CISO. The CISO has to be in there fighting with the CIO, fighting with the IT operations people and actively keeping those numbers down and making sure they're good with compliance. There are compliance tools to help you monitor that. It's one thing to monitor; it's another thing to change.

CHABROW: The technology, the processes and the laws are there. For many people, is it just hard to do?

BIGMAN: It's hard to do. When the CIO's constant focus is on operations, support, access, getting people what they need ... and getting things done, the rigor in security tends to [fall off], especially if no one is watching. It's just human nature; it's just how it happens.

Data Rights Management

CHABROW: Is there a question I should have asked you about and I didn't? And what would the answer be?

BIGMAN: The other thing I would mention is data rights management: encryption in which the data both is enciphered and has user protection governing it, and it's not tied to a computer system it is on. It's tied to a separate policy server that sits on your network, which the systems administrators do not have access to, and it controls the data that's on the system. If you have very sensitive files, you can both encipher them and say, "This person does have access. This person doesn't have access." And no matter what the administrator does, unless he has access to the policy server - and you want to keep those two separate - he can't access the data. The data is under policy control.

CHABROW: So in other words, the systems administrator could be in there to sort of manage the system itself, but cannot necessarily get a hold of specific documents that have data rights management tied to them?

BIGMAN: Exactly, as long as the data rights management tool is managed separately and distinctly from the network itself.

CHABROW: Is that hard to do?

BIGMAN: No, it's not hard to do. There are products that do that.




Around the Network

Our website uses cookies. Cookies enable us to provide the best experience possible and help us understand how visitors use our website. By browsing govinfosecurity.com, you agree to our use of cookies.