# The value of security tools: what we wouldn't have if we had everything Nikita Vyugin · MKO Systems MOSCOW FORENSICS DAY ’25 · Day 2 — Friday, 12 September 2025: information security day · Scheduled 13:10–13:40 · In the recording 05:48:22–06:35:13 Talk transcript · https://2025.moscow-forensics-day.workers.dev/en/transcript/14-vyugin Summary: https://2025.moscow-forensics-day.workers.dev/en/summary/14-vyugin · Slides: https://2025.moscow-forensics-day.workers.dev/en/slides/13-vyugin-instrumenty-ib · Watch from 05:48:22: https://youtu.be/4V7Wez3L_58?t=20902 --- ## Moderator's introduction About the golden antelope. You'd think: strike a hoof, and gold will pour out. But each time it gets heavier and heavier. And as if it's no longer a blessing to us. It's roughly the same story with security tools. You'd think, if we had everything, we'd be invincible. But is that really so? My much-loved and much-respected colleague Nikita Vyugin will tell us about that. Let's give him a round of applause. Nikita, the floor is yours. — ## Talk and Q&A Hello everyone, colleagues. As Dima has already confidently said, well, just in case, yes, I'm Nikita, I work at MKO Systems. I think we already know each other. If not, I'm glad to meet you. It's great to see you all here, but let's move on to a rather interesting story. As Dima correctly framed my topic, today I'll be talking about the value of security tools. From both sides. I think a bit later you'll understand what I mean. I'll start, actually, from afar. Preparing for today's event, I wrote 33 pages of text, terribly complex, dripping with technical detail, descriptions, abbreviations, with modern security tools and all sorts of other things. Overall, I wanted to present it to you. And then I was lying on the couch scrolling through Telegram. And I saw this text in Dmitry Boroshchuk's channel. Dima, sorry if anything, do subscribe, it gets extremely interesting there. And this text really struck a nerve with me. It struck a nerve because, indirectly, I belong to the cohort of marketers, specifically in information security. And somehow it all made me really angry. Like, Dima, we're working here, and you go and write things like that. We're all for maturity here, real maturity, I mean. Pity nobody held up that little sign for me, because apparently I was tired by then. I still want to discuss security tools with you, with their nuances. But above all, I want to discuss them from two positions I think matter right now. Especially important for companies that are only starting to build some more or less serious security function in their organizations. The two positions are, However strange it may sound, the position of reasonableness and of maturity. Too early. Actually, if we're talking from the position of reasonableness, then in my subjective understanding, reasonableness isn't the moment when we look at something and go, damn, that looks reasonable. Reasonableness is when information security, as a department of some company, chooses a security solution for itself, consulting the other departments. Not just with the business, as usual, not only, well, we've passed that stage, that we don't build fences the business can't get through. Here we also bring in physical security, the security service, the economic security service, lawyers, HR, and countless others. That is, modern security systems are deployed into processes that affect every department. And deploying something without knowing how those business departments work, we make a big mistake. And sometimes we just waste money, as often happens. In terms of maturity, it's even simpler. Dima's absolutely right in what he said: maturity isn't the ability and willingness to buy any tools for millions upon millions. Maturity is clearly understanding how we build them, whether we need them or not, and how we integrate them in-house. Once again, my task today is to remind you of the familiar security practice tools, and without all this marketing tinsel, in order to step back a little and remember what these things are actually for in the first place, at what stages, to think about at what stages we might need them, or rather you might need them, and whether to deploy them, and what it costs us, not in money terms, although in money terms too. Let's start with scary antivirus, as ever, our familiar one, our most, most, most basic level. Actually, for those who aren't in the know, let me remind you that an antivirus, in essence, simply removes malware… blocks and removes malware on endpoints. It has a catalog of all sorts of critters and a catalog of suspicious operations. If it finds a match on one or the other, it, essentially, stops the process or kills the file. What's important to grasp? Antivirus is the most, most, most basic level of endpoint protection. This is all about users, about office machines, about servers and so on. It's the very first step in cybersecurity. What's important to know even when deploying an antivirus? Every information security tool has its nuances. And speaking of nuances, what will we run into when deploying an antivirus? As always, false positives. Triggering on things it shouldn't trigger on. On some legitimate processes, on some legitimate files. There'll be some. You need to be ready for that. A false sense of security. As often happens. Buy our antivirus and everything will be fine. That's not quite so. Up to some level, everything will be fine. And in its basic form, again, I'm talking about the basic level, it integrates with other security tools rather peculiarly, and most often super basic products simply don't integrate with anything at all. Another important point is the BYOD policy in companies. That's bring your own device, when our entire infrastructure is covered by antivirus, and then a remote colleague comes along with some personal device of their own, knocks on our infrastructure's door with no corporate antivirus, and, accordingly, all sorts of wonders can start happening to us. And, accordingly, one more point. Everything the antivirus takes out, it takes out into quarantine or for good. And sometimes it's quite hard to investigate incidents after that. But you have to understand that despite some seeming difficulties and limitations, I subjectively believe that if your company has at least one digital device in today's world, you need an antivirus. Since everyone in a company has at least one digital device, you need an antivirus. — Without an antivirus, the risks we'll face are that 90% of simple threats won't be blocked right away. That is, all these critters living online, which get onto USB sticks and so on, will be wreaking all kinds of havoc in our infrastructure. Without an antivirus, if we already have some security structure, and suddenly a strange thought strikes you: maybe I should drop the antivirus. No, don't drop it, because it's that first barrier stage. If we remove it, the load on the rest of the infrastructure goes up. And, accordingly, that other infrastructure usually costs more. So, if the load on it goes up, we'll, accordingly, be paying more for it. Well, accordingly, there are some basic levels of compliance with various requirements. And as consequences, for the corporate story we always have financial risks and reputational consequences. I'll say it again: antivirus in today's Russia is perhaps the integral, most important and most initial and non-negligible part of information security. Next, let's go in ascending order. DLP. I don't think it needs much explaining either. In essence, it simply controls potential leak channels. It identifies sensitive data by signatures, by content analysis, by document classification, by security labels and so on. And, essentially, it prohibits copying, encrypting, moving these files somewhere. Essentially, DLP is used, to the point that, whereas an antivirus, I believe, should always be used, DLP is used in cases where we have a high risk of leakage of some insider information, trade secrets, or we need to comply with some regulation. Let's imagine a simple situation. We have only 15 machines, but we deal with some kind of private data, some personal data. And it would seem, with 15 machines in a small little firm, you could get by on antivirus alone. But let's add to that, say, some tyrant of a boss who really likes to periodically part ways with our employees on bad terms. Well, that's just how he is. Do we need DLP in that case? Well, I think you know the answer. So, it would seem the scale is small, yet DLP is needed. What's another small point about DLP? DLP is extremely sensitive to configuration. This is important. Extremely sensitive to data classification. If we configure DLP badly, we'll get a lot of noise in the metrics that we'll have to respond to, and that will make our lives harder. Because, essentially, if we overtighten the settings and crank every knob to the max, then we'll simply be drowning in that noise. We'll also need to integrate it with our business processes, because just adding DLP as an afterthought and saying, go work, no, that won't do. When you scale, it will need further tuning. When the business processes scale, it will need further tuning. So it's not a plug-and-play story where we plug it in, it runs, and that's it, it's wonderful. Plus, of course, there's the balance, which is also written up here. We need to set it up in a balanced way so that, again, it doesn't hinder business processes too much, doesn't kill our business processes, but lets nothing extra through either. This thing isn't constant; we'll have to keep adjusting that level. And for that we'll need proper specialists. About DLP. What awaits us without DLP? A growing risk of data leaks. I've seen different statistics. The figure I believe most is that up to 30% of data leaks are cut by using DLP in a company. Some say 90–100 in the marketing brochures, but as they say, necessity's the mother of invention — they'll get it out somehow. But that core 30% we cut off just fine. Accordingly, we won't be able to control leak channels, we won't be able to properly investigate incidents, if we don't know where and how it all leaked, where it was all stored, and who had it. And, accordingly, if you're part of some kind of supply chain, then complying with the regulations agreed between the two companies will be extremely difficult. Let's move on. And next we'll be talking about EDR and XDR. These are quite interesting things, but I've combined them on one slide. And with EDR everything is fairly simple. Well, relatively simple. EDR is a kind of overseer. It monitors endpoints, PCs and servers. It does it a bit more interestingly than an antivirus, in the sense that it records process behaviour, network connections, script execution. It's not just matching an antivirus database and some database of actions. What do we need EDR for? We need EDR to detect sophisticated threats and to have the means to investigate them afterwards. I think you all know it, but just in case I'll say that EDR is implemented as follows. It's an agent that's deployed to a machine and then, in fact, runs there. Cool thing. It's often used, and it makes sense to use it if you understand that you're in the risk zone for more or less sophisticated attacks. XDR is essentially an extended EDR that uses as its input data the network, email, and clouds, and provides a kind of correlation of events with each other. XDR combines data, applies analytics, often applies machine learning and correlations. Also a very, very cool tool. The difference between them. EDR works on endpoints. XDR covers the entire infrastructure, including networks and clouds. Nuances of working with these two tools and deploying them. As always, noise, alert overload. There's no getting away from that. I think it's inherent in practically every security tool that has any ability to alert. Complex deployment and configuration. That's really so. An important point that I think is worth highlighting. By deploying EDR and XDR, you've reached a certain scale. And that scale will grow. Accordingly, you'll need new licences, new endpoints. It's important to understand that if you go down this road, then you'll also be scaling your spending on these systems. These systems are cool, but expensive. So if you're told that you'll install EDR and all your problems will vanish, that's probably true, but you need to look, count, calculate, and make a decision for yourself. How important is this to you — if you need it, deploy it. If you "need" it because some slick salesperson came in and sold you the idea, well, do the maths. Count, count, don't be lazy. It's important. And, as an afterthought, what awaits us without EDR, by contrast? So with EDR we understand: we defend against sophisticated threats, we get a certain headache in money, a certain headache in scaling and a certain maintenance complexity. But nevertheless, without EDR and XDR we have poor visibility of endpoints. We detect incidents late. That is, meaning that the earlier we detect an incident, the easier it is to work with, the easier it is to investigate, the easier it is to prevent, and the more we reduce the consequences of that incident. So without EDR, growing damage from attacks awaits us, for the reason above. And, of course, non-compliance with many modern security and protection standards. I'll repeat my thesis. Powerful tools, but you need to prepare for deploying such tools. This is no longer a basic antivirus, no longer a basic DLP system. Here — though a DLP system without proper configuration is quite a headache too, but here you'll really have to think hard about everything and do serious estimates. And be ready for the fact that you have major changes coming in security at the very least, and in IT for sure. Next, SIEM. My favourite thing, about which there are a lot of misconceptions, at least from my experience of talking to people at various events. SIEM, in essence, can be thought of, very simply, as an alarm system. When something goes wrong in our infrastructure, SIEM screams and, in fact, collects some logs, stores events, integrates with a huge pile of different devices and different information security tools. In skilled hands, SIEM is an indispensable assistant, because at scale, keeping track of everything, if you have a fairly large infrastructure, manually keeping track of everything that happens in your infrastructure, well, that's impossible, frankly, impossible. We'll either miss everything, or we need a battalion of security people running around by hand. Well, that's just ridiculous. But there's one important nuance. For your SIEM to work adequately, you need to have aced all the previous stages and some of the following ones. Otherwise we get some very unpleasant things. I'll explain which ones later. And one more important point. SIEM doesn't respond to incidents automatically in any way. It doesn't protect on its own. It detects and informs the operator about what's happening in the infrastructure. It's not SOAR, not some kind of artificial intelligence. It's simply this: SIEM screams, and the IT guy cries. That's the story. On the nuances, first, what's important to say — if you remember, I said that everything we had before needs configuring to perfection. Because with SIEM the main principle is this. Garbage in, garbage out. If all our systems are spewing some nonsense, some noise, our SIEM is just as noisy and, in fact, nothing good comes of it. Second point. For every infrastructure, for every individual company, sometimes per business unit, you'll have to write detailed SIEM behaviour rules, when it will scream. There are no ultimate ones, there are some, let's say, presets, but they all need to be fine-tuned, they all need thinking through with the business, since what's open to accountants isn't always open to IT people and so on — so there are important points. And I probably shouldn't forget to say something about reasonableness. Well, there's the classic example. 6,000 machines, 6 IT specialists. Do you have… You roll out SIEM. Are your 6 IT people ready to maintain 6,000 machines under a poorly tuned SIEM? Well, I think the answer is obvious too. The nuances, the difficulties of deploying SIEM. What are SIEM's advantages? Or, more precisely: what awaits us without SIEM? No unified security picture. We collect everything on separate monitors. That is, we don't aggregate data across our systems anywhere. Adequately, I mean. We don't see whether an attack is unfolding in real time, or we see it through the fog of war, which is quite difficult. The SOC, if you have one, becomes relatively blind. As for DFIR, probably no point even mentioning it here. And, as always, non-compliance with standards, if you're in some field where a certain level of standards must be observed, or if you're in a supply chain with some company that imposes certain requirements. And these days that's not rare, as far as I know. In general, what can I say about SIEM? And in conclusion: without SIEM, a company is left without central security monitoring. All the other systems can work, and can even work well, but each on its own. That is, we have no way to correlate and aggregate data in one place. We won't have a complete security picture. And if we don't have a complete security picture, some kind of unified one, let's say not a complete, but a unified security picture, then even if we have a huge number of great infosec specialists, we're going to lose a lot of time and resources trying to somehow respond to incidents and keep them under control. Next up for us is SOAR. Probably the system I personally find most interesting of all. SOAR, the way I see it, is a kind of automatic problem-cruncher. We integrate it with the SIEM, with the EDR, with all the other systems, write playbooks into it — read: simply scripts of automated response to specific triggers. And when those triggers fire, it goes and runs the playbook. Now SOAR is probably the one tool that we absolutely must integrate through negotiations and agreements between all the departments involved in the business, and not just the business. Otherwise it seems to make no sense at all. SOAR, unlike a SIEM, doesn't collect data on its own, but it automates the response. Again, you need to understand that SOAR is not artificial intelligence. It doesn't invent anything new. Whatever playbooks you write, that's what it'll follow. And accordingly, it won't solve all your problems. But with the right approach, it will do a decent job of the part of the work that otherwise has to be done by hand, and solve problems at the outset. And accordingly, your own infosec people will find it easier to work from there. The caveats. Obviously, with systems like these. Integration is complex to set up. It will be very hard, fairly hard, to develop the playbooks, the automated responses. It really is... And again, don't forget, we're scaling all the time, our threats keep changing. These playbooks are one thing today, tomorrow they're modified, the day after it's a third version, a tenth, a twenty-fifth. There's the danger of automated actions. Meaning playbooks must be written with your head on. Sometimes automated actions are written in such a way that they'd better never have been written. It runs into something, some trigger, it fires, someone didn't think it through or write it properly, business goes down. That happens too. Again, what we run into most often, an important point — resistance from other teams. Other business units don't always trust infosec, don't always trust some new mechanisms, don't always trust some new processes, and can throw a spanner in the works. This is about how, for some chief accountant with a USB stick lying in the top desk drawer with the keys sitting on the desk, it'll be hard to explain we'll now install DLP on you, which will monitor your every action, and SOAR on top of that, which will automatically do something or other. Not everyone's ready for that, so you end up having to do educational work. Well, and as I said, SOAR doesn't think, it does what it's told. And if we've messed up, we can't pin it on SOAR. Here you only have yourself to blame. But on the flip side, as always, without SOAR corporate infosec is left without automation and standardization of response, which matters at scale. When, again, we have 15 machines, a decent antivirus rolled out, DLP configured properly, and overall we've got an IT guy and an infosec guy, if we even have them at all, who can run around on foot, it's all clear, all good. We don't especially need it, really. And automation and standardization of response are, in a sense, already covered. But when we have 6,000 machines, we'll have to respond somehow. SOAR doesn't replace a SIEM, or EDR, or XDR. It speeds things up and makes life easier, including the lives of SOC analysts. That's its main story: to offload the SOC guys, turning them from a fire brigade that's always running somewhere, tripping and dropping things along the way, into an effective response center. And actually, since we're on the subject of SOC, let's talk about SOC. SOC. You can't really call it an infosec tool in the usual sense. A SOC is a sort of center for monitoring, detection, and response. It's a team of specialists plus infrastructure plus tools. Essentially they gather signals from these systems, triage them, analyze events, escalate incidents, kick off some kind of response, use playbooks, TI feeds, and tons and tons of various tools, and by processing all of that, they provide you with protection. That's the SOC — it's probably more accurate to call it an organizational unit that receives signals from everywhere and sorts through them. That's if we put it very, very, very roughly. There are caveats with SOC too, as with everything. There are two sides to the coin, the obverse and the reverse. On the reverse side... wait, where did my slide go? What awaits us with SOC? "Without" should be crossed out, oh well. SOC is expensive, you have to understand that. It's live people plus prepared infrastructure. So, again, we understand we need to calculate the scale at which we need a SOC. Second point. SOC people burn out often and hard, because it's difficult, heavy work. A SOC has to run 24/7, because otherwise — well, attackers don't sleep. Not on our schedule, unfortunately. The shortage of decent staff is tied to just that. To the fact that, first, there aren't that many great specialists freely available. Second, they get tired fast. That's really true. They burn out fast. Especially if somewhere while building your information security infrastructure you made mistakes, and they're running around all the time, despite SOAR, in fire-brigade mode. It integrates with practically everything. It all pours into SOC. That's hard too. And attacks keep evolving. So you somehow need to keep raising the level of your analysts. And what awaits us without a SOC? This. No round-the-clock monitoring, which, as I said, is important. No kind of complete, centralized picture of threats. Response chaos, along the lines of: we've got six infosec guys. Vasya, run over there; Lenya, cut the hoses. And, again, no expertise — not in investigation, but rather for investigations, although the SOC often takes part directly in the investigations themselves. We respond slowly, protect nothing, everything falls apart in our hands. Again, in the case — this is important — in the case of a company scale that warrants it. So, the takeaways are all fairly clear. A successful SOC is a well-built mechanism made up of good specialists, well-configured systems, and processes. Our favorite, my favorite — DFIR. Here it's all extremely simple. DFIR doesn't protect anything, but you have to resort to it, because in order to write that same playbook, some new one, in order to understand where it hurts and how it happened, you need to investigate the incident. So, what can I say about investigation. Unlike SOC, DFIR is a really super deep dive into incidents. It's not monitoring; it very often, in probably 90 percent of cases works retrospectively, i.e. after it's all happened, the incident has already occurred and most likely been contained, but we need to understand what happened. It uses very deep methodologies, very deep technical tools. So, in a big company, DFIR is like, I don't know, investigating an accident on a nuclear submarine a week later from the wreckage, and while some, I don't know, fleet admiral's yelling at you: yes, you must be done by such-and-such hour. Well, something like that, that's roughly what it looks like. Let's... So, the caveats, what stands in the way of DFIR. We can't properly investigate an incident, dig into it, if we don't have any systems for recording information. Time is critical; there are data sources used in DFIR that are very time-critical, for example, our beloved RAM. It takes huge experience, again, not... I mean, it takes huge experience both on the DFIR specialist's side, when he... he needs to not screw up while collecting the data, not wreck anything, not delete anything, and so on. And on the infrastructure side, since, roughly speaking, RAM holds a whole lot of useful stuff, but then some accountant, Valentina Ivanovna, panicked and yanked the cord, everything rebooted, and now we can't find patient zero, we don't understand what happened to us or where it all crept in from. Again, at probably every conference we talk about the myriad of complex DFIR tools, and it's not just the vendor tools that we and our competitors offer. It's also open-source stuff. It's scripts that people knock together for themselves to simplify their own tasks, to implement their own investigation methodology. And extremely high requirements for data collection and storage. But without DFIR we've become... And DFIR is expensive, it's complicated. I don't know, "expensive" is probably one for you. But it is quite complicated. DFIR specialists are deep-dive specialists. And the vendor tools aren't simple either. And you need... now a lot of people will say, well, I want my own DFIR team, but I only have, like, three incidents a year that I investigate. Think about whether you need... there are people who provide these services. So maybe it makes sense to contact them, no need to grab it all yourself. Again, assess your scale, do the math. Without DFIR we don't understand what happened. If we don't understand what happened and how, we can't prevent it in the future. We don't know if the attack is eliminated. Because there really are elaborate, multi-stage attacks. I think that's already been talked about today, and probably will be again. When we have no idea what's going on in an incident, we seem to have put it out, but did we really? Is there no backdoor left, wasn't this a diversion, wasn't this specific thing an attempt to distract our attention somehow? Again, the absence of digital evidence. I remember about digital evidence, but let's say, if you're a big company and you need to take this into the legal arena, you're going to need evidence. If you say we comply with some specific set of regulations, but we got hacked, and here's what happened, you'll need to show how you got hacked, and that you did everything to keep it from happening. Without DFIR, again, trouble with regulators and law enforcement. As you know, our reports are read by law enforcement as well. That's also extremely important, because it can greatly simplify your communication. If your DFIR report is done properly, the guys come to you after an attack and say, show us what happened, and you hand them the report. Everything goes faster, less painfully, and with less digging into your business on their part. And, well, increased business risks. Obviously, if we don't investigate, if we go through all of this, or rather, if this whole set of messes has happened to us, then, accordingly, of course, we'll spend more money, we'll spend more time cleaning up the consequences. And the consequences we face will be fatter. Again, just a thesis. I have a little cheat sheet. Just in case, I think we'll be sending out these presentations. If you want, you can take a photo. This is just a very, very, very basic example, a very simple explanation of what each system is for and at what stage. No, not like that. At each, for the use of each of these systems, you yourselves have to decide in a calculated, weighed, reasonable way, and work out whether you need it or not, and how much you need it. Obviously, if you're under regulators, you need it, there's no way around it, no arguing with it. Instead of a conclusion, what I'll say. Dima, I'll paraphrase that Telegram post of yours. Don't fall for bare advertising. Approach everything sensibly. Right now it's all colorful, all great, but you need to look, you need to count. Evaluate, consult, communicate with your own business if you're the security team. If you're on the business side, consult your security people. Do we need it or not? What's it going to cost us? What do we get out of it? And, an important point, what's the potential lost profit going to be if we don't adopt this or that technology or tool. And most importantly, just buying and installing cool hardware, just buying great licenses, genuinely great ones. Right now, security has probably never been better in terms of tooling. We're at the peak now and it's only going to get better. But if you install all of that without proper configuration, you'll just earn yourself a headache, spend a pile of money, get disillusioned with life, and maybe even go bankrupt. Think, reflect, and above all communicate with your business units, otherwise you're toast, gentlemen. I guess that's it. That was my little talk to warm up your brains a bit, because before me and after me there are more strong technical talks. Thank you very much. Should have ended with: don't fall for bare advertising, but do buy MK Enterprise. Colleagues, your question. Nik, look, you said very correct things, but even at the bare minimum, what you described comes to those same 5–10 million that small businesses, small and medium businesses, most often don't have. Can you say something about what those who aren't so rich should do? — — What should the less rich do? There's a very simple, there's a correlation method. I mean, look, there's… How much does hardening cost? — — No. We could debate this for a long time. In fact, it all comes down to four main areas, based on the threats. That's user identification, password protection or two-factor authentication together with it. That's perimeter control, because everything goes through the perimeter. That's a backup system, given that if it all breaks down, well, you can't protect everything 100%. And that's control of users inside that very perimeter, because users do all kinds of crazy things. And these four areas show very well, essentially, what to do. And here, on user control, for example, inside the perimeter, if we can't control them with DLP, right, well, the average company in the city of Moscow is about 100 people, give or take, revenue around 200 million, and if they have no DLP, and most likely they don't, or they have some cheapest one that's used as access control, then it's logical to put them in a controlled environment, to take something like, if we're talking about budget solutions, Nextcloud, ownCloud, where we can easily control and detect every sneeze. If our users sit on workstations and again there's no DLP, SIEM, EDR, and most likely there isn't any in a business that small. That's exactly where the forensics story comes in, when you can pull out all the user's actions, well, if he hasn't deleted them, after the fact, yes, of course. And then reconstruct the chain of events that led to a given incident. Well, again, regular backups and, above all, a system for checking those backups, whether they're actually alive or were made a year ago and only halfway. And two-factor authentication, because that's the fight against phishing, that's, essentially, perimeter control. And all of it comes down to a very small kit like that. It seems like it's just plain simple. At one of the meetups, where... Ah, you weren't there that time. Sasha Dmitriev, unfortunately I don't see him today, said a very correct thing. For each stage he... Just in case, let me explain. Sasha Dmitriev is our great friend, a pentester. Hold on, first explain what the meetups are. — — We periodically get together as security specialists and give ourselves a brain workout. That's what we call a meetup. And at one of those brain warm-ups we had a lively discussion. Sasha Dmitriev, a seasoned pentester, both physical pentesting and non-physical pentesting. And he said this thing. If you just open the Golden Rules book, open it like this and go through it, everything will be fine. I asked Sasha, I said, Sasha, how many companies have you seen in your whole career that actually went that way? He told me: one. I said, and how many big pentests have you done? He says, 200. With some simple arithmetic we figure out that's only half a percent. You're saying very true things, really, very true things. But it's just, I didn't ask you that question about hardening for no reason, that same one. I said, how much does it cost? Hardening costs nothing. If you have, well, it costs your specialist's time and money. Now, if you have a good specialist, they can solve a great many problems. But, first of all, users are always the hardest, hardest, hardest part of it. And what's my point? That yes, at a basic level you can do without certain things, but it will still cost you time. What are infosec tools for? To save your business time, to save your business money. And to protect you from problems that lead to loss of time and money. Can you do that yourself, with some basic methods? Yes, you can. Can you guarantee that those basic methods will actually be followed? Alas. Let's take one more question. We're running a bit over time. We're sliding into a roast again. I get that it's probably fun, but still. Colleagues, any more questions on the talk itself? On the right. — — Igor Evgenievich, I see your hand. Nikita, I'd ask a question as someone who deals with clients using Mobile Criminalist Corporate. Well, from our modest experience, maybe three years now of actively deploying it, nobody who's had it installed has dropped it. But the inflow of new clients is lower. I want to ask the following question. The Kaspersky representative who spoke before you was actively trading in fear, he did a wonderful job scaring the audience with what would happen to them, while promising nothing along the lines of: if you install my product, everything will be fine. No, they're not an insurance company, they don't compensate any losses, and neither do you, I suppose. Maybe a talk that's meant for specialists, for discussing the features and nuances of these solutions with Dima, should be reoriented the other way and also start putting pressure on those who make the decisions. Infosec specialists don't make decisions. What we run into is that they support it, they push it through, but the decision is made at the management level. And that's who has to listen, understand, get scared and make that decision. Thanks. Why don't you do it that way? — On fear, I'll fix that now. Gentlemen, you're all doomed, our booth's over there, please, without DFIR you're all finished, come to us, buy. Everyone's scared now. Frankly, the people who make decisions, that's exactly why my talk went from highly technical to fairly light and surface-level, because you can go on about tech for a long time, it's heavy and complicated. Scaring people, as if it's some kind of, I don't know, maybe Olga Vasilyevna Pugashkina feeds me this, it's bad form. That is, from a business-ethics standpoint, scaring people is not good. The decision to buy a complex suite — our product is not a simple one. Plus, it's not so much that the product is complex as that you also need skilled specialists to work with it, who need to be trained. That can be done with us. But by and large, that decision has to be a weighed one. Otherwise, if we sell through fear now, those people won't come back. As you say, the people who bought our software or any other DFIR software and did it sensibly, they don't drop it, because they understand its weight and importance. If they bought it out of fear, they were scared into it — that's actually what my whole presentation is about. If they bought it out of fear or because someone promised them the moon, well, he took a one-year license, used it or, worst of all, never used it even once. Or the worst thing is he used it and decided he doesn't need it. What's the likelihood that person will come back later to renew the license? Well, obviously. It's kind of, in my subjective understanding, selling through some kind of fear, or pushiness, or embellishment. No, there's a price, it's expressed in people, it's expressed in time, it's expressed in money. And the person, or decision-maker, either knows about our product and is ready, and finds it necessary, or isn't ready. If they're not ready or don't consider it necessary, we'll wait. The time will come anyway when they'll have to turn to DFIR. Either build their own DFIR team in-house, or bring in DFIR specialists from some specialized organizations that do incident investigation. It's a bad phrase, "we'll all end up there", but that's really how it goes. — — Nikita, thank you very much. Let's send Nikita off with a round of applause. Thank you very much, colleagues. And we move on. And overall, Nikita, please hand over the microphone and the clicker. Thank you very much. And I'll put it here. Okay.