Computer Science WK1 Assignment

Information_Security_Fundamentals_----_Chapter_1_Developing_Policies.pdf

Home >Computer Science homework help >Computer Science WK1 Assignment

Chapter 1

Developing Policies

Thomas R. Peltier

Contents Policy Is the Cornerstone .......................................................................................2 Definitions ............................................................................................................2

Policy ................................................................................................................2 Standards ..........................................................................................................2 Procedures ........................................................................................................4 Guidelines ........................................................................................................4

Policy Key Elements ..............................................................................................6 Policy Format ........................................................................................................7

Global Policy (Tier 1) .......................................................................................8 Topic ............................................................................................................8 Scope ...........................................................................................................8 Responsibilities ............................................................................................9 Compliance or Consequences ......................................................................9

Topic-Specific Policy (Tier 2) ............................................................................9 Thesis Statement ........................................................................................10 Relevance ...................................................................................................10 Responsibilities ..........................................................................................11 Compliance ................................................................................................11 Supplementary Information .......................................................................11

Application-Specific Policy (Tier 3) .................................................................12 Summary .............................................................................................................12

Peltier, Thomas R.. Information Security Fundamentals, Auerbach Publishers, Incorporated, 2013. ProQuest Ebook Central, http://ebookcentral.proquest.com/lib/apus/detail.action?docID=1375200. Created from apus on 2025-04-08 02:10:22.

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

2 ◾ Information Security Fundamentals

Policy Is the Cornerstone The cornerstone of an effective information security architecture is a well-written policy statement. This is the source from which all other directives, standards, pro- cedures, guidelines, and other supporting documents will spring. As with any foun- dation, it is important to establish a strong footing. As will be discussed, a policy performs two roles, one internal and one external.

The internal portion tells employees what is expected of them and how their actions will be judged. The external portion tells the world how the enterprise sees its respon- sibilities. Every organization must have policies in place that support sound business practices and they will demonstrate to the world that this organization understands that the protection of assets is vital to the successful execution of its mission.

In any discussion regarding written requirements, the term policy has more than one meaning. To some, a policy is senior management’s directives on how a certain program is to be run, what its goals and objectives are, and to whom responsibilities are to be assigned. The term policy may refer to the specific security rules for a particular system such as Access Control Facility 2 (ACF2) rule sets, Resource Access Control Facility (RACF) permits, or intrusion detection system policies. Additionally, policy may refer to entirely different matters, such as specific management decisions setting an organiza- tion’s e-mail privacy policy or Internet/social media usage policy.

Definitions Policy A policy is a high-level statement of enterprise beliefs, goals, and objectives and the general means for their attainment for a specified subject area. When we hear discussions on intrusion detection systems monitoring compliance to company policies, these are not the policies we are discussing here. The intrusion detection system is actually monitoring standards (which we will discuss in more detail later), rule sets, or proxies. We will be creating policies like the policy on information security shown in Figure 1.1.

Later in this chapter, we will examine a number of information security policies and critique them based on an established policy template.

Standards Standards are mandatory requirements that support individual policies. Standards can range from what software or hardware can be used, to what remote access protocol is to be implemented, to who is responsible for approving what. When developing an information security policy, it will be necessary to establish a set of supporting standards. Figure 1.2 is an example of what standards for a specific topic might look like.

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

Developing Policies ◾ 3

Information Security Policy

Business information is an essential asset of the Company. This is true of all business informa- tion within the Company regardless of how it is created, distributed, or stored and whether it is typed, handwritten, printed, filmed, computer-generated, or spoken.

All employees are responsible for protecting corporate information from unauthorized access, modification, duplication, destruction, or disclosure, whether accidental or intentional. This responsibility is essential to Company business. When information is not well protected, the Company can be harmed in various ways such as significant loss to market share and a damaged reputation.

Details of each employee’s responsibilities for protecting Company information are documented in the Information Protection Policies and Standards Manual. Management is responsible for ensuring that all employees understand and adhere to these policies and standards. Management is also responsible for noting variances from established security practices and for initiating cor- rective actions.

Internal auditors will perform periodic reviews to ensure ongoing compliance with the Company information protection policy. Violations of this policy will be addressed as prescribed in the Human Resource Policy Guide for Management.

Figure 1.1 Sample information security policy.

Information Systems Manager/Team Leader

Managers with responsibility for Information Systems must carry out all the appropriate respon- sibilities as a Manager for their area. In addition, they will act as Custodian of information used by those systems but owned by other managers. They must ensure that these owners are identi- fied, appointed and made aware of their responsibilities.

All managers, supervisors, directors and other management level people also have an advisory and assisting role to IS and non-IS managers in respect of

◾ Identifying and assessing threats ◾ Identifying and implementing protective measures (including compliance with these

practices) ◾ Maintaining a satisfactory level of security awareness ◾ Monitoring the proper operation of security measures within the unit ◾ Investigating weaknesses and occurrences ◾ Raising any new issues or circumstances of which they become aware through their spe-

cialist role, and ◾ Liaising with internal and external audit

Figure 1.2 Example of standards.

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

4 ◾ Information Security Fundamentals

Procedures Procedures are mandatory, step-by-step, detailed actions required to successfully complete a task. Procedures can be very detailed. Recently, I was reviewing change management procedures and found one that consisted of 42 pages of precise infor- mation. It was very thorough and was what was needed to ensure that the process could be followed (Figure 1.3).

Guidelines Guidelines are documented suggestions for the regular and consistent implemen- tation of accepted practices. They usually have less enforcement powers. Where standards are mandatory, guidelines are recommendations. An everyday example of the difference between a standard and a guideline would be a “Stop” sign, which is a standard, and a “Please Keep off the Grass” sign, which would be nice, but it is not a law.

Application Change Management Procedure

General

The System Service Request (SSR) is used to initiate and document all programming activity. It is used to communicate customer needs to Application Development (AD) personnel. A SSR may be initiated and prepared by a customer, a member of the AD staff, or any other individual who has identified a need or requirement, a problem, or an enhancement to an application. No tasks are to be undertaken without a completed SSR.

System Service Request General

This form, specifying the desired results to be achieved, is completed by the customer and sent, together with supporting documentation, to AD. The request may include the identification of a problem or the documentation of a new request. Customers are encouraged to submit their request in sufficient detail to permit the AD project leader to accurately estimate the effort needed to satisfy the request, but it may be necessary for the project leader to contact the customer and obtain supplementary information. This information should be attached to a copy of the SSR.

After the requested programs have been completed, the agreed-upon acceptance tests will be conducted. After the customer has verified that the request has been satisfied, the customer will indicate approval on the SSR. This form will also be used to document that the completed project has been placed into production status.

Processing

This section describes the processing of a SSR:

1. The customer initiates the process by completing the SSR and forwarding it to the appro- priate Project Manager (PM) or the Director of Application Development (AD).

2. The SSR is received in the AD department. Regardless of who in AD actually receives the SSR, it must be delivered to the appropriate PM.

Figure 1.3 Sample of an application change management procedure.

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

Developing Policies ◾ 5

3. If the PM finds the description of requirements on the SSR inadequate or unclear, the PM will directly contact the customer for clarification.

When the PM fully understands the requirements, the PM will prepare an analysis and an estimate of the effort required to satisfy the request. In some cases, the PM may feel that it is either impossible or impractical to satisfy the request. In this case, the PM will discuss with the customer the reasons why the request should not be implemented. If the customer reaffirms the request, the PM and Director of AD will jointly deter- mine whether to appeal the customer’s decision to the Information Systems Steering Committee for a final ruling on the SSR.

4. If the project estimate is forty (40) hours or less, the detailed design should be reviewed with the customer. After design concurrence has been reviewed, the PM will project the tentative target date (TTD) for completion of the SSR. In setting the TTD, the PM will take into consideration the resources available and other project commitments. The TTD will be promptly communicated to the requesting customer.

5. If the project estimate exceeds forty (40) hours, the SSR and any supplemental project documentation will be forwarded to the ISSC for review, priority determination, and authorization to proceed.

The committee will determine whether the requested change is to be scheduled for immediate implementation, scheduled for future implementation, or disapproved. If the request is disapproved, it is immediately returned to the customer, together with an explanation of the reason(s) for disapproval. If it is approved for implementa- tion, a priority designation is made and the SSR is returned to AD for implementation scheduling.

