Cloud Control: Q&A with Erik Hajnal of Tradeshift on Infusing Fun into Cybersecurity While Keeping Business Front and Center

May 7, 2024

Want weekly newsletters featuring interviews with security and cloud leaders delivered right to your inbox? Sign up for Cloud Control here.

Erik Hajnal of Tradeshift on Infusing Fun into Cybersecurity While Keeping Business Front and Center

Hey Cloud Control Readers,

I'm Ian, and today, I'm excited to bring you insights from Erik Hajnal, the CISO at Tradeshift, who's reshaping how we think about cybersecurity. Erik believes in making security engaging and approachable, blending it seamlessly with business operations.

In our discussion, Erik explains how integrating humor and straightforward communication transforms the traditional view of cybersecurity within a company. His approach not only makes learning about security more enjoyable but also integrates it deeply with corporate strategies, ensuring everyone feels part of the security process.

From creating memorable training sessions to aligning security initiatives with broader business objectives, Erik shares practical advice that bridges the gap between technical necessity and business innovation. This is about enhancing a culture where security supports creativity and corporate growth.

So, let's dive in and explore how Erik's strategies can inspire changes in your security landscape 👇

Question 1 💭

Erik, it’s great to have you on Cloud Control. When we were talking privately you mentioned that you’ve had your fair share of cybersecurity hiccups. Can you tell us how your early experiences have shaped smarter security strategies at Tradeshift? What lessons can other CISOs take from your experience?

I see many organizations struggling with getting security taken seriously - either because people don’t really care, or because of a no fun allowed environment, full of rules and regulations. I’ve learnt that in order to get taken more seriously, you sometimes need to take it less seriously.

Answer 1 🎯

Happy to be here! Indeed, early on as an engineer I've made my fair share of blunders over the years, and while I always felt the responsibility, I also always felt a bit excited that I got to learn something new. I often wondered about balancing the seriousness of security with how exciting and cool it can be at the same time.

I see many organizations struggling with getting security taken seriously - either because people don’t really care, or because of a no fun allowed environment, full of rules and regulations. I’ve learnt that in order to get taken more seriously, you sometimes need to take it less seriously. In fact, fun is one of the key values of the security team at Tradeshift! Context is everything though: what works great for your engineers might need a bit of tweaking before taking it to the board of directors!

Question 2 💭

Having a background in both computer science and business must give you a unique perspective to the CISO role. How do you use your background to your advantage to align Tradeshift's cybersecurity measures with its broader business objectives? Can you give examples of how this has played out in decision-making or strategy formulation at Tradeshift or other companies?

Answer 2 🎯

Most security teams I’ve seen have endless backlogs: there are always so many different things to do, new technologies keep popping up, nothing is ever perfect, so we have risks we’re trying to navigate. One very common issue I see with managing risks is the translation of siloed risks into business risks: a remote code execution (RCE) flaw is as bad as it gets as far as vulnerabilities go, and yet it could be at the bottom of our risk register if it only affects a single test server that’s not connected to the internet.

Without a solid understanding of the business, one simply cannot assess these risks well, so at Tradeshift we always try to take a step back and look at the bigger picture. After all, a critical RCE may be actually less important than a medium-severity vulnerability that actually affects all our users.

Over the past few years, cloud security posture management (CSPM) tools have become common, which can help us by putting these CVEs in the context of our infrastructure. However, we need to keep in mind that these tools don’t actually understand the business - that remains the security team’s job, and CISOs and managers of security organizations are directly responsible for connecting the dots for their teams.

Question 3 💭

You were instrumental in setting up the application security team at Tradeshift when there was a clear need. What were some of the initial hurdles you encountered while building this team from scratch? How did you go about tackling them?

The biggest challenge was making sure that people see the security team as their allies, as opposed to people who always just say “no” to everything.

Answer 3 🎯

The technical aspects of security are often about telling people what to do or how to do things: validate those inputs, use parameterized queries, use HTML encoding, keep your dependencies up-to-date, etc.: heaps of rules that can slow everyone down. The biggest challenge was making sure that people see the security team as their allies, as opposed to people who always just say “no” to everything.

To solve this, I wanted people to see us as people first, who just happen to know about security. Having worked as a software engineer for years, I tried to remember what resonated with me: fun. I like fun. Most people I know like fun. So I thought: what if we approach security with a fun-first mindset? We changed our training decks and policies to have little jokes, interesting anecdotes, tiny challenges, spot-the-mistake exercises, and lots and lots of interactivity in general.

