AllWhy SOX Compliance is Impossible without Privileged Management
Why SOX Compliance is Impossible without Privileged Management
control design, implementation
and operating precision sufficient
to detect error that could cause
material misstatement.
Protected
information
is stored and
transmitted
in a variety of
systems across
an organization’s
network.
In the early days of SOX, the
SEC and PCAOB had very little
guidance to provide the audit
community regarding the shared
responsibilities for evaluating
an organization’s IT control
risk in the context of ICFR
other than to point internal
and external auditors to those
technology controls that could
be a “source of likely potential
misstatements” in the financial
statements. As financial audit
practices matured, the PCAOB
recognized the need for external
auditors to intelligently assess the
information technology controls
involved in ICFR audits.
Two standards are of particular
import here:
• PCAOB Auditing Standard
No. 5, which states that
“the auditor should assess
… the extent of information
3
technology (`IT`) involvement
in the period-end financial
reporting process.”
• Auditing Standard No.
12, which states, “The
identification of risks and
controls within IT is not a
separate evaluation. Instead,
it is an integral part of the
approach used to identify
significant accounts and
disclosures and their relevant
assertions and, when
applicable, to select the
controls to test, as well as
to assess risk and allocate
audit effort.”
The impact on corporate IT
The trend towards using
technology in virtually every
step of the process of producing
financial statements, combined
with this pressure on audit
firms to provide additional
evidence, has in turn placed
pressure on public companies to
identify, collect and provide more
evidence of effective IT general
controls (ITGCs). Now more than
ever, IT departments of public
companies need to be ready to
provide evidence of effective IT
general controls to their external
audit firms.
What does this entail? SOX ITGCs,
which are implied in section
302 and 404 of the Act, include
both basic and enterprise-wide
IT security controls that require
organizations to:
• Reduce opportunities for
financial data tampering
— One strategy is to enforce
a disciplined process of
authorizing privileged user
roles and responsibilities
around financial data not
only within the application
layer but also within its
underlying technologies. This
would include defining who
is authorized to approve
access to the infrastructure
of financial systems, including
network and server hardware,
operating systems, log files,
and databases of applications
running financial transactions
such as purchase orders.
• Reduce opportunities
for reporting period
tampering — For example,
organizations can enforce
least-privilege access control
models at the operating
system level of the financial
data environment, audit all
system time change events,
and monitor activities of
user accounts with access to
system time clocks.
• Monitor who had access to
what financial information
and when — This could
include monitoring activities
of user accounts with access
to servers that record,
transmit or store activity
on systems containing
financial data.
• Monitor automated
transactions that affect
financial data — Examples
include inventory movements
and account reconciliations.
• Monitor manual
transactions — This
includes, for instance, postclosing journal entries.
• Ensure ongoing
effectiveness of controls
— For example, organizations
should actively review all
suspicious events occurring
within their IT systems
and provide their external
auditors the results of
this process.
Risks that every organization
should assess
While the text of the Sarbanes
Oxley Act does not specifically
mention internal controls for
access to financial data, it’s clear
across all industries that an
issuer’s signing officers cannot
assert that their company has
an effective system of internal
controls without ensuring
properly controlled access to
their financial data, via both
financial applications and the
underlying infrastructure. For
privileged access to be properly
controlled, at a minimum, all
public companies must assess the
following risks:
• Lack of separation of
development and test
environments from the live
production environment,
including but not limited
to proper network
segmentation and controls
around changes in the
production environment
• Unauthorized or unmonitored
privileged access to financial
data the company relies
on or could potentially
rely on when preparing its
financial statements
• Unmonitored significant
financial transactions,
financial data updates and
related system controls at
the application, database,
operating system, hypervisor,
network device and
hardware level (including
connections from all possible
accessing devices)
4
• The abuse of system
accounts and privileged
utility programs
• Unauthorized, unmonitored or
uncontrolled modifications to
source code
• The use of weak passwords,
default passwords, static
passwords, unencrypted
stored or transmitted
passwords, shared user
accounts, non-named
accounts, and aging accounts
in all environments where
financial data, authentication
data or source code exists
• Persons granted multiple
privileged access profiles (for
example, roles) that produce
a conflict of interest
One Identity privileged
account management
(PAM) solutions
The security features
of primary applications
are insufficient.
With all of the risks that can arise
from poorly managed privileged
access, it is not surprising that
auditors today look for extensive
controls related to privileged
access management. But using
the group permissions and rolebased management features of
primary applications (financials,
payroll, ERP, POS, e-commerce
and so on) to protect sensitive
information is not enough to
safeguard that information. ICFR
auditors know that protected
information is stored and
transmitted in a variety of
systems across an organization’s
network, including the support
systems (such as file servers,
mail servers, backup servers,
development and test servers,
and network devices) and
underlying platforms (databases,
operating systems, hypervisors
and VM hosts) that make up
the environment outside the
organization’s primary business
applications. Therefore, those
systems and platforms must
also be included in the ICFR
risk analysis and protected by
appropriate controls.
Organizations
need to
supplement
application-based
security features
with privileged
account access
controls that
protect the entire
environment
subject to
compliance
regulations.
Automating privileged
account management and
streamlining compliance
When auditors evaluate a financial
statement control risk, such
as monitoring user access to
financial data and management
override situations, PCAOB
Auditing standard No. 5 points
Please complete the form to gain access to this content
