People, Process, and Technology

Tune in to this episode of Ask A CISO to hear:

• What his first steps were after joining Jofform as the Head of Internal Security
• His experience trying to acquire new hires to strengthen his team
• Why he thinks problem-solving skills can be bolstered with proper run books and playbooks
• His take on the right approach to people, process, and technology, the three pillars of information security
• His approach to Security by Design
• Johannes' main takeaways from the recent RSA conference

About The Guest: Johannes Wiklund

Johannes Wiklund is the Head of Information Security at Jotform, a fast-growing Software-as-a-Service company offering a full-featured form builder that makes it easy for end-users to create customized forms easily without having to code.

Johannes is an IT and cybersecurity leader with extensive experience in starting up and implementing security programs, delivering and operating hybrid cloud critical infrastructure, and architecturing cost-saving enterprise solutions.

Johannes was a previous speaker at the RSA security conference and is a frequent speaker in the BrightTALK forums.

About The Host: Paul Hadjy

Paul Hadjy is co-founder and CEO of Horangi Cyber Security. 

Paul leads a team of cybersecurity specialists who create software to solve challenging cybersecurity problems. Horangi brings world-class solutions to provide clients in the Asian market with the right, actionable data to make critical cybersecurity decisions.

Prior to Horangi, Paul worked at Palantir Technologies, where he was instrumental in expanding Palantir’s footprint in the Asia Pacific. 

He worked across Singapore, Korea, and New Zealand to build Palantir's business in both the commercial and government space and grow its regional teams. 

He has over a decade of experience and expertise in Anti-Money Laundering, Insider Threats, Cyber Security, Government, and Commercial Banking. 

Transcript

Jeremy

Hello, and welcome to today's episode of the Ask A CISO podcast. My name is Jeremy Snyder. I'm hosting today's episode, and I'm delighted to be joined today by Johannes Wiklund.

Johannes has 25 years of experience across broad areas of IT and cybersecurity. For the past seven years, he's focused on leveling up security programs for late-stage startups. As Jotform's Head of Information Security since 2021, Johannes is responsible for the strategy and implementation of the Information Security program that safeguards the data entrusted to Jotform, a fast-growing Software-as-a-Service company specializing in no-code forms.

Johannes is a past speaker at the RSA security conference and a frequent speaker in the BrightTALK forums. Johannes enjoys contributing to the discourse on advancing cybersecurity and he lives with his family in Virginia, as I do myself.

Johannes, thank you so much for joining us here today. We're delighted to have you.

Johannes

I'm happy to be here, Jeremy.

Jeremy

Awesome. Awesome.

So I wanted to focus today's conversation on some of your recent experiences because I know you recently joined Jotform as of 2021, it sounds like, and I'm kind of curious from your perspective as a leader, in Information Security, what are the first steps you take when you join a new organization? Where do you focus your first efforts in security?

Johannes

Well, thanks so much for that intro.

So I do believe that when you start a new company, you have to level-set and you have to sort of understand what you're starting from.

So in my case, I started with Jotform last October. And, you know, first of all, I want to assure you that I did not have to start from scratch here. I inherited a good team and many capabilities were already in place. However, I do believe that performing some kind of a gap assessment in your first 90 days is key. So what I wanted to do then is to bring the security program to the next level I had to find out where could ... The assessment really is there to find out where could we add the most value by adding some maturity?

So I did that assessment. I presented to my CEO who was actually very receptive to my recommendations and then created a roadmap which I'm now in the process of executing.

Jeremy

Okay. And when you did that initial assessment, do you focus on, kind of, let's say, the teams and the skills, or do you focus on the operating procedures and the runbooks or on the tooling and the visibility, or is it some of all and how did you think about the balance there?

Johannes

That's a good question.

I think that it's a little bit of everything. So first of all, it's important to really understand the architecture, you know, to be able to understand if there are any weak points. But also to understand the processes and ultimately to understand the people. Now, when it comes to team management, I typically don't wanna shake things up too early.

Like I said, I inherited a good team here, so there was really no reason to make any material changes right away. The company is growing, you know, and with that, I've been lucky enough to be able to do some hiring on my own, and hiring both in cloud security as well as compliancecompliance. So about six months into the job, I found there was the right time to make some team management tweaks just to streamline responsibilities.

Jeremy

Yeah. Have you found hiring to be particularly challenging in the modern landscape?

I mean, we hear on the media all day and all night about companies struggling to hire, and I know from my experience in the cyberspace for the past five, six years that we've talked about a skills gap and a lack of workers.

So is it really super difficult in the modern climate to hire?

Johannes

I would say yes, especially with niche areas, such as cloud securitycloud security.

So, you know, on pretty much on day one, when I started, I opened up a rack for a remote North America-based cloud security engineer and it took me literally six months to find and hire the right candidate.

Jeremy

Oh, wow.

Johannes

And you know, one of the things about Jotform that I really like is everyone here is technical. And even my CTO still codes, so we do expect everyone who joins the team to be technical as well. You know, everyone needs to be hands-on, you know, roll up their sleeves. We're not, we don't hire paper pushers.

We're too small for that.

Jeremy

Right.

Johannes

So everyone has to contribute with hands-on real-world skills, and that's why we actually ask candidates to pass a technical screening in both Python and Linux. I'm currently reading up on Python forensics myself. At the end of the day, you know, technical skills are really important, but I also look for team members who can communicate, who can problem solve, and ultimately bring a positive attitude about getting the work done.

So all of that is important in finding the right candidateright candidate that will fit in and, you know, it's more important to find the right candidate than to get someone in the door quickly.

Jeremy

Yeah. And with that, certainly, that's a great way of thinking about it. And especially given kind of the culture of the organization where everybody's kind of a doer, if you will, right? Everybody has to do things as you say.

Do you find that you need to think about kind of finding that attitude first and then maybe training for some of the technical skills gap? So if you found somebody, for instance, who was a Linux whiz with like a little bit of Javascript, but maybe not that Python exposure, you would cross-train on Python, or were you really kind of set on a need to find somebody who can step in right away with the right skills for our environment?

Johannes

We're relatively flexible. So it's really about having the right technical competency.

What I did find though, is a lot of candidates put things on the resume that doesn't really measure up to hands-on capability. Even if they've done cloud security, they may have been part of a team where essentially someone else was actually doing the implementation and they were mostly coordinating. And, you know, those are the kind of candidates that we filter out by having technical screenings.

But for example, if you don't have Python, we'd be happy to test your bash scripting skills instead, and just ensure that you can contribute to that hands-on level.

Jeremy

Yeah. Yeah. That's fair enough. And I think one of the other things you mentioned there that I have found super important for my own career in kind of IT and cybersecurity, you know, I was a practitioner for the first 12 years of my career. I ran data centers for a couple of SaaS companies and then a video game company.

We always had cyber as a part of IT, but that troubleshooting mindset is something that I think is really hard to train later stage in people's careers, if they haven't kind of grown up with it in terms of, I think about kind of situations that I've encountered where something was working and then all of a sudden isn't working.

And there's any number of changes that might have happened and kind of going through those changes systematically to figure out what was the change that made it not work is such a crucial thing and if you don't have that kind of systematic approach to troubleshooting, I find that can be really difficult to kind of teach people.

Any tips on that, or does that match your experience as well?

Johannes

Yeah, I think it matches. I would just modify that a little bit by saying that it's a combination of kind of harnessing the individual's native problem-solving skills with having some documented processes as well.

So I've found that in incident response, it's really important not to just kind of poke around and say, let's see what happened here. You actually have to have a playbook and execute the playbook and reasonably organize the manner, otherwise, you run the risk of actually ruining your forensics approach, right?

So yes, having people who can troubleshoot on their own and having that kind of curiosity and mindset and knowing what to look at is definitely key. And now if you can take those people and harness their power and experience and have them actually create those run books or playbooks, I think that's even more powerful because then now you can scale the team.

You can have more incident responders that follow a consistent approach, and ultimately that helps mature the entire company.

Jeremy

Yeah. Yeah.

