Краткие итоги круглого стола «Развитие открытого кода для решений в кибербезопасности и открытого ПО для корпоративного сектора»

Краткие итоги круглого стола «Развитие открытого кода для решений в кибербезопасности и открытого ПО для корпоративного сектора»

Вчера, на PHDays 11 мне довелось модерировать круглый стол «Развитие открытого кода для решений в кибербезопасности и открытого ПО для корпоративного сектора» и уже традиционно я хотел бы поделиться ключевыми тезисами, прозвучавшими на нем, а также высказать ряд своих мыслей относительно заявленной темы. Надо сразу сказать, что open source в корпоративной ИБ — это то, к чему нас принудила сложившаяся ситуация. Приостановление деятельности или уход почти всех американских ИБ-компаний, которые превалировали на российском рынке, привели к тому, что многие предприятия встали перед большим знаком вопроса, ответ на которой подразумевает несколько альтернатив:

  • ждать, когда иностранцы вернутся (да, таких компаний немало и их можно понять — инвестиции сделаны немалые и не хотелось бы выглядеть перед руководством, санкционировавшим эти инвестиции, глупо)
  • перейти на израильских/ближневосточных/азиатских/южноамериканских вендоров, хотя нет гарантий, что их не включат в новый Указ Президента, который запретит использовать вообще все зарубежные средства защиты, независимо от дружественности страны
  • перейти на отечественное ПО, но тратить столько же денег, сколько на иностранцев, сегодня мало кто готов (срок амортизации купленного еще не истек)
  • перейти на open source, вокруг которого мы и дискутировали с коллегами из Ozon, Yandex.Cloud, CyberOK, Positive Technologies и Минцифры.
PHDays 11 — секция по open source

