by Godfrey Kutumela, leader of the cyber crime and security division

Security needs to be integrated into the way apps are developed. Here's how.

In my previous Industry Insight on the security challenges faced by mobile apps in particular, as well as in other columns, I have advocated integrating security into the way in which apps are developed.

Only when they are intrinsically secure will apps be fit-for-purpose in a world in which the threat landscape is in constant flux.

The big question is how.

The following five principles will help put you on the right path − no matter whether you follow the Waterfall or Agile development methodologies:

* Adopt a secure software development life cycle policy. All the stakeholders in the development process, from the business analysts to the operations team, need to have a common understanding of how important it is to integrate security into everything that they do. The policy will give them the mandate to do so, and will also specify the governance and compliance frameworks.

* Empower development teams by providing security education. The security policy is all about creating the climate for culture change. To make that change real, those involved in software development need training. Traditionally, none of the stakeholders in software development − business analysts, developers, architects, production teams − have any security training. It's clearly important they understand what cyber criminals are up to, and what advanced response methods have been created.

* Undertake application threat modelling. This is really the cornerstone of application security. It entails assessing how an application could be attacked − and how to make it watertight. Companies that have mature software development environments with good documentation will be able to develop threat models more quickly. There are five high-level steps to creating an application threat model, but it is advisable to get an application security architect to lead the process:

1. Identify the critical assets that the application is using, and what regulatory compliance issues apply to each. These critical assets would typically include personal and financial data, HR data and corporate intellectual property.

2. Create an architectural overview of the application. This means establishing exactly which components it will be using and how they will be used.

3. Decompose the architecture into small components. Having established the architectural overview, look at how the critical data passes through the various application components − where it comes from, where it is processed and where it is stored.

4. Conduct a vulnerability analysis. Find out what the common threats are for each of the critical assets, and how the attacks are carried out.

5. Develop a response plan to these threats. This is the outcome of the threat-modelling process. The threats to the critical assets need to be documented, along with how the team plans to counter them. As part of the process, research how others have responded, and determine the best approach based on the current development team's skills. It is also necessary to prioritise the threats − which must be countered, and which are less likely and so might be excluded if necessary.

The security policy is all about creating the climate for culture change.

* Integrate software security tools into the software development environment. Static code analysis tools and dynamic application security test tools are fairly recent arrivals, so they may not be in general use. The key is make them part of the development process. Used properly, they will first help developers fix vulnerabilities but the ultimate aim must be to move from "fix" mode to "avoid" mode.

* Implement 24/7, real-time application security threat monitoring. The application is only secure in the context of the threat landscape at the time of going into production. However, it will potentially be used for years, and threats are evolving and increasing at a frightening rate. Real-time threat monitoring will allow you to keep up to date with these threats and then, if a vulnerability is identified, either to fix it via a patch, or in severe cases to remove it from the production environment for remediation.

The whole DevOps philosophy, which seeks to integrate the development and operational teams, has the potential to help feed information on vulnerabilities discovered in production back into the development process.

In line with the drive to bring the development and operations environments into closer collaboration − known as DevOps − it is highly recommended that the threats identified by the security monitoring software are fed back into the development environment, where they will obviously influence future projects.

In my next Industry Insight, I will delve into securing open source. Until then, stay safe!

This article was first published on ITWeb