Sarbanes-Oxley 404 Security Controls: A Hands-on Perspective

1
Sarbanes-Oxley 404 Security Controls A Hands-on
Perspective

• SDISSA Conference November 16, 2004
• Presented by Alex Branisteanu
• Abranisteanu_at_yahoo.com

2
Introductions

• Alex Branisteanu, CISA, CPA
• Information Security Officer, Scripps Health
• Disclaimer
• - The information presented in this presentation
  represents a personal perspective on
  Sarbanes-Oxley Act (SOX) controls. It does not
  represent the opinion of and has not received
  endorsement from the presenters/authors present
  or past employers, Security and Exchange
  Commission, Public Accounting Oversight Board, or
  any other organization. The presenter/author
  makes no representation or warranties and
  provides no assurance that an organizations
  disclosure controls and procedures and the
  internal controls and procedures for financial
  reporting are compliant with the certification
  requirement and internal control reporting
  requirements of SOX, nor that an organization's
  plans are sufficient to address and correct any
  shortcomings that would prohibit the organization
  from making the required certification or
  reporting under SOX.
• - The presenter/author makes no claim that the
  use of the information in this presentation will
  assure a successful outcome. The presentation
  should not be considered inclusive of any
  appropriate procedures and tests or exclusive of
  other procedures and tests that are reasonably
  directed to obtaining the same results. In
  determining the appropriateness of any procedure
  or test, professionals should apply their own
  professional judgment to the specific control
  circumstances presented by a particular system
  within its particular control environment.
• - Examples provided in the presentation are only
  for illustration purposes and are not related in
  any way to any particular system that the
  presenter has ever reviewed, worked on, or made
  aware of. Tool examples provided are not
  endorsed by the presenter or her past or present
  employers.

3
Points covered in todays presentation

• Brief overview of SOX 404.
• Managements assessment attestation of the
  internal control effectiveness over financial
  reporting for Controls (ICOFR).
• Overall project approach the big picture.
• Hands-on approach on documenting and testing
  security controls.
• Lessons learned and references.

4
Brief overview of SOX 404

• The Sarbanes-Oxley Act (SOX) of 2002 was signed
  into law by US Congress in 07/2002.
• SOX is a reaction to the financial fall and
  malfeasance of several publicly traded companies,
  e.g., Enron, WorldCom, etc.
• Most substantive legislation pertaining to
  publicly traded companies since the Securities
  Acts of 1933 and 1934.
• Applicable to all public companies and their
  board of directors, audit committees, independent
  auditors, legal departments.

5
Brief overview of SOX 404 (cont)Sections 302 and
404

• Numerous law sections, of which two (2) stand
  out
• Section 302 requires CFOs and CEOs to certify
  quarterly that they are responsible for
  disclosure of design and operational
  effectiveness of controls, e.g., acts of fraud,
  material weaknesses.
• Section 404 with real teeth requires an
  annual evaluation of internal controls for
  financial reporting, e.g., all controls that
  provide assurance that financial statements are
  accurate.
• Definition of control (or control activity)
• Safeguards or processes that mitigate a risk, OR
• Processes effected by people designed to
  accomplish specified objectives (COSO), OR
• Actions designed to ensure data, code,
  infrastructure, and other components maintain the
  CIA (confidentiality, integrity, availability)
  triad.

6
Brief overview of SOX 404 (cont)Oversight and
Enforcement

• Enforcement agency Securities and Exchange
  Commission (SEC)
• Bodies that interpret/establish rule-making
  processes auditing standards
• SEC
• PCAOB (Public Company Accounting and Oversight
  Board).
• In 2004, SEC approved PCAOBs Auditing Standard
  2 An Audit of Internal Controls over
  Financial Reporting (ICOFR) Performed in
  Conjunction with an Audit of Financial
  Statements.
• Compliance deadlines started in 2003 and depend
  on several factors size of the company, when
  the fiscal year of the company ends, etc.
• Section 404 effective for fiscal years ending on
  or after November 15, 2003 for accelerated
  filers, or on or after July 15, 2005.

7
Managements assessment attestation of the
internal control effectivenessAuditing Standards

• Auditing Standard 2 on ICOFR requires that
  management
• A) Accept responsibility of control
  effectiveness
