OWASP Sofia December 2025 Meetup (part 2)

3:34↗става все по-трудно и по-трудно да и близко дори до невъзможно по стандартния начин, който много често ние, по който ние много често се учим. Това е задължително ние да го знаем като фундамент, но в играта с критична инфраструктура и големи предприятия там вече нещата са малко нест левъл и това не работи. И поради тая причина хакерите се си изместват фокуса все повече и повече а към именно soft chain security, тоест така да се каже. А предавам щафетата на моя колега, който ще довърши. Искаш ли да сме? Айде. >> Айде. Благодаря. [аплодисменти] >> Добре. Чуваме ли се? Добре. Да. Така. Сега в случая аз ще влезна малко в по-техническа техническата част от гледната точка на софтуер, разработване на софтуер, назряване и така нататък. В случая аа свързано със supply chain а много е важно да разберем как може да открием а дали ние сме уязвими към такъв вид атака.

4:42↗А това са едни от основните а начини, по които може да да разберем дали сме уязвими спрямо. Като част от тях са следните. Първоначално, когато внедряваме софтуер или разработваме такъв, а много често се случва, че не виждаме всички версии на целия софтуер, както и на компонентите, които използва, дали те са уязвими. Какво имам предвид, когато използваме а библиотеки или най-различни софтуери, които те а всъщност използват зад кулисите други библиотеки или други компоненти на софтуер, те използват версии, които ние много често не виждаме. Това се нарича transitive dependencies. Когато нещо се случи, а много често може да използват библиотеки и софтуер, който да е с открита уязвимост, което даже е публичен, много лесно може да се експлоатира, но ние не го виждаме много често това нещо. Също така, ако използваме софтуер, който вече а е към End of Life, демек не се поддържа, няма

5:43↗нови ъпдейти. А други начини да го намерим е когато имаме а липса на мениджмънт на промени. В случая, когато разработваме софтуер, да кажем. А ако в случая не нямаме разработена мениджмънт система, в която записваме всичките чейнджове, така наречения change или не четем, не се събскрайбваме по такива чейнджлогове на компоненти, които не които използваме в нашия софтуер, може да а да останат тези уязвимости недетектнати от нас в компанията. Също така много интересен пример е Accessive Permissions, в където DevOps, софтуер програмисти, интегратори и така нататък тези позиции имат повече права, отколкото трябва и могат да изтеглят софтуер или компоненти или много често библиотеки от а а unreliable източници, които а в случая може да са да имат компроментиран код вътре в тях, когато ги изтегляме. Също също така а не е окей да може един човек да има повече права като

6:59↗авторизация в като пример нали мога да дам един софтуер девелопър в компанията не е окей да пише един софтуер едно парче код и да може сам да си го засили до продукционна среда без да има нито един човек който да трябва задължително да го провери или да го погледне или да знае въобще това нещо е стигнало до продукционна среда. Delay patching е също нещо, което много доста за жалост компании го правят. Вместо нали да има непрекъснат процес, в който нали се проверяват а уязвимостите на софтуера и на кода, който който може да разработвате, вместо нон-стоп да се проверяват тези неща, уязвимости и да се интегрира или да се пачват версиите спрямо риск, аа много компании решават, че това ще го правят на месец или на тримесечие и в този случай, когато се интервюс на някаква уязвимност, може следващите три месеца тя да си е напълно отворена и да е готова за експлоатация. и никой да не

7:57↗знае и да се чака следващия пач сайкъл, така наречения, за да се направи това нещо. Също така, ако не се тества редовно за такива уязвимости, не се сканира редовно за такива уязвимости, визирам в случая CCD пайплайнове и както и така ми с конфигурации и въобще CCD pipeline да е по-незащитен, отколкото другата част на софтуера, защото за много организации пайплайн е нещо, което е то е нали не е чак не трябва да е толкова защитен. Тя е изолирана среда, но не е не е така. Мога да дам много добър пример за това как може да се открие уязвимостите и в случая за BL SPS мога да дам за тези transitive depend for shell нещо което може би много от вас са чували и знаят е уязвимост на W for J библиотеката която а за тези от вас които не знаят W for J е библиотека в Java разработването помага за логване за най-различни Java библиотеки или а API йове, които се пишат. Много често в

9:05↗компаниите W for Shell не се ползва директно, ами много публични библиотеки я използват транзитивно. И в случая, когато вие вземете някоя библиотека, да кажем, примерно е снб тази, а тази библиотека вие не виждате, че използвате реално, но тя е вътре в кода по този транзитив индиректен начин и се разкрива, че в една от версиите има Zeroay, който в случая е Remote Code Execution. А при което а да кажем сега да ви дам вас като пример. Разработвате една Java апликация. В случая решавате да използвате дадена версия примерно в Sprintboot и вие имате тази уязвимост вътре и дори не знаете. Вие нямате никаква представа за това нещо. Аз сканирам, проверявам, че реално вашият код има тази уязвимост вътре и използвам да вкарам код, който е зловреден в най-различни форми във вашия сайт, които може да са логин, може да са а user agent и така нататък, най-различни

10:09↗места. Вкарвам най-обикновен стринг, не е най-обикновен, може да се види в какъв формат е. А, вкарвам този стринг, вкарвам за увередния код и общо взето правя remote cд execution и вие нямате никаква представа защо и как се е случило това нещо и в случая се разбира, че е заради тази уязвимост, която вие дори не знаехте, че ползвате тази библиотека. Този случай W for show, който е доста известен, е причината с бом да се създаде, което е софt би materials. Това е нещото, което след тази атака се задължава от enterprise компаниите да имат централизиран звон. Сега това как да видим, да забележим дали ние сме а уязними към този вид атака. Сега как според Оласт ние може да се защитим в тези казуси? Някои от аа начините, по които може да се защитим, са централизиран фон, както вече го обясних. Това е едно място, на което имаме целия софтуер, както библиотеки,

11:10↗версии и така нататък, които може да следим и да използваме за всеки нов софтуер, който използваме. Например, ако разработваме API-ве, всеки нов API може да използва този централизиран слон и ще е на версиите на библиотеките, които и са останалите API. Аа проследяване на по-ниско ниво а на библиотеките е друг начин на защита, което вече обяснихме по същия начин е проверяването на тези транзитив библиотеки. Дали случайно няма библиотека, която е на версия, която за нас не е окей. да намалим атак сервиса в случая тука много често означава при например дори не е в софтуер разработването на софтуера там е много ясно нали махането на компоненти които не се използват outdated cod много често се слагат библиотеки които въобще не се ползват но там си седи двадца и може да не се махне никога по същия начин внедряването на софтуера използваме системи и търпарти апликации които дори

12:10↗въобще не ползваме от много време и те следят там ни увеличават так сервиса. Постоянно сканиране, автоматично сканиране за уязвимостите. CV-ите, които вече са публично разкрити в зададени библиотеки, подпомагат много а за разкриването на това дали ние имаме използваме софтуер, който има уязвима версия. Ясна, ясно и съзнателно избиране на версия, а не просто това много ми харесва, въпреки че le доста често акo въпреки това, нали ясно да знаем, ние отиваме тази версия с причина, както и когато пачваме софтуера, знаем на коя версия отиваме с причина, а а не просто пачваме for the и също така много ясно да е от защитени и официални места да се теглит софтуери, библиотеки, а не откъдето и да е. Добър пример за това нещо е автоматизиран с бомба. Автоматизиран сбо нещо, което в последните години стана доста нашумяло и е доста ефективно. Това е, когато се разработва софтуер, да

13:19↗автоматично да генерираме този софтуер B of materials. Най цялото всичките dependнсите, които имаме а към софтуера автоматично да излезат с техните транспорти и детенсите, като с версиите и с всякакви уязвимости, които са нон, да излизат в един файл. Това също важи и за софтуер, важи и запинсите и за всичко останало, което ползваме. И е много удобно, защото първо за секюрити тиймовете е много лесно да видят всичките версии, всичките проблеми, които може да има вашия софтуер за секунди, а не за дни да трябва да минавам през цялата инфраструктура и да гледаме, нали, какво се случва. Също така имаме пълна и ясна видимост към всичко, което е транзитив. Също така машини могат да го четат това нещо като код, защото то е един файл и могат да анализират дали тези версии са уязвими или на последно място. Ако компанията трябва да е има някои регулации, те много лесно може да се изкара тоя

14:17↗документ и да е за доказателство за стейта на а компанията спрямо този софтуер Supply Chain AT, нали, че защитата е добра. Това е като цяло от нас, нали и на NHL какво е Soft Supply Chain Security и мога да дамтата на вас, ако имате въпроси към нас.

14:46↗>> Благодаря.

14:54↗>> Супер, момчета. Много ви благодаря. Много беше полезно и интересно. Мене съплачени атаките са ми много така любима и интересна тема при сърце. Така, сега ще срещнеме нашия лектор Йонко. Здрасти. >> Така, сега ще ни разкажа нещо интересно.

15:17↗разберем дайте после

15:24↗>> чуваме ли се всички? Добър вечер. Аз се казвам Йон Йонков и имам около четири години опит в сферата на киперсигурността и темата, за която ще ви разкажа днес е методите от киберсигурността. и ефективно също не ефективно докладва. Реално това е тема, с която може всички да сте се сблъсквали или ще се сблъскате, независимо дали започвате кариерата си сега, дали сте в мениджмънт, ръководство, дори и в red team и team докладите са неизбежни. Това са неща, които а трябва да се представят и много често е мостът между техническите хора и самия бизнес, за да могат да разберат те какво правят и дали получават стойност за това, което инвестират в самия екип. Нека започнем с това какво наричаме метриката. Метриката много често е нещо, което може да измерим обективно. Важно е също всички да разбират метриката, която се измерва. Какво искам да кажа с това? Качество тя може да се използва и като

16:27↗стандарт за качество. Не е нужно а тя да бъде единство метрик номинално число. Тя може да бъде а стандартизирана, така че екипът да знае към какво ниво да се придържа. не е средство за да се наказва по някакъв начин, но иска искаме нали да поддържаме една стови кой от екипа работи, ако става въпрос за сок, хората са на смяна, те все пак да придържат едно ниво на стандарт. Важно е също да може да се проследява във времето. Тенденцията а е важна, да може да се вижда дали имаме някакъв прогрес с времето, дали се врушава, дали се подобрява, за да може да се каже дали са нужни повече ресурси или по-малко. И най-малко и не на последно място, но не и по важност да се прилагат действия. Действията от екипа са важни, за да може а те да действат върху самата метрика и ако има нещо, което тези не са видели техен пропуск, те да могат да работят върху него. Затова метриката е важно да

17:26↗има и приложими действия зад нея. Какво много често може да наблюдаваме? Това са повърхностни срещустойностни или така наречените ефективни метрики. Какво са повърхностните? Метрики. Те много често се обличават с неща, които са много обек, нали, много общо обективни, не ни дават реалнастойност и с малко се губи контекстът при тях. Те изглеждат добре на хартия. Пред мениджмънта също може много да ги впечатли, но на практика в един момент и в теста на времето те са провали. Докато стойностните метрики те повече наблягат върху това, което е важно. Набляга се върху самата а самата самия контекст на нещата и какво реално secкюрити екипът, техническите хора какво трябва да се фокусират и помагат за приоритизация на рисковете. Как изглеждат повърхностните метрики? Те много често май както казах, те имат липса на контекст и нямат много последващи действия. За пример имаме 5

18:28↗милиона блокирани атаки на този фон. Това изглежда страхотно число. Човек ще си каже: "Ние имаме най-добрия secюриity екип, те блокират, нали, няма какво да ги спрем." Обаче реално какви са тези атаки? На практика това фало го прави автоматично и няма никаква реално намеса. И бизнесът казва си, че е добре, но реално не може да разбере каква е вашата стойност. Може би продуктът прави цялото тежко, а вдига цялата теж, докато вие а си почивате. Идеята тук е да се представи на база на тези блокирани атаки, да се изведе важното. Ако да кажем тези атаки, които са предотвратени, три от тях са били опит за пробив и от този пробив е можело да го кати целия на бизнес и да е имало загуби за стотици хиляди. Това е нещо, което бизнесът може да разбере. Това може да се устойности и по този начин вие да а от една страна да покажете, че мислите и имате нали така проактивност в

19:20↗самите числа, които показвате. И другият пример, който да кажем, завършваното обучение. Имаме 99% завършено обучение. Хората са си направили нещата. От кампания с гледна точка ние сме супер спокойни. Обаче какви действия са предприели хората? Дали кати от счетоводството ще продължава да си цъка на а спам имейлите, които са реално фишинг за 5% отстъпка, нали? Не сме особено сигурни. Трябва да проследим действията, които са направени в последствие на тези обучения. дали има нещо, което допълнително трябва да се направи. Същото дали тези обучения ще бъдат подкрепени с фишинг кампании, в които ние може да видим какви действия най-често се правят от служителите в една организация. Нека минем към ефективните метрики. Те са насочени към действие, могат да се изменят във времето и много често а екипът може реално да се простлява взелта. Нека вземем за скоростта на реакция. Това

20:20↗много често е метрика, която се използва, за да се измери времето на, да кажем, един висок екип, за колко време може да види една форма, да я обработи и вече ако има някакви последващи стъпки или ако е външен сок, има разлика между това дали е вътрешен или външен, а защото ако е вътрешен, тази метрика може да е малко по-либерална, обаче ако е това нещо може да е обвързано с SM а или по-накратко може да го има в договора и тези условия на договора Ако не са спазени за определено време, ще се наложат глоби, санкции или неустойки. Така че има малки разлики от естеството на бизнеса, но тази метрика е много лесно измерима и трябва с времето да може да се измена адекватно самите хора да знаят как да реагират и какво се очаква от тях като реакция, защото реакциите са едни от нали много зависи реакцията за за самия бизнес, нали, ако е много бавна реакцията, ако е много

