Why Developers Matter For Security
This post talks about the critical importance of actively engaging softwaredevelopers in security activities and presents a few timely real worldexamples where this was not done sufficiently and companies paid the price.
Robinhood Gold
The first example this week is from Robinhood. Robinhoodis a low cost trading platform. It turns out that you can essentially leveragemore money than you had in your account. Some users were calling it an infinitecheat code! Here’s how a Bloomberg writer explained it.
Here’s how the trade works. Users of Robinhood Gold are selling covered calls using money borrowed from Robinhood. Nothing wrong with that. The problem arises when Robinhood incorrectly adds the value of those calls to the user’s own capital. And that means that the more money a user borrows, the more money Robinhood will lend them for future trading.
This is a great example where we can pretty easily think of the bad situation by puttingon our villain hat. What would you want to do on a trading platform? Get money. Ormake trades with money that isn’t yours. The latter is exactly what is described in thisreddit post which exposed the issue.
So I would assume that Robinhood has an AppSec program. I would assume they had staticcode analysis. I would even assume that they had pentesting done against their system.If they haven’t done these things in the industry they are in, they are probably on thewrong side of all of the regulations. But obviously these activities did not identify thisissue! This could be because the Gold tier was out of scope, or the pentester didn’tunderstand the capabilities of the trading system.
On the other hand, a developer that understood what this function meant and who hadcoded the system to support this function should know that it was or was not possible.All we really need to do is educate and empower them to raise their hand and start ateam discussion about the proper handling of this type of scenario. Of course,business analysts and stakeholders need to participate to define the correct behavior.
Twitter Spies
Twitter also had some interesting problems this week. It was exposed that severalemployees had likely been in the employ of other governments or interests. Specifically,they were charged with spying for Saudi Arabia.
This raises a critical question around who should have access to data. Inside Twitter,there are undoubtedly ways for people to get access to power tools, reporting systems,and raw data. This in itself is not an issue. You can’t run a platform like Twitter withouthaving the data, tools to manage and manipulate the data, and people with access to thosetools.
What you can do though is:
- Strictly limit who can see the data
- Track who does see data
- Store data with controls commensurate to the exposure
- Build active monitoring functions (human or otherwise) to detect misuse
The fact that Twitter did not detect that insiders were exploring thousands ofaccounts and capturing personal information associated with the accounts fromthe inside of the business reflects a gap in internal controls - likely at theapplication level.
It is chilling to think that these spies were specifically searching out dissidentsand funneling information from inside Twitter to a government that may havemurdered a journalist, Jamal Khashoggi.
I wonder what other governments have agents in place in Twitter … let aloneGoogle, Facebook, Apple, AT&T, Disney, Amazon, etc. I would assume at leasta few have them in all of the above!
The answer again is to have developers trained and empowered to think about theseangles on security so that they can properly implement controls which make itdifficult to get access to these data, track access for later review, andset off alarms when it is accessed.
Trend Micro Insiders (via CRM?)
Trend Micro, a security company, had its own security issuethis week in which it revealed that an employee had accessed customer informationwith criminal intent and sold it to a “currently unknown third-party malicious actor”.
It is most likely that the Trend Micro customer information is in a commercialCRM system (e.g. Salesforce, Hubspot, etc.) which was either not configured properlyto prevent the access or did not properly alert the Trend Micro team about theunusual access pattern. The incident took place in August and 68,000 records wereimpacted. This sounds like something the CRM developers should know could bepossible and which Trend Micro should have known about before November throughchannels other than customer complaints containing substantial legitimate information(real information about the customer’s licenses).
This is not to point at Trend Micro but to reflect on what the “solution” is - andmy take is that it is building security auditing and metrics into software so thatincidents like this aren’t discovered so far after the fact but can be identifiedwhile they are in progress.
Unfortunately, the developers of the CRM system probably weren’t thinking about howthings could go wrong or didn’t have the time and money to spend building anappropriate solution. Again, developers matter a lot when it comes to security.
Developer DNA
These real world examples show that there are significant advantages to makingsecurity part of a development organization’s culture or DNA.
Ever since I started Jemurai in 2012, I knew abstractly that if you wanted totalk to someone who really knew what code was doing, the best place to go wasdirectly to the developer.
Sure a BA, QA, VP, Stakeholder, AppSec person or Pentester might know,but the developer has to know. They coded it.
In secure dev trainings, we teach not only security topics, such as the OWASP Top 10 (see this post for more), but also processes and habits that developers can use to keep security top of mind. Examples range from code review checklists to writing abuse cases in a villain persona.
Ultimately, it takes a lot of work and a cultural shift to create a team wheredevelopers actively embrace security. It is not easy. We always work to meetthem halfway by providing easier tooling, libraries to help, and being reasonableabout expectations. We are careful not to inundate developers with falsepositives because that is the worst thing you can do culture wise - itundermines your own credibility and the security culture when you insist onforcing developers to fix things that don’t matter.
Note that I am not advocating that we immediately hold developers accountablefor security. Sadly, this is not an established enough skillsetthat we could turn on a dime and start requiring developers to do this. Butit is something we need to start working toward.
Conclusion
We love developers. We embrace bringing security to developers and have had awesomeresults in real world scenarios building shared tooling and culture to promote bettersecurity. Developers are part of the solution. They are a key part of the solutionto real world problems like the ones we saw this week.
References