Augusto Barros: 0:04

Hello and welcome to the Simple Talks podcast. I am your host, Augusto Barros, and this is the second episode of the podcast. I'm pretty sure that there is a statistic thing out there somewhere saying that a certain number of, a certain percentage of podcasts do not survive past the first episode. But here we are on the second one. So that's really kind of pretty good news for Simple Talks. And if you enjoyed the first episode, here we are with the second. And today I have a very exciting guest to talk to. It's someone from the same city where I am here in Toronto. Most of our guests and audience are in the United States, as we've been looking into the demographics for the podcast. So it's always nice to have fellow Canadian here to discuss the most interesting things in cybersecurity. So here is the point where I'm going to stop and say hello to Eugeny Karam. Hello, eugeny.

Evgeniy Kharam: 1:09

Thank you very much. I'm very happy to be on the podcast, very happy to be the second guest and definitely very happy to record with a fellow Canadian. We need to figure out a way to record physically in the same space. That would be cool, but for now I'm happy to be here virtually.

Augusto Barros: 1:24

Perfect. Evgeniy has been doing a lot of things in the cybersecurity space. He's an author, cybersecurity architect, has been advising kind of multiple organizations, podcaster as well. So just before we started here I was kind of taking a lot of tips from him about editing etc. So if you are listening to this and thinking, oh, the audio quality sounds good, there's not many ums and uns there, that's probably because Evgeniy was giving me a hand here, not only all the nice stuff that he does on cybersecurity itself, but he's also one of the organizers of probably one of the coolest cybersecurity conferences out there. Right Every winter here in Ontario we have the how do we call it? The Ski and Snowboard.

Evgeniy Kharam: 2:09

Cybersecurity Conference. The Ski and Snowboard Cybersecurity Conference.

Augusto Barros: 2:13

Perfect, yeah. So it is very cool. You just essentially go to a ski resort and we don't spend much time on talks and et cetera. We're just going to go to the mountain and going to go kind of truly to the tracks. And the most funny thing there is you go on the lift with people that you don't know, but you know that everyone there essentially works with cybersecurity, so you have the most interesting conversations while you're on the lift going up to the mountain, right? So I really want to thank Edwina for putting the idea together. It is really a very nice conference and I'm looking forward for the next one That'll be February, right?

Evgeniy Kharam: 2:50

February 27th. You have a special place in this place because in the first conference you were the first person that got a ticket and you actually spoke about risk and cybersecurity.

Augusto Barros: 3:01

That's right. I think I have the badge of honor of being the first speaker for this conference.

Evgeniy Kharam: 3:06

I'm going to carry that with pride, it's definitely a nice way to combine soft skills and cybersecurity, because in many conferences we are feeling a bit shy how do we connect with someone, how do we start the conversation? And if you're doing this as you mentioned the ski lift you can always start from oh, what type of skis you have, what do you usually ride, what do you do? And it's opened up the conversation to a more easier and human way to connect later and talk about cyber.

Augusto Barros: 3:35

Perfect. Well, I did a kind of quite kind of a fast introduction to you, so I probably left a lot of things out to give you the opportunity to talk a bit about yourself, your career and how you end up here, right, kind of talking about cybersecurity and security architecture with me today.

Evgeniy Kharam: 3:54

I'll do a very brief one, or what we call like an elevator pitch, about you, evgeny. I've been in industry for quite a long time, started the career in Israeli Navy, more IT still in the Israeli Navy, moved to work for a small company called Checkpoint, been around for a long time and I started the career at Checkpoint as a QA analyst in the firewall space, so my cybersecurity career actually went from QA. So it was very interesting when I came to Canada in 2006 to understand that not everybody knows how to debug a firewall. For me it was apparent that everybody was supposed to know how to do it, so it was a bit of an adjustment. But at the same time I realized that my firewall rule-based skills are very, very immature, because in QA you usually have five or ten rules, but in reality some of my customers had hundreds and even thousands of rules. So definitely an interesting way to start.

Evgeniy Kharam: 4:47

I spent 16 years in a company called Herjavec Group that now calls Cyderes, from running and installing firewalls to managing a team of professional service engineers in endpoint, in network, in SIEM a bit of cloud as well to later on become the VP of architecture and solutioning in the company, doing a lot of technical pre-sales and workshops for companies in Canada, us and Europe as well. And this was an interesting revolution and revelation for myself is that while you can be very deeply technical, it doesn't mean you're doing what the customer wants you to do in many cases, because one part is to be technical, second part to explain your ideas in a simple or business or the language that somebody understands and resonates as well.

