BSides Sofia 2022: Where and how to implement Security in Software Development

1:03↗Аз се занимавам с следването на Cyber Security екипа и целият бизнес, който е обвързан към клиенти и продаването на Cyber Security услуги във фирмата. Като бекграунд за много кратко време бях програмист. Впоследствие минах през Quality Assurance, Automation, за едни 10 месеца и DPO бях, така че с различни регулации също съм имала досък. В един момент стигнахме до Penetration, Testing и Security. В обща линия беше Love at First Sight. Останахме за по-дълго, имахме възможността да го развиеме и да сътворим цял екип, с който да продължим да развяме и услуги и knowledge. Дълго мислех с какво реально да започнем тази тема и попаднах на този клоот, на този стат.

1:56↗от плато. Ignorance is the root cause of all difficulties. Защо това?

2:03↗Миналата година бях лектор на една друга конференция, която имаше разнородни колеги от тази сектора. Имахме девелопери, quality инженери, DevOps-ове, network инженери и security, естествено. Когато ги питах в техните правителни, в техните фирми, в които работят, има ли хора, които да се занимават с секьюрити, някой, който да подсигурява сигурността на дадената разработка, продукт или това, което правят. Те казаха не. Питах добре, кой се грижи за сигурността? Отговорът беше никой. В общия случай, когато нямаме такива хора, а дори и да имаме, отговорността за сигурността на работата на всеки един от нас носим ние. Защо се получава така вече е по-интересен въпрос.

2:57↗Аз, това са едни принципи, които предлагам да се допнат от всички. Първият е Security с Everyone Responsibility, точно това, което исках да ви кажа. Независимо дали имаме хора, които се занимават със секюрване на разработката, която ние правиме, въпреки всичко изпълнението на сигурността остава във ангажменците на всеки един от нас. Дори да приемеме, че имаме човек, секюрити инженер, който да ни помага или цял екип,

3:27↗работата, която ние извършваме, изисква от нас да имплементираме някакви секюрити мерки.

3:33↗човека, който работи с нас в екипа, който ни помага, той може да ни даде насоки, но е ден да вдаде и не може да следи непрекъснато всяка една наша стъпка. Защо? Това е много важно да се разбере, защото в екипите, в които в общия случай се случва Software Development, всеки гледа своето собствено направление. Важно е да се гледа голямата картинка и да може да се вижда цялостната... визия за този проект, как той ще се случва и съответно къде е евентуално би имало проблеми. Втория принцип и това, на което основно ще се фокусираме, prevention is the key to avoiding problems. Аз имам едно такова мнение, че пентестовете и като цяло секьюрити тестинга е нещо много готино, но Имплементира се на доста късна фаза, в общия случай преди да излезе лайв даден продукт или в последствие. Трудно хваща всички проблеми, лимитиране от много неща, включително знание на човека, който го прави,

4:39↗достъп, който има и отстраняването на всякакви проблеми, води до едно забавяне на цялото delivery на този проект. бих казвала, че е доста по-скъпо начинание, отколкото да имплементираме секьюрити в началото. И последното нещо, няма 100% сигурност, това съм сигурна, че всеки един от вас го знае, защо, всъщност го казвам тук, дори да си свършим всички поверегата работата, пак ще имаме проблеми. Въпросът е какви проблеми и колко леяри в Дефенс сме заложили на нашата разработка.

5:14↗И тук идва нещо много важно, това, което може би пропуснах да кажа, че една от основните част от работата ми, аз се занимавам с консултанци на различни големи фирми

5:24↗в хелткер, в финансовата индустрия, в енерджи трейдинг. Много е важно как ще се справим от гледна точка на специалисти със ето този прекрасен триагъл, на който повечето от вас знаят. Security, usability, functionality. Ще дам един много прост пример. Наречем, че нашата фирма би искала да имплементира нов вебсайт, който да е за компанията. И съответно те искат да е удобен за бизнес, да бъде юзер-френдли, да има съответно всякакви настройки, за да може по-лесно да намират нашите клиенти, да може да го ползват нашите колеги по-лесно и съответно да бъде и секюр. И сега всеки почва да дърпа към неговата страна. Аз ще дори като секьюрити специалист, приятели да кажа ми има три различни решения или две в случая, за да е по-лесно. Маме една WordPress платформа и да кажа ми има една компания, която може да ни доставя едно custom решение, много добре

