Select a topic Information Security Develop a thesis statement. Provide evidence

Question

Select a topic Information Security Develop a thesis statement. Provide evidence to support your thesis statement. Your Paper should include: Title Page (Include Academic Honesty Statement) Introduction (including clearly stated thesis) Supporting paragraphs Conclusion Reference page Your paper should be 5-7 pages in length. Include research from at least seven sources other than the text. Note: Wikipedia can be used as a resource, but will not count as one of your seven official sources. The paper should contain: Double spacing One inch margins 12 pt. Times New Roman font A polished and professional appearance APA formatting, including a title page and reference page Correct grammar and spelling See below for Final Research Project grading guide. Suggestions for Topics (but are not limited to) Network Security Biometrics Wireless Security Firewalls Information Security Encryption Anti Spam User policies IT Auditing Policies

Explanation / Answer

INFORMATION SECURITY DEVELOP

Introduction

Although the importance of information security for businesses is increasingly recognized, the complexity of issues involved means that the size and shape of information security policies may vary widely from company to company. This may depend on many factors, including the size of the company, the sensitivity of the business information they own and deal with in their marketplace, and the numbers and types of information and computing systems they use. For a large company, developing a single policy document that speaks to all types of users within the organization and addresses all the information security issues necessary may prove impossible. A more effective concept is to develop a suite of policy documents to cover all information security bases; these can be targeted for specific audiences, making a more efficient process for everyone. This paper examines the elements that need to be considered when developing and maintaining information security policy and goes on to present a design for a suite of information security policy documents and the accompanying development process. It should be noted that there is no single method for developing a security policy or policies. Many factors must be taken into account, including audience type and company business and size, all of which are discussed in this paper. One other factor is the maturity of the policy development process currently in place. A company which currently has no information security policy or only a very basic one may initially use a different strategy to a company which already has a substantial policy framework in place, but wants to tighten it up and start to use policy for more complex purposes such as to track compliance with legislation. When starting out it is a good idea to use a phased approach, starting with a basic policy framework, hitting the major policies that are needed and then subsequently developing a larger number of policies, revising those that are already in place and adding to this through the development of accompanying guidelines and job aids documents which will help support policy. The varying levels of maturity in policy development are discussed later in this paper in more detail

Why Do You Need Security Policy?

Basic Purpose of Policy A security policy should fulfill many purposes. It should:

• Protect people and information • Set the rules for expected behavior by users, system administrators, management, and security personnel

• Authorize security personnel to monitor, probe, and investigate

• Define and authorize the consequences of violation1

• Define the company consensus baseline stance on security

• Help minimize risk

• Help track compliance with regulations and legislation Information security policies provide a framework for best practice that can be followed by all employees. They help to ensure risk is minimized and that any security incidents are effectively responded to. Information security policies will also help turn staff into participants in the company’s efforts to secure its information assets, and the process of developing these policies will help to define a company’s information assets2 . Information security policy defines the organization’s attitude to information, and announces internally and externally that information is an asset, the property of the organization, and is to be protected from unauthorized access, modification, disclosure, and destruction.

Policy and Legislative Compliance In addition to the purposes described above, security policies can be useful in ways that go beyond the immediate protection of assets and policing of behavior. They can be useful compliance tools, showing what the company’s stance is on best practice issues and that they have controls in place to comply with current and forthcoming legislation and regulations. In today’s corporate world it is essential for companies to be able to show compliance with current legislation and to be prepared for forthcoming legislation. Recent laws such as HIPAA (Health Insurance Accountability and Portability Act), GLB (Gramm-Leach-Bliley Act) and Sarbanes Oxley have had major implications for policy makers in the U.S. and farther a field. Policy can be used to help companies ensure they have the controls in place to work towards compliance by mapping policy statements to legislative requirements. In this way they can provide evidence that their baseline security controls are in line with regulations and legislation. This type of stance will also give companies an indication based on legal requirements of what they need to protect and to what extent. This will help to ensure that they target security controls only where they are needed, a benefit from both a financial and personnel resourcing perspective.

Policies as Catalysts for Change

It is also possible to use policies to drive forward new company initiatives, with policy acting as the catalyst for future projects which move towards better security and general practices. For example, a policy stating that a certain type of encryption is required for sensitive information sent by email may (with prior consultation with the appropriate technical experts) help to promote the need to develop such a capacity in the future. The presence of this requirement in policy has made sure the impetus to develop the email encryption project has remained strong. In short, security policy should be a useful tool for protecting the security of the Enterprise, something that all users can turn to in their day-to-day work, as a guide and information source. All too often however, security policies can end up simply as “shelf ware” , little read, used, or even known of by users and disconnected from the rest of company policy and security practice.

