Top five application security pitfalls to avoid

What are the common perils and pitfalls CISOs should consider when investing in corporate application security and Application Security Testing (AST)?

Spending without holistic application inventory

Shadow and legacy web-based systems, abandoned web services and APIs, expired SSL certificates, and unprotected cloud storage (e.g. AWS S3 buckets) adversely affect even the vast majority of FT 500 companies today. Many organizations, including the largest ones, still have a rudimentary application inventory that is often incomplete and outdated. Outsourcing, cloud and containers make CISO’s lives even more arduous.

DevSecOps is certainly the way to go for application security. However, even when implemented, few people within enterprise know for sure how many corporate web and mobile applications they have, let alone their branches in test and dev environments. When people leave or retire, newcomers often prefer not to deal with the existing application jungles and just follow previously existing practices, exacerbating the problem. Consequently, corporate WAF and other security controls are unimplemented on some of the business-critical applications and APIs, corporate AST programs miss important targets in regular testing, while forgotten and unsupported systems leave the door wide open for attackers. I remember a case, when after ISO 27001 disaster recovery (DRP) exercise, obsolete web systems with PII were restored and became publicly accessible from the Internet where they remained unnoticed for six months after the exercise. This lack of a proper inventory inevitably results in a serious non-compliance with GDPR and other laws and regulations.

Therefore, in addition to centralized application management and continuous security testing within Secure SDLC, implement a regular application discovery to reveal newly created (sub)domains, mobile APIs, issued and expired SSL certificates, new software versions and code deployed into production.

Giving too much importance to generic benchmarks

Every single AST vendor detects OWASP Top 10 risks, or at least say they do. However, not every OWASP Top 10 risk is detectable by most AST products and solutions. An ubiquitous and trivial (at first glance) XSS may be worth a thousand-dollars bounty payment if located after two-factor authentication process, is present in an HTTP parameter that is uncrawlable and unbruteforceable, and requires a complicated WAF bypass exploitation. Contrariwise, a dozen of reflected XSSs found by an open source vulnerability scanner unlikely deserves any considerable score in a benchmark.

Most complicated, and often most dangerous security flaws, hardly enter into any OWASP Top 10 category, especially when dealing with sophisticated business logic issues like reimbursing already shipped goods at e-commerce website. Moreover, many professionals questioned CSRF disappearance from the latest OWASP Top Ten ranking, taken into consideration the global widespread of the flaw. The latest PCI DSS still contains CSRF testing amid 6.5.x requirements. Purposely vulnerable software frameworks, allegedly purported to impartially benchmark AST products, may be biased and tailored for a particular commercial software. Another frequent issue of such frameworks are purely artificial “vulnerabilities” that are practically never found in real environments, but are lined up together with essential vulnerability detection capacities within the framework, misleading the decision makers.

Therefore, make sure that an AST benchmark is properly tailored for your applications and environment, related risks and vulnerabilities you aim to detect in production. Using your own systems in test environment for a benchmark may be a good idea.

Acting without consistent application security strategy

Virtually every CISO is well familiar with Secure SDLC and DevSecOps concepts, however, not so many have managed to properly implement them. Being an inseparable subpart of corporate cybersecurity strategy, application security should be risk-based, goal-oriented, coherent and consistent. That is to say everyone, including external suppliers and consultants, should play in the same orchestra.

A new trend of Application Security Testing Orchestrating (ASTO) is a good development towards consistency and coordination in AST. However, many companies still desultory shift between tools and services, trying to remediate isolated problems rather than following a clear goal-oriented strategy.

Your application security strategy should unambiguously set measurable goals, empower people to take well-informed decisions and allocate necessary resources to meet intermediary objectives of the long-term strategy. Busy cybersecurity executives tend to mechanically follow best practices from industry analysts without customizing their advice for their own needs, processes, people and risk appetite. If you have a corporate subscription to Gartner, it always worth your time to schedule a couple of calls with Gartner technology analysts as they have great insights to share.

Omitting legal aspects of software development

Corporate legal counselors often prefer to avoid dealing with peculiar IT folks talking incomprehensible technology terms they fail to grasp. Omitting complexity and diversity of conflicting laws that may govern corporate IT, legals and techies generally feel pretty comfortable without each other, sometimes leading to disastrous consequences for their employers.

Being a cybersecurity executive make sure that:

All of the abovementioned elements are quite tricky and may widely differ depending on the governing law and jurisdiction. Make sure you will get a legal advice from a licensed attorney or your corporate counsel.

Forgetting about Open Source Software risks

Emerging Software Composition Analysis (SCA) is a valuable technology for almost any company or organization, including SME. Software developers use Open Source Software (OSS) more and more frequently even when building business-critical or internal systems, bringing new risks and threats.

Usage of OSS may be perfectly legitimate, economically justified and even necessary in many cases. However, it is not that uncommon, especially for third-party or junior developers, to leverage ready-to-use open source libraries, frameworks or code excerpts (often in violation of licenses, intellectual property rights and contracts). A considerable part of OSS is frequently riddled with security and privacy flaws that nobody really cares to fix. Black Hats are well informed about the great wealth of windfall opportunities provided by newly disclosed OSS vulnerabilities and promptly launch large-scale automated attacks against unwitting companies once a new vulnerability becomes public. Worse, cybersecurity teams often have no clue how many outdated libraries or other OSS species their application hide, leaving them vulnerable and unprotected.

Make sure that every single piece of your corporate software is composed of identifiable modules and that OSS risks are properly addressed therein. Ascertain that your developers and third-party software suppliers are aware of the OSS risks. Implement continuous monitoring for vulnerabilities in OSS products you use and establish an internal policy to authorize or not OSS usage, depending on circumstances. Last, but not least, consider implementing SCA if not yet done.  

Consider the five aforementioned steps for your operational plan in 2019 - you will likely prevent many expensive problems and concomitant headache.