[BreachExchange] Where enterprise CISOs go wrong

[Destry Winant]

https://www.scmagazine.com/home/security-news/features/where-enterprise-cisos-go-wrong/

The best laid plans are often fraught with mistakes – some big, some
more nuanced. Evan Schuman looks at where CISOs can fall short.

Enterprise security today, at least at the $4 billion annual revenue
level and up, is in a precarious place. Despite GDPR and best security
practices insisting on having complete global datamaps, hardly any
such firms have them. Cloud use is just about universal, but the
assets moving to the cloud is sharply increasing ever year. And yet,
cloud security – or, more precisely, unwarranted reliance on presumed
cloud security – is abysmal.

Shadow IT is getting far worse, even though it’s been around for well
more than a decade, IoT usage is soaring with security protections
often barely negligible and CISO to board communications are hardly
improving. Much of the board problems involve communications. But as
bad as board communications are, CISO to LOB communications are widely
regarded as even worse.

 Access to sensitive information is being shared more widely with all
manner of partners and even some prominent customers, with woefully
inadequate means to guarantee security compliance. CISOs are regarded
as overly resistant to change, while some CISOs are more worried that
they are being pushed to use an unproven new technology too quickly.

 As the old joke says, “Other than that, Mrs. Lincoln, how was the play?”

 The area where most security consultants expressed the greatest
concern is accurate and comprehensive datamaps, aka, asset management.
In short, the criticism is that hardly any large enterprises know
where all of their sensitive data is, what cloud environments they
control, what mobile devices exist in the company and what data those
devices hold and they often have barely a clue about what applications
the company is using. If security and IT don’t know where all their
data is, the argument continues, how can they possibly protect it or
even know if it’s been breached? Until some third-party stumbles on
the stolen data in the dark web or law enforcement finds it on the
server of an arrested cyberthief, these security incidents are often
secrets from the very people paid to protect that data.

 “Some 100 percent of (CISOs) have apps in the cloud that they don’t
even know exist,” says Gartner Research Director Sam Olyaei. That is a
combination of shadow IT (employees purchasing their own cloud
environments for working on their own or their business unit’s
projects – without telling IT or security) and the nature of many
major cloud environments, which use their own apps in addition to the
ones the enterprise knows about.

Joe Nocera, a principal in cybersecurity and privacy with PwC, the
consulting firm more commonly known as PricewaterhouseCoopers, agrees
with Olyaei. He sees large enterprise CISOs still struggling with
asset inventory. Part of that problem is that datamap perfection –
knowing exactly where all data, apps and infrastructure are and what
they all contain – is arguably impossible and that discourages many
CISOs from seriously trying, especially when they are overwhelmed with
other tasks that they can in fact master.

“They tell me, ‘I’ll never have 100 percent complete and accurate’ and
I tell them ‘So strive for that 99 percent,’” Nocera says. “They are
being hit by a misconfiguration or a patch to a system they didn’t
even know was running on that software. They either get overwhelmed by
the size and the challenge and they don’t even start or they try and
do too much and they don’t accomplish anything.”

Another analyst who points to insufficient datamaps as being a key
CISO mistake is Andrew Morrison, who leads strategy, defense and
response for Deloitte Cyber in the U.S. Part of the negative
consequences materializes with vulnerability management of
applications. CISOs “are sitting on a timebomb, They can only fix or
patch so many things,” Morrison says. “It’s a whack-a-mole game of
patch configuration.”

PwC’s Nocera offers one solution and that is to “leverage big data
techniques to better (handle) inventory and discover the environment.
Any type of way to continually monitor new assets.” Some enterprises
have toyed with using a modification of security’s continuous
authentication to constantly watch the network for any new executables
or even IoT devices – whether installed by friend or foe. Nocera says
that could help with asset inventory as well, particularly when trying
to identify assets or programs created via shadow IT.

CISOs “can’t depend on the rest of IT telling you,” Nocera says,
adding that they also suffer from a sharp lack of resources. Also, he
says, every unit is looking only for the items that most relate to
their own operations. “The infrastructure team is trying to find
assets, the data team is trying to discover the data, the privacy
group is looking for GDPR or CCPA violations, etc.”

The challenges of asset management lead directly to the problems with
the cloud, whether it’s an official cloud environment or one purchased
by a renegade unit operating within the wild west rules of shadow IT.

The biggest cloud problem discussed by consultants is that many
security departments assume – or, perhaps more bluntly, hope – that
the major cloud environments (Amazon, Google, Microsoft, etc.) offer
far more security for client tenants than they actually do.

Often, it’s not that cloud environments are necessarily less secure
than the security at the enterprise tenant’s operations – although
that is certainly sometimes the case – but it’s that cloud
environments are working with a massive number of tenants from Fortune
1000 companies and the cloud vendor does the best it can offering a
decent vanilla environment for all. But it can’t tailor its
environment for the compliance and security needs of different tenant
companies and it therefore assumes that every client tenant will
perform their own extensive customization based on that enterprise’s
security, compliance, vertical and geographic needs.

 “Cloud workflows are not inherently secure,” says Gartner’s Olyaei,
who drew the comparison of a cloud tenant with a physical tenant in an
apartment building. He argues that an apartment tenant has to make
sure that the apartment doors and windows are locked and that no
stranger is granted access, but that apartment tenant can’t control
the CCTV in the lobby or make sure that the doorman and security
guards stay awake and do their jobs. “The CISOs believe that it’s the
(cloud service provider’s) responsibility to protect their data and
apps” even though that is not the cloud company’s job, he says.

Olyaei points to Capital One’s massive cloud breach as an example of
an enterprise trusting the cloud provider too much on security
matters. “The fact that the misconfiguration happened is the
customer’s responsibility,” he says.

