В Європі CISSP прирівняли до магістрського ступеню

Трохи дивна новина, поясню чому.

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

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

Другий шлях простіший – ви записуєтесь на один з безлічі «таборів з підготовки» (CISSP boot camp), проводите в ньому близько тижня, там вам в голову «заливають» необхідний для здачі мінімум знань, після чого садять за комп і через дві години ви майже CISSP. А через чотири – вже майже нічого з того не пам‘ятаєте.

Пишу майже, бо в обох сценаріях вам тепер треба знайти хто б з дійсних CISSP-ів підписав вам рекомендацію (endorsement), але це вже бюрократія. Після успішного ендорсменту вам надходить сертифікат, і тепер ви – раб лампи, адже щороку мусите його продовжувати за гроші.

Сподіваюся, я склав враження про те, скільки зусиль та знань треба, щоб отримати CISSP. А, ще одне – обов‘язковою вимогою є 5 років практичного досвіду в професії кібербезпеки за деякими знижками по типу профільної освіти.

І ось це тепер в Європі – еквівалент магістра. Чи справедливо це, вирішуйте самі. Моя справа – дати вам вхідні дані.

Поділитися:
Posted on Categories КібербезпекаTags CISSP, Навчання, Сертифікати2 Comments on В Європі CISSP прирівняли до магістрського ступеню

Знову про сертифікати

Другий день зачитуюсь в Kostiantyn Korsun в коментах, як люди без жодного професійного сертифіката з кібербезпеки дискутують про їхню потрібність чи непотрібність. Чесно, думав що ці часи в минулому, але ніколи не кажи ніколи. Тому спробую пояснити свою позицію, яку я напрацював у глобальному диспуті на цю тему. Адже ні для кого не секрет, що українська спільнота кібербезпеки переживає ті самі срачі, що й західна професійна тусовка, але із запізненням в 5-7 років.

The burning CISSP certificate
The burning CISSP certificate. Boris “Jaded Security” Sverdlik.

Отже, по-перше: професійні сертифікати з кібербезпеки не мають стосунку до вендорських сертифікатів. Навіть якщо вендор з кібербезпеки. Навіть якщо сертифікація дуже об‘ємна, іспит складний, та вимагає неабиякого практичного досвіду. Сертифікати вендорів – це артефакти системи контролю якості доставлення їхніх продуктів та сервісів уздовж ланцюга постачання. Іншими словами, щоб некваліфіковані та недосвідчені люди не стали на перешкоді бізнес-моделі вендора. Фарбу там не подряпали, не в ту розетку штекер не встромили тощо.

Звісно, я тут трохи накидую на фен, адже топові вендорські сертифікати вимагають фундаментальних знань з базових технологій, системної інженерії, архітектури тощо. Але колись давно я мав задачу в рекордні терміни провести близько 50 співбесід з потенційними архітекторами безпеки, половина з яких була обвішана шпалерами з логотипами Cisco, IBM, RSA, Microsoft, CheckPoint, McAfee… Я мав тоді на ці заходи дуже небагато часу, тому моїм першим питанням було: «Існує 10 фундаментальних принципів побудови захищених систем. Назвіть 3 з них». Таким чином я відфільтровував для продовження співбесіди 2 з 10 кандидатів.

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

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

І ми не маємо манери приховувати ці думки від наших колег, які з того цілком логічно роблять висновки, що нічого складного та цінного в сертифікатах немає. Бо так сказала людина, яка пройшла квест з отримання того папірця. Тут немає нічого неприродного – людина, яка не має уявлення про предмет, спирається в його сприйнятті на досвід людини, яка має про предмет повніше уявлення. Ось і маємо, що несертифіковані спеціалісти «перестрибують» ментальний бар’єр та «зрізають» до результату, яким з ними поділилися інші. Але при цьому вони все ще не мають уявлення про те, що говорять, бо формулюють запозичені погляди, у формуванні яких не брали участі.

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

Саме тому я в певний момент прийняв рішення не обговорювати цінність сертифікатів із колегами, які їх не отримали. А з тими, хто їх має, залюбки пліткую, кепкую з ляпів в програмах навчання, та навіть жартую про їхню зарозумілість, безглуздість та відірваність від реальності. Можемо навіть зібратися якось після завершення чергового трирічного циклу та спалити наші CISSP/CISA/CISM тощо, хто зі мною?

Шкода, що деколи ці наші балачки чують ті, хто не в темі.

P.S. Тут напевно буде доречним вказати, що автор цього допису володіє CISSP, CISA та OSCP. Я, також, мав змогу отримати SCSA (Sun), CCNA (Cisco), CEH, та ISO27001LA, але продовжувати їх не став. Це може щось вам сказати про перші три згадані ачівки, але то вже зовсім інша історія.

Поділитися:

Різниця між корпоративною та продуктовою безпекою

Серед українських організацій чи не найчастіше до нас звертаються ІТ-компанії. Тому хочеться розповісти про певний накопичений досвід. Цілком можливо, він стане в пригоді іншим організаціям в цій вертикалі, а може й організаціям з інших галузей. Тому якщо у вас є знайомий 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 в продуктовій організації — конфлікт кудись зникає, адже саме СТО зацікавлений в безпеці сервісів та продуктів, що розробляються.

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

Поділитися: