Fraudulent bugs

Over the past few years security has become one of the most talked about topics in the IT sector. Businesses have made huge investments in technology to try and ensure hackers cannot penetrate their networks and cause serious financial damage. However, the enemy can also lurk within and steal millions without the company even knowing. For example, it cost the Jasper State Bank in Minnesota $2.7 million before it realised that two former employees were engaged in fraudulent activities.

Organisations are tackling the issue of fraud by carefully vetting and monitoring employees who have access to sensitive financial systems. Employee vetting has become a critical part of the recruitment process because typically, with development projects, there is a high staff turnover.

The predictable churn of staff within a project, in addition to project managers hiring contractors (to address the peaks and troughs or to utilise staff with a particular skills set required at that point) is a cause for concern from a security perspective.

Having a high turnover means that there is a larger potential for people to place malicious code into your applications. In addition, even vetting and monitoring employees does not always protect against former staff who may still be in a position to commit fraud.

Most organisations do not view current or former employees as an immediate threat, because they are very diligent about managing passwords and access rights when people move on. However, many may be unaware that systems or applications can be developed in such a way that features are built in to enable someone to steal millions of rands from company accounts or destroy applications without leaving a trace.

Fraudulent application developers can insert lines of code that remain dormant for several years. When or if they leave the company, the code may become active. Because the code is often carefully hidden away within the application, it will only be found if people are specifically looking for it.

Presently, most businesses do not have the controls or processes in place to protect against criminals who have the technical knowledge to insert fraudulent code into IT systems. Most security managers would not be able to find this type of threat because very specialised and technical knowledge is generally required to discover this malicious code. Methods can, however, be employed within the specialist application testing or quality assurance teams to trap fraudulent code.

Companies need to turn to the testing teams and look at the testing processes they have in place. It tends to be the norm for people to only test active code (code that actually contributes to the running of an application), but this needs to change if businesses are to protect themselves from rogue developers. They need to make sure that more of the code is tested, so that dormant code is identified, examined and analysed for fraudulent attributes.

Embedding code coverage analysis as an element to the testing strategy will ensure that testing teams can easily highlight lines of code that may not have been tested, prompting a revision in test procedures to generate more testing scenarios aimed at uncovering fraudulent code. Obviously increasing the amount of testing will cost money, but it is easy to see why it is crucial that businesses act to ensure that their application development and testing processes are water-tight, guaranteeing fraudsters cannot use dormant code to steal money from the business.

By Paul Wandrag