MyInfoTechJournal: Never Let a Crisis Go to Waste: The Ultimate Business Continuity Plan (BCP) for Thriving in Any Situation (Part 3 of 3: EXAMPLE)
My InfoTech Journal:
Introduction to SOX Compliance
Sarbanes-Oxley Act of 2002 is defined as “An Act to protect investors by improving the accuracy and reliability of corporate disclosures made pursuant to the securities laws, and for other purposes.” 1
Sarbanes-Oxley Act or more commonly known as SOX, is a Federal Law which was enacted on 30-July-2002.
The Sarbanes-Oxley Act was known in the US Senate as the “Public Company Accounting Reform and Investor Protection Act” and known in the US House as the “Corporate and Auditing Accountability, Responsibility, and Transparency Act”. This law was enacted as a response to a number of major corporate and accounting scandals including Enron and WorldCom. 2
The Sarbanes-Oxley Act defined “A violation by any person of this Act, any rule or regulation of the Commission issued under this Act, or any rule of the Board shall be treated for all purposes in the same manner as a violation of the Securities Exchange Act of 1934 (15 U.S.C. 78a et seq.) or the rules and regulations issued thereunder, consistent with the provisions of this Act, and any such person shall be subject to the same penalties, and to the same extent, as for a violation of that Act or such rules or regulations.” 1
Section 302: Corporate Responsibility for Financial Reports
Photo Credits: US Government Information: Sarbanes-Oxley Act of 2002
Section 302: Corporate Responsibility for Financial Reports
Section 302 of the Sarbanes-Oxley Act mandates that the Principal Executive Officer/Officers and the Principal Finance Officer/Officers or persons performing similar function has to certify all reports submitted in compliance with this Section 302 of the Sarbanes-Oxley Act.
This basically means that it is the accountability of these Officers to ensure that the report has been reviewed, the contents are accurate, and that internal controls are in place and effective.
Section 404: Management Assessment of Internal Controls
Photo Credits: US Government Information: Sarbanes-Oxley Act of 2002
Section 404: Management Assessment of Internal Controls
Section 404 of the Sarbanes-Oxley Act mandates that the Management and Auditors implement internal controls and ensures that these controls complies with the control requirements of this Section 404 of the Sarbanes-Oxley Act.
Internal Controls focuses on testing Access Control, IT Security Controls, Data Backup and Recovery, and Change Management Controls.
Sarbanes-Oxley (SOX) Compliance Project
When the Sarbanes-Oxley (SOX) Compliance Project was initiated, I was nominated as the Representative for the IT related compliance requirements. I was the Service Delivery Manager (SDM) for this IT Outsourcing project within the company prior to being nominated to join the SOX Compliance Project.
The SOX Compliance Project was huge, with representatives from all the different departments and teams. We had several training sessions to understand all the SOX Compliance requirements and how to design controls in order to comply. The IT Control requirements cut across all the applications and platforms that the IT Team supports.
From the IT Team SOX Compliance, the scope covers all countries within the ASEAN region (Philippines, Singapore, Malaysia, Thailand, Hong Kong). I created a program that will monitor SOX Compliance for all the Platforms hosting identified SOX In-Scope systems or applications from these in-scope countries.
The IT Infrastructure Compliance Program involves compliance to Operating Systems Security and Patching, Anti-Virus and End-Point Security, Access Controls, Applications Security Patching, and Change Management.
Operating Systems (OS) Vulnerability Checks
Back in the days, Scripting Tools are limited to only a few capabilities. The IT SOX Compliance Team has to manually check and fix every security vulnerabilities from the registry level. This is a very tedious and repetitive process done manually. Each member has to be focused on the task at hand because a wrong registry entry may possibly cause the operating system to break. Since this is a manual process, we have to assign an executor and a verifier before a registry setting is updated.
Any changes in the system go through a stringent Change Control review and approval process.
All evidences are recorded and stored securely with date and time stamps in compliance with the approved SOX evidence criteria.
Fast-forward to current IT environment and infrastructure. There are now a lot of tools available that is capable of generating Server OS vulnerability reports which include an explanation and procedure on how to fix an identified vulnerability. There are also tools available to fix these vulnerabilities automatically within the parameters set. Compliance Solutions has drastically changed over time and compliance tasks has become more automated and easier to implement.
Operating Systems (OS) Security Patching
The IT SOX Compliance Team ensures that SOX In-Scope Servers are patched on a timely manner.
The more challenging part for this task is on the patch testing to ensure that no untoward incidents on the hosted systems are encountered after the patching. Therefore Testing and User Acceptance is very important during the patch testing phase. Since testing is done on a non-production environment, we have arranged with the Systems Owner to nominate a designated tester with pre-agreed testing schedule and test criteria.
For this SOX Compliance Project, I gathered all the busy periods of the system usage. Found out that since these are mostly financial systems, it was identified that 3rd week to around 1st week of the following months are the busy periods. This gives us the 2nd week of the month to schedule all the OS patching schedules.
Any changes in the system go through a stringent Change Control review and approval process.
All evidences are recorded and stored securely with date and time stamps in compliance with the approved SOX evidence criteria.
Password Complexity
We have tools to extract User Accounts and run password complexity tests. All users found to have vulnerable passwords get notified and provided with refresher courses on account and password management. Tips are also given to guide them create complex password with hints that they can remember.
Access Control List (ACL)
Access Control Lists (ACL) are being generated on an agreed frequency to ensure that only authorized personnel have access to specific data. The Systems Owner is responsible for reviewing the ACL and ensuring that the ACL is current. The Systems Owner is responsible for ensuring that changes like users leaving the company or change in role has to be requested and ticket submitted as reference.
Back in our days, the ACL review has to be done with some tools but has to be requested and approved through the ticketing system.
Nowadays, there are tools available that makes this process self-service. Meaning, the Systems Owner has access to the tool with capability to verify the security groups and update the ACL members as and when needed. This lessens turnaround time and effort.
Segregation of Duties (SoD)
Segregation of Duties aims to prevent a combination of roles that can facilitate into committing fraud.
For SOX Compliance, Segregation of Duties is a very important control requirement. The SoD aligns with the basic tenets of the SOX Compliance requirement which is to implement controls to ensure accuracy in the data process and that there is accountability when fraudulent transactions are discovered.
To comply with the Segregation of Duties compliance requirement, you have to start with evaluating the roles and responsibilities within a specific process. There must be controls to ensure that no combination of roles can facilitate a fraudulent transaction. This is where the SoD matrix come into play.
One good example of the Segregation of Duties that most will be familiar with are the bank processes. You will normally hear a Bank Staff saying “Override please!”, and then the Bank Manager reviews and approves the transaction. The Bank Manager in this process is the control that ensures the transaction complies with the SoD requirement. The Bank Staff should not be able to process a transaction beyond the defined roles and responsibilities within the SoD matrix.
Another example is that, a payment requestor must not be the approver for the same payment request that was submitted. There must be layers of controls to ensure that these roles don’t overlap or negate the other.
Once you have finalized the Segregation of Duties (SoD) matrix, you use this as reference for implementing the security controls from the application and platform access control or permission level configuration. There must be segregation of duties between an Application Administrator and the Platform Administrator.
Example: Giving both the Application Administrator and the Platform Administrator roles into the same person is a violation of the SoD controls.
Example: Giving the roles of Requestor and Approver to the same person is another example of a violation of the SoD controls.
I hope the above has provided you something to takeaway from this section.
Server Administrator Password
Server Default Administrator Account must not be used for daily operations support and the Password has to be changed regularly and has to be complex. Two-Factor Authentication should also be implemented.
Each Platform Team Admin member must have a normal account for office functions and must have a separate Server Admin account for platform administration purposes.
Anti-Virus and EndPoint Security
The younger generation of IT Professionals has to thank the fast development of tools in this area.
Total End-Point Security can now be configured and deployed from the main server to hundreds of end-point clients. Additional monitoring will be on ensuring that those machines that are non-compliant are verified and rectified to ensure it reports back to the server for security updates.
Configuring Endpoint security settings is now easy to do deploy from the server like, Data Loss Prevention (DLP), Application Control, Device Encryption, Data Encryption, Device Control, USB port restrictions, Anti-Spam, Anti-Malware, Personal Firewall, HIPS, NAC, Web Filtering, and others.
Change Management
Any changes in the IT infrastructure has to go through a stringent Change Management review and approval process.
There should be a Change Advisory Board (CAB) responsible for reviewing all change requests for the in-scope SOX systems. The CAB is responsible for verifying the activity, its impact on the system and also to check and ensure all the parameters within the Change Management System are accurate and in compliance with the agreed criteria and approvals.
For example, the Configuration Item type should be SOX System, the Severity Level is either 1 or 2, the Criticality is High, the Approvers should be the Systems Owner or Delegate, and the CAB members.
Change Request records act as evidences for this compliance requirement. The agreed parameters should therefore be checked for accuracy and proper approvals.
Disclaimer
This article is based on my research and personal experience.
This is in no way a substitute for legal advise.
Please consult your Legal Team, Ethics & Compliance, or Regulatory Team for the interpretation of the SOX Compliance requirements.
Disclaimer
This article is a result of my personal research and is not a substitute for legal advise.
Please consult your Legal Team, Ethics & Compliance, or Regulatory Team for the interpretation of specific CyberSecurity requirements.
Support My InfoTech Journal
Comments
Post a Comment