Although #Great (corporate) Wall of China never trended on underworld Twitter sites, so far as we know, there’s no real doubt that firewalls have well and truly failed as effective ways to secure corporate systems and data. The number of breaches reported daily testifies to that.

The truth is, though, that today’s application-based and customer-focused business environment means that the old model of corporates cowering behind their battlemented perimeters is no longer appropriate anyway. Rich Internet applications are now at the forefront of most companies’ business strategies. How secure these applications are determines how secure the company’s IT systems are.

In other words, getting your Web applications written on the cheap by your idiot cousin’s dopehead son makes even less sense than ever! To put it bluntly, the quality of the development of your Web application is all that stands between your corporate data and cyber-criminals or hackers.

We should not take this threat lightly. In 2013, 42 percent of all vulnerabilities reported were related to Web-based applications, according to the IBM X-Force Research Team. The US National Institute of Standards and Technology (NIST) reports that 90 percent of all attacks target Web applications, while the Verizon Security Breach Report found that 95 percent of all data leaks could be traced to them. Sony, Target and Lockheed Martin are just some of the high-profile institutions that have suffered an attack on their Internet applications.

Of course, the security community hasn’t been sitting still. Many techniques—among them Source Code Peer Review, Web Application Penetration Testing, Web Application Firewall, Dynamic Application Security Testing and Static Application Security Testing—have been developed to mitigate this risk. But how do you know which of these would be most effective in protecting your organisation’s applications against current and future cyber threats?

My advice to fellow security professionals is simple: Never forget that application security is a software development challenge, and can only be solved by the development teams.

To do this, the notion of application quality, which has traditionally focused on functionality and performance, must be expanded to include security. The following three steps are essential to any successful application-security programme.”

1. Set a policy direction and protection strategy. Fortune cookies are right: if you don’t have a target, then you will hit it every time, and if you don’t have a destination, every route is correct. Begin by knowing where all your applications are and which data each uses, including associated databases. Then prioritise the critical ones and set security policy and standards based on the risk each application faces.

During this phase, conduct a full assessment of the application landscape, looking at the threats you are facing and the risk the company is prepared to tolerate. Compliance and governance needs must also be considered.

The aim is to align development activities with policies and requirements through a comprehensive application-security strategy and implementation plan. The plan should define which applications should be protected and to what extent. (As you know, security cost and effort must always be commensurate with the value of the asset in question.)

2. Integrate security into your software development life cycle (SDLC). As noted above, the development factory is the best place to address security issues. This should be done during the design phase; any attempt to secure the software after it has gone into production will be difficult, inexpensive and, ultimately, ineffective.

To tackle this challenge, you will need to begin by identifying all stakeholders in the SDLC, and ensure that they all buy into the policy and strategy direction set in the first step above. Once that has been achieved, the next step is to optimise the SDLC methodology, which might include agile techniques and DevOps, to factor in security at all stages, from business requirement articulation through design, coding, building and quality assurance.

Key approaches will include performing application threat modelling in the requirement/ design phase; running static code analysing tools in the coding and building phases; and using dynamic application testing techniques in the quality assurance phase.

If the DevOps methodology and approach is used, then the operational teams will carry the security measures into the post-production cycle to ensure continuity.

3. Engage and educate all SDLC stakeholders. Common errors in implementing application security programmes tend to centre on engaging and educating SDLC key stakeholders. Great care should be paid to identifying them (Step 2), bearing mind that stakeholders self-identify based on whether they are interested or affected. Define awareness activities based on the roles and interest of each stakeholder, and avoid one-size-fits-all approaches.

To help SDLC teams make the right decisions, they will need a thorough grounding in the security standards and policies. I strongly recommend the following key principles to develop a team that can develop secure applications:

•             Managers and architects need to understand topics like threat modelling, architecture risk analysis, and secure SDLC practices.

•             Developers should know how to code defensively for the specific languages and environments in which they are developing.

•             Developers should know how to perform their own static code analysis to identify violations of security best practices.

•             Testers and developers should know how applications are attacked.

In conclusion; secure SDLC integration is not a magic bullet but a journey to undertake. Engagement with the entire SDLC team and implementation of a static code analysis tool are the centres of success.