With the data breaches that have occurred during the last few years, the bottom line has been heavily impacted for many issuers along with the information systems supporting them.
IT teams are realizing there is a need to examine, prioritize and introduce new security tools, techniques and processes in an industry that is slow to adopt technology.
Business dictates the production features and the processes needed for payments and every other financial application. It is up to developers to include the nonfunctional requirements, which often include both performance and security. Do all the developers know security best practices in their coding languages? In most cases, the answer is no, creating the need to outsource application security testing, as a third-party code review.
Outsourcing security checks and tests make more sense than trying to hire and retain expert security talent and developers.
Here in the heart of the Silicon Valley, it is inexcusable not to have default passwords, up to date patches, and multifactor authentication for logins to financial systems because we’ve been attacked for years, and we have a lot of security talent at our fingertips. Emerging markets and small businesses are a softer target, but their money spends just as well to thieves.
Having a security program is the key — as the top IT security managers will all echo, everyone needs to help the security program succeed. New workflows take time to set up, to educate a team and measure success. Vendors need to help the champions in various institutions design the processes that make the tools successful.
The user isn’t the weakest link in security any longer. If we are honest with ourselves, it’s the companies who supply services to the user, and look after their best interests. If we fail, we have done our users a disservice.
An IT security manager for a major financial organization recently spoke to our firm about how his organization implemented handled security concerns, with a focus on app security. He summed up his technology headaches in a few main points: visibility into every system; balancing business needs versus security; managing legacy code and systems; prioritization of budget and manpower; and staying ahead of hackers.
Every security or data privacy officer needs to quantify, address known findings and search for unknown vulnerabilities, whether on the network side or via applications, so that they can better allocate resources, design their remediation strategy and distribute and implement patches.
If this is a problem that major players in the world’s financial stages have, imagine how much harder is it for smaller issuers and businesses.
Take this example of how easy it is to steal credentials. Is email used as a login? Is the application secure vis-a-vis how it asks you to reset a password? Is there multifactor authentication set up, so that if you log in from a new location in a public library you have to check your phone or email for a security code?
If you are a bank or financial Institution, in order to protect your bottom line you need to invest in security. SWIFT system owners figured this out last summer around the time of the Bangladesh attack, investing a large chunk of its profit into its IT security features as well as monitoring. The security team tripled, they created a Security Operations Center for threat monitoring and did some major work improving both the SWIFT messaging service on the application side and applying new fraud control reporting into their software.
SWIFT is pretty solid these days thanks to that heavy expenditure in security. So is SPEI. So how did hackers get in? Pending the publication of official findings, we have a few suppositions we can make.
For example, secured communication between any two systems requires a combination of secured certificate exchange and secure APIs. Most of the regulations on how to engineer secure systems (like
For a decade network security companies reminded everyone that there is no “silver bullet” to be secure; hence the creation of the term defense in depth. However, defense in depth was limited to looking solely at network traffic, ignoring the use case of a legitimate login doing bad things within a closed system.
