App security depends on culture change

In my previous Industry Insight, I argued that security had to be embedded into the way apps are created in order to protect important data in today's distributed, open systems. Clearly, this will involve changing the way all those in the software development and maintenance cycle go about their work.

Changing behaviour is neither easy nor quick. But it can and must be done, or the company and the data it holds will be at risk.

So, how do companies get the process of culture change under way?

At the most general, organisational level, the first step should be to get the IT and security functions collaborating. One of the benefits here will be to create a single point of accountability with regard to IT risk generally.

When it comes to application security specifically, all the stakeholders across the whole application life cycle need to be identified and targeted. These would include the product owner (business owner), business analysts, designers, developers, quality assurance team/testers and, critically, the operational team.

All of these players need to understand that software apps are no longer to be conceived, developed or rated in terms only of functionality, user experience and quality; security has to become one of the key criteria that each one of them factors into their thinking.

The corollary is that security should not be seen as something that might slow down the development process, but rather as something that is intrinsic to it at every step of the way. This latter point is very important for two reasons. The first is that the task becomes much easier if each stakeholder considers the security implications. This way of doing things has to begin with the product owner, who needs to consider the security implications of the required piece of software. What data sets will it access? What local or global compliance issues are raised? What is the appropriate level of security for this particular application?

If this process continues down the chain, each stakeholder will be able to build on what went before, rather than trying to begin from scratch.

Integrating security into the way each stakeholder performs his or her task will require extra training. For example, members of the value chain will need to know how to do some basic threat modelling appropriate to their disciplines and roles.

Thus, developers should know how to code defensively for specific languages and environments, as well as how to perform their own static code analysis to identify violations of security best practices early on. They should also know how certain types of applications are attacked - something the testing team should also know.

Initially, this training will have to be separate in order to improve existing skills, but in time, security training should be integrated into the normal training for each stakeholder group.

Human nature also means the carrot is needed as well as the stick.

The creation of a new culture will be greatly assisted by the existence of an overarching corporate policy relating to application security, principles and standards. Human nature being what it is, law can play a big part in changing behaviour, not only by spelling it out but also by threatening sanctions.

However, human nature also means the carrot is needed as well as the stick. Attention should be paid to positive reinforcement; rewarding sound security practices will help to make them second nature, and slowly but surely build a new security-conscious culture.

Finally, care must be taken to create a feedback loop from the operations team back into the development process. They are the ones who live with the application the longest, and are best placed to monitor just how secure it actually is. Their findings are invaluable, and should be used to refine the security practices of the whole team.

Next time, I will consider how to protect the crown jewels, which hackers are actually after: data.