What is SOX Compliance

The scope of SOX Compliance is broad and encompasses a company's management of quality, security and operational risk. Effective risk control of Information Technology (IT) is an essential element of corporate governance and is a key enabler for business process control and compliance with the Sarbanes-Oxley legal and regulatory framework. SOX Compliance is the process of ensuring transparency of corporate disclosures by requiring that internal controls related to financial reporting are documented and tested to ensure the effectiveness of accounting controls in the construction of annual reports and other financial disclosures. Few points are : 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Databases are appropriately secured from unauthorized access(approval policies and procedures). Evidence exists to ensure database integrity(evidence of policy and procedures). Roles and responsibilities for security administration are clearly defined and documented. Processes and Procedures for granting access to sensitive system profiles. tranfers and Leavers processes and evidence for the same. Segregation of duties conflict matrix and mitigating controls for the same wherever applicable. Access rights should be reviwed at least on an annual basis. Password control for users. External connections requests process and review. Security incident logging, monitoring and follow up. Restrictions for the use of super users like SAP*, DDIC, etc.

SAP R/3 Security in the Sarbanes OXley Era - 7 Steps for Better SOX Compliance Post Sarbanes Oxley, focus for corporations is more on compliance and security. Sarbanes Oxley has had a major impact on the organizations using SAP R/3 as their ERP. Some of the changes seen in the corporate landscape include identifying and documenting processes, implementing controls and safeguards, documenting user access approvals etc. In short, there has been a cultural shift in organizations post Sarbanes Oxley. Below, I have listed 7 major pointers which can help organizations towards better SAP security in the Sarbanes Oxley Era. 1. Provide users access on a need to know and need to do basis. 2. Adequately secure programs, transactions and tables. 3. All user accesses to SAP R/3 are properly authorized and approved. 4. Segregation of duties is maintained for all sensitive business transactions 5. All controls and business processes are documented. 6. Anti-fraud preventive controls are in place to prevent & detect fraud before an audit. 7. User profiles and roles in SAP are secured and designed to meet business requirements.

Sarbanes-Oxley IT Security Compliance Checklist
April 21, 2006 By Jason Kolb 5 Comments

and particularly as they move into the enterprise. I realize that not all companies will be able to comply with all of the requirements.Web-based applications and the technology that enables them are fantastic.0 applications gain traction. I had to figure these out the hard way. Back when I had to go through making a company SoX-compliant. Because there¶s nothing in the Act itself about IT. if you meet the bullets on this checklist you¶re most likely going to pass. However. but rather is meant to be a starting point for entrepreneurs or individuals curious about the security of a specific application. This list represents an attempt to compile those considerations and the proper way to handle them. Here¶s a basic list of what constitutes that vague term (I probably left some out so please leave feedback if you think of something I missed): y y y y y y y y y Account number and identifiers Customer numbers User names Credit card or bank information of any kind Passwords Private messages and blog posts Wage information Social security and driver¶s license numbers Birthdates . I hope this checklist will eat a chunk out of the SoX auditing extortion racket. Well. especially in the back-end section. that is. a small cottage industry has sprung up around telling companies what they need to do to become compliant and then auditing them so that their partners know that they¶re "SoX Cerified". This is by no means a comprehensive list. but they¶re bringing a new set of security considerations and challenges along with. I was never able to find anything like this. If a company chooses not to take them into consideration they¶re most likely going to be cutting all publicly traded companies (and the companies that do business with them) out of their potential customer base. keep in mind that these requirements all need to be addressed to comply with the Sarbanes-Oxley Act (SoX). This is destined to become a bigger and bigger issue as Web 2. by paying consultants boku bucks to tell me what they were Sensitive User Information The crux of this list and SoX is protecting "sensitive user information". On a side note.

mixed upper. Doing this will avoid the possibility of using Javascript injection attacks. Strong passwords (more than 8 characters. etc. all other methods are vulnerable to man in the middle attacks. and only known by somebody outside of the IT department. No sensitive information should be stored in cookies. stored procedures should be used for all database access since they are not vulnerable to SQL injection attacks. This includes database logins. Backups should be encrypted and stored off-site in a secured location. . SSL is currently the only 100% secure way of making XmlHttpRequest calls. This isn¶t more secure per se. No sensitive account stored by the application should ever be rendered to the client. with special consideration given to AJAX and Web services calls: y y y y y y y y y y y The application should use Digest authentication or SSL when accepting a user¶s password for authentication. All forms should check for special characters such as single or double quotes before sending the information to the database. Back-End Security This list applies primarily to the internal database and network: y y y The database administrator password should not be used for application access.and lower-case) should be enforced if users select their own passwords. If possible it should be renamed from the default name (sa. GET and POST requests should not be vulnerable to SQL injection attacks. Anyone who has access to the production database should be required to change their password at least every 90 days. for example). User sessions should not be identified using cookies or IP addresses. User passwords should be stored as an MD5 hash of the password in the database rather than as plain text. If the database contains sensitive customer information. If sensitive user information is sent or received using XmlHttpRequest (AJAX calls): The entire page utilizing XmlHttpRequest needs to be secured using SSL (which will secure the XmlHttpRequest calls from that page using SSL as well). All input validation should be done on the server. even if it was already done on the client. If sensitive user information is sent or received from Web services: The WS-Security SOAP header or SSL should be used.Front-End Security The first list applies to the application front end. email logins. HTTP POST requests should be used instead of GET requests whenever possible. third-party site logins. both of which can be easily compromised. mixed alphanumeric and special characters. Preferably. the number of people who know the application database login or have unrestricted access to the database should be strictly limited. but it raises the bar for potential hackers and makes it more difficult to crack your system.

The Web servers should be on a separate network. The physical servers that hold sensitive customer information need to be secured and protected as well. Change your network Administrator account name (so that it¶s not "Administrator"). particularly when they¶re hosted on the Internet: y y y The firewall should only allow ports 80 and 443 (HTTP and SSL) except when other applications such as BitTorrent or FTP need to be used. Domain administrator accounts should rarely if ever be given out. Perimeter (Network) Security Here are some requirements that are just good practices for building secure Web-based applications. . and the list of people with that access should be documented and readily available. The default database application port should be changed if possible. it should be encrypted and preferably wiped out after processing is completed. Typically this is taken care of in a hosted environment. separated from the database and other internal servers by a firewall which only allows the database application port to be used. Security violations (such as a user entering the wrong password three times in a row) should be logged to a secure location and reviewed by the company Security Officer on a regular basis.y y y y y If you must store credit card information. but if you¶re hosting your application from your basement then you¶d better make sure that you have the basement locked and you make the water heater repair man sign in and out.

Sign up to vote on this title
UsefulNot useful