Johannes Wiklund of Jotform

Jeremy At Firetail (00:02.83)
All right, welcome back to another episode of Modern Cyber. I'm delighted to be joined by somebody today that I happen to know personally. He lives local to me. We get together from time to time. He was also previously on the Ask a SISO podcast. So this name may be familiar to him. I am delighted to be joined by Johannes Wicklund. Johannes is the head of information security at JotForm. And in that role, he's responsible for the strategy and implementation of the information security safeguards that protect the data entrusted to JotForm.

a powerful SaaS application for creating online forms. specializes in leveling up security programs for late stage startups, implementing AppSec, cloud security, incident response and compliance functions, including HIPAA, SOC2 and FedRAMP slash StateRAMP. That's a lot of range of compliance coverage, Johannes. I don't know where you find the time to do it all, but thank you so much for taking the time to join us today.

Johannes (00:53.901)
I'm really happy to be here, Jeremy.

Jeremy At Firetail (00:56.685)
Awesome, and I didn't even mention like your ISE 2 certifications and all of these other things. I'm curious about how do you actually manage your schedule as a head of information security, a kind of a chief information security officer role?

Johannes (01:12.247)
Yeah, that's a good question. So it's really about being able to keep multiple balls in the air at the same time and getting involved where needed. So I've been at JotForm close to three years and about six months into my tenure, I reorganized the teams. created an AppSec team, a cloud infrastructure team, an incident response team, and then governance and compliance team.

So I spend my day sort of across all of those four functions, but I deep dive, you know, where needed, when needed. So, you know, being that we're a SaaS provider, I definitely spend a lot, a lot of time on product security and making sure that, you know, my developers don't create issues that are going to negatively affect the security of the company's data.

If there's anything that keeps me up at night, it's data security, right? Because JotForm, you know, we have 25 million users out there and that includes big corporations like McDonald's or Mattel, for example, and all of these customers entrust us with securing their data. So, you know, with that in mind, I've also built a 24 by 7 incident response team so that, you know, if we do see something suspicious, we can respond right away.

And so I spend a lot of my time, you know, in incident response and looking at suspicious alerts and behavior and mentoring that team. And also a lot of time with product security and really making sure we're architecting and building a solid

Jeremy At Firetail (02:49.299)
Well, I want to talk about both kind of the product security aspect as well as the data security aspect. Maybe let's start with the product stuff because you mentioned that last. I hear a lot from organizations and, frankly, in the work that we do on API security, we see that actually the number one, number one, number two and number three issues are all in the design of the application. Like the top API security risks are all around that. And in talking to security leaders, when you...

have a conversation around, how are you making the security of your own product better? I hear a lot of things. hear, we're running a, you know, eliminate vulnerability program. You know, we're shifting left. Or I hear about, we're doing red teaming and we're hiring, you know, bug bounty hunters and things like that. How do you think about it and what has been most impactful and beneficial to you guys at JotForm?

Johannes (03:41.603)
I think to be honest, you have to have more than one iron in the fire, clearly, right? So there's no one trick solution, but I think the bug bounty programs actually work pretty well. So George form, we're, we have a private program that we run through hacker one. So it's by invitation only. But we do, you know, extend new invitations really on a monthly basis. And, you know, we've actually gotten, you know, some pretty good reports.

Jeremy At Firetail (04:00.166)
Okay. Yep.

Johannes (04:11.313)
and are able to essentially stay on top of many things. But then we also have our own internal tooling. You I noticed you had Tanya Janko on the program a little while back and she is now with Semgrep and Semgrep is one of the tools that I'm using actually for static code analysis. And I'm finding that integrating that in the CI -CD pipeline can be quite effective.

Not necessarily to break the build because everyone hates breaking the build but at least to create action items So we're basically creating github actions that are flagging different code components for review and You know, it's really helping my team stay on top of things as well as for the development team just to be on on alert or on notice that Some of their code commits may need need review

Jeremy At Firetail (05:07.873)
Okay, so code commits might need review, you flagged something out of there. So that's one iron in the fire, and you've got the bug bounty program. That's kind of another. Those two together, are those kind of the foundation of the strategy for you? Or are there other things as well?