6:15↗изграден вебсайт, който е много секьюр, много хубаво направен, много скъп. И аз ще почна да дърпам към моята част, ето тук за секьюрити. Да, обаче така ще услужна много работата на колегите ми, които реално ще използват тоя сайт. Той ако не е юзер френдли, ако е много скъп, ние няма да имаме бюджет. Ако те не могат да го ползват, реално кейл файдача е секюр. И в общия случай ние всички винаги се борим да застанеме някъде и тук и така по средата. И нишката е много тънка. И не се налага като хора, които се занимаваме с секюрити, да взимаме такива решения, които да са удачни за бизнеса. Тоест, аз може да искам да го направим много секюр, но ако това на нас няма да ни донесе полза нито от бизнес-гледна точка, нито на хората, които го ползват, се налага да направим някакви компромиси, които да се отдачне за всички. Но дори и това да се случи, дори и пак

7:09↗да кажа всичко да сме направили като хората, идва момента, в който идва и end-user. Неща, за които не сме подготвени и ни се налага да импровизираме на момента.

7:22↗Това са простите принципи, които аз вярвам, че ако се адопнат във всеки един екип, биха имали доста сериозен успех. И понеже казах, че ще говорим за Software Development Lifecycle, това е една примерна картинка, как изглежда един Software Development Lifecycle, сега зависимо с коя методология гледаме, между 5 и 6 фази. Така изглежда стандартно. Основно Security имплементираме Ето тук в Testing and Integration и евентуално в Implementation. Това, окото говориш колегата Свет. Да, примерно тук са частта DevSecOps, която стана по-популярна, места, където започват вече да се слагат с DAS, Software Composition Analysis и т.н. Но основно от моя експеринс с работа с различни клиенти, анзористични индустрии, различни географии,

8:15↗пристигаме на фаза Testing and Integration и очакваме чудеса да се случат. Много трудно.

8:22↗Концепцията тук е, че по-скоро, ако започнем от самото начало да имплементираме Security, може

8:29↗да получим така наречения Secure Software Development Lifecycle. Какво имам предвид? На всяка една от тези фази, приемете го като примерни, това не е, между другото не знам колко се вижда, аз ще ви ги прочета, това не е силвар болет, т.е. не е задължително по този начин да се водите по тези препоръки. Това е пример. В зависимост от разработката, колко е голям продукт, за какво ще се използва едно или повече от тези неща, биха могли да се вкарат. Като концепцията е да се започне от самото начало. Още на ниво requirements and planning, когато се обсъжда да речем с... било то с вашите колеги какво ще разработвате или с клиента ако работите в Сървисис, е много важно да се обсъдят и така наречените security requirements, които често се пропускат. В общия случай имаме един човек, който идва и примерно иска като end user да получи някакво приложение, но ние като специалисти

9:29↗сме должны да му помогнем и да го насочим на правилната насока какво би трябвало да има това приложение. Тук се съобразявате естествено много неща. Какви assurance методологии бихме ползвали, съответно, ако да кажем това е софтуер, който е за специфична индустрия, банкинг, хелткер, енерджи, гавърмент и т.н. Стандарти и фреймварци, които евентуално това приложение би попадало под тях и съответно ние трябва да се съобразим.

9:58↗Фаза анализи, риск анализи, билдинг чеклест и security baseline, което съм сигурна, че колегите по-дъбре от мен ще го обяснят, но създаването на минималните секьюрити изисквания, които да бъдат за този продукт. В дизайн чували сте 100% секьюр дизайн принципа, секьюрити контрол, трет моделинг, за това ще обясня малко повече, полиси истин процеджер са не има, обантияксес контрол листа. Така, какво имам предвид тук най-основно? Виждала съм аз и колегите всъщност страхотни продукти за много пари, които са сбъркани още на дизайн фаза. И отключват невероятни секьюрити проблеми, които костват цял бизнес, санкции, въобще катастрофални неща могат да се случат. И то само защото секьюрити идва на по-късен етап в тази разработка. Затова е много важно, когато правим самия дизайн, да помислим и за тези неща. Имплементацията.

11:02↗Много неща могат да се случат тук. От гледна точка на писане на код, на вкарване на секюр-рекодинга, политики, практики, тренинги в екипите, SAST, DAST, Software Composition Analysis, License Misalignments, DevSecOps,

11:20↗карване на различни тулове в пайплайна, както обясни Свет, биото от Jenkins или друг, примерно, пайплайн сервер, който се ползва, Security Hardening и Secrets Management. Сега колегата преди мен спомена Hashicorp, аз съм голям фен на Vault на Hashicorp с Secret Management. Страхотен сервер е, може да пробвате да го ползвате. Това е един от вариантите. Нататък в фаза 5 вече обидам на security testing, аз съм ги обединила. Биото application testing, дали ще го правят quality assurance хората, дали ще го правим и ние по принцип трябва да го правят всички. Даня ще ви кажа като девелопер, всеки един трябва да се тества кода преди това. Но основно така се движат. Security bug handling, специфични процедури, които да се разработят за това. И когато вече софтуера е готов, Не трябва да забравяме да се грижим за него, съответно петч менеджмент, апгрейдване на политиките,

12:19↗на полистата, които сме крейтнали и мониторинг, както и постоянен асесмент. Сега пониждам, тук имаше един въпрос от колегата преди това за софтуер Билов Матсириос файла. Миналата година основно се занимахме така с екипа да си разработиме вътрешна една платформа за

12:37↗така, сайбер секюрити бих казала, и по-скоро за провайдване на визибилити. От нашия експеринс забелязахме, че това, което се получава, в общия случай ние нямаме ама никаква идея, какво се случва с нашата разработка на всички нива. Ние имаме порции от тук малко, от там малко, от искрес малко. Това, което се опитахме да направим е да събираме информация от няколко места. Тоест, тези софтуер бил в материал с файлове, взимайки ги тях, единствено от тях не е source кода, анализирай ги и давайки информация за vulnerabilities, това е Software Composition Analyze. Другото много важно нещо, което е хубаво да се следи, ако не го правите и някой се занимава на Software Development, моля ви се започинете да го правите, лицензионната политика е използвана на Open Source компонентите. Това е нещо в общия случай, което заляга в договорите с всеки един, но никой не следи за него поради

13:26↗липса на ресурса или капацитета. И това, което се получава е, че ние можем да правим един софтуер, който да бъде за продаж на цел и използваме open source компоненти, на базата на които изграждаме нашия софтуер, но не спазваме тяхната лицензионна политика, тъй като те не се ползват за commercial use. Това при изтичане или при случване на някаква неприятна ситуация за нас би довело до доста сериозни санкции и глоби. Така че това е част от нещата, които софтуера се занимава, но като цяло мисълта ми е, че има много quick win-ове, които могат да се направят тук. Не е нужно да е това цялото нещо, което виждате. Може за проекта, по който вие работите, да ви е достатъчно едно, две или три. Може да ви трябват по-различни неща, но това е една визия за как би могъл да изглежда Secure Software Development Life Cycle. И понеже това, както виждате, е доста информация, няма да

14:25↗имаме просто възможност да обсърим всичко, но ако някой го интересува, някоя конкретна тема, и аз си дани сме на разположение, ако искате да ги обсъриме след това.

14:35↗За момента ще се спрем на 3D Modeling и на Security Hardening. Сега, за 3D Modeling колегата започна. Аз ще продължа с това, че това е човека, който аз наричам The Father. Това е Адам Шуфер. Мисля, че така ме са произнася фамилията, да ме прощава човека. Дълги години той беше менеджер на Secure Software Development Lifecycle екипа в Microsoft. И този човек всъщност модернизира трет моделинга като концепция през последните години. Той не е човека, който го разработва като теория назад във времето, но той е човека, който го модернизира. И благодарение на него почнахме все повече и повече да говорим и това нещо да се имплементира. Иронията на съдбата е, че Адам има книга издавена през 2014 година на тази тема, а аз все още не виждам много хора да ползват тази концепция. Какво представлява сам по себе си

