Czy Bezpieczeństwo IT Idzie Dzisiaj W Dobrym Kierunku?

Thank you very much for the invitation. As for CTF, the guys told me to emphasize that there are cool gadgets, so I invite you to the tasks. If someone has problems and in the evening they put a beer, then reverse engineering will make it a little easier for him. As for today's pre-lecture, I started to think some time ago. My experience in IT Security is several dozen years. I started to think if what we do now is going in the right direction. I got to many points, I chose some of them. I would like to tell you about some of them today. The first thing is who I am. As P.H. already said, I work for Allegro, among others, and I am also a tester in Tanuc. Today I

would like to throw some fun at you, to give you a moment to think about what we do and whether we are going in the right direction. I would like to influence your way of thinking, especially those who are not so closely connected to IT and security. I would like to change our ITSEC culture, at least a little bit. It is aimed at people who are already sitting, who have a little more experience and who have an impact on companies, whether internally or externally, i.e. outside pentesters or employees of companies. Maybe something can be changed, maybe we can do something better globally. It's not about doing better tests, or better individual elements, how to play, maybe something can be done better. I would

like to tell you about a few random facts from my department, which may come together at the end of the presentation, give you some time to think. When it comes to the facts, it's about technical problems we face, but it's not about how to solve them, how to patch them, but more about whether we use the technical elements we have well. The second thing is personal problems, because it's a problem that we can't ignore in our department, but I'd like to approach it from several aspects, from several sides. and our IT security culture. Why do we do certain things? Why do we go the other way? What is the global impact on the organizations we work for? A few technical things. If someone is

working in IT security for a long time, it's nothing new. These are great, inventive things, but I hope they will make you think a little. The first thing is e-mail. We had and still have a lot of problems with e-mail, but we also have a lot of solutions. However, this spam is still reaching us. We have problems with phishing, which we have just discussed. We have something like spoofing a domain source. And what to do to protect yourself from it? Of course, we had a blockade project of a port from which it was impossible to send spam, but there is something like SPF. SPF is a headshot in is a DNS field that we use to secure and inform the user whether

the IP and domain address match each other. So, are we sure that the received email is "OK"? First thing, the standard is quite good, there is already another version, but it is not used too much. It is not mandatory on any of the pages and it is not used often. If we look at an domain, we will see that it has a field and it adds additional includes. Very popular in corporations is the transfer of mail to the cloud. We have Outlook, which is in the Azure cloud. And the question now is: how many companies have their own machines or services in such a cloud? How many IP addresses are there? Are these IP addresses all in, for example,

Scope or Bug Bounty? If we look even further, we can see that Outlook itself has a lot of IP addresses. Here we have 14. Have you ever wondered if in all these IP addresses we have any classes available for Azure clients? What is there? Are there any machines that can be compromised? If anyone who participates in bug bounty sees such ranges, they see money coming up in front of their eyes. Because as long as there is no security team, if they actively use these ranges, there is no way to protect them 100%. But this does not apply only to Microsoft. If we touch Google, we have a very similar Here, note that the IPs of the domain owner themselves are also very wide. Besides this

include, we have 22s, 16s, these are also places where you can enter and send a mail. And then, even if someone verifies this SPF, he will not be blocked despite this minus, because the IPs will be blocked. If we go a little further, here we have specific, next includes. Google has a lot of them, so they are divided into several pieces. And in these includes, there are more networks. Let's pay attention to this 16. If you test it, and here it is not "responsible disclosure", but nothing, Google has confirmed that it is not a bug. I don't know if we as IT Security will determine whether it is a bug or not, but we will leave it to you to assess. Imagine that if we

look at this address, which is part of this mask, we can send mail from the domain of companies that are in the portfolio of Google services. Is it a problem? Is it a liability? OK. When it comes to DNS, we have something similar to DNSSEC. There was a problem with the fact that DNS is based on UDP. It's a very old protocol. We have many protocols that simply don't want to die. We have TFTP, we have DNS, for example. DNS is used in many attacks. The attack on DNS itself, by races, who will respond faster, attacks related to DNS responses on IPv6, attacks using DNS as a possible middle of the attack, i.e. DDoS, mentioned

by Pehat. If we get away from DNS, our IP address is hidden. This applies to all protocols that operate on UDP, but DNS is cool because it gives us amplification. We are 8 years after the introduction of the DNSSEC and we are currently at a rather strange level. Although it is a security mechanism, just like SPF, its implementation has its pros and cons, but it is not very popular. Although it does bring a lot of effects. This is a fight that started a few years ago. Another aspect is the HTTP/HTTPS transition. It's been happening very actively in recent years. Standards force us to upgrade the next versions of SSL and TLS. A very nice browser action to show as

quickly as possible that you are on the HTTP side. OK, everything is great. The problem started with men in the middle when it came to HTTP. A very popular protocol. We had men in the middle, so we implemented SSL and TLS. A bit historically. But the attackers also decided that, okay, but apart from the large attacks or very complicated attacks on the protocols themselves, we have to do something to automate it, to make it work on a larger number of clients and viewers. So, such tools as SSL Strip were created, using the fact that at some point in the HTTPS movement, A client, when entering a website, does not enter "https://". We have been getting used to this for a long time, as Boris said,

to some features that do not work for our benefit. If someone writes "google.pl", the first thing they get is a "http" response. If they write a letter, a subdomain, we have more problems. What can protect us from this? Of course, HSTS. But have you ever wondered if HSTS is well implemented? The race between the bad and the good, as usual, continues, so SSL-strip was created in the second version. And this security, which is often talked about and implemented in the form you see, ceases to be so effective. because there are no included subdomains. Okay, a more historical example, but showing the problem. We have a mistake and we want to get rid of it. We have methods and

standards that tell us how to do it, when to do it. And we have, for example, OWASP, great projects on web and mobile applications. They show us problems and how to deal with them. Implement CSRF tokens. So what happens often, I hope not so often in applications, it's thrown into cookies. Is there a security? Yes. Has anyone tested it? Hmm, okay. A little more application-wise. We have data filtering to secure ourselves in applications, data filtering at the input and output, various technologies, we can do it in various ways. Do we have any technologies that can help us in defense of such attacks effectively and globally? Of course there is content security policy. But if you look at content security policy on many pages,

first of all, policies are often too complicated, exclusive and difficult. that doesn't cover the whole thing. But then, it's often report only. When it comes to report, it's cool, someone is already making a move forward to do something about it, but if they have a big application, the question is whether they are looking into the logs they receive, whether they are doing anything about it, whether they categorize it. Okay, there is CSP, we should implement it, but has it risen to the level of security? Not quite. This step will lead us to the group of problems with people. If we use CSP reports, we need to have people, tools and people who will look at

it. Even if we have a cool tool that will make us a sort of unique, we will have a top, we will have specific attacks, we need to have people who will look at it. The first thing is the lack of people. In many companies we face this. that there are simply no people to work with. The teams should be much larger. It comes from various aspects. Here I have a notice for both companies that I pointed out, we also conduct recruitment, so if anyone is interested, I invite you. But okay, luckily people send CVs with hundreds and there is something to wear. Not really. A notice is sent out, a few people are reported, who don't even know what they would like to do in this security. It's

catching people who are often nice to raise their salaries. They come, they have a conversation, they are on a good level and after receiving an offer they thank you, because they are also people who are not replaced in their own companies and they also need to be stopped by force. Okay, we have a sucked up IT market and what can we do about it? Here is the first thing, or another thing I would like you to pay attention to. How are security guards trained at this moment? people from various departments, from physical to technical, it could be done differently. It's a long process, but we have to think about whether it's the same as it is now, for example, someone has a cut in IT security, was a

developer, administrator, dealt with other departments, but they had such a cut, it was clear that their mindset was whether they were part of this team or not, these are relatively rare cases. I think we need to go much lower with the promotion, among other things, as today's conference, the promotion of IT security and training much lower, that is, to the level of teenagers or even children. Okay, the next problem is the swirling of employees' positions. I don't think I'll be developing here, because the problem concerns the whole IT, so I guess that 90% of people in the room know what I mean. But companies, fighting against employees, raising the rates one way or another, are raising them to such levels

that it is difficult to justify the business expansion of the security team. And an important aspect. When I started playing with IT Security, if someone asked me what I was doing, I would usually say I was an IT specialist. Now there are administrators, developers and IT Security. But if you look at developers, security guards, administrators, each of these teams can be divided into many different sections. If someone deals with the security of web applications, this position can be divided into five. He deals with the security of Java, security of load balancers, security of cache, specializes in browser tests or client-side security of JavaScript. And here, if we have... Someone said yesterday that we have a few dozen of

us in the room, plus a few dozen in the lobby. I think that there are more people from the security team or the technical security guards, although if we divide them into such specialties, individual people will fall into these buckets. And how to expand these individuals to the market of needs that we currently have? I don't know, it's hard to say. Okay, when it comes to more and more specializations, the number of specialization types and technologies is increasing. If we look at what big companies like Nokia, Samsung, Netflix, big corporations are supporting, they have a very large number of new ideas, new technologies, Security services have to chase it. A developer comes in, says: "I have a nice library, a new programming language was created

six months ago and I'd like to write something in it and put it into production." It will be fast, efficient, it will work very well. The last example is Firebase. Super technology, it's developing very well. Very few people chase this technology from the point of view of IT security. If someone does it, they enter a path and tries to do it after hours, not during the work he does. Work means security in the corporation in normal hours or penetration tests. The number of attack vectors increases automatically. we will increase the number of technologies published publicly, then each of these technologies will be able to be attacked in different ways. If we go back 10 years, we had several headings that were in the

questions of HTTP. Now there are many more. Recently, at a meeting in Wasp, on Wednesday, I think, a very nice lecture about caches, about attacks on caches. Very few people test it, very few people, even though they deal with pentests, know that such attacks can be performed. And if you find out, does it deepen this knowledge to the end? It's hard to say. Not everyone can specialize in everything. And when it comes to attacks, they are more and more technically complicated. In the past, CVSSs at level 10 were quite common. Code execution, attack leading to total penetration. These are very specific cases. Here we have to take something from the cloud, from the bucket, we have to put something in the form of a specific file

in a specific format to trigger some technology that is at the bottom. We combine several different technologies to perform stronger attacks. These types of attack vectors are not to be detected in standard tests, especially if companies rely solely on automates, because they don't really have to cover people with more safety. Okay, next thing. People are starting to specialize, but they don't have the basics. I don't want to show it as a problem, because if someone is a specialist in a specific department, they should know the basics of that particular department. But of course, when it comes to security, we want to create them now, train them as much as possible, but we also want them to be good security guards. We just need a time

to market. A person comes in, who says he wants to take care of security, I was a developer, I was an administrator, I know something, how to quickly transform him into a person who will detect these very complicated attack vectors. It's a big problem, and after three months, such a person gets the information: "OK, do the tests". Okay People often appear who don't have such basic computer skills. Maybe it's because I've had my neck on a bar for a few years and I grew up without a graphics card, but there are problems with using consoles in the system. If someone is interested in such application attacks, they don't have to use this console. A question to be

asked is whether they should know such low-level How is a computer built to make use of its work? Partially yes, partly no. We could discuss this very closely. Okay, as far as the basics of computer operation are concerned, a quick question. KB is 2 to 10 or 3, 10 to 3? Who is the first option? Okay, and the second option? Cool, good statistics. Most of you answered correctly. A kilo of sugar, what is a kilogram of sugar? 1024 grams? Okay. Kili is a 2 to 10 kilo. These are the basics. And these are things that people learn in high school, people learn in their studies, but it doesn't always stay in the head. Just a coincidence. Who writes this

documentation? This is a 3D printed icon of a file saving. Of course, a floppy disk. A fun fact: the floppy disk capacity is 1.44 x 1000 x 1024. If you think it's a big problem, then it's not necessarily worth it to use kilobyte. It's not necessarily worth it, but it's worth knowing some things, it's worth reading, it's worth learning even from such a simple things. I don't remember, for example, the capacity of tapes. I didn't deal with tapes and it's not a problem for me at work either. So maybe it's not as big a problem as it may seem. Okay, the third department: IT security culture. First thing, and I wonder if I should mention it in the personal

or in this section, we have offensive vs. defensive. How many people are offensive here? Okay, two, three, more, great. And defensive? More. Usually it is like this, that there are more people who deal with defense than offense. The problem here, I think, in our culture is the fact that Offensive is sexy, while defensive is sitting in a corner and watching what's going on. But I want to draw your attention to the fact that this guy on the right needs one hole to get into the system. It's enough to find one path to penetrate the system, extract data, and throw malware. These guys have to protect all people. We've talked about social engineering attacks or a preamble. If we

want to attack an organization, it's nice to have statistics. 30% of people responded to an email, 15% wrote a password. But often, with normal attacks, they are automated. So if the password is already entered, the machine reads it immediately and the attack starts immediately. It immediately tries to use this password to log in. The guest needs one password, one user who can use it effectively. These people need to secure, train, equip thousands of people with tools. If there is one person who says "sorry, I clicked because I'm after training", Even though I'm trained, but it happened, we already have a problem, we already have someone in the middle. So, in fact, from the point of view

of defenders, we are always in the lost position. Okay. As for statistics, also regarding the previous presentation, many people, despite having training in social engineering, can be caught a week, two weeks later. And this is a big problem in our culture, in the culture of IT security. High-cost games. I don't know if you know this. A chip that is located on top. I won't comment on the matter, but let's think about it. If we are two super-sacrifices, Americans vs. Chinese, if Americans design the equipment and send the specifications to China, and build it there, and then send it back, then who would think that something is not happening there on the way? Come on! They

have no control over factories or hardware construction. The same goes for the other side. The topics that Snowden revealed: sending Cisco hardware with backdoors in it. Another problem with testing is the time we spend on testing. I found some very cool drawings. If we give the draftsman 10 minutes, a minute or 10 seconds, he can either make a very nice drawing or a fairly visual one, but you can still see something. If we give him little time, he won't even speed up. The same is true for security tests. Of course, time is always cash. Time spent on tests, on people who work on something, is always counted in zlotys. Zlotys, dollars, whatever currency we choose. The problem is that if

we give someone an app for testing and we tell them that it takes 4 hours to do it, because you have to do these apps 20 times a week or for 2 weeks, then they will look at the app and say "ok, look and feel, cool, it looks ok, there is no alert without any coding, I didn't check SQL injection and I didn't open ASVS at all". The more time we give to such a person, the better and more effective the tests will be. Of course, we reach the point when there is a blockade and I can't come up with anything else, I take something else. And it's not necessarily about giving full time to

individual tests, unless they are very priority tests, but there are As a person who performs penetration tests for companies that require compliance with the standard of PCI and receiving very limited time to perform these tests, I wonder if this compliance, which is on paper, is in fact a compliance. There are companies that lost their cards, had PCI and everyone wondered why. Because they didn't spend enough time on it, the auditor didn't add more topics, but we have more problems with it. What are we testing and what should we test? The question is: how many companies do the tests? Two. takes care of these tests. How much they would like to do, but their budget does not allow it. Here, too, I would like to

focus a little on changing our culture and moving it to the point that we start taking care not only of large corporations, which put hundreds, hundreds of thousands of us here, "do me tests", but also think about, as part of those people who already have some experience, how to do it, to take care of these smaller companies. Okay. If we have a company that is aware of this and has more money and can spend it on it, then what is the number of tests in these companies? Usually these are general tests, external scans of one or two of the most important applications, but the rest of the company, i.e. other ways of entering the same

infrastructure or the same group of machines in the cloud, weaker applications, less significant test environments, exposed to the world, are not tested. Did the level of security of these companies rise because we tested some kind of cut-off? We have to think about it. If we have a bug bounty and we cut it off to one part of the infrastructure and leave the other, does this scope also provide us with great security? We have to think about it. The quality of the tests in terms of time is more or less what I mentioned in the drawings. But also the quality of the tests in terms of requirements. We test this, you must not touch this, this

is beyond scope, because there is some problem with performance. A very large number of limitations. And then at the end there is a quarrel, no, no, this is not critical for us. To not be so sad, because I see your faces, I put a few slides in to move you a bit. A super safe padlock, it can be overcome only and exclusively with a screwdriver. Who knows what the code is or how many times you have to shoot to reflect? A very popular sight, pay attention to airports. The same codes have always been around for many years and this is what the panels look like. Okay, no comments. This is a very similar example, here is a barrier,

sorry for the resolution. Here, too, a great secured gate. It was probably in the original GIF, but I couldn't find it. The guy shows that you can just jump through these gates here. Fortunately, I have the code written twice. Write down "security failed images Google". This is the source I got it from. I took only a few to show you that we need tests, we need it even in this look and feel, if we don't have resources. So that someone comes and says: Why do you need this lock? If there is a code here, then take it and install it. You will be richer in a bit of a break. And of course, security everywhere. Another problem with tests. If we already perform tests,

