Sarbanes-Oxley 404 Security Controls: A Hands-on Perspective SDISSA Conference – November 16, 2004 Presented by: Alex Branisteanu [email_address]
Alex Branisteanu, CISA, CPA
Information Security Officer, Scripps Health
- 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 presenter’s/author’s 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 organization’s 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.
Points covered in today’s presentation
Brief overview of SOX 404.
Management’s 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.
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.
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.
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 :
PCAOB (Public Company Accounting and Oversight Board).
In 2004, SEC approved PCAOB’s 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.
Management’s assessment attestation of the internal control effectiveness Auditing 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.
Management’s 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.
Management’s assessment attestation (cont) IT Application Controls
Application controls = controls that ensure transaction related processes are complete and accurate. Covers:
Example: Changes to customer credit’s master file are authorized and enforced through system (application) edits: field length, number formats, etc.
Management’s 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
Management’s 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
Acts of God
Management’s 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?
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.
Management’s 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.
Overall project approach
Step 1 :
Scope and plan the project,
Ensure executive mgmt. sponsorship,
Form ‘disclosure’ committee,
Assign project manager,
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.
Design effectiveness and operational effectiveness testing.
Certify and assert (management and independent auditors)
Overall project approach (cont) Documentation: COSO and the Control Environment
Five (5) COSO framework components:
Control environment - People’s 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.
Documenting and Testing Security Controls Documentation: Example for Security Controls
Identify the relevant security control objectives
Identify risk for each objective: What can go wrong?
Identify relevant control activities
Information and Communication (I&C)
Evaluation of design effectiveness
Testing of operations effectiveness
Documenting and Testing Security Controls Get 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,
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.
Documenting and Testing Security Controls Step 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.
Documenting and Testing Security Controls Step 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.
Documenting and Testing Security Controls Step 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.
Documenting and Testing Security Controls Step 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.
Documenting and Testing Security Controls Step 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
Screen shots - e.g., User Object Properties screen, Workstation Properties, Properties Setup, User Authentication Action Properties).,
Narratives, etc. etc.
Who maintains that supporting document (or artifact).
Documenting and Testing Security Controls Step 5: For each Control Objective, Document Relevant Information and Communication (I&C) Activities
Information and Communication (I&C) 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 .
Documenting and Testing Security Controls Step 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.
Annual performance reviews if security control activities are part of IS staff’s 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?
Documenting and Testing Security Controls Step 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 management’s input. Example of Evaluation of Design Effectiveness ratings:
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.
Documenting and Testing Security Controls Step 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 3 rd 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.
Documenting and Testing Security Controls Steps 7 and 8: Example Ratings for Overall Control Effectiveness