SpiderLabs is the penetration testing and forensic security investigation arm of Trustwave, a US headquartered IT security company. Last year, it conducted 2,200 penetration tests and 330 investigations for companies who were compromised.

This gives SpiderLabs a front-line view of the security challenges that businesses – especially merchants that handle credit card data – are struggling with and that are being exploited by cyber criminals.

According to John Yeo, SpiderLabs’ EMEA director, businesses are finding it difficult to detect security attacks going on within their own infrastructure. "One thing I see organisations struggling with is being able to analyse events that are going on within their environment and detect deviations from normal activity, given the complexity of their environments," he says.

"We know that this is a problem, because only 16% of security incidents are discovered by the victim themselves," he says. More often, data breaches are detected by third parties such as credit card processing companies.

"That suggests organisations aren’t doing enough to understand what’s going on in their IT environments," he says.

Yeo says security information and event management (SIEM) can help organisations identify suspicious behaviour in their complex IT environments (SpiderLabs’ parent company, TrustWave, sells a SIEM solution). This analyses system logs to develop a picture of normal behaviour, and can flag up deviations from that behaviour to an administrator.

However, companies need to apply SIEM and other security measures with some intelligence if they are to thwart some of the more sophisticated security attacks.

One recent example of an incident SpiderLabs helped investigate illustrates the sophistication of some cyber criminals. "The attackers exploited a legacy X25 link –  a system used by the banking industry for wire transfers – to access the company’s network, and they spent about six months just mapping out the internal environment," Yeo explains.

"They managed to identify a couple of key systems that had the sensitive data on them, including a legacy UNIX system, and they spent another six months developing some malware specifically for those systems to harvest the data.

"Here’s the amazing thing: because it was some kind of legacy UNIX, the attackers didn’t have access to a development environment, so they were actually using the organisation’s own development environment to make this malware.

"After they’d deployed the malware, the attackers were doing their regular updates to their own malware," he explains. "The only reason they were spotted was that they had introduced a bug into their malware that generated lots of files on the disk and started using up disk space. Luckily, the systems administrator was pretty savvy, and figured out something was really wrong and called the investigators in.

"The time from the start of the intrusion to detection was three years," he says.

Piecing together log data in order to identify this attack would have taken some imagination on the part of the victim. "You can see where some of the challenges lie for organisations," says Yeo. "They have to think very creatively about the mass of log data that they are dealing with."

One SpiderLabs customer doing just that is a New York company, which discovered that some of its executives’ remote access credentials had been compromised through phishing attacks. The company now cross checks system access logs against the physical security system in its headquarters, so that if an executive’s remote access log-in is used when they are inside the building, this can be quickly flagged as a suspicious incident.

Secure coding

Another weakpoint for many organisations is secure software development. Mature software development shops will include security testing in their quality assurance controls, but Yeo says that companies should consider the security implications of any new system in the very earliest stages of development.

"When a business wants to roll out a new applications, they go through a requirements capture phases, and they evaluate the use cases for the application," he explains. "Security requirements should be captured as part of that process, and the company should devise the ‘misuse’ cases – how an attacker could abuse the application to get unauthorised access to data.

"But it’s fair to say that there are very few organisations that approach software development with that much rigour," he says. "In a typical software development project, functionality is the top priority, followed by quality, and security comes in third."

Yeo acknowledges that not every developer can be a security expert. "It’s difficult to expect any individual to be an expert in two domains," he says.

Nevertheless, he adds, there is an awareness problem when it comes to secure development. "There isn’t always an appreciation from the organisation developing code what can go wrong if they don’t address security."