5 steps to boost your application security testing ROI

While Gartner forecasts global cybersecurity spending to reach $96.3 billion already this year, Gemalto reports a 164 percent surge in breached records just in the first half of 2017, affecting almost 2 billion people. The same research says that the insider threat is diminishing, attributing as much as 74 percent of all breaches to malicious outsiders. The World Economic Forum now estimates that the cost to the global economy due to cybercrime is roughly $445 billion a year – a modest estimation surrounded by multi-trillion statements.

The majority of the external data breaches and security incidents involve insecure or abandoned web applications one way or another. Nowadays, mobile and IoT applications are rapidly joining the game. Meanwhile, the Web remains of the most dynamic, fast growing and agile part of corporate IT infrastructure, offering all types of products and services. The 2017 State of Application Security White Paper by the SANS Institute states that over 43 percent of organizations are pushing out application changes weekly, daily or even continuously. The White Paper’s data also says that over 60% of the breaches were [partially or entirely] attributed to public-facing web applications.

The emerging market of application security testing (AST) provides a great wealth of innovative tools, SaaS and services. However, the overwhelming majority of customers are firmly frustrated by the complexity of new technologies and the accompanying terms, most of which are frequently misplaced and misused. If amorphous DevSecOps or CI/CD have become an engraved part of the application security market, AVC or ASTO are currently seeking their place under the sun, probably in vain. Let alone the AI hype or endless incidents around bug bounties that do not increase trustworthiness of the market.

Unsurprisingly, many companies are now completely lost in these jungles. They desultory try one AST solution after another, facing new breaches, alternately blaming vendors, nation-state hackers and market analysts. In this article, we will try to shed some light on the foggiest realm of the application security testing and bring some simplicity and common sense to it via five coherent steps:

Start with application discovery and inventory

You can triple your application security spending every quarter, but if you don’t have an accurate, comprehensive and up-to-date inventory of all your applications (including their API and web services), you will inevitably fail. RASP or web application firewalls based on machine learning will not be a panacea.

At the ISF Annual World Congress in November, my company High-Tech Bridge launched a vendor-independent application discovery service. In just a few hours of non-intrusive reconnaissance and crawling of OSINT data sources, the free service gathers external applications, domains and web systems attributable to your company or its subsidiaries. You can alternatively hire a cybersecurity consulting boutique or a perform the discovery inhouse, but without it – don’t spend on application security testing – you will just pour money down the drain.

Minimize external attack surface

Most of our customers, who performed application discovery, were surprised by how many legacy, internal or otherwise inapposite applications were publicly accessible from the outside. Shadow IT, abandoned APIs, test [sub]domains, abolished corporate applications suddenly reanimated to production during a DRP testing – are just the tip of the iceberg.

Sensitive applications can be protected with a two factor (2FA) or strong authentication, firewalled for a specific range of IP addresses or a GeoIP of a country. These simple, costless measures significantly reduce the external attack surface, skyrocketing cost of intrusion into your digital realm for attackers.

Assess application risks and perform BIA

Once all unnecessarily exposed web applications and web services are insulated from the outside, you can start a holistic risk assessment and Business Impact Analysis (BIA) for your applications, including internal ones.

During the process, it is pivotal to identify which personal data each application stores or processes. In light of the impending GDPR enforcement, PII identification across your systems may save millions in fines. Check which of your applications may fall under other existing regulatory or compliance requirements, such as PCI DSS.

Last, but not least, you have to nominate (or identify) a responsible person for each application. In a larger company, separate vertical or horizontal roles can be assigned for application security, privacy, maintenance or virtual patching. In a smaller organization, one person or team should be the single point for all issues for application or a group of applications.

Implement continuous monitoring

Continuous security monitoring is an inalienable part of a good application security strategy. A 24/7 application security testing and integrity monitoring should be implemented for the most critical applications and their components. For less critical or static applications, integrity monitoring should nonetheless be performed on a continuous basis to identify a breach non-related to application flaws (e.g. compromised admin password or breached SFTP server).

Software composition analysis (SCA) is a relatively new technology that can help identify security flaws in third-party and open source components of your applications. Continuous monitoring for tangential problems, such as phishing or typosquatted domains can be a very good complementary activity.

Establish clear remediation guidelines

Many organizations detect application vulnerabilities in a [relatively] timely manner, but fail to patch or otherwise remediate them for weeks or even months. The complexity of the applications, lack of time or responsible person, fear to break something – are among frequent reasons for the detrimental sluggishness. The delay undermines the entire value of application security testing, putting systems at critical risk.

Obligatory guidelines and procedures prescribing remediation techniques should be imposed on web developers and security teams. Depending on an application’s business risk, criticality and exploitability of the vulnerability, remediation can be performed via deployment of new code to production or a temporary virtual patch with a web application firewall. Timeframe of remediation and its verification process should be clearly defined, otherwise developers may find a wide spectrum of excuses for omitted patches.

By implementing the aforementioned recommendations, you can boost the efficiency and effectiveness of your application security testing strategy, maximize its ROI and better protect your digital crown jewels, without unnecessarily increasing your cybersecurity spending.