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

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

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

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

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

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

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

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

Я схожу с ума, когда узнаю, что системные администраторы не обучают своих пользователей. Слишком часто при установке систем и формировании учетных записей пользователям не объясняют важность правильного выбора и правила обращения с паролем. Также довольно распространенным среди системных администраторов является отсутствие привычки тестировать пароли. Иногда у них действительно на это нет времени. Но во многих случаях они просто не знают, как это делать, и боятся или затрудняются спросить об этом.

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

Тому, кто проводил аудит в прошлом году, должно быть стыдно за то, что в отчете не указывается, сколько ненадежных паролей было обнаружено. Мне трудно поверить, что положение с ними было хуже, чем в этом году. К тому времени, как Crack завершил свою работу, им было взломано целых 190 паролей в системе с 520 пользователями. Почти каждый второй пользователь имел ненадежный пароль. При таком соотношении лучше было бы отказаться от паролей вообще. Почему бы просто не транслировать пароли по National Public Radio, чтобы напоминать их любому служащему, который позабыл свое второе имя или день рождения?!

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

Для определения нарушений связей между сотрудниками я начала с верхнего уровня руководства и пошла сверху вниз. На своем пути я сделала ряд блестящих открытий.

• Руководство высшего уровня никогда не требовало и не получало отчетов о том, делаются ли какие-либо изменения в сети, повышающие ее безопасность.

• Руководители просто считали, что проблемы безопасности будут решены только потому, что они об этом сказали.

• Отдел системных администраторов был неукомплектован, и его сотрудникам не хватало времени на решение этих проблем в системах.

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

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