ESG's Jon Oltsik talks with Amos Stern of Siemplify about SOAPA and Cybersecurity. This is part 2 of a 2-part series.
Read the related ESG Blog: SOAPA Video with Siemplify (Part 2)
Jon: Welcome back to my SOAPA video with Amos Stern from Siemplify. You come at this from a background in security operations, so tell me how that benefits you guys as you've become a product company.
Amos: Yeah. So I think it's a good point. So we're coming from a background and myself of security, and I've built security systems and I've built SIEM's and I've built SOC's. And I think this experience together with training of a lot of different SOC teams, I think I've probably trained tens if not north then a hundred different security operations teams worldwide, gave us the perspective of understanding what's the pain point for the analysts' team and for the security operations team. Now we're not looking at it necessarily from the technical point of view, but from the operations point of view. What do the analysts need to see? How can we help the analyst? And this comes into play in, you know, a very different aspect of our system and why, you know, we're even called Siemplify. We want to simplify the life of the security operations team.
Jon: Now, one of the things that I've learned through these series is we talk about technology but it's all process. So what are the processes that you're trying to improve?
Amos: So processes...again, when you look at an operation, process is split in between a few different categories. You have different, you know, triage investigation response processes and you need to have some sort of consistent flow, you know, implemented and repeated so that you can improve it. So it starts by managing all the different incidents, then it continues by having a consistent process into a higher respond to certain types of incidents and make sure you do this consistently and then you improve. And then the last part is measurements. How you measure what you've done, how you make sure that the processes you have are good and how you make sure that the technologies that you have installed are providing you good data and something that you can act upon and then continue to, you know, improve this circle.
Jon: Okay. Now if we look at security operations, if we look at SOAPA, historically, kind of, the middle or the hub of this has been SIEM. Now you work with a SIEM, you can plug your tools into a SIEM or you don't need a SIEM. So why would I do one or the other and what's your company's thoughts about SIEM as a product?
Amos: SIEM and SOC are…you know, once were maybe thought to be the same, but they're very different in nature and they have two different needs that they need to fulfill. And the SIEM, you know, has two main usages. One will be to collect the logs and store the logs and store a lot of log data and provide you with the capability to query that log data and so on. And the other is to create more alerts. Basically, create different rules and by these rules create more alerts that you wanna look at. Then the SOC they have a different need. They need to be taking all these alerts and then understand what to do with these alerts. Which one to look at first? How do I respond to this alert? Maybe making the response more efficient and then improving upon that operation. And up until today, SIEM's didn't really pick up the glove on what do I do after these alerts are popping?
And many times SOC teams and...like I mentioned before, when I was training them, they were looking at all of the alerts in the SIEM and trying to triage it in there. But in order to triage these alerts and enrich them and investigate, you need more data that sits in the other tools that's not necessarily sending all of it in logs to the SIEM.
Amos: So for that you need an operation system that focuses on operation, focuses on orchestration and helps you for every alert that comes in from a SIEM or from any other system, directly from the tools, from email, from phishing, whenever source you wanna, you know, put into the system, it will help you then take these alerts through a consistent process of response.
Jon: Okay. So it's sort of a manager of managers?
Amos: You can say so.
Jon: Okay. One other aspects of your tool or capabilities of what you guys provide is automation and orchestration. We see a tremendous demand for that, but when you peel back the layers of the onion what we find is that companies wanna automate the easy stuff, but they really aren't sure how to move on. So how are you helping your customers really automate security operations? Really orchestrate processes?
Amos: We see this a lot in implementations. If we want, you know, both us and the customer for an implementation to be successful, it has to be done in a way that's, you know, basically, a step by step implementation. You don't wanna jump to try to immediately automate response actions. And I think, you know, customers are reluctant to do so, and the way that we found that's the most effective is before you jump into the automation of response you first start implementing the processes. So you start with the orchestration. You start with, "What tools do I need to integrate to? What processes do I need to have, you know, codified into some playbooks for example?" And then even if they're completely manual and you don't have automation yet, you start, you know, putting their processes into action and see that you track those, you see that you have confidence in those.
And that's the important word here. Once you build confidence in this process and in this centralized management tool, then you can start adding automation. And then once you have these playbooks, you can start taking singular actions out of it and say, "This one I trust to be automated. And then this one I trust to be automated." And you would start by doing this with enrichment, investigative contractual actions and then slowly, I think, as the industry will gain more confidence, they would be more willing to do so with response actions.
Jon: Yeah. And I think that's where your experience comes in, is being able to guide people to those things. Because you've lived them and other companies, they provide the tools to do that, but they may not have the experience. So final question, SOAPA is all about integration and we'd love to see the industry get behind this and make it easier for all of these disparate tools to plug in together. But from your perspective and what you've learned from customers, what do you think the future is in of that kind of a trend?
Amos: So I think this is something that everybody realizes that's very important. The customers would like to see their security tools work together instead of they...you know, they need to be working all these tools together and getting really deep into them. And the industry as a whole is working to try to integrate more tools, but I think it's impossible to, you know, expect all the different tools to directly integrate to all of the other tools. It would be like, you know, a mesh of tools and also where would you actually manage these processes? Like, we need to basically implement these policies in all of the different tools. How each one integrates directly to the other ones. So here it really comes into need this layer that sits on top and it helps you basically, become the bus of all your different security tools. And this is where, you know, I see and we see that, you know, the future of SOAPA and orchestration is, being able to provide decentralized bus and allow every new tool that you add into your arsenal immediately be used with all of the other tools in context.
Jon: I couldn't have said it better myself. Well, thank you for participating, Amos. And for more, go to our website, our SOAPA landing page and there is a lot of videos and a lot of material, and stay tuned for more.