15:28↗Трид Моделинг? За мен това е едно прекрасно начинание, безплатно за целият екип, който се занимава с Software Development, да може да навлезе в Security. Това, което ви казах, че е важно всеки един от нас да отговаря за секьюрити на неговото парченце. Дори да нямаме секьюрити човек в екипа, всеки един може да носи своя кръс за секьюрити.

15:49↗Самия Тред Моделинг представлява, така да го кажа, започвайки от дефинирането на какви са нашите рекламенти за секьюрити. В зависимост как сме получили информацията, може и да нямаме такива и може да ни се наложи да ги създадем. Така че много е важно да знаеме какво ще се изисква от тази разработка, като я започнем в началото от гледна точка на сигурност. Ако ги нямаме, накрая после да се мъчиме да ги имплементираме. Хората, които се занимават софтуер или въплант, ще ви казват колко е сложно. Трябва да се променя и архитектура в някой случай. Така че трябва да се дефинираме нашите изисквания. Правим една диаграма. Диаграмата е много важна от опит, пак да кажа, когато участва целият екип, това е нещо, което дава възможност на всеки един да види как се случват нещата в тази разработка. Това, което каза в началото. Ако ти си девелопърти, си гледаш и е някакъв голям проект, да

16:41↗кажем с микросервизи, различни домени, 50 човека екип си. Всеки си гледа неговата градинка и си гледа това, което той прави. Една такава диаграма дава възможност да виж, че във, че прави колегите ти. Кое с кое комуникира, как се случват нещата, къде може да имаме евентуални пропуски. Защото, ако ние направим в нашата девелопмент разработка, подсигурим тази част, тази част, тази част, все пак оставят връзките между чах и те как се взаимодействат. Така че диаграмата е много важна и помага на целият екип да разбере какво се случва. След това, като се заберем всички, Това може много готюно да се имплементира и като част от, примерно, да кажем, скръм процеса или там каквото следвате лотърфо, де ли срещите, които имате, може да си го правите, да кажем, веднъж месеца, веднъж на три месече, както е удобно за вас. Но започвате, сядате на тази диаграма и

17:33↗всеки има различно виждане. Едно виждане има девелопера, едно виждане има нетворк инжинира, друго виждане има девопса, quality assurance човека и всеки вижда различни проблеми, които биха могли да излядат в тази разработка. Оттам на сетне, като ги имаме тези проблеми, идва да хард парт в общи линии, поне за мене, почваме да мислим всъщност как да ги митигираме и кои са най-възможности да се случат за нас. Връщаме се на максимата, която казах, няма 100% сигурност, т.е. не може да махнем всичко, кое е най-възможно да се случи за нас и кое е най-адекватно да премахнем прямо средствата и наличния ресурс, който имаме, защото премахването на такъв тип проблеми ще е екстрадевълкмент работа в най-общия случай.

18:16↗Съответно, измисляме тези, които ще премяхнеме, митигираме ги и накрая валидираме. И това цялото нещо, концепцията е да се върти в кръг, за да може постоянно да се сравнява тази разработка с новите условия, които изникват и новите третове. Сега тук съм дала един пример, който абсолютно целия кредит е на синопсис. Аз много ги харесвам като цяло и повечето им продукти. Но това е една примерна диаграма, която обяснява тред моделинга.

18:50↗Може да видите, има цяла статия как да се направи този тред моделинга, ако някой не е запознат и има желание. Съответно те го обяснем. Това е една примерна диаграма, с кое си комуникира, по какъв начин си комуникират, връзката с Secure ли, не е ли Secure, кое живее в нашия нетвор, кое е извън, откъде имаме интеракшн с юзъра,

19:12↗съответно какви третове биха могли да възникнат, какви ейдженти или какви са типовете хора, които могат да предизвикат тези третове и съответно какви контроли бихме имплементирали.

