Poor Scoping Disastrous for Security
Tue, 04/14/2009 - 16:00
Topic Source:
Building security testing into your project lifecycle is one of those critical growing-up points for a business.
All enterprises must eventually accept that security is just one more part of software or system development lifecycle. Both designs and implementations must be reviewed, developers need security training and infosec teams need the power to veto go-live dates.
Lots of businesses have arrived at this point. But what often happens as a result is security gets siloed per project. The project scope determines where security people will see, where there is budget, and critically, where the incentive to fix the problems lies.
This means that the way that project siloes interact -- the reefs between scope islands -- are never in scope. And as we all know, scope is for project managers, auditors and security consultants. Hackers don't care about your scope.
Let's look at how scoping can create some pretty peverse outcomes.
Tue, 04/14/2009 - 22:40
#2
agree 100%
I remember doing a social engineering assessment for a USG AGENCY$ a few years ago. The 'scope' was that we could target anyone but the top 5 people. Problem was, the top 5 people were the most visible and well-known (and thus likely targets) in their employ.
But nooooooo, the AGENCY$ didn't want to even hear that as a possible risk -- indeed, in my outbriefing report, the Agency program manager for our job actually forced me to delete a sentence referencing the "incomplete" rules-of-engagement and warning that "these findings may not represent a complete or valid assessment of your ability to recognize or withstand social engineering attempts."
Unfortunately security assessments are requested by folks who think conventionally, and are uncomfortable dealing with the abstract/creative/unconventional.
Bottom line - Adversaries have no scope in probing you, we should have no scopes in probing ourselves.
Well-said.
Fri, 04/17/2009 - 12:40
#3
Heads up their arses...
Great article, metl.
Sounds like your clients have implemented Ostrich Risk Management 101 theory.
http://tr.im/j0Iy
:)
Makes you want to release ./reallyreallybadsport.sh burning the infrastructure/systems/apps from the outside in, concentric circles, onion layers.. 'wr erase' RELOAD>
...worrying more about industrial and nation-state backed terrorism of critical infrastructure... Race you to the SANs/NASs. How to take a telco down. How to screw with SCADA....