March 2, 2021

TerabitWeb Blog

Fascinating Technology and Security Information

Top five application security pitfalls to avoid

5 min read

Original Post from SC Magazine
Author: Doug Olenick

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 regularapplication
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:

  • Intellectual property (mostly copyright, patents and trade secrets) developed internally, outsourced or both – belongs exclusively to your company.
  • Your software developers and external contractors are properly informed about confidentiality and non-use of your intellectual property and are aware of sanctions for a breach.
  • Your software developers remember that any external storage of code (e.g. in third-party code repositories), even if not accessible to the public, may be considered as a breach of confidentially if not expressly authorized in advance.
  • Your software suppliers are contractually bound to indemnify you for any lawsuits from third parties whose intellectual property their code may infringe.

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.

The post Top five application security pitfalls to avoid appeared first on SC Media.


Go to Source
Author: Doug Olenick

Copyright © All rights reserved. | Newsphere by AF themes.