Итак, тезисно, что прозвучало на круглом столе и чтобы я хотел добавить к прозвучавшему:

  1. Чтобы работать с open source вам нужны люди; люди квалифицированные. Без них вам делать в этой истории нечего. Вам нужны люди на доработку софта под себя, на проверку/аудит чужого кода, а это все история не для обычного ИБшника. Кто вообще будет дорабатывать ПО под нужды корпоративных заказчиков? Писать свои ветки под каждого клиента? Или делать свои форки, забывая контрибьютить в сообщество (нежелание делиться тем, за что заплачены деньги, у нас достаточно сильно)?
  2. Open Source — это не про бесплатно. Не надо путать его с freeware. Даже если это ПО пишут комьюнити, то для корпоративного рынка важна поддержка, а она не бывает бесплатной. А учитывая требования к персоналу, который может работать с open source, то затраты на него могут быть достаточно значительными. Поэтому смотреть на open source надо не с точки зрения экономики, а с точки зрения цифрового суверенитета и независимости (с оговорками, конечно).
  3. Open source в ИБ может закрыть практически любую нишу, но централизованное управление распределенных решений на open source — это боль, которая сегодня решается из рук вон плохо.
  4. Корпоративные заказчики любят предсказуемость — четкие роадмапы, уверенность, что разработчику не надоест его творение, уверенность, что разработчика не купит крупный игрок рынка ИТ/ИБ, который попадет сразу под кучу ограничений (вспомним Elastic, Redhat, Github и т.д.) и т.п. С open source неопределенность гораздо выше проприетарных решений.
  5. Некоторые участники дискуссии готовы выкладывать часть своих продуктов в паблик, но пока этого не сделали, а только раздумывают. Вообще у меня сложилось впечатление, что у нас рынок готов делится исходниками ОС, СУБД и т.п. решениями, но как только заходит речь об ИБ, особенно той, которая попадает под регулирование ФСТЭК и ФСБ, то ситуация кардинально меняется и все придерживают исходники у себя. По крайней мере я так и не смог вспомнить, чтобы кто-то из наших разработчиков активно контрибьютил в зарубежные решения и выкладывал свои наработки у нас (хотя отдельные примеры все-таки есть). Выкладывать можно движки, а вот контент (сигнатуры атак, паттерны для обнаружения аномалий, правила для SIEM, иную экспертизу) уже можно продавать, но найти золотую середину между свободной и закрытой частями ПО непросто.
  6. Многие разработчики стыдятся своих творений из-за «тяпляпского» подхода к созданию ПО и куче наспех написанных фрагментов, отсутствия комментариев и т.п. Поэтому они оттягивают выкладывание своего ПО в паблик, не стесняясь при этом отдавать его на сертификацию ???? Но даже если код выложен, то возникает иная проблема, — уязвимости в нем. Не раз упомянутая на круглом столе OpenSSL, как мы помним, содержала нашумевшую уязвимость Heartbleed, которую не могли обнаружить в течение десятка лет. И это при том, что код был доступен миллионам пользователям для анализа. Потом выяснилось, что код, который использовался и используется огромным числом компаний и продуктов, писался всего двумя программистами. И это проблема, которой та же ФСТЭК уделяет немало внимания в части безопасной разработки, но пока эта история не стала очень популярной ввиду отсутствия и практики SecDevOps, и специалистов по ней.
  7. Сертифицируя open source, можете забыть про open source. Он превращается в закрытый код. Да, у него появляется ответственный, техподдержка и все остальные прелести кода проприетарного, но в открытом виде в его уже, скорее всего, не увидите. А учитывая, что у ФСБ вообще требования ужесточаются по мере получения доступа потенциальными злоумышленниками к среде функционирования.
  8. Исходники open source куда-то должны выкладываться. Если это будет какой-то публичный репозиторий типа Github, то возможны истории аналогичные npm-модулю node-ipc, с которыми бороться не так уж и просто (хотя по словам участников, куда уж проще детектить обращение к геолокации в коде). Если ориентироваться на государственный репозиторий, который готовит Минцифры, то встает вопрос «А если его скомпрометируют как Linux Mint в 2016-м году и Gentoo Linux в 2018, то кто будет нести ответственность за раскатывание недокументированного и вредоносного кода по всем пользователям?» Коллеги делились своим опытом и все сошлись во мнении, что эта история требует ручного аудита кода, а это вновь обращает нас к требованиям к высококвалифицированному персоналу или использованию услуг аутсорсинга, что тоже история недешевая.

Это, пожалуй, все, что я хотел бы тезисно упомянуть по результатам круглого стола. Что-то я оставлю за рамками заметки и вы можете пересмотреть запись эфира, которую можно посмотреть на сайте мероприятия (искать круглый стол 18-го мая в 16.00). Думаю, что сегодня его также должны будут выложить в виде отдельного видео на канале Youtube. Часть вопросов, например, «под какой из лицензий, GNU AGPLv3, GNU GPLv3, GNU LGPLv3, Mozilla, Apache, MIT, выпускать open source по ИБ?», «как и где судиться в случае нарушения лицензии GNU?» и т.п., мы так и не успели рассмотреть, но о них тоже стоит подумать при использовании этой альтернативы.

Заметка Краткие итоги круглого стола «Развитие открытого кода для решений в кибербезопасности и открытого ПО для корпоративного сектора» была впервые опубликована на Бизнес без опасности.

Alt text
Обращаем внимание, что все материалы в этом блоге представляют личное мнение их авторов. Редакция SecurityLab.ru не несет ответственности за точность, полноту и достоверность опубликованных данных. Вся информация предоставлена «как есть» и может не соответствовать официальной позиции компании.
310K
долларов
до 18 лет
Антипов жжет
Ребёнок как убыточный
актив. Считаем честно.
Почему рожают меньше те, кто умеет считать на десять лет вперёд.

FREE
100%
Кибербезопасность · Обучение
УЧИСЬ!
ИЛИ
ВЗЛОМАЮТ
Лучшие ИБ-мероприятия
и вебинары — в одном месте
ПОДПИШИСЬ
T.ME/SECWEBINARS