Comments 3
Зоны ответственности инженера и аналитика могут пересекаться
Скажу больше, люди должны хотя бы в общих чертах знать, что делает их коллега. Например, создание снимков экранов по событию (запуск программы, посещение сайта и т.п.). В первую очередь знать о таком функционале должен аналитик (как он что-либо найдёт, если снимки экрана бубут делаться "тупо" по расписанию раз в 5 минут). Но так как это функционал для агента на конечной точке, то он прилетит в конфиге. А конфиги настраивают инженеры.
Полностью согласен. Даже лучше, когда аналитик не связан с ИТ, а скорее человек из бизнеса, с полей. Из инженера кстати будет тяжело сделать хорошего аналитика, т.к. это просто разные интересы и род деятельности.
Добавлю, что инженер в системе еще может выполнять сложные настройки, требующей ИТ-навыков, например написание регулярок, тюнинг логики сложных правил.
Попробую с вами не согласиться: что если бы вы давали инженеру сразу готовый чеклист с 30ю вопросами, на которые нужно ответить при выявлении сомнительной передачи конфы. Вот и все и даже BPNM диаграмму можно дать. Тогда простой инженер будет тупо по ним идти и сам себе задавать вопросы, что написаны в чек листах. А в конце еще и шаблон заключения, в котором нужно вписать ответы.
К чему я, лично я так и переходил в аналитики с техническим бэкграундом. Только я эти вопросы себе задавал сам, плюс всегда предварительно с кем-то согласовывал документы и у каждого возникали вопросы, которые в последствии вырастали в чек-листы.
Вы клиенту чек листы, базовые методики расследования каждого потенциального способа утечки и шаблоны документов, они вам плюс в карму и рекомендации другим клиентам. Так же лучше?
Ну вот нет у компании денег на еще одного спеце, а если и есть, то не выбить их. Проще обучить, да и в маленьких компаниях куда там бесконечно внедрять агенты и поддерживать их работоспособность.
Аналитик вам не инженер. Почему инженера недостаточно для работы с DLP-системой