Категорія: Кібербезпека

Уважно прочитав сьогодні “Загальні вимоги до кіберзахисту об’єктів критичної інфраструктури”, затверджені Кабміном 19 червня 2019 р. Якщо не маєте нагальної потреби, моя вам порада: не читайте. Це сміх, сльози та кров з очей. Я зробив це за вас: вважайте це жертвою, яку я приніс заради вашого психічного здоров’я.

---

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

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

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

---

Щоб не залишатися голослівним, давайте я наведу декілька найяскравіших прикладів непрофесіоналізму авторів “вимог”. По порядку.

Початок просто блискучій: таким чином, всі процеси автоматично вважаються критичними.

Як я неодноразово підкреслював, критична інфраструктура це те, без чого ми здохнемо, і те, що може нас вбити. Це найвища форма залежності суспільства та держави. Область, в якій немає ризиків, що можна прийняти без покарання. Тому казати, що критичними ми вважаємо процеси, реалізація загроз на які може заподіяти нам майнову шкоду, — це здійснити інфляцію слова “критичний” в усіх означеннях навколо поняття критичної інфраструктури. Таким чином все стає критичним, а отже критичним не залишається нічого. І це не помилка, далі в “вимогах” цей дух зберігається аж до кінця документу.

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

Далі ніби натяк на те, що вам дадуть вибір: будувати КСЗІ, або ж нормальну систему ІБ, аби ж твільки вона була дійсно номальна. Це непорозуміння далі в тексті виправляється декілька разів: таки ні, лише КСЗІ.

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

Далі перша згадка про оцінку ризиків. Оцінку. Ризиків. Оцінку ризиків, Карл! На об’єктах критичної інфраструктури! За допомогою настанов ISO27005.

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

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

В дев’ятому пункті нам дають надію: створювати КСЗІ та захищений вузол зв’язку на провайдерах – це дурість, і автори це розуміють. Але далі в тексті цю надію знищують.

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

Далі треш. Відвертий та жалюгідний навіть в порівнянні з рештою документу. Очевидно, це писав окремий “автор”, який не засвітився в документі раніше.

В автора цього абзацу в голові блокування, а не ІБ. Немає в кібербезпеці поняття блокування загрози! Нейтралізація загрози — це поцілити в хакера з дрону та розх***ити його на шмаття! Ось що таке блокування загрози. ІБ – це про ризики, та їхнє зниження до прийнятного рівня. Який в випадку справді критичної інфраструктури — дуже низький, але все одно він є. Вердикт: повна некомпетентність, навіть на рівні загальних означень. Стажер бухгалтерської фірми “великої четвірки” написав би краще.

Щойно було про блокування та нейтралізацію, а тепер про компенсаційні контролі! Скільки людей писали цей документ? Чому пункти конфліктують між собою? Хтось це зводив? Покличте редактора!

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

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

---

Під час призначення відповідального за кібербезпеку фахова освіта — не обов’язкова! Але їх буде надано перевагу.

Підпорядкування керівнику — круто. Тепер залишилося його навчити розуміти, про що говорить особа, відповідальна за ІБ. Хтось наслухався пісень про “хороші практики” організації ІБ, які культивуються бухгалтерськими фірмами. Але в дійсності ІБ повинна підпорядковуватися найвищій посаді, на якій сидить людина, яка хоч трохи на цьому знається. Чи це керівник об’єкту критичної інфораструктури? Дуже сумніваюся.

Знову згадування про оцінку ризиків на об’єктах КІ. Не буду повторюватись.

Далі до п. 7 – тупо робіть КСЗІ. А давайте сформуємо собі ринок на 5 років наперед? А давай! Навіть не буду наводити.

Пункт 7 про Політику, яка насправді не політика, а повний пакет нормативки по процедурах ІБ. Цікаво як вона закінчується: може. А може й ні?

Доведення “під підпис” взагалі фіговий спосіб підвищення обізнаності, але що значить “в інший спосіб”?

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

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

А згодом таке: всім використовувати багатофакторку. Але лише там, де вона є. Чи де її немає? Або використовувати скрізь багато факторів, але де є тільки два — то там два? Ось тут в мене вже сльози потекли.

Добрий ранок! Підвезли Secuirty Through Obscurity! А от просто взяти і виставити вимоги до імен та паролів неможна? Бо так же й зроблять як написано, і зупинять античні черв’яки з дев’яностих. А могли LAPS поставить і забити на це все. Ні! В України свій шлях!

