Arian J. Evans wrote:
What is secure software?
It is one quality of an application that can be measured
by the emergent behaviors of the software while trying to
meet and enforce its use-case in a given run-time environment.
Fairly new to the list so if I cover things discussed before or breach
some list standards here feel free to jump all over me.
What is secure software good discussion to help us set our sights on
where we need to go. Want to keep it grounded in the reality of today
though just a bit.
I think one of the problems we have in the security industry is secure
itself is a bad term. Somebody, somewhere can find a way to attack any
computer as long as it exists. I've often told folks I'm beginning to
work with that you could power off a computer, encase it in a block of
cement, dump in it the ocean to try to secure the data in it it and
Robert Ballard could probably located it and retrieve it for anybody
willing to pay for it and meanwhile it hasn't been very useful to you.
Even short of that drastic of a step, if users can use it, somebody can
attack it. Features themselves are double edged swords; del *.* or
sudo rm * can be useful commands or very dangerous ones. Even with
draconian input validation, users could mess up the integrity of the
data just by fat fingering input or selecting the wrong item in a pick
list or a disk controller going bad could cause garbage. Somebody
reading over a user's sholder can comprise the confidentially of the
data or listening to them at lunch time. (Ever want to know what is
going on at Microsoft just go to the opening day of any major science
fiction movie at any theater in the Redmond area.) Flooded network pipes
or cut cables can create DoS attacks. A user walking away from his desk
without locking the computer opens up non-repudiation issues. Secure
can be successfully attacked in too many ways and proven insecure.
I try to focus more on secure enough to do the job it needs to do in the
environment it will operate in. That adds a lot of complexity that is
difficult to deal with since it makes simple check lists less useful but
it can also simplify things. I've had experiences where we removed
security features because they were unnecessary for the application and
its environment. Had a design team engineer FT Knox to that could have
protected data for years when that data was going live on a public
website in less than 24 hours. They were rather surprised to have
security remove things that were way too costly for the nature of what
they were doing.
Just started as the security reviewer/lead on a new project yesterday.
Went into my standard introductions about how this is an ever changing
world and what passes as good enough today may be wide open tomorrow and
we just have to live with that fact. We don't have the time or budget to
fully inject security into their development life cycle at this time or
dive deep into their code but any improvement is still improvement. What
we do now will make them better on the next version or the next project.
(Have seen that happen in a big way with some of the teams we work
with.) We may have a larger budget next time or get more mileage out of
the same budget because of what they learn now. As is all too typical,
our customers get us engaged after the project is already in progress so
we can't inject security considerations from the beginning and help
drive the design or the application or the specifications. We do what we
can while in progress. It'll be better than it would have been without
When we are done, will it be secure? No, we couldn't ultimately achieve
that anyway but will it be secure enough for its intended use and
environment is the better question. Should be but even then I won't give
concrete answer. Based on what we know today it probably will be but
somewhere somebody may well be crafting that next attack that blows us
out of the water.
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.