Система и способ идентификации информационных активов

Изобретение относится к области информационной безопасности в части управления информационными активами. Технический результат заключается в минимизации ложных объединений активов. Способ идентификации активов, в котором сопоставляют набор идентификационных данных входящего актива множеству идентификационных данных всех существующих записей об активах; проверяют множество существующих активов на соответствие входящему активу на основании типа актива и как минимум одного способа проверки идентификационных данных для получения непротиворечивого подмножества активов, идентичных входящему; создают новую запись в базе активов, если количество существующих активов, идентичных входящему, равно нулю; обновляют найденную запись в базе активов, если количество существующих активов, идентичных входящему, равно единице; объединяют найденные записи в базе активов и обновляют объединенную запись в соответствии с входящими данными, если количество существующих активов, идентичных входящему, больше единицы. 51 з.п. ф-лы, 2 ил.

 

Область техники

Изобретение относится к решениям для управления информационными активами в системах управления событиями информационной безопасности, а более конкретно к способам идентификации информационных активов.

Уровень техники

В настоящее время растет разнообразие информационных систем (таких, например, как операционные системы сетевых устройств), технологий и протоколов, используемых для обеспечения информационной безопасности. При этом спектр задач, стоящих перед системами управления событиями информационной безопасности, также весьма широк - к ним относятся агрегация данных из различных источников, корреляция событий и управление инцидентами, аудит конфигурации устройств на предмет соответствия политике безопасности, отслеживание уязвимостей и оценка рисков. Ключевым условием, обеспечивающим эффективное использование совокупности указанных функций в управлении информационной безопасностью, становится поддержание актуальной, точной и непротиворечивой базы информационных активов (далее - «активы») на основе множества разнородных источников, предоставляющих в общем случае неполный и потенциально противоречивый набор данных, идентифицирующих активы. Следует отметить, что в контексте систем управления событиями информационной безопасности под активом понимается совокупность физического или виртуального устройства (такого как сервер, компьютер, сетевое оборудование), подключенного к информационной сети, и установленного на нем программного обеспечения, включая операционную систему.

Актуализация базы данных активов заключается в сопоставлении набора идентифицирующих атрибутов во входящих данных от любого источника (например, событий или сканирования на уязвимости) с существующим состоянием базы активов. При этом компонент системы, обеспечивающий актуализацию базы данных активов, может именоваться по-разному в зависимости от конкретной системы; например, в системе управления уязвимостями QRadar компании IBM (https://www.ibm.com/support/knowledgecenter/SS42VS_7.2.8/com.ibm.qradar.doc/c_qradar_adm_asset_workflow.html) этот компонент называется профилировщиком активов (asset profiler), так как запись в базе данных активов в терминологии данной системы называется профилем актива (asset profile). За отсутствием устоявшейся терминологии мы будем называть компонент системы, обеспечивающий актуализацию базы данных активов, агрегатором активов. В существующих решениях этот же компонент осуществляет и идентификацию активов.

При обновлении базы данных активов в соответствии с результатом идентификации входящего актива в общем случае возможны три сценария. Если не найдено ни одного актива, соответствующего новым данным, как правило, на их основе создается новый актив. Если установлено соответствие новых данных одному и только одному существующему активу, как правило, обновляется информация об этом активе. Если новым данным соответствует более одного существующего актива, поведение системы зависит от конкретной реализации. Одним из частных вариантов решения в последнем случае является объединение всех найденных активов в один и его актуализация на основе пришедших данных.

Можно выделить несколько факторов, осложняющих эту задачу: неполнота источников данных, динамическая природа части идентифицирующих атрибутов и наличие промежуточных устройств, способных изменять атрибуты, идентифицирующие актив. Подавляющее большинство источников предоставляет принципиально неполный набор данных. Наиболее полный набор идентифицирующих атрибутов способен принести только аудит актива в режиме белого ящика, но даже в этом случае полнота данных зависит от сочетания операционной системы актива и используемого при аудите протокола (например, SSH, WMI, SNMP, OPSEC). Часть идентифицирующих атрибутов способна изменяться с течением времени - как автоматически, в рамках нормального функционирования актива (например, IP-адрес), так и в результате вмешательства администратора (например, имя устройства). Наконец, промежуточные устройства способны изменять атрибуты, потенциально идентифицирующие актив, на пути между сканирующим агентом и активом (NAT, балансировщики нагрузки), между источником событий и приемником событий (например, централизованный сервер syslog), между активом и источником событий, от которого поступает информация о данном активе (например, VPN-шлюз между удаленным активом и DHCP-сервером).

Как следствие, неизбежно возникновение ситуаций, когда часть идентифицирующих атрибутов во входных данных соответствует одной или нескольким существующим записям в базе активов, но в действительности входные данные и существующие записи относятся к различным реальным активам. Возможны два принципиальных подхода к таким ситуациям. Первый можно назвать презумпцией идентичности активов: предполагается, что в большинстве случаев активы, для которых найдено соответствие каких-либо идентифицирующих атрибутов, действительно идентичны, если не наблюдается явных признаков обратного. Второй можно назвать презумпцией различия: предполагается, что активы различны, если в результате дополнительных проверок не удается с достаточной достоверностью установить их идентичность. В настоящее время в существующих решениях доминирует первый подход. Мы будем исходить из второго подхода, из которого проистекает как постановка задачи, так и используемая ниже терминология. В рамках данного подхода нормальной считается гипотеза о различии двух активов, а альтернативной - об их идентичности. Соответственно, ошибкой первого рода будем называть принятие решения об идентичности двух в действительности различных активов; ошибкой второго рода - принятие решения о том, что две различные записи соответствуют двум различным активам, тогда как в действительности они соответствуют одному и тому же реальному активу.

Задача, таким образом, заключается в минимизации уровня ошибок первого рода. Второстепенной целью является минимизация уровня ошибок второго рода. Толерантность к ошибкам второго рода связана с тем, что основной причиной их возникновения представляется неполнота входных данных; соответственно, по мере сбора большего количества данных, идентифицирующих активы, автоматически устраняется и большая часть ошибок второго рода. Ошибки первого рода, результирующие в объединении записей о различных активах, напротив, являются деструктивными, так как их результат невозможно исправить без ручного вмешательства. Поэтому введение какой-либо логики с целью минимизации уровня ошибок второго рода допустимо только в том случае, если в результате при этом не возрастает уровень ошибок первого рода.

Существующие способы идентификации активов допускают высокую частоту ошибок первого рода и обладают рудиментарными механизмами проверки на их возникновение, в результате чего в процессе штатного функционирования системы в хранилище активов появляются записи, в которых хаотично и в общем случае непредсказуемо смешиваются данные, соответствующие нескольким реальным активам. Такие записи не могут быть использованы для адекватного выполнения любых задач современной системы управления событиями информационной безопасности, в которых задействуется компонент управления активами, как то: оценка соответствия политике безопасности, отслеживание уязвимостей, оценка рисков, связь событий и инцидентов с активами. Для восстановления непротиворечивого состояния хранилища активов требуется ручное удаление подобных записей, что влечет за собой потерю всех данных, соответствующих затронутым активам; при этом ничто не гарантирует от повторного возникновения подобных записей в процессе дальнейшего функционирования системы. В отдельных случаях, как, например, в способе идентификации активов, реализованном компанией IBM в системе управления уязвимостями QRadar (www.ibm.com/support/knowledgecenter/SS42VS_7.2.8/com.ibm.gradar.doc/c_gradar_ug_assets.html), вводятся дополнительные апостериорные проверки, в которых косвенным признаком наличия уже допущенных ошибок первого рода становится аномальное количество объединений записей об активах. Таким образом, существующие способы не решают задачу минимизации ложных объединений активов. Предлагаемый способ позволяет решить эту задачу.

Сущность изобретения

Технический результат настоящего изобретения заключается в минимизации ошибок первого рода, а именно объединений записей в базе данных активов, соответствующих различным реальным активам, с помощью способа идентификации активов, в котором осуществляется последовательная проверка идентификационных данных, упорядоченных по приоритету в соответствии с типом сравниваемых активов и результатом вспомогательных проверок, для исключения возможности объединения записей об активах, не соответствующих более приоритетному критерию проверки, на основании совпадения идентификационных данных, которым при проверке назначен меньший приоритет.

Согласно одному из вариантов реализации предлагается способ идентификации информационных активов, при этом под реальным информационным активом понимается совокупность физического или виртуального устройства (такого как сервер, компьютер, сетевое оборудование), подключенного к информационной сети, и установленного на нем программного обеспечения, включая операционную систему, при этом далее в целях краткости под словом «актив», в зависимости от контекста, может пониматься как реальный информационный актив, так и соответствующая ему запись в базе данных, при этом сам способ содержит этапы, на которых:

а) сопоставляют набор идентификационных данных входящего актива множеству идентификационных данных всех существующих записей об активах путем попарного сравнения идентификационных данных входящего актива с каждой существующей записью на основании типа актива и по меньшей мере одного способа проверки идентификационных данных для получения множества существующих активов, соответствующих входящему;

