Шпаргалка з кібербезпеки для розробників

Мене звуть Микола Мозговий, я старший розробник і ментор в Sigma Software. Зараз займаюся розробкою хмарного бекенду для кліматичних систем.

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

Для таких випадків непогано мати нагадування чи шпаргалку, тому я склав список питань, яким потрібно приділити увагу. Цей список і не короткий, і не є вичерпним, але, принаймні, він є цілком зрозумілим і здійсненним. Повинен зізнатися: на поданий нижче матеріал мене надихнув один дуже хороший курс, який я проходив кілька років тому і який рекомендую всім, кого цікавить питання InfoSec/Cybersecurity. Це курс Software Security від Університету штату Меріленд, вільно доступний на Coursera.

Особливості безпеки

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

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

Властивості безпеки

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

конфіденційність (Confidentiality) — означає, що інформація повинна передаватися неавторизованим особам;
цілісність (Integrity) — збережена інформація не повинна бути пошкоджена внаслідок втручання неавторизованих осіб або системних збоїв;
доступність (Availability) — тобто система повинна завжди реагувати на запити (у рамках узгоджених вимог).

У той час як доступність інтуїтивно асоціюється з захистом від DoS-атак , вона ними не вичерпується. Є завдання не меншої важливості:

апгрейди додатків;
продовження прав на IP-адресу;
продовження прав на доменне ім'я;
поновлення сертифікатів шифрування і аутентифікації.

Кожен раз, коли порушуються властивості безпеки, програмне забезпечення вважається вразливим .

Уразливість (Vulnerability) — це пов'язаний з безпекою дефект програмного забезпечення, який можна використовувати для досягнення небажаного поведінки. Якщо вразливість викликана дефектом дизайну, а не коду, вона називається вадою , або проломом (Flaw).

Принципи безпеки

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

Запобігання (Prevention) — вичерпне усунення дефектів. Наприклад, можна запобігти цілі категорії дефектів, використовуючи мови, безпечні для пам'яті, такі як Java або C# замість C/C++.
Пом'якшення (Mitigation) — зменшення шкоди від експлуатації невідомого дефекту. Наприклад, шкоду від зламаної бази даних можна значно зменшити, якщо зашифрувати збережені дані. Ще один приклад — блокування облікових записів з підозрілою поведінкою і вимога додаткового підтвердження для потенційно небезпечних дій.
Виявлення (Detection) — виявлення і аналіз атаки (тобто моніторинг). Необхідно якомога швидше отримувати інформацію про потенційно шкідливих діях. В цьому випадку дуже допомагає комплексна телеметрія в реальному часі.
Відновлення (Recovery) — нейтралізація шкоди. «Швидко підняте не вважається впало». Тому завжди необхідно мати резервну копію даних і додаткові ресурси, які будуть доступні в разі екстреної необхідності. Крім того, вкрай важливо мати процедури відновлення зламаних облікових записів.

Нижче наведені основні принципи, яких потрібно дотримуватися при розробці, впровадженні або обслуговуванні програмного забезпечення.

Віддавайте перевагу простоті (Favor simplicity — prevention).

Вибирайте просту архітектуру. «Keep it simple, stupid» — цей відомий мем прекрасно працює в цьому контексті. Наприклад, подумайте двічі, коли ви вибираєте між старомодним монолітом і сверхкрутыми микросервисами. Завжди враховуйте наявні можливості і досвід.
Застосовуйте безпечний вибір за замовчуванням (fail-safe defaults). Ніколи не використовуйте паролі, видані за замовчуванням, застосовуйте стандартну криптографію, віддавайте перевагу білим списками, а не чорним і т. д.
Не чекайте просунутого користувача. Чим більше можливостей ви даєте, нічого не обмежуючи, тим вище ймовірність зловживання ними. Наприклад, установка додатків з ненадійних джерел на Android (файли АПК) потребує активації цієї функції у налаштуваннях пристрою.
Віддавайте перевагу простому інтерфейсу користувача (UI). Повторюся, складність — ворог безпеки. Складний UI підвищує ймовірність помилок як з боку розробника, так і з боку користувача.
Не дозволяйте користувачам робити вибір щодо безпеки. Ви не повинні припускати, що користувачі розуміють схеми криптографії або хоча б правила безпечної поведінки в інтернеті, тому не дозволяйте їм обирати алгоритми та ключі шифрування або небезпечні паролі.

Довіряйте з обережністю (Trust with reluctance — prevention & mitigation).

