Не надо думать как хакер!

Не надо думать как хакер!

Всякая сложная проблема имеет простое, очевидное, неправильное решение. 
—народная мудрость

Автор: Махметов Геннадий

«Чтобы защититься от хакеров, нужно уметь думать и действовать, как хакер». Мне кажется, или действительно никто не подвергает это утверждение сомнению? Я вижу его, или подобные ему мнения, и в интернете, и даже в специальной литературе.

Давайте не будем ходить далеко. Ответьте для себя на один вопрос: как достичь безопасности разрабатываемого программного обеспечения? Думаю, подавляющее большинство читающих эти строки ответит примерно одинаково: искать уязвимости и устранять их. Я уверен, будут обязательно упомянуты и тестирование, и инспекции кода, и программы автоматизированного поиска уязвимостей. Наиболее продвинутые вспомнят какой-нибудь «threat analysis» — методику обнаружения уязвимостей на этапе проектирования — и скажут, что именно использование подобных методик называется «security by design».

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

В этой статье я иллюстрирую свое мнение. В ней я делаю обзор идей, которые будут изложены в более поздних работах; я не пытаюсь что-либо обосновывать, я просто обозначаю свою точку зрения, все доводы будут представлены позже.

Маленькое отступление

Термин «хакер» очень неоднозначен. Он зачастую применяется в абсолютно разных ситуациях. Так мне приходилось встречать это слово, как минимум, в следующих значениях:

  • человек, очень хорошо знающий программу или устройство;
  • человек, творчески подходящий к решению задачи;
  • человек, занимающийся взломом программ и информационных систем.

Давайте не будем спорить о правильности названия. Договоримся, в этой статье я буду использовать термин «хакер» для обозначения человека, который занимается поиском уязвимостей программного обеспечения.

Возможно, это несколько натянутое решение. Но я просто не придумал ничего лучше, прошу читателя меня простить.

В чем проблема?

Все верят, что взламывая, мы можем защититься от взлома. Эта вера влечет за собой очень важные последствия:

  • поиску и устранению уязвимостей учат во всех учебных центрах, занимающихся «безопасностью»;
  • учат, естественно, хакеры;
  • учат только поиску и устранению уязвимостей;
  • мы планируем поиск и устранение уязвимостей во вновь разрабатываемой программе;
  • мы планируем обучение программистов именно поиску и устранению уязвимостей;
  • мы нанимаем новых сотрудников, которые умеют искать уязвимости;
  • мы покупаем программное обеспечение для поиска уязвимостей в наших продуктах;
  • мы покупаем услуги сторонних компаний для проведения поиска уязвимостей в наших продуктах.

Ищем уязвимости, ищем уязвимости, ищем уязвимости… Мы верим, что все эти меры сделают наши приложения безопаснее.

Мы активны! Мы не миримся с нашими проблемами, мы над ними работаем!

Кажется, это называется прокрастинация. Когда мы сталкиваемся со сложной проблемой и не знаем, как с ней справиться, мы очень часто начинаем делать «что можем». В этом случае мы занимаемся бесполезными делами, даже если знаем, что они бесполезны, и мы продолжаем заниматься ими, даже если это не приносит результата: ведь мы заняты, мы не бездельничаем, мы стараемся. Можно сказать об этом поведении и по-другому: искать, где светло, а не там, где потерял.

С другой стороны — маркетинг. Что же лучше продемонстрирует нашим клиентам нашу заботу о безопасности? Конечно, давайте расскажем им, как мы героически разыскиваем уязвимости. Мы расскажем, и всем-всем станет понятно: мы не закрываем глаза на недостатки, мы пишем умные книги, проводим конференции, мы работаем над собой.

Так давайте разбираться, действительно ли наш подход работает. Или может нам надо начать делать что-то другое?

Простая аналогия

Любая аналогия хромает. Тем не менее, их использование позволяет автору лучше донести свою идею, поэтому я начну именно с аналогии, но прошу не воспринимать ее слишком прямолинейно.

Поговорим об автомобилях. Возьмем машину, ВАЗ, «пятерку», и я попрошу вас довести ее до состояния современного автомобиля, например, банального Форда Фокуса. Можете менять любые детали!

Давайте даже применим принцип «by design». Давайте предположим, что вы можете вносить некоторые изменения в проект нашего автомобиля. Как вы считаете, сможете вы довести его «до кондиции»?

Кто-то верит, что это осуществимо? Думаю, найдется не так много наивных, которые бы поверили, что я предложил осуществимую задачу. Да, я понимаю, вы можете в конце концов изменить автомобиль до неузнаваемости и получить вполне приличный экземпляр, особенно, если вы используете «by design». Но не проще ли тогда было изначально выбросить негодные чертежи и начать все с чистого листа?

Хорошо, думаю договорились. А если я теперь попрошу вас запатчить «дырявую» программу?

