СОИБ. Анализ. Вызовы для ИБ
В ряде случаев возникает необходимость
привести примеры инцидентов ИБ и других сложных ситуаций, которые возникают у
ответственных за ИБ в случае отсутствия комплексной системы обеспечения
информационной безопасности.
Привожу ниже те случаи и инциденты,
которые связаны с наиболее ценной защищаемой информацией (остальные остались за
границами данной заметки):
1.
Администратор бизнес приложения или БД,
используя локальный доступ к консоли сервера, сделал копию большого объема
данных и записал её на свой АРМ или съемный носитель;
2.
Пользователь бизнес приложения за короткий
промежуток времени выполнил просмотр ценной информации по большому количеству
ключевых клиентов (в том числе тех, с которыми ранее не работал), распечатал
или сохранил информацию в файл
3.
Пользователь бизнес приложения, скачал в сети
Интернет клиентское ПО для подключения к БД, подключился напрямую к БД с
использованием своей учетной записи и получил доступ к ценной информации,
которая обычно не отображается в бизнес
приложении;
4.
Сотрудник Организации, знал, подсмотрел или подслушал
пароль другого сотрудника; подключился к бизнес приложению со своего АРМ от
имени другого пользователя и получил несанкционированный доступ к информации
5.
На АРМ сотрудника Организации произошло
заражение и выполнение вредоносного кода, который автоматически просканировал
сервера приложений и БД и получил несанкционированный доступ к ним через не
устранённую уязвимость
6.
Клиент Организации, используя уязвимость
фильтрации данных в бизнес приложении выполнил атаку (например, SQL injection)
и получил несанкционированный доступ к ценной информации
7.
В рамках контроля выполнения требований ФЗ в
области защиты ПДн, аудитор просит предоставить свидетельства регистрации всех
фактов доступа к персональным данным
8.
В рамках контроля выполнения требований PCI
DSS, аудитор просит предоставить свидетельства регистрации всех фактов доступа
к информации о пластиковых картах (Cardholder Data)
9.
В рамках контроля выполнения требований ЦБ РФ,
аудитор просит предоставить свидетельства регистрации всех фактов доступа к
платежной информации
10.
В результате жалобы клиента банка обнаружено,
что одним из сотрудников месяц назад была выполнена несанкционированная
операция (например, перевод денежных средств); Необходимо расследование
инцидента
Хотелось бы услышать что произойдет в
вашей организации не имеющей СОИБ? (будет ли что-то зарегистрировано в
журналах, будет ли предотвращено автоматически какое-то нарушение, будет ли
кто-то автоматически уведомлен, будет ли у вас необходимая информация для
свидетельств)
Хотелось бы услышать что произойдет в
вашей организации имеющей СОИБ?
Что предложите использовать в качестве
контрмеры для данных инцидентов или случаев ИБ?
Можно по части пунктов.
Потом, соответственно, я приведу свои варианты.
Комментарии
a. В базовом случае у нас есть бизнес приложение которое разрабатывалось без учета детальных требований ИБ, есть межсетевой экран и возможно даже средство анализа защищенности.
Средством анализа защищенности обнаружены уязвимости web приложения, но в договоре с разработчиком не были прописаны их необходимость устранения уязвимостей.
Что мы имеем в ситуации 6: атака не обнаружена, так как межсетевой экран не осуществляет детальных проверок на прикладном уровне, а для приложения этот запрос был неотличим от легального.
Инцидент был зарегистрирован только когда Организация узнала об утечке информации из СМИ. Ущерб средний-высокий.
б.
Возможными контрмерами для подобных угроз может быть:
- внешний пентест приложений раз в год + внутренний анализ защищенности раз в квартал + договор с разработчиком бизнес приложения на разработку подсистемы ИБ + договор с разработчиком
- внедрение IPS с поддержкой прикладного уровня + внедрение расширенных функций безопасности СУБД
- внедрение специализированных систем защиты web приложений и СУБД
Что мы имеем в ситуации 6: атака автоматически заблокирована, все события зарегистрированы, администратор ИБ автоматически уведомлен, клиенту отправлено письмо о возможном заражении его АРМ, включен режим детального анализа данного клиента
jungle_vnd 23.10.2012 15:08:01
Хорошие примеры. можно еще добавить "1. вынесли системный блок/сервер/жесткий диск, 2. ИТ-админ уничтожил БД и все резервные копии. 3. Сотрудник, не допущенный к ценной информации, подсмотрел ее на мониторе у соседа. 4. Органы регуляторы отказывают в консультировании по блоку нормативных актов, приостановили лицензию на вид деятельности."
Думаю, в организации с СОИБ произойдет реагирование на инцидент в соответствии с установленными стандартами и регламентами. А инцидент - он разный, многогранный, где-то сложный, а где-то уборщица шваброй махнула )
А еще есть жуткий анекдот:
Больница. Утренний обход. Идут врач в белом халате и санитар с
бензопилой.
Врач:
- Иванову правую руку ампутировать.
В-жжжжж-ик.
- Петрову левую руку ампутировать.
В-жжжжж-ик.
- Сидорову правую ногу ампутировать.
В-жжжжж-к.
- Я сказал правую.
В-жжжжж-к.
- Я сказал ногу.
В-жжжжж-к.
- Я сказал Сидорову!!!
Человеческий фактор, ошибки первого и второго рода.. все в кучу. и нам с этим жить. (с)
3 - я не рассматриваю, так как ценность информации которую можно подсмотреть на мониторе - низка.
Нас интересует защита наиболее ценной информации в консолидированном виде.
4. До внедрения СОИБ или СЗПДн - мы имеем лицение лицензии и большой ущерб.
Контрмера - консалтинг от интегратора в рамках внедрения СОИБ.
После внедрения СОИБ - можем оказывать консультации регулятору.
по 1-2 что скажете коллеги?
По 1. Задним числом при разборках (если всплывет и таковые потом возникнут) факт попадания в серверное помещение (протоколируется) + видеозапись. Автоматом аларма не будет. Теоретически будет при косвенных последствиях - место на диске, сервер просел по производительности во время выгрузки очень больших объемов и т.п.
По 3. Не сможет так просто подключиться к БД, по крайней мере со своего раб. места, защита на сетевом уровне. Попытки будут зафиксированы, админ получит уведомление на мыло.
4. Если скозная аутентификация, допустим АД-шной учеткой, будет аларм, что юзер не со своего компа работает, но это никого не волнует, аларм осядет в базу, потом это можно поднять. Юзеры постоянно это делают и руководство этому не препятствует. Задним числом раскрутить можно будет.
По 5. Смотря какой скан. Если этот скан нарвется на недоступность сетевую - будет автоаларм. Если скан более тонок, т.е. сразу адресно и точечено и куда надо и пускает при этом (а дальше прикладной уровень) - ничего не будет.
Информация для свидетельств для ряда случаев найдется, если я правильно понимаю, что это такое. Syslog централизованный, netflow, (местами и для локального трафика) логи ACL, плотный анализ активности и аномалий на L2.