we have a set of vulnerabilities, then I noticed that there are two trends. Of course, we use CVSS, because people from IT Security, and that's cool. We like standards. We have SVS for web, we have Here we have CVSS for evaluating errors. This is only a base score. We can add more components and calculate nice values on them. If an append tester company is doing tests, then, you know, a perfect example is a colleague from the team who says that there are no append tests without RCA. But it doesn't always happen. There is not always a remote code execution. And sometimes you have to show that there are fewer errors, that it is maybe a

little safer. And two trends that I noticed among people who write reports. They drag some things up to show that they are important, using CVSS, which is not entirely OK. But we sometimes feel, when we see the tax, that even though there is a medium, it is something that really hurts the company when it hits. So you should pay attention to it. It is written in the descriptions, but do you think that many people read reports? Not really. They see the colors. If there is red, purple, yellow for medium or any other color you use, they look at the basis of whether the report is OK or not. whether they are important or not. But what happens

next with these similarities? And here is a sad practice and this is the first moment when you have to start talking about communication. If we have an external pentester company that will come, make a report, present the report, show how cool the proof of concept works, and then leave this report along with the invoice and come out, then usually it goes to the drawer. The same thing hurts internal security teams. They see that these are things that should be improved. We don't always have resources, time, people. Risk mitigation through its acceptance is very popular. The same goes for the projects of these security teams. They go to the drawer because maybe they will be useful

someday. Maybe we'll start it someday when the right time comes. And this is a specific date called "Holy Never". But let's move on. In practice, it's always nice to do retests of these vulnerabilities. And in requests for retests within the orders, retests are very often. 95% of requests for retests contain retests. Ultimately, these tests are not performed and there is only one iteration of tests, which often happens after a year. It shows that the same errors are still there. They are still in this report. the company is still liable for the same attacks and nobody did anything about it. Moreover, the company doesn't even have a unit that could check if these errors have been exploited, if someone got inside thanks to

them or stole any data. This is a very big problem and I think that it needs to be addressed in the teams you work in. Okay, but when does patching go fast? Can someone guess? after an attack, after an incident, I agree, it's something else. When we add a logo to the tax, not all of these taxes, most of them are known, but not all of these taxes, I would say, that most of them are not critical. But if the CEO reads in the newspaper or on the portal, or in the phone in the morning, on the way to work, there is a critical vulnerability, which of course in the CVSS is 4.4 and does not concern the company, then he will ask: "Excuse me,

but is this patched by your directors?" The director will come down to the driver and say: "Hey, are we doing something with this?" and the manager asks the team if they are open to it. And the team says: "Dude, it doesn't concern us at all!" Fortunately, these types of lags work very well on imagination. Okay. As for the problem with patching, here it is more about correcting these errors, to go one step further. We have a set of problems. First of all, technicians and business speak a different language often. We try to present the technical threat, something we know about, at a business level, through risk analysis, for example. What can happen if it happens, what can't happen. But

it's a difficult conversation. We need resources to fix it. Yesterday, a colleague from RBS talked about Responsible Disclosure has also started to push this topic. Completed processes. If we have a liability, if we are internally in a team, how to arrange processes, if we know external, internal, public or not, how to very quickly, according to these processes, because not next to them, deploy to improve the liability, how to improve it so that the company becomes safe in a short time. Here, I will also refer to it in a moment, but in February 2017, the information comes out: "Check the B1, do not use the B1". The information is quite sharp, all scanners show 10/10 of the CVSS, although the CVSS was written there "on fire",

Nobody knew what the tax was, but everyone who knew a little about security knew that something was coming. What happened? A month later, the country's debt hit and there was a big problem in all of Europe and not only. Many companies had problems because no one paid more attention to it. Maybe some started to patch, but their processes were It's impossible to do it so quickly, it's impossible to do it fast enough. Or maybe developers or administrators just decided to show proof of concept, then it will be patched. That's a big problem. Risk management through acceptance. I've already mentioned that. And lack of proper skills to talk to both sides. I've heard this sentence twice at this conference. Maybe not in this form, but people

who are purely technical, who are inclined to make mistakes, are not always the right people to talk to the other side. We have different psychological profiles, we want to secure something in different ways. We would best come and say: "Look, I've won here." And they went. And people asked why, what for. I have to spend time on people, how long it takes, whether it needs to be tested. Or if we go even higher, to abstraction, whether we need it at all. Prove that there is a problem here. It is worth working out a conversation path or the right person. Not everyone is created for this type of conversations. And the problem I see in our department is very significant, it's the culture of fear. Just now, Boris also

said: let's not learn from the culture of fear. Very nice, because it confirms the same thing. Historically, do you remember what happened with this date? The whole Internet was supposed to fall. It turned out that it is not as critical as it turned out. The second thing is the country I've just mentioned. We have ransomware, but let's not treat it as a big threat, but let's try to protect it in a simple way. To protect the company globally, as well as the employees. Through procedures, through changing the way of thinking, through the fact that users do not click, do not install various things. This is a very complicated process, but the question is whether it is very expensive for the company if this application and

infrastructure part is secured. If a single employee's computer is encrypted and he loses some data, he should have backups. If there are no backups, how much did you lose? Okay, six months of work for one employee. These are not big costs. And companies that fight against this say: "Ok, we'll decrypt your files, but it will cost tens of thousands of zlotys". And often on public websites, decryptors appear after some time. Let's not be afraid of big costs and let's not try to draw money. big money from companies only because there is something that can be used to scare companies. The same thing is with these error logs. There is something critical, the Internet will not work soon because we have SSL downgrade. Okay, does anyone know what this is?

This is exactly the Internet map. Another nightmare, IPv4, coverage. Our addresses will be over soon, but fortunately there is something like notifying, but it was not such a big problem. We did not have to replace all devices with IPv6 It works, but it's not a market leader. And the topic that has moved the PHD is DDoS. From yesterday's presentation we know that 5.2 gigabits per second are in the average DDoS attack. If we look globally, we have to pay attention that if someone takes over our enterprise and spends a lot of money on it, he will always be able to harm us. Not necessarily to destroy the application, destroy half of our infrastructure, but it will do us harm. If we look at what is

average or below average in most attacks, these are things that we can block by anything on the firewall. If a company has one 10 GB connection, then the average 5.2-5.3 attack will be unnoticed. If it blocks it at home, OK. If it has one 10 GB connection and someone attacks it with a bigger attack, it also has ways to defend itself. It can also use the cloud to make this move, it can use external resources, communicate with the supplier by blocking various elements. This is not something that should scare people either. Why is the fear culture so developed in companies? Can you guess? Of course, it's about cash. IT security is a big business and everyone tries to sell us something. If we don't

have people, a personal problem, we don't even have the possibility to verify whether what people sell us is worth 5 PLN, 50 PLN or 500 PLN. We take, install because we are afraid. If there are simple ways to mitigate some attacks, the whole classes, I don't want this presentation to come out with such a difficult sound, but many classes of mistakes that we had a problem with a dozen years ago are not a problem now. Many things are rising in people's consciousness. The fact that so many people meet here is also a point that shows that we are going in the right direction, but maybe it's worth changing something further. And such a very important

thing that has been hurting me for several years and from which I actually started the idea for this presentation. Who do we defend and who should we defend? Returning to this slide, we defend those who have cash. But if we think about DDoS, if we think about massive attacks, then let's not defend ourselves, but let's try, even though it will last longer, let's try to protect as far as possible from us. Ordinary users. Operational systems are quite old. This is one of the examples. Other things are users using old monitors, old network devices, TVs, fridges, industrial cameras, whatever you put in your hands. IoT is in charge now. We must not only inform employees. If we can do a procedure in the company to secure a computer, then the

same employee using his computer at home will not necessarily carry on the same habits. In fact, no one defends ordinary users of computers. Sometimes it is said that my internet provider gives me a great service that I have never seen and that costs me another 50 zlotys, or I bought a computer and had an antivirus for a zlotys. This is the only thing we do with ordinary users, with ordinary devices that which are the source of these DDoS attacks. If we didn't have so many unsecured IoT devices, we wouldn't have such big record attacks. And of course we have to raise awareness of users or users-harmonizers. Regardless of where they are located. Are they employees of a company, from an administrative, administrative level, ordinary

people who use our applications, use the computer and don't necessarily want to upgrade it because this Pentium 2 from 20 years ago is still running and AES 5 is only being distributed on some sites. And we have so many malware that we could open a museum. I would like to ask you to think about the topics I have put up for presentation. They will probably be available, if I'm not mistaken. Think about what you can do about it, but let's shift the pressure from cash to places where there is and never will be cash. Because when we talk about pentester companies, they are pricing themselves They evaluate a lot of tests and this is a big added value.

