ISO 17999

ISO 17799 is a standard on how to develop policies. Policies are often not viewed as exciting security topics; however, the core of your security posture is your policies. Thus, it is critical to develop policies appropriately.

ISO/IEC 17799:2005 describes best practices related to control objectives and controls in the following areas of information security management:

• Security policy

• Organization of information security

• Asset management

• Human resources security

• Physical and environmental security

• Communications and operations management

• Access control

• Information systems acquisition, development, and maintenance

• Information security incident management

• Business continuity management

• Compliance

It is a good idea to develop familiarity with this standard and at least consider its recommendations when developing policies.

Let’s briefly review some of these standards.

NIST SP 800-53

The National Institute of Standards and Technology (NIST) in the United States publishes a number of standards relevant to cybersecurity. NIST SP 800-53 (where SP stands for special publication, though it is often omitted) identifies 18 families of security controls (listed in Table 10.1). NIST 800-53 is a good reference when analyzing your system security policies.

ISO 27001

ISO/IEC 27001 requires that management:

• Systematically examine the organization’s information security risks, taking account of the threats, vulnerabilities, and impacts.

• Design and implement a coherent and comprehensive suite of information security controls and/or other forms of risk treatment (such as risk avoidance or risk transfer) to address those risks that are deemed unacceptable.

• Adopt an overarching management process to ensure that the information security controls continue to meet the organization’s information security needs on an ongoing basis.

(Note that ISO 27001 is designed to cover much more than just IT.)

ISO 27002

ISO 27002 recommends best practices for initiating, implementing, and maintaining information security management systems (ISMS). This standard starts with several introductory chapters that provide guidance about terminology and the scope of the standard. The chapters starting with Chapter 5 cover important ISMS topics:

• Chapter 5: Information Security Policies

• Chapter 6: Organization of Information Security

• Chapter 7: Human Resource Security

• Chapter 8: Asset Management

• Chapter 9: Access Control

• Chapter 10: Cryptography

• Chapter 11: Physical and Environmental Security

• Chapter 12: Operation Security: Procedures and Responsibilities

• Chapter 13: Communication Security

• Chapter 14: System Acquisition, Development, and Maintenance

• Chapter 15: Supplier Relationships

• Chapter 16: Information Security Incident Management

• Chapter 17: Information Security Aspects of Business Continuity Management

ISO 17799

Perhaps the standard most obviously connected to policy development is ISO 17779 (titled “How to Develop Security Policies”). This standard establishes guidelines and general principles for initiating, implementing, maintaining, and improving information security management in an organization.

ISO/IEC 17799:2005 describes best practices and control objectives in the following areas of information security management:

• Security policy

• Organization of information security

• Asset management

• Human resources security

• Physical and environmental security

• Communications and operations management

• Access control

• Information systems acquisition, development, and maintenance

• Information security incident management

• Business continuity management

• Compliance

Passwords

Keeping passwords secure is critical. Chapter 8, “Encryption,” discusses appropriate passwords as part of operating system hardening. Most sources indicate that a good password is at least 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 such as %trEe987 or 123DoG$$ since those don’t reflect the person’s personal interests and therefore would not be easily guessed. Issues such as minimum password length, password history, and password complexity come under administrative policies, not user policies. User policies dictate how the end user should behave. For reliable security, I recommend using a passphrase that has been altered to include numbers and special characters. This can be something easy to remember but altered so that it will not be vulnerable to guessing or brute-force attacks. An example would be altering the phrase “I like double cheeseburgers” to be something like IliK3double3ch33$eburg3r$. Notice that the Es were changed to 3s, the Ss were changed to $s, and two random letters were capitalized. You now have a 25-character password that is also complex. It is easy to remember and very difficult to break.

However, no password is secure, no matter how long or how complex, if it is listed on a sticky 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 email, and more. 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 that 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.

Administrative policies need to address issues like minimum length of passwords, password age, and password history. System administrators can force these requirements. However, none of that will be particularly helpful if users don’t 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 the following:

• Passwords are never to be kept written down in an 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 your home (not in the office right next to your computer).

• Passwords must never be shared with another person for any reason.

• If an employee believes his password has been compromised, he should immediately contact the IT department so his password can be changed and so that logon attempts with the old password can be monitored and traced.

