Ну продолжим :-) Сразу скажу, что создание собственной системы ИБ-аналитики (хотя бы с точки зрения каркаса для последующего его наполнения данными) - задача нетривиальная. В качестве примера сошлюсь на наш собственный опыт, которым мы поделились в нашем корпоративном блоге:
- Часть 5. Антифишинг из облака
- Часть 4. Автоматическая категоризация и обработка спама с помощью Hadoop
- Часть 3. Визуализация ИБ-аналитики
- Часть 2. Использование Berkeley AMPLab Stack для эффективного применения Hadoop
- Часть 1. Инструменты Big Data, используемые командой Cisco TRAC для ИБ-аналитики
Но это уже из области практики, до которой нам пока далеко - ведь наша первая задача - выстроить инфраструктуру, которая должна опираться на открытые стандарты. Какие это стандарты могут быть? Их на самом деле уже немало разработано:
Есть и еще один проект, который позволяет собирать и обмениваться информацией об угрозах - это Open Threat Exchange. И хотя он построен на OSSIM (open source SIEM), все-таки он зарубежный и учитывая исходные предпосылки врядли подойдет для "нашей" задачи. По состоянию на начало прошлого года через него обменивались информацией свыше 18000 внедрений OSSIM по всему миру. Также он может обмениваться информацией с CIF.
Резюмируя обзор стандартов и framework'ов для создания собственной системы ИБ-аналитики в целях отраслевой CSIRT или национального центра обмена информацией об угрозах (как написано в 31-м указе), могу предположить, что если не создавать систему с нуля, то наиболее предпочтительной выглядит CIF. Во-первых, ее можно докрутить под свои нужды. Во-вторых, она уже прошла апробацию временем и существует опыт ее использования. И, наконец, генерация правил для Snort, на базе которого построено несколько сертифицированных в России отечественных систем обнаружения атак. Учитывая рост их числа, могу предположить, что ФСБ решило реализовывать 31-й указ не на том, что реально работает, а на том, что хоть как-то контролируется (открытый Snort тут как нельзя лучше подходит). Соответственно CIF тут подходит лучше MANTIS. Для отраслевой же CSIRT третий критерий не столь критичен.
- TLP (Traffic Light Protocol) - простой протокол, предложенный US CERT, и позволяющий "раскрасить" информацию в 4 "цвета", от которых зависит кому можно передавать информацию об угрозах - всем, внутри отрасли или сообщества, внутри организации, нельзя передавать никому. Протокол очень просто в реализации и его можно применить даже к обычной электронной почте.
- Протоколы и стандарты рабочей группы MILE (Managed Incident Lightweight Exchange), включающие:
- Стандарт Incident Object Description and Exchange Format (IODEF), описанный в RFC 5070, и содержащий в формате XML свыше 30 классов и подклассов инцидентов, включая такую информацию как контакт, финансовый ущерб, время, пострадавшие операционные системы и приложения и т.д. IODEF - стандарт достаточно проработанный и уже немало где используется. Из организаций его использует Anti-Phishing Working Group, а также многие CERT/CSIRTы. Да и с вендорской поддержкой не так все плохо - SIEM постепенно интегрируют его внутрь себя.
- Стандарт IODEF for Structured Cyber Security Information (IODEF- SCI) является расширением для IODEF, позволяющем добавлять к IODEF дополнительные данные - шаблоны атак, информация о платформах, уязвимостях, инструкциях по нейтрализации, уровень опасности и т.п. Также предлагается включить в состав IODEF-SCI часть стандартов MITRE - CAPEC, CEE, CPE, CVE, CVRF, CVSS, CWE, CWSS, OCIL, OVAL, XCCDF, XDAS (я про них уже писал).
- Протокол Real-time Inter-network Defense (RID) позволяет взаимодействовать различным системам ИБ-аналитики. Построенный на базе HTTP/HTTPS он описан в RFC 6545.
- OpenIOC - это открытый стандарт описания индикаторов компрометации (Indicator of Compromise, IOC), который первоначально был закрытой разработкой компании Mandiant (известна тем, что сделала в январе доклад о массовых атаках объектов в США со стороны Китая), но потом стал открытым. Также построен на базе XML и содержит свыше 500 различных индикаторов, преимущественно узловых (хостовых) - файл, драйвер, диск, процесс, реестр, система, хэш и т.п. Пока OpenIOC - это преимущественно епархия продуктов Mandiant, но постепенно он начинает проникать и в другие компании-разработчики.
- VERIS (Vocabulary for Event Recording and Incident Sharing) - стандарт американской Verizon, ориентированой в отличие от тактического OpenIOC на стратегический взгляд на информацию об угрозах и инцидентах. По сути это некий единый язык для описания и обмена информацией об инцидентах. Схема VERIS состоит из 5 частей - отслеживание инцидента, описание инцидента, демография жертвы, оценка ущерба и реагирование, каждая из которых в свою очередь делится на различные типы данных и переменные.
- Протоколы и стандарты MITRE, включающие:
- Стандарт CybOX (Cyber Observable Expression) предназначен для описания индикаторов наблюдаемых событий безопасности. Сегодня уже представлено свыше 70 различных описываемых объектов - файл, сетевая соединение, HTTP-сессия, сетевой поток (Netflow), сертификат X.509 и т.п.
- Стандарт STIX (Structured Threat Information Expression) позволяет унифицировать описание различных угроз. Про STIX я уже писал.
- Стандарт TAXII (Trusted Automated eXchange of Indicator Information) позволяет унифицировать обмен данными об угрозах. Про TAXII я уже писал. Он уже используется в центре обмена информацией об угроза в финансовой отрасли США (FS-ISAC), некотором аналоге банковского CERT, о котором у нас недавно заговорили.
- Европейские стандарты, включающие:
- Стандарт VEDEF (Vulnerability and Exploit Description and Exchange Format) для обмена информацией об уязвимостях и эксплойтах, разработанный рабочей группой при TERENA.
- Стандарт SecDEF (Security Description and Exchange Format) по обмену различной информацией в области безопасности. Инициирован ENISA, но пока широко не применяется и не опубликован.
- Стандарт CAIF (Common Announcement Interchange Format), предложенный немецким RUS-CERTом для обмена формализованными бюллетенями по безопасности.
- Стандарт DAF (Deutsches Advisory Format / German Advisory Scheme), также предложенный другим немецким CERTом.
На базе данных стандартов и создаются системы ИБ-аналитики. Это можно делать самостоятельно, а можно взять также готовые framework, уже интегрирующие между собой различные компоненты и стандарты, решающие описанные вчера задачи. К таким framework'ам можно отнести:
- CIF (Collective Intelligence Framework), разработанная REN-ISAC (центр обмена информацией об угрозах для американских ВУЗов и исследовательских организаций), поддерживаемая рядом организаций, позволяет собирать и объединять информацию об угрозах из различных источников и использовать ее для идентификации индидентов, обнаружения и нейтрализации угроз. Нейтрализация заключается в генерации правил для Snort, iptables и других средств защиты. CIF преимущественно работает с IP-адресами, доменными именами и URL, связанными с вредоносной активностью. В качестве формата хранения информации использует IODEF.
- The MANTIS (Model-based Analysis of Threat Intelligence Sources) Framework - это новая инициатива, которая объединяет вместе вышеперечисленные стандарты OpenIOC, IODEF, CybOX, STIX, TAXII (последний в процессе разработки). Пока сказать что-то конкретное про эту систему рано - она только-только появилась.
Резюмируя обзор стандартов и framework'ов для создания собственной системы ИБ-аналитики в целях отраслевой CSIRT или национального центра обмена информацией об угрозах (как написано в 31-м указе), могу предположить, что если не создавать систему с нуля, то наиболее предпочтительной выглядит CIF. Во-первых, ее можно докрутить под свои нужды. Во-вторых, она уже прошла апробацию временем и существует опыт ее использования. И, наконец, генерация правил для Snort, на базе которого построено несколько сертифицированных в России отечественных систем обнаружения атак. Учитывая рост их числа, могу предположить, что ФСБ решило реализовывать 31-й указ не на том, что реально работает, а на том, что хоть как-то контролируется (открытый Snort тут как нельзя лучше подходит). Соответственно CIF тут подходит лучше MANTIS. Для отраслевой же CSIRT третий критерий не столь критичен.
0 коммент.:
Отправить комментарий