Uncovering Security Risks in C++ Apps with LD_PRELOAD and API Interception @ C++ Bay Area Meetup

0:00
well thank you everyone for the opportunity to to present my story here
0:06
I’m Kiran committee I’m the founder and CEO at Deep Factor so for those of you
0:11
that don’t know uh What uh deep factor is we’re a developer security company we help you create secure software by
0:17
detecting vulnerabilities during Dev and tests so we do some really interesting things around observing running
0:23
applications and running containers and that’s what this presentation is uh fundamentally based on three years of
0:29
work that we put in to create some really really unique things about how you can detect security bad security
0:36
behaviors in your applications by watching every thread every process running inside your applications whether
0:42
it’s running in a container or in a monolithic application and then
0:47
detecting the bad things that could happen um that could be happening inside your
0:53
applications now why is this important because there’s a list of vulnerabilities that you know your
0:59
static code scanners will detect but static code scanners do not scan your third party code and third-party
1:05
code these days is 80 of your applications not more and depending on the apps that you’re writing
1:11
so for detecting vulnerabilities in third-party code you have software composition analysis dependency scanners
1:17
container scanners and things like that but they only look for known vulnerabilities that are cves that are
1:23
out there what about bad behaviors that could result in a zero day tomorrow
1:29
that may be hiding in your applications especially if your application is a combination of your code your
1:36
dependencies and the packages that make up your container the only way to detect these vulnerable
1:41
vulnerable behaviors is to observe running processes and that is
1:48
essentially what this talk is all about how do you analyze running applications and processes and detect bad things that could that your app could be doing a
1:55
simple example just to kind of semi-funnily talk about it is your
2:01
developer imported a piece of dependency and that dependency is making an outbound connection to let’s say North Korea and you did not
2:08
even realize that it wasn’t a CDE so your software composition analysis or dependency scanners didn’t catch it how
2:15
are you going to catch those types of things that in a nutshell is what runtime analysis is that today’s talk is
2:20
going to be about before we get into the weeds of the tech
2:27
um the the actual interception and the types of things that we find it’s important to understand why this is an
2:33
important problem to solve now right so let’s take a look at what has been happening with software over the last
2:39
let’s say decade or so you know we’ve we’re sitting at the intersection of a few interesting Trends
2:46
right one is you know a lot of developers are now especially new age developers are creating applications in
2:51
containers uh it uh I how how common is it in your organization since you guys
2:57
are CC plus plus you probably are probably one of the last ones that are probably going to convert to Containers but
3:03
um you know show of hands how many of you guys build containerized apps
3:08
okay so still even the marketing person in the group is building containerized apps that’s
3:14
awesome um how many of you guys just uh understand the lay of the land here a little bit are in our actual Developers
3:23
how many in uh devops how many have the insecurity you could
3:30
you could raise it multiple times too awesome and uh how many in QA
3:38
okay cool so majority developers thank you for that
3:44
um the second Trend that’s happening is the release velocity thanks to cicd we’re shipping applications really
3:49
really fast how many of you guys have CI CD in place in your company
3:54
and the rest of you guys are you like do you create bills like how often do you create bills like is it
4:00
like once every few few months on demand
4:07
likely okay um yeah but needless to say CI CD is becoming you know an extremely important
4:14
thing and majority of the organizations do it uh the third one that’s happening is we are
4:21
able to automate things we have we automate quite a bit of things these days uh in the past only the best you
4:26
know when I say in the past like let’s say a decade ago only the best organizations were putting a lot of effort around automation now pretty much
4:33
everybody does automation how many of you guys have awesome unit tests Automation in place
4:42
how many of you guys how many of you guys have Automation in place less than awesome
4:48
maybe okay all right cool
4:53
um the one piece that so we’re able to build things fast we’re
5:00
able to assess if they’re if they’re if the functionality is supposed to be
5:06
what it is and therefore which ship thinks fast all the way through the CI and but we stop
5:12
sometimes at the deployment time and why it’s generally because there’s some security thing or some someone needs to
5:18
come in and do an extra layer of check from a security perspective before they’re comfortable deploying the
5:24
artifact to production how many of you guys have all the way through completely automated CI CD like does it
5:30
automatically gets deployed only the devops person in the room that’s that’s awesome
5:38
um so yeah so that that’s kind of the kind of what we see out there as well which is a lot of the people a lot of the organizations create code fast build
5:45
fast test fast but shy away from automatic deployment automated deployment and security seems
5:52
to be one of the biggest reasons for it and we believe that the next few years let’s say five maybe even 10 years
5:57
security has got to be an important part of quality just like how we say today’s quality
6:04
when you ask you Engineers you have functionality I want to test functionality I want to test performance I want to test you know reliability and
6:10
things like that they’re all part of quality but when there’s log for J the QA person is not
6:17
filing you know uh the ticket saying hey I found love for Jay in this container there is some other security team that
6:25
is doing it or it is baked into your CI pipeline in such a way that the devs get informed but the testers don’t think of
6:32
security as an important aspect of quality and that needs to change it is changing and we believe that that’s kind
6:38
of the next five ten years we’re going to see security also becoming an integral part of your CI CD and quality
6:45
in general if you don’t do it
6:51
we all know what’s happening lots of lots of attacks and the interesting
6:57
thing that that we see we have seen now is that
7:02
the attackers have become quite sophisticated if you leave your application with potential
7:08
vulnerabilities then the attackers are able to they have the same resources that your Dev teams
7:15
have Cloud automation Metasploit so they’re able to create scripts to
7:20
automatically you know uh leverage and exploit vulnerabilities that you may have like staggering stat is that within
7:26
72 hours of log4j becoming a Known Zero day vulnerability there were 830 000
7:33
attempts to exploit it it is it is just staggering and that’s because of the automation that is
7:38
capable and that’s at the hands of the attackers yes sir
7:46
attempts yeah oh that would be that would be crazy if it was successful
7:52
attacks um so and and when is the right time
7:58
therefore to fix these security vulnerabilities who in this room believes that their team writes perfectly secure software
8:04
all the time that kudos to you sir that’s awesome
8:12
design Hardware it’s fully verified awesome only the hardware person in the
8:18
room raised their hand so obviously it’s imp it’s really hard to confirm that
8:24
you’re writing secure software 100 of the time and what is the best time to so
8:30
vulnerable software exists everywhere so what is the best time um to fix vulnerabilities in your
8:35
software it is when you’re creating them it’s it becomes more and more expensive
8:42
to fix issues as your artif artifact is moving to the right in your in your CI
8:48
pipeline from Dev you know architecture time to coding to testing to integration
8:54
testing and and all the way through to prod it becomes more and more expensive to fix things as they get closer to
9:00
production so hence which is why you know I’m sure the devops person in the room relates to
9:06
it we’re trying to make Dev you know security tooling into the devops pipeline so that we can detect these
9:11
vulnerabilities early on now let’s look at the security tooling there are different approaches to
9:19
understanding security risks in your application let me go one by one
9:25
and security is the layers game even if you gather use one tool that detects one type of vulnerability it doesn’t
9:31
guarantee that you’re protected against other types of vulnerabilities first common thing that is done is code
9:37
scanning you know you have a scanner it scans your code detects common vulnerabilities that are present in your
9:44
code sometimes you know and these tools commonly known as static application security testing tools SAS for short
9:51
have been around for almost two decades now um you know with the coverity you know
9:56
the likes of those guys leading the pack uh in the early 2000s these tools detect vulnerable
10:04
vulnerabilities that are lying in your code but we all know your code
10:10
the custom code that every organization is writing these days is only a small fraction of the entire application that
10:15
is getting shipped eventually uh it may be a little less so for cc plus plus application but it’s
10:21
definitely more for python node.js you know those types of applications because they’re bringing in lots of dependencies and you cannot scan your dependencies
10:27
code or typically not common practice to scan all of that using your SAS
10:33
so the industry came up with this second set of tools called software composition
10:39
analysis software composition analysis tools are examples are dependency
10:44
scanners container image scanners these can also be baked into your pipeline they detect vulnerabilities that are
10:51
known they compare the dependencies that you have or the packages that are
10:57
installed in your container image with a whole list of cves that are out there
11:03
you know published either with um the nvd database vulnerability database
11:09
or dozens of other you know vulnerability Feeds out there that are that are published by operating system
11:15
vendors for example Ubuntu Red Hat published their own CDE feeds as well um based on that you can say okay here’s
11:22
the list of known vulnerabilities and here’s the list of packages that I’m using each of these packages has this
11:28
known vulnerability therefore I am susceptible to this vulnerability it is a it results in sometimes a lot of noise
11:34
because um you know it’s it’s not as intelligent it’s just purely based on a list of uh
11:40
known vulnerabilities out there but the more important thing that is kind of relevant to today’s discussion is
11:46
what about vulnerabilities that are not known that are just bad behaviors that are
11:51
existing in your application or your processes your your devs either have written code
11:58
hopefully not malicious with malicious intent but hopefully just a mistake or they’ve brought in third party code that
12:05
is doing bad things that is not yet a known vulnerability it could become a zero day vulnerability
12:12
tomorrow it once it becomes known uh but it may just be hiding you know within
12:17
your code deep down to detect those types of issues runtime analysis of your applications is
12:24
the right way to detect them this approach essentially there’s a different a few different technical ways of doing
12:30
this uh Where You observe what your processes are doing as they’re running
12:36
what file system Network memory and related behaviors are they exhibiting
12:42
and based on that are there any vulnerable are there any insecure behaviors that are actually
12:48
being exhibited the interesting thing about runtime security is this is actual bad behavior that your
12:55
process is exhibiting because it did run and do something that is insecure
13:01
whereas the um items on the left SAS and sea are
13:07
generally speaking um May that code path may not even be taken by your application so it’s it’s a
13:13
it’s a potential it’s in a for lack of a better word it’s a broad kind of guess on the this
13:21
is something bad in your application code or in your dependency it may or may not happen but the other
13:28
if it happens at runtime you know it has happened as you go along to the right from Dev to
13:34
prod runtime security can also play a great part in compliance
13:40
many uh some of the compliance Frameworks like sock 2 or PCI
13:45
Etc require that you have boundaries around how your application
13:51
is behaving when it comes to its file system Behavior or network Behavior so on and so forth for example if there is
13:57
a process that is running in your application that is touching Etsy password or some kind of some parts of
14:03
the file system that is it’s generally not supposed to be touching or exhibiting privileged escalation type behaviors maybe it’s using set uid in
14:09
certain ways or set GID in certain ways then it’s a good idea to Cache those things and if you don’t you may be
14:15
violating Talk to Type 2 as well depending on which line item in the in
14:20
these compliance Frameworks that you’re looking at so it’s important to think about security as a layers game and it’s important to incorporate security all
14:26
the way from left through to the right for completeness of it now let’s specifically start doing a
14:35
slightly deeper dive into runtime security how do you actually
14:40
look inside a running process and gather all the Telemetry that you know about the file Network process memory behavior
14:49
that it’s exhibiting and then how do you detect anomalous behavior from it
14:56
the first step of that in order in order for you to be able to get to the end goal of detecting anomalous runtime
15:01
Behavior you need to be able to instrument an application and look inside the application
15:07
there are several techniques that can be used to do it we have a nice white paper I’ll share with you the link at the end
15:13
of it you know and where our CTO our CTO Mike Larkin he’s the father of the open BSD hypervisor so really deep down in
15:21
the weeds brilliant guy he wrote this white paper you know working together with the rest of our team
15:27
um it’s it’s available for everyone to access so I can share with you the link at the end but in this white pages this
15:33
table is essentially a screenshot from that white paper um it talks about four different ways in
15:39
which you could get inside the process and start observing what the process is
15:44
doing I’m going to focus on two of those approaches right now import table rewriting and callbacks
15:50
um the import table pre-writing approach is essentially
15:55
uld preload how many of you guys are familiar with LD preload how many of you guys have played with LD preload
16:01
awesome um you’ve done everything hands up for everything wow awesome so
16:09
LD preload is a way to get in your process address Space by preloading a library a data so for example
16:16
when you um essentially LD preload you get a chance
16:21
to be in that processes address space and you will be able to then start
16:28
understanding or you’ll be able to then do interesting things it’s typically a
16:34
technique that is used by monitoring tools datadog or
16:39
um not sure if Splunk uses it but but a New Relic and and tools like that defactor
16:45
we use LD preload as well these are the once you get in using LD preload then
16:52
you can start doing some really interesting things and since our goal here is to observe how
16:59
each of these processes is behaving with respect to file Network Etc our first order of business after we’ve done LD
17:05
preload is to collect the Telemetry from these processes around how many F opens have I done you know
17:12
which files am I opening how many networks you know connects have I done you know where am I connecting to by
17:19
looking inside the payload so I need to be able to look at those calls and those calls are you know many of them are in
17:25
libsy and and some other libraries depending on which ones you want to intercept but the goal then is after you
17:32
get in you want to create uh you want to identify the apis that you want to intercept and you want to start
17:38
intercepting them yes sir yes ma’am yep absolutely sjs is another great tool
17:45
um the thing with s chases you can at least to my knowledge you can look at it after the system call has happened you can’t look at it in the user space
17:53
um before the system call becomes a system call so that’s what LD preload allows you to
17:58
do is it gives you a lot more flexibility around it um exactly
18:04
uh Dan for those of you that couldn’t hear Dan’s question why not modify the
18:09
kernel and do this in the kernel itself there are evpf that’s column number three over
18:17
there the Callback approach right so ebpf is another way to get in the
18:22
process space and do something similar there are pros and cons of both approaches and in this white paper we’ve
18:27
analyzed both of them and and there’s depending on your use case ebpf might be useful for some and Le
18:33
preloadus is a it could be a better fit for some the just to touch upon a couple
18:39
of these pros and cons with the LD preload approach you have to intercept a specific process
18:46
and only that process is being intercepted but if your goal is to intercept
18:51
everything that’s happening all the processes that are running on the host then doing it in the kernel is the right way but doing in the kernel can
18:57
sometimes be perceived as intrusive because if there is a bug in the kernel you crash the entire host also to turn
19:04
on ebpf especially in kubernetes environments if you have multiple kubernetes hosts you want to make sure
19:09
that you have a certain kernel version that supports ebpf and some Enterprises might not want to use that kernel
19:16
version so the other limitation is fargate it it really yeah it really
19:21
depends uh the question is you know which one is better I don’t know if there’s one better answer for everybody
19:27
it really depends on what your Enterprise wants and where which approach you fit in but
19:33
from what we have seen if your goal is to observe more
19:39
things about your application semantically richer things about your application
19:45
and you’re okay doing LD preload especially in Dev test and staging type
19:50
environments then having that access into the user space
19:56
of the process is far more effective because you can see calls before they become system calls
20:02
but if your goal is to observe everything that’s happening on the host every process every container that is
20:09
running on your kubernetes host probably for Far Right threat detection live you
20:14
know live threat detection on a on a production system where you want to be watching everything
20:20
then ebpf is probably better suited so depending on which one you know you’ve got you got to pick the right tool for
20:26
the job cool so okay now let’s say we got in with nld preload
20:32
into the process address space the next step is to is to gain control when somebody says
20:38
you know in this example Malik I wanted to go to my Malik because I want to I want to track that you’re doing a Malik
20:44
only then I’ll be able to understand if you’re doing anything malicious or not for so
20:50
the next job is next step is to create trampolines so you know there’s about 200 different things that you could
20:56
watch in your in each process you know the span file memory Network and process
21:01
behaviors so you end up creating trampolines for it this is exactly by the way guys what uh uh container
21:08
runtimes do like Docker runtime for example you know does something similar
21:14
to this to create that isolation at the above the operating system level uh I I’m not sure if they
21:21
preloads but I I don’t believe they do but I think it’s more uh but the concept
21:26
of creating a trampoline is is common across container runtimes in fact my first company ring Cube Technologies
21:33
um in 2011 we sold it to Citrix um we built a container runtime for the
21:39
Windows operating system before Docker existed so we used something similar but for Windows uh where you know something
21:45
like a detours for those that are familiar with it but anyway so the next step after you get into LD preload is to
21:52
create these trampolines identifying which calls you want to watch and then create those trampolines
21:58
and I in our case we identified about I don’t know somewhere between 150 to 200
22:03
you know apis and create a trampolines for them
22:09
um with ebpf it’s a little bit different because you’re doing it at the Cisco level so after the Cisco is made by your
22:16
process evpf which is part of the kernel um then captures the stream and then uh
22:22
yeah it performs the analysis on it in the kernel so again which one is better there’s no one is better it is really
22:29
what tool you do you need for the show question yeah you you well you can do Cisco
22:35
interception also I I believe before the transition to the kernel happens so
22:41
um I I I’m not sure um if is the question again do you need
22:47
to do both I see I don’t know the answer to I I think
22:54
if uh I I do not know the answer to that
23:01
question [Music] um yeah BPF yeah
23:07
okay so some of the things that we’ve done uh now that you’ve gathered the ins the
23:14
Telemetry from each of these processes how do you detect anomalous behaviors what is an anomalous behavior and
23:21
there’s a whole bunch of CIS benchmarks as well as tools like Falco that have you know that that uh had created it and
23:28
we uh essentially took about 80 different behaviors that
23:34
fall into this category that I would say you know can be uh you know span across
23:39
insecure execution add file system behavior that system calls remote code
23:45
execution privilege escalation you know uh so on and so forth so about 80 different things 80 85 something like
23:51
that that we’ve created and these rules essentially mean so essentially what we do is when the process is running
23:58
the Telemetry from the process can be collected using all of the things that we talked about and then once you collect the
24:05
telemetry you can analyze the Telemetry for and compare them with with these rules
24:12
um and we I’ll spend a little bit of time on these rules as well just so that we can kind of have a geek out a little bit on
24:18
those um you know what rules kind of are some examples of anomalous behavior that you
24:25
should be watching for I’ll spend a little bit of time on that
24:30
on those rules in just a little bit but um before that it’s important to understand that
24:38
to productize something like this you’ve got to be able to support monolithic
24:43
applications um you also have to be able to support containers out there
24:50
you have to be able to support kubernetes deployments and you have to be able to support uh different schedulers like swarm or
24:58
ECS or even Lambda with container type modes so in all of these different modes
25:03
that we had to create when we spent three years on building this uh Tech and you know we three now almost three and a
25:10
half years um and you know different all of these modes essentially had to be created in
25:17
order for it for you to easily go you know simple command line to do all of this magic behind the
25:23
scenes So when you say DFT is dfct will run my application or on my container
25:29
um what happens is every process that is running in that container essentially we
25:36
preload the init process of the container which then carries through all the child processes so they all get
25:42
instrumented and um the Telemetry corresponding to these
25:47
each of these like 200 types of intercepts is watched and collected and
25:53
sent over to the analysis engine and then all of this data goes to the analysis engine which is where the rules
25:58
are compared against so let’s let’s get into those rules so I
26:04
can show you a little bit of what those what those rules are
26:09
yeah so I’m just going to log into the so this is the back end of it so all of
26:14
the Telemetry that is collected ends up going to the back end um the we call that the portal I’m going
26:21
to just uh click on one of these applications that is provisioned in this application we give like the
26:28
overview of okay here’s the vulnerabilities in your container package and here’s your
26:33
runtime violations and so on and so forth but for the purpose of this Meetup I’m just going to focus on the runtime
26:39
violations um so we were able to basically by doing the LD preload detect all of these
26:45
things about your application you know what namespaces is running on in kubernetes uh in this particular case
26:50
what uh ports is it listening on what incoming connections is it making without bound connections is it making
26:57
what DNS lookups is it doing Etc and once we collect all of that information detect anomalies around it so um the way
27:06
you get in like I said is like you can say Okay I want to scan my container image statically I want to look at
27:12
vulnerabilities in kubernetes workloads Docker containers other containerized deployments so on
27:18
and so forth and you know for example if it’s kubernetes you just drop in this web hook and configure like which name
27:24
spaces you want watched if it’s a simple Docker uh you know container you can
27:31
just simply say dfct will run my Docker container and so on and so forth once you do that your application shows up
27:37
here in the list of apps and then you can click through it and uh and watch
27:43
look at the list of bad things that could be there in your application now specifically focusing on the rule set
27:51
that we look for from a runtime perspective um it’s it’s this um
27:57
here’s here’s a here’s a full list of rules um just for the morbidly curious
28:03
um folks it’s in this case for example this tab we’re looking at bad
28:10
you know behaviors that could potentially result in privileged escalation like uid changes GID changes
28:18
um PK exec that’s an interesting one um from a insecure execution perspective
28:25
you know Secrets being left in your environment variables developers not using Vault but postgres passwords being
28:32
hidden in in clear text type thing and we see that all the time actually um in in real Enterprise applications
28:41
um other examples here could be
28:48
process elevating itself or or running is root or using unsafe random number
28:53
apis using Rand instead of srn48 you know something like that we see that all the time so it may not exactly be
28:59
security only related it’s just good programming practice as well so having rules like that will help you catch
29:05
those things process creating um a Cron job you know that’s that’s an
29:12
interesting uh you know alert application launching a shell that’s a potential cause for concern
29:20
somebody launching a package manager inside a container and this is a sign of you know them trying to install
29:26
something and if it’s being done by some dependency that you imported and that’s that’s cause for concern you’ve got to
29:32
take a serious look at it um netcat being launched or things like
29:38
remote copy SCP and rsync being launched from inside your application process these are all things that should
29:44
typically not be happening in in Enterprise grade applications that are running in production but you’d be
29:50
surprised I think uh you know it’s it’s it’s good to watch for them than not right yeah yes sir question
29:56
I think I think we may if you yeah yeah
30:02
um I think we probably have a role for that so let’s see if uh if one of these rules actually
30:11
text that program requests allocation of
30:16
uninitialized memory that’s a good one using unsaved strings
30:27
I think I remember seeing one of those it could yeah
30:35
wxrx
30:46
if the application attempts to allocate memory with both writable and executable permissions simultaneously
30:52
allocating W plus X memory is a technique used by attackers when uploading Shell Code into a hollow
30:57
process that could be essentially what you described
31:08
and then turn into ex executable I think we catch that too but
31:14
I I think it catches for not just at the same time but also writing an
31:20
execute separately I I’m not 100 sure but you asked a great question I’m going to check with our team if not we can add
31:27
a rule to it but yeah sorry yeah exactly so in uh the question is can you add
31:34
exceptions so here if you see that uh this list there is an ignore if the
31:39
following processes trigger the alert rule so you can customize this list it’s too small of a font so you may not see
31:45
it but basically you can add ignore lists you can change priorities depending on your applications you can
31:50
turn these alerts on or off you know as you create a policy that makes sense for your app
31:56
um that is the because not everybody’s app or not every
32:02
organization is going to be looking for the exact same product so we do have default policies but you can customize
32:07
it and add exceptions to it cool so that is
32:14
[Music] um a list of those rules there’s also just to kind of briefly
32:21
touch upon it some other interesting things that you could do now that you’re in the system if you want to take this a
32:27
step further let’s say you’ve done ldp loan you’ve detected runtime risks and that’s great
32:32
there’s another benefit of being in the process remember I talked about container
32:38
scanning or dependency scanning being too noisy because it tells you everything that is a known vulnerability
32:44
what if you could then compare that and correlate it with what your application
32:50
is actually doing at runtime and say I know my container has these you know
32:57
500 packages in it I know that you know 100 of them are vulnerable which is what like jfrog x-ray for example will tell
33:03
you but if you could correlate that with the factor and say okay there are in this case
33:09
you know um total of 30 13 36 packages
33:14
562 are vulnerable you know 33 are used and 59 are both
33:20
used and vulnerable so as you are prioritizing which ones to
33:25
fix which you know packages to kind of fix you can look at the used and
33:30
vulnerable ones first of course your security team will tell you you’ve got to fix everything but
33:36
there’s different ways of fixing it right and you can just change the order a little bit you can prioritize the
33:41
things that are used first then you can say the things that are not used I’m going to fix that later or I’m
33:47
going to consider removing them from my package because I’ve never seen them load even though I ran my application for 10 days and and Dev test and prod
33:55
so yeah so this correlation with usage gives you runtime enriched software composition analysis which is kind of
34:01
really interesting so there’s some a way to kind of marry jfrog X-ray and the factor you know findings there
34:08
yeah we we give you that connector into the Running World and and therefore map it back yeah there’s there’s benefits of
34:17
doing both yeah cool um let me go back to my slide I think
34:22
we’re kind of towards the end of it okay yeah this is I guess this is the last slide so a few resources that I want to
34:28
point you to is uh one is if you uh like what you saw today you
34:34
want to connect with me personally please uh hit me up on LinkedIn um you know my name is Kiran committee
34:40
and if you search for dfactory you’ll probably find me um the uh other thing for those that
34:47
feel like this is something that is useful for your own companies the apps that you’re creating uh you know you can
34:54
either scan the QR code or reach out to um hello appdfactor.io
35:00
and you know one of our guys will reach out to you and um you know you can get a free assessment of what this type of
35:06
tool can find in your own application it’s it’s free so take advantage of it and the other resource that I said I
35:12
will share with you is uh there’s a good white paper for the technically interested if your goal is not to assess
35:20
vulnerabilities in your app but rather to um to understand the tech of
35:27
interception if you go to the Deep factor.io website there’s a resources section where you know we’ve created a
35:35
white paper um so if you look for white papers here you’ll see that uh this this one the
35:42
observing API Behavior via API interception that’s a great resource for you it’s a it’s a fantastic
35:49
coffee read so um you can
35:54
um I enjoy it in my copious spare time but I hope you do too
36:00
so that’s all I have guys I I hope you found this talk useful
36:06
thank you so question uh here for those on the
36:13
zoom is if uh this needs to be deployed in production what kind of overhead are you looking at uh it’s uh typically from
36:21
what we’ve seen again it depends on the type of your application what your app is doing but the average that we see in
36:27
our test environments is you know less than a couple percent uh from a CPU memory perspective and from a network perspective really depends on what your
36:33
app is doing yeah so we Benchmark it with a few apps in our labs and and uh yeah
36:40
yeah another question oh the analysis engine uh from the so the question is
36:45
what data is sent from the uh uh from the instrumented apps to the
36:51
factor so there are two modes to set up the Deep Factor backend uh we call it the portal that’s the one that receives
36:58
the data and analyzes it you can either use you can either set it up on your site in your own AWS account or our AWS
37:05
account we we offer both options for customers that don’t want any data to be sent to us you can set it up in
37:11
completely your own AWS and we’ll manage it for you for customers that send it to us the data that gets sent is
37:18
essentially all of the interception data deduct right so all of the events that are
37:23
being watched uh and um so essentially the way it works is let’s say for example kubernetes right
37:30
so um when each of these processes is observed and
37:35
um the data is gathered the data that is gathered is just strictly the fact that you made XYZ call and here’s an
37:42
interesting piece of information in the header for example that data is written to a buffer the buffer gets flushed over
37:47
from time to time over https back to our portal so it’s essentially that but before it gets written to the buffer
37:53
there’s a dedup that happens so that we don’t send too much data let me repeat the question for those on
37:59
Zoom so that you know I understand and also to make sure that I understood your question properly the question is
38:06
if there is a malicious behavior that is detected in fraud or some kind of alert that the factor or some other tool
38:11
triggers for you the next order of business should be to write a unit test for it and make sure
38:16
that that behavior is tested to the left during during Devon test can you do that absolutely I think you should totally do
38:23
that you should do that we don’t I mean that’s yeah that’s not a
38:29
tool that we build but I think it’s more like uh application specific I would think in your really specific to the
38:36
customers that we work with but um once you write a tool to
38:42
to determine that bad behavior then you can always retest it in your Dev test and make sure that the factor doesn’t
38:47
trigger that alert again that’s a good way to kind of you know improve the security posture of your app
38:53
yes yeah so the question is instead of catching yeah so our policy is not a enforcement
39:02
our Tool’s not an enforcement tool it’s purely a monitoring tool so but you can
39:07
create policies that allow you to say only look for these bad behaviors so essentially to accomplish what you just
39:13
said you would turn off out of the 85 something rules you would turn off let’s say 50 rules and only look for 35 rules
39:19
we can we can alert you basically like if it’s one of the if it’s one of the 85 rules I mean it’s possible that there’s
39:27
other rules that we don’t have today that but we could easily add it because you know we have the the intercepts uh
39:33
but in the spirit of your question is if if there is a rule that you don’t want
39:40
uh if there’s a behavior in your application that you don’t want happen can you be alerted the answer is yes and
39:45
that’s what the policy is for yeah I’m guessing Alex you said Malik as more of
39:50
an example rather than that specific rule yes there’s another question Yeah
39:55
question for those on the zoom is how do you deal with false positives and reduce essentially
40:00
um the noise and you know make it high signal there’s obviously some learning
40:06
curve that’s going to be there for every organization so when you turn this on initially you’re going to see some things
40:11
um there are two ways to think about it oh I’m seeing you know lots of things about my app
40:17
um I want to turn it off or you know why is my app doing this I want
40:23
to find out why and then decide whether to turn it off or not I am of the belief that you rather know that your app is
40:30
doing XYZ behaviors than than not and believe that it’s secure so so I you
40:36
know our guidance is turn it on for a few days figure out what you see then work with uh you know our team or just
40:43
your own experts in in the in the team to figure out how you can which ones you
40:48
want to turn on which rules you want to turn off because there’s obviously flexibility in the tool to configure the
40:53
policy the way you want but I would initiate my my personal uh recommendation is to turn on Max Alert
41:00
in the beginning see how it goes and if you don’t see that many Fantastic you your team has written extremely
41:06
secure applications but if you do see a lot then figure out which ones are false positives but this is not something that
41:13
you just go oh I’ve turned it on you know you’ve got to fix everything you’ve got to put some thought into it and make
41:21
it a a project just like setting up jira as a project in your company right yeah
41:26
we haven’t reported yet but we have we do find some interesting things in Java
41:32
runtime itself you know so um and and we’re planning to figure out
41:38
like what’s the right way to kind of package it up and report it out another question uh yeah exactly any tool can be used by
41:46
the good guys or the bad guys but the the not having a tool is not the answer to that right so yeah yeah you can’t say
41:54
don’t build fast cars because people that drive fast cause accidents right so
42:03
I just have a comment on your comment which is uh earlier you were uh were comparing your product uh you know
42:09
you’re saying well you know it’s also you know how jira does it right so I just want to say that that’s not a great
42:15
advertisement to compare to jira
42:20
okay I didn’t compare my tool to cheer I I basically said
42:25
just like how setting up jira or any bug tracking system is a project in the engineering team incorporating a tool
42:33
like this the factor or others who should be treated like a proper project in the team you can’t just turn it on
42:39
and say guys fix all of these things you know that’s that’s gonna fail Dan’s asking all this Dan’s asking all
42:45
the hard can I can I say pass I’m just I’m just kidding what we do is
42:53
oh yeah save that one for the bar after but um oh this
43:00
no see the uh one way to kind of put some boundaries around it is if you see
43:06
that there’s another LD preload happening we don’t launch so that’s what we do today like if there’s if there’s
43:12
no but the order of preload at least to my knowledge is something that is uh like if there’s another Le preload and
43:19
your lunch if if the if the next LD period comes in after you are in then I
43:24
don’t know how to I have to check with my team members uh how that I see it is
43:30
true then it’s a good bar conversation right after this yeah