OWASP Sofia December 2025 Meetup (part 3)

2:41↗минимума, да изключим това, което не използваме. много си прилича с предния риск поради простата причина, че в предния риск говорим за аутентикации, за това, което не бива застъпване, нали прич. Тук говорим закърс на софтуера или хардуер, който използваме и това просто да го минимизираме, нали, ако примерно вие си налично сравнявам с автомобил, си купите автомобил и той няма а да речем имобилайзъра или аларма или GPS тракъ нещо подобно, нали, и ви е скъп или пък застраховка каско и ви е скъп си го паркирате пред блока, нали, най-малко бихте искали да го харднете с някаква аларма или нещо, а особено ако живеете на нея. в някой по-скъв рисков рейон. А най-просто казваме премахваме рисковите компоненти, нали в превенцията има, особено за clуда и за контейнерите има готови ванила или харни имиджи, които ние можем да свалим и използваме и те с тях достатъчно много работа, нали? Не се

3:37↗налага ние да инсталираме или деинсталираме нещо от тия системи аа сваляме ги и започваме да ги използваме. също пози хардуера. Ако например си купим а лаптоп, нали най-простия пример или си купихме мрежово оборудване, редно е като го инсталираме, го настроиме по такъв начин, че то да е изолирано, да е минимизирано, нали, да няма някакви неща, които не ни трябват, да не остават сервизните там а потребители, админ админин и нещо подобно в него. Доста е доста е проста превенцията. Не е лесна понякога, защото може скейлът да е доста голям. Аа убително ще го пропусна поради простите приключи. че колегите свършиха изключително добра работа заoftare supply chain tailers аз обикновено си го а го презентирам като един огромен айбек на който ние виждаме само повърхността тъй като абсолютно всичко което разработваме днешно време зависи от изключително много pate или open source

4:27↗компоненти и ние трябва да сме superвин да ги сканираме постоянно да ги анализираме постоянно поради проста причина че да те са тук да ни спестяват много време и енергия за да пишем лайбърите за какво ли не или използваме софтуер за какво ли не, но ние не познаваме всичките девелопъри за тия компоненти и рано или късно можем да се окажем жертва на някакъв вид запланичек, нали. Това може да включи, както колегите казаха и са софтуери, нали всичкия софтуе, които използваме всичките дентори а е редно да бъдат тествани и скринирани. Между другото, не знам дали повечето от вас знаят, а млади хора, предполагам по по-технични хора в модерните а и базирани а регулации, които излизат на последно време, нали, AI актове, долара и така нататък, там е изключително много за наблягане на софтуерчей от гледна точка на това, да речем банките или финансовите компании какво

5:19↗ползват, откъде го купуват това нещо, то тествано ли е, сигурно ли е, а нали това вече една по-висока абстракция, но реално е същият този проблем, нали? Не е Просто не е просто проблем. Аз като пиша едно приложение, какви компоненти вкарвам нещо в него, тъй като аз мога в backда да ползвам някакъв компрометиран друг SAS сървис, който дайпасне всичко това, което правя на полто нива. А на четвърто място все още се запазва cryptographic failers. Моята теория, че е на толкова високо място е а произлиза от факта, че с напредването на нали хардуера и технологиите а чисто от гледна точка на CPU Power и GPU Power, кракването на по-стари а шифри а в криптографията е доста по-възможно, нали? Вървим в посока квантова криптография. Достача според мене от нея, нали тя няма да бъде толкова достъпна за средния пред актор, но аа все още си позволява да допускаме базови

6:17↗грешки при разработването на приложение, нали? Ако си позволите в бъдеще да станете 10 или ако не сте, а и си разгледате приложенията на телефона, повечето от тях на телефона ви се храняват нещата в clearтекст или понякога дали комуникацията е в Clearтек, което е супер страшно, защото нали вие сте на летище и случайно се конектнали към Малишас с Wi-Fi и те ги компроментират трафика, не биха могли да гледат трафика на приложенията и е доста неприятно. Другото, което е така доста дефинси в сектора, е използването на остарели шифри за комуникация, а остарели функции за хиширане и валидиране на на файловете, нали, дали един файл е същия или не е. А каква е причината? Бидейки а компроментирани и разбити, така да се каже, тези шифри, а много лесно човек може да генерира а само пояснение с тези от вас, които не знаят идеята, афиширането и основната му основния му иска основното му използване

7:14↗е това да варитираме дали файлове са едни и същите например или дали софтуерни компоненти са едни и същи. И когато един шиif разбит, тоест аз мога да генерирам същия fingerprпint, но с друг файл, аз мога да заменям файлове в отделни компоненти, нали, да си представям за нещо, което не съм. И това е доста страшно. Аа но причината да е на толкова високо място като риск е фактът, че се out, както се казва, има доста остарели компоненти, доста остарели браузъри и системи, които ги използват. А аз вярвам, че нали с времето ние минаваме към все по-сигурни компоненти. А повечето браузърисват вече HTPS, нали, предупреждават средния потребител, че нещо не е окей, нещо не е сигурно, което рано или късно ни ще доведе от това този риск да падне доста значително надолу, поради простата причина, че криптографика така или иначе е бедната всичко, което използваме и правим. Сега

8:07↗аа преведницата е доста лесна на думи, понякога е доста комплексна. А всичко, което е сензитивно, трябва да бъде кредитирано навсякъде. Това е заключението на правента. А нали съхраняването на сензитивна информация на компютъра и вече на разработчици, девелопъри, девелопсита на инфраструктурни хора трябва да бъде винаги навсякъде кредитирано. Не е за съжаление а все още правилно навсякъде. Аз съм работил доста компании, съм виждал доста неща и за съжаление се случва все още да имаме стари данни, които са достойни и не са криптирани по правилния начин. Разбира се, използването на legacy протоколи и шифри трябва да бъде елиминирано, изведено до минимум. И това се случва много просто, като постоянно си сканираме абсолютно всичко, което използваме за неща, които са старели. Аа петият риск е инжекtion. Той комбинира в себе си всякаква форма на инжектиране на код или а инструкции от

9:06↗зломерена от зломерено място в нашите софтуерни компоненти или програми. А какъв най-м познати нис или crosssite scripting, а който просто представлява инжектиране на JavaScript код. Той може да е по най-различни методи, както може би някои от вас знаят, може да е blind, може да е директно в reflection и така нататък. SQL injection, той беше изключително популярен в миналото. Аа вече е по-малко. Причината е много проста. А особено тези от вас, които споделиха, че се занимават с девелопмънт, най-вероятно знаят, че ние използваме много повече библиотеки за комуникация с базите днешно време. Ние използваме директни, нали, simple quта и повечето от тези библиотеки имат доста добро санитизиране или почистване нари, така наречените ORM, което ни позволява, нали, да сме доста по-сейни. Тоест много от сотъра, който правим днешното време, благодарение на това, че годините нали

10:02↗се учим от грешките си като а специалисти и девелопъри ни позволява да минимизираме риска от всички тия неща, което е страхотно конкретно иш, защото аз си спомням преди около близо 20 години беше топ Wild West почти навсякъде, където се пробваш да направиш някакъв инкш минаваше. Да, >> извинявай, не искам да те прекъсвам, обаче наблюденията ми благодарение на изкуствения интелект е, че все повече и повече SQ и инжекъ се връща. >> Абсолютно, абсолютно мога да съм съгласен с теб, само че аз бих го префразил по следния начин. Prompt и injection. А и причината е много проста. Prompt иjectionш а нали причината това за това да е толкова на високо място икшън като риск. А тоест нещо спада SQL, обаче нещо друго се качва. А поради поради факта, че сега с повече софтър започваме да комуникираме с текст или по друг начин с някакъв вид протиting с AI агенти или NCP протоколи,

11:03↗а това ни дава възможността да експериментираме страшно, ама ние можем също да си направим един агент, който да комуникира с от срещния агент, който се опитва да го инжектира. И това е доста страшно поради простата причина, че скрива възможност за много пермутации, които не са възможни в стандартния софтуер, нали, ако стандартния софтур има едно поле аа което ние можем да експлоатираме, то не е до безкрайно, докато когато е някакъв промт, ние сме ограничени в контекста на тоя пронт, но тоя промт се изпълнява някъде в cloud някаква среда, нали, има шанс да стигнем да да джелбрейкнем, така да се каже, защита на тоя пронт и да стигнем до нещо. И това е причината, нали, този риск да остава на такава висока позиция и според мен, нали, е възможно дори да се качи нагоре, а в бъдеще поради простата причина, че нали с фронт инженеринг можем да стигнем много далече. А превенцията е проста, само че

11:58↗не е и в AI средите, аа в AI средите единствено нещо, което ни помага да сме долу-горе добре. АAD е това да тестваме самите промтове с подобен тип ферментации и инжекшни и да мониторираме самите протове за такъв тип поведение. Разбира се, това помага и за друг тип инжекшъни, за crosside scripting, за remote code execution ad и така нататък. А реално трябва да се стараем в това, а когато става въпрос за потребителски инпут, ако разработваме каквото и да е, да мислим, че винаги той може да е малишест, без значение дали той идва от а frontндend, мива през някакъв тип backend, тоест идва от място, което ние познаваме, идва от някой интегратор, който ние сме се интегрирали и така нататък. поради простата причина, че това нали е в основата на този златен принцип в киберсигурността Zero Trust или астche. Тоест ние мислим с концепта, че всеки един entry point, data point,

13:02↗който влиза в нашия софтуер и комуникира с нещо, без значение откъде идва, той може да е малишеств, той може да е нали написан по начин, по който да се опитва да инжектира код, quщо друго. На шестото място имаме несигурен дизайн. А причината при а причината поради която на толкова високо място а и това до което той довежда е обикновено експлоатиране на бизнес логиката на приложенията. Предполагам, че сте чували или виждали в миналото всъщност а пример за movт мисля, че е нябно е експлоатиране на бизнес логиката на това приложение, което ни позволява да браузме файлове на други потребители. То е нещо като файл менеджър. Аккурдизай е доста абстрактно нещо и означава, че нещо софтуер а или нещо, което сме дизайн като някакъв компонент, има по дефиниция в себе си а дефицити по отношение на сигурността, тоест в бизнес логиката, в логиката на това приложение,

14:02↗начина, по който потребителят ще го използва, нали, това може да включва някаква форма на инжекtion, може да включва и а неща, които не не би трябвало да са позволени на този потребител, но те не са позволени и те се разбира се разрешават най-рано в а цикъла на девелопване в софтуер девелопване на life cycle. Още когато седим и планираме какво точно ще правим, ние трябва да мислим като злонамерения на трета. Проблемът е, че нали звучи малко скучно и на някои девелопъри не им е интересно, нали. Те искат да пишат код, те са девелопъри, те не са разказвачи на история. А, но е възможно най-ефективния метод за за фиксване на проблеми по-късно. А колегите, които работят тестери, ще ви кажат колко скъпа е тази услуга и още повече колко скъпо е, ако се намери а фундаментален проблем в софтуера, който трябва да означава пренаписване на огромни компоненти или използване на нещо по-скъпо. Колко

14:58↗по-скъпло би могло, колко по-лесно би могло това се решава още в началото на дизайнването на софтуера. Има обаче един друг проблем. Ние да речем, а ако се върнем във времето назад, тръгваме да дизайн някаква софтуер, но с промяната на технологиите, което е неизбежно. Ние не живеем в такъв свят, софтуерът е там, за да се променя. Вече решенията, които сме взели по времето на дизайн фазата на този софтуер, те не са толкова валидни или или комплекс комплексто на компоненти, които използваме предразполага securюity и по принцип е така continuous процес продължителен. Не е нещо, което просто правим веднъж, нали, дизайн нещо секре и го забравяме. Просто не е вече на проблем. Той е, тъй като тези от вас, които знаят, а в модерния софтър девелопмент има така наречената ja методалогии, които не се разработва всичко още в самото начало имен правим някои роджения и това е край. Няма

15:54↗повече да го дизайнваме, а правим и го делираме. А в днешното време тези доста го знаят, има двуседмични цикли, по-дълги или по-кратки цикли, които се разработват, фичъри или бъгове се разрешават в софтуера. Редно е по време на тези цикли да се прави и някаква форма на secюрити, нали, assessment, треad моделинг, просто да се мисли като атакуващ от тези моменти поради простата причина, че каквото и да правите, каквото и да пишете, някой по него ще мисли като атакуваш, по-добре да сте вие. А най-добрият начин за разрешаване и за минимизиране на нищо от тия неща не може да се елиминира, поне това трябва да сме сигурни, но може да се минимизира, да се управлява рискът от тях. А най-лесният начин справят. Това е така нареченият трет моделинг, който няма нищо общо схо и нали моделинг нафлек, а представлява една среща, де така да го кажем, която се събират девелобъри, може би секюрити хора. Има

16:45↗най-различни имплементации поласт има една програма, която се казва аз не мога да проинеса дискуссия тука Корникопо или нещо подобно. Тя е кар кар, една игра на карти, която може да си придитирате, може да си поръчате и тя представлява роли и потенциално неща, които биха могли да се случат. Например, аз съм злонамерен вътрешен потребител на административното приложение, какво мога да направя и примерно мога да го изтрия, да го счупя и така нататък. и почват да си мислят обратно стана до аз какво мога да го предотвратя това нещо и реално така се раждат идеите и секюрити контролите, които могат да превентнат евентуално такъв тип нали проблем и атака. На следно място имаме authentication проблеми. А autentication проблемите основно аа позволяват нали автоматизирани атаки в миналото бяха какво да кажа популярни. Сега са понамаляли. а така наречения брудфорс а

17:41↗той позволява има и много разновидности на брудфорсинг разбира се пастор спрен и така нататък и така ната а за щастие модерната инфраструктура на използвам модерни компоненти компоненти и така нататък ни позволява да лесно да въвеждаме различни рейдлимити и а контроли които могат да спрат подобен тип атаки и поне да ги минимизират ноли а технологията се адаптира атакуващите се адаптират игра фотка и нещо. Хубаво е, защото ние ще имаме работа много дълго време. Лошо е, защото ние трябва постоянно да си обновяваме, нали, компоненти, да мислим една стъпка напред и да си ги тестваме. Разбира се, а много често се случва, нали, в практиката, поне аз съм бил свидетел, е използването на autentтикеation имплементации по несигурен начин. А поради простата причина, че особено в места, където нали ние трябва да използваме доста така силни модерни подходи, ако се остави на

18:39↗developм екипите сами да изобретят някаква форма наorization и autentication, много често се случва, понеже те не мислят а като атакуващи, много често се случва те допускат някакви неволни грешки понякога. И поради тази причина, а може би лично за мен една от най-често среща а методи на превенция е първо да използваме неща, които са стандарт, нали, да не си измисляме протоколи за аутентикация, да не си измисляме нали някакви наши имплементации, нали тука тука ако използваме нещо, което вече е измислено и то е софтуерен компонент, ние махаме или минимизираме риска отation и въвеждаме риска от supply chain failer, нали, всичко е управление на някакви неща, нали, трябва да го тестваме и това нещо. А, но много е важно, нали, да си изтестваме, ако имаме приложение, нещо, което се аутентикира, да го изтестваме, нали, с кому пароли, с кому проблеми и така нататък и така на

19:33↗просто, защото ако ние не го направим, някой друг ще го направи, нали? Не трябва да се заблуждаваме с това. А много важно е също така чисто оперативна гледна точка, нали, когато направим едно приложение да поемем, но вече хората се аутентикират, идентифицират с него, логоват се, така да се каже, а ние непрестанно да мониторираме. Има ли примерно потребител, който прави неочакван брой заявки? Сега аа някой нали потребител от, да речем си Битли изведнъж се е опитал да се логне 10 000 пъти от Хондорас. Няма нали логика в такъв тип поведение. редно да контрираме за такъв тип а активити или дейност и да действаме, нали, да блокираме трафика. В най-големия случай не трябва да го правим, нали, ръчно в красно, както обичам да се изразявам, трябва да го правим изключително автоматизирано, нали. Това трябва да е посоката, в която работим, защото от следната страна го

20:21↗прави автоматизирано и ние не можем да смогнем, ако си играем на котка и мишкаме и добавяме фару или нещо подобно. Не трябва да мислим в посока автоматизация. А на осмо място имаме а интегрити проблеми. Те са софтуерни а или дета и интегри проблеми. Какво представлява интегритетът на софтуера? Когато сваляме някакъв компонент отнякъде, да речем, ако имаме уеб приложение, в него много често, нали, ние не създаваме а цялата графика на приложението от нулата. Ние най-вероятно използваме някаква тип библиотека за самия интерфейс. А всеки сайт, който отваряте, той ползва някакви тип библиотеки, React, View JS, нещо ползва нещо, нали? Никой девелопър нещо време да пише прозорчетата или буквичките от нулата. Просто е загуба на време. И когато използваме такъв тип софтуер, аа много често го използваме от някакви несигурни места, нали. И тука засягва малко и счейн а рисковете, обаче

21:23↗аа използвайки по някакви несигурни места, ние бихме могли да сложим чек сума или хш, който е нали криптографиic хш на компонент, който използваме, с който ние верифицираме тоя компонент. А как се случва това? А когато си инсталираме някакво приложение, то дърпа някакви други неща в някакви сървъри. И ако девелопърите на това приложение, вие ако го девелопърите на това приложение вкарвате логика за проверка на интегритета на тези backндend места, нали може да се случи инцидент, може някой да инжектира нещо по пътя. По принцип това се решава много просто с интегриране на проверка откъде идват компоненти, които инсталираме, нали? Мисля, че колегите малко по-рано казаха, а още в началото да ако позволяваме на определени колеги в организацията да инсталират компоненти от знаени и незнаени репозитори, то рано или късно не може да осъмне с някакъв малъ. Трябва много

22:23↗внимателно да тестваме, дафицираме откъде идват компоненти, които използваме. идват някакви транзитивни репозитори и без нали адекватна проверка. А девето място, предпоследно с малко ще ви помоча, а на на двето и на трето място като цяло стават оперативни оперативни рискове в софтърните разработки по принцип. А ако ние разработваме нещо, без значение какво е то, дали е уебсайт, приложение, мобилно, инфраструктура, а, каквото и да е, и не го мониторираме, някой рано или късно нали започва да го тества. Това е неизбежно, нали? Представете си в момента, в който ако вдигнете една виртуална машина, направете си този тест, а ако искате вдигнете една виртуална машина, сложете потребители парола adдми adminн и я поставете в интернет, нали, в някакъв контейнер на някъде да не ви е лаптопа или домашния сървър и засечете в колко до колко минути, то аз сигурен, че са

23:22↗минути, няма да са часове, а тя може и секунди, зависи къде къде тя ще бъде компроментирана. Тоест всичко, което е публично и не само, рано или късно ще бъде тествано от злонамерени хора. Просто така работи интернет, нали? А чисто протинистично целият свят сканира целия свят. Даже мисля, че имаше статистика, а по-голям от 50% от трафика в интернет е ботнет мрежи, ботове, сканирания, нали, nonнхhuman trрафиic. Аа и това просто трябва да нали нас малко така стресне, че интернет не е толкова супер сейф място. Нали, ако изложите нещо, което е несигурно, рано или късно то ще бъде компроментирано и превзето. И поради тази причина, нали, ние трябва да се съотчим това да мониторираме мрежата вътрешно, външно, нали, вътрешно поради проста причина, че не знаем, нали, някой да не е плътно някоя USB флашка, нещо в мрежа ни, някой колега може да е компрометиран, нали. А

24:20↗на аз като говоря за сигурността на една организация много често се случва според това случва се някой служител да кликне на нещо, което не трябва да кликне, да свали нещо, да се отива на нещо. Аз не монтурирам за това нещо, поради факт, че нали ние хората сме най-слата връзка в киберсигурността, рано или късно това би довело на някой сериозен инцидент, а и не просто се мониторира, нали, влоговете да отиват на някакво място и да ги гледаме чак когато стане инцидент. трябва да имаме изградена система за алармиране, а която ни казва, че нещо нередно се случва. И тази система за алармиране и блокване на информацията трябва постоянно да се обновява. Не знам дали аа вече предполагам, че повечето от вас, които се вземат скис в най-добра линия разбират, че това е продължителен процес. Просто не ние нещо сканираме и то е point in time то може да е окей, може да не е окей, нали, зависи какво

25:10↗сме получили като резултати или правим одит на логовете и алармите, които събираме или колегата, както порано каза, на метрите, които събираме, нали, дали те са адекватни или какво мониторираме реално, но това е само за този point in time. Утре се появява нова технология. Утре се появява нов метод на мая. Утре се появява проявява нов метод на икшъ на AI компоненти на браузъра и на браузъра и на браузъра. Ние трябва да ъпдейтваме целия този обстак и подход дали е правилен. Не е много нали лесна работа, трудоемка работа е, но реално трябва да сме една стъпка пред також. А другото, което е много важно, което колегата Стоянко беше сподели, е да не създаваме прекалено много аларми игове, нали? Не всичко а е пожар. Трябва да гледаме нещата, които са а наистина смислени поради простата причина, че ако ние се заре зарием с изключително много аларми и шум, така да се каже, noйс

26:07↗алър, ще създадем така наречения алъртвати, както имали, тоест ние ще се преуморим от нотификации и няма да видим нещо, което е наистина смислено. Затова е много важно от време на време да се прави анализ на логовете, смислени ли са, не са ли смислени и разбира се всичко поне почти кирствеността трябва да бъде тествано и самите а респонси на тези тип лъгови инциденти. Ние трябва да направим един bridge simulation, да се пробваме да инсталираме ма там, където не очакваме, да видим дали нашия монитори, нашите са адекватни или не са. И на последно място аа неуправлението на еспtion. Поради простата причина, че сотърните компоненти стават все по-комплексни и епшъте са все по-вероятни, а би трябвало ние нали да направим един такъв trй catch all на почти всичко, което използваме. Това включва не само с общините компоненти, това включва всякакъв тип инфраструктура, която ние използваме.

27:08↗А това, което се опитваме тук да постигнем, е да хванем неочакваното поведение на софтуера, на хардуера, на AI-я в настоящата вече не е бъдеще, а и да се опитаме да разберем точно какво се случва. Превенцията не е лесна, защото ние се опитваме да хванем всичко, което не е нормално. А, но превенцията се състои в това отново да логваме и да мониторираме всичко необичайно. Модерните системи за secюрити event мениджм CM системи, PDR, нали, има страшно много а маркетинг генерирани термини за secюрити мониторинг и логинг системи, които в днешно време използваме. Все тая какво използвате. Идеята е, че много често те от тях ни предоставят възможността за така наречения anomaly detection. Нещо държи ли се по начин, който ние не очакваме извън бейслайна на трафик. А в миналото това се случваше с Big F5 а системи например межвия трафик. Започваме да монитрираме стандартния

28:15↗трафик и си казваме това е what good looks like. Така изглежда трафикът между приложенията ни и включваме този basйн да мониторираме трафика след това. Все обаче това все по-трудно става поради простата причина, че е много по-комплексно, поради простата причина, че всички тези инпути на приложенията, нали, модални диалози, които използваме, уеб прилежения и така нататък, са много по-комплексни. Имат слоеве на комплексност, особено по отношение, нали, на изкуствения интелект. Там, както вече го обсъдихме, промамта може да представлява най-различни неща и поради факта, че в промта може да има най-различни неща, нали, ние вече не сме ограничени в това да монтуриме само трафика. трябва да мониторираме абсолютно всичко. А просто трябва да мислим с подход, който да мониторираме всякакъв вид интеракция с нашите а приложения, инфраструктура и така нататък, да го логваме и армираме

29:03↗на него, нали, на така наречения anomaly base deкъ. Аа това е нали моя анализ, мое общение. Аз бих обобщил нещата, че аа нали те са основно заложени в два екипа, две направления, нали, от една страна developм екипите, от друга страна operation скипите или така наречената имплементация DSOs. Много от тях а биха могли да се оправят още по времето на девелопването на приложението или софтуера, но много от тях зависят след това в оперирането, връвването или търкането на нещата, които след това създаваме. А една графика, която аз много обичам да използвам в такъв тип презентации, е колко струва да фикснем едно нещо. Ако започвам още в дизайн фазата и то обикновено, както ви казах, е доста скучен процес, поради простата причина, че ние все още нищо не сме направили и се представяме, че го чупим, нали, малко е по-трудно чисто ментално да го направим, но цената да го фикснем още

30:01↗тогава, тоест още тогава да си кажем ами добре, нека да заложим на адекватните логове, нали, правилната криптография, на това най-актуалния, нали, криптографиic сайт ли е, който можем да използваме. Това най-сигурният метод ли е? Имаме метриките, има Можем да го монтирираме тоя софтуер, можем да монтирираме тея компоненти. Ако този разговор го направим още в дизайна, нали, в исепшъ на нашето приложение или инфраструктура или каквото там правим, по-късно като започнем да го правим, нали, представете си това е да строите къща и да осъзнаете, че основите не сте ги направили в подходяща почва, твърда почва и не сте направили на а хидроизолация на основите и после след като къщата е построена, осъзнавам, че тя потъва или долу ви е наводнено, нали, не е окей. А абсолютно също важи и за собствената разработка и аз обичам просто да говоря с това поради простата причина, че ако

30:49↗открием уязвимост, която е в приложение, което е продукционно и не дай си боже то вече е експлоатирано, както е примерно movт примерът, това струва много повече на организацията, на нас, на всички потребители като обобщение. А повечето от рискове те могат да се идентифицират и разрешат още в дизайн девелопмънт фазите. А колкото по-рано го така приложим а като подход, толкова по-лесно се случва. Разбира се, това не е технологичен процес в случай. Това е процес на анализ, на правен избор нали подготовка. Аа по-късно много по аа трудно се разрешава подобен тип проблеми, но е много важно абсолютно всичко да се мониторира и логове. Просто е изключително важно поради простата причина, че аз съм бил в организации, където става някакъв инцидент. Той е станал и започнал преди месеци и ние сега започваме да разпитаме нишка какво точно се е случило. Обаче нямаме цялата

31:48↗картинка, нямаме логовете, нямаме трейса и можем само да гадаем, нали? Няма няма следа. А разбира се при използване на софта човешката грешка е най-често срещаният фактор, нали това не трябва да се лъжем и екипите трябва заедно да работят за разрешаване поради проста причина, че това е обще проблем, нали, не е само на девелопмънт или на OS или на Develops или на някой екип. Това е проблем на цялата компания, на цялата организация и на това най-общи най-общи линии още в дизайна, ако започнем с а стъпки, просто ще ни бъде много по-лесно после да не сменяваме компоненти, криптография, нали? Да. да похарчваме още девелопънт и а време на компанията в поправяне на някакви неща, които са доста тривиално и доста лесно могат да се разрешат. Сега аз тука доста претърчах през съдържанието и не можах да ви покажа конкретни примери. Аа в началото на следващата година ще направим малко поep

32:44↗потехнил на топ 10. А, нали сер човек ви каза с такива код, ако искате не го правите. Def.bg там има група за събития. Може да се събскрайбнете. Има сайди събития, между другото, които са доста интересни. А, нали, заповядайте. Ще се радвам да се видим отново. А вие сами може да прочетете и анализирате данните. Това е хубавото на такъв тип организация. Те са Open source. Абсолютно прозрачно е всичко. дори процеса на събиране на данните и писане на всеки един от тия файлинги, което е страхотно. Искам да ви първо благодаря, че си отделите толкова много време, че останахте от толкова късно, нали, супер много го оценявам и се радвам да вие толкова много младни хора. Благодаря на предишните лектори. Просто аз съм много доволен, понеже съм на тоя сектор от 2004 година и нивото се качва и качва и качва и качва и е супер хубаво. Да, да, да. Нали, да виждам толкова добри

33:42↗специалисти да говорят на толкова приятен, разбираем език, да споделят това, което знаят, защото това е много ценно. Аа като започнете, ако не работите вече в сектор, ще разберете колко е ценно. Просто изпестява страшно много работа и анализ. И оставям аа нали полепи за за въпрос. Ще се радвам да ви отговоря. Там имаме вода, кола, нали, тука сме доста още доста времени. Свободни сме за въпроси и разговори Discord, нали. Навсякъде може да намерите LinkedIn, но ако имате въпроси сега да ви отговорим. и да затворим днешния ден, че сигурно някои от вас платират на протеста. Има ли въпроси? Не. Нито един. А един. Прави. >> Относно Извинява извинявам се. Относно мониторирането и на логовете. Предполагам в практиката си срещал често опити за фейкло обви, които така да се натрупят като много обви, които да ни заблудят, да не се съсредоточим в основната. Това е много интересен въпрос, аз го

