Никакая защита не сравнится с ПО, которое изначально разрабатывается с учетом средств защиты и исключением ошибок. Тем не менее идеальное, безошибочное программное обеспечение не решит все проблемы. К сожалению, его уязвимости не единственная наша проблема. Троянские программы срабатывают только потому, что их запускает сам пользователь. Многие хакеры и вредоносные программы используют типичные, часто легитимные возможности данных, языков программирования и других компонентов, чтобы совершать злодеяния. А социальная инженерия может сделать то, на что не способно программное обеспечение. Тем не менее никто не спорит, что более безопасные программы не могут быть панацеей.
В следующих главах мы поговорим о двух экспертах, посвятивших свою жизнь совершенствованию ПО. Глава 7 посвящена Майклу Ховарду, который популяризировал более безопасные методы разработки, а глава 8 фокусируется на Гари Макгроу, одном из лучших специалистов по поиску уязвимостей в истории.
7. Профиль: Майкл Ховард
Майкл Ховард – отличный педагог и энергичный оратор, который за 20 лет работы в сфере ИБ не утратил ни грамма энтузиазма, которым заражает всех, кто с ним сталкивается. Обычно пары минут общения с Майклом достаточно, чтобы собеседник загорелся желанием сделать мир более безопасным с помощью нескольких строк кода. Он получил всемирное признание, написав книгу Writing Secure Code(https://www.amazon.com/Writing-Secure-Code-Michael-Howard/dp/0735615888) вместе с Дэвидом Лебланом. Кроме того, он сделал очень много для того, чтобы компания Microsoft стала приверженцем идеи безопасного программирования. Ховард родом из Новой Зеландии, но сейчас живет в Остине, штат Техас. Он стал соавтором нескольких книг по безопасному программированию и ведет собственный блог.
Примечание. Дэвид Леблан, в соавторстве с которым Ховард написал книгу Writing Secure Code, – еще один прогрессивный специалист по ИБ. Он значительно обезопасил пакет Microsoft Office и создал более безопасную модель браузера, которая в настоящее время используется компаниями Google, Adobe и Microsoft.
Я спросил Ховарда, как он пришел в сферу ИБ. Вот что он ответил: «Я работал над ранними версиями Windows NT в компании Microsoft. Отвечал за такие низкоуровневые аспекты, как контроль доступа, криптография и графические интерфейсы GINA (которые раньше использовались для авторизации в операционной системе Microsoft Windows и других сервисах аутентификации). Это заставило меня задуматься о безопасности как о функции. Примерно в 2000 году стало ясно, что встроенные в продукт защитные функции не делают его по-настоящему безопасным, поэтому мы должны сосредоточиться на разработке безопасных функций, а это совершенно другая дисциплина».
На мой вопрос об истории возникновения концепции SDL в компании Microsoft он сказал: «Со временем различные практики обеспечения безопасности, изученные командами разработчиков. NET Framework, Windows, Office и SQL Server, а также других продуктов, превратились в концепцию SDL (Security Development Lifecycle, жизненный цикл безопасной разработки). Эта концепция помогла популяризировать идею безопасного программирования, и во многом именно благодаря ей компании стали гораздо лучше защищать свое ПО».
Я спросил Ховарда, стала ли концепция SDL результатом совершенствования уже существовавшего подхода или чем-то абсолютно новым, на что он ответил: «Мы все опираемся на работу других людей, однако бо́льшая часть концепции SDL – это результат экспериментов. То, что работает, остается, а то, что не работает или оказывается нецелесообразным, отбрасывается. Иногда я задаюсь вопросом о том, были ли те или иные академические модели опробованы в производственной среде со всеми ее дедлайнами, требованиями к производительности, сроками вывода продукта на рынок, экономическими соображениями, обеспечением обратной совместимости и т. д.
В то время было принято считать, что улучшение качества кода автоматически делает его более безопасным. Но я не видел никаких эмпирических доказательств этой идеи. Вы можете создать функциональный SQL-код, который проходит все функциональные тесты, но он может оказаться уязвим к SQL-инъекциям. Если вы никогда не сталкивались с ними, вы увидите перед собой лишь идеальный код, который делает то, что от него требуется. Безопасная система делает только то, что должна, и не более того, – небезопасной ее делает “дополнительная функциональность”, связанная с уязвимостью к SQL-инъекциям».
Когда я спросил о его роли во внедрении компанией Microsoft концепции SDL, Ховард сказал: «Этому способствовало сочетание различных вещей, над которыми помимо меня работало множество людей. Все началось в конце 2001 года, когда команда разработчиков. NET провела мероприятие, где обсуждались текущие проблемы безопасности и потенциальные риски. Благодаря ему мы многому научились и добавили множество новых средств защиты. Я помню, что для этого мероприятия было заказано несколько футболок с нанесенной на них датой конференции, правда, из-за начавшейся снежной бури ее пришлось отложить… Так что по иронии судьбы на мероприятии, посвященном повышению безопасности кода, мы все ходили в футболках с неправильной датой. Однако уроки, полученные в ходе этой конференции, в итоге были положены в основу концепции SDL. Публикация нашей с Дэвидом книги заставила многих людей задуматься о безопасности кода. В 2001 году система компании Microsoft подверглась множеству атак со стороны хакеров и вредоносных программ. Особенно серьезный ущерб нанесли черви Code Red и Nimda. Билл Гейтс спросил нас о природе уязвимостей в ПО и о том, почему мы до сих пор их не устранили. Будучи частью команды, с которой он встретился, я вручил ему раннюю копию книги Writing Secure Code, и после встречи он написал свою знаменитую заметку «Надежные вычисления»(https://www.wired.com/2002/01/bill-gates-trustworthy-computing/), в которой упомянул нашу книгу, благодаря чему ее продажи выросли в разы! В итоге я перешел на работу во вновь созданное подразделение надежных вычислений Microsoft. После этого был проведен ряд аналогичных мероприятий, посвященных проблемам безопасности ОС Windows, SQL Server и многих других продуктов Microsoft. Все это способствовало проработке концепции SDL, которая обновляется практически ежегодно».
Я спросил, действительно ли он и компания Microsoft предоставили больше информации и инструментов, связанных с безопасным программированием, чем любая другая организация. Он сказал: «Однозначно да! Но что еще более важно, все эти инструменты и методы мы используем в своей производственной среде, ежедневно применяя их к миллионам строк кода. Это не отвлеченная теория. Это то, чем занимается одна из крупнейших компаний в мире. И она охотно делится своим наработками».
Я спросил, почему количество публично анонсируемых уязвимостей не сокращается, несмотря на то, что программисты все больше узнают о проблемах информационной безопасности. Вот что сказал Ховард: «Отчасти это связано с появлением все большего количества программ, содержащих множество строк кода. Однако главная проблема заключается в том, что программистов все еще не обучают методам безопасного программирования, и они плохо осознают основные угрозы. Большинство образовательных программ не отвечают современным потребностям. На днях, просматривая учебную программу по информационной безопасности одного университета, я обратил внимание на то, что почти половина занятий посвящена низкоуровневым сетевым угрозам. Я не обнаружил лекций по обеспечению безопасности облака или безопасному программированию. Наши колледжи все еще выпускают программистов, которые мало что знают об информационной безопасности и разработке безопасного ПО, что довольно странно, учитывая то, что этим выпускникам предстоит создавать критически важные системы, подключенные к Интернету. Я до сих пор нахожу примитивные ошибки в коде других людей. Когда я демонстрирую им весьма распространенную проблему, связанную с повреждением памяти, или уязвимость к SQL-инъекции, на меня смотрят так, будто я совершил нечто невероятное. Программисты, знакомые с основами информационной безопасности, встречаются так редко, что я радуюсь, если кандидат хотя бы проявляет интерес к этой теме. Если программист внимательно слушает, когда я говорю о проблемах ИБ, это делает меня счастливым. Если человек заинтересован, мы можем научить его всему остальному. Но вы даже не представляете, скольким людям нет до этого никакого дела, и одна из главных причин в том, что их этому до сих пор не учат. Или учат, но не тем вещам, делая акцент на сетевой безопасности или каких-нибудь мелочах. Студентам подробно описывают принцип работы алгоритма RSA, но не объясняют, почему он должен использоваться, какие проблемы он решает и для каких целей подходит лучше всего. Умение правильно использовать инструмент для решения реальных проблем безопасности гораздо важнее понимания принципа его работы. Любой человек может разобраться в работе протокола, однако нам нужны люди, осознающие риски и думающие о решениях. Правда, существуют некоторые преподаватели и колледжи, которые придерживаются правильного подхода, например Мэтт Бишоп из Калифорнийского университета в Дэвисе. Он и другие неравнодушные преподаватели – настоящие герои».
Я спросил, что может сделать сам программист, учитывая то, что большинство колледжей недостаточно хорошо готовят студентов в этом отношении. Он посоветовал: «Постоянно учитесь. Я ежедневно выделяю час на учебу. Я читаю, пишу код и экспериментирую с чем-то новым. И занимаюсь этим на протяжении всей своей карьеры. Кроме того, если в вашем учебном заведении нет формального курса по информационной безопасности, разработайте собственную обучающую программу. Перейдите на сайт https://cve.mitre.org/cve/ и внимательно прочитайте о недавно обнаруженных уязвимостях. Затем напишите код, содержащий одну из них, и подумайте, что нужно было сделать для предотвращения ее появления как на техническом уровне, так и на уровне процессов. Выясните, откуда взялась эта уязвимость и как именно попала в код. А затем используйте извлеченные уроки, чтобы предотвратить появление подобных ошибок в вашем собственном коде».