After implementation authorization has been received, the detailed design should be reviewed with the customer. After design concurrence has been received, the PM will project a TTD for completion of the project. In setting a TTD, the PM will take into con- sideration resources available and other project commitments. The TTD will be promptly communicated to the customer.

6. The PM will coordinate with AD personnel and other IT management and staff personnel (such as Database Administration, User Support Services, Network Administration, etc.) of their resources will be required to satisfy this request, or if there will be an operational or procedural effect in the other areas.

7. The PM will contact the customer to discuss, in detail, the test(s) that are to be conducted. 8. When Acceptance Testing (AT) has been completed, and the customer has verified the

accuracy of the results obtained, the customer will indicate their approval to place the project into production by signing the SSR.

9. The Production Control Group (PCG) will place the project into production status. The PM will complete the bottom portion of the SSR, documenting that the project has been placed into production. The PM will log the status of the request as “completed” and file a copy of the SSR. The PM will promptly notify the customer that the project has been completed and placed into production.

Retention of Forms and Documentation

All documentation associated with the processing of each SSR will be retained for at least twelve (12) months.

Figure 1.3 (Continued) Sample of an application change management procedure.

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

6 ◾ Information Security Fundamentals

Policy Key Elements To meet the needs of an organization, a good policy should:

◾ Be easy to understand. It is important that the material presented meet the require- ments of the intended audience. All too often, policies, standards, and procedures are written by subject experts and given to a general use audience. The material is often written at a college or technical level when the average reading and compre- hension level in the workplace is that of a sixth grader (a 12-year-old).

◾ Be applicable. When creating policy, the writer may research other organiza- tions and copy that document verbatim. This may be expedient; however, it is very important to ensure that whatever is written meets the needs of your specific organization.

◾ Be doable. Can the organization and its employees still meet business objec- tives if the policy is implemented? All too often, organizations implement policies to answer audit comments. The problem with doing this is that the policy may be so restrictive that it inhibits the ability to perform the business or mission of the organization.

◾ Be enforceable. Do not write a self-defeating policy. “Use of the Company- provided telephone is for business calls only.” For most organizations, this may in fact be the policy, but almost every phone in the facility is used daily for personal calls. What might make a better policy is one that says, “Company- provided telephones are to be used for management-approved functions only.” This opens up some latitude and still meets the business need.

◾ Be phased in. It may be necessary to allow the organization to read and digest the policy before it takes effect. Many organizations publish a policy and then require the business units to submit a compliance plan within a specific number of days after publication. This provides the business unit managers a period of time to review the policy, determine where their organization may be deficient, and then submit a timetable for compliance. These compliance letters are normally kept on file and are made available to the audit staff.

◾ Be proactive. State what has to be done, do not get into the rut of making pronouncements—“Thou shall not!” Try to state what can be done and what is expected of the employees.

◾ Avoid absolutes. Be diplomatic and understand the politically correct way to say things. When discussing sanctions for noncompliance, some organiza- tion have stated, “Employees violating this policy will be subject to disciplin- ary sanctions up to and including dismissal without warning.” When the policy could have read something like, “Employees found in noncompliance with this policy will be deemed in violation of the Employee Standards of Conduct.” The Standards of Conduct state that employees will suffer dis- ciplinary sanctions up to and including dismissal. Where possible, use the kindlier, gentler approach.

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

Developing Policies ◾ 7

◾ Meet business objectives. Security professionals must learn that controls must help the organization to an acceptable level of risk. One hundred percent security is 0% productivity. Whenever controls or policy affect the business objectives or mission or the organization, then the controls and policy will lose. Work to understand that the policy exists to support the business, not the other way around.

Policy Format The actual physical format (layout) of the policy will depend on what policies look like in your own organization. To be successful, it is very important that any pol- icy developed look like published policies from the organization. Find out who is responsible for policies at your organization and see if they have a template avail- able. Some members of the review panel will be unable to read and critique the new policy if it does not look like a policy.

Policies are generally brief in comparison to procedures and normally consist of one page of text using both sides of the paper. In my classes, I stress the concept of brevity. However, it is important to balance brevity with clarity. Take all the words you need to complete the thought, but fight the urge to add more information.

