US Cybersecurity Strategy Shifts Liability Issues to Vendors
Governance
&
Risk
Management
,
IT
Risk
Management
,
Standards,
Regulations
&
Compliance
Holding
Vendors
Liable
for
Insecure
Apps
Fuels
Safe
Harbor,
Transparency
Questions
The
White
House
website
A
new
federal
strategy
to
make
commercial
manufacturers
liable
for
insecure
software
requires
an
attainable
safe
harbor
policy
and
could
be
a
disincentive
for
software
manufacturers
in
sharing
important
vulnerability
information
with
the
U.S.
government,
according
to
industry
observers.
See
Also:
OnDemand
|
Navigating
the
Difficulties
of
Patching
OT
The
Biden
administration’s
National
Cybersecurity
Strategy
released
Thursday
calls
for
shifting
liability
for
software
products
and
services
to
promote
secure
development
practices.
The
liability
is
designed
to
shift
to
large
companies
that
assemble
software
products
and
license
them
to
the
federal
government.
It
will
not
affect
developers
of
open-source
applications,
which
are
commonly
used
to
build
new
software
products.
“We
can’t
have
them
devolving
that
responsibility
down
to
a
two-person
open-source
project
that
hasn’t
received
any
funding
in
the
last
five
years,”
according
to
a
senior
administration
official.
“That’s
not
going
to
get
us
the
outcome
that
we
want.”
In
announcing
the
new
strategy,
officials
said
the
liability
shift
will
be
a
“long-term
process,”
potentially
taking
a
decade
to
fully
implement.
But
cybersecurity
industry
insiders
fear
passing
legislation
that
sets
liability
for
software
manufacturers
will
make
them
far
less
likely
to
share
information
with
the
U.S.
government
if
one
of
their
products
has
a
highly
exploited
vulnerability
(see:
White
House
Unveils
Biden’s
National
Cybersecurity
Strategy).
“The
threat
of
liability
will
always
discourage
transparency,”
Proofpoint
Executive
Vice
President
of
Cybersecurity
Strategy
Ryan
Kalember
tells
Information
Security
Media
Group.
“I
don’t
think
that
there
is
a
simple,
straightforward,
easy
compromise
here.”
Creating
a
Sturdy
Liability
Shield
The
administration
envisions
that
it
will
roll
out
more
stringent
software
development
practices,
work
with
vendors
to
implement
them
in
the
software
development
process
and
then
work
with
industry
and
Congress
to
establish
a
liability
shield
for
companies
that
adopt
those
practices.
That
process
will
take
well
over
a
year,
the
senior
administration
official
predicts.
Veracode
founder
and
Chief
Technology
Officer
Chris
Wysopal
says
drawing
from
the
NIST
Secure
Software
Development
Framework
for
the
safe
harbor
law
is
more
aspirational
than
realistic
since
the
liability
shield
must
consider
a
company’s
maturity
and
security
posture.
Kalember
says
no
current
institutions
are
well
positioned
to
assess
compliance
with
NIST
or
assign
blame
after
a
security
incident.
“We
need
a
few
different
levels
of
what
building
safe
software
means,”
Wysopal
tells
ISMG.
“The
SSDF
is
a
good
starting
point,
but
I
think
it
does
need
to
be
more
practical
and
more
basic.”
The
safe
harbor
must
both
set
high
expectations
for
entrenched,
incumbent
software
manufacturers
while
not
inhibiting
the
ability
of
new
startups
to
compete
and
get
to
market
quickly
with
a
new
product,
Wysopal
says.
He
wants
to
see
liability
established
for
all
software
rather
than
just
critical
infrastructure
software
since
attackers
can
strike
critical
targets
through
general-purpose
software.
“We
need
to
worry
about
lifting
the
bottom
up
a
little
bit
to
get
to
a
reasonable
level
rather
than
just
focusing
on
the
software
running
in
the
water
treatment
facility,”
Wysopal
says.
What
Belongs
in
a
Safe
Harbor?
Software
development
best
practices
have
shifted
over
the
past
two
to
three
years
from
being
focused
almost
entirely
around
code
security
to
broadly
incorporating
development
processes
and
infrastructure,
says
Nurit
Bielorai,
Aqua
Security’s
go-to-market
manager
for
software
supply
chain
security.
The
NIST
SSDF
has
gotten
organizations
to
look
beyond
code
and
consider
the
integrity
and
provenance
of
their
software.
“Organizations
should
pay
a
price
for
making
their
cloud
services
or
their
software
less
secure.
But
right
now,
they’re
not
paying
that
price.”
–
Ryan
Kalember,
executive
vice
president
of
cybersecurity
strategy,
Proofpoint
As
part
of
the
safe
harbor,
Bielorai
says
organizations
should
have
to
validate
at
the
end
of
the
software
development
process
that
the
output
is
what
the
company
intended.
He
also
says
firms
should
have
to
provide
a
full
security
history
of
all
components
in
their
software
regardless
of
whether
those
components
were
developed
by
the
organization
in
question
or
taken
from
elsewhere.
“If
I
see
that
your
product
has
gone
through
the
right
security
process,
I’m
much
more
likely
to
pick
this
product
than
to
pick
a
product
that
has
a
ton
of
vulnerabilities,”
Bielorai
tells
ISMG.
“It’s
about
allowing
the
software
consumer
to
understand
what
they’re
about
to
consume.”
Although
Wysopal
says
universal
adherence
to
NIST
SSDF
isn’t
realistic,
he
believes
basic
application
security
testing
and
management
of
open-source
risk
should
be
part
of
any
safe
harbor.
Automated
static
and
dynamic
testing
of
applications
can
uncover
the
most
commonly
exploited
flaws,
such
as
buffer
overflows,
remote
command
injection
and
SQL
injection,
according
to
Wysopal.
He
also
says
organizations
seeking
a
liability
shield
must
understand
what
third-party
libraries
and
versions
of
open-source
software
they
use
so
they
can
react
quickly
if
new
vulnerabilities
are
found.
Nearly
every
commercial
software
manufacturer
does
some
degree
of
application
security
testing,
but
older
products
with
declining
customer
bases
are
often
neglected
when
it
comes
to
security.
“Everyone’s
doing
a
little
bit
of
this
somewhere,”
Wysopal
says.
“But
is
it
being
done
consistently
throughout
all
the
products
from
a
particular
vendor?
Someone
who’s
buying
a
10-year-old
product,
paying
money
for
it
and
installing
it,
shouldn’t
be
put
at
huge
risk
just
because
the
vendor
thinks,
‘Oh,
well,
we
didn’t
secure
it
10
years
ago.
It’s
too
expensive
to
try
to
secure
it
now.'”
Alternatives
to
Making
Manufacturers
Liable
Although
Proofpoint’s
Kalember
isn’t
overly
optimistic
about
finding
a
way
to
establish
liability
for
commercial
manufacturers
without
harming
information
sharing,
he
does
believe
software
makers
need
more
incentive
to
produce
secure
products
since
the
market
hasn’t
really
punished
companies
such
as
Fortinet,
VMware
and
Microsoft
for
their
vulnerabilities
that
were
exploited
on
a
massive
scale.
“Organizations
should
pay
a
price
for
making
their
cloud
services
or
their
software
less
secure,”
Kalember
says.
“But
right
now,
they’re
not
paying
that
price.
Until
they’re
incentivized
to
do
that,
you’re
not
going
to
get
inarguably
useful
controls
enabled
by
default.”
Kalember
supports
the
Biden
administration’s
effort
to
stop
vendors
from
disclaiming
liability
through
an
end-user
licensing
agreement
that
no
one
actually
reads.
He
also
says
software
manufacturers
should
have
economic
incentives
to
implement
by
default
strong
security
features
such
as
multifactor
authentication,
turned-off
federation
features,
and
basic
checks
for
malware
when
hosting
files.
“We
should
be
able
to
agree
on
all
of
these
–
even
if
they
do
introduce
a
little
bit
of
cost
–
as
the
price
of
being
on
the
internet
and
being
a
software
company
that’s
able
to
sell
to
the
world’s
biggest
market,”
Kalember
says.
“The
market
power
that
we
have
in
the
U.S.
might
actually
be
used
to
do
some
good
here.”
About Author
