 |
 |
|
Redspin
Client Example
|
|
How does MasterCard make sure their network is secure? Despite a very large internal security department, MasterCard hired Redspin to provide an objective, outside security assessment. For organizations with more modest resources, requesting past audits from the vendor or service provider is an effective first step. Unfortunately, the problem with this approach lies in the fact that the quality of security audits varies widely, and nothing is more effective than a live calibration of the current network environment, because past audits may not reflect recent risk-introducing changes to the vendor's network.
|
|
|
|
 |
|
|
|
 Back To Redspin Security Management Advisory Headlines
|
 |
Volume 2 | May 6, 2008
|
 |
|
59% of Bank Security Breaches Occur at the Service Provider Level*
How do you manage the security posture of your service providers and vendors? According to reports from the FDIC, and confirmed by our own analysis, this is one of the key security issues of 2008. This category of risk encompasses a number of related scenarios all of which can ultimately result in your organization being held accountable for a breach, even though the actual source of the risk was introduced by vendor hardware or a service provider's network architecture.
|
Other areas of security risk are somewhat more tangible and can often be mitigated through a configuration-tweak or with an update to policies. However, service provider and vendor-based security issues are much more challenging to mitigate, because to do so requires first successfully communicating the issue to the vendor or provider and then validating the improvement in their security posture. As a result, the time-frame for mitigation is considerably extended relative to more common configuration-based security risks.
This Redspin Security Advisory provides a number of practical mitigation tips for management to consider, as well as one client example that describes a highly efficient route towards mitigation. Also included here is a slightly more technically in-depth example demonstrating how ATM Machines and POS Terminals relate to both vendor and service provider oversight security issues.
|
|
Technical Overview
Last year, the FDIC Office of the Inspector General analyzed the FDIC's oversight of bank's vendor management program and found it inadequate, revealing that 59% of bank data breaches happened at the service provider level, and stating that "the vendor management program should require security standards that meet or exceed the bank's own standards."
www.fdicoig.gov/reports07/07-005.pdf
Guidance such as this is helpful and is a great improvement on the part of the FDIC, however, it still leaves management without practical and actionable steps that they can take to mitigate this type of risk. For example, what do you do when a vendor or service provider produces a SAS-70 audit as evidence of their security?
Because a SAS-70 is an expensive and highly formal auditing procedure, many people assume that it must be exhaustive. The SAS-70 "represents that a service organization has been through an in-depth audit of their control objectives and control activities, which often include controls over information technology and related processes."
www.SAS70.com
However, in our experience, a SAS-70 does not even come close to replacing or compensating for an expert security assessment, because it was never intended to be a robust risk-based network security assessment. A SAS-70 can verify that certain stated controls are in existence, such as for example, "a firewall is present," but in our experience a SAS-70 audit is unable to reflect the effectiveness of a stated control. Unfortunately, most security risk is found in subtle configuration errors, so just verifying that a given control exists barely scratches the surface from a realistic security perspective.
Therefore, when a large vendor provides you with a SAS-70 as evidence of their security, it is likely to be inadequate and often does not provide sufficient technical insight into the security environment in question. As we discuss below, this can be dealt with by deploying specific technical controls on your side, and also by requesting past audits from the vendor/service provider in question.
|
|
Redspin Example from the Field: Insecure Service Providers
Redspin regularly encounters partner networks and service providers who present risk to their clients because their own network architecture is insecure. In our experience, even the major service providers are unwilling to discuss or acknowledge potentially critical security problems. In fact, they often insert a clause in their contract to specifically limit your freedom to analyze the risk they represent to your network.
In the case of one such incident, involving a well known national service provider, we were actually able to persuade management to fix the issue specifically for our clients. However, the provider still refused to mitigate the risk on the rest of their network. Just two weeks later this provider was breached, with hundreds of their customers impacted as a result. Educational anecdotes such as these are clear examples of the dangers of being dependent upon, or ignorant of, your vendor or service providers' security. While everyday thought would suggest that a well established organization must be secure, our research actually shows just the opposite. Because most security risk lies in subtle configuration-based problems, added complexity only increases security risk.
|
|
Technical Example: The Risk to Data in Transit
One particular example that we encounter often in the course of our analysis are insecure ATM Machines and POS (Point-of-sale) Terminals. It is an interesting example to look at briefly, because one can see that it encompasses both components of this risk category. On one hand, the initial risk stems from vendor hardware that is insecure, however, this same risk is then greatly increased as a result of that insecure data traveling across several service provider networks.
ATMs are typically out of date Windows PCs which fail to encrypt anything but the PIN number, transmitting all other data (including names and card numbers) in clear text.
However, for the transaction to be authorized (at either an ATM Machine or POS Terminal) the unencrypted data must traverse up to several layers of regional and/or national service providers. While the elapsed time is only a matter of seconds to the front-end user at the ATM/POS, their data has actually made a substantial number of additional hops at insecure service provider networks. In other words, what was already a risky scenario, due to poorly configured vendor equipment not encrypting sensitive data, is further exacerbated by the complex path of the sensitive data through several service provider networks.
The recent Hannaford Brothers Grocers data breach (in which data in transit from POS Terminals was intercepted) is a strong reminder of the need to encrypt all sensitive data and to minimize the risk to that data while it is in transit. The mitigation techniques available to management are, however, somewhat diluted by the fact that additional service provider networks are compounding the initial risk of an insecure ATM Machine or POS Terminal failing to encrypt sensitive data. A general rule of thumb for management is to mitigate all the risk that possibly can be on your own network while at the same time urging your vendors and service providers to improve their own security posture. See the example of MasterCard World Wide, one Redspin client who took the fast track towards reducing this category of risk.
|
|
Executive and Technical Conclusion(s)
4 Technical and 3 Operational steps that your organization can take to begin mitigating this confusing area of risk:
Technical (IT):
- Verify that sensitive data is encrypted throughout its journey.
- Place a Firewall with strict rule sets between you and the vendor/service provider.
- Limit access through the "rule of least privilege" - always route vendor, service provider, or partner network connections to a segmented security domain.
- Understand the high-level architectural picture - who is connected to whom? What are the intermediary connections?
Operational (Management):
- Request past audits and have those audits reviewed by experts.
- Hire an objective, outside security audit firm, and include the service provider and/or vendor network in their scope.
- In the case of core banking service providers, request FDIC official examinations which are rarely disclosed publicly, so institutions must specifically make a request to the FDIC.
|
|
Speak with a Redspin Security Consultant Today!
|
* = Required Information
|
|
|
|
|
|
|
 |
