А какая риторика юриста компании, если сотрудник скажет, что он этого не делал, его взломали или подставили (например, как минимум системный администратор может это сделать)?
Как минимум, есть данные СКУД, показания коллег и пр. DLP логирует не только факт, но и время инцидента.
То есть в суде экспертам дадут код DLP, они его проанализируют полностью, поймут, как он работал на конкретно заданной машине в конкретно заданный момент времени (т.е. с учетом других запущенных приложений, с учетом обновлений ОС и пр.), а потом смогут четко сказать, что это лог именно программы? Звучит, как фантастика, с технической точки зрения.
Нет, код, разумеется, никто не даст, он и не нужен. Речь не логах работы самого решения, а о логировании действий пользователей. Эти логи хранятся в системе, и они не зависят от окружения.
Сотрудники должны знать (т.е. опять-таки расписаться в ознакомлении), что исполнение этих правил, как и использование корпоративных средств обработки информации, контролируется с использованием средств мониторинга.
Цели детально описать введение режима КТ не было, статья более общей направленности. Проблема с юридическим сопровождением DLP не в том, что люди не знают, как оформить КТ, а в том, что многие до сих пор не знают, что что-то вообще надо оформлять, что надо прописать в регламентах, о чем уведомить сотрудников и т.д.
нет явных оснований считать, что действия совершены конкретно обвиняемым
Да, это справедливое замечание, логируются, строго говоря, действия не человека, а учетной записи. Для этого и составляются различные регламенты по процедурам и политикам ИБ. Человек должен расписаться, что он обязуется никому не передавать свой пароль от учетной записи, что он несет ответственность за действия, осуществляемые из-под его аккаунта и т.д.
Если возникает вопрос о подлинности логов системы, суд опирается на заключение экспертов. Изымаются серверы, производится анализ, и эксперты говорят, логи это из DLP или чье-то творчество в условном ворде.
Давайте я кратко опишу самых ярких и заинтересовавших нас производителей (в основном смотрели тех, которые в России не представлены, т.к. наш рынок знаем хорошо):
Bulletproof — забавные ребята, SOC 24x7, MDR. Очень схожи с нашим Solar JSOC по перечню сервисов и позиционированию.
eSentire — очень крутой MDR, одними из первых попали в отчеты Gartner по этой теме. Прямо лидер-лидер, стоит к ним присматриваться.
Cyberbit — предлагают интересные решения по автоматизации работы SOC.
SolarWindsMSP предлагают услуги для MSSP (автоматизация деятельности), стоит присмотреться к продукту MSP Remote Monitoring & Management (платформа).
CrowdStrike — один из лидеров темы threat intelligence.
Securonix и Exabeam — признанные лидеры в теме UEBA. Оба предлагают платформу, на которую можно заводить информацию из разных источников, собирающих события пользователей (U) и «ИТ-сущностей» (e).
RedOwl — предлагают интересное решение по защите от инсайдеров. По сути, тоже единая платформа с серьезной аналитикой.
Teramind — забавное endpoint-решение для защиты от инсайдеров, понравилось своим веб-интерфейсом и описанными кейсами.
Digital Guardian, GTB Technologies, Forcepoint — «классические» DLP решения, практически не представленные в России. При этом считаются одними из лучших по MQ Gartner. Хороши по технологиям перехвата, но сильно уступают по аналитике UBA-решениям, и, кстати, российским DLP.
CoSoSys — нишевое DLP, построенное на сильном endpoint.
InteliSecure — консультанты, «на флаг» подняли DLP-консалтинг, и вроде как на этом специализируются.
Я как раз хотел дать общий обзор тенденций, но готов отвечать на вопросы. Например, если говорить о вендорах, то в MDR это Bulletproof, eSentire и Redscan.
С вендорами DLP вопрос сложнее. На Infosec было четкое разделение на DLP-решения и на продукты, защищающие от внутренних угроз (Insider Threat). Первые — это больше про противодействие утечкам и соответствие законодательству. А вот вторые — это и есть те решения, где внедрены технологии UBA и прочие прогрессивные аналитические инструменты.
Резюмируя. На фирме с централизованным сетевым управлением должна быть команда антикризисных админов, способных самостоятельно принять решение о блокировке служб удаленными политиками. Что то у меня в этом есть сомнения. Потому что это решение гарантировано прервет рабочий процес. Где файловые ресурсы станут недоступными, где лисенеры сдохнут. А отвечать за это кому то… И объяснять… недалекому начальству сложные вещи про порты и уязвимости.
В идеале безопасник в конторе должен обладать полномочиями, в том числе, останавливать бизнес-процессы для минимизации последствий атак. Соответственно стандартные действия выполняются админами штатно, а остальные согласуются с безопасником, у которого картбланш от руководства, так как последствия понятны и риск высок.
Agile не говорит, что документировать не надо. Он говорит о том, что выбор между работающим продуктом и написанной документацией должен быть сделан в пользу работающего продукта. Другими словами, если ресурс ограничен, а нужно или сделать документ, или доделать фичу, то выбор должен быть сделан в пользу фичи.
Еще раз: нет декларации того, что документация не нужна. Документирование – крайне важная часть процесса разработки. Но ресурсы ограничены, а значит, документирование можно перенести на следующий спринт, например.
Также важно помнить, что Agile хорош для решения коротких задач за ограниченное время. Когда мы говорим про принятие в эксплуатацию и на поддержку, например, ПАКа, Agile тут будет слабо применим.
А скрам – это методика работы в рамках принципов Agile. Если Вы приведете примеры применения спринтов не в рамках Agile, будет очень интересно о них почитать =)
Так бывает чаще, чем может показаться. Причем иногда это даже не злонамеренная утечка — просто человек хочет поработать из дома и скидывает себе необходимые документы. И как раз в таких случаях тело письма отсутствует.
Сложно сказать, почему сначала подумали на внутренний сговор, а не на вирус. Возможно, профдеформация — на DLP-проектах люди «заточены» на выявление утечек и различного толка мошенничеств. К тому же, в рамках большой организации 20 человек — это не так много, как может показаться.
Это потому, что статья изначально писалась отдельно, не ради последнего абзаца, а потом в пиаре подумали, что можно же и про триал дописать :). В свое оправдание скажу, что мои мотивы чисты: просто подумалось, что это и правда может быть кому-то полезно.
Да, это все он)
Сейчас никто не может сказать наверняка, сбудутся ли все эти прогнозы (и сбудутся ли они в указанные сроки). В оценке B2C-трендов Gartner и правда пока не очень справляется, но корпоративный сегмент (да еще в такой сфере, как ИБ) гораздо менее менее динамичен, так что и прогнозы аналитиков обычно более адекватные. Скажем, в отношении тех же SOC'ов.
Как минимум, есть данные СКУД, показания коллег и пр. DLP логирует не только факт, но и время инцидента.
Нет, код, разумеется, никто не даст, он и не нужен. Речь не логах работы самого решения, а о логировании действий пользователей. Эти логи хранятся в системе, и они не зависят от окружения.
Цели детально описать введение режима КТ не было, статья более общей направленности. Проблема с юридическим сопровождением DLP не в том, что люди не знают, как оформить КТ, а в том, что многие до сих пор не знают, что что-то вообще надо оформлять, что надо прописать в регламентах, о чем уведомить сотрудников и т.д.
Да, это справедливое замечание, логируются, строго говоря, действия не человека, а учетной записи. Для этого и составляются различные регламенты по процедурам и политикам ИБ. Человек должен расписаться, что он обязуется никому не передавать свой пароль от учетной записи, что он несет ответственность за действия, осуществляемые из-под его аккаунта и т.д.
Ну, вот, хотя бы как-то так…
С вендорами DLP вопрос сложнее. На Infosec было четкое разделение на DLP-решения и на продукты, защищающие от внутренних угроз (Insider Threat). Первые — это больше про противодействие утечкам и соответствие законодательству. А вот вторые — это и есть те решения, где внедрены технологии UBA и прочие прогрессивные аналитические инструменты.
В идеале безопасник в конторе должен обладать полномочиями, в том числе, останавливать бизнес-процессы для минимизации последствий атак. Соответственно стандартные действия выполняются админами штатно, а остальные согласуются с безопасником, у которого картбланш от руководства, так как последствия понятны и риск высок.
agile безопасность — 176
блокчейн – 174
Пора ли вводить мораторий на публикации про блокчейн?
Еще раз: нет декларации того, что документация не нужна. Документирование – крайне важная часть процесса разработки. Но ресурсы ограничены, а значит, документирование можно перенести на следующий спринт, например.
Также важно помнить, что Agile хорош для решения коротких задач за ограниченное время. Когда мы говорим про принятие в эксплуатацию и на поддержку, например, ПАКа, Agile тут будет слабо применим.
Сложно сказать, почему сначала подумали на внутренний сговор, а не на вирус. Возможно, профдеформация — на DLP-проектах люди «заточены» на выявление утечек и различного толка мошенничеств. К тому же, в рамках большой организации 20 человек — это не так много, как может показаться.
Спасибо)
Сейчас никто не может сказать наверняка, сбудутся ли все эти прогнозы (и сбудутся ли они в указанные сроки). В оценке B2C-трендов Gartner и правда пока не очень справляется, но корпоративный сегмент (да еще в такой сфере, как ИБ) гораздо менее менее динамичен, так что и прогнозы аналитиков обычно более адекватные. Скажем, в отношении тех же SOC'ов.
Прогнозы собраны из разных материалов Gartner, какой раздел Вам интересен?