3 questions to…

Here’s something much easier to read hopefully, compared to the previous, quite technical posts. MoneyGram International runs a “3 questions to…” series in the corporate newsletter with the aim to bring the team closer and shed some light on the profiles of senior leadership in the company. My turn to answer 3 questions came last week and I’m glad, because that’s always an opportunity to practice the non-technical writing. I didn’t expect much out of it, but the feedback was exceptionally positive. Well, positive enough to convince me it might be worth sharing with LinkedIn. What do you think?

You’re managing multiple IT Teams at MGI. What skills do you find exceptionally useful in your role?

Empathy, the queen of all skills is probably worth mentioning on the top spot. This is especially important if your teams work from all around the globe and come from a variety of cultures. Leading such teams is often a challenge, even in IT, where information is crisp and precise. Same message is worth conveying in a variety of ways, staying considerate of how others might look at challenges or upcoming projects. Likewise, sometimes substantially different encouragement is needed in order to gain valuable input and uncover true potential of individuals. Being considerate about those differences and yet not losing track of the technical bits and the end goal is a great challenge to have. I believe that empathy is the key to victory in this aspect.

What are the biggest challenges you face at MoneyGram and how do you address them?

I’m sure everyone mentioned time zone difference between Europe and the US, so I’ll skip that and mention something from technology perspective. As such, while we deliver interesting solutions to the market, I believe we can still do better from the perspective of internal and customer facing technology. While staying abreast is an area dedicated to roles outside of IT Operations, I’m putting extra efforts to bring up some ideas and gain resources to new projects.

Based on your professional experience, what career advice would you give to your colleagues at MoneyGram?

I try to give advice to my team (then it’s called “direction”;) ) all the time, so to give one piece of advice now in general is not an easy task without sounding trivial, but let me give it a try. I believe that many people underestimate the power of research. For example, every time I hear or read anything I don’t know or am not sure about, I make sure I write it down. I then have a dedicated time slot, negotiated carefully with my wife, where I follow up on each item on my research list. Sometimes reading is not enough and I end up like building a proof of concept. I never let information get past me without verification – if there’s a chance to broaden knowledge in the area I’m working in, then it is certainly worth following through. Having strong understanding of all aspects results in working less on assumptions, which gives confidence a great boost. And what’s a leader without confidence?

Could SHA-1 and Dirty COW have something in common?

SHA, or Secure Hash Algorithm is a hash function initially announced in 1995 by the United States’ NSA. It become widely popular with appliances for password hashes, certificates and a variety of software. The implementation made it to SSL (and later TLS) collections, SSH, PGP and many more. From the very moment of publication, SHA-1 was contested by cryptography researchers from all over the world, but not to much success. It took 10 years after the initial publication for the first papers to appear claiming weakening SHA-1 to some extent. The papers remained theoretical due to the cost – it would take almost $3mil of CPU power to execute the attack. It took another 10 years for a group of security researchers to further weaken SHA-1 and actually demonstrate an attack by moving the computation to 64 Nvidia GPUs. And why am I writing this? Mainly because this is a story of great success – for a hash function – to remain unbroken for over 2 decades. Still, around 2015 various security authority boards have decided that, by Moore’s Law, within the next 2-3 years, the cost of attacking SHA-1 by brute force was going to be economically viable and generally available. Based on that SHA-1 was to be gradually removed from public use.

On a side note, here’s one very intriguing case with lots of food for thought. Due to the wide adoption of SHA-1, the ban was instated by various decision makers at different times. In 2015, the Browser Forum decided that SSL certificates using SHA-1 can no longer be issued after the 1st of January 2016. Was this enough to stop all CA’s from issuing the popular SHA-1 certificates, sometimes even hard-coded into proprietary software? Dit auditors save the world as it is widely expected by various company boards? Read the full story and brilliant analysis here.

Back to the original subject, I got a bit nostalgic for a reason, and it is not because I hadn’t had steak for a while. Dirty COW is a funny acronym for a rare race condition introduced into the Linux kernel Copy-On-Write code around 2007 (kernel 2.6.22). It is not however a new vulnerability. Linus Torvalds revealed that even though it was discovered long time ago, the race condition leading to privilege escalation was rare enough that it was actually discarded. It was concluded that computation resources required to trigger the condition are not realistic. And almost 10 years later anyone can execute a local exploit and bypass internal security countermeasures companies spend huge sums on. The exploit is easy to obtain, execute and has a very high success rate.

Two completely different cases and security risks. And a complete contrast in strategy. Or the lack of. A decision to obsolete SHA-1 well in advance of vulnerabilities, despite a decent design. And no decision for a ticking bomb. I have read many quotes by Linus on security (or actually against security). Don’t get me wrong, he still is a brilliant lead for the kernel development, but why wouldn’t the Linux Foundation add the missing strategy? Track security bugs that are closed for a reason like this one and react on time? Someone might say “that’s not their job”. If reality requires it, it has to become someone’s job.