Случай 1: Контроль целостности

В 1996 году один из самых первых Web-магазинов начал работать на полную мощность, и в его внутреннюю сеть извне проник хакер. Торговая система состояла из примерно 20 Web-серверов, подключенных к центральному серверу с базой данных. Когда администратор системы понял, что хакер проник через МСЭ и теперь пытается проникнуть внутрь сервера, его охватила вполне понятная тревога.

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

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

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

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

Случай 2: Анализ уязвимостей

"Мы используем систему поиска уязвимостей, объединенную с системой управления сетью для того, чтобы получить информацию о правах пользователей, привилегиях, о доступе к учетным записям, ограничениях на доступ к учетным записям, и определить пользователей, которые имеют легко подбираемые пароли".

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

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

Случай 3: Обнаружение атак на сетевом уровне

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

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

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

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

В течение 72 часов мониторинга защиты офицер СБ наблюдал регулярные попытки входа в систему при помощи трех учетных записей в 1:30, в 2:30 и в 3:30 ночи. Все указывало на то, что это была автоматическая программа, использующая эти три учетных записи для входа в систему в одно и то же время каждый день. Используя возможности прогнозирования инструмента обнаружения атак, офицер СБ просматривал данные в течение последних трех дней с целью определения других случаев доступа и запуска этих учетных записей в течение этих отрезков времени. Следующая попытка заключалась в том, чтобы поговорить с владельцами этих учетных записей с целью определения, знают ли они о программах, которые запускаются под их учетными записями в течение этих отрезков времени. Благодаря комбинации анализа данных и опросу конечных пользователей было определено, что для электронной почты использовались интерактивные MAPI-входы. Теперь эта картина рассматривается в качестве санкционированной.