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/ и внимательно прочитайте о недавно обнаруженных уязвимостях. Затем напишите код, содержащий одну из них, и подумайте, что нужно было сделать для предотвращения ее появления как на техническом уровне, так и на уровне процессов. Выясните, откуда взялась эта уязвимость и как именно попала в код. А затем используйте извлеченные уроки, чтобы предотвратить появление подобных ошибок в вашем собственном коде».

На вопрос о том, что могут сделать компании для создания более безопасного кода, помимо следования текущим принципам SDL и использования доступных инструментов, он ответил: «Сделайте так, чтобы программисты не только понимали теоретические основы, но и осознавали реальные угрозы. Кроме того, вам следует встроить процесс обеспечения безопасности в сам конвейер разработки ПО, чтобы плохой и небезопасный код не мог в него попасть. В Microsoft мы используем так называемые ворота качества. Хороший (не связанный с безопасностью) пример – это написание кода, который предполагает, что все IP-адреса состоят из четырех октетов. Это означает, что такой код никогда не будет работать в чистой среде IPv6. Этот код даже не сможет пройти проверку, поскольку специальный инструмент, работающий в автоматическом режиме, выявит проблему и предотвратит его сохранение в системе. Вот что мы подразумеваем под термином “ворота качества”. В целях обеспечения безопасности этот же подход можно применить для выявления уязвимостей к SQL-инъекциям, угроз, связанных с безопасностью памяти, и всего того, что вы не хотите видеть в своем коде.

Если бы меня попросили назвать несколько основных практик, связанных с обеспечением безопасности, то я выбрал бы следующие:

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

• разработчикам/архитекторам/менеджерам, отвечающим за создание ПО, необходимо освоить методы моделирования угроз и убедиться в том, что их система предусматривает соответствующие средства защиты;

• наконец, тестировщики должны доказать неправоту разработчиков, создавая или приобретая инструменты, которые генерируют вредоносные и/или недействительные данные. Цель в том, чтобы выявить недочеты, допущенные разработчиками, если они есть.

Разумеется, это далеко не все, что требуется для обеспечения безопасности ПО, но, на мой взгляд, это те фундаментальные навыки, которыми должны обладать все инженеры-программисты».