Showing posts with label Network. Show all posts
Showing posts with label Network. Show all posts

Saturday, July 4, 2009

JCAHO Accreditation SealHOW THOUGHTLESS DECISION-MAKING & SLOPPY HOUSEKEEPING NEARLY HIJACKED A HOSPITAL’S JCAHO

In 2005, twenty servers running a critical application at the busiest hospital in Illinois were consolidated into one physical server. Instead of reaping the benefits of consolidation, disaster struck. (Its name will go unmentioned but you’ll find it out if you read on.)

Hospital management anticipated the usual benefits that virtualization brings:
  1. Easier administration. Caring for one server is easier than caring for 20.
  2. Greater confidence in the IT infrastructure. The storage that accompanies virtualization is likely to be more reliable than the distributed storage of standalone servers. This reliability is a product of newer technology and a more efficient design.
  3. Peace of mind. Virtualized storage complements or fits well with its business continuity features. VMware’s VMotion, for instance, empowers the human administrator to migrate virtual machines to backup servers in real time.
Unfortunately these benefits did not happen. They lost data and, for a time, they risked, first, losing JCAHO accreditation and, second, punitive action from CMS.

(Click here to learn why JCAHO accreditation is important to a hospital.)

How did this happen?

After the virtual environment was created, the IT staff added standard security controls to each new virtual server. This was fine as this is standard procedure. However, some of those virtual servers lay dormant. In fact, it appears that nearly a dozen servers were created for “testing” purposes. These were not removed after they had served their purpose. (I actually think that most of them were created for the novelty of it. How do you account for servers named “Tyrone” or “Michael Jordan?”) During the months that these servers lay dormant, Microsoft and the application vendor had issued patches. When these dormant servers were reactivated, they were not updated with those patches. The servers thus turned into potholes or, worse, security vulnerabilities waiting to be compromised. It didn’t take long for that to happen. Consequently, the hospital lost data.

We were brought in to sort out the mess.

LESSONS LEARNED

What did we take away from this incident?

First, virtual servers must be managed individually and managed from their creation to their removal.

Second, management of these servers consists of staying abreast of patches, installing them as needed and meticulously documenting the patches that were installed. These steps have to be done for the virtual environment, the guest operating system and the application. These steps are crucial especially because of staff turnover.

Finally, management of the virtualized data center should be handled by capable hands. The integrator may have configured the virtual environment properly when it was created. However, we all know that things change over time. Someone has to take ownership of staying abreast of these changes. In the hospital’s situation, the virtual environment unraveled in steps. Visualize these: (1) a new appliance was installed, (2) a new server was created, (3) a new application was implemented, and (4) Microsoft issued more security patches. All of these events most likely took place. Consequently, failing to update the relevant pieces or updating the pieces incorrectly would have caused problems. Note that there are two hurdles: (1) identify the pieces that need to be updated and (2) do the updates correctly. At the end, we discovered two network links that were dead ends. We think these links had prevented two or more virtual servers from communicating.

While that was a technical AHA!, the bigger picture shows the consequences of a thoughtless decision. The hospital had stopped paying maintenance fees to the integrator. It attempted to maintain the environment on its own. This was unwise since the IT staff did not have trained personnel. The VLAN’s configuration developed potholes and compromised security. This is how a combination of thoughtless decision-making and sloppy housekeeping nearly hijacked a hospital’s JCAHO accreditation and risked punitive action from CMS. (This was a major reason. During that period, the hospital was cited for numerous violations.)



Sphere: Related Content

Saturday, February 10, 2007

AN EASY AND COMPREHENSIVE EXPLANATION OF THE OSI MODEL

"All People Seem To Need Data Processing."

"Please Do Not Throw Sausage Pizza Away."

Either way, these are the two mnemonics for the OSI model of the ISO’s standard networking protocols. In the 1990s when I was studying for my various certifications (Novell’s CNE, Microsoft’s MCSE, and Cisco’s CCNA), I learned those two mnemonics. I'd like to pass the knowledge along to the next generation. You might not find this information presented this way anywhere else.


The International Standards Organization (ISO) developed a model to serve as a standard point of reference for networking protocols. It uses seven layers to break down the networking process into seven independent processes. OSI stands for Open Systems Interconnection.

These are the seven OSI layers, listed from the outermost to the innermost layer.

APPLICATION
This is where network services and applications reside. These services and applications utilizes the formats established in the Presentation layer.

PRESENTATION
This is where file and file access formats reside; examples of file formats are PostScript, ASCII, Microsoft Word; examples of file access formats are Sun Microsystem's Network Filing System (NFS) or Microsoft's New Technology Filing System (NTFS).

SESSION
This layer serves two functions. First, it establishes and maintains the inter-nodal connections (i.e., connections between nodes). And second, it maintains the logical sequence of message exchanges.

TRANSPORT
This layer ensures the reliable delivery of messages. If one portion of the message transmission is lost or garbled, this layer re-transmits the necessary portion.

NETWORK
This layer addresses the messages for delivery. It functions like an envelope wrapper for the message. The envelope has the recipient's address and the sender's return address. These are logical addresses that are specific to the networking protocol that is used (e.g., IP). The envelope is known as a datagram.

DATA LINK
This layer refers to the specific kind of communication medium being employed. It places the datagram inside the network's delivery vehicle - generically known as a frame. Network delivery frames are specific to the particular kind of communication medium (e.g., Ethernet or Token Ring).

PHYSICAL
This describes the actual physical media being employed (e.g., network interface card). This layer often has its own form of addressing in addition to the protocol-specific logical addressing. For example, each Ethernet node (e.g., the network interface card or NIC) has a permanent unique 48-bit hardware address. The first 24 bits identify the device's manufacturer. The second 24 bits identify the specific device. Example of an Ethernet device's hardware address: 08-22-12-32-12-12.

To be continued...


Sphere: Related Content