Internet Use

Most organizations provide their users with some sort of Internet access. There are several reasons for this. The most obvious reason is email. 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. (Believe it or not, chat rooms are being used for business communications.) The Internet can be used for legitimate purposes within any organization, but it can also bring about serious security problems. Appropriate policies must be in place to govern the use of Internet technologies.

The World Wide 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 non-technology-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, and to perhaps even get prices

• Creditors checking the business’s AM Best or Standard & Poor’s rating to see how their business financial rating is doing

• Business travelers checking weather conditions and getting prices for travel

• Online training with webinars

• Web meetings

• Online bill payment or in some cases even filing of regulatory and government documents

Of course, there are other web activities that are clearly not appropriate on a company’s network:

• Using the Web to search for a new job

• Any pornographic use

• Any use that violates local, state, or federal laws

• Use of the Web to conduct your own business (if you have another enterprise you are involved in other than the company’s business)

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 an organization have very clear policies detailing specifically what is and what is not acceptable use of the Web at work. It is also important to give clear examples of what is acceptable use and what is not. 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.

Email Usage

Most business and even academic activity now occurs via email. As we have discussed in several previous chapters, email also happens to be the primary vehicle for virus distribution. This means that email security is a significant issue for any network administrator.

Clearly, you cannot simply ban all email attachments. However, you can establish some guidelines for how to handle email attachments. Users should open an attachment only if it meets the following criteria:

• It was expected. (Someone requested documents from a colleague or client.)

• If it was not expected, it came from a known source. If so, first send that person an email (or phone her) and ask if she sent the attachment. If so, open it.

• It appears to be a legitimate business document (a spreadsheet, a document, a presentation, and so on).

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, which are often attached to email, 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 email itself does not appear to be 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 email. Rather, she should contact someone in the IT department who has been designated to handle security. That person can then either compare the email subject line to known viruses or can simply come check out the email personally. Then, if it appears legitimate, the user can open the attachment.

Installing/Uninstalling Software

When it comes to installing and uninstalling software, there is an absolute answer: End users should not be allowed to install anything on their machines. This includes wallpaper, screensavers, utilities—anything. The best approach is to limit end users’ login privileges so that they cannot install anything. However, this should be coupled with a strong policy statement prohibiting the installation of anything on their PC. 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 or at least disable media drives (CD, USB, and so on) from end-user PCs, so installations can occur only from files that the IT department has put on some network drive. This is usually a more extreme measure than most organizations require, but it is an option you should be aware of. In fact, Windows allows the administrator to disable allowing new USB devices. So the admin can install some USB devices that are approved for corporate use and then disallow any additional devices being added.

Instant Messaging

Instant messaging is widely used and abused by employees in organizations. In some cases, instant messaging can be used for legitimate business purposes. However, it does pose a significant security risk. Some viruses specifically propagate via instant messaging. In one incident, the virus would copy everyone on the user’s buddy list with the contents of all conversations. Thus, if you were subject to the virus, a conversation you thought was private ended up being broadcast to everyone you had ever messaged with.

Instant messaging is also a threat from a purely information security perspective. Nothing stops an end user from instant messaging trade secrets or confidential information without the traceability of email going through the corporate email server. It is recommended that instant messaging simply be banned from all computers within an organization. If you find you absolutely must have it, then you must establish very strict guidelines for its use, including the following:

• Instant messaging can only be used for business communications, not 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 such rules in place. Then if you find a person violating them, you can refer to the company policy that prohibits such actions. However, you should be aware that in all likelihood, you won’t catch most violations of this rule.

• No confidential or private business information should be sent via instant messaging, text messaging, or any sort of messaging app. The exceptions being if it is absolutely vital to send such information and the app has robust security including encryption. The Signal app is one example of a secure communications app.

Desktop Configuration

Many users like to reconfigure their desktops, changing the background, screensaver, font size, and resolution. Theoretically speaking, this is not a security hazard. Simply changing your computer’s background image cannot compromise the computer’s security. However, there are other issues involved.