• B) Evaluate control effectiveness
• C) Support evaluation with sufficient evidence
• D) Provide written assessment of control
  effectiveness.

8
Managements assessment attestation
(cont)Covered IT Areas

• What Specific IT general controls integral
  part of ICOFR controls, e.g.
• Change management control
• Security (logical and physical)
• Back-up and recovery
• Job scheduling and operations, etc.
• Note Business continuity and disaster recovery
  are not in scope.
• What Specific IT application controls integral
  part of ICOFR controls, e.g.
• Edits and validation
• Disallowance of duplicate transactions
• Processing error correction
• Processing report accuracy
• Why Most financial processes are automated and
  supported by IT systems. IT systems support
  financial processing and reporting.

9
Managements assessment attestation (cont) IT
Application Controls

• Application controls controls that ensure
  transaction related processes are complete and
  accurate. Covers
• Initiation,
• Authorization,
• Recording,
• Processing,
• Reporting.
• Example Changes to customer credits master file
  are authorized and enforced through system
  (application) edits field length, number
  formats, etc.

10
Managements assessment attestation (cont)IT
General Controls

• General IT Controls controls that are pervasive
  across systems and provide the control foundation
  for application programmed controls, system
  implementations and maintenance, access security,
  duty segregation, etc.
• Note. Of all general IT controls, focus on those
  that affect ICOFR, transaction integrity, i.e.,
  accuracy and completeness. This is why disaster
  recovery is not in scope.
• Example Logging of unsuccessful sign-on
  attempts to the UNIX operating system that
  supports the payroll system, e.g.,
• Unsuccessful su attempts
• Unsuccessful attempts to change /etc/profile
  permissions
• Unsuccessful attempts to change permissions to
  other critical system files

11
Managements assessment attestation
(cont)Frequency

• How often Management must re-evaluate controls
  quarterly or whenever a change occurs that
  materially impacts ICOFR, e.g.,
• Mergers and acquisitions
• New system implementations (additions)
• Customers needs change
• Technologies change
• Acts of God

12
Managements assessment attestation
(cont)Evaluating Control Design Operations
Effectiveness

• A) Control design effectiveness Is the control
  designed properly to mitigate the identified
  risk? Can the control be circumvented?
• Highly subjective
• Based on professional judgment.
• Who evaluates control design effectiveness?
  Management.
• Value Proves that mgmt. has thought the process
  through and applied professional judgment in
  making the evaluation.
• B) Control operational effectiveness Is the
  control operating as intended/designed? Is there
  a need for remedying/enhancing the control?
• Objective - Must be tested!
• Based on test results.
• Who Generally, who evaluates the design
  effectiveness should not test the operational
  effectiveness.
• Value Will identify remediation items above and
  beyond items already identified by mgmt. during
  design effectiveness evaluation.

13
Managements assessment attestation
(cont)Control Design Operations Effectiveness
Examples

• Example Daily review of access to sensitive
  tables in the payroll system.
• Control design effectiveness
• While evaluating the controls documented by DBAs,
  the DBA manager noted that the automated reports
  ran daily, but no one reviews them.
• The DBA manager rates the monitoring control
  design as ineffective (insufficient).
• The DBA manager recommends remediation Going
  forward, 2 DBAs will review reports,
  summarize/research potential exceptions, and
  report true exceptions to the DBA manager for
  further escalation.
• B) Control operational effectiveness
• While testing the monitoring controls, the
  internal auditors found that the daily monitoring
  performed by the 2 DBAs was ineffective.
• The 2 DBAs would summarize the potential
  exceptions, but fail to report true exceptions to
  the DBA manager.
• Furthermore, reports showing potential exceptions
  when users access sensitive data tables, were in
  fact, run only monthly.

14
Overall project approach