19:27↗Защо смятам, че е много готино да почнате да се занимавате с трет моделинг?

19:33↗ще помогне на всеки един от нас, дори колкото и да се е занимавал с секьюрити. За мен лично помага адски много да идентифицираш всичките проблеми и да приоритизираш най-важните спрямо твой бизнес кейс. Ако разработваме един софтуер, който е за финансовата индустрия, за него ще са специфични едни третове. Ако разработваме софтуер за хелткер индустрията, за него ще са други третове. Определено намалява тайм-то маркета. Защото това нещо влиза като част от регулар девелопмента и започва да минимализира всякакви проблеми от една точка на секюрити в разработката. Става за всички связи на Secure Software Development Cycle, всички колеги са инволвирани, тоест вече ще имаме разбирателстви от колегите и ще имаме този байас за секюрити. На този същи Адам, ако му гледате интервюта, той има една много готина теза, която аз поделяме. За момента се още е така, секьюрити няма място на масата за decision

20:35↗making. Какво означава това? В общия случай взимаме някакви решения, било то за бизнес или какво да правим и най-накрая мислим за секьюрити. Както виждате, секьюрити не е нова тема, но ние в момента имаме желанието да стартираме нашето секьюрити коммунити в България, което е след DevOps и след Quality Assurance коммунитито, както знаете.

20:58↗Та цялата концепция е, че ние идваме по-скоро на края. Много сме важни, но в последния момент са мисли за нас. И колкото повече хора намеряме, които да байнат нашата идея, билото нашите колеги, толкова по-лесно ще е да spread the word, както казваме. Тада. Няколко полезни материала. Всичко, което намерите на Адам е топ. Той вече не работи за Microsoft, но като цяло дала съм ви една лекция за Как изглежда Тред Моделинка през 2021. Не е много по-различан от 2014, за съжаление, както казах. Неговата книга.

21:35↗Добре е, че така, давах съм в линк за Amazon, но съм сигурна, че повечето от вас са достатъчно кадърни. Ако се разровите в интернет, ще я намерите и в Re-of-Charts, макар, че е нелегално. И най-голченото нещо, което може да направите, това наистина вече е безплатно и съм дала безплатен линк за него. Това е Elevated Privilege

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

22:26↗Вие може да имате друго мнение по въпроса, но това е така наречената практика, в която ние искаме да редуцираме вънравилитетата и като цяло Атак Сърфиса и РСК с нашата разработка. Как е възможно да стане това? Надявам се да сте чували за така наречените National Checklist Program, която е by MVD National Vulnerability Database. Това е една база данни с страшно много информация за различни операционни системи, сервъри и всякакви други продукти на големи вендори, която са разписани от, бих казала, MVD-ентусиасти, които са пронувнати от тях. Различни чеклисти с прямо различни регулации или добри практики. CIS, NIST, Data Stick,

23:24↗XCCDF и така нататъка. Но концепцията тук е, че това нещо го има безплатно. Междунатно, много хора знаят за него и явно изпитват проблем в момента, в който идва имплементацията. Но да кажем, че вие имате някакъв Windows Server 2012-2016, няма значение, и искате да го подсигурите, да го харднете, не знаете как да го конфигурирате, може да влезете тук, да се потърсите чек-листа с прямо, примерно, CIS или NIS или нещо друго, което ви допада и да си я свалите и да го харнете този сервер по тази логика. Сега, как би изглеждало това нещо? Понеже няма да имаме време да го покажем, само ще го обясня. Така, първа стъпка. Аз съм от балканите, както и ви, обичаме безплатни неща. OpenScap, безплатен тул. Може да се свалите OpenScap,

24:14↗който ще ви помогне с сваления чек-лист, било то от MVD. Има още едно място, което е наречно така Oval Repository. Някой чуява ли за Oval?

24:27↗Добре, една че ще бъде интересно. Oval Repository всъщност представлява едно репозитори създарено от CIS, в което се събрани...