The first issue is where a background image comes from. Frequently, end users download images from the Internet. This means there is a chance of getting a virus or Trojan horse, particularly one using a hidden extension. (For example, a file that appears to be mypic.jpg may really be mypic.jpg.exe.) There are also human resources/harassment issues involved if an employee uses a backdrop or screensaver 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 users access to change screensavers, background images, and resolution, you must give them rights that also allow them 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 users to change their screensaver might open the door for them to alter other settings (such as the network card configuration or the Windows Firewall) that would compromise security.

Bring Your Own Device

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 activity monitors that they will carry with them into the workplace. Having these devices connected to your wireless network introduces a host of new security concerns. You have no idea what networks each device previously connected to, what software was installed on them, or what data might be exfiltrated by these personal devices.

In highly secure environments, it may be necessary 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.

Whatever approach you take, you must have some policy regarding personal devices as they are ubiquitous. Just a few years ago, smart phones were common but smart watches were not. It is difficult to predict what new smart devices might loom on the horizon.

There are a variety of approaches to handling user devices on an organization’s network, some of which have their own acronyms:

• CYOD (choose your own device): The company lists acceptable devices (that is, those that meet company security requirements) and allows each employee to choose his or her own device.

• COPE (company owned/personally enabled or company-owned and provided equipment): The company owns and provides the equipment. This clearly offers more security than BYOD or CYOD but also comes at the highest cost.

• COBO (company owned/business only): This model provides the most security. The company owns and operates the equipment, and corporate IT services control the device and options for the device.

Final Thoughts on User Policies

This section has provided an overview of appropriate and effective user policies. It is critical that every 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 following:

• 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 the case of 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 being hired to prevent employees from claiming that they are not aware of the policies.

It is also important to realize that there is another cost to misuse of corporate Internet access: lost productivity. How much time does the average employee spend reading personal email, doing nonbusiness web activities, or social media? 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 date and time of posts. See how many posts are made during business hours. It is unlikely that all of those people are out of work, retired, or at home sick. You will find something similar on any social media platform.

Let me be completely clear: The Internet is the single greatest communication tool in human history. And it can have a tremendous positive effect on any business. I conduct almost all of my business activities through the Web. However, many employees abuse their Internet privileges, and using the Web does decrease productivity for those who cannot be self-disciplined. Here are just a few studies supporting this assertion:

• A 2022 article reporting on multiple studies claimed that 89% of workers admit to wasting time every day.¹ It is often the case that widespread Internet access actually inhibits productivity rather than enhancing it.

  1. https://www.zippia.com/advice/wasting-time-at-work-statistics/

• Ohio State University researchers found regular Facebook users had a lower GPA than nonusers.²

  2. http://content.time.com/time/business/article/0,8599,1891111,00.html

• Multiple studies have shown that Facebook at work has a negative impact on productivity. Most of these studies are a few years old because it has become well established that social media at work hurts productivity.³,⁴,⁵

3. http://www.cnbc.com/2016/02/04/facebook-turns-12--trillions-in-time-wasted.html

4. http://www.riskmanagementmonitor.com/the-risks-of-social-media-decreased-worker-productivity/

5. http://www.shellypalmer.com/2011/05/social-media-use-drastically-reduces-work-productivity/

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 function requires. The granting of that access must be documented (possibly in a log). It is also critical that the new employee receive a copy of the company’s computer security and 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 the person will be working. That request should specify exactly what resources this user will need and when she will start, and it should 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.

Departing 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 too many organizations do not give enough attention to. You cannot be certain which employees will bear the company ill will and which won’t upon leaving the company. It is imperative to have all of a 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 need to 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 email, Internet access, wireless Internet, cell phones, and so on are shut off.

• Any accounts for mainframe resources are canceled.

• 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 (such as proprietary company data) or conducting any other improper activities, you need to find out right away. If you do see any evidence of 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 to be concerned about. However, if you do not make it a habit of securing employees’ access when they depart, you will eventually face an unfortunate situation that could have been easily avoided.

Change Requests

The nature of information technology 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, and web developers change the website. Change is occurring all the time. Therefore, it is important to have a change control process. This process not only makes the change run smoothly, but it also 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:

1. An appropriate manager within the business unit signs the request, signifying approval of the request. In other words, there is no point in pursuing the change request process if the immediate supervisor of the requestor has not approved the request.

2. The appropriate IT unit (database administration, network admin, email admin, cloud administration) verifies that the request is one it can fulfill technologically, fits within budget constraints, and does not violate IT policies.

3. The IT security unit verifies that this change will not cause security problems. This is becoming more and more critical in modern times.

4. 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. That latter part is very critical and is often overlooked. There must be some mechanism to roll back the change should it cause any problems.

5. 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, it 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 the impact of those changes prior to implementing them.

Change management activities are frequently managed through a change control board (CCB) process, sometimes also called a change approval board (CAB) process. The change process was detailed previously in this section, but the basic process can be summarized as follows:

1. Initiate the process with an RFC (request for comments or request for change) document.

2. Send the RFC for approval.

3. Set the priority of the process.

4. Assign the process to whomever makes the change.

5. Document decisions.

6. Have the CAB evaluate changes.

7. Schedule the RFC.

8. Have the change owner and requester verify successful implementation of the change.

9. Review the RFC.

This process can involve formal meetings of the CAB and extensive documentation, or it can be informal and conducted via emails with the appropriate parties.

Virus Infection

When a virus strikes your system, immediately quarantine the infected machine or machines. This means literally unplugging the machines from the network. If it is a subnet, then unplug its switch or disconnect wireless access. 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:

1. Scan and clean each and every infected machine. Since the machines are now off the network, this will be a manual scan.

2. Log the incident, the hours/resources taken to clean the systems, and the systems that were affected.

3. 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.

4. Notify the appropriate organization leaders of the event and the actions you have taken.

5. After you have dealt with the virus and notified the appropriate people, have a meeting with appropriate IT staff to discuss what can be learned from this breach and how you might prevent it from occurring again in the future.

DoS Attacks

If you have taken the steps outlined earlier in this book (such as properly configuring your router and your firewall to reduce the impact of any attempted DoS attack), then you will already be alleviating some of the damage from DoS attacks. In addition, consider taking the following measures:

• 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 the IP address(es) access to your network.

• Use online resources (interNIC.net and so on) to find out who the address belongs to.

• Contact that organization and inform it of what is occurring.

• Log all of these activities and inform the appropriate organizational leaders.

• After you have dealt with the DoS attack and notified the appropriate people, 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

What do you do if a malicious hacker has intruded into your network? In other words, what are the basics of incident response? Consider taking the following measures in the event of intrusion by a hacker:

• Immediately copy the logs of all affected systems (firewall, targeted servers, and so on) 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 need to perform an emergency audit to see 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 be part of later 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 have a meeting with appropriate IT staff to discuss what can be learned from this breach and how you might prevent another one from occurring in the future.

These are just general guidelines, and some organizations may want to take much more specific actions 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 be in addition to any already outlined in this book. 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.

Data Classification

It is critical to classify information within an organization. This process is common in Department of Defense (DoD)–related agencies and organizations. It is less common in the civilian sector. Classifying information provides employees with guidance on how to handle data. Classification can be as simple as using two categories:

• Public information is information that can be disseminated publicly to anyone. There are no restrictions on who can view the data.

• Private information is intended only for use internally in the organization. This type of information can potentially embarrass the company, disclose trade secrets, reveal corporate strategy, expose private personal data of employees or customers, or otherwise reveal information that your organization does not want revealed.

This two-tier approach to data classification is rather elementary. Most organizations will have multiple tiers. Each tier is defined by the damage that information disclosure could cause. We will take a look at U.S. DoD clearance levels. These provide some insight into varying security classifications. Even if you work in an entirely civilian environment, reviewing the DoD approach can give you some suggestions on how to classify your data and how to properly evaluate which personnel should have access.

DoD Clearances

The terms secret and top secret have specific meanings. The United States has a specific hierarchy of classification. The lowest is confidential. This is information that, if disclosed, might damage national security. Secret information is data that, if disclosed, might cause serious damage to national security. Top secret information is data that, if disclosed, could be expected to cause exceptionally grave damage to national security. There is another designation: top secret SCI (sensitive compartmented information).

Each of these clearances requires a different level of investigation. A secret clearance requires a complete background check including criminal, work history (for the past 7 years), credit check, and checks with various national agencies (Department of Homeland Security, Immigration, State Department, and so on). This type of background check is referred to as an NACLC, or National Agency Check with Law and Credit. The secret clearance may or may not include a polygraph.

The top secret clearance is more rigorous, as you might imagine. It involves a Single Scope Background Investigation (SSBI)—a complete NACLC for the subject and spouse that goes back at least 10 years. It also involves a subject interview conducted by a trained investigator. Direct verification of employment, education, birth, and citizenship are also required. At least four references are necessary, and at least two of those will be interviewed by investigators. A polygraph is also used. The SSBI is repeated every 5 years.

An SCI is assigned only after a complete SSBI has been completed. An SCI may have its own process for evaluating access; therefore, a standard description of what is involved is not available.

Disaster Recovery Plan

A disaster recovery plan (DRP) is a plan you have in place to return business to normal operations after a disaster occurs. A DRP must include a number of items. It must address personnel issues, including being able to find temporary personnel, if needed, and being able to contact the personnel you have employed. It also includes having specific people assigned to specific tasks. Your DRP needs to address who in your organization is tasked with the following:

• Locating alternative facilities

• Getting equipment to those facilities

• Installing and configuring software

• Setting up the network at the new facility

• Contacting staff, vendors, and customers

These are just a few areas that a disaster recovery plan must address.

Business Continuity Plan

A business continuity plan (BCP) is similar to a DRP but with a different focus. A DRP is designed to get the organization back to full functionality as quickly as possible. A BCP is designed to get minimal business functions back up and running at least at some level so you can conduct some type of business. An example would be a retail store whose credit card processing system is down. Disaster recovery is concerned with getting the system back up and running, and business continuity is concerned with simply getting a temporary solution, such as processing credit cards manually.

To successfully formulate a BCP, you must consider those systems that are most critical for your business and have an alternative plan in case those systems are down. The alternative plan need not be perfect, just functional.

Impact Analysis

Before you can create a realistic DRP or BCP, you have to do an impact analysis of what damage to your organization a given disaster might cause. This is called a business impact analysis or business impact assessment (BIA). Consider a web server crash. If your organization is an e-commerce business, then a web server crash is a very serious disaster. However, if your business is an accounting firm and the website is just a way for new customers to find you, then a web server crash is less critical; you can still do business and earn revenue while the web server is down. You should make a spreadsheet of various likely or plausible disasters and do a basic BIA for each.

One item to consider for a BIA is the maximum tolerable downtime (MTD). How long can a given system be down before the effect is catastrophic and the business is unlikely to recover? Another item to consider is the mean time to repair (MTTR). How long is it likely to take to repair a given system if it is down? These factors help you determine the business impact of a given disaster.

Disaster Recovery and Business Continuity Standards

Several standards might be useful to you in forming a BCP and a DRP. Familiarizing yourself with existing standards can aid you in forming your own DRP and BCP:

• ISO 27035: This standard is about incident response. It requires a structure, planned approach to detecting and reporting incidents, as well as responding.

• NIST 800-61: This standard is concerned with establishing incidence response policies. It provides guidance on incidence response teams, response procedures, and related items.

Both of these are good, general disaster recovery standards. Either can provide a basis for your own disaster recovery planning.

Fault Tolerance

The fact is that at some point, all equipment fails. So fault tolerance is important. At the most basic level, fault tolerance for a server means a backup. If the server fails, did you back up the data so you can restore it? While database administrators may use a number of different types of data backups, from a security point of view, there are three primary backup types to be concerned with:

• Full: All changes

• Differential: All changes since last full backup

• Incremental: All changes since last backup of any type

Consider a scenario in which you do a full backup at 2 a.m. each morning. But you are concerned about the possibility of a server crash before the next full backup, so you want to do a backup every 2 hours. Well, the type of backup you choose will determine the efficiency of doing those frequent backups and the time needed to restore. So let’s consider each scenario and what would happen if the system crashed at 10:05 a.m.:

• Full: Say that you do full backups at 4 a.m., 6 a.m., … 10 a.m., and then the system crashes. Well, to restore, you just have to restore the last full backup, which was done at 10 a.m. This makes restoration much simpler. However, running a full backup every 2 hours is very time-consuming and resource intensive, and it will have a significant negative impact on your server’s performance.

