Вышла версия v4.0-beta системы защиты информации от инсайдеров SecrecyKeeper. - Форум по вопросам информационной безопасности

Где ж вас таких учат? :)

> загрузку со съемных носителей запретить

Обязательно

> выполнение (в броузере) ActiveX запретить

Допустим

> VB редактор удалить

Какой именно: ворд, эксель, ноутпад?

> макросы в офисе отключить

Забудьте про эту фичу. Самописные скрипты для автоматизации работы пользователей в Офисе используются почти повсеместно. И ваше (как и мое) мнение по этому поводу ничего не значит.

> список программ которые он может запустить ограничить

Спасибо, посмеялся :) Вы хотя бы приблизительно представляете список таких экзешников? А процесс его изменения при установке пользователю софта? В сети на тысячу пользователей при пяти сотрудниках хелпдеска?

> Что еще не учел ?

Того, что речь идет не о скромной компашке на 100 компов, а о крупной организации, сотрудники которой должны работать бесперебойно.

>Где ж вас таких учат? :)
в семье и школе, где же еще ?:)

>> VB редактор удалить
>Какой именно: ворд, эксель, ноутпад?
вы правы, можно не удалять, достаточно запретить выполнение скриптов

>Самописные скрипты для автоматизации работы пользователей
>в Офисе используются почти повсеместно.
скрипты можно подписать и разрешить выполнение только подписанных.

>Вы хотя бы приблизительно представляете список таких экзешников?
я представляю список экзешников, которые надо разрешить, не такой уж и большой

>А процесс его изменения при установке пользователю софта?
>В сети на тысячу пользователей при пяти сотрудниках хелпдеска?
я внедрял srp и на бОльших сетках. особых проблем не было. а количество разных наборов софта определяется не количеством сотрудников, а количеством отделов (строго меньше). причем они пересекаются. и новый софт пользователям не каждый день ставят.

>отрудники которой должны работать бесперебойно
вот когда у всех все стандартно, то и будет бесперебойная работа и устранение проблем легкое и быстрое. пятью сотрудниками.

> скрипты можно подписать и разрешить выполнение только подписанных.

В теории - да. Практика несколько иная.

Нормальная ситуация, когда манагеру ставят задачу срочно перелопатить выгрузку по операциям (экселевский файл). Манагер пишет простенький скрипт, который это делает (сейчас этому учат даже в ПТУ). Разрешите ему подписывать скрипт самому - убьете смысл запрета. Будете подписывать сами - увеличится время выполнения задачи, причем виноват будет именно безопасник.

> я внедрял srp и на бОльших сетках. особых проблем
< не было. а количество разных наборов софта определяется не количеством сотрудников,
> а количеством отделов

Между "внедрял" и "использовал" есть большая разница :) Я наблюдал результаты подобных внедрений где-то через год после их окончания. Как известно, любая диета заканчивается словами: "Да ну, на фиг, задолбало!" :)

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

Когда на хелпдеск начинают валиться заявки типа: "У меня не запускается установленный вами ZZZ", начальство дает команду "отключить эту хрень" (c).

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

п. 3.5 Концепции защиты СВТ (Хотя это конечно и общие взгляды, но это все же РД Гостехкомиссии):
Программно-технические средства защиты не должны существенно ухудшать основные функциональные характеристики АС (надежность, быстродействие, возможность изменения конфигурации АС)

2 malotavr
не обязательно прописывать все экзешники.
достаточно просто обеспечить принцип "пользователь не может запускать то, куда может писать"

В смысле запретить запуск из каталога, в который может писать? Или экзешник нельзя запустить, если пользователь может его изменить?

А кстати, в контексте обсуждаемой проблемы (обхода СЗИ штатными возможностями офиса), какой мысл имеет это ограничение?

разрешить запуск только из опред каталога, запретить запись в этот каталог, запретить писать в файлы в этом каталоге.

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

Беспредметный разговор получается...
Изначально рекламировался продукт, потом поднялся вопрос о целесообразности появления его на рынке и применения для борьбы с инсайдерами, а скатились к основам защиты от НСД.
Да я, например, и не буду извращаться с поиском дыр в системе и СЗИ, для копирования информации возьму кнопикс и загружусь с компахи и солью все на флешку. Не удасться загрузиться с компахи, сброшу БИОС, не удасться сбросить Биос (опломбированный системник) - убъю МБР НЖМД, а потом свалю все на глючное железо у тупых админов, да можно дофига еще чего придумать...
Система защиты не должна стоить дороже стоимости утечки, а применение подобных решений действительно напоминает кашу из топора - клиент покупает, внедряет, происходит утечка - а ему разработчик говорит - ну дык вы ведь должны были еще ОРД разработать, электронные замки поставить, создать систему сигнализации вскрытия системных блоков, систему контроля установки стороннего ПО, и бла, бла, бла...

"Вопрос в том, можно ли сделать эти возможности не доступными пользователю, при этом оставляя ему возможность работать"

Да, питон, это вопрос, и именно на этот вопрос вы ответить не можете. Я вам привел пример с офисом. Вы мне начинаете рассказывать про запрет запуска абстрактного софта. Зачем? Давайте закончим с офисом, в котором не получается отключить скрипты, не лишив пользователя возможности работать :)

NoVaN немного сгущает краски, но мысль высказал верную.

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

NoVaN
>Система защиты не должна стоить дороже стоимости утечки,
>а применение подобных решений действительно напоминает кашу из топора
С первой частью насчет стоимости, согласен полностью. А что касается топора, то по моему вы не правы. Система безопасности должна быть комплексной. Ни кто ведь не ставит бронированную дверь на фанерный домик. А защита от кражи инсайдером это не защита от НСД. Доступ уже получен, причем легально. И хотя это не значит, что не надо настраивать окружение, приобретать дополнительные продукты я ни где не рекомендовал. Большую часть необходимых настроек можно сделать штатными средствами ОС.
Кстати, внедрение DLP систем очень часто сопровождается аудитом и даже реорганизацией бизнес процессов и хотя это ни кого не радует, но воспринимается с пониманием.