[BreachExchange] 7 Modern-Day Cybersecurity Realities

[Destry Winant]

https://www.darkreading.com/cloud/7-modern-day-cybersecurity-realities/d/d-id/1340826

Move to the cloud. Shift left. Buy the latest XDR and deception tools. The
technology and cybersecurity industry has always been susceptible to
marketing hype, but do these moves actually make their organizations more
secure? Or do they just add more complexity?

With all the major hacks, from SolarWinds to the issues with Microsoft
Exchange, how can security pros sleep at night? They may think they are
doing the right thing, but are they operating with a false sense of
security?

Michael Isbitski, technology evangelist at Salt Security, says security
pros have to focus more on securing the application programming interfaces
(APIs) that power many of these tech strategies. From hosting internal
cloud apps to relying on gateways and traditional patch management tools,
the old methods don't focus enough on API security – and the APIs are
susceptible to attackers.

"With so much at stake, businesses need to humbly accept that they have
been overly confident in these security approaches and tool choices,"
Isbitski says. "They should seek to update their tooling and processes
accordingly to address modern threats."

We've compiled seven tips to help security pros sort out what they need to
think about as they deploy many of these evolving security concepts and
technologies.


Are the Cloud Apps You Build Really Secure?
As companies moved to the cloud, they invested heavily in security tooling
reimagined for the cloud, often in the form of cloud workload protection
and container security tools, says Salt Security's Isbitski. Such tools, he
says, are useful for identifying known vulnerable dependencies, detecting
misconfigurations, microsegmenting workloads, and preventing drift from
hardened baselines. But unpatched vulnerabilities and misconfigurations in
platforms such as Kubernetes have been a point of entry for attackers,
allowing them to bypass access controls, run their own code on compromised
clusters, and deploy cryptocurrency miners.

"Unfortunately, this new breed of cloud security tooling still fails to
address much of application-layer security," Isbitski says. "These tools
primarily address network security and infrastructure security and continue
to leave applications vulnerable. So the public cloud may be secure, but
that doesn't mean what you build in-house is secure."


Companies Can Shift Left but Still Must Shift Right
The shift-left mantra encourages development teams to push security process
and tooling earlier into the software development life cycle (SDLC), as
well as dispersing security subject matter expertise, says Salt Security's
Isbitski. Shift left has strong ties to DevSecOps practices, which aim to
integrate and automate security during design, build, and deploy phases.
The practice has paid off for many organizations, as they can iterate on
security more quickly, validate whether security was appropriately built in
from the beginning, and reduce the cost of fixing vulnerabilities later in
the SDLC.

However, organizations cannot entirely shift left at the expense of runtime
security, Isbitski says. Developers will never write perfect code, they
can't always scan the code extensively enough within release windows, and
scanners by design are built to find known vulnerabilities or weaknesses
that follow well-defined patterns.

Sandy Carielli, a principal analyst at Forrester who covers security, adds
that shift left was never meant to mean only shift-left. However, on the
plus side, she says shift left does let development teams find and
remediate a large number of security flaws faster.

"New attacks and zero-days are always coming along, so we still also have
to protect applications in production," Carielli says. "I don't think there
are a lot of organizations that are shifting left to the exclusion of
runtime security. Most people realize they need both."


WAFs and Gateways Won't Fully Secure APIs
APIs are the foundation of today's modern applications, but few
organizations understand just how prominent they are or the level of risk
they present, says Salt Security's Isbitski. APIs make up a
disproportionate share of risk because they're such an attractive target
for attackers, but too many organizations assume Web application firewalls
(WAFs) and API gateways protect their APIs. These technologies cannot
prevent most types of API attacks because of inherent design limitations,
and they give organizations a false sense of security for their APIs and
API-driven applications.

"APIs are unique to every organization, and real-world attacks against APIs
don't often follow well-defined patterns of known vulnerabilities,"
Isbitski says. "Combatting these security risks requires runtime security
that continuously learns API behaviors and stops attackers early regardless
of the attack techniques used."

Rik Turner, principal analyst for emerging technologies at Omdia, agrees
that security teams need to address API security beyond WAFs or API
gateways.

"I recall in the mid-2010s having this discussion with another of our
analysts who argued that the gateway vendors would step up to the need for
additional security, and indeed at least one of them, Apigee, did launch an
add-on module for security," Turner says. "However, API security is largely
the preserve of a separate group of vendors and not the API gateway folks."

Forrester's Carielli adds that organizations expose a large number of
applications, and hence a large amount of data, through APIs. She says
stories of data leakage and unauthorized access are common. Carielli
stresses that API security today consists of a combination of tools -- some
runtime application security tools that have expanded to protect APIs, some
API management tools that address certain security use cases, application
security testing tools that can test APIs, and API-specific security tools.


Traditional Patch and Vulnerability Management Tools Won't Secure APIs
While patch and vulnerability management programs can help security teams
address risks in off-the-shelf software and components, application and API
security strategy requires more, says Salt Security's Isbitski.

But eager to avoid falling victim to the 99% of vulnerabilities that are
known by security and IT pros, companies have put significant effort behind
patch and vulnerability management. They are often tracked as common
vulnerabilities and exposures (CVEs), a useful taxonomy for cataloging
well-defined vulnerabilities in published software or released hardware.
However, Isbitski says this can never capture the expanding universe of
potential weaknesses that organizations can introduce as they build or
integrate applications and APIs.

