“We’ve just traced the attack... its coming from inside the house!” How do you secure your network when the bad guys already have control of your servers? It’s so hard to keep up with the attacks, maybe it’s safer to architect with the assumption that you’ve already been breached. What does this entail?
Wednesday, February 12, 2014
Top 5 ways organizations fail at managing third-party risk
Those blasted third-parties! Turns out they’re to blame for Target's mishap.
Well, guess what? We all know you can’t outsource the blame and Target is taking the hit for not managing their third-party risk very well. Having spent the past 6 years as one of those blasted third-parties (and before that about the same amount of time as someone who audited third-parties for banks), I can tell you there are right ways to do this and wrong ways.
BTW, if you’re a PHB and prefer the “business friendly version” of this post, just read this article I wrote last summer for the financial industry.
So in my years of auditing and being audited, I have seen many many many irrational and ineffective choices made by auditor and auditee. One of the worst cases (there are so many to choose from) as an auditor was when I assessed a third-party servicing the banking industry in downtown Manhattan who refused to answer any of my questions. They failed and did not get the contract…. despite their belief that they would despite what the audit report read. Hmm.. then there was that third-party we convinced to get out of the financial services industry because they security was so bad. Sigh, sweet memories.
Oh, where was I… yeah, on with my rant list:
1. Wrong-fit assessment for the organization
If your third-party has direct physical access to your internal network, then a five page spreadsheet questionnaire is not going to tell you enough. If the company is producing software that is essential or is counting the money, then yeah, the audit should include some secure development practices. If the company is a cloud provider or a hosting company, you probably need to include audits of disaster recovery and physical security. These all seem obvious, but I’ve endured thirty page questionnaires and hours of grilling about things that were most “not applicable” for our organization, while other more important issues were left wholly unexamined.
2. Over-reliance on the wrong certification
I’ve written about this a little bit before, but this is really a variant of #1. The easiest miss I’ve seen is asking for PCI certification from companies that don’t process credit cards. If you followed the letter of the rule for PCI and you don’t have credit cards, it’s a pretty low bar to jump over. If you can’t tell the different between SSAE-16 SOC-1, SOC-2 or SOC-3, then don’t use them to rate your third-parties.
3. Sloppy scoping
The scope is where you begin, not an afterthought. You need to understand what data and dependencies the third-party is responsible for and where the heck they are. Two times out of three, the third-party does not even fully understand this. You can’t do a risk analysis if you don’t what and where the assets are. You surely can’t do a useful assessment. And once the scope is established and verified, then you can start looking how hard the boundaries are between the in-scope and out-of-scope areas.
4. Fire and forget
Most organizations can’t afford to review their third-parties more than once a year. Some only doing once every three years. That means that for one or two days out of 365, things are being looked at the third-party. How effective is that? This why I push for Type II audits which cover at least six months of assessments, and are often “rolling” so the review is constant. I also like weekly or even daily vulnerability scans for IT posture assessment. Threats change, infrastructure changes, compliance needs changes. Review should be as ubiquitous as it can be.
5. Lack of assessor skill
If the person doing the assessment doesn’t understand everything we’ve mentioned up until now, they’re not skilled enough to do the assessment. A lot of folks doing third-party audits on behalf of large organizations are just business dev people with checklists that they submit back to infosec for review. Fail. A good auditor also knows when a control is appropriate and a risk acceptable, which is why I always prefer working with knowledgeable experienced people than clueless newbs who ask all the wrong questions.
That’s it for today. Maybe later I’ll list how I think you should do this right.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment