WATCH THE DOOR

Sometimes, a physical security measure can be something as simple as

watching the door. Once, while visiting a client, I noted that one of the doors in their highly secure data center closed very slowly and, in fact, didn’t shut completely on its own. While walking down the hall, I asked one of my company’s engineers to see if he could reenter the room without the required biometric. He could. Needless to say, we quickly alerted the client. The point here is, test anything connected to security. Don’t get burned by something as simple as a door not closing properly. It makes little sense to put all these safeguards in place only to have them, essentially, fly out the door.

The point is, you’ve got to know the source of your infrastructure compo- nents and, then, you have to test them. Consequently, your policies and proce- dures for this security element involve testing and review by a team of subject matter experts, who are responsible for ensuring that software like the one I just described isn’t unwittingly unleashed on your network.

25. Support Interface: Protecting Confidential Information

All organizations have employees and contractors who have access to confi- dential information, everything from detailed information on how to adminis- ter infrastructure components to an employee’s Social Security number. Typically, these include help desk staff, customer support representatives, human resources employees, and others. All employees with such access must understand how to handle this sensitive information. This is accomplished by writing very specific policies and procedures that help support staff under- stand how to handle sensitive and confidential information and high-impact system administration. Next, an aggressive training program for support interface policies and procedures needs to be put in place. As noted in number 27, “Training: Achieving Security through Education,” support interface poli- cies and procedures should also be practiced during scheduled drills.

26. Testing, Integration, and Staging: Get It Right before Betting the House on It

Deploying a complex system without first testing and staging (that is, simu- lating a real environment) is like performing surgery on a patient without ster- ilizing the instruments. One of the most serious mistakes you can make in implementing a security plan is to connect a new machine to a live network without first staging and testing it. Unfortunately, this is what most people do. Bluntly put, you cannot build a secure system that is connected to a live net- work because while you’re securing it, a hacker could be taking advantage of the vulnerabilities you have yet to lock down.

Systems must be staged and built offline on isolated networks, those not connected to anything but other systems being built. You need policies and procedures that detail how to test, stage, and deploy software on your net- work. Then you must test systems before you deploy them. For example, if you decide to implement a vulnerability analysis system, do not simply set the thing loose on your live network. They have been known to crash live systems. Test first. The same goes for just about anything else affected by security. After you have tested, deploy, but first on a limited basis if possible; collect informa- tion, then make a decision whether to complete the deployment or return to the lab for further testing.

27. Training: Achieving Security through Education

No security plan is complete without a policy that makes ongoing training mandatory for general staff, contractors, and security staff. A training program

should incorporate classes, presentations, formal training, posters, and any other mechanisms that will reinforce to employees the importance of security. The training program should also define procedures for carrying out this training, the objective being to practice the security strength of your organiza- tion and thus the effectiveness of this training. You should conduct role- playing drills, for example, to simulate a hacker attempting to convince a help desk employee to provide a password to a system. The following is an exam- ple from my own experience.

I called a company specializing in security to make a change to my account. Instead of first asking me for my account number and then my password (which they need to make changes), I was asked only to “please provide your password.” Seeing this as an opportunity, I shot back, “But that makes no sense; many people could have the same password as I do.” Apparently my question rattled the company representative a bit. She then provided—with- out my asking—the full names of five people who had the same password as mine. She wanted to prove that if I had simply given her my password with- out making such a point of it, she still could have determined my name. She indicated this by telling me that she intended to ask for my name after I pro- vided my password. In this way, she explained, she could ultimately narrow down who I was. I suppose the idea here was that no two people would ever likely have the same password. What a complicated, contrived, inefficient, and, most importantly, insecure scheme, and what a poorly trained support representative. I thanked her for providing the password for five other people.

This is a good example of how a poorly trained employee, working with a poorly designed infrastructure, can easily get rattled and provide information he or she shouldn’t—in this case, potentially very damaging information.

28. Recovery: Getting Back on Track

Finally, we come to recovery. Obviously, you need to be able to recover from a security incident. To do that, you should include contingency planning as part of your security effort, in case things don’t go as expected. One of the most important aspects of a recovery plan is a solid backup/restoration plan. Unfor- tunately, many organizations run backups but never practice restoration. Restoring often fails because data, programs, and so forth are correlated, and if you restore one thing but not something else, often the entire system is bro- ken. You need to have a backup and restoration plan that takes into account data dependencies of all kinds, from business data to configuration informa- tion used within your machine that you may need to restore.

That said, it’s important to be aware that repairing, as opposed to rebuild- ing, a hacked system is dangerous and a nearly impossible task. Why? Because you don’t know exactly what the hacker did. Therefore, part of your restora- tion activity is to know how to rebuild a system, from scratch, to a certain level,

apply any needed patches in response to the security compromise, then care- fully determine what—if any—data can be restored back over that machine. Obviously, hackers modify data to their advantage, so a security plan that con- siders this is necessary. An IDS can help here, assuming that the IDS itself wasn’t compromised and that what it reports can be relied on, as it can help point us to things that have been tampered with. Still, this is a messy process that requires detailed knowledge of data dependencies. Therefore, your backup plan has to clearly state exactly what will be backed up, including sys- tem files and configuration data, not just information relevant to the business process itself. It must state how often data will be backed up and whether full backups or incremental backups will be performed. Also, because hackers have a way of destroying anything they can access online, remember that highly reliable online storage systems aren’t enough. You need backups of sys- tems, and these backups need to have physical disconnection and storage away from the real-time systems.

An important aspect of a backup plan is to store media off-site at a secure location. It seems like common sense to do this, but I repeatedly find clients who do not perform off-site backups. They just don’t take this risk seriously enough. Fire, theft, flood, or vandalism can cost a company its ability to sur- vive. I’m reminded of a technology company whose building was burned down by the employees of a competitor. The company went out of business because it didn’t maintain off-site backups; all of its backups were in the burned building.

In your recovery policies and procedures, detail the steps required to imple- ment the recovery and contingency plan. These policies and procedures should include mandatory, regularly scheduled drills to practice recovery and contingency procedures. Then, address any problems discovered during these drills through revision of associated planning documents and processes.

Conclusions

It should be clear from these first two chapters that security planning is a mul- tidimensional effort. It touches every aspect of our organization—people, business, and technology. A security plan that works is one that addresses real- world issues in a balanced fashion and, at the same time, is well organized. In the next two chapters, we combine our security template and 28 security ele- ments, forging them into a powerful tool you can use to write your own secu- rity plan. In Chapter 3 we’ll focus on the fundamental security elements, and in Chapter 4 we’ll walk through the core and wrap-up elements. Those two chapters also include the security worksheets you’ll use to complete your own security plan.

79

3

In this chapter, we begin the process of completing the security worksheets that will serve as your guide throughout the security planning process. The worksheets contain an important starter set of questions and pointers. When you address them conscientiously and plan accordingly, the result will be a comprehensive security plan. Note that many of the questions demand more than a simple yes or no or a one- or two-sentence response. Certain questions point to the need to develop a detailed technical plan of some kind or to write related polices and procedures.