Designing IA for AI - Information Architecture Conference 2024
Wendy Nather - Building a Rube Goldberg Application Security Program
1. Building
a
Rube
Goldberg
Applica3on
Security
Program
SOURCE
Boston
2011
Wendy Nather
The 451 Group
2. The
451
Group
451
Research
is
focused
on
the
business
of
enterprise
IT
innova3on.
The
company’s
analysts
provide
cri3cal
and
3mely
insight
into
the
compe33ve
dynamics
of
innova3on
in
emerging
technology
segments.
Tier1
Research
is
a
single-‐source
research
and
advisory
firm
covering
the
mul3-‐tenant
datacenter,
hos3ng,
IT
and
cloud-‐compu3ng
sectors,
blending
the
best
of
industry
and
financial
research.
The
Up3me
Ins3tute
is
‘ The
Global
Data
Center
Authority’
and
a
pioneer
in
the
crea3on
and
facilita3on
of
end-‐user
knowledge
communi3es
to
improve
reliability
and
uninterrup3ble
availability
in
datacenter
facili3es.
TheInfoPro
is
a
leading
IT
advisory
and
research
firm
that
provides
real-‐world
perspec3ves
on
the
customer
and
market
dynamics
of
the
enterprise
informa3on
technology
landscape,
harnessing
the
collec3ve
knowledge
and
insight
of
leading
IT
organiza3ons
worldwide.
ChangeWave
Research
is
a
research
firm
that
iden3fies
and
quan3fies
‘change’
in
consumer
spending
behavior,
corporate
purchasing,
and
industry,
company
and
technology
trends.
8. How
it
really
happens
Training
• Onsite
classes
are
expensive
• Offsite
classes
are
even
more
expensive
• You
can’t
pay
to
train
contractors
• The
most
important
developers
can’t
make
it
to
the
classes
• Nobody
fires
up
the
e-‐learning
applica3on
• E-‐learning
doesn’t
teach
developers
half
of
what
they
need
to
know
9. How
it
really
works
Threat
modeling
and
security
requirements
• It’s
not
in
any
story
• Security
isn’t
just
in
the
applica3on
design
• Developers
make
bad
assump3ons
about
the
environment
for
their
applica3ons
• YOU
try
wri3ng
down
every
single
security
requirement
• Security
requirements
are
new
and
can
be
every
bit
as
disrup3ve
as
new
func3onality
• Func3onal
requirements
change
mid-‐project;
threat
modeling
and
security
requirements
have
to
be
re-‐visited
• Developers
will
ask
for
excep3ons
to
security
requirements
and
you
have
to
grant
them
and
track
them
10. How
it
really
works
Peer
review
and
scanning
in
development
• Not
every
tool
will
scan
an
app
that
isn’t
built
• Itera3ve
scanning
is
what
the
developer
wants
to
do,
but
it
takes
too
long
• The
development
environment
is
different
from
produc3on
• The
security
team
becomes
a
boleneck
as
they
field
ques3ons
and
help
write
the
code
• There
are
s3ll
dependencies
on
other
insecure
applica3ons
and
insecure
libraries
• Here
There
Be
Deadlines
11. How
it
really
works
QA
tes3ng
• They
don’t
want
security
tes3ng
messing
with
their
tes3ng
results
• Itera3ve
scan-‐fix-‐rescan
cycle
too
short
for
many
tools
• QA
thinks
that
“security
tes3ng”
means
tes3ng
to
see
if
the
login
works
• Verbose
error
messages
are
needed
for
troubleshoo3ng
• Test
environment
s3ll
isn’t
the
same
as
in
produc3on
• Those
short
deadlines
again
12. How
it
really
works
The
Budget
Issue
• Once
a
project
is
done,
it’s
done
• Nobody
keeps
staff
siang
around
wai3ng,
in
case
there’s
an
applica3on
that
needs
remedia3ng
• Remedia3on
of
an
app
can
be
a
full
project
in
and
of
itself
• The
CIO
never
intended
to
touch
that
applica3on
again
• Project
managers
rarely
budget
for
QA
3me,
much
less
for
security
tes3ng
Boom
line:
they
don’t
see
the
risk
20. The
moral
of
the
story
Budget
isn’t
enough
(even
when
there’s
enough
budget)
Have
your
pieces
placed
in
the
right
order
Timing
is
everything
A
“15-‐minute
fix”
–
isn’t
Running
an
applica3on
security
program
is
as
much
about
social
engineering
as
it
is
about
the
technical
side