So we've just touched on kind of two of the pillars of what you often hear kind of, you know, people, process, and technology. We've just talked about, kind of, people and process. So from your view, thinking as a security leader overall for a global organization, when you think about people, process, and technology, how do you think about it in, let's say, in terms of a successful security program?

What elements of each do you need to have, or how do you tie it all together? What's the right strategy or the approach to think about people, process, and technology?

Johannes

That's a great question, Jeremy, and thank you for framing it up that way, because those three pillars really are the legs of the stool, if you will. And in order to level up your security program, you have to raise all three legs.

You know, going back to 2016, already I was presenting security updates to the Board of Directors about twice a year, and I typically do frame my updates around these three pillars, if you will, right?

In my previous company. In fact, I was building a security program from the ground up, where I really had to focus on all of those attributes, right. Now, in talking to folks in the industry, I found kind of early in one cyber career, there's very tempting to focus on toolstools.

Jeremy

Yep.

Johannes

While you take the vendors with a grain of salt, there's at least a willingness to believe that, Hey, if I just had the right tool, it could solve all my problems, but you know, I've also seen a fair amount of tool implementations fail because they're not truly operationalizing their value. So one example would be ...

Jeremy

So let's take for example between the tool and the procedure?

Johannes

Well, the gap would be, you know, a SIEM tool, for example, that's collecting a bunch of logs essentially storing them for compliance reasons, but failing to really define the alert conditions to actually provide actionable alerts. Right?

Jeremy

Okay.

Johannes

So that's why I believe that process maturity is actually very important to fully take advantage of your investment in tools. And so I mentioned, having joined a previous company where I had to build everything from scratch and, so I had a security policy that I could basically fan myself with to keep cool at night, but there was not much behind it. Right.

So I spent a fair amount of time actually building out the security standards, as well as the procedures for anything from secure coding to incident response. And I found that following those procedures adds a lot of value, but like I previously mentioned, I do also believe that attracting and retaining the right talented people, being the third leg of the stool is really important.

And upskilling your existing people, you asked a little bit about that, and while I wanna assume a fair level of baseline knowledge, I'm also working on upscaling not only my own team, but the entire engineering team. One of the programs that I'm introducing is our role-based security training program that's gonna actually help our developers be more savvy in terms of secure coding standards and actually be able to avoid common mistakes that lead to, for example, the OWASP Top 10OWASP Top 10 web application vulnerabilities.

So at the end of the day, upskilling your workers and bringing the people dimension up to par with the processes and tools is really just as critical.

Jeremy

Yeah, absolutely. And that makes perfect sense.

And I think all of us in the industry, like you said, we tend to really focus heavily on the technology side because a lot of us are technologists by training and by background. Many of us come out of network engineering or we come out of software engineering or coding. And so we tend to really go to software and tools as kind of our first instinct.

But I agree with what you're saying in order to kind of scale the organization and to bring people in and make them productive, it's really important to have that process.

And then if you don't have the people in place to run it and you can't keep them, that's a problem as well. You talked about kind of joining this previous company and building a security program from the ground up. I don't know if it was at that company or another one, but I know you've done a lot of work on the cloud security side.

What was your original approach to cloud security because there's a lot of messages out there around different strategies towards cloud security? Some who would advocate for hard centralization and make sure everything goes through a central kind of authorization system, like a CASBCASB. And others who are much more on the kind of shift-right, you know, give developers full access and focus on kind of real-time monitoring and visibility?

What were your approaches and how have those changed over time?

Johannes

Yeah. So I was a pretty early cloud adopter and this was many years ago, but, essentially we were running our production workloads on-prem. And while I was building out a physical data center for that purpose, I also opened our very first cloud account because we really needed the speed of deployment for our dev-test workloads. So at the time, we were primarily using the cloud as a VMware replacement. So, you know, building EC2 instances and the like, you know, like for like with our on-prem architecture.

Now I have to tell you, first of all, that this is not really the most cost-effective way to use the cloud. I then moved on later to auto-scaling server groups and then using tools like Terraform.

And finally, I've also tried some of the use cases on serverless, but, you know, as the cloud evolved itself, so did the security so early on, really, I felt that the native security tools available from the cloud providers themselves were pretty weak. So, it took several years for them to catch up.