• Step 1
• Scope and plan the project,
• Commit resources,
• Ensure executive mgmt. sponsorship,
• Form disclosure committee,
• Assign project manager,
• Allocate resources.
• Step 2
• Select an Internal Control framework. Note SEC
  recommends COSO (Committee of Sponsoring
  Organizations of the Treadway Commission.
• Understand, assess, and define process of
  transaction flow.
• Start with financial statements, work through
  accounts, and identify supporting IT systems.
• Conduct a risk assessment and define the project
  scope.
• Educate organization on what needs to be done.
• Step 3 Establish an Internal Control Program.
• Step 4 Implement Internal Control Program
• Identify and document controls.

15
Overall project approach (cont)Documentation
COSO and the Control Environment

• Five (5) COSO framework components
• Control environment - Peoples attributes,
  including integrity, ethical values and
  competence.
• Risk assessment - Define Control Objectives.
  Identify, analyze, and manage risks as pertaining
  to business operations.
• Control Activities Control policies,
  procedures, and other processes established to
  address identified risks to ensure objectives are
  accomplished.
• Information and Communication Enable people to
  capture and exchange information needed to
  contact, manage, and control operations.
• Monitoring Ensure that processes are assessed
  regularly and modifications are made as necessary
  to ensure control quality.

16
Documenting and Testing Security
ControlsDocumentation Example for
SecurityControls

• Identify the relevant security control objectives
  
• Identify risk for each objective What can go
  wrong?
• Identify relevant control activities
• Supporting Documents
• Information and Communication (IC)
• Monitoring
• Evaluation of design effectiveness
• Testing of operations effectiveness

17
Documenting and Testing Security ControlsGet
Organized Use a Software Tool, Templates, or DB

• For example, we are documenting file
  FW_Authentication Objective.
• When was the document created This file created
  in MS Access on mm/dd/yyyy.
• Who documented the file Joe Blow, System
  Engineer with Firewall Administration duties,
  reports to John Doe, Sr. System Engineer.
• Background/process The organization has 4
  firewalls all of which are XXX version 12.5.
  There are 3 system engineers with firewall
  administration responsibilities, all of which
  report to the Sr. System Engineer. User
  authentication, which requires security servers,
  and client authentication are both used. 3
  options are used for passwords OS, Radius, and
  TACACS. For client authentication, IP addresses
  are not shared. This objective focuses on
  client-to-console and console-to-firewall
  authentication. The mgmt. console is
  authenticated to the fw via IP address and pw.,
  etc, etc, etc,

18
Documenting and Testing Security ControlsStep 1
Identify Relevant Logical Security Objectives

• Examples
• Identification and authentication effectiveness
  password controls, sessions suspension after a
  predefined number of unsuccessful logon attempts.
• Account management or administration (AKA account
  provisioning and de-provisioning) manage account
  additions, deletions, and changes.
• Access authorization role-based access to
  ensure segregation of duties, ACLs.
• Temporary and emergency access emergency
  passwords, logging of emergency maintenance
  activities, notification/escalation to management
• Logging and monitoring of security violations.
• Protection of and changes to security
  configuration changes centralized security
  administration, protection of sensitive security
  data.
• Encryption of data stored and transmitted If
  used, document how keys are protected.
• Anti-virus and other anti-malicious code controls
  includes controls over media, freeware use,
  utilities, files/directories, patch management,
  vendor maintenance contracts.
• Note. Listing may not be complete! You may need
  to add other control objectives.

19
Documenting and Testing Security ControlsStep 2
For each Control Objective, Document the Risk

• For the Authentication Effectiveness control
  objective example
• Risk /What can go wrong Inadequate
  authentication could result in making
  inappropriate system (FW) changes and lack of
  accountability.

20
Documenting and Testing Security ControlsStep 3
For each Control Objective, Document Relevant
Control Activities

• Control Activities for the Authentication
  Effectiveness Objective
• 1) Initial passwords are issued in a secure
  manner.
• Upon hire, the Sr. System Engineer communicates
  the passwords to the newly hired system
  administrator verbally, not via email or phone.
• 2) Passwords are changed on first use.
• The OS (Solaris) forces password change upon
  initial use. However, RADIUS, and TACACS servers
  do not. Remediation?
• 3) Passwords have a sufficient length.
• The OS (Solaris), RADIUS, and TACACS all enforce
  passwords 8- character minimal length.
• 4) Password change frequency is appropriate.
• Neither the OS, nor the authentication servers
  enforce password change at predefined intervals.
  However, by policy, firewall administrators are
  required to change admin. passwords every 3
  months.

21
Documenting and Testing Security ControlsStep 3
For each Control Objective, Document Relevant
Control Activities (cont)

