UAppSec
374 subscribers
59 photos
2 videos
7 files
61 links
Трохи про апплікєйшн сек'юріті та світ навколо нього. Авторський блог Віталія Балашова.
Download Telegram
Channel created
Channel name was changed to «AppSec оборона»
Доброго дня, еврібаді

Стартую свій авторський блог. Про безпеку додатків. Максимально професійно. Принаймні намагатимуся, а там вже як вийде.
Маю надію, що нотатки з мого досвіду допоможуть комусь підвищити свою кваліфікацію та зробити ваш софт та інфру безпечніше, стійкіше та надійніше.

Поїхали!
Як зрозуміти поточний стан справ?

Поширена практика для визначення стану безпеки софтварного продукту - використовувати пентест чи якісь схожі на нього аудити. Пентест не є аудитом, пентест є різновидністю тестування. Загальну ж оцінку слід проводити за чимось більш призначеним для цього. Наприклад за існуючими моделями зрілості продукту (SAMM, BSIMM, тощо) або на відповідність якимось галузевим стандартам (ISO 27001 або більше специфічні).
Вже згаданий пентест є складовою будь-якої моделі зрілості чи вимогою більшості галузевих стандартів.

Надалі розпочинаємо серію постів про детальну роботу із SAMM, BSIMM, ASVS та іншими стандартами.
Channel name was changed to «AppSec Оборона»
SAMM - Software Assurance Maturity Model

Моделі зрілості - це такі собі колекції вимог до продукту (чи чогось ще). Відповідність даним вимогам або їх частині дозволяє надавати певну оцінку продукту і формувати подальшу стратегію, і, як наслідок, тактику поведінки з цим продуктом.
Моделі зрілості доволі часто передбачають рівні, на які можуть виходити продукти, що спрощує сприйняття загальної оцінки та не вимагає від нетехнічного менеджменту глибоко занурюватись у "ті ваші технічні штуки". Пізніше ми розберемо декілька моделей та порівняємо їх, але зараз почнемо із OWASP SAMM.

Перш за все SAMM - це модель зрілості життєвого циклу софта (SDLC). Тобто SAMM передбачає, що ви розроблюєте свій продукт та обслуговуєте його, а не лише роздеплоїли готовий. Хоча і у цьому випадку можна використовувати відповідну частину SAMM.

Якщо вам треба якось довести замовнику, що ви дотримуєтесь кращих практик безпечної розробки - не кажіть йому про OWASP top 10. Кажіть йому про OWASP SAMM.

Уся модель повністю відкрита та доступна на офіційному сайті проекту: owaspsamm.org
Там же можна знайти вже готовий формуляр для проведення первинного асесменту на відповідність моделі. Можете ознайомитися за матеріалами сайту самостійно, поки я готую наступний пост. Будемо проводити асесмент разом :)

#SAMM
Приклад автоматично порахованого результата асесменту. Тобто поточний стан безпеки вашого продукту за SAMM-ом та прогрес у кожному з доменів розділений по фазах проведення робіт.

#SAMM
Як користуватися excel таблицею для інтерв'ю

Дуже зручно, прозоро та ефективно використовувати excel-таблицю, що розповсюджується через офіційний репозиторій OWASP SAMM. На перший погляд вона трохи складна, але це лише на перший погляд. Та й взагалі, ласкаво просимо до професії, де усе складно.

Перший лист таблиці суто титульний. Можете дізнатися щось про авторів.

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

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

Scored та Roadmap Chart формуются автоматично і вам не треба там щось змінювати. Лише отримувати наглядну інфу про стан речей.

Roadmap слід використовувати для відслідковування інкременту стану безпеки. Іншими словами - прогрес роботи. Просто заповнюйте інтерв'ю ще раз але тепер у колонках для фази 2, потім для фази 3 и і т.д.

#SAMM
Так виглядає Score Card та інтерв'ю листи у згаданій вище ексельці. Дуже зручно. Транслювання ситуації у вимірювальні величини є правильним шляхом для конструктивного розвитку. "Не можешь виміряти - не контролюєш" (с) десь чув

#SAMM
Структура моделі OWASP SAMM

Модель ієрархічно складена із:
- бізнес функцій - найвищий рівень. Всього п'ять.
- Практик безпеки - по три в кожній бізнес функції
- Рівнів зрілості - по три для кожної практики
- Потоків - по два для кожної практики

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

#SAMM
Governance | Strategy & Metrics | Create and Promote | L1