24:40↗Едни файлове, които ако ги ранете на различна операционна система, да кажем, или на някакъв сервер, биха върнали информация какви са валидните вънерабилитета за този сервер. Найобщо казано това представлява. Такива овал имиджи може да намирате не само в овал репозитори, а в официалните сайтове на големите вендори, бето Red Hat, Ubuntu или някой друг. Те се поддържат тези файлове. Концепцията тук е сваляме този OpenScape на базата, инсталираме си го на нашата машина, да кажем някаква патч там примерно. Отиваме в MVD, сваляме си подходящия чек-лист, който е примерно по стиг. Няма проблем, ние не сме чак толкова много хора. Отиваме в Овел, сваряме си подходящия имидж, който е от Овел репозиторито. И вече ги рънваме с нашия OpenScape. Вече те поддържат различни версии на езиците и

25:38↗като цяло възможността за сканиране. А откома, който реално получавате, не се вижда много добре, но се опитах да ви направя един скриншот на двата репорта. Получавате два много детялни репорта. Какви са вашите вънравилите на тази машина и как да я конфигурирате секюрили. Къде имате пропуски? Какъв е риска обвързана с ня? как да подобрите това нещо с команди. Всяко едно нещо е описано много детайлно. За мен това лично е win-win, но много малко хора го прилагат, макар че, как да кажа, free of charge съществува доста отдавна. Това е един лесен начин, по който бихте могли да подсигурите инфраструктурата, на който върви вашия софтуер.

26:20↗И това е в обща линия от мен. Сега Дани ще ви представя едно кратко демо. Аз да кажем, че обясних за частта

26:29↗която е обвързана с как се случва софтуер девелопмента и какво е, той ще ви покаже нагледно как може да направите една част от това. Да, чувам ли се? Да. Добре, съм подготвил едно малко демо за вас. Цял идеята е да иллюстрира кво се случва, когато не се спазват най-добрите практики при софтуер девелопмента. Приложението е написано на че из JavaScript. Тази backend съм ползвал Java с Spring Framework.

27:05↗Секундечка.

27:12↗Така, като цяло всъщност съм избрал да имплементирам File Upload Functionality. Избрал съм точно това, понеже, както знаете, почти всички модерни web апликейшони го имат под някаква форма това. А неправилната имплементация мога да доведе до множество проблеми, като Remote Code Execution, XSS, XXI, Phishing и т.н.

27:39↗Направил съм го на левъли. Първия левъл всъщност е InSecure имплементацията, втори левъл е Secure имплементацията, а третия съм го кръстил Secure звезда, понеже е

27:51↗надгражда, както се сещате, левъл 2. Ще започна с Level 1.

27:58↗При отваряне виждаме една upload форма. Като цел, аз вече казах, че бекенда

28:04↗е Java, но с Lappalizer мога да валидирате, че всъщност наистина е Java бекенда. Обикновено аз като вият такова нещо, пъдърдето нещо, което пробвам е да кача .gsp файл. Подготвил съм за тази цел един.

28:21↗Цъкам upload. И... Accessfully mi actual file. Не знам дали се вижда, но всъщност аз имам direct and link до файл, което принцип не е много добра практика. Сега ще го отворя. И изглежда, че имаме JSP code running. Като мога да пробвам, примерно LS, виждате, че имам code execution на хост машината. Цялата имплементация е доста кофти, Много от нещата са много зле направени. Сега ще ги коментирам. Какви са lessons learned реално от Level 1? Никога не трябва да се пише код преди да са изяснени всичките функционални, технически и security requirements. Какво им предвид с това? Ако някой дойде и ви каже, нали трябва да напишете upload функционалност, Първото нещо, което трябва да ви идва в главата е какви файлове трябва да могат да се аплодват, имаме ли ограничения за размера, къде трябва да заплазваме файловете и който би трябвало да има достъп до тия файлове.

29:35↗И много други въпроси, нали, зависимост от кейса. При Level 2 съм се опитал точно това. Ако пробвам да аплодна отново Shell GSP, на този път Garmy Validation Error, invalid файл. За целите на демото съм предценил, че ще приема само PNG файлове. Като останалите валидации, ще ги покажа в кода, не знам. Вижда се.

