Главная мысль статьи Reuters в том что запрос исходного кода для аудита плохая и опасная практика. Это попросту неверно. Аудит кода очень широко распространенная регулярная практика, используемая как компаниями, так и профессиональными разработчиками, специалистами в области информационной безопасности, чтобы убедиться в безопасности устанавливаемого программного обеспечения(ПО). Так же в статье информационного агентства отмечается что «Reuters не нашло никаких свидетельств того что аудит исходного кода имел значение для проведения кибератак». Для нас в фонде EFF является обычным делом выполнение аудита исходного кода любого ПО, которое мы выбираем для использования.
Подчеркнем для полной ясности: мы не хотим преуменьшать степень иностранных угроз для кибербезопасности США или подстрекать к использованию уязвимостей ПО, напротив, мы хотим подчеркнуть что открытый код(open source) и аудит кода — одни из сильных мер безопасности. Именно поэтому EFF серьезно поддерживает распространение и использование открытого ПО.
Не только производители ПО запрещают иностранным правительствам производить аудит кода, торговые соглашения используются теперь и для того чтобы запрещать странам запрашивать аудит кода важных для них программных комплексов. Первым торговым соглашением с таким ограничением стало Транстихоокеанское партнерство ( Comprehensive and Progressive Trans-Pacific Partnership — CPTPP так же известное как TPP), которое должно быть подписано в марте этого года.
Аналогичное ограничение предлагается включить в обновленное соглашение о Североамериканской зоне свободной торговли (NAFTA) и в грядущем двустороннем соглашении с ЕС. EFF уже заявлял о своей позиции по данному вопросу: такие запреты на обязательный аудит кода создают препятствия для легализации мер по подтверждению безопасности и качества такого ПО как VPN и средств безопасного общения, а так же таких устройств как роутеров и IP-камер.
Неявное предположение что «сохранение нашего исходного кода закрытым повышает нашу защищенность» очень опасно. Исследователи и эксперты в области информационной безопасности периодически наглядно демонстрируют нам что защищенность, главным образом, полагающаяся на безопасность через неясность просто не работает. Еще хуже то что она дает ит-специалистам ложное чувство безопасности и поддерживает этим соответствующие плохие подходы к информационной безопасности.
Даже во времена политических бурь и неопределенности мы не должны терять головы. Разрешение проведения аудитов исходного кода программ не является вызовом для нашей национальной безопасности --на самом деле нам крайне необходимо, чтобы их было больше.
Комментарии (10)
InChaos
27.02.2018 09:23Разработка персонального продукта для каждого, кто хочет аудита.
Да, дорого. Но зато обнаруженные уязвимости не могут быть использованы аудитором против других пользователей.
Вы хоть каким то боком к программированию относитесь или опять пропускаете голосование в думе?
Как предлагаете это реализовывать? Есть в продукте функция — «обмен по сети», у нее есть входные и выходные параметры и какой то определенный функционал внутри. Т.е. для одного мы ее так программируем, для другого по другому? Это как вообще? 2+2 для каждого клиента считаем по разному?
geher
27.02.2018 10:18Все проще, чем кажется.
Для потребителя, который жаждет аудита, разрабатывается с нуля новый продукт новой командой без доступа к кодовой базе старого проекта. И да, каждая функция должна быть написана заново другим человеком, с новыми ошибками и уязвимостями.
Сторонние библиотеки — не головная боль разработчика продукта. Он не может предоставить исходники чужого закрытого продукта, а чужой открытый и без того доступен.
Я понимаю, что первый вариант так себе решение, и второй всяко получше будет, но разработка с нуля персонального продукта не является чем-то абсолютно невозможным.
Разные компании как-то умудряются разработать свои независимые решения
Дополнительной альтернативой является доверие к аудиторам клиента (а я рассматриваю случай, когда доверия нет) или отказ в аудите (и потеря клиента).
tBlackCat
27.02.2018 12:12Бритва Оккама вновь актуальна.
Положим, можно разработать систему под конкретного заказчика и отдать ему код на аудит, но есть пакостный момент. Аудитом будет заниматься ограниченный круг специалистов и чем это грозит вполне понятно. Стоит вспомнить, что в открытых продуктах до сих пор обнаруживают уязвимости, несмотря на общедоступность исходников и несравненно бОльший круг исследователей.
Крайне неоднозначный вопрос, пока не имеющий универсального решения.
ads83
27.02.2018 19:13Вариант достаточно хорошего решения — это распределение разработки, тестирования и аудита заказной системы между разными исполнителями-конкурентами. Если времени совсем не жалко, проектирование можно заказать отдельно от разработки. Такая схема позволяет достичь приемлемого уровня аудита и для непубличных исходников.
Например, если продукт разрабатывал условный Эпам, а тестирование проводит условный Люксофт, то шансы на пропущенный косяк резко падают. Хотя проверять код будет меньше людей (по сравнению с open source), они будут заниматься только аудитом. Полный рабочий день, проверяя по максимуму. Допускаю, что в пересчете на мифические человеко-часы сферического сеньора выйдет больше, чем аудит неограниченным кругом пользователей неопределенной квалификации. Потому что каждый аутсорсер заинтересован, чтобы поддержка досталась именно ему — говорят, она приносит гораздо больше, чем другие этапы жизни продукта.
У этого подхода есть и минусы. Как минимум, усложняется управление проектом и увеличиваются сроки. Разумеется, получается дороже. Хуже, если подрядчики увлекаютсякиданием какашекперекладыванием ответственности и забывают про проект. Допускаю, что есть и другие минусы, добавляйте в комментариях — все-таки я не менеджер.tBlackCat
28.02.2018 05:58На самом деле аудит не вывляет косяки, только преднамеренные закладки, да и то не гарантированно.
Тут дело в том, что помимо багов самой программы есть и баги компиляторов и иже с ним. Достаточно вспомнить, например в мире Линукса, ряд условий при компиляции програм — определённые версии компиляторов, жёсткий состав ключей компиляции… Всё это было.
> Допускаю, что в пересчете на мифические человеко-часы сферического сеньора выйдет больше
Часы можеи и из сферической области, но за них расплачиваются полновесной монетой :)
> все-таки я не менеджер
Поверьте, от них тоже зависит весьма многое. Поварился в кухне тестирования и имел возможность наблюдать чудеса полёта фантазии менеджеров.
teecat
27.02.2018 16:00Никто не говорит, что проверка кода не нужна, но есть нюансы
1. Есть такая штука как пиар. Доля Макафи и Симантика в госорганах практически равна нулю, поэтому им сертификация уже не нужна. А раз не нужна, то можно и заявления делать. Вот Майкрософт как-то не спешит делать заявления об отказе предоставления исходных кодов на сертификацию
2. Обновления. Если мы говорим об антивирусах Макафи и Симантик, то что их сертифицируй, что не сертифицируй — отказаться от обновлений нельзя. А с обновлениями может прилететь что угодно (ну почти что угодно). Более того — задержка времени на сертификацию и проверку кода может быть критически важна
ni-co
27.02.2018 19:04Рассказывать об устройстве новой системы безопасности потенциальному домушнику — не просто глупость, а преступление.
ads83
27.02.2018 19:25Если система безопасности так себе — то да. А если рассказ будет демонстрировать best practices вида помимо трех замков разных систем на двери и решетках на окнах, помещение оснащено объемными датчиками движения и видеонаблюдением? Это отсечет большинство домушников. Так же, как фразы наш сайт находится под защитой от DDoS или в автомобиле установлена спутниковая противоугонная система — они раскрывают систему безопасности, но снижают количество атак. И не раскрывают критичных деталей вроде используемых портов, схемы видеокамер и проводки автосигнализации.
Areso
28.02.2018 06:09Даже самого крупного аудитора (3-ю сторону) можно купить.
Я слышал, не так давно большая четверка стала большой тройкой, когда вскрылся такой факт. Правда свято место пусто не бывает, и теперь это снова четверка)
geher
С аудитом исходных кодов не все так однозначно.
Нельзя передавать исходники широко используемого продукта в аудит только людям, которым не вполне доверяешь. Например, какой-нибудь хакерской группировке или спецслужбам (любым). Они могут найти и припасти для исключительного использования какие-нибудь уязвимости.
Но есть и обратная сторона. Использовать непроверенный продукт на критически важных системах тоже нельзя. Разработчик может в чьих-то интересах сознательно создать в продукте дыры.
Впрочем, проблема имеет решения.
Вариант первый. Разработка персонального продукта для каждого, кто хочет аудита.
Да, дорого. Но зато обнаруженные уязвимости не могут быть использованы аудитором против других пользователей.
Вариант второй. Аудит у нескольких групп, вызывающих доверие, плюс открытый общественный аудит.
В этом случае снижается вероятность, что какой-либо аудитор сможет обнаружить и "приватизировать" уязвимость.
Естественно, абсолютных гарантий никаких: уязвимости могут быть пропущены при любом аудите, доверенный аудитор может обмануть доверие. Но и "закрытый" код вполне может быть подвержен исследованиям на уязвимости, что показывает вал обнаруживаемых уязвимостей, включая очень опасные, в закрытых системах.