In the compliance and regulation-driven financial services market, we all know that audits are a fact of life.  What is perhaps less well-known is that software development is also subject to these audits.  It makes sense because after all, software is at the heart of most financial products these days and it can be an area of risk if not managed properly. Vulnerabilities can creep in during the development process, whether accidentally or maliciously, and can create havoc at a later point. 

Let’s take a look at how to prepare for audits and the kind of questions that auditors may ask about software development and how those can be answered using server logs.   These logs, part of the daily routine in software development, highlight how software developers use version control systems (VCSs). 

For anyone not familiar with VCSs, these are an integral part of any modern software development process. VCSs act as a ‘single source of truth’, where all contributors to a project check-in and check-out their code. Plus, these days, they also incorporate all kinds of other digital assets, not just code.  In effect, the VCS provides a real-time insight into what is happening on a project at any one time, as well as providing a historic record of who did what, when, how and where.  

VCSs vary in terms of feature and capability, but that’s not the point of this blog.  What matters is making sure that the VCS is properly prepared for an audit, including containing clear, comprehensive, and well-defined plans, rules and practices that regulate access to systems and the data they contain.   While requirements will vary, there are six basic questions that will need to be addressed for audit purposes:

1.       What is the documented security policy?

Most larger companies have documented security policies, but developers may not be exposed to such policies, thus putting valuable IP at risk. The version control policy should be a subset of the overarching security policy, encompassing developers, how they use the VCS and other systems.  In order to evaluate the policy’s reliability, auditors will want to compare documentation with established internal processes.  If they do not match, auditors will raise concerns. 

2.       Do employees actually know the security policy?

Auditors will also want to know how employees are actually following security policies. This may mean checking and updating the training they are given, as well as how any security policy updates are communicated.  Often, training isn’t specific to a developer’s role and doesn't include actionable insights. It’s therefore important to provide specific, relevant training to developers to raise their security consciousness and help them care about security.

3.       How is data being protected?

Many information security policies focus on protecting sensitive data, such as PII. Although PII is not  usually stored in a VCS, it’s common to have configuration data stored in the VCS, especially in the age of Infrastructure as Code (IaC). This makes it critically important to control and monitor access. Developing a layered security model helps secure information from multiple angles.

4.       How are access permissions granted throughout the organization?

Auditors want to examine who has access, to what and why.  A lack of proper access permissions control is a common problem that can create a significant security risk, so it is essential to demonstrate that permissions are effectively assigned, in-line with the security policy. 

A critical part of securing the VCS is controlling access to code that, for example, could provide access to customer databases. This is why more financial institutions are implementing granular permission systems and layered security: in other words, only giving people access to what they really need. Not only does this reduce the risk landscape, it makes it easier to detect intruders or abuse of data access by employees. 

5.       What is the high availability/disaster recovery (HA/DR) plan?

HA/DR has a direct impact on business continuity and the VCS needs to be included within any HA/DR planning.  Questions may include: if a server fails, is failover readily available?  What systems are in place to restore from a back-up?  When was the last time backups were tested?

6.       What is the plan in case of a VCS breach?

Let’s imagine a potential security breach, such as a developer’s laptop or credentials being stolen: what steps are in place to minimize damage?  These might include: identifying which employees are responsible for security in case of emergency; how should they react if a breach occurs? Who should they contact? Is it clear what code or data is stored on that laptop (if using Git, it’s common for an entire project’s code base to be stored locally on a developer’s laptop – how to mitigate that particular risk is a whole other topic)? Finally, what systems and data should be secured first?

Making audit data easy to monitor and locate

Once security is in place, VCS server logs can help proactively monitor the situation on a daily basis.  However, the amount of data that VCS logs can provide varies, and depending on the system, may not make extracting relevant information straightforward.  A further challenge is that even if the data can be obtained, it still needs to be kept long enough for compliance purposes.  Given the sheer volume of VCS traffic involved in most financial services development projects, this can make it hard to track what’s what.

So, apart from choosing VCS systems that make it relatively easy to set up logs to capture information for audit purposes, consider establishing a regular rotation of logs to make it easier to organize and retain data, regardless of volume.  Frequency of log rotation depends on the size and nature of each company, but it’s typically carried out daily. 

Make sure that the VCS is preserving full change and access histories, with audit trails for all files, users, and product releases, across the entire organization.  Consider using other third party tools to more easily analyse the VCS server logs.  Finally, rehearse: preparing for an audit is like having a back-up, unless tested it does not exist.   

Put in place all these measures and a financial organization should be in better shape to be audit-ready, plus the added reassurance that all those valuable digital IP assets at the heart of so many financial products are more secure.