Позначка: Appsec

Чому Bug Bounty не є доказом безпеки Дії

Чому Bug Bounty Дії не є доказом безпеки? В чому помилка Мінцифри, яка переконує українців в протилежному? Що можна зробити для справжнього покращення безпеки?

Кібербезпека держави в смартфоні питання заполітизоване та наелектризоване. Щоб зорієнтуватися у фактах, я присвятив кілька тижнів вивченню інформації про безпеку Дії як програмного продукту. Навіть на їхню Bug Bounty програму підписався і вже поскаржився на її недоліки в підтримку BugCrowd, така вже я людина. В цьому пості я ділюся своїми висновками про безпеку Дії.

Щоб увійти в курс справ, вам слід прочитати останні 100 постів Костянтина Корсуна, Андрія Барановича та Артема Карпінського, а також опанувати два цікаві матеріали в онлайн-ЗМІ. Перший це колонка міністра цифровізації на Лізі, другий це інтерв’ю заступника міністра цифровізації у НВ. Усі згадані джерела маніпулятивні поза рамками пристойності, проте за лаштунками дотичних наративів очевидний головний меседж Мінцифри: ми піклуємось про безпеку Дії як головної (наразі) маніфестації концепції “держави в смартфоні”. Ми здійснюємо для її захисту потрібні та ефективні заходи. Зокрема це КСЗІ навколо інфраструктури додатку Дія та Bug Bounty її програмної частини. З боку критиків лунають закиди, які підлаштовуються під контекст та тон контраргументів. Але якщо коротко, то на думку опонентів Мінцифра некомпетентна виконувати взяті на себе зобов’язання.

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

Продовжити читання “Чому Bug Bounty не є доказом безпеки Дії”

Критичні вразливості в Microsoft Exchange

SolarWinds з його Supply Chain, про який всім вже мозок винесли сейли та маркетологи, це практично ніщо в порівнянні з десятками тисяч скомпрометованих цими днями серверів Microsoft Exchange.

Короткий переказ подій: якщо ваша корпоративна пошта на Microsoft Exchange і ви розміщуєте її у «наземному» датацентрі, – є високі шанси, що це вже не ваша корпоративна пошта. В продукті було знайдено низку критичних вразливостей безпеки, які активно використовуються кількома хакерськими групами. Одна з таких груп, що має назву HAFNIUM та напряму пов’язана з китайським урядом, ймовірно першою розробила багатоетапний експлойт та вже встигла скомпрометувати з його допомогою понад 30,000 поштових серверів, в тому числі в чисельних державних установах США. І не дивно, адже за спостереженнями компанії Volexity активна експлуатація цих вразливостей нульового дня розпочалася ще 6 січня цього року.

Продовжити читання “Критичні вразливості в Microsoft Exchange”

Новини про мою роль в OWASP

Я складаю повноваження лідера OWASP Kyiv та продовжую діяльність в OWASP як член OWASP Chapter Committee.

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

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

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

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

Якщо ви поняття не маєте, про що був цей допис, подивіться це відео 🙂

Рекомендовані книжки прочитані у 2020. Частина І: кібербезпека

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

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

Також, цього року я вперше за багато років читав російською. Попри те, що російська – моя перша мова (а українська – третя), вже понад 10 років я не послуговуюся нею для читання та письма. Годі й казати, що після 2014 року це лише підсилилося. Проте, наприкінці останнього допису серії я порекомендую твір російською.

Продовжити читання “Рекомендовані книжки прочитані у 2020. Частина І: кібербезпека”

В чому різниця між тестами на проникнення, аудитами, та іншими послугами з кібербезпеки

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

Penetration Test або тест на проникнення це дуже перевантажене поняття. На жаль, так зараз називають все, що завгодно: від переформатовування звітів Nessus та Acunetix до висококваліфікованого редтімінгу. Серед професіоналів з тестування на проникнення, пентестом називають набір вправ з динамічної та інтерактивної перевірки впроваджених заходів безпеки. Тобто, пентест це умовна лінійка, якою ви можете виміряти ефективність вашого захисту проти актуальних загроз кібербезпеки.

Application Security або безпека програмного забезпечення це не лише тестування. Щобільше, тестування програмної безпеки – це навіть не 5% всіх вправ у цій дисципліні. Зорієнтуватися в цій сфері знань найлегше за допомогою проєкту OWASP SAMM. Там лаконічно та доступно перелічені всі поширені практики AppSec та надані напрямки, де шукати більше інформації. Звісно, тестування безпеки входить до п‘яти найважливіших практик захисту програмного забезпечення, поряд з навчанням розробників основам аппсеку, моделюванням загроз, формуванням вимог безпеки, та ревю безпеки програмного коду. Проте, коли люди без досвіду в цій галузі говорять про аппсек, вони зазвичай мають на увазі незалежні тести на проникнення додатків.

Secuity Assessment або оцінка захищеності це перевірка захисту певного скоупу на момент у часі. Тобто, це такий собі снепшот рівня безпеки в порівнянні до загальноприйнятих практик в галузі, вимог певного стандарту або внутрішньої документації: політик, процедур, тощо. Але це точно не аудит, бо вимоги до цього процесу менш строгі, а очікування менш формальні, подробиці в наступному параграфі. Оцінка захищеності це найзагальніше поняття, яке застосовується дуже широко. Та найпоширенішим прикладом звісно ж є оцінка захищеності за стандартом PCI DSS, яку проводять QSA – Qualified Security Assessors.

Information Security Audit або аудит інформаційної безпеки це незалежна перевірка ефективності виконання контролів інформаційної безпеки за певний період. Тобто, якщо у вас аудит, то у вас вже має бути набір вимог, способи їх задовольнити, оцінка ризиків, система внутрішніх контролів, журнали їх виконання тощо, а можливо навіть й підрозділ внутрішнього аудиту. Важливо розуміти, що на відміну від оцінки захищеності, аудит перевіряє не як ви захищаєтесь зараз, а як ви захищалися останні пів року чи рік. Наприклад, якщо сьогодні у вас ввімкнений та налаштований Web Application Firewall, то для ассессора цього буде досить. А от аудитору доведеться показати логи ефективної роботи WAF за шість місяців, і якщо їх десь немає, то контроль безпеки буде визнано неефективним. Аудитори використовують складніші та загальніші стандарти, такі як ISO/IEC 27001 та 27002, SOC 2, ITIL тощо.

Якщо коротко, то це все. Докладніше у відео, слайди нижче.