21:14↗троново, тези неща могат да бъдат много ценни минути и съответно финансовите щети. Друга метрика, която също може да бъде обвързана е аз тук съм използвал малко съм я побългарил фолшивите тревоги или позитиврейта. Тя е малко две в едно метрика. А тук виждаме младия сока анализ. Той се е поизпотил от негото шум, който се случва. Може би ще му поболеят косите до 25-годишна възраст, но това, което искаме да измерим с това нещо, е да видим колко са ефикасни нашите вълве за засичане или самите а неща, колко шум генерирате, дали са оптимално направени и колко време те губят в това да си играят, да гонят призраци от а за фалшиви тревоги. Същото нещо, което е може да бъде в резултат на много в общими или тревоги, то е алъртфатика, нали? Те свикват с това, че постоянно има шум, постоянно има а фалшиви тревогии, те губят това чувство за любопитство или много бързо стигат

22:14↗тавана, който те а който е техният потенциал и вече търсят да се пренасочат. Така че това е нещо, което активно трябва и да се атакува не само и не толкова от мениджмънта, ама толкова от secкюрити екипа, за да могат тези неща да са в здравословен а здравословна граница. А кое е клиент, те могат да си имат в договора, както казах, някои SD, които тази метрика да я гледат и вие трябва по договор да сте под тази метрика. Как може ние да валидираме дали една метрика е ефективна? Има някои неща, които а така може да си зададем. дали може да приложим ефективни действия, дали може да проследим нещата за прогрес, както и дали нещата може да ги преведем в бизнес контекст, да вземем тази метрика, която е на а екрана средно време за обработка на какво може ние да приложим като действие в този случай може да установим какви са проблеми там реакцията е бавна, дали има нещо, което

23:16↗липсва като знание в някои от екипа или трябва нещо, което просто не е съвсем изве известно и трябва да се отработи вече. Ако като се установят тези неща, ние може да направим определени тестове, могат да се направят и а като упражнения, за да се види реакцията и къде са основните проблеми, но е нещо, което активно може да се работи върху него и да се приоритизира. Тенденция във времето, ако вземем за пример, че имаме а цел, която е четири часа, ние искаме да видим с времето, нали да кажем на тримесечие ще измерме. Ние сме започнали тук. Установяваме си базовата линия, четири часа. Целта ни е 2 часа и половина. Ние вече като проследяваме във времето как вървим добре или зле, ние ще знаем, че нашите действия реално имат резултат от това нещо. и дали има въздействие върху бизнеса. А вече а тук как може да го преведем на един бизнес или на ръководството? Казваме, че а времето за

24:13↗реакция е бавно от гледна точка, че има и много товари обем от неща, които екипът също трябва да отработва. Много често се случва някои екипи да се занимават с много неща едновременно и това може да посочи към проблем, който в бъдеще ще могат да се отпуснат повече ресурси или допълнителен човек или бюджет, за да могат хората да се справят с този обем. И по този начин ние отговаряме на трите въпроса. Как една местка може да си я пречупим по начин, който да ефективна. Естествено, тези три въпроса не са единственото. Може да ги ползвате като основа. Стигаме до това защо са важни доплате. Докладите а първата точка определяне на бюджета, тема, която е доста разрешена в момента. А по този начин вие може да покажете какво а може имате като пропуски или неща, които се случват добре. Това помага, нали, в кратък и ясен вид. Защо аа те трябва да отпуснат повече бюджет

25:17↗или по-малко? Има лек лека ирония в това, че при сигурността, когато нещата вървят добре, бюджетът лека-полека се урязва. Когато нещата са зле, бюджетът до тавана. Но въпреки това тази стигма лека-полека се изчиства и тези доклади, когато имате време с ръководство или с хора, които взимат решенията и определят бюджетите, много е важно вие в кратък и ясен формат да им кажете защо ви трябват тези ресурси, тези неща да бъдат подкрепени. Един вид се получава, вие продавате проблема, но вие трябва да го направите това нещо, за да може да се отпусне бюджет. Не е любимата част на техническите хора, но е важно, за да може да се а за да може да се движи екипа напред. Периотизиране на риска. Това също е нещо, което ви дава визуална цел. Може да са три, може да са четири, може да са две, но ви дава реално къде да си насочите ресурсите. Тези неща винаги са променливи. Едно тримесе,че

26:16↗може да са ед едни приоритетите, друго тримесе, че може да са други, но с развитието на а и узряването на сигурността на един бизнес по същия начин а се развиват и метриките, така и екипа. Друго нещо, което е важно е доверие в екипа. А като се работи с клиенти, е много приятно, когато те могат да ви имат доверие и могат да разчитат на вас. Това не е нещо, с което трябва да се злоупотребява. Те, ако виждат, че вие сте поразчни с тях и им докладвате не само нещата, с които се справяте, но и нещата, в които ви куцат, те ще имат много повече доверие и ще вярват на това, което вие им предлагате като варианти и много повече ще се случват във вас като професионалисти, както и самия подбор на метриките много често идват от а експертите по киберсигурност, а не от самия клиент. Те могат да имат някои договорени неща от екипа за продажби, но това, което са обещали тези

27:12↗от а екипа по продажби, не винаги е реално това, което може да се предостави като услуга. И на последно място са регулаторните съответствия. Това са неща, които много често са малко, нали, много хора могат да ги намерят за досадни, но това, което трябва да се има предвид тук, че доклад за одитори и за комщите като тези за вътрешно в екипа и нещата, които ще се действат. Много често при регулаторните доклади те са много широки като повърхност, но често не са много задълбочени. Те имат определени неща, които за тях са полезни, но оттам нататъка аа вече на вътрешно ниво много повече се стимулира и технически екип, но да могат и да да го отразят и към бизнеса, да получат нужните инструменти. Сега тук а ще минем към ефективно срещу неефективно докладване. Ще ви помоля с вдигане на ръка да кажете визуално на пръв поглед кой от тези два доклада ви допада повече. Нека започнем на кой му

28:19↗допада повече от ваше ля доклад. Така. А на кого доклад? Повече този отдясно. >> Добре. Може би видяхме кои са мениджъри и кои са Така. Тука има една уловка. А единият рекорд. Той изглежда по-добре визуално. Да. Но информацията в него не е особено а тя е малко по-повърхностна. Имаме а блокирани атаки, които са 15 милиона. Имаме сканирани системи на 99%. Едно усмихното лице мениджмънтът си казва добре нали супер сме, нали бюджетът си остава същия, независимо какво, нали, да кажем, добре сме. Но реално нали това е единственото нещо, което виждаме, докато другият репорт, той съдържа реална информация, но е направена в толкова нечетим вид. Имаме български, имаме английски, не знаем точно какво се случва и той човек не може да вземе решение на вас на това нещо. Така че не е достатъчно един репорт да е само добре изглеждащ. Той трябва да има и съдържание, а и в същото време не може

29:23↗да бъде само с а ефикасни данни, без да бъдат четими. Те ако не са четими, няма кой да ви обърне внимание. Някой ще го види това нещо и веднага ще го затвори и ще кажесправяме ли се добре? Ако се справяме добре, палец нагоре и това е. А затова имаме една златна среда или както обичаме да казваме да намериш на хляба млекото. А тук имаме една един доклад, който използва методологията на светофар. Много често се използва една много елементарна метология, която червеното е лошо, жълтото е средна работа и вече зеленото е всичко е наред. И тук и показваме кои неща вървят добре. Имайте предвид, че това е за пример може и да са червени метриките. В случая сме избрали две зелени и една жълта. А имаме две, които сме в целта. По тях няма какво да се направи. Жълтата вече сме написали, че имаме нещо, което е в прогрес, нали? Чакаме да се обработи. Планирали сме го. А има неща, които

30:23↗трябва да се довършат. Нас не ни е срам това нещо. Осъзнаваме, че имаме някъде, където може да се подобрим и ще бутаме в тази посока. Другото нещо, което също сме направили в този доклад, сме си показали от тримесечието как сме се развили. Реално ние имаме една проследимост за фалшивите тревоги. Ние сме започнали 8%, където са били в червено, а целта е била от пет. Вече второто тримесечие малко сме се доближили към тази цел. Но вече накрая третото тримесече сме успели. Показали сме реално, че във времето сме се справили по-добре и сме стигнали до метрика, която е в здравословния лимит. Ако работим с клиента, съответно няма да стигнем и до глоби. А тук искам да направя една вметка, че те метриките не са един вид бухалка за мениджърите и за това да използват върху secкюрити екипа. Това са неща, където са спомагателни и са метрики за измерване, но всички имат

31:23↗принос към това нещо. Мениджъра на екипа или ръководството, което е, то трябва да може тези неща да ги разбере и като види, че нещо е жълто, да не се планира, а да просто да пита какво се случва в този момент и защо е така и какво има нужда екипа, за да тези неща да се изгутят до края. Може би е просто въпрос на време, но в други ситуации може да е нужда на допълнителни ресурси. Така че от тази гледна точка бих искал да завърша също с това да ако утре се окажете в позиция, където трябва да правите репорт или трябва да го докладвате пред ръководството, прегледайте всичките метрики, през които за които ще докладвате и подберете реално тези, които са ефективни, които смятате. Ако всички са ефективни, браво. Но ако има такива, които мислят, че могат да се добавят и да надградят екипа, е, опитайте да видите дали ще има а ефективен резултат. Благодаря за внимание.