Policies Must be Workable

The key to ensuring that your company’s security policy is useful and useable is to develop a suite of policy documents that match your audience and marry with existing company policies. Policies must be useable, workable and realistic. In order to achieve this it is essential to involve and get buy-in from major players in policy development and support (such as senior management, audit and legal) as well as from those people who will have to use the policies as part of the daily work (such as subject matter experts, system administrators and end users). In order to achieve this, one important element is to communicate the importance and usefulness of policies to those who have to live by them. Often users seem to think that policy is something that is going to stand in the way of their daily work. An important element of policy development, and to ensure policies are put into practice and not rejected by the users, is to convey the message that policies are useful to users: to provide a framework within which they can work, a reference for best practice and to ensure users comply with legal requirements. Once users realize that policy is something that may actually help them as they do about their work, they are much more likely to be receptive to both helping you develop it and living up to it to ensure compliance. Similarly, once senior management realize that policy is a tool they can leverage to help ensure adherence to legislative requirements and to move forward much needed new initiatives, they are much more likely to be supportive of policy in terms of financial and resourcing support as well as becoming policy champions themselves.

Who Will Use Your Policies?

Audience Groups Your audience is of course all your company employees, but this group can be divided into audience sub-categories, with the members of each sub-category likely to look for different things from information security policy.

The main audiences groups are:

• Management – all levels

• Technical Staff – systems administrators, etc

• End Users

All users will fall into at least one category (end-user) and some will fall into two or even all three.

Audience and Policy Content

The audience for the policy will determine what is included in each policy document. For example, you may not always want to include a description of why something is necessary in a policy - if your reader is a technical custodian and responsible for configuring the system this may not be necessary because they are likely to already know why that particular action needs to be carried out. Similarly, a manager is unlikely to be concerned with the technicalities of why something is done, but they may want the high-level overview or the governing principle behind the action. However, if your reader is an end-user, it may be helpful to incorporate a description of why a particular security control is necessary because this will not only aid their understanding, but will also make them more likely to comply with the policy

Allow for the fact that your readers will want to use the policies in a number of ways, possibly even in more than one way at one time. For example, when first reading a policy document, an end-user may be interested in reading the entire document to learn about everything that they need to do to help protect the security of the company. On another later occasion however, the user may reference the document to check the exact wording of a single policy statement on a particular topic

Policy Types

Policy Hierarchy Overview

a hierarchy for a fairly mature, developed process, probably aligned to that possible in a large company where policy development has been underway for several years. For smaller companies or for those just starting to develop policy, it is possible to use this basic framework, but to initially have a smaller number of Technical Policies and possibly no guidelines or job aids early in the process. Rather than trying to develop a large hierarchy all at once, it is more realistic to develop a Governing Policy and a small number of Technical Policies initially, then increase the number of policies and supporting documents, as well as the complexity of the policies as you move forward.

Governing Policy

Governing Policy should cover information security concepts at a high level, define these concepts, describe why they are important, and detail what your company’s stand is on them. Governing Policy will be read by managers and end users. By default it will also be read by technical custodians (particularly security technical custodians) because they are also end users. All these groups will use the policy to gain a sense of the company’s overall security policy philosophy. This can be used to inform their information security-related interaction with business units throughout the company. Governing Policy should be closely aligned with existing and future HR (Human Resources) and other company policies, particularly any which mention security related issues such as email or computer use, etc. The Governing Policy document will be on the same level as these company-wide policies. Governing Policy is supported by the Technical Policies which cover topics in more detail and add to these topics be dealing with them for every relevant technology. Covering some topics at the Governing Policy level may help obviate the need for a detailed technical policy on these issues. For example, stating the company’s governing password policy means that details of specific password controls can be covered for each operating system or application in the relevant technical policy, rather than requiring a technical policy on password controls for all systems. This may not be the case for a smaller company, where fewer systems/applications are used and where a single technical password policy would therefore be sufficient. For a larger company however, the former method provides a more efficient process for users to follow because they will have to reference fewer documents – simplifying this process raises the odds that users will comply with the policy, thereby improving security

Technical Policies

Technical Policies will be used by technical custodians as they carry out their security responsibilities for the system they work with. They will be more detailed than Governing Policy and will be system or issue specific, e.g., an AS-400 Technical Policy or a Technical Physical Security Policy

Job Aids / Guidelines