Рукаліцо. А якшо ні то шо? Автор пробував примусити мережевий пристрій працювати без IP або MAC адреси? Як воно взагалі працює, ви не замислювались? Magic dust?

Ось тут одне з найшедевральніших формулювань, які я зустрічав в житті. Тобто – вічно!

Встановіть щось, щоб захищатися від маліварі, ШПЗ та вірусів. Але не переплутайте!

Наступний пункт наштовхує на думку, що десь на об’єктах критичної інфраструктури все ще існують мережі на хабах.

А тепер, мої шановні читачі, якщо стоїте, то присядьте, або візьміться за щось міцне. Увага…

Все. Я все. Збираю манатки і йду вчитися на комбайнера. Всі проблеми безпеки вирішено постановою Кабміну. Розходимось, хлопці та дівчата. Було приємно з вами мати справу.

“Як мінімум, захистіть все від зіродеїв.” Нонсенс за визначенням. Хіба що, як влучно помітив дехто з колег, це “заточка” під окремі “рішення безпеки”, які нахабно вихваляються такими фічами в своїх рекламних презентаціях.

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

І там далі ще є пункти, в яких йдеться про ці зони, але дані означення не використовуються. Вводиться Security-zone. Нафіга порядок в нормативці? Її потім важче порушувать.

Далі моє найулюбленіше. Хтось в госусі дуже давно вирішив, шо робити пентести в критичній інфраструктурі – це хороша ідея. Ідея це відверто ідиотська, в мережах такого гатунку пекнути бояться, не те шо пентести робити. Способи та методи оцінки захищеності таких мереж — це окрема дисципліна. Але ж то треба було зробити домашню роботу та вивчити питання. Автори “вимог” цього робити не стали.

Тобто, пентести вимагаються. І знахідки треба буде усувати. А кого усувати, якщо все успішно навернеться під час такого пентесту? А знаєте що, в мене є здогад, що не навернеться. Бо робити ці “пентести” будуть експерти Держспецзв’язку, які їх робити не будуть. Завіса.

Наступний пункт треба читати з особливим таким пафосом.

Це неможливо. Фізично. Організаційно. Культурно. Неможливо. Але давайте впишемо в вимоги. Будемо “нейтралізувати” всіх, хто не ввімкнув режим польоту на прохідній.

О, а тут (пам’ятаєте, я обіцяв) — пряма вимога підключатися до інтернет через провайдерів з КСЗІ. Браво! В двох місцях документу написані принципово різні речі.

Далі, в відмовостійкості. Тобто, два провайдери з КСЗІ. Масштаб зростає!

Далі в мене з очей потекла кров і мене забрали в швидку. Пам’ятаю лише, що в документі багато разів згадується про роль Адміністратора, яка ніде не визначається. Як і відповідальність за порушення цих вимог.

---

Висновки зробимо згодом і разом. Зараз хочу нагадати про те, що запропонована мною Рада кібербезпеки України повинна в першу чергу виявляти та виносити на публічне обговорення ось такі приколади знахабнілої некомпетентності в державних установах. Цей документ або не буде прийнято до уваги, або не буде реалізовано, або він зашкодить більше, ніж допоможе. Я не побоюся цих слів та зроблю припущення, що висловлюю думку більшості моїх колег: Це жахливо, жалюгідно та образливо.

Концепція

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

---

Проблематика

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

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

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

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

Джерело натхнення

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

1. Безпрецедентна ефективність Нідерландської моделі кібербезпеки в плані економічної доцільності. Дослідники економіки кібербезпеки наводять приклад голландського Національного ревю кібербезпеки як фреймворку для оцінки стану безпеки, який перевищує найпоширеніші міжнародні та галузеві стандарти, такі як ISO27001 або PCI DSS.
2. Тісні культурні та професійні зв’язки Нідерландів та України на тлі збройної агресії РФ, які значно прогресують з часів трагічної катастрофи рейсу MH17. Професійні спільноти Нідерландів та України ефективно обмінюються досвідом, а голландські спецслужби відіграють важливу роль в протистоянні російській агресії в кіберпросторі.

Мета

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

Основні напрямки діяльності РКУ:

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

Склад

З метою покриття якнайширшого спектру питань з кібербезпеки, склад РКУ складається із представників приватних та державних організацій в таких пропорціях:

• 6 представників державних установ – органів влади, державних та спеціальних служб, які здійснюють діяльність в галузі кібербезпеки. Державні службовці та функціонери, які дотримуються прогресивних поглядів щодо кібербезпеки та готові аргументовано доводити позицію держави в раді.
• 6 представників приватних установ — відомих та успішних українських комерційних компаній, які засновані в Україні та мають український капітал; та недержавних некомерційних організацій, які здійснюють діяльність в Україні. Іншими словами, офшори, дочірні іноземні компанії та осередки іноземних NGO в склад ради не допускаються.
• 3 представники освітніх та наукових закладів — авторитетних та прогресивних академічних установ, які здійснюють навчання спеціалістів в галузі кібербезпеки та проводять відповідні дослідження. Науковці та викладачі, які мають авторитет серед студентства, колег та професійної спільноти.

Перший склад ради формується шляхом проведення відкритого конкурсу. Члени ради визначають заступників, які можуть представляти їх у засіданнях ради. Члени ради та заступники обираються в РКУ щороку на один рік та не можуть засідати в раді довше двох років поспіль. Наступний склад РКУ визначається голосуванням за кандидатів 1/3 складу наприкінці року роботи ради. В перший та другий рік РКУ покидають 1/3 її членів, визначені випадковим жеребкуванням. (Таким чином 1/3 ради першого покоління буде змушена «відбути» три терміни.)

Рівень членства в РКУ — не статусний та не політичний, а професійний та функціональний. Члени ради та заступники повинні бути дійсними (протягом п’яти останніх років) практиками кібербезпеки, і це повинно підтверджуватися досвідом, рекомендаціями визнаних експертів, дослідженнями, виступами, публікаціями, престижними міжнародними сертифікатами тощо.

Секретар ради визначається РКУ щороку голосуванням на першому засіданні за поданням члена ради. Секретар не може суміщати роль члена ради або заступника.

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

Порядок роботи

РКУ проводить чергові засідання щомісяця. Участь в засіданнях — персональна або дистанційна за допомогою відео зв’язку із належними засобами захисту. Позачергові засідання ради проводяться за ініціативи не менш ніж трьох дійсних членів. Кворум засідання — 11 членів або заступників. У разі відсутності члена ради, заступники беруть участь та мають право голосу. Заступники також можуть брати участь в присутності відповідного члена ради, але право голосу зберігається за останнім. Рішення РКУ приймаються прямим чи таємним голосуванням простою більшістю.

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

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

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

Рішення ради

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

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

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

Рішення ради можуть виноситися на засідання інших державних органів України, таких як РНБОУ, КМУ, ВРУ тощо, із метою формування безпекового та політичного порядку денного української держави.

Інша діяльність

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

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

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

Морально-етичний бік такої поведінки дуже цікавий. З одного боку, здійснювати проникнення в цивільну інфраструктуру, навіть якщо вона належить або контролюється урядом, це трохи поза рамками status quo. Але ж РФ вийшла за ці рамки ще під час атаки на Прикарпаттяобленерго. Тому зважаючи на контекст, здається, все в рамках. Хоча, цілком можливо, що я упереджений. Як і більшість читачів цих рядків.

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

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

Але, при цьому звернення «по безпеку» від ІТ-компаній відбуваються трохи безсистемно і тут давайте зупинимось докладніше. Причина ховається в дуалізмі поняття про безпеку в будь-якій організації, яка створює інформаційні продукти або сервіси. З одного боку, є організаційна безпека: захист інформаційних систем та мереж, охорона інтелектуальної власності, виконання вимог місцевих та міжнародних регуляторів тощо. Тобто, захист інтересів бізнесу як сутності: щоб він не збанкрутував, а його керівники не сіли у в’язницю. З іншого боку, є безпека інженерна: захист власне продуктів та сервісів від зловживань неавторизованих осіб, захист користувачів та їхніх даних від наслідків таких зловживань, а також захист бізнес-моделі як від третіх осіб, так і від авторизованих користувачів (наприклад, ліцензування ПЗ або DRM). Тобто, захист продукту діяльності бізнесу та можливості його перетворити на прибуток.

Годі й казати, що ці дві “безпеки” є досить різними галузями знань. На жаль, цей факт відомий далеко на всім керівникам. Деколи це призводить до того, що за Application Security в компанії відповідають операційні ІБшники, що стає причиною купи непорозумінь та додаткового “тертя” в стосунках ІТ та бізнесу. Трохи рідше, програмістів з продуктової розробки обтяжують операційними завданнями — оце коли розгорається справжня драма. В казці із щасливим кінцем, в обох випадках всі дійові особи зрештою досягають консенсусу та розподіляють обов’язки більш-менш органічно. В протилежному разі, деколи доходить до робочих конфліктів, і тоді все залежить від дипломатичності та професіоналізму його учасників.

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