б) множество существующих активов, соответствующих входящему, проверяют на непротиворечивость на основании типа актива и по меньшей мере одного способа проверки идентификационных данных для получения непротиворечивого подмножества активов, идентичных входящему;

в) в случае, если количество существующих активов, идентичных входящему, равно нулю, создают новую запись в базе активов в соответствии с входящими данными;

г) в случае, если количество существующих активов, идентичных входящему, равно одному, обновляют найденную запись в базе активов в соответствии с входящими данными;

д) в случае, если количество существующих активов, идентичных входящему, больше одного, объединяют найденные записи в базе активов и обновляют объединенную запись в соответствии с входящими данными.

Согласно одному из частных вариантов реализации предлагается способ, в котором тип актива может определяться в соответствии с типом операционной системы, где различные типы операционных систем организованы в иерархию наследования, при этом более подробные сведения об операционной системе представляют собой дочерний тип по отношению к более общим, таким образом, в корне дерева наследования находится тип устройства, об операционной системе которого ничего не известно, при этом критерием несоответствия двух активов может считаться невыполнение условия нахождения их типов на одной ветви в иерархии наследования, что исключает возможность объединения записей об этих активах на основании совпадения идентификационных данных.

Согласно еще одному частному варианту реализации предлагается способ, в котором проверка идентификационных данных осуществляется путем сравнения ключей идентификации, упорядоченных по приоритету в соответствии с типом обоих сравниваемых активов и результатом вспомогательных проверок.

Согласно еще одному частному варианту реализации предлагается способ, в котором в качестве ключа идентификации может выступать идентификатор виртуальной машины.

Согласно еще одному частному варианту реализации предлагается способ, в котором в качестве ключа идентификации может выступать множество МАС-адресов всех активных интерфейсов устройства.

Согласно еще одному частному варианту реализации предлагается способ, в котором в качестве ключа идентификации может выступать уникальный идентификатор устройства.

Согласно еще одному частному варианту реализации предлагается способ, в котором в качестве уникального идентификатора устройства может использоваться серийный номер, для операционных систем сетевых устройств.

Согласно еще одному частному варианту реализации предлагается способ, в котором в качестве уникального идентификатора устройства может использоваться уникальный идентификатор загрузочного раздела диска, для ОС семейств Unix и Windows.

Согласно еще одному частному варианту реализации предлагается способ, в котором в качестве ключа идентификации может выступать имя устройства.

Согласно еще одному частному варианту реализации предлагается способ, в котором в качестве ключа идентификации может выступать множество уникальных идентификаторов устройств, входящих в отказоустойчивую группу, для обеспечения возможности представления отказоустойчивой группы устройств как единого узла в сети.

Согласно еще одному частному варианту реализации предлагается способ, в котором в качестве ключа идентификации может выступать множество адресов IPv4 всех активных интерфейсов устройства.

Согласно еще одному частному варианту реализации предлагается способ, в котором в качестве ключа идентификации может выступать множество адресов IPv6 всех активных интерфейсов устройства.

