Editor’s Note: This is an excerpt from Mark Troester’s upcoming book, ‘Good Component Practice‘.
It was all so easy. As I sit back, and think about it (on the most gorgeous white sand beach you’ve ever seen), I truly can’t believe it was that easy.
You were probably complicit in my work, if you’re too trusting of a developer, or maybe too focused on speed or even, “pleasing the customer”. Oh, that’s a good one. I hope that was reflected on your performance review.
It began when you downloaded that framework that was going to “make everything so easy”. The one you didn’t update. The one that had the major vulnerability that you noticed only after I arrived here. Really, you should have just hung a sign on your wall that says, “infect me”.
I am one of you
I think what might scare you the most, is that I was one of you. That’s right, I came from the inside. You and your colleagues taught me how to do it, how easy it was to blow a hole into your application a mile wide for all the world to see. Ok, not all the world, only the guys that paid me so handsomely to retire to this beautiful beach in exchange for infiltrating your system. The way I think of it, I did nothing wrong. Well, technically nothing wrong. Technically, I was completely right! They were the one’s that started the actual attack, and unbeknownst to you, they got complete access to your customer & product data.
Yep, that data. The data that legal and compliance created all those B.S. rules to protect.
I told you I was one of you.
I’ll never get caught, either. Your company paid the ransom to protect their “reputation”. And that money – a lot of it came to me, as the architect.
OK, maybe I feel a little guilty, but more so, I think I’m going to tell you all of this to brag. Of course I think I’m clever, but deep down I know it’s a fault in the process that made the plan work. Actually, some people have figured it out how to prevent this from happening in the first place, so I’m just going to tell you not why I did it (if you even care), but I’ll tell you how.
And you can do with it what you wish.
The Story Begins
I started to get the idea a few years ago, just after the financial crisis. I just started working in application development at – let’s call them a large financial services firm – not to protect them, mind you, but to protect myself. I wasn’t new to the sector though; I spent five frustrating years before that on a corporate dev team working on a personal finance application.
When I arrived at … let’s go with Large Firm from now on, I was sufficiently impressed with the lead developer and the way the department embraced open source. Honestly, it was refreshing after my previous job recreating the wheel. We could download a component (and eventually an entire framework), and be in production in the time it would take my old company to start testing. We quickly progressed to the point that the majority of our applications were constructed from components that we downloaded from the Internet. We were kicking ass and taking names!
A few months after I started, Large Firm acquired a mortgage company, and I was tapped as project lead to merge their client services app into our web application. At first I was psyched – but things changed. Quickly I realized how shielded I was on the dev team from the compliance folks and from upper management. Talk about pressure. Straight from the C-level I heard, “We need this by the end of the month”. No problem, I thought. After some research, I found some additional components that would speed things along and allow us to deliver on time.
Being the good employee that I was, I knew I needed to get this component on the approved list. Large Firm had a tight perimeter-based approach – if something wasn’t on their approved list, just forget about downloading it. So I brought the issue up to compliance and asked if they could turn a decision around quickly so we could make the deadline. As you can guess, that didn’t happen.
There I was, left reconciling the need to go fast with the need to be secure.
I’m not going to lie, I was really conflicted and probably too honest for my own good. I put two of my best developers on the project to work on plan B – trying to code up what I knew already existed. Time was lost and we missed the deadline by weeks. By the time we went into testing, plan B was filled with errors. It was a mess.
It won’t surprise you to learn that I didn’t make the first round of layoffs that came later that year. Which is ok, because I was frustrated anyway. But before you think I did what I did for revenge, you’re wrong. I did it for the money.
The Conflict: Speed vs Security
I knew, and I mean I KNEW, that as better and better components were showing up that security/legal/compliance/ “dev-ops” whatever-you-want-to-call-them departments couldn’t keep up with those “approved” lists. Before my exit at Large Firm, I found out that people in my own department were bypassing the list anyway.
I’m sure the devs that survived the layoff learned a lesson from me – speed wins out over security. And in talking to developers from other companies, I realized that everyone was doing the same thing – turning to components to get things done, while NOT managing the security risk.
Not long after that, I started exploiting some banks based on what I had learned about the flawed components. It was so easy, my old “friends” writing financial-oriented web apps were completely unaware – and the security team focused on protecting custom code, they didn’t know what hit them. Of course, the application, more specifically the components, became the attack vector.
Reflections on the Beach
Some organizations probably found the exploit – I’m not sure since I moved on to my next target – it’s pretty easy when you can just repeat the exploit! Those that detect the intrusion are probably running around trying to replace the component, updating their stupid approval list. And this is even better, I’ve heard some organizations issue an edict: “there shall be no more open source in our critical applications” – What a joke!!
Like I said before, it was all so easy.
As the IT/CIO Strategist, Mark leads the product marketing effort for Sonatype – specializing in IT & CIO strategy. Mark brings over 20 years of experience leading product marketing / management efforts for established vendors and startups that are focused on IT/CIO solutions.
He leverages his previous experience as a senior IT & development manager to focus on driving business value through technology. Mark led CIO and IT strategy and marketing efforts for SAS, formulating product and marketing direction in both technical and business domains. Mark holds a Bachelor’s degree in Computer Science from University of Missouri.