I was a bit worried at first: is it really okay to take something as serious as security, and make it fun? Being feedback-oriented, we’d always do anonymous surveys after training sessions, and the feedback was overwhelmingly positive: people suddenly loved learning about security, and they kept asking for more sessions, praising the change in tone. Granted, there were always a few people who would prefer a more serious tone, but one size doesn’t really fit all, and I’d much rather get very high scores with a few lower ones mixed in, than everybody giving it a “meh, it’s fine I guess?” average rating.

Question 4 💭

Transitioning from a software engineer to a focus on application security certainly gives you a well-rounded view of the tech landscape. How has this varied technical background helped you in shaping effective security strategies? Could you share how understanding different tech stacks influences your approach to cybersecurity across the organizations you’ve worked with?

Answer 4 🎯

Strangely enough, I feel that my technical background is most helpful in a non-technical way: it allows me to really understand how things are done across most levels of the organization. When we come up with a new security policy, my background allows me to judge its impact in a much more well-rounded way: how long will it take to implement? Will it affect our engineers’ productivity? Could it cause any issues for our customers? Should we inform our customer support team so they can be better prepared if tickets are raised because of our changes?

Having been there and done that really helps me put myself in others’ shoes and anticipate issues more easily, making us a less siloed, and more integrated team overall.

Question 5 💭

You’ve been a strong advocate for moving away from the traditional 'police officer' role of security teams. What are some effective strategies you've implemented to make security teams more approachable and viewed as partners rather than roadblocks? How have these strategies improved collaboration and compliance within the teams you've led?

Answer 5 🎯

The biggest one is the fun part, which I already touched upon, so I’ll go with another one: speaking the same language.

I often get asked: Why? Why do we need to do this? Why this way? I think the worst answer we can give as security professionals is “because of compliance”. I heard this phrase many times as a software engineer and it made me shrug every time. I believe it is crucial to be able to explain to people in engineering, support, marketing, design, etc., why we do things the way we do them, using their language, relating it to their day-to-day tasks. In most cases people go from “that’s a stupid policy” to “oh, that makes sense”. And sometimes the policy is stupid, and we end up improving them thanks to the feedback!

To help with this, Tradeshift’s application and infrastructure security teams don’t have any analysts, everyone’s an engineer, working with code on a daily basis. If we discover a vulnerability within our platform, we’ll typically assign it to the owning team, but every now and then we’ll dive in and fix it ourselves - which keeps us on our toes, but also shows engineers that we really are on the same team.

Question 6 💭

Training sessions are crucial for keeping security top-of-mind without dampening the team spirit. From our conversations, it sounds like you’ve had some success with them in making these sessions both fun and educational. Can you share your approach to designing these training programs? What tips would you give to other CISOs looking to implement similar engaging and effective security education within their teams?

Answer 6 🎯

There are three key pillars I always keep in mind: know your audience, tell a story, and have fun.

Knowing your audience sounds simple, but I think it is the hardest one. People remember things that are relevant, so it’s important to tailor the contents to the audience. Talk about those people’s tasks, problems, needs. Use examples, languages, and frameworks that they work with. It’s also vital to pay attention to people’s faces: do they look like they’re having fun? Do they look confused? Don’t get stuck looking at your slides (nothing wrong with glancing at them), as a presenter you need to be looking at the audience and reacting to them.

Tell a story is all about the structure of your presentation - is it just a collection of slides, or do they amount to something more? I like to take the audience on a journey: starting with a problem, laying out the foundations, then working in collaboration with the participants to slowly understand the topic, to finally solving the problem.

Tell a story is all about the structure of your presentation - is it just a collection of slides, or do they amount to something more? I like to take the audience on a journey: starting with a problem, laying out the foundations, then working in collaboration with the participants to slowly understand the topic, to finally solving the problem. It’s also a very dynamic story - I never deliver the same training in the same way, because the story is always tailored to the people listening to it. I would never use Bob and Alice as characters, I always pick people from the audience. It’s such a tiny change, yet it makes the whole journey much more relatable because we’re talking about people we know.

‍Having fun can be tricky. Have you ever delivered training that you didn’t really care about? That’s a surefire way to make sure your audience won’t care either. You having fun during the presentation is a prerequisite of the audience enjoying it. To flip that around, if you’re enjoying doing the presentation, the audience might enjoy watching it. You need to show that you care, your passion and zeal, that you think what you’re talking about is cool, because it is your job to spread the fun and the knowledge! And if you don’t like your own slides, just change them until you do, even if it morphs into something slightly different in the process.

Question 7 💭

Balancing technical expertise with a deep understanding of business needs is key for any CISO. How do you ensure your security team stays in-the-know of business and effectively communicates with non-engineers? What strategies have you found most effective in fostering this kind of cross-departmental understanding and cooperation?

