qualit

y time
Editors: Nancy Eickelmann Motorola nancy
.eickelmann@motorola.co m
Jane Huffman Hayes University of Kentucky hayes@cs.uk y
.ed u
Security and
Software Quality: An Interview with Frank Perry
Jane Huffman Hayes, Nancy ickelmann,
and ! Ashlee Hol"rook
ne of the fastest groing to!ics
in sys" tems engineering today
is security. #t$s nearly
im!ossi%le& and certainly not ad"
visa%le& to neglect security$s role
hen develo!ing a softare
system. 'he ram" ifications of
failing to com!letely and
(
correctly address security can %e
devastating to an organi)ation& not
only in com!romised data and
financial cost
%ut also in the
time and en"
ergy s!ent to recover. (ne of us& Jane
Hayes& sat don ith an e*!ert in the
field& +rank ,erry& to discuss the state
of the art and future directions of
system security and !articularly ho it
inter" acts ith softare quality.
+rank ,erry has %een chief engineer
of the -ystem and Netork -olutions
.rou! at -/#0 for to and a half
years. 'he grou! of almost
12&222 !eo!le focuses on netork
technolo" gies and a!!lications&
!rimarily in the federal market. ,rior
to 3oining -/#0& ,erry s!ent to years
as the chief technology officer at the
U- 4e!artment of 5eteran$s /ffairs.
He has also served as technical
director at the U- Navy$s -!ace and
Naval 6arfare -ystems 0ommand
and at the 4efense #nformation
-ystems /gency. He received his
,h4 in electrical engineering ith a
minor in com!uter science from the
Naval ,ostgraduate -chool.
Jane Hayes: .ood morning& 4r.
,erry. 6e$ve !ut together a list of
questions from a diverse grou! of
folks from industry& acade" mia& and
civil service. 6e asked them& 7#f you
had a chance to s!eak ith an e*!ert
on secu" rity& hat questions ould
you ask dealing ith softare
security and softare quality89 (ne
of the overarching questions e
heard as 76hat concerns kee! you
u! at night89
Frank Perry: #$m not the ty!e of
!erson that loses slee! over very
much& %ut if # ere to lose slee! over
security concerns& it ould %e over
the state of security on the #nternet
today and the !otential for harm if
the rong set of things ere to
come together. +or e*am!le& if you
com%ine a )ero"day vulnera%ility :a
secu" rity vulnera%ility that someone
might e*!loit %efore it %ecomes
generally knon; together ith an
e*tremely fast !ro!agation orm&
such as a 6arhol orm& hich can
!ro!agate orld" ide during its 1<
minutes of fame& and if that orm has
a hostile !ayload focused on doing
damage or making your machine !art
of a %ot" net& then that$s actually a
fairly scary thought.
JH: #$d like to talk a %it a%out the
softare develo!ment !rocess. 4o
you have a !referred security !rocess
for softare develo!ment8 +or
e*am!le& 0=/-, :0om!rehensive&
=ighteight /!!lication -ecurity
,rocess; or !erha!s Mi"
12 IEEE SOFTW ARE Published by the IEEE Computer Society 070!7"#$0%$&20'00
( 200% IEEE
Q#A$I%& %I'
crosoft$s -ecurity
4evelo!ment =ifecy" cle
!rocess8
FP: # don$t really. More so
than argu" ing for a s!ecific
7!ro!er"noun9 !rocess>
0=/-, in the ?ational
Unified ,rocess frameork& or
someone else$s !rocess in a
different frameork>the more
im!ortant issue is to have a
!rocess>hatever is right for
your orga" ni)ation>and
integrate it into a %roader set of
softare develo!ment
!rocesses. +or e*am!le&
integrate it in the 0MM#
:0a!a%ility Maturity Model
#ntegration; a!!roach and
evaluate it as a !art of the
%roader set of !rocesses that
the enter" !rise uses.
6ithin our grou! at -/#0&
e$ve em%raced 0MM# as many
others in the industry have.
6e$ve created our on !rocess
asset li%rary to include a num"
%er of security"s!ecific
!rocesses. (ur grou! has gone
through the 0MM# a!" !raisal
and is at maturity level <. 6ith
security& as ith many other
as!ects of the overall softare
develo!ment life cycle& the key
issue is to have a !rocess that
makes sense for your
organi)ation and industry and
then tailor it as a!" !ro!riate to
individual !rograms. Even if
you %egin ith something like
0=/-,& it$s actually a general&
high"level& and fairly
heavyeight set of !rocesses
that are not going to %e
a!!ro!riate for every !ro3ect.
# don$t think it$s different than
other as!ects of softare
develo!" ment. Having security
!rocesses inte" grated into your
overall set of softare
develo!ment !rocesses is the
im!ortant ste!.
JH: 'he ne*t question
comes from one of our leaders
ho has a U- 4e" !artment
of 4efense %ackground& so
that ill !ro%a%ly sho in
the ques" tion. 0an you tell us
a%out the devel" o!ment of
standards and !olicies for
secure softare systems8
'he 4o4 thre out their
standard 12 years ago in the
name of acquisition reform.
'hat action a!!ears& to some&
to have %een a disaster. Has the
4o4 recovered8
FP: # think defense is actually
doing quite ell com!ared to
many other sec" tors in the
market today ith res!ect to
security standards and
!olicies. #f e look %ack to
the early 1@A2s& e had
Frank
Perry
the ?ain%o -eries of
!u%lications& hich ere very
good& very thorough& very
com!lete& and also very
difficult to im!lement. 'hey
ere ahead of their time ith
res!ect to the ca!a%ilities of
many of the o!erating systems
of the day. Bou go from there
forard through hat the
4o4 has %een doing& and
you$ll see a focus on 0ommon
0riteria certification and
National #nformation
/ssurance ,artnershi!
certification for !roducts in the
defense market. #f you fast"
forard %eyond that& you see
ork that$s %een going on in
-ecurity"Enhanced =inu*& hich
started at the U- National
-ecurity /gency. -E =inu* has
%een %roadly ado!ted %y the
o!en source community and
has the !otential to
1 )
*+ y$ , u - e 200% IEEE SOFTW ARE
Q#A$I%& %I'
fundamentally change some
as!ects of the com!uting
!latform that have %een
!ro%lematic. # think the 4o4
actually has its act !retty ell
together in that regard.
JH: 6hy is it so difficult to get
com" !anies to ado!t knon&
sound soft" are engineering
!ractices hen %uild" ing
security"critical softare8
FP: -ecurity"critical softare
is e*" tremely com!le*& more so
than many other as!ects of
softare develo!ment. 'hat$s
one of the issues>com!le*ity.
/nother issue is time>the time
it takes to deal a!!ro!riately
ith that level of
com!le*ity and to get the right
level of assurance in the overall
!rocess. #t$s also eighing that
time versus the counter"
%alancing force of s!eed to
market and com!etitiveness.
'hat makes it really difficult.
Bou also have a mindset shift&
from the early #nternet days
hen !eo" !le ere %enevolent
users to today$s #n" ternet here
you have to assume malice from
the outset. 'hat makes it
much more difficult. #f you
look at cry!to" gra!hic
!roducts and im!lementations&
if you look at some of the core
cry!to" gra!hic %uilding
%locks& it really does take an
e*!ert to deal ith them.
Many softare engineers aren$t
a!!ro" !riately trained to deal
ith those tasks. (ne issue this
raises is that if e$re go" ing to
%e successful& e have to
inte" grate those !roducts into
much larger architectural
%uilding %locks. .etting
someone to take a lo"level
cry!to" gra!hic /,# and
integrate it a!!ro!ri" ately into
an overall system environment
is really going to ta* many
softare de" velo!ment
organi)ations.
JH: 6hat have you found to
%e the most effective security
tools8
FP: 'his really isn$t my area
of s!e" cialty& so # can$t give
you s!ecific an" sers to that
question. #n general& # look to
some of the real e*!erts in that
field and am ho!eful %ecause
of the level of o!timism that
several of them have e*!ressed.
+or e*am!le& in an in" tervie
at the Euro!ean (!en -ource
0onference last year
:Euro(-0(N
C22<;& /lan 0o* as o!timistic
a%out the code verification and
analysis tools that are finally
starting to come into the
market!lace>they have real
!romise for the future. /t
the same time& though& e$re
only at the start of that 3ourney&
and it$s going to %e a very long
time %efore that %ecomes
!ervasive in the industry. #t$s
certainly not !ervasive today.
JH: +rom the !oint of vie of
soft" are engineering& hat
tools ould you like
cry!togra!hers to develo!8
6hat cry!togra!hic tools are
needed or are inadequate for
today$s engineer" ing needs8
6hat ill %e needed in five or
12 years8
1 )
*+ y$ , u - e 200% IEEE SOFTW ARE
FP: #$m not sure # can
!rognosticate
12 years into the futureD that$s
a little %eyond my crystal %all$s
ca!a%ility. #$ll go %ack to hat #
said earlier a%out the
com!le*ity of cry!togra!hic
!roducts and security !rotocols.
'here are some key e*am!les
that have %een very suc" cessful.
Even though the 4istri%uted
0om!uting Environment as
too com" !le* to !ro!agate
idely& Ker%eros as a security
mechanism as an integral
!art of 40E. #t$s %een very
successful and survives to this
day in a num%er of !roducts.
-imilarly& if you look at --=
:-ecure -ockets =ayer; and
'rans!ort =ayer -e" curity in
6e%"%ased a!!lications& you$ll
find you$re not really relying on
most softare engineers to
develo! or even integrate many
of those com!le*
cry!togra!hic !roducts. Bou
leave it to the e*!erts hen it
comes to designing and
im!lementing cry!togra!hic
!rod" ucts and secure !rotocols
and integrat" ing them into
higher"level architectural
%uilding %locks. +or most
softare en" gineers& then& it$s
more a question of choosing
ho to use and configure the
%uilding %locks rather than one
of devel" o!ment. Bou have a
much higher !ro%" a%ility of
success ith that a!!roach.
40E and --= integrated into
higher" level %uilding %locks
are to key e*" am!les. #f #
look today at architectural
constructs such as service"
oriented ar" chitectures& # think
e$ll have to take a similar
a!!roach if e$re going to
have end"to"end security
across a distri%uted chain of
service invocations. 'he mar"
ket!lace is not there yet.
/nother key for foundation
mech" anisms like 40E and
--= to %e suc" cessful is that
they must %e standards" %asedD
e have to evolve %eyond the
intero!era%ility !ro%lem
stage to a state here the
standards are ell un"
derstood and acce!ted. ,eo!le
should understand ho to
!rofile and im!le" ment the
standards& and multi!le ven"
dor im!lementations should
%e inter" o!era%le out of the
%o*. 'hat$s the ideal state.
6e$re making !rogress %oth
ith the ne domains like
service" oriented architecture
and ith truly standards"%ased
and intero!era%le
im!lementations.
JH: 6hat do you feel is the
greatest security threat on the
hori)on& and here should
research focus to counter it8 'hat
is to say& ith ne technologies&
for e*am!le +,./s :field"
!rogramma" %le gate arrays; that
let softare mod" ules
reconfigure themselves or
ada!t& hat kind of security
issues do you see surfacing8
FP: 'here$s a scary thought
>ada!" tive or self"modifying
softare and emergent %ehavior.
#$m not sure ho to deal ith
that in a security environ"
mentD that$s very challenging
and com" !le*. Many security
issues& hoever& are not as
much a%out technology as they
are a%out engineering and
!rocess& and e have the same
issue e 3ust dis" cussed.
0ertainly ne technologies ill
!lay a significant role& 3ust as
air%ags did hen they ere
introduced in auto" mo%ile
safety& %ut the air%ag %y itself
doesn$t give you a safe ride.
'he safe ride comes from the
air%ag integrated intelligently
into the overall system>
understanding the threat model
and in" tegrating not only front"
%ut also side" curtain air%ags to
!rotect against the different ty!es
of threats that you face in
vehicles. 'hose advances on a sys"
tematic level are key to going
forard. 'hey$ll most certainly
involve ne tech" nologies& %ut
!rogress isn$t 3ust a%out ne
technologies.
(ith defense)in)de*th, you decide
what the ri+ht mechanisms are at
each layer in your stack for
*rotection
as well as detection and
reaction!
JH: Ho secure do you
think things are right no8
Ho secure is the /mer" ican
7homeland9 from !otential
soft" are security threats8
FP: #t goes to the very first
question that you asked. #f
the rong set of things ere
to come together& it ould
cause a real !ro%lem& and the
degree of damage ould
de!end on !re!aration. #n the
general #nternet !o!ulation&
the com%ination of something
like a )ero" day e*!loit& a very
high"s!eed !ro!a" gation
mechanism& and a destructive
!ayload could significantly
affect a su%stantial num%er of
!rivate ,0s. 'o the e*tent that
an organi)ation has de" fense"
in"de!th mechanisms %uilt
into their enter!rise
architecture& from !ro" tective
mechanisms at each layer of
the stack all the ay through
to detection and reaction
mechanisms& the enter" !rise
should %e a%le to do much
%etter. 6e must evolve to
have those mecha" nisms in
!lace& and again it should %e
more !roactive rather than
reactive. 0ertainly& the
enlightened enter!rises that
focus on defense"in"de!th
security are in much %etter
sha!e& %ut even there e have
a ay to go.
JH: 6hat current eaknesses
do you see in the area of
!erimeter"%ased secu" rity& and
also in host"%ased security8
FP: +rom time to time& you
see ar" guments come u! a%out
firealls get" ting in the ay
of conducting com" merce and
%usiness& so !eo!le ant to
eliminate firealls and 3ust
go ith host"%ased security.
0onversely& #$m sure you can
find similar arguments for
relying only on !erimeter"
%ased secu" rity. 'oday& the
a!!ro!riate a!!roach in my
o!inion is defense"in"de!th&
here you take a layered
a!!roach and don$t de!end on
any single mechanism. 6ith
defense"in"de!th& you decide
hat the right mechanisms are
at each layer in your stack for
!rotection as ell as detection
and reaction.
JH: 6hat role does softare
diver" sity !lay in our nation$s
security8 #n other ords& does a
single o!erating system$s
dominance !lace our national
cy%erinfrastructure at risk8
FP: Monocultures in any environ"
1 IEEE SOFTW ARE ... 'computer 'or/$so0t.+r e
Q#A$I%& %I'
1 "
*+ y$ , u - e 200% IEEE SOFTW ARE
ment are less than com!letely
desira%le& %ut you have to
counter%alance that ith
!ractical realities. 6e$re in an
en" vironment today here the
ma3ority of deskto!s are
6indos"%ased deskto!sD there
aren$t as many Macintosh"
%ased or =inu*"%ased deskto!s.
+rom an o!" erations
!ers!ective& it$s something that
e have to deal ith and !ut
the a!" !ro!riate mechanisms
in !lace. 0er" tainly& :having a
single o!erating sys" tem; does
make it easier to have a
%roader im!act more ra!idly if
some" one com!romises or
!enetrates the de" fense"in"
de!th structures.
JH: #s security a real
system at" tri%ute or an
emergent !ro!erty that is
conte*t& time& and environment
%ased8
FP: #t really is an attri%uteD it
has to %e a fundamentally
%uilt"in attri%ute to the system
through the hole life" cycle
!rocess that e$ve talked
a%out. Bou can$t count on
serendi!ity to have it emerge.
JH: 6e kno that many&
most& or may%e all security
issues today arise %e" cause of
im!lementation errors that
make systems vulnera%le to
certain at" tacks such as %uffer
overflos. 6e also kno that
most of the !rograms e use
have %ugs& %ut are all security
!ro%lems related to %ugs8 #n
!articular& if e man" aged to
make !rograms that ere error
free& ould e there%y get rid of
all our security !ro%lems8
FP: #t de!ends on ho you
define %ug. #f you talk a%out it
in the conte*t of %uffer
overflos& those are im!le"
mentation !ro%lems>for
instance& not doing the
a!!ro!riate %ounds checking&
or not testing to discover that
someone failed to do the
a!!ro!riate %ounds checking.
0onversely& you can find e*"
am!les of security !ro%lems
here the im!lementations
ere high quality. +or
e*am!le& look at the security
!ro%lems :e had; in early
A2C.11 ireless tech" nology
ith the %roken 6ired
Equiva" lency ,rotocol& and
the correction of those
!ro%lems in 6i"+i ,rotected
/c" cess and the 'em!oral Key
#ntegrity ,rotocol& hich are
secure from the ground u!.
#$d call that a design"time or an
architecture"time issue. #t$s a
different
class of !ro%lem than
im!lementation !ro%lems such
as %uffer overflo. Un"
fortunately& you have to have
everything right to have a
secure im!lementation.
JH: +inally& are there any
questions that you thought
our readers ould ask that
e did not8
FP: 'his :security and
quality; is such a %road to!ic.
'here are !ro%a%ly a mil" lion
questions across the s!ectrum
in" cluding ones a%out identity
and !rivacy. 'hose are
im!ortant issuesD they$re not
the same as security& %ut they
have many !arallels in our use
of netorked infor" mation
technology. ,rivacy issues
are very significant today& and
it$s going to take some time for
our society to ork through
these issues.
Acknowled+ments
(e thank the many
individuals from +ov)
ernment, industry, and
academia who su+) +ested
e,cellent -uestions for this
interview as well as security
e,*erts to interview! (e thank
.harlotte and John /auss for
su++estin+ Frank Perry as a
*ossi"le interview candidate!
Jane Huffman Hayes is an
assistant !rofessor of softare engineering
in the 0om!uter -cience 4e!artment at the
University of Kentucky. 0ontact her at
hayes@cs.uky .edu.
Nancy ickelmann is a
4istinguished Mem%er of the 'echnical
-taff at Motorola =a%s. 0ontact her at
1 "
*+ y$ , u - e 200% IEEE SOFTW ARE
nancy. eickelmann@motorola.com.
! Ashlee Hol"rook is a ,h4
student in the 4e!art" ment of 0om!uter
-cience at the University of Kentucky. 0ontact
her at ashlee@uky.edu.
+or more information on this or any other
com!uting to!ic& !lease visit our 4igital
=i%rary at .com!uter .orgE
!u%licationsEdli%.
How
How
to
to
0each
0each
#s
#s
(riters
+or detailed information on
su%mitting articles& rite for our
Editorial .uidelines
Fsoftare@com!uter.orgG or access
.com!uter .orgEsoftareEautho
r.htm.
$etters to the ditor
-end letters to
Editor& #EEE -oftare
12HHC =os 5aqueros
0ircle =os /lamitos& 0/
@2IC2
softare@com!uter.or
g
,lease !rovide an email address or
daytime !hone num%er ith your
letter.
1n the (e"
/ccess
.com!uter.orgEsoftare for
information a%out #EEE -oftare.
Su"scri"e
5isit .com!uter .orgEsu%scri%e.
Su"scri*tion .han+e of Address
-end change"of"address requests for
maga)ine su%scri!tions to
address.change@ieee.org. Je sure to
s!ecify #EEE -oftare.
'em"ershi* .han+e of Address
-end change"of"address requests for
#EEE and 0om!uter -ociety
mem%ershi! to
mem%er.ser vices@ieee.org.
'issin+ or 2ama+ed .o*ies
#f you are missing an issue or you
received a damaged co!y& contact
hel!@com!uter .org.
0e*rints of Articles
+or !rice information or to order
re!rints& send email to
softare@com!uter.org or fa* K1
I1L AC1 L212.
0e*rint Permission
'o o%tain !ermission to re!rint an
article& contact the #ntellectual
,ro!erty ?ights (ffice at
co!yrights @ieee.org.
1 "
*+ y$ , u - e 200% IEEE SOFTW ARE