Johannes (05:19.246)
Right?

Johannes (05:25.551)
Well, of course we're running monthly vulnerability scans as well. And while the vulnerability scans don't catch problems with my custom code, they do catch problems with shared libraries and code that we've imported, right? So we're actually, one of the pushes this year is to be better at creating a software bill of materials and truly understand.

all of the shared components and making sure that they stay up to date. As our application has grown organically over time, there's a lot of libraries that have been imported and some of them are used by multiple different product teams. So we have an architecture group that is really in charge of streamlining and understanding what components are we gonna continue to use and how do

retire or deprecate some of the ones that you know maybe are less mature and that we don't want to continue to propagate.

Jeremy At Firetail (06:27.851)
And do you think about also incorporating threat modeling into the product security planning and let's say like architectural changes coming down the road? Does that factor in much as well?

Johannes (06:39.567)
So a little bit. I really, guess, threat modeling is really kind of a broad topic, right? So I think where I'm using threat modeling more is more on the cloud infrastructure side and really understanding emerging cloud threats and making sure that my cloud security posture is up to date.

And I'm using things like CIS benchmarks to essentially secure not only my cloud accounts, but my Linux operating system, making sure that they're tuned to eliminate or reduce the vulnerabilities as much as possible.

Jeremy At Firetail (07:26.899)
Okay, okay. So in that case, when it comes to cloud accounts, it's probably a lot of, you know, double check configurations, make sure that there's no weaknesses in infrastructure as code or no misconfigurations in infrastructure as code that are going to get pushed out with each new release or each update or things like

Johannes (07:44.461)
Yeah. And so this year I've actually been working a lot with infrastructure as code because that's a fundamental component of a new product that we've spent a better part of a year architecting and is finally going live this week. And that's JotForm for government.

Jeremy At Firetail (08:04.488)
Okay, so let's talk about that. So I hear, you know, we all know about the cloud platforms, we know about the public regions, and now we hear more and more about the government regions coming up and even, you know, secret regions, private regions, all these types of things. What's the goal there and what's kind of been the process for getting that going?

Johannes (08:24.517)
Yeah, so JotForm has always been a cloud native application and we run primarily in Google Cloud. But with government, they always have more robust security standards than anyone else, right? So we are already SOC 2 compliant. We're already complying with regulations around HIPAA. We have PCI.

And now we're taking that to the next level. So we took our most secure enterprise product and we re -hosted it on a FedRAMP certified version of Google Cloud. And we're in the process of implementing all the NIST 853 controls. So what we elected to do as a first step as we go live now is we aligned it with StateRAMP. And so we've enrolled in StateRAMP's security snapshot program, which basically helps

validate our artifacts and security controls to make sure that we're on the road to full compliance and then we're working toward full audit and compliance with state ramp within the next 12 months and we're targeting primarily state and local governments as well as higher education institutions who are receiving some sort of government funding.

Jeremy At Firetail (09:45.99)
And as you've gone through that process, a couple of questions come to mind. Number one is, what just worked the way that you expected it to? And I guess more importantly, what didn't work the way you expected it to? When you think about, you okay, you were always cloud native, but now you're moving over to this kind of specialized region or that may or may not have the same controls in place and whatnot. How has that process gone for you guys?

Johannes (10:11.107)
Yeah, so maybe I'll talk about a few examples. So one example would be the actual infrastructure as code. You know, so we felt strongly about not just kind of copy pasting and creating a server and the new cloud region. We wanted to build a server from the ground up. So it was really about understanding all the components that we needed and creating a repeatable process to build that using infrastructure as code.

And then, you know, of course, with NIST requirements, everything has to have approvals and a lot more controls. So you take kind of a fast moving cloud company and you add a layer of maturity and say, you know, here's what we have to do to prove that we're actually, you know, following all these security controls. And that's the result of that really is our government product. it's everything that worked well is really, you know, the

the power of the application and then we just added some security maturity to ensure that we're not deploying things without having them fully approved and fully tested.

