QA: Secure coding & pen testing – Testing, testing

Ensuring the security of your bank or insurance company’s IT environment is a core consideration for chief information security officers (CISOs) and others at financial institutions. Tony Dennis looks at the issue of secure coding, accrediting penetration testers and other quality assurance (QA) programmes, and asks if more can be done

Industry experts are generally agreed that there is a definite shift in the pattern of penetration attacks. The change in emphasis is towards attacks which target application code and custom software in particular. One reaction to this change was the launch in April last year of the Council of Registered Ethical Security Testers (CREST). Its aim is to build a quality assurance (QA) programme that will benefit commercial end users, including banks and insurance companies. In essence, CREST is focused on testing the testers themselves by introducing a stringent set of qualifications and requirements for practitioners.

According to Richard Hollis, managing director with CREST member, Orthus: “One of the most important developments in penetration testing is the new focus on identifying application-level security vulnerabilities.” Before this happened, security penetration testing was traditionally infrastructure-based. Hollis explains that the objective was to identify vulnerabilities associated within the target network that would enable unauthorised access by hackers. He argues that forensics and fraud findings have indicated that the real game is now on the application level. “Incidents of external hacking as well as internal theft and fraud were directly linked to application weaknesses, which are now being scrutinised as a matter of priority by corporate information security professionals.” It’s no longer about ensuring the virtual private network is secure, but more about identifying poor coding that might let the hackers in. Securing your code is vital.

Ian Glover, president of CREST, largely agrees. He thinks demand for security applications testing is set to take off. “There are also some fringe benefits to this kind of penetration testing, given that many vulnerabilities result from ‘sloppy’ coding. Writing applications to prevent penetration results in much ‘tighter’ code,” he says. For example, while regular testing might reveal the danger of an application leaving a port open, with CREST, the testers will actually assess whether or not that open port genuinely represents a vulnerability that needs to be closed.

Piers Wilson, head of technical assurance with Siemens Enterprise Communications and also involved in CREST, argues that the value of penetration testing is not something that diminishes in times of recession. “More specifically, though, the focus is more than ever on the impacts in terms of data exposures; the loss or unavailability of systems; and needing to protect against the risk of reputational damage.” He agrees that, from a technical standpoint, there is increasing interest in the client-side of security, especially the configuration of remote workers equipment such as laptops (including encryption) and mobile devices. “Plus the drive to automate business processes has meant greater autonomous operation and hence a much increased degree of technical complexity and interaction,” says Wilson.

Secure coding
There have been significant improvements in the last few years in the design and deployment of more resilient and secure code. Best security coding practices (once a fringe issue) are now considered mandatory across the industry and have resulted in the growing popularity and acceptance of procedures promulgated by such organisations as Open Web Application Security Project (OWASP). Even the International Standards Organisation (ISO) is now drafting code development security standards. Orthus’ Hollis believes that the practice of secure coding has now become universally accepted and the industry is rapidly responding with training and certification programs. CREST, with its emphasis on testing the penetration testers, can only help with this drive to secure the IT environment and its operations around the financial services sector.

Vendors are also making their own push to improve matters. At Oracle, for instance, specific emphasis is now given to secure coding and training. Its software security assurance is now integrated in the application lifecycle. “The lifecycle approach is key to us. This is about securing products through each phase of their life – from design and development right through to release,” explains Naveen Grover, EMEA regional head of Oracle Financial Services Consulting.

Training
More than anything, the IT industry needs to put more effort into training developers in writing secure code. “There is still a significant gap in computer science courses and general developer training,” argues Dr Paul Dorey, a director with the consultants, CSO Confidential. “Initiatives such as the not-for profit Safecode.org are important to change current bad practice.” Orthus’ Hollis concurs: “Security training has become essential for software developers. Most often security bugs are really common coding errors, but with far more serious consequences than ‘regular’ bugs. That’s why good training is essential.”

Professor Howard Schmidt has served as the CISO and security strategist for eBay, as well as being chief security officer for Microsoft, so he has long experience in this area. He is now president of the Information Security Forum (ISF) trade body. He obverses that: “The training to write secure code and the software tools are frequently missing. The first imperative is to train software engineers in how to write secure code in the first place. Then comes testing and after that penetration testing in native environments not just in ‘the lab’. One of the problems is that penetration testing often only occurs after the app is deployed.” So why a QA programme for pen testers is important, it is even more vital to ensure software is secured earlier in the development cycle, even before it’s implemented by a financial institution.

