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

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

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

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

Отчеты, представляемые вышестоящему руководству, должны быть короткими (в идеале — в одну страницу и никогда больше двух), легко читаемыми и легко понятными.

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

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

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

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

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

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