Продолжение: браузеры, которые делают “не у нас”

Обсуждали записку с цитатой про “пока браузеры делают не у нас…” (напомню: там речь примерно о том, что, якобы, если браузеры делаются где-то “не у нас”, то они обязательно содержат закладки, представляют угрозу и т.п.). Мнения, как говорится, разделились: некоторые готовы верить, что, действительно, для обеспечения безопасности наипервейшее значение имеет “родовое” происхождение браузера; но готовы верить – не все, и это хорошо. Вообще, основная хитрость тут в том, что необходимо оценивать весь цикл принятия браузера в эксплуатацию.

Предположим, что “борьба закладок” уровня “у нас/не у нас” в типовых “гражданских” браузерах, не являющихся специальным ПО – не вымысел. Тогда, если браузер делают “у нас”, то возможность появления в нём уязвимостей и даже закладок – всё равно остаётся. Ну, раз есть “борьба”, то её станут продолжать и после того, как география разработки скорректирована. Понятно, что для внесения закладок (а это саботаж, вообще говоря) потребуются другие инструменты, чем использовались бы (гипотетически) при внешнем происхождении браузера (там просто – дописали, что хотели). Но такие инструменты существуют. Что касается уязвимостей, то на их появление географическое место разработки браузера уж точно не влияет.

Следовательно, раз мы озаботились не просто переносом места происхождения браузера от “не у нас”, а действительно боремся с закладками и уязвимостями, то всё равно потребуется аудит безопасности вновь созданного браузера. Если делать всё согласно традициям, сложившимся в тех областях, где подобные подходы действительно оправданы, то аудит должна делать лаборатория, не просто независимая от разработчиков браузера, но, вообще говоря, не доверяющая этим разработчикам в вопросах создания браузеров. На первый взгляд, вопрос доверия тут может показаться некоторым перегибом. Но это не так. Предположим, что аудиторы полностью доверяют разработчикам. Тогда недобросовестные разработчики, при желании, смогут аудиторов дезинформировать, например, с помощью ложной документации – и аудит закладок/уязвимостей в браузере теряет смысл.

Но раз так, то возникает вопрос: а почему бы этой же лаборатории аудита не провести аудит браузера, сделанного “не у нас” и просто сертифицировать его? Такой вариант будет эффективнее, ведь внешний браузер уже готов, обкатан, отлажен и доступен для сборки в исходных кодах. Тем более, что развивать технологии автоматизированного аудита кода, позволяющих без опаски использовать чужие наработки (а также находить в них уязвимости/закладки; обратите внимание, какой это бонус!) – в нынешних условиях существенно полезнее, чем изобретение браузерного велосипеда.

()

Похожие записки:



Далее - мнения и дискуссии

(Сообщения ниже добавляются читателями сайта, через форму, расположенную в конце страницы.)

