What banks can learn from a cryptocurrency's bug bounty program
https://www.americanbanker.com/news/what-banks-can-learn-from-a-cryptocurrencys-bug-bounty-program
What banks can learn from a cryptocurrency's bug bounty program
By
Published
This sort of design ethos is anathema to banks, which have traditionally relied on secrecy—keeping their code private, whether it was developed in-house or written by vendors such as Fiserv, FIS or Jack Henry—and trying to deny access to hackers in order to keep their systems secure.
To be fair, this has been slowly changing in recent years as a number of banks, including Citigroup, BBVA, JPMorgan Chase, Wells Fargo and Capital One have opened up developer hubs that give third parties access to some of their code and data. Some large banks use bug bounty programs, though they don't like talking about them, and some are seriously testing and considering open-source blockchain technologies, including Hyperledger and Quorum, for certain purposes such as derivatives clearing. And there are a few open-source core banking initiatives, such as the Open Bank Project and Apache Fineract, though they haven't been widely adopted in the United States.
Yet even if they can't, or won't, fully adopt the open-source mindset of security through transparency, financial institutions can learn from its best practices. One step might be to embrace wholeheartedly the practice of rewarding coders for finding and patching bugs.
"Programmers like creating stuff," Taylor said. "It's far less sexy to comb through legacy code that has existed for years and attempt to find vulnerabilities in it. And it's unlikely that their bosses are going to pat them on the back for spending a chunk of time looking for bugs and not finding them. And if they do find them, [their managers] generally say, 'OK, great, good for you.' But there's no incentive there. If they fail to find anything, they're scolded; and if they do find something, it's viewed as luck."
Building bug-hunting bonuses into the pay structure of engineers, for instance, would send the message that software quality is more important than quantity.
"If you incentivize programmers to find and resolve bugs, it will change behavior," Taylor said.
Banks could also start open-sourcing certain parts of their systems, suggested Alex Waters, a former bitcoin quality assurance engineer and the chief technology officer of the stealth startup GetKelvin.
"There are aspects of their applications that probably should be open-source—things like authentication and communication," said Waters. "Which is not to say that they'd be open-sourcing the underlying data. Of course not. It's just they'd be making available for public review the methodology for authentication, for example."
Taylor agrees, with the caveat that any software providing a true competitive advantage should be kept under wraps. But for commoditized functions and services, banks could actually reduce their security risks by using open-source software, he said. "And I don't think that is ever really a consideration for them. I think they blindly use closed-source, or commercial, software for everything."
Nothing banks can't handle
Waters, who has consulted for banks, is convinced of the open-source approach's benefits.
"Generally speaking, large open-source projects are far more secure than in-house, private software," he said. "And within the realm of large open-source projects, cryptocurrencies—because of their inherent nature as being based on cryptography—tend to be the most secure, and security-conscious, groups."
What, then, of banks working with cryptocurrencies themselves? Asked whether financial institutions are right to be wary of these new technologies, since by and large they can't be centrally controlled, Bugcrowd's Ellis says no.
"I don't consider crypto to be a unique or a special case from a vulnerability standpoint," he said.
Article Battle for the home screen
As the phone replaces the …
PARTNER INSIGHTS
SPONSOR CONTENT FROM:
BankingJuly 28
You can count on any software being attacked at some point, he clarified. What does make digital currency unique is that "the [monetary] value is inherent in the code," so major flaws in the code can be financially catastrophic. Extra care and attention is required, and that is where his company's crowdsourced security comes in.
"You don't build a three-foot fence to defend against a 10-foot attacker, because that would be ineffective," he said. "But you also don't build a 10-foot fence to defend against a three-foot attacker, because that would be economically irrational."
Ultimately, the security challenges posed by cryptocurrencies are nothing banks can't handle, Waters said, provided that they "apply everything they already know. What better industry to work on custody, settlement and clearing for cryptocurrencies than the banking industry, which has been doing [these things] for years? They're totally equipped to understand all of the various risks and how to mitigate them."
https://www.americanbanker.com/news/what-banks-can-learn-from-a-cryptocurrencys-bug-bounty-program
What banks can learn from a cryptocurrency's bug bounty program
By
Published
- September 06 2017, 12:35pm EDT
This sort of design ethos is anathema to banks, which have traditionally relied on secrecy—keeping their code private, whether it was developed in-house or written by vendors such as Fiserv, FIS or Jack Henry—and trying to deny access to hackers in order to keep their systems secure.
To be fair, this has been slowly changing in recent years as a number of banks, including Citigroup, BBVA, JPMorgan Chase, Wells Fargo and Capital One have opened up developer hubs that give third parties access to some of their code and data. Some large banks use bug bounty programs, though they don't like talking about them, and some are seriously testing and considering open-source blockchain technologies, including Hyperledger and Quorum, for certain purposes such as derivatives clearing. And there are a few open-source core banking initiatives, such as the Open Bank Project and Apache Fineract, though they haven't been widely adopted in the United States.
Yet even if they can't, or won't, fully adopt the open-source mindset of security through transparency, financial institutions can learn from its best practices. One step might be to embrace wholeheartedly the practice of rewarding coders for finding and patching bugs.
"Programmers like creating stuff," Taylor said. "It's far less sexy to comb through legacy code that has existed for years and attempt to find vulnerabilities in it. And it's unlikely that their bosses are going to pat them on the back for spending a chunk of time looking for bugs and not finding them. And if they do find them, [their managers] generally say, 'OK, great, good for you.' But there's no incentive there. If they fail to find anything, they're scolded; and if they do find something, it's viewed as luck."
Building bug-hunting bonuses into the pay structure of engineers, for instance, would send the message that software quality is more important than quantity.
"If you incentivize programmers to find and resolve bugs, it will change behavior," Taylor said.
Banks could also start open-sourcing certain parts of their systems, suggested Alex Waters, a former bitcoin quality assurance engineer and the chief technology officer of the stealth startup GetKelvin.
"There are aspects of their applications that probably should be open-source—things like authentication and communication," said Waters. "Which is not to say that they'd be open-sourcing the underlying data. Of course not. It's just they'd be making available for public review the methodology for authentication, for example."
Taylor agrees, with the caveat that any software providing a true competitive advantage should be kept under wraps. But for commoditized functions and services, banks could actually reduce their security risks by using open-source software, he said. "And I don't think that is ever really a consideration for them. I think they blindly use closed-source, or commercial, software for everything."
Nothing banks can't handle
Waters, who has consulted for banks, is convinced of the open-source approach's benefits.
"Generally speaking, large open-source projects are far more secure than in-house, private software," he said. "And within the realm of large open-source projects, cryptocurrencies—because of their inherent nature as being based on cryptography—tend to be the most secure, and security-conscious, groups."
What, then, of banks working with cryptocurrencies themselves? Asked whether financial institutions are right to be wary of these new technologies, since by and large they can't be centrally controlled, Bugcrowd's Ellis says no.
"I don't consider crypto to be a unique or a special case from a vulnerability standpoint," he said.
Article Battle for the home screen
As the phone replaces the …
PARTNER INSIGHTS
SPONSOR CONTENT FROM:
BankingJuly 28
You can count on any software being attacked at some point, he clarified. What does make digital currency unique is that "the [monetary] value is inherent in the code," so major flaws in the code can be financially catastrophic. Extra care and attention is required, and that is where his company's crowdsourced security comes in.
"You don't build a three-foot fence to defend against a 10-foot attacker, because that would be ineffective," he said. "But you also don't build a 10-foot fence to defend against a three-foot attacker, because that would be economically irrational."
Ultimately, the security challenges posed by cryptocurrencies are nothing banks can't handle, Waters said, provided that they "apply everything they already know. What better industry to work on custody, settlement and clearing for cryptocurrencies than the banking industry, which has been doing [these things] for years? They're totally equipped to understand all of the various risks and how to mitigate them."
Last edited: