IT-безопасность: стоит ли рисковать корпорацией?

Знакомясь с отчетом по аудиту, составленным Мартином в прошлом году, я обнаружила, что его трудно читать. В нем сообщалось обо всех рисках, но техническим языком и без каких-либо логических связей. Если бы руководство получило этот отчет, то оно бы не знало с чего начать. Я потратила больше времени, чем планировала, чтобы докопаться до полезной информации в отчете.

Разобравшись с отчетом Мартина, я поняла, с какими системами финансовой сети связан наибольший риск. Я прозондировала вначале информацию этих систем. Затем сняла копию таблицы паролей и запустила программу Crack. Мне нравится начинать аудит с взлома паролей, потому что я хочу увидеть, как много можно их взломать с первого захода. В таблице содержалось 520 паролей пользователей — это довольно много. Поэтому мне, возможно, удастся взломать некоторые из них. И мне удалось. Просмотр файла crack.out показал, что 10 паролей были угаданы с первого раза. Я столько и ожидала. Оставив просмотр дальнейших результатов программы Crack на более позднее время, я сосредоточилась на аудите систем повышенного риска.

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

Я не считаю, что тест на проникновение всегда необходим. Например, в системе оказалась старая версия Sendmail. Общеизвестно, что такая система может быть взломана. Зачем же тратить время для того, чтобы доказать, что вода мокрая?

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

В данном аудите тест на проникновение, определенно, не был необходим. Руководство знало, что сеть может быть взломана. (И я была здесь потому, что хакерам это было тоже известно!) Аудит должен был ответить на вопрос, почему сеть все еще уязвима. Зная это, я отказалась от проведения теста на проникновение и пошла дальше.

Я приступила к проверке наиболее ответственной финансовой системы. Она была широко открыта и не имела патчей безопасности. Я взломала корневой каталог, использовав очень старую программную ошибку в защите. Легко обнаруживалось, что эти системы имели стандартные настройки и не было установлено никаких дополнительных средств защиты. Я протестировала вторую систему, затем третью и четвертую. Та же история. Насколько мне было видно, абсолютно ничего не изменилось с тех пор, как был проведен последний аудит безопасности. Было ясно, что сотрудники нижнего уровня («находящиеся в окопах») не устранили проблем.

Вопрос, вполне подходящий для телевикторины $64 000 Question:[14] почему не устранили? Определенно, проблемы безопасности в ISD должны были быть решены. Либо линейные менеджеры[15] не слышали распоряжения Чарльза сверху, либо они не хотели его услышать.

Скорее всего, когда Чарльз сказал своим людям: «Сейчас же устраните проблемы безопасности», он посчитал вопрос закрытым. Он никогда не проверял, выполняется ли его распоряжение. Какими бы причины не были, проблемы не были решены, и Чарльз не получил желаемых им результатов.

Говоря о результатах, я вспомнила, что у меня все еще работает Crack. Желая узнать, как много еще паролей Crack может взломать, я проверила файл crack.out снова. Невероятно! Было взломано еще 100 паролей. Еще более удивительным было то, что Crack не закончил свою работу! Он все еще «долбил», пытаясь угадать пароли. Очевидно, что пользователей никогда не учили тому, как выбирать надежные пароли. Также было очевидно, что системный администратор никогда не заботился о проверке надежности паролей.