Forget Security?

Like many other large companies, S&B Systems looked for innovative ways of doing business in the 1990s. And, like so many of their contemporaries, they latched onto the concept of outsourcing.

Basically, outsourcing means paying another company to do business for you. For example, S&B didn't want to actually hire (and pay benefits to) 70 receptionists worldwide. So, they outsourced the service instead. That receptionist in the lobby may look like she's an employee of S&B Systems, but she really works for a staffing firm called Job Power. After their success with outsourcing the receptionists, S&B began looking at their other staffing needs with the outsourcing model in mind.

One day, management decided to outsource all shipping operations. They selected a vendor, Express Time, with years of experience and a solid reputation for timely deliveries. To facilitate the process, S&B connected Express Time to their network. The switch seemed to progress smoothly. Soon, S&B Systems didn't have to worry about maintaining and staffing a shipping department. Their selection of Express Time seemed to be a huge success for both parties.

What the executives at S&B Systems and Express Time didn't know was that the system connecting the two companies was not configured for security. Anyone with access to that bridge system could move from company to company, gathering, modifying, or destroying data at either S&B Systems or Express Time.

A full year passed before anyone noticed that the two networks were easy targets. Given the level of risk, both companies were lucky that their systems weren't shut down altogether. It would have been incredibly easy to do!

In fact, it was only by chance that S&B Systems discovered just how risky that network connection was.

Day 1: Taking a Look at Security Controls

It all started out fairly simply. I was hired as an independent auditor to test security on some systems at S&B Systems. One of S&B's support managers, Shelley Berger, had requested an audit of the customer network because her staff were planning to upgrade the operating systems on their network. They were also planning to upgrade the firewall that connected their network to Express Time. Before implementing that upgrade, Shelley wanted to know how well security had been configured on the systems.

Shelley's request was a smart one. Before performing a major upgrade, you should always make sure that you really understand the environment in which it will be implemented. Running a security audit in advance is the best way to avoid nasty little surprises later.

Shelley's group had already completed an audit of the firewall and was now preparing for that upgrade. So, my focus was on S&B's internal systems.

Shelley gave me a guest office with a view, my own system, a network map, and a nice stack of policies and procedures. She also gave me a rundown on S&B's support structure. Security responsibilities crossed over several departmental boundaries. In a nutshell, they had a security group, a system administration organization, and a network team. The security group was responsible for auditing security, handling intrusions, and reviewing code. The system administrators were responsible for installing systems, applying upgrades, and meeting general user needs. The network team was responsible for maintaining the network and firewall connections. I found this support structure to be fairly typical of companies of S&B's size, and I was actually impressed that they had put a lot of thought into formally defining roles and responsibilities.

Shelley didn't really care what approach I took to testing the systems. She just wanted to know what the risks were. I asked her to get me an account on one of the database servers and set up some meetings with the security group and system administrators for the next day.

Shelley left me to ponder the network map and policies and procedures. In a sense, this was a comfortable audit in that I was actually looking to prevent security problems and not reacting after the fact. On the other hand, I wasn't really inspired by this audit. I pored over the policies and procedures looking for inspiration.

After a few hours, I had made my way through most of them. Upon close inspection, they really weren't that great. They were mostly what I like to call 30,000-foot security policies the long and weighty type that impress executive managers but don't do anything for the people in the trenches.

The day was nearly over and I was still basically uninspired. Usually, I get pretty pumped up just by the thought of finding risk. But this time, nothing was energizing me.

I knew that Shelley would be walking out with me soon, so I took my last few minutes to glance through the network map. S&B Systems had a ton of database servers and it was easy to see where the customer network was. Actually, it looked like they had three different customers connected to the network. Each connection was being protected by a different firewall. I guessed that those were the firewalls they'd just audited and were preparing to upgrade.

That was when Shelley appeared. I filed my thoughts on the network map to think about later. For now, my mind was running ahead to some work I needed to do on my home network. One of my hard drives had crashed and I needed to replace it and restore the data. Not the most exciting evening to look forward to, but it had to be done.

Day 2: Network Connections

On my drive in to S&B Systems, I started thinking about that network map again, remembering how they'd just completed a security audit on their customer network connections. As I pulled into the parking lot, I was wondering exactly who had done that audit.