32:22↗[аплодисменти] Ако имате въпроси, а следният въпрос. Къде отчита ли се предела? Два варианта на предел може да имаме в тия мерки. А, тоест момента, в който това е най-доброто, което може да направим при тоя екип, с тая натовареност и така нататък. Х >> и другият предел е, когато вече, да кажем сме няма прочи добре, ама примерно по-сигурни от това няма как да бъде. >> Тоест тогава тия метрики ще застинат. Няма да има разми двата варианта. Еди въпросът ми е това отчита ли се и един така съвет, който бих дал към секюрити екипите, обяснете на вашите мениджъри, че дори и 1 милиард атаки да блокирате една е достатъчна. >> Така. Пак >> и затова трябва да се поддържа нивото. >> Да. А, съгласен съм. А, благодаря и за въпроса. А, идеята е, че точно като се стигне това застиване на метриките, те да еволюират заедно с реалността на бизнеса. Може би те ще са основата и

33:22↗нещата, които трябва да се поддържат, но за да се поддържа и екип остър, трябва допълнително метрики или неща, върху които да се работи, защото нещата са много динамични. Във всеки един момент има неща, върху които да се работи. Въпросът самите метрики те първо да бъдат подкрепени за целта на а която искат да бъде постигната и може би да има вторапена, която ги подкрепя да се следи, че екипът не работи само в посока да стигне метриката, а реално да поддържа и качеството, защото понякога се случва обратния ефект. Те работят за количество, но не и за качество. И това искаме да се избегне, за да може а да се а за да се избегне това нещо, трябва да мериките, нали, или ръководство, или човек, който реално разбира, да може да ги а налага или дори да бъдат изговорени с екипа. Други въпроси? Ами добре. А, предавамтата [аплодисменти]

34:36↗се. >> Здравейте, отново съм. Първо а искам да благодаря и на трите екипа, които аа имахме възможността да чуем досега. Първо демо беше много интересно което. След това много ми хареса на Костадин лекцията и по-специално факт, че той е на много добре на много приятен език, нали успя да го да го преразкаже и да го разкаже без твърде много чужденци, без твърде много комплекси и на искам да благодаря също доста се беше постарал. Много ви благодаря заделното време се постараете наистина значи много. А аз сега ще продължа с аop 10 и преди да започна да се представя на както аз казвам тези вас които не се познавам иглен се казвам както вече изстинк се занимавам с кил от много време а близо много дни смисъл над 15 може 20 ги закрилиме зависи какво броим а работих съм в най-различни компании аалет пакр в България йхоп може би сте чували Там изградихме информационната

35:48↗сигурност. А Amazon дълги години в чужбина и сега в момента хиберсигурност става евротъраст. Предполагам, че половината или повече от вас може да има това приложение на телефон син. А сигурност остава на мен и на колегите ми е страстен от предишните презентиращи, за което благодаря и се радвам, че има толкова много млади хора. Това за което сега ще си поговорим е Last топ 10. И преди да започна искам, аз имам много кратка адже и тя е какво представлява този проект. А да си поговорим какво се е променило от първия релиз на проекта от 2003 година. Объркан съм на 0. Какво се е променило и какво се случва сега през ноември има нов релийз на а рисковете. Да си поговорим накратко какво е ново. Сега, преди да продължа напред, да питам кой от вас не знае какво е властта? За първи път го чува, нали? Окей. Предполагам, че някой от вас са студенти, са чули за това нещо и са

36:48↗поканени от Юли Иван, за което много ви благодаря. Няма нали странен отговор тука. Кой от вас не знае? Добре, имаме някъде около 10%, които не знаят. Супер много нещо да ви кажа ново. А а от останалите, които знаят какво е власт, предполагам няма много хора, които не знаят какво представлява тоя ден. Почти няма. Охо, ами почти не се вдигнаха ръце. Аз мога да затваря. Нещо ще го прегледаме набързо. А хубавото е, че вто втората ми лекция ми реши един от топ тен рисковете. Практически няма да ви разказвам за него. Добре, ще разкажем накратко какво представлява власт. Преди а първо това е една неправосна организация фондация, която е основана в Щатите през 2001 година. Още са кривите експерти като нас. Целта е много проста. Разработват се проекти, анализи, инструменти, а на които се базира изключително голяма част от инициативите киберсигурността. Аа бекбоум на много на много

37:53↗голяма част от продуктите или имплементацията в нашия сектор е ласки и причината, нали, че е фондация над правителстване, над финансова, ако щете, нали. А по-известните неща са топ. Не може да не ако не сте в кибер от сигурността няма как да не знаете какво представлява тоя проект а има страшно много читве проекти четлинстове запак профил и така нататък а комюнити дригане тоест хора като нас и вас в бъдеще надяваме се разработват тези проекти всеки може да се включи те са в гифт може да отворите порест както се казва и разбира се има страшно много чаптери както този sopm който нали сме се събрали тук сега и гол е много прост да направим продукт тите, които практически ние използваме, защото ние използваме всички тия неща, да ги направим малко по сейф и secure чрез нашата работа и нашата експертиза. Топ 10 проектъ представлява аа един списък на най-често срещаните рискове.