Кажуть що починати завжди правильно з початку. То ж давайте розглянемо усі можливі пункти моделі OWASP SAMM у деталях, починаючи з самого початку. А саме - бізнес-функція Governance, Практика безпеки - Strategy & Metrics, Потік - Create and Promote рівень зрілості - перший.

Перший рівень для цього потоку можна описати як "загальне розуміння стану безпеки вашої організації". Головна робота, яку ви маєте виконати, це отримати розуміння ризиків, які існують на рівні організації чи бізнесу. Це саме про бізнес ризики, бізнес загрози та бізнес цілі. Поки що не про технології. Як це зрозуміти? Легко (насправді - ні) - поговорити про це з керівниками бізнесу. Ніхто краще за них не може розуміти цих речей. Якщо вони не здатні відповісти на питання стосовно ризиків бізнесу, краще обновіть профайл у LinkedIn, але поки що не звалюйте з контори. Може ви це виправите. Але профайл обновіть.

Розробники моделі надають нам допомогу у підготовці до інтерв'ю ваших босів. Ви маєте отримати відповідь на питання "чи розумієте ви ризик-апетит у масштабі організації для вашого програмного забезпечення?".

Для того, щоб краще орієнтуватися у питанні, автори моделі надають нам так звані "критерії якості" відповіді на питання. У вас все добре якщо:
1. Ви отримуєте ризик-апетит керівництва вашої організації
2. Керівництво організації ветує та підтверджує набор ризиків
3. Ви ідентифікуєте найбільші бізнесові та технічні загрози вашим активам та даним.
4. Ви документуєте ризики та зберігаєте їх у доступному місці

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

Тут треба зазначити, що варіант відповіді надається на виділене жирним шрифтом питання, а не на кожний із
критеріїв.

Що автори мали на увазі під можливостями, я все ще не второпав, але цю відповідь слід обирати, коли ви максимально круті.

Складно взагалі щось це не про ту безпеку, де ви хотіли зламувати Пентагон та керувати транспортною системою росіян?
От у вас це і не вийде так просто, бо тамошній стафф робить подібні вправи з аналізу ризиків. Так шо, го розбиратися з ризик апетитом у наступних постах.

#SAMM
Risk appetite - що за шняга та як порахувати

Чесно кажучи, самому довелося пірнати в тему та розбиратися. Але то було корисно.

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

Певне дивування викликає слово "хоче". Звісно, що не хочемо ми ніякого ризику, хочемо щоб цілі самі виконалися. Але нафіга тоді ви у цій схемі? Бізнес без ризику не існує. Нормальний менеджер повинен порахувати скільки ризику він вимушений хотіти виходячи із цілей, які він хоче досягнути. Також він має враховувати ще дві невід'ємні від ризик-апетиту метрики:
- Толерантність до ризику - це рівень одного конкретного ризику, не сумарне значення, а саме одного, який організація може собі дозволити без особливих напрягів. Типу, якщо сторож Петрович забухає й не прийде сьогодні знову спати за гроші у офіс, наша безпека буде знижена, росте ризик пограбування. Але в нас є система сигналізації і мобільна бригада прилетить за 2 хвилини по SLA. Ми толерантні як до хоббі Петровича, так і до ризику, що виникає внаслідок.
- Ємність ризику - сумарний об'єм ризиків, що може собі дозволити організація і не здохнути. Це десь на грані. Тобто перевищення цього значення нанесе неповоротні наслідки конторі і, можливо, дупі топ-менеджера.

Як ми розуміємо, якщо апетит ризику перевищує ємність, то треба підійти до дзеркала і запитати себе "А не дохєра ти на себе береш?". 99% гарантії провалу із 1% запасу на диво, прорахунок, та лоховський фарт.

Загалом усі ці показники слід враховувати для керування на стратегічному рівні. Вони допомагають приймати рішення безпечніше.
Як оцінювати ризики, то вже інша історія і відповідний ISO 31000 пропонує понад 40 методів оцінки. Кожний із своїми плюсами і мінусами, а значить більш підходить до своєї певної ситуації. В цілому там величезний пласт інфи від якого хочеться плакати.

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

USAID - Risk-appetite Statement 2018
Office of the Comptroller of the Currency
Risk Appetite Statement - Nordic Investment Bank
Risk Appetite Statement and Guidelines - Bank of Cyprus
Central Bank of Ireland

#SAMM
👍2