Concepts:Chapter 13Implementation processesThe 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 StateThe 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:
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 LanguageThe 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.
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 AwarenessThere 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:
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 IssuesAs 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 14Enforcing policiesThe 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 EmployeesThe 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 LawsThe 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.
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.
|