The Scoop
The ABC’s of a Security Policy
Mimi Carpenter
Abstract
Any corporation that is serious about doing business in today’s workplace needs to take care of its security, both physical plant security and network security. Most companies wouldn’t question this assertion, but by the same token most companies have no idea where to start in implementing a security policy. In this paper, I will attempt to not only describe what a security policy is but also how to design and implement one in order to insure a company’s maximum physical and network security.
What is a Security Policy
A security policy is, simply, a statement or a set of rules that defines a company’s security-related decisions. It can be very simple, or it can be as complex as necessary. The only thing that is true about every security policy is that every security policy is different.
It’s important to differentiate a security policy from security procedures. Procedures are part of a policy, but the policy determines what the procedures will be, not the other way around. In other words, “we do it this way” does not determine what your actual security policy is. Policy drives procedure, not the other way around.
In some companies, the same person or persons will be in charge of the total security of the company, from door keys to firewalls. In other cases, physical security and digital security will be handled by different groups. However your company decides to do it, it makes sense to have at least some overlap between your physical security and digital security personnel, even if that overlap simply consists of regular meetings between the groups, and there should be one security policy that covers both groups.
Physical Security
Physical security involves access to the actual physical plant or plants and the physical data therein, such as hard copy files and such. Most companies will have, at very minimum, locks on their doors, but as time goes on companies are finding it more and more necessary to more closely secure the physical plant. For instance, companies are finding that if their facility is broken into and data stolen, they cannot prosecute unless they have taken certain mandated steps to protect the physical plant and its contents.
Network Security
Network security is much like physical security in that it involves access to servers and their data; the difference is that it is less tangible and therefore seems harder to understand. However, if you look at your servers as similar to the physical plant, and your access control as similar to the access control methodologies employed at the physical level, then it’s fairly easy to understand. And again, there is some overlap between the two; you want to physically secure your servers (in a locked rack behind a locked door, for instance) as well as virtually secure them.
Why a Security Policy is Necessary
Once you realize that security is, itself, necessary, it’s obvious that the next step is to draw up a security policy. However, security policies take many forms. Some companies keep their procedures written down and subjected to constant audit; other companies keep their security policies in the security officer’s head. The correct way to develop and maintain a security policy depends on the type of company, its size, what it does, and government regulations pertaining to all these things. However, even if the security policy is never committed to writing, it surely exists the moment a company goes beyond putting simple locks on the doors or restricting network share access.
Security Threats
There are several different types of threat to a company’s security, both physical and network-related.
Hackers and/or Corporate Spies
When companies consider security, they first think of hackers or corporate spies: malicious persons who are trying to compromise a company for either personal or competitive reasons. And indeed, these malicious agents are probably a company’s largest security threat, whether the intrusion is “just because” or to gather sensitive data for competitive reasons. Hackers and spies are really the raison d’etre of corporate security, but having said that, it’s not always obvious exactly how to deal with them. Because of their existence and the fear resulting from their existence, there are large physical and network security industries (which have some overlap) that deal with detecting possible intruders and neutralizing their threat.
Visitors
Visitors are a major security risk for a company, but at the same time it is almost impossible to prevent their access. Sometimes visitors are customers or shareholders in the company and have a legal right to have access to the physical plant or even the network. Sometimes they are a friend or close relative of an employee. And sometimes they are a vendor or service representative. Each of these visitors can pose a risk to a company’s security, and each should be dealt with in different ways.
If a company requires all visitors to sign in and out at a single point of entry, and perhaps also wear a badge identifying them as a visitor, then it is much easier to control the access that any visitors will have to sensitive data or areas. In addition, a company can have different types of badges or escort requirements based on the purpose of the visit. For instance, although many employees are inclined to be less stringent with friends and relatives, a company should actually be more stringent with such visitors who have no actual company business; they should be restricted to the reception area and/or escorted constantly, or at minimum receive a badge that differentiates them from visitors that have company business.
Corporate Users
Many companies think that they should be able to trust their employees, but, despite background checks at time of hire, it’s not always possible to insure that the people working for a company have that company’s best interests in mind. Sometimes the threat that employees pose involves is as simple as petty thievery of office supplies; sometimes it can be as complex and damaging as tie-in to corporate spies on the outside. A company should never assume that its employees are trustworthy; by the same token, it is bad for morale to assume the very opposite and treat the employees as if they were all potential criminals. It’s useful in cases where employees pose a significant risk to have the relevant parts of the security policy revealed to the employees and signed by them (to indicate understanding and agreement).
The Cleaning Staff
A company’s cleaning staff is “silent” in the sense that most members of the company never see or interact with the cleaning people themselves, or the cleaning company, as most cleaning companies contract their staff to come in after business has closed. Sometimes a company has complete control over the selection and use of the cleaning staff; sometimes, as in a large office building, the cleaning staff is hired by the building management.
In general, a company does not or should not worry about its cleaning staff maliciously compromising security. Most after-hours cleaning companies are bonded, which means that if something is missing or broken the cleaning company is responsible. However, this does not mean that it’s a good idea to leave personal valuables or company valuables lying around at the end of the business day; if they’re stolen, then the damage is done no matter who is responsible.
Methods
Unfortunately for the corporate security officer, there are myriad ways to compromise a company’s security.
Brute Force
Brute force means either physically breaking something to get in, or, in case of a network, using unsophisticated methods over a long period of time to batter down the network defense.
Social Engineering
Social engineering involves manipulating someone in the company to give the agent information that will allow him to get sensitive data, or perhaps even giving him the data itself, by posing as a person who should have access to that information or data.
Denial of Service
Denial of service is a sort of “backwards” type of security threat; it involves not gaining access to sensitive data but denying it to persons who should have it, by making access difficult or impossible. If a company’s legitimate agents cannot do their jobs, then the malicious agent may accomplish his objective without actually needing access to the corporate secrets himself.
Door Rattling
Door rattling generally precedes some other type of attack; it means doing some preliminary checking to see if the malicious agent can discover any obvious vulnerabilities.
Malicious Leaks
Malicious leaks come from the inside, and involve a trusted employee giving sensitive data to an agent on the outside. Many malicious leaks come from disgruntled employees or corporate spies.
Viruses and Trojans
Viruses and Trojans are solely network attacks; the idea is to corrupt data or remove it, crippling a company.
How to Write a Security Policy
Sitting down to write a security policy can seem like a daunting task, because the company’s security touches on every department and every individual in that company. When planning a security policy from the ground up, you have to answer questions that you may not have thought of before because you may have thought of them as covered by existing policies that you did not have a hand in formulating. For instance, when considering access to your office space outside of regular business hours, you have to consider not only your company’s needs but also the priorities of the building management, which has its own security policy.
You also have to consider both the limits of your current hardware and software, and plan for implementation of new hardware and software to achieve your security goals. This takes a great deal of knowledge and research. The good thing is that a security policy is always a work in progress; if your security solution is not complete, well, that’s what the periodical reviews and re-implementations are for.
Determining Risk
The first thing you should do when formulating your security policy is to determine what your company’s risks are. Sit down, clear your mind, and ask yourself the following question:
What asset is it that, if it were compromised, would
make our company most suffer?
In most cases, of course, that question will be easy to answer: the subject of your business is your most important asset. For instance, if you are an insurance provider, your most important asset is patient data; if you are a bank, you most important asset is your customers’ money. However, sometimes it’s not so simple. For instance, if you are a software vendor, obviously your proprietary code is a very important asset. But consider also, particularly if you run a managed service, the proprietary data of your customers. Any vendor of security software will tell you that one of their most jealously guarded secrets is their customer list, and the customers mandate that as much as the salespeople do. After all, you don’t want potential hackers to know which security solutions you are using, the better to hack you. So sometimes the answer to “what is my most important asset” will have more than one question.
And that’s fine. The more precious assets you have, the more complex your security policy will be, certainly. But remember, you have just one basic goal for your security policy, and that is to protect those assets. Any other goals are secondary.
Once you’ve listed your assets, you need to identify the various risks to those assets. For instance, say again that you are a software vendor. Your two main risks, both presented by your competition, are theft: theft of your code and theft of your customer list (and perhaps customer secrets). You also need to keep in mind that other people, if they come across this data, might be persuaded to sell it to your competitors or go into business against you, so it is not only your competition themselves that you have to watch out for.
When you’re identifying risks, go for the inobvious as well as the easy to spot ones. For instance,
here in sunny
Identifying Trouble Spots
After you have your assets and the primary risks to them identified, you need to think about things that could present a possible problem in physically and digitally securing those assets. At the top of the list should probably be the words “Front Door.” Think about it: every day, potentially hundreds of risks to your assets come into your company through your front door, from potentially dishonest employees, to deliverypersons, to cleaning and maintenance staff, interviewees, and so on. You’ll notice that each type of person I’ve listed has a legitimate reason to come in through that front door, but each person also presents a potential risk. And that totally leaves out people who do not have a legitimate reason to enter but who try to fool you into thinking that they do.
Obviously, you need to be very careful of your front door. In the same way, you need to think of your network’s perimeter as a potential trouble spot. You need to let some legitimate network traffic in: email, web clients, and so on. However, each legitimate connection you permit carries a risk, never mind the possible illegitimate connections that hackers will attempt to make.
The proliferation of wireless network cards and access points presents another trouble spot. It takes only a minute or two to set up a wireless access point; virtually all WAPs are set up not to use encryption by default; and typically, WAPs are accessible for several hundred feet. If you have undiscovered wireless networks in your office, you are essentially inviting the general public to participate on your network. That’s definitely a trouble spot.
Your telephone system is a potential trouble spot, for several reasons. One is social engineering, the same as the front door. Another is that very often companies do not have complete control over who has access to their phone closet. Phone hacking was popular long before anyone had heard of the Internet, and it remains popular among some hackers today. It’s not amiss to list “phone system and hardware” as a potential trouble spot.
Disasters and Acts of God
As I mentioned, a disaster such as an earthquake presents a risk to your assets. The risks that disasters and “acts of God” can present are so important to consider that some security professionals specialize solely in disaster recovery (also called business continuity).
I’ll discuss disaster recovery in depth in Chapter 11, but when you are formulating your security policy, you need to think about what you will do if a disaster occurs. For instance, say the building that houses your offices burns down. Do you have a way to recover your data and your other assets? Do you have a place for your employees to work while you’re either finding a new permanent space or waiting for the old one to be rebuilt? In short, do you have a way to continue carrying on your business if “the worst” happens, or will you have to shut down?
Planning for disaster is usually not the first thing that comes to mind when setting up a business, or even necessarily when thinking about physical and digital security. However, it should very much be part of your security policy. Even if the first time around you have to leave a lot of “to be decideds” on your disaster recovery checklist, as time goes on your should be making plans for failover and contingency.
Site Scans
Once you have identified potential trouble spots, you will want to begin scanning your perimeter and your internal network(s). Remember, as I mentioned in Chapter 5, your best defense is in knowing what your vulnerabilities are. In Chapter 10 I discuss network scanning and penetration testing in more depth; it’s a step you don’t want to skip when certifying your network as secure.
Typically, you’ll do a scan initially to determine what your vulnerable points are before doing any hardening or tightening. When the vulnerability report comes back, you’ll want to start working on the vulnerabilities that it discusses. Keep in mind that your security team is not always the entity responsible for making the changes. For instance, if your mail server has vulnerabilities, you’ll want the admin in charge of that server to patch it, and so on.
After you’ve made all the changes you deem necessary, and perhaps brought your new security architecture online, you’ll want to scan again to make sure that you didn’t miss anything when applying patches or turning off non-essential services. Typically you’ll have missed some things, or perhaps there will be new vulnerabilities in the meantime; remember that new flaws are always being published for whatever operating system you choose to base your network on. After another period of patching and tightening, you’ll want to institute regular network scanning on a regular basis, perhaps once a week or once every two weeks. I wouldn’t suggest scanning any one segment any less often than once per month at the absolute minimum.
Making Rules
You’ve identified your assets and the risks to them, thought of potential trouble spots, and checked your network for vulnerabilities. Now comes the fun part: you get to decide on the actual rules of who gets to do what. There are three sorts of rules that you need to make:
* who gets in;
* who gets out;
* who gets to do what.
In your typical network, you’re going to want to keep most people on the outside from getting to most of your systems inside, and you’re going to let at least some of your users on the inside access everything, or almost everything, on the outside. However, as mentioned in previous chapters, sometimes you need to let people on the outside do things on the inside, and sometimes you want to prevent people on the inside from having certain types of access to resources on the outside, or even resources on other inside networks. If you are an educational institution, you may not have an “inside” and an “outside”, per se, which can vastly complicate matters when it comes to securing your systems; a well thought out security policy, with distinct rules as to what types of people get what types of access, will help when deciding how to implement a security architecture.
“Who gets to do what” is not quite the same thing as “Who gets in/out”. What “who gets to do what” means is that you need to decide who will be allowed certain types of access whether they are inside or outside. For instance, your network admins (employees/inside) can go into the server room; other employees cannot. Those individual admins may have access to some, but not all, of the machines contained in that server room. Not everyone has access to all the same resources, even if they can all “get inside”.
How to Implement a Security Policy
Writing your security policy can be complicated enough, but once you’re finished writing it, have reviewed it and sanity checked it, and have gotten it approved by your Executive Committee or Board of Directors, the hard part begins. Now you have to implement it. It’s one thing to say that you are going to put up a firewall and allow only (for example) SMTP access inbound; it’s another thing to price a firewall and then put it in place without any significant downtime. This may be a good time to beef up your security team; if you’ve come this far with just one person who has a good general security background, you may want to look into hiring or contracting with people who have the specific knowledge to get your security solutions in place.
First you should probably implement new physical security solutions, such as building or suite access controls, badges, bioscanning stations, or whatever else you have decided you want to use to physically secure your assets. Obviously, the more important the asset, the more rigorous your physical security should be. Key cards are great for the front door, but you might want to look into bioscanning (such as fingerprint scanning) for your server room, for instance.
You also want to begin implementing your plans for what to do in case of a disaster. I discuss disaster recovery planning in depth in Chapter 11; at the least it will involve failover/high availability systems, but in more extreme cases you’ll want to consider colocation.
Next on your list should be implementing your network security. As discussed in Chapter 5, a well-rounded security solution can include one or more firewalls, NIDs, HIDs, and scanning devices. You want to pay attention to network structure and design, utilizing your resources so that everyone who needs to access them can do so, while disallowing intruders from getting to them.
After you have implemented your security solutions, you should make sure that your personnel are aware of your security policy. You may or may not want to publish all of it, but you do need to publish part of it (the part that states what employees may and may not access, and may and may not do with that access and the associated resources), and your employees need to sign off on it. Your security team will probably want to hold educational seminars once a year or so to acquaint users with security procedures and instruct them how to deal with social engineering attacks. As mentioned in Chapter 4, social engineering is probably the most effective attack that potential intruders have against your company; don’t underestimate the importance of educating your employees about how to combat it.
Periodical Policy Review
Once your security policy and all your new systems and solutions are in place, the security policy process is anything but over. Once a year, at a minimum, you want to sit down with your executive committee and your security team and review the current security policy, procedures, and architecture for obsolescence and efficacy. Be aware that even if you spent hours with your security team sweating out the exactly right solution or phrasing, your security policy cannot be considered to be written in stone in order to be effective over time. You must be constantly willing to change it as the times change and threats to your assets change with them.
Conclusion
Writing a security policy can be a daunting task, but it’s worth it to take the time to do it and do it right. Once written, a security policy is never set in stone, but changes and grows with the company. Periodical review of the security policy, and the parts that comprise it, is essential and should be at least a yearly task for any company that takes Internet security seriously.