Shelley was already waiting for me in the lobby. As we walked to my temporary office, I filled her in on what I'd done the day before. I let her know that I had spent most of the afternoon reviewing the policies and procedures. When we arrived at my office, I showed her the network map and remarked, "I didn't realize that several different companies had connections to your network." She responded, "Yes. We've been outsourcing a lot this year. We're keeping just the core competencies and outsourcing the rest." Pointing at the network map, I inquired, "Are these the systems that were just audited?" She said, "Yes, and these systems over here too." Shelley pointed to a group of database servers (labeled DBS1 to DBS10) that appeared to be on S&B's intranet and not on a customer network (extranet).

She then said, "No, those are customer systems too. You see, we outsourced our shipping department last year and those are the database shipping systems." That made sense. DBS must have stood for database shipping.

Now, I was finally becoming energized for this audit. This was exactly the kind of risk I was looking for.

Shelley began to inform me that when S&B had outsourced their shipping operations, they had connected the DBS systems to the network at Express Time. S&B still maintained and updated the database, but Express used the shipping data on the systems to ship the actual machines to customers.

As I looked at the map a little closer, I noticed that the DBS10 system had two network connections. One was to S&B's intranet. The other was unlabeled. I assumed that it went off to Express Time's network.

Shelley was not very technical. Otherwise, she would have realized that what she was saying was that S&B's shipping servers were connected to Express Time's network. Therefore, once you logged onto the shipping server you could access any of the systems on the Express Time network. Or vice versa. Logging into a shipping server from Express Time would also let you access any of the systems on S&B's network.

To see what I mean, think of it as a lock to the door of your office. Now, let's imagine that you work in a high-rise building in New York. You're on the 20th floor of the building. There's another company on the 20th floor that you've outsourced all your purchasing to. Obviously, you have a key to your office on the 20th floor. But, though they don't know it, your key also works on your partner's door. You can get into their office and wander through their files any time they're out. You could even change their billing records to give yourself a better deal on the outsourcing work! In the same way, your partner's key also works on your door. Anyone from that firm could wander through and change your files at will, too.

Now you can see why I felt I'd just hit the jackpot! Of course, this was still a gut-based feeling. I needed to log in and try it out to prove my theory.

Amazing Security Mistakes

I asked Shelley to firm up my appointments and to make sure that she set up a meeting with the person who audited the DBS systems and other customer network connections. I also asked her to give me a copy of the audit reports.

Shelley continued talking, but I had completely tuned out. All I could think about was what I was going to find on the DBS10 system. I started thinking about my audit approach. Network auditing is great, but you can't tell everything from the network. For example, you can't tell how the filesystem permissions are set or what kinds of set user ID (setuid) scripts are being used.

I use different approaches and sometimes different tools for auditing. I always test for certain problems, however, no matter which approach or tools I use. If I miss even one important step, I could walk away while still leaving the entire system open. As a professional auditor, I can't afford to make that kind of mistake.

I figured that for now I'd just log into the network, try to access DBS10, and pinpoint the risks. After that, I'd make sure I covered the other necessary tests.

First, I checked for an NIS (Network Information Service) password map. S&B was supporting the network password file using encrypted passwords. It looked like about 100 passwords were listed in the map. I yanked my travel floppy from my briefcase and pulled out one of my favorite security tools a password-breaking program called Crack. (For details, see Appendix A, "People and Products to Know.") I started running Crack on the password file immediately. After only 60 seconds, Crack had already broken 10 passwords. And, one of them was for an account called dbadmin presumably for database administration!

My guess was that all the database servers used the dbadmin account. I was right. I now had access to all the shipping servers. I wouldn't even need to log into the account that Shelley had set up for me.

Now that I was into the network, I logged into DBS10 and verified my assumption. It was true! DBS10 was connected to Express Time's network and it had no security configured at all not even patches. After gaining full access to DBS10, I easily gained full control (root access) of the system. I was able to hop casually from one system to another as a superuser.

This was scary. I could have easily shut down these systems without leaving a trace of my visit. So could anyone who had access to either network! For any yahoo who wanted to steal data, plant a Trojan horse, unleash a virus, or set a time bomb, S&B were just sitting ducks.

