hello everyone i hope you can hear me and see me and we will start in a couple of seconds okay it's 30 minutes already so uh let's start today i would like to talk about the challenges and issues that you can face if you're running security operations in-house and some findings we have observed across all our customers across the globe and some possible ways how it can be solved so the key issue that's a lot of enterprise companies uh highly in investing in cyber security and still facing the cyber breach or incidents on the regular basis according to uk department of science for the last year for the last 12 months uh 69 of high enterprise organizations have faced the breach or incident itself that means um we can and this is a big enterprises so they invest in cyber security a lot they have a lot of technical solutions they have a lot of uh security tools and um most likely every big enterprise uh at least according to my experience they have our security operations uh implemented in one or another way of course it can be mssp but in most cases if we're talking about really big enterprise we're talking about in-house security operation center and it's exactly for area of focus of my team and expertise so uh what we're doing for this so my team is responsible for SOC development projects for any external security operation project in kaspersky uh usually touch our team in one or another way uh we're working with building uh security operation centers from scratch but also we are focusing on uh performing the evaluation and assessment of current operations it could be uh evaluation of current maturity level it can be evaluation of processes procedures but also we are focusing on uh technical evaluation and assessment project and uh performing emulation drills to really understand in the practice what SOC is able to detect what SOC is able to see and how exactly the uh operations uh developed uh i i deliver it by the team in practice uh besides security operations we're also focusing on incident response activities in the same manner so processes and technical areas and for threat intelligence uh it's also area of our expertise that means that uh we're not looking in the security operation center only like a technology so we are understanding it's like one full component uh that should work together so all technologies are needed as just tools they needed to team to perform the necessary activity to detect the threat in timely manner and what is most important to reduce the impact as as much as possible so uh usually we're again we're not able to avoid any attacks which our mission is any security operation center we just have to reduce the possible damage as much as possible and do it as early as possible so based on this um uh idea uh let's focus on some challenges that was um announced uh almost two years ago by osterman research that a lot of SOC are facing challenges in their daily operations so most almost every SOC reports that they have increased backlog and all another and uh amount of failures and incidents they're not able to really handle in timely manner it's also confirmed by our observations so we see a lot of the time that SOC is focusing sometimes only on critical incidents or on some high severity incident and because of the volume of incidents they're ignoring medium and low incidents or alerts as well so that means uh of course it's a good approach if you especially if you have good prioritization if it's meaningful and adapted to infrastructure but uh if you missing some small stuff if you see missing some uh not very important uh alerts in the end you can you can miss the advanced attacker who was just expertise enough to cover the tracks and uh not generate too much noise to be uh noticed by your security team another one another two important metrics that a lot of uh security operation center not able to clear the backlog of ongoing tasks so so it's not only about operations not only about that you're tracking incidents and alerts on daily basis but you also have to develop yourself you have to evolve to be able to detect new threats uh there are always some space for improvement in any security operations and uh that means that you still have a lot of things uh to develop new detection threats some optimization automatization now the last couple of years ai implementation has also became a topic for every security operation center and every this activity is just for leading us to growing backlog of internal activities that has to be done and any SOC every SOC in the wall in this world don't have enough resources to complete everything in desired timeline so uh besides uh these issues of course then uh can be added uh can can be extended with some additional issues like we are facing this every year evolving threats so attack surface is growing again we see a lot of migration of business to the cloud we see a lot of migration to remote work that also is disolving our attack perimeter and the amount number of soft is growing from day to day uh last two years we also can observe the trends that a lot of applications are done in wipe coding um manner that not also introduce the best security that means that some vulnerabilities if uh software wasn't properly developed tested and uh sec devops was not a part of the development process it also can provide us much more new attack vectors um from other side ai is also helping uh attackers to identify the vulnerabilities if you take a look on the recent trends of revealed vulnerabilities you can see the significant growth of from the last two years especially for the last year when ai um started uh to use by attackers to analyze the software code to analyze the vulnerabilities and uh to to use this information in the attacks so now we have more vulnerabilities revealed every month than it was ever before and of course the another issue with this evolving threats and evolving perimeter that we have uh some reduced visibility especially for cloud infrastructure and for containers especially for containers because here we have we can have multiple containers in one environment and it's not always easy for security operation team to understand what is going on where is behavior of the host itself or where is behavior of specific container and application within this container so it's also not providing the easier uh easy life for our security teams and for our security engineers at the same time uh we have as always in cyber security market we have a shortage of skilled talent of skilled talents uh it's not possible to find uh very fast necessary person with required expertise and especially with a required tool stack that is used by uh your company and your infrastructure so of course now we are going to the global market it's becoming a bit more easier but for some specific areas it's still a huge issue to find the proper people in uh necessary time for example i was involved in uh hiring of sock analyst team uh and the full um onboarding of the team is so to find the proper person to evaluate the skills and necessary um knowledge and to the moment when this person is ready to work in your security operation center this uh timeline is usually starting from six months so from initial search started to onboarding process finished and that means that half of the year you don't have enough people in your security operation team to be able to fight the threats and identify the threats and uh in other points that uh we have evolving threats we have a huge bigger landscape of the threats we don't have enough people and at the same time uh in most of the security operations centers we don't have enough processes and defined um procedures uh to mature the security operations that means uh of course we always can have a very talented talented team with some high-level experts uh that don't who don't need the processes but if we're starting to talk about any uh sizing any growing of our business that has to become uh complemented by growth of our cyber security team and security operations we also have to be able to scale our security operations as well and this scaling necessity usually requires the well -defined processes that you can adapt to the growing infrastructure and the processes is still the big point of any security operation center that we can observe so uh the next on the next slides i would like to share some findings that was taken from our project by projects again we have uh so governance assessment when we evaluate the ability of the soft to executed work and overall management process behind the uh the soc daily tasks and development uh we're talking about technical assessments that is including assessment of specific technical tools and even go deeper to exact detection capabilities and detection rules it's also evaluated and even sources that is used by security operation center as well and the last uh type of the project that also has contributed to the following findings it's all types of drills emulations and purple assessments when we work together with the blue team to understand their uh weaknesses in detection capabilities for modern threats so uh the first one the first observation uh let's start with the telemetry and we will stick to classic soc pipeline of processing the information and by the classic pipeline i understand that we receive telemetry we apply some detection engines or any detection technologies to this pipeline and based on these findings we generate automatic alerts that has to be processed by soc team by ai analyst by additional analytics engine and us and only in uh in case if we will detect them some signs of compromise some signs of real security incident on this level only in this case we are rising the incidents that we have to deal with and implement some containment activities and basically performs uh performs a real response response to reduce the impact from the uh incident itself so sorry so for the uh telemetry uh what we can observe and of course obvious uh statements that with every year every soc is observing and has to work with more data than year before so every year we have increasing volume of the logs uh the next one already was mentioned that visibility is sometimes limited due to usage of the cloud because cloud usually have some very specific logs and it's not always possible to extract these logs to you uh on in-house soc sometimes you have to build some hybrid platforms that part of the telemetry will be in the cloud from the providers that's providing you cloud services and some part from internal infrastructure will be handled in the inside of the in-house so and it's not very easy to combine these two approaches with two platforms in one pipeline that all analysts can work uh with smoothly with any type of environment that you have um in your company and uh again a lot of containers are still in used and containers doesn't provide the gray is the best of the visibility the visibility comparing to the classic approach of the operating system when you just imply when you're just using host for this specific business function and not running multiple applications in the one environment with multiple containers again with containers we usually observing the same uh some issues with receiving the proper telemetry and some issues with proper detection what exact behavior is behind this specific container so uh from our from our projects we also have observed very strange no not not very strange there a lot of explanation can be provided but we have observed the trend that most of the data is not used by security operation center so almost every sock has some data that it's not used for detection capabilities sometimes it was done by intent uh it was done intentionally to support analyst with necessary telemetry to support uh for example investigation uh sometime it was done to support threat hunting activities but in most of the cases uh for not mature sock uh we see that data is only collected but it's never used for detection capabilities so basically just a useless information that is stored in uh cm database or xdr database or any platform you're using and in best case it can be stored it's storing it's stored for compliance purposes but again in reality we have uh phase that in most cases with data just ingested and never used and uh the interesting case that the more data sources you have uh the less detection coverage uh you have in your security operation center of course this trend quite obvious that because the more data you have the more different types you have it's a bit more difficult to cover everything with detection capabilities but the idea behind why do you need to collect this data why do you need to affect performance of your technical platform why do you need to uh to make life of you data engineers more difficult if you're not using this data so here in the telemetry we observe this trend very clear of course there are some other trends but they are not very significant like the quality of the data that you're receiving if you're using any normalization data to the unified schema if it's used by your platform it's also part of the assessment and part of the healthy sock pipeline but in this case just you can focus on reviewing of your data to understand why do you need with data don't store unnecessary information it will provide performance impact on your technical solutions it will make the life of your sock analyst more difficult and what is more important for sock analyst it will slow down the your capabilities to search and investigate for necessary events so basically every uh unnecessary chunk of information in your data platform will slow down your overall activity and security operations the next step of this pipeline is detection so after we have received all telemetry we have to apply some detection mechanics um uh to this telemetry to be able to identify sign of the threats sign of the attacks the attacks and here we see again some some maybe pretty obvious uh trends but um sorry so here we can see that it's not an option anymore that you are using just default content from the vendor a lot of uh cm and xdr solutions they are providing some uh default let's say default content with a set of rules that are able to detect the attacks but the idea behind these uh packages and rule um collections that you first of all you have to adapt them to your infrastructure because without adaptation it will be just over overwhelming flow of the alerts that will be generated and analysts uh will not know which alert they should uh take first uh so again cm and xdr platforms it's not like the endpoint protections they have a wide uh set of capabilities but these capabilities has to be used wisely so you always have to adapt this content uh to your infrastructure to reduce the false positive phrase to make these rules work uh one of our team is also developing the content from our cm solution and uh we we can say directly that 70 of the content requires some actions sometimes very easy actions from your site just to fill the specific list just to specify which servers are performing dns function in new environment which accounts are important which accounts are used for domain operations but you still need to perform some specific actions to adapt the content to your infrastructure otherwise it will it will not provide you value that we intended to provide with our development and uh continue continuation of this idea that it's not enough that you're using and rely only on contents that provided by security vendors you have to the uh to deploy and develop detection engineering discipline within your security operation center so it's became uh become mandatory activity right now because every day we have again we have evolving threat landscape we have new threats and uh you have to keep an eye on these threats you have to keep an eye uh on attacks and uh trends that is going in your sector in your uh in in in your company in your region uh to understand what is uh using in the wild for attacks for breaches uh in your neighbors and your competitors so you have to be ready for these attacks because it's very high chance especially for the new attack types for the new vulnerabilities and techniques that you can uh became the next target uh for for such uh attack techniques and again going back to vulnerabilities again that a trend that uh the gap between vulnerability was revealed and usage of this vulnerability in attacks uh in the world it's close it's uh going down with every month uh right now so this is uh sooner we will see that very short gaps that uh between vulnerability released and new attack types that will be used for uh successful breaches so that means that we have to establish detection engineering process and we not only have to develop rules we have to verify all our rules not only the new developed but we have to implement validation practice for any security operations we have usually a big infrastructure that's covering a lot of different uh uh apparently system types it is sometimes it covered multiple sub companies and you cannot be sure that without proper validation practices that every you've seen across your infrastructure across protected infrastructure is working smoothly as expected so sometimes audit policies can be changed by administrators by mistakes sometimes it can be changed by specific software and then you will lose visibility for some specific sectors uh maybe it will not be a losing of full visibility but maybe some specific event types that were important for your detection content so that means you have to verify on regular basis that your rules is still working uh and usually the best way how to do it is generate some specific activity that imitates the behavior so any type of breach attack simulation solutions any type of manual execution will work here but of course the automatization here will save you a lot of the time but just the general idea test the full chain of the receiving events not don't send only synthetic events to the SOC to do to check the truth is still working check the full chain that audit event is generated according to your audit policy that this audit event is sent to uh collector from your security operations team and the collector processing everything is correctly and it's reaching the detection engine and detection engine is generating necessary alert or notification or whatever you are using for your detection pipeline so that means again validation it becomes vital especially in the big infrastructure for big enterprises because you're not always can be sure that everything is still working smoothly after one two or three years that you have when you have implemented everything so um the next uh of course the next idea the behind the detection that everything is evolving over the time attackers started to use ai so that means for us that more new attack types we have to trigger uh we have to check and uh we have to develop more new detection capabilities rules especially tied with our infrastructure and again uh forgot to mention that uh if we're talking about some contents that provided by security vendors uh they are usually focusing on uh very um common data sources that can be reached that can be met across multiple customers as soon as you develop in your own applications as soon as you develop and you have some specific business solutions here you have to develop and identify attack vectors by yourself you have to cover everything with your detection logic so here it's where you have to rely fully on your detection engineering team so again it's becoming a mandatory practice right now and it's vital for any modern security operations so uh the next uh step uh it's not uh not only detection engineering that you have to implement you also have to connect with detection engineering discipline with other advanced practices for the SOC especially we're talking about the threat intelligence and threat hunting activities so let's start with threat hunting it's not always possible to detect everything in real time some activities can be silent some activities require a bit more attention that you have to hunt for them and analyze the results that means in some cases it requires um some decision making from the people to understand is if this data is uh has a sign of hostile activity or not another topic for threat hunting usually if we're talking about it it's uh reverse detection or historical detection when we received in very basic scenario we have received new indicator of compromise we have to scan back our telemetry collection if this indicator was met uh very simple and basic activity for threat hunting but it still has to be done of course in most cases and with modern solutions that can be done automatically but it's the doesn't it still has to be performed on a regular basis uh the more interesting approach to uh use threat hunting activities when you got information about some new threats and before implement the new detection rule you have to hunt for this activity with an idea of maybe you already will compromised or at least how this is specific query how we specific hunt will provide results in your environment so that's another topic where threat hunting can help you so any new idea any new attack types um try to search and try to hunt for it in your historical logs and if you will see some meaningful results that you can automate and convert to real-time rule yeah in this case it's a great idea to connect everything to connect threat hunting activity with detection engineering and of course the threat intelligence uh it's uh disciplines that is contributing to both detection engineering and threat hunting with new ideas with information about what is uh really used in attacks right now what are modern attack trends and where we have to focus our detection engineering team and where we have to focus our threat hunting team uh in in case if they are looking for new attack types and new attack techniques in our environment so cti is usually has to work as a contributor of new ideas for both with disciplines and uh in the end we will convert uh some information some ti data to threat hunting uh hypothesis and some information we will be able to convert directly to uh detects that can be implemented in real time but in most case it's also good uh if you go through the full process with threat hunt first and based on results you was able to see in your infrastructure and of course based considering the normal behavior of your infrastructure considering the false positives uh you will observe you can develop the better rule for detection to be placed in real-time engine so uh the next uh the next idea of cross usage of multiple processes that we're using uh our cti in uh our daily operations so when you're triage on any alert when you try to understand if uh this information this uh alert contains indicator of incident you can extend the context of the alert of the incident with cti data you have uh combined information about malware which apt is using this malware related techniques tools that you have to look for everything will be helpful as a content and as a context uh for extending the scope of investigation for our security analyst as well so the next step we can modify a bit the agent process and we can implement a layer here to identify obvious false positive results uh through the verification with this intelligence uh layout uh here it's uh demonstrating usually good results uh in kaspersky in our mdr services we're also using this layer to uh to get rid of uh unnecessary events before they reach the analyst uh and uh that is usually the modern trend uh for any security operation center just one small note here uh don't leave it unattended sometimes double check and cross verify the results of your ai layer is uh providing and for example you can check 10 or 5 percent of the alerts that were dropped by a layer by your human team by your sock analyst just to be sure that everything is working that model are not hallucinating that model is still working as x as expected so after this uh step usually alerts is coming to a real team of uh security experts and we can say it can be tier one or it can be some mixed approach depending on the sock schema you're using but anyway uh so people have to verify some some reports portion of incidents and here what is uh also important you don't leave your false positives unattended so if you were able to identify the false positive with your l1 make sure that you have a process well established process that can help you to reduce this false false positive in the future so always uh pass information is very about false positives to detection engineering team that they can aggregate research and improve your detection capabilities in the future to uh make it better to prevent this situation to happen again so um the next uh findings i would like to highlight on the pipeline of sock uh of the sock data uh that uh in some sock we have seen that uh criticality of incidents is not defined well so there are two or there are usually two bad situations that we can observe in case if we found any issues uh the first one there are no criticality at all used in the sock or criticality is um is getting from sources that are not controlled or not reviewed for example if you're using cm rules or you're using some rules you're taking from public sources maybe you're adapting some sigma rules you're just taking the severity from this rule and you are not adapting this severity to your infrastructure you're not adapting to your threat model uh you're not uh that it's uh that adapting it to your impossible attack vectors but that is that are important uh for you also we have observed that uh the severity is never changed by analyst even through the triage process uh they got some severity and a person can understand if it's a real critical activity or it can be changed so we also have seen that in socks there were no processes to uh reevaluate activity and that means that incident that will be raised from the same alert uh in the end i will get the same severity level and the full prioritization of the next steps of the pipeline for a tier 2 and a tier 3 analysis uh will be broken because of this incorrect prioritization in the very beginning and also that i guess it's not the consequences but it's the main reason of incorrect criticality for incidents and alerts that no context is used in security operation center so if you are building a house so you can easily define okay not easily but you can define the which business systems are critical for you which are not and this information has to be used by the sock to prioritize to prioritize the activity so you have to consider the business function you have to consider the criticality of your business systems within the security operation center to properly evaluate the threat another issue we have observed that security operation center are not security operations are not evaluated so there are no metrics implemented or very basic metrics like mean time to detect or mean time to contain are implemented and nothing more so the false positive rate of the rules are not working you are not measuring the efficiency of detection capabilities you don't understand uh which exact source is providing the more value for you which points you have to invest more for reaching better efficiency for reaching better understanding of the data you have in place so for everything of this you have to implement some metrics you have to implement reporting mechanics and you have to keep an eye on this and analyze this data on regular basis so efficiency understanding for security operations and critical is very critical and security operations can be measured there are a lot of points a lot of timelines that has to be analyzed and also a lot of other additional quality and quantity metrics that you have to implement in your security operation center to understand if you have any issues and to be able to fix these issues another topic related to uh these procedures that again this triage we have triage we have the same issues like for incident prioritization it's uh very hard to uh understand which uh alerts has to be taken and work in the first place uh usually you have to make more much more alerts than your team can process and um if you try to implement uh kpi and slas for this one to manage this team you also have to do it in smart way because in a lot of cases we can see just abuse of um sla procedures uh when l1 analyst just uh escalating the alert uh only by reason because i don't have enough time to process with alert in within the time within the sla and kpi that was defined by soc manager for me so uh again this trash uh you have to first of all reduce the volume of the alerts that are coming to analysts you can split some approaches from the uh correlation rule to detect with the direct connection to the alert to some additional aggregation functions when you generate alerts only for critical rules focus that's clearly demonstrated that you under attack and the rest you can process during the threat hunting activities or maybe by aggregating too many alerts from one host for one from one entity from one user another way how to fix it of course it's your detection engineering discipline when you can adjust on when you're adjusting all the rules on continuous base to reduce the false positive step-by-step procedures every type of checklist is also helping analysts to do work better and faster because even if you have alert fatigue fatigue fatigue you don't pay too much attention to the every with every next alert you will pay less and less attention to the details so usually well defined step-by-step procedures well defined checklist for analysts will help you to do it in a faster and more reliable way enrichment is also key to success for any alert processing the more information you have in place in the first glance the better the better this information is presented to security analyst the better results you will get in the end so always try to provide more information more reliable information and more action information in the formats that can be easy easy and fast understandable by security analyst so and again if you're if you're talking about any procedures we have to implement the clear escalation criteria we have to implement the clear procedures how alert can should be processed how it should be handled how it should be escalated and based on these well-defined procedures you have to implement quality control approach you have to evaluate metrics you have to measure the overall pipeline and results of your security operations considering all common metrics but also focus on the quality of the overall the overall detects you have in SOC how many false positive you have what rules are more important what sources are more important so you better can understand where you can where you have weaknesses and where you have strong points to develop the future so uh let's take let's go back to the overall uh pipeline of the SOC and let's take a one case that is usually an issue for everyone nowadays it's subline chain contractor sub organization so any entities that has uh to have access to your infrastructure but you're not really able to uh control this entity and you're not really able to uh interact with this entity uh within your security operation center so here in this case we can observe fail on every step starting with the telemetry that such entities are not providing any meaningful telemetry for us from internal perimeter uh so here we can compensate uh this uh more precise monitoring of our interaction and telemetry from the border and perimeter uh with this uh with this uh with more precise monitoring of our interaction and telemetry from the border and perimeter with this entity. So here is basically only our solution because again, in most cases it's not possible to generate necessary telemetry to process from this uncontrolled environment. So on the very next step, we have to implement some detection capabilities. And again, if we don't have enough telemetry, we have a limited capacity and capability to implement detection use cases for this exact case. This can be compensated maybe in some specific use cases that we are monitoring the activities of these entities, but we have to clearly understand which accounts belong to this organization, which systems they allow to work with, and what is the usually profile and baseline for working on daily basis with our organization. So based on this, we can develop some specific use cases like third party monitoring use case bundle. So this alert, more or less, everything is fine. Besides, we don't have information about context. We don't have information from inside of the perimeter of this entity. So we have very reduced context of analyzing. And when we can observe signs of the incident, so we raise the incident and process it. In this case, usually what we can observe in security operation center, they not able to receive any meaningful feedback from this uncontrolled environment. So was it a real incident? What containment steps was taken by their team? And what was the result in original region of these behaviors that we have observed in our environment that was triggered from uncontrolled perimeter? So that's usually very common and quite often issues that can be made for any organizations that have to work with us, but we don't have the full control. So how we can solve this? Obviously, we can implement some compliance for cybersecurity compliance on board into the SOC. So in any cybersecurity standard and any cybersecurity framework, you have a specific section within how to control, how to manage the cybersecurity. If you have any subcontractors, if you have any site organizations that has to work with your environment. In security operations, it's the same. You have to perform some specific measurements. They have to comply with your security operations policies. They have to provide logs. They have to follow some specific rules of the behavior. They have to be involved in your incident management and monitoring process. So at least they have to, you have, you need the contact to be in contact with the team. You have to receive feedback from this team in case if any incident or alert is related to their infrastructure. The second way I already have mentioned, you have to develop some specific detection engineering bundle for, especially for any third party to work to, that SOC will be able to look at them more precisely. And in worst case, if nothing was working and the incident is really happened, you have to agree before any contractor will be onboarded some emergency isolation triggers. So basically the event that will give you a right to cut the network, to cut the infrastructure and all the accesses from your environment to prevent the spread of the incident, to prevent the threat to be going to your environment. So the attacker will damage your environment. So usually it's a free ways that you can improve your security operations if we're talking about any site entities. So the next step, the next, what we'd like to discuss today, it's a response. So for security operations, for security operation centers, usually we have an issue with response that SOC does not have enough rights to response. So, so, but we observe the same behavior in normal enterprise that's response can be done only by IT department and SOC does not have any rights. SOC is, so, so can only see how attack is developing within the infrastructure and not able to prevent this in real time is a meaningful timeline. So, best case, best solution, you have EDR agents and they're spread across the environment that you can isolate necessary hosts that you can isolate specific processes or log the user accounts that you found compromised. So, and again, supply chain is a headache again, again, again, again, again, again, again, again, again, again, supply chain is a headache, again, like it was discussed in the case before. And automation and AI is still not very trusted if we're talking about response. So here any security operation center has the same issue. We don't have enough capacity, technology or authority to perform very fast response that's necessary in critical cases. So, what else can we, how we can solve this issue with a response? The first one, let's, I can advise that we can go step by step with very small steps that we implement the very limited authority for response. So we are starting with a very limited set of actions. For example, we are able to log account if it's not critical business user, or we can isolate the host if it's not belong to critical system. So this, this small authority to response, you can start your journey, you can automate it, you can track every possible issue within your organization. And this, this pre agreed response, you can mitigate some threats already. And day to day, day by day, you can develop your SOC and you can increase the number of such scenarios that you can do from by your security operations. So usually it's working better in in-house SOC, but also can be applied for MSSP and for contract, subcontractors as well. So in-house SOC is just more easier that you, is every day, you can get more trust from them as a department from IT and business department and can increase your authority for, to perform the necessary response steps. So the next class of issues that we can observe in security operation center, it's technology issue, but here, yeah, it's still nothing new. Infrastructure is growing. So we're observing multiple platforms that are using in a SOC without proper integration with each other. And SOAR, unfortunately, is still a challenge to implement. It's a great class of the solutions. You, it can help you to automate the workflow to automate a lot of activities for enriching your SOC pipeline. And even for, and also you can use it for response automation, but as a SOAR project itself, sometimes it's very difficult and very complicated and requires the dedicated team of engineers, of cyber security engineers who will be in charge of integration and overall quality control for this solution. So technical integrations with multiple system is still a challenge, especially if we are talking about the fast response. Usually here we have to rely on some well-known solutions again, like EDR. Too much customization for modern SOC. It's also introduced additional issues to maintain the technology stack of the SOC. If we have seen a lot of open security patient sensors based on open source. And we, this open source is so, has so high level of customization that this SOC is basically not able to collect ideas from another organization, from another security teams, because they have focused on their stack of technologies. Of course, it can work perfectly, but they are not able to share the findings, the technologies. And for example, to share their detection capabilities as well, and exchange with the peer organization. And the last observation, we still have a lot of organization, a lot of security operation center without plan B. So without continuity plan for your security operations. We can see the BCP for business part, but not for security. If your security, if your security fail, if your technology has a failure, of course, that's, uh, uh, prevents your, uh, to, to be able to detect the attacks. And that means also that security operation will be stopped. I can see some strangers with my camera. It's turn it off and turn it on. Uh, okay. And the last, um, observations that is coming from SOC CMM report from this year. Uh, that's we can observe that automation besides, uh, that SOAR is still a challenge, that the technology of automation are not very trustful. It's growing year to year. And in this year we can observe that, um, automation probably will be the answer for any, uh, for any challenges, uh, that we will face, um, in, in the future. And here I just would like to highlight the most significant growth in automation topic we can observe this year in response automation. That means that, uh, this issue that I have highlighted also was observed by all the players and they invested more and more in automation of the response to be able to react more faster and reduce the impact of the incident as well. So instead of the summary, let's just highlight again, what are critical highlights from any modern security operation center. That visibility is a key for, uh, your proper security operation center. You have, uh, to have, uh, detection engineering, not just ad hoc, but build a reliable, uh, continuous discipline and, uh, connect with discipline with those activities. With threat intelligence, with threat hunting, and of course, with your security operation center, um, and daily security operations, uh, operations to maintain the false positive rate on the necessary level. And just keep in mind that tasks, uh, growing and growing with every day, with every year. It's not possible to maintain all of them. So you have to prioritize. You have to clearly understand which, uh, uh, weak spots you have on your SOC and you have to address these, uh, weak spots first. So any type of self-assessment or external assessment can be helpful here. Uh, just, just work on it and improve this every day. So, uh, that's it from my side. Uh, the last one, I just, uh, would like to, uh, remind you that SOC is not only technologies, but it's also people. And if I'm talking about people, we have to train them. And for security operations, we have a, uh, special offer for, uh, our training program on Xtraining portal. So you can, uh, reach this portal by QR code in the, uh, right bottom of these slides. And on this portal, we have a multiple trainings focusing on security operations, on threat hunting, on incident response, and even, uh, reverse engineering. So basically every discipline that is required by any modern SOC. So, uh, thank you for your attention.