In order to create software that is truly useful to your customers, partners, and users, it helps to understand a bit about why certain software and systems requirements matter to them. For example, expect to hear more systems and software requirements that are tied to government regulations as compliance deadlines approach. It is important not to get lost in the details when it comes to regulatory compliance. IT and security are key enablers for most of these new laws from a technical perspective. Therefore, you need to know as much as needed to complete the software project; however, it is not necessary to be a legislative talking head. Hopefully, your company’s or your customer’s legal counsel will handle interpreting this law. Your job is build software based on corporate counsel’s input.
Of course, for anything to happen, you will need the commitment of your company’s business management to:
- Support secure coding as a requirement for the project.
- Allocate project budget for the additional time needed to produce secure code.
Without this support, nothing will change. With this support, your end product will be more likely to endure the scrutiny of a wary and anxious end customer.
We will look at one example of an up and coming regulatory requirement that will directly affect, from a security perspective, the software projects you may be working on.
What Is Sarbanes-Oxley?
Executive management of publicly held companies reporting $75 million revenue dollars or more to the SEC are under the gun to be compliant with the Sarbanes-Oxley Act of 2002 (SOX) legislation within the next few months.
Note: The SOX compliance dates have been pushed back.
The full text of the law can be found in the entire law, which can be found at http://news.findlaw.com/hdocs/docs/gwbush/sarbanesoxley072302.pdf.
However, as a developer, it is not necessary to go into great detail on all 11 titles and multiple sections of this law, to glean the concepts that are most important for software developers to be aware of. This law, signed by President Bush in 2002, is designed to “protect investors by improving the accuracy and reliability of corporate disclosures made pursuant to the securities laws” and to “deter and punish corporate and accounting fraud and corruption, ensure justice for wrongdoers, and protect the interests of workers and shareholders.” Criminal penalties are imposed on CxO and other members of upper management (i. e. section 304 mandates personal reimbursement of illicit financial gain to shareholders).
Security Requirements—What To Expect
The following chart is an example of an security assessment matrix that may be used to evaluate security impact of various regulations to software development projects. This is just an example for use in the case of Sarbanes-Oxley. Most of the countermeasures are commonly known. By using this matrix approach, it is possible to get a rough understanding of possible requirements to expect from customers/end users. Ultimately, software security and application security requirements that you will most likely encounter will be based around DIGITAL DATA INTEGRITY and ACCOUNTABILITY. Although there is nothing new about these concepts, they provide a central theme within SOX.
It may be useful to review the security implications of various regulatory environments by using a matrix as shown in the below example (for Sarbanes-Oxley).
Security Requirements Matrix example (for Sarbanes-Oxley)
| Statute | Summary | Threat | Possible Requirement |
| Section 302—Corporate Responsibility for Financial Reports | Requires executives to certify the accuracy of corporate financial reports. | Unauthorized modification of data; data fraud | Authenticate data using strong data integrity controls—secure hash of data, row level encryption, provide detailed user level logging of access and data change events |
| Section 404—Management Assessment of Internal Controls | Requires executives and auditors to confirm the effectiveness of internal controls for financial reporting. | Unauthorized access to data, data deletion | Robust access controls, interoperable with enterprise authentication, access and auditing |
| Section 409—Real Time Issuers Disclose | Requires any material changes in financial state of issuer be communicated quickly and with supporting data to the public. | Non-Availability of data, data recoverability issues, backup, and restore | Data mirroring, Application resilience against DoS, unauthorized application shutdown, data properly recorded and reported |
What this means in practical terms is that CEOs and boards of directors now care, more than ever, about software and systems that will help them comply with SOX. Specifically, the tenets of SOX specify that corporate governance be responsible for providing transparency, integrity, and accountability over regulated financial data. As with most laws of this type, regulatory compliance only establishes a base line and is just a start to ethical corporate governance and financial conduct. Also, because so much is at stake, it may be appropriate to outsource some of the software systems development to companies that already have the expertise of both the regulation as well as secure coding techniques. In addition, you may also explore the role that application security products could play in reducing time to be compliant.
If you do become involved in a project that is related to regulatory compliance, such as SOX, the use of a matrix analysis similar to the above example, along with a business process analysis, can be a first step in getting enough understanding of a regulation’s impact on security component requirements in software application that you may write.
| Sarbanes-Oxley specifies that officers of publicly held businesses can, by law, be punished for financial misconduct to include jail time and significant monetary fines and reimbursement to share holders. Sarbanes-Oxley also applies to foreign business entities that are required to file under the SEC Securities Exchange Act. If you write software for foreign companies, be aware of this from a requirements perspective. |
Just for fun, try creating a security matrix after researching the regulatory landscape as shown in the following chart.
| SEC | HIPAA | GLBA | CA SB 1386 | FISMA |
| FDA 21 | CFR 11 | ISO 17799 | Common Criteria | EU Data Protection |
| BASEL Accords | Canadian Privacy Law | PATRIOT Act | FERC/NERC |
About the Author
Keith Pasley, CISSP is an information security professional with over 20
years of experience in the information technology industry. He has designed
security architectures and implemented security strategies for both
government and commercial sectors. Pasley has written articles on various
security related subjects.
