Re: [SC-L] informIT: software security zombies

[Gary McGraw]

hi kevin,

I completely agree that bugs and flaws exist as two categories (with a
slippery slope between them) outside of security.  It is important that we
focus on both kinds of defect since the narrative in software security has
mostly been about the bug parade. (See Getting Past the Bug Parade
 (September 17,
2008)).  

In my experience, there seem to be three kinds of categories that flaws
tend to clump into:
* flaws on "the list" (see STRIDE...or your own list of historical flaws)
ex. attacker-in-the-middle attacks
* ambiguities in the specs (here I agree with your assessment of #2)...I
think that errors of omission go here FWIW
* problems with dependencies (lots more of these in Framework-land than
there used to be)

Requirements would be nice.  Sadly, not enough software products actually
use requirements even though the people in Pittsburgh would like us to
pretend that they do.  (Your mileage may vary, etc.)

gem

On 7/21/11 10:40 AM, "Wall, Kevin"  wrote:

>Gary McCraw wrote:
>> This month's informIT article covers the zombies:
>[snip]
>> * Software security defects come in two main flavors‹bugs at the
>>implementation level (code) and flaws at the architectural level (design)
>
>So, two questions:
>1) How is this (software *security* defects) different than any other
>software defect?
>It seems to me that these are also 2 main categories of software
>defects in general.
>
>2) In terms of "flavors", where do you see software security defects
>arising from either incorrect
>requirements or simply lack of specifications?
>
>My experience with #2 is that poor specifications are a major contributor
>to software
>security defects, more so even than with software defects in general.
>That's because generally
>these specs are usually considered "non-functional requirements" and they
>get missed
>more by systems analysts simply because they are not something that the
>business
>wants and therefore they aren't put into the reqts and thus never get
>built.
>
>I'm not talking about the pseudo-PCI-like requirements that says things
>like making
>sure that you have no OWASP Top Ten vulnerabilities, but rather actual
>omission
>of requirements such as failure to specify that data must be kept
>confidential,
>or to access this data requires authorization by a certain role, or that
>an audit
>trail must be required for certain actions, etc.
>
>I don't see how you can chalk these sorts of defects up to flaws at the
>architecture level (unless you and I have drastically different views of
>system architecture). The are outright omissions in the specifications
>and because they are not there, the application team never even thinks
>about building in that functionality.  Bottom line: I think you are
>missing
>a "flavor".
>
>Thanks,
>-kevin
>--
>Kevin W. Wall   614.215.4788   Qwest Risk Management / Information
>Security Team
>Blog: http://off-the-wall-security.blogspot.com/
>"The most likely way for the world to be destroyed, most experts agree,
>is by accident. That's where we come in; we're computer professionals.
>We *cause* accidents."-- Nathaniel Borenstein, co-creator of MIME
>
>
>This communication is the property of Qwest and may contain confidential
>or
>privileged information. Unauthorized use of this communication is strictly
>prohibited and may be unlawful.  If you have received this communication
>in error, please immediately notify the sender by reply e-mail and destroy
>all copies of the communication and any attachments.


___
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.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___

Re: [SC-L] informIT: software security zombies

[Wall, Kevin]

Gary McCraw wrote:
> This month's informIT article covers the zombies:
[snip]
> * Software security defects come in two main flavors—bugs at the 
> implementation level (code) and flaws at the architectural level (design)

So, two questions:
1) How is this (software *security* defects) different than any other software 
defect?
It seems to me that these are also 2 main categories of software defects in 
general.

2) In terms of "flavors", where do you see software security defects arising 
from either incorrect
requirements or simply lack of specifications?

My experience with #2 is that poor specifications are a major contributor to 
software
security defects, more so even than with software defects in general. That's 
because generally
these specs are usually considered "non-functional requirements" and they get 
missed
more by systems analysts simply because they are not something that the business
wants and therefore they aren't put into the reqts and thus never get built.

I'm not talking about the pseudo-PCI-like requirements that says things like 
making
sure that you have no OWASP Top Ten vulnerabilities, but rather actual omission
of requirements such as failure to specify that data must be kept confidential,
or to access this data requires authorization by a certain role, or that an 
audit
trail must be required for certain actions, etc.

I don't see how you can chalk these sorts of defects up to flaws at the
architecture level (unless you and I have drastically different views of
system architecture). The are outright omissions in the specifications
and because they are not there, the application team never even thinks
about building in that functionality.  Bottom line: I think you are missing
a "flavor".

Thanks,
-kevin
--
Kevin W. Wall   614.215.4788   Qwest Risk Management / Information Security Team
Blog: http://off-the-wall-security.blogspot.com/
"The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We *cause* accidents."-- Nathaniel Borenstein, co-creator of MIME


This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful.  If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy
all copies of the communication and any attachments.

___
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.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___

[SC-L] informIT: software security zombies

[Gary McGraw]

hi sc-l,

Some of us have been doing this software security thing for a long time (about 
15 years in my case), and it is easy to overlook basic ideas that we believe 
everybody already gets.  During Cigital's internal technology fair this year, I 
did a presentation on these basic truths which I have deemed "software security 
zombies."

This month's informIT article covers the zombies:
* Network security alone will not solve the computer security problem
* Security software is not software security
* The more code you have, the more security bugs you will have
* Software security practices should be integrated into the software 
development lifecycle (SDLC)
* Software security defects come in two main flavors—bugs at the implementation 
level (code) and flaws at the architectural level (design)
* Badness-ometers are not security meters
** Fix the (dang) software  <-- bonus baby zombie

If you've ever heard me give a talk over the last decade there is some very 
high chance that you've heard something about these zombies.  As we continue to 
grow the software security field, it's important that we make sure to cover the 
basics with new people and with our customers.

Speaking of customers, we have 28 openings at Cigital right now (and a staff of 
200).  We are on the lookout for experienced software security types!

As always, your feedback is welcome.

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
blog www.cigital.com/justiceleague
book www.swsec.com

___
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.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___