Procedural documents give step-by-step directions on the ‘how’ of carrying out the policy statements. For example, a guide to hardening a Windows server may be one or several supporting documents to a Technical Windows Policy. Procedures and guidelines are an adjunct to policy, and they should be written at the next level of granularity, describing how something should be done. They provide systematic practical information about how to implement the requirements set out in policy documents. These may be written by a variety of groups throughout the company and may or may not be referenced in the relevant policy, depending on requirements. Procedural documents may be written where necessary in addition to and in support of the other types of policy documents, to aid readers in understanding what is meant in policy through extended explanations. Not all policies will require supporting documents. Beware however, if you find yourself getting requests for job aids for every policy document you write, your original documents may be too complex or hard to understand. Save you and your readers time by ensuring everything you write is clear, concise, and understandable in the first place.

Technical Policies

The number of Technical Policies required will depend on the number of operating systems, applications, and other technologies used by your company. Listed below are some categories that can be used to identify policy needs in each area. Each entry in a category represents a single Technical Policy document. This is by no means an exhaustive list and while the list for any given company will be dictated by the technologies in use by the company, some policies will be almost universal and most companies will need to consider developing a policy for these areas. This may seem like a large number of policies, but remember that the audience for these documents are technical people who work specifically with these technologies. Therefore, most technical staff will only have to read and know about the content of one or two technical policies. Information security employees will have to be familiar with a greater number of the documents. Another way of structuring technical information security policies is to group by security topic, e.g., one policy on authorization, another on authentication, another on securing sensitive information, etc. There are times when this works well (physical security, privacy) and times when it isn’t so successful (authentication, authorization), particularly for companies whose policy development model hasn’t reached full maturity. The company’s baseline stance on authentication fits comfortably into the Governing Policy for example, but when it comes to the detail on authentication (differences between platforms, etc) this is best tackled in the Technical Policy for as many technologies as need it rather than in a single authentication policy.

The list below is a sample list of some of the policies a company might expect to develop7 . Note however that the universal list is virtually endless and therefore each company’s list will be different. Depending on how your company is set up, you may also group these policies differently, for example it may make sense to include your policy statement on VPN in your Remote Access Technical Policy in some cases. Another company might decide to have a single Technical Policy dealing with all peripheral devices while a larger company which uses many types of these devices might decide to have several policies dealing with individual devices types.

Operating Systems

Windows

UNIX

Linux

Mac OS

OS400

zOS

Solaris

Applications

Applications (a single document covering applications development policy, including policy for web, vendor, and in-house applications)

Oracle

DB2

SQL Server

SAP

B2B

IMS

Network

Router / Switch

Remote Access / VPN

Extranet

Wireless

Exchange

Web Conference

Security Devices

IDS (Network and Host-based)

Firewall

Anti-Virus

Peripheral Devices

Copiers, printers, and fax devices)

Voice Communications (including VOIP)

PDAs and other portable devices such as USB keys, flash drives

CDs/DVDs

Cryptography

Encryption

Key Management Physical Security Physical Security Lab Security

Policy Development Team

It is important to determine who is going to be involved in the actual development phase of policy at an early stage. The group who develops the policy should ideally also be the group who will own and enforce the policy in the long-term; this is likely to be the information security department.

Primary Involvement

Information Security Team-

A team or part of a team from this group should be assigned the overall responsibility for developing the policy documents. Overall control may be given to one person with others in a supporting role. This team will guide each policy document through development and revision and should subsequently be available to answer questions and consult on the policy

Technical Writer(s)-

Your company or security department may already have a technical writer on staff who can assist in writing security policies. Even if they are not able to take primary responsibility for the information security policy project, an in-house technical writer can be a valuable resource to help with planning your policy project, determining an appropriate style and formatting structure for your documents, and editing and proof-reading your policy drafts.

Secondary Involvement

The following groups may (and in some cases, should) have input during the development of the policy in reviewing and/or approval roles.

• Technical Personnel –

In addition to staff on the security team, you may need to call upon the expertise of technical staff who have specific security and/or technical knowledge in the area about which you are writing. They will be familiar with the day-to-day use of the technology or system for which you are writing policy, and you can work with them to balance what is good security with what is feasible within your company.

• Legal Counsel –

Your Legal department should review the policy documents once they are complete. They will be able to provide advice on current relevant legislation such as HIPAA and Sarbanes Oxley, etc that requires certain types of information to be protected in specific ways, as well as on other legal issues. The Legal department should also have input into the policy development process in terms of-letting the policy development team know about forthcoming legislative requirements and helping to decipher these for the team. • Human Resources – The Human Resources department may need to review and/or approve your policy depending on how you have determined that your policy will relate to existing company policies. Where your policy touches on topics covered by existing HR policy, e.g., email usage, physical security, you must make sure that both sets of policy say the same thing.