Certifying the quality of your pen testers is still important of course. “We’re working with training companies and academia to try to build a professional development programme that would be spread over, say, two years,” explains CREST’s Glover, who makes it clear that their qualifications are not the kind to be acquired from a mere week-long ‘boot camp’. The body has already developed some workshops and guidelines since its launch last year and will continue to expand its remit (see boxout).

Suitably qualified staff
“The provision of qualified and accredited staff and contractors is a start but not a solution,” argues Orthus’ Hollis. The secure coding issue still needs to be addressed by the majority of software vendors. As the primary originators, vendors need to recognise the value of implementing best secure coding practices in the development of their commercial offerings. If these simple and effective best practices, such as not leaving ‘backdoor cheats’, were followed by vendors the security integrity of ‘off-the-shelf’ software could be increased making it much less vulnerable. “The main entry point is the keyboard beneath your fingers,” observes ISF’s Schmidt. “You don’t have to be a super user to let the hackers in. Once behind the firewall hackers can start to look for known vulnerabilities.” One of the gravest dangers is from malware which is written only after details of vulnerabilities have been identified and publicised by those with good intent.

The government’s GCHQ-based CHECK qualification is a good scheme but one orientated towards the public sector. “For the private arena, CREST is the only credible scheme for commercial organisations,” claims CREST’s Glover. He also argues that the initiative is unusual in that it resulted from within the testing industry itself, rather than being stimulated by the financial community – who are effectively the buyers. For this reason CREST has set up an Industry Advisory Panel (IAP). “We’re inviting the industry to come and help define future strategy,” Glover declares. He also hopes that CREST will be able to persuade the Financial Services Authority and other industry bodies to “embrace and endorse the CREST initiative. We’re more than happy to talk to the [financial] industry.” Indeed, Aviva and the DTCC were some of the financial institutions present at the launch of CREST last year.

Competent practitioners
A common dilemma is knowing that your chosen supplier is truly trustworthy. “To answer this it is best to understand what value CREST (or CHECK, the public sector equivalent) gives you,” says Siemens’ Wilson. “In essence you are gaining assurance that the penetration testers you are being supplied with have a high level of technical skill and trustworthiness. The staff accreditations and qualifications give you a level of assurance. However, a tester who has an accreditation may still not be considering your systems in a business context, unless that was explicit in the scope of the review, so good project management is still required.”

One area of weakness is that CREST is predominantly UK-focused and many financial institutions are global. “We are looking to roll out CREST to other territories, without compromising our integrity, and preserving the same quality that we offer in the UK,” counters Glover. The most likely new candidate for CREST expansion is South Africa.

Conclusions
Remember, insecurity of coding comes at three levels. Firstly, there are commercial apps (such as Oracle) as well as the OS (operating system) itself and web server software. The same vulnerability applies to Open Source products, too. At the next level there are the smaller threats, such as apps to burn DVDs. Here organisations need to enforce rigorous updates to ensure protection against intrusions. Finally, there is the custom applications that enable employees to do their job - for instance, the spreadsheets used by traders on the financial markets.” As the ISF’s Schmidt admits though, the dangers from insecure coding aren’t felt just by the financial sector; they’re ubiquitous, covering blue chip companies down to SMEs. “The very applications which are the foundation of our success are also the area of greatest vulnerability.”

CREST explained

Ian Glover, president of CREST says that, to date, 30 people have passed the body’s assessment process, a pass rate of only 30 per cent, illustrating the quality of the individuals. There is also a degree of risk for those who decide to go for the CREST assessment. If they fail they will lose their ‘CHECK Team Leader’ status – a qualification obtained by taking a course run by the UK’s GCHQ. However, passing the CREST infrastructure assessment is equivalent to a CHECK team leader status. “It is designed to be very tough,” admits Glover. “On the other hand, you effectively get two for one if you pass [CHECK and CREST qualifications].”

At present, there is only one level of CREST qualification but two forms of assessment – infrastructure and web application testing. Soon the body intends to replace that with two levels. One level would be CREST Certified and the other would be CREST Registered. The Registered assessment comprises of both a written and a technical assessment which would simulate a systems-based test. By contrast, the CREST Certified Tester qualification will require an individual to pass the written assessment and simulation, and also to have passed a whole day’s technical assessment.

>> other supplement features