Jeremy At Firetail (11:21.734)
Got it, got it. And was there anything along the way where you were like, wow, we really didn't expect that X service wouldn't work the same way on GovCloud? Because I know one of the things that some companies face, especially if they are cloud native, is they'll use some of the services from the cloud provider. Maybe that's like an identity store or a secrets manager or a particular like, let's say, network infrastructure or network topology.

And then some of the GovCloud regions from historically have always lagged behind the public regions and may not have the same set of services available. Was there anything that kind of like tripped your team up along the way or?

Johannes (12:00.633)
Yeah, I think historically I would agree with you and with my previous company, I actually built two FedRAMP compliant systems that were hosted in AWS. And at the time we did run into some of those challenges, but you the good news with Google Cloud is that Google Cloud has certified really all of their components and all of their US regions to be FedRAMP compliant at the moderate level.

And as I mentioned, our application is cloud native and is using a lot of, you know, internal cloud features from Google itself, right now. However, yes, there were a few third party components where we had to switch gears and say, say, we're not going to be able to use, you know, x, y, component. And we just had to change the architecture. But, you know, I guess the only thing

From a fundamentals perspective, would say is the version of Linux we were using was the Ubuntu Community Edition and we had to switch to Ubuntu Pro for the government edition because Ubuntu Pro is the only way to really get access to some of those security patches in a more timely manner.

Jeremy At Firetail (13:16.003)
Gotcha, gotcha. That's really interesting. I think that's one of those things where you wouldn't necessarily think that the version of the Linux OS that you're using would have to change because Linux is Linux, virtual machines are virtual machines, but then the FedRAMP requirements of the environment, I guess, were the main thing that kind of triggered having to up to that next level or did I get that wrong?

Johannes (13:39.363)
Right, so part of it was the FIPS mode encryption as a requirement for FedRAMP. And then the second thing is just the tightness of the patching schedule and making sure that the vulnerability patches are available timely. And that's one thing that I think Canonical could do a little better is to make security patches available to everyone because there are different repositories for Ubuntu and...

they make patches available on a different schedule, which is a little bit inconvenient.

Jeremy At Firetail (14:15.459)
Gotcha, gotcha. And just for anybody in the audience who's kind of listening and facing the same type of process for their own organization, how long did it take you roughly start to finish, if you don't mind sharing?

Johannes (14:28.165)
Well, we've been working on this project for a better part of a year, actually, right? So we started with a gap assessment. We had, as I said, an enterprise product that was already SOC 2 compliant. And with that in mind, we did a gap assessment together with a consulting partner, and they were able to point out, you know, some of the areas that we needed to improve, both technology wise and process wise. And then, you know, with that in mind, and I guess I have

pretty small team working on it, right. But with a small team working on it, it has taken us better part of the year to get to a production ready state.

Jeremy At Firetail (15:07.447)
And were there big gaps in process between SoC 2 and FedRAMP?

Johannes (15:12.517)
I think what I would say is that SOC 2 leaves it up to the service organization to define a lot of processes, whereas NIST or FedRAMP requirements are a lot more prescriptive. They're very specific in terms of how you do things, not just what you do.

Jeremy At Firetail (15:33.365)
Yeah, I mean this is such a great point. We went through SOC 2 with our organization about, well for the first time about a year back and then we recertified just recently here and

To your point, a lot of it was we kind of looked at the processes we had, we documented them, in our case on a confluence page, probably the same for a lot of smaller organizations, and our auditors came in and a lot of it was just, okay, do you have a process defined? Do we have incidents of when that process needed to be followed and do they match up?

But what is an acceptable level of process? What is an acceptable level of, let's say, secure data handling in each of those incidents or things like that was very much left up to us. So it's interesting to hear that as you kind of get into some of those, what I think of as a little bit tougher compliance standards, it does become a little bit more and more prescriptive.

Johannes (16:25.251)
Yeah. And it becomes a little more maintenance work to make sure everything stays up to date and that we gather the evidence for all the, let's say control approvals and you know, every policy has to be signed and approved and dated and then, change control tickets for every, every change, cetera. So it's, it's a lot more evidence gathering on top of the process writing, I would say.

Jeremy At Firetail (16:52.743)
Got it, got it. And have you thought about what you can do as an organization in terms of automating that evidence gathering so that, for instance,

In our case, one of the things that we did was for our common tasks, which is things like new customer onboarding or employee onboarding and offboarding and data handling and data transfers and things like that, we created ticket templates so that we can kind of just very quickly fill those out with the evidence for each of the processes. Did you go through a similar kind of exercise there to try to facilitate and make that easier?

Johannes (17:28.761)
Yeah, it's interesting. So I just went through actually onboarding a fake employee because like I mentioned, the team that's working on dot from Gov is relatively small. And as per requirements, we're using only us citizen personnel. So that's a subset of the company to start with. Right. So, you know, I was working with my state ramp PMO and they're asking for evidence that I can onboard and off board a privileged user. And I said, well, I don't have

a new hire that's starting now and nor anyone who's about to leave. So they suggest that I actually onboard a fake employee. So we did that, you know, with HR's blessing and everyone's buy in clearly, but so we do have a ticket template through our HR system that basically will help us through the onboarding. And then we just had to do, you know, some extra work to gather the evidence for the privileged access to show that this

person that now has access to the JotForm Gov console and can SSH into those servers. And then, you know, four days later, I basically pulled the trigger on, you know, saying this fake employee is no longer working out and we need to off board in a hurry within 24 hours. So I just went through literally, this morning, I put the finishing touches on the evidence narrative that I'm submitting to state ramp that shows that that we did follow that process. So

Jeremy At Firetail (18:42.575)
Yep, yeah.

Johannes (18:56.621)
Yes, it's a little bit of templates, but certainly there's still manual work involved.

Jeremy At Firetail (19:02.852)
Gotcha, gotcha. And just one last question on this topic while we're on it, because I know this comes up in a lot of conversations. People ask us, Sita, we're a hybrid organization in the sense, well, in multiple senses, but in one sense that we actually have small office locations, but we have a ton of people who work remote. And then also in the fact that we're split between the US and Europe, both in terms of like where our employees sit, but also in terms of our customer base and in terms of like the data that we collect and so on. And we have a lot

GDPR impact on our own data, both internal and customer data. And so we've just chosen to kind of run the company on GDPR standards and follow GDPR guidelines for data handling universally, because it kind of simplifies it. And so as you think about kind of JotForm's journey, kind of again, up the compliance stack from SOC 2, where it's a little bit more user defined up to FedRAMP, do you now look at this and you say, actually, we're going to try to operate everything FedRAMP.

understanding that you can't do that with team that's not based in the US, which I know is a small section of your team. But when it comes to, let's say, like processes or operations or security controls, do you now just kind of look at the company running to FedRAMP standards universally? Or how do you think about that?

Johannes (20:18.873)
So I don't necessarily think we're ready to run toward FedRAMP universally yet. I think that FedRAMP also implies a certain number of restrictions on the customer that maybe not every customer would want to accept. But when it comes to GDPR, and certainly I would say that the FedRAMP is geared toward the US.

Jeremy At Firetail (20:37.177)
Sure.

Johannes (20:44.277)
audience, but for the GDPR, we do have the ability to host your server in Europe. And we do have a data processing addendum that we signed with our European customers. And we also do fulfill a number of GDPR requests on a daily basis. So, you know, I think it's definitely possible to operate with multiple parallel compliance frameworks.

Jeremy At Firetail (21:11.619)
Got it, got it. Yeah, I just wonder about the overhead of it. for, not for you guys, you guys are a bigger organization than we are. But for us, we looked at the overhead and we're like, yeah, we're just gonna have to pick one way to manage these things. And that's what we ended up doing. But I wanna change gears for a second and come back to something that we talked about at the beginning of the episode. You we spent some time talking about product security. How do you think about data security right now, especially as an organization that's cloud native? I know there can be challenges around

cataloging all the data that you have, whether it's in object storage or database as a service or even on a virtual disk on a virtual machine, how do you think about that? What are some of the common tools and methodologies that you look at for data protection for your own customer data?

Johannes (22:00.611)
Yeah, so I mean, one important point to remember is that we're really hosting data on behalf of our customers. So if you subscribe to JotForm, you're creating a JotForm account. And then essentially you're building forms that you're sending out to your end users to gather submissions or, you know, collect whatever data you need for your use case,