• Audit and Compliance –

The Internal Audit department in your company are likely to be involved in monitoring company-wide compliance with the policy once it is in force. It is therefore useful if they are involved in the development and review processes for policy to ensure that it is enforceable in terms of their procedures and current best practice. If there are other compliance groups additional to the main internal audit department, these groups should also be consulting as needed.

• User Groups –

During revision of policy documents, it can be useful to work with users to determine how successful current policy is, and thereby determine how the policy may need to be changed to make it more useable for your target audiences. Issues such as the style, layout, and wording of your policy documents may seem minor issues compared to their content, but remember that if your documents are off-putting or hard to understand, users may not read them fully or may fail to understand them correctly, thereby needlessly risking security compromise

Policy Document Outline

Introduction -

This section should introduce the policy by name and locate it within the hierarchy of other existing information security and company policy documents.

Purpose-

State the main goals of the policy; this will explain the reason for the policy and will help readers understand how the policy should be used. Legal and compliance issues should also be mentioned in here. Include statements on any specific legislation the policy is designed to adhere to.

Scope-

The scope is a statement of the infrastructure and information systems to which the policy applies, and the people who are stakeholders in it. Stakeholders would typically include anyone who is a user of the information or systems covered by the policy.

Roles and Responsibilities- This is a statement of the structures through which the responsibilities for policy implementation are delegated throughout the company. Job roles may be specified in this section, e.g., Database Administrators (DBAs), Technical Custodians, Field Office employees, etc.

  Sanctions and Violations –

This section details to what extent breaking policy is considered a violation (e.g., it is HR-related and therefore related to an employee’s contract, or is it an information security department matter?) This section should also detail how violations should be reported, who to and what actions should be taken in the event of a violation. It should also include information on what sanctions will be carried out resulting from a violation (for example, verbal or written warnings, etc).

Revisions and Updating Schedule –

This section defines who is responsible for making updates and revisions to the policy and how often these will take place. It may be useful to include a reference to the document as a “living document” which can be updated as determined by those responsible for updates and revisions. This will ensure that any ad hoc revisions are accounted for as well as scheduled updates. Information should also be included detailing where the policy will be published and how employees can access it

Troubleshooting

This section details some of the things that go wrong during policy development and some ideas to remedy these problems.

Policies Lack Weight-

It is a big concern when policies that have taken time and effort to develop are not taken seriously. This is common when starting to develop information security policies and for those whose development process isn’t yet mature. Don’t worry too much at these early stages. Weight is likely to come with time and increasing numbers of policies, backed up and promoted by a combination of management backing and a good awareness/communication campaign. With this will come a realization on the part of the enterprise (and particularly those bodies involved in compliance and governance) that policy can be used to leverage change and a move towards best practice and compliance.

Lack of Reviewing Feedback –

Lack of feedback following reviews can also be a fairly common complaint from the policy development team. This is fine if the reviewers have read the policy and simply don’t have any feedback; the problem arises when they have skimmed over the document without reading it closely or taking in the implication of its content. In these cases problems may only be noticed at a much later stage or, even worse, after publication. This can serve to weaken the policy and even discredit the policy development process as a whole. One solution is to review each document in detail at a meeting (or meetings) with each group of reviewer. The development team representative can read through each policy statement and seek feedback on each one. This will help make sure the reviewers have both read and thought about the policy in detail. Sometimes reviewers may not be sure what is required of them and this may result in a low level of feedback. To avoid this, inform all your reviewers about the process and what is expected of them (e.g., you are looking for feedback on the technical content of the policy rather than on typos and grammar errors). Another possible reason for this is simply not giving the reviewers enough time to review. Be aware of their workload and agree a realistic timescale in advance. If you are dealing with review groups regularly for more than one policy, agree a regular timescale and stick to this.

Conclusion

Policy is both the starting point and the touchstone for information security in any company. Policy provides evidence of the company’s stance on security and provides a living tool for every employee to help build and maintain that level of security. It is therefore essential that security policy is accurate, comprehensive, and useable. It can be a daunting task to produce policy that lives up to this standard. Assessing policy audiences, topics, and methods using the processes I have described in this paper will help to ensure that your policy documents are as efficient and use able as possible. In turn, this will help ensure that your efforts to raise the standard of security in your company are worthwhile..

Related Questions

Navigate

• Browse (All)
• Browse S
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.