Augusto Barros: 5:37

That's true. We have more or less the same time in terms of career and I'm really kind of I remember easily kind of the number of very bright people from the technology side or from the technical perspective. They were just incapable of communicating concepts to anyone that were not also kind of very technical, kind of from a background point of view. So I think, kind of being able to bridge the two words right at the business or sometimes just management side to the technical side, it is a very rare and very precious skill, I should say.

Evgeniy Kharam: 6:12

How do you explain theme without using any technology names?

Augusto Barros: 6:17

That's a very good question, I would say we collect data or signals from lots of technology components from your environment in search for traces of attacks or other threats in your environment. Nice.

Evgeniy Kharam: 6:32

So I had this metaphor of a sim of a condo building and a security guard that stands in the condo building and he knows everyone was going in and out, doesn't really do anything, but then he knows that everybody going to one particular location was the party over there. So when something happened, because he already know who went where, who came, he understands that the party probably is the cause of a trouble.

Augusto Barros: 6:59

That's a good example, right, but I would say right. If we start going into analyzing analogies and metaphors, we will go forever. Right, but I say that kind of reminds me a lot of the old IDS, right, when you're observing the network. In the same, on this case of the big condominium, he will ask for everyone that lives there to come to his office so he can look at their faces and decide if they're a threat or not. Right?

Augusto Barros: 7:23

The same pulls people, pulls people to it. That's, I think, today, and we're going to go through that topic a little more later. But I think one of the challenges of the SIEM is you have to send data to it in order for it to do something. I think it's very tempting for many architects, when they're using or they're deploying a SIEM, to send everything right. It is because you want to. I think there's a common idea of you have more signals, you will be able to find more stuff, right. You have more telemetry, you'll find more stuff. But what we've been seeing ultimately right, is it's a lot of noise, right, and it's not that cheap to send garbage to the SIEM, right. So that's kind of something that we really need to figure out. And what do you think about that challenge?

Evgeniy Kharam: 8:11

So, first of all, garbage in more money to store the garbage. Second, in reality, the logs and the signals we need to understand what's happening is probably 10% of what we need day by day, and only only only when something really bad happens we may need the rest of the data. So it's creating interesting challenges. Do I need the data all the time, or I can one filter the data and store the data I don't need right now somewhere else and only need the data I want? Second, in many cases and because I worked for MSSP for a long time people just log whatever. I'm not just talking about storing. Do I really need to log everything? Do I need to read all this information on how I can tune the endpoints, I can tune the firewalls, to understand what I need and what I don't need?

Evgeniy Kharam: 9:03

Also, people forget that 15 years ago our speed to the internet was what 50 meg, 100 meg, 150 meg? My phone can do 100 meg right now when it sleeps. My home has a 1.5 gigabyte fiber and most of the offices have a very high speed as well all locations and it means that the data we generate is much bigger as well. So it means we need to store much data as well. So definitely I agree that we don't need all the data. We need to understand what the data we need. We need to understand if there's a creative or not creative ways to filter the data we need. We need to understand if there's a creative or not creative ways to filter the data, or maybe we have a way to store the data cheaper somewhere else until we need it as well.

Augusto Barros: 9:52

That's right and that touches on something that you mentioned and it is related to the use cases of the SIEM. And, from a technology archaeology point of view, right, when you look at the SIM acronym, right you have the I and E, right S-I-E-M, and that was a consolidation of two technologies. It was the security information management and the security event management. That essentially kind of puts two use cases on the same platform. Right, can you get in the data, so the events, so you can look for right a threat and then react immediately. So it's that detection and response piece. And there is the part about collecting data and retaining that data for different reasons investigations, threat hunting, compliance and auditing, reporting.

Augusto Barros: 10:40

Reporting as well. So you have these two use cases on the same platform and that's why sometimes we end up collecting a lot of data that you have the perception that you do not need. In truth, you need for one use case, probably the one about retaining the data for a longer period. For those reasons, instead of detection, normally you need to collect more for audit purposes and compliance reasons than you really need for threat detection. But because you're using the same platform for both, it looks like a lot of waste, and it can be a lot of waste depending on the architecture of that technology. If you build a SIEM with technology that is optimized for real-time detection, it may be very expensive to collect data that you're collecting just in case you need it eventually.

Evgeniy Kharam: 11:32

Yes, and also, do I need to duplicate the data? If the data is located on the firewall management, if the data is located on the EDR in management, if the data is located on VAF manager or Active or active directory, do I need to be also saved on the scene at the same time, or I can get the data if I need the data during this time. Of course, you know something very important in many cases, compliance drives spending. So if my compliance says I need the data to be hot, cold, if you want to go geeky for 19 days or a year, then it's complicating stuff as well, because I need the data to be somewhere, but it doesn't mean I cannot have it somewhere else. Of course, we spoke about data lakes for the last probably decade and if it's a good or bad idea, maybe multiple people can use it In reality. Unfortunately, the concept is there, but in reality, I don't really see many companies moving there and using this big data lake, because we're always fighting who will maintain this and who will use it as well.

Augusto Barros: 12:31

Yeah, it's going to be. I see architecting the SIEM as a product right Kind of putting my vendor hat here of a SIEM technology. It is complex, right, and I remember kind of by looking again at the archeology of technology, looking at the same history. There were so many SIMs that were built with that intention of keeping data for a long time and focusing on search, and over the years they have been doing a lot of shortcuts or putting kind of some patches on top of that original architecture to try to replicate the idea of online or real-time detection. But what they were doing is just running a lot of searches in very short batched groups and that's not always efficient, or you may end up having some quite sharp cost increases as you start putting more things in.

Augusto Barros: 13:25

You mean SQL is a bad database for storing logs, or what? Well, I think we learned that a long time ago, right Apart from Isn't this interesting?

Evgeniy Kharam: 13:34

Sorry, I'm interrupting. We're talking about archaeology. Do you think people in five years will understand what's 5.1 forming? Because right now we don't really use the idea. But everyone that started with the sim understand that log and syslog used to run in udp, completely unsecure, completely basically acceptable because like, why not? It's on prem, it's, it's around here, and right now we move more and more to api, where we it by definition, we need to have validation of technology and encryption and not just, oh, let's add it and see what's happening.

Augusto Barros: 14:11

Well, actually some of my newer competitors right, the ones that were born in the cloud, I will say right, Kind of born in the last five, maybe 10 years, stretching a bit Some of those do not have collectors from on-prem data. If you want to get data from on-prem devices, for example, you have to use a third-party technology, because they just decided to just build their product with kind of the API or REST regular-based collectors and nothing else. And it may look like a crazy idea, but if they are looking from a buyer perspective or selling to organizations that were born in the cloud, it doesn't look like such a bad idea. It's just that they probably will not be the best option for large hybrid organizations that still have their data centers etc. But if they are selling to a small startup that was born in AWS, entirely well, I don't see why that model wouldn't work.

Evgeniy Kharam: 15:10

So let's run kind of a hypothesis If I'm a device I'm not going to name it right now in a magical cybersecurity platform in the cloud that doesn't collect syslog, that has APIs to connect to other EDRs systems and I get information of what I need, how is that different than SOAR? How is it like who I am, what I'm an XDR SIM or just a SOAR? Because SOAR, being around for longer, you just use API to get the data.

Augusto Barros: 15:48

Yes, I would say you can build a SIM on top of a SOAR solution. I think it's a pretty bad idea from an architecture point of view, by the way, but you can do it. I think one of my largest competitors they actually have done it. Their product today was built on a SOAR technology that they acquired. But I think it may work when you're getting data to retain it for later, for that search-oriented use case. But when you're looking for the real-time detection, normally the stream-based technologies would be more performatic, more efficient. So that's kind of where what is the use case and if you're trying to be good in those two groups of use cases, that's where a solution based on a SOAR platform like that may not be that efficient.

Evgeniy Kharam: 16:36

There's an interesting part because in many cases when we do SIEM architectural design, we don't ask a question about corporate environment and my product environment. Because if I'm a company let's take an insurance company, for example I have a corporate environment and I have my product environment when I start an insurance, so where do I connect the same? Does it collect everything? Just my corporate information or just my product information? And how do we match together? I know a lot of video. I'm using my hands, the information to have a better picture, potentially if attacked came from one point or another point.

Augusto Barros: 17:18

Yeah, and that's where the complexity starts to come in into our space, because I noticed that in the last few years it's not uncommon to see organizations with more than one SIEM.

Augusto Barros: 17:30

They have one SIEM for the product environment and another SIEM for the corporate environment. The scenario that you're describing is also one of the main reasons why you do not see all organizations out there being able to consolidate everything in a single cloud provider. I remember a few years ago, when I was a gardener covering the security operations space, there was some discussion about oh, should organizations try to just pick one cloud provider and do everything there? In theory it makes sense because it makes your life easier from a skills point of view. You optimize all your knowledge about that certain cloud provider. You will spend more there, so you're probably going to get more discounts as well from that provider. But all that ends up not working when you start doing that and then six months later your company acquires another one that is running on the other cloud provider, and now you have and the release goes down and you realize all your eggs in one basket and your entire company just went down.

Evgeniy Kharam: 18:42

Do you remember when DNS went down about eight years ago? And people are like, oh, I forgot the company. Who is the one on the Rood DNS that went down? I don't remember right now. And people are like do I need to maybe do something else with the DNS Because apparently there's a big problem? So I think actually having several cloud providers may separate my high availability to understand what I can do, especially if my DR is very mature. But, it's a different conversation.

Augusto Barros: 19:11

On the flip side, you may maximize the chances that you're going to be disrupted somehow, because every time that one of those providers have a problem, you are affected, right interrupted somehow.

Evgeniy Kharam: 19:20

Because every time that one of those providers have a problem, you are affected, right? Yeah, so this is definitely, definitely no one way to skin the cat excuse the cats, I have a lot of the cats. There's different ways and I this way. I don't really like the idea of the best practice. It cannot be best practice depending on the company. If I'm a marketing agency with 200 people with almost zero infrastructure, I may go one way to choose a SIEM and monitoring. And if I'm 10 people company that are doing call center and I have 800 servers, I may have a different way to monitor my environment.

Augusto Barros: 19:53

Perfect, yeah, and I want to switch a bit. We went deep down into the architecture of SIEM and the likes, but I want to switch back into the discussion about simplifying complex cybersecurity topics and concepts for people to understand better. And you mentioned not being very friendly for best practices, and I'll probably open that topic with a question Wouldn't it be better for us, as a field or as a domain, to teach more systems thinking instead of best practices?

Evgeniy Kharam: 20:29

100% Because, in the end of the day, best practice was written by a human person, a boy or a girl or someone. They decided this is the best way. But same as fruits and vegetables. What if I don't like vegetables and I like fruits? Or vice versa. You cannot tell me that the best is to eat cucumbers if I don't like them.

Evgeniy Kharam: 20:49

So best practices could be for a niche. You know this could be good for you if X Y Z, x Y Z. So if you're an insurance company that's doing X Y Z, this is probably the best for you way for you to configure the, to configure whatever this, but not just in general best practices. Or I may say our solution under this circumstance is the best. Configured like, like this and not just in general best practices is to put a firewall in a sandwich. Yes, we did it 25 years ago. I have no idea why, but you know there's a lot of stuff. But when we understand the underground part not underground the underlay part of the architecture and design, how stuff actually works, how the traffic flows to the environment where the traffic goes work, how the traffic flow to the environment where the traffic goes, now we can understand more about what is the best practice for this company, for this particular environment.

Augusto Barros: 21:48

Perfect. So how do you think that we can simplify this concept? Like you use the example of the sandwich firewalls, right? Or kind of the old idea, I'm going to put kind of my Cisco firewalls in front of the checkpoint firewalls, right? Or kind of the old idea, I'm going to put kind of my Cisco firewalls in front of the checkpoint firewalls, so now, right, if one of them have a problem, I am safe, right? There is a lot of probably kind of more technical details that we normally would have to refer to to explain why that may not necessarily be a best idea, right? Or maybe just a waste of money. So how can we go through discussions like this while simplifying all the complex components that are part of that discussion?

Evgeniy Kharam: 22:28

I think, first of all, we need to establish the language we are speaking. So if I'm talking to you and let's say I don't know that, you don't know English, and I start speaking with you English and you don't know English. Or let's say I speak with you Hebrew and you're speaking with me Spanish, okay, and none of us don't understand each other. But if we understand oh wait a second we actually understand that we speak in a different language. Then the moment we understand this part, we may choose to writing maybe signals, maybe images, because we understand this part. We may choose to writing maybe signals, maybe images, because we understand we're not speaking the same language.

Evgeniy Kharam: 23:04

If I'm talking to you on back-to-technology, I need to establish the understanding of your level of technology and how geeky you want to go, or high level you want to go. So this is in my mind for Spark Instead of simplifying right away, why maybe you want to go deep, this is what you want to do. I need to understand hey, can you guide me? How do you want the creature to go? Or can I guide you? We want to talk about firewalls and architectural design? How deep do you want me to go? And you will tell me, evgeny, what are you going to tell me?

Augusto Barros: 23:40

I want to know why this is not a good idea from an IP packet kind of characteristics point of view.

Evgeniy Kharam: 23:45

So you want to go deep. So now we establish we can go deep. Or you say you know what. I actually don't want to go deep. Just give me the high level of why it's a bad idea in the business. So now we understand the level.

Evgeniy Kharam: 23:57

If you want to go deep, we can go deep on technology. If you're going to a higher level, then I need to find metaphors or analogies in different ideas or life to explain to you what's happening. But if I don't establish this part, it's going to be bad, because people are hearing being from ideas that we don't always want to say that I have no idea what you're talking about. Can you simplify this? We don't want to look stupid, but if me, as somebody that's talking to you, can help you to tell me where you want to go, high or low, then it's helping. Nobody looks stupid.

Evgeniy Kharam: 24:32

We are trying to get to the same cause, because I'm definitely not trying to bring you down or tell you that you're not smart. I just want to communicate with you. So when I'm definitely not trying to bring you down or tell you that you're not smart, I just want to communicate with you. So when I'm doing a call with analysts, for example. I usually ask guys, I can go very high or very low. In case I'm going very deep on technology, please stop me. I'm here for you. I'm giving them all the indication and the rules of engagement, what they can do Like oh okay, oh, no, evgen again. This is too low, oh, this is too high. Can you go deeper on this part?

Augusto Barros: 25:03

Yes, what do we want to avoid is kind of the group of nodding heads and smiles that are thinking I have no clue of what you're talking about.

Evgeniy Kharam: 25:12

And it could be even harder when we're doing this over Zoom and several people, when we don't see all the faces, or your camera is off, then I don't see the facial expression, I don't know what you're saying. Then I ask you does it make sense? And you're like, yeah, definitely all crystal clear, but in theory it's not. So there are different ways to definitely validate what are we talking. In many, many cases, I will ask is it something that helps you in your environment? Is this the problem you experience, or can you ask me a question that can help? There's many different ways to roll this part and I think it's also important, depending on the conversation when we're done, to try to summarize what we discuss. Again, it's really going to be dependent on the conversation and the person we're talking to.

Evgeniy Kharam: 26:06

Perfect.

Augusto Barros: 26:07

Yeah, and in some of these examples, right that, through the many things we have discussed so far, right, we mentioned syslog by UDP and different kind of layers of firewalls, et cetera. That starts to kind of show up a bit of our age here. So let me bring things a little more towards these days. Right, In terms of innovation in cybersecurity, what changed in our world when we moved from that old on-prem environment to SaaS, right? What is good from how we are, the technologies that we are dealing with today, and what is bad?

Evgeniy Kharam: 26:43

The good part we can scale much, much faster. When we used to buy firewall themes or whatever it is, we'll buy and size it for the worst case scenario, because maybe during holidays or other times we're going to scale, not scale times. We're going to scale. We're going to increase the environment throughput, so we'll need to scale. We will need to make sure our equipment is capable to consume whatever needs to be consumed. In SaaS we don't, so our span could be smaller. Because we know it's easier to scale with the cloud. We're kind of scaling it differently as well. So this is the good part. We're changing the architecture from very, very big boxes, if you can say this, to very, very tiny boxes. But they can multiply and add multiple boxes all the time when we need to, basically on demand, and when we're done go back and scale down. So this is good. We also now can release code and updates much quicker.

Evgeniy Kharam: 27:46

In the past we used to joke when you end up upgrading the firewalls to version number x, then you're done and you start again, because version y came out and you need to go again to all the 50, 100 firewalls to do it right now, or you will wait and understand when is the next version coming every quarter, every six months. Right now, saas providers release version 2, 3, minor versions every week, so we can get the features we want quicker. The problem we're getting. So there's actually a couple of other advantages I remove the cost that I pay for people to do upgrades, I remove the SLAs and I kind of now trust the SaaS provider to keep the SLAs and I don't need to do RMA of my equipment because it's there. But it's also a problem because now I need to trust you that you will actually do the SLAs and keep the SLAs and keep it up and running and not put me in danger. And because we are now releasing versions more often, if you have a problem, you can introduce the problem to my environment much faster as well. We had bad examples for the last few months no need to mention vendor names when an update caused a problem and this wasn't a vulnerability. It was a mistake. But in the same time, if a vendor used open source libraries and there is an issue with open source library, it means we can introduce a problem that came with open source library vulnerability to our environment much quicker as well. So there is a few issues that coming with this part as well, because there's more trust. The third party management of vendors became quite a big problem because in the past, if everything was in my environment, I controlled everything. Right now, my data is like everywhere, so I need to understand how you're going to treat and do and work with my data as well. So it's definitely many, many things that came as a blessing, but also as a curse.

Evgeniy Kharam: 29:51

Another interesting part is actually a conversation with the founder last week. We spoke about access to the environment. In the past, you didn't know there's a problem with your environment, with your application, until a customer call you. Now you can see there's a problem with the environment because you own the environment in your data center, so you can react faster. This is another advantage. Last disadvantage it's probably something I missed.

Evgeniy Kharam: 30:19

I'm sure that I think is a very, very big problem is a vendor, almost by definition, have access to your environment. It's slowly closing down, slowly, slowly, because I call support. Of course I want to have access, I want to help you, but because you have access to your environment, but do I want you to have access to my environment? Do I want you to see my data? And this gap is slowly going to be closing and I believe in the next five years all the vendors will have to have an approval from a customer to get access to the environment or some kind of mechanism of keeping the privacy to the customer, because unfortunately, vendors got hacked as well and get breached as well, and then the bad guys, by definition, have access to everything, but when they hack the vendors, the same way, where we have all those processes to allow developers to go into production to fix bugs, et cetera, those break glass processes, et cetera.

Augusto Barros: 31:19

We can have those with the cloud vendors as well. Right, it may be more challenging for you to verify if the process is sound and if it's actually implementing the barriers and the controls that you believe are in place. Right, if I am a SaaS vendor, right, and I tell you I do not have access to your data unless you allow me to do so and I give you right, kind of a form, a type of workflow for you to approve it, you still not sure if I just cannot do that whatever I want, because it's my environment. So, unless you, I have gone through certifications or anything like that, that will put some level of assurance, or you kind of went through the environment to do some kind of auditing, or we have some kind of encryption in place where I will only have access to the keys as part of that workflow that we built together. Right, and you have some assurance because you are the one in control of the keys all the time, it's pretty hard for you to be sure that I do not have ways to bypass the process that I'm giving you to give me access to your own data, and so that's kind of really kind of one of the big challenges for SaaS environments.

Augusto Barros: 32:34

I found interesting one of the things that you mentioned that is related to the elasticity of the cloud. It was right in the beginning. When you start mentioning the advantages for SaaS environments, you do not need to buy the big box just because of kind of eventually running a holiday, you're hitting that spike of traffic, for example. But even if the technology allows us to be more elastic, there are still many SaaS vendors that implement license models that are quite punitive if you go beyond the level of, or the amount of pre-hired access or pre-hired kind of volume that you agreed on. Is that because they're trying to protect their margins or just aren't they just being greedy?

Evgeniy Kharam: 33:25

Everybody's trying to make money, so this is why we have this the ingestions, the users different models of how to get the money. I think, in reality, people trying to understand what's the best way, to have some kind of a license where people can control the cost. Because we unfortunately know many examples when you start this vendor, why, and the cost is five, for example, and then three months after, the cost is seven and then the cost is 10. It doesn't matter what, they're just putting numbers, numbers. How is this one here in a contract and my cost is duplicated right now? Or is it because of DNS traffic or because of this traffic?

Evgeniy Kharam: 34:05

This is why we're trying to change and play with the models, the same as if you ask MSSPs. We still didn't fix this till the end. How do I charge Ingestions users? Many different options to charge by. We're playing with these models, but there is no one model that can fit for everyone, because everyone is different. And I think this is the same as vendors, because they're trying to say okay, I can understand this part, but the moment I get to a point that you have more data, then I need to pay money for more data, and if I need more data. I'm going to just offload this price to you.

Augusto Barros: 34:45

As a vendor of a SaaS service there is primarily volume-based. I know how challenging it is to put together a pricing model that will give some assurance to the customer and give some predictability to the customer about how their costs will evolve and, at the same time, protecting my margins and my own costs. It is very challenging because when you were a SIEM, you're essentially talking about data volumes how much network traffic, how much storage, how much processing and you really need to put some controls in place that you're going to have to pass to the customer in the form of a license agreement, in a license model and it is really challenging to find a balance between kind of what will be primarily a benefit for the vendor, what would be great for the customer and what actually kind of can work for both of them. Yep, let me change gears again. Let's go into another direction, although we may end up kind of stumbling in things that we've already kind of touched. What do you think has been the most disruptive security technology in the last five years?

Evgeniy Kharam: 36:01

It's an interesting question. Security technology we definitely have the AI stuff, but you know what.

Augusto Barros: 36:10

All right, let me stop you there. We spent 37 minutes more or less, without touching AI. It's a new record. I know it's just the second episode, but I think the last one. It took 20 minutes Wow.

Evgeniy Kharam: 36:25

Probably maybe a bit biased, but on the corporate world, probably maybe a bit biased, but on the corporate world, I think the enterprise browsers are definitely changing many different things.

Evgeniy Kharam: 36:36

Because they're collapsing many technologies under one vendor, we work everywhere and because we are removed the perimeter for a long time ago and it's everywhere right now we wanted to protect people everywhere they're located and because we more and more use the browser, this is a disturbing part and we already saw some acquisitions in this piece and again, if you look inside and unpack how much going in network security, this is talking about ages of different technologies remote access, dlp, malware, access in general. So masking so many different URL filtering so many different things. I think it's definitely, in my mind, disturbing the space of corporate security and what I envision is that in the near future, some of the endpoint security companies will buy in and buy some of the vendors in enterprise browser to have a better control on the endpoint in general and then going to go and try to compete against the SaaS and theCC vendor as one vendor. This is in the corporate world.

Augusto Barros: 37:52

Perfect. And you know, what I find interesting is I remember watching keynote session I think it was in Black Hat or Defcon kind of from the remember the Jericho Forum. It was 20 years ago, right, and it was some of these ideas about kind of collapsing the perimeter down to the endpoint. And now we're going even further, down to the browser. Those ideas are already there but we're only seeing a separate practical implementations some of those ideas now, 20 years after. Then that's very interesting to see where the ideas first came up versus when the technology started to be available in a way that was actually kind of easy to implement and available to the masses, even if it's kind of from an enterprise and corporate point of view, available to the masses.

Evgeniy Kharam: 38:40

I do want to add. So this is the corporate one, because this is what people are going to feel by themselves. The one people are not going to feel is potentially the API security, because we have so much machine-to-machine communication right now and this includes the non-human identities, but the idea that everything is happening over APIs. So we cannot just unpack SSL and see we need to understand on a deeper level the functionality of how API work, what's business allowed and what security allowed as well, and this communication is humongous and a human being cannot really understand by themselves what's happening. This is actually the thing where AI will shine to help us understand. Like the simplest example not the simplest one I like is like from gaming, all the gaming companies right now. Basically, when you play a game World of Warcraft it's an API going back to the server. You can exchange money, you can get a better shield.

Augusto Barros: 39:41

It's basically an API call to get something else or exchange some kind of resource something else or exchange some kind of resource, and, because of latency, there are so many controls that still rely on the client on this gaming industry right, that it's pretty hard for you, kind of from being the API on the server, to be able to validate that everything is actually happening as it should on the client side. And another thing that I believe touches this API security side is the agentic AI. Right Now you have this AI systems that can call other things and they will call what they're gonna call APIs in many places. So the API security controls. We will have to consider a lot of additional context when these APIs are being called by AI technologies where you can have AI-based systems. So that really gonna be very interesting to watch and see how these things will evolve. And I will throw almost the same question but at the same time, the opposite what do you think is the most disruptive technology to security?

Evgeniy Kharam: 40:54

In AI. We need to understand how to secure AI. We need to understand how to understand and do security around AI. This is definitely something happening in my mind. I cannot claim I understand how to do it, but my mind okay. I need to understand and learn because we don't understand what's happening there, what's coming, what comes out. So how do we can help people there. And if a bank, an insurance company, the board says we need to have ai, what does it mean? But as a security professional, we need to provide the rules of privacy of what it can do, cannot do, what data can expose what it can achieve as well. This is definitely a big challenge to solve. Not how to use AI in security is how to provide security for AI.

Augusto Barros: 41:44

Right. I'm thinking we're going to have fun for far more time in this space. Nothing is solved and as the technology evolves, things get even more interesting as time passes. Let me ask you I did this on the first episode and I like what it was by accident, but I like it so much that I'm probably going to become one of the hallmarks of this podcast what do you think we do right today as an industry In cybersecurity? What are we doing right? We like so much to talk about things that go wrong right, so I want to ask you what do?

Evgeniy Kharam: 42:20

we do right. We definitely think we understand. It's not just one part of cybersecurity. We need a village to raise a child. We need multiple professions, multiple people, multiple technologies, multiple things to make it happen. It's not just the security control, it's not just the policies, it's not just the compliance, it's not just X, y, z. It's many different people working together to open up and communicate better. So we are more and more communicating better with each other to actually address the problem together.

Augusto Barros: 42:58

Yeah, I think, learning right that we need multiple skill sets. I think it's something that and I'm happy to say, I think we know that as an industry. I think one challenge we have is to make the new entrance in this industry to learn that as soon as possible, because I think, especially when you see the more technical people, they tend to get in with the impression that, hey, I know this thing about protecting APIs and everything else that people in security talk about is nonsense. What really matters is protecting the API, and then, with experience and over time, they learned that the field is far broader than they really were able to perceive in that early moment. So I think one of the challenges that we have is accelerating that awakening moment where they really kind of realize it's not only this piece that I know well and that I can understand the challenges. There are more things around it that kind of need to be taken care of too.

Evgeniy Kharam: 44:04

Yeah, and I think the problem we're also having is let's blame someone. I just spoke about learning how to work together, but we still want to blame someone. So, instead of working together and learning, we just want to blame someone. Oh, it's the user.

Augusto Barros: 44:20

We know it's the user. It's the user. It's the user.

Evgeniy Kharam: 44:22

It's the guy. And last part in many cases we don't want to do the boring stuff. We want to find the sexy technology that magically will solve the stuff. And every time you ask someone how's your asset management? They're all. How do you know you have EDR everywhere? How do you know you collect all of the same from the same? Do you know all you like? Even back in hard-draft days we're like okay, we're going to need XYZ. Do you have an asset management of the security controls you have? How many firewalls you have? Is everyone configured or is all of them logging?

Augusto Barros: 45:03

And this is like the boring stuff nobody wants to do. Yeah, a lot of the asset management right, it is remember, right, the critical security controls is the first thing right, right at the top. Right kind of know what you have there. And there's so many breaches out there that are not because there's kind of a high technical and high advanced threat behavior right or techniques being used is essentially finding a system that was forgotten that can fall through the cracks. So either no one accounted for it or they were just kind of not part of the vulnerability management process. It was something that was not included in all the processes and asset management and monitoring and et cetera. Right, that's still kind of probably one of the main reasons we see breaches out there.

Evgeniy Kharam: 45:47

Yep.

Augusto Barros: 45:48

All right Again. That's what happens when the conversation is fun. We are out of time.

Augusto Barros: 45:55

I really, really want to thank you for joining kind of the podcast. It was a very interesting conversation and we will have this out early in January. So if you're listening to us, you are talking to us from the future because we're still early in January. So if you're listening to us, you are talking to us from the future because we're still here in 2024. So I wish you some good and happy holidays and a good end of the year, but for you they're in 2025. You already went through all that. You're probably recovering for eating, all the turkey and et cetera, and the drinking, etc. But I'd like to thank you for listening to our podcast and we'll see you again soon. Thank you again and have a good one.

Evgeniy Kharam: 46:41

Thank you very much. Very happy to be here today.