Chapter 11
Security Policies
Chapter Objectives
After reading this chapter and completing the exercises, you will be able to do the following:
Create effective user policies.
Outline effective system administration policies.
Define effective access control.
Generate effective developmental policies.
Introduction
Throughout this book we have occasionally mentioned the topic of policies; however, our primary focus has been on security technology. Unfortunately technology alone is not a panacea for network security problems. One reason is that technology cannot be effective if people do not follow appropriate procedures. Examples of this include:
Virus software won’t prevent a user from manually opening an attachment and releasing a virus.
A technologically secured network is still very vulnerable if former employees (perhaps some unhappy with the company) still have working passwords or if passwords are simply put on Post-it notes on computer monitors.
A server is not secure if it is in a room to which virtually everyone in the company has access.
Another reason that technology alone is not the answer is that technology must be appropriately applied. Policies can effectively guide you as you implement and manage security, including security technology. In this chapter we will examine computer security policies, including the elements for creating good security policies and examples of how to establish a network security policy.
Defining User Policies
In Chapter 1, “Introduction to Network Security,” we mentioned that misuse of systems is a major problem for many organizations. A large part of the problem comes from the difficulty in defining what exactly misuse is. Some things might be obvious misuse, such as using company time and computers to search for another job or to view illicit websites. However, other areas are not so clear, such as an employee using her lunchtime to look up information about a car she is thinking of buying. Generally, good user policies outline specifically how people may use systems and how they may not. For a policy to be effective it needs to be very clear and quite specific. Vague statements such as “computers and Internet access are only for business use” are simply inadequate.
Every organization must have specific policies that will be applied fairly across the organization. In the previous example, using a general statement of “computers and Internet access are only for business use” can be problematic. Assume you have an employee who occasionally takes just a few minutes to check home e-mail with the company computer. You decide that this is acceptable, and choose not to apply the policy. Later another employee spends two to three hours per day surfing the Net and you fire him for violating company policy. That employee might sue the company for wrongful termination.
Other areas for potential misuse are also covered by user policies, including password sharing, copying data, leaving accounts logged on while employees go to lunch, and so on. All of these issues ultimately have a significant impact on your network’s security and must be clearly spelled out in your user policies. We will now examine several areas that effective user policies must cover:
Passwords
Internet use
E-mail attachments
Software installation and removal
Instant messaging
Desktop configuration
Passwords
Keeping passwords secure is critical. In Chapter 8, “Operating System Hardening,” appropriate passwords were discussed as part of operating system hardening. You should recall that a good password has in the past been defined as one that is six to eight characters long, uses numbers and special characters, and has no obvious relevance to the end user. For example, a Dallas Cowboys fan would be ill-advised to use a password like “cowboys” or “godallas,” but might be well advised to use a password like “%trEe987” or “123DoG$$” because those do not reflect the person’s personal interests and therefore will not be easily guessed. Issues such as minimum password length, password history, and password complexity come under administrative policies, not user policies. Those complexity requirements are still good recommendations. However, you should consider longer passwords, such as those 12 characters or longer. User policies dictate how the end user should behave. Later in this chapter we will discuss passphrases.
However, no password is secure, no matter how long or how complex, if it is listed on a Post-it note stuck to the user’s computer monitor. This may seem obvious, but it is not at all uncommon to go into an office and find a password either on the monitor or in the top drawer of the desk. Every janitor or anyone who simply passes by the office can get that password.
It is also not uncommon to find employees sharing passwords. For example, Bob is going to be out of town next week, so he gives Juan his password so that Juan can get into his system, check e-mail, and so on. The problem is that now two people have that password. And what happens if, during the week Bob is gone, Juan gets ill and decides he will share the password with Shelly so she can keep checking that system while Juan is out sick? It does not take long for a password to get to so many people that it is no longer useful at all from a security perspective.
Issues like minimum length of passwords, password age, password history (all mentioned in Chapter 8 on operating system hardening) are issues of administrative policies. System administrators can force these requirements. However, none of that will be particularly helpful if the users do not manage their passwords in a secure fashion.
All of this means you need explicit policies regarding how users secure their passwords. Those policies should specify:
Passwords are never to be kept written down in any accessible place. The preference is that they not be written down at all, but if they are, they should be in a secure area such as a lock box at the user’s home (i.e., not in the office right next to your computer).
Passwords must never be shared with any person for any reason.
If an employee believes his password has been compromised, he should immediately contact the IT department so that his password can be changed and so that logon attempts with the old password can be monitored and traced.
I recommend people choose a passphrase, something like ILikeCheeseBurgers, and then change the e’s to 3’s and use some capitalization. Perhaps add a symbol so it becomes #ILik3Ch33s3Burg3rs. This is a very secure password. It can be remembered and it has complexity and length.
The complexity requirements prevent dictionary attacks (using words from a dictionary) and guessing. But you might be wondering why a long password is so important. The reason has to do with how passwords are stored. In Windows when you select a password, that password is stored in hashed format in a SAM file. Now remember from Chapter 6, “Encryption Fundamentals,” that a hash cannot be undone. So when you log in, Windows will hash whatever you type in and compare it to what’s in the SAM file. If they match, you are in.
Hashing passwords leads to the use of an interesting hacking technique called the rainbow table. A rainbow table contains all the possible hashes of all the key combinations that might have been used in a password, up to a given size. For example, all the single-character combinations are hashed, all the two-character combinations are hashed, and so on up to some finite limit (often 8 to 10 characters). If you get the SAM file then you can search the rainbow table for any matches. If you find a match, then the associated plaintext must be the password. Tools such as OphCrack boot into Linux and then run a rainbow table against the SAM file. However, larger rainbow tables are cumbersome. No current rainbow tables can handle passphrases of 20 characters or more.
You can find a good reference for this discussion at http://www.passwordanalytics.com/theory/security/rainbow-table.php.
Internet Use Policy
Most organizations provide users with some sort of Internet access. There are several reasons for this. The most obvious reason is e-mail. However, that is hardly the only reason to have Internet access in a business or academic setting. There is also the web, and even chat rooms. All of these can be used for legitimate purposes within any organization but can also be serious security problems. Appropriate polices must be in place to govern the use of these technologies.
The web is a wonderful resource for a tremendous wealth of data. Throughout this book we have frequently referenced websites where one can find valuable security data and useful utilities. The Internet is also replete with useful tutorials on various technologies. However, even nontechnology-related business interests can be served via the web. Here are a few examples of legitimate business uses of the web:
Sales staff checking competitors’ websites to see what products or services they offer in what areas, perhaps even getting prices
Creditors checking a business’s AM Best or Standard and Poor’s rating to see how their business financial rating is doing
Business travelers checking weather conditions and getting prices for travel
Of course, other web activities are clearly not appropriate on a company’s network:
Using the web to search for a new job
Any pornographic use
Any use which violates local, state, or federal laws
Use of the web to conduct employee’s own business (i.e., an employee who is involved in another enterprise other than the company’s business, such as eBay)
In addition, there are gray areas. Some activities might be acceptable to some organizations but not to others. Such activities might include:
Online shopping during the employee’s lunch or break time
Reading news articles online during lunch or break time
Viewing humorous websites
What one person might view as absurdly obvious might not be to another. It is critical that any organization have very clear policies detailing specifically what is and what is not acceptable use of the web at work. Giving clear examples of what is acceptable use and what is not is also important. You should also remember that most proxy servers and many firewalls can block certain websites. This will help prevent employees from misusing the company’s web connection.
E-mail Attachments
Most business and even academic activity now occurs via e-mail. As we have discussed in several previous chapters, e-mail also happens to be the primary vehicle for virus distribution. This means that e-mail security is a significant issue for any network administrator.
FYI: E-mail Communications
Some people might still not fully grasp the extent and usefulness of e-mail communications. Many people today are working entirely or partially from home. Courses, and in fact entire degree programs, are offered on the Internet. Business associates in diverse geographical areas need to communicate. E-mail provides a way to send technical data, business documents, homework assignments, and more. More importantly, from a business/legal perspective, it provides a record of all communication. For many situations, e-mail is clearly far superior to phone communications.
As a case in point, the author of this book has never met anyone from the publishing company nor even his own agent in person. Except for a few brief phone calls, all communication pertaining to writing and producing this book has been done entirely via e-mail. Much of this involved e-mailing documents and images as attachments. This illustrates the growing importance of e-mail as an avenue for both academic and business communications.
Finding accurate statistics on office e-mail use is difficult. However, if you enter any office in any type of organization and ask any employee about the amount of business e-mail traffic they receive, you will probably find the amount to be quite large. The proportion of e-mail communication to other communication such as phone and fax is likely to continue to increase.
Clearly you cannot simply ban all e-mail attachments. However, you can establish some guidelines for how to handle e-mail attachments. Users should open an attachment only if it meets the following criteria:
It was expected (i.e., the user requested documents from some colleague or client).
If it was not expected, it comes from a known source. If so, first contact that person and ask whether they sent the attachment. If so, open it.
It appears to be a legitimate business document (that is, a spread sheet, a document, a presentation, etc.).
It should be noted that some people might find such criteria unrealistic. There is no question they are inconvenient. However, with the prevalence of viruses, often attached to e-mail, these measures are prudent. Many people choose not to go to this level to try to avoid viruses, and that may be your choice as well. Just bear in mind that millions of computers are infected with some sort of virus every single year.
No one should ever open an attachment that meets any of the following criteria:
It comes from an unknown source.
It is some active code or executable.
It is an animation/movie.
The e-mail itself does not appear legitimate. (It seems to entice you to open the attachment rather than simply being a legitimate business communication that happens to have an attachment.)
If the end user has any doubt whatsoever, then she should not open the e-mail. Rather, she should contact someone in the IT department who has been designated to handle security. That person can then either compare the e-mail subject line to known viruses or can simply come check out the e-mail personally. Then if it appears legitimate, the user can open the attachment.
FYI: About Attachments
The author of this book frequently follows the “better safe than sorry” axiom on this matter. This means that when forwarded some joke, image, Flash animation, and so on circulating the Internet, I simply delete it. That may mean that I miss many humorous images and stories, but it also means I miss many viruses. You would do well to consider emulating this practice.
Software Installation and Removal
This is one matter that does have an absolute answer. End users should not be allowed to install anything on their machine, including wall papers, screen savers, utilities—anything. The best approach is to limit their administrative privileges so they cannot install anything. However, this should be coupled with a strong policy statement prohibiting the installation of anything on users’ PCs. If they wish to install something, it should first be scanned by the IT department and approved. This process might be cumbersome, but it is necessary. Some organizations go so far as to remove media drives (optical drive, USB, etc.) from end users’ PCs so installations can occur only from files that the IT department has put on a network drive. This is usually a more extreme measure than most organizations will require, but it is an option you should be aware of.
Instant Messaging
Instant messaging is also widely used and abused by employees in companies and organizations. In some cases instant messaging can be used for legitimate business purposes. However, it does pose a significant security risk. There have been viruses that propagated specifically via instant messaging. In one incident the virus would copy everyone on the user’s buddy list with the contents of all conversations. Thus, a conversation the user thought was private was being broadcast to everyone with whom that user had messaged.
Instant messaging is also a threat from a purely informational security perspective. Without the traceability of an e-mail going through the corporate e-mail server, nothing stops an end user from instant messaging out trade secrets or other confidential information undetected. It is recommended that instant messaging simply be banned from all computers within an organization. If you find your organization absolutely must use it, then you must establish very strict guidelines for its use, including:
Instant messaging may be used only for business communications, no personal conversations. Now this might be a bit difficult to enforce. Rules like this often are. More common rules, such as prohibiting personal web browsing, are also quite difficult to enforce. However, it is still a good idea to have those rules in place. Then if you find an employee violating them, you can refer to a company policy that prohibits such actions. However, you should be aware that in all likelihood you will not catch most violations of this rule.
No confidential or private business information should be sent via instant messaging.
Desktop Configuration
Many users like to reconfigure their desktop. This means changing the background, screen saver, font size, resolution, and so on. Theoretically speaking, this should not be a security hazard. Simply changing a computer’s background image cannot compromise the computer’s security. However there are other issues involved.
The first issue is where the background image comes from. Frequently end users download images from the Internet, creating an opportunity for getting a virus or Trojan horse, particularly one using a hidden extension (e.g., it appears to be a mypic.jpg but is really mypic.jpg.exe). There are also human resources/harassment issues if an employee uses a backdrop or screen saver that is offensive to other employees. Some organizations simply decide to prohibit any changes to the system configuration for this reason.
The second problem is technical. In order to give a user access to change screen savers, background images, and resolution, you must give her rights that also allow her to change other system settings you might not want changed. The graphical display options are not separated from all other configuration options. This means that allowing the user to change her screen saver might open the door for her to alter other settings that would compromise security (such as the network card configuration or the Windows Internet connection firewall).
Termination or Expulsion
Any policy that can lead to expulsion from a school or termination from a job (or even a demotion) should first be cleared by your legal advisor and/or human resources department. There can be significant legal ramifications for wrongful termination or expulsion. The author of this book is neither an attorney nor an expert in legal matters and cannot provide you with legal advice. It is imperative that you do consult an attorney about these matters.
Bring Your Own Device (BYOD)
Bring Your Own Device (BYOD) has become a significant issue for most organizations. Most, if not all, of your employees will have their own smart phones, tablets, smart watches, and Fitbits, etc. that they will most likely carry with them into the workplace. When they connect to your wireless network, this introduces a host of new security concerns. You have no idea what networks those devices previously connected to, what software was installed on them, or what data might be exfiltrated by these personal devices.
In highly secure environments, the answer may be to forbid personally owned devices. However, in many organizations, such a policy is impractical. A workaround for that is to have a Wi-Fi network that is dedicated to BYOD and is not connected to the company’s main network. Another approach, albeit more technologically complex, is to detect the device on connection, and if it is not a company-issued device, significantly limit its access.
There are also alternatives to BYOD. For example, Choose Your Own Device (CYOD) is a policy wherein the company allows the employee to bring their own device, but only if that device is from a list of pre-approved devices. This gives the company some control over what the user is connecting to the company network.
COPE, or Company Owned and Provided Equipment, is another option. In this scenario, the company provides the device, and has complete control over it. However, this can become an issue when the employee uses a device for both personal and professional purposes, not to mention the expense of providing employees with devices, then maintaining those devices.
Whatever approach you take, you must have some policy regarding personal devices. They are already ubiquitous and spreading even more. Just a few years ago smart phones were really the only BYOD device. But today there are smart watches, smart luggage, etc., and it is difficult to predict what new devices might be coming in the future.
Final Thoughts on User Policies
This section has provided an overview of appropriate and effective user policies. It is critical that any organization implement solid user policies. However, these policies will not be effective unless you have clearly defined consequences for violating them. Many organizations find it helpful to spell out specific consequences that escalate with each incident such as:
The first incident of violating any of these policies will result in a verbal warning.
A second incident will result in a written warning.
The third incident will result in suspension or termination (in academic settings, this would be suspension or expulsion).
You must clearly list the consequences, and all users should sign a copy of the user policies upon joining the organization. This prevents anyone claiming they were not aware of the policies. It is also a good idea to re-acquaint employees with the policies from time to time, particularly if a policy changes.
It is also important to realize that there is another cost to misuse of corporate Internet access. That cost is lost productivity. How much time does the average employee spend reading personal e-mail, doing nonbusiness web activities, or instant messaging? It is hard to say. However, for an informal view, go to www.yahoo.com on any given business day during business hours, and click on one of the news stories. At the bottom of the story you will see a message board for this story. It lists the dates and times of posts. See how many posts are done during business hours. It is unlikely that all of the people posting these messages are out of work, retired, or at home sick.
The question becomes, who creates the policies? Is it strictly management? The IT department? Ideally a committee consisting of human resources and IT, with input from legal, and approval from upper management, will set policies. Policies must be carefully thought out.
Defining System Administration Policies
In addition to determining policies for users, you must have some clearly defined policies for system administrators. There must be a procedure for adding users, removing users, dealing with security issues, changing any system, and so on. There must also be procedures for handling any deviation.
New Employees
When a new employee is hired, the system administration policy must define specific steps to safeguard company security. New employees must be given access to the resources and applications their job functions require. The granting of that access must be documented (possibly in a log). It is also critical that each new employee receive a copy of the company’s computer security/acceptable use policies and sign a document acknowledging receipt of such.
Before a new employee starts to work, the IT department (specifically network administration) should receive a written request from the business unit for which that person will be working. That request should specify exactly what resources this user will need and when she will start. It should also have the signature of someone in the business unit with authority to approve such a request. Then, the person who is managing network administration or network security should approve and sign the request. After you have implemented the new user on the system with the appropriate rights, you can file a copy of the request.
Leaving Employees
When an employee leaves, it is critical to make sure all of his logins are terminated and all access to all systems is discontinued immediately. Unfortunately, this is an area of security that all too many organizations do not give enough attention to. When an employee leaves, you cannot be certain which employee will bear the company ill will and which will not. It is imperative to have all of the former employee’s access shut down on his last day of work. This includes physical access to the building. If a former employee has keys and is disgruntled, nothing can stop him from returning to steal or vandalize computer equipment. When an employee leaves the company, you should ensure that on his last day the following actions take place:
All logon accounts to any server, VPN, network, or other resource are disabled.
All keys to the facility are returned.
All accounts for e-mail, Internet access, wireless Internet, cell phones, etc., are shut off.
Any accounts for mainframe resources are cancelled.
The employee’s workstation hard drive is searched.
The last item might seem odd. But if an employee was gathering data to take with him (proprietary company data) or conducting any other improper activities, you need to find out right away. If you do see any evidence of any such activity, you need to secure that workstation and keep it for evidence in any civil or criminal proceedings.
All of this might seem a bit extreme to some readers. It is true that with the vast majority of exiting employees, you will have no issues of concern. However, if you do not make it a habit of securing an employee’s access when he departs, you will eventually have an unfortunate situation that could have been easily avoided.
Change Requests
The nature of IT is change. Not only do end users come and go, but requirements change frequently. Business units request access to different resources, server administrators upgrade software and hardware, application developers install new software, web developers change the website, and so on. Change is occurring all of the time. Therefore, it is important to have a change control process. This process not only makes the change run smoothly but allows the IT security personnel to examine the change for any potential security problems before it is implemented. A change control request should go through the following steps:
An appropriate manager within the business unit signs the request, signifying approval.
The appropriate IT unit (database administration, network administrator, e-mail administrator, and so on) verifies that the request is one they can fulfill (from both a technological and a budgetary/business perspective).
The IT security unit verifies that this change will not cause any security problems.
The appropriate IT unit formulates a plan to implement the change and a plan to roll back the change in the event of some failure.
The date and time for the change is scheduled, and all relevant parties are notified.
Your change control process might not be identical to this one; in fact, yours might be much more specific. However, the key to remember is that in order for your network to be secure, you simply cannot have changes happening without some process for examining their impact prior to implementing them.
In Practice
Extremes of Change Control
Anyone with even a few years of experience in the IT profession can tell you that when it comes to change control there are all sorts of different approaches. The real problem is those IT groups that implement unreasonable extremes. This author has personally seen both. Without using the real names of the companies involved, let’s examine a real case of each extreme:
Software consultant’s company X was a small company that did custom financial applications for various companies. They had a staff of fewer than twenty developers, who frequently traveled to client locations around the country. They literally had
No documentation for any of their applications, not even a few notes.
No change control process at all. When someone did not like a setting on a server or some part of the network configuration, they simply changed it.
No process for handling former employee access. In one case a person had been gone for six months and still had a valid logon account.
Now clearly this is alarming from several perspectives, not just from a security viewpoint. However, that is one extreme, one that makes for a very chaotic environment that is very insecure. Security-minded network administrators tend to move towards the opposite extreme, one which can have a negative impact on productivity.
Company B had more than 2,000 employees and an IT staff of about 100 people. In this company, however, the bureaucracy had overwhelmed the IT department to the point that their productivity was severely impacted. In one case, the decision was made that a web server administrator also needed database administration rights on a single database server. The process, however, took three months with one face-to-face meeting between his manager and the CIO, as well as two phone conferences and a dozen e-mails between his manager and the manager of the database group.
The company’s convoluted change control process had a severely negative impact on productivity. Some employees informally estimated that even the low level IT supervisors spent 40 percent of their time in meetings/conferences, reporting on meetings/conferences, or preparing for meetings/conferences. And the further one went up the IT ladder, the more of one’s time became consumed by bureaucratic activities.
Both of these examples are meant to illustrate two extremes in change control management that you should try to avoid. Your goal in implementing change control management is simply to have an orderly and safe way of managing change, not to be an impediment to productivity.
Security Breaches
Unfortunately, the reality is that your network will probably, at some point, have a security breach of some kind. This could mean that you are the target of a DoS attack, your system is infected with a virus, or a hacker gains entrance and destroys or copies sensitive data. You must have some sort of plan for how to respond should any such event occur. This book cannot tell you specifically how to deal with each and every event that might occur, but we can discuss some general guidelines for what to do in certain, general situations. We will look at each of the main types of security breaches and what actions you should take for each.
Virus Infection
When a virus strikes your system, immediately quarantine the infected machine or machines. This means literally unplugging the machine(s) from the network. If it is a subnet, then unplug its switch. Isolate the infected machines (unless your entire network is infected, in which case simply shut down your router/ISP connection to close you off from the outside world and prevent spread beyond your network). After implementing the quarantine, you can safely take the following steps:
Scan and clean each and every infected machine. Because they are now off the network, this will be a manual scan.
Log the incident, the hours/resources taken to clean the systems, and the systems that were affected.
When you are certain the systems are clean, bring them online in stages (a few at a time). With each stage check all machines to see that they are patched, updated, and have properly configured/running antivirus.
Notify the appropriate organization leaders of the event and the actions you have taken.
After you have dealt with the virus and notified the appropriate people, you should then have a meeting with appropriate IT staff to discuss what can be learned from this breach and how you might prevent it from occurring in the future.
Denial of Service Attacks
If you have taken the steps outlined earlier in this book (such are properly configuring your router and your firewall to reduce the impact of any attempted DoS), then you will already be alleviating some of the damage from this type of attack. Use your firewall logs or IDS to find out which IP address (or addresses) originated the attacks. Note the IP address(es), and then (if your firewall supports this feature, and most do) deny that IP address access to your network.
Use online resources (interNIC, etc.) to find out who the address belongs to. Contact that organization and inform them of what is occurring.
Log all of these activities and inform the appropriate organizational leaders.
After you have dealt with the DoS and notified the appropriate people, you should then have a meeting with appropriate IT staff to discuss what can be learned from this attack and how you might prevent it from occurring in the future.
Intrusion by a Hacker
There are specific steps you should take if you believe that your system has been compromised by an intruder. These steps will assist you in documenting the incident and preventing further harm to your system. Before going over some essential steps, keep in mind that an intrusion investigation might turn into a criminal investigation. If you don’t handle the evidence properly, the criminal case will fail. Every incident response team should have some basic training in digital forensics. And if you lack such training, do not touch the system—call a digital forensics specialist. Beginning with how one makes a copy of a drive can be critical. Chapter 16, “Introduction to Forensics,” covers the basics of forensics.
Immediately copy the logs of all affected systems (firewall, targeted servers, etc.) for use as evidence.
Immediately scan all systems for Trojan horses, changes to firewall settings, changes to port filtering, new services running, and so on. In essence you are performing an emergency audit (described in greater detail in Chapter 12, “Assessing System Security”) to determine what damage has been done.
Document everything. Of all of your documentation, this must be the most thorough. You must specify which IT personnel took what actions at what times. Some of this data may later be part of court proceedings, so absolute accuracy is necessary. It is probably a good idea to log all activities taken during this time and to have at least two people verify and sign the log.
Change all affected passwords. Repair any damage done.
Inform the appropriate business leaders of what has happened.
After you have dealt with the breach and notified the appropriate people, you should then have a meeting with appropriate IT staff to discuss what can be learned from this breach and how you might prevent it from occurring in the future.
These are just general guidelines, and some organizations may have much more specific actions they want taken in the event of some security breach. You should also bear in mind that throughout this book when we have discussed various sorts of threats to network security, we have mentioned particular steps and policies that should be taken. The policies in this chapter are meant to complement any already outlined. It is an unfortunate fact that some organizations have no plan for what to do in case of an emergency. It is important that you do have at least some generalized procedures you can implement.
Defining Access Control
An important area of security policies that usually generates some controversy in any organization is access control. There is always a conflict between users’ desire for unfettered access to any data or resources on the network and the security administrator’s desire to protect that data and resources. This means that extremes in policies are not practical. You cannot simply lock down every resource as completely as possible because that would impede the users’ access to those resources. Conversely, you cannot simply allow anyone and everyone complete access to everything.
No, this is not a nefarious plot, nor does CIA stand for Central Intelligence Agency in this instance. CIA is an acronym for Confidentiality, Integrity, and Availability. This has direct bearing on access to resources. The concept is that data must be kept confidential. That means that only those personnel with a need to know will have access to the data. Secondly, the data integrity must be maintained. This means that the data must be reliable. That involves limiting who can alter the data and under what conditions they can alter it. Finally, all data must be available to be accessed.
It is worth keeping this acronym in mind when thinking about access control. Your goal is to make sure the data is accurate, confidential, and available only to authorized parties.
This is where the least privileges concept comes into play. The idea is simple. Each user, including IT personnel, gets the least access they can have to effectively do his job. Rather than asking the question “Why not give this person access to X?” you should ask “Why give this person access to X?” If you do not have a very good reason, then do not provide the access. This is one of the fundamentals of computer security. The more people who have access to any resource, the more likely some breach of security is to occur.
Clearly tradeoffs between access and security must be made. Examples abound. One common example involves sales contact information. Clearly a company’s marketing department needs access to this data. However, what happens if competitors get all of your company’s contact information? That information could allow them to begin targeting your current client list. This requires a tradeoff between security and access. In this case you would probably give sales people access only to the contacts that are within their territory. No one other than the sales manager should have complete access to all contacts.
Defining Developmental Policies
Many IT departments include programmers and/or web developers. Unfortunately many security policies do not address secure programming. No matter how good your firewalls, proxy server, virus scanning, and policies, if your developers create code that is flawed, you will have security breaches. Clearly the topic of secure programming requires a separate volume to explore thoroughly. Nonetheless, we can consider a brief checklist for defining secure development policies. If your company currently has no secure programming initiatives, this checklist is certainly better than developing in a vacuum. It can also serve as a starting point to get you thinking, and talking, about secure programming.
All code, especially code done by outside parties (contractors, consultants, etc.) must be checked for back doors/Trojan horses.
All buffers must have error handling which prevents buffer overruns.
All communication (such as using TCP sockets to send messages) must adhere to your organization’s secure communications guidelines.
Any code that opens any port or performs any sort of communication is thoroughly documented and the IT security unit is apprised of the code, what it will do, and how it will be used.
All vendors should supply you with a signed document verifying that there are no security flaws in their code.
Following these steps will not guarantee that no flawed code is introduced into your system, but it will certainly lower the odds significantly. The unfortunate fact is that these simple steps alone are more than most organizations are taking.
Summary
In this chapter you learned that technology is not enough to ensure a secure network. You must have clear and specific policies detailing procedures on your network. These policies must cover employee computer resource use, new employees, outgoing employees, access rights, emergency response procedures, and the security of code in applications and websites.
User policies must cover all aspects of how the user is expected to use company technology. In some cases, such as instant messaging and web use, policies may be difficult to enforce, but that does not change the fact that they must still be in place. If your user policies fail to cover a particular area of technology use, then you will have difficulty taking any action against any employee who performs that particular misuse.
You also learned that it is not just the end user who needs policies. The IT staff needs clearly delineated policies covering how to handle various situations. Of particular concern will be policies dictating how to handle new and existing users. You also need a carefully considered change management policy.
Test Your Skills
MULTIPLE CHOICE QUESTIONS
1. Which of the following does not demonstrate the need for policies?
A. Antivirus software cannot prevent a user from downloading infected files.
B. The most secure password is not at all secure if posted on a note by the computer.
C. End users are generally not particularly bright and must be told everything.
D. Technological security measures are dependent upon the employees’ implementation.
2. Which of the following is not an area user policies need to cover?
A. Minimum length of passwords
B. A description of websites users may or may not visit
C. If and when to share passwords
D. What to do when the user believes your password has been compromised
3. Which of the following is not an example of a user password policy?
A. Users may not keep copies of passwords in their office.
B. Passwords must be eight characters long.
C. Users may share passwords only with their assistants.
D. Passwords may not be shared with any employee.
4. What should an employee do if she believes her password has been revealed to another party?
A. If it is a trusted employee or friend, just ignore it.
B. Change her password immediately.
C. Notify the IT department.
D. Ignore it.
5. Which of the following should be recommended as acceptable e-mail attachments?
A. Flash animations
B. Excel spreadsheets from a colleague
C. Attachments the user expected
D. Plain text attachments from known sources
6. Which of the following is the best reason users should be prohibited from installing software?
A. They may not install it correctly, which could cause security problems for the workstation.
B. They may install software that disables existing security programs on your machine.
C. Software installation is often complex and should be done by professionals.
D. If a user’s account does not have privileges to install, then it is likely that a Trojan horse will not be inadvertently installed under her account.
7. Which of the following is not a significant security risk posed by instant messaging?
A. Employees may send harassing messages.
B. Employees might send out confidential information.
C. A virus or worm might infect the workstation via instant messaging.
D. An instant messaging program could actually be a Trojan horse.
8. What is the most important characteristic all user policies must have in order to be effective?
A. They must be reviewed by an attorney.
B. They must have consequences.
C. They must be notarized.
D. They must be properly filed and maintained.
9. Which of the following is the appropriate sequence of events for a new employee?
A. IT is notified of the new employee and the requested resources. > Employee is granted access to these resources. > Employee is briefed on security/acceptable use policies. > Employee signs acknowledgment of receipt of company security rules.
B. IT is notified of the new employee and the requested rights. > Employee is given access to these resources. > Employee signs acknowledgment of receipt of company security rules.
C. IT is notified of the new employee and assigns requested rights. > Employee is briefed on security/acceptable use. > Employee signs acknowledgment of receipt of company security rules.
D. IT is notified of the new employee and assigns default rights. > Employee signs acknowledgment of receipt of company security rules.
10. Which of the following is the appropriate sequence of events for a departing employee?
A. IT is notified of the departure. > All logon accounts are shut down. > All access (physical and electronic) is disabled.
B. IT is notified of the departure. > All logon accounts are shut down. > All access (physical and electronic) is disabled. > The employee’s workstation is searched/scanned.
C. IT is notified of the departure. > All physical access is shut down. > All electronic access is shut down.
D. IT is notified of the departure > All electronic access is shut down. > All physical access is shut down.
11. Which of the following is the appropriate sequence for a change request?
A. Business unit manager requests change. > IT unit verifies request. > Request is implemented.
B. Business unit manager requests change. > IT unit verifies request. > Security unit verifies request. > Request is scheduled with rollback plan. > Request is implemented.
C. Business unit manager requests change. > IT unit verifies request. > Request is scheduled with rollback plan. > Request is implemented.
D. Business unit manager requests change. > IT unit verifies request. > Security unit verifies request. > Request is implemented.
12. What is the first step after discovering a machine or machines have been infected with a virus?
A. Log the incident.
B. Scan and clean infected machines.
C. Notify appropriate management.
D. Quarantine infected machines.
13. What is the best rule of thumb in access control?
A. Allow the most access you can securely give.
B. Allow the least access job requirements allow.
C. Standardize access for all users.
D. Strictly limit access for most users.
14. After dealing on a technical level with any security breach, what is the last thing to be done for any security breach?
A. Quarantine infected machines.
B. Study the breach to learn how to prevent a reoccurrence.
C. Notify management.
D. Log the incident.
15. Which of the following is a list of items that should be implemented in all secure code?
A. All code checked for back doors or Trojans, all buffers have error handling to prevent buffer overruns, and all communication activity thoroughly documented
B. All code checked for back doors or Trojans, all buffers have error handling to prevent buffer overruns, all communication adheres to organizational guidelines, and all communication activity thoroughly documented
C. All code checked for back doors or Trojans, all buffers have error handling to prevent buffer overruns, and all communication adheres to organizational guidelines
D. All code checked for back doors or Trojans, all communications adheres to organizational guidelines, and all communication activity thoroughly documented
EXERCISES
Each of these exercises is intended to give you experience writing limited portions of a policy. Taken together, the exercises represent a complete policy for a college campus computer network.
EXERCISE 11.1: User Policies
1. Using the guidelines provided in this chapter (and other resources as needed), create a document that defines end user policies in an academic setting.
2. The policies should clearly define acceptable and unacceptable use for all personnel.
3. You may require some separate policies for administration, faculty, and students.
EXERCISE 11.2: New Student Policy
1. Using the guidelines provided in this chapter (and other resources as needed), create a step-by-step IT security policy for implementing a new user account for a student.
2. The policy should define which resources the student will have access to, what she will not have access to, and the duration of her access.
EXERCISE 11.3: Departing Student Policy
1. Using the guidelines provided in this chapter (and other resources as needed), create a step-by-step IT security policy for handling user accounts/rights for a student that is leaving prematurely (drops, is expelled, etc.).
2. You will need to consider specialized student scenarios, such as a student who works as an assistant to a faculty member or as a lab assistant in a computer lab who may have access to resources most students do not.
EXERCISE 11.4: New Faculty/Staff Policy
1. Using the guidelines provided in this chapter (and other resources as needed), create a step-by-step IT security policy for implementing a new user account for a faculty or staff member.
2. The policy should define what resources the employee will have access to, what she will not have access to, and any restrictions. (Hint: Unlike student policies, you will not need to define time length since it should be indefinite).
EXERCISE 11.5: Leaving Faculty/Staff Policy
1. Write a policy for how to handle a faculty or staff member’s departure (e.g., quit, fired, retired, etc.). Use the guidelines in this chapter and any other resources you like to get you started.
2. Make certain you consider not only shutting down access but the possibility of proprietary research material existing on the faculty or staff member’s workstation.
EXERCISE 11.6: Student Lab Use Policy
1. Considering the material in this chapter, create a set of policies for acceptable use of computer lab computers.
2. Make sure to specify web use, e-mail use, and any other acceptable uses.
3. Carefully spell out unacceptable usage (e.g., is game playing acceptable?).
PROJECTS
PROJECT 11.1: Examining Policies
1. Examine the following web resources that discuss security policies:
AT&T Acceptable use policy: https://www.att.com/legal/terms.aup.html
Brown University Acceptable use policy: https://it.brown.edu/computing-policies/acceptable-use-policy
SANS institute policies: https://www.sans.org/security-resources/policies/
2. Summarize the main theme of these policy recommendations. Pay particular attention to any area in which these recommendations differ from or exceed the recommendations of this chapter.
3. Choose the policy recommendation you believe is the most secure, and state the reasons for your choice.
PROJECT 11.2: Examining Security Policies
1. Ask a local business or your college for a copy of its security policies. Study the policies carefully.
2. Summarize the main theme of these policy recommendations. Pay particular attention to any area in which these recommendations differ from or exceed the recommendations of this chapter.
3. Choose the policy recommendation you believe is the most secure, and state the reasons for your choice.
PROJECT 11.3: Create Your Own Policies
Note: This project works well as a group project.
1. At this point in the book you have studied security, including policies. After this chapter and the preceding exercises and projects, you have examined several polices from various web resources, as well as the policies of some actual organizations.
2. Take the brief policies you created for the exercises in this chapter and expand them to create an entire working security policy for your academic institution. You will need to add administrative policies, developmental policies, and more.