January 13, 2025 • 46 mins
Join us for an engaging conversation with Evgeniy Kharam, a distinguished cybersecurity expert, as he takes us through his fascinating journey from the Israeli Navy to becoming a leading figure in the field. Evgeniy shares invaluable insights into the critical role that effective communication plays alongside technical expertise in cybersecurity. We also discuss the novel Ski and Snowboard Cybersecurity Conference, an innovative blend of networking and leisure that offers a fresh perspective on professional connections.
We navigate the rapidly evolving world of cybersecurity technology, the challenges that hybrid organizations face, strategic decisions about cloud providers, disaster recovery plans, and service consolidation.
We also discussed challenging the notion of "best practices" in cybersecurity, advocating for a systems-thinking approach tailored to each organization's needs. Evgeniy emphasizes the importance of clear communication and understanding your audience to translate technical concepts effectively.
Join us for this insightful episode that promises to enrich your understanding of the dynamic cybersecurity arena.
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Augusto Barros (00: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 astatistic thing out there
somewhere saying that a certainnumber of, a certain percentage
of podcasts do not survive pastthe first episode.
(00:27):
But here we are on the secondone.
So that's really kind of prettygood news for Simple Talks.
And if you enjoyed the firstepisode, here we are with the
second.
And today I have a veryexciting guest to talk to.
It's someone from the same citywhere I am here in Toronto.
Most of our guests and audienceare in the United States, as
(00:53):
we've been looking into thedemographics for the podcast.
So it's always nice to havefellow Canadian here to discuss
the most interesting things incybersecurity.
So here is the point where I'mgoing to stop and say hello to
Eugeny Karam.
Hello, eugeny.
Evgeniy Kharam (01:09):
Thank you very much.
I'm very happy to be on thepodcast, very happy to be the
second guest and definitely veryhappy to record with a fellow
Canadian.
We need to figure out a way torecord physically in the same
space.
That would be cool, but for nowI'm happy to be here virtually.
Augusto Barros (01:24):
Perfect.
Evgeniy has been doing a lot ofthings in the cybersecurity
space.
He's an author, cybersecurityarchitect, has been advising
kind of multiple organizations,podcaster as well.
So just before we started hereI was kind of taking a lot of
tips from him about editing etc.
So if you are listening to thisand thinking, oh, the audio
quality sounds good, there's notmany ums and uns there, that's
(01:47):
probably because Evgeniy wasgiving me a hand here, not only
all the nice stuff that he doeson cybersecurity itself, but
he's also one of the organizersof probably one of the coolest
cybersecurity conferences outthere.
Right Every winter here inOntario we have the how do we
(02:08):
call it?
The Ski and Snowboard.
Evgeniy Kharam (02:09):
Cybersecurity Conference.
The Ski and SnowboardCybersecurity Conference.
Augusto Barros (02:13):
Perfect, yeah.
So it is very cool.
You just essentially go to aski resort and we don't spend
much time on talks and et cetera.
We're just going to go to themountain and going to go kind of
truly to the tracks.
And the most funny thing thereis you go on the lift with
people that you don't know, butyou know that everyone there
(02:34):
essentially works withcybersecurity, so you have the
most interesting conversationswhile you're on the lift going
up to the mountain, right?
So I really want to thankEdwina for putting the idea
together.
It is really a very niceconference and I'm looking
forward for the next one That'llbe February, right?
Evgeniy Kharam (02:50):
February 27th.
You have a special place inthis place because in the first
conference you were the firstperson that got a ticket and you
actually spoke about risk andcybersecurity.
Augusto Barros (03:01):
That's right.
I think I have the badge ofhonor of being the first speaker
for this conference.
Evgeniy Kharam (03:06):
I'm going to carry that with pride, it's
definitely a nice way to combinesoft skills and cybersecurity,
because in many conferences weare feeling a bit shy how do we
connect with someone, how do westart the conversation?
And if you're doing this as youmentioned the ski lift you can
always start from oh, what typeof skis you have, what do you
(03:27):
usually ride, what do you do?
And it's opened up theconversation to a more easier
and human way to connect laterand talk about cyber.
Augusto Barros (03:35):
Perfect.
Well, I did a kind of quitekind of a fast introduction to
you, so I probably left a lot ofthings out to give you the
opportunity to talk a bit aboutyourself, your career and how
you end up here, right, kind oftalking about cybersecurity and
security architecture with metoday.
Evgeniy Kharam (03: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 quitea long time, started the career
in Israeli Navy, more IT stillin the Israeli Navy, moved to
work for a small company calledCheckpoint, been around for a
long time and I started thecareer at Checkpoint as a QA
analyst in the firewall space,so my cybersecurity career
(04:16):
actually went from QA.
So it was very interesting whenI came to Canada in 2006 to
understand that not everybodyknows how to debug a firewall.
For me it was apparent thateverybody was supposed to know
how to do it, so it was a bit ofan adjustment.
But at the same time I realizedthat my firewall rule-based
skills are very, very immature,because in QA you usually have
(04:38):
five or ten rules, but inreality some of my customers had
hundreds and even thousands ofrules.
So definitely an interestingway to start.
I spent 16 years in a companycalled Herjavec Group that now
calls Cyderes, from running andinstalling firewalls to managing
a team of professional serviceengineers in endpoint, in
(04:58):
network, in SIEM a bit of cloudas well to later on become the
VP of architecture andsolutioning in the company,
doing a lot of technicalpre-sales and workshops for
companies in Canada, us andEurope as well.
And this was an interestingrevolution and revelation for
myself is that while you can bevery deeply technical, it
(05:22):
doesn't mean you're doing whatthe customer wants you to do in
many cases, because one part isto be technical, second part to
explain your ideas in a simpleor business or the language that
somebody understands andresonates as well.
Augusto Barros (05:37):
That's true.
We have more or less the sametime in terms of career and I'm
really kind of I remember easilykind of the number of very
bright people from thetechnology side or from the
technical perspective.
They were just incapable ofcommunicating concepts to anyone
that were not also kind of verytechnical, kind of from a
(06:00):
background point of view.
So I think, kind of being ableto bridge the two words right at
the business or sometimes justmanagement side to the technical
side, it is a very rare andvery precious skill, I should
say.
Evgeniy Kharam (06:12):
How do you explain theme without using any
technology names?
Augusto Barros (06:17):
That's a very good question, I would say we
collect data or signals fromlots of technology components
from your environment in searchfor traces of attacks or other
threats in your environment.
Nice.
Evgeniy Kharam (06:32):
So I had this metaphor of a sim of a condo
building and a security guardthat stands in the condo
building and he knows everyonewas going in and out, doesn't
really do anything, but then heknows that everybody going to
one particular location was theparty over there.
So when something happened,because he already know who went
(06:53):
where, who came, he understandsthat the party probably is the
cause of a trouble.
Augusto Barros (06:59):
That's a good example, right, but I would say
right.
If we start going intoanalyzing analogies and
metaphors, we will go forever.
Right, but I say that kind ofreminds me a lot of the old IDS,
right, when you're observingthe network.
In the same, on this case ofthe big condominium, he will ask
for everyone that lives thereto come to his office so he can
look at their faces and decideif they're a threat or not.
(07:22):
Right?
The same pulls people, pullspeople to it.
That's, I think, today, andwe're going to go through that
topic a little more later.
But I think one of thechallenges of the SIEM is you
have to send data to it in orderfor it to do something.
I think it's very tempting formany architects, when they're
using or they're deploying aSIEM, to send everything right.
(07:46):
It is because you want to.
I think there's a common ideaof you have more signals, you
will be able to find more stuff,right.
You have more telemetry, you'llfind more stuff.
But what we've been seeingultimately right, is it's a lot
of noise, right, and it's notthat cheap to send garbage to
the SIEM, right.
So that's kind of somethingthat we really need to figure
(08:08):
out.
And what do you think aboutthat challenge?
Evgeniy Kharam (08:11):
So, first of all , garbage in more money to store
the garbage.
Second, in reality, the logsand the signals we need to
understand what's happening isprobably 10% of what we need day
by day, and only only only whensomething really bad happens we
may need the rest of the data.
So it's creating interestingchallenges.
(08:32):
Do I need the data all the time, or I can one filter the data
and store the data I don't needright now somewhere else and
only need the data I want?
Second, in many cases andbecause I worked for MSSP for a
long time people just logwhatever.
I'm not just talking aboutstoring.
Do I really need to logeverything?
(08:52):
Do I need to read all thisinformation on how I can tune
the endpoints, I can tune thefirewalls, to understand what I
need and what I don't need?
Also, people forget that 15years ago our speed to the
internet was what 50 meg, 100meg, 150 meg?
(09:12):
My phone can do 100 meg rightnow when it sleeps.
My home has a 1.5 gigabytefiber and most of the offices
have a very high speed as wellall locations and it means that
the data we generate is muchbigger as well.
So it means we need to storemuch data as well.
(09:34):
So definitely I agree that wedon't need all the data.
We need to understand what thedata we need.
We need to understand ifthere's a creative or not
creative ways to filter the datawe need.
We need to understand ifthere's a creative or not
creative ways to filter the data, or maybe we have a way to
store the data cheaper somewhereelse until we need it as well.
Augusto Barros (09:52):
That's right and that touches on something that
you mentioned and it is relatedto the use cases of the SIEM.
And, from a technologyarchaeology point of view, right
, when you look at the SIMacronym, right you have the I
and E, right S-I-E-M, and thatwas a consolidation of two
technologies.
It was the security informationmanagement and the security
(10:14):
event management.
That essentially kind of putstwo 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 thenreact immediately.
So it's that detection andresponse piece.
And there is the part aboutcollecting data and retaining
that data for different reasonsinvestigations, threat hunting,
(10:37):
compliance and auditing,reporting.
Reporting as well.
So you have these two use caseson the same platform and that's
why sometimes we end upcollecting a lot of data that
you have the perception that youdo not need.
In truth, you need for one usecase, probably the one about
retaining the data for a longerperiod.
(10:58):
For those reasons, instead ofdetection, normally you need to
collect more for audit purposesand compliance reasons than you
really need for threat detection.
But because you're using thesame platform for both, it looks
like a lot of waste, and it canbe a lot of waste depending on
the architecture of thattechnology.
If you build a SIEM withtechnology that is optimized for
(11:22):
real-time detection, it may bevery expensive to collect data
that you're collecting just incase you need it eventually.
Evgeniy Kharam (11:32):
Yes, and also, do I need to duplicate the data?
If the data is located on thefirewall management, if the data
is located on the EDR inmanagement, if the data is
located on VAF manager or Activeor active directory, do I need
to be also saved on the scene atthe same time, or I can get the
data if I need the data duringthis time.
(11:52):
Of course, you know somethingvery important in many cases,
compliance drives spending.
So if my compliance says I needthe data to be hot, cold, if
you want to go geeky for 19 daysor a year, then it's
complicating stuff as well,because I need the data to be
somewhere, but it doesn't mean Icannot have it somewhere else.
Of course, we spoke about datalakes for the last probably
(12:14):
decade and if it's a good or badidea, maybe multiple people can
use it In reality.
Unfortunately, the concept isthere, but in reality, I don't
really see many companies movingthere and using this big data
lake, because we're alwaysfighting 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 asa product right Kind of putting
my vendor hat here of a SIEMtechnology.
It is complex, right, and Iremember kind of by looking
again at the archeology oftechnology, looking at the same
history.
There were so many SIMs thatwere built with that intention
of keeping data for a long timeand focusing on search, and over
(12:55):
the years they have been doinga lot of shortcuts or putting
kind of some patches on top ofthat original architecture to
try to replicate the idea ofonline or real-time detection.
But what they were doing isjust running a lot of searches
in very short batched groups andthat's not always efficient, or
(13:19):
you may end up having somequite sharp cost increases as
you start putting more things in.
You mean SQL is a bad databasefor storing logs, or what?
Well, I think we learned that along 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 fiveyears will understand what's 5.1
forming?
Because right now we don'treally use the idea.
But everyone that started withthe sim understand that log and
syslog used to run in udp,completely unsecure, completely
(13:54):
basically acceptable becauselike, why not?
It's on prem, it's, it's aroundhere, and right now we move
more and more to api, where weit by definition, we need to
have validation of technologyand encryption and not just, oh,
let's add it and see what'shappening.
Augusto Barros (14:11):
Well, actually some of my newer competitors
right, the ones that were bornin the cloud, I will say right,
Kind of born in the last five,maybe 10 years, stretching a bit
Some of those do not havecollectors from on-prem data.
If you want to get data fromon-prem devices, for example,
you have to use a third-partytechnology, because they just
decided to just build theirproduct with kind of the API or
(14:35):
REST regular-based collectorsand nothing else.
And it may look like a crazyidea, but if they are looking
from a buyer perspective orselling to organizations that
were born in the cloud, itdoesn't look like such a bad
idea.
It's just that they probablywill not be the best option for
(14:57):
large hybrid organizations thatstill have their data centers
etc.
But if they are selling to asmall startup that was born in
AWS, entirely well, I don't seewhy 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 itright now in a magical
cybersecurity platform in thecloud that doesn't collect
syslog, that has APIs to connectto other EDRs systems and I get
(15:32):
information of what I need, howis that different than SOAR?
How is it like who I am, whatI'm an XDR SIM or just a SOAR?
Because SOAR, being around forlonger, 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 ideafrom an architecture point of
view, by the way, but you can doit.
I think one of my largestcompetitors they actually have
done it.
Their product today was builton a SOAR technology that they
acquired.
But I think it may work whenyou're getting data to retain it
(16:12):
for later, for thatsearch-oriented use case.
But when you're looking for thereal-time detection, normally
the stream-based technologieswould be more performatic, more
efficient.
So that's kind of where what isthe use case and if you're
trying to be good in those twogroups of use cases, that's
where a solution based on a SOARplatform like that may not be
(16:34):
that efficient.
Evgeniy Kharam (16:36):
There's an interesting part because in many
cases when we do SIEMarchitectural design, we don't
ask a question about corporateenvironment and my product
environment.
Because if I'm a company let'stake an insurance company, for
example I have a corporateenvironment and I have my
(16:56):
product environment when I startan insurance, so where do I
connect the same?
Does it collect everything?
Just my corporate informationor just my product information?
And how do we match together?
I know a lot of video.
I'm using my hands, theinformation to have a better
picture, potentially if attackedcame from one point or another
(17:16):
point.
Augusto Barros (17:18):
Yeah, and that's where the complexity starts to
come in into our space, becauseI noticed that in the last few
years it's not uncommon to seeorganizations with more than one
SIEM.
They have one SIEM for theproduct environment and another
SIEM for the corporateenvironment.
The scenario that you'redescribing is also one of the
(17:39):
main reasons why you do not seeall organizations out there
being able to consolidateeverything 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 tojust pick one cloud provider and
(18:00):
do everything there?
In theory it makes sensebecause it makes your life
easier from a skills point ofview.
You optimize all your knowledgeabout that certain cloud
provider.
You will spend more there, soyou're probably going to get
more discounts as well from thatprovider.
But all that ends up notworking when you start doing
(18:24):
that and then six months lateryour company acquires another
one that is running on the othercloud provider, and now you
have and the release goes downand you realize all your eggs in
one basket and your entirecompany just went down.
Evgeniy Kharam (18:42):
Do you remember when DNS went down about eight
years ago?
And people are like, oh, Iforgot the company.
Who is the one on the Rood DNSthat went down?
I don't remember right now.
And people are like do I needto maybe do something else with
the DNS Because apparentlythere's a big problem?
(19:05):
So I think actually havingseveral cloud providers may
separate my high availability tounderstand what I can do,
especially if my DR is verymature.
But, it's a differentconversation.
Augusto Barros (19:11):
On the flip side , you may maximize the chances
that you're going to bedisrupted somehow, because every
time that one of thoseproviders have a problem, you
are affected, right interruptedsomehow.
Evgeniy Kharam (19:20):
Because every time that one of those providers
have a problem, you areaffected, right?
Yeah, so this is definitely,definitely no one way to skin
the cat excuse the cats, I havea lot of the cats.
There's different ways and Ithis way.
I don't really like the idea ofthe best practice.
It cannot be best practicedepending on the company.
If I'm a marketing agency with200 people with almost zero
infrastructure, I may go one wayto choose a SIEM and monitoring
(19:43):
.
And if I'm 10 people companythat are doing call center and I
have 800 servers, I may have adifferent way to monitor my
environment.
Augusto Barros (19:53):
Perfect, yeah, and I want to switch a bit.
We went deep down into thearchitecture of SIEM and the
likes, but I want to switch backinto the discussion about
simplifying complexcybersecurity topics and
concepts for people tounderstand better.
And you mentioned not beingvery friendly for best practices
(20:14):
, and I'll probably open thattopic with a question Wouldn't
it be better for us, as a fieldor as a domain, to teach more
systems thinking instead of bestpractices?
Evgeniy Kharam (20:29):
100% Because, in the end of the day, best
practice was written by a humanperson, a boy or a girl or
someone.
They decided this is the bestway.
But same as fruits andvegetables.
What if I don't like vegetablesand I like fruits?
Or vice versa.
You cannot tell me that thebest is to eat cucumbers if I
don't like them.
(20:49):
So best practices could be for aniche.
You know this could be good foryou if X Y Z, x Y Z.
So if you're an insurancecompany that's doing X Y Z, this
is probably the best for youway for you to configure the, to
configure whatever this, butnot just in general best
practices.
Or I may say our solution underthis circumstance is the best.
(21:13):
Configured like, like this andnot just in general best
practices is to put a firewallin a sandwich.
Yes, we did it 25 years ago.
I have no idea why, but youknow there's a lot of stuff.
But when we understand theunderground part not underground
the underlay part of thearchitecture and design, how
(21:34):
stuff actually works, how thetraffic flows to the environment
where the traffic goes work,how the traffic flow to the
environment where the trafficgoes, now we can understand more
about what is the best practicefor this company, for this
particular environment.
Augusto Barros (21:48):
Perfect.
So how do you think that we cansimplify this concept?
Like you use the example of thesandwich firewalls, right?
Or kind of the old idea, I'mgoing to put kind of my Cisco
firewalls in front of thecheckpoint firewalls, right?
Or kind of the old idea, I'mgoing to put kind of my Cisco
firewalls in front of thecheckpoint firewalls, so now,
right, if one of them have aproblem, I am safe, right?
There is a lot of probably kindof more technical details that
(22:10):
we normally would have to referto to explain why that may not
necessarily be a best idea,right?
Or maybe just a waste of money.
So how can we go throughdiscussions like this while
simplifying all the complexcomponents 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 andlet's say I don't know that, you
don't know English, and I startspeaking with you English and
you don't know English.
Or let's say I speak with youHebrew and you're speaking with
me Spanish, okay, and none of usdon't understand each other.
But if we understand oh wait asecond we actually understand
(22:51):
that we speak in a differentlanguage.
Then the moment we understandthis part, we may choose to
writing maybe signals, maybeimages, because we understand
this part.
We may choose to writing maybesignals, maybe images, because
we understand we're not speakingthe same language.
If I'm talking to you onback-to-technology, I need to
establish the understanding ofyour level of technology and how
(23:12):
geeky you want to go, or highlevel you want to go.
So this is in my mind for SparkInstead of simplifying right
away, why maybe you want to godeep, this is what you want to
do.
I need to understand hey, canyou guide me?
How do you want the creature togo?
Or can I guide you?
We want to talk about firewallsand architectural design?
(23:32):
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 ofcharacteristics point of view.
Evgeniy Kharam (23:45):
So you want to go deep.
So now we establish we can godeep.
Or you say you know what.
I actually don't want to godeep.
Just give me the high level ofwhy it's a bad idea in the
business.
So now we understand the level.
If you want to go deep, we cango deep on technology.
If you're going to a higherlevel, then I need to find
metaphors or analogies indifferent ideas or life to
(24:07):
explain to you what's happening.
But if I don't establish thispart, it's going to be bad,
because people are hearing beingfrom ideas that we don't always
want to say that I have no ideawhat 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 totell me where you want to go,
(24:29):
high or low, then it's helping.
Nobody looks stupid.
We are trying to get to the samecause, because I'm definitely
not trying to bring you down ortell you that you're not smart.
I just want to communicate withyou.
So when I'm definitely nottrying to bring you down or tell
you that you're not smart, Ijust want to communicate with
you.
So when I'm doing a call withanalysts, for example.
I usually ask guys, I can govery high or very low.
In case I'm going very deep ontechnology, please stop me.
(24:52):
I'm here for you.
I'm giving them all theindication and the rules of
engagement, what they can doLike oh okay, oh, no, evgen
again.
This is too low, oh, this istoo 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 andsmiles that are thinking I have
no clue of what you're talkingabout.
Evgeniy Kharam (25:12):
And it could be even harder when we're doing
this over Zoom and severalpeople, 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 whatyou're saying.
Then I ask you does it makesense?
And you're like, yeah,definitely all crystal clear,
but in theory it's not.
So there are different ways todefinitely validate what are we
(25:37):
talking.
In many, many cases, I will askis it something that helps you
in your environment?
Is this the problem youexperience, or can you ask me a
question that can help?
There's many different ways toroll this part and I think it's
also important, depending on theconversation when we're done,
(26:01):
to try to summarize what wediscuss.
Again, it's really going to bedependent on the conversation
and the person we're talking to.
Perfect.
Augusto Barros (26:07):
Yeah, and in some of these examples, right
that, through the many things wehave discussed so far, right,
we mentioned syslog by UDP anddifferent kind of layers of
firewalls, et cetera.
That starts to kind of show upa bit of our age here.
So let me bring things a littlemore towards these days.
Right, In terms of innovationin cybersecurity, what changed
(26:31):
in our world when we moved fromthat old on-prem environment to
SaaS, right?
What is good from how we are,the technologies that we are
dealing with today, and what isbad?
Evgeniy Kharam (26:43):
The good part we can scale much, much faster.
When we used to buy firewallthemes or whatever it is, we'll
buy and size it for the worstcase scenario, because maybe
during holidays or other timeswe're going to scale, not scale
times.
We're going to scale.
We're going to increase theenvironment throughput, so we'll
(27:04):
need to scale.
We will need to make sure ourequipment is capable to consume
whatever needs to be consumed.
In SaaS we don't, so our spancould be smaller.
Because we know it's easier toscale with the cloud.
We're kind of scaling itdifferently as well.
So this is the good part.
(27:24):
We're changing the architecturefrom very, very big boxes, if
you can say this, to very, verytiny boxes.
But they can multiply and addmultiple 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 codeand updates much quicker.
(27:46):
In the past we used to joke whenyou end up upgrading the
firewalls to version number x,then you're done and you start
again, because version y cameout and you need to go again to
all the 50, 100 firewalls to doit right now, or you will wait
and understand when is the nextversion coming every quarter,
(28:06):
every six months.
Right now, saas providersrelease version 2, 3, minor
versions every week, so we canget the features we want quicker
.
The problem we're getting.
So there's actually a couple ofother advantages I remove the
cost that I pay for people to doupgrades, I remove the SLAs and
(28:27):
I kind of now trust the SaaSprovider to keep the SLAs and I
don't need to do RMA of myequipment because it's there.
But it's also a problem becausenow I need to trust you that
you will actually do the SLAsand keep the SLAs and keep it up
and running and not put me indanger.
And because we are nowreleasing versions more often,
(28:50):
if you have a problem, you canintroduce the problem to my
environment much faster as well.
We had bad examples for thelast few months no need to
mention vendor names when anupdate caused a problem and this
wasn't a vulnerability.
It was a mistake.
But in the same time, if avendor used open source
(29:11):
libraries and there is an issuewith open source library, it
means we can introduce a problemthat came with open source
library vulnerability to ourenvironment much quicker as well
.
So there is a few issues thatcoming with this part as well,
because there's more trust.
The third party management ofvendors became quite a big
(29:32):
problem because in the past, ifeverything was in my environment
, I controlled everything.
Right now, my data is likeeverywhere, so I need to
understand how you're going totreat and do and work with my
data as well.
So it's definitely many, manythings that came as a blessing,
but also as a curse.
Another interesting part isactually a conversation with the
(29:53):
founder last week.
We spoke about access to theenvironment.
In the past, you didn't knowthere's a problem with your
environment, with yourapplication, until a customer
call you.
Now you can see there's aproblem with the environment
because you own the environmentin your data center, so you can
react faster.
This is another advantage.
(30:15):
Last disadvantage it's probablysomething I missed.
I'm sure that I think is a very,very big problem is a vendor,
almost by definition, haveaccess 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
(30:37):
because you have access to yourenvironment, 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 tobe closing and I believe in the
next five years all the vendorswill have to have an approval
from a customer to get access tothe environment or some kind of
mechanism of keeping theprivacy to the customer, because
(30:59):
unfortunately, vendors gothacked as well and get breached
as well, and then the bad guys,by definition, have access to
everything, but when they hackthe vendors, the same way, where
we have all those processes toallow developers to go into
production to fix bugs, etcetera, those break glass
processes, et cetera.
Augusto Barros (31:19):
We can have those with the cloud vendors as
well.
Right, it may be morechallenging for you to verify if
the process is sound and ifit's actually implementing the
barriers and the controls thatyou believe are in place.
Right, if I am a SaaS vendor,right, and I tell you I do not
(31:42):
have access to your data unlessyou allow me to do so and I give
you right, kind of a form, atype of workflow for you to
approve it, you still not sureif I just cannot do that
whatever I want, because it's myenvironment.
So, unless you, I have gonethrough certifications or
anything like that, that willput some level of assurance, or
(32:04):
you kind of went through theenvironment to do some kind of
auditing, or we have some kindof encryption in place where I
will only have access to thekeys as part of that workflow
that we built together.
Right, and you have someassurance because you are the
one in control of the keys allthe time, it's pretty hard for
you to be sure that I do nothave ways to bypass the process
(32:26):
that I'm giving you to give meaccess to your own data, and so
that's kind of really kind ofone of the big challenges for
SaaS environments.
I found interesting one of thethings that you mentioned that
is related to the elasticity ofthe cloud.
It was right in the beginning.
When you start mentioning theadvantages for SaaS environments
(32:46):
, you do not need to buy the bigbox just because of kind of
eventually running a holiday,you're hitting that spike of
traffic, for example.
But even if the technologyallows us to be more elastic,
there are still many SaaSvendors that implement license
(33:07):
models that are quite punitiveif you go beyond the level of,
or the amount of pre-hiredaccess or pre-hired kind of
volume that you agreed on.
Is that because they're tryingto 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, peopletrying to understand what's the
best way, to have some kind of alicense where people can
control the cost.
Because we unfortunately knowmany examples when you start
(33:47):
this vendor, why, and the costis five, for example, and then
three months after, the cost isseven and then the cost is 10.
It doesn't matter what, they'rejust putting numbers, numbers.
How is this one here in acontract and my cost is
duplicated right now?
Or is it because of DNS trafficor because of this traffic?
This is why we're trying tochange and play with the models,
(34:08):
the same as if you ask MSSPs.
We still didn't fix this tillthe end.
How do I charge Ingestionsusers?
Many different options tocharge by.
We're playing with these models, but there is no one model that
can fit for everyone, becauseeveryone is different.
And I think this is the same asvendors, because they're trying
(34:30):
to say okay, I can understandthis part, but the moment I get
to a point that you have moredata, then I need to pay money
for more data, and if I needmore data.
I'm going to just offload thisprice to you.
Augusto Barros (34:45):
As a vendor of a SaaS service there is primarily
volume-based.
I know how challenging it is toput together a pricing model
that will give some assurance tothe customer and give some
predictability to the customerabout how their costs will
evolve and, at the same time,protecting my margins and my own
costs.
It is very challenging becausewhen you were a SIEM, you're
(35:09):
essentially talking about datavolumes how much network traffic
, how much storage, how muchprocessing and you really need
to put some controls in placethat you're going to have to
pass to the customer in the formof a license agreement, in a
license model and it is reallychallenging to find a balance
(35:30):
between kind of what will beprimarily a benefit for the
vendor, what would be great forthe customer and what actually
kind of can work for both ofthem.
Yep, let me change gears again.
Let's go into another direction, although we may end up kind of
stumbling in things that we'vealready kind of touched.
(35:51):
What do you think has been themost disruptive security
technology in the last fiveyears?
Evgeniy Kharam (36:01):
It's an interesting question.
Security technology wedefinitely have the AI stuff,
but you know what.
Augusto Barros (36:10):
All right, let me stop you there.
We spent 37 minutes more orless, without touching AI.
It's a new record.
I know it's just the secondepisode, 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 maybea bit biased, but on the
corporate world, I think theenterprise browsers are
definitely changing manydifferent things.
Because they're collapsing manytechnologies under one vendor,
we work everywhere and becausewe are removed the perimeter for
(36:49):
a long time ago and it'severywhere right now we wanted
to protect people everywherethey're located and because we
more and more use the browser,this is a disturbing part and we
already saw some acquisitionsin this piece and again, if you
look inside and unpack how muchgoing in network security, this
(37:14):
is talking about ages ofdifferent technologies remote
access, dlp, malware, access ingeneral.
So masking so many differentURL filtering so many different
things.
I think it's definitely, in mymind, disturbing the space of
corporate security and what Ienvision is that in the near
future, some of the endpointsecurity companies will buy in
(37:38):
and buy some of the vendors inenterprise browser to have a
better control on the endpointin general and then going to go
and try to compete against theSaaS and theCC vendor as one
vendor.
This is in the corporate world.
Augusto Barros (37:52):
Perfect.
And you know, what I findinteresting is I remember
watching keynote session I thinkit was in Black Hat or Defcon
kind of from the remember theJericho Forum.
It was 20 years ago, right, andit was some of these ideas
about kind of collapsing theperimeter down to the endpoint.
And now we're going evenfurther, down to the browser.
(38:15):
Those ideas are already therebut we're only seeing a separate
practical implementations someof those ideas now, 20 years
after.
Then that's very interesting tosee where the ideas first came
up versus when the technologystarted to be available in a way
that was actually kind of easyto implement and available to
the masses, even if it's kind offrom an enterprise and
(38:37):
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 tofeel is potentially the API
security, because we have somuch machine-to-machine
communication right now and thisincludes the non-human
identities, but the idea thateverything is happening over
APIs.
So we cannot just unpack SSLand see we need to understand on
(39:05):
a deeper level thefunctionality of how API work,
what's business allowed and whatsecurity allowed as well, and
this communication is humongousand a human being cannot really
understand by themselves what'shappening.
This is actually the thingwhere AI will shine to help us
understand.
Like the simplest example notthe simplest one I like is like
(39:27):
from gaming, all the gamingcompanies right now.
Basically, when you play a gameWorld of Warcraft it's an API
going back to the server.
You can exchange money, you canget a better shield.
Augusto Barros (39:41):
It's basically an API call to get something
else or exchange some kind ofresource something else or
exchange some kind of resource,and, because of latency, there
are so many controls that stillrely on the client on this
gaming industry right, that it'spretty hard for you, kind of
from being the API on the server, to be able to validate that
(40:02):
everything is actually happeningas it should on the client side
.
And another thing that Ibelieve touches this API
security side is the agentic AI.
Right Now you have this AIsystems that can call other
things and they will call whatthey're gonna call APIs in many
places.
So the API security controls.
(40:24):
We will have to consider a lotof additional context when these
APIs are being called by AItechnologies where you can have
AI-based systems.
So that really gonna be veryinteresting to watch and see how
these things will evolve.
And I will throw almost thesame question but at the same
(40:47):
time, the opposite what do youthink is the most disruptive
technology to security?
Evgeniy Kharam (40:54):
In AI.
We need to understand how tosecure AI.
We need to understand how tounderstand and do security
around AI.
This is definitely somethinghappening in my mind.
I cannot claim I understand howto do it, but my mind okay.
I need to understand and learnbecause we don't understand
what's happening there, what'scoming, what comes out.
(41:16):
So how do we can help peoplethere.
And if a bank, an insurancecompany, 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 bigchallenge to solve.
(41:38):
Not how to use AI in securityis how to provide security for
AI.
Augusto Barros (41:44):
Right.
I'm thinking we're going tohave fun for far more time in
this space.
Nothing is solved and as thetechnology evolves, things get
even more interesting as timepasses.
Let me ask you I did this onthe first episode and I like
what it was by accident, but Ilike it so much that I'm
(42:05):
probably going to become one ofthe hallmarks of this podcast
what do you think we do righttoday as an industry In
cybersecurity?
What are we doing right?
We like so much to talk aboutthings that go wrong right, so I
want to ask you what do?
Evgeniy Kharam (42:20):
we do right.
We definitely think weunderstand.
It's not just one part ofcybersecurity.
We need a village to raise achild.
We need multiple professions,multiple people, multiple
technologies, multiple things tomake it happen.
It's not just the securitycontrol, it's not just the
policies, it's not just thecompliance, it's not just X, y,
(42:43):
z.
It's many different peopleworking together to open up and
communicate better.
So we are more and morecommunicating better with each
other to actually address theproblem together.
Augusto Barros (42:58):
Yeah, I think, learning right that we need
multiple skill sets.
I think it's something that andI'm happy to say, I think we
know that as an industry.
I think one challenge we haveis to make the new entrance in
this industry to learn that assoon as possible, because I
think, especially when you seethe more technical people, they
(43:22):
tend to get in with theimpression that, hey, I know
this thing about protecting APIsand everything else that people
in security talk about isnonsense.
What really matters isprotecting the API, and then,
with experience and over time,they learned that the field is
far broader than they reallywere able to perceive in that
(43:45):
early moment.
So I think one of thechallenges that we have is
accelerating that awakeningmoment where they really kind of
realize it's not only thispiece that I know well and that
I can understand the challenges.
There are more things around itthat 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 howto work together, but we still
want to blame someone.
So, instead of working togetherand 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 wedon't want to do the boring
stuff.
We want to find the sexytechnology that magically will
solve the stuff.
And every time you ask someonehow's your asset management?
They're all.
How do you know you have EDReverywhere?
How do you know you collect allof the same from the same?
Do you know all you like?
(44:44):
Even back in hard-draft dayswe're like okay, we're going to
need XYZ.
Do you have an asset managementof the security controls you
have?
How many firewalls you have?
Is everyone configured or isall of them logging?
Augusto Barros (45:03):
And this is like the boring stuff nobody wants
to do.
Yeah, a lot of the assetmanagement right, it is remember
, right, the critical securitycontrols is the first thing
right, right at the top.
Right kind of know what youhave there.
And there's so many breachesout there that are not because
there's kind of a high technicaland high advanced threat
behavior right or techniquesbeing used is essentially
(45:23):
finding a system that wasforgotten that can fall through
the cracks.
So either no one accounted forit or they were just kind of not
part of the vulnerabilitymanagement process.
It was something that was notincluded in all the processes
and asset management andmonitoring and et cetera.
Right, that's still kind ofprobably one of the main reasons
(45:44):
we see breaches out there.
Evgeniy Kharam (45:47):
Yep.
Augusto Barros (45:48):
All right Again.
That's what happens when theconversation is fun.
We are out of time.
I really, really want to thankyou for joining kind of the
podcast.
It was a very interestingconversation and we will have
this out early in January.
So if you're listening to us,you are talking to us from the
(46:09):
future because we're still earlyin January.
So if you're listening to us,you are talking to us from the
future because we're still herein 2024.
So I wish you some good andhappy holidays and a good end of
the year, but for you they'rein 2025.
You already went through allthat.
You're probably recovering foreating, all the turkey and et
cetera, and the drinking, etc.
(46:30):
But I'd like to thank you forlistening to our podcast and
we'll see you again soon.
Thank you again and have a goodone.
Evgeniy Kharam (46:41):
Thank you very much.
Very happy to be here today.
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 astatistic thing out there
somewhere saying that a certainnumber of, a certain percentage
of podcasts do not survive pastthe first episode.
(00:27):
But here we are on the secondone.
So that's really kind of prettygood news for Simple Talks.
And if you enjoyed the firstepisode, here we are with the
second.
And today I have a veryexciting guest to talk to.
It's someone from the same citywhere I am here in Toronto.
Most of our guests and audienceare in the United States, as
(00:53):
we've been looking into thedemographics for the podcast.
So it's always nice to havefellow Canadian here to discuss
the most interesting things incybersecurity.
So here is the point where I'mgoing to stop and say hello to
Eugeny Karam.
Hello, eugeny.
Evgeniy Kharam (01:09):
Thank you very much.
I'm very happy to be on thepodcast, very happy to be the
second guest and definitely veryhappy to record with a fellow
Canadian.
We need to figure out a way torecord physically in the same
space.
That would be cool, but for nowI'm happy to be here virtually.
Augusto Barros (01:24):
Perfect.
Evgeniy has been doing a lot ofthings in the cybersecurity
space.
He's an author, cybersecurityarchitect, has been advising
kind of multiple organizations,podcaster as well.
So just before we started hereI was kind of taking a lot of
tips from him about editing etc.
So if you are listening to thisand thinking, oh, the audio
quality sounds good, there's notmany ums and uns there, that's
(01:47):
probably because Evgeniy wasgiving me a hand here, not only
all the nice stuff that he doeson cybersecurity itself, but
he's also one of the organizersof probably one of the coolest
cybersecurity conferences outthere.
Right Every winter here inOntario we have the how do we
(02:08):
call it?
The Ski and Snowboard.
Evgeniy Kharam (02:09):
Cybersecurity Conference.
The Ski and SnowboardCybersecurity Conference.
Augusto Barros (02:13):
Perfect, yeah.
So it is very cool.
You just essentially go to aski resort and we don't spend
much time on talks and et cetera.
We're just going to go to themountain and going to go kind of
truly to the tracks.
And the most funny thing thereis you go on the lift with
people that you don't know, butyou know that everyone there
(02:34):
essentially works withcybersecurity, so you have the
most interesting conversationswhile you're on the lift going
up to the mountain, right?
So I really want to thankEdwina for putting the idea
together.
It is really a very niceconference and I'm looking
forward for the next one That'llbe February, right?
Evgeniy Kharam (02:50):
February 27th.
You have a special place inthis place because in the first
conference you were the firstperson that got a ticket and you
actually spoke about risk andcybersecurity.
Augusto Barros (03:01):
That's right.
I think I have the badge ofhonor of being the first speaker
for this conference.
Evgeniy Kharam (03:06):
I'm going to carry that with pride, it's
definitely a nice way to combinesoft skills and cybersecurity,
because in many conferences weare feeling a bit shy how do we
connect with someone, how do westart the conversation?
And if you're doing this as youmentioned the ski lift you can
always start from oh, what typeof skis you have, what do you
(03:27):
usually ride, what do you do?
And it's opened up theconversation to a more easier
and human way to connect laterand talk about cyber.
Augusto Barros (03:35):
Perfect.
Well, I did a kind of quitekind of a fast introduction to
you, so I probably left a lot ofthings out to give you the
opportunity to talk a bit aboutyourself, your career and how
you end up here, right, kind oftalking about cybersecurity and
security architecture with metoday.
Evgeniy Kharam (03: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 quitea long time, started the career
in Israeli Navy, more IT stillin the Israeli Navy, moved to
work for a small company calledCheckpoint, been around for a
long time and I started thecareer at Checkpoint as a QA
analyst in the firewall space,so my cybersecurity career
(04:16):
actually went from QA.
So it was very interesting whenI came to Canada in 2006 to
understand that not everybodyknows how to debug a firewall.
For me it was apparent thateverybody was supposed to know
how to do it, so it was a bit ofan adjustment.
But at the same time I realizedthat my firewall rule-based
skills are very, very immature,because in QA you usually have
(04:38):
five or ten rules, but inreality some of my customers had
hundreds and even thousands ofrules.
So definitely an interestingway to start.
I spent 16 years in a companycalled Herjavec Group that now
calls Cyderes, from running andinstalling firewalls to managing
a team of professional serviceengineers in endpoint, in
(04:58):
network, in SIEM a bit of cloudas well to later on become the
VP of architecture andsolutioning in the company,
doing a lot of technicalpre-sales and workshops for
companies in Canada, us andEurope as well.
And this was an interestingrevolution and revelation for
myself is that while you can bevery deeply technical, it
(05:22):
doesn't mean you're doing whatthe customer wants you to do in
many cases, because one part isto be technical, second part to
explain your ideas in a simpleor business or the language that
somebody understands andresonates as well.
Augusto Barros (05:37):
That's true.
We have more or less the sametime in terms of career and I'm
really kind of I remember easilykind of the number of very
bright people from thetechnology side or from the
technical perspective.
They were just incapable ofcommunicating concepts to anyone
that were not also kind of verytechnical, kind of from a
(06:00):
background point of view.
So I think, kind of being ableto bridge the two words right at
the business or sometimes justmanagement side to the technical
side, it is a very rare andvery precious skill, I should
say.
Evgeniy Kharam (06:12):
How do you explain theme without using any
technology names?
Augusto Barros (06:17):
That's a very good question, I would say we
collect data or signals fromlots of technology components
from your environment in searchfor traces of attacks or other
threats in your environment.
Nice.
Evgeniy Kharam (06:32):
So I had this metaphor of a sim of a condo
building and a security guardthat stands in the condo
building and he knows everyonewas going in and out, doesn't
really do anything, but then heknows that everybody going to
one particular location was theparty over there.
So when something happened,because he already know who went
(06:53):
where, who came, he understandsthat the party probably is the
cause of a trouble.
Augusto Barros (06:59):
That's a good example, right, but I would say
right.
If we start going intoanalyzing analogies and
metaphors, we will go forever.
Right, but I say that kind ofreminds me a lot of the old IDS,
right, when you're observingthe network.
In the same, on this case ofthe big condominium, he will ask
for everyone that lives thereto come to his office so he can
look at their faces and decideif they're a threat or not.
(07:22):
Right?
The same pulls people, pullspeople to it.
That's, I think, today, andwe're going to go through that
topic a little more later.
But I think one of thechallenges of the SIEM is you
have to send data to it in orderfor it to do something.
I think it's very tempting formany architects, when they're
using or they're deploying aSIEM, to send everything right.
(07:46):
It is because you want to.
I think there's a common ideaof you have more signals, you
will be able to find more stuff,right.
You have more telemetry, you'llfind more stuff.
But what we've been seeingultimately right, is it's a lot
of noise, right, and it's notthat cheap to send garbage to
the SIEM, right.
So that's kind of somethingthat we really need to figure
(08:08):
out.
And what do you think aboutthat challenge?
Evgeniy Kharam (08:11):
So, first of all , garbage in more money to store
the garbage.
Second, in reality, the logsand the signals we need to
understand what's happening isprobably 10% of what we need day
by day, and only only only whensomething really bad happens we
may need the rest of the data.
So it's creating interestingchallenges.
(08:32):
Do I need the data all the time, or I can one filter the data
and store the data I don't needright now somewhere else and
only need the data I want?
Second, in many cases andbecause I worked for MSSP for a
long time people just logwhatever.
I'm not just talking aboutstoring.
Do I really need to logeverything?
(08:52):
Do I need to read all thisinformation on how I can tune
the endpoints, I can tune thefirewalls, to understand what I
need and what I don't need?
Also, people forget that 15years ago our speed to the
internet was what 50 meg, 100meg, 150 meg?
(09:12):
My phone can do 100 meg rightnow when it sleeps.
My home has a 1.5 gigabytefiber and most of the offices
have a very high speed as wellall locations and it means that
the data we generate is muchbigger as well.
So it means we need to storemuch data as well.
(09:34):
So definitely I agree that wedon't need all the data.
We need to understand what thedata we need.
We need to understand ifthere's a creative or not
creative ways to filter the datawe need.
We need to understand ifthere's a creative or not
creative ways to filter the data, or maybe we have a way to
store the data cheaper somewhereelse until we need it as well.
Augusto Barros (09:52):
That's right and that touches on something that
you mentioned and it is relatedto the use cases of the SIEM.
And, from a technologyarchaeology point of view, right
, when you look at the SIMacronym, right you have the I
and E, right S-I-E-M, and thatwas a consolidation of two
technologies.
It was the security informationmanagement and the security
(10:14):
event management.
That essentially kind of putstwo 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 thenreact immediately.
So it's that detection andresponse piece.
And there is the part aboutcollecting data and retaining
that data for different reasonsinvestigations, threat hunting,
(10:37):
compliance and auditing,reporting.
Reporting as well.
So you have these two use caseson the same platform and that's
why sometimes we end upcollecting a lot of data that
you have the perception that youdo not need.
In truth, you need for one usecase, probably the one about
retaining the data for a longerperiod.
(10:58):
For those reasons, instead ofdetection, normally you need to
collect more for audit purposesand compliance reasons than you
really need for threat detection.
But because you're using thesame platform for both, it looks
like a lot of waste, and it canbe a lot of waste depending on
the architecture of thattechnology.
If you build a SIEM withtechnology that is optimized for
(11:22):
real-time detection, it may bevery expensive to collect data
that you're collecting just incase you need it eventually.
Evgeniy Kharam (11:32):
Yes, and also, do I need to duplicate the data?
If the data is located on thefirewall management, if the data
is located on the EDR inmanagement, if the data is
located on VAF manager or Activeor active directory, do I need
to be also saved on the scene atthe same time, or I can get the
data if I need the data duringthis time.
(11:52):
Of course, you know somethingvery important in many cases,
compliance drives spending.
So if my compliance says I needthe data to be hot, cold, if
you want to go geeky for 19 daysor a year, then it's
complicating stuff as well,because I need the data to be
somewhere, but it doesn't mean Icannot have it somewhere else.
Of course, we spoke about datalakes for the last probably
(12:14):
decade and if it's a good or badidea, maybe multiple people can
use it In reality.
Unfortunately, the concept isthere, but in reality, I don't
really see many companies movingthere and using this big data
lake, because we're alwaysfighting 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 asa product right Kind of putting
my vendor hat here of a SIEMtechnology.
It is complex, right, and Iremember kind of by looking
again at the archeology oftechnology, looking at the same
history.
There were so many SIMs thatwere built with that intention
of keeping data for a long timeand focusing on search, and over
(12:55):
the years they have been doinga lot of shortcuts or putting
kind of some patches on top ofthat original architecture to
try to replicate the idea ofonline or real-time detection.
But what they were doing isjust running a lot of searches
in very short batched groups andthat's not always efficient, or
(13:19):
you may end up having somequite sharp cost increases as
you start putting more things in.
You mean SQL is a bad databasefor storing logs, or what?
Well, I think we learned that along 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 fiveyears will understand what's 5.1
forming?
Because right now we don'treally use the idea.
But everyone that started withthe sim understand that log and
syslog used to run in udp,completely unsecure, completely
(13:54):
basically acceptable becauselike, why not?
It's on prem, it's, it's aroundhere, and right now we move
more and more to api, where weit by definition, we need to
have validation of technologyand encryption and not just, oh,
let's add it and see what'shappening.
Augusto Barros (14:11):
Well, actually some of my newer competitors
right, the ones that were bornin the cloud, I will say right,
Kind of born in the last five,maybe 10 years, stretching a bit
Some of those do not havecollectors from on-prem data.
If you want to get data fromon-prem devices, for example,
you have to use a third-partytechnology, because they just
decided to just build theirproduct with kind of the API or
(14:35):
REST regular-based collectorsand nothing else.
And it may look like a crazyidea, but if they are looking
from a buyer perspective orselling to organizations that
were born in the cloud, itdoesn't look like such a bad
idea.
It's just that they probablywill not be the best option for
(14:57):
large hybrid organizations thatstill have their data centers
etc.
But if they are selling to asmall startup that was born in
AWS, entirely well, I don't seewhy 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 itright now in a magical
cybersecurity platform in thecloud that doesn't collect
syslog, that has APIs to connectto other EDRs systems and I get
(15:32):
information of what I need, howis that different than SOAR?
How is it like who I am, whatI'm an XDR SIM or just a SOAR?
Because SOAR, being around forlonger, 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 ideafrom an architecture point of
view, by the way, but you can doit.
I think one of my largestcompetitors they actually have
done it.
Their product today was builton a SOAR technology that they
acquired.
But I think it may work whenyou're getting data to retain it
(16:12):
for later, for thatsearch-oriented use case.
But when you're looking for thereal-time detection, normally
the stream-based technologieswould be more performatic, more
efficient.
So that's kind of where what isthe use case and if you're
trying to be good in those twogroups of use cases, that's
where a solution based on a SOARplatform like that may not be
(16:34):
that efficient.
Evgeniy Kharam (16:36):
There's an interesting part because in many
cases when we do SIEMarchitectural design, we don't
ask a question about corporateenvironment and my product
environment.
Because if I'm a company let'stake an insurance company, for
example I have a corporateenvironment and I have my
(16:56):
product environment when I startan insurance, so where do I
connect the same?
Does it collect everything?
Just my corporate informationor just my product information?
And how do we match together?
I know a lot of video.
I'm using my hands, theinformation to have a better
picture, potentially if attackedcame from one point or another
(17:16):
point.
Augusto Barros (17:18):
Yeah, and that's where the complexity starts to
come in into our space, becauseI noticed that in the last few
years it's not uncommon to seeorganizations with more than one
SIEM.
They have one SIEM for theproduct environment and another
SIEM for the corporateenvironment.
The scenario that you'redescribing is also one of the
(17:39):
main reasons why you do not seeall organizations out there
being able to consolidateeverything 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 tojust pick one cloud provider and
(18:00):
do everything there?
In theory it makes sensebecause it makes your life
easier from a skills point ofview.
You optimize all your knowledgeabout that certain cloud
provider.
You will spend more there, soyou're probably going to get
more discounts as well from thatprovider.
But all that ends up notworking when you start doing
(18:24):
that and then six months lateryour company acquires another
one that is running on the othercloud provider, and now you
have and the release goes downand you realize all your eggs in
one basket and your entirecompany just went down.
Evgeniy Kharam (18:42):
Do you remember when DNS went down about eight
years ago?
And people are like, oh, Iforgot the company.
Who is the one on the Rood DNSthat went down?
I don't remember right now.
And people are like do I needto maybe do something else with
the DNS Because apparentlythere's a big problem?
(19:05):
So I think actually havingseveral cloud providers may
separate my high availability tounderstand what I can do,
especially if my DR is verymature.
But, it's a differentconversation.
Augusto Barros (19:11):
On the flip side , you may maximize the chances
that you're going to bedisrupted somehow, because every
time that one of thoseproviders have a problem, you
are affected, right interruptedsomehow.
Evgeniy Kharam (19:20):
Because every time that one of those providers
have a problem, you areaffected, right?
Yeah, so this is definitely,definitely no one way to skin
the cat excuse the cats, I havea lot of the cats.
There's different ways and Ithis way.
I don't really like the idea ofthe best practice.
It cannot be best practicedepending on the company.
If I'm a marketing agency with200 people with almost zero
infrastructure, I may go one wayto choose a SIEM and monitoring
(19:43):
.
And if I'm 10 people companythat are doing call center and I
have 800 servers, I may have adifferent way to monitor my
environment.
Augusto Barros (19:53):
Perfect, yeah, and I want to switch a bit.
We went deep down into thearchitecture of SIEM and the
likes, but I want to switch backinto the discussion about
simplifying complexcybersecurity topics and
concepts for people tounderstand better.
And you mentioned not beingvery friendly for best practices
(20:14):
, and I'll probably open thattopic with a question Wouldn't
it be better for us, as a fieldor as a domain, to teach more
systems thinking instead of bestpractices?
Evgeniy Kharam (20:29):
100% Because, in the end of the day, best
practice was written by a humanperson, a boy or a girl or
someone.
They decided this is the bestway.
But same as fruits andvegetables.
What if I don't like vegetablesand I like fruits?
Or vice versa.
You cannot tell me that thebest is to eat cucumbers if I
don't like them.
(20:49):
So best practices could be for aniche.
You know this could be good foryou if X Y Z, x Y Z.
So if you're an insurancecompany that's doing X Y Z, this
is probably the best for youway for you to configure the, to
configure whatever this, butnot just in general best
practices.
Or I may say our solution underthis circumstance is the best.
(21:13):
Configured like, like this andnot just in general best
practices is to put a firewallin a sandwich.
Yes, we did it 25 years ago.
I have no idea why, but youknow there's a lot of stuff.
But when we understand theunderground part not underground
the underlay part of thearchitecture and design, how
(21:34):
stuff actually works, how thetraffic flows to the environment
where the traffic goes work,how the traffic flow to the
environment where the trafficgoes, now we can understand more
about what is the best practicefor this company, for this
particular environment.
Augusto Barros (21:48):
Perfect.
So how do you think that we cansimplify this concept?
Like you use the example of thesandwich firewalls, right?
Or kind of the old idea, I'mgoing to put kind of my Cisco
firewalls in front of thecheckpoint firewalls, right?
Or kind of the old idea, I'mgoing to put kind of my Cisco
firewalls in front of thecheckpoint firewalls, so now,
right, if one of them have aproblem, I am safe, right?
There is a lot of probably kindof more technical details that
(22:10):
we normally would have to referto to explain why that may not
necessarily be a best idea,right?
Or maybe just a waste of money.
So how can we go throughdiscussions like this while
simplifying all the complexcomponents 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 andlet's say I don't know that, you
don't know English, and I startspeaking with you English and
you don't know English.
Or let's say I speak with youHebrew and you're speaking with
me Spanish, okay, and none of usdon't understand each other.
But if we understand oh wait asecond we actually understand
(22:51):
that we speak in a differentlanguage.
Then the moment we understandthis part, we may choose to
writing maybe signals, maybeimages, because we understand
this part.
We may choose to writing maybesignals, maybe images, because
we understand we're not speakingthe same language.
If I'm talking to you onback-to-technology, I need to
establish the understanding ofyour level of technology and how
(23:12):
geeky you want to go, or highlevel you want to go.
So this is in my mind for SparkInstead of simplifying right
away, why maybe you want to godeep, this is what you want to
do.
I need to understand hey, canyou guide me?
How do you want the creature togo?
Or can I guide you?
We want to talk about firewallsand architectural design?
(23:32):
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 ofcharacteristics point of view.
Evgeniy Kharam (23:45):
So you want to go deep.
So now we establish we can godeep.
Or you say you know what.
I actually don't want to godeep.
Just give me the high level ofwhy it's a bad idea in the
business.
So now we understand the level.
If you want to go deep, we cango deep on technology.
If you're going to a higherlevel, then I need to find
metaphors or analogies indifferent ideas or life to
(24:07):
explain to you what's happening.
But if I don't establish thispart, it's going to be bad,
because people are hearing beingfrom ideas that we don't always
want to say that I have no ideawhat 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 totell me where you want to go,
(24:29):
high or low, then it's helping.
Nobody looks stupid.
We are trying to get to the samecause, because I'm definitely
not trying to bring you down ortell you that you're not smart.
I just want to communicate withyou.
So when I'm definitely nottrying to bring you down or tell
you that you're not smart, Ijust want to communicate with
you.
So when I'm doing a call withanalysts, for example.
I usually ask guys, I can govery high or very low.
In case I'm going very deep ontechnology, please stop me.
(24:52):
I'm here for you.
I'm giving them all theindication and the rules of
engagement, what they can doLike oh okay, oh, no, evgen
again.
This is too low, oh, this istoo 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 andsmiles that are thinking I have
no clue of what you're talkingabout.
Evgeniy Kharam (25:12):
And it could be even harder when we're doing
this over Zoom and severalpeople, 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 whatyou're saying.
Then I ask you does it makesense?
And you're like, yeah,definitely all crystal clear,
but in theory it's not.
So there are different ways todefinitely validate what are we
(25:37):
talking.
In many, many cases, I will askis it something that helps you
in your environment?
Is this the problem youexperience, or can you ask me a
question that can help?
There's many different ways toroll this part and I think it's
also important, depending on theconversation when we're done,
(26:01):
to try to summarize what wediscuss.
Again, it's really going to bedependent on the conversation
and the person we're talking to.
Perfect.
Augusto Barros (26:07):
Yeah, and in some of these examples, right
that, through the many things wehave discussed so far, right,
we mentioned syslog by UDP anddifferent kind of layers of
firewalls, et cetera.
That starts to kind of show upa bit of our age here.
So let me bring things a littlemore towards these days.
Right, In terms of innovationin cybersecurity, what changed
(26:31):
in our world when we moved fromthat old on-prem environment to
SaaS, right?
What is good from how we are,the technologies that we are
dealing with today, and what isbad?
Evgeniy Kharam (26:43):
The good part we can scale much, much faster.
When we used to buy firewallthemes or whatever it is, we'll
buy and size it for the worstcase scenario, because maybe
during holidays or other timeswe're going to scale, not scale
times.
We're going to scale.
We're going to increase theenvironment throughput, so we'll
(27:04):
need to scale.
We will need to make sure ourequipment is capable to consume
whatever needs to be consumed.
In SaaS we don't, so our spancould be smaller.
Because we know it's easier toscale with the cloud.
We're kind of scaling itdifferently as well.
So this is the good part.
(27:24):
We're changing the architecturefrom very, very big boxes, if
you can say this, to very, verytiny boxes.
But they can multiply and addmultiple 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 codeand updates much quicker.
(27:46):
In the past we used to joke whenyou end up upgrading the
firewalls to version number x,then you're done and you start
again, because version y cameout and you need to go again to
all the 50, 100 firewalls to doit right now, or you will wait
and understand when is the nextversion coming every quarter,
(28:06):
every six months.
Right now, saas providersrelease version 2, 3, minor
versions every week, so we canget the features we want quicker
.
The problem we're getting.
So there's actually a couple ofother advantages I remove the
cost that I pay for people to doupgrades, I remove the SLAs and
(28:27):
I kind of now trust the SaaSprovider to keep the SLAs and I
don't need to do RMA of myequipment because it's there.
But it's also a problem becausenow I need to trust you that
you will actually do the SLAsand keep the SLAs and keep it up
and running and not put me indanger.
And because we are nowreleasing versions more often,
(28:50):
if you have a problem, you canintroduce the problem to my
environment much faster as well.
We had bad examples for thelast few months no need to
mention vendor names when anupdate caused a problem and this
wasn't a vulnerability.
It was a mistake.
But in the same time, if avendor used open source
(29:11):
libraries and there is an issuewith open source library, it
means we can introduce a problemthat came with open source
library vulnerability to ourenvironment much quicker as well
.
So there is a few issues thatcoming with this part as well,
because there's more trust.
The third party management ofvendors became quite a big
(29:32):
problem because in the past, ifeverything was in my environment
, I controlled everything.
Right now, my data is likeeverywhere, so I need to
understand how you're going totreat and do and work with my
data as well.
So it's definitely many, manythings that came as a blessing,
but also as a curse.
Another interesting part isactually a conversation with the
(29:53):
founder last week.
We spoke about access to theenvironment.
In the past, you didn't knowthere's a problem with your
environment, with yourapplication, until a customer
call you.
Now you can see there's aproblem with the environment
because you own the environmentin your data center, so you can
react faster.
This is another advantage.
(30:15):
Last disadvantage it's probablysomething I missed.
I'm sure that I think is a very,very big problem is a vendor,
almost by definition, haveaccess 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
(30:37):
because you have access to yourenvironment, 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 tobe closing and I believe in the
next five years all the vendorswill have to have an approval
from a customer to get access tothe environment or some kind of
mechanism of keeping theprivacy to the customer, because
(30:59):
unfortunately, vendors gothacked as well and get breached
as well, and then the bad guys,by definition, have access to
everything, but when they hackthe vendors, the same way, where
we have all those processes toallow developers to go into
production to fix bugs, etcetera, those break glass
processes, et cetera.
Augusto Barros (31:19):
We can have those with the cloud vendors as
well.
Right, it may be morechallenging for you to verify if
the process is sound and ifit's actually implementing the
barriers and the controls thatyou believe are in place.
Right, if I am a SaaS vendor,right, and I tell you I do not
(31:42):
have access to your data unlessyou allow me to do so and I give
you right, kind of a form, atype of workflow for you to
approve it, you still not sureif I just cannot do that
whatever I want, because it's myenvironment.
So, unless you, I have gonethrough certifications or
anything like that, that willput some level of assurance, or
(32:04):
you kind of went through theenvironment to do some kind of
auditing, or we have some kindof encryption in place where I
will only have access to thekeys as part of that workflow
that we built together.
Right, and you have someassurance because you are the
one in control of the keys allthe time, it's pretty hard for
you to be sure that I do nothave ways to bypass the process
(32:26):
that I'm giving you to give meaccess to your own data, and so
that's kind of really kind ofone of the big challenges for
SaaS environments.
I found interesting one of thethings that you mentioned that
is related to the elasticity ofthe cloud.
It was right in the beginning.
When you start mentioning theadvantages for SaaS environments
(32:46):
, you do not need to buy the bigbox just because of kind of
eventually running a holiday,you're hitting that spike of
traffic, for example.
But even if the technologyallows us to be more elastic,
there are still many SaaSvendors that implement license
(33:07):
models that are quite punitiveif you go beyond the level of,
or the amount of pre-hiredaccess or pre-hired kind of
volume that you agreed on.
Is that because they're tryingto 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, peopletrying to understand what's the
best way, to have some kind of alicense where people can
control the cost.
Because we unfortunately knowmany examples when you start
(33:47):
this vendor, why, and the costis five, for example, and then
three months after, the cost isseven and then the cost is 10.
It doesn't matter what, they'rejust putting numbers, numbers.
How is this one here in acontract and my cost is
duplicated right now?
Or is it because of DNS trafficor because of this traffic?
This is why we're trying tochange and play with the models,
(34:08):
the same as if you ask MSSPs.
We still didn't fix this tillthe end.
How do I charge Ingestionsusers?
Many different options tocharge by.
We're playing with these models, but there is no one model that
can fit for everyone, becauseeveryone is different.
And I think this is the same asvendors, because they're trying
(34:30):
to say okay, I can understandthis part, but the moment I get
to a point that you have moredata, then I need to pay money
for more data, and if I needmore data.
I'm going to just offload thisprice to you.
Augusto Barros (34:45):
As a vendor of a SaaS service there is primarily
volume-based.
I know how challenging it is toput together a pricing model
that will give some assurance tothe customer and give some
predictability to the customerabout how their costs will
evolve and, at the same time,protecting my margins and my own
costs.
It is very challenging becausewhen you were a SIEM, you're
(35:09):
essentially talking about datavolumes how much network traffic
, how much storage, how muchprocessing and you really need
to put some controls in placethat you're going to have to
pass to the customer in the formof a license agreement, in a
license model and it is reallychallenging to find a balance
(35:30):
between kind of what will beprimarily a benefit for the
vendor, what would be great forthe customer and what actually
kind of can work for both ofthem.
Yep, let me change gears again.
Let's go into another direction, although we may end up kind of
stumbling in things that we'vealready kind of touched.
(35:51):
What do you think has been themost disruptive security
technology in the last fiveyears?
Evgeniy Kharam (36:01):
It's an interesting question.
Security technology wedefinitely have the AI stuff,
but you know what.
Augusto Barros (36:10):
All right, let me stop you there.
We spent 37 minutes more orless, without touching AI.
It's a new record.
I know it's just the secondepisode, 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 maybea bit biased, but on the
corporate world, I think theenterprise browsers are
definitely changing manydifferent things.
Because they're collapsing manytechnologies under one vendor,
we work everywhere and becausewe are removed the perimeter for
(36:49):
a long time ago and it'severywhere right now we wanted
to protect people everywherethey're located and because we
more and more use the browser,this is a disturbing part and we
already saw some acquisitionsin this piece and again, if you
look inside and unpack how muchgoing in network security, this
(37:14):
is talking about ages ofdifferent technologies remote
access, dlp, malware, access ingeneral.
So masking so many differentURL filtering so many different
things.
I think it's definitely, in mymind, disturbing the space of
corporate security and what Ienvision is that in the near
future, some of the endpointsecurity companies will buy in
(37:38):
and buy some of the vendors inenterprise browser to have a
better control on the endpointin general and then going to go
and try to compete against theSaaS and theCC vendor as one
vendor.
This is in the corporate world.
Augusto Barros (37:52):
Perfect.
And you know, what I findinteresting is I remember
watching keynote session I thinkit was in Black Hat or Defcon
kind of from the remember theJericho Forum.
It was 20 years ago, right, andit was some of these ideas
about kind of collapsing theperimeter down to the endpoint.
And now we're going evenfurther, down to the browser.
(38:15):
Those ideas are already therebut we're only seeing a separate
practical implementations someof those ideas now, 20 years
after.
Then that's very interesting tosee where the ideas first came
up versus when the technologystarted to be available in a way
that was actually kind of easyto implement and available to
the masses, even if it's kind offrom an enterprise and
(38:37):
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 tofeel is potentially the API
security, because we have somuch machine-to-machine
communication right now and thisincludes the non-human
identities, but the idea thateverything is happening over
APIs.
So we cannot just unpack SSLand see we need to understand on
(39:05):
a deeper level thefunctionality of how API work,
what's business allowed and whatsecurity allowed as well, and
this communication is humongousand a human being cannot really
understand by themselves what'shappening.
This is actually the thingwhere AI will shine to help us
understand.
Like the simplest example notthe simplest one I like is like
(39:27):
from gaming, all the gamingcompanies right now.
Basically, when you play a gameWorld of Warcraft it's an API
going back to the server.
You can exchange money, you canget a better shield.
Augusto Barros (39:41):
It's basically an API call to get something
else or exchange some kind ofresource something else or
exchange some kind of resource,and, because of latency, there
are so many controls that stillrely on the client on this
gaming industry right, that it'spretty hard for you, kind of
from being the API on the server, to be able to validate that
(40:02):
everything is actually happeningas it should on the client side
.
And another thing that Ibelieve touches this API
security side is the agentic AI.
Right Now you have this AIsystems that can call other
things and they will call whatthey're gonna call APIs in many
places.
So the API security controls.
(40:24):
We will have to consider a lotof additional context when these
APIs are being called by AItechnologies where you can have
AI-based systems.
So that really gonna be veryinteresting to watch and see how
these things will evolve.
And I will throw almost thesame question but at the same
(40:47):
time, the opposite what do youthink is the most disruptive
technology to security?
Evgeniy Kharam (40:54):
In AI.
We need to understand how tosecure AI.
We need to understand how tounderstand and do security
around AI.
This is definitely somethinghappening in my mind.
I cannot claim I understand howto do it, but my mind okay.
I need to understand and learnbecause we don't understand
what's happening there, what'scoming, what comes out.
(41:16):
So how do we can help peoplethere.
And if a bank, an insurancecompany, 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 bigchallenge to solve.
(41:38):
Not how to use AI in securityis how to provide security for
AI.
Augusto Barros (41:44):
Right.
I'm thinking we're going tohave fun for far more time in
this space.
Nothing is solved and as thetechnology evolves, things get
even more interesting as timepasses.
Let me ask you I did this onthe first episode and I like
what it was by accident, but Ilike it so much that I'm
(42:05):
probably going to become one ofthe hallmarks of this podcast
what do you think we do righttoday as an industry In
cybersecurity?
What are we doing right?
We like so much to talk aboutthings that go wrong right, so I
want to ask you what do?
Evgeniy Kharam (42:20):
we do right.
We definitely think weunderstand.
It's not just one part ofcybersecurity.
We need a village to raise achild.
We need multiple professions,multiple people, multiple
technologies, multiple things tomake it happen.
It's not just the securitycontrol, it's not just the
policies, it's not just thecompliance, it's not just X, y,
(42:43):
z.
It's many different peopleworking together to open up and
communicate better.
So we are more and morecommunicating better with each
other to actually address theproblem together.
Augusto Barros (42:58):
Yeah, I think, learning right that we need
multiple skill sets.
I think it's something that andI'm happy to say, I think we
know that as an industry.
I think one challenge we haveis to make the new entrance in
this industry to learn that assoon as possible, because I
think, especially when you seethe more technical people, they
(43:22):
tend to get in with theimpression that, hey, I know
this thing about protecting APIsand everything else that people
in security talk about isnonsense.
What really matters isprotecting the API, and then,
with experience and over time,they learned that the field is
far broader than they reallywere able to perceive in that
(43:45):
early moment.
So I think one of thechallenges that we have is
accelerating that awakeningmoment where they really kind of
realize it's not only thispiece that I know well and that
I can understand the challenges.
There are more things around itthat 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 howto work together, but we still
want to blame someone.
So, instead of working togetherand 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 wedon't want to do the boring
stuff.
We want to find the sexytechnology that magically will
solve the stuff.
And every time you ask someonehow's your asset management?
They're all.
How do you know you have EDReverywhere?
How do you know you collect allof the same from the same?
Do you know all you like?
(44:44):
Even back in hard-draft dayswe're like okay, we're going to
need XYZ.
Do you have an asset managementof the security controls you
have?
How many firewalls you have?
Is everyone configured or isall of them logging?
Augusto Barros (45:03):
And this is like the boring stuff nobody wants
to do.
Yeah, a lot of the assetmanagement right, it is remember
, right, the critical securitycontrols is the first thing
right, right at the top.
Right kind of know what youhave there.
And there's so many breachesout there that are not because
there's kind of a high technicaland high advanced threat
behavior right or techniquesbeing used is essentially
(45:23):
finding a system that wasforgotten that can fall through
the cracks.
So either no one accounted forit or they were just kind of not
part of the vulnerabilitymanagement process.
It was something that was notincluded in all the processes
and asset management andmonitoring and et cetera.
Right, that's still kind ofprobably one of the main reasons
(45:44):
we see breaches out there.
Evgeniy Kharam (45:47):
Yep.
Augusto Barros (45:48):
All right Again.
That's what happens when theconversation is fun.
We are out of time.
I really, really want to thankyou for joining kind of the
podcast.
It was a very interestingconversation and we will have
this out early in January.
So if you're listening to us,you are talking to us from the
(46:09):
future because we're still earlyin January.
So if you're listening to us,you are talking to us from the
future because we're still herein 2024.
So I wish you some good andhappy holidays and a good end of
the year, but for you they'rein 2025.
You already went through allthat.
You're probably recovering foreating, all the turkey and et
cetera, and the drinking, etc.
(46:30):
But I'd like to thank you forlistening to our podcast and
we'll see you again soon.
Thank you again and have a goodone.
Evgeniy Kharam (46:41):
Thank you very much.
Very happy to be here today.
Popular Podcasts
United States of Kennedy
United States of Kennedy is a podcast about our cultural fascination with the Kennedy dynasty. Every week, hosts Lyra Smith and George Civeris go into one aspect of the Kennedy story.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
Bookmarked by Reese's Book Club
Welcome to Bookmarked by Reese’s Book Club — the podcast where great stories, bold women, and irresistible conversations collide! Hosted by award-winning journalist Danielle Robay, each week new episodes balance thoughtful literary insight with the fervor of buzzy book trends, pop culture and more. Bookmarked brings together celebrities, tastemakers, influencers and authors from Reese's Book Club and beyond to share stories that transcend the page. Pull up a chair. You’re not just listening — you’re part of the conversation.