[SC-L] What is the size of this list?

[Brad Andrews]

Great points Karen!  We can't prove a program is "secure" in the same vein.

The danger I am spouting off about is the idea that we would solve the  
software security problem if we just take a more "scientific" or  
"mature" (or whatever) approach.  I think those can definitely reduce  
the risk, but I don't think it will reach the goal.

I am all for getting 50% of the way there.  That is a lot better than  
being 0% or even 25% of the way there!  I am just VERY concerned that  
if we try to sell management the idea that we are now taking a  
"scientific" approach (or whatever the term), we will end up with  
implied promises that will lead them to expect perfection, which won't  
come.  They will likely ignore all our disclaimers that we are only  
seeking a partial solution to what we can solve, at least in the  
current state of thinking.

Getting them to even take any action is a challenge in many companies,  
so some could argue my concerns are foolish.  I think they are  
important because you want to make sure any buy-in you eventually get  
expects the right things.  If you don't do this, you will end up in an  
even worse position down the road.

-- 

Brad Andrews
RBA Communications
CISM, CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI


Quoting "Goertzel, Karen [USA]" <goertzel_karen at bah.com>:

> Actually, we can't prove programs are bug free if by "bug" we also   
> mean all possible anomalous behaviours. My colleagues keep pointing   
> this out to me when I suggest that we should start leveraging the   
> computational power of computing grids to analyze complex software   
> the same way other researchers are using grids to develop models of   
> the natural world, the human genome, etc. They keep quoting that   
> bloke Kurt Gödel with his pesky little incompletness theorem as   
> proof that 100% complete analysis of software cannot be done.   
> Frankly, I'm beginning to think this is their excuse for not even   
> trying to get me to the 50%. But the point is, even if you can do   
> everything "right" in terms of building software to be   
> vulnerability-free and behaviourally-benign, you apparently cannot   
> achieve 100% verification that you've done so. Ergo, assurance can   
> never be 100%.