Уявимо собі наступну ситуацію.
Одного разу відділ продажів отримує електронний лист від невідомої особи. Відділ продажів передає його у відповідний відділ. Електронний лист має такий вміст:
Що ж робити?
Перш за все, необхідно усвідомити, що це ще не атака. Якби це був зловмисник, потенційний вплив був би набагато більшим. Людина, яка писала таке повідомлення, є незалежним дослідником безпеки. Такі спеціалісти зазвичай находять проблеми безпеки та добросовісно повідомляють про них, заробляючи на винагородах.
Крок 1. Ефективна комунікація
ЩО ПОТРІБНО РОБИТИ
- В найкоротші строки відповісти на лист. У діалозі з хакером бути відвертим і чесним, тримати його в курсі останніх оновлень. Набратися терпіння — вони можуть бути неефективними комунікаторами.
- Поважати право на приватність. Якщо вони використовують псевдонім та/або анонімний проксі-сервер, не варто змушувати їх розкривати особисту інформацію. Якщо вони використовують PGP для шифрування та підпису своїх повідомлень, доцільно використовувати їхній відкритий ключ також для шифрування зворотних відповідей. Конфіденційність важлива для хакерів, але, на жаль, не всі компанії ставляться до цього з розумінням і нерідко залучають правоохоронні органи.
- Сповістити хакера про часові рамки роботи з нововиявленою вразливістю і чітко дотримуватися встановленого обмеження. «Білі капелюхи» дотримуються відповідальних практик розкриття інформації. Зазвичай вони дають вам конкретний часовий проміжок для усунення вразливості, перш ніж оприлюднити її публічно.
ЩО НЕ ВАРТО РОБИТИ
- Змушувати хакера чекати. Якщо, наприклад, було обіцяно розібратися в цьому питанні протягом 7 календарних днів, дотриматися обіцянки не вийшло, необхідно обов’язково оповістити хакера про затримку, вибачитися та вказати актуальний дедлайн.
- Намагатися шукати способи уникнути оплати чи заплатити менше. Не варто брехати що хтось інший повідомив про помилку раніше і вже отримав винагороду. Такий підхід є дуже неетичним і шкідливим. Скоріше за все, помилку буде оприлюднено ще до того як технічні спеціалісти встигнуть її виправити. Якщо компанія-отримувач не дотрималася обіцяних строків опрацювання питання і хакер публічно розкрив вразливість, необхідно усвідомити, що в неефективній комунікації винна сама компанія.
Крок 2. Опрацювання вразливості
ЩО ПОТРІБНО РОБИТИ
- Навіть якщо повідомлена вразливість не є критичною для системи безпеки, необхідно розглядати її у порядку високого пріоритету, оскільки про неї повідомило зовнішнє джерело. Якщо вразливість було виявлено в власному коді, цією можливістю можна скористатися, щоб пояснити команді розробників як уникнути таких вразливостей у майбутньому. На Invicti Learn є багато статей про вебвразливості та способи їх уникнення.
- Використовуйте автоматизований сканер для того, щоб підтвердити та дослідити вразливість. Наприклад, система керування вебвразливостями Acunetix за лічені хвилини може сформувати звіт, що містить вичерпну інформацію про вразливість, включаючи місце її розташування в байт-коді чи вихідному коді, докази її існування, вплив на систему та рекомендації щодо її усунення. Сканер може значно скоротити час опрацювання вразливості й звести ризики у подібній ситуації до мінімуму.
- У багатьох випадках можна скористатися тимчасовим обхідним шляхом. Наприклад, встановити правило для WAF, щоб захистити свою систему, доки вразливість не буде усунена. Якщо ви підтвердили вразливість за допомогою сканеру Acunetix, ви можете автоматично експортувати таке правило в брандмауер.
ЩО НЕ ВАРТО РОБИТИ
- Завчасно робити висновки, що вразливості не існує, якщо використовуване програмне забезпечення або команда не можуть підтвердити це. Окрім використання автоматизованих інструментів можна також звернутися по допомогу до хакера. В такій ситуації можна попросити доказ існування вразливості (якщо хакер його не надав), більш детальний опис і інші деталі. Просити додаткової допомоги чи інформації в цій ситуації буде абсолютно прийнятно, не варто цього боятися. Обов’язково необхідно збільшити винагороду, якщо хакер погодився допомогти з подальшим виправленням і повторним тестуванням.
- Думати, що вразливість стороннього ПЗ не є проблемою. Якщо третя сторона відмовляється виправляти вразливість, можливо, доведеться або натиснути на виробника, або створити власне тимчасове рішення (наприклад, у випадку програмного забезпечення з відкритим кодом). Вразливості zero-day в популярному програмному забезпеченні часто є найнебезпечнішими, оскільки хакери намагаються використати їх першими.
- Сприймати тимчасові заходи мінімізації впливу як розв’язання проблеми. Обмеження у WAF допоможе уникати проблеми лише до того моменту, як хтось не знайде інший спосіб підійти до вразливості з іншого боку.
Крок 3. Ретроспектива
Одна з найбільш поширених проблем — ігнорування подібних листів. Якщо повідомлення про вразливість надійде на пошту, наприклад, працівнику бухгалтерії, або на загальну скриньку, то з високою долею ймовірності лист буде проігнорований працівниками. Чи варто казати про наслідки? Тому, вкрай важливо сформувати чіткий перелік рекомендацій, де зазначається кому і в якому порядку буде переданий такий запит. Необхідно переконатися, що співробітники розуміють, як діяти в подібних ситуаціях і не ігноруватимуть такі повідомлення.
ЩО ПОТРІБНО РОБИТИ
- Створити власну Програму розкриття вразливостей (VDP) і Програму винагороди за помилки. Умови Програми розкриття вразливостей, включаючи інструкцію щодо розкриття інформації та прийнятні методи тестування можна описати на сайті та в соцмережах. Необхідно створити файл security.txt для свого вебсайту з відповідною інформацією та переконатися, що контактну інформацію легко знайти. Обсяг премій за помилки повинен залежати від ступеня критичності для бізнесу та типу вразливості.
- Після усунення вразливості необхідно визнати це та розкрити подробиці з двох причин. По-перше, хакер міг мовчки використати вразливість і викрасти конфіденційні дані. В такій ситуації, буде значно краще, якщо компанія заявить про вразливість перша, ніж це стане відомим після злиття інформації стороннім джерелом. По-друге, публічний звіт матиме позитивний вплив на те, як компанію сприймає індустрія безпеки. У звіті необхідно обов’язково вказати хто і коли повідомив про вразливість.
ЩО НЕ ВАРТО РОБИТИ
- Вважати що політика розкриття вразливостей буде розв’язувати усі проблеми безпеки. Необхідно проводити власні дослідження і працювати з вразливостями на постійній основі. За допомогою найсучасніших рішень, сканування вразливостей можна виконувати автоматично, в неробочі години, а також імплементувати процес в SDLC.
