Do's and Don'ts of Working with Auditors
SOX, PCI, ISO? You're going to have to work with
auditors eventually.
Whether you're working with an auditor who's
performing an internal or external Sarbanes-Oxley
(SOX) audit, a Payment Card Industry (PCI) audit, a
SAS 70 audit, an ISO audit, or any other type of
audit, some fundamental "do's" and "don'ts" exist.
Since every organization has to go through some type
of audit these days, I thought some tips for working
with an auditor might be helpful.
Audits go much more smoothly if you have done your
homework before the auditors arrive. Here are some of
the ways you can prepare for an audit:
Understand the Scope of the Audit
Understanding the purpose and scope of the audit is
critical to passing the audit. Audits do not come in
"one size fits all." While one auditor performing an
external audit may ask for a list of all users with
*ALLOBJ special authority, the SOX auditor working on
your account may examine all of your documentation on
creating user accounts for each system in your
organization. Understand the purpose of the audit
(external, SOX, PCI, etc.) and prepare accordingly.
If your organization has gone through an audit of this
type before, start your preparations by looking at
last year's results. While the auditor may not look at
the exact same things again, it will help give you an
idea of what to expect. Pay particular attention to
the issues that were listed as needing remediation
(fixing). The auditor will most assuredly be checking
to ensure that these have been addressed. In addition,
look for items that didn't require remediation but
were listed as lesser issues. I've seen auditors
require remediation for those. The best course of
action is to fix those issues as well. If you don't
have time or resources to accomplish that, at least
write a formal work plan to address the issue or a
risk-acceptance statement if you have no intention of
ever addressing the issue. Finally, if you don't have
time to write a formal statement of work to address
the issue and it's something you do intend to address
in the future, spend some time thinking through what
you will do if you are required to remediate the
issue. This way, you'll be prepared to discuss with
the auditor your remediation solution or your methods
for mitigating the risk should the topic arise.
Understand the Laws and Regulations That Apply to This
Audit
If you are being audited against a specific law or
regulation—such as the Graham-Leach-
or SOX—I recommend that you (personally) read that law
or regulation. For example, systems storing credit
card numbers are subject to the regulations of the
Payment Card Industry (PCI). The PCI sends out
auditors to ensure regulations are being followed. If
you're about to undergo a bank audit, your company
needs to comply with the GLBA or perhaps Basel II.
Why understand the laws and regulations? Knowledge is
power, as the saying goes. Knowing the laws or
regulations associated with the audit will help you
better understand and better prepare for what the
auditor will be examining during the audit. Links to
the more popular laws and regulations can be found
here.
Do Be Prepared
Being prepared for an audit before you go into it will
greatly assist in getting through it more quickly.
Here are some ways you can prepare.
Have Your Security Policy Ready
One of the documents an auditor may request is your
security policy. Large or small, all organizations
need a written security policy. It doesn't have to be
complex or long-winded, but it does need to be a
written policy that has management approval. Why? A
security policy documents the organization'
issues such as classification of data, data access,
appropriate use of technologies such as email and the
Internet, etc. Without a written policy, there can
easily be conflict within the organization and
disagreement over what data should be protected or
what services should be allowed. And, from an
auditor's point of view, without a written policy
there is no way for him or her to know whether or not
the organization is following its policy because the
implementation cannot be compared to the
organization'
Perform an Assessment
Rather than let your auditor discover your system's
vulnerabilities or a process that is not documented
accurately, it is far better to discover them yourself
prior to the audit. In addition, some laws such as the
Health Insurance Portability and Accountability Act
(HIPAA) and PCI's Data Security Standard require a
periodic assessment of your systems and networks.
Performing an assessment allows you to discover areas
of weakness (i.e., vulnerabilities) and determine what
to do about them. When vulnerabilities are discovered,
they should analyzed to determine the risk level they
pose to the organization. Once that's been done, three
options exist:
For high-risk vulnerabilities, issues should be
remediated (fixed) soon if not immediately.
For vulnerabilities whose risk is low or can be
mitigated, a risk acceptance statement should be
written, documenting why the vulnerability does not
constitute a significant risk to the organization, why
the impact to the business outweighs the risk, or what
mitigating factors are in place or being put in place
to lower the risk to the organization.
For vulnerabilities that are too risky to accept but
cannot be fixed right away, a work plan should be
created. If the vulnerability is discovered by the
auditor, a documented work plan will show the auditor
that you understand the issue and plan to fix it.
What do you measure your system against? Security
"best practices." One example of best practices is the
PCI's Data Security Standard. Other examples include
CobiT and ISO 27001. For translation from these best
practices to i5/OS settings, check out the iSeries
Security Reference manual available from the System i
Information Center as well as the book I co-authored
with Patrick Botz, Experts' Guide to OS/400 and i5/OS
Security.
Secure Your Data Appropriately
Based on your organization'
want to make sure that your organization'
secured appropriately. This means that access—both
through an application'
direct access (such as command line access)—is
appropriate and matches the requirements of the data
access and data classification sections of your
security policy. Be prepared to show proof that you
have in place both menu controls and access controls
that support the implementation of your policy.
Secure Your System Appropriately
Securing your system constitutes more than just
setting the appropriate authority on data files. User
profile configuration, system values, and TCP/IP
auto-start values all need to match your policy.
However, just because they match your policy doesn't
mean they satisfy the auditor's requirements,
especially system value settings. Unfortunately, many
auditors have little or no knowledge of OS/400 or
i5/OS. Auditors may come prepared with a checklist of
"appropriate" system value settings. Often, this list
is out-of-date and contains required settings that no
longer make sense for today's system configurations.
This is why risk acceptance statements need to be
written for system values (and other security
configuration items) that cannot be set to the value
recommended by best practices. In the risk acceptance
statement, explain the disruption to productivity, the
function that will break, etc. along with any
mitigating controls you are taking to reduce the risk
of the value not being set to the most secure setting.
Document Your Processes
Auditors look for processes that will assure them that
appropriate controls are in place to ensure the
integrity, accuracy, or privacy of the data being
examined. The processes required may vary slightly,
but the ones I see auditors require on a consistent
basis include these:
Change management documents how objects (programs and
files) get moved into production. This includes the
process programmers go through to gain access to
modify data on a production system.
"Patch" management documents how fixes (PTFs, in i5/OS
terms) get applied and tested.
Request for user access documents the process an
employee or manager has to go through to request new
or additional access to an application, system, or
network.
Inactive profiles documents how and when inactive
profiles are managed.
Save strategy documents the schedule for how and when
data is saved.
Disaster recovery documents how the organization would
recover from various types of disasters.
These processes need to be documented (along with the
other processes deemed critical to your business).
Auditors will also look for evidence that these
processes are being followed. An auditor may literally
watch people perform their jobs to see if they are
following the exact steps documented in the process.
Therefore, it is vital that the process documentation
is up-to-date and matches the actions actually
performed.
Be Ready for the Auditor's Arrival
If, prior to their visit, the auditors request a
specific set of reports to be generated or other
information to be gathered, have the reports and
information available upon their arrival. Making
auditors wait for reports or information provides them
with free time to think of other reports to run or
other areas of the organization to examine. Have those
reports and information ready for them the minute they
arrive!
Provide a Focal Point
Consider providing a focal point for all audit
questions. Some organizations, such as banks, can go
through numerous audits each year. Various auditors
may request similar reports. The focal point can
provide process documentation or the reports generated
for a prior audit without having to bother IT. In
addition, the focal point can provide guidance to
users who have never participated in an audit. The
focal point can educate these users about appropriate
ways to answer auditor questions and interact with
auditors.
The Don'ts
Now that we've reviewed what you should do, let's
review what you should definitely not do.
Don't Be Mean
Auditors are people. Treat them as such. You may not
enjoy the fact that you have to go through an audit,
but that's not the auditors' fault. They're just
trying to do their job.
Don't Guess
If the report that your auditor is asking you to
produce or the type of information requested doesn't
make sense to you, ask a clarifying question. It's
(quite) likely that the auditor is asking for
information using terms that are more widely used in a
Windows or UNIX environment. As such, you may have to
"translate" these into i5/OS terms. To do that, you
may need to ask for an example or for further
explanation of the type of information the auditor is
asking you to gather.
Don't Be Over-Zealous
Don't provide more information than is asked for. If
you're asked to provide a report of all of the users
with *ALLOBJ special authority, don't hand the auditor
a report of all users on the system (unless of course,
all users actually have *ALLOBJ!). Reports with more
information than requested can confuse the auditor or
prolong the audit by causing the auditor to
investigate other areas that might have otherwise been
left alone.
Don't Answer for Someone Else
When questioned by an auditor, do not answer for any
process or action that is not your responsibility or
for which you do not have direct knowledge. Processes
and situations can change, and you do you not want the
responsibility of providing an inaccurate or
misleading answer to the auditor.
Don't Elaborate
While you must answer any question the auditor asks,
you don't need to elaborate outside of the specific
question being asked. Now is the time to be literal
and answer only the question asked. For example,
suppose the auditor asks, "Do you update production
data?" If the answer is "no," say only that. Don't
say, "I don't, but Joe and Sally access production
systems and update data all the time."
Don't Lie
Lying is never a good idea. Lying to or misleading an
auditor can land you and your organization in serious
legal trouble.
Don't Be Surprised
If the auditors discover something significant, don't
be surprised when it's reported to the company's board
of directors. Changes to the Statement on Auditing
Standards—specifical
Related Matters Identified in an Audit as published by
the American Institute of Certified Public
Accountants—require that auditors report findings "to
communicate, in writing, to management and those
charged with governance." "Those charged with
governance" are typically the board of directors or a
committee of directors or partners, etc. In the past,
these reports may have stopped at the IT director, but
no longer can this be the case. I don't know about
you, but this type of "attention" is not the type I
crave! This is all the more reason to perform that
assessment and fix as many issues as possible before
the auditor shows up.
Don't Kid Yourself
Just because you've passed an audit does not ensure
that your systems or data are secure. Auditors come
with varying degrees of knowledge of the applications,
operating systems, and networks they audit. Just
because an auditor does not specifically look at the
access controls of files containing private or company
confidential data does not mean that the security
configuration of the file is set accurately or
securely. In addition, the scope of the audit could
have been limited based on time and resources so that
only certain aspects of the organization were audited.
Ultimately, the security of your data, systems, and
network are your responsibility.
Carol Woodbury is co-founder of SkyView Partners, a
firm specializing in security policy compliance and
assessment software as well as security services.
Carol is the former chief security architect for
AS/400 for IBM in Rochester, Minnesota, and has
specialized in security architecture, design, and
consulting for more than 16 years. Carol speaks around
the world on a variety of security topics and is
coauthor of the book Experts' Guide to OS/400 and
i5/OS Security.
Unlimited freedom, unlimited storage. Get it now, on http://help.
"The answer(s)/advice(s) on this Group web-site are the personal opinions of the members who sent those messages. They may/or may not be based on research(s)/opinion(s) on the fact(s) provided to the Group in the said query, and any advice tendered here is subject to the accuracy of the description of facts, proposed transactions, and their purpose and
whether they constitute a complete and accurate disclosure of all
relevant fact(s), and provided the proposed transaction(s) is completed
in the stated manner. The Group Owner/Moderator and/or the group
member(s) do not even imply the accuracy or value of any advice
submitted by its member(s) and are not liable for any damages or costs,
if any, suffered through the acceptance or putting into operation either
the whole or part of any advice so tendered on the group-site. If you
have any question(s), please do not hesitate to seek clarification(s)
Here"
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch format to Traditional
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe
__,_._,___
0 comments:
Post a Comment