• 5) Password complexity is appropriate.
• The OS requires that passwords have at least 1
  alpha character and 1 digit. However, RADIUS,
  and TACACS servers do not. No password cracking
  tools are used to check passwords against
  dictionary listings. Remediation?
• 6) Password history is enforced.
• Neither the OS, nor the authentication servers
  prevent prior password usage. Therefore, users
  may recycle the same password. There are no
  relevant policies. Remediation?
• 7) The password is changed upon reset and users
  are authenticated before resets.
• Only 4 users have fw admin capabilities and
  hence, the ability to reset pws. All users are
  restricted to particular source and destination
  IP addresses. For resets of admin pws
  authentication is not an issue, as it is done
  only by one of 4 people.
• 8) Users are suspended after a number of
  unsuccessful logon attempts.
• The OS (Solaris), RADIUS, and TACACS lock users
  after 3 unsuccessful logon attempts. Both
  successful and unsuccessful logon attempts are
  logged. ETC. ETC.
• Note. It is OK to document compensating
  controls, see 5) above.

22
Documenting and Testing Security ControlsStep 3
For each Control Objective, Document Relevant
Control Activities (cont)

• To facilitate testing of operational
  effectiveness and minimize time impact, consider
  documenting the following for each control
  activity
• Whether the control is automated or manual.
• Whether the control is preventive, detective, or
  corrective.
• Who performs the activity.

23
Documenting and Testing Security ControlsStep 4
For each Control Objective, Document Supporting
Documents (AKA Artifacts)

• For the Authentication objective, describe
  supporting documents or artifacts, e.g.,
• System setting screens (pw),
• Tech manual Solaris
• Admin proc. manual
• Reports,
• Screen shots - e.g., User Object Properties
  screen, Workstation Properties, Properties Setup,
  User Authentication Action Properties).,
• Flowcharts,
• Narratives, etc. etc.
• Who maintains that supporting document (or
  artifact).

24
Documenting and Testing Security ControlsStep 5
For each Control Objective, Document Relevant
Information and Communication (IC) Activities

• Information and Communication (IC) for the
  Authentication Effectiveness control objective,
  e.g.
• Policies and procedures. Computer, network, and
  email appropriate usage policy, see intranet
  http//....
• Job descriptions. The system engineer job
  descriptions include clear security
  responsibilities.
• Performance evaluations.
• Email communications from management. Quarterly,
  the Info Sec Officer emails reminders about
  password change requirements. Also, the Info Sec
  Officer publishes monthly reminders pw best
  practices on posters, newsletters, etc.
• Verbal communications and on-the-job supervision.
  During monthly staff meetings, the sr. system
  engineer reminds fw admins about pw requirements.
  Quarterly one-on-one discussions are held to
  improve pw controls.
• Training. The 4 sys admins attend security
  conferences at least annually. Quarterly
  Informational Lunch security sessions sponsored
  by the Info Sec Officer. Attendance sheets or
  minutes. Training manuals.
• Compliance Hotline, Human Resources, Ethics and
  Compliance Committees, Internal Audit.

25
Documenting and Testing Security ControlsStep 6
For each Control Objective, Document Relevant
Monitoring

• Monitoring for the Authentication control
  objective and related activities, e.g.
• Report review - Logging only is not sufficient.
  Logs must be reviewed (daily, weekly, monthly,
  etc.)
• Viewing logs may be sufficient if follow-up on
  violations is documented in writing.
• Metrics
• Annual performance reviews if security control
  activities are part of IS staffs job duties.
• Enforcement of policies and procedures, e.g.,
  violation escalation notifications in
  writing/warnings, escalation to sr. mgmt., and
  other reprisals, up to and including employment
  termination.
• In the fw example Administrator actions through
  the GUI are logged in fw.log file, which logs all
  actions performed through the policy manager,
  including pw related changes. On the OS, changes
  are logged in the syslog. However, none of the
  logs is reviewed by the system engineers or sr.
  system engineer with leadership duties.
  Remediation?

26
Documenting and Testing Security ControlsStep 7
For each Control Objective, Document Evaluation
of Design Effectiveness

• Control design effectiveness The reviewer asks
  herself Is the control designed properly to
  mitigate the identified risk and meet that
  objective? Can the control be circumvented? Are
  the controls likely to prevent or detect an error
  related to financial statement assertions?