I continued to test the other systems on the network and found the same security problems repeated over and over again. These systems looked like typical out-of-the-box installations. And, to that inherent risk, the system administrators had added an even riskier web-of-trust configuration.

Now I listed the major problems. Of course, at this point in this book, you've probably memorized most of this list:

  • No one had written any audit policies or procedures.

  • Likewise, no one had written any policies or procedures for supporting customer networks.

  • Support staff were not properly trained in security.

  • There was inadequate network security for customer connections.

  • Root access was far too easily attained.

  • Security patches had not been applied.

  • File permissions were being granted left and right.

  • Unnecessary network services were enabled.

  • And, your average 8-year-old could have guessed many of the passwords being used.

At this point, Shelley arrived to escort me to my interviews. I'd have to finish gathering data later on.

Untrained and Inexperienced Support

Shelley had set up my first meeting with the system administrator, Andrew Klein. Andrew had just started supporting systems on S&B's network. His prior background was in supporting mainframe systems. He'd switched to UNIX about a year earlier because he'd seen mainframes heading the way of the dinosaur.

Andrew was really new to supporting a distributed network. He thought that the DBS systems were on the customer network and were protected by a firewall. Since he didn't really understand system security, he'd never actually checked. After all, those systems had been installed before he took over the network. He'd just assumed that whoever installed them had known what he was doing.

I talked with Andrew a while about the risk to both the customers' systems and S&B's systems. He seemed genuinely surprised that the type of risk I was talking about was even possible. I strongly suggested that he get some security training if he planned to continue supporting this type of network.

My next interview was with the security administrator, Jim Barnes. Jim brought a copy of the security audits that included the DBS10 system. Glancing over it, I saw that he'd checked some of the important security configurations, but not all of them. His report had pointed out the excessive file permissions and unnecessary network services, but he'd never checked whether security patches had been applied or tried to crack the user passwords. And, of course, he missed the $64,000 question: "Why was DBS10 connecting the two networks without any firewall protection?"

Jim seemed to be a pretty smart guy, but he'd just started this job and had no prior experience in auditing systems. Jim was obviously the new kid on the block. Since they were using the sink-or-swim approach to training, the powers-that-be had just instructed him, "There. Go and audit those systems."

Of course, Jim didn't have the slightest idea how to conduct an audit properly. Asking someone to audit a group of systems without a standard approach or proper training is unwise and fairly cruel to that employee. It would be like your mechanic asking you to park your car on the railroad tracks when you both know that the car's got a bad starter. "Don't worry," he tells you. "If you run into a problem starting when the train comes, just give me a call." This is not the level of risk that companies should be willing to tolerate on their networks.

This was the end of my interviews for the day, so I headed home. So far, I was really pleased with this audit. I'd identified a lot of risk to resolve before the upgrade so that the refurbished system structure would be safe enough for use.

Days 3 and 4: Does Management Understand?

I finished gathering data to support my conclusions and wrote up the final version of my audit report. The data gathering provided me with a good bunch of juicy evidence to attach to the report.

Now I needed to spend some time explaining the risks and problems to management. These risky kinds of configurations can be difficult to understand. But you can usually tell when the situation finally clicks with the top brass. (That's usually when the color drains out of their faces.)

I left behind a nearly colorless management team at S&B Systems. Now the ball was in their court to ensure that the problems got fixed.

Summary: Outsourced Systems Must Be Secured

This case study brings to bear two very important points. First, outsourcing operations doesn't mean outsourcing responsibility for security. In fact, what usually occurs is that security responsibilities need to be clarified and redefined. Remember Chapter 7, where we talked about the need to define roles and responsibilities within your company? Well, outsourcing operations usually means that you're extending security roles and responsibilities to include a third party. The need for security doesn't go away just because you're no longer paying benefits to the staff. If anything, outsourcing usually adds a new level of complexity (in some cases, a whole new network!) to the process.

The second major point here is: "You need to test security!" No matter how you look at it, you're not going to see security problems unless you look for them. That is basically what an auditor does. The alternative is to wait for those problems to come looking for you, which is not a good strategy unless, of course, you'd like to find your own job outsourced.



IT Security. Risking the Corporation
IT Security: Risking the Corporation
ISBN: 013101112X
EAN: 2147483647
Year: 2003
Pages: 73

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net