ITS 3050 - Security Policies and Auditing

Security Policies and Implementation Issues
Chapter 13, IT Security Policy Implementations
Chapter 14, IT Security Policy Enforcement

Objectives:

This lesson covers chapters 13 and 14. It discusses implementing policies and holding employees accountable for following them. Objectives important to this lesson:

  1. Implementation processes
  2. Target state
  3. Good policy language
  4. Employee training
  5. Implementation issues


  6. Enforcing policies
  7. Monitoring employees
  8. Security policies and laws
  9. Accountability

Concepts:

Chapter 13

Implementation processes

The chapter starts by introducing a flow chart on page 365 that displays an idealized path to take to the implementation of a new or changed policy. As we have seen before, the author is foreshadowing the goal. We need to walk through the rest of the chapter to understand what happens in each step.

Target State

The text describes the target state as the state we wish to achieve when we have implemented the new/changed policy. In order to understand that state, we should explain our current state in terms of:

  • our business risks that the policy will reduce
  • the threat vectors that will be detected, reduced, or eliminated by the policy
  • the state of compliance with laws and regulations that the policy will provide to us

As the text explains, this section of the process is meant to convince those who see and hear it, typically the executive whose buy in we need, that we are doing the right thing for our organization.

The text then spends a few pages in fantasy land, wasting our time and concentration until we arrive at page 373.

Good Policy Language

The author's point that a policy must resemble a legal contract is a good one. A policy should be specific, measurable, achievable, realistic, and time-related. That spells SMART, an acronym that stands for setting goals that matter, that can be achieved, and that should be achieved, on a timeline that will give us results in time to use them.

  • Explain the situation. Are you deploying new software or hardware? Is there a new threat that the policy addresses? Tell people what is going on and what they must do.
  • Tell people to do something that can and will be measured. Tell them that compliance is required, not requested or expected. Don't leave the impression that this is a guideline or a suggestion. It is a rule that must be followed, and someone will be watching.
  • Make sure your policy is requiring a behavior that can be achieved. It may be difficult, but it must never be impossible. It could be useful to mention the results attained by a pilot group. This information may establish a standard for performance, or a goal for the current quarter.
  • Tell people how to attain the goal. Include a procedure or reference one they may refer to when following the policy.
  • Tell them when measurements will begin and what they should do to meet or exceed requirements.

The text cautions us to make a policy more general than a procedure, so that we do not have to rewrite it when a technology change is adopted. This is sensible from one point of view, but it merely moves the real rule to a different document that must still be revised when the technology change occurs. If you are in a small organization, minimize the paper work, and eliminate the second click. Put the rule in the policy, and revise it as needed. And put a version number and an effective date in the silly thing. There is nothing like the feeling of looking up a policy, thinking it is the same one you have seen for years, and ignoring it, only to find out later that it had changed. Make the effective date and version number very visible.

Employee Awareness

There is a real problem with compliance that has nothing to do with willingness or ability. I mentioned it in the previous paragraph. If an employee knows a policy and has followed it for some time, that employee feels no need to look at the posted policy again just to check for changes. People need someone to tell them when something changes. That's what newscasters and managers are for.

The text mentions two components to this process. We should measure the need for each one against the content of the current policy change or implementation:

  • Awareness - Sometimes, information is enough. If this is a change that requires a modification of current skill that can be explained in a meeting or a document, let managers inform their staff and assess the need to train them.
  • Training - If this is a major change in skill or behavior, impress that on staff by having a formal training activity to show them what to do. Do not make it over long and tedious. Make it informative, then send them back to work.

The text continues this topic, repeating some things it has said before about training staff when they are hired or moved to jobs that require special or different knowledge. It recommends creating a computer based training program where it is possible to use one. Such a system can provide training on demand. This is beneficial when you do not know when you will be hiring, or how many people will need a refresher on the material. This is the kind of training material I have my staff prepare for technical staff and for general staff. It becomes available on our web server to anyone in the organization, and it can be updated easily when updates are needed. The text warns us that although computer based training is less expensive than paying for lost work hours, travel time, and trainer time, it can fail to measure what is actually understood by the student. That is true of classroom training as well, especially when there is no allowance for testing. It is better in either case to have managers measure the performance and understanding of their staff.

