И снова всем привет. Цикл «SOC for …» продолжает свое движение и развитие. Первый слой внутренней кухни центров мониторинга и реагирования на инциденты мы уже успели осветить в предыдущих статьях, поэтому попробуем понемногу пойти вглубь, к техническим подробностям и более тонким проблемам.
Мы уже несколько раз косвенно касались темы управления активами: и в статье про контроль защищенности, и в вопросах автоматизации и искусственного интеллекта в SOC. Очевидно, что без инвентаризации инфраструктуры заказчика центр мониторинга не сможет его защищать. При этом составить ее детальное описание отнюдь не тривиальная задача. И главное — через пару месяцев оно снова не актуально: одни хосты исчезли, другие появились, возникли новые сервисы или системы. Но защита инфраструктуры — процесс непрерывный, и SOC не может притормозить свою деятельность до получения актуальной информации об активах заказчика. Напомню, качество работы Solar JSOC регулируется не абстрактными обещаниями, а вполне конкретным SLA, за нарушением которого следуют различные небесные кары. Как выкрутиться в такой ситуации и не потерять в качестве оказываемого сервиса?
Мы уже несколько раз косвенно касались темы управления активами: и в статье про контроль защищенности, и в вопросах автоматизации и искусственного интеллекта в SOC. Очевидно, что без инвентаризации инфраструктуры заказчика центр мониторинга не сможет его защищать. При этом составить ее детальное описание отнюдь не тривиальная задача. И главное — через пару месяцев оно снова не актуально: одни хосты исчезли, другие появились, возникли новые сервисы или системы. Но защита инфраструктуры — процесс непрерывный, и SOC не может притормозить свою деятельность до получения актуальной информации об активах заказчика. Напомню, качество работы Solar JSOC регулируется не абстрактными обещаниями, а вполне конкретным SLA, за нарушением которого следуют различные небесные кары. Как выкрутиться в такой ситуации и не потерять в качестве оказываемого сервиса?