So the data storage, first of all, is 100 % fluid, right? It can be defined any which way you want. Every time a customer builds a new form, it comes with an associated table. And that table stores the data. And then the customer has the ability to export that data. They can actually use it in various workflows. They can have

you know, if it's an enterprise customer, they can have multiple different users accessing the data and they can, you know, essentially, you know, put their own restrictions even on the visibility of the data, you know, and who can, you know, approve a particular workflow, etc. So because of the fluidity of the customer data, there's no sort of one size fits all. But I think what I probably can

tell you is that the most important thing for me is to log events, right? So basically, I'm not just logging, you know, user login events and certain things like that, I'm actually logging access. So basically, if there's ever an investigation, I need to be able to say, who accessed this particular data table from this particular George form account, you know, was it a, you know,

Jeremy At Firetail (23:35.391)
Right.

Johannes (23:46.861)
If it's a enterprise customer with multiple users, I can give them the user ID that logged in, the IP address they came from, what query strings they ran or what particular data elements they accessed. So even if it's, let's call it a benign situation, there's sometimes enterprise customers will ask us what happened because they had an administrator who left the company, for example.

you know, their data was reassigned to someone else and they wanted, you know, to see if if if anything was accessed outside of the ordinary. So we help fulfill those kind of requests. But so a lot of it, I think is based on logging, you know, the application logging a lot of data. And then, you know, my incident response team supplementing that with SIM logs, you know, that really capture, you know, all of the

typical events that you would need to capture on both the application and the infrastructure side.

Jeremy At Firetail (24:52.911)
I got it, sense. Awesome.

Thanks for taking us through that. It's been really interesting to hear about kind of your journey, both in terms of the prioritization of, let's say, the different product security programs, the approach to data security, and certainly the compliance journey in launching the new JotForm GovCloud. That's really awesome. I want to change gears and talk about a couple of other things that I know are in your background and you've got a lot of familiarity with. You mentioned also that on the JotForm side, you guys look at credit card processing.

And I know you recently had a chance to talk to some people around fraud, fraud protections, fraud detection, the overall kind of state of security in the payment ecosystem. What can you share with us about

Johannes (25:38.073)
Yeah, so I was recently asked to participate in an interview on Payments TV actually, I was co -presenting with Visa and visasauthorized .net is one of our payment partners. We also partner with Square, we partner with Stripe, PayPal and a smattering of other providers as well.

through JotForm, you one of the competitive advantages is that you can collect payments and you know, so that could be, you know, because you're running an online store, you're accepting donations, you know, or whatever your use cases. And so we give you a lot of payment gateways to choose from essentially, and you can integrate those with your JotForm account. Now, you know, what's the fraud aspect to this is that

you know, we also have to watch out for malicious behavior, right? So essentially, you know, one of the things that anyone who runs a payment portal is subject to is some amount of card testing, right? So bad actor has a stolen credit card, and now they want to test whether or not they have the correct CVV code, for example, right? So they'll put in a number

you know, small dollar transactions. we have to constantly monitor the forms for certain parameters. And we have to basically put rate limits and thresholds on the number of transactions and, you know, have the ability to block, you know, transactions that seem suspicious. So we do that in conjunction with the payment processor. There are definitely multiple different options for how to integrate.

But in some of the more sophisticated integration flows, we have access to a lot of the fraud prevention tools of the payment gateway or processor themselves, because they have a much better view of, you know, how that, you know, payment account number has been used elsewhere and what would be normal versus suspicious behavior. But you know, so I guess here's where product security and

Johannes (27:56.079)
fraud prevention actually intersect is, you know, I'm getting a little more involved in actually making some product decisions around what should be part of our product because in the past we've built a lot of payment integrations, you know, for payment providers that you've probably never heard of and that most people have not heard of because at one point we thought it was a competitive advantage to have as many payment integrations as possible.

And now we're finding that, you know, some of those are only being used by four customers and they have, you know, 10 transactions per month. And then, you know, at the bottom line is that the amount of effort it takes for us to maintain that and the amount of risk that, you know, uh, exists for potential of abuse, uh, you know, may not justify, may not be justified based on the business benefit of four users.

