Home > Articles > Software Development & Management

Unplanned Security: Risk Assessment

Security expert Linda McCarthy shares a case study of security for a hospital computer network and provides a short risk assessment checklist to help you determine if your organization is at risk. Whenever new systems are added, system platforms are changed, or any major organizational modifications are undertaken, you need to redo your risk assessment.
This chapter is from the book

Imagine for just a moment that it's 6:30 a.m. and you're a patient in a hospital waiting for surgery. It's a routine operation to remove your gall bladder (one of those throwaway parts), and no big deal. What you don't know, however, is that the hospital's computer network was recently redesigned. The support staff moved all of the critical applications from the mainframe to a distributed network environment (right-sizing it). In the rush to move from one platform to another, management never developed security policies and procedures for the new systems. So the hospital support staff never configured security. On the surface, the right-sized network is running smoothly. Underneath, however, anyone on the hospital network can steal, modify, or destroy patient information on the servers.

Yesterday, when you were admitted to the hospital, you had some pre-op testing done to make sure that you don't have an infection. They did blood work and a chest X-ray—the standard pre-op stuff. You wake up early the next day, 4:00 a.m., and your surgery isn't for several hours. You wake because you're a little nervous about getting that gall bladder removed. After considering the problems it was giving you, you decide you'll be better off without it. Feeling calm, you fall back to sleep and have a few pleasant dreams.

Six a.m. rolls around. The doctor calls down from the operating room. He tells the nurse that he wants the results of your pre-op tests sent with you to the operating room. Since the results haven't come back to the floor yet, the nurse logs into the computer to get your results. They're normal. Or, at least they are now.

What your nurse doesn't know is that a hacker broke into the server and changed your test results from abnormal to normal. Before the information was modified, the results of your lung X-ray review noted a questionable shadow—maybe just congestion, or maybe pneumonia. Results that would tell your doctor to postpone the surgery to avoid possible complications that could lead to respiratory failure.

Since your doctor doesn't get those results, he operates anyway. Your gall bladder takes the route your tonsils fell to many years ago. It appears to have been a successful operation. That is, until the anesthesiologist notifies your surgeon that he can't seem to get you off the respirator. He orders a repeat chest X-ray which shows a dense pneumonia. He then requests your pre-op X-ray that shows a smaller shadow in the same area. He calls your surgeon wanting to know why he did an elective surgery on a patient with preexisting pneumonia. Your doctor can't be reached because he is busy filling out your death certificate. Guess what? Your lungs gave out—you're dead.

This is one case when the safety of the data means more than protecting information—it means protecting lives. Pretty scary when you consider just how much real hospitals rely on their computers. Just consider?

Transition Plan

Like many other institutions in its league, Rockland General decided to advance its computer operations by right-sizing its network. The plan was fairly straightforward. Roll the legacy systems (mainframes) out the door; roll in advanced architecture to move Rockland into the 21st Century. In preparation, Rockland's staff designed and installed a high-performance distributed network. Then, as planned, they rolled out the mainframes.

Rockland's executive staff saw the right-sizing effort as a huge success. The MIS managers who spearheaded the effort, Joe Davis and Marlene Schmidt, were promoted and glorified throughout the medical profession. Other hospitals sought their advice for similar projects. Joe and Marlene were so successful that they founded their own company, assisting hospitals worldwide with right-sizing needs.

When Matt Borland took over the new systems, he soon found that all was not as great as it appeared to be. Since Joe and Marlene left the hospital as heroes, it was only a matter of time before Matt took the heat for the mess they left behind.

In a previous life, Matt had been a system administrator. So he understood what it took to keep systems up and running. He felt lucky to take over the computer operations for Rockland General. He was advancing in his career, now a third-level manager, and this was an opportunity for him to advance another rung on the corporate ladder. Joe and Marlene's right-sizing efforts had enshrined them as heroes with prior management, and Matt knew that hard work would pay off for him, too.

What Matt soon discovered was that Joe and Marlene painted a pretty picture for the world. What they left behind, however, was a high-risk computer room with tons of proprietary information available to anyone on the hospital network to copy, modify, or steal. Since Matt had thought that he was taking over a top-notch system, he wasn't happy at this discovery.