So in the meantime, I was insisting on things like third-party firewalls on my cloud accounts, and that sometimes put me at odds with my engineering counterparts. Like you said, they wanted the flexibility, the speed of delivery. They felt security was slowing them down but the danger with the cloud is that an engineer armed with nothing more than a corporate credit card can essentially stand up a whole infrastructure by themselves. And that they are typically not security experts, especially not at the network level.

So while you said us as security professionals often come from a network background, most software engineers do not, right? And they don't really understand what leaving the SSH port open to quad zeros might imply for their server security, right? Just as one example: so I personally experienced several network intrusions that were due to really poor hygiene and in the cloud account using native security tools.

I will say that, you know, most of the cloud providers have now upgraded, brought their solutions up to the next level, but there're still some capabilities that you just can't get without a firewall. So, you know, as me playing defense, I remember at one point I had to sort of backdoor in a requirement for a firewall into one project by creating a user story that called for an egress filter that supports fully qualified domain names, a requirement that really could only be met with a firewall, but essentially folks were a little bit allergic to what they thought were legacy concepts and having a lack of understanding of network security.

You know, I had to put it in actual user story terms what is the functionality we're trying to achieve here in order for the requirement to get approved.

Jeremy

Yeah. Yeah.

And do you think your approach to cloud security has changed over the years? I mean, for instance, in the modern world, would you still focus on kind of network layer ingress-egress security, or would you focus a little bit elsewhere if you're starting a new cloud security project? So, first of all, my new organization now is a hundred percent in the cloud. We don't even have an on-premise data center.

So I think it makes absolute sense for a SaaS provider like ourselves. Now we do take data security very seriously and our end customers trust Jotform with a lot of personal data. We even have a HIPAA-compliant solution where all the data is full-disk encrypted and only the customer holds the decryption key.

So we architect our solutions in a way that security is built into the extent possible. And we do invest heavily in security monitoring as well. So today I do believe that the native security tools have pretty much caught up. I'm using third-party tools for some layers of the infrastructure if you will. But we also take care to architect our solution to be cloud-agnostic.

So today we're actually using two different cloud providers and I have the flexibility to shift workloads, you know, based on either cost or other business requirements.

Jeremy

Yeah. Yeah. And you mentioned something in there that kind of brings me to another topic.

So you mentioned that you're building in a secure way. And I think about kind of this buzzword of shift-left, or I like to think of it as kind of security by design and, you know, kind of, if there's two strategies, security by design and security by defense, I certainly believe that security by design is super important going forward and it's not one or the other.

It's just a question of how much of each you choose to use and which processes or which kind of approaches from each side you might choose to use. I think I saw somewhere that you gave a talk about security by design. So it sounds like you're a fan of this approach as well, right?

Johannes

Yeah. So thanks for that.

I definitely am trying to, as part of my leveling up strategy, is to bring a little more secure by design concepts here as well. So one of the things is I introduced the concept of product-based risk assessments. So we have Agile teams that are designing and building new products that are essentially complementary feature sets to the baseline Jotform product.

And what I do is I sit down with them early on and basically I ask a ton of questions around application security, data security threat modeling, fraud, and abuse use cases. And essentially the question is what could go wrong? And let's just think through all of the things that could go wrong early while we're still in the design phase. Because as we all know, it's much more cost-effective to solve a problem that you find in the design versus, you know, once the system hits production.

Although we do have the ability to fix things in production pretty quickly as well. You know, as a software, as a service company, we actually deploy code to production as many as 200 times per week. But even having said that though, securing the product from the design stage is truly important. So the risk assessment is really one facet of that. Another facet that I'm working on is creating a security champions program. You know, so that's one way to extend your reach if you will.

So as much as I would love to be able to hire 35 people over the next year, that's not gonna be possible. And I can never put an AppSec person on every single Agile team, right? So the best method for me is to really recruit someone who's already on that Agile team playing a different role, whether it be backend developer, frontend developer, even product manager, someone who's interested and passionate about security.

