The State of the Audit in 2018
Merriam Webster defines audit blandly as “a methodical examination and review,” but the term itself conjures up so much more. An audit implies exhaustive, relentless precision. The type of precision that flags a single missing receipt in 200 expense reports – or the one anomalous bank transfer in a room full of document boxes that blows the lid off a $10-million money laundering scheme.
Like their financial counterparts, software audits call for a methodical and rigorous examination. Software auditors need to validate that the organization’s applications and development processes adhere to regulations, standards, and internal procedures. They need to provide assurances that an organization understands its application infrastructure and can track changes to the underlying source code. But if we take an honest look at today’s development methodologies and the state of documentation and other governance activities, most organizations simply don’t have the ability to achieve the level of precision expected in an audit. The result of this deficit is that software audits tend to be unnecessarily expensive in terms of time and money while producing unreliable results.
Software Audit Drivers
The mechanics of a software audit vary widely depending on the organizations involved and the context of the audit. The Institute of Electrical and Electronics Engineers Standard for Software Reviews (IEEE Std. 1028) provides a list of 32 software products subject to audit. These products run the gamut from procurement methods to the source code. While an audit can be triggered by such work-a-day scenarios as a vendor’s demand for documentation of licensing compliance or an internal management review, the audits most likely to make CIOs and their teams lose sleep are the audits driven by regulatory compliance.
Two such regulatory frameworks are the Sarbanes-Oxley Act (SOX) of 2002, that applies to organizations handling financial data, and the Health Insurance Portability and Accountability Act (HIPAA) of 1996, that applies to organizations processing sensitive healthcare patient data. Both of these frameworks place heavy IT security burdens on organizations and require them to have strict controls in place to ensure data integrity and confidentiality.
An additional layer of the audit is driven by the Service Organization Control (SOC) program administered by the American Institute of Certified Public Accountants. SOC assessments (SOC 1, SOC 2 and SOC 3) are designed to provide independent assessments of the security controls in place at a service provider. Organizations that find themselves on the receiving end of a SOC report request include payroll processors, medical claims processors, data center companies, and of course any Software-as-a-Service (SaaS) company whose services may impact financial or sensitive private user information.
IT AUDIT- Chasing Our Tails
Regardless of the driver, for most organizations today the ability to respond to an audit that goes deep into the software lifecycle is fundamentally limited.
Auditors themselves do not have access to the runtime environment, so they are left to rely on developers to tell them what changed in the environment. In this do-loop where the auditors are relying on the people being audited to guide them, it is easy (even likely) to miss auditable events.
Even organizations with fairly robust practices in place for manually and automatically tracking application changes are likely to overlook critical changes. Non-application changes in particular, such as changes to database schemas, key/value stores, and message queues frequently go undetected.
For the application related changes that developers and DevOps folks do pickup from the runtime environment, auditors then spend a huge amount of time manually correlating those changes with commits in the source code repository. Not only is this task crushingly time-consuming, it is extremely error-prone, primarily when the code is spread across multiple repositories.
All told, in a system that does not enforce transparency and documentation, auditing application changes borders on the absurd. The reliance on the development team and an incomplete record of system changes results in a superficiality to the audit results that all but defeats its purpose.
How Crosscode Helps
Crosscode’s audit trail feature identifies changes directly from the runtime environment, significantly lowering the bar on the expertise needed to collect the necessary information for an audit. Auditors no longer need to rely on the development team to provide data, nor do they need to crawl through source code versioning systems.
Using Crosscode’s audit trail makes it easy for auditors to identify what change was made to the system and when the change occurred, dramatically reducing the time required to collect and review the audit data. More importantly, Crosscode adds completeness and veracity to the audit, reliably capturing all relevant changes including database changes, code changes, and configuration changes.
Crosscode was designed to help organizations manage today’s complex application environments. Our tools give you unique insight into your application infrastructure across the entire software development lifecycle. Contact us today to learn how we can help you respond to your internal and external audit demands more quickly and reliably, and at a lower cost than ever before