34:44↗ориентирам. А идеята на колегата е случвало ли се много да се генерират, за да се създаде шум, така да се каже, от който ние се опитваме да търсим, нали, и главкопаснал и да не успяваме. А, разбира се, да. Това е нали методология на атака, която аа е по-присъща на така по-опитни атакуващи. Ние в сектора ги нали не е тайна да ги наричаме advanced persist. Идеята на подобен тип трет актори и организации, те обикновено са доста така добре организирани, по-големи сигурно от територията, която сме се събрали. Тука са държавно спонсорирани и така нататък. А концепцията там е следната. Те се опитват да опитват да проникнат някъде, но да стоят максимално дълго време, защото не се знае в бъдеще примерно как ще се развие организацията, какво ще какво ще се случи и така нататък. Има много примери, които са публични, има примери, които не са публични, никога няма да разберем и така

35:40↗нататък на такъв тип атаки. А естествено, че се случва поради простата причина, че то си е някаква форма на на инвестиция на малко време, особено примерно аз съм работил доста организации, съм виждал логовете и CM-ите на доста места, те не се мониторират по най-добрия начин, нали? Ако още повече познаваш какво се мониторира отсреща, много лесно може да го задоволиш. Ако не го познаваш, да можеш да препълниш, както се казва, логовете буфера с информация. има най-различни типове подходи, а към всякакъв тип системи, нали, които могат да се генерират толкова много аларми, толкова много шум, че екипът отсреща въобще да не забележи, да не разбере какво се случва. И точно заради това, а според мен най-ефективният подход е ние сами, нали има със сигурността има концепции за BL, purple, red team и така нататък, ние сами или да им компания, ако няма възможност вътре в

36:34↗организацията да си създадем ред тим, която да ни направи подобен тип атака, за да видим нали нашият мониторинг дали е ефективен, дали има правилните логове, правилните аларми, могат ли да ни нали за задушат, така да се каже, и ние да не разберем какво се случва поради проста причина, че всичко ни свети в червено и какво гледаме, нали не знаем. Аа сурфло се естествено, че се е сурфло. Да, това си е стандартен подход. А това това бих го приличил на den сървис на secюрити мониторин на съвсем нормален подход. >> Благодаря. Благодаря за хубави въпроси. Има ли още въпроси? Да. >> Само един кратък коментар, за да няма дезинформация. А сподели, че плантам не е много на дневен ред. Сега ете няма да има нещо спешен порядък, но а до 2030 година абсолютно всички системи на всички банки, държавни организации, болници, а енергийни дружества, а обществени, комунални. Каквото се сетите, което пада

37:42↗критикал икчер, поне 10 различни огромни сектори на съвременната икономика трябва да преначат цялата си криптография в Европейския съюз, защото по одобрените стандарти и алгоритми трябва да се замине абсолютно пълно пренаписване на критографията по стандарта, който е публикуван. Това от юни тази година е обявено като взето решение. Така че на принципа на свидетелите на Ехова може от 1 януари да чукнете на врадата на стилоото и да кажете здравейте, имате ли минута време да поговорим за >> квантом карто >> нашия нашето божество квантум компютъра? Да. >> Благодаря за >> Дори и да е някъде в облаците и да не е ясно какво е това дружество, ние ще трябва да го посрещнем доста скоро. >> Благодаря зането, до-р християнскалов. Сега моят коментар защо беше такъв? Аа първо да факт е, че Европейският съюз и не само пушва критичните организации. Има страшно много регулация, няма да

38:44↗отпечавам. А пушва ги да са една идея по подготвени. Позитивното нещо е, че те няма да пренаписват, а просто ще използват готови кланм, ready аа криптографи, алгоритми, които са стабилни и работят. Естествено са, нали, всичко е точно. Моята оценка е, че не е проблем все още и скоро няма да бъде проблем поради простата причина, че нали квантом компютинг хардуерът е доста скъп и обикновено в момента той е затворен за няколко правителствени или големи корпорации, които могат да си го позволят. Те реално волят ресърча в света по тая тема. Тоест не е нещо, което можем да си купим а врс.bg БГ или някъде да бъде това, а и няма да бъде скоро достъпен за обикновения, нали гражданин като нас или трета акция зномерените хакери. В някакъв момент след десетилетие две може би ще бъде достъпен, но поради факта, че ние изборихме тука 10 топ риска и тия топ рискове, особено in secure design,

39:43↗счупене автентификация, стари шифри са все още на дневен ред. В смисъл те все още се експлоатират. За мен квантови критографи проблемите са малко по-бъд поради простаточе, че ние все още виждаме нали текст протоколи за каква клан криптография говоря. Хубавото е, че нали имаме вече технологията да се защитим. А хубавото е, че няма да бъде пренаписвана, просто ще бъде преизползвана, нали? Но тука отново попадаме в друг риск. SUI chain проблеми. Някой може да попне някой криптографи пакет и дали инжектира нещо. Stay V, както се казва в сектора. Благодаря за въпроса. Има ли още въпроси? Да. А, гледа, аз имам само нещо да добавя. Да. >> Аа, първо да кажа, че аз съм абсолютно наясно с техническия ти бекграунд и няма да те изненадам с нищо, но може би за аудиторията ще е интересно, тъй като и двамата с тебе имаме достатъчно опит в критограф критографията. А по принцип действително

40:50↗напълно съм съгласен с тебе, че крайният потребител и дори много организации няма да могат да си позволят това компютинг много дълго време и наистина няма за какво да се притесняваме, но реалността е съвсем друга. Това може да се съди по космени показатели. А например, тъй като в нашата академия подготвяме кадри, имаме партньорство и на IBM, които ги взимат по многочни позиции към Европейски съюз и към отранителния сектор на НАТО. >> А от поне две години спряхат позициите. Всичко е само офсайт, защото действително явно в някъде зад гада аа има организации международни или а на определени държави, които са страшно напред с това с тая технология. А и тъй като А да, обаче факт е, че масовият потребител, масовите компании, масовите сървъри, те са оперативно безиинтересни за такъв тип, а, така да кажа сторници, ако нарека така. Но наистина наистина проблемът колкото е далече,

42:09↗толкова е и близо. И може да обърнем внимание на последния опрене с каз десятката. който всъщност почна да включва клан квантовоустойчиви а >> алгоритми алгоритми ама те са кексове, защото са комбинация от алгоритми, които може колегите като се приберат да им обърнат малко внимание. Така че много е интересна темата и може би в някои от бъдещите издания ще ще направим много по-интерес, ще обърнем повече внимание. Със си попъ много интересна тема. Моята друга теория е при комуникацията на клавен сървър. А ние имаме така едно известно забавяне заради на мрежа и какво ли още не е. И това да се прихване нали текущия трафик, нали текущата сесия, когато има текущи сешънки, не говоря за SH нещо за говоря за стандартния, е изключително трудно във времето да се прихвав това да се декритира някъде в квантов компютър днес или следващите десетилетия. Но това, което се случва е много

43:11↗злонамерни организации и правителства на детства общет дали събират вече а дета адреса, която е криптирана с по-стари алгоритми и в някакъв период след 5, 10, 15, 20 години това ще бъде много лесно четимо, нали. Това е, което мен ме притеснява, но с текущия ни трафик, нали, текущата ни комуникация много трудно според мен би могло да бъде комплементирана. >> Имам нещо още да добавя. >> Да. А, напълно съм съгласен с теб. И другото, което е, трябва да се аа трябва да се притесняваме много повече за точно такива мис конфигурейшъни втографията на всеки а средностатистически сървър. Хм. >> Аз ще аз направих едно изследване с един мой колега, с който се занимавахме с киберсигурност и криптография по-рано. Аа при който правехме аа голям брой заявки. хендшейк заявки за TLS сесии към сървъра. Това е всеки един публичен сървър. Това даже няма да ви го отрази нито един лог. А при което при

44:17↗наводняване на сървъра със заявки, това което правихме аа рандъма, който сървърът генерира от следната страна, защото винаги рандъм се дава на сървъра, да, тоест сървърът го дава, защото по принцип по подразбиране клиентът винаги е компроментиран. И ние следяхме тоя рандъм в кой момент ентропията ще падне на сървъра. Тоест, сочвахме ентропията до момента, в който а падне цялата ентропия на сървъра и тогава всеки следващ токън, който се генерира в комуникацията с клиент, става кредит, нали? И това го направихме в изследване и и буквално с една видеокарта, а не Nvidia, по-добра геймърска, горе-долу за половин час падаха токъните на потребители в потребителските сесии. го направихме в когато го представихме на една международна конференция аа за сигурност и хай компюнг няколко човека излезнаха от залата да проверят дали са си направили добре конфигурацията на сървърите, защото

45:19↗имаха въгласения, а ние направихме демонстрацията общо взето с изследването горе-долу в рамките на половин час, което ни беше дадено като време. Така че наистина по-добре се притесняваме за сегашните недобре конфигурирани машини, >> има много такива, >> да е. >> Благодаря. Благодаря. Не, >> само да споделя, че а Китай пуснаха първия чип с квантум 100% в квантум. Аа може, тоест да могат с кбит и не знам колко на брой към 100 на брой или нещо подобно да правят си изчисления и са и е днеш сорта на $16 000 или $000. >> О, >> то е да хан ханин хани е ако готе можете. >> Значи наближава >> ами доста наближава да >> сновете. Значи 10 години добре сменявам пет. Хубаво. Благодаря. И аз благодаря. Браво. >> Благодаря.

46:27↗Ами запичка во годичка да си поговорим твоите желание и отново благодаря ви заеснахте.

46:49↗Изолираха се толкова, толкова държат на киберността, че сами се изолираха режи. Не >> знам.