SECURITY AUDIT FAQ'S:


Why are security audits of software critical for addressing IT risk?

One of the greatest - but least understood - sources of IT security risks lies within software applications. As the engines that power today's global enterprises, they process, calculate, transmit, and store the data that are an organization's primary asset. Gartner states that 70% of attacks come at the application layer, yet security audits are never performed on most critical software applications to identify vulnerabilities that may expose critical data and operations to hackers. Increasing consequences caused by regulations, targeted attacks and consumer awareness mandate IT security audits and an enterprise-wide approach for measuring and addressing risk to operations from vulnerable software.

Do software security audits play a role in achieving regulatory compliance?

Software security is a significant element of compliance with the laws, regulations, and policies that govern an organization and its data. Weak software security can represent, for example, a significant control deficiency in terms of compliance with the Sarbanes-Oxley Act; potentially compromising the reliability of financial information and reporting. Some regulations, specifically PCI, specifically require software security audits as part of the compliance process. Achieving compliance with key regulations may require internal and external security audits within organizations.

For references to example laws and regulations related to information security, and cross references to sources of guidance for assuring effective compliance practices, please refer to the appendixes of the Ounce Labs' Software Security Audit Framework.

What is the Executive's role in assuring application security in the organization and IT security audits?

While many positions within an organization have responsibilities for ensuring the security of online applications - starting with the programmer writing the source code, software security assurance is a broad management responsibility. Because software vulnerabilities represent significant control deficiencies in terms of secure and reliable information, processes, and reporting, they fall within the direct purview of the CEO, CFO, and audit committee of the board. Security vulnerabilities may also result in the disclosure of personal and other sensitive information, and therefore also impact the roles and responsibilities of management positions throughout the enterprise. For a detailed discussion of roles and responsibilities within a software security auditing program, please refer to the Ounce Labs' Software Security Audit Framework.

What are the key components of a software security audit?

Ongoing security auditing and monitoring provide the means for ongoing effective software security assurance practices. Audit review provides an independent assessment and attestation to management's assurance of an effective system of security vulnerability management, while internal auditing is an important element of the overall system of internal controls.

Compliance audits and other information security audits should specifically address management of security vulnerabilities in the source code, and need to include the following elements:

  • Measurement of vulnerabilities against prescribed standards for security and risk management.
  • Testing of software applications for the existence of security vulnerabilities using security auditing software.
  • Management of software security vulnerabilities in the IT system design, development, maintenance, and change management processes.
  • Management of software security in all outsourced IT systems and programming processes.


How do software security audits help organizations to comply with PCI?

The PCI DSS is demonstrably becoming a de facto standard of due care for any organization responsible for the privacy and integrity of data. Its focus on application security can be traced directly to many of the recent high profile breaches, where insecure applications have proved to be the point of access for hackers, and the source of data loss.  As a result, PCI Requirement 6 calls for organizations to develop and maintain secure systems and applications, addressing security and review throughout the software development lifecycle

For more information on the application security requirements of PCI, read Meeting the PCI Application Security Requirements: Building Security In.

How do IT security audits of software affect the organization's compliance with the Sarbanes-Oxley Act?

As the Securities and Exchange Commission (SEC) and the Public Company Accounting Oversight Board (PCAOB) continue to establish rules and standards to tighten the interpretation of Sarbanes-Oxley provisions, it remains clear that systems and software security are integral to SOx compliance. A security audit of an organization's application portfolio is a warranted element of a SOx compliance program relevant to the assurance of information and software security.

Because Sarbanes-Oxley specifically addresses financial information and all the processes related to managing this information, ensuring its reliability and security, and ensuring reliable financial reporting, it necessarily applies to information security and management controls. A breach in information security that could allow insiders or attackers to compromise financial information or systems would certainly be considered "significant" to SOx compliance, and would require management and auditors to disclose the breach and its possible consequences.

The IT control objectives for SOx require the organization to monitor changes in external requirements for legal, regulatory or other external requirements related to IT practices and controls. They also require having control activities in place and followed to ensure compliance with external requirements, such as regulatory and legal rules.

A software security audit can help the organization obtain assurance of compliance with regulations and frameworks pertinent to critical systems, either through a third party or internal security audit team reviewing security controls and assessing compliance with laws, regulations and contracts.

For a complete framework on SOx compliance relevant to the assurance of information and software security please refer to Appendix C of the Ounce Labs' Software Security Audit Framework by Charles H. Le Grand, CIA, CISA.

How can an organization conduct an IT security audit to support the implementation of ISO 17799?

Although called an international standard, ISO / IEC 17799 is actually classified as a "Code of practice for information security management." Much of the material is high-level and open to broad interpretation. It is adopted by ISO / IEC from the British Standards Institute where it is Part 1 of the two-part BS 7799. ISO/IEC 17799 consists of 12 sections. Pertinent "Standards" start at section 3.

The standards within ISO / IEC 17799 most relevant to software security assurance include:

Section 8. Communications and Operations

  • 8.1 Establish operational procedures
  • 8.1.2 Control changes to facilities and systems
  • 8.3 Protect against malicious software
  • 8.3.1 Detect and prevent malicious software

Section 10. Systems Development and Maintenance

  • 10.1 Identify system security requirements
  • 10.1.1 Specify security controls and requirements that new information systems must meet
  • 10.2 Build security into your application systems
  • 10.2.1 Build input data validation controls into your application systems
  • 10.2.4 Build output data validation into your systems
  • 10.3 Use cryptography to protect information
  • 10.5 Control development and support
  • 10.5.1 Establish change control procedures
  • 10.5.2 Review changes to operating system
    • - Review and test application systems whenever OS changes
    • - Make sure OS changes do not adversely effect applications
  • 10.5.4 Safeguard against covert channels and Trojans
    • - Purchase programs from reputable sources
    • - Inspect all source code before you use it
  • 10.5.5 Control outsourced software development

Section 12. Compliance Management

  • 12.2 Perform security compliance reviews
  • 12.2.2 Review technical security compliance
    • - Carry out penetration tests to detect information security vulnerabilities

For a reference matrix on regulatory frameworks including ISO / IEC 17799 and applicable software risk analysis initiatives for the private and public sectors, please refer to "A Framework For Software Vulnerability Management And Audit."

How does a security audit of software support the implementation of the COBIT framework?

COBIT
(Control Objectives for Information and related Technology) is a widely recognized framework for information, systems, and technology controls, compliance, and auditing. Promulgated by the Information Systems Audit and Control Association, ISACA refers to COBIT as an "Open Standard."

The COBIT framework control objectives for acquiring and implementing software systems require that each organization ensures and builds Internet-facing infrastructure to a high standard of security because it becomes part of the global information infrastructure. Conducting security audits using consistent, reliable, and affordable security auditing software that measures and helps manage security vulnerabilities in the source code has become a "best-practice" in acquiring and implementing systems and programs.

COBIT also requires organizations to audit online IT systems for security, including measuring security vulnerabilities as well as any exploits in those systems. Given that the typical organization with online systems implemented many of them before automated security auditing software became available to support assessment of security vulnerabilities, it is now important to audit the extent of security vulnerabilities in those systems and determine the steps needed to remediate vulnerabilities based on their potential impacts.

For a reference matrix on regulatory frameworks including COBIT and applicable software security assurance requirements, please refer to "A Framework For Software Vulnerability Management And Audit."

How can an organization determine the most appropriate method and resources to implement security audit in their development lifecycle?

The three models explained in Ounce Labs' whitepaper titled "Implementing Source Code Vulnerability Testing in the Software Development Lifecycle" represent common scenarios currently being used to successfully implement security audit processes in the development lifecycle and reduce security vulnerabilities. These audit models help establish criteria for assessing goals, resources, obstacles, and ultimately, the most favorable approach for individual organizations.

Although it is clear that development organizations and processes each have their own distinct characteristics, the models outlined in this paper address the common elements that should be leveraged to achieve effective security auditing.

The primary functions that must be served by existing IT staff or security audit experts brought in during implementation are:

  • Set security requirements: A manager or central source of IT security expertise defines what should be considered vulnerabilities and how to judge criticality based on business needs.
  • Configure security analysis: Internal definitions are used to customize the source code analysis tool to match policies.
  • Analyze source code: The source code analysis tool is run against the target application or parts of the application to pinpoint vulnerabilities.
  • Triage results: Staff members with knowledge of IT security issues and of the application study results to prioritize remediation workflow.
  • Remediate flaws: Security vulnerabilities are eliminated by rewriting code, removing flawed components, or adding security-related functions.
  • Verify fixes: The code is rescanned and analyzed to assure the code changes have eliminated the security vulnerability while maintaining application functionality.

For more detailed information please refer to "Implementing Source Code Vulnerability Testing in the Software Development Lifecycle."

Back to Top