Коллеги, по поводу обоснования затрат и донесения до руководства, что это нужно. У вас есть автомобили? А подушка безопасности? Какова вероятность, что попадёте в ДТП? Хотелось бы в этом случае сидеть в автомобиле, где есть полный комплект мер безопасности? Так же и с бизнесом...есть критичная информация, потеря которой может «покалечить» и потребуется много времени и денег на «выздоровление» или вовсе «привести к летальному исходу». Причём это далеко не всегда зависит от атак из вне, хватает «водятлов» и внутри. Поэтому всякий раз, когда руководство противится тратить деньги на защиту - спросите, готовы ли они даже с вероятностью 5-10% лицезреть как их бизнес «покалечится» или «издохнет». А для оценки в помощь: 1. Выявляем КИ и делим её на 2 типа («покалечит» и «летальный исход») 2. Берём у фин.дира или даже у самого собственника инфу о хотябы примерной стоимости бизнеса (точную цифру вам вряд ли кто даст). 3. Считаем в % вероятность наступления «неблагоприятных ситуаций» (утечка, атака и т.д.) 4. Считаем сумму этого % от стоимости бизнеса. Если сумма потерь больше суммы затрат на защиту - вменяемый Руководитель примет предложение по ЗИ.
P.S. Это так... «на коленке» сварганил, к этому расчету можно подойти более тщательно, чтобы нокаутировать аргументами и цифрами руководство и финансистов, яро урезающих всевозможные расходы на то, чего не понимают.

Всем хороших выходных!)))

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

А не осталось ссылок на эти доклады?

Согласен. Но в нашей деревне (Омск) эта осязаемость пока только на бумаге. Мне вон вчера пятикурсник пришел на пересдачу и утверждал что TCP сессия инициируется с ACK пакета, метод SYN сканирования бесшумный, а при передаче копии трафика через SPAN СОВ будет что-то назад отвечать роутеру )

И отвечать RST может, в зависимости от реализации, со стороны как management интерфейса, так и со SPAN. Если последнее - нужно на span dst port сетевого девайса указать ingress и номер vlan, подготовленный для этого.

@pozdnyakolga не подскажите?

Кстати, СОВ в такой реализации может отвечать сети. Либо отправкой TCP RST участникам подозрительной сессии друг от друга (благо, интерсептит), либо тем, что зайдет на firewall и сделает shun (по крайней мере, циска так умеет). В первом случае надо принимающую заспуфленный ответ подсеть освободить от таких настроек совести, как urpf check.

Она может интерсептить при условии установки в разрыв. При этом в большинстве случаев будет использоваться либо TAP либо встраивание на уровне L2. Во втором варианте это технически возможно, но это выглядит больше как сетевой костыль. Тем более я ни в одной другой СОВ такого не встречал. Те же palo alto и fortigate в таких условиях предлагаю ставить в l2.

Я неправильно выразился. В описанной мной реализации оно не интерсептит, а владеет всей информацией о сессии, и имеет все шансы отправить RST от имени участников друг другу.

Это не в каждой архитектуре сработает.

Даже статью нашел почти десятилетней давности: http://aodugin.blogspot.com/2016/02/idsips-1.html

Меня тут всегда беспокоит схема лицензирования таких решений. Если забирать SPAN с коммутатора ядра внутри живой сети 500-1000 человек, это же 5—7 Gbit. С учётом балансировки утилизации подключаемых интерфейсов, их(интерфейсов) должно быть не меньше 8-9. Что за монстр это и сколько он стоит?)