The Disconnect between IT Audit and Software Developers

IT-Auditors-and-Software-DevelopersIT auditors, whether they’re in-house or external, are forming stronger relationships with IT and security staff. They have to in order to effectively perform their audits. It’s good for the auditor, IT staff, and the business as a whole. When everyone’s on the same page, information flows freely and informed decisions can be made about security.

The problem is, not everyone is on the same page. Namely software developers.

In virtually every situation I’ve come across, developers have been out of the loop on discussions concerning IT audit, compliance, and overall governance. Yet, the decisions they make and the work they do have a profound effect on the business’s security posture. I’m convinced this is a large reason why we still have so many web security risks to contend with.

Based on my experience, I’m willing to bet that IT audit’s involvement with software developers in any given organization is checkbox-based at best:

Auditor: “Do you incorporate security into your software development practices?”

IT representative: “Yes. Our developers do that.”

Auditor: “Great, thanks.”

The roles and expertise for ensuring proper web security oversight do exist but the means for actually bringing it all together is faulty. Simply put, web security is not being addressed at the proper level.

Not that IT auditors are all knowing; it’s just that they have one thing that many people in IT and information security don’t: the ear of management.

I see the scenario time and again where IT admins or security managers beg and plead for the proper resources to properly test and secure their web applications; yet their requests fall on deaf ears. But when an IT auditor documents detail web security concerns in his audit report, suddenly the board is involved, legal has a hand in it, and management miraculously comes through with money and support.

I believe that this is not an intentional oversight in the business-audit-security cycle. I think it’s more of a side-effect of how business, IT, and software development has evolved.

Acknowledging the problem is half the battle. Do your part to bring everyone together and keep the conversation going.

Auditor, meet developer. Talk amongst yourselves. Get to know each other. You just might learn something.

  • I’ve done a lot of sessions with our clients who use Acunetix and when they bring up this issue, I specifically point them to the reporting tools in Acunetix.

    First, the Developer Report will give all the details a programmer would need to fix any of the issues discovered on the website. Perfect report to cover everything they need to know.

    However, when it comes to prioritizing? That’s when I suggest that the Compliance reports and the comparison report tool be used.

    With the Compliance Report you can select which regulatory compliance items your company follows and make sure that certain items which are not highlighted in the Developer Report. My usual advice is to fix all the vulnerabilities rated as High on the Developer Report and then any of the non-compliant items on the Compliance Report.

    The Comparison Report is one that I use to demonstrate the changes to a website over a period of time and to stress which items are not being addressed by the developer team. It’s a great tool to note if new vulnerabilities have popped up since the last scan and which items have not been resolved yet.

  • Leave a Reply

    Your email address will not be published.


    *