Разработчик или хакер

Давайте поговорим о навыках.

На первый взгляд, кто как не хакеры лучше всех знают, как защитить программу? Действительно, эти парни могут эффектно продемонстрировать проникновение в систему, заставить программу делать совсем не то, что предполагал ее разработчик или пользователь. Значит, именно они лучше всего эту программу смогут и защитить! Правильно?

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

Кажется странным? Тогда подумайте, хакеры изучают уже готовый объект — программу, протокол, «железку», или что еще можно взламывать. С другой стороны, разработчики создают новые, до этого времени не существовавшие объекты, новые сущности с заданными свойствами, в том числе с заданными свойствами безопасности.

Таким образом, хакер не разработчик. Знания и навыки хакера и разработчика настолько разные, что практически не пересекаются. Поэтому опыт хакера, каким бы богатым он не был, абсолютно не помогает разрабатывать программы, в том числе (особенно?) безопасные программы.

Чтобы стать разработчиком, хакеру нужно время. Чтобы стать специалистом — другими словами, понять хоть что-то, — нужно примерно 5 лет упорного труда; достигнутый при этом уровень в данной области — уровень выпускника вуза. Чтобы стать действительно хорошим специалистом, способным самому решать подобные задачи, консультировать и учить этому других надо лет 8-12, в зависимости от того, что считать «хорошим специалистом». Более того, у меня есть основания думать, что опыт хакинга мешает пониманию методов безопасной разработки, но этот вопрос требует отдельного подробного разговора, давайте пока про это забудем.

Потрудившись, хакер может стать разработчиком.

Вопрос: а нужно ли это хакеру? Нужно ли ему тратить время и усилия, когда у него и так уже есть востребованные навыки?

Хакинг не работает

Я предвижу очень важное возражение.

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

Будем искать и устранять уязвимости. Давайте создадим программу «как получится», а затем будем шаг за шагом устранять имеющиеся в ней проблемы.

Кажется, это разумный подход. Действительно, программа — объект конечный, а это значит, что в ней есть только конечное число уязвимостей. Устраняя их одну за другой, мы рано или поздно придем к идеально защищенной программе.

Согласны? Подход разумен?

Только что-то мне это напоминает… В одной из своих статей я уже писал, что самым первым методом разработки был метод code-and-fix (он используется уже лет 40). Согласно этой методике программа как раз и разрабатывается, «как получится», а потом, при необходимости, в нее вносятся изменения. Причем одним из главных преимуществ этой методики является низкая квалификация, требующаяся от разработчика.

Методика code-and-fix очень быстро доказала свою низкую эффективность. Она работает исключительно при решении крайне простых задач; при создании более или менее сложных программ методика быстро приводит к краху проекта: устранение одной ошибки создает новые, зачастую более серьезные проблемы.

Посмотрите что происходит сейчас с безопасностью. Разве мы видим не то же самое?

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

Так нужны ли хакеры?

Считаю ли я, что хакеры вообще не нужны? Действительно, из того, что я написал, может показаться, что, по моему мнению, хакеры вообще не играют никакой роли в защите информации.

Это не так. Хакеры играют несколько крайне важных ролей.

Хакеры играют роль нападающих. Думаю, ни у кого уже не остается сомнений, что кибервойны уже стали важным аспектом нашей жизни. Чтобы успешно вести такие войны необходимо уметь не только защищаться, но и атаковать, возможно даже, это умение более важно в данном контексте. И здесь мы никак не обойдемся без наших хакеров, к нашему счастью, очень хороших.

Хакеры помогают нам выбрать продукт для покупки. Когда мы покупаем программы или оборудование сторонних разработчиков, нам надо иметь возможность оценить их соответствие нашим требованиям. Если безопасность приобретаемого нами продукта нам важна, мы должны иметь возможность ее оценить. И здесь, конечно, очень важную роль играют хакеры: они находят возможные проблемы в исследуемых продуктах. Это помогает нам сравнивать предложение разных разработчиков. Хотя, надо понимать, здесь нельзя ограничиваться только поиском уязвимостей, но это — тоже тема для отдельной большой статьи.

И, наконец, хакеры помогают нам тестировать наши продукты. Если бы мне понадобилось разработать безопасную программу, я возможно(не всегда это нужно!) попросил бы хакера проверить результаты своей работы. Но, если бы он нашел в моем приложении недостатки, я не стал бы его спрашивать, как их исправить, это я должен либо сделать сам, либо попросить другого, более опытного специалиста (но не хакера).

Подводя итог, скажу: я считаю, что хакинг — очень важный элемент обеспечения безопасности программного обеспечения. Главное знать, когда и для каких целей его использовать.

Квантовый кот Шрёдингера ищет хозяина!

Живой, мертвый или в суперпозиции? Узнайте в нашем канале

Откройте коробку любопытства — подпишитесь