Архив метки: Monreal

На PHDays в этом году я рассказывал о мониторинге стабильности ИТ/ИБ вендоров и рекомендательном алгоритме НКЦКИ

На PHDays в этом году я рассказывал о мониторинге стабильности ИТ/ИБ вендоров и рекомендательном алгоритме НКЦКИНа PHDays в этом году я рассказывал о мониторинге стабильности ИТ/ИБ вендоров и рекомендательном алгоритме НКЦКИ

На PHDays в этом году я рассказывал о мониторинге стабильности ИТ/ИБ вендоров и рекомендательном алгоритме НКЦКИ. На этой неделе тоже буду выступать на по ИБ мероприятии со схожей темой, но постараюсь расширить и углубить. По случаю сделал на github-е проект Monreal и немного покодякал там. Monreal потому что МОНиторинг стабильности вендоров и РЕкомендательный АЛгоритм НКЦКИ. 😉

Первый скриптик позволяет по заполненному опроснику (вероятность внешнего санкционного события, вероятности реакции на события, веса опасности реакций) оценить стабильность ИТ вендора

Первый скриптик позволяет по заполненному опроснику (вероятность внешнего санкционного события, вероятности реакции на события, веса опасности реакций) оценить стабильность ИТ вендораПервый скриптик позволяет по заполненному опроснику (вероятность внешнего санкционного события, вероятности реакции на события, веса опасности реакций) оценить стабильность ИТ вендораПервый скриптик позволяет по заполненному опроснику (вероятность внешнего санкционного события, вероятности реакции на события, веса опасности реакций) оценить стабильность ИТ вендора

Первый скриптик позволяет по заполненному опроснику (вероятность внешнего санкционного события, вероятности реакции на события, веса опасности реакций) оценить стабильность ИТ вендора. Для примера сделал заполнения для нескольких кейсов:

1. Локальный российский вендор, у которого все бизнес-интересы и активы в стране и на которой не повоздействуешь
2. Западный вендор, который старается санкции обойти, перевести дела в подходящую штаб-квартиру, заблочить только какую-то дополнительную незначимую функциональность для вида, но в случае формальных требований конечно закрутит гайки по полной
4. Западный вендор, который при появлнеии первых формальных требований блочит все по полной и рвет все связи
5. Западный вендор, который мало того, что все поблочит. так ещё и ваши данные передаст куда надо с понятно какими целями

В общем, фреймворк конечно крайне примитивный, но как POC сойдет. 🙂

Второй скриптик это реализация рекомендательного алгоритма НКЦКИ

Второй скриптик это реализация рекомендательного алгоритма НКЦКИВторой скриптик это реализация рекомендательного алгоритма НКЦКИВторой скриптик это реализация рекомендательного алгоритма НКЦКИ

Второй скриптик это реализация рекомендательного алгоритма НКЦКИ. Сразу наглядно видно какие параметры нужны для принятия решение. Подаешь заполненный дикт на вход, получаешь вердикт стоит обновлять или не стоит, нужно ли повторять проверку через какое-то время или нет, а также шаг алгоритма на котором было принято итоговое решение (для отладки). Можно менять параметры и смотреть как результат меняется. На слайдах я меняю CVSS Base Score c 9 на 6, патчить все ещё надо, т.к. отказ сервиса влияет на бизнес, а СЗИ-шек для митигации не внедрено. Меняю параметр, что у нас есть СЗИ блокирующие эксплуатацию уязвимости и получаю ответ, что патчить не требуется.

Это в первую очередь мне нужно для демонстрации того какие теперь требуются дополнительные входные данные для VM процесса. Но в принципе можно и в реальных системах использовать.