Процедури безпеки для ІТ

П - 19

версія 5.0

ТОВ "Бінотел"

Затверджено:

Генеральний директор

Корзун А.В.

09 грудня 2021 року

Переглянуто 14 лютого 2022 року

Переглянуто 23 лютого 2023 року

Переглянуто 23 лютого 2024 року

Переглянуто 23 лютого 2025 року

1. Терміни, абревіатури та скорочення

СУІБ – система управління інформаційної безпеки

КІБ – комітет з інформаційної безпеки.

Інформаційна безпека (ІБ) - означає різні процеси та заходи, що застосовуються для забезпечення конфіденційності, цілісності та доступності інформації.

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

Інформаційні системи – означають комп'ютерні системи, програмне забезпечення, телекомунікаційне та периферійне обладнання.

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

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

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

2. Призначення та сфера застосування

Метою цього документа є забезпечення правильного та безпечного функціонування інформаційних та комунікаційних технологій.

Цей документ визначає технічні та адміністративні процедури інформаційної безпеки, які застосовуються до ІТ-інфраструктури компанії. Політика відповідає вимогам ISO/IEC 27002:2022, розділ 8. Вона охоплює процеси резервного копіювання, журналювання, сегментації, криптографії, безпечної розробки, фільтрації та утилізації інформаційних активів.

Процедура застосовується до всіх співробітників / підрядників ІТ-підрозділу (далі «Компанія»).

3. Нормативні посилання

Політика розроблена відповідно до вимог чинних нормативних документів:

Міжнародний стандарт ISO/IEC 27001:2022 «Інформаційні технології. Методи захисту. Системи управління інформаційною безпекою. Вимоги»;
Міжнародний стандарт ISO/IEC 27002:2022 «Інформаційні технології. Методи захисту. Кодекс практик з управління інформаційною безпекою».

4. Процедури безпеки

Резервне копіювання (8.12)

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

Моніторинг подій та журналювання (8.16)

Критичні ІС ведуть журнали доступу, змін, системних помилок та аномальних дій.
Відстеження ведеться у реальному часі через централізовану систему моніторингу (SIEM).
Щомісячний аналіз логів оцінюється членами КУІБ.
Логи зберігаються не менше 6 місяців, з обмеженим доступом.

Сегментація мережі (8.21, 8.22)

Внутрішня мережа поділена на зони: офісна, серверна, DMZ, тестова.
Між зонами застосовуються Access Control Lists (ACLs) та правила фаєрволів.
Доступ дозволяється лише за принципом найменшого привілею.

Фільтрація веб-доступу (8.23)

Усі підключення до Інтернету здійснюються через корпоративний проксі з функцією URL-фільтрації.
Заборонено доступ до ресурсів, пов’язаних з азартними іграми, піратством, соцмережами (крім службових).
Журнали активності користувачів зберігаються протягом 3 місяців.

Криптографічний захист (8.24)

Усі зовнішні підключення шифруються протоколами TLS 1.2 або вище.
Для резервного копіювання, електронної пошти та VPN використовується сертифіковане криптозабезпечення.
Облікові дані зберігаються в хешованому вигляді (bcrypt або SHA-256).

Безпечна розробка (8.25)

У внутрішніх застосунках впроваджено захист від SQL-ін’єкцій, XSS, CSRF.
Весь код проходить перевірку: peer-review та сканування статичним аналізатором безпеки.
Аутентифікація реалізується через токени з обмеженим строком дії.

Контроль сторонніх компонентів (8.28)

Заборонено використання модулів, бібліотек чи скриптів із неофіційних джерел.
Компоненти перевіряються за допомогою автоматичних сканерів (OWASP Dependency Check, Snyk тощо).
Оновлення компонентів відстежуються через публікації CVE та плануються не рідше одного разу на місяць.

Утилізація інформації (8.31)

Перед утилізацією всі пристрої проходять процедуру очищення даних (wipe) з багатократним перезаписом.
У випадку фізичного знищення — складається відповідний акт.
Відповідальність за процес несуть ІТ-відділ та КУІБ.

4.1. Управління змінами

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

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

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

Аудит безпеки повинен проводитись після всіх аварійних змін.

Нормальна зміна - будь-яка зміна послуги, яка не є стандартною або екстреною.

Зміни в ІТ-інфраструктурі повинні відповідати таким вимогам:

1. Кожна зміна має ініціюватися запитом щодо внесення змін.

2. Впровадження змін має бути схвалено власником Сервісу, який має оцінити бізнес-обґрунтування та можливі негативні наслідки для ІБ.

3. Зміни повинні впроваджуватись адміністраторами, які повинні заздалегідь повідомити про ці зміни усі зацікавлені сторони.

4. Адміністратор несе відповідальність за перевірку того, чи були внесені зміни відповідно до вимог.

5. Адміністратор відповідає за тестування та перевірку стабільності системи. Зміни можуть бути реалізовані лише після ретельного тестування.

6. Після впровадження змін слід повідомити ініціатора зміни та усі зацікавлені сторони.

7. Усі записи, що стосуються змін, повинні бути захищені від зміни та видалення.

4.2. Резервне копіювання та відновлення резервних копій

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

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

Адміністратор резервного копіювання відповідає за резервне копіювання інформаційних систем.

Резервні копії повинні зберігатися у безпечних місцях (фізичних чи цифрових) відповідно до вимог Компанії щодо безперервності бізнесу.

Резервні копії повинні містити всі необхідні дані для відновлення інформаційних систем (ОС, програми та файли конфігурації) та бізнес-даних.

Журнали процесу резервного копіювання повинні створюватися автоматично в системах, де створюється резервна копія.

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

Адміністратор резервного копіювання відповідає за тестування резервних копій. Необхідно вести запис про тестування резервних копій.

4.3. Управління безпекою комп'ютерних мереж

Компанія дотримується наступних принципів побудови, керування та використання комп'ютерної мережі:

4.3.1. Забезпечення доступності мережі

Резервування. Завжди, коли це необхідно і можливо, обладнання та канали зв'язку мають дублюватись. Мережева надмірність має бути побудована з урахуванням вимог SLA компанії та бізнес-вимог.

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

4.3.2. Сегментація та мережна адреса

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

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

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

4.3.3. Принципи управління мережею

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

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

Одноманітність адресації. Мережеву адресу, системи та обладнання слід обирати централізовано із приватного діапазону мережевих адрес.

4.3.4. Принципи мережевої безпеки

рівні. Вимоги безпеки сегмента мають відповідати серйозності його інформаційних активів.

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

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

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

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

4.3.5. Поділ середовищ розробки, тестування та експлуатації

Засоби розробки, тестування та експлуатації повинні бути розділені, щоб знизити ризики несанкціонованого доступу або змін в операційному середовищі.

Слід враховувати такі моменти:

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

програмне забезпечення для розробки та виробництва повинно працювати на різних системах або комп'ютерних процесорах та в різних доменах або каталогах.

зміни у виробничих системах та додатках повинні бути протестовані у тестовому чи проміжному середовищі, перш ніж вони будуть застосовані до виробничих систем.

крім виняткових обставин, тестування має проводитися на виробничих системах.

компілятори та інші інструменти розробки або системні утиліти не повинні бути доступні з виробничих систем, коли вони не потрібні

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

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

4.4. Логування та моніторинг

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

Журнали подій повинні включати, якщо необхідно:

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

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

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

4.5. Синхронізація часу

Час усіх відповідних систем обробки інформації у Компанії або домені безпеки мають бути синхронізовані з одним еталонним джерелом часу.

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

4.6. Управління вразливістю

Процедура керування уразливістю охоплює всі мережі, сервери та інші ІТ-активи.

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

Часовий інтервал сканування визначається ІТ-адміністраторами, відповідальними за сканування систем. Сканування заплановане на неробочий час мінімального впливу на продуктивність. Звітність із зазначенням рівнів ризиків складається після кожного сканування. Звіт готується та розсилається адміністраторам ІТ-систем. Встановлення патчів регулюється ІТ-адміністраторами і впроваджується пізніше місяця, з дати їх виходу, якщо такий перехід не зачіпає безперервність сервісів Компанії.

5. Перегляд документа

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

Підписати ознайомлення з документом