Feb 23 2010 4:17AM GMT
Posted by: David Schneier
Regulatory Compliance,
GLBA,
SOX,
PCI,
Audit,
Vendor Management,
risk assessment,
disaster recovery,
bcp
Here’s me about to eat crow.
After nearly a decade of railing against software as a solution to address the challenges of regulatory/industry compliance, I’m being forced to reconsider my position.
I’ve long advocated that an institution or organization could just as easily develop manual policies and procedures that would pass examiner/auditor scrutiny without having to spend additional money on a related software-based solution. I’d encountered too many instances where an application was purchased to automate the related steps and it either fell short, was too complicated or was really designed to do something else and was poorly retrofitted just so the vendor could pursue a new market.
But my experiences this past year have revealed another side to this story that I hadn’t really considered. In the spirit of full disclosure, I need to share with you that my company has developed a regulatory compliance solution and I’ve been heavily involved in its design and development. Because of this experience and because of the myriad conversations and meetings I’ve participated in, I have a new found perspective on all of this.
First and foremost, it turns out that the foundation of my bias was formed on solid logic. Many of the solutions that started popping up nearly a decade ago were born from desperation as an endless number of vendors watched their Y2K-centric solutions pushed to the edge of extinction as the new millennium came and went. Many of these products morphed into network utility-ish software, some reinvented themselves and created a new market (e.g. portfolio management) and many others unfortunately died from the effects of irrelevance. But some languished on the sidelines, barely existing and surviving on small crumbs of opportunity.
Then along came SOX and PCI and suddenly there were new revenue stream opportunities. Vendors rushed to reinvent their products by re-branding, adding some cosmetic enhancements and the full force of a marketing campaign. As I encountered many of these solutions out in the field, I formed a bias because so many of these “solutions” weren’t really solving anything, at least not the way they promised they would. After developing less expensive and more effective manual compliance programs, I decided that was the better way to go.
But I sort of threw out the baby with the bath water. What I didn’t consider were solutions that were designed by people who understood the purpose of the exercise and knew where and when to automate. I hadn’t encountered very many, if any at all, that I felt were tightly aligned with the work that really needed to be done. Those that I did like were often bloated, complicated and required a more advanced skill set than most of my clients possessed (e.g. disaster recovery). At some point, I stopped even paying much attention to the details and more or less put all of them into a single category.
This past year, though, has served as a slap upside the head. It turns out that there are some fantastic compliance-centric software solutions kicking around addressing a wide range of challenges that my clients are confronted with. In hearing from the banking community what they liked, what they didn’t like and more importantly, what they needed versus what they didn’t, they shared real-world examples based on existing products. It seems that some of the solutions I’d shunned since hanging my shingle in the banking sector years ago were making a difference for the better.
It didn’t take long to figure out what separated these vendors from the rest of the pack though. Most of them were run by people who understood the underlying business drivers that created the market. They also understood the behaviors of the user community and how they’d use the software. Perhaps the most notable trait was that they were almost laser-like in what requirements they addressed and how that fit into an institution’s overall framework. They were designed to address specific needs and solve specific problems. They didn’t just solve part of a problem, they solved the entire problem, all of it with one well-designed solution.
Before recommending that anyone run out and purchase a “silver-bullet” solution to appease their examiners, I offer the following advice:
- Know what you need a product to accomplish in order to meet regulatory demands.
- Qualify a solution based on real results from recent customer experiences; did the software live up to expectations?
- Test the vendor’s knowledge of the related regulation and gauge the depth of their expertise in complying with same.
- Find out what the examiners thought of the solution. While they won’t endorse a product/solution they are quick to let an institution know when they like something.
- Be realistic in terms of how much effort is required to get a product installed and running right. Even the best software needs to be populated with data and that takes time.
As for the possibility that this post may be perceived as self-serving, I would share with you that when conducting audits and assessments, I still advocate using manual programs to address gaps and deficiencies. Oh and another thing, don’t get used to my admitting I may be wrong; it’s a very rare event indeed.
Feb 12 2010 11:38PM GMT
Posted by: David Schneier
Regulatory Compliance,
Audit,
NCUA,
GLBA,
IT,
ITGC,
IT General Controls,
Information Technology General Controls,
infrastructure,
fraud,
corruption
I was reading the local newspaper this morning and was surprised to find a front page story ripped from the headlines of my professional life (ironic, I know).
Right there on the front page of today’s News and Observer was a story about how a recent audit claimed corruption at a local college (North Carolina Central University). I’m sort of trained in a Pavlovian sort of way to notice anything having to do with audit and so I gave it a cursory read. Cursory turned into focused when I reached the part about how the school’s chancellor Charlie Nelms called the report draft “sloppy” and went on to say that some of its harshest accusations might not be true.
One of the oldest tricks in the business book when it comes to audits is to start questioning the quality and veracity of reports that are perceived as not being favorable. Instead of focusing on the audits findings and trying to validate them (because a good audit is your best friend if you really want to do things right) the auditee goes into a series of tactical maneuvers to deflect attention away from the report’s contents and feigns disgust and outrage.
The school chancellor went on to say that, after firing the auditor who produced the report, he “ordered his staff to gather more information before he releases a final version to the public.” He went on to say that the “draft audit was so poor that he doesn’t trust it, and he does not want to damage the reputations of people who might not have done anything wrong”.
A few years ago, I conducted a risk assessment for a client with an odd configuration of infrastructure pieces that clearly defied anything close to typical, so it was difficult to measure them against the norm. Just the same, I tried. I took a step back after conducting all of my interviews and gathering as much information as was available and filtered it through the lenses of an examiner. I surfaced gaps and issues that were likely to be viewed in a negative light, explained why that was and offered clear and concise remedial steps. Senior management went bonkers (for lack of a better word) when they received the report.
They were outraged because the report was delivered a week late (which was true), they were insulted that there were typos (not factual errors, just a few grammatical/spelling hiccups which are common in draft versions) and charged that some of the issues listed were completely false. In summary, they called into question the accuracy and reliability of the entire report. It was startling for me because in my more than two decades working in the business world with more than 10 years conducting audits and assessment, I’d never had a client react anywhere near this way before.
But it was really more about using diversionary tactics intended to gain a negotiating advantage. Their end game was to soften the report’s contents so that it looked better when the examiners came back around; by pushing us back into a defensive position, they were almost successful. Fortunately, I’m stubborn when it comes to standing behind my findings and need incontrovertible proof that I was wrong about something before changing or removing things. I may not be the best auditor but I have well honed instincts around IT, the myriad processes necessary to support the infrastructure, and I know good from bad. I never put anything into my reports that doesn’t resonate with me and my peers (and typically the report’s audience).
So you can imagine where my head was at while reading the story today. Mr. Nelms also said, “I want to see the source documents, and I want to see the field notes from the audit, because I want it to be accurate. I don’t want it to be hearsay, because some of the allegations are just mind-boggling.”
Well that’s good to hear because any audit worth its weight in paper needs to be supported by solid work papers. But considering that he fired the auditor, I’m hoping someone in his office thought to secure that beforehand. And I’d need to understand why he’s gathering more information when all he really needs to do is use the work papers and have another independent auditor re-perform the tests.
Oh and another thing, who hired the auditor to begin with?
Also, now that the report’s findings are semi-public (it’s available despite not having been formally released), where’s the value in conducting a follow-up audit? Anyone involved with any alleged wrongdoings now has a clear roadmap in front of them on how to cover their tracks.
Here’s my thinking on all of this: The audit is likely somewhere close to 100% accurate but far from perfect (I know that’s a contradiction). If the chancellor was really interested in handling this properly, he’d quietly set about having independent people digging into the findings, not as a CYA exercise but simply to get to the bottom of things and deal with whatever is found. I’m not saying that where there’s smoke there’s always fire but unless Mr. Nelms can offer a credible explanation why he would think that the fired auditor would fabricate stories or offer poorly formed conclusions I’d have no choice but to question his position on all of this. I guess what I’m asking for is a credible explanation as to where the smoke is coming from and an explanation why he thinks it’s benign.
What I’d like is to hear the auditor’s side of the story. I’m betting that would be an enlightening conversation. But if Mr. Nelms was successful in his very public tongue lashing of this auditor, he/she will do anything and everything to avoid having their name outed. And so the diversionary tactics score another point.
And the best part of this? I almost never read the paper.
Feb 5 2010 3:57AM GMT
Posted by: David Schneier
Regulatory Compliance,
information security,
Security,
social engineering,
phishing,
phish,
security testing,
Audit,
risk,
risk assessment,
GLBA,
NCUA
Consider this post to be something of a (banking) community service announcement.
It’s February 2010, do you know when the last time was that your organization conducted a social engineering exercise?
I come across instances almost all of the time where financial institutions have obvious issues with regards to their staff and how they handle sensitive information. I almost always find non-public personal information (NPPI) left unsecured on desktops, in printer/fax queues and displayed on computer monitors. I can recall at least a half-dozen instances during the past year where I personally witnessed person-to-person exchanges where proper protocol was not followed in handling situations that are now supposed to be governed by the Red Flags rule.
It’s not hard to understand why these things happen; it involves human nature and that’s a wild card element that can’t be easily managed or controlled. People are busy, people are inherently trusting and in their haste to help a customer or get their work completed, they lower their guard. But it’s in those moments when good judgement is pushed to the side that an institution is most vulnerable.
A password is shared, a sensitive document is left exposed or a file loaded with account information is carted off on a USB storage device. Ultimately, how it happens is never really the big story though, at least not for those impacted by the breach. For the affected, it’s all about the damage, both potential and realized, that they’re confronted with. And of course it then also becomes about the tarnished reputation of the institution connected to the breach.
Do something about it.
Schedule a social engineering exercise; it’s easy, it’s affordable and it works. It tests the effectiveness of your security awareness program(s), illuminates what’s working and what’s broken, and allows you to adjust your training accordingly. And you can vary the angles taken from year to year. Start by seeing what happens when someone places calls to your staff trying to get them to share sensitive information. Follow that up by doing the same with emails. When you conduct your next internal vulnerability assessment, have the project include having the testing resources access secured facilities. You can also mix in dumpster diving (a favorite of mine), fax phishing and eavesdropping (don’t laugh, it’s a great way to skim NPPI and impossible to trace).
The results will prove to be revealing - both good and bad - and will serve as remarkably effective fodder for your next round of training. And the testing itself becomes an important tool because once people are aware that these tests are occurring, they begin to pay greater attention to their action. No one want to be tagged as being on the wrong side of the testing - trust me on this, I’ve seen this dynamic in play and it’s real.
Jan 27 2010 12:13AM GMT
Posted by: David Schneier
Regulatory Compliance,
FDIC,
Basel,
bank,
banking,
GLBA,
NCUA,
FFIEC
I was scanning through emails the other day and almost missed a good one. It was from the FDIC on Friday, January 22. As we’ve all come to know Friday is the FDIC’s equivalent of “bring out the dead day” when they almost always announce the most recent slate of bank closings, so I didn’t pay it any attention at first. But it was issued early in the day and the barrage of bad news announcements typically doesn’t arrive until sometime around Happy Hour (you decide for yourself if that’s coincidence).
And so I popped it open for a read.
It was an announcement about how the FDIC and the Bank of England signed an agreement (they called it a Memorandum of Understanding or MOU) to cooperate with one another in the dissolution of cross-border institutions. Forgive a compliance geek his potentially misplaced enthusiasm, but I thought this to be a neat and somewhat intriguing bit of news. The biggest banks all operate on a global level and I know from first-hand experience that in many instances they do so not so much to tap into new markets but rather to exploit competitive and legal advantages (think Switzerland and their very favorable rules). One of the distinctive advantages of doing business this way is that what might go wrong in one marketplace is often insulated from the rest of their organization, thus reducing their risk; you may blow up one business unit but legally it doesn’t expose the remainder of the company. But regardless of the reasons, what this business model almost always creates is the overly complex monolithic banking monsters that have commonly been thought of as “too big to fail.”
This MOU is an important step towards doing something to simplify the global banking world. It potentially lays the groundwork for the oversight agencies that are often responsible for cleaning up the mess made by the banking giants to have wider authority to do what’s necessary to protect depositors (and tax payers) from absorbing the brunt of the blow. It also is the first salvo resulting from the recommendations of the Cross-border Bank Resolution Group (which operates as part of the Basel Committee) headed up by my favorite banking superstar, FDIC Chairman Sheila Bair. You might recall that she railed against the concept of “too big to fail” and as a result of her involvement with this group put herself in the position to do something about it.
I’m not sure how much further this sort of thing will extend itself, being bit of a cynic when it comes to banking oversight on an international level. You see, back in 2008, I conducted a fairly exhaustive amount of research trying to identify the FDIC’s counterparts around the world and was amazed and dumbfounded based on what I didn’t find. Outside of the U.S. and UK there really wasn’t anything even close on a functional level. Sure there were some government agencies in place but their role and powers weren’t anywhere close to what we have here. And I was all the more amazed that despite having the Euro currency in place and an organization to oversee its management there really wasn’t a related banking oversight group. When you think about Europe and how it’s laid out and how simple and obvious it would be for banks to operate across borders, you’d think they’d be among the first to coordinate efforts but it simply wasn’t there. So what we have at this point is an important agreement between the two most mature and best- organized nations regarding banking oversight. But this one was relatively easy; what remains to be seen is how the rest of the civilized world addresses this issue.
I’m hopeful that in light of the mess the global economy has been in due to mistakes made in the banking industry, that the various governments will move to get on board quickly but there’s little in the way of historical precedent to make anyone think that’s likely. Still, with Sheila Bair involved, you never know.
Jan 15 2010 6:05AM GMT
Posted by: David Schneier
Regulatory Compliance,
Audit,
GLBA,
risk,
controls,
evidence
A recent jobs survey released last week indicated that less than 50% of the work force is satisfied with their job. Me, I’m a lucky guy as I genuinely like what I do for a living. It’s funny in a way because over the first decade or so of my career, I held people like me in very low regard; I just didn’t much care for or respect auditors.
One of the key considerations in sorting through the irony that’s my place in this world is that I’m nothing like the auditors I used to deal with in my application development days on Wall Street. What I audit, how I examine related controls and activities and review supporting evidence is heavily biased by my first-hand knowledge of the IT infrastructure. I understand technology and how it’s used, and so when I’m conducting fieldwork, I’m able to see things from a blended perspective. Most of the auditors I dealt with understood audit way better than they understood technology and so they’d ask question after question, not really knowing if the answers made sense, only if they matched expected results. For me, if the answer doesn’t make sense or is the wrong one, I immediately switch gears and seek out compensating controls because they’re often there if you know where to look.
Audit is heavy on my mind this week because I’m in the process of wrapping up a report for a client about the exit meeting. It’s interesting how the names and faces change from engagement to engagement but the script rarely varies. You’d think it would get old or boring but curiously it never does. The client never likes to see anything negative in print and it usually sets off a flurry of activity from report issuance to the first review meeting. There are almost always a series of requests to move things around, change the way things are worded and occasionally to reevaluate ratings. And I can’t recall a single audit where additional evidence wasn’t submitted for review after the initial draft was distributed to offset findings - artifacts that often have that “new car” sort of smell. But that’s actually a good thing and I’ll explain why.
An auditor’s job is to find control gaps and weaknesses. I’ve often compared what we do to fishing: You cast your line, see what you can catch, and keep at it until you either fill up your basket or have exhausted all available time and resources. Sometimes the bounty is rich and sometimes not so much. But there are always things to catch (I’ve never been shut out yet) even in the very best managed IT shops. The payout for the auditor is to identify legitimate issues that resonate with client. You want for those who own the controls to understand what the issues are and take swift action to remediate. I know some auditors take offense to after-the-fact evidence being provided because they perceive it as if though it’s implied that they missed something. Not me. When the client comes back quickly with viable solutions to make the findings go away, I consider that a bonus even if they didn’t exist a week earlier. That means that real risk is being further mitigated and managed and that’s the only reason to ever conduct an audit, in my opinion.
The client I’m working with, as it turns out, has fast become a favorite of mine. They’ve made great strides over the past year or so in enhancing their security posture and have gone a very long way towards putting in place effective controls to protect themselves, which ultimately results in their better protecting their customers. They take this sort of thing very seriously and as such, they have earned my respect. So when they come back to me with newly available information to offset findings in the draft report I’m happy to factor that into my findings. I did my job, they did theirs and in the end, the world is a little more secure.
So I guess I’m a minority on a couple of fronts: I’m more than satisfied with my job and I’m an IT auditor who genuinely understands the technology infrastructure. So much for there being strength in numbers.
Dec 29 2009 5:30PM GMT
Posted by: David Schneier
Regulatory Compliance,
business continuity planning,
Vendor Management,
information security,
GLBA,
Audit,
IT General Controls,
red flags,
red flags identity theft
When I sat down to write my last blog post for 2009, I was planning to write either about my predictions for 2010 or a retrospective of 2009. But that’s just so clichéd; everyone does that or tries to. And as I’d wrote in a recent post about the Verizon report on security threats, sometimes there’s not a whole lot that changes year-over-year and so my bold predictions for 2010 would likely look almost exactly like those I made for 2009.
Instead what’s on my mind isn’t so much a revelation or prediction but rather an observation.
When I first started focusing on the banking vertical a few years back, I was often depressed by how so many institutions did what they did because they had to and not because they viewed any inherent value in the exercise. Information security policies were dust collecting binders, business continuity plans (BCP) were a collection of basic documents that described what needed to be done but rarely provided direction on how to do it, and vendor management was typically just a spreadsheet with a some key data elements. Rarely did any of these artifacts provide real value or come anywhere near close enough to address the spirit of the regulations that required them to exist.
That’s definitely changing.
I’m currently working on two projects that deal directly with business continuity planning. For the first project, I’m rewriting a clients plan and taking it from the aforementioned collection of basic documents and remodeling it into an actionable plan that will allow them to use it as a road map to steer them through various types of business disruptions (they’re not all disasters, sometimes it’s just a power outage or a burst water pipe). They knew they needed to make changes to their existing plan and management saw the inherent value in having something that would actually drive the decision-making process when necessary and increase their chances of successfully navigating through a crisis. The second project is actually an IT general controls audit in which the project sponsor has requested increased scrutiny be placed on BCP related activities. They wanted to make sure that their plan was well designed and properly tested and would at least meet, if not exceed regulatory requirements. The amount of work their management team poured into the plan and its related activities was clearly reflected in the evidence I reviewed. They not only have a viable plan but have tested it from several entry points, have identified potential glitches and fixed them so that should they need to implement the plan, they have a high degree of confidence that it will work. Both of these projects underscore something that’s significant: financial institutions are embracing the value of complying with the regulations. Having a formal BCP is not just a way to make the examiners happy; it’s the best way to successfully manage the unexpected.
And this more than subtle shift has been noted in other key regulatory areas.
Vendor management has moved from a clerical exercise into something that’s more day-to-day, where contracts are being scrutinized and performance measured. We have an ever-growing client list on that front where they aren’t concerned about the regulators so much as making sure that they’re protecting themselves and their customers/members from unnecessary risks and exposure. We’re seeing it with Red Flags – Identity Theft and Incident Response plans where the banks and credit unions want to leverage the “have to” and convert it into something that helps them manage risk better. Regarding Red Flags, we’ve found that most institutions have their plans up and running but haven’t implemented it properly and are using it more as a Suspicious Activity Reporting (SAR) mechanism rather than the its intended use. But when we bring that up in our reports, the response has been refreshingly positive where management wants to get it right. That’s what’s different from previous years.
I’ve long advocated for doing it right as long as you have to do it and now it appears that management is coming around to embracing that idea. Perhaps that’s what 2009 will reveal itself to be in the rear-view mirror: The year when our industry matured from “have to” to “want to” when addressing information security. A year when it wasn’t about having a board-approved document but rather a viable plan or program. Now, that would have to be considered a good year.
Happy New Year. May it be a good one filled with an improved economy, fewer breaches and an increase in management oversight.
Dec 11 2009 5:29AM GMT
Posted by: David Schneier
Regulatory Compliance,
Security,
cyber security,
Audit,
compliance,
threats
I just finished reading through the most recent report from Verizon Business, which offers a deeper dive into the most common security breaches identified during 2008 and quite frankly, I’m concerned. Turns out that there’s very little new to worry about beyond what we already know - and that concerns me greatly.
I am a bit relieved that the threats we already know about are still pretty much those that we’re dealing with; we know how they happen, why they exist and what to do about them. But that’s also why I’m worried.
If we know about these threats and have at our disposal a wide range of techniques and tools to prevent them, why are they still finding any measure of success?
For example, take a personal experience I had while using Facebook. Shortly after becoming an active user on the popular social networking site, I fell prey to a virus delivered by way of a URL that presented itself in the form of a video link sent from a friend. The link appeared suspicious and though I attempted to close the message without clicking on the link, something went awry and I navigated right into the steely, sticky jaws of a truly annoying virus. Fortunately, I was able to clean my machine and irradicate the virus eventually (many thanks to Trend Micro for some pretty good software on that front). But the experience served as a booster shot of sorts for my overall online strategy. Now, I won’t even open a message unless it presents itself correctly (e.g. proper spelling, contextually appropriate, etc.). It took me all of one bad experience to realize I had to use the same level of vigilance on Facebook as I did in the rest of my digital world.
In other words, I learned the lesson and have taken steps to not make the same mistake again. Why can’t the business world do the same thing?
Of the threats detailed in the Verizon report, the vast majority can all be addressed via proper system configuration and basic monitoring techniques. We’re not talking rocket science here. And the remaining threats - the ones involving the human element - can be greatly reduced by proper and consistent security awareness training. Honestly, if I can get my almost octogenarian mother to screen emails and only open those that come from trusted sources, I’m thinking corporate America can train its employees to do the same. If I can educate my wife on the dangers of skimming and give her the basic tools necessary to avoid suspicious ATM’s (e.g. only use bank-branded devices in well lit areas; always cover the keypad when entering PIN’s, etc.), I’m certain financial institutions can do so with their customers.
The criminal element can be a pretty sharp group and are always, always thinking of new ways to get to other people’s money. Why make it easier for them by leaving the same doors unlocked and windows opened? As I’ve already pointed out, it’s good that we have identified the threat but it’s not so good that we haven’t done enough to stop it.
And here’s a neat little addendum: I wrote this post earlier today while traveling and when I returned home this evening and sorted through my mail, I found a brochure for the SANS event scheduled for March, 2010 in Orlando. While flipping through the pages, I saw session after session all aligned quite nicely against the threats detailed in the Verizon report. Again, successfully dealing with this ain’t exactly rocket science.
Dec 1 2009 1:49AM GMT
Posted by: David Schneier
Regulatory Compliance,
bank,
banking,
PCI,
PII,
FDIC,
credit card,
social security numbers,
routing number,
checking account,
identify theft,
online fraud
I want to play a game with you, sort of like the compliance equivalent of the Rorschach inkblot test. I’m going to throw out a phrase and I want you to write down the first acronym that comes to mind.
Ready? Here we go……
1) Credit card numbers
2) Social security numbers
3) Bank account information
I’m betting most of you came up with the following answers:
1) PCI
2) PII
3) ?
I’ve been fascinated for a few years now as a regulatory compliance professional about how little attention one of the most significant risks remaining in the digital world receives anywhere in my industry. Everyone has gone absolutely nuts when it comes to credit card numbers. There’s a significant groundswell around personally identifiable information as is evidenced based on the growing number of state laws being passed to oversee such things. But try and find anything in the pipeline seeking to protect your bank account information in the public domain and there’s “ “ (aka crickets).
Earlier this month we celebrated a milestone event in our family and a fair number of gifts we received were presented in the form of personal checks. I had in my hands full name and addresses, bank routing details and individual account numbers from dozens of people at my disposal to do with as I pleased. And while I was honorable and simply deposited them (for some of my friends I apparently did so a little too quickly) the potential for fraud was huge. Consider that of the nearly two dozen companies I conduct business with each month (e.g. mortgage, car loans, utilities, etc), more than two-thirds accept online checks in lieu of credit cards. If you’ve never paid via an online ACH payment or check, all you need to do is provide the bank routing number (got it right there on the check), the individual bank account (got that too) and on occasion the name of the institution (but again, you have that right there in front of you). Really when you boil it down to bare essentials, it’s somewhat the equivalent of giving someone your credit card information on a piece of paper that than gets circulated through multiple touch points before it is completely processed.
It’s insane, it’s unnecessary and most of all it’s unacceptable, and I’m betting it’s the next big information security flashpoint in the banking industry.
One of my colleagues considers checks to be archaic and thinks they should be eliminated altogether. Another suggested that they should be protected exactly the same way credit card numbers are being handled these days courtesy of the PCI standard. I was thinking of something a little simpler to start with. Why don’t they simply eliminate printing the routing and account details and rely exclusively on barcode technology as a Phase 1 sort of exercise? It’s an embedded technology and while far from tamper-proof it would certainly eliminate the biggest exposure currently in existence. I’d like to think that my money is a little harder to access than by my simply writing a check to a local service company and having someone in their office copy down the details and use them to make an unauthorized purchase. It’s not likely they’d have a barcode reader and so that would be the first logical step to take.
But whatever steps the industry takes to remedy this problem, one thing’s certain: Something has to be done. At this point in the evolution of identify theft and online fraud, it’s not as if the oversight bodies can claim ignorance. They know that the criminal element continually pursues the lowest hanging fruit, and right here and now the exposure provided courtesy of the printed bank check is just about dragging on the ground.
It’s time for the industry to change and hopefully before this reaches epic proportions. Because if bank customers become afraid or reluctant to use personal checks as a method of payment, it’s going to become a huge problem for commerce in general. Considering where our economy is at the moment, I doubt we can easily withstand such an event.
Nov 12 2009 1:44PM GMT
Posted by: David Schneier
Regulatory Compliance,
GLBA,
Audit,
compliance,
information security,
business continuity planning,
Vendor Management,
CISO,
ISO,
information security office
I was talking with a client last week about a perceived gap in their organization. Despite having to address multiple regulations cutting across several oversight bodies, they were lacking a single point of contact or central coordinator for all information security related activities. Their sense was that they were long overdue for some form of a chief information security officer (CISO) and I had to agree.
The same point was underscored earlier this week during a kick-off meeting with a client regarding a pending audit. Almost all of the requests for information, including policy and procedure documentation were redirected to their most senior IT person. As we were wending our way through the items on the list and they kept verbally pointing to the IT person, I started wondering how he could be responsible for all of these information security related items and perform his regular IT duties. The answer of course is that he can’t, not effectively anyway.
There’s a discipline involved with regards to regulatory and industry compliance that requires someone be committed to both understanding what needs to be done and then making sure that it’s happening. This isn’t a new consideration; I’ve blogged in the past how we’ve moved from an age where you simply needed documentation to one where actionable steps are required. It’s not enough to have an information security policy in place, you also need to comply with it and then be able to prove that fact upon request. You can’t talk about how you restrict access to systems and information and not be able to provide a recent access review/report.
I’m routinely amazed by how few of my clients understand the growing need for the role of a CISO despite their awareness and sensitivity to the increasing regulatory burden. Many financial institutions will offer up that they have a BSA officer and some will introduce a compliance “person” who is almost always focused on AML/Patriot Act activities and not much else. I’ve interviewed several dozen people over the years who were included in the audit or assessment process because I asked to speak to their head compliance person and it turned out that they had very little if anything at all to do with information security and GLBA-related activities. How is that possible?
How can you expect someone who is an expert in technology to to also be an expert in information security and GLBA?
The answer is obvious, you can’t. First, there’s a very real conflict of interest in asking the person who owns many of the required controls to also monitor themselves. Second, I’ve yet to meet a technology person in all but the largest institutions who didn’t end the day with more to do than when they started it. Third, it’s very unlikely that a technologist will interpret and apply the myriad rules around information security for all in-scope regulations and apply them correctly. I’ve been doing this sort of work for more than a decade and it’s a full-time job just keeping up with the changes let alone figuring out how to properly comply.
There needs to be an assigned gatekeeper for information security, plain and simple. And the size of your institution doesn’t matter. I’ve worked with very small financial institutions (under $100m in assets) that had a single, non-IT person in charge and it worked out quite well. In one case the individual was also responsible for business continuity and vendor management, which oddly enough isn’t so odd. Both of those require a certain degree of expertise that exceeds what you’d expect a technology person to have and more importantly, both of those activities need to cover the entire organization, not just what runs on the network. When I worked within the technology infrastructure, I never understood why these things always got dumped there and now that I’m on the other side of things I know that it doesn’t make sense.
When the examiners or auditors ask to speak to your CISO, ISO, head security person, compliance officer or compliance manager, you need to have a name to give them not some vague answer or explanation about how it’s done piecemeal. This is 2009 and the demands of compliance are great and they’re real. Ignoring the obvious or incorrectly assuming that this is a part-time job is no longer acceptable.