"Attackers will sometimes target well-known exploits in software, like in
the case of the recent Exchange server hack," he says. "Much more common,
though, attackers look for weaknesses in APIs or API integrations that are
unique to the target organization. There are no 'patches' for code that the
organization has created or integrations that engineers will use to stitch
together applications and APIs."

Common weakness enumeration (CWE) IDs are a more appropriate classification
to describe issues in homegrown applications and APIs, Isbitski says. If
the organization develops its own code or integrates with other code, then
security professionals should get familiar with CWEs and the OWASP Top 10,
he adds. They are more relevant classifications when building applications
or APIs rather than sourcing software from somewhere else where CVE IDs are
applicable.

According to cwe.mitre.org, CWEs helps developers and security
practitioners do the following:
- Describe and discuss software and hardware weaknesses in a common
language.
- Check for weaknesses in existing software and hardware products.
- Evaluate coverage of tools targeting these weaknesses.
- Leverage a common baseline standard for weakness identification,
mitigation, and prevention efforts.
- Prevent software and hardware vulnerabilities prior to deployment.


Basic Awareness Training Falls Way Short -- Especially For Engineers

A great deal of attention has been put into security training around
ransomware attacks, phishing, and social engineering since these are common
techniques employed by attackers.

Maxine Holt, senior research director for security at Omdia, says companies
make far too many assumptions regarding the extent to which this kind of
awareness training actually changes behavior. Too many organizations take a
tick-box approach, she says, delivering the training typically from a third
party once or twice a year, ensuring employees have done this training, and
then forgetting about it until it is due again.

"It's woefully inadequate and, quite frankly, a waste of time," Holt says.
"It would be significantly better to focus on point-in-time security
training that changes the behavior of employees so that they think in a
more security-positive way."

Training and awareness focused on application security still lag behind at
many companies, adds Salt Security's Isbitski. Developers and engineers
have minimal time for training as application release trains have
accelerated. If they do find time to learn, they will focus on their
technology stack of choice and security becomes mostly an afterthought.

"Security expertise continues to be in short supply for most organizations,
particularly when it comes to 'full stack' engineering," Isbitski says.
"This leaves nonsecurity personnel with minimal guidance as they create or
update applications. Compressed development and release timelines that
result from agile methodologies and DevOps practices leave little time for
secure design reviews or threat modeling exercises where security training
and awareness could bear fruit."

Lack of time is always a challenge, Holt says, but security must shift left
in the development life cycle; it can't remain an afterthought, adding that
from an organizational perspective, why not build security in up front?

"This is so much cheaper than remediation after a security incident or
breach," Holt says. "But this does require commitment to allow for training
and time for developers to learn, as well as the desire from the developers
to do so. It's not an overnight fix."


Just Buying a New Tool Doesn't Make the Company Secure
Companies like to think that once they buy the latest hot security tool,
the organization is secure, but that's just not the case, says Peter
Firstbrook, a research vice president at Gartner who covers security.

Companies have a very hard time holding on to good people, he says, so
quite often the new tools companies buy are managed improperly and the
admins misconfigure them. Security teams need to ask: Are we on the latest
version? Are we using all the capabilities of the new product? Do some of
the rules get overwritten during updates?

"People think they can buy their way out their security problems,"
Firstbrook says. "Unfortunately, in a lot of situations, the people who
installed the product in the first place are long gone. That's why in some
situations there may be 1,000 rules and the people managing the operation
are afraid to change them. They're afraid they will take out something
important."

Companies also need people with soft-side skills -- people who can follow
procedures, read the documentation, and communicate what's wrong to
management, he says.

According to Eric Parizo, principal analyst for security operations at
Omdia, people also think that all these new products will come fully
integrated. That's one of the reasons extended detection and response (XDR)
has emerged, as it's essentially a preintegrated solution encompassing
threat detection and response across endpoints, networks, and clouds, he
says.

"But it's a big challenge any way you slice it," Parizo says. "That's also
a reason why managed security services continue to grow to the point that
even the top-tier vendors are increasingly offering managed services. They
recognize that no matter how integrated and effective their product
platforms may be, there's an increasing number of CISOs who are looking to
outsource management of as much technology as possible. I think that's a
trend that's likely to grow steadily over time."


Companies Rolling Out IoT Products Don't Always Focus on Security
A company's focus may be on building cars, consumer electronic products, or
household appliances, but they don't always realize that they have to
invest a bit more time and money into the development and management of the
code that goes into these products or the mobile apps that integrate with
them, says Salt Security's Isbitski.

"It's really been the evolution of computing," he says. "Companies that
weren't in the business of software creation now find themselves developing
applications and APIs to enable their core business. Organizations don't
always realize that with many IoT devices they have to secure the APIs as
well as the app."

Omdia's Parizo adds that what Isbitski refers to encompasses many of the
issues around the Internet of Things (IoT). As 5G becomes more pervasive in
the US and across much of the developed world, ubiquitous connectivity for
all sorts of IoT devices will become not only possible, but standard
practice, he says. And many of those devices not only don't have security
capabilities built in, but they also weren't developed with security in
mind.

"As a result I think without better protection for IoT over 5G, we're going
to see a massive comeback of IoT botnets, especially as botnet-driven
cryptomining has become increasingly lucrative for many adversaries,"
Parizo says. "I think IoT will be one of the cybersecurity stories of the
coming decade."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riskbasedsecurity.com/pipermail/breachexchange/attachments/20210514/001d8010/attachment.html>