Tuesday, February 12, 2008

trust but verify

ok, so i was having this conversation w/ a buddy a few days back. we were talkin about baseball, and all the cheating and such. and then of course the superbowl came up, w/ the recent allegations that the pats cheated in previous superbowls.

the conversation covered a lot of ground, but some parts stuck out in my mind. for one, the whole history of drug testing and baseball. over and over throughout the saga, you have people with vested interests making decisions that they are in no way impartial about. the players unions can't tell us if it is ok to test for steroids, because they represent the people who would be using steroids for personal gain.

it's just like the NFL, where you have a team that was caught cheating already. then allegations come up that they cheated in the same basic way in a different circumstance, and the NFL commisioner and peeps are like "oh, we don't think it's credible"... i'm sorry, what? it isn't credible because they've already done something exactly like that? or it isn't credible because you don't want any bad press or feelings right before the biggest game of the year?

so we got to talkin about how to fix cheating in baseball. we ended up agreeing that the way to do it was to have a completely independent body who tested pro atheletes (in multiple sports) for drug use. indepent funding, management, etc. this would keep the organization from having conflicts of interest, and should insure the impartiality of the testing to both the players as well as the team management.

i think this situation ties in very nicely w/ an infosec situation i was just in...

so, one reason to get an external company to do a review or assessment of your security posture is to verify that your people are doing what they tell you they are doing. you trust them, but it doesn't hurt to have another set of educated eyes looking over the situation.

so what if your org uses outside contracters to do work? well, in my estimation, you do the exact same thing. you bring in a 3rd party contractor to verify what's going on. it is really funny to me how in the RW you end up w/ people in these situations worried about how the original business partner feels. this isn't personal. you're handing them a check. it isn't about their feelings, it is about the quality of the work.

anyway, i was out of town doing an assessment at a bank a few days back. the CISO of the company had been using a consulting shop for network and security services. they had a vulnerbility identified a year back, and the company stepped in to sell them a product and offer consulting hours to remediate the vuln. i get in there, and i'm looking at the diagrams, and i'm like "why is this thing here again?" it just isn't making sense to me. the more i dig, the funnier things get. it ends up w/ the consulting company refusing to grant me access to review the firewall policies, and a review of a text version of the supposed firewall config reveals that the issue which was supposed to be remediated were, in fact, still present. and beyond that, the scope of the issue had grown over the past year (via direct action from the consulting company).

so i delivered my preliminary report before i jetted out of town, and the CISO looked fairly unhappy.

some people might blame the CISO. shoulda been technically proficient enough to see the issue hadn't been fixed. well, i'd take the position that managing infosec is wayyy different than implementing infosec. i don't want my CISO to know how to implement sec... i want them to manage it, and trust me that i'm doing the job...

and i definately want them to verify the work that's being done...

No comments: