[BreachExchange] Data breaches good reminders of vendor risks

Audrey McNeil audrey at riskbasedsecurity.com
Mon Dec 18 18:59:46 EST 2017


http://www.bankingexchange.com/news-feed/item/7239-data-
breaches-good-reminders-of-vendor-risks

Data breaches involving billion-dollar companies ranging from Deloitte,
Yahoo!, and, of course, Equifax have forced bankers and regulators alike to
place increased scrutiny on vendor risk management practices.

Data liquidity will be a key focus for efforts towards mitigating future
reputational, operational, and legal risks.

Compared to other businesses, banks have a higher bar to reach when
developing risk management programs. Federal regulators are constantly
monitoring for potential missteps and there is an increasing level of
expectation from customers to improve security.

Following the recent Equifax breach, bankers must ensure that their vendors
are putting the proper controls in place to mitigate all potential threats.

Prioritizing and stratifying vendor risk

Risk management is intended to be a process of identifying the biggest
threats to your organization. The first step towards creating a proper
program is to stratify risks categorically. Some banks apply the same risk
rating to each of their vendor relationships, regardless of the service
provided; the level of access they have to bank data; or the types of data
shared.

This, frankly, is a recipe for disaster. Some vendors pose a larger, more
catastrophic risk to your bank than others. For example, most financial
intuitions are leveraging one vendor for branch automation technology while
using another for their loan origination system (LOS). While both vendors
have access to the institution’s network (which must be accounted for), the
LOS is potentially pulling much more sensitive data from the bank into
their own system. This flow could be easily compromised if the vendor is
lax in managing its own safeguards.

This brings up the key issue of managing exactly how data moves through an
organization. Some vendors require data to be transferred between the
bank’s server and their own, while others process data within the
institution’s servers.

Some banks might consider getting into this a trivial nuisance, but it’s of
critical importance to a robust risk management program.

It’s true that internal intrusions are a key risk for financial
institutions, but what could be more risky than allowing data to leave an
organization? Once data is outside of a bank’s network, bankers have little
to no control over it, and it’s up to the vendor to hold up their end of
data security.

Safeguards and due diligence

After evaluating, categorizing, and tracking the various risks posed by an
institution’s vendor relationships (technology or otherwise), the bank must
conduct its due diligence and ensure the vendor is upholding its end. This
typically equates to a requirement on the vendor’s part to provide
documentation that demonstrates the company’s security arrangements and
controls.

Such analysis can be critical to any vendor-bank relationship. Yet
frequently this is only done at the onset of a relationship— once a program
is up-and-running conducting any further analysis is too often treated as
an unnecessary, time-consuming expense.

Due diligence, in reality, should be an ongoing effort and one that never
takes a backseat to the operation itself.

Even if a vendor has the proper safeguards in place at the beginning of a
relationship, that does not mean those controls will remain up-to-date or
effective over time.

Consider the Equifax breach, where not updating the Apache Struts
web-application enabled hackers to gain access to more than 145 million
Americans’ personal identification information, including Social Security
numbers. Based on percentages alone, that means that half of any given
bank’s customers may be impacted.

This underscores an important point: What’s true the moment a contract is
signed may not be the case months, or even years, down the road.

This is particularly the case for technology vendors who have specialized
access to a bank customer’s data. Physical threats have always been
ubiquitous for banks. Bankers understand that branches and ATMs can be
targets for criminals, and they have put protections in place to limit
those risks, but technology and software threats are always evolving.

Hackers constantly discover workarounds to what was once perfectly secure
technology. It’s their livelihood to do so. It’s a banker’s job on the
other hand, to limit the number of potential backdoors and routes a hacker
can use to commit criminal acts.

Response tactics when inevitable happens

Once a financial institution has a strategic, robust risk management
program in place, and has conducted proper due diligence on all of its
vendors, it’s up to the controls in place and the institution’s regular
audits to ensure that no issues occur.

Risks are always there. A bank can take all the precautions in the world
and hire the best people available however, and a disaster can still occur.
A patch can be missed, an employee will click a malicious email link, or a
hacker will simply find a new and innovative way of accessing data that no
one could have predicted, other than the hackers themselves.

When infiltration occurs, the approach shifts towards mitigating the
opportunity for a disaster to ever occur again. To do this, banks must
identify where any missteps occurred within the program, whether or not
there was a fundamental flaw in the initial risk assessment or if the
vulnerability was previously unknown. This way, bank management can better
identify where to implement new and more robust controls.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riskbasedsecurity.com/pipermail/breachexchange/attachments/20171218/28f69948/attachment.html>


More information about the BreachExchange mailing list