Password
Policy Change: Aligning to SOX
Samuel
Warren
IS464
Policy
City
University of Seattle
Professor
Ryan Gunhold
February
10, 2012
Revision
and Signoff Sheet
Change Record
|
Date
|
Author
|
Version
|
Change reference
|
|
2/10/12
|
Samuel Warren
|
1.0
|
Initial draft
for review/discussion
|
|
2/11/12
|
Samuel Warren
|
1.1
|
Edit for
grammar and formatting
|
|
2/11/12
|
Samuel Warren
|
1.2
|
Final version
for submission.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Reviewers
|
Name
|
Version approved
|
Position
|
Date
|
|
Ryan Gunhold
|
1.2
|
Project
Sponsor
|
|
|
Amber Warren
|
1.1/1.2
|
Content Editor
|
2/11/12
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||
Signoff
|
Amber Warren
|
2/11/12
|
|
Editor
|
Date
|
Signoff
|
|
|
|
Project Sponsor
|
Date
|
Table of Contents
1 Executive Summary.............................................................................................................................................................. 1
2 Introduction........................................................................................................................................................................... 2
2.1 Objectives......................................................................................................................................................................... 2
2.2 Audience........................................................................................................................................................................... 2
2.3 Scope................................................................................................................................................................................. 2
2.4 Risks / Concerns............................................................................................................................................................. 2
2.5 Governance Structure..................................................................................................................................................... 2
3 Problems with Current Policy........................................................................................................................................... 4
4 Change in Policy Explanation............................................................................................................................................ 5
4.1 Two-Phased Approach................................................................................................................................................... 5
4.1.1 Technical Implementation....................................................................................................................................... 5
4.1.2 Process/Policy Implementation.............................................................................................................................. 5
4.2 How the Changes Comply with SOX............................................................................................................................ 6
4.3 Importance of Strong Passwords................................................................................................................................. 7
4.3.1 Optional Tools.......................................................................................................................................................... 7
5 Deployment Plan for new policy....................................................................................................................................... 9
5.1 Schedule of tasks............................................................................................................................................................ 9
5.2 Communication Plan...................................................................................................................................................... 9
5.3 Training Plan................................................................................................................................................................. 10
5.4 Deployment Support Service Level Agreement...................................................................................................... 10
6 Enforcement plan................................................................................................................................................................ 12
6.1 What to Expect.............................................................................................................................................................. 12
6.2 Consequences of Noncompliance............................................................................................................................. 12
6.3 Ongoing Training and Support................................................................................................................................... 12
6.4 “Sunset” Clause............................................................................................................................................................. 13
7 References............................................................................................................................................................................. 14
During
a recent audit, our organization was determined to be noncompliant to the
Sarbanes-Oxley Act (SOX) in the areas of password and access control. What is
clear is the need to update the policies, processes, and systems associated
with password control.
There
are several components to SOX, but it clearly stipulates that organizations are
required to establish an “adequate internal control structure,” including
control over system access. Sections 302 and 404 of SOX specifically
require CEOs and CFOs to ensure their business processes are under
control. (PistolStar Authentication Solutions)
To
comply with SOX, the IT department and Policy Committee have launched a new
project that will bring all applications, all processes, and all policies
related to the aforementioned SOX standards. The project team will start with a
discovery phase. During that phase, the team will document requirements, use
cases, and interview key Stakeholders. After that has been completed, a
two-phased implementation involving technical and policy/process change. As
soon as the implementation phase is completed, Training and Support roll out.
Also, key to the adoption of this change is a “Sunset” clause. No employee will
be held responsible for lack of policy compliance during the effective timeline
of the clause.
With
such a large project, it is very important that all the various department
heads are extremely involved in communication and training. If the organization
is able to work cohesively as a large team, it will not only make the project
successful, but also decrease the amount of time to implement the changes and
increase the speed of adjustment to the new processes and policies.
The
Objectives of this policy stub are two-fold. To educate all staff members on
the need for compliance to HIPAA and SOX password compliance and to describe
the changes in moderate detail.
The
audience this policy stub is directed at is the current policy owner and all
staff using any electronic device associated with our organization
In-Scope
items include policy change, process change, and systems change to accommodate
new policy change.
·
Enforcement by management
·
Employee buy-in
·
Cost of implementation
Governance
of the password policy comes in two stages: technical and business. For the
Technical governance, the IT director will be responsible for overall adoption
of the technical changes and support once the changes have been made. The
business owner will be the primary driver for all changes in policy and
process. Implementing the correct process is crucial to the continued
compliance. Understanding that department manager is responsible to account for
alignment with policy. The final stakeholder to mention with respect to
governance is Human Resources. Human Resources will enforce noncompliance up to and including termination. For more
details, see Section 6 on Enforcement of the policy.
Current
policy for access and control does not meet required policy controls for HIPAA
and SOX compliance standards. In the event of an audit, our compliance in the
area of passwords would not pass minimum criteria. Among access tools needing
to be considered are Username and Domain names. Of those, the goal is to
address our username and domain masking in separate policy documents. We accept
any combination of upper and lowercase letters and no symbols. We also allow
full access to our proprietary applications without needing a separate password
to anyone who has access to our network. According to SOX regulations, we
should only allow access to the systems if the person is required to access it.
According to Derek Melber in his 2010 White paper:
It
is this reason why so many compliance regulations are putting effort into
making the user password more secure and forcing the restrictions on how long
the password can be valid. If the password in the security model is made to be
strong, long, hard to guess, and hard to crack, then the core security model is
much more effective.
Changing the
password policy is relatively easy; however, modifying all the applications is
technically complex and requires a lot of communication and teamwork. In
addition to the “weak” passwords and the lack of application security, we do
not have password expiration dates. In section 4 Change in Policy Explanation,
we will discuss the new requirements for “strong” passwords, the time factor,
and the application level passwords.
To implement the required changes to our password
policy, it has been determined that a two-phase approach to the deployment will
be the easiest to implement with the fewest overall problems during
implementation.
Implementation
from the technical perspective will begin with a discovery phase. During this
phase of the process, new system controls like user groups, permission types,
and access control lists will be analysed and processed. All the requirements
for adding passwords, access control lists, user groups, and permission types
will be documented and workflows diagrammed. The next phase is the development
phase. In the development phase, the application developers work with the
programs, the networks, and the servers to add system passwords. Then the
system administrators will go through each application and add specific users
and user groups to specific permissions. From there, the next step is the release
and support phase for the technical implementation team. During this phase,
users try accessing the applications and contact the help desk for support on
the new passwords.
During
the release and support phase of the technical implementation, the system
administrators will work with the team managers and the executive Vice
Presidents to gain momentum for enterprise-wide policy and process changes.
They will determine the consequences for noncompliance to the policy. They will
utilize the communication plan outlined herein.
By adding a layer of
permissions, the gaps in the program will be lessened. The Policy Control Board
also feels that alignment to Section 302 of the SOX act, which discusses
disclosure, should be included into the process/policy implementation. By
following Sections 302 and 404 of SOX, we ensure that we follow these
requirements:
·
Certify that they have
reviewed financial statements and each annual or quarterly report.
·
Certify that each such
report fairly represents the company's financial condition.
·
Certify that they have
established and are maintaining internal controls.
·
Ensure the
effectiveness of such internal controls every quarter.
·
Address significant
changes in internal controls or other factors that could significantly affect
such controls.
·
Identify corrective
actions taken regarding deficiencies/weaknesses in controls.
·
Disclose any
significant deficiencies in internal controls and/or any fraud involving
persons with a significant role in upholding such controls. (MandyLion Labs,
2012)
These
requirements are the base requirements that have been used for both technical
and policy/process implementation phases. While it is not as comprehensive as
some may think, it does give quite a bit of information to use as a starting
point for building a more secure system.
At the heart of this policy is a simple request. Make
passwords strong. Do not use “password” as the password. Usernames can only be
so strong, but the single point of failure for many companies is the password.
According to Joel Dubin, an independent IT Security expert, “The purpose of
making passwords more complex and indecipherable is to prevent so-called
dictionary attacks, where hackers run password hash files through programs like
‘John the Ripper,’ which look for common words in dictionaries used as
passwords” (2007). Having strong passwords, using combinations of symbols, numbers,
and making it obscure knowledge will go a long way to making the password
strong. Instead of using “I love my wife,” try using something like
“1_lv_w1f3.” Another great way to obscure passwords is to add a mixture of
upper and lowercase letters and symbols to form a very personal reminder. For
example, try using “Ju43#is#m7#SON” instead of “Judeismyson.”
In
order to make it easier on staff during part of the technical implementation phase,
the IT staff will install an optional tool called “Password Safe.” Password
Safe is a product that keeps track of all the passwords a user has in a secure
place that is accessible only through a separate password. The concept being
that one would only have to remember one password and generate strong passwords
using Password Safe for all the required passwords. When the user is ready to
access the password, they can copy and paste their strong password from the
safe and never have to remember.
Password
Safe allows you to manage your old passwords and to easily and quickly
generate, store, organize, retrieve, and use complex new passwords, using
password policies that you control. Once stored, your user names and passwords
are just a few clicks away. (Passwordsafe.sourceforge.net)
Using
a tool like this will enable simple, strong password creation and storage with
fewer passwords to remember. As previously mentioned, the IT department has
worked heavily with Password Safe to purchase some licenses, which will enable
the organization to use this handy tool.
The
following are a list of high-level tasks and milestones and their estimated
delivery date.
|
Discovery phase kick off meeting
|
February 13, 2012
|
|
Documentation
and Key Stakeholder interview findings
|
March
7, 2012
|
|
Knowledge transfer from
|
March 8-9, 2012
|
|
Begin
Technical phase
|
March
13, 2012
|
|
Complete Release 1 of Technical phase
|
April 23, 2012
|
|
Begin
Policy/Process change phase
|
April
23, 2012
|
|
Begin Release 2 of Technical phase
|
April 24, 2012
|
|
Complete
Release 2 of Technical phase
|
May
18, 2012
|
|
Complete Policy/Process change phase
|
May 11, 2012
|
|
Deployment
communications begin
|
May
21, 2012
|
|
Support and Analysis of new policy
|
May 22, 2012
|
|
“Sunset”
Clause Expires (see Section 6.4)
|
July
27, 2012
|
Given the number of
applications needing change and the amount of architecture required to
implement the changes, this timeline is very ambitious. Please allow up to four
weeks of additional “padding” for potential roadblocks and other issues. Due to
the time of year, the business feels that this level of change will be
minimally impacting to the organization, thus not needing the additional four
weeks.
The communication for
the changes will begin by line management communicating the changes to the
affected staff. Once that has been done, the Internal Communications team will
coordinate with the Executive Committee for wording and channels to target. The
Internal Communications team will create memorandums, intranet articles, email,
and in-person meetings to explain the new processes, policies, and software
changes. Additionally, they will publish a comprehensive listing of the systems
affected by the change.
Training for the new
systems, including the use of Password Safe, will be done in four 2- hour
training sessions. Each employee will be scheduled for one of the four sessions
that will occur in August 2012. Upon completion of the training, the IT
department will assign temporary passwords to each employee and give them 24
hours from their training day to enter a new password. Each employee will be
given a password, which they can change, for their access to their personal
Password Safe installation at the training session. Upon completion, the
training materials will be furnished in the intranet in the “Resources”
section. All employees are required to take the training or go through the
optional e-training at their manager’s discretion.
The IT department has
agreed to Support the changes in the affected systems. A Service Level
Agreement has been created to govern response times from the IT department. The
following table is an outline of the aforementioned agreement:
|
Issue type:
|
Timeline to respond:
|
|
Severity 4- Low priority (for example:
password resets)
|
72 hours to respond, depending on
solution 24 hours+ to implement fix.
|
|
Severity
3- Medium priority (for example: Password Safe won’t work)
|
48
hours to respond, depending on solution 24 hours+ to implement fix.
|
|
Severity 2- High Priority (for example:
application permissions improperly assigned)
|
24 hours to respond, depending on
solution 24 hours+ to implement fix.
|
|
Severity
1- Extremely Urgent (for example: application does not load at all)
|
1
hour to respond, depending on solution 24 hours+ to implement fix.
|
The policy will be
enforced predominantly in regards to process/policy. If staff members breach
any processes or policies, the consequences will be enforced by the chain of
command with HR input. Any disciplinary action must fall within HR guidelines.
Those habitually using weak passwords will have their password reset
automatically and an email will be sent to them with a carbon copy sent to
their manager as to the reason for the change. The employee will then have
three days to fall into compliance.
The consequences of
noncompliance include, but are not limited to, verbal warnings, written
warnings, and possible termination. In the event of termination, the
organization, represented by HR, will exercise its right as a “Right to Hire”
employer. HR will work directly with the employee’s manager to ensure that
there are no violations of “Equal Opportunity” standards prior to signing the
termination note and escorting the employee outside the secured portion of the
building. HR will make copies for the employee’s permanent file and a copy for
the manager’s records.
After the initial
training period, the onus will be on the managers to make sure their employees
are trained in the use of Password Safe. However, the contents of the 2-hour
training session, minus the pieces with Password Safe, will be taught as a part
of the on-boarding process for new employees. By working with the current
employees and training the new employees as they come into the organization, it
is estimated that 100% of the employees will be trained in the new system
changes, policies, and processes. Along with that, the organization will be
doing yearly audits on the password policy to maintain relevance.
To allow for ease of
transition, all new processes and policies will be in place on a provisory
basis and phased in over the course of two weeks. No employee will be given any
sort of punitive measure during this window. To better illustrate, notice the
phase-in of the new processes and policies does not fully begin to take effect
until about day 6. That is due to the communication and adjustment period
needed to bring staff up to speed. Once that is in effect, the old policies and
processes will begin strategically fading out, starting with the least business
impacting. During this two week “Sunset” of old policies, it is expected that
employees will have questions and need further support, hence the lack of
punitive measures for noncompliance.
Authentication Solutions - The Sarbanes-Oxley Act
(SOX). (n.d.). PistolStar Authentication Technologies - Simplify Application
Logons. Retrieved February 8, 2012, from http://www.pistolstar.com/authentication-solutions/regulation/SOX.html
Dubin, J. (2007, October). Complex password
compliance requirements made simple. Information Security information, news and
tips - SearchSecurity.com. Retrieved February 8, 2012, from http://searchsecurity.techtarget.com/tip/Complex-password-compliance-requirements-made-simple
Gunhold, R., & Resonant Insights, Inc. (2011,
November). Sharepoint Governance Plan (Ver. No. 1.0). Retrieved from Policy
Professor, City University website: http://courses.cityu.edu/@@/29D29B7214A06ADA38E4B485AB2E7229/courses/1/11231274/db/_4442658_1/RGunhold%20-%20Governace%20Plan%20Sample_md%20edits.docx
Melber, D. (2010). Meeting HIPAA/Hitech Data access
and password requirements in the Windows healthcare enterprise. Retrieved from
SpecOps Software USA INC. website: http://www.specopssoft.com/resources/white-papers/hipaa-hitech-password-security-in-active-directory
Password Safe. (n.d.). How many passwords do you
have to secure? [Product Site]. Retrieved February 10, 2012, from SourceForge
website: http://passwordsafe.sourceforge.net/index.shtml
Regulatory Compliance. (n.d.). MandyLion Research
Labs. Retrieved February 8, 2012, from http://www.mandylionlabs.com/compliance/compliance.htm
No comments:
Post a Comment