Импортозаместители

Импортозаместители
Илья Медведовский | 10.09.2014
«И если в нашем доме вдруг завоняло
серой, мы просто обязаны предположить, что где-то рядом объявился черт с
рогами, и принять соответствующие меры вплоть до организации производства
святой воды в промышленных масштабах»

Братья Стругацкие

Последнее время в связи с понятными событиями тема импортозамещения в ИТ стала чрезвычайно модной. И дело тут не только в том, что все вдруг внезапно прозрели, а скорее всему виной поговорка: «Пока петух не клюнет — мужик не перекрестится». 

В любом случае процесс этот для страны нужный и, самое главное, сейчас необходимо направить его в правильную сторону. Поскольку то, что происходит сегодня, та, не побоюсь этого слова, начинающаяся вакханалия и масса внезапно появившихся из ниоткуда бизнесменов от импортозамещения вызывает много вопросов и требует отделить зерна от плевел. Но мы посмотрим на данную проблему исключительно с точки зрения информационной безопасности. Итак, прежде всего, какой синоним сразу всплывает в голове, как только мы слышим слово «импортозамещение». Ответ очевиден: 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%-ного контроля. Но к ним необходимо стремиться. Уязвимости будут всегда — мы же можем повлиять только на их качество и количество, своей постоянной работой постепенно повышая первое и понижая второе. 

Теги: Open Source, DDOS, Импортозамещение, Уязвимости, безопасность

Журнал IT-Manager    [ PDF ]    [ Подписка на журнал ]

Компания: Digital Security

Об авторе


Илья Медведовский

Илья Медведовский

Более 20 лет занимается информационной безопасностью. Это давно уже перестало быть просто бизнесом, увлекательной работой. ИБ - хобби, любимое дело, миссия и мечта. В течение 12 лет руководит консалтинговой компанией Digital Security, которая на сегодняшний день является одним из лидеров российского рынка аудита ИБ. В 2010 году создал также дочернюю международную компанию ERPSсan, осуществляющую разработку средств мониторинга защищенности SAP. Автор около 200 статей по информационной безопасности, а также легендарной хакерской серии книг «Атака через Интернет», в которую также вошли «Атака на Интернет» и «Атака из Интернета». Спикер на ведущих российских конференциях по ИБ.


ВКонтакт Facebook Google Plus Одноклассники Twitter Livejournal Liveinternet Mail.Ru


Другие материалы рубрики

Особенности отрасли в настоящее время — высокооплачиваемые специалисты, имеющие профильное образование. Информационная инфраструктура создается и развивается в соответствии с лучшими практиками, на основе обоснованных организационных и технических решений.
По данным «Лаборатории Касперского», в 2015 году каждый второй корпоративный компьютер в России подвергся хотя бы одной веб-атаке. И этот показатель значительно выше, чем в среднем по миру.

Мероприятия


08.09.2016
Санкт-Петербургский клуб ИТ-директоров «SPb CIO Club» и компания Event House приглашает Вас принять участие во втором Форуме по промышленной автоматизации «Industrial IT-Forum»! Промышленная автоматизация на предприятии – важная область, которой уделяется повышенное внимание. Использование информационных технологий - один из немногих технологически и экономически выгодных способов повышения эффективности подготовки производства. На современных предприятиях автоматизируются по максимуму все возможные участки работ. Новый взгляд на проблемы и тенденции информационных технологий в области промышленной автоматизации будут рассмотрены на II Форуме по промышленной автоматизации «Industrial IT Forum»

22.09.2016
24 июня 2016 года Госдумой шестого созыва был принят законопроект «Антитеррористический пакет» Яровой, который назван одним из самых резонансных. Существенная часть законопроекта призвана регулировать деятельность телекоммуникационных и интернет компаний. Согласно документу, операторы связи и «организаторы распространения информации» должны в течение полугода хранить вообще всю переданную информацию, то есть и записи телефонных звонков, и содержание смс-сообщений. В течение трех лет они также обязаны хранить сведения о переданных данных. Наконец, компании должны помочь ФСБ расшифровать весь трафик. Как законопроект повлияет на рынок? Смогут ли крупнейшие интернет-компании отстоять свою позицию? Готово ли государство прислушиваться к мнению бизнеса? На конференции Право.ru участники обсудят скрытые и явные угрозы «пакета Яровой», а также о другие законодательные изменения.