1. З’ясуйте, що ви захищаєте:
А: фірму, з усіма її активами, персоналом, фінансовими таємницями, від дій кіберзлочинців та наслідків дії законів та галузевих стандартів,
чи
Б: продукт/сервіс, який ця фірма виготовляє, від атак кіберзлочинців та зловмисних дій користувачів.

А.2. У першому випадку довіряйте виконання задачі спеціалістам з безпеки, які займаються технічним захистом інформації та організаційними заходами ІБ. Такі спеціалісти виходять, наприклад, з горнила кадрової кузні банківської системи, або з класичних ІТ-інтеграторів та дистриб’юторів. В минулому вони зазвичай працівники операційних підрозділів ІТ: системні та мережеві адміністратори. Деколи — працівники правоохоронних органів.
Ключові слова: CISSP, CISM, Information Security, Security Administration.

Б.2. У другому випадку довіряйте виконання задачі спеціалістам з безпеки програмного забезпечення. Такі спеціалісти менш поширені на ринку праці та володіють дещо іншими навичками. В минулому вони програмісти, тестувальники або ж розпочали кар’єру одразу ж в Application Security. Скоріш за все, вони беруть участь в програмах Bug Bounty у вільний час.
Ключові слова: OSCP, OSCE, Application Security, Bug Bounty, White-Hat Hackers.

А.3. Методичних рекомендацій та галузевих стандартів (тобто вказівок, як будувати безпеку, коли не знаєш, як це робити) у першому випадку навіть занадто багато. Скоріш за все ви матимете справу з ISO 27001, SOC 2, NIST, CIS або іншим фреймворком. Беріть це до уваги, коли обираєте виконавців та керівників операційної ІБ.

Б.3. Щодо безпеки ПЗ, тут рекомендацій теж вистачає, а ось із стандартами поки що все глухо (і на мою думку це добре). Рекомендації з безпечної розробки можна шукати по ключових словах OWASP, SAMM, SDL, NIST. Керівники функцій безпечної розробки повинні мати не лише образне уявлення про ці процеси, але й вміти їх ефективно впроваджувати та вдосконалювати.

А.4. Залучення зовнішніх консультантів до технічної та організаційної ІБ може відбуватися в багатьох форматах, але зазвичай це або побудова чогось швидше, ніж ви можете це зробити самотужки, або перевірка якості ваших заходів безпеки. Аудит та консалтинг в цій галузі досить прибуткові види діяльності, якщо ви розумієте про що я. Тому тут треба бути дуже уважними на всіх стадіях формулювання та виконання проєктів, адже скоуп розповзається з першого дня, а невраховані очікування можуть виявитися на завершальних стадіях.
Ключові слова: CISA, CISSP, ISO27001LA, ISO27001LI, Penetration Test, Security Audit.

Б.4. Залучення зовнішнього ресурсу до процесів безпечної розробки можливе майже на всіх стадіях побудови ПЗ за виключенням, хіба що, формулювання бізнес-ідеї. Дизайн, архітектура, планування, реалізація, тестування, міграція, підтримка, робота з інцидентами — всі ці та інші фази можуть виконуватися як власними силами, так і виноситися на аутсорс. Але є один момент: на певному етапі розвитку проєкту існування власної внутрішньої функції стане набагато ефективнішим та вигіднішим. Використання послуг незалежної перевірки/тестування безпеки та ad-hoc консалтинг, скоріш за все, доведеться залишити, але в ході розробки, вдосконалення та інтеграції продукту стане актуальним власний спеціаліст з безпеки ПЗ або навіть цілий підрозділ.
Ключові слова: OWASP, OSWE, OTG, ASVS, SAMM, Application Security Assessment, Application Penetration Test.

5. Розміщення підрозділу безпеки в організаційній структурі — окрема складна та драматична тема. Багато прихильників “хороших практик” управління безпекою наполягають, що підпорядкування CISO (Chief Information Security Officer) до CIO — погана ідея, адже таким чином виникає конфлікт інтересів: ІТ-директор наполягає на доступності та продуктивності систем та сервісів, коли керівник ІБ накладає на них купу обмежень. У випадку організаційної безпеки, можливо, це твердження і є доцільним, але коли мова йде про підпорядкування безпеки до CTO в продуктовій організації — конфлікт кудись зникає, адже саме СТО зацікавлений в безпеці сервісів та продуктів, що розробляються.

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