Согласно еще одному частному варианту реализации предлагается способ, в котором в качестве ключа идентификации может выступать полное доменное имя устройства (далее - «FQDN»).

Согласно еще одному частному варианту реализации предлагается способ, в котором критерием соответствия двух активов, для обоих из которых задан идентификатор виртуальной машины, может считаться равенство идентификаторов виртуальной машины сравниваемых активов.

Согласно еще одному частному варианту реализации предлагается способ, в котором критерием несоответствия двух активов, для обоих из которых задан идентификатор виртуальной машины, может считаться неравенство идентификаторов виртуальной машины сравниваемых активов, что исключает возможность объединения записей об этих активах на основании совпадения других ключей идентификации.

Согласно еще одному частному варианту реализации предлагается способ, в котором при сравнении двух активов, если по меньшей мере у одного из них не задан идентификатор виртуальной машины, выбор критерия сравнения может производиться в зависимости от результатов дополнительной проверки, устанавливающей, известно ли про оба актива, что они являются виртуальными устройствами.

Согласно еще одному частному варианту реализации предлагается способ, в котором критерием несоответствия двух активов, для обоих из которых известно, что они являются виртуальными устройствами, может считаться отсутствие пересечения множеств МАС-адресов сравниваемых активов, что исключает возможность объединения записей об этих активах на основании совпадения других ключей идентификации.

Согласно еще одному частному варианту реализации предлагается способ, в котором для двух активов, для обоих из которых известно, что они являются виртуальными устройствами, в случае пересечения множеств МАС-адресов сравниваемых активов производятся дальнейшие проверки ключей для исключения возможности объединения записей об активах на основании совпадения только МАС-адресов.

Согласно еще одному частному варианту реализации предлагается способ, в котором критерием соответствия двух активов, для обоих из которых задан уникальный идентификатор устройства, может считаться равенство уникальных идентификаторов устройства сравниваемых активов.

Согласно еще одному частному варианту реализации предлагается способ, в котором критерием несоответствия двух активов, для обоих из которых задан уникальный идентификатор устройства, может считаться неравенство уникальных идентификаторов устройства сравниваемых активов, что исключает возможность объединения записей об этих активах на основании совпадения других ключей идентификации.

Согласно еще одному частному варианту реализации предлагается способ, в котором при сравнении двух активов, если по меньшей мере у одного из них не задан уникальный идентификатор устройства, критерием соответствия может считаться равенство имен устройства сравниваемых активов.

Согласно еще одному частному варианту реализации предлагается способ, в котором при сравнении двух активов, если по меньшей мере у одного из них не задан уникальный идентификатор устройства, критерием несоответствия может считаться отсутствие имени устройства по меньшей мере у одного из сравниваемых активов, что исключает возможность объединения записей об этих активах на основании совпадения других ключей идентификации.

Согласно еще одному частному варианту реализации предлагается способ, в котором при сравнении двух активов, если по меньшей мере у одного из них не задан уникальный идентификатор устройства, критерием несоответствия может считаться неравенство имен устройства сравниваемых активов, что исключает возможность объединения записей об этих активах на основании совпадения других ключей идентификации.

Согласно еще одному частному варианту реализации предлагается способ, в котором критерием соответствия двух активов, по меньшей мере про один из которых не известно, что он является виртуальным устройством, если для обоих из них задан уникальный идентификатор устройства, может считаться равенство уникальных идентификаторов устройства сравниваемых активов.

Согласно еще одному частному варианту реализации предлагается способ, в котором для двух активов, по меньшей мере про один из которых не известно, что он является виртуальным устройством, если для обоих из них задан уникальный идентификатор устройства и эти идентификаторы неравны, выбор критерия сравнения может производиться в зависимости от результатов дополнительной проверки, устанавливающей, являются ли оба актива устройствами Cisco ASA.

Согласно еще одному частному варианту реализации предлагается способ, в котором критерием несоответствия двух активов может считаться отсутствие соотнесенности по меньшей мере одного из них типу устройства Cisco ASA, что исключает возможность объединения записей об этих активах на основании совпадения других ключей идентификации.

Согласно еще одному частному варианту реализации предлагается способ, в котором критерием несоответствия двух активов, оба из которых являются устройствами Cisco ASA, может считаться неравенство имен устройства сравниваемых активов, что исключает возможность объединения записей об этих активах на основании совпадения других ключей идентификации.

Согласно еще одному частному варианту реализации предлагается способ, в котором для двух активов, оба из которых являются устройствами Cisco ASA, в случае совпадения имен устройства сравниваемых активов выбор критерия сравнения может производиться в зависимости от результатов дополнительной проверки, устанавливающей, известно ли про оба актива, что они являются участниками отказоустойчивой группы, для исключения возможности объединения записей об активах, не составляющих одну отказоустойчивую группу, на основании совпадения имени устройства.

Согласно еще одному частному варианту реализации предлагается способ, в котором критерием соответствия двух активов, являющихся участниками отказоустойчивой группы, может считаться равенство множеств уникальных идентификаторов устройств, входящих в отказоустойчивую группу, для обоих активов.

Согласно еще одному частному варианту реализации предлагается способ, в котором критерием несоответствия двух активов, являющихся участниками отказоустойчивой группы, может считаться неравенство множеств уникальных идентификаторов устройств, входящих в отказоустойчивую группу, для обоих активов, что исключает возможность объединения записей об этих активах на основании совпадения других ключей идентификации.

Согласно еще одному частному варианту реализации предлагается способ, в котором критерием соответствия двух активов, про один из которых известно, что он является участником отказоустойчивой группы, может считаться вхождение уникального идентификатора устройства второго актива во множество уникальных идентификаторов устройств, входящих в отказоустойчивую группу, первого актива.

Согласно еще одному частному варианту реализации предлагается способ, в котором критерием несоответствия двух активов, про один из которых известно, что он является участником отказоустойчивой группы, может считаться отсутствие вхождения уникального идентификатора устройства второго актива во множество уникальных идентификаторов устройств, входящих в отказоустойчивую группу, первого актива, что исключает возможность объединения записей об этих активах на основании совпадения других ключей идентификации.