It's not money thrown into the mud, but a regular Kovalcki won't pay for his computer's tests. He'll ask: "Ok, my uncle is a developer, can you take a look at my computer? Is it safe? Is something ok?" And that's it from the presentation.

Hi Czesław Hi, I have a question for you Kuba You said that companies order the tests and nothing is improved after the retests, nothing is improved after a year, maybe, but not really I have seen various cases from different companies, I agree with your observation, but what can we do, in your opinion, because you also said that the money is not spent for free. In fact, Pentester did its job, but in fact, these tests were ordered completely unnecessarily. What can we, as Pentesters, do to make the product of our work useful for the recipient, so that this company actually does something, so that it does not use, do not order unnecessary Pentesters, better prepared to consume these results. Ok, great question, thanks. The first thing is that

we glorify too much. I'm on the attacking side, to make it clear. I've always been an offensive spirit. But we glorify too much this part of offensive security, we underestimate too few people who build this security. And now, to To influence the company's activity, take a look at the several pentesters on the market. They sell, because they sell best, such are the desires on the market. Such and such tests, infrastructure, application, mobile, social security tests and finally there are consultations. And in these consultations, it should be a floor above. Let's not sell tests, because if we enter the company and someone says: "Someone broke down somewhere next door, I would like to test it too." The question is: "Have you analyzed the risk and do you know

what you really want to test?" Do you not need someone to sit down with you for at least one day? These are not expensive conversations. One day, one person. Let's look at the company's resources. Let's check what should be protected in what way. What systems should be implemented and which do not have to be. Sometimes it happens, and it's quite rare, but it happens, you come to a meeting with the person responsible for the tests and you get a link to a website where there is only an information application, where there is literally HTML. We want to test it, we have such a budget, I say: "Okay, I can live on it, but it's not

better to transfer this budget somewhere where you actually have assets, money, production, credit cards, customer data." or it's better to test something that will actually hurt you. And here, if we are the first person someone contacts, then let's not sell this service at first. This service will eventually be sold anyway. We will do these tests for them some time later, if we will make this person aware or this company, but if we let them know First, analyze what is important and what should be tested, and then test it. Or, let's secure it, because I see that you don't have IDS or WAF, the app is throwing XSS at the first test. Let's first do some

security, do some review, and then we'll start with pentests. Here, too, you need to make people aware of the difference between pentests, Red Team and Blue Team simulation, and security tests, compliance with standards. Let's be aware of it. Maybe we will sell less at the beginning, but globally it will be more profitable. I have a question. Will the entire range of security programs be needed in the future? Where are these programs more and more friendly to users? Nice question, thanks. Have you used security scanners? And have you found errors that the scanner has not found? I recommend you check out the pages like HackerOne, Backcrowd. When you see the errors, 95% of them, the better ones, of course, I'm not

talking about SSL problems, are errors where you need to add more logic. Even if you take big tools, I won't mention them, I had the opportunity to take part in the tests of the source code analysis tool. If you feed this tool with the source code, it usually spits out even fewer errors than a live tester would find. In the example I gave, a very skillful person with a lot of knowledge about security wrote a gripper, literally grips, a bit of AWK and found more errors than this machine after a week of tuning by the company that sold it. And these are very big tools. Even if we manage to replace part of testing with tools. Of course, to make it clear, tools are very cool and automate

our work. There are few of us and we have to somehow share or prioritize these tasks. Then the tool will always send you a report and you have to have a person who will say: "This is false positive, this is false positive, and this is some weird bug." And here I have telnet and it says it's informational and I can get there without the username and password. And these are examples live pentests. Even if we exclude pentesters or testers who manually click something, you always have to put a person behind the scanner who will first configure it, and secondly interpret the report. And she will be able to pass it on to the business. If

we put a report to the business, I had one such case where I took a security scanner and just scanned everything. I limited the report to 900 pages, a very large infrastructure, to 900 pages of only high and critical and I passed it on without a comment. I got feedback, but what to do with it, because I didn't even read it. I will cut the time a bit, but it's okay. So, will you be at the afterparty? So, as I said, we will go for the beercoins and then we will ask the prelegent some questions. So, there is also a contact. Allegro is recruiting, because he didn't say it. I have to talk to them. Okay, so, loud applause, please.