Сейчас уже существует временная форма карточки инцидента, разработанная 8-м Центром ФСБ и представленная в формате XML. Это очень важный шаг в стандартизации обмена информацией об инцидентах, которые будут передаваться в ГосСОПКУ. Эту же карточку с высокой вероятностью будет использовать и ФинЦЕРТ при своем взаимодействии с финансовыми организациями, которые обязаны сообщать об инцидентах в своей инфраструктуре. Пока рано говорить о том, насколько предложенный формат карточки инцидента совпадает с признанным во всем мире стандартом STIX, о котором я уже писал 4 года назад. Меня гораздо больше интересует другой вопрос. Разработан ли протокол обмена такими карточками инцидентов и каков формат данных об индикаторах компрометации, которые НКЦКИ должен будет рассылать по своим подопечным. В методических рекомендациях по созданию корпоративных и ведомственных центров ГосСОПКИ тема взаимодействия описана очень скупо. Более того, слово «индивидуально» меня смущает — оно так напоминает классическое «в частном порядке», которое очень любят представители 8-го Центра, которым задают вопросы по криптографии.
Как может выглядеть взаимодействие с ГосСОПКОЙ? Я бы выделил несколько вариантов передачи данных по инцидентам:
- Старая добрая электронная почта, по которой будут отправляться карточки инцидентов на заранее определенный ящик (так делается сейчас в рамках взаимодействия с ФинЦЕРТ). Если не рассматривать вариант, что этот канал слабо защищен и может потребоваться внедрение средств обеспечения целостности и конфиденциальности (разумеется, на ГОСТе и сертифицированных), то возникает сложность с автоматизацией процесса разбора таких сообщений e-mail на стороне ГосСОПКИ. Конечно, это не наша проблема, но мы же сейчас рассуждаем о всей схеме.
- Система личных кабинетов, которую планируют к концу следующего года внедрить в ФинЦЕРТе и вроде такие же слухи ходят и про ГосСОПКУ. Иными словами участник информационного обмена должен будет самостоятельно заливать карточки об инцидентах в личный кабинет, а оттуда она уже попадет в системы аналитики. Тут тоже возникает вопрос с автоматизацией данного действа — будет ли какой-то API для залива (с токенизацией, конечно, для защиты от подмены) или все надо будет делать вручную?
- API для взаимодействия по специальному протоколу (например, TAXI), который позволит унифицировать процедуру и автоматизировать ее. На мой взгляд, это был бы идеальный вариант, учитывая известность TAXI и его поддержку многими производителями средств защиты и мониторинга (те же SIEM).
Я надеюсь, что к 1-му января 2018-го года уже наступит ясность (а может ее внесут уже на SOC Forum, где по ГосСОПКЕ будет отдельная секция с 3-мя докладами представителей ФСБ) по вопросу взаимодействия с ГосСОПКОЙ, так как в противном случае возможны самые нехорошие последствия. Например, дополнительные затраты (в том числе бюджетные) на приобретение решений, которые только и поддерживают протокол, разработанный в ФСБ. Сейчас уже ходяит по рынку компания, которая заверяет заказчиков, что она единственная, кто уполномочена ФСБ разрабатывать шлюз взаимодействия с ГосСОПКОЙ и что надо в обязательном порядке приобрести ее шлюз, который будет транслировать данные из имеющихся у заказчиков решений в понимаемый ГосСОПКОЙ формат. А это уже потенциально обвинения в монополии и другией репутационные риски.
А что делать с уже имеющими у многих заказчиков SIEM, которые работают годами и их никто не планирует выбрасывать на свалку и заменять на что-то отечественное (при всем выбранном на импортозамещение курсе)? В идеале им бы выдать описание формата карточки инцидента (это будет сделано) и описание протокола, под который можно написать соответствующий коннектор и подцепить к SIEM или IRP (будь-то QRadar, ArcSight, LogRhytm, Splunk, R-Vision, IBM Resilient и т.п.). Тогда затраты, включая и бюджетные, будут гораздо ниже, чем в случае использования отдельного «православного» шлюза.
С получением данных Threat Intelligence от ГосСОПКИ ситуация и проще и сложнее одновременно. Про то, какой формат будет использовать для передачи индикаторов компрометации пока не говорится. Это может быть OpenIOC, это может быть CybOX, это может быть STIX и т.п. Наверное, это был бы самый правильный вариант, чтобы не плодить промежуточные конверторы из принятых в мире стандартов в нечто, что понимается только ГосСОПКОЙ. И с одной стороны ГосСОПКА не чурается применения международных (читай, американских) стандартов, например, TLP:
и сигнатуры атак описывает на языке стандарта дефакто в области обнаружения атак — Snort:
