Продолжу-ка я тему, начатую позавчера, и разверну вопрос, упомянутый вскользь, — облачная аналитика Threat Intelligence. Я упомянул, что новые сертификационные требования ФСТЭК по требованиям безопасности фактически делают невозможным оперативное получение данных об угрозах из облаков. Причина такого решения ФСТЭК мне понятна — они опасаются нанесения ущерба защищаемым объектам из таких облаков. Рисков два — утечка информации из защищаемой сети в облако и получение из него вместо обновлений вредоносного кода.
Что можно сделать в такой ситуации? Как, например, можно обновлять антивирус или систему обнаружения атак, требующие регулярного получения сигнатур? Флешка — самый простой вариант, который нередко используется сертифицированного решениями. Или создается нечто вроде прокси-шлюза, который отвечает за обновление всех средств защиты внутри защищаемого объекта, а сам он обновляется с помощью той же флешки или через однонаправленный канал. Например, именно такой вариант используют те же решения «Лаборатории Касперского», которые применяют не обычную KSN, а ее приватную версию — KPSN (Kaspersky Private Security Network). Кстати, и при сертификации «Касперского» подавалась именно KPSN, а не KSN. Схожая схема используется в тех же решениях Cisco, которые могут обмениваться данными с облачной песочницей Threat Grid, а могут с локальной, работающей даже в режиме «air-gap». EDR-решение Cisco AMP имеет как управление из публичного облака, так и из частного. Но вариант с флешкой или локальным сервером обновления (или той же «песочницей») работает только в случае, когда источник обновления всего один — от самого вендора средства защиты.
Но сегодня нельзя доверять одному вендору. И дело не в том, что он может прекратить свое существование или неоперативно обновлять свои средства защиты. Он не может «видеть» и знать все и обо всем. Например, он может хорошо разбираться в угрозах для финансовых организаций, но не иметь представления о промышленных атаках. Или он может прекрасно разбираться в атаках, присущих для европейского региона, но не «видеть» азиатских или американских операций хакеров. В любом случае потребитель хочет иметь возможность резервировать источники получения информации об угрозах. Поэтому сегодня многие современные защитные решения поддерживают функцию работы с различными TI-сервисами по стандартизованным протоколам — STIX/TAXI, OpenIOC, CyBOX и т.п. В этом случае вы можете существенно повысить эффективность купленных решений.
Но не в том случае, если вы хотите использовать сертифицированное ФСТЭК решение, так как было показано выше облачная аналитика угроз де-факто недопустима регулятором. Вы еще можете заменить флешкой один источник данных TI. Ну два; ну три. Но десятки или даже сотни уже нет. И вы встаете перед выбором — иметь сертификат и отказаться от оперативного обновления средства защиты данными о новых появляющихся атаках (оперативно — это один раз в 3-5 минут, а не один раз в день) или нарушить сертификат, повысив защищенность своей компании и подключив множество внешних TI-источников напрямую. Правда, последний вариант у меня вызывает вопросы, так как и сертифицировать решение с поддержкой таких подключений в ФСТЭК нельзя. Третий вариант я озвучил позавчера — забить на сертификацию и начать дышать полной грудью, выбирая то, что нужно, а не то, что есть в реестре сертифицированных решений (рабочий вариант, если вы не госорган).
ЗЫ. Да, стоит отметить, что описанные проблемы касаются только тех решений (а они преимущественно не отечественные), которые умеют работать не только со своими источниками обновления, но и с независимыми внешними источниками. Если же у решения только один канал получения сигнатур, данных по уязвимостям, индикаторов компрометации, то достаточно, чтобы производитель смог подтвердить доверенность канала обновления (хотя это отдельная тема — доверие к каналу и источнику обновления) или возможность получения обновлений на флешке или через локальный сервер.
ЗЗЫ. Отдельный вопрос — как проверить облачную площадку на соответствие новым требованиям к доверию? Ведь такое облако является частью сертифицируемого решения и его тоже надо «подавать» на оценку соответствия. И что-то я пока не вижу, как можно новую методику ФСТЭК по поиску НДВ и уязвимостей применить к облачной платформе, неотчуждаемой от вендора (и уж тем более расположенной за пределами РФ)?
Проблема, скорее, надуманная. Обязательность сертификации установлена только для ГТ и ГИС, в остальных случаях обладатель сам выбирает себе решения по защите. Если уж есть такая острая необходимость обновлять данные об атаках каждые 3 минуты — это можно устроить. Другой вопрос, насколько можно доверять столь поспешно рассылаемой информации и успеет ли хозяин ресурса справиться с потоком таких "обновлений". Станет ли система, которую каждые 3 минуты пугают очередной опасностью, более безопасной?
Ну я изначально писал, что коммерческим компаниям надо забить на сертификацию и жить нормальной жизнью. Но есть то есть, кто все еще считает, что сертификация дает им больше гарантий.
Мы в Cisco в год детектим 7 триллионов угроз; новых получается несколько в секунду. Поэтому да, обновление каждые 3 минуты — это необходимость. Например, фишинговых доменов в квартал появляется около 400 тысяч, то есть 3 домена в минуту. Так что это не такая уж и надуманная проблема даже для госов, не говоря уже о коммерсах