Вчера, на PHDays 11 мне довелось модерировать круглый стол «Развитие открытого кода для решений в кибербезопасности и открытого ПО для корпоративного сектора» и уже традиционно я хотел бы поделиться ключевыми тезисами, прозвучавшими на нем, а также высказать ряд своих мыслей относительно заявленной темы. Надо сразу сказать, что open source в корпоративной ИБ — это то, к чему нас принудила сложившаяся ситуация. Приостановление деятельности или уход почти всех американских ИБ-компаний, которые превалировали на российском рынке, привели к тому, что многие предприятия встали перед большим знаком вопроса, ответ на которой подразумевает несколько альтернатив:
- ждать, когда иностранцы вернутся (да, таких компаний немало и их можно понять — инвестиции сделаны немалые и не хотелось бы выглядеть перед руководством, санкционировавшим эти инвестиции, глупо)
- перейти на израильских/ближневосточных/азиатских/южноамериканских вендоров, хотя нет гарантий, что их не включат в новый Указ Президента, который запретит использовать вообще все зарубежные средства защиты, независимо от дружественности страны
- перейти на отечественное ПО, но тратить столько же денег, сколько на иностранцев, сегодня мало кто готов (срок амортизации купленного еще не истек)
- перейти на open source, вокруг которого мы и дискутировали с коллегами из Ozon, Yandex.Cloud, CyberOK, Positive Technologies и Минцифры.
Итак, тезисно, что прозвучало на круглом столе и чтобы я хотел добавить к прозвучавшему:
- Чтобы работать с open source вам нужны люди; люди квалифицированные. Без них вам делать в этой истории нечего. Вам нужны люди на доработку софта под себя, на проверку/аудит чужого кода, а это все история не для обычного ИБшника. Кто вообще будет дорабатывать ПО под нужды корпоративных заказчиков? Писать свои ветки под каждого клиента? Или делать свои форки, забывая контрибьютить в сообщество (нежелание делиться тем, за что заплачены деньги, у нас достаточно сильно)?
- Open Source — это не про бесплатно. Не надо путать его с freeware. Даже если это ПО пишут комьюнити, то для корпоративного рынка важна поддержка, а она не бывает бесплатной. А учитывая требования к персоналу, который может работать с open source, то затраты на него могут быть достаточно значительными. Поэтому смотреть на open source надо не с точки зрения экономики, а с точки зрения цифрового суверенитета и независимости (с оговорками, конечно).
- Open source в ИБ может закрыть практически любую нишу, но централизованное управление распределенных решений на open source — это боль, которая сегодня решается из рук вон плохо.
- Корпоративные заказчики любят предсказуемость — четкие роадмапы, уверенность, что разработчику не надоест его творение, уверенность, что разработчика не купит крупный игрок рынка ИТ/ИБ, который попадет сразу под кучу ограничений (вспомним Elastic, Redhat, Github и т.д.) и т.п. С open source неопределенность гораздо выше проприетарных решений.
- Некоторые участники дискуссии готовы выкладывать часть своих продуктов в паблик, но пока этого не сделали, а только раздумывают. Вообще у меня сложилось впечатление, что у нас рынок готов делится исходниками ОС, СУБД и т.п. решениями, но как только заходит речь об ИБ, особенно той, которая попадает под регулирование ФСТЭК и ФСБ, то ситуация кардинально меняется и все придерживают исходники у себя. По крайней мере я так и не смог вспомнить, чтобы кто-то из наших разработчиков активно контрибьютил в зарубежные решения и выкладывал свои наработки у нас (хотя отдельные примеры все-таки есть). Выкладывать можно движки, а вот контент (сигнатуры атак, паттерны для обнаружения аномалий, правила для SIEM, иную экспертизу) уже можно продавать, но найти золотую середину между свободной и закрытой частями ПО непросто.
- Многие разработчики стыдятся своих творений из-за «тяпляпского» подхода к созданию ПО и куче наспех написанных фрагментов, отсутствия комментариев и т.п. Поэтому они оттягивают выкладывание своего ПО в паблик, не стесняясь при этом отдавать его на сертификацию 🙂 Но даже если код выложен, то возникает иная проблема, — уязвимости в нем. Не раз упомянутая на круглом столе OpenSSL, как мы помним, содержала нашумевшую уязвимость Heartbleed, которую не могли обнаружить в течение десятка лет. И это при том, что код был доступен миллионам пользователям для анализа. Потом выяснилось, что код, который использовался и используется огромным числом компаний и продуктов, писался всего двумя программистами. И это проблема, которой та же ФСТЭК уделяет немало внимания в части безопасной разработки, но пока эта история не стала очень популярной ввиду отсутствия и практики SecDevOps, и специалистов по ней.
- Сертифицируя open source, можете забыть про open source. Он превращается в закрытый код. Да, у него появляется ответственный, техподдержка и все остальные прелести кода проприетарного, но в открытом виде в его уже, скорее всего, не увидите. А учитывая, что у ФСБ вообще требования ужесточаются по мере получения доступа потенциальными злоумышленниками к среде функционирования.
- Исходники open source куда-то должны выкладываться. Если это будет какой-то публичный репозиторий типа Github, то возможны истории аналогичные npm-модулю node-ipc, с которыми бороться не так уж и просто (хотя по словам участников, куда уж проще детектить обращение к геолокации в коде). Если ориентироваться на государственный репозиторий, который готовит Минцифры, то встает вопрос «А если его скомпрометируют как Linux Mint в 2016-м году и Gentoo Linux в 2018, то кто будет нести ответственность за раскатывание недокументированного и вредоносного кода по всем пользователям?» Коллеги делились своим опытом и все сошлись во мнении, что эта история требует ручного аудита кода, а это вновь обращает нас к требованиям к высококвалифицированному персоналу или использованию услуг аутсорсинга, что тоже история недешевая.
Это, пожалуй, все, что я хотел бы тезисно упомянуть по результатам круглого стола. Что-то я оставлю за рамками заметки и вы можете пересмотреть запись эфира:
Часть вопросов, например, «под какой из лицензий, GNU AGPLv3, GNU GPLv3, GNU LGPLv3, Mozilla, Apache, MIT, выпускать open source по ИБ?», «как и где судиться в случае нарушения лицензии GNU?» и т.п., мы так и не успели рассмотреть, но о них тоже стоит подумать при использовании этой альтернативы.
