Security Sandwich: інструкція з приготування

Привіт! Мене звати Таня, і я все ще тестувальник. За той час, що ми з вами не бачилися, я встигла заснувати митап QA Amsterdam і дати інтерв'ю про те, як докотилася до такого життя. А сьогодні я хочу розповісти про Security Sandwich.

Кіт Матроскін говорив, що краще їсти бутерброд маслом вниз: так смачніше. Про те, що таке бутерброд безпеки і як потрібно їсти, щоб не вдавитися, ця стаття.

Що ж представляє із себе класичний бутерброд безпеки

Початкова стадія , яка включає у себе вимоги до безпеки, оновлення інфраструктури, угоди і принципи реалізації.

Розробка , що включає впровадження цього добра в итеративную аджайл-методологію, інсайти, основні елементи, постійні вимоги та перегляд.

Go-Live-стадія , що включає код рев'ю і тестування на проникнення.

Початкова стадія: всі хочуть від чогось захиститися. Але від чого?

Перш ніж починати робити щось у цьому напрямку, добре б подумати над тим, що ми захищаємо і від кого . І тоді ми отримаємо правильну відповідь на питання, як захищатися.

Наприклад, компанія в якій я працюю, — це платіжний провайдер. Ми зберігаємо божевільна кількість даних про операції, які відбуваються по всьому світу щохвилини. Ми знаємо майже все, навіть які труси і де ви купили. Хіба що я не зможу дізнатися, чи купували ви зброю і порнографію, бо ми не співпрацюємо з такими мерчантами.

Але в цілому, якщо хтось отримає доступ до нашим даним, то він отримає все. Включаючи номери кредиток, ім'я та домашню адресу. І покупки, звичайно ж.

Тому відповідь на питання, що ми захищаємо, — конфіденційність наших клієнтів та свою репутацію. У разі злому наслідки будуть для нас дуже важкими. Швидше за все, компанія цього не переживе.

Від кого . Ворог може бути як зовнішнім (злодії всіх мастей), так і внутрішнім (наприклад, ображений співробітник).

Як ми захищаємося — військова таємниця, звичайно ж. Але спроби отримати доступ до інформації у нас відбуваються постійно. З найшкідливіших, про які можна розповісти, — фішинг. Найчастіше це розсилання листів всім співробітникам компанії. Фантазія і обізнаність зломщиків не знає кордонів. Я серйозно захоплююся ретельністю роботи, яку злодії проводять перед тим, як відправити той чи інший лист.

Наприклад, пару місяців тому вони відправляли e-mail в стилі «Привіт! Сиджу на нараді, не можу говорити, терміново прийшли таку-то інформацію. Рудольф». Відправлено з айфона.

Начебто нічого такого, от тільки зазначений Рудольф — це наш СЕО. Він в той момент дійсно сидів на нараді, і він дійсно час від часу надсилає з нарад такі листи, використовуючи свій айфон.

Коли ми з'ясували ось це все, то вирішили визначити вартість провалу: у скільки обійдеться нам те, що ми «профакапим» те чи інше дію. Зазвичай це оцінюється з точки зору ймовірності, критичності та ризиків.

Отже, що у нас має бути результатом роботи на першому етапі

Цілі безпеки : визначено коло запитів від бізнесу, юристів і регулятивний контекст (які закони повинні дотримуватися тощо).

Сценарій «А що, якщо?..»: що станеться, якщо наші поставлені цілі будуть порушені?

Ризики виникнення: беруться виходячи з власного досвіду, або аналогічної події у конкурентів, або з законодавчих актів.

Розробка: коли ж «відбувається» безпека

Традиційно шлях до продакшену включає:

