Сотрудники должны знать (т.е. опять-таки расписаться в ознакомлении), что исполнение этих правил, как и использование корпоративных средств обработки информации, контролируется с использованием средств мониторинга.
Цели детально описать введение режима КТ не было, статья более общей направленности. Проблема с юридическим сопровождением 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 вопрос сложнее. На Infosec было четкое разделение на DLP-решения и на продукты, защищающие от внутренних угроз (Insider Threat). Первые — это больше про противодействие утечкам и соответствие законодательству. А вот вторые — это и есть те решения, где внедрены технологии UBA и прочие прогрессивные аналитические инструменты.
В идеале безопасник в конторе должен обладать полномочиями, в том числе, останавливать бизнес-процессы для минимизации последствий атак. Соответственно стандартные действия выполняются админами штатно, а остальные согласуются с безопасником, у которого картбланш от руководства, так как последствия понятны и риск высок.
agile безопасность — 176
блокчейн – 174
Пора ли вводить мораторий на публикации про блокчейн?
Еще раз: нет декларации того, что документация не нужна. Документирование – крайне важная часть процесса разработки. Но ресурсы ограничены, а значит, документирование можно перенести на следующий спринт, например.
Также важно помнить, что Agile хорош для решения коротких задач за ограниченное время. Когда мы говорим про принятие в эксплуатацию и на поддержку, например, ПАКа, Agile тут будет слабо применим.
Сложно сказать, почему сначала подумали на внутренний сговор, а не на вирус. Возможно, профдеформация — на DLP-проектах люди «заточены» на выявление утечек и различного толка мошенничеств. К тому же, в рамках большой организации 20 человек — это не так много, как может показаться.
Спасибо)
Сейчас никто не может сказать наверняка, сбудутся ли все эти прогнозы (и сбудутся ли они в указанные сроки). В оценке B2C-трендов Gartner и правда пока не очень справляется, но корпоративный сегмент (да еще в такой сфере, как ИБ) гораздо менее менее динамичен, так что и прогнозы аналитиков обычно более адекватные. Скажем, в отношении тех же SOC'ов.
Прогнозы собраны из разных материалов Gartner, какой раздел Вам интересен?
Конечно, имелась в виду проверка с целью выявления индикаторов компрометации различных вредоносов, а не различными вредоносами).