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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Линейные менеджеры также запросили расширить штат сотрудников по обеспечению безопасности сети. На это в бюджете опять не оказалось денег. И снова окончательный ответ на этот запрос был отложен на будущее.

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

Удивительно, как много можно узнать из бесед с сотрудниками. Досадным в этой истории являлось то, что линейные менеджеры знали, что их системы все еще оставались незащищенными. Тем не менее высшее руководство было в неведении. Это случилось потому, что оно не потребовало отчета о решении проблем. Линейные менеджеры знали, что ничего не делается, но не проявляли инициативы в докладе наверх. В результате этого высшее руководство по-прежнему оставалось в неведении. Оно твердо было уверено в том, что все сделано и все шло своим чередом.

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

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