And then I can support them from behind the scenes and kind of give them some training, give them things to look out for, and just basically establishing a dialogue, right? Because that person can then become my eyes and ears. They'll tell me what's going on on their team. They're someone that I can now use to give messages to that team as well.

So in many ways, that's a capability that a lot of companies are looking to leverage into their product development. And it's actually something that I heard a lot of talks about at the recent RSA conference as well.

Jeremy

Yeah. Yeah.

Well, speaking of RSA, you know, we've had a couple of conversations on this podcast with people who were there and we've heard different themes that stood out to people around, you know, zero trust, XDR, MDR, cloud security, Kubernetes security.

What were some of the things that stood out to you?

Johannes

So I'm sure every attendee is gonna have a different experience.

There were 42,000 attendees and 350 plus track sessions. So I think you can pick and choose and get to hear a bit of what you want to hear. But, you know, besides the security champions and the shift-left that we already talked about, two other things that I felt were in focus this year was identity and incident response.

Jeremy

Okay.

Johannes

And so, regarding identity. So Rohit Ghai really focused it up in his keynote because the theme of the RSA conference was transformation. And, you know, he made the statement that identity is the only constant. And while we, there will always be new technology, technology remains vulnerable. We need to build solutions around identity because you know, most cyber attacks are due to compromised identity.

So maybe, Jeremy, this year can be the year that we finally stop prioritizing convenience over security.

The first best major step is to implement MFA for everyone. You know, there were also a lot of talk about identity helping to confirm the veracity or truthfulness of data. And, you know, that's another interesting dimension that, you know, where identity as the only constant is starting to take more of a front seat. So I saw that as being a big trend.

The other hot topic was incident response and a couple of the prominent vendors out there who focus on incident response were summarizing some of what they've seen or, you know, helped client overcome over the last year.

Malware, ransomware are still high on the list and something like 94% of all malware actually comes in through an email vector. So, you know, email defense, whether it be technical controls as well as people controls, educating your end-user on what to look out for continues to be important, but also an important, you know, facet of incident response is to make sure that you have those playbooks and you're able to respond quickly.

I heard one talk where the incident responders were actually found to sort of just watch the attacker. They knew they were in the environment and they said, we just wanna see what this person does next. Right? They didn't have a plan, really a playbook for how to shut down the attacker's access. So, you know, cyberattacks will always be here and nobody can say that they're totally immune and we just need to be ready when they do come.

Jeremy

Yeah.

Well, it's back to one of your original points about the three pillars of a good security program is a process. And if you don't have that, that process in place, you don't have those playbooks, it's very challenging for your people to know what to do. So I can certainly understand that. And I think it really reinforces the point.

So I guess, Johannes, that's been a great conversation. We're coming up to time here, I guess just one last thing that we like to ask people if they have one theme or one recommendation that they would give to the audience. And we've covered a lot of things. We've covered kind of the people, process, and technology. We've covered security by design, security champions.

If you had, you know, just one actionable piece of advice that you want to give to somebody who is trying to improve their security, that could be security by design, that could be security through monitoring. What was that one piece of advice be?

Johannes

I think my one piece of advice is partner with people from outside the security organization and find a way to make security everybody's mission. And so I try to use that as kind of, as a common thread through a lot of my communication, and if someone brings me a good idea, I thank them. You know, I give them the positive reinforcement and feedback.

If I have to announce some new effort, get people on board, I play up the fact that this is part of making cybersecurity everybody's mission. And I think that people really appreciate the inclusion, you know?

Jeremy

Yeah.

Johannes

Cybersecurity is no longer the team of "no", right? We're the partner of the business. We're not here to tell them what not to do. We're here to help them do their job, but to do their job securely. And it's more about the messaging and communication. the advice I would give is to really develop those partnerships with your stakeholder organizations and make sure that they feel that you're part of their team.

Jeremy

Yeah. Yeah.

I think that's great advice. That's great advice.

And I think that is a great note to end today's conversation on.

Johannes Wilklund, thank you so much for joining us on the Ask A CISO podcast. It's been an absolute pleasure to have you.

Johannes

Thank you so much. Pleasure all mine.