• Using a rating system based on communication with
  the project team, independent auditors, and
  managements input. Example of Evaluation of
  Design Effectiveness ratings
• Unreliable
• Insufficient
• Reliable
• Optimal / Mature
• Upon reading and performing a walkthrough of the
  control objective and underlying control
  activities, supporting documentation, information
  communication, and monitoring, the reviewer
  rates the controls as RELIABLE.
• However, she noted that several controls were
  missing or existing controls were not properly
  designed. She makes remediation recommendations,
  e.g.,
• There are no controls or relevant
  policies/procedures for password history.
  Password complexity not enforced by TACACS or
  RADIUS, etc. Remediation may be required to
  implement password history controls, pw
  complexity, etc. etc.

27
Documenting and Testing Security ControlsStep 8
For each Control Objective, Document Testing of
Operations Effectiveness

• Control operations effectiveness Upon
  documenting the control objective and evaluating
  the design effectiveness, management, the
  internal auditors, a 3rd party (or combination)
  test controls.
• Purpose of test Prove that designed controls
  operate as intended. Test examples
• Inquiring of the system engineers on her team.
• Reviewing fw settings on different screens,
  system manuals, running pw cracker tools, etc.
• Upon performing several tests on the fw, the
  tester determines that in addition to the control
  improvements identified by the reviewer, in fact
  there were additional weaknesses and rates the
  operations effectiveness as INSUFFICIENT.
• The passwords were communicated via email.
• The policies and procedures have not been updated
  for 5 years and in general, other documentation
  is minimal.
• Passwords were, in fact, changed every 2-3 years
  and when a system engineer transferred to another
  department, the console pw was not changed.
• New system engineers are not made aware of their
  pw control responsibilities.
• The tester makes additional remediation
  recommendations for remediation.

28
Documenting and Testing Security ControlsSteps 7
and 8 Example Ratings for Overall Control
Effectiveness

• Unreliable (0), Insufficient (1), Reliable (2),
  Optimal / Mature (3)
• Unreliable (0)
• No relevant policies and procedures are
  documented.
• No information communication, i.e., employees
  are not aware of their control responsibilities.
• No monitoring, i.e., management has no process to
  evaluate controls (design and operational
  effectiveness) and/or is unable to identify
  control deficiencies.
• Conclusion There is insufficient documentation
  to support managements assertion. Required
  effort to document, test, and remedy controls is
  significant.
• Insufficient (1)
• Controls and related policies/procedures exist,
  but not fully documented.
• There is monitoring, violations are reported and
  escalated, but the process is not fully
  documented.
• Some information and Communication Some, but not
  all employees are aware of their control duties.
• The operating effectiveness of controls is not
  evaluated on a regular basis and the
  documentation is insufficient.
• The design effectiveness deficiencies are
  identified, but it takes a long time to remedy
  the weaknesses.
• Conclusion There is insufficient document to
  support managements assertion. Required effort
  to document, test, and remedy controls is
  significant.

29
Documenting and Testing Security ControlsSteps 7
and 8 Ratings for Overall Control Effectiveness
(cont)

• Reliable (2)
• Controls are documented, supporting documents are
  adequate.
• Information and Communication is effective.
  Employees are aware of their control duties.
• Monitoring with the process of escalating and
  reporting violations is effective, regular, at
  least quarterly, and documented.
• Design deficiencies are identified and remedied
  timely.
• Conclusion There is sufficient documentation to
  support managements assertion. Required effort
  to document, test, and remedy controls may be
  significant.
• Optimal / Mature (3)
• An annual enterprise-wide risk management program
  is in place. The control program is continuous
  and well documented.
• Information and Communication is effective and
  continuous. Employees are continuously made
  aware of their control duties.
• Managements monitoring is real-time, based on a
  periodic self-assessment process that documents
  the control design effectiveness and operational
  effectives is tested periodically.
• Control gaps are identified through various
  technologies and remedied timely.
• The effort to document, test, and remedy controls
  is moderate and efficient.

30
Deficiency and Material Weakness Definitions

• Deficiency (design or operation)
• Control is missing, or
• Control objective is not met (design def.)
• Control is not operating as designed (operations
  def.)