• Differential: Say that you do differential backups at 4 a.m., 6 a.m., … 10 a.m., and then the system crashes. To restore, you will need to restore the last full backup, which was done at 2 a.m., and the most recent differential backup, which was done at 10 a.m. This is just a little more complicated than the full backup strategy. However, those differential backups are going to get larger each time you do them, and thus they will be more time-consuming and resource intensive. While they won’t have the impact of the full backups, they will still slow down your network.

• Incremental: Say that you do incremental backups at 4 a.m., 6 a.m., … 10 a.m., and then the system crashes. To restore, you need to restore the last full backup, which was done at 2 a.m., and then each incremental backup done since then, and they must be restored in order. This type of restoration is much more complex, but each incremental backup is small and does not take much time or consume many resources.

There is no “best” backup strategy. Which one you select will depend on your organization’s needs. Whatever backup strategy you choose, you must periodically test it. The only effective way to test your backup strategy is to actually restore the backup data to a test machine.

The other fundamental aspect of fault tolerance is RAID, or redundant array of independent disks. RAID allows your servers to have more than one hard drive, so that if the main hard drive fails, the system keeps functioning. The primary RAID levels are described here:

• RAID 0 (striped disks): RAID 0 distributes data across multiple disks in a way that gives improved speed at any given instant. There is no fault tolerance.

• RAID 1 (mirroring): RAID 1 mirrors the contents of the disks, making a form of 1:1 ratio real-time backup.

• RAID 3 or 4 (striped disks with dedicated parity): RAID 3 or 4 combines three or more disks in a way that protects data against loss of any one disk. Fault tolerance is achieved by adding an extra disk to the array and dedicating it to storing parity information. The storage capacity of the array is reduced by one disk.

• RAID 5 (striped disks with distributed parity): RAID 5 combines three or more disks in a way that protects data against the loss of any one disk. It is similar to RAID 3, but the parity is not stored on one dedicated drive; instead, parity information is interspersed across the drive array. The storage capacity of the array is a function of the number of drives minus the space needed to store parity.

• RAID 6 (striped disks with dual parity): RAID 6 combines four or more disks in a way that protects data against loss of any two disks.

• RAID 1+0 (or 10): RAID 1+0 is a mirrored data set (RAID 1) that is then striped (RAID 0), hence the “1+0” name. A RAID 1+0 array requires a minimum of four drives: two mirrored drives to hold half of the striped data, plus another two mirrored for the other half of the data.

A server without at least RAID 1 is gross negligence on the part of the network administrator. RAID 5 is actually very popular with servers.

While RAID and backup strategies are the fundamental issues of fault tolerance, any backup system provides additional fault tolerance. This can include uninterruptable power supplies, backup generators, and redundant Internet connections.

HIPAA

The Health Insurance Portability and Accountability Act (HIPAA) is a U.S. federal regulation that mandates national standards and procedures for the storage, use, and transmission of personal medical information. Passed into law in 1996, HIPAA has caused a great deal of change in healthcare record keeping.

HIPAA covers three areas—confidentiality, privacy, and security of patient records—and was implemented in phases to ease the transition. Confidentiality and privacy of patient records had to be implemented by a set date, followed by security of patient records. Standards for transaction codes in medical record transmissions had to be completed by a given date as well.

The penalties for HIPAA violations are very stiff: They can be as high as $250,000, depending on the circumstances. A medical practice is required to appoint a security officer. All related parties, such as billing agencies and medical records storage facilities, are required to comply with these regulations.

Sarbanes-Oxley

The Sarbanes-Oxley Act is legislation that came into force in 2002, introducing major changes to the regulation of financial practice and corporate governance. Named after Senator Paul Sarbanes and Representative Michael Oxley, this law is designed to make publicly traded corporations more accountable.

The legislation focuses primarily on financial issues, but it also affects IT departments that are responsible for storing a corporations’ electronic records. The Sarbanes-Oxley Act states that all business records, including electronic records and electronic messages, must be saved for “not less than five years.” The consequences for noncompliance are fines, imprisonment, or both.

Payment Card Industry Data Security Standards

While not a law, the Payment Card Industry Data Security Standards (PCI DSS) is certainly something any IT security professional who works for a company that handles credit cards and debit cards should be familiar with. PCI DSS is a proprietary information security standard for organizations that handle branded credit cards from major companies, including Visa, MasterCard, American Express, and Discover.