Research

Richard expresses a little shock upon discovering that SAS 70 audits don’t evaluate security. I’d be shocked if any service provider, or other organization for that matter, claimed to me a SAS 70 made them secure. As in I’d consider them totally fracking worthless. All a SAS 70 does is certify that a control works as documented. Kind of like Common Criteria (my other favorite puppy to kick). If you document a single control, a SAS 70 will certify it works as documented. Nothing more. A lot less if it’s a Type I; since the auditor just signs off on management’s assertion that the control works as management documented (cool, eh?). SAS 70 has nothing to do with security. For SOX some orgs are certifying using the COSO Internal Controls Framework, which is as close as you can get to a SOX audit. It works for that since they certify to the same standard used for the SOX audits. Sort of; it can be grey depending on the auditor. For security the best we have is the imperfect ISO 27001 and 27002. If nothing else, they’re a good baseline. I’d also ask your provider for their latest penetration test results from a third party. Really, none of these checklists prove you’re secure. But they are very useful tools in designing and evaluating your security program. Except SAS 70- at least where security is concerned. Share:

To be honest, this is just a signing statement and, from what little constitutional law I know, kind of illegal. Basically, when Bush signed a law into effect that prohibited warrantless reading of citizens email, he added a statement that said the feds can still read email without a warrant. Wacky, huh? Bush asserted the new authority Dec. 20 after signing legislation that overhauls some postal regulations. He then issued a “signing statement” that declared his right to open mail under emergency conditions, contrary to existing law and contradicting the bill he had just signed, according to experts who have reviewed it. Still, it’s fun to get all hot under to collar about it, and if they we start hearing about opened mail, we’ll know that we don’t live in a democracy. Anyway, original article here. Share:

Securosis is officially declaring February as the “Month of No Bugs”. This follows the trend started by HD Moore with the Month of Browser Bugs, then continued by LMH with the Month of Kernel Bugs, and now the Month of Apple Bugs. During the month of February no security researcher will release any vulnerabilities on any systems, giving IT departments and vendors valuable time to make a dent in their backlog of existing vulnerabilities to fix and patch. All cybercriminals will refrain from using any of their 0-day exploits and limit themselves to previously reported public vulnerabilities. “We feel that the Month of No Bugs will force improvements in information security by giving vendors time to create patches for existing flaws while allowing users to catch up on updating their systems.” Stated Securosis, “an additional advantage is providing security researchers a full month off to relax, recharge, and explore new hobbies or scan the Microsoft Robotics Studio for any back-door code from Skynet.” The Month of No Bugs will not release a bug on each day in February. Seriously folks, while I have tremendous respect for security researchers I think this “Month of” stuff is getting out of hand. HD started with hacks that disclosed a flaw without a direct path to remote code execution, but it looks like a number of the flaws released by LMH will come with working exploits. I’ve had positive discussions with him in the past, and think his heart’s in the right place, but this isn’t the way to make things better. As messed up as the industry’s disclosure approaches may be, dumping code isn’t the answer. One of my first posts was on the dirty little secrets of disclosure, and while there is sometimes a time and place for releasing code, this clearly isn’t it. Apple, or any vendor for that matter, that doesn’t respond well to reported vulnerabilities isn’t about to change their practices due to ending up in the crosshairs of a lone gunman (or even several), whatever their intentions. It’s only when the end users start getting hurt and either complain enough, or start switching to other products enough, that a vendor starts to think differently. It’s what moved Microsoft, and it’s what will move Apple when the time comes. Releasing code without reporting it to the vendor does little more than ga er attention and place end users at risk. I highly doubt it will change any vendor’s patching policies. This is turning into the cyber equivalent of a self-declared vigilante smashing everyone’s doors down while they’re away on vacation, leaving them as burglar-bait, to prove to them how weak their lock vendor is. Either that or handing out bump keys and instructional videos in the worst part of town and pretending that the lock vendors will get it all fixed before the bad guys watch the DVD and put it to work. I’ve never hidden that I think our disclosure process, if we can even call it that, needs serious work. And I’ve called some big vendors to the carpet more than once. But spending a month dumping exploit code is only going to make us end users less secure, and make it even harder to deal with those vendors. It might be the right intent, but it’s definitely the wrong approach. Share:

Yep, I’m usually late to parties. The holidays were pretty intense with various family events this year, so I blogged and worked less than expected on my vacation. I’ve also managed to come down with a nasty case of strep, which is an annoying way to start the year. Thus it’s only now, on January 2nd, that I can finally respond to Alex’s challenge/tag for my 2007 predictions. Let’s start with the 2006 recap: Some good stuff happened Some bad stuff happened Some things got better Some things got worse Everything else stayed the same Hmm, did I miss anything? Now for my 2007 predictions: Some good stuff will happen Some bad stuff will happen Some things will get better Some things will get worse Everything else will stay the same While I do think the end of the year can be a good time to reflect on the recent past and look towards the future, I also think we in the security world can’t always afford to make these arbitrary divisions of time. We live on a non-cyclical continuum that, vacations aside, doesn’t begin or end on annual or quarterly cycles (except for some of you on the vendor side, maybe). I think this cynicism is probably an artifact of working so many holidays as a paramedic or physical security guy (for the record, Xmas was usually slow, with a few tragic calls, and New Year’s Eve usually busy). Thus I’m using this arbitrary black line of the end of the year to remind you that there are no arbitrary black lines. Actually, there is one prediction I want to make for 2007. It isn’t about any markets, threats, or technology developments. In 2007 the job of a security professional will be neither materially more difficult, nor materially less difficult, than it was in 2006. My fellow bloggers, and my coworkers, have already done a good job of predicting specifics and I don’t see much to add. Threats, tools, and technology will change, but the net balance for 2007 will stay even. Sorry folks, you’ll still have job security into 2008… Share: