Sarbanes-Oxley

Sarbanes-Oxley 404 Security Controls: A Hands-on

Perspective

SDISSA Conference – November 16, 2004

Presented by: Alex Branisteanu

[email protected]

Sarbanes-Oxley 404 Security Controls -- A Hands-on Approach

2

IntroductionsAlex Branisteanu, CISA, CPAInformation 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 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.


3

Points covered in today’s presentation

1. Brief overview of SOX 404.

2. Management’s assessment attestation of the internal control effectiveness over financial reporting for Controls (ICOFR).

3. Overall project approach – the ‘big picture.’

4. Hands-on approach on documenting and testing security controls.

5. 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 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.


7

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.


8

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.


9

Management’s 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 credit’s master file are authorized and enforced through system (application) edits: field length, number formats, etc.


10

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


11

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– Technologies change– Acts of God


12

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? 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

Management’s assessment attestation (cont)Control Design & Operations Effectiveness

Examples• Example: Daily review of access to sensitive tables in the payroll system.

A) 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.– Design effectiveness and operational effectiveness testing.– Remedy inadequate controls – risk rank, prioritize.– Implement sustainable monitoring.– Certify and assert (management and independent auditors)


15

Overall project approach (cont)Documentation: COSO and the Control

EnvironmentFive (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.


16

Documenting and Testing Security ControlsDocumentation: Example for Security

Controls

1. Identify the relevant security control objectives 2. Identify risk for each objective: What can go

wrong?3. Identify relevant control activities4. Supporting Documents5. Information and Communication (I&C)6. Monitoring7. Evaluation of design effectiveness8. 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:

1. Identification and authentication effectiveness = password controls, sessions suspension after a predefined number of unsuccessful logon attempts.

2. Account management or administration (AKA account provisioning and de-provisioning); manage account additions, deletions, and changes.

3. Access authorization = role-based access to ensure segregation of duties, ACLs.4. Temporary and emergency access = emergency passwords, logging of emergency

maintenance activities, notification/escalation to management5. Logging and monitoring of security violations.6. Protection of and changes to security configuration changes: centralized security

administration, protection of sensitive security data.7. Encryption of data stored and transmitted = If used, document how keys are

protected.8. 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 (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.


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

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?


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 management’s input. Example of Evaluation of Design Effectiveness ratings:

1. Unreliable2. Insufficient3. Reliable 4. 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 management’s 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 management’s 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 management’s 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.• Management’s 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 > a remote likelihood that a misstatement of financial statements is > inconsequential, and

• B) will not be prevented or detected.

• Material weakness = single of combination of deficiencies that

• A) results in > a remote likelihood that a material misstatement of financial statements is > 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

1. Control objective 2. Risk associated with not meeting the objective3. Relevant control activities4. Supporting Documents5. Information and Communication (I&C)6. Monitoring7. Evaluation of design effectiveness8. Testing of operations effectiveness

- Overall rating: Unreliable (0), Insufficient (1), Reliable (2), Optimal / Mature (3). In the previous example: INSUFFICIENT (1)


34

Lessons Learned1. It is a crunch! Stay positive. 2. Not an optional project. 3. Audit act and project. Get subject-matter help, e.g., internal and

external auditors. Learn the control language.4. Listen to and work with the independent auditors. They will do

their own testing and issue ‘auditor’s opinions’ on a) effectiveness of ICOFR and b) management's assessment.

5. Use a consistent approach across the organization, e.g., templates, database forms, or a software tool.

6. 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.

7. Everyone should attend the same training to minimize the inconsistencies and miscommunication.


35

More Lessons Learned8. 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.

9. 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

Referenceswww.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.orgwww.erm.coso.org/Coso/coserm.nsf/vwWebResources/PDF_Manuscript/$file/COSO_Manuscript.pdfhttp://www.aicpa.org/news/2004/2004_0929.htm www.auditnet.org/sox.htmhttp://www.pcaobus.org/rules/2003-09-10_Audit_Documentation_Briefing_Paper.pdfhttp://www.eweek.com/article2/0,4149,1527933,00.asphttp://www3.gartner.com/research/spotlight/asset_52231.jsphttp://www.itgi.org/

http://www.isaca.org/

http://www.theiia.org/

http://www.coso.org/

http://www.erm.coso.org/Coso/coserm.nsf/vwWebResources/PDF_Manuscript/$file/COSO_Manuscript.pdf

http://www.erm.coso.org/Coso/coserm.nsf/vwWebResources/PDF_Manuscript/$file/COSO_Manuscript.pdf

http://www.aicpa.org/news/2004/2004_0929.htm

http://www.auditnet.org/sox.htm

http://www.pcaobus.org/rules/2003-09-10_Audit_Documentation_Briefing_Paper.pdf

http://www.eweek.com/article2/0,4149,1527933,00.asp

http://www3.gartner.com/research/spotlight/asset_52231.jsp

http://www.itgi.org/


37

Software Enabling Tool Examples

• Movaris, see www.movaris.org• Tools provided by ‘the big 4’ accounting firms:

KPMG, E&Y, PWC, and Deloitte.• Protiviti, see www.protiviti.com• Paisley, see www.paisleyconsulting.com• Microsoft, see

http://www.microsoft.com/office/solutions/accelerators/sarbanes/default.mspx

• ETC. ETC. ETC.

http://www.movaris.org/

http://www.protiviti.com/

http://www.paisleyconsulting.com/

