Bridging the gap between security and developers

A lack of common understanding between IT security professionals and application developers is causing security flaws to be built...

A lack of common understanding between IT security professionals and application developers is causing security flaws to be built into systems from the earliest stages of development. This problem was the subject of a lively March meeting of Computer Weekly's Infosecurity User Group.

Peter Wood, partner and chief of operations at First Base Technologies, said that because developers are not security professionals, their application development stresses functionality, not security, and there is a lack of awareness of security issues.

Equally, security professionals lack awareness of application vulnerabilities in security teams, and of effective testing tools.

Furthermore, Wood said, security certification and accreditations do not examine web applications; the development cycle is often missing from security procedures and audits; and, although security people scrutinise the desktop, the network and the server, they usually miss the web application.

Application vulnerabilities occur, said Wood, because common coding techniques do not necessarily include security; input is assumed to be valid, but untested; and inappropriate file calls can reveal source code and system files.

To bring security to the development environment, said Wood, it is necessary to create and enforce secure coding practices, self-assess code during development, implement security checks into the quality assurance cycle and consider security during change control. In other words, early detection equals early prevention.

The challenge of achieving this in global organisations was addressed by Andy MacGovern, global security awareness manager at Reuters.

He said that security is often seen as a "hold up" in the product development lifecycle, where products have to be delivered faster in a climate of increased customer expectations, more complex products, reduced budgets, fewer resources and a tougher legislative environment.

MacGovern said good communication between the security and applications development teams is key.

When it comes to developing a strategy, he suggested asking what you are trying to achieve. Is it a "tick in the box from audit". Is it a secure product/environment? Or is it both?

Similarly, you should identify and adopt an appropriate security framework and develop policies appropriate to the organisation, said MacGovern. Focus your activities on solutions and develop a mechanism for delivering the framework, then build on it once it is in place.

Reuters has developed an extended practice that takes into account limited security resources, and aims to have two "streams": replication of security consulting resources, and the development of so-called "security evangelists" - people who understand the need for security.

Reuters' security managers have a power of veto over projects if they are involved late in the process and deficiencies are identified. However, power of veto should be a last resort, said MacGovern. The best approach to security is a proactive one in the product development lifecycle.

In his presentation, Stuart King, security consultant at Reed Elsevier, highlighted the most common vulnerabilities in corporate IT infrastructure: buffer overflow, web servers, database servers, cookie poisoning, parameter tampering, SQL injection and cross-site scripting.

He then demonstrated online how simple it can be to access and use error messages to understand an application and get access to business data.

Recipe for apps development disaster

To guarantee failure for your application development, follow these rules

  • Omit security requirements from the project specifications

  • Bolt on security once the development is complete

  • Do not create development standards

  • Do not validate user input

  • Do not encrypt authentication credentials

  • Forget peer review of code

  • Trust all third-party development

  • Allow developers to manage the change control process

  • Keep developers in the dark about security practices

  • Forget about vulnerability testing.

Source: Stuart King, Reed Elsevier

Read more on IT risk management