If you've recently taken over the support responsibilities for new systems, maybe you should take a closer look at Matt's predicament. Do you know where the high-risk systems are on your network? Did your predecessors leave you a security nightmare that you don't know how to deal with?

In the introduction to this chapter, I got a bit melodramatic with the death by poor system installation. Unfortunately, that really could happen.

Every day, managers, CIOs, and system administrators take over systems that were installed by other people. Unless they actually audit those systems (something done only rarely), they simply assume that the systems are safe. That's a risky assumption. It's difficult to place the blame on previous management and support personnel after you have owned systems for six months or more. When you take over new systems, immediately test those systems to find out where you stand. Regardless of what Mo, Larry, or Curly might have done in the past, at the end of the day, it's now your system and your job on the line. If you're a manager, you are responsible for the reliability and integrity of the data. If you're a system administrator, accusing fingers will always point at you. After all, don't you support the systems?

Matt took over management of operations, but he was so busy making sure that the systems were available (because that was his #1 goal), that he never considered security to be a problem. Lucky for him, an unscheduled audit of the computer room uncovered the risks. If that hadn't happened, he might have lost his job, or at least his good reputation. And who knows, someone could have lost their life.

It was strictly by chance that Rockland General's management got a view of the real picture. Unless you have a good view of the security state of your network, you might not be so lucky. So let's take a closer look at the details of this audit.

Day 1: Testing Security

When Matt took over management of the hospital's computer operations, he started to look at ways to improve network performance and support. It was very important for him to keep the system up and running. In fact, that was one of Matt's goals—system availability.

System availability is an important goal. If you can't access patient information because the systems are down all the time, you have a problem (and a highly visible one at that). Matt made sure that he had the right tools to report network availability. The operations crew ran daily and monthly reports on the availability of the systems. One system administrator was even responsible for sending those daily and monthly reports on to Matt. Matt took a keen interest in the performance and availability of the network.

At about the same time, the hospital's auditors decided to conduct an unscheduled security audit. As part of their approach, no one from computer operations was notified of the audit—not even Matt.

It's funny how you can work at a company for ten years and not even know who the internal auditors are. They really do exist. And, they can show up at the drop of a hat. That is, if they smell risk in your area. Auditors are a different breed altogether. They look for risk, report the bad stuff, and try to reduce the risk.

Maria Plank, Rockland General's audit manager, hired me to conduct an audit on their computer room. Like most hospital auditors, Maria didn't understand the systems side of the house. That wasn't a problem for her. She could smell risk a mile away. It was in her blood. She heard some rumblings at a high level about risk in the computer room and decided to hire someone to conduct the audit for her. She didn't need to figure out what (if anything) was at risk: all she needed were the results from the expert. That's where I stepped into the picture.

Understanding Risk

When I spoke with Maria, she didn't give me much information. She just said she suspected risk. I asked her for a network map of the computer room and a list of the suspected high-risk systems.

Maria set up a visitor's office for me with a phone and system. She also gave me an account on the system—just in case I wanted to write my report there. That was nice. I took a look at the network map. Wow, they had a ton of database servers. That wasn't surprising, since that's what happens after a major right-sizing effort. What was surprising was that none of those servers were assigned risk classifications. That is, none were marked critical, mission critical, or noncritical.

Since Maria had no idea which servers were high risk, I needed to discover that myself. There are two ways to get that information. You can log into the servers and look around to see what they are storing. (This method takes a lot of time when you have a lot of servers.) Or, you can ask the system administrator. I couldn't do that because he wasn't supposed to be aware of the audit. Back to approach one. At this point, I was playing a game. The goal of that game was to uncover as much data and risk as possible before being detected.

Phase One: Physical Security

To start the game, I needed to put on a suit and dress the part. After all, my first goal was to get into the computer room without authorization. When I put on a suit, Bingo! I look like I belong.

Maria offered to sign me into the computer room, but I turned her down. An important part of my audit would be seeing whether I could let myself in without attracting suspicion. That's why I wore the suit.

Phase Two: Getting Past Physical Controls

I asked Maria to wait for me in my office and told her I'd call if I couldn't get in. It was easy to tell that she liked my approach. (I actually think that she wanted to go with me just to see me get away with it. But she knew that it wouldn't work if she were there.) If it did work, that would say a lot about security right off the bat. Surely a setup that gave virtually anyone access to the main computer room without authorization would indicate very high risk. If I succeeded, Maria would already have her money's worth. Any other risks I found would be icing on the cake.

With that in mind, I made my way down to the basement computer room. On paper, you had to have a badge with access enabled to get in. I picked up the phone by the entrance and waited for a guy standing in the computer room to answer.

When he answered, I informed him that I'd been sent by internal auditing to check on some systems. He immediately opened the first door and welcomed me. There were actually two sets of doors to get into the computer room, meaning, two levels of security. As I passed through the second set of doors, it occurred to me that neither level was being very effective. There were several main consoles to the left where my greeter seemed to be working. After introducing himself, he walked back to his phone to continue the conversation he'd been having when I knocked. Mission accomplished. He was distracted. I looked official. I was in.

The servers were lined up in tidy little rows and the place looked very clean. Not one piece of paper was left out. Nothing was left on the printers, either. Even the floors were spotless. There weren't even any cables hanging from the ceiling; every cable must have been hidden under the floors. You could tell that these guys put a lot of work into making this computer room look good.

I wandered up and down the rows looking for a monitor that someone might have forgotten to log off. No luck. I'd have to get onto the network another way. I thanked the guy who'd let me in, flashed a smile, and walked out.

Even though I couldn't easily access information once I was in the computer room, I could have left a bomb and destroyed their entire operation. You never know. That's why good physical security is necessary.

Although their physical security left a lot to be desired, Rockland General obviously kept a very clean computer room. Or, at least it was clean on the day I showed up. A week later, I might have found it littered with patient files. But for today, they were running 50/50 on my tests.

Phase Three: Unauthorized Access

Walking back to my office, I wondered how I could access those systems in the computer room. When I got back to my office, I logged in. I glanced at the network map to see if I could identify a system that might contain some juicy data.

Sometimes, people give their systems obvious names (like payroll) so that you know what data's on them before you even log in. Not here. The systems were all named with a letter/number combination (PR1, PR2, etc.). No clues.

I started probing a random system for information. Wouldn't you know it? I was able to access the system. I pulled out a travel floppy from my brief case and loaded some of my favorite tools onto the system. Tools make life easy. A few good tools can make all the difference in the world. My plan was to try to get into a system as a regular user, break root, and take over the system.

I began by testing to see if any of the systems in the computer room trusted me. In this case, trusted means that those systems were set up to trust my system. A trusted system allows you easy access without a password. (Trust relationships on networks can be dangerous, because if a hacker breaks into one system and 50 other systems trust that system, the hacker can then log into those 50 systems without a password.) When the script was done running, the results showed that I was trusted by ten systems. Not too bad for me. But definitely bad for the hospital, bad for the data, and bad for the patients.

I was in. Once I have a login to a machine, I have a pretty good chance of obtaining data. Just as I logged into the first machine, PR1, Maria strolled into my office. I told her that I was able to get into the computer room without any problems, but hadn't been able to access any data from there. She was incredulous that just anyone could walk in. That's when I explained to her my reasons for wearing the suit.

Moving on, I updated Maria on my successful approach to entering a system in the computer room. I let her know that I'd spend the rest of the day gathering data. I asked her to set up meetings with the lead system administrator and operations manager for the next day. She agreed, looked pleased, and walked away.

It was only a matter of time, about a minute, before I had full control of the system. If you're familiar with break-in techniques, that probably seems pretty long. In any case, the ten systems I had easy access to were running an old version of the operating system. (Older versions of operating systems can leave a system vulnerable, because old security bugs that hackers can easily exploit most likely exist.) It looked like those systems were running applications that hadn't been ported to the new version of the operating system. At least, that was my guess.

I filed that thought and began looking for access to the rest of the systems. You know, it's amazing how quickly time flies when you're having fun. Before I knew it, it was approaching 5:00 p.m. At any time, I expected Maria to stop by and walk me out. I was ready to leave. Tallying up my successes over the day, I'd been able to gain access and obtain full control of 60 servers. It seemed that Rockland's system administrators had installed their systems right out-of-the-box without configuring security or adding patches. They also made a lot of my work easy by configuring a good number of the servers to trust each other.

As a potential patient, I was beginning to find the situation scary. All of the critical systems were accessible and so far as I could tell, there weren't any audit trails. (An audit trail identifies activity of users or actions involved.) An experienced hacker could run rampant and leave without ever being detected. After all, I'd personally cracked 60 servers today and no one seemed the wiser.

Maria showed up at 5:15 p.m. I didn't give her the full story yet. I let her know that I was able to get into some systems but was still gathering data. Sometimes it's best to get to the end of an audit before you share the information. I also hate to pass on bits and pieces before I have all the facts.

Maria let me know that she'd set up interviews for the next morning. I would be meeting with the operations manager, Matt Borland, and the system administrator, Jill Rosenberg. Since Maria was so prompt in her scheduling, I would need to finish my testing after the interviews.

Day 2: Personal Information at Risk

I met with Matt first. He seemed like a nice guy, but clearly interested in upward mobility. Sometimes you meet people in business and just know that's their agenda. Of course, that was his agenda, not mine. My agenda was understanding the risks and gathering data. Matt didn't have much information for me. He had other managers reporting to him, but I didn't want to waste my time talking to them. I finished the small talk with Matt and decided to move on.

At this point, Matt passed me to Jill, the system administrator supporting the systems. Jill was calm, but hardly thrilled at being interviewed and audited. (I can't say that I blame her, but someone has to do it!)

I began the interview by requesting the policies and procedures. She had them ready for me. For the most part, the documentation looked good. However, the security section was very short (almost nonexistent). Jill explained that they were currently working on that part.

I was curious how they'd configured the systems for security during right-sizing without writing the procedures first. They hadn't. Management knew that there was no security, but the schedule was tight, so they decided to address security issues later. As a result, Rockland had been operating the new network for over a year without security.

In addition to not securing the systems, Rockland's staff had never classified them. My next job was to grill Jill on system contents. Getting those facts from her would allow me more time for testing, information gathering, and report writing. I needed to know which systems contained the most critical information, what kind of information that was, and why she considered it critical. That information would let me target the most important systems for my audit.

Jill knew where some of the critical data was, but it hadn't occurred to her to add a higher level of security to those systems. From Jill's data, however, I now understood where the juicy stuff was.

In my career, I have often seen auditors ask the staff which systems they want the audit tools run on. Sometimes the staff answers honestly. Sometimes they don't. Even without direct subversion, however, support staff don't always understand the high-risk areas on their own networks. So, even if someone tells you that DS19 is the highest-risk system, you still need to verify that information.

Jill pointed out that the patient records were on PR1 through PR10. Aha! Now I knew what the PR was for—Patient Records. I guess I just hadn't given it enough thought before. Anyway, those systems would be considered mission critical and should have security controls in place. As I mentioned earlier, though, those had been the first systems I'd broken into.

Jill's information was right on the mark. I verified that by checking the operating systems and system types, and by examining the data that the systems were holding. Having verified that step, I decided that I had enough data to write a report. Of course, there were a lot of security problems. But the top problems on my list were:

  • No one had ever completed a risks assessment.

  • The policies and procedures were incomplete.

  • Systems containing highly sensitive information had been installed right out-of-the-box.

  • Data could be easily modified, stolen, or destroyed without a trace.

Obviously, no one had paid enough (or any?) attention to the risks of change, destruction, or theft of data when the data was moved from the mainframe to a server environment. As a result, all of the patient records were at risk.

Summary: Plan Outsourcing Carefully

Moving systems from one platform to another is not an easy task. Before right-sizing a computing environment or moving systems to a new platform, a risk assessment needs to be done. In addition, new policies and procedures must be developed to reflect the new environment.

At the same time, system administrators need to be trained on how to provide security within the new system.

The old management in this scenario really played their cards right. With great pizazz, Joe and Marlene built the system, collected the applause, and moved on. Unfortunately, the new network they designed contained some pretty major security problems.

In real life, the cards that Joe and Marlene played are not that unusual. In network design, security often drags down the schedule and blows up the budget. Even worse, it doesn't win the type of attention that precedes big promotions. After all, management doesn't really want to be reminded of what can happen when security fails.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020