• The individual performing the control is not
  qualified or not authorized to perform the
  control (operations def.)
• Deficiencies range from insignificant to
  material.

31
Significant Deficiency and Material Weaknesses

• Significant deficiency Single or combination of
  deficiencies that
• A) results in gt a remote likelihood that a
  misstatement of financial statements is gt
  inconsequential, and
• B) will not be prevented or detected.
• Material weakness single of combination of
  deficiencies that
• A) results in gt a remote likelihood that a
  material misstatement of financial statements is
  gt inconsequential, and
• B) will not be prevented or detected.

32
Examples of Internal Control Deficiencies

• Lack of policies and procedures on enterprise
  information security, incl. personnel security
  education and training.
• Lack of certain basis security controls,
  including
• Security administration, e.g., pw controls
• Access control, incl. 3rd party access and
  periodic review of user profiles, permissions,
  monitoring
• User account administration and mgmt.
• Excessive number of system admin accounts
  (superusers)
• Physical security
• Security incident response
• Anti-virus controls
• Back-up and restore
• Segregation of duties between business owner
  duties and IT custodianship duties.

33
Summary of documentationSecurity Control Doc.
Example

• Control objective
• Risk associated with not meeting the objective
• Relevant control activities
• Supporting Documents
• Information and Communication (IC)
• Monitoring
• Evaluation of design effectiveness
• Testing of operations effectiveness
• - Overall rating Unreliable (0), Insufficient
  (1), Reliable (2), Optimal / Mature (3). In the
  previous example INSUFFICIENT (1)

34
Lessons Learned

• It is a crunch! Stay positive.
• Not an optional project.
• Audit act and project. Get subject-matter help,
  e.g., internal and external auditors. Learn the
  control language.
• Listen to and work with the independent auditors.
  They will do their own testing and issue
  auditors opinions on a) effectiveness of ICOFR
  and b) management's assessment.
• Use a consistent approach across the
  organization, e.g., templates, database forms, or
  a software tool.
• The documentation and testing process will need
  to be sustained over time. Tools will get
  better, people will get better at documenting,
  the control environment will get better.
• Everyone should attend the same training to
  minimize the inconsistencies and miscommunication.

35
More Lessons Learned

• 8. The scope of the project is a result of the
  initial risk assessment
• Define systems in scope.
• Agree upon control objectives that need to be
  documented.
• Strictly document what you have (not should or
  would like to have).
• Once you identified deficiencies, risk-rate,
  prioritize, and start remediation ASAP.
• Restrict access to the SOX documentation. Treat
  SOX security controls like you treat any other
  security documentation.
• 10. Think about this is a continuous improvement
  program. It will not go away.
• Like security, it is a journey, not a
  destination.
• Unlike security, it has strict deadlines.
  Top-down sponsorship and communication are key!
• Believe it or not, it has benefits security
  professionals will have a louder voice.
• It will teach you things you never knew about the
  security environment.
• Keep abreast of developments listserv,
  conferences, seminars, peer communications.

36
References

• www.isaca.org
• - CoBIT (from ISACA)
• - IT Governance Institute IT Control
  Objectives for Sarbanes-Oxley white paper
  (hyperlink from ISACA website)
• - listserv isaca sox.
• www.theiia.org
• - Archived SOX webcasts (well-worth and time)
• www.coso.org
• www.erm.coso.org/Coso/coserm.nsf/vwWebResources/PD
  F_Manuscript/file/COSO_Manuscript.pdf
• http//www.aicpa.org/news/2004/2004_0929.htm
• www.auditnet.org/sox.htm
• http//www.pcaobus.org/rules/2003-09-10_Audit_Docu
  mentation_Briefing_Paper.pdf
• http//www.eweek.com/article2/0,4149,1527933,00.as
  p
• http//www3.gartner.com/research/spotlight/asset_5
  2231.jsp
• http//www.itgi.org/

37
Software Enabling Tool Examples

• Movaris, see www.movaris.org
• Tools provided by the big 4 accounting firms
  KPMG, EY, PWC, and Deloitte.
• Protiviti, see www.protiviti.com
• Paisley, see www.paisleyconsulting.com
• Microsoft, see http//www.microsoft.com/office/sol
  utions/accelerators/sarbanes/default.mspx
• ETC. ETC. ETC.