Импортозаместители
Автор
Илья Медведовский
Есть прекрасный шанс броситься в слепую атаку на укрепрайон, в принципе не понимая, что он собой представляет, и подорваться на всех возможных минах, не дойдя в итоге до нужной цели.
«И если в нашем доме вдруг завоняло
серой, мы просто обязаны предположить, что где-то рядом объявился черт с
рогами, и принять соответствующие меры вплоть до организации производства
святой воды в промышленных масштабах»
Братья Стругацкие
Последнее время в связи с понятными событиями тема импортозамещения в ИТ стала чрезвычайно модной. И дело тут не только в том, что все вдруг внезапно прозрели, а скорее всему виной поговорка: «Пока петух не клюнет — мужик не перекрестится».
В любом случае процесс этот для страны нужный и, самое главное, сейчас необходимо направить его в правильную сторону. Поскольку то, что происходит сегодня, та, не побоюсь этого слова, начинающаяся вакханалия и масса внезапно появившихся из ниоткуда бизнесменов от импортозамещения вызывает много вопросов и требует отделить зерна от плевел. Но мы посмотрим на данную проблему исключительно с точки зрения информационной безопасности. Итак, прежде всего, какой синоним сразу всплывает в голове, как только мы слышим слово «импортозамещение». Ответ очевиден: Open Source А это значит, что первая задача — вбить в голову масс тождественное равенство между импортозамещением и опенсорсом — уже почти решена, и решение, на основе чего мы будем импортозамещаться, скорее всего, принято. Вариант сделать самим с нуля практически никем не рассматривается — ну может, оно и к лучшему. Сейчас мы говорим о безопасности. И в данном случае что использовать о Open Source, что писать самим с нуля — особой разницы нет, ведь для нас всегда актуален только вопрос контроля. У обоих вариантов с точки зрения безопасности есть свои минусы и плюсы, но с точки зрения разработки, видимо, проще использовать готовую базу, чем писать свою.
Впрочем, вернемся к безопасности. И вот тут все весьма грустно, потому что бизнесмены от Open Source пока предпочитают использовать как старые проверенные мантры (открытость = безопасность), так и придумывать новые. Все бы ничего, но такое положение крайне опасно, поскольку у нас, как у государства, есть прекрасный шанс броситься в слепую атаку на укрепрайон, в принципе не понимая, что он собой представляет, и подорваться на всех возможных минах, не дойдя в итоге до нужной цели.
Итак, что же нам последнее время активно вбивается в голову. Давайте подробнее разберем каждый сценарий.
«100%-ная российская программная платформа»
Я думаю, все не раз слышали этот лозунг применительно к Open Source. Что же за ним стоит на самом деле? Воспользуемся открытой статистикой:
«Вопреки расхожему мнению, большая часть всех изменений, вносимых в ядро (более 80%), сделана программистами, получающими за эту работу оплату, в том числе и сотрудниками крупных компаний (например, Hitachi, LG Electronics, Renesas, NEC, Sony, Panasonic, Qualcomm). Доля энтузиастов составляет всего 13,6%, еще 0,9% кода принадлежит образовательным учреждениям и столько же The Linux Foundation».
Таким образом, сегодня ядро Open Source — не просто код, созданный энтузиастами, это более чем на 85% продукт деятельности тех самых западных вендоров, от которых нам и предлагается сегодня «замещаться». Как вам такое «замещение»? Кстати, среди указанных вендоров видные места занимают демонизируемый сегодня «Майкрософт» и то самое АНБ, являющееся контрибьютором Open Source. К слову, участие в разработке позволит АНБ скорее не вносить уязвимости в свой код (что крайне маловероятно и слишком уж грубо и «в лоб»), а получить необходимые глубокие знания «внутренностей» ядра для дальнейшего поиска уязвимостей в чужом коде.
Кроме того, в массы насаждается еще одно опасное заблуждение. Оно похоже на «открытое — значит безопасное», но я бы сформулировал его как «открытое — значит контролируемое». Речь о том, что само по себе наличие кода и возможность его компиляции якобы автоматически дает «контроль» над разработкой. По оценке экспертов для того, чтобы обеспечить должное погружение и соответствующий контроль над всей этой огромной массой сложнейшего кода, нужны годы и команда от 500 специалистов. Тогда, при условии выделения разработки в самостоятельное направление, через несколько лет можно будет сказать, что теперь данный код наш более чем на 90%. В противном случае все это лишь вводящие в заблуждение лозунги про «100%-ную российскую разработку». Но, к сожалению, сценарий простого использования чужих библиотек гораздо дешевле и проще (зачем и кто станет в них разбираться?). В таком случае результат традиционен: своего мы вносим менее 0,1% и более-менее разбираемся в 10% остального кода.
«Исходный код = гарантированная безопасность и отсутствие закладок»
Не могу пройти мимо известной старой опенсорсной мантры, в которую многие до сих пор верят. Открытость равно безопасность — об этом все слышали. И с точки зрения стороннего наблюдателя всё ведь совершенно логично, потому и миф столь живуч. Код есть, значит, его можно проверить и выявить все закладки и уязвимости. Крайне опасное заблуждение. Дело в том, что по коду в статике удается обнаружить только часть проблем, другая же часть определяется в динамике, и код здесь совершенно не обязателен. Чтобы наглядно понять всю сложность задачи статического анализа кода, я приведу один пример.
Недавно нам довелось поучаствовать в роли третейского судьи в крупном западном проекте по анализу ядерного Open Source кода на С. После запуска лучшей в мире коммерческой системы статического анализа кода специалисты выявили более 18 тысяч потенциальных уязвимостей, из которых сканером было признано свыше 2500 высокого уровня опасности, а критического уровня — около 200. Затем исследователи вручную изучили все потенциальные критичные уязвимости и часть уязвимостей с высоким уровнем критичности. После длительной работы из всей этой массы, найденной сканером, реальными уязвимостями было признано примерно 10 критичных и 20 высокого уровня. А далее началось самое интересное. Разработчик изучил отчет исследователей и уверенно сообщил, что все это не уязвимости и ничего он менять не собирается. Исследователи с ним не согласились. Все, ситуация стала патовой. Стороны позвали нас в качестве третейского судьи, чтобы мы их рассудили. Наш итоговый вывод оказался следующим:
- 10 «уязвимостей» - ложные срабатывания и они не являются ни ошибками, ни уязвимостями;
- 5 уязвимостей однозначно ведут к DoS;
- 15 уязвимостей требуют дальнейшего глубокого изучения и трудоемкого анализа.
Итог данного труда: после множества проверок (исследователи, разработчики, мы) реально опасных эксплуатируемых уязвимостей (типа RCE) было найдено ноль.
Это история ясно показывает, что означает на практике наличие исходного кода и насколько «прост» анализ кода для языков типа С, а также как «просты» в использовании системы статического анализа кода. Особенно, когда речь идет об их применении не исследователями и ядерными разработчиками, а сотрудниками на стороне заказчика. Все это, конечно, не означает, будто анализ кода не нужен — он необходим и используется, но именно как часть SDL-цикла разработки.
Между прочим, когда мы в свое время начали работать внутри SAP, тестируя пререлизные версии их продуктов, наши немецкие партнеры быстро отказались от идеи привлекать нас к результатам анализа кода статического анализатора в связи с неэффективностью. Поэтому нас привлекают там в основном именно на этапе итогового пентеста.
«Форк всему голова»
Форк, или создание новой собственной ветки разработки, — типовой сценарий использования Open Source. Однако, судя по всему, в самой среде OS начинается внутренняя борьба за место под солнцем, и здесь показателен следующий пример, взятый мной из недавнего интервью одного из разработчиков, ну конечно же, про «100%-ную российскую программную платформу»:
«Форк был необходим, поскольку мы уже столкнулись с появлением недекларированных возможностей в некоторых из используемых нами OpenSource-библиотек и очень не хотим повторения этой истории. Использование OpenSource-проектов в оригинальном виде, без контроля за кодом со стороны российских компаний, опасно. И если заказчик рискует и начинает его применять, пусть не удивляется, с чего бы вдруг очередная версия прикладного продукта, использующего опенсорсные библиотеки, вдруг сама полезла на сервера иностранных компаний».
С одной стороны, наблюдается сплошной прогресс — Open Source признает недекларированные возможности в своем коде. С другой стороны, совершенно неясно, чем именно поможет форк, когда разработчики как использовали, так и будут использовать 99,99% чужого, сложного и плохо им знакомого кода, содержащего многие мегабайты. То есть мантры развиваются, видоизменяясь и осовремениваясь буквально на ходу.
Оказывается, сделай форк и спи спокойно: все сразу будет «безопасно» и никакой контроль не нужен. Но при этом, конечно же, «100%-ная российская» и обязательно «безопасная» платформа. Кстати, при форке интерес представляет вопрос: что делать с обновлениями из общей ветки и кто их будет контролировать? Складывается ощущение, что за сомнения в безопасности Open Source и за необходимость серьезного контроля над ним скоро будут сжигать на костре святой инквизиции неукротимого импортозамещения.
Контроль нам только снится
Что же делать и есть ли свет в конце туннеля? Выход есть. Неважно, на базе чего будет проходить импортозамещение и будет ли оно вообще проходить — нужен процесс контроля, как внешнего, так и внутреннего. Да, с одной стороны, должен присутствовать внутренний контроль самой разработки, так называемый SDL. Но по опыту я в него слабо верю: у отечественных вендоров есть только зачатки, да и то у единиц. Он дорогой, сложный, удлиняет процесс. Плюс отсутствие мотивации у подавляющего большинства наших вендоров. Ранее я об этом подробно писал в статьях "Санитары леса" и "Железный ад". При этом можно утверждать, что наши разработчики сами не будут ничего делать, пока на них серьезно не надавят сверху. Разумеется, в данном случае речь идет о критичных для государства системах. Причем надавят именно сверху. Это российская особенность. У нас даже в столь критичной отрасли, как банковская, сами банки ничего не могут сделать с разработчиками, все зависит от решений ЦБ РФ. В целом же надо ясно понимать, что внутренний контроль в разработке (SDL) должен быть по определению. Впрочем, его существование не отменяет необходимости внешнего контроля.
Процесс внешнего контроля критичных систем обязателен, и не имеет значения, свой код или чужой или его вообще нет. Нужны единые требования по внешнему контролю над ключевыми системами, используемыми государством, и наличие их исходного кода здесь вовсе не является непременным условием. Контроль на практике можно и нужно реализовать и без исходного кода. Причем сам вопрос контроля критичного ПО — крайне сложен. Для его решения необходимы различные центры компетенции, сформированные на базе коммерческих компаний и специализирующиеся на изучении продуктов разных типов. Деятельность таких центров должна финансироваться и регламентироваться из единого специально созданного или уже существующего государственного органа по контролю над ключевым ПО, например ФСТЭК. Только так мы сможем за несколько лет наладить процесс соответствующим образом. И повторюсь: совершено неважно, своя ли это разработка, или чужая, созданная с нуля или на базе Open Source, — в случае критичных систем все следует контролировать одинаково.
Заключение
Как глава исследовательской компании, чьи специалисты ломают все что можно и нельзя, я абсолютно одинаково отношусь к нашим «кормильцам» — любым разработчикам — неплохо представляя все их плюсы и минусы и специфику в плане ИБ. Мне просто не нравятся заведомо насаждаемые маркетинговые мифы, которые предназначены для зомбирования широких масс и которыми все вендоры так или иначе грешат. Вот почему в своих статьях я всегда пытаюсь донести только одну мысль: не имеет значения, какой вендор — опенорс не опенсорс, российский или западный. Важно другое: чтобы в случае критичных систем был реализован постоянный процесс внешнего контроля.
Возвращаясь к Open Source, на базе которого сегодня и будет, вероятнее всего, организовано импортозамещение, отмечу, что оценка защищенности любого решения, созданного на базе OS, крайне сложная задача и не стоит заблуждаться, будто наличие исходного кода является панацеей и может помочь само по себе. Присутствие исходного кода лишь несколько упрощает часть процесса анализа, не более. Вот почему использование Open Source -решений само по себе не дает ни повышенной безопасности, ни тем паче никаких «гарантий безопасности» продукта или отсутствия закладок. Однако при наличии большой и сильной команды разработки, внедренной процедуры SDL и, главное, серьезного и постоянного процесса внешнего контроля можно с течением длительного времени попытаться построить, в том числе, и на базе Open Source что-то свое, причем достаточно безопасное. Главное понимать: без должного процесса внешнего контроля мы получим очередной дырявый клон. И также четко надо понимать, что не бывает как 100%-ной безопасной разработки, так и 100%-ного контроля. Но к ним необходимо стремиться. Уязвимости будут всегда — мы же можем повлиять только на их качество и количество, своей постоянной работой постепенно повышая первое и понижая второе.
Опубликовано 10.09.2014