Adversarial Machine Learning for Fraud Detection - How Can Organizations Benefit from the Pioneering Work of the NSA and Facebook?
<mobile banking are two vendor management program areas that have opened up a wide range of security issues, says the FDIC's Donald Saxinger. And in the wake of such high-level breaches like Citigroup and Epsilon, financial institutions need to look at their vendor programs, risk assessment plans and service level agreements carefully.
"Now with so many services out there, it's getting a lot more challenging," Saxinger says.
Saxinger, senior examination specialist with the Federal Deposit Insurance Corp., says vendor management programs are getting more scrutiny from regulators. With cloud computing, it's difficult for financial institutions to know where their data is, and it's hard to secure that data when the bank doesn't know where it's being stored.
Paying attention to the contract is essential, Saxinger says, because the cloud environment is still very new. "The contracts that you have with [new cloud providers] are changing. It's difficult to lock down and say 'This is really what a cloud contract is,'" he says.
With mobile banking, regulators would like to see an aggressive approach taken - making sure the software being used is properly secured. Mobile applications are quick to be marketed, and the thought of fixing any problems comes later on down the line, Saxinger says.
Managing breaches on a mobile platform becomes that much more confusing as well. It's not just the core service provider organizations are dealing with. "You have to deal with the network provider, application developers and network gateway providers," Saxinger says.
Security for cloud and mobile platforms needs to be addressed during the risk assessment phase. Once the decision is made, security aspects need to be placed into service level agreements. And then those agreements need to be monitored for compliance.
"It's up to the financial institution, through its strategies, policies, contracting and monitoring, to make sure all of these things work together as part of their overall objective," Saxinger says.
During this first part of a two-part interview with Information Security Media Group's Tracy Kitten [transcript below], Saxinger discusses:
Saxinger is the team leader and subject expert for the FDIC's Division of Supervision and Consumer Protection in the area of regulatory IT examinations. He serves as the lead developer of the FDIC's IT examination standards and procedures, IT examiner education, and IT examination oversight. He has authored or contributed to various regulatory policies such as third-party risk and outsourcing, business continuity, payment systems, authentication, identity theft, spyware, and other emerging technologies. He is also a member of the FFIEC IT Examination Handbook working group which publishes the interagency guidance and examination procedures for various IT, payment, and operational risk areas.
DONALD SAXINGER: All of the banking regulators, including the FDIC, look at the banks' vendor management programs very seriously. We started looking at outsourcing issues almost 40 years ago when the government issued the Bank Service Company Act, and we've been conducting examinations of our financial institutions, like in the area of IT, for almost as long. And one of those areas that we look at is the vendor management program. Back in 2004, we updated one of our handbooks on an interagency basis. Its part of the FFIEC IT Examination Handbook, and it's called "Outsourcing Technology Services," issued in June of 2004. It covers the basic areas of what we expect as regulators for the financial institutions to implement. It takes a risk management approach, and it says we'd like to see this process followed at a high level. There are four key areas: risk assessment, due diligence, contract issues and monitoring.
Risk assessment is all about the bank identifying the need for outsourcing and then justifying the decision. How does the bank's business plan need to outsource this function? What are the goals of this process that they want to outsource?
Due diligence is more about the process of selecting a specific service provider, making sure that that they can meet the goals that you've described in your risk assessment, making sure that they're the proper type of company for insuring the types of data financial institutions usually have, like sensitive customer information, and being capable of providing available services.
The third area, contracting, isn't just about a document, but from our perspective, it's the process to ensure that the business objectives, goals and expectations are all agreed upon. And the key area that we look at there are what are the service level agreements.
And, lastly, is monitoring. How do you monitor that relationship? Who does the monitoring? What do you monitor? For example, are you looking at the business health of the service provider, the compliance with regulations and compliance with the bank's own internal policies? How is their security posture? Essentially it's everything we'd want to see in the service level agreements. That's at a high level of what the regulators are expecting. That booklet that I mentioned, Outsourcing Technology Services, is used by examiners for conducting their exams. It's used by financial institutions to perform a self-assessment or a general health of their program. It's also used by service providers to find out what the regulators expect of their clients.
That's the main policy area, but there are also a couple of regulations that are out there. One of them comes under Gramm-Leach-Bliley, which is the Customer Information Security Standards. There are specific requirements in there for a financial institution to oversee their service provider arrangement and all of those areas I just covered that are in the handbook.
SAXINGER: First I'd like to say that I do see a lot of good examples in our financial institutions. Back in 2008, we made a new effort to place under management at one of the top areas that we look at in our examination programs. And we've been doing this for many years, so I would expect the life cycle to be mature in many institutions. But there are a few areas that we're seeing that are sort of emerging, so they're probably areas that we'd like to see a little more emphasis on. One of them has to do with payment systems. It's not exactly what you would think of as a service provider, but it covers the broader topic of third-party relationship. And we had issued guidance a couple years back on third-party relationships, which essentially says any third-party relationship should follow the guidance in our outsourcing guidance for risk assessment, due diligence, contracting and monitoring.
In the area of third parties, we have some new players in the payments arena. For example, under the new ACH rules, there are now intermediaries called third-party senders. It separates the bank from knowing who their ultimate originators are. And there have been a few weaknesses out there where these third-party senders have put the bank in a position of possibly being liable for fraudulent payments entering into the system or for some compliance risk.
Another area that we can address is the risk assessment process itself. It probably could use a little bit of improvement. As more and more technology is outsourced, we need to see a little bit more formality in the governance of how we do these risk assessments. For example, who is participating in the risk assessment? Is it the IT department? Is it legal? Is it the business unit managers? Who is responsible for the overall vendor management program? And what happens when some of these new technologies come across the table of the IT steering committee, or even just the CEO's desk, and there's no actual technology implemented? For example, take cloud computing or social media. You don't have to install applications; you don't have to change your infrastructure to start utilizing some of these services that are out there. And you could have somebody from your staff doing it without your knowledge.
Those are areas that are clicking in my mind right now. I do see some challenges as we outsource more and more for documenting all of these relationships, tracking and reporting. It's a challenge enough to do with just your one core processor, but now with so many services out there, it's getting a lot more challenging.
SAXINGER: Let me take a step back and say what I've seen in vendor management over time. Early on, we would see a file, a physical file, kept on each vendor, and somebody would be responsible for managing that vendor and possibly doing the financial review and reviewing the contracts, etc. And then as institutions acquired more and more vendors, they moved to something more like a small database or a spreadsheet to track all of these things. But as the situation becomes more complex in a financial institution, and you have more internal departments involved, you need to have a better methodology or a proven methodology for tracking and reporting all of these relationships.
One of the areas that I've seen is services to help you manage your services - sort of like a cloud-based vendor management program. That's one of the newest innovations I've seen as far as the cloud helping you with vendor management.
KITTEN: What challenges does the cloud pose when it comes to service level agreements and/or data ownership?
SAXINGER: The cloud has gotten pretty complicated as far as tracking what and where our data is. It's very difficult to be secure when you don't know where your data is. And as far as availability of your systems, it's really going to depend on what type of cloud you're implementing. Are you just implementing a web hosting system or are you trying to integrate some sort of distributed architecture into the cloud? The more complex of a system you're trying to use, the more it takes to evaluate your service level agreements.
For example, ensuring availability of your data, how do you know whether or not the cloud is really capable of providing you 100 percent up time? Is it a guarantee or is it a commitment? And we've seen some recent examples where cloud outages do occur, even though they may provide commitments 100 percent up time. The same goes for security. There have been a few instances where we've seen some cloud providers for data storage asserting that there is security, only to find out later that there really isn't security that they committed to. Specifically, for the availability issue, we saw that with Amazon where they had a regional outage. Some clients were able to work through and plan for that outage while other clients were completely lost on their systems, and some of them even lost data.
KITTEN: And how have you seen that evolve or change over the last 6 to 12 months? How are we improving? How are financial institutions improving in that arena, or are they?
SAXINGER: With cloud computing I think we're still in the learning phase. We're still finding out what's new here. There are so many new cloud providers out there. The contracts that you have with them are changing. It's difficult to lock down and say this is really what a cloud contract is. These are the standards that are out there. Particularly for financial institutions that might be used to dealing with core service providers that are knowledgeable of the regulatory environments, the service providers in the cloud space may not quite be there. Those contracts, the service level agreements, they're not necessarily made to benefit the financial institution.
SAXINGER: Well, in one aspect, I'd like to be able to say that the guidance that we have for outsourcing technology services, or other guidance on implementing information security, is still applicable. But that is a little bit simplistic, because mobile does have some specific challenges. Particularly since it's so new, I think the security model behind it hasn't quite caught up. We see instances where there are breaches that we weren't expecting, almost on a weekly basis, from different mobile platforms. How do you manage that as a vendor? If you're going into that, you're going to have to deal with a lot more players than you would, for example, with a core service provider. You have to deal with the network provider. You're going to have application developers. There's going to be network gateway providers. It becomes a lot more complicated for a financial institution to understand, for example, the security of their customer as it goes through the entire system.
KITTEN: And where are some of the challenges posed by mobile where application development is concerned?
SAXINGER: I was looking at some mobile apps recently, and I use mobile banking quite a bit too. I find mobile banking actually helps me stay more secure because I can check my balances and look for any problems that come up a lot quicker. But there is a question of trust. Who are these developers that are trading applications that will interface with the bank, either in contract with the bank or through aggregation-type techniques? And there's not always a lot of vetting who these vendors are, particularly when they're from an indirect banking model. So that's something I worry about.
Then there've been cases where applications are released, and it's sort of a typical internet type software model, where we are quick to market and then we fix the problems later. When it comes to dealing with bank and customer data, we'd like to see a little bit more of an aggressive approach taken on getting the software right the first time.
KITTEN: That's a good point that you raise. With any emerging technology, that's something that comes into play with getting product development and your fraud and security teams to work together. What about some of the privacy concerns that surround mobile? We talk a lot about geolocation, and, of course, that could be something that's used as another layer of authentication or another layer of security, but it also poses privacy concerns.
SAXINGER: Isn't that interesting, how the same technology that can be used to improve security is also a security risk. It's going to depend on how the banks use it, and not just how the banks use it. That data is there for others to use, and it could leak out. Financial institutions that are going to have this built into their application are going to have to review their compliance requirements and what their liabilities are, and to think about, from a risk process, what are some of the potential things that could happen. Maybe it's what you would normally do in a risk assessment like analyzing potential threats to the data. And it's certainly reasonable now to expect that certain types of that data could leak out through the application or the network. It's definitely something now for legal and the compliance side to take a look at.
KITTEN: When it comes to some of these agreements that institutions would have with third-party providers, especially in the mobile arena, the number of institutions are leaning on some of these outside providers to help them with mobile. It's an emerging technology. But when they're looking at some of these agreements and some of these privacy concerns, are there places they can go? Are there examples they can look to, or is it just advantageous to get their legal departments involved, as well as product development and security, and have them all put their heads together and figure out the best solution moving forward?
SAXINGER: First of all, I wouldn't expect your vendor to necessarily guide you down the security path. This is going to be up to the financial institution. This is where the financial institution needs to figure out what its security strategy is for these devices and what their privacy strategy is for these devices. You do that during the risk assessment phase of deciding that you're going to go into this line of business. Then once you make that decision, you need to get those put into your service level agreements and licensing agreements. Then you have to monitor for compliance with those agreements. There are some studies out there that said a lot of these vendors don't believe that security is their responsibility; it's the client's responsibility. Even if you put the security requirement on a service provider, there's only a certain amount of security that they're going to have to provide to meet the minimum requirements of the contract. It's up to the financial institution, through its strategies, policies, contracting and monitoring, to make sure all of these things work together as part of their overall objective.
This is the end of the first part of a two-part interview with Donald Saxinger of the FDIC's Division of Supervision and Consumer Protection in the area of regulatory IT examinations. Be sure to check out part two, when we talk about business continuity planning and the impact SLAs have on recovery during disasters.
Follow Tracy Kitten on Twitter: @FraudBlogger
The Federal Reserve on Jan. 26 revealed its roadmap for an overhaul of the U.S. payments system,...
The Federal Reserve on Jan. 26 revealed its roadmap for an overhaul of the U.S. payments system,...
Makes Recommendations for Boosting Cybersecurity
Duggal: Legislation Should Keep Pace with Technology
Section 118 (d) Ruled Unconstitutional
Expert Offers Risk Management Insights
Vasco's Dica on Authentication Trends in the Indian Market
Supreme Court Rules Section Is Unconstitutional
Concerns Voiced Over Narrower Risk Assessment Proposal
FS-ISAC's Anderson on How to Improve Information Exchange
SCOPE's Dhingra: Security Awareness Lacking at Indian PSUs