About this talk
This talk focuses on runtime security with an emphasis on the Falco project, which is a runtime threat detection tool for cloud-native environments. The speakers explain the importance of monitoring security events in containerized applications while they are actively running on servers. They discuss the evolution of Falco and its capabilities, including the use of extended Berkeley Packet Filter (eBPF) for efficient kernel monitoring without compromising system stability. The speakers describe how Falco utilizes system calls to track process activity, network interactions, and more. They highlight the role of Falco Sidekick, an extension that facilitates alerting and integrates with various other tools to enhance the observability of security events. The session includes a demonstration of the Falco Sidekick UI, showcasing its ability to present detected events in a user-friendly format.
Full transcript
[Music] hi everyone uh thank you for joining today's session uh we're navigating the storm and it's fala Sidekicks role in the Everlasting uh kubernetes cyber security battle um I'm joined today by my colleague toas uh we are both um from the Falco project um Thomas do you want to introduce yourself sure so my name is Thomas Tom in French I'm Senor developer Advocate at C like Nigel
before that I was s for and also phps for something like almost 10 years now I'm also CNF Ambassador a Falco contributor and the creator of Falco psychic Nigel will introduce to you right now yeah so um yeah toas is the real mind behind this as it shows on screen he's the creator of the the Falco sidekick project that we're going to show today um but yeah
like today we're really talking about runtime security uh and in case you're wondering what we mean by runtime we mean when applications containerized apps when they're running um like actually active on a server um and anything around that you know tools that are used procedures used to secure those running apps that's what mean I run time security straightforward now what is Falco and how does that work
within runtime security so Falco was a donated project to the cloud native Cloud native Computing Foundation or cncf um why does this matter well it it's quite interesting so the cncf are essentially a foundation a charity if you want to put it that way that are responsible for uring um a better you know better progress when it comes to Cloud native Computing and this isn't just down
to security this is down to um all elements of making sure that applications are deployed uh appropriately and certain guard rails are created and that we can scale these applications appropriately and Falco is the runtime detection um component you could say of this uh Cloud native ecosystem so anything from the applications that run on a host securing the host itself but also the connections to the cloud
tenant um and securing the the cluster that runs within the cloud tenant um this is what Falco serves as so it's got over 100 million pull um on for Docker pulls um and Docker Hub and then you've got 6,000 people giving a nice little stare on GitHub so it's a very popular project and the fact that it's recently graduated from the cncf this year means that it
has met all of the stringent checks um that you can imagine from an open source project to prove that it is managed appropriately that it has security audits performed but also that it's um evolving in line with the standards that are expected of the cncf so again graduation is a fantastic seal of approval for the project Falco so you know that when attending the session you're not
hearing about some kind of Fringe open source theoretical novel technology but rather you're talking about something that has met the requirements to run in production in some of the largest cloud environments so with that how are we monitoring all of this runtime activity and Falco is designed for Linux systems so how this works is you um have a kernel probe or an ebbf probe we'll come back
to that in a short while but this collect system calls from the actual Linux k stuff so by collecting system calls like imagine this every time a file is created deleted any time you make any modification on a system a system call is triggered that's associated with that activity and that's really from the lowest level of the system you know the kernel operates below the operating system
so below the user level you have this kernel and that's the brain of the machine so by collecting and interpreting those system calls we can monitor process activity network activity all sorts of activity even down to IO activity so what we're trying to show is that with Falco we have this interconnected use case to look at in real time but also you know across different context what's
going on at the operating system level at orchestration layers like kubernetes which is responsible for deploying these containerized applications but also monitoring the activity within those applications are process themselves so I mentioned briefly a second ago about ebbf how we traditionally did this in falico how other applications would have done similar idea if they were doing introspection of a kernel is they put in a kernel probe
and kernel probes are great right like they do everything you expect you get all that deep visibility problem is it's a piece of arbitrary code and I guess where the industry saw a concern was if you were to introduce these arbitrary piece of code into the kernel what if for instance it didn't perform as expected and something went wrong it panicked and that's a big concern colel
Panic it's not something you see every day but if it happened you could break the system itself so obviously that's undesirable so ebbf came as this it's called extended Berkeley packet filter but it's really quite different from the Berkeley packet filter project which was really just for packet handling in the system kernel um but ebbf can be used for a bunch of different use cases generally speaking
you know security monitoring any kind of diagnos tics because it's able to retrieve data from the kernel but how it's different is it's kind of like a little VM running within the kernel and by running in this secure isolated environment there's no risk to stability or security so again those concepts of like kernel panic and the likes don't really apply when we talk about ebf so it's
You could argue the more secure the better approach um to moving forward with the project um and uses this what we call Core compile once and then run everywhere um which is a cool um concept so here's the architecture on the highest possible level for Falco and so you understand what we're talking about today so we mentioned we're collecting system calls from the Linux kernel so this
is the event collection stage and that can either be done through the kernel module or through the ebbf probe again that's up to the end user and there's going to be different cases for each like if you're on an older Linux system prior to the introduction of ebbf then of course you're going to have to use the kernel module but in certain distributions of Linux let's say
or kubernetes they might be clamping down on you introducing kernel modules and because they're on a later version let's say um bottle rocket or one of these optimized Amis that you can use in the cloud a specific distribution in the cloud of KU a of Linux you might actually have to use ebbf in that scenario so we're granting the user the flexibility depending on their system uh
build how you're going to collect that event data then once we've collected the system called data we then match it against a rule set so these rules again Falco's open source so the same logic it then extends down to the rule set we give you full flexibility to then Define these rules is how you're going to match that event traffic like if we were to handle all
system events it's just far too much data it's we're not a Sim you know we're not handling all events and then just trying to build some kind of complex data Lake instead we're trying to say build a complex rule structure so let's say I want to look at um outbound connections to a C2 server so I would defile devise a rule in the rule I would have
um a list which is another abstraction and that would be my list of IP addresses then in my rule I'd have some kind of macro and this can be my Boolean logic right and or logic statements and I would say something like Define what is the context of an outbound connection you know like it has to be an event connection from the system kernel but might have
to have some other context to it like is it an outbound connection from a container that wouldn't talk to a CG Server Like that's unusual so you define the context within the macro you've listed all your list of ips that are considered like C2 botnet IPS and you put that in your list and then the Falco rule is just this really clean yaml manifest that says what
I want to detect on we mention that in the conditions so so that's your list in your macro and then we're going to have some output which is just the extracted metadata context from the event and that's giving us that rich visibility as to well what actually happened so we can see the out Bend IP from a source IP we could see for instance what was the
connection type what was the user running that we'll come to all this in a short while but that is the logic behind rules and FAL is very much a rules engine out of the box without Falco sidekick you can stream out certain alert outputs so you can send it to a CIS log if you want to send it to the Sim or you can output this to
a file if you just want kind of CSV output or something of your events um you can do STD out you know there's a bunch of these different methods where you can send them to an external endpoint like HTTP if it's going to be like a web hook to some other tool so you want to get like automation alerting or something like that in your pager Judy
or something like that so these are out of the box options but they're Limited in their scope and that's where Falco sidekick comes into today so before I talk about sidekick I do want to give some more context around the kind of the evolution of the project Falco so we talked about system calls and they are pretty amazing like we're handling full system visibility so we can
look at process activity container activity the host operating system activity but by creating these kind of arbitrary grpc plugins like again open source project anyone can build their own plugins but this is a way to like authenticate from a third party data source and then stream those events to Falco where we can apply the same rules logic again so we can handle stream of events from okay
without authentication I mean you could do this on the same server kubernetes audit log so kubernetes as an orchestration tool has its own audit logging service and these are called kubernetes audit logs so by handling those and streaming them through plugin into Falco you can now correlate the context of the system calls with the KU audit log so rather than just saying I saw um an unusual
connection to a C2 server now I can see an unusual connection to a C2 server but rather than seeing it from a process ID I know it's coming from a container a pod name uh within a network name space in kubernetes within It's associated deployment object within kubernetes so you can enrich the context and really have deeper visibility than you would have in kind of traditional EDR
Solutions an alternative approach here at plugins is by streaming context from say for instance AWS cloud trail from your cloud provider you could say I have a container but it's running in the cloud and yes you know I can monitor the container in the cloud from the kernel events but correlating that against the context of the cloud provider you get deeper context about okay well I have
a very complex Cloud tenant can I troubleshoot this quicker and by having the output with the additional context from the cloud provider super powerful or just simply alerting on insecure behavior on the cloud provider alt together and again you can do that via cloud trail so having this plugin architecture means we continuously handle different sources from new complex different parts of your stack and then we can
build build detection around it so it's really at this point Cloud native detection and response or at this point we're just talking detection so moving on you so far I've talk rules and you're probably thinking what is a rule so this is an example of the simplest rule I could possibly show on screen so at the moment you've got a rule name and that's just an arbitrary
string and it's just saying terminal sh the container the description is that additional context it's it's describing what is being said in the rule so in this case we know it's a shell that's been spawned and it's specific to a container now that doesn't do anything in itself that's just something we'll see if it's triggered the conditions is really the PowerHouse here so I mentioned earlier about
defining macros and lists like a macro could be how do we Define what are spawn processes and like how do we know what is a container you know and we also want to know what are those shell processes they might be different shell process that are defined so you create the macros they handle all the complexity and then by just saying I need a spawn process and
its container and it's a shell process that is a consistent string like a ni string but a consistent statement that you don't need to modify often or ever because the context that needs to be modified if we're trying to update this over time is within those macros so the rule stays consistent it's not this complex logic that you see in a single rule that would be hard
to modify or hard to manage um the output then is really where Falco differs from other Solutions because we're handling the system calls well we want to extract the metadata from those system call events so we can say for instance a shell was spawn in container that's just the string in the brackets then within those parentheses we're defining what are the fields that we've extracted from the
system call and we can extract for instance uh the user in this case was it root or other um what was the login user ID I could look at things like the shell process name I can see parent child process relationships um was the explicit command that was executed container ID and so on like I mean realistically if there's a system call being triggered in the kernel
and it's relevant to the event we we can uh plug in that context into the output and then really we just have all this additional context so for troubleshooting it's better than just saying we know there's a terminal sh container but I want all the surrounding context as well and you can put that in within your output so again it's really important for operational response priorities are
again I I've said arbitrary a few times but you can Define the priority yourself like that's not a fixed thing but like for in terminal shell and container there might be a legitimate scenario why an employee is doing a terminal shell container but saying that it's not guaranteed to be a an actual known threat it's just an insecure Behavior so you might have priority warning because you're
trying to let the admins or SRE know okay someone's terminal sh container that's unusual but it's not absolutely a threat versus someone running a crypto Miner in a pod is totally utterly has to be bad behavior as per company guidelines tags again arbitrary you define your own tags what you want to have in here and these are really the supporting context these can be used for filtering
we'll talk about all this later but if you're trying to align with certain for instance like miter attack framework from a threat detection response perspective or with reg regulatory Frameworks so things like um Hippa PCI DSS that kind of stuff you can define those tags with those IDs and it just means that when you going FAL psychic later we have a nice report of what are the
detections in line with what is our framework so we can actually maintain compliance and that's really powerful as well so I talked about these rules you might be wondering okay it's I'm not used to writing in yaml or I don't know how to use this override context that you're mentioning here on the right side view it's all very scary in the beginning well it's not you know
in a way because we provide again this number changes all the time time but we provide like 880 plus system rules out of the box and for all those other plugins whether it be kubernetes audit um AWS cloud trail whatever the source is we generally speaking have a um a list of supported not supported but you know stable rules associated with that so things like privilege escalation
data exfiltration um you know it could be anything to do with um executing shell into a container we have rules for those activities so the idea is once you install Falco and you start running some insecure Behavior probably we detect it out of the box but we give you the flexibility to then Define your own rules that um monitor Behavior that's unique to your own environment so
you might say for instance uh these pods should only talk to these pods over these IPS and if we see TCP connections on ports that are not mentioned in that you know allow list then we see that as inse secure Behavior but that's of course going to be unique to your organization so here's what the output will look like um so we mentioned there about the shell
into container so it was this one the description is the first thing you see so it's a shell that's been spawn in the container and we mentioned we just injected a bunch of these um different fields into the output so here we see a shell Bond the it says notice but it should actually be warning as per the party here but either way once you have that
you'll see the priority the name oh yeah this actually a slightly different one this with an attached terminal on it then it will show you here are the fields see the way they're colored in blue they're the injected context that was extracted from the metadata of the sorry the system call and again if you have this correlated against kubernetes context then you can say not just that
I see that there was a terminal behavior on a container ID which is um like an algorithmically generated ID and that's subject to change regularly instead then you also have the um the kubernetes metadata context to say well I know it's in the names space default I know it's from this container name cncf and that way even though container IDs tend to change that metadata from kubernetes
those abstractions though they don't tend to change so at least we know where this unsecure behavior is happening and I know how I can better get to the solution of the problem so that's really cool and that's what you'll see but again we'll show where limitations occur when you just have a stream of all this output data so that's where Falco pyic comes into place Falco psychic's
one of the late I mean it's been there for a few years now but this was a project that was added on later and as you can see from the bottom left corner um it was introduced into the Falco security project on geub so it's another open source project but it's an extension of the capabilities of Falco and from here what you can do is you connect
your ecosystem with with 65 possible Integrations and Counting you can use it for alerting storage streaming you know chat notification tools whatever it is there's a dedicated if it's functions as service if it's kind of you know infrastructure as service this kind of stuff that you can say based on an alert we've detected an unusual thing in the cloud then connect to the FAS service and then
take action automatically remediate that threat and this is again a very cool um addition to the project now for today's session we probably don't have enough time to go through through um response capabilities in Falco pidi we do have a session in two days time in villus which we can go into further with the Talon response engine but today we're going to focus on the UI element
so again as you you probably would have guessed all the events are streamed through Falco sidekick and Falco sidekick now is responsible for how it's going to push those events to those uh third party end points or again if it's something like um Prometheus you can actually pull metrics from Falco sidekick and then enrich that dashboard with all the additional context that is coming from Falon so
Falco Sidekick is installed on the side of Falco then it handles all the responsibility of how we're going to get events to a third party endpoint now I'm going to focus on Psychic UI as you again this is a separate module within the Falco security project so you can use Falco sidekick UI as kind of a standalone thing with Falco and you don't need to actually have
to do all this other automation stuff if you don't want to but Falco pyic UI obviously came after a bit of community need demand if you want to put it that way that it's great that Falco has such deep visibility but I I love to see this in a graphical user interface I don't want to see it via terminal I don't want to worry about sending it
to third party endpoints I just need something quick that I can just you know go port forward access on local host on a specific port number and from there I have all this beautiful graphic UI to show me all the context so rather than spending too much time on this part um we're going to quickly go into a demo I think this is what's probably everyone's going
to benefit from so now you see the full view of Falco Falco side kick and the UI whereby you have um all the event sources whether be system calls or plugins going through Falco which has the rule engine that decides what to do with the event it alerts through HTTP endpoint the web hook which then goes to Falco psychic which then takes the action on how it's
going to do to these notifications unlike writing these kind of arbitrary web hooks yourself and maintaining that Falco pyic was supposed to abstract away that responsibility so then it chooses okay if it's going to send it for automation through those notification engines like slack or elastic search whatever or you can just use it for the website uh psychic UI um which we will show in this Tona
in a second so with that we're into to the demo time um I want to make sure that everyone can see this effectively and I think it can um so that's good so I have a simple kubernetes cluster and it's basically just running on one single node and if I said cctl get nodes wide you can see the type of node it is so it's it's it
is a Linux system it's an Amazon Linux 2 operating system is what I'm using and I have a specific kernel version and all this is great you know so this is the environment in which we're doing the testing so it is kubernetes but my node is running in AWS so that's all you needed to know and I've installed Falco sidekick and you can see that they're all
running as pods within my cluster so let's do some testing so first thing I want to do is prove that we have the connection so look we we have a port forward it's really small but it's because it's not a prior here so I'm just saying Cube CTL port forward the service of the FAL II UI on Port 282 and again this the rest is not important
for this demonstration so once I've done the port forward you can go to the Falco psychic UI and right now I have no events there's nothing worth reporting on it's just a pretty UI it tells me the info output about you know I'm using RIT back end and I have no password worth talking about set up on this this is purely for demonstration and it's listening on
Local Host so to show the value of it I have two tabs here so one that's going to show me running an insecure Behavior and the other tab here should show the the output of the Falco logs that are being handled in real time just to prove it works in real time so I'll start by um applying a file um yeah so I'm just going to introduce
a workload a simple workload at that and this workload it probably shouldn't create um a falor rule I know or maybe it did yes it did so you see there's a few things going on here I have um privileged container was started so I created this workload with um you know it was as it was defined as a privilege workload it had privilege set to true so
it had that higher level privileges on it um to prove that I could actually just grab this yaml manifest um I could W get this file for instance and I could cat the file which is dodgy sorry um if I open here dodgy you can see that I had this security context that privilege set to true so when I did that you know we know it was
a privilege workload and in instantly in real time we saw a privilege workload was created and yeah and then the privilege container had started so already you can see we got all that deep context but this is kind of hard to read what would be more desirable is if I went in into this UI and I refresh my page and I go to the events View and
you can see for instance launch privilege container here's the tagging context the the description is easy to read and you can see all the different fields are extracted in it and an easy to interpret way and this is also useful in many other ways so for instance I quickly know that the source data for this alert is coming from system calls it's not coming from kubernetes audit
log or some other log logging service we know the source event we know for instance if I had a complex system of many different endpoints knowing which host name that this is coming from is probably one of the quickest things you want to do because you want to be able to for instance filter based on host name or based on other context but as I mentioned earlier
I'm running this cluster as as just a single node server so it was just one node and this is the endpoint here that we're running all the tests on so already we've Port forwarded we can see we can easily access the faly UI and rather than looking as an event stream which can be complex we have it in the faly UI as you know a pretty D
to view um output so now let's look at more complex scenario so we created that um workload what I'd probably want to do for instance is a terminal shell into the Container now we mentioned earlier that that's not a critical Behavior it's just you know it's not not something you should be doing all the time you should avoid making changes I mean for troubleshooting you can you
can trouble terminal sh container and check for logs within a container or make some kind of modification if needed for troubleshooting but generally speaking with kubernetes at least you're supposed to interact with the abstractions and kind of shift left where possible and not be making changes within runtime so this is kind of insecure Behavior we're doing here so I terminal Chan container and straight away we get
a new alert and it's telling us a shell with sponding container with the the attached terminal again that same output I should see um here I guess I refreshed oh it's because I refresh every 10 seconds so you can see the terminal sh in container now already the more alerts that we trigger that we show inside this UI the more valuable this is becoming because you'll notice
that these are out of the box rules like I didn't even configure anything here and because they already have this context to tell me it's miter it's related to miter tactic T1 610 without me even knowing how concerning this is when I go into my dashboard view I get a better picture of for instance how many of my rules align with specific miter attack tactics and techniques
but also where do those apply within the miter attack Matrix like for instance these activities so far whether it be terminal sh container or launching the privilege container um these are executions so you know so far we're only talking about Minor execution but if a tid came up later and it was related to exfiltration um Data Destruction these are you know not just for compliance sake these
are really important for taking action because someone is you know stealing sensitive data from our organization or um or potentially destroying sensitive data within our organization so we'll jump quickly back into um here and I'm already in that container like I say if I do LS I can see I'm running as root and I have all this um you know I can see all the the file
system of that container if I destroy it it's not the end of the world it's just a a test container that I'm running with root permissions so with that I could download say for instance a minor package I'm doing this just as a useful case of showing the value of our rules engine and the meditate output so if I unzip the package that I just downloaded with
curl and I CD into that file directory say for instance our rules are kind of written to be to handle specific activities so if I want to do something as broad as just connecting to a um um let's say a mining pool so like for instance I have the fully qualified domain and Port so if I hit enter on that I'm running a crypt Miner obviously at
this point it's no point talking about the output here in um in the output of the logs because it's so hard to read because it's so big and the more events coming through it would just become unmanageable so instead I go to the events View and I can see we they got a detection for an app and connection to a minor pool and Port but as I
mentioned earlier we need the context quickly to take action so you can see here that we can see the full command that I executed there which was you know XM rig was the the the binary I executed we know for instance this was the fully qualified main Port but also because in the uh output Fields I asked for specifically I wanted to know what were the IPS
they're connecting to or the range of ips and I also want to know what was the actual IP I connected on and what was the port so you can see FD R and FDR Port so this extracting this context is so so valuable so rather than just focusing on a command was executed I know that they connected to malicious ports and pools you know for a mining
uh pool because again we have a a list of these IPS fully qualified domains and ports and there's a rule already configured for this out of the box but also it's extracting the point that we know what was the context because for instance if you connected to a minor P Port but you don't have root permissions on the exm rig then the you're going to get nothing
out of it you know in the same way I don't know we can check for instance if those IP ranges are fully qualified Mains are actually in our block list on our firewall so or network policy in kubernetes so this is really powerful so far but let's say they go further they want to connect not directly to the IP or whatever but they want to use like
specific protocols that are known for um crypto mining activity so instead I could go in here quit this uh example sorry I'm going to quit here and I want to I'm going to close this tab and just keep this one open and I'm going to move that down a little bit but if I was to use stratom TCP protocol this is a protocol specific to crypto mining
activity and as if I refresh the URL here you can see yes it's detecting to a minor Pool Port activity but also we're detecting activity to using the Strand protocol so this is Again by having rules in depth and being able to corate context like these are critical events you know if someone's running a crypto mining binary inside your environment then they're naturally trying to abuse your
resources for financial gain there at no point is this it's a bit of a warning it's it's absolutely the thing that's most concerning so you may want to use Falco sidekick for for instance doing automation based on tagging to alert better to do automation based on the criticality of these priorities that are coming through we don't want to for instance do automation based on observational activity like
for instance when containers are launched for privileged access because we probably have a bunch of pods for whatever use case or testing that will use privileges I mean we talk about reducing the attack Surface by limiting permissions on workloads but again this is just an observation it's only when they abuse those Privileges and start running crypto miners are we really concerned at this point so that's one
of the really good use cases there um the Pod was actually killed and that might have been ju a response engine so we'll come back to that in a second but if I was to exec back into the Pod it should be a clean POD at this point uh oh the pod's gone that's okay so what I'll do is I'll introduce it one last time into our
into environment and you can see it's now created a brand new pod and if I exec into that pod and what I want to do is we talked about a while ago when we had our packages for the mining binary at this point I'm going to just for the sake of it download it um unzip it and I don't think I even need to unzip it at
this point but we'll unzip it and then I'm going to exit the Pod when I use this um CP command what I'm trying to do is basically say in my pod you know the way I called this um dodgy pod well basically I want to say use the cube CTL client so yeah we have in kubernetes it has its own CLI tool called cctl so I'm going
to use cctl to copy a file from a container called doipod it's got this tar.gz so the unzip package and I'm going to move it to my local desktop toop and it's going to have the same file name it's just going to be running on my local desktop so when I copy which should just take a second I guess cool when I go back here and we
refresh the URL we can see for instance xfil trading artifacts via the kubernetes control plane so this is so important in so many ways here so one thing um this rule wasn't even in the stable rule set you know this was coming from um an in incubating maturity rule set so the Falco projects at a maturity level now that it's created the maturity framework for rules so
anything that's stable that we know it's not going to cause any false positives it's not going to have any issues or it doesn't require too much customization will come out of the box and stable then there's rules that are in incubating that may need further work on them to make sure that they can reach that stage of stable and and then there's the other ones that are
kind of sandboxed that may produce certain false positives or just require a heck of a lot of configuration so you couldn't push them out of the box and stable because probably they'll never trigger any detections because they require end user interaction with the list and macros to make it actually work for your environment so the more of these activities we do like at this point I could
for instance just shell into the Container right and just perform random acts so it might be to find AWS credentials whether or not the directory like the way I'm saying path to some file the directory doesn't exist but if I'm trying to grap something that has the name AWS secret access key which is pretty common even these kind of activities if you create a macro to Define
what our access keys or credentials associated with AWS well then you're probably going to you're going to get outputs that tell you for instance okay we're seeing data exfiltration for trying to find aw's credentials on a system and this would be considered a stable Rule and again we know this could either happen on a host or in a container because as long as it has a file
that's got those names associated with AWS then it's going to trigger that rule but tying it back to the miter attack Matrix like no matter what it is if I'm trying to read sensitive files and if the file system doesn't necessarily exist it doesn't have to because the user for instance is going to try to perform these actions they don't know your system inside out but if
they're trying to for instance run cat to read a file from Etsy shadow and you know if it has anything in it and it shows them a bunch of keys or whatever then we should be able to go back here and say look even though the user wasn't successful it doesn't matter the user attempted to re read senstive files from an untrusted directory or something like that
so this is really powerful so we talked about Falco psychic abstracts us away from just looking at the raw output of the logs in the um in the terminal to a point where we can go to this dashboard understand what's the breakout of all of our rules based on sources based on is it coming from AWS audit logs is it coming from the system core kubernetes Auto
log wherever but also across the tagging context and the Richer the tags you apply that are more relevant to the activity then when we look at our rules that are being executed we can really get a better picture of for instance I want to look at all miter execution activity or actually I can just go to events go to tags and look up for instance t105 and
then I can see all activity related to miter attack t105 9 and if I was to look up the miter attack Matrix that would turn out to be related to terminal shell and container so having all that it's just a really powerful um output now I I don't know where we are with time um do we have a few more minutes or are we nearly stuck on
time two minutes okay so I'm going to jump back into the slides um that demo hopefully was useful we didn't talk through the reacting use case here but as I mentioned we have another session in two days time and we're going to talk about Falco Talon as a response action uh engine dedicated to the Falco sidekick project um so of course without Talon there was always the
way to use all these functions as service tools like open FAS or AWS Lambda on on Amazon side to do this kind of automation but the session in two days time is just going to be really invaluable for this so myself and Tomas will be back again and we will talk about the response side of the Falco project and I I really hope you can attend because
I think it's going to be a brilliant session and it's a really new technology and it's constantly evolving um so if there's any minute or time left for Q&A we're more than happy to answer um or if there's any questions outstanding there from you T that you want to ask me we have five minutes now for cers okay cool so yeah um I hope that session was
useful and um yeah like realistically speaking um there's a lot of extended use cases that we didn't have enough time to to uncover today but um hopefully this was an interesting insight into Falco psychic's no questions from now okay I guess if there's no question we close out um yeah um oh yeah no questions coming in um yeah and again if if you want to contact us
directly uh myself and tomama uh we have a right at the beginning we put our details I don't think we put in details but you know we're on LinkedIn we're on slack you know if you're on kubernetes slack already you can contact us there um but also I pretty much just use the same handle for everything so whether it's be on LinkedIn or you end up looking
up that Handler um probably it's going to relate to a bunch of different things that you can contact me on so um yeah thank you for attending today's session and if there's no more questions I'd say we're good to close