38:51↗Той е сравнително highлевъл и той включва аа възможно най-много технологични аспекти, нали, в миналото е започнал като web аликейшъ, ама практически почти всичко, което ползваме е application по един или друг начин. А и представлява от името си е ясно списък с 10те приоритета, които ние трябва да се фокусираме, а и то е да го наречем, че е базовия минимум, а които просто ни дава една яснота какво в момента е така сравнително актуално като рискове и като неща, които се експлоатират и ги дава препоръки, разбира се, как да го предотвратим. Както ви казах, през далечната 2001 година остана на фондацията, а през 2003 година се започва с тоя списък и той включва 10 а неща, които по това време, нали, преди повече от 20 години са били доста доста простичък бил в списъка. Den of service, а инвалидиран input, буфер overflow. Сами знаете, те са възплина съжалявам, че някои от тези неща вече

39:56↗липсват списка. Причината е много проста. А първо чисто концептуално например of сървиice си е тип атака, а не е по-скоро нещо, което ние сме контрол дизайна на софтуера. Донякъде с мене това ще го следим. А инвалидираният инпут е преместен в други категории, като популярната ни днешно време е injection. Например сайт с script, който виждаме тука и през а инициализирането на топ. Списъкът е бил в четвърто място. После различните видове инжекъ са комбинирани в един единствен атъм. И през годините се така доста развивало. Обикновено това, което се случва е чрез обновяването на технологиите и адаптирането на повечето компоненти а някои от аа рисковете са мърчвани или някои са елиминирани или са добавени. Нали сега живеем примерно в Air, която всички от нас ползваме AI по един и друг начин или ако не ползваме сме клиенти. Аа това създава нови и нови неща, нови и

41:02↗нови възможности и рискове. Всъщност OLP като говорим за AI има и специално за LLM а топте 10 рискове има за APИ и за Mobile. Просто има различни категории. Този списък, който сега ще разгледаме, а е по-скоро генерален а и отговаря за така по-инклузивен. А така, през 2013, 2017, 2021, както виждаме, виждаме, много от нещата са се адаптирали, а мърчвали. Аз ви споделих, че а например cross scripting а и code injection и други фай и рискове са мърчнати в общи названия поради простата причина, че с модернизацията на технологиите се налага някои да отпадат. Например XML externality и се е мържнат в други компоненти security configuration. А същото се случва и сега през 2025 година, ако трябва да обобщим какво се е променило, какво се е променил списъка и ние ще ги разгледаме един по един 10, което вече разгледате. А на първо място остава брокер акess control а по поради

42:12↗много причини, че ще ги обсъдим. А много обаче от останалите аа топ три спадат надолу и те си западат позиция, което означава, че нали не се променят като приоритет. Каква е обаче причината да спадне? Първо как се събира информацията за тефайдинг? Нали не е някаква форма на гадае. Всичко е базирано на данни. А специалисти в компаниите, които повече от нас работят, участват в тези групи, а разбира се допринасят с данни, а международни агенции, които се занимават с кибернциденти, допринасят с данни и така се сформира информацията, а нали се анализира, която е основа на пренареждане на тоя списък, нали, не е не си представяте, че е хвърляне на боб. И за да се пренаредят едни неща, аз правят анализ на нали последните една, две три години, а чисто от комюнитито. А това, което обаче наблюдаваме тука като основни промени е, че а мис конфигурациите са се качили на второ

43:12↗място. Аа моят прочит на данните е свързан с това, че ние използваме изключително много компоненти, изключително страничен софтуер, SAS софтуер и много често го използваме по несигурен начин. Просто използваме out of the box. А нали той в крайна сметка сотър е нали спестява време и работа, но много често забравяме елементарните а секюрити практики за киберхити, така да го кажа и много често се случва. Предполагам, че и вас ви се е случило в миналото примерно си купите вече не се е случвало, тъй като по дефолт си идват рутери и други дражова, апмент си идва с по-силни пароли къде ще в миналото време ако си купите линк ру или нещо подобно, най-вероятно идва с admin adminн и нали ако е exposт вашия рутер камера нещо подобно и вие сте забравили да си смените defultшлите или нещо нещо друго сте забравили да преконфигурите най-вероятно се случва да бъде компроменде неизбежен такъв сега живее

