I hate to start a random definition thread, but Ben asked me a good question and I'm curious if anyone else sees this matter in the same fashion that I do. Ben asked why I refer to software security as similar to artifacts identified by emergent behaviors:
> > Software security is an emergent behavior that changes over time > > with software use, evolution, extension, and the changing threat > > landscape. It's not an art you get people inspired in. > > > You keep using that phrase - "emergent behavior" - and I'm not sure what > you mean. So one of the biggest challenges for me was communicating to any audience, and most importantly the business and developers, what "secure software/applications" means. Around 2000/2001 I was still fixated on artifacts in code and in QA and secure software == strongly typed variables with draconian input validation and character set handling (canonicalization and encoding types). Yet I continued to have problems with the word "security" when talking to business owners and developers about software. This is because you say "security" and business owners see sandbags blocking their figurative river of profits. Corporate and gov developers see sandbags stopping them from going home and having dinner with the wife or playing WoW. Startup developers just laugh. I started using phrases like "predictable and dependable software" instead of security. Giving examples of "Rob's Report" -- it has all these user requirements it must meet to pass on to UAT, and if it fails, blah blah. SQL injection is a failure of degree, and not of kind. Same kind of failure as a type-mismatch error that stops the report from running -- but huge difference in degree of impact. Finally it dawned on me folks latch on to this secure software stuff as features and requirements, anyone using waterfall gets drowned in insecure software due to forever-pushed-back security "features". My experience also was that never, ever, is a Production app deployment identical to dev regions, let alone QA stages, UAT, etc. >From a security posture: prod might be better *or* worse than the other environments. Yet even worse -- sometimes I'd test app A and app B for a company, and they would both fair well when tested independently. I'd come back a year later and the company would have bolted them together through say some API or WS and now, together, apps A and B were really weak when glued together. Usually this was due to interfaces handling I/O that they weren't intended to. Long and short of it -- it struck me that security is a measure of behaviors. It is one quality of an application, like speed/ performance, but this quality is measured by the observed behaviors, regardless of what the source code, binary, or blueprint tells you... Note -- I am not saying any of these things are not valuable. There's things I'd still far rather find in source than black box, and things binary tracing is brilliant at. I'm simply saying that at the end of the day, the "proof in the pudding" is at run-time. The same way we perform the final measure the quality of commercial jets: I don't care about tensile strength exceeding tolerance standards if the wings are falling off at run-time. If someone compromises 1000 customer accounts, steals their prescription data, and tells the zoloft folks who is buying prozac so they can direct-market (real world example): you have a defective application. Those behaviors are always emergent -- meaning they can only ultimately be measured at runtime in a given environment with a given infra and extension (like plugging app B into app A through some wonky API). Sometimes it's the *caching* layer that allows you to insert control characters that lead to compromising the rest of the application, soup to nuts. You won't find any hint of the caching layer in source, in binary, in blueprint, in conversation with the devs, in dev or QA regions, in staging and UAT, or by running your desktop or network VA webapp scanner unauthenticated on the entry portal. You might find it in documentation, or during threat modeling. You will find it when you start measuring the emergent behavior of a piece of otherwise well-vetted software now sitting behind a weak caching layer and you start observing wonky caching/response issues and realize these behaviors are weak; you can attack them.... 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. This now fits back to the whole ideology discussion that is sorely needed and overdue. -- Arian Evans software security stuff _______________________________________________ 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. _______________________________________________