Согласно еще одному частному варианту реализации предлагается способ, в котором критерием соответствия двух активов, про оба из которых неизвестно, являются ли они участниками отказоустойчивой группы, может считаться полное вхождение множества IP-адресов одного актива во множество IP-адресов другого актива, при этом сравнение может производиться для адресов IPv4 и IPv6.

Согласно еще одному частному варианту реализации предлагается способ, в котором критерием несоответствия двух активов, про оба из которых неизвестно, являются ли они участниками отказоустойчивой группы, может считаться отсутствие полного вхождения множества IP-адресов одного актива во множество IP-адресов другого актива, при этом сравнение может производиться для адресов IPv4 и IPv6, что исключает возможность объединения записей об этих активах на основании совпадения других ключей идентификации.

Согласно еще одному частному варианту реализации предлагается способ, в котором для двух активов, по меньшей мере про один из которых не известно, что он является виртуальным устройством, и по меньшей мере для одного из которых не задан уникальный идентификатор устройства, установление приоритетов ключей идентификации для дальнейшего сравнения может производиться в зависимости от результатов дополнительной проверки типа сравниваемых активов, для исключения возможности объединения записей об активах на основании совпадения ключей идентификации, корректность и уникальность которых для конкретных операционных систем не гарантируется.

Согласно еще одному частному варианту реализации предлагается способ, в котором основанием для выбора в качестве приоритетного ключа FQDN может считаться принадлежность обоих сравниваемых активов к одному и тому же типу на основании определения операционной системы активов как Microsoft Windows, VMware ESXi или Cisco IOS.

Согласно еще одному частному варианту реализации предлагается способ, в котором критерием соответствия двух активов - в случае выбора в качестве приоритетного ключа FQDN, при условии, что FQDN задано для обоих активов, - может считаться равенство FQDN сравниваемых активов.

Согласно еще одному частному варианту реализации предлагается способ, в котором критерием несоответствия двух активов - в случае выбора в качестве приоритетного ключа FQDN, при условии, что FQDN задано для обоих активов, - может считаться неравенство FQDN сравниваемых активов, что исключает возможность объединения записей об этих активах на основании совпадения других ключей идентификации.

Согласно еще одному частному варианту реализации предлагается способ, в котором критерием соответствия двух активов - в случае выбора в качестве приоритетного ключа FQDN, при условии, что по меньшей мере для одного из них FQDN не задано, при этом операционная система обоих активов определена как Cisco IOS и для обоих активов задано имя устройства, - может считаться равенство имен устройства сравниваемых активов.

Согласно еще одному частному варианту реализации предлагается способ, в котором критерием несоответствия двух активов - в случае выбора в качестве приоритетного ключа FQDN, при условии, что по меньшей мере для одного из них FQDN не задано, при этом операционная система обоих активов определена как Cisco IOS и для обоих активов задано имя устройства, - может считаться неравенство имен устройства сравниваемых активов, что исключает возможность объединения записей об этих активах на основании совпадения других ключей идентификации.

Согласно еще одному частному варианту реализации предлагается способ, в котором критерием соответствия двух активов - в случае, если FQDN не было выбрано в качестве приоритетного ключа, при условии, что для обоих активов задано имя устройства, - может считаться равенство имен устройства сравниваемых активов.

Согласно еще одному частному варианту реализации предлагается способ, в котором критерием несоответствия двух активов - в случае, если FQDN не было выбрано в качестве приоритетного ключа, при условии, что для обоих активов задано имя устройства, - может считаться неравенство имен устройства сравниваемых активов, что исключает возможность объединения записей об этих активах на основании совпадения других ключей идентификации.

Согласно еще одному частному варианту реализации предлагается способ, в котором выбор критерия сравнения может производиться в зависимости от наличия непустого множества МАС-адресов в ключах обоих активов.

Согласно еще одному частному варианту реализации предлагается способ, в котором критерием соответствия двух активов, для обоих из которых задано непустое множество МАС-адресов, может считаться пересечение множеств МАС-адресов сравниваемых активов.

Согласно еще одному частному варианту реализации предлагается способ, в котором критерием несоответствия двух активов, для обоих из которых задано непустое множество МАС-адресов, может считаться отсутствие пересечения множеств МАС-адресов сравниваемых активов, что исключает возможность объединения записей об этих активах на основании совпадения других ключей идентификации.

Согласно еще одному частному варианту реализации предлагается способ, в котором для двух активов, множество МАС-адресов по меньшей мере одного из которых пусто, выбор критерия сравнения может производиться в зависимости от наличия непустого множества адресов IPv4 в ключах обоих активов.

Согласно еще одному частному варианту реализации предлагается способ, в котором критерием соответствия двух активов, для обоих из которых задано непустое множество адресов IPv4, может считаться пересечение множеств адресов IPv4 сравниваемых активов.

Согласно еще одному частному варианту реализации предлагается способ, в котором критерием несоответствия двух активов, для обоих из которых задано непустое множество адресов IPv4, может считаться отсутствие пересечения множеств адресов IPv4 сравниваемых активов.

Согласно еще одному частному варианту реализации предлагается способ, в котором критерием соответствия двух активов, множество адресов IPv4 по меньшей мере одного из которых пусто, может считаться пересечение множеств адресов IPv6 сравниваемых активов.

Согласно еще одному частному варианту реализации предлагается способ, в котором критерием несоответствия двух активов, множество адресов IPv4 по меньшей мере одного из которых пусто, может считаться отсутствие пересечения множеств адресов IPv6 сравниваемых активов.

Согласно еще одному частному варианту реализации предлагается способ, в котором для получения непротиворечивого подмножества активов, идентичных входящему:

а) множество активов, соответствующих входящему, упорядочивают в обратном хронологическом порядке в соответствии со временем последнего обновления записи об активе;

б) создают общий набор идентификационных данных и заносят туда идентификационные данные входящего актива;

в) задают множество активов, идентичных входящему, как пустое множество;

г) каждую запись из упорядоченного множества активов, соответствующих входящему, последовательно проверяют на соответствие общему набору идентификационных данных на основании тех же способов проверки типа актива и идентификационных данных, которые используются для определения соответствия входящего актива существующим записям, в том же логическом порядке;

д) в случае установления соответствия проверяемой записи общему набору идентификационных данных включают проверяемую запись во множество активов, идентичных входящему, а ее набор идентификационных данных добавляют к общему набору идентификационных данных для исключения возможности объединения с записями, соответствующими входящему активу, но не соответствующими уже проверенным записям.

Согласно еще одному частному варианту реализации предлагается способ, в котором получение множества идентификационных данных всех существующих записей об активах может осуществляться не путем запроса к базе данных активов, а путем сохранения идентификационных данных всех входящих активов и принятых решений по обновлению или объединению записей об активах.

Краткое описание чертежей

Дополнительные цели, признаки и преимущества настоящего изобретения будут очевидными из прочтения последующего описания осуществления изобретения со ссылкой на прилагаемые чертежи, на которых:

Фиг. 1 описывает вариант взаимодействия компонентов системы управления событиями информационной безопасности, известный из уровня техники.

Фиг. 2 описывает вариант взаимодействия компонентов системы управления событиями информационной безопасности, в рамках которой возможно осуществление настоящего изобретения.

Фиг. 3 иллюстрирует способ работы настоящего изобретения.

Описание вариантов осуществления изобретения

Объекты и признаки настоящего изобретения, способы для достижения этих объектов и признаков станут очевидными посредством отсылки к примерным вариантам осуществления. Однако настоящее изобретение не ограничивается примерными вариантами осуществления, раскрытыми ниже, оно может воплощаться в различных видах.

Сущность, приведенная в описании, является не чем иным, как конкретными деталями, необходимыми для помощи специалисту в области техники в исчерпывающем понимании изобретения, и настоящее изобретение определяется в объеме приложенной формулы.

Введем несколько терминов для лучшего понимания материала заявки.

Служба управления событиями - центральный компонент системы управления событиями информационной безопасности, обеспечивающий разбор и нормализацию исходных событий, их корреляцию и извлечение из них полезных данных, в том числе относящихся к активам. Именование данного компонента, как и его внутренняя архитектура, может различаться в зависимости от конкретной системы конкретного производителя; например, в системе управления уязвимостями QRadar компании IBM для его обозначения используется название Sense Analytics Engine (https://public.dhe.ibm.com/common/ssi/ecm/wg/en/wgd03097usen/qradar-siem-digital-data-sheet-june-29-2016_WGD03097USEN.pdf). В контексте данной заявки данный компонент системы управления событиями информационной безопасности рассматривается исключительно с точки зрения его интерфейса с компонентами, непосредственно относящимися к сущности изобретения, то есть с компонентами системы управления событиями информационной безопасности, осуществляющими управление активами.

Служба управления сканированием - компонент системы управления событиями информационной безопасности, поставляющий в систему информацию об активах от встроенных или внешних сканеров аудита и отслеживания уязвимостей, если в системе реализована такая возможность. Именование данного компонента и его доступность в системе зависят от конкретной системы конкретного производителя; например, в системе управления уязвимостями QRadar компании IBM (https://www.ibm.com/support/knowledgecenter/SS42VS_7.2.8/com.ibm.gradar.doc/c_qvm_vm_ov.html) он называется менеджером уязвимостей (Vulnerability Manager).

Скан - формат, в котором информация об активах поступает в систему от службы управления сканированием.

Хранилище сканов - компонент системы, который может использоваться для промежуточной консолидации сканов с дальнейшей их передачей на обработку агрегатору активов.

Фиг. 1 описывает вариант взаимодействия компонентов системы управления событиями информационной безопасности. Поскольку областью применения настоящего изобретения является управление активами, на схеме показаны только компоненты системы, непосредственно относящиеся к задаче поддержания и обновления базы данных активов, и компоненты, взаимодействующие с ними, при этом в целях упрощения все компоненты, относящиеся к управлению событиями, представлены в виде единого компонента, а именно службы управления событиями 110, без учета внутренней архитектуры конкретного решения данного компонента, не оказывающей влияния на его интерфейс с компонентами, осуществляющими управление активами.

Служба управления сканированием 210 поставляет сканы, собранные модулями сканирования (на схеме не показаны), в хранилище сканов 220. Данные об активах, поступающие от службы управления событиями 110, также поступают в хранилище сканов 220 в виде сканов активов. Агрегатор активов 240 получает из хранилища сканов 220 новые сканы, ищет в базе данных активов 250 записи, соответствующие входящему скану по критерию равенства хотя бы одного из ключевых полей, и в зависимости от результатов поиска создает новую запись, обновляет уже существующую или объединяет несколько существующих записей в базе данных активов 250.

Однако, как было отмечено в уровне техники, недостатком такого решения является высокая частота ошибок первого рода, выражающихся в объединении записей, соответствующих различным реальным активам.

Фиг. 2 описывает вариант взаимодействия компонентов системы управления событиями информационной безопасности, в рамках которой возможно осуществление настоящего изобретения. В отличие от Фиг. 1, на данном чертеже добавлена служба идентификации активов 230, которая получает тип и набор ключей идентификации каждого входящего актива из хранилища сканов 220, определяет множество существующих активов, идентичных входящему, и в зависимости от мощности этого множества принимает решение о создании нового актива, обновлении существующего или объединении нескольких существующих активов. Агрегатор активов 240 получает от службы идентификации активов 230 команду, соответствующую принятому решению, получает из хранилища сканов 220 скан входящего актива, выполняет полученную команду над записями в базе активов 250 и данными скана и записывает результат в базу активов 250.

Поскольку идентификационные данные всех активов перед записью в базу активов 250 в обязательном порядке проходят через службу идентификации активов 230, в частном варианте реализации получение множества идентификационных данных всех существующих записей об активах может осуществляться без непосредственного запроса со стороны службы идентификации активов 230 к базе данных активов 250, путем сохранения идентификационных данных всех входящих активов и принятых решений по обновлению или объединению записей об активах.

В одном из вариантов реализации служба идентификации активов 230 также отвечает на запросы службы управления событиями 110 для установления связи между активами и событиями (привязки событий к активам). Данная дополнительная функция не влияет на состояние базы активов 250.

Также отметим, что служба идентификации активов может быть реализована как в виде отдельного сервиса в операционной системе, так и в виде программного компонента в составе агрегатора активов.

Фиг. 3 иллюстрирует способ работы настоящего изобретения. Тип и ключи идентификации входящего актива 310 поступают на вход службы идентификации активов 230. На этапе 320 сопоставляют набор идентификационных данных входящего актива 310 множеству идентификационных данных всех существующих записей об активах путем попарного сравнения идентификационных данных входящего актива с идентификационными данными каждой существующей записи на основании типа актива и по меньшей мере одного способа проверки идентификационных данных. В случае, если на этапе проверки 321 было установлено соответствие существующего актива входящему, на этапе 322 существующий актив добавляют в коллекцию активов, соответствующих входящему, при этом здесь и далее под коллекцией активов понимается множество идентификационных данных с указанием типа активов. Сопоставление входящего актива 310 и существующих записей об активах выполняется до исчерпания множества идентификационных данных всех существующих активов. На этапе 330 полученную коллекцию активов, соответствующих входящему, сортируют в обратном хронологическом порядке в соответствии со временем последнего обновления записи об активе. На этапе 340 создают общий набор идентификационных данных и заносят туда идентификационные данные входящего актива. На этапе 350 каждый актив из упорядоченной коллекции активов, соответствующих входящему, последовательно проверяют на соответствие общему набору на основании тех же способов проверки типа актива и идентификационных данных, которые используются для определения соответствия входящего актива существующим записям, в том же логическом порядке. В случае, если на этапе проверки 351 было установлено соответствие проверяемого актива общему набору, на этапе 352 актив добавляют в коллекцию активов, идентичных входящему, а на этапе 353 идентификационные данные этого актива добавляют в общий набор.

На этапе 360 осуществляется принятие решения на основании количества активов, идентичных входящему. Если это количество равно нулю, на этапе 370 создают новый актив. Если это количество равно единице, на этапе 380 обновляют существующий актив. Если это количество больше одного, на этапе 390 объединяют существующие активы и обновляют объединенный актив на основании данных входящего актива.

В заключение следует отметить, что приведенные в описании сведения являются примерами, которые не ограничивают объем настоящего изобретения, определенного формулой. Специалисту в данной области становится понятным, что могут существовать и другие варианты осуществления настоящего изобретения, согласующиеся с сущностью и объемом настоящего изобретения.

1. Способ идентификации информационных активов, при этом под реальным информационным активом понимается совокупность физического или виртуального устройства, такого как сервер, компьютер, сетевое оборудование, подключенного к информационной сети, и установленного на нем программного обеспечения, включая операционную систему, при этом далее в целях краткости под словом «актив», в зависимости от контекста, может пониматься как реальный информационный актив, так и соответствующая ему запись в базе данных, при этом сам способ содержит этапы, на которых:

а) сопоставляют набор идентификационных данных входящего актива множеству идентификационных данных всех существующих записей об активах путем попарного сравнения идентификационных данных входящего актива с каждой существующей записью на основании типа актива и по меньшей мере одного способа проверки идентификационных данных для получения множества существующих активов, соответствующих входящему;

б) множество существующих активов, соответствующих входящему, проверяют на непротиворечивость на основании типа актива и по меньшей мере одного способа проверки идентификационных данных для получения непротиворечивого подмножества активов, идентичных входящему;

