Security Confidential S4 E10 Fredrik Oedegaardstuen

Manoj Tandon: Welcome everyone to another episode of Dark Rhino’s Security Confidential. This is Manoj Tandon, your host, and today I’m joined by Fredrik Oedegaardstuen. I apologize if I have butchered that.

Fredrik Oedegaardstuen: People usually butcher my name too, Manoj, so maybe that’s a little bit we have in common.

Manoj Tandon: Fred is a software engineer, an entrepreneur, and has extensive experience in open source DFIR, automation, and pen testing. He has worked in an MSSP environment, in essence, and Fred is the co-founder and CEO of Shuffle. He has an extensive background in cyber, and we are honored to have him on as a guest on Security Confidential. Thank you, Fred. I understand this is your first podcast, so we’re kind of honored to have you do your first one with us.

Fredrik Oedegaardstuen: Appreciate it. Hopefully the first of many. It’s exciting. I’m trying to spread and talk more about security outwards instead of just keeping everything to myself, but I’m learning over time now. So yeah, thanks again for having me.

Manoj Tandon: You’re joining us from Tokyo, so that we have in common. I used to live there.

Fredrik Oedegaardstuen: Way better, yeah. I heard you said that earlier, right, and I’m really excited to actually hear more about that now. We decided to skip it for now.

Manoj Tandon: Right, so can you talk a little bit about that? Where do you live?

Manoj Tandon: I lived in Ebisu and my office was in Shinjuku. So I used to take the train in every day. Two trains. It was wonderful. We had a heck of a time living in Tokyo. It’s a very vibrant city. From what I remember, it’s a metropolis.

Fredrik Oedegaardstuen: Oh for sure, it’s way different for me as well. I’m a Norwegian from a tiny country with a tiny population, right? Going on the street here, in one day I see more people than I see in a year in Norway is what it feels like.

Manoj Tandon: Well, is the population of Tokyo more than the entire country of Norway?

Fredrik Oedegaardstuen: Oh yeah, way more. Norway is like seven times smaller.

Manoj Tandon: So why Tokyo? How did you get over there?

Fredrik Oedegaardstuen: So, I can bring you all the way back or I can bring in the essentials. I essentially went here on holiday two or two and a half years ago, and throughout that I got to experience everything about the country and kind of fell in love with the whole thing. But the reason I actually ended up moving here was a little different, because as I went here, I wanted to talk to some other people. So I actually went on a couple of dates to learn from people. It wasn’t really about the dating side, but it was about meeting people and talking to them, and I met this one amazing woman who I’m now living with, who is Japanese.

Manoj Tandon: Wonderful, congratulations.

Fredrik Oedegaardstuen: So that’s kept me here.

Manoj Tandon: Do you find it difficult as a cybersecurity practitioner, where I assume Japanese is a second language for you, to engage in the community?

Fredrik Oedegaardstuen: I don’t speak Japanese. I’m going to school now to learn it on the side. I’m spending time trying to learn how to speak so I can talk to her and her family in their native tongue, right? But I’m not there yet. I wish I were, but I don’t have any trouble actually talking to people here because most people in cybersecurity are mostly international, is what I’ve found. So that’s why, for example, I spoke at a conference back in January, a Japanese conference, and I got good feedback even from the Japanese people at that conference.

Manoj Tandon: Excellent. So talk to us a little bit about open source and cybersecurity. A lot of times there’s a lot of open source technologies out there. In fact, for threat hunting there are so many open source tools that are available and they’re good tools, but it hasn’t become as mainstream as one would have thought. And you’re totally open source, so tell us a little bit about what your thoughts on open source are.

Fredrik Oedegaardstuen: Sure. So there’s a lot of ways to go with that question. Of course, you can take it to business decisions or you can take it from the security side. I’m something in between, right?

Manoj Tandon: I would love to get both sides of it, so you can start with security or the business. I’m good with it either way.

