Коллектив авторов - Защита от хакеров корпоративных сетей

Разве программа не могла потребовать, чтобы законный пользователь помнил ключ расшифровки? Могла, но тогда почему пароль клиента запоминается в первую очередь? Только для того, чтобы пользователь не вводил пароль постоянно.

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

Функциональное тестирование значительно отличается от тестирования безопасности, хотя на первый взгляд это близкие понятия. Оба тестирования ищут дефекты программ, правильно? И да, и нет. Тестирование безопасности требует гораздо более глубокого анализа программы и обычно включает экспертизу исходного кода программы. Функциональное тестирование проводится для гарантии того, что большой процент пользователей сможет эксплуатировать программу без жалоб. Защититься от среднего пользователя, случайно споткнувшегося на проблеме, намного легче, чем попытаться защититься от хорошо осведомленного хакера, пытающегося взломать программу любым доступным ему способом.

Даже без подробного обсуждения того, что собой представляет аудит безопасности, его необходимость очевидна. Сколько коммерческих средств подвергается проверке безопасности? Практически ни одно. Обычно даже те немногие, которые имеют хотя бы поверхностный обзор безопасности, считаются безопасными. Хотя позднее часто становится очевидным, что они не прошли должную проверку.

Заметьте, что этот закон содержит слово «начала». Аудит безопасности – только один шаг в процессе создания безопасных систем. Для того чтобы понять, что в защите систем программного обеспечения полно недостатков, достаточно лишь ознакомиться с архивами списка отчетов любой уязвимости. Более того, можно увидеть одни и те же ошибки, неоднократно допущенные различными производителями программного обеспечения. Ясно, что это относится к классу систем, не подвергавшихся аудиту даже в минимальном объеме.

Вероятно, OpenBSD представляет собой один из наиболее интересных примеров роли аудита в разработке более безопасной системы программного обеспечения. С самого начала в проекте OpenBSD, являющемся ответвлением от главного проекта NetBSD, было решено обратить особое внимание на вопросы безопасности. Команда разработчиков OpenBSD потратила пару лет, занимаясь аудитом исходного кода для поиска и устранения ошибок. Разработчики исправляли любые найденные ошибки независимо от того, относились они к безопасности или нет. При нахождении общей ошибки они возвращались назад и просматривали все исходные коды, чтобы убедиться в том, что подобная ошибка не была сделана где-нибудь еще.

В конечном результате OpenBSD часто считается одной из наиболее безопасных операционных систем. Часто, когда обнаруживается новая ошибка в операционных системах NetBSD или FreeBSD (другой вариант BSD систем), в аналогичных условиях признается неуязвимость OpenBSD. Иногда причиной подобной неуязвимости является решение выявленной в других системах проблемы (случайно) во время обычного процесса исправления всех ошибок. В других случаях недостаток системы защиты был ранее выявлен и устранен. И в этих случаях системы NetBSD и FreeBSD (если в их составе была та же самая часть программного кода) были уязвимы, потому что никто не просматривал базу данных новых исправлений ошибок в OpenBSD (все исправления в OpenBSD обнародованы).