Комментарии читателей блога: 6

  • 1. 23rd April 2011, 04:51 // Читатель Космические самолё… написал:

    Встройте аудит в в браузер – и вопрос будет закрыт. Живое рождается со встроенной иммунной системой – давайте “рожать” браузеры с ней тоже.
    Традиционная цепочка управления:
    1) детектирование симптомов болезни – сбор информации;
    2) накапливание и анализ – кашель, температура, голова болит, …;
    3) анализ;
    4) выработка решений – антител;
    5) реализация решений – доставка антител по кровеносным сосудам, повышение температуры тела, … ;
    6) анализ отклонений;

    Рецепторы встроены в браузер. Всё остальное – в фирму-разработчик. А можно и в сам браузер. Центры выработки антител ! Каналы передачи – в интернет. Браузер может болеть, выздоравливать, умирать. Состояния браузера – здоров, болен, умер.

    “Memento mori” – “не забудь умереть”(именно так – а не “помни о смерти”).

  • 2. 23rd April 2011, 09:38 // Читатель Vlad написал:

    Налицо непонимание процесса написания чувствительного ПО. В таковом процессе аудит проводят, но не на предмет закладок, а на предмет ошибок. Закладки же (практически) исключаются путём найма людей, которым доверяют. Людей отбирают путём background checks, и сомнения (“был, участвовал, …”) трактуют не в пользу кандидата.

    Я принимал участие в написании банковского ПО. Система работает именно так. Проверка человека длится 2-3 месяца. Код же проверяется только на баги безопасности (и их таки ищет сторонняя контора, но во взаимодействии с разработчиками).

    Таким образом, изложенное в посте — некорректно. Стоимость аудита собственного кода на порядки дешевле, чем чужого (где доверия разработчикам нет).

    Но, конечно, можно наставить на свою машинку всякого отовсюду, а потом удивляться — а чего это Мои Документы в Австралии читают?

  • 3. 23rd April 2011, 16:40 // Александр Венедюхин ответил:

    Vlad, всё корректно в посте изложено. Это у Вас некорректная логика, по которой, выходит, что служба внутренней безопасности не нужна, потому что сотрудников всё равно проверили background check – а при этом на практике куча проблем от инсайдеров происходит.

    Интересно ещё, как это Вы собрались ошибки от закладок отличать – типа одно ищем, второе пропускаем.

    Так что система должна работать иначе.

    (Занятно, кстати, сравнивать массовый браузер и некое абстрактное “банковское ПО”.)

  • 4. 23rd April 2011, 19:38 // Читатель Vlad написал:

    Александр, вы искажаете чужие посты в попытках найти аргументы в поддержку своей позиции.

    Если аудит-компания найдет закладку, конечно, она о ней сообщит. Но в условиях, когда сотрудники проверены, шансы наткнутся на таковую просто нижу. Профилактика, если хотите.

    И служба безопасности не дремлет, но одно дело — искать единичные случаи против потенциально организованной операции.

    И браузер отличается от банковского ПО, но не в плане обеспечения отсутствия закладок. Процесс тот же самый.

    Признайте, пожалуйста, что люди, которые занимаются этим профессионально, давно выработали процесс, который удовлетворяет строгим требованиях в банковском, правительственном и прочем софте, и этого процесса придерживаются. Вы, будучи, видимо, человеком со стороны, считаете этот процесс нерабочим. Ну что ж, предложите другой, работающий. А мы пока будем продолжать использовать проверенный подход.

    Другое дело, что написание собственного браузера, собственного офиса, собственной операционки, собственных мессенджеров, собственного всего — экономически нецелесообразен. Увы, придется жить с написанным за бугром. Максимум, что можно сделать — это использовать софт с открытым кодом (Firefox, OpenOffice) и таки проводить аудит (но иметь в голове всегда, что аудит, скорее всего, тонкие закладки не найдет). Нужно обкладывать госслужащих кучей firewalls (OpenBSD?), систем мониторинга подозрительной активности по типу той, что обнаружила атаку внутри RSA в процессе экскалации привилегий, и так далее, и тому подобное.

    Но сидеть сложа ручки “а, аудит невозможен, так что давайте ничего и не делать” — это халатность, если мы говорим о службе безопасности.

  • 5. 23rd April 2011, 20:22 // Александр Венедюхин ответил:

    Да нет, Vlad, я не со стороны. И про “аудит невозможен” – это Вы ж написали, не я. Кстати, “процесс”, который просите признать, Вы не описали, а он, на самом деле, не полагается исключительно на проверку лично разработчиков (иначе – как бы сертифицировали продукцию Cisco или, например, Microsoft?). Ну да ладно. Хорошо хоть сами признали, что экономически нецелесообразно велосипеды изобретать.

  • 6. 25th April 2011, 13:41 // Читатель jno написал:

    Ну, писал я и банковский софт. Тиражный, между прочим. И что? Никто меня не проверял. Это, так сказать, раз.

    “Выработанный процесс” в этом секторе – штука хорошая, но лечит другую болезнь: распределяет и “оптимизирует” ответственность разных лиц. Дополнительный (к штатному тестированию) отлов багов – приятный бонус, не больше. Это – два.

    Процессы вырабатывают не только банкиры – в авиапроме, к примеру, процедур не меньше. Есть и стандарты на каждый чих – в том числе и на организацию разработки ПО. И там уже давно в ходу термин “верификация кода” (а не аудит и, тем более, тестирование). Это – три.

    Но настоящая доказательная верификация – это дорого (в любом смысле). Это – четыре.

    А теперь попробуем из этих пунктов сложить подход к разработке/внедрению *МАССОВОГО* FOSS-браузера:
    1. разработка ведётся незнамо кем, непойми где.
    2. ответсвтенность разработчика варьируется от “AS IS” до пресловутых “не более пяти баксов в любом случае”.
    3/4. для применения реальных процедур *доказательства* соответствия кода спецификации просто нет средств!

    Что тут можно изменить?

    Похоже, что только крайние пункты – за счёт средств госбюджета (или всё же “госбюджетов”? нам одним он нужен, что ли?) простимулировать пару-тройку команд разработчиков на применение процедур в духе всё тех же ARP-4754, DO-178, ARINC-653 и т.п. (могу путать номера – давно уж “не в теме”).

    http://www.osp.ru/os/2005/05-06/185577/ тут вот, кому интересно, некий список стандартов в тему.