So, you know, there's definitely some architectural decisions then in terms of what payment gateways to potentially deprecate, as well as, you know, what payment gateways you can modernize because even though we have our own PCI server and we go through PCI DSS audits every year, there are more modern payment integrations now where essentially you can bypass all of that and you send the payment account.

information directly to the payment processor. And, you know, it removes a lot of compliance headaches from from the merchant. So, you know, there's a lot of architectural decision, that's kind of one of things I love about the SaaS industry is being able to kind of weigh in on product decisions, you know, wearing my security hat, but still, you know, doing some amount of product management as well.

Jeremy At Firetail (29:31.413)
Yeah. Yep.

Jeremy At Firetail (29:52.732)
Yeah, yeah, that's awesome. I mean, I know for us, you mentioned there at the end, what I think a lot of companies face the decision of is, do we want to do this ourselves or do we want to reach out to some third party that we partner with who kind of takes this problem off of our hands, right? And, you know, I know for us, we made the decision of, we never want to store credit cards. We don't want to be involved in that. We don't want to be subject to PCI DSS compliance. So we have gone exactly the route that you mentioned is, you know, integrating with one of the

kind of modern payment providers through an API. And we just kind of wash our hands of the whole topic, thankfully. And I hope to not have to revisit that topic, but I totally get that you guys are coming from a different space.

But that's really interesting to hear your experience on that side. And I guess just to kind of close things out on today's conversation, I know something that I'm looking forward to, and I think you maybe as well, what has been lovingly come to be known as Hacker Summer Camp coming up here in Las Vegas. For anybody who's never been or never heard that phrase, it generally refers to kind of the three events that all go back to back to back there. You've got B -Sides Las Vegas, Black Hat, and then DEF CON.

with maybe like a half day of inter of overlap there. What are you looking forward to this year and what will you be doing out there in Vegas?

Johannes (31:14.307)
Yeah, so I'm going to be in Las Vegas the whole first week of August, but I'm actually not going to Black Hat. I'm going to be attending B -Sides and Def Con. And so I've been to Black Hat in the past and, but this year I decided to forego it. And part of the reason is actually some of my team members. So I'm actually bringing in about a half a dozen people from my team. So it's going to be a nice

team building activity and the team actually told me that black hat seems too corporate for them. No one was really interested, right? And, so I also looked at, you know, some of the presenters and based on, know, what's been presented in the past.

Jeremy At Firetail (31:48.604)
Yeah, yeah.

Johannes (31:58.765)
And I kind of feel that, you know, many of the more actionable doers in the field are not able to present at Black Hat. They, you know, they, I know someone who has applied four times and didn't get accepted, but instead is presenting at B -sides, right? So I'm starting to feel that, yes, there's a B -sides, you know, along every security conference, but the B -sides, the sides of Las Vegas is probably the biggest.

And I'm starting to get the feel that besides Las Vegas is really the conference for builders. If you want to build something in security and black hat is more for those who want to buy something in

Jeremy At Firetail (32:42.847)
and you would put JotForm in the builders camp.

Johannes (32:44.933)
And yes, we are much more in the builder category. then of course, DEF CON is for those who want to break something in cybersecurity. And that's always fun to watch, even if you're not a breaker yourself. But yeah, we're coming with an open mind in terms of learning how to build and optimize our home build solution, as well as understanding how people may break.

solutions and stay ahead of that. you know, this year, I'm, you know, if I could put anything on my name badge, it would be not buying software.

Jeremy At Firetail (33:18.854)
Fair enough, fair enough, awesome. Well, on that note, I think that's a great place to kind of wrap up today's conversation. Johannes, thank you so much for taking the time to join us today on this episode of Modern Cyber. We look forward to hearing more from you and to those in our audience, please, if you've got a second, give us a rating, give us a review. And if you know somebody who would like to come on the show or if you yourself would like to come on the show, please just reach out to us at any time. Johannes, thanks one more time.

Johannes (33:45.187)
Alright, it's been a pleasure to be

Jeremy At Firetail (33:47.61)
All right, to our audience, we will talk to you next time on the next episode of Modern Cyber. Bye

‍