Fredrik Oedegaardstuen: Sure. So without going into too much history, because you can go really far back if you want to talk about this, but talking about my experience, because I’ve been working on open source tools for maybe eight years or so at this point, and Shuffle is just the latest one. So I have a lot of stuff out there, as I’ve been in the community and I’ve seen everything.

But one thing about it that I can get straight to, which is really important, is that it’s all about sharing, right? It’s about sharing knowledge, and I’m really, really into that, which is all about teaching people how something works in a better way and giving them the opportunity to grow by just looking at what’s out there. So going far, far back, this is all about innovation, and most of the stuff we’re using even right now in this recording session is from open source tools, even though we are on this platform that’s like a really mature and futuristic example of 2020 or 2021. Most of what it is is open source, and that comes down to the fact that people just want to share the knowledge and want to help other people understand and keep engineering new things. It’s a developer’s dilemma, I think, something I’m struggling a lot with.

Manoj Tandon: So then, doesn’t at some point you have to make a living too? Right, so the monetization of this—what’s been your experience with that with open source technology?

Fredrik Oedegaardstuen: So in general, I’d say it’s not the best, right? People have not done it very well over the years, and I think that is because there is a lot of hate, actually, towards people that are open sourcing and trying to earn money from it, because they feel like it should just be open source. And because of that, a lot of people are not going down that route. Plus, on the other side, it’s actually really hard to monetize something like that.

Something I’ve been living out of for the last year, year and a half, has been sponsors—people actually helping me out personally through these open source platforms like GitHub, where they kind of give money to me before the business becomes sustainable. Because that is a way for you as an entrepreneur, as a creator, to share with the community even more than you would otherwise. For me personally, I would not be doing it still if I didn’t start earning money like half a year ago when I first got some help.

Manoj Tandon: That’s very cool. I didn’t know that was the path forward, where people are willing to sponsor, and that’s great. You’re also doing the service by creating open source technologies that are available to everyone and accessible to everyone.

Fredrik Oedegaardstuen: Yeah, so there are a lot of ways to go here, right? And the long-term goal for Shuffle as well is not to make money for me personally as the creator of the tool itself, as the starter of it. The point is to create an enterprise where you can actually help innovation in general outside of just the open source part of it. You need to help people, you need to actually make a business model around the thing instead of just going for sponsorships. This is all about how to get started, right? And I am in the start phase of this.

How we’re actually approaching it—and I’m saying “we” because I’m working with a lot of different people now who will be brought on board as this gets bigger and bigger—we are working on ways that you can bind business aspects over here with the open source side and really reduce the barrier to entry for all of these things.

Specifically, just to go into specifics here, one of the things we’ve done, which people typically don’t do and which I haven’t seen too much of in the open source space, but which, for example, Elastic has done really well, has been support and integrations with cloud services. There are really important ways you can go there where you can offer a fully working open source solution which doesn’t need all the maintenance. It’s not like 20 years ago when it felt like it would break at any point.

Manoj Tandon: Yeah, it’s more of a mature process now where you actually have these entities behind it like Red Hat, right? They also did this really well. They took this open source process and made it kind of their own, made their own version, and that is Red Hat Linux. They also have CentOS around that—I’m not sure if they’re behind it actually—but the point is around the support of it, they made such a good business model that now they are a giant of industry in IT in general. And that is something that we see more and more at this point.

So just to get into security a little bit, because you said you don’t see it a lot.

Fredrik Oedegaardstuen: I see it a lot, because my goal is essentially to help spread the word of all of these things. Tools like TheHive have been a big up-and-coming tool over the last five years, and I’m not sure if your listeners have heard of it.

Manoj Tandon: A lot of our listeners are cybersecurity practitioners, so I’m sure they would know what that is.

Fredrik Oedegaardstuen: Okay. Anyway, just to bring it back for those people that don’t know, it is a ticketing tool made for cybersecurity. It’s based on doing incident response in a better way by using tools made for incident response instead of using normal ITSM ticketing tools.