30:05↗Както казах, първо се проверява размера. Важно е хем минимум, хем максимум constraint да сложите на сайза. След това имам една симпл валидация на екстеншена.

30:19↗и на финал проверявам MagicBytes. Предполагам повечето от вас знаят какво е MagicBytes, но за тези, които не знаят, ще кажа, това са реално първите няколко байта от един файл, които определят какъв е той. В случая на PNG, това са първите 8

30:36↗байта. В ASCII representation, реално има думата PNG и някои други non-printable ASCII characters.

30:48↗Ако пробваме обаче да аплоднем валиден файл, нали? Все пак да видим, че работи. Този път отново имам success, но вместо директен линк до файла, което казах, че не е добра практика, имам този download button, който реално ми тегли файла като attachment. Да.

31:12↗Като цяло, ако имате възможност да имплементирате по този начин, теглиния на файлове, препоръчително да се прави така, като attachment, а не да ги дисплейвате инлайн, както беше в предния кейс. Insecure варианта. Нещо друго, на което искам да обърна внимание, е при сторването на файла. Ряло първото нещо, което права е, че санитизирам името, премахвам всички

31:42↗символи, които не са букви или цифри и ги заменям с долна черта. И накрая append въм extension, който трябва да е валиден. След това, нещо, което пропуснах да кажа. При първия вариант, реално защо работеше този web shell? Понеже файла се сторваше на web root на приложението. Съответно, Tomcat, embedded сервера на Spring Boot, можеше разпознава GSP-то и екзекютва команди. Това е много лоша практика да се сторват файлове в web root. В случай аз имам просто една допълнителна папка, в която това се случва.

32:26↗И за финал, Secure звезда варианта. По-рано някой изпомена израза fail fast, fail early. Аз доста го харесвам и като цяло не мисля, че има нужда да се правят всичките тези валидации и санитизации на user input. Преди въобще самия контент контент е сканиран. Какво имам предвид?

32:50↗Ако пробвам отново да аплодна този .gsp файл, този път не гарми validation error, а гарми с malicious content, детекнал е, че това е трожен web shell, remote shell. Реално какво съм направил? Интегрирал съм backend-а с на VirusTotal API, понеже е безплатен и е доста готин. И по този начин се подсигурявам, че въобще няма нужда да просътвам файл, който очевидно е malicious.

33:23↗И да, това исках да ви покажа.

33:29↗Въпроси някой ако има? Да, слушам. Я пак само, че по-високо изменя.

33:45↗Да. Някой си ги ползвал по-малко, други си ги... Готини са туловете, ползвали сме ги по различни проекти, но може би начина по който се исках да...

34:04↗А, извинявайте, пита дали имаме опит с автоматични тулове за трет моделинг или по-скоро използваме тази концепция, нали така?

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

35:16↗Добре. Въпрос е дали сме ползвали и дали имаме опит с тулове, които се използват за секьюрити тестинг най-основно. Да, в обща линия екипа, да, не аз колегите е там и бившите колеги. Занимаваме основно и с пентестинг и с секьюрити тестинг. Ползваме различни тулове. Имате на разположение безплатни варианти, както някой спомена, зап, мисля, че беше ти, жуто. Бях фен и все още съм страхотен фен на ООСП, но запто да дава за мене лично и за колегите много фолз позитиви. Ние ползваме, в зависимост от това, което имаме на разположение, примерно в компанията или от клиентите, ни ползваме различни тулове. Бърб може да препоръчам, примерно, като много добро решение от гляна точка на тестване на реквести, респонси. Между другото, ако имате повече знания, може да ползвате и Фидлер. Всяко едно... Подобно решение, което прокусира, би ви свършило работа. Nesos, Acunetix,

36:18↗Netsparker, какво друго пропускам. Смисъл има различни вендори. В общия случай сме работили с повечето. Зависи с какъв бюджет разполагате, ако искате да имплементирате такова нещо и какво искате да постигнете. Защото един ресурс на пазара за целият toolset, било то за това или за нещо друго е доста обемисто.

