This chapter is from the book
This chapter is from the book
This chapter is from the book
Let's Not Go There...
Doing a major overhaul of a large computer system is a situation rife with possibilities for security lapses. At the very least, you're exposed to a new learning curve as the system administrators come up-to-speed on the new system.
In this case, that learning curve could have been fatal to some of Rockland General's patients. Thankfully, luck was with them.
Good fortune notwithstanding, here's what Rockland General should have done instead.
Assess Risks
Before moving data between platforms, always perform a risk assessment. By its very nature, some data is inherently riskier than other data. In this case, that risky data was the patient records.
If a risk assessment had been done, management would have identified that risk and taken steps to ensure the privacy of that data. They could have added better access control, auditing, intrusion detection, and encryption to the patient record systems.
Classify Systems
Systems should be classified and secured based on the level of risk to the data. The basic classifications are noncritical, critical, and mission critical. Once classified, the systems should be configured based on the company's data-protection policy.
Since each company has a different culture and is responsible for protecting its own data, the classifications and levels of security need to be determined on a case-by-case (company-by-company) basis.
In this case, the only person who had even a vague idea of the system classifications was Jill. And that's only because she'd been around for awhile. That's not the way to run computer operations. You must know what you're trying to protect. Otherwise, you can't be sure whether the current level of security is adequate.
Forbid Out-of-the-Box Installations
We talked about this earlier (in Chapter 2), but it's worth repeating here. Out-of-the-box installations are high-risk for any company that doesn't have good policies and procedures in place. These types of installations can leave gaping holes on your network.
Why leave an open invitation to hackers when you can take another approach? Instead, implement the proper policies and procedures for installing systems on your network.
Don't Be Too Trusting
Trust can be a scary thing on networks that aren't properly configured. Once you are into one machine, other machines trust you to log into them. If you must use a trusted configuration (and there are few cases when it's absolutely necessary), you need to make sure that adequate security exists on the trusted machine. That can be a hard thing to do. Whenever possible, look for a less risky alternative.
Learn from the Past
It's often said that people who don't remember history are doomed to repeat it. New managers and system administrators should not assume that the security of the systems they're taking over is adequate without checking it themselves—regardless of the reputations of their predecessors. If this audit hadn't uncovered the pre-existing problems, Matt could have found that trusting Joe and Marlene's reputations had destroyed his own.
Target Budget Cuts
Few funding sources are bottomless, and the age of economy is definitely upon us. Even so, cutting corners to stay within budget is always risky.
This is where classifying systems has added benefit. You don't want to start adding security randomly with the first system to the left and then stop when you run out of money. If you've run your risk assessment and classified your systems, you can take a more practical approach. You can use that information to target budget cuts to the areas in which they'll do the least harm.
Ideally, of course, you really should add proper security to every system. But if your budget truly can't handle that right now, you want to make sure that the mission-critical systems are protected first.
Conduct Security Testing
Use security audits as a tool for assessing the risk level in the environment.
Rockland General should have conducted a security audit before moving the systems to the new platform. Such an audit would have pointed out the security risks that existed and helped the computer-room staff to obtain proper funding for the conversion.
Of course, they should have done a lot of things. My guess is that the computer operations staff resisted the initial audit because they didn't really want to point out the existing risks to management. Why go to such lengths to show your superiors problems that you don't know how to fix?
Hold Management Accountable
Another obvious problem at Rockland General was that the managers were clearly short-term thinkers—"Get your bonus and run kind of folks." Given a corporate culture that was accepting of people passing through between promotions, security should have been part of their job descriptions! No security, no bonus. Furthermore, personnel should have made more of an effort to hold onto top talent. Or, at least they could have tried to assign only managers who seemed permanent to support mission-critical machines.
Clearly, the final responsibility for security risks lies with management. But, it does little good to put the blame on people who are no longer around.
Don't Set Yourself Up
System administrators often take the heat for security, even when it isn't their fault. Don't be surprised if the manager who refused to approve proper funding to support security is also the first one to pounce on you when something goes wrong.
It never fails that when something happens to the machines you support, people will put the blame on you. If you're working for a company that won't fund security support or training, maybe you should be thinking about updating your resume.
Include Training in Budgets
Changing platforms and radically altering configurations means that you're taking away all the stuff that your people really know. Before you do that, make sure that you train them on the new stuff. System administrators don't just wake up one morning and find that they've mysteriously assimilated NT operations in their sleep. They need someone who knows to tell them which patches to apply, which services to disable, and so on.
At Rockland General, the computing staff moved all the hospital's mission-critical data from a mainframe they knew how to support to an unfamiliar distributed environment. And, in the process, management never provided them with even a single security class. Small wonder that security became such a big problem!
Keep Score
We've already talked about the types of risks inherently caused by short-term thinking. Now, let's talk about one way to avoid those risks: keep score!
Executive management should score employees at all levels on security. No manager responsible for computer operations should receive a bonus check unless his or her security goals have been attained. Likewise, system administrators should be scored on how well they protect data—not just how well they keep the network up and running.
Checklist
Use this checklist to determine whether your company is at risk because it doesn't really understand what the risks are. Can you mark a "Yes" beside each item?
|
___ |
Was a risk assessment completed recently? |
|
___ |
Have systems been classified by risk level (noncritical, critical, mission critical, etc.)? |
|
___ |
Are management's goals tied to security? |
|
___ |
Are routine audits conducted to verify risk-assessment conclusions? |
|
___ |
Are external auditors used when appropriate in assessing and reducing risk? (Sometimes data owners just don't understand the value of what they've got!) |
|
___ |
Are all employees (managers, as well as system administrators) assigned and evaluated based on security goals? |