The text also spends a few pages discussing various methods of communicating with staff. Several methods are listed on page 382, and some concerns about crafting communications are listed on the bottom of that page. Note the use of that list of concerns, applied to two communications streams on the top of page 383. It is a good plan that concerns itself with the message, the audience, the medium, and the timing of the delivery of information.

Implementation Issues

As noted in the example above, it is a good idea to test a policy with people motivated to try new things. A pilot group, a number of early adopters, or a test group can serve as responsible spokespersons for the change, having already accepted it and used it. Without a test, you can't say you have actually accounted for what might go wrong.

As the text also states, selling the concepts of security may not work for every employee, which is why it must become a mandatory issue. Security policies must be followed, and noncompliance must receive discipline as the situation requires. This does not mean that you stop selling the idea. It means that there must also be the reality that we expect and require participation from all employees.

Chapter 14

Enforcing policies

The chapter opens with a discussion of its main topic on page 398. It begins by reminding us, as the last chapter did, that we must inform our staff about policies and policy changes. The text has previously made the point that executive support for policies and enforcement is critical. A point that the text does not make is that the security people, and perhaps the IT people in general, may be perceived as "not my boss" by the general staff. In many cases, a rule does not seem real to staff until it is made real by their immediate manager. That is unlikely to occur if the rule does not flow down the entire organization table, starting at the top.

This concept links to the material on page 401 about using a hierarchy to manage policies.This is how governance committees are typically organized. A person requesting a change submits it to local management, who forwards the requests that are endorsed to a local change approval board. The local board will forward approved requests to a board at the next hierarchical level in the organization chart. This process is followed until a request is approved at the highest level required for its type. Some types may be approvable at any level, if that level is the last one the request will affect. The list of committees on the bottom of page 401 is very inflated, so let's move on.

On page 405, we are reminded of a simple concept. The idea is that first line managers are the best people to assess their staff, to see they are trained, and to inform them of their accountability for their actions. This is not as hard as the text makes it. Tell people what to do, show them, watch them, and correct them where they need correction. This gives the manager insight into the work being done, it gives the workers feedback, and it gives them both a way to show improvement.

Monitoring Employees

The concept is expanded on the next page, where we are told that the Electronic Communication Privacy Act gives an employer the right to monitor email, computer work, and telephone calls made during regular business. That right is less clear when the employee uses a work computer to access their personal email, not the company email. The text quotes a case in which it was ruled that the employee had a reasonable expectation that her personal email was private, which her company violated by accessing that material on the work computer.

Security Policies and Laws

The text offers an example of an interpretation of a law on page 409. The law is GLBA, which requires reporting for instances of unauthorized access. Regulators may provide guidance on the issue of how many breaches it takes to make it worth reporting. Yes, one instance is important, but a single access may be by accident or mistake. The guideline in the text of one thousand breaches may seem quite high, but it establishes a guide that may be followed. A real hacker will want to access as many records as possible. With that kind of motivation, a thousand is not an unreasonable number to set as an alarm.

On the next page, the text discusses the fact that an organization should make policies whose intent is to keep employees compliant with relevant laws and regulations. This does not make a policy into a law. A violation of a policy may, in fact, occur when a law or regulation is broken. However, the mere violation of a policy does not constitute a violation of a law. Policies are not laws. The organization does not enforce laws. If we suspect that a law has been broken, we should notify the responsible police agency or regulatory agency.

On page 411, there is a bulleted list of common security policy goals that provide compliance with privacy laws. Since these are common policies, they should be on your list of policies that will show that you are trying to comply with standards across the IT industry.

There are similar lists on pages 412 and 413, listing automated policies and manual policies that should be implemented to provide security for our data and to prove compliance efforts by our organization.

  • Authentication method policies
  • Authorization method policies
  • Data encryption policies
  • Event logging policies
  • Data segmentation policies
  • Network segmentation policies

  • Background check policies
  • Log review policies
  • Access rights review policies

The last item to consider from this chapter is the message on page 417, regarding enforcement of policies by different entities at different levels of the organization.

  • Several times we have seen the first line supervisor/manager named as being responsible for enforcement of policies regarding the actions of their employees.
  • The human relations department of your organization may be involved in discipline and dismissal.
  • The information security staff are responsible for implementing policies across the department or organization, as a security program.
  • Executive management is responsible for implementing and enforcing policies that support the goals of the enterprise.