Anyway, the reason I bring them up is because they have also gone and tried to make a business model out of this now, and in the last year they’ve hired, I think, three or four more people for their team instead of working from within a different company building it from there. All of these security tools are slowly growing into mature organizations.

Another one—an acquisition two weeks ago by Rapid7 of an EDR tool called Velociraptor, which they will build into their systems as well. This is all about: how can you make this little tool that you start building in your home office or at your workplace into some giant that can help you and help all the other creators of it actually make a sustainable living in a different way than just from within these operations teams?

Manoj Tandon: What about the myth that open source tools, from a security aspect, are not that secure?

Fredrik Oedegaardstuen: Well, that is a dilemma for sure, and it is a misconception. I’d say it’s also a part of why we are open sourcing in general. Just to give you an example, I open sourced Shuffle about a year ago now, and Shuffle is my company, as you mentioned earlier, right, which I started and now have a lot of people working on in general and a larger community around. We’ve worked together a lot on finding all the issues around it—not just security issues but also functionality issues and bugs. So I’d say I’ve seen the opposite effect entirely.

But to what you’re saying, yes, if they are immature projects without a user base, I totally agree because then it’s basically just someone making it at home, not trying to earn money from it or anything. But once you try to make it commercial, you have to get it to a certain standard before people will even be willing to try it out.

Manoj Tandon: So talk to me about Shuffle a little bit. The technology—it’s a SOAR platform, correct?

Fredrik Oedegaardstuen: I don’t like SOAR. I don’t like that term. But yes.

Manoj Tandon: Tell us your words here, Fred.

Fredrik Oedegaardstuen: Sure. Shuffle is an automation platform. In general, it’s a security automation platform. So it has all the essence of a SOAR, except it doesn’t have all the unnecessary tools, in my opinion. What I mean by that is it’s not bloated.

All these larger SOARs that have been bought out and who have been doing well for themselves—I never liked their approaches to it because they try to do everything, and that is kind of the point of automation, but I don’t think you should build it into your solution. The difference here has been that all these SOAR products are also building case management systems, threat intel systems, and everything into one, and they’re trying to make it a monopoly of sorts.

While here I’m taking the open approach. Totally opposite—the whole point is to enable sharing and collaboration. That’s what we try to do with Shuffle.

And the whole goal of building it has been to use open source standards and build open source integrations so that every operations center around the world can have the same processes. Whether they’re an MSSP or an enterprise, they have most of the same problems, especially when they’re getting started.

And I’ve seen that most of the companies coming to me trying to approach it aren’t the Fortune 1000 or Fortune 500, because they need mature products; they want to get into it when it’s at a certain stage. But it’s been more of the companies that don’t have anywhere else to go. It’s the companies that are doing well, it’s the smaller MSSPs—of which there are a lot around the world—and it is the companies that don’t have the funds necessarily to buy the most expensive products where you pay ten thousand dollars or stuff like that.

Manoj Tandon: We’ve looked at SOAR platforms and they are not cheap. They are very expensive, and it is a complex deployment. It’s not something that you just do on a Saturday afternoon.

Fredrik Oedegaardstuen: Yes, but why shouldn’t it be?

Manoj Tandon: Well, there’s a complexity there. And if developers and folks like you manage that complexity and shield the end user—yes, you can. People have—I mean, you look at Okta. It’s not open source, but when you look at them, there was a time when you did an IAM system and there was so much complexity to it in engaging it. They’ve taken all of that away with all the pre-built integrations out of the box. There’s so many complexities we don’t have to worry about anymore.

Fredrik Oedegaardstuen: Oh for sure, yeah. That’s what we’re trying to do here as well. So in short terms, to actually talk about the platform itself and not everything around it, it is an automation platform. It’s trying to solve the same problems that all the SOARs are trying to tackle. We are trying to take it from a more open approach where we share literally everything. The others have done a little bit of the same, but still everything is about sharing. Everything is about getting everyone to the same level, kind of like increasing the average security maturity level globally long term, and enabling everyone to share what they’re doing. And that is a really critical aspect to it—it’s about sharing their processes and their automations.

For example, if you have MITRE ATT&CK, it would take you years to implement that whole thing into your pipeline if you have to do it one by one. That is so hard. It’s such a huge undertaking, and you need to talk about it with every team in the organization that’s related to it. It’s such a huge undertaking, but I don’t see why it should be if we think long term here. All of those things have—most of them have technical solutions rather than needing to talk to people and the human aspect essentially.

So I’m a real optimist when it comes to how much technology can do.

Manoj Tandon: If you think about it, it gets back to original design intent quite a bit as well, right? When you are laying out the architecture of Shuffle, I’m sure you put a huge amount of thought into the complexities that are involved and how you’re going to take those complexities out of it. In fact, that is a question—when you have multiple developers working on an open source platform, how do you keep cohesivity in the systems architecture and design part of the execution?

Fredrik Oedegaardstuen: Well, that’s not really a difference between open source compared to when you do it in an enterprise. The only difference with enterprise is that you probably do it from eight to four instead of doing it when you want to do it, which typically happens with open source.

How we are doing it is we talk regularly. It’s kind of like you’re giving people a task. You talk about the architecture and then you bring it forward to, “Should we focus on this part?” and then you give people a task and then they deliver. Then you need to have some change management that’s putting the code into the production pipeline. So it is the exact same process.

But I want to get back to what you said there. You talked about architecture and the thoughts around it, and yes, you’re correct. There are a lot of things going into it because these platforms are really hard to build, and that’s why they are really expensive as well. They know people can’t build it themselves in most cases. A lot of enterprises have their own system for automation, but it’s not as cohesive. And I want to say that I would never do it myself if I knew how much work it was—I wouldn’t do it again.

But about the architecture specifically, it’s actually based on something the NSA did. The NSA built an open source tool for workflow automation called Walkoff, which was also for security operations and which they are using inside of the NSA for their operations in general, even right now I believe. I’m not sure how much—I don’t have this knowledge properly. It’s very interesting. I know they used to.

So what I essentially did was I dug really far into their code and I took out the aspects that made sense, and I rebuilt the whole thing from scratch because if you’re going to build something that’s this big of an undertaking, you need to prepare a lot for what’s in the future and you need to understand the really deep components of it. So actually everything is built on the same architecture Walkoff—the NSA’s Walkoff—has, even down to the Docker level. But everything is rewritten—the whole codebase is rewritten with different languages.

Manoj Tandon: Wow. So the NSA built an open source platform. You leveraged that platform to enable another open source automation tool.

Fredrik Oedegaardstuen: That’s pretty cool. And we are compatible—that’s the cool part. They work together.

Manoj Tandon: That’s actually very cool. So now let’s go to the conspiracy theory side of things just for a second. Since you’re building off of something that the NSA did and they put it out as open source, there will be people that will say, “Well, then there are all kinds of backdoors into it and our security could be compromised.”

Fredrik Oedegaardstuen: Yeah, and that is exactly why it’s rewritten from scratch. That is the same thing that happened with Ghidra when it was open sourced about two years ago—the reverse engineering tool. People went through the whole thing just to make sure that it doesn’t have some hidden backdoors of some kind.

And so for Shuffle, it’s literally new programming languages and written all the way from scratch with new methodologies where I saw it necessary to improve. I wouldn’t have made it from scratch if I didn’t think there had to be major reconstructions in the whole scheme of things.

Manoj Tandon: I’m glad you addressed that head-on, Fred, because I’m sure we would get notes from listeners saying, “Well, now we know it may not be that secure.”

But that’s great. So you’ve taken the foundations and then you’ve re-engineered it and you’re building it from the ground up. Shuffle is your idea—it is the architecture, the operating principles, essentially.

Fredrik Oedegaardstuen: Yeah, it’s more about taking ideas from people that have done smart things before. Before you start something, you should probably look at if someone did it before you, right?

Manoj Tandon: Oh, absolutely. Why reinvent the wheel? There’s no point to it.

Fredrik Oedegaardstuen: Well, I think there’s something to that, though—I like reinventing the wheel because maybe you make something better, and that’s kind of what happened here.

Manoj Tandon: So for Shuffle, I haven’t personally been exposed to it, but I have heard our engineers at Dark Rhino talk quite a bit about it, and they seem to be quite excited about it. From what I understand, in the security operations center it can work as that unifier—that single pane of glass across everything, right?

Fredrik Oedegaardstuen: I would say it’s a little bit different. It’s not about making the single pane of glass. We’re simplifying it. So keep in mind, I’m not a security practitioner, so you’re the one talking about it. I’ll try to get into it.

There is something around this, right? And this is what SOARs are doing wrong in my opinion, like what you just said. They’re making the single pane of glass where everything is supposed to be, because I don’t think that fits into an automation platform. And the reason for that is simply because of bloat. It feels like bloat to the system if you make everything into one.

So what we’re trying to do instead with Shuffle is to use the tools you already have and kind of empower them into being the tools that are working together to become the single pane of glass. So back to what I said about, for example, TheHive earlier, or let’s take ServiceNow or PagerDuty as examples of these kinds of systems. Those ticketing systems, case management systems, are the tools that should be the single pane of glass. That is where everything should start.

So if you have that inside an automation platform, yes, it should be the go-to place for analysts, but the point is instead of doing that and giving you too many opportunities or too many tools within one, it’s all about using the tools you already have in different places and making them work together in symbiosis and then putting that data into the ticketing system where the analyst can work.

Manoj Tandon: All those separate subsystems—the integration of them—is going to be non-trivial.

Fredrik Oedegaardstuen: Yes.

Manoj Tandon: And from your smile, it says that you’ve already encountered probably a lot of challenges in making that happen. But it’s a fantastic idea. Ever since I’ve been in software hands-on—or not working in it for a long time—but the integration of disparate systems has been an ongoing challenge for many, many decades now, right? I mean, there are entire consulting empires built on that very challenge.

Fredrik Oedegaardstuen: On addressing it, yeah. And I think it’s a shame they haven’t built a solution for it instead of keeping on consulting. But yeah, for sure. It is a real problem and it is a hard problem to solve. It’s not something I was surprised by—this is something that I knew from the get-go because I used to work at this fintech company. It’s a huge fintech company in the Nordics and I was doing security there.

And when I came to that company, we were working with an MSSP. We had an MSSP, we used Excel, and we used Outlook. Those were the three tools, to bring it down to the core of how we were working. When I came in, that happened, and then the whole team quit. That also happened around the same time—I’m not sure if it’s my fault, but hopefully not. But maybe.

Anyway, I came in there and within like three days I kind of convinced my boss, my new boss at the time, and the team that we need to change our processes because this is not working. This is not okay. So I just started automating things. I came in there and I tried to do it.

This was when I was kind of a rookie at this—I knew security and I knew how it worked. I also knew some development, but I didn’t know how complex this gets in big enterprises. And the reason I’m bringing this up is because big enterprises are hard to deal with, and when you’re in fintech dealing with money at the same time, it’s really complex and really hard to build in new structures and processes there.

So what ended up happening was I spent a lot of time just integrating one by one all these tools. And I read a stat about this, about the average analyst using something like 33 tools on a daily basis—cloud services and in-house services, however you set it up. Integrating all of those—and in that company I think I did 13 tools, I put them together—and having done that for a year and a half or so, I kind of got bored of it because I just kept doing the same thing. It felt like I was writing the same code over and over again because it’s all about moving data around and enriching it in some specific way, and you have to build all these systems around it. And I couldn’t find a better solution. There was literally no better solution around this.

So I kind of found that I needed to spend a lot of time just thinking about how we can do this better. That was kind of what it came down to. A lot of companies are doing this right now: how can we do this automation thing better?

So what I started looking at was whether there are any open ways of doing this. And it turns out, yes, people are doing it already, but they’re not doing it in security—they’re not sharing enough. But in almost every other industry outside of security—even in IT, which is bigger than security for sure—in all of these industries, people are already sharing open specifications for their APIs and use cases for them. That is something called OpenAPI or Swagger, as it used to be called. This is all about specifying how something works, but in security we have almost nothing at this point. It’s getting better, but it’s something that we’re trying to help fix with Shuffle.

So whether the platform is used or not, we are still providing people with better resources for reading APIs and how to use them through Shuffle, as we are kind of sharing everything.

Manoj Tandon: And these are then created into code with Shuffle, right? This is kind of like the standardization part of it.

Fredrik Oedegaardstuen: It’s taking these specifications for APIs—say you have an EDR or say you have a SIEM, because that’s what people are mostly interested in. What is a SIEM? If you break it down really far, it is just a log aggregator.

Manoj Tandon: Yes, that is the exact thing.

Fredrik Oedegaardstuen: And now they’re trying to put all these other tools into the SIEM. And I’m kind of asking why—what’s the point of that? Shouldn’t it be a log aggregator and a place you can search and get alerts from in some way, so you can schedule some kind of search for it? And there are other tools like that, but there’s the case management system—it’s all about putting tickets in somewhere, in some place where the analyst can work. For the EDR, it’s all about actually having all your endpoints in a single place where you can kind of create rules based on what happens on the computer. It’s like antivirus—literally stopping stuff on your computer.

So all of these tools are kind of standardized. The only thing that’s not standardized about them is how you connect to them—the API itself.

Manoj Tandon: Absolutely.

Fredrik Oedegaardstuen: So the idea around this is standardizing the APIs. In a way, helping move the industry towards more standardization for the APIs. Not that they need to change their endpoints for it, but so that for an EDR you should have a way to search for the processes on a machine, you should have a way to get alerts from the system—you should have all these things. And that shouldn’t be different between systems. Of course you have unique selling points, and that is why you buy them most of the time, but that is hidden beneath those layers. A lot of the time it’s, “What are the detections within the system?” That’s what you’re usually buying. So it’s all about unifying those.

Manoj Tandon: You’re absolutely throwing up a challenge to the standard industry norms in doing this, which is great. I think the industry could use a little bit of a shake-up. A lot of it, I think—maybe get your thoughts around this—is that cybersecurity, we’ve seen, is one area where there’s a huge focus on tools. There are so many vendors, so many technologies, and everyone is trying to sell their tool as a magical—I don’t want to use the word “silver bullet,” but for lack of a better word—that sort of comes about that way, and that’s why you’re seeing all these functionalities getting put into areas that are being duplicated across different segments.

Fredrik Oedegaardstuen: Yeah, that’s right. And to that point—to the silver bullet point—that is kind of the point of Shuffle as well: to take your tools that you already have and make them the silver bullet they originally were supposed to be, right? They were supposed to solve this problem, but they’re not solving it; they’re just giving you a new problem that you have to deal with. So why not automate the part that’s annoying, and then you get the silver bullet part they’re trying to sell you?

Manoj Tandon: Well, how novel is that concept?

Fredrik Oedegaardstuen: Yeah, this is a weird thing coming from a provider of a product in general, but in general with Shuffle, I don’t want you to use Shuffle manually day by day—that’s not the goal. I want you to use the least amount of time within the tool possible and get the most automation out of it you can. So you shouldn’t need to sit there every day and kind of look at the same stuff and improve everything all the time. The whole point is kind of to alleviate all that effort as if you had a silver bullet.

Manoj Tandon: Do you see, with the approach that you’re introducing in cybersecurity, the role of the analyst changing?

Fredrik Oedegaardstuen: That’s a good question. Kinda. I see it that way, but I also see it as… I talked to a smart person yesterday about this and he said something I really liked, which was about whether an analyst should be an analyst or not, or whether an analyst is the wrong name for it. Because what it turns out to be is if you’re in a big MSSP, you’re usually put into like a Level 1 MSSP or SOC role first of all. That’s the entry-level role and I think that’s really important. It’s really, really important to keep that role because otherwise we don’t have an entry point into defensive security. And that is the best way to go about it because you can learn a lot in that role about all the different tools and how they work and fit together and infrastructure and everything.

But what it kind of came down to was whether you should yourself be automating all these things or analyzing all these things, or what the actual role of the analyst is. So yes, in trying to say yes to your question in a way, but I’m not sure where to go with it.

Manoj Tandon: Well, it’s so necessary. I think human intelligence in cybersecurity is absolutely critical to take on the biggest challenges. So if you look at that pyramid of pain, the very tip of the pyramid of pain is not the domain of any toolset; that is the domain of human consciousness. Someone uses a new TTP that’s never been seen before. There’s no automation that’s going to catch that. That’s going to be hunches of an analyst—someone says, “Something doesn’t seem right,” and piecing a puzzle together. I think that’s a very important function.

Human intelligence, the contribution of human intelligence in the SOC, is very, very important. I think oftentimes, because of a lack of automation, a lot of the fun part of the job—being the detective, threat hunting, and things of that nature—but because of a lack of automation, the job has a certain tedium to it because you’re repeating the same process steps over and over again. And that somewhat dulls the analyst. We’re all human. At some point you’re going to get bored of doing the same thing over and over. And it happens. It’s a very real problem for anyone that started in a SOC analyst role. They’re going to know exactly what I’m talking about, right? Because you keep going through the same thing again and again and again.

Yeah, so if you can alleviate that and allow them to focus where their intelligence is much more needed, then that would be—I think it would actually, operationally, make the SOC much more efficient—not only efficient, but it would increase the effectiveness.

Fredrik Oedegaardstuen: Yeah, I think as well. I think you’re absolutely talking about the right thing here. This is a hard problem to solve both short and long term, because I think if we talk just about the pyramid of pain for a second, the issue there is not necessarily that you shouldn’t have human intelligence in the picture. Of course you should. You should have a lot of training and the best people in your SOC so that they can solve all these issues when they come up. Because a lot of the incident response—the incidents I got as well when I used to work at the fintech company—was not purely technical stuff. The TTPs were often really weird things that you had to all of a sudden react to and fix. Not to mention that we implemented GDPR processes on how to handle those kinds of things, right? There are always these new processes coming into play.

But the issue is that I don’t believe most companies at all are at the maturity level where they should even care about those things, because most of them are struggling with the thing you just said, which is around doing the same thing day in and day out. And that means you don’t have time for threat hunting, you don’t have time to look at all these new TTPs that have come up in the last week. Like MITRE ATT&CK—they released TTPs for Docker last week as a new standard, like containers. I don’t think most people should look at them yet, because they haven’t gotten that far in their infrastructure defense. But a lot of them have as well.

This is kind of a hard thing to talk about as a provider as well, as a security automation provider. We can solve all those issues, but whether we should yet is not feasible to go that route yet, essentially, because you need to get people to a certain level first. That is what we’re trying to do. It’s all about moving people up the pyramid of pain to the point where they should be working at the top.

Manoj Tandon: Right. That’s absolutely correct. And that’s very cool. I think if you are successful—I should say more appropriately, as you become more and more successful—that you could have a dramatic impact on the industry.

Fredrik Oedegaardstuen: I’m hoping so, long term. Over the long term, I think that this is a direction that the entire industry needs to go in, not just…

Yeah, but I am scared—I mentioned long term a little bit—and I am really, really scared about one specific thing, which is if you automate too much, you don’t have an entry-level role anymore. And that means you’re not going to get new people into cybersecurity. I’m not sure how that problem should be solved yet, because that is already a problem we’re having with missing talent at this point. If you’re going down that route…

Manoj Tandon: Sorry, go ahead.

Manoj Tandon: No, I was going to say that I feel a little differently about that, because when you put a new entry-level person in, you still need to train them. They need to understand the “why” behind the events and the mechanics of it. They must get their fingernails dirty. If they don’t get them dirty, it’s going to be very hard for them to leverage the automation to an optimal point.

It’s like this: I’ll use an analogy that’s totally from a different industry. In photography, you look at how complex these cameras have become and how automated they have become, but they have not negated the role of the photographer at all. The photographer still needs to understand exposure, they need to understand framing, they need to understand so many things. The automation maybe has sped up their workflow, but it hasn’t eliminated their need for the knowledge that drives that workflow.

So I think automation will take the tedium out. But what’s going to be very cool now is if the analyst can focus on the top part of that pyramid of pain. Now they’re going to take a very deep dive into areas that they’re not even doing today, because they’re not worrying about the things down there anymore.

Fredrik Oedegaardstuen: Yeah, but that is something that I’m not sure if it’s a good or bad thing—whether you should be worried about it or not. Because what if the one thing down there… We are security people, right, and you need to think worst-case. What if that process down there was misimplemented and every company has it misimplemented? You’ve got to go back and no one’s looked at that for 10 years, and all of a sudden you have technical debt that goes really far.

Manoj Tandon: Well, the scenario you paint is very real and it very well could be the case. But there’s a fundamental overriding factor in this: imperfection cannot yield perfection. As humans, we are imperfect creatures, and anything we design and execute is going to have imperfections; it will not have perfection. It will be a reflection of us.

Yes, I deviated a little bit into philosophy, but okay. It’s just the way things are. And that’s because if we could design with perfection, we wouldn’t have any security gaps. Our systems would be 100% secure. But that’s not the world. Cyber compromise is looking for those imperfections and how to exploit those imperfections for whatever nefarious purpose or intent you have. So I think it’ll always be there. But it will change, and I don’t know how it will change.

Fredrik Oedegaardstuen: That is the exciting part, right? It’s what can happen if you give people more time to focus on development and innovation within security. How much better can we actually get if you can get those people to look at new things all the time and try to figure out how to solve a new problem instead of solving the same thing, kind of back to reinventing the wheel.

Manoj Tandon: Yeah, absolutely. I agree with you completely.

So we’re nearly at the hour here. There are so many more questions—we’re going to have to get you back for a Part 2 here because I really want to get deep into some thoughts around security topics that we can maybe explore in more detail.

But I want to give you a chance to plug anything. Are you going to be at any conferences or appearances? Any talks you’re going to be giving or any organizations?

Fredrik Oedegaardstuen: Yes, thanks. Yes, I would like to bring up Shuffle, of course. The company I’m building is trying to change the world with automation, at least in the security world. And my Twitter, if you want to follow me, is @frikkylikeme. I hope you put that in the description somewhere.

Manoj Tandon: We’ll put that into the show notes.

Fredrik Oedegaardstuen: Thank you. And thank you a lot for having me, for that matter. There are a lot of things I can go into here, but I don’t really have anything I would like to plug except for thank you—and thank my better half, who’s supported me through doing this throughout Corona.

Manoj Tandon: It’s been a pleasure to have you, and what you’re doing is fantastic work. It’s needed in our industry, and we’re going to look forward to having you back, Fred. We’ll deep dive into a lot more areas.

Fredrik Oedegaardstuen: Thank you very much, and have a fantastic weekend.

Manoj Tandon: Oh, you too. Thank you very much.

Fredrik Oedegaardstuen: You too.