36:42↗Не, може да се имплементират. За платените тулове зависи какъв лицензи са купиш и в общия случай зависи какъв е модела на работа, който правим. Примерно, ако е за Software Development, задължително ще го вкараме в част като CICD процеса, който ще рънва регулярно скенове, но няма да са само тези. Те са на нива, които минават. Ще имаш Unis test, може да имаш различни test suite, които са създадени от Automation инженерите, съответно ще имаш security testing, който да се прави, software composition analysis, статичен код анализ. Виждалото има безплатни решения за software composition analysis, както и за статичен код анализ. Така че има възможност на пазара това не е да се направи и без платени версии. Това отговаря ли?

37:32↗Някъде го... Да?

38:04↗Така е. Въпрос е докога може девелопментът, според мен като цяло колегите, които работят по разработката, да правят компромис с секюритито, докато менеджмента натиска с дедуайновете. Това е трики въпрос, на който трудно ще ти отговоря.

38:36↗Сменяш фирмата. Между другото, добре, отговорността, пак да перефразирам. Как се чувстваме след като менеджментът натиска да правим неща, които не са в хармония с нашите вътрешни разбирания за разработката и за нейната сигурност? Пак ще го кажа от опит. Менеджментът и техникал, техникал пипл и менеджментът или въобще бизнес хората комуникират на два различни язика. Много е важно да имаш или в себе си, или колега около тебе, който да е медиатор и да можеш да преведе рисковете на менеджмента в случая, ако ти не можеш сам, с който поне ти ще отидеш и ще му кажеш, това са рисковете, ако направя това, това, това и това. Такива са евентуалните последствия за тебе, за нас като фирма. Аз не съм окей чисто като човек, професионалист да го направя по този начин, но NDN-DVD понякога и го казвам пак от опит, се налага да

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

39:52↗Или смея на фирмата, както къде. Да. Други въпроси?

40:00↗Да? Аха.

40:08↗Отгледна точка на какво?

40:24↗Добре, въпрос е коя е...

40:50↗Въз случай, ти като си купиш кола след две години, как изглежда тяло? Смисълно, нали? Добре, въпросът беше...

41:01↗Да, како съществаме... За фирмата ли питаш конкретно, защото не ми е много... Добре, по принцип, защото нали не искам тук да промотираме фирмата на някакъв начин, имаме дивизия отделна в момента, която се създаде наскоро, която да се занимава с последващо...

41:18↗Ако ще те е application support като цяло, но по-скоро зависи от какъв е use case. Ти като създадеш един софтуер, може, примерно, дори да си фриленсър, твоя джоб да стига до там, че ти запредвеш софтуера. И вече те отива в трета страна, в който те вземат отговорността да се грижат за него.

41:39↗И както всяко едно нещо, ти дори, нали то, аз защо не съм По принцип много харесвам пентестовете и като цяло това нещо да се случва, но не съм фен това да ти е единствения начин, по който ти си подсигуряваш твоята разработка, фирма или квото и да било. Защото аз ще го предам този пентест сега. Ще ти напиша един страхотен репорт, обаче той след 5 минути, след като съм ти го предала, вече аз не носи отговорност. Ако излезе нов Zero Day, нова атака. По същия начин е софтуера ти, като го продадеш на някой, ако не се грижи за него, как ти кажах с колата, тя няма върви след 2 години само ако стои пред вас. Минимум, ако уматора ще е умрял.

42:24↗Точно така. Точно така. Тук си прав. За колата има гаранция, за девеламента няма. Затова говорим за качество. Стана много модерно в нашите географски ширини, развива се сектора, но говорим и за качество. Секюрити е част от качеството на всеки един и това, което доставя. А, не, зависи с колата. Нали има софтуер? Той е писан от някой.

42:56↗Ами, зависи по какъв начин работите. Смисъл такъв аз не съм чувал, между другото, много фирм, които да ги дават гарантия, премо след 5 години този софтвер ще работи, нали? Или нещо подобно.

43:22↗Добре, тука е спорна тема, понеже сигурна съм, че другите се умориха. Аз нямам нещо против да я продължим сега. Някои други последни въпроси? Добре, благодаря ви за вниманието.