Answer 7 🎯

We use a multi-faceted approach at Tradeshift: part of a CISO’s job is to liaise with other senior leaders in the business to make sure we’re up to date on what’s going on. It is then equally important to relay the relevant information to the security team. This is obviously a top-down approach, so the second facet bypasses the chain of management entirely: members of Tradeshift’s security team do regular security sinks (yes, a trivially simple joke, but it immediately sets a friendlier tone) with many other teams in the organisation. These are 1:1 meetings where we just show up and ask “what’s up, what are you working on these days?”, which allows us to get an understanding of what’s actually being worked on (as opposed to the equally valuable high-level strategic picture we get by talking to higher management), and it also gives us the opportunity to identify any items that might be of interest to the security team, such as integrating with a new vendor for customer support, designing a brand new component, etc. Finally, as mentioned above, being able to speak the same language is crucial here as that’s what really allows this to be a friendly conversation where we’re both working towards the same goal.

We expect software developers to be aware of the basics of software security even though that’s not their primary focus; similarly, I think we should also expect the technical members of the security team to know the basics of governance, risk, and compliance (GRC).

Question 8 💭

Transitioning to governance, risk, and compliance involves a significant shift from hands-on technical work. What were the key learning points for you in this transition, and how have these insights shaped your leadership in the security space?

Answer 8 🎯

Although I did have a lot to learn, it also wasn’t a dramatic change. We expect software developers to be aware of the basics of software security even though that’s not their primary focus; similarly, I think we should also expect the technical members of the security team to know the basics of governance, risk, and compliance (GRC).

As part of that, I had been working with our GRC team for quite some time and thus had a decent understanding of the domain by the time I took on the CISO role. That’s not to say that I knew everything, and I think a little humility goes a long way: owning the fact that nobody is perfect instead of trying to save face and pretending. while, but also jumping at the opportunity to learn. Personally, I found it helpful to dive in and take on some day-to-day tasks, such as answering security questionnaires or audit fieldwork.

Question 9 💭

Building a positive security culture can be challenging. What strategies have you implemented to ensure that security is both respected and embraced within the organization?

Answer 9 🎯

Our values as Tradeshift’s security team are approachability, fun, and technical excellence (not a prioritised list). I’ve already talked about fun a lot, but I really cannot emphasise its importance enough - it really is a cornerstone of our security culture.

You mentioned respect, and that’s where technical excellence comes in. Our application security team owns a few services and production, and they actually have the highest internal SLAs within Tradeshift. Granted, it’s small even among microservices, but it still shows other teams that not only do we understand security, we also hone our skills as software engineers. That, in conjunction with us jumping into random codebases to fix a security issue every now and then garners a decent amount of respect from a technical point of view.

Approachability is another key element when it comes to respect, and it’s also what ties our entire security programme together. Technical excellence and fun are important, but without approachability it could still lead to an elitist security organisation that nobody wants to work with. Approachability for us means remembering the fact that we’re dealing with people. That no matter how obviously wrong something might seem to us, we had to learn those best practices, too. While security is crucial, a business isn’t about security - security is about the business.

Question 10 💭

With all the advancements in AI and the ongoing challenges in dependency management, what developments in cybersecurity are you most excited or concerned about? How do you think these will shape the future of security practices across the industry? What steps should security leaders be considering now to prepare?

Answer 10 🎯

Patching dependencies is not fun. Modern tools can help us navigate and prioritise the hundreds of vulnerability alerts that plague organizations. At Tradeshift, we barely even look at them, instead, we opted for continuous, automated patching. Sure, we still need to deal with breaking changes, and we still take critical zero-days very seriously, but I’m quite excited to see how AI will be able to automate even more of it away: detecting when a version bump affects us in any way, being able to automatically take care of major version updates, etc.

As for AI in general, I think all security leaders need to embrace the idea, and stay on top of AI’s capabilities and limitations. We also shouldn’t be thinking of AI as its own box (like we might say frontend security, infrastructure security, mobile security, etc.), but rather as part of our foundational knowledge.

As for AI in general, I think all security leaders need to embrace the idea, and stay on top of AI’s capabilities and limitations. We also shouldn’t be thinking of AI as its own box (like we might say frontend security, infrastructure security, mobile security, etc.), but rather as part of our foundational knowledge. AI will be everywhere: part of the products we’re trying to secure, part of our security tools we use to secure ourselves, part of our production infrastructure, our CI/CD pipeline, our business analytics, our risk management process, our compliance process, our data classification process, etc. Finally, we need to not only focus on AI security, but also making sure we maximize the efficiency of our security team and processes by leveraging AI where it makes sense.