Deloitte’s Morrison agrees. “In the adoption of cloud, the notion of
outsourcing security responsibilities to the cloud vendor” remains, he
says. Some CISOs “are learning the hard way that you’re not obviating
the responsibility for security” when a cloud vendor is retained.

Morrison said some of his clients have suffered because of how a cloud
vendor handled some tracking. “Things like logging and how far back
they retain logs. We’ve seen a major (enterprise) have an attack and
want to do the standard forensics and the data just wasn’t there
because the cloud provider – courtesy of the contract – only retained
that log data for 30 days,” Morrison says.

Another frequently mentioned complaint about what mistakes Fortune
1000 CISOs make today involves the fear to change. All humans fear
change – and yes, despite what some CFOs believe, all CISOs are
technically human – but analysts argue that this resistance to
security change is proving quite counter-productive.

Shawn Fohs, the managing director of the U.S. forensic, privacy and
cyber response for consulting firm Ernst & Young (EY), points to the
general CISO resistance to, for example, AI’s machine learning (ML)
for security, despite the fact that many of these same enterprises are
aggressively using ML in other departments for research, product
development or marketing analysis.

“A lot of it is a confidence issue,” he says. CISOs “have to become
more aware of potential risks and how these risks are evolving.
Cybersecurity professionals are hesitant to change and it’s a mistake
that they are this hesitant to change.”

Much of this hesitancy to change is evidenced in purchasing patterns,
Fohs said. “CISOs tend to get very focused on that we need this tool
to solve this problem. They get too fixated on a specific tool and
they don’t embrace all of the different tools that are available to
them. They get vendor fatigue and they stick with what they know”
rather than “adapting to a new mindset. They go to all of these
conferences and they meet with all these vendors, but instead of
actually engaging or embracing (the new tools), they just go back to
tried and true. They know what has historically worked for them.” He
cited continuous authentication and behavioral analyts as other
examples of promising technologies that are meeting with a lot of CISO
resistance.

Forrester Research Vice President and Principal Analyst Jeff Pollard
agreed with Fohs and says that many “CISOs have created that situation
for themselves by not being involved in innovation processes. It’s a
lack of flexibility and treating everything the same. Security hasn’t
been very willing to customize.” He wants to see more CISOs not only
embracing DevSecOps, but taking the DevSecOps approach and applying it
to improving relations with lines of business (LOB) by embedding
security people within those groups.

Not only would that kind of cooperation bring security into product
development far earlier, but team members would also bring back much
more sophisticated understandings about the goals and priorities of
those LOBs so that security wouldn’t merely improve, but could also
become far more responsive to those business units and might even be
able to accurately anticipate their needs.

 PwC’s Nocera also sees this complacency and lack of growth to be a
key CISO mistake. CISOs “are not adapting their security model to be
as agile as it could be. They are not being on the front-end of
innovation. Many of these chiefs have grown up being excellent
technologists, (wonderful) at responding to incidents. Their comfort
zone is fighting fires,” Nocera says.

Sometimes, good guys become bad guys with a little math error

In security circles, the typical discussion about mistakes is when
CISOs/CSOs/Security Analysts are accused of making them. But sometimes
it’s the cybercriminals or cyberterrorists who make mistakes. And even
more interestingly, it’s sometimes good guys who make mistakes and
accidentally morph into bad guys.

The recent history of security incidents gives us two superb examples
of hacker mistakes turning those bold hackers into unintentional
attackers.

The first is Robert Tappen Morris, who gave the industry what is
arguably the very first Internet Worm (now known as the Morris Worm)
back in 1988. That worm, which brought much of the Internet to a crawl
or a dead-stop, was an experiment that graduate student Morris created
to make a point about Internet security failings. Point made.

But his intent had never been to crash the Internet, had never been to
create something that more closely resembled an early D-DOS attack
than a run-of-the-mill worm. That was the result of a math error that
Morris made. While leveraging holes in Finger ID, Sendmail and
rsh/rexec, Morris created the worm to impact a limited number of
computers globally: Just enough to make his point.

Ironically, the error grew out of Morris’ explicit attempt to make
sure that the worm did not grow wildly out of control. To slow it
down, it coded the worm to, in effect, ask every machine it visited
whether the worm was already installed. But Morris knew that admins
could simply program the system to always say “Yes, you’re already
here. You can go away now.” To combat this, Morris programmed the worm
to install itself even if the system said it was already there,
roughly one out of seven times.

It turns out that he had intended to have it install itself either way
only once out of seven times, but his math error was that he should
have opted for a far smaller number. That was more than enough to
crash the Internet.

 A more recent example was the Heartbleed virus, from back in 2014. In
a wonderful interview with Heartbleed creator Robin Seggelmann in
Autralia’s Sydney Morning Herald, Seggelmann said “”I was working on
improving OpenSSL and submitted numerous bug fixes and added new
features. In one of the new features, unfortunately, I missed
validating a variable containing a length.” After Seggelmann submitted
the code, a reviewer “apparently also didn’t notice the missing
validation, so the error made its way from the development branch into
the released version.” Seggelmann said the error was “quite trivial,”
even though its effect wasn’t. “It was a simple programming error in a
new feature, which unfortunately occurred in a security-relevant
area.”

As for the impact, the Herald put it succinctly: “The bug introduced a
flaw into the popular OpenSSL software, which is used by many popular
social networking websites, search engines, banks, and online shopping
sites to keep personal and financial data safe. It allowed those who
knew of its existence to intercept usernames, passwords, credit card
details and various other sensitive information from a website’s
server in plain text. It also allowed for a server’s private
encryption keys to be stolen.”

If the path to hell is paved with good intentions, so, too, it seems,
is the path to cybersecurity disasters. At least sometimes.