Автор: Андрій Михалюк, CEO CoreWin
Одним з ключових питань в сучасному цифровому світі є безпека програмного забезпечення, а відтак і даних та систем. Софт відрізняється технологіями, використаними в його написанні, але окрім технологій є ще одна одвічна відмінність — чи є код відкритим, безкоштовним. Оскільки технології змінюються, а природа інтелектуальної власності залишається незмінною, суперечка триває десятиліттями як серед спеціалістів, так і серед академіків: що безпечніше, відкритий чи закритий код?
Спершу, спростуємо 3 основних міфи про відкритий код:
- Будь-хто може прочитати відкритий код і скористатись вразливостями.
Хоча відкритий вихідний код в принципі можна прочитати та скомпрометувати, на практиці ситуація набагато складніша. По-перше, людям, які зламують програмне забезпечення, насправді не потрібно дивитися вихідний код. Для досвідченого хакера немає потреби копатися в тисячах рядків коду, щоб знайти вразливість. Зловмисники скоріш зосереджуються на тому, що виконує програма, а не на тому як саме вона написана. По-друге, той факт, що будь-хто має доступ до коду, насправді збільшує шанси знайти помилки та вразливості.
- Відсутність фінансових стимулів означає відсутність мотивації для забезпечення безпеки FOSS.
Насправді багато успішних продуктів з відкритим кодом стали прибутковими для команд, які їх створюють. Наприклад, Mozilla отримує значну частину доходу від Firefox за кліки користувачів на оголошеннях на сторінках пошуку. А Wazuh заробляє на підтримці, платних налаштуваннях та навчаннях. Більшість проєктів такого калібру мають власні групи реагування на безпеку, які займаються виправленням вразливостей.
- Закрите програмне забезпечення за своєю суттю є більш безпечним, ніж програмне забезпечення з відкритим кодом.
Цей міф походить від багатьох упереджень. Але закритість коду (чи його відкритість) не гарантує відсутність недоліків в ньому. На відміну від пропрієтарного програмного забезпечення, проєкт з відкритим кодом є прозорим щодо потенційних вразливостей. З платним софтом контроль за виявленням і виправленням помилок здійснює команда розробника. За допомогою FOSS ви також можете взяти участь у перевірці коду, а потім або залишитися з попередньою версією, випустити власний патч або навіть вимкнути певні функції.
Ключові елементи підвищення безпеки
Оскільки відкритий та пропрієтарний код, пакети та системи потребують однакових технічних та організаційних засобів захисту, зазвичай державне регулювання їх безпеки не відрізняється. Хоча особливості кожного інциденту кібербезпеки можуть бути різними, їх предметна суть незмінна – від атак ланцюга постачання до інфікування шкідливим кодом. Спільнота кібербезпеки регулярно оновлює рекомендовані найкращі практики на основі нової інформації, що вимагає постійної пильності, аналізу та перевірки наявного коду та компонентів. Виходячи з цього, спільнота все більше схиляється до такого консенсусу: не настільки важливо чи рішення має відкритий, чи закритий код, важливо які роботи виконані для підвищення безпеки. Ці зусилля можна розділити на два ключові елементи:
- Робота над безпекою команди розробки, контролю якості та підтримки. Тобто не лише наявність ресурсів, та нормальної швидкості виправлення вразливостей, але і наявності ефективної команди підтримки та контролю якості, що виявляють недоліки.
- Робота над безпекою конкретної системи та конкретного впровадження. Оскільки не буває теоретичної системи в вакуумі та всі інформаційні системи працюють лише у взаємодії з іншими системами та користувачами – це вимагає контролю безпеки на рівні кожного конкретного впровадження.
Можливі ризики
Занурюючись глибше в тему, безкоштовні системи з відкритим кодом (FOSS) мають ключову особливість: активна спільнота, яка попереджає та виправляє вразливості. Однак часто спільнота, що супроводжує код не працює за контрактом і не отримує оплату за свою роботу. Це несе певний ризик у двох аспектах:
- Використання FOSS системи, як компонента власної інфраструктури, приміром, SIEM з відкритим кодом. Тут варто вивчити питання та виявити чи є у цієї системи ядро розробників та команда, яка працює платно і професійно над цим рішенням. Це говоритиме про те, що є контроль якості та наявні політики перевірки безпеки та пріоритетності в їх усунені. Прикладом таких команд можуть бути Wazuh чи RedHat. Якщо ж це рішення написав студент, його підхопили нічим не пов’язані люди та працюють над ним не професійно та безоплатно – ризикованість використання такого рішення різко виростає.
- Безкоштовні компоненти та бібліотеки. У рішеннях з закритим кодом використовуються як безкоштовні, так і платні сторонні компоненти та бібліотеки. Не є комерційно ефективним писати все програмне забезпечення з нуля, а вигідніше зосередитись на інноваціях та використати здобутки інших організацій. Обравши FOSS, ви зможете відкрито провести аналіз, інвентаризацію всіх сторонніх компонентів. Ці рішення відкриті. Їх компоненти переглядає і основна команда, і спільнота, і користувачі.
Висновок
Висновок, який випливає з останньої тези, — рішення з відкритим та закритим кодом більш пов’язані, ніж здається на перший погляд.
До цього ж прийшли дослідники зі спільноти DevSecOps. Їх додатковий висновок: таємність коду програми напряму не впливає на кількість наявних вразливостей, а його відкритість не підвищує його ризикованість. Тобто очевидним є те, що закритість чи відкритість коду не впливає прямо на кількість помилок у ньому, вирішальним фактором є лише докладені зусилля та їх ефективність.
Joe Brockmeier у своїй статті «Міф про безпеку з відкритим кодом» приходить до такого висновку: «Отже, чи безпечне програмне забезпечення з відкритим кодом? В абсолютному вираженні жодне програмне забезпечення не повинно вважатися вільним від вразливостей. Але, якщо говорити відносно, я б сказав, що так».
Ми бачимо, що кордони між відкритим і закритим кодом стираються. З одної сторони компанії, які володіють закритим кодом, все більше намагаються знайти компроміс та отримати переваги рішень FOSS, приміром, всі технологічні гіганти мають bug hunting політику. Рішення ж FOSS перестали бути студентськими проєктами, їх підтримують повноцінні компанії та команди. Деякі стартапи одразу вирішують відкрити свій код і працювати в цій моделі.
Вкрай важливим у сучасному світі є ефективне використання ресурсів, як інтелектуальних, так і фінансових. Тому з описаного вище можна зробити такий висновок. Безкоштовного програмного забезпечення не існує, є лише з відкритим кодом. В будь-якому випадку систему треба налаштовувати, перевіряти, доопрацьовувати. Тому обов’язково потрібно звертати увагу на:
- Наявні функції.
- Рівень підтримки.
Вартість ліцензії сама по собі не є корисною вартістю, має значення скільки підтримки і які функції ви отримаєте з купівлею ліцензії.