в) в случае, если количество существующих активов, идентичных входящему, равно нулю, создают новую запись в базе активов в соответствии с входящими данными;

г) в случае, если количество существующих активов, идентичных входящему, равно одному, обновляют найденную запись в базе активов в соответствии с входящими данными;

д) в случае, если количество существующих активов, идентичных входящему, больше одного, объединяют найденные записи в базе активов и обновляют объединенную запись в соответствии с входящими данными.

2. Способ по п. 1, в котором тип актива может определяться в соответствии с типом операционной системы, где различные типы операционных систем организованы в иерархию наследования, при этом более подробные сведения об операционной системе представляют собой дочерний тип по отношению к более общим, таким образом, в корне дерева наследования находится тип устройства, об операционной системе которого ничего не известно, при этом критерием несоответствия двух активов может считаться невыполнение условия нахождения их типов на одной ветви в иерархии наследования, что исключает возможность объединения записей об этих активах на основании совпадения идентификационных данных.

3. Способ по п. 1, в котором проверка идентификационных данных осуществляется путем сравнения ключей идентификации, упорядоченных по приоритету в соответствии с типом обоих сравниваемых активов и результатом вспомогательных проверок.

4. Способ по п. 3, в котором в качестве ключа идентификации может выступать идентификатор виртуальной машины.

5. Способ по п. 3, в котором в качестве ключа идентификации может выступать множество МАС-адресов всех активных интерфейсов устройства.

6. Способ по п. 3, в котором в качестве ключа идентификации может выступать уникальный идентификатор устройства.

7. Способ по п. 6, в котором в качестве уникального идентификатора устройства может использоваться серийный номер для операционных систем сетевых устройств.

8. Способ по п. 6, в котором в качестве уникального идентификатора устройства может использоваться уникальный идентификатор загрузочного раздела диска для ОС семейств Unix и Microsoft Windows.

9. Способ по п. 3, в котором в качестве ключа идентификации может выступать имя устройства.

10. Способ по п. 3, в котором в качестве ключа идентификации может выступать множество уникальных идентификаторов устройств, входящих в отказоустойчивую группу, для обеспечения возможности представления отказоустойчивой группы устройств как единого узла в сети.