обговорення (вербализацию функціональності);
вимоги (перенесення того, що нам потрібно, в епіки);
аналіз (поділ эпиков на User Stories);
розробку (User Stories стають функціоналом);
тестування (поставлений функціонал проходить рев'ю);
деплоймент (функціонал доступний користувачам).

На етапі аналізу ми встановлюємо Definitions of Ready.

Для цього нам потрібно:

проаналізувати наявні активи: що саме ми торкнемося змінами, які нові компоненти будуть в цьому порушенні брати участь, наскільки критично те, що у нас зараз є і як все це вплине на поточну ситуацію;
змоделювати загрози. Ця частина найцікавіша. Вона базово включає в себе питання про те, як ми можемо бути зламані і що буде при цьому вдариш. Але моделювання загроз саме по собі — один з моїх улюблених етапів. Моделі бувають прості і відомі типу STRIDE, а є прикольні і хитромудрі типу Persona non Grata. Я дуже хочу з цією темою виступити на наступному митапе, але перед цим потренуватися. Якщо ви хочете приєднатися і послухати про моделювання загроз, то приходьте на вебінар 27 листопада, о 20.00 (по Києву) . N. B. Матеріал буде читатися англійською мовою!
передбачити дії при зломах. Пом'якшити? Перенаправити? Уникнути? Або взяти?
передбачити зворотний зв'язок. Як ми захищалися? Як відповідали на злом? Як відновлювалася система? Які у нас могли б бути альтернативи?

І звичайно, тепер у нас з'являється новий борг — security debt, за ним тепер теж треба ретельно стежити.

На етапі розробки ми полегшуємо собі життя за допомогою автоматизації, а також:

звертаємо увагу на залежності: діємо на випередження, підтримуємо їх в актуальному стані та активно тестуємо;
використовуємо CVE (Common Vulnerabilities and Exposures): списки з уразливими постійно поповнюються, і це можна і потрібно використовувати. Автоматична настройка сканерів для бібліотек та фреймворків ніколи не зашкодить;
контейнери: як не дивно, контейнеризація — це не панацея від всіх бід. У них теж є уразливості, і добре б налаштувати і для них автоматичне сканування.

Go-Live: знай свою систему!

Вся попередньо проведена робота була б марною, якби ми не могли побачити її результати. Тому після випуску продукту (або нового функціоналу) ми зазвичай:

Пропонуємо поточний стан системи. Це всілякі метрики і статистика в реальному часі, по одному погляду на які можна зробити висновок, добре все йде. Наприклад, у нас в компанії в кімнаті кожної команди встановлені великі монітори (а у менеджерів їх по кілька штук), на які виведені дашборды з метриками системи. У будь-який момент кожен член команди може достовірно сказати, чи все йде як треба. Для цього досить підняти голову і подивитися на монітор на стіні.
Робимо структуровані і зрозумілі логи. Хорошим тоном тут вважається не засовувати логи в стринги, а логировать нормальні, індексовані дані. В ідеалі система логування повинна бути легко инспектируемой і корелювати з усією системою.
Визначаємо нормальний і не дуже поведінку. Ми повинні вміти швидко фіксувати, що щось пішло не так, і мати стандартну процедуру поведінки в таких ситуаціях. Наприклад, у нас один раз «дещо» сталося. Це «дещо» швидко усунули, але нервів попсували чимало, тому що, по-перше, «дещо» сталося близько опівночі, а по-друге, процедури на випадок «дещо» не було. Тому діяли інтуїтивно і досить хаотично. Після усунення «дещо» провели роботу над помилками і зробили строго певний регламент поведінки на випадок повторення, який розіслали всім працівникам компанії: кому дзвонити першою, кому другому, за якими телефонами, яких клієнтів і яким чином інформувати і так далі.
Застосовуємо методологію безпеки Shift Left. Ця (і схожа з нею Shift Right) методологія набирає все більше популярності, і ось вона доповзла до безпеки. Суть її проста: якщо ми представимо процес розробки як пряму з плануванням в точці нуль і випуском готового функціоналу в крайній правій точці, то Shift Left — це зсув вліво. Тобто починаємо робити що-то як можна раніше. Так тепер і з безпекою: раніше почнеш — менше втратиш. Тому варто стежити за Security Debt, впроваджувати колективну відповідальність за діри безпеки в коді та інші приємні речі.

В якості висновку

Security Sandwich здається простий і нехитрою річчю, тим не менш у процесі постійно щось втрачається.

Але, як і з цим бутербродом, якщо прибрати нижній шар хлібця (стадія Go-Live), то весь сир з ковбасою буде постійно провалюватися вниз, а підтримувати його пальцями практично нереально.

Коли ж прибираємо верхній шар хлібця (планування вимог, облік угод тощо), то все начебто працює. Але якщо з'їсти ковбасу з сиром недостатньо швидко, вони обветрятся і буде вже не той кайф.

Ну а прибравши середину (аналіз, розробка, тестування), отримаємо не сендвіч, а взагалі якесь хлібне непорозуміння.

Готуйте ваш Security Sandwich правильно.

І приємного апетиту!

Опубліковано: 15/11/19 @ 11:00
Розділ Різне

SEO Блог