Pull to refresh
11
0

Пользователь

Send message
Про это мы в паблике бы фокусно писать пока не стали. Думаем об отдельном исследовании :)
Добрый день. Процесс есть, только в непривычном для ИТ формате. В настоящий момент у нас есть четко детерминированный функционал, выполняемый линиями. И есть скоринговый маршрутизатор, отправляющий инцидент на анализ сразу на 1-ю или 2-ю линии, где и происходит полный цикл разбора инцидента и оповещения Заказчика. Так же есть четко описанные ситуации(и все эти ситуации подсвечиваются нашей тикетной системой), когда к дальнейшей работа с инцидентом передается напрямую в 4-ю или 3-ю линию.

Что же касается процесса эскалации с младших на старшие линии по нехватке экспертизы в виде – тикет всегда приходит на первую линию и в случае нехватки компетенций шагает по ступенькам все выше и выше – вы правы – таких процессов у нас нет и мы их сознательно избегаем.
Добрый день. Примеры успешные есть, но к сожалению пока за пределами публичности. Процесс согласования проекта всегда творческий, всегда процесс упрощает предварительная проработка вопроса с вендором АСУ на стендах и тестовых лабораториях.
Добрый день. Да, очень хорошая идея. Есть у нас и такие Заказчики. Попробуем с ними обсудить
Да, тут сложно не заподозрить нас в предвзятости :) Но тезисы и проблемы сложности построения SOC, кажется, уже являются истиной, не требующей доказательств. Тем более что сама статья содержит методы и подходы, которые могут использоваться как при работе коммерческого SOC при подключении клиента, так и внутри компании при собственном запуске центра.
Доброго дня. Есть планы на открытие офиса в Сибири, но вряд ли в Красноярске
И свежие и горячие :) «Зато не скучно» — это про работу, всегда найдется что-то увлекательное.

Зарплата рыночная во всех регионах присутствия. За подробностями напишите на personal@rt-solar.ru
Да, так бывает. Но, к сожалению, не всегда допустимо и не все решения VPN такой подход поддерживают. Хотя с точки зрения внутреннего ИБ он практически оптимален, но пользователи крайне нервничают, когда такой доступ осуществляется с личного устройства: нарушение privacy
Есть немалое количество ограничений по внедрению двухфакторной аутентификации в крупном корпоративном Заказчики. Погружаться в детали в данной статье бы не хотелось.

При предоставлении удаленного доступа как правило внутреннее ИБ пытается минимизировать доступ до минимально требуемого. То есть только самые критичные для работы системы. Происходит это в первую очередь из-за рисков компрометации, например, самой удаленной рабочей станции (если это домашняя машина). Собственно эту проблемы мы описывали в статье. Находясь внутри контура, доступы, как правило, сильно шире.
Да, и именно с попыткой защитить новую «точку опоры» мы и писали эту статью
В целом вы правы. И чаты, и конференции, и ВКС сейчас массово переезжают в облака. Но в больших корпоративных Заказчиках все-таки большой кусок систем находится внутри: CRM, документооборот, системы управления заявок. Поэтому совсем без VPN чаще всего не обойтись.
Да, целиком разделяем позицию и ровно про это и писали

Когда система содержит невысокий уровень хаоса и энтропии, то обучение выглядит вполне понятным и правильным процессом. Например были хорошие кейсы вокруг выявления обфускации через ML/AI обучение. И в вопросах защиты веб-приложений тема выглядит очень перспективно. В более общем случае — расходы на обогащение информацией выглядят более высокими, чем получаемые преимущества, и качество детекта будет страдать.

Information

Rating
Does not participate
Works in
Registered
Activity