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

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

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

I have been in pentesting and appsec business for a while. For the last 10 years, I am more or less involved in security assessments of various kinds. I have started as a junior security engineer in a large international firm, where I did my share of scanning and translating the reports. Then I had to leave the infosec industry for a couple of years that I spent in IT audit, but I continued occasional freelancing. After that, I joined a smaller firm where I grew my first pentesting team, then another one. Currently, I run my own company and I can finally focus on building the security assessment practice the way I see it right. One question that I am regularly asked by clients, friends, and colleagues is:

Why do you still do appsec and pentests when Bug Bounties are so much more profitable?

Sometimes I joke about it, sometimes I try to explain, but normally I limit the answer to “bug bounties are overrated”. Simply because it’s true. I will not dig deep into the difference between classic consulting services and security assessments in particular, and the crowdsourced approach implemented by contemporary bug bounty programs. Instead, I will point your attention that both leading bug bounty brokers have lately introduced a new service: the so-called “next generation pentest”. Which in fact is just a pentest, but provided to you by a broker that uses bug hunters as human resources. Of course, we can argue about the differences in methodology that supports the two approaches, but after a few minutes I will most probably convince you that this difference is negligible. What really matters is who does the job.

A few words about the history of the discipline. For many years the pentesting firms were so small, that they were not considered actual market players. Simply because big clients were not the fans of the idea of giving such a sensitive job to a pentest boutique. Instead, they offered contracts to the entities who already had built trust with them: accounting firms, system integrators, and even software vendors. Then, slowly but surely, smaller companies have started to gain trust too: sometimes because of a deeper focus on the subject, sometimes because they were founded by the individuals who had built trustworthy public profiles throughout their carriers. And then bug bounties emerged.

Bug bounties have offered the market the crowdsourced security assessments of unlimited scale. In other words, now “thousands of eyes” could review the security of your software and report issues, while only the first report complete according to the program rules could win the reward. Many customers were quick to jump into the bandwagon that seemed an economically good idea. Pay as you go? Better: pay as you get value! Who in possession of required funds would resist the temptation?

But as it turned out, not every customer was ready for the “thousand eyes” attention. A few did not go through any formal appsec practices prior to posting the bug bounty brief. As a result, a thousand eyes quickly emptied the budget of a program that had not had a couple of eyes looked at its scope first. So the paradigm had to evolve: now the bounties were only good for the “mature” products, that had some in-house appsec. After this and some other improvements, the balance has been found.

The ingenuity of the idea and the trajectory of its success made bug bounties a nice thing to invest in. And the investment capitalism, in short, means that fsck dividents — the growth is all that matters. But the growth has not been as intensive as expected: the market has quickly reached its capacity in both clients and human resources. Not that many customers are declaring bounties now, although many pilot the service in a private mode. Not many bug hunters become professional and dedicated full-time appsec researchers. There are super effective 1%ers on both sides. Apparently, the investors are not OK with “the flow” of operations and revenue that the field has reached. Thus, the rewind to the classic dedicated consulting/pentesting kind of services is being attempted — albeit with a certain facelift. And it will most probably work out, as the bug bounty brokers have the required trust and quality controls out there and are able to deploy trustworthy, background-checked resources. I am not sure that this will allow the brokers to sustain the growth rate that is expected from them, because the next “bug bounty boom” is not necessarily arriving any time soon. But the combination of public and private bounties and classic pentests would secure the flow.

In conclusion, I will sum it all up as I see it. Bounties offered the market the promise that Bitcoin once gave: the elimination of trust from the equation. Bitcoin never made it: not only because now you had to trust Bitcoin itself, but more importantly because people are willing to trust each other and the independent third parties who would enforce rules in case one of them decides to cheat. Neither will bounties make it. Instead, the brokers will have to take trust into account and diversify their offering accordingly.

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

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

Цікавий парадокс являє собою галузь кібербезпеки. З одного боку, кібербезпека вважається технічною галуззю, яка успадкувала від інших технічних професій високий відсоток чоловіків. Ми ж бо технарі! Ось, подивіться, у нас руки по лікті в мазуті! З іншого ж боку, кібербезпека, після певного рівня кар’єрного узагальнення, – це здебільшого управління ризиками та робота з людьми. Кумедно? Якщо ми з вами спілкувалися на цю тему раніше, то ви знаєте мою думку: жінки більше підготовлені для роботи в кібербезпеці, і цьому є багато прикладів та їхня кількість зростає. Не зважаючи на те, що дівчата рідко сюди потрапляють, вони зазвичай досягають тут більших успіхів.

В окрему тему можна виділити конференції з кібербезпеки. Зазвичай, коли людина здобуває цікавий досвід, логічно ним поділитися. Особливо, коли справа стосується досліджень або завдань та ситуацій, інформація про які може бути цікава іншим людям. І тут ми маємо просто неймовірний перекіс в бік доповідачів-чоловіків: доля доповідачок навіть не є пропорційною долі жінок в професії. Чому? Тому що хлопці подають заявку на виступ, коли впевнені у тому, що їхня тема цікава, хоча б наполовину. А дівчата – коли впевнені хоча б на 90%.

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