44:09↗Та може би това е едно от причините, поради която се изкачва до второ място. Забелязваме, че на трето място, както колегите вече споделиха, а vлно компонентите или в миналото а този finding е наричан използване наро компоненти е обединен вър а причината не е само dependencyта в application факт, че почти всичко, което правим в днешния софтуерен свят има страшно много компоненти от други места, които използваме. Не говоря само за package, а в контейнерите, в паустрате, навсякъде ние инсталираме нещо, на което да приеме от хора и организации, които са open source и ние не познаваме и съвсем степен, нали, се случват вне разни аа инциденти. А така че там разместването долу-горе долу-горе е ясно. А прави ни впечатление обаче, че се появява една изключително нова категория на 10-то място. А тя наричах handling на exceptional conditions. Аз лично бих я превел на български като а неуправление

45:18↗на поведението на софтуера в неочаквани няма превод, но аз ви представям така. А софтуераъ при различни а интеракции се държи по разнообразен начин и ако при разработката не планираме аа за тези ексепшъни и за тези необичайни а използване на софтуера, е възможно нали да попаднем в ситуация, в която а да се получи secюрити уязвимост. Сега обаче в днешния етап, в който живеем с large mod AI навсякъде, възможността от софтуера, тъй като интерфейсът към софтуера вече ни е промт, глас или нещо друго, да се държи по необичаен начин. Тоест ние да сме изтествали всички възможни комбинации е невъзможен, просто защото не е повтаряем. В смисъл ако питате чат пити един и същи въпрос с 10 различни, да, ще ви отговори по най-вероятно 10 различни начина. А допускам, че това е една от причините да се появи нали този файдинг. Другата от причините е простия факт, че сме увеличили комплексито на

46:21↗софтуера, нали върнем а време назад с 20 и повече години. Ще забележим, че тогава софтуе интерфейсън ни към софтуе беше доста прост. Имаме дропдауни, нали, имаме инpта, които са доста лимитирани. Сега софтуерът се държи доста по-комплексно и може да бъде комбиниран на граждан и така нататък. И долу-горе останалата част от файлингите се запазва, като един от 10тия предишн сървър сай request forgery е комбиниран в счупен access control. А има причини за това. Аз смятам, че е доста правилно решение. Сега аз ще опитам да бъда доста така на български език превеждам нещата и да бъда доста аа кратък и добре а разбираем. Ако имате въпроси, разбира се, първо може да прекъснете, после в края може да ги обсъдим и сега какво представлява а първият фанинг, който вече е в новия списък, broken access control. А в в използването на софтуер най-вече такъв тип client сървър, това може да е всичко

47:22↗уеб мобилно приложение, API, нещо, което достъпваме отречено. А една от първите стъпки ние да се идентифицираме кои сме аа под една или друга форма, било то с креншо, потребители, парола. по-модерни методи на аутентикация, па скил и така нататък. А след като ние се а ау ав аутентикираме, предполагам сте ползвали най-различни държавни, не само сайтове, понякога се случва поради пропуски нали базови секюрити имплементации да достъпите а нещо, което не бива да достъпите. И а както е написано първа точка, това е а реално ние един от основните а една от основните идеологии в кирсигурността, нали, zero zero trust принципа на най-малко достъпи нали ако дойде служител или в случая потребител на нашето приложение би трябвало да има достъп само това, до което те трябва да достъпят. Обаче много често не се случва така. Много често приложенията, които използваме,

48:28↗не е естествено абсолютно всичко. Дали от човек не естествено или по принцип и се случва така, че да доставим аа нещо, което не е планирано да се случва. А другата причина, поради която това се случва е, че в модерната разработка на софтуер, предполагам тези от вас, които са се занимават със софтуер, знаем, че вече има доста така комплексно разделение поради простата причина, че имаме много интерфейси към софтуера. мобилно приложение, а уеб интерфейси, друг тип интерфейси, а и така нататък. Много често не всичко води към едно централизирано app или това е програми интерфейс тези брат, които не знам. И много често се случва аа киберзащитата да се случва на ниво интерфейс, в смисъл убложението в мобилното приложение, тоест във фронт енда по една или друга форма. И сега снамерените трета актори или хакери много често се случва да го байпа това нещо, нали? Не е много трудно

49:17↗да разглобим един уебсайт, да видим какви заявки прави към Appто и да планираме какво можем да направим извън това. Просто си представям, нали, ако отворите браузъра си натиснете 10 бутон и цъкнете напект, ще видите трафика, нали? Това е най-елементарния начин. по-сложният изисква допълнителни инструменти и тулове като а и оттам може да видите и много лесно може да си представите как може да се репродуцира комуникацията към бехен и съответно нали да достъпите да речем нали на мен ми се е случвало да ползвам държавни общински услуги пуснал съм жалба моят документ е сти 22 14 15 и просто любопит защото съм любопитен човек сменява Нямам последната цифричка с надолу.