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

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

Через несколько часов я просмотрела больше их половины. При более глубоком изучении они не казались такими уж восхитительными. Скорее, они подходили под то, что я называю политиками безопасности с высоты 30 000 футов — пространными и тяжеловесными инструкциями, которые должны были произвести впечатление на начальство, но мало полезны людям «в окопах».

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

Я знала, что Шелли скоро проводит меня к выходу, поэтому я посвятила последние минуты просмотру сетевой схемы. В компании S&B имелись тонны серверов базы данных, и клиентская сеть была видна сразу. Было также видно, что к сети было подключено три различных клиента. Каждое соединение было защищено своим брандмауэром. Я догадалась, что это были именно те брандмауэры, которые они только что проверили и готовили к апгрейду.

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

День 2-й: Сетевые соединения

Приехав в S&B Systems, я начала снова думать о сетевой схеме и вспомнила, что они только что провели аудит безопасности соединений их клиентской сети. Заехав на стоянку, я пыталась понять, кто же у них делал аудит.

Шелли уже ждала меня в холле. По дороге в мой временный офис я рассказала ей о том, что вчера потратила вторую половину дня на просмотр политик и процедур. Когда мы прибыли в мой офис, я показала ей сетевую схему и заметила: «Я не представляла себе, что несколько различных компаний подключены к вашей сети». Она ответила: «Это так. Мы многое перевели на аутсорсинг в этом году. Мы оставили в компании лишь в главные функции, а остальные отдали подрядчикам». Показывая на сетевую схему, я спросила: «Это те системы, на которых только что проводился аудит?» Она ответила: «Да, и вон те системы тоже». Шелли показала на группу серверов баз данных (обозначенных как DBS1 — DBS 10), которые явно принадлежали интранет S&B и не были похожи на клиентскую сеть (экстранет).

Но Шелли сказала: «Нет, это тоже клиентские системы. Видите ли, мы в прошлом году перевели на аутсорсинг отдел перевозок, а это системы его баз данных». Это все проясняло. DBS должно было обозначать «база данных о перевозках» (database shipping).

Теперь я почувствовала прилив энергии. Это как раз был такой риск, который я искала.

Шелли начала рассказывать мне, что когда S&B переводила на аутсорсинг операции по перевозкам, то она подключила системы DBS к сети Express Time. S&B по-прежнему поддерживала и обновляла базу данных, но Express использовала информацию о перевозках, хранящуюся на этих системах, для поставки изготовленных машин потребителям.

При более пристальном изучении схемы я заметила, что система DBS 10 имела два сетевых соединения. Одно шло к интранет S&B, а другое не имело обозначения. Я предположила, что оно идет к сети Express Time.

В технике Шелли не очень разбиралась. Иначе она бы поняла, что из сказанного ей выходило так, что серверы службы перевозок S&B были подключены к сети Express Time. Таким образом, как только вы открывали сессию на сервере перевозок, вы могли получать доступ к любой системе сети Express Time. И наоборот, открытие сессии на сервере перевозок со стороны Express Time позволяло получать доступ к любой системе сети S&B.

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

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

Поразительные ошибки в защите

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

Шелли продолжала говорить, но я уже полностью настроилась на другую тему. Я могла думать только о том, что мне нужно будет искать в системе DBS 10. Я начала думать о подходе к своему аудиту. Проведение аудита самой сети — это превосходно, но из него всего понять невозможно. Например, вы не сможете сказать, каким образом устанавливаются разрешения на доступ к файловой системе или какие скрипты определения ID пользователя (setuid) используются.

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

Я задумала сейчас просто войти в сеть, попытаться получить доступ в DBS 10 и оценить риски. После этого я проведу все остальные обязательные тесты.

Сначала я проверила таблицу паролей сетевой информационной службы (NIS-Network Information Service). S&B использовала файл сетевых паролей с зашифрованными паролями. В таблице было около 100 паролей. Я вынула мою «дорожную» дискету из портфеля и переписала один из моих любимых инструментов для проверки защиты — программу взлома паролей под названием Crack. (Подробнее см. Приложение А, «Люди и продукты, о которых следует знать».) Я немедленно запустила Crack на работу с файлом паролей. Уже через 60 секунд Crack взломал 10 паролей. Один из них был для учетной записи, названной dbadmin, как я предположила — для администрирования базы данных!

Моя догадка, что для всех серверов базы данных используется учетная запись dbadmin, оказалась верной. Теперь я имела доступ ко всем серверам перевозок. Мне даже не надо было регистрироваться с помощью учетной записи, которую создала для меня Шелли.

Сейчас, когда я была в сети, я открыла сессию на DBS 10 и проверила свое предположение. Оно оказалось правильным! DBS 10 был подключен к сети Express Time, и у него не было настроек безопасности вообще — даже патчей. После получения полного доступа к DBS 10 я легко добилась полного контроля (прав суперпользователя[49]) над системой. Я могла, как мне заблагорассудится, перескакивать из одной системы в другую на правах суперпользователя.

Это было ужасно. Я легко бы смогла обрушить эти системы, не оставляя следов моего визита. То же мог сделать каждый имевший доступ в любую из сетей! Для любого плохого парня, желающего украсть информацию, внедрить «Троянского коня», спустить с поводка вирус или установить бомбу с часовым механизмом, S&B была настоящей находкой.

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

Теперь я выявила главные проблемы. Разумеется, в этом месте книги вы почти все из них уже знаете наизусть.

• Никто не писал каких-либо политик и процедур аудита.

• Точно так же никто не писал каких-либо политик и процедур по поддержке клиентских сетей.

• Персонал технической поддержки не получал должного обучения по вопросам безопасности.

• Безопасность сети для клиентских подключений была недостаточной.

• Слишком легко мог быть получен доступ к корневому каталогу.

• Не были установлены патчи, повышающие безопасность.

• Разрешения на доступ к файлам раздавались направо и налево.