Years ago, we had a young priest visit our parish and his homily that weekend included a discussion on the concept of imprinting. This concept is normally cov- ered in a basic Psychology 101 class and is an early social behavior among birds and is a process that causes the newly hatched birds to become rapidly and strongly attached to social objects such as parents or parental surrogates. Although a number of parishioners understood what he was talking about, the majority of the parish just stared at him blankly. So he continued to add explanation after explanation until his homily lasted about 45 minutes. When writing a policy, balance the atten- tion span time limit with what needs to be addressed. Keep it brief, but make it understandable.

There are three types of policies and you will use each type at different times in your information security program and throughout the organization to support the business process or mission. The three types of policies are

1. Global (tier 1)—these are used to create the organization’s overall vision and direction

2. Topic-specific (tier 2)—these address particular subjects of concern. Where a typical tier 1 policy might address “Corporate Communications,” the sup- porting tier 2 policies might address communication requirements when using e-mail, social media, voice mail, and other such methods

3. Application-specific (tier 3)—these focus on decisions taken by management to control particular applications (financial reporting, payroll, etc.) or sys- tems (budgeting system)

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

8 ◾ Information Security Fundamentals

Global Policy (Tier 1) Under the Standard of Due Care, and charged with the ultimate responsibility for meeting business objectives or mission requirements, senior management must ensure that necessary resources are effectively applied to develop capabilities to meet the mission requirements. They must incorporate the results of the risk analy- sis process into the decision-making process. Senior management is also responsible for issuing global policies to establish the organization’s direction in protecting information assets.

An information security policy will define the intent of management and its sponsoring body with regard to protecting the information assets of the organi- zation. It will include the scope of the program, that is, where it will reach and what information is included in this policy. Finally, the policy will establish who is responsible for what.

The components of a Global Policy (Tier 1) typically include the following four characteristics.

Topic

The topic portion of the policy defines what specifically the policy is going to address. Because the attention span of readers is limited, the topic must appear quickly, in the opening or topic sentence. I normally suggest (note that it is a guide- line, not a standard) that the topic sentence also include a “hook,” that is, the reason I, as a reader, should continue to read this policy. So, in the opening sentence, we will want to convey two important elements: (1) the topic (it should have something to do with the title of the policy), and (2) the hook (why the reader should continue to read the policy).

An opening topic sentence might read as follows: “Information created while employed by the Company is the property of the Company and all employees must properly protect it.”

Scope

The scope can be used to broaden or narrow either the topic or the audience or both. In an information security policy statement, we could say, “information is an asset and the property of the Company and all employees are responsible for protecting that asset.” In this sentence, we have broadened the audience to include all employees. We can also say something like “Business information is an essential asset of the Company. This is true of all business information within the Company regardless of how it is created, distributed, or stored and whether it is typed, hand- written, printed, filmed, computer-generated, or spoken.” Here, the writer broad- ened the topic to include all types of information assets.

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

Developing Policies ◾ 9

Another example of broadening the scope might be as follows: “Information of the Company, its subsidiaries and affiliates in electronic form, whether being transmitted, or stored, is a key asset of the Company and must be protected accord- ing to its sensitivity, criticality, and value.” Here, the topic subject is narrowed to “electronic form.” However, the audience is broadened to include “subsidiaries and affiliates.”

We can also use the scope concept to narrow the topic or audience. In an Employment Agreement policy, the audience is restricted to a specific group such as the following:

The parties to this Agreement dated (specify) are (Name of Company), a (specify State and type of company) (the “Company”) and (Name of Employee) (the “Executive”).

The Company wishes to employ the Executive, and the Executive wishes to accept employment with the Company, on the terms and subject to the con- ditions set forth in this Agreement. It is therefore agreed as follows:

Here, the policy is restricted to Executives and will then go on to discuss what can and cannot be done by the executives.

Responsibilities

Typically, this section of the policy will identify who is responsible for what. When writing, it is better to identify the “who” by job title and not by name. An Office Administrator’s Reference Guide can be of great assistance by identifying how cer- tain levels of management are referred to in communications. The policy will want to identify what is expected from each of the stakeholders.

Compliance or Consequences

