Tips from an IT auditor

Sometimes in a momentary panic attack after news of the latest cyberbreach breaks, bankers will look to purchase the latest security application to help deflect a similar attack.

Mike Morris will often try to talk them out of it. “New is fine,” says the experienced bank IT auditor, “but first see what you’ve already got in hand and figure out if you’ve got gaps, and then buy new tools.”

All banks, for example, have an email filter. If properly set up and used by employees, says Morris, these filters will block spoofing and other types of fraudulent email attempts. (Spoofing is where someone outside sends an email that looks just like your domain, trying to trick your users.) An automated tool such as an email filter takes a potentially bad decision out of the user’s hands, says Morris. Blocked emails can be quarantined and later released if they are determined to be legit by IT.

In his bank IT auditing work, Morris, who is systems partner with Porter Keadle Moore, an Atlanta-based accounting and consulting firm, reviews standard internal controls. One of the things he looks for is how a bank enforces segregation of duties. This involves access levels, particularly a practice called “least-privileged access”—meaning “just the access you need to do your daily job duties,” according to Morris. It is designed to ensure that no one person can “dominate a transaction.” A simple example: a wire transfer, where the bank sets up dual controls and limits so one person can’t simply wire out $10 million, without administrator approval.

Morris says that the average bank he goes into fails to properly segregate duties— usually the result of growth. Early on, a small bank may only have 12 people, he says, making segregation of duties difficult. Instead, such banks can rely on monitoring and controls. But as they grow, says Morris, these banks need to limit access.

“I’m a good person”

The greatest risks, says Morris, often turn out to be “people who know best”—the ones who know the controls and who’s looking at what. For those people, he continues, you especially need to apply least-privileged access.

“The average tenure of someone who commits bank fraud is about 26 years,” Morris notes. These folks “know where the holes are. They’re often the last person you’d suspect.”

Such people typically fall within a “fraud triangle.” As Morris explains it, the three sides are Opportunity, Pressure, and Rationalization.

A person who has been at the bank a long time often has opportunity.

The pressure, says Morris, can come from any number of things including living above one’s means.

Rationalization comes into play as the person assures himself that “I’m a good person; I’m going to pay this back, but I’ve got to deal with this problem.”

“We can’t really control pressures or rationalizations, says Morris. “So we try to reduce the opportunity for somebody to do something they shouldn’t. Using least-privileged access takes away some of that opportunity.”

Double-checking the backup

Morris says another part of his work is examining processes and availability of systems in general. From a continuity standpoint does the bank have a contingency plan should a hard drive crash or the bank’s main technology provider be down? There are really two sides to it, he says.

On the contingency side, Morris will ascertain “what the business people do when a systems down. Can they still operate manually, realistically, and for how long?

On the disaster recovery side, how quickly can the bank come back up and in what order so that people can start working again? Regulators, Morris notes, put heavy pressure on banks to get back up within 72 hours in most situations. One consideration is whether a particular disaster will also impact the secondary site the bank is depending on.

Because so many banks now rely on vendors to run the bank through the cloud or some other remote arrangement, checking on the vendors to be sure they are testing their backups is equally important. Banks have to make sure the vendor has tested its continuity plan at least annually, Morris notes.

Phish, catch, release

Circling back to cybersecurity, Morris says his team typically works with bank IT people to understand where the most common attack vectors are at any given time—i.e., how hackers are trying to get in. Then, starting from the front line, look at how to stop these attacks.

The PKM team will “phish” a client bank (with permission, of course)—sending fake emails and trying to gather credentials.

In some cases, Morris explains, “We have impersonated an email from [Microsoft] Office 365 to attempt to harvest usernames and passwords.”

“We almost always get at least one set of credentials which enables us to log in,” says Morris. In one recent bank test four users clicked on the emails and three gave their credentials.

“They did not have dual-factor authentication turned on, so for those three users I got into their email system remotely,” says Morris.

“Once inside, it can get pretty nasty,” he continues, “because you have full access to internal correspondence.” Morris says that at that point the PKM team takes a quick screen shot to verify the entry and gets out, resetting the passwords.

Beware the waterhole trap

Morris also discussed so-called “waterhole” attacks—so named because they mimic animals drawn to a waterhole where predators lurk. In such attacks, he says, a cybercriminal infects a legitimate website, and when users go to the site, if they have any type of vulnerability on their machine (they don’t have the latest patch, for example), the infected site downloads the virus onto the visitor’s machine.

Most banks, says Morris, have web filters to help prevent such infection. But he describes many of these filters as “too wide open.” Banks need to restrict employee web use to business-related activity. Other things—personal email, personal chat—should be blocked, he says.

“Four or five years ago we would meet with resistance on this point,” says Morris. “Now boards understand they need to be locking things down because the risks are getting too high.”

APIs, more help than risk

When asked if the increasing bank use of application programming interface (API) technology presents any increased risks, Morris says it can, but that the technology overall is a plus for banks because it gives banks choices and makes it easier and less expensive to connect third-party applications with core systems.

“Vendor management is the key,” says Morris. “Vendors have to understand the different requirements and demands of bank users.”

He adds that from the banks’ perspective, potential vendors—those outside the usual bank vendor universe—need to be well-vetted, including checking the company’s financial statements, but with the understanding that they will be different from those of more traditional vendors. Banks should also look at subservicing agreements in which the bank’s vendor risk extends out further than they might first have thought.

“Banks are still leery of going outside the box” at this point,” says Morris, but this is beginning to change now that the industry’s post-crisis credit and capital issues are behind them. APIs will help the industry move forward, Morris believes, enabling banks to do things differently than they have in the past.

Asset-based lending is one example he cites. It’s a business that many banks would not have touched on their own. But a fintech company can provide an API tool to valuate assets for collateral, something banks are not set up to do.

Still, he says, it gets back to hiring the right people and having the right policies. “You need good risk management,” to make such third-party partnerships work, says Morris.