У нас було 2 аналізатори коду, 4 інструменти для динамічного тестування, свої вироби та 250 скриптів. Не те щоб це все було потрібно в поточному процесі, але раз почав впроваджувати DevSecOps, то треба йди до кінця.
. Автори персонажів: Джастін Ройланд та Ден Хармон.
Що таке SecDevOps? А DevSecOps? У чому відмінності? Application Security – про що це? Чому класичний підхід більше не працює? На всі ці запитання знає відповідь Юрій Шабалін з Swordfish Security. Юрій докладно на все відповість та розбере проблеми переходу від класичної моделі Application Security до процесу DevSecOps: як правильно підійти до вбудовування процесу безпечної розробки у процес DevOps і нічого не зламати при цьому, як пройти основні етапи тестування на безпеку, які інструменти можна застосовувати, ніж вони відрізняються і як їх правильно налаштувати, щоб уникнути підводного каміння.
Про спікера: Юрій Шабалін - Chief Security Architect у компанії Swordfish Security. Відповідає за впровадження SSDL, за загальну інтеграцію інструментів аналізу додатків до єдиної екосистеми розробки та тестування. 7 років досвіду в інформаційній безпеці. Працював в Альфа-Банк, Ощадбанк та в Positive Technologies, яка розробляє софт та надає сервіси. Спікер міжнародних конференцій ZerONights, PHDays, RISSPA, OWASP.
Application Security: що це?
Захист програм — це розділ безпеки, який відповідає за безпеку програм. Це не стосується інфраструктури чи мережевої безпеки, а саме того, що ми пишемо і над чим працюють розробники — це недоліки та вразливості самого додатка.
Напрямок - Security development lifecycle - Розробила компанія Microsoft. На схемі - канонічна модель SDLC, основне завдання якої - участь безпеки на кожному етапі розробки, від вимог до релізу і виходу в продакшн. У Microsoft зрозуміли, що в промі занадто багато багів, їх стає більше і з цим треба щось робити, і запропонували цей підхід, який став канонічним.
Application Security та SSDL спрямовані не на виявлення вразливостей, як прийнято вважати, а на запобігання їх появі. Згодом канонічний підхід від Microsoft був покращений, розвинений, у ньому з'явилося глибше детальне занурення.
Канонічний SDLC дуже деталізований у різних методологіях - OpenSAMM, BSIMM, OWASP. Методології відрізняються, але загалом схожі.
Building Security In Maturity Model
Мені найбільше до душі BSIMM - . Основа методології - поділ процесу Application Security на 4 домени: Governance, Intelligence, SSDL Touchpoints та Deployment. У кожному домені 12 практик, представлених у вигляді 112 активностей.
Кожна зі 112 активностей має 3 рівня зрілості: початковий, середній та просунутий. Усі 12 практик можна вивчати по розділах, відбирати важливі для вас речі, розбиратися, як їх впроваджувати та поступово додавати елементи, наприклад, статичний та динамічний аналіз коду або code review. Розписуєте план та по ньому спокійно працюєте у рамках впровадження обраних активностей.
Чому DevSecOps
DevOps – це загальний великий процес, у якому потрібно піклуватися про безпеку.
Від самого початку передбачав перевірку на безпеку. На практиці чисельність команд безпеки була набагато меншою, ніж зараз, і вони виступали не як учасники процесу, а як контрольний та наглядовий орган, який висуває до нього вимоги та перевіряє якість продукту в кінці релізу. Це класичний підхід, у якому команди безпеки перебували за стіною від розробки та не брали участі у процесі.
Основна проблема саме в тому, що ІБ стоять окремо від розробки. Зазвичай це якийсь контур ІБ і в ньому 2-3 великі і дорогі інструменти. Раз на півроку прилітає вихідний код або додаток, який потрібно перевірити, а щорічно виробляються . Це все призводить до того, що терміни виходу в пром відкладаються, а на розробника вивалюється безліч вразливостей з автоматизованих засобів. Все це неможливо розібрати та відремонтувати, бо ще за попередні півроку не розібрали результати, а тут нова партія.
У процесі роботи нашої компанії ми бачимо, що безпека у всіх сферах та індустріях розуміє, що настав час підтягуватися і крутитися з розробкою в одному колесі. . Парадигма DevSecOps чудово лягає на методологію гнучкої розробки, на впровадження, підтримку та участь у кожному релізі та ітерації.
Перехід до DevSecOps
Найважливіше слово в Security Development Lifecycle – це «процес». Ви повинні це зрозуміти, перш ніж думати про покупку інструментів.
Просто включити інструменти в процес DevOps недостатньо — важлива взаємодія та розуміння між учасниками процесу.
Найважливіші люди, а не інструменти
Часто планування процесу безпечної розробки починається з вибору та купівлі інструменту, а закінчується – спробами інтегрувати інструмент у поточний процес, які так і залишаються спробами. Це призводить до сумних наслідків, тому що всі інструменти мають свої особливості та обмеження.
Поширений випадок, коли відділ безпеки вибрав хороший, дорогий інструмент, із широкими можливостями, і прийшов до розробників — вбудовувати процес. Але не виходить — процес збудований так, що обмеження вже купленого інструменту не лягають у поточну парадигму.
Спочатку опишіть, який результат ви хочете і як виглядатиме процес. Це допоможе зрозуміти ролі інструменту та безпеки у процесі.
Почніть із того, що вже використовується
Перед покупкою дорогих інструментів подивіться на те, що ви вже маєте. У кожній компанії є вимоги щодо безпеки, які пред'являються до розробки, є перевірки, пентести — чому б не перетворити все це на зрозумілий і зручний для всіх вигляд?
Зазвичай вимоги – це паперовий талмуд, що лежить на поличці. Була нагода, коли ми приходимо в компанію, щоб подивитися процеси і просимо показати вимоги щодо безпеки до софту. Фахівець, який цим займався, довго шукав:
— Зараз десь у нотатках був шлях, де лежить цей документ.
У результаті ми отримали документ за тиждень.
Для вимог, перевірок та іншого, створіть сторінку, наприклад, на Злиття - Це зручно всім.
Простіше переформатувати те, що вже є і використовувати для старту.
Використовуйте Security Champions
Зазвичай, у середній компанії на 100-200 розробників працює один безпека, яка виконує кілька функцій, і фізично не встигає все перевіряти. Навіть якщо він намагається щосили — поодинці не перевірить весь код, який генерує технологія. Для таких випадків розроблено концепт. .
Security Champions – це людина всередині команди розробки, яка зацікавлена у безпеці вашого продукту.
Security Champion - точка входу в команду розробки та євангеліст безпеки в одній особі.
Зазвичай, коли в команду розробки приходить безпека і вказує на помилку в коді, то отримує здивовану відповідь:
- А ви хто? Я вас бачу вперше. У мене все добре - мені старший товариш на code review поставив "apply", ми йдемо далі!
Це типова ситуація, тому що до старших чи просто колег по команді, з якими розробник постійно взаємодіє по роботі та в code review, довіри набагато більше. Якщо замість безпеки на помилку і наслідки вкаже Security Champion, то його слово матиме більше ваги.
Також розробники краще знають свій код, аніж будь-який безпечник. Для людини, яка має мінімум 5 проектів в інструменті статичного аналізу, зазвичай складно пам'ятати всі нюанси. Security Champions знають свій продукт: що з чим взаємодіє і на що дивитися в першу чергу вони ефективніші.
Тож подумайте над тим, щоб впровадити Security Champions та розширити вплив команди безпеки. Для самого чемпіона це також корисно: професійний розвиток у новій галузі, розширення технічного кругозору, прокачування технічних, управлінських та лідерських навичок, підвищення ринкової вартості. Це деякий елемент соціальної інженерії, ваші «очі» у команді розробки.
Етапи тестування
каже, що 20% зусиль дають 80% результату. Ці 20% - це практики аналізу додатків, які можна і потрібно автоматизувати. Приклади таких активностей – це статичний аналіз. SAST, динамічний аналіз DAST, и контроль Open Source. Розповім докладніше про активність, а також про інструменти, з якими особливостями ми зазвичай стикаємося при їх впровадженні в процес і як це робити правильно.
Основні проблеми інструментів
Виокремлю актуальні для всіх інструментів проблеми, які потребують уваги. Розберу їх докладніше, щоби не повторюватися далі.
Довгий час аналізу. Якщо від комміту до виходу на прод йде 30 хвилин на всі тести та складання, то перевірки на інформаційну безпеку займуть добу. Так гальмувати процес ніхто не буде. Враховуйте цю особливість та робіть висновки.
Високий рівень False Negative або False Positive. Всі продукти різні, всі використовують різні фреймворки та свій стиль написання коду. На різних кодових базах та технологіях інструменти можуть показувати різний рівень False Negative та False Positive. Тому дивіться, що саме в вашої компанії та для ваших додатків буде показувати гарний та достовірний результат.
Немає інтеграцій із існуючими інструментами. Дивіться інструменти з точки зору інтеграцій, з тим, що ви вже використовуєте. Наприклад, якщо у вас Jenkins або TeamCity - перевірте інтеграцію інструментів саме з цим програмним забезпеченням, а не з GitLab CI, який ви не використовуєте.
Відсутність чи надмірна складність кастомізації. Якщо інструмент не має API, то навіщо він потрібен? Все, що можна зробити в інтерфейсі, має бути доступне через API. В ідеалі, інструмент має мати можливість кастомізації перевірок.
Ні Roadmap розвитку продукту. Розробка не стоїть на місці, ми завжди використовуємо нові фреймворки та функції, переписуємо старий код на нові мови. Ми хочемо бути впевненими, що інструмент, який ми купимо, буде підтримувати нові фреймворки та технології. Тому важливо знати, що продукт має реальний і правильний розвитку.
особливості процесу
Крім особливостей інструментів, враховуйте й особливості процесу розробки. Наприклад, заважати розробці – це типова помилка. Давайте подивимося які особливості слід враховувати і на що звернути увагу команді безпеки.
Щоб не зривати терміни розробки та релізу, створіть різні правила та різні show stoppers - Критерії зупинки процесу складання за наявності вразливостей - для різних середовищ. Наприклад, ми розуміємо, що поточна гілка йде на девелоперський стенд або UAT, отже, ми не зупиняємо і не говоримо:
— У вас тут уразливості, ви нікуди далі не підете!
На цьому етапі важливо сказати розробникам, що є проблеми безпеки, які варто звернути увагу.
Наявність уразливостей – не перешкода для подальшого тестування: ручного, інтеграційного чи мануального. З іншого боку, нам потрібно якось підвищити безпеку продукту і щоб розробники не забивали на те, що знаходить безпеку. Тому іноді ми чинимо так: на стенді, коли викочується на девелоперське оточення, просто сповіщаємо розробку:
— Хлопці, ви маєте проблеми, будь ласка, зверніть на них увагу.
На етапі UAT знову показуємо попередження про вразливості, а на етапі виходу в пром говоримо:
— Хлопці, ми кілька разів попереджали, ви нічого не зробили — з цим вас не випустимо.
Якщо говорити про код і динаміку, то необхідно показувати і попереджати про вразливості тільки тих фіч та коду, який був написаний щойно в цій фічі. Якщо розробник пересунув кнопку на 3 пікселі і ми йому говоримо, що у нього там SQL-ін'єкція і тому потрібно терміново поправити - це неправильно. Дивіться тільки на те, що написано зараз, і на ту зміну, яка надходить у додаток.
Припустимо, у нас є якийсь функціональний дефект — те, як додаток не повинен працювати: гроші не переводяться, при натисканні на кнопку немає переходу на наступну сторінку або не завантажується товар. Дефекти безпеки - Це такі ж дефекти, але не в розрізі роботи програми, а безпеки.
Не всі проблеми якості програмного забезпечення — це проблеми безпеки. Але всі проблеми безпеки пов'язані з якістю програмного забезпечення. Sherif Mansour, Expedia.
Оскільки всі вразливості - це такі ж дефекти, вони повинні бути там же, де всі дефекти розробки. Тому забудьте про звіти та страшні PDF, які ніхто не читає.
Коли я працював у компанії, яка займалася розробкою, мені надійшов звіт із інструментів статичного аналізу. Я його відкрив, жахнувся, заварив каву, погортав 350 сторінок, закрив і пішов працювати далі. Великі звіти – мертві звіти. Зазвичай вони нікуди не йдуть, листи видаляються, забуваються, губляться чи бізнес каже, що він сприймає ризики.
Що робити? Підтверджені дефекти, які знайшли, просто перетворимо на зручний для розробки вид, наприклад, складаємо в backlog Jira. Дефекти пріоритезуємо та усуваємо у порядку пріоритету нарівні з функціональними дефектами та дефектами тестів.
Статичний аналіз - SAST
Це аналіз коду на наявність уразливостейале це не те ж саме, що SonarQube. Ми перевіряємо не лише за патернами чи стилем. При аналізі застосовується ряд підходів: по дереву вразливостей, , з аналізу конфігураційних файлів Це все, що стосується безпосередньо коду.
Плюси підходу: виявлення вразливостей у коді на ранньому етапі розробки, коли ще немає стендів та готового інструменту, та можливість інкрементального сканування: сканування ділянки коду, що змінився, і тільки тієї фічі, яку ми зараз робимо, що зменшує час сканування.
Мінуси - Це відсутність підтримки необхідних мов.
Необхідні інтеграції, які мають бути в інструментах, на мою суб'єктивну думку:
- Інструмент інтеграції: Jenkins, TeamCity та Gitlab CI.
- Середовище розробки: Intellij IDEA, Visual Studio. Розробнику зручніше не лазити в незрозумілий інтерфейс, який ще треба запам'ятовувати, а прямо на робочому місці у своєму власному середовищі розробки бачити всі необхідні інтеграції та вразливості, які він знайшов.
- Code review: SonarQube та ручне ревью.
- Дефект-трекери: Jira та Bugzilla.
На малюнку кілька найкращих представників статичного аналізу.
Важливими є не інструменти, а процес, тому існують Open Source рішення, які також хороші для обкатки процесу.
SAST Open Source не знайдуть величезну кількість вразливостей або складних DataFlow, але при побудові процесу їх можна і потрібно використовувати. Вони допомагають зрозуміти, як буде побудовано процес, хто відповідатиме на баги, хтось репортуватиме, хтось звітуватиме. Якщо ви хочете провести початковий етап побудови безпеки вашого коду, використовуйте Open Source рішення.
Як це можна інтегрувати, якщо ви спочатку шляху, у вас немає нічого: ні CI, ні Jenkins, ні TeamCity? Розглянемо інтеграцію у процес.
Інтеграція на рівні CVS
Якщо у вас є Bitbucket чи GitLab, можна зробити інтеграцію на рівні .
За подією - pull request, commit. Ви скануєте код і в статусі build'а показуєте, що перевірка на безпеку пройшла чи не пройшла.
Зворотній зв'язок. Безумовно, зворотний зв'язок потрібний завжди. Якщо ви просто виконали на боці security, у коробочку склали і нікому нічого не розповіли про це, а потім наприкінці місяця вивалили купу багів – це не правильно та не добре.
Інтеграція із системою code review
Якось ми ставили в ряді важливих проектів дефолтним ревьюєром технічного користувача AppSec. Залежно від того, чи виявлено помилки в новому коді чи помилок немає, на pull request ревьюєр проставляє статус на accept або need work або все ОК, або потрібно доопрацювати і посилання на те, що саме доопрацювати. На інтеграцію з версією, яка йде в прод, у нас була включена заборона merge, якщо тест з ІБ не пройдено. Ми це включали в ручне code review, і решта учасників процесу бачила статуси з безпеки саме для цього конкретного процесу.
Інтеграція з SonarQube
У багатьох є за якістю коду. Тут те саме - можна зробити ті ж самі gates тільки для інструментів SAST. Буде той самий інтерфейс, той же quality gate, тільки називатися він буде ворота безпеки. І так само, якщо у вас поставлено процес із використанням SonarQube, можна спокійно все туди інтегрувати.
Інтеграція на рівні CI
Тут також усе досить просто:
- На одному рівні з автотестами, юніт-тестами.
- Поділ за етапами розробки: dev, test, prod. Можуть включатися різні набори правил, або різні fail conditions: стопаємо складання, не стопаємо складання.
- Синхронний/асинхронний запуск. Ми чекаємо на закінчення перевірки тестів на безпеку або не чекаємо. Тобто ми їх просто запустили та йдемо далі, а потім нам приходить статус, що все добре чи погано.
Це все в ідеальному рожевому світі. У реальному житті такого немає, але ми прагнемо. Результат виконання перевірок безпеки має бути аналогічним результатам юніт-тестів.
Наприклад, ми взяли великий проект і вирішили, що тепер скануватимемо його SAST'ом — ОК. Ми запхали цей проект у SAST, він нам видав 20 000 уразливостей і вольовим рішенням ми прийняли, що все гаразд. 20 000 уразливостей – це наш технічний обов'язок. Борг помістимо в коробочку, потихеньку будемо розгрібати і заводити баги в дефект-трекери. Наймемо компанію, зробимо все самі чи нам допомагатимуть Security Champions — і технічний борг зменшуватиметься.
А всі вразливості, що знову з'являються, в новому коді повинні бути усунені також, як помилки в юніт або в автотестах. Умовно кажучи, запустилося складання, прогнали, впало два тести та два тести з безпеки. ОК - сходили, подивилися, що трапилося, поправили одне, поправили друге, наступного разу прогнали - все добре, нових вразливостей не з'явилося, тести не провалено. Якщо це завдання глибше і потрібно добре в ньому розібратися, або виправлення вразливостей стосується великих пластів того, що лежить під капотом: завели баг в дефект-трекер, він пріоретизується і виправляється. На жаль, світ не є ідеальним і тести іноді падають.
Приклад security gate - аналог quality gate, за наявністю та кількістю вразливостей у коді.
Інтегруємо з SonarQube – плагін ставиться, все дуже зручно та класно.
Інтеграція з середовищем розробки
Можливості інтеграції:
- Запуск сканування із середовища розробки ще перед commit.
- Перегляд результатів.
- Аналіз результатів.
- Синхронізація із сервером.
Приблизно так виглядає отримання результатів із сервера.
У нашому середовищі розробки просто з'являється додатковий пункт, який повідомляє, що під час сканування виявлено такі вразливості. Можна відразу правити код, дивитися рекомендації та . Це все розташоване на робочому місці розробника, що дуже зручно — не треба ходити за іншими посиланнями і щось дивитися додатково.
Open Source
Це моя улюблена тема. Усі використовують Open Source бібліотеки — навіщо писати купу милиць та велосипедів, коли можна взяти готову бібліотеку, де все вже реалізовано?
Звичайно, це так, але бібліотеки також пишуться людьми, також включають певні ризики і також там присутні вразливості, про які періодично, або постійно, повідомляється. Тому є наступний крок у Application Security – це аналіз Open Source компонентів.
Аналіз Open Source - OSA
Інструмент включає три великі етапи.
Пошук уразливостей у бібліотеках. Наприклад, інструмент знає, що ми використовуємо якусь бібліотеку, і що в або в баг-трекерах є якісь уразливості, які належать до цієї версії бібліотеки. При спробі використання інструмент видасть попередження, що бібліотека вразлива, і радить використовувати іншу версію, де вразливостей немає.
Аналіз ліцензійної чистоти. У нас це поки не особливо популярно, але якщо ви працюєте із закордоном, то там періодично можна отримати атата за використання компоненти з відкритим вихідним кодом, яку не можна використовувати або модифікувати. Відповідно до політики ліцензійної бібліотеки, ми цього робити не можемо. Або якщо ми її модифікували і використовуємо, то повинні викласти свій код. Звичайно, ніхто не хоче викладати код своїх продуктів, але від цього також можна захиститися.
Аналіз компонентів, що використовуються у промисловому середовищі. Уявимо гіпотетичну ситуацію, що ми нарешті завершили розробку і випустили останній реліз нашого мікросервісу. Він там чудово живе – тиждень, місяць, рік. Ми його не збираємо, перевірки з безпеки не проводимо, начебто все добре. Але раптово через два тижні після випуску виходить критична вразливість у Open Source компоненті, яку ми використовуємо саме в цій збірці, у пром-середовищі. Якщо ми не записуємо, що і де ми використовуємо, то цю вразливість просто не побачимо. У деяких інструментах є можливість моніторингу вразливостей у бібліотеках, які зараз використовуються у промі. Це дуже корисно.
Можливості:
- Різні політики щодо різних етапів розробки.
- Моніторинг компонент у промисловому середовищі.
- Контроль бібліотек у контурі організації.
- Підтримка різних систем збирання та мов.
- Аналіз Docker-образів.
Декілька прикладів лідерів області, які займаються аналізом Open Source.
Єдиний безкоштовний із них — це від OWASP. Його можна на перших етапах увімкнути, подивитися, як він працює і що підтримує. В основному це все хмарні продукти, або on-premise, але за своєю базою вони все одно вирушають до інтернету. Вони відсилають не ваші бібліотеки, а хеші або свої значення, які вираховують, та фінгерпринти до себе на сервер, щоб отримати звістку про наявність уразливостей.
Інтеграція у процес
Контроль бібліотек у периметрі, які завантажуються із зовнішніх джерел. У нас є зовнішній та внутрішній репозиторії. Наприклад, всередині Event Central стоїть Nexus, і ми хочемо, щоб усередині нашого репозиторію не було вразливостей зі статусом «критичний» чи «високий». Можна налаштувати проксіювання за допомогою інструмента Nexus Firewall Lifecycle так, щоб такі вразливості відсікалися і не потрапляли у внутрішній репозиторій.
Інтеграція в CI. На одному рівні з автотестами, юніт-тестами та поділом по етапах розробки: dev, test, prod. На кожному етапі можна завантажувати будь-які бібліотеки, використовувати будь-що, але, якщо там є щось жорстке зі статусом «critical» - можливо, варто звернути на це увагу розробників на етапі виходу в пром.
Інтеграція з артефакторіями: Nexus та JFrog
Інтеграція у середу розробки. Інструменти, які ви обираєте, повинні мати інтеграцію із середовищами розробки. Розробник повинен зі свого робочого місця мати доступ до результатів сканування, або можливість самому просканувати та перевірити код на наявність уразливостей до комміту в CVS.
Інтеграція у CD. Це класна фішка, яка мені дуже подобається і про яку я вже розповідав — моніторинг появи нових вразливостей у промисловому середовищі. Це працює приблизно так.
У нас є Public Component Repositories — деякі інструменти назовні, і наш внутрішній репозиторій. Ми хочемо, щоб у ньому були лише trusted components. При проксуванні запиту перевіряємо, що бібліотека, що завантажується, немає вразливостей. Якщо вона потрапляє під певні політики, які ми встановлюємо та обов'язково узгоджуємо з розробкою, то її не закачуємо та приходить відбивка на використання іншої версії. Відповідно, якщо в бібліотеці є щось реально критичне та погане, то розробник ще на етапі встановлення не отримає бібліотеку — нехай використовує версію вищу чи нижчу.
- При build'і ми перевіряємо, що ніхто не підсунув нічого поганого, що всі компоненти безпечні і ніхто не приніс на флешці нічого небезпечного.
- У репозиторії ми тільки trusted components.
- При депло ми ще раз перевіряємо саме сам пакет: war, jar, DL або Docker-образ на те, що він відповідає політиці.
- При виході в пром ми моніторимо те, що відбувається у промисловому середовищі: з'являються чи не з'являються критичні вразливості.
Динамічний аналіз - DAST
Інструменти динамічного аналізу кардинально відрізняються від усього, що було сказано раніше. Це якась імітація роботи користувача з програмою. Якщо це веб-додаток, ми надсилаємо запити, імітуючи роботу клієнта, натискаємо на кнопки на фронті, надсилаємо штучні дані з форми: лапки, дужки, символи в різному кодуванні, щоб подивитися на те, як програма працює та обробляє зовнішні дані.
Ця система дозволяє перевіряти шаблонні вразливості в Open Source. Так як DAST не знає, який Open Source ми використовуємо, він просто кидає «шкідливі» патерни та аналізує відповіді сервера:
— Ага, тут проблема десеріалізації, а тут ні.
У цьому є великі ризики, тому що якщо ви проводите цей тест безпеки на тому ж стенді, з яким працюють тестувальники, можуть статися неприємні речі.
- Високе навантаження на мережу сервер програми.
- Нема інтеграцій.
- Можливість зміни налаштувань аналізованого додатка.
- Немає підтримки необхідних технологій.
- Складність налаштування.
У нас була ситуація, коли ми нарешті запустили AppScan: довго вибивали доступ до програми, отримали 3 обліки та зраділи — нарешті все перевіримо! Запустили сканування, і перше, що зробив AppScan - заліз у адмін-панель, протикав усі кнопки, поміняв половину даних, а потім взагалі вбив сервер своїми -запитами. Розробка із тестуванням сказали:
— Хлопці, ви знущаєтесь?! Ми дали вам обліки, а ви стенд поклали!
Зважайте на можливі ризики. В ідеалі готуйте окремий стенд для тестування ІБ, який буде ізольований від решти оточення хоча б якось і умовно перевіряти адмінку бажано в ручному режимі. Це пентест — ті відсотки зусиль, які ми зараз не розглядаємо.
Варто врахувати, що це можна використовувати як аналог навантажувального тестування. На першому етапі можна включити динамічний сканер у 10-15 потоків та подивитися, що вийде, але зазвичай, як показує практика, нічого хорошого.
Декілька ресурсів, які зазвичай використовуємо.
Варто виділити — це «швейцарський ніж» для будь-якого безпекового фахівця. Його використовують усі, і він дуже зручний. Наразі вийшла нова демо-версія enterprise edition. Якщо раніше це була просто stand alone утиліта з плагінами, то зараз розробники роблять великий сервер, з якого можна буде керувати кількома агентами. Це круто, раджу спробувати.
Інтеграція у процес
Інтеграція відбувається досить добре та просто: запуск сканування після успішного встановлення програми на стенд та сканування після успішного проведення інтеграційного тестування.
Якщо інтеграції не працюють або там стоять заглушки та mock-функції, це безглуздо і марно — який би ми патерн не відправляли, сервер все одно відповідатиме однаково.
- Ідеально – окремий стенд для тестування.
- До початку тестування запишіть послідовність логіну.
- Тестування системи адміністрування – лише ручне.
Процес
Трохи узагальнено про процес взагалі і роботу кожного інструменту, зокрема. Всі програми різні — в одного краще працює динамічний аналіз, у іншого статичний, у третього аналіз OpenSource, пентести або взагалі щось інше, наприклад, події з .
Кожен процес потребує контролю.
Щоб зрозуміти як працює процес і де його можна покращити, потрібно збирати метрики з усього, до чого дотягнуться руки, у тому числі виробничі метрики, метрики з інструментів та дефект-трекерів.
Будь-які дані корисні. Потрібно дивитися у різних розрізах те що, де краще застосовується той чи інший інструмент, де процес безпосередньо просідає. Можливо, варто подивитися на час відгуку розробки, щоб зрозуміти, де покращити процес на основі часу. Що більше даних, то більше розрізів можна побудувати від верхньорівневих до деталей кожного процесу.
Так як у всіх статичних і динамічних аналізаторів свої API, свої способи запуску, принципи, в одних є шедулери, в інших немає ми пишемо інструмент AppSec Оркестратор, який дозволяє зробити єдину точку входу у весь процес з виробу та керувати ним з однієї точки.
У менеджерів, розробників та security-інженерів одна точка входу, з якої можна подивитися, що запущено, налаштувати та запустити сканування, отримати результати сканування, пред'явити вимоги. Ми намагаємося уникати папірців, переводити все в людський, який використовує розробка — сторінки на Confluence зі статусом і метриками, дефекти в Jira або в різних дефект-трекерах, або вбудовування в синхронний/асинхронний процес у CI/CD.
Ключові винесення
Інструменти не є головним. Спершу продумати процес — потім впроваджувати інструменти. Інструменти хороші, але дорогі, тому можна почати з процесу та налаштувати взаємодію та розуміння між розробкою та безпекою. З точки зору безпеки – не потрібно «стопити» все підряд, З точки зору розробки – якщо є щось high mega super critical, то це потрібно усувати, а не закривати на проблему ока.
Якість продукції - Загальна мета як безпеки, і розробки. Ми робимо одну справу, намагаємось, щоб усе правильно працювало і не було репутаційних ризиків та фінансових втрат. Саме тому ми пропагуємо підхід до DevSecOps, SecDevOps, щоб налагодити спілкування та зробити продукт якіснішим.
Почніть із того, що вже є: вимоги, архітектура, часткові перевірки, тренінги, гайдлайни. Не потрібно відразу застосовувати всі практики на всі проекти. рухайтесь ітераційно. Єдиного стандарту немає експериментуйте і пробуйте різні підходи та рішення.
Між дефектами ІБ та функціональними дефектами знак рівності.
Автоматизуйте все, що рухається. Все, що не рухається – рухайте та автоматизуйте. Якщо щось робиться руками, це не хороша ділянка процесу. Можливо, варто його переглянути та теж автоматизувати.
Якщо розмір команди ІБ невеликий використовуйте Security Champions.
Можливо те, про що я розповідав, вам не підійде і ви придумаєте щось своє — і це добре. Але вибирайте інструменти, виходячи з вимог саме до свого процесу. Не дивіться на те, що говорить, що цей інструмент поганий, а цей хороший. Можливо, саме на вашому продукті виявиться все навпаки.
Вимоги до інструментів.
- Низький рівень False Positive.
- Адекватний час аналізу.
- Зручність використання.
- Наявність інтеграцій.
- Розуміння Roadmap розвитку продукту.
- Можливість кастомізації інструментів.
Доповідь Юрія обрали одним із найкращих на DevOpsConf 2018. Щоб познайомитися з ще більшою кількістю цікавих ідей та практичних кейсів приходьте 27 та 28 травня у Сколково на у рамках . А ще краще, якщо ви готові ділитися своїм досвідом, тоді на доповідь до 21 квітня.
Джерело: habr.com