Code Red, Nimda, and SQL Slammer are three of the most well know worms that had a massive impact on the Internet. The industry has considerably improved since then, and it’s much harder to target operating systems in the past few years. Automated patching, vulnerability scanning, sandboxing, compiler, and memory management techniques improved by adding a layer of security and making exploit writing harder. A straightforward and easy to vulnerabilities in the infrastructure are almost non-existent and even when found the level of complexity required to exploit it on multiple systems reliably had grown exponentially.

Threat actors do not stand still

The threat actors are evolving as well. The traditional hacks for fun and profit, a.k.a. see how far we can spread this thing are few and far between. There are more sophisticated attackers nowadays whose goal is financial gain, and the Web is the perfect place for this. There are all sorts of sensitive personal and payment information processed, transmitted and stored by Web applications. I am sure that your personal data is there on some Web application right now.

Old problems in a new world

The widespread of web apps means new propagation channels for next generation of malware or worms. A growing number of popular websites with good reputation become compromised with the site owners having no knowledge of it. The site is then used to launch drive-by attacks where the malicious code on the web site attempts to covertly install malicious code on computers of visitors to the site.

The low hanging fruit

Software teams are turning to agile software development methods to improve velocity and deliver results quickly. Agile methods should generally promote a disciplined project management, but the reality is quite different. Web applications are put together in a rush with little attention given to security and defensive programming. A whole new ecosystem of web frameworks has sprung up to existence that prioritises quick results and ease of use over security. Many applications are so exposed that an attacker requires only very simple file inclusion exploits. That’s the reason why some people are exploiting them rather than targeting the underlying infrastructure. It only takes minutes to understand a typical web application’s coding errors. By nature, web applications to be successful must be indexed by Google and other search engines. It is a double-edged sword. A simple search for vulnerable installations may reveal more candidates with a similar vulnerability. In just a few minutes, an average attacker with little talent and even less time can compromise a typical web application.

No silver bullet for AppSec

There are no silver bullets for ensuring web application security. No amount of network hardening, platform auditing, or vulnerability scanning can compensate for bad programming. Understanding the limitation of any automated application security tools is also essential. Tools like SAST, DAST and IAST are not technically capable of finding the types of vulnerabilities found by penetration testers or your QA team. Automated tools are not capable of identifying access control flaws or business logic issues. Robust application security is essential to the long-term survival of any organisation. Application security begins with secure coding and design, continues with security activities embedded in the software development lifecycle and is maintained over the life of the software.

It takes skill and manpower to design, review and test web applications. I’m afraid there are no shortcuts, it’s twisty and hard-to-follow route to success.

In a highly agile environment, security is fast becoming embedded into the Continuous Delivery of software as part of the DevOps process. As we are shifting things increasingly forward in the software development lifecycle which means the budgeting of software security should be more aligned with development costs.

Basic definitions

Software development costs fall into two categories: capital expenses (CapEx) and operational expenses (OpEx). Let’s first recap the basic definitions of CapEx and OpEx:

• CapEx is a business expense incurred to create an asset that will have a future benefit and will span beyond the current tax year. These assets are presumed to have a useful life. Expenses for these assets are recognised as they are depreciated over time.

• OpEx is a business expense to keep the business running. It is recognised in the period incurred (i.e., in the current tax year). Most expenses for the day-to-day operations that are not directly contributing towards the creation of assets with benefits spanning beyond the current tax year would end up being categorised as operational expenditure.

CapEx vs. OpEx

Why is the CapEx vs. OpEx distinction so important when trying to get a software security initiative approved?

Because the right mixture of CapEx and OpEx in your project can mean the difference between getting it approved and having it rejected for budgetary reasons.

Most software development activities resulting in a creation of a software asset would generally be accounted for as CapEx. A modern Agile software development process allows you to capitalise more of your costs. I will touch on this later in the post.

Any SDLC activities of a security team that directly contribute to the creation of a specific software like Security Architecture, Threat Modelling, Code Reviews or Testing would fall under CapEx.

On the other hand, any day-to-day operations that are not directly contributing to the creation of an asset like quarterly security testing of the running application portfolio, security training, vulnerability management would fall under OpEx.

Advanage of Secure Agile Development

You can capitalise the cost of development activities, provided you can demonstrate how the software will yield future economic benefits. However, any day-to-day operations as well ass research costs associated with the software project planning must be considered OpEx and cannot be capitalised.

The classic waterfall development process employs a rigidly structured, sequential steps to produce an entire, finished software application in one iteration or, possibly, in several linear phases. While Agile process expends less effort during the research phase of a project, which means you need less OpEx to get your project started. Additionally, continuous delivery blends the development and production phases as new code is steadily added in an automated fashion to the product reducing the cost required to install and configure, means less OpEx.

Making an investment in building security early in the SDLC for specific software products (CapEx) should reduce the amount of OpEx that is required after the fact for security bug fixes as part of maintenance. OpEx should decrease because down the line maintenance costs of the software will be less as it was built securely from the beginning and thus will require fewer security fixes down the line

Alignment is key

A software security initiative should align with a specific software project to balance CapEx/OpEx and derive the greatest benefit. Strengthening that alignment is key as resources must directly contribute to the creation of asset to be capitalised. DevOps process helps with this as it creates self-sufficient teams that are self-contained and responsible for development and maintenance of a specific product.

Organisations may sometimes choose to be more conservative and count some of that spend OpEx depending on current financial needs. By capitalising as much as possible, an organisation can amortise costs over several years and spread out the impact on earnings. On the contrary, organisations that prefer to expense quickly will take an immediate hit in the current year, allowing a greater one-time effect on earnings.

Book a meeting with your CFO or a member of the accounting department and find out how your organisation handles CapEx/OpEx. You may find that the ability to capitalise a larger percentage of software security costs can get your projects done sooner.