11. Способ по п. 3, в котором в качестве ключа идентификации может выступать множество адресов IPv4 всех активных интерфейсов устройства.

12. Способ по п. 3, в котором в качестве ключа идентификации может выступать множество адресов IPv6 всех активных интерфейсов устройства.

13. Способ по п. 3, в котором в качестве ключа идентификации может выступать полное доменное имя устройства (далее - «FQDN»).

14. Способ по п. 3, в котором критерием соответствия двух активов, для обоих из которых задан идентификатор виртуальной машины, может считаться равенство идентификаторов виртуальной машины сравниваемых активов.

15. Способ по п. 3, в котором критерием несоответствия двух активов, для обоих из которых задан идентификатор виртуальной машины, может считаться неравенство идентификаторов виртуальной машины сравниваемых активов, что исключает возможность объединения записей об этих активах на основании совпадения других ключей идентификации.

16. Способ по п. 3, в котором при сравнении двух активов, если по меньшей мере у одного из них не задан идентификатор виртуальной машины, выбор критерия сравнения может производиться в зависимости от результатов дополнительной проверки, устанавливающей, известно ли про оба актива, что они являются виртуальными устройствами.

17. Способ по п. 16, в котором критерием несоответствия двух активов, для обоих из которых известно, что они являются виртуальными устройствами, может считаться отсутствие пересечения множеств МАС-адресов сравниваемых активов, что исключает возможность объединения записей об этих активах на основании совпадения других ключей идентификации.

18. Способ по п. 16, в котором для двух активов, для обоих из которых известно, что они являются виртуальными устройствами, в случае пересечения множеств МАС-адресов сравниваемых активов производятся дальнейшие проверки ключей для исключения возможности объединения записей об активах на основании совпадения только МАС-адресов.

19. Способ по п. 18, в котором критерием соответствия двух активов, для обоих из которых задан уникальный идентификатор устройства, может считаться равенство уникальных идентификаторов устройства сравниваемых активов.

20. Способ по п. 18, в котором критерием несоответствия двух активов, для обоих из которых задан уникальный идентификатор устройства, может считаться неравенство уникальных идентификаторов устройства сравниваемых активов, что исключает возможность объединения записей об этих активах на основании совпадения других ключей идентификации.

21. Способ по п. 18, в котором при сравнении двух активов, если по меньшей мере у одного из них не задан уникальный идентификатор устройства, критерием соответствия может считаться равенство имен устройства сравниваемых активов.

22. Способ по п. 18, в котором при сравнении двух активов, если по меньшей мере у одного из них не задан уникальный идентификатор устройства, критерием несоответствия может считаться отсутствие имени устройства по меньшей мере у одного из сравниваемых активов, что исключает возможность объединения записей об этих активах на основании совпадения других ключей идентификации.

23. Способ по п. 18, в котором при сравнении двух активов, если по меньшей мере у одного из них не задан уникальный идентификатор устройства, критерием несоответствия может считаться неравенство имен устройства сравниваемых активов, что исключает возможность объединения записей об этих активах на основании совпадения других ключей идентификации.

24. Способ по п. 16, в котором критерием соответствия двух активов, по меньшей мере про один из которых не известно, что он является виртуальным устройством, если для обоих из них задан уникальный идентификатор устройства, может считаться равенство уникальных идентификаторов устройства сравниваемых активов.

25. Способ по п. 16, в котором для двух активов, по меньшей мере про один из которых не известно, что он является виртуальным устройством, если для обоих из них задан уникальный идентификатор устройства и эти идентификаторы неравны, выбор критерия сравнения может производиться в зависимости от результатов дополнительной проверки, устанавливающей, являются ли оба актива устройствами Cisco ASA.

26. Способ по п. 25, в котором критерием несоответствия двух активов может считаться отсутствие соотнесенности по меньшей мере одного из них типу устройства Cisco ASA, что исключает возможность объединения записей об этих активах на основании совпадения других ключей идентификации.

27. Способ по п. 25, в котором критерием несоответствия двух активов, оба из которых являются устройствами Cisco ASA, может считаться неравенство имен устройства сравниваемых активов, что исключает возможность объединения записей об этих активах на основании совпадения других ключей идентификации.

28. Способ по п. 25, в котором для двух активов, оба из которых являются устройствами Cisco ASA, в случае совпадения имен устройства сравниваемых активов выбор критерия сравнения может производиться в зависимости от результатов дополнительной проверки, устанавливающей, известно ли про оба актива, что они являются участниками отказоустойчивой группы, для исключения возможности объединения записей об активах, не составляющих одну отказоустойчивую группу, на основании совпадения имени устройства.

29. Способ по п. 28, в котором критерием соответствия двух активов, являющихся участниками отказоустойчивой группы, может считаться равенство множеств уникальных идентификаторов устройств, входящих в отказоустойчивую группу, для обоих активов.

30. Способ по п. 28, в котором критерием несоответствия двух активов, являющихся участниками отказоустойчивой группы, может считаться неравенство множеств уникальных идентификаторов устройств, входящих в отказоустойчивую группу, для обоих активов, что исключает возможность объединения записей об этих активах на основании совпадения других ключей идентификации.

31. Способ по п. 28, в котором критерием соответствия двух активов, про один из которых известно, что он является участником отказоустойчивой группы, может считаться вхождение уникального идентификатора устройства второго актива во множество уникальных идентификаторов устройств, входящих в отказоустойчивую группу, первого актива.

32. Способ по п. 28, в котором критерием несоответствия двух активов, про один из которых известно, что он является участником отказоустойчивой группы, может считаться отсутствие вхождения уникального идентификатора устройства второго актива во множество уникальных идентификаторов устройств, входящих в отказоустойчивую группу, первого актива, что исключает возможность объединения записей об этих активах на основании совпадения других ключей идентификации.

33. Способ по п. 28, в котором критерием соответствия двух активов, про оба из которых неизвестно, являются ли они участниками отказоустойчивой группы, может считаться полное вхождение множества IP-адресов одного актива во множество IP-адресов другого актива, при этом сравнение может производиться для адресов IPv4 и IPv6.

