Let s Not Go There...

Let's Not Go There...

In new-product development, we all try to stay at least a few paces ahead of the pack. But the wolves may be closer to your heels than you think. In his book Information Warfare: Chaos on the Information Superhighway, Winn Schwartua notes, "At one point, if not already, you will be the victim of information warfare... If not yesterday or today, then definitely tomorrow."

If this sounds a bit melodramatic to you, stop to consider the overall price. According to the Office of the National Counterintelligence Executive, in the year 2000 alone industrial espionage cost American business an estimated $100 to $250 billion in lost sales. And you can add to that the economic and personal cost of lost jobs.

Even a single act of espionage can be devastating. Vogon, a computer forensics firm, asserts that one of its client audits found an employee downloading proprietary data in order to start a competing firm. The client estimated that its losses, had the piracy not been uncovered, could have approached $10 million.

Given this backdrop, do you have adequate security controls in place? Don't let your future blur and disappear as JFC's nearly did. Instead, do what JFC should have done.

Use Standard Architecture Designs

Make sure that security architectures exist for connecting external customers to your network (extranet). An architecture should cover the big picture. It should specify the type of firewall to be installed, list which services should be allowed, describe the software installed, and clearly specify all network connections.

You should also know what architecture your customer has on the other side. Obviously, you need to trust your customers to some degree. But you can't afford to trust them without a clear reason. JFC offered unconditional trust, without the technical specifications to be sure the trust was warranted. Don't put yourself into that position. By all means, offer your trust. But first make sure that your customers deserve it by providing you with detailed information about the system configuration on their side.

In the post-Internet business world, trust is no longer a handshake. It's a clearly written and agreed-to architecture.

Track External Connections

The demand for external connections can build quickly, especially if you work for a growing company. In 1996, Ernst & Young found that a full third of businesses that they surveyed used the Internet to exchange important business information. Since then, the e-commerce revolution has taken hold and caused the number of external connections to skyrocket. By 2002, fully 99 percent of respondents had company Web sites. Of those, 52 percent actually conducted e-commerce on their Web sites. Now actual funds as well as financial data are routinely zapped into cyberspace. External connections are no longer exceptional; they're expected.

One of JFC's major problems was that they couldn't even tell me how many external connections were hooked up. The requests for connections were stored in an ASCII file, but that file didn't tell me which requests had been approved and/or implemented.

Put someone (anyone!) in charge of tracking external connections. Then give that person detailed instructions on how to maintain the records. If you can't easily access and report against the external connection information, it's worthless. Even better, require the person in charge of external connections to submit regular, detailed reports on the connection status.

Take Responsibility for Your Territory

If you're a system administrator responsible for specific systems, remember that those systems are your territory. Unless you split the responsibility with a security administrator, you are responsible for every one of the systems in your territory. In the JFC case, Fred put the blame on Dave because at the end of the day, Drug10 belonged to Dave.

If you are a system administrator responsible for a specific territory and don't know how to configure security on those systems get help fast. If you don't speak up and ask for help, you won't get it. Ask for training or hire someone who already has the expertise to maintain the security of your area. If your manager won't provide funding for training or help, you might want to consider looking for another job. Remember, if a hacker breaks into your network, it will be your butt on the line not your manager's.

Require Approval for External Connections

Tracking external connections is a good starting point to regaining control of your network. But you may also want to consider limiting those connections as well. In all honesty, not everyone really needs access. To limit risk, you may want to establish guidelines to determine when (and whether) requests for access should be granted.

We've all seen the statistics on increased Internet connections and lots of hype about increased productivity facilitated by easy information access. But increased access doesn't always lead to increased productivity. Seventy-eight percent of CSI's 2002 study participants reported catching their own employees using the Internet inappropriately. In fact, the California-based Saratoga Institute reported in 2000 that over 60 percent of American firms had officially censured employees for Internet abuse. Even more telling, a full 30 percent of firms had actually fired employees for actions including online day trading and gambling, accessing pornographic Web sites, and simply wasting too much time on the Web. Before you decide to increase your company's productivity with more access, really think about the potential consequences.

As a start, put someone important (perhaps management?) in charge of approving external connections to other networks. It's also a good idea to have a manager sign off on each connection. This way, the responsibility goes up the chain a little the higher up, the better.

I strongly suspect that if JFC's management had been required to approve the Internet connection for Drug10, someone would have questioned its wisdom. If nothing else, it would have taken the heat off Dave and moved the blame to that manager.

Enforce Policies and Procedures

In its defense, JFC at least had a policy for firewalls. It was a 30,000-foot, one-size-fits-all policy, but at least it was there. And, it clearly stated that only one connection to the Internet was allowed. Unfortunately, that policy was not enforced. If it had been, Drug10 would never have been installed as it was.

Developing policies is pointless unless those policies are consistently and ruthlessly enforced.

Disable Unnecessary Services

Bugs and configuration errors with network services can lead to security breaches. Bugs, unfortunately, are a fact of life. To minimize the risk to your network, you need to minimize exposure to network services that you don't really need. Services that are not necessary (such as walld, findgerd, sprayd, etc.) should be disabled. Running unneeded services is a good way to set up your network for a denial-of-service attack.

Your site security policy should clearly spell out which services are necessary and which services pose unacceptable risks and should be disabled. If your site policy doesn't address network services and you don't know which services to disable, hire a security administrator or consultant for advice. Don't play around with the services on the systems you support unless you know what you're doing.

Stress the Importance of Training

I've said this several times already, and will no doubt say it many times again: often the weak link in security is ignorance. All the technology in the world won't help if employees are not trained and can easily bypass existing controls.

JFC's system administrator, Dave, was clearly concerned about security. But he didn't have the slightest idea how to configure it. If you're in the same situation, learn how to configure security from someone who knows. Don't just pass the buck to somebody else. Dave did that. He assumed that Fred would take care of the problem. Unfortunately, Fred didn't see ensuring the security of Drug10 as part of his job. For better results, Dave should have had Fred teach him how to ensure that security. Even better, Dave's manager should have arranged for appropriate training.

Follow Through

If I told you that I would set up your system for security, wouldn't you like to be sure that I actually did it? When the ultimate responsibility for the system is yours, always be sure to follow up on promised security help. If possible, use the opportunity to gain experience in security yourself by actually watching the procedures. If that's not possible, at the very least ask the person point-blank whether he or she completed the project. Because of time constraints, mixed messages on priorities, and genuine emergencies, you can't always expect people to do what they say they're going to.

In short, never assume that security problems have been fixed without checking to be sure.

Don't Connect Unsecured Systems to the Internet

This really should be obvious, but just to make it clear: Don't ever connect an unsecured database server to the Internet! (Unless, of course, you'd really like to trade in your company badge to try your hand at selling encyclopedias door to door...)

Checklist

Use this checklist to determine how your company is doing at controlling external connections. Can you mark a "Yes" beside each item?

___ Is management involved in the external-connection approval process?

___ Does someone (preferably someone important) keep track of external connections?

___ Does management know how many employees and contractors have external connections?

___ Are unnecessary network services disabled?

___ Are all outside connections evaluated for true need before approval?

___ Does your company conduct routine audits to maintain control of external connections?

___ Is appropriate training provided for persons responsible for security?

___ Are procedures in place to disable connections when employees and contractors resign?

___ Do policies and procedures exist for external connections?

___ Do policies and procedures exist for installing firewalls?

___ Do policies and procedures exist for installing customer connections (extranets)?

___ Most importantly, are connection-related policies and procedures enforced?