Вот ровно в этом вопросе и заключен весь смысл сделанного.
Все изменения структуры таблиц мы “запихнули” в скрипты. Да, исторические данные при подключении конвертируются автоматически. Там возникают ошибки, верно, мы отлаживали эту систему 5-7 лет в общей сложности. Изменения были разные, простые и сложные. Упор был именно на то, что обычный администратор (не DBA!) при нашей поддержке, не обладая знаниями и умениями (ну, или обладая начальными), сможет проводить работу по управлению секциями. Мы очень часто, особенно на раннем этапе, входили в организации, где не было Oracle, и должны были работать в таких условиях.
Часть скриптов обеспечивает трансформацию данных из старых форматов (не только перестроение структуры таблиц, но и их логическое наполнение ), и еще часть пытается обеспечить надежное выполнение этих действий в отсутствие ораклового специалиста. Понятно, что эта цель выглядит крайне амбициозной, но система доказала свою жизнеспособность и работает. На поддержке у нас есть проблемы, связанные с отключением/подключением секций, но, как правило, они связаны со внешними причинами технического характера.
Да, скрипты целиком выложить не можем — это часть продукта, и они раскрывают схему хранения.
Но мы готовы отвечать на вопросы, если вам интересно, как реализованы какие-то конкретные вещи. Кусками можем проиллюстрировать.
1. Сделайте, пожалуйста, картинку с описанием сценария заражения кликабельной — очень мелко, сложно прочитать.
При открытии в новой вкладке картинка, вроде бы, грузится в полном размере.
Вопросы:
1. В статье указано, что заказчику были переданы образы, логи и т.д. для подачи в правоохранительные органы. Вы фиксировали доказательства с процессуальной точки зрения таким образом, чтобы они были приняты судом? (например жесткие диски были запечатаны в конверты и вскрытие только в присутствии эксперта, комиссии и т.д.). Интересно узнать практику оформления таких мероприятий.
Образы были сделаны с помощью специализированного АПК, сами жесткие диски модификации не подвергались. При исследовании образов мы преследовали не криминалистические, а скорее технические цели. Для полноценного криминалистического исследования заказчик самостоятельно должен отдать жесткие диски на экспертизу в некоммерческую организацию. Но наше заключение хоть и не является экспертизой, вполне сойдет за косвенное доказательство как исследование. Практика чаще всего такова, что если заказчик изначально хочет идти в правоохранительные органы, он привлекает соответствующие организации, которые имеют право проводить соответствующую экспертизу.
2. Злоумышленники получили УЗ доменного админа. Удалось установить, как это было сделано?
К сожалению, в силу давности событий нам не удалось установить, как произошла компрометация.
3. У меня сложилось впечатление, что векторов атаки все же могло быть несколько — через УЗ доменного админа (хотя эта УЗ, на мой взгляд, стала бонусом) и/или локального админа (он, скорее всего, был с одинаковым паролем, как минимум для пользовательских машин), а потом получили уже и доменного админа. Еще вариант: пользователь с правами локального администратора.
Почти наверняка Вы правы. Скорее всего, произошла компрометация обычной пользовательской машины, потом mimikatz, получение новых учеток, а дальше уже и доменный администратор.
Если говорить про сотрудников компании, то признаков их вовлеченности в процесс хищения критичной информации мы не обнаружили. Если у заказчика и были внутренние подозрения в отношении сотрудников, нам они неизвестны.
Что касается поиска внешних злоумышленников, то информацию по всем индикаторам, внешним адресам, участвующим в атаке, снятые образы хостов и значимые исходные логи мы передали заказчику для дальнейшего разбирательства с правоохранителями. Финал истории нам, увы, неизвестен.
Сейчас тема о «размытии сетевого периметра», облаков и BYOD в большом почете. Надо только расписать руководству все риски таких подходов. Если руководство подписывается под этими рисками, то безопаснику только и остаётся работать в заданных условиях.
Целиком согласны. Именно о таких ситуациях с заданными условиями мы и пишем статьи :)
Тут кстати интересный вопрос, что еще дешевле выйдет, закрыть прямой доступ в интернет (воздушный зазор) или доступ оставить и озаботиться услугами SOC аутсорсера.
К сожалению, здесь вопрос не про деньги. Первый подход с точки зрения расходов ИБ стоит дешево, но целиком сказывается на динамике и мобильности самого бизнеса, которую «в лоб» деньгами не измерить. И чаще всего именно из-за этого и редко применяется в принципе и практически отсутствует в коммерческом секторе.
Милитаристский подход к обеспечению безопасности — достаточно эффективный и позволяет закрыть много векторов угроз. Но сторонники этого подхода сейчас находятся скорее в начале пути с согласованием политик и блокировок (закрыть прямой доступ в интернет в крупной компании и обеспечить управление уязвимостями — те еще задачи, каждая на медаль тянет), а безопасность нужна уже сейчас. А вообще большинство организаций, особенно коммерческих, все чаще двигаются в обратную сторону: минимизация жестких запретов и предоставление допустимой свободы бизнес-пользователям, но при этом всеобъемлющий мониторинг активностей с возможностью вмешаться и воздействовать в критической ситуации.
Скажем так, построить «SOC в базовой комплектации» из 5 элементов реально. Но если мы сейчас назовем их, какой же людям будет интерес дальше отвечать?)
К тому же, все-таки компании, понимающие, что им нужен SOC, обычно уже обзавелись, как минимум, антивирусом. Поэтому если мы подразумеваем, что у заказчика есть базовые системы защиты, дальше многое зависит от специфики его бизнеса.
Вы абсолютно правы, задача действительно очень сложная, но, как правило, детализация нужна вокруг критичных систем и данных, там важны нюансы. А общие пользовательские сети для оценки защищенности зачастую достаточно описать в «крупную клетку». Именно поэтому мы рекомендуем начинать с общего описания (филиал такой-то, dmz в ИА, VPN-пул, сеть АРМ КБР). Все остальное по мере возникновения инцидентов попадает в условную зону Unknown, и в момент анализа инцидента заодно уточняется информация.
Какие гарантии производитель дает организации-заказчику? Т.е. если данные утекли мимо DLP программы, то какая компенсация предусмотрена?
Гарантий никто не дает. Информация может пройти мимо DLP, это не секрет. Если Вы узнаете о предстоящем слиянии Uber и Яндекс.Такси и посоветуете друзьям срочно покупать акции «Яндекса», это будет утечка. Но техническими мерами предотвратить такое пока нельзя.
Как вы ловите утечки через DNS/IP туннели, передача информаций с помощью звуковых разъемов и т.д.?
Конкретно Solar Dozor контролирует утечки через каналы, где невозможно снятие копии трафика с помощью скриншотов экрана. В некоторых решениях стоит кейлоггер. Через звуковые разъемы — никак. Некоторые заявляют о контроле голосовых сообщений, но там пока остается вопрос качества распознавания речи.
Как защищают DLP решения от подделки логов, т.е. какая защита от того, что один сотрудник может скомпрометировать другого сотрудника? Какую ответственность несет производитель DLP решения, если такое произошло?
Это технически нереализуемо (по крайней мере, в известных нам DLP-решениях).
А какая риторика юриста компании, если сотрудник скажет, что он этого не делал, его взломали или подставили (например, как минимум системный администратор может это сделать)?
Как минимум, есть данные СКУД, показания коллег и пр. DLP логирует не только факт, но и время инцидента.
То есть в суде экспертам дадут код DLP, они его проанализируют полностью, поймут, как он работал на конкретно заданной машине в конкретно заданный момент времени (т.е. с учетом других запущенных приложений, с учетом обновлений ОС и пр.), а потом смогут четко сказать, что это лог именно программы? Звучит, как фантастика, с технической точки зрения.
Нет, код, разумеется, никто не даст, он и не нужен. Речь не логах работы самого решения, а о логировании действий пользователей. Эти логи хранятся в системе, и они не зависят от окружения.
Сотрудники должны знать (т.е. опять-таки расписаться в ознакомлении), что исполнение этих правил, как и использование корпоративных средств обработки информации, контролируется с использованием средств мониторинга.
Цели детально описать введение режима КТ не было, статья более общей направленности. Проблема с юридическим сопровождением DLP не в том, что люди не знают, как оформить КТ, а в том, что многие до сих пор не знают, что что-то вообще надо оформлять, что надо прописать в регламентах, о чем уведомить сотрудников и т.д.
нет явных оснований считать, что действия совершены конкретно обвиняемым
Да, это справедливое замечание, логируются, строго говоря, действия не человека, а учетной записи. Для этого и составляются различные регламенты по процедурам и политикам ИБ. Человек должен расписаться, что он обязуется никому не передавать свой пароль от учетной записи, что он несет ответственность за действия, осуществляемые из-под его аккаунта и т.д.
Если возникает вопрос о подлинности логов системы, суд опирается на заключение экспертов. Изымаются серверы, производится анализ, и эксперты говорят, логи это из DLP или чье-то творчество в условном ворде.
Все изменения структуры таблиц мы “запихнули” в скрипты. Да, исторические данные при подключении конвертируются автоматически. Там возникают ошибки, верно, мы отлаживали эту систему 5-7 лет в общей сложности. Изменения были разные, простые и сложные. Упор был именно на то, что обычный администратор (не DBA!) при нашей поддержке, не обладая знаниями и умениями (ну, или обладая начальными), сможет проводить работу по управлению секциями. Мы очень часто, особенно на раннем этапе, входили в организации, где не было Oracle, и должны были работать в таких условиях.
Часть скриптов обеспечивает трансформацию данных из старых форматов (не только перестроение структуры таблиц, но и их логическое наполнение ), и еще часть пытается обеспечить надежное выполнение этих действий в отсутствие ораклового специалиста. Понятно, что эта цель выглядит крайне амбициозной, но система доказала свою жизнеспособность и работает. На поддержке у нас есть проблемы, связанные с отключением/подключением секций, но, как правило, они связаны со внешними причинами технического характера.
Но мы готовы отвечать на вопросы, если вам интересно, как реализованы какие-то конкретные вещи. Кусками можем проиллюстрировать.
При открытии в новой вкладке картинка, вроде бы, грузится в полном размере.
Образы были сделаны с помощью специализированного АПК, сами жесткие диски модификации не подвергались. При исследовании образов мы преследовали не криминалистические, а скорее технические цели. Для полноценного криминалистического исследования заказчик самостоятельно должен отдать жесткие диски на экспертизу в некоммерческую организацию. Но наше заключение хоть и не является экспертизой, вполне сойдет за косвенное доказательство как исследование. Практика чаще всего такова, что если заказчик изначально хочет идти в правоохранительные органы, он привлекает соответствующие организации, которые имеют право проводить соответствующую экспертизу.
К сожалению, в силу давности событий нам не удалось установить, как произошла компрометация.
Почти наверняка Вы правы. Скорее всего, произошла компрометация обычной пользовательской машины, потом mimikatz, получение новых учеток, а дальше уже и доменный администратор.
Что касается поиска внешних злоумышленников, то информацию по всем индикаторам, внешним адресам, участвующим в атаке, снятые образы хостов и значимые исходные логи мы передали заказчику для дальнейшего разбирательства с правоохранителями. Финал истории нам, увы, неизвестен.
К сожалению, здесь вопрос не про деньги. Первый подход с точки зрения расходов ИБ стоит дешево, но целиком сказывается на динамике и мобильности самого бизнеса, которую «в лоб» деньгами не измерить. И чаще всего именно из-за этого и редко применяется в принципе и практически отсутствует в коммерческом секторе.
К тому же, все-таки компании, понимающие, что им нужен SOC, обычно уже обзавелись, как минимум, антивирусом. Поэтому если мы подразумеваем, что у заказчика есть базовые системы защиты, дальше многое зависит от специфики его бизнеса.
Сейчас поправим заголовок во избежание :)
Пример:
Конкретно Solar Dozor контролирует утечки через каналы, где невозможно снятие копии трафика с помощью скриншотов экрана. В некоторых решениях стоит кейлоггер. Через звуковые разъемы — никак. Некоторые заявляют о контроле голосовых сообщений, но там пока остается вопрос качества распознавания речи.
Это технически нереализуемо (по крайней мере, в известных нам DLP-решениях).
Как минимум, есть данные СКУД, показания коллег и пр. DLP логирует не только факт, но и время инцидента.
Нет, код, разумеется, никто не даст, он и не нужен. Речь не логах работы самого решения, а о логировании действий пользователей. Эти логи хранятся в системе, и они не зависят от окружения.
Цели детально описать введение режима КТ не было, статья более общей направленности. Проблема с юридическим сопровождением DLP не в том, что люди не знают, как оформить КТ, а в том, что многие до сих пор не знают, что что-то вообще надо оформлять, что надо прописать в регламентах, о чем уведомить сотрудников и т.д.
Да, это справедливое замечание, логируются, строго говоря, действия не человека, а учетной записи. Для этого и составляются различные регламенты по процедурам и политикам ИБ. Человек должен расписаться, что он обязуется никому не передавать свой пароль от учетной записи, что он несет ответственность за действия, осуществляемые из-под его аккаунта и т.д.