34. Способ по п. 28, в котором критерием несоответствия двух активов, про оба из которых не известно, являются ли они участниками отказоустойчивой группы, может считаться отсутствие полного вхождения множества IP-адресов одного актива во множество IP-адресов другого актива, при этом сравнение может производиться для адресов IPv4 и IPv6, что исключает возможность объединения записей об этих активах на основании совпадения других ключей идентификации.

35. Способ по п. 16, в котором для двух активов, по меньшей мере про один из которых не известно, что он является виртуальным устройством, и по меньшей мере для одного из которых не задан уникальный идентификатор устройства, установление приоритетов ключей идентификации для дальнейшего сравнения может производиться в зависимости от результатов дополнительной проверки типа сравниваемых активов, для исключения возможности объединения записей об активах на основании совпадения ключей идентификации, корректность и уникальность которых для конкретных операционных систем не гарантируется.

36. Способ по п. 35, в котором основанием для выбора в качестве приоритетного ключа FQDN может считаться принадлежность обоих сравниваемых активов к одному и тому же типу на основании определения операционной системы активов как Microsoft Windows, VMware ESXi или Cisco IOS.

37. Способ по п. 35, в котором критерием соответствия двух активов - в случае выбора в качестве приоритетного ключа FQDN, при условии, что FQDN задано для обоих активов, - может считаться равенство FQDN сравниваемых активов.

38. Способ по п. 35, в котором критерием несоответствия двух активов - в случае выбора в качестве приоритетного ключа FQDN, при условии, что FQDN задано для обоих активов, - может считаться неравенство FQDN сравниваемых активов, что исключает возможность объединения записей об этих активах на основании совпадения других ключей идентификации.

39. Способ по п. 35, в котором критерием соответствия двух активов - в случае выбора в качестве приоритетного ключа FQDN, при условии, что по меньшей мере для одного из них FQDN не задано, при этом операционная система обоих активов определена как Cisco IOS и для обоих активов задано имя устройства, - может считаться равенство имен устройства сравниваемых активов.

40. Способ по п. 35, в котором критерием несоответствия двух активов - в случае выбора в качестве приоритетного ключа FQDN, при условии, что по меньшей мере для одного из них FQDN не задано, при этом операционная система обоих активов определена как Cisco IOS и для обоих активов задано имя устройства, - может считаться неравенство имен устройства сравниваемых активов, что исключает возможность объединения записей об этих активах на основании совпадения других ключей идентификации.

41. Способ по п. 35, в котором критерием соответствия двух активов - в случае, если FQDN не было выбрано в качестве приоритетного ключа, при условии, что для обоих активов задано имя устройства, - может считаться равенство имен устройства сравниваемых активов.

42. Способ по п. 35, в котором критерием несоответствия двух активов - в случае, если FQDN не было выбрано в качестве приоритетного ключа, при условии, что для обоих активов задано имя устройства, - может считаться неравенство имен устройства сравниваемых активов, что исключает возможность объединения записей об этих активах на основании совпадения других ключей идентификации.

43. Способ по п. 35, в котором при невыполнении критериев, устанавливающих соответствие или несоответствие сравниваемых активов согласно п. 37-42, выбор критерия сравнения может производиться в зависимости от наличия непустого множества МАС-адресов в ключах обоих активов.

44. Способ по п. 43, в котором критерием соответствия двух активов, для обоих из которых задано непустое множество МАС-адресов, может считаться пересечение множеств МАС-адресов сравниваемых активов.

45. Способ по п. 43, в котором критерием несоответствия двух активов, для обоих из которых задано непустое множество МАС-адресов, может считаться отсутствие пересечения множеств МАС-адресов сравниваемых активов, что исключает возможность объединения записей об этих активах на основании совпадения других ключей идентификации.

46. Способ по п. 43, в котором для двух активов, множество МАС-адресов по меньшей мере одного из которых пусто, выбор критерия сравнения может производиться в зависимости от наличия непустого множества адресов IPv4 в ключах обоих активов.

47. Способ по п. 46, в котором критерием соответствия двух активов, для обоих из которых задано непустое множество адресов IPv4, может считаться пересечение множеств адресов IPv4 сравниваемых активов.

48. Способ по п. 46, в котором критерием несоответствия двух активов, для обоих из которых задано непустое множество адресов IPv4, может считаться отсутствие пересечения множеств адресов IPv4 сравниваемых активов.

49. Способ по п. 46, в котором критерием соответствия двух активов, множество адресов IPv4 по меньшей мере одного из которых пусто, может считаться пересечение множеств адресов IPv6 сравниваемых активов.

50. Способ по п. 46, в котором критерием несоответствия двух активов, множество адресов IPv4 по меньшей мере одного из которых пусто, может считаться отсутствие пересечения множеств адресов IPv6 сравниваемых активов.

51. Способ по п. 1, в котором для получения непротиворечивого подмножества активов, идентичных входящему:

а) множество активов, соответствующих входящему, упорядочивают в обратном хронологическом порядке в соответствии со временем последнего обновления записи об активе;

б) создают общий набор идентификационных данных и заносят туда идентификационные данные входящего актива;

в) задают множество активов, идентичных входящему, как пустое множество;

г) каждую запись из упорядоченного множества активов, соответствующих входящему, последовательно проверяют на соответствие общему набору идентификационных данных на основании тех же способов проверки типа актива и идентификационных данных, которые используются для определения соответствия входящего актива существующим записям, в том же логическом порядке;

д) в случае установления соответствия проверяемой записи общему набору идентификационных данных включают проверяемую запись во множество активов, идентичных входящему, а ее набор идентификационных данных добавляют к общему набору идентификационных данных для исключения возможности объединения с записями, соответствующими входящему активу, но не соответствующими уже проверенным записям.

52. Способ по п. 1, в котором получение множества идентификационных данных всех существующих записей об активах может осуществляться не путем запроса к базе данных активов, а путем сохранения идентификационных данных всех входящих активов и принятых решений по обновлению или объединению записей об активах.