Використовуйте мінімальну довірену обчислювальну базу (trusted computing base ). Чим більше компонентів — як апаратних, так і програмних має система, тим більше можливих напрямів для атак. В цьому сенсі кожна нова платформа, яку ви збираєтеся підтримувати, і кожен сервіс, який ви інтегруєте, повинні розглядатися як джерела ризику і небезпеки.
Уникайте застосування вашої власної криптографії. Криптографія — це настільки нетривіальний предмет, що спроба реалізувати її аспекти самостійно не більше ніж марнославство, якщо, звичайно, ви не є експертом. Правильний підхід полягає у використанні відкритих, стандартних для галузі протоколів і алгоритмів.
Максимально обмежуйте повноваження для компонентів і користувачів. Будьте обережні при наданні прав своєму додатком і користувачам (навіть непрямим чином). Вашій додатком дійсно потрібен доступ до файлової системи? Точно потрібно виконувати операції читання з бази даних під обліковим записом з більш високим рівнем доступу?
Валідація вхідних даних . Не згодовуйте вашій системі некоректні дані. Чітко визначте межі коректності даних і перевіряйте їх, використовуючи білі списки .
Підсилюйте конфіденційність — обмежуйте доступ до персональних даних.Формальне визначення персональних особистих даних може відрізнятися в залежності від місцевого законодавства, але загальна характеристика особистих даних — це пряма або непряма можливість визначити, яким особі ці дані фактично належать.
Відокремлення (compartmentalization) — використовуйте процеси, контейнери і «пісочниці», щоб відокремити компоненти і навіть операції один від одного.

Захист в глибину (Defense in depth — prevention, mitigation & recovery).

Безпека в силу різноманітності (HTTPS + безпечний мова + шифрування даних + VPN). Об'єднайте всі механізми безпеки, наявні у вашому розпорядженні. В той же час не використовуйте інструменти поза своєю компетенцією, а при необхідності знайдіть експерта.
Використовуйте стандартні та відкриті рішення. Уникайте принципу «безпека через неясність» (security through obscurity ). Позбавтеся від думки, що пропрієтарне програмне забезпечення або протоколи (особливо ваші власні) забезпечують захист лише на тій підставі, що вони нікому не відомі. Тільки загальнодоступні і вивчені інструменти та протоколи можуть претендувати на безпеку.

Моніторинг та відстеження (Monitoring and traceability — prevention & recovery).

Збирайте логи і телеметрію. Не забувайте встановити оповіщення при виявленні небезпечних/підозрілих подій.
Створюйте резервні копії/знімки стану (snapshots). Зберігайте їх на окремих серверах і розробляйте механізми їх відновлення.

Звичайно, можна вивести більше число подібних принципів, але, як правило, достатньо буде слідувати вже певним.

Безпечний процес розробки

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

Вимоги:

Визначте вимоги до безпеки (сценарії порушення, abuse cases). Сценарій порушення — протилежність сценарієм використання (функціонального вимоги, use case). Він чітко визначає, що система не повинна робити.
Визначте необхідні властивості безпеки для компонентів системи (тобто конфіденційність, цілісність, доступність). Просто позначте, які частини збережених даних є конфіденційними. Визначте, які ролі присутні в системі і з даними вони повинні працювати. Опишіть вимоги до доступності.
Визначте механізми безпеки для підтримки цих властивостей (аутентифікація, авторизація, аудит — три Au). Наявність механізмів цих трьох Au вважається золотим стандартом безпеки. Система не може бути безпечною, якщо в ній відсутній один з них.
Моделюйте загрози. Це означає необхідність визначення шкідливого агента і можливих видів атак (наприклад, це може бути мережевий трафік, локальні файли чи навіть відображаються дані тощо).

Розробка:

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

Реалізація:

Дотримуйтеся кращих практик написання коду.
Проводите обов'язкові рев'ю коду.
Застосовуйте інструменти автоматизації для забезпечення найвищої якості коду:

Тестування:

Тестування на основі ризиків .Ці тести націлені на найбільш критичні частини системи, визначені за допомогою моделювання загроз.
Випробування на проникнення . Фахівці з безпеки відіграють роль зловмисника, намагаючись подолати механізми безпеки.
Фаззинг . Навмисне введення в систему випадкових і некоректних даних часто може допомогти виявити небажану поведінку.

Поширені вади проектування і реалізації

Дотримуючись безпечного процесу розробки, завжди пам'ятайте про помилки, які часто допускають розробники:

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

Саме це є джерелом горезвісних впроваджень SQL-коду , XSS-атак і віддаленого виконання коду .

не проводити валідацію даних;
невірно використовувати криптографію;
неправильно ідентифікувати конфіденційні дані;
інтегрувати зовнішні компоненти без урахування загрози з їхнього боку;
жорстко обмежити майбутні зміни вихідного коду і конфігурації.

OWASP і топ-10 вразливостей

Open Web Application Security Project (OWASP) — це некомерційна організація, орієнтована на підвищення безпеки програмного забезпечення. І ви можете знайти відмінне застосування її ресурсів. Ця організація надає корисні рекомендації та «шпаргалки» для популярних платформ розробки, таких як .NET і Java .

OWASP в першу чергу відома своїми списками «топ-десяток», що описують найбільш поширені уразливості в різних доменах:

Вкрай важливо добре знати поширені уразливості свого домену. Попереджений — значить, озброєний.

Висновки

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

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

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

SEO Блог