When business units or employees are found to be in a noncompliant situation, the policy must spell out the consequences of these actions. For business units or department, if they are found in noncompliance, they are generally subject to an audit item and will have to prepare a formal compliance response.

For an employee, being found in noncompliance with a company policy will mean they are in violation of the organization’s Employee Standards of Conduct and will be subject to consequences described in the Employee Discipline Policy.

Topic-Specific Policy (Tier 2) Where the Global Policy (tier 1) is intended to address broad, organization- wide issues, the Topic-Specific Policy is developed to focus on areas of current

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

10 ◾ Information Security Fundamentals

relevance and concern to the organization. In support of the tier 1 “Corporate Communication Policy,” management may find it appropriate to issue a policy on how an organization will approach social media usage or the use of the company- provided e-mail system. Topic-specific policies may also be appropriate when new issues arise, such as when implementing a recently enacted law requiring protec- tion of particular information (GLBA, HIPAA, etc.). The Global Policy (tier 1) is usually broad enough that it does not require modification over time, whereas the Topic-Specific Policies (tier 2) are likely to require more frequent revisions as changes in technology and other factors dictate.

Topic-specific policies will be created most often by an organization. We will examine the key elements of the topic-specific policy. When creating an Information Security Policies and Standards document, each section in the document will nor- mally begin with a topic-specific policy. The topic-specific policy will narrow the focus to one issue at a time. This will allow the writer to focus on one area and then develop a set of standards to support this particular subject.

Where the tier 1 policies are approved by the Information Security Steering Committee, the topic-specific (tier 2) policies may be issued by a single senior man- ager or director.

As with the tier 1 policies, tier 2 policies will address management’s position on relevant issues. It is necessary to interview management to determine what their concerns are and what is it that they want to have occur. The writer will take this information and incorporate it into the following structure.

Thesis Statement

This is similar to the Topic section discussed in the tier 1 policies, but it also adds more information to support the goals and objectives of the policy and manage- ment’s directives. This section will be used to discuss the issue in relevant terms and what conditions are included. If appropriate, it may be useful to specify the goal or justification for the policy. This can be useful is gaining compliance with the policy.

When developing a Workstation Standards document, a topic-specific policy on appropriate software, with supporting standards, might include a discussion on “Company-approved” software. This policy would define what is meant by company-approved software, which might be “any software approved, purchased, screened, managed, and owned by the organization.” The policy would also discuss the conditions required to have software approved.

Once the terms and conditions have been discussed, the remainder of this sec- tion would be used to state management’s position on the issue.

Relevance

The tier 2 policy also needs to establish to whom the policy applies. In addition to whom, the policy will want to clarify where, how, and when the policy is applicable.

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

Developing Policies ◾ 11

Is the policy only enforced when employees are in the work-site campus or will it extend to off-site activities? It is necessary to identify as many of the conditions and terms as possible.

Responsibilities

The assignment of roles and responsibilities is also included in tier 2 policies. For example, the policy on company-approved software will have to identify the pro- cess to get software approved. This would include the authority (by job title) autho- rized to grant approval and a reference to where this process is documented.

This is a good time to discuss deviations from policy requirements. I have established a personal standard in that I never discuss how an entity can gain a dispensation from the policy. I don’t like to state that “this is the policy and all employees must comply, except those of you that can find a way around the policy.” Most organizations have a process to gain an approved deviation from a policy or standard. This normally requires the petitioner to submit a business case for the deviation along with alternative controls that would satisfy the spirit of the policy. If some organization or person wants a deviation from the policy, let them discover what the process is.

Compliance

For a tier 2 policy, it may be appropriate to describe, in some detail, the infrac- tions that are unacceptable, and the consequences of such behavior. Penalties may be explicitly stated and should be consistent with the tier 1 Employee Discipline Policy. Remember, when an employee is found in a noncompliant situation, it is Management and Human Resources that are responsible for disciplining the individual.

Supplementary Information

For any tier 2 policy, the appropriate individuals in the organization to contact for additional information, guidance, and compliance should be indicated. Typically, the contact information would be specified by job title, not by individual name. It may also be prudent to identify who is the owner of this policy. This information will provide the reader with the appropriate information if they have suggestions on how to improve the policy.

To be effective, a policy requires visibility. Visibility aids implementation of the policy by helping ensure that it is fully communicated throughout the orga- nization. Management presentations, videos, panel discussions, guest speakers, question and answer forums, and newsletters will increase visibility. The organiza- tion’s Information Security Awareness Program can effectively notify users of new policies through the security blog or social media account. The New Employee

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

12 ◾ Information Security Fundamentals

Orientation program can also be used to familiarize new employees with the orga- nization’s policies.

When introducing policies, it is important to ensure that management’s sup- port is clear, especially in areas where employees feel inundated with directives, regulations, or other requirements. Organization policies are the vehicles used to emphasize management’s commitment to effective internal controls and their expectations for employee support and compliance.

Application-Specific Policy (Tier 3) Global-level (tier 1) and topic-specific (tier 2) policies address policy on a broad level; they usually encompass the entire enterprise. The application-specific (tier 3) policy focuses on one specific system or application. As the construction of the organization information security architecture takes shape, the final element will be the translation of tier 1 and tier 2 policies down to the application and system level (tier 3).

Many security issue decisions apply only at the application or system level. Some examples of these issues include

◾ Who has the authority to read or modify data? ◾ Under what circumstances can data be read or modified? ◾ How is remote access to be controlled?

To develop a comprehensive set of tier 3 policies, use a process that determines secu- rity requirements from a business or mission objective. Try to avoid implementing requirements based on security issues and concerns. Remember, the security staff has been empowered to support the business process of the organization. Typically, the tier 3 policy is more free-form than tier 1 and tier 2 policies. As you prepare to create tier 3 policies, keep in mind the following concepts:

◾ Understand the overall business objectives or mission of the enterprise ◾ Understand the mission of the application or system ◾ Establish requirements that support both sets of objectives

Summary In this chapter, we discussed that policy is the cornerstone of an organization’s information security architecture. That a policy is important to establish both inter- nally and externally what an organization’s position on a particular topic might be. We defined what a policy, standards, procedure, and guideline is and what should be included in each of these documents or statements (Figure 1.4).

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

Developing Policies ◾ 13

Sample Security Policy

I. Purpose

To provide direction regarding the protection of Michigan State Specific Agency (MSSA) infor- mation resources from unauthorized access, modification, duplication, destruction or disclosure.

II. Application

This policy applies to all MSSA personnel including employees, interns, vendors, contractors, and volunteers. This policy pertains to all information resources used to conduct MSSA business or used to transmit or store MSSA Restricted or Confidential information.

A MSSA information resource includes information that is electronically generated, printed, filmed, typed, stored or verbally communicated. Information resources must be protected according to its sensitivity, criticality and value, regardless of the media on which it is stored, the manual or automated systems that process it, or the methods by which it is distributed.

III. Definitions

1. Information Resource—any information created, stored in temporary or permanent form, filed, produced or reproduced, regardless of the form or media. Information includes, but is not limited to

a. Personally identifiable information (PII) b. Reports, files, folders, memoranda c. Statements, examinations, transcripts d. Images, and e. Communications

Information resources also include any electronically based system configured for the col- lection, processing, transmission, and dissemination of MSSA information resources. This includes, but is not limited to, software, hardware, and equipment such as servers, mainframes, midrange systems, telecommunications hardware, routers, switches, and software applications.

2. Information Owner—the Director of a MSSA Division where the information resource is created, or who is the primary user of the information resource.

3. Business Owner—where multiple information owners for the same information resource occur, the information owners must designate a Business Owner who will have authority to make decisions on behalf of all the owners of the information resource.

4. Information Classification Categories—all MSSA information shall be classified by the information owner into one of three classification categories:

a. Restricted: This classification applies to information that is the most sensitive to MSSA and typically only a small number of personnel are authorized to view this type of information. The disclosure of this restricted information could have seri- ous and damaging effects on MSSA and its partners. This type of information could include, but is not limited to, customer PII data (Social Security numbers, driver’s license numbers, credit card numbers, etc.), human resource data (Social Security numbers, medical information, etc.), financial data, administrative passwords, encryption keys, litigation, archaeological site location information, and strategic planning documentation.

b. Confidential: This classification refers to proprietary business information that is intended for use within MSSA for normal day-to-day responsibilities. Examples of this type of information could include, but are not limited to, policies, procedures, standards, business process flow diagrams, phone directories, organizational charts, archaeological collections, and documents labeled as confidential.

Figure 1.4 Sample security policy.

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

14 ◾ Information Security Fundamentals

c. Public: This classification applies to information that is approved for public access or to data whose disclosure would have no negative effects on MSSA. Examples could include, but are not limited to, agency announcements, publicly published phone numbers and addresses, general information about archaeological sites (excluding locations), and press releases.

5. Reclassification—the information owner is to establish a review cycle for all information classified as Restricted or Confidential, and reclassify it when it no longer meets the cri- teria established for such information. This cycle should be commensurate with the value of the information but should not exceed 1 year.

6. Custodian—the individual or entity designated by the information owner that is respon- sible for maintaining safeguards established by the information owner.

7. Users—authorized personnel who are responsible for using and safeguarding the infor- mation resources under their control according to the directions of the information owner.

IV. Policy

MSSA information resources residing in the various agency divisions are strategic and vital assets belonging to the people of Michigan. These assets shall be available and protected com- mensurate with the value of the assets. Measures shall be taken to protect these assets against unauthorized access, disclosure, modification or destruction, whether accidental or deliberate, as well as to assure the availability, integrity, utility, authenticity, and confidentiality of informa- tion. Access to MSSA information resources shall be appropriately managed.

All MSSA personnel are accountable for their actions relating to information resources. Information resources shall be used only for intended purposes as defined by MSSA and consis- tent with applicable laws.

V. Responsibilities

1. The information owner has the responsibility to a. Identify the classification level of all information resources within their division b. Define and verify implementation of appropriate safeguards to ensure the confiden-

tiality, integrity, and availability of the information resource c. Monitor the safeguards to ensure their compliance and report instances of

noncompliance d. Authorize access to those who have a demonstrated business need for the informa-

tion resource, and e. Remove access to those who no longer have a business need for the information

resource 2. The Custodian has the responsibility to a. Implement integrity controls and access control requirements specified by the infor-

mation owner b. Advise the information owner of any major deficiency or vulnerability encountered

that results in a failure to meet requirements c. Comply with all MSSA-specific guidelines and procedures to implement, support,

and maintain information security 3. The Users have the responsibility to a. Access only the information for which they have been authorized b. Use the information only for the purpose intended c. Ensure that authenticating information (e.g., password) is in compliance with exist-

ing MSSA/SOM security standards d. Maintain the integrity, confidentiality and availability of information accessed con-

sistent with the information owner’s expectations while under their control

Figure 1.4 (Continued) Sample security policy.

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

Developing Policies ◾ 15

1. Global (tier 1)—these are used to create the organization’s overall vision and direction

2. Topic-specific (tier 2)—these address particular subjects of concern. We will discuss the information security architecture and each category such as the following

3. Application-specific policies—these focus on decisions taken by management to control particular applications (financial reporting, payroll, etc.) or sys- tems (budgeting system)

e. Comply with all MSSA/SOM-specific guidelines and procedures to implement, sup- port, and maintain MSSA/SOM Information Security policies and standards

f. Report violations or suspected violations of policies and standards to the appropriate MSSA management or the MSSA Information Security Project Manager

Access to information resources will be granted by the information owner to those with an approved business need. (Refer to MSSA Information Security Access Control Policy.)

VI. Compliance

1. The MSSA Division Directors (information owner) shall: a. Ensure there are adequate controls and separation of duties for tasks that are suscep-

tible to fraudulent or other unauthorized activity b. Manage MSSA/SOM information resources, personnel, and physical property rel-

evant to MSSA’s mission, as well as the right to monitor the actual utilization of all MSSA/SOM assets

c. Ensure that all employees and contract personnel are aware of and accept their obli- gation to protect MSSA/SOM information resources

2. All authorized users (including but not limited to, agency personnel, temporary employ- ees, and independent contractors) of MSSA information resources, shall formally acknowledge that they will comply with the information security policies and procedures of MSSA or they shall not be granted access to information resources.

Figure 1.4 (Continued) Sample security policy.

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .