Читать книгу "Управление информационной безопасностью. Стандарты СУИБ"

3 фаза – оценка и принятие решения

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

В этой фазе организация должна выполнить следующие действия:

1) проведение группой поддержки оценки события ИБ, является оно инцидентом или ложной тревогой, и если это – не ложная тревога, требуются ли дальнейшие действия. При оценке нужно применить согласованную шкалу классификации инцидента / события ИБ (в том числе определение воздействия события на активы / сервисы) и принять решение, нужно ли событие классифицировать как инцидент ИБ.

Определяя воздействие события (возможного инцидента) на ИБ, организация должна идентифицировать следующее:

– область воздействия (физическая или логическая),

– попадающие под влияние активы (информация, процессы, сервисы и приложения),

– возможное влияние на ключевые сервисы;

2) проведение ГРИИБ оценки результатов оценки группы поддержки для подтверждения, является ли событие инцидентом. В случае необходимости, нужно применить другой метод оценки, используя согласованную шкалу классификации инцидента / события ИБ с детализацией события (возможного инцидента) и затронутого ресурса (категоризация). Этот процесс нужно завершить принятием решения, как с подтвержденным инцидентом ИБ нужно обращаться, кому и с какой приоритетностью.

Необходимо использовать заранее определенный процесс распределения приоритетов, чтобы назначить ответственного за каждый инцидент ИБ и определить безотлагательность обработки и реагирования на инцидент ИБ, в том числе, немедленное реагирование, правовой анализ и необходимые взаимосвязи;

3) расширение, при необходимости, сферы принятия решений (эскалация) для дальнейших оценок и/или решений;

4) регистрация всех действий, результатов и соответствующих решений для более позднего анализа;

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

6) поддержка режима контроля изменений при отслеживании инцидента ИБ и обновлении данных о нем и актуальности базы данных события / инцидента / уязвимости ИБ.

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

После обнаружения и оповещения о событии ИБ дальнейшая деятельность заключается в следующем:

7) распространение ответственности за действия по управлению инцидентами ИБ на всю иерархию персонала по оценке, решению и действиям, включая персонал, не связанный с ИБ;

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

9) применение директив по ведению документации о событии ИБ и последующих действиях для инцидента ИБ, если событие ИБ классифицируется как инцидент;

10) обновление базы данных события / инцидента / уязвимости ИБ.

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

3.1. Оценка и предварительное решение группы поддержки

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

Затем представитель группы поддержки должен провести оценку для определения, является ли событие ИБ инцидентом (на основании согласованой в организации шкалы классификации инцидентов). Если событие ИБ определяется как неопасное (ложное), необходимо заполнить форму отчета и передать в ГРИИБ для записи в базу данных уязвимостей / инцидентов / событий ИБ и дальнейшего анализа, а также создать копии для сообщившего о событии лица и его руководителя.

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

Кроме даты и времени выполнения действий необходимо документировать:

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

– место хранения доказательств;

– как доказательства архивировались (если необходимо);

– как выполнялось подтверждение доказательств (если необходимо);

– детали безопасного хранения материалов и последующего доступа к ним.

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

Если событие ИБ определено как значительный инцидент (по шкале классификации, принятой в организации), то об этом необходимо немедленно проинформировать руководителя ГРИИБ.

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

Каким бы ни был следующий шаг, группа поддержки должна заполнить форму отчета максимально подробно. Форма отчета об инциденте ИБ должна содержать следующую информацию о нем:

– общее представление;

– возможная цель;

– возможная причина;

– степень значительности;

– принятые меры.

Потенциальное или фактическое негативное влияние инцидента ИБ на бизнес организации может привести к следующим проблемам:

– несанкционированное разглашение информации,

– несанкционированная модификация информации,

– отрицание информации;

– недоступность информации и/или сервиса,

– уничтожение информации и/или сервиса,

– снижение эффективности сервиса.

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

Примерами категорий последствий могут быть:

– финансовые убытки/прерывание бизнес-операций;

– ущерб коммерческим и экономическим интересам;

– ущерб информации, содержащей персональные данные;

– нарушение правовых и нормативных обязательств;

– сбои операций управления и бизнес-операций;

– утрата престижа организации;

– телесные повреждения или смерть;

– социальные проблемы.

Если инцидент ИБ был разрешен, то отчет должен содержать детали предпринятых мер и полученных уроков (например, меры для предотвращения повторного события или подобных событий). После наиболее подробного, по мере возможности, заполнения форма отчета должна быть представлена в ГРИИБ для ввода в базу данных уязвимостей / инцидентов / событий ИБ и анализа в будущем.

Если время расследования превысило время, ранее определенное политикой управления инцидентами ИБ, то по его истечении должен быть составлен промежуточный отчет.

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

– когда и кому необходимо направлять материалы об инциденте;

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

3.2. Оценка и подтверждение инцидента ГРИИБ

Оценка и подтверждение решения о том, является ли событие ИБ инцидентом, входит в обязанности ГРИИБ. Принявший отчет об инциденте сотрудник ГРИИБ должен:

– подтвердить его получение (должен быть заполнен группой поддержки максимально подробно);

– ввести его в базу данных события / инцидента / уязвимости ИБ (если этого не сделала группа поддержки, и обновить базу данных, если необходимо);

– собрать дополнительную информацию о событии ИБ (от группы поддержки, заполнившего отчет сотрудника или какого-либо иного источника);

– проанализировать содержание отчета.

Если все еще остается какая-либо неопределенность относительно подлинности инцидента ИБ или полноты полученной информации, то сотрудник ГРИИБ должен провести вторую оценку для определения реальности или ложности инцидента ИБ (используя согласованую в организации шкалу классификации инцидентов). Если инцидент ИБ определен как ложный, необходимо заполнить отчет о событии ИБ, добавить его в базу данных уязвимостей / инцидентов / событий ИБ и передать руководителю ГРИИБ. Копии отчета необходимо передать группе поддержки, лицу, сообщившему о событии, и его/ее местному руководителю.

Необходимо провести сравнительный анализ инцидента ИБ с любым другим инцидентом / событием, переданным в ГРИИБ. Важно проверить, сопоставим ли инцидент с любым другим событием / инцидентом, или это новый инцидент. Взаимосвязь инцидентов также важна в распределении приоритетов усилий ГРИИБ.

Если инцидент ИБ определен как «реальный», то сотрудник ГРИИБ, при необходимости привлекая коллег, должен провести дальнейшую оценку.

Целью дальнейшей оценки инцидента ИБ является подтверждение следующей информации о нем:

– общее представление;

– цель;

– причина;

– степень значительности;

– последствия;

– принятые меры.

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

Чтобы облегчить процесс адекватного реагирования на инцидент ИБ, им должен заниматься самый компетеный сотрудник или группа сотрудников в ГРИИБ. В частности, когда одновременно обрабатывается несколько инцидентов ИБ, приоритет зависит от уровня реагирования на инцидент ИБ.

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

4 фаза – реагирования

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

В этой фазе ГРИИБ выполняет следующие первоначальные действия:

– немедленное реагирование (локализация инцидента);

– оценка контроля инцидента;

– последующее реагирование;

– передача информации об инциденте.

Также ГРИИБ выполняет при необходимости следующие действия:

– кризисные действия;

– правовая экспертиза;

– эскалация (расширение сферы принятия решений);

– документирование и контроль внесения изменений в схему.

Как только любой инцидент ИБ успешно обработан, этот процесс нужно формально завершить и записать информацию в базу данных уязвимости / инцидента / события ИБ. Эта фаза также включает создание отчетов об уязвимости ИБ в соответствии с действиями, определенными в фазе оценки и решения. Как только любая уязвимость детально обработана, она должна быть записана в базу данных уязвимости / инцидента / события ИБ.

4.1. Немедленное реагирование

После подтверждения инцидента ГРИИБ выполняет следующие действия:

– немедленное реагирование,

– регистрация подробностей в форме отчета,

– введение в базу данных,

– уведомление сотрудников о требуемых действиях.

Результатом данных действий может быть принятие аварийных защитных мер (например, отключение атакованной ИС, сервиса и/или сети по предварительному соглашению с соответствующим руководством ИТ-подразделения и/или управления бизнесом) и/или определение дополнительных защитных мер и уведомление сотрудников организации о принятии этих мер.

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

Процесс реагирования на инциденты ИБ включает следующие действия:

– ограничение их неблагоприятных влияний,

– улучшение ИБ.

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

ГРИИБ также является ответственным за возвращение поврежденных устройств в такое безопасное рабочее состояние (при возможности), которое исключит повторное возникновение инцидента, а также за соответствующее обновление базы данных событий / инцидентов / уязвимостей ИБ.

Примерные действия

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

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

2) Важно, чтобы при принятии соответствующего решения была техническая возможность быстро и надежно изолировать атакованную ИС, сервис и/или сеть. Это даст возможность локализовать инцидент.

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

Что касается других инцидентов ИБ, кроме преднамеренной атаки, то их источник должен быть идентифицирован. Может потребоваться отключение ИС, сервиса и/или сети или изоляция соответствующим их частей (после получения предварительного согласия руководства подразделения ИТ и/или управления бизнесом) на время внедрения защитных мер. Для этого может потребоваться больше времени, если уязвимость ИС, сервиса и/или сети окажется существенной или критически важной.

Второй реакцией на преднамеренную атаку может быть активация дополнительных методов отслеживания действий нарушителя (например, honeypots – «приманки» для хакеров в виде виртуальных ресурсов). Это действие должно осуществляться на основе процедур, задокументированных в схеме управления инцидентами ИБ.

Информация, которая могла быть повреждена в результате инцидента ИБ, должна быть проверена ГРИИБ по резервным записям на предмет модификации или уничтожения. Может возникнуть необходимость проверки целостности журналов регистрации (логов), поскольку злонамеренный нарушитель может подделать их с целью сокрытия следов проникновения.

Обновление информации об инцидентах

Независимо от последующих действий ГРИИБ должна обновить отчет об инциденте ИБ с максимальной детализацией, добавить его в базу данных событий / инцидентов / уязвимостей ИБ и оповестить об этом руководителя ГРИИБ.

Необходимо обновлять следующую информацию об инциденте:

– что собой представляет;

– как, чем или кем был вызван;

– на что повлиял или мог повлиять;

– как изменялась его серьезность;

– как обрабатывался до сих пор.

Если инцидент ИБ разрешен, то отчет должен содержать подробности предпринятых защитных мер и полученных уроков (например, дополнительные защитные меры, которые следует предпринять для предотвращения повторного события или подобных событий). Обновленный отчет следует добавлять в базу данных событий / инцидентов / уязвимостей ИБ и уведомлять руководителя ГРИИБ и других лиц по их требованию.

ГРИИБ должна обеспечить безопасное хранение информации об инциденте ИБ с целью проведения дальнейшей правовой экспертизы и возможного использования в суде как доказательств.

Для инцидента ИБ, повлившего на ИТ, необходимо выполнить следующие действия.

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

При этом необходимо:

– в зависимости от характера инцидента ИБ провести полное дублирование свидетельств правовой экспертизы пораженной системы, сервиса и/или сети на случай судебного разбирательства или резервное копирование логов и важных файлов;

– собрать и проанализировать журналы (логи) соседних систем, сервисов и/или сетей, например, маршрутизаторов и межсетевых экранов;

– всю собранную информацию хранить только на неперезаписываемых носителях;

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

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

Дальнейшая деятельность

После определения реальности инцидента ГРИИБ должна выполнить и другие важные действия:

– проведение правовой экспертизы;

– информирование ответственных лиц за передачу информации о фактах и предложениях (для чего, в какой форме и кому).

Как только собрана полная информация об инциденте ИБ, она должна быть внесена в базу данных событий / инцидентов / уязвимостей ИБ и доложена руководителю ГРИИБ.

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

Член ГРИИБ при оценке инцидента ИБ должен на основании руководящей документации схемы управления ими знать следующее:

– когда и кому направлять материалы,

– действовать согласно процедур контроля изменений.

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

Если инцидент ИБ является серьезным и/или была определена кризисная ситуация, руководитель ГРИИБ, получив санкцию руководителя службы ИБ и руководителя организации, должен сообщить об этом всем подразделениям, которые вовлечены в инцидент ИБ как внутри организации, так и за ее пределами.

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

4.2. Оценка контроля инцидентов ИБ

После того, как член ГРИИБ осуществил немедленные реагирования на инцидент ИБ, соответствующий правовой анализ и коммуникации, необходимо быстро установить, находится ли он под контролем. При необходимости член ГРИИБ может проконсультироваться с коллегами, руководителем ГРИИБ и/или другими специалистами и группами.

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

Если не подтверждается, что инцидент ИБ находится под контролем, член ГРИИБ должен инициировать кризисные действия.

Если инцидент ИБ связан с потерей доступности, методология оценки того, находится ли инцидент ИБ под контролем, должна определять время от возникновения инцидента ИБ до восстановления нормальной ситуации.

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

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

4.3. Последующее реагирование

Определив, что инцидент ИБ находится под контролем и не является объектом кризисной ситуации, член ГРИИБ должен определить необходимость и вероятные способы дальнейшей обработки инцидента ИБ.

Последующее реагирование может включать в себя следующие действия:

– восстановление пораженных систем;

– предотвращение повторного возникновения инцидента;

– активация дополнительных средств мониторинга систем.

Восстановление пораженных систем, сервисов и/или сетей до нормального рабочего состояния может быть достигнуто исправлением известных уязвимостей или отключением скомпрометированных элементов. Если степень инцидента ИБ неизвестна из-за повреждения логов в течение инцидента, всю систему, сервис и/или сеть необходимо перестроить.

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

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

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

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

После успешного завершения действий по реагированию на инцидент ИБ все данные об этом ГРИИБ должна внести в форму отчета и базу данных события / инцидента / уязвимости ИБ и уведомить соответствующий персонал.

4.4. Реагирования на кризисные действия

Может случиться так, что после оценки контроля инцидента ГРИИБ придет к выводу, что он не находится под контролем и должен обрабатываться в режиме кризисного управления в соответствии с заранее разработанным планом.

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

Стратегия кризисного управления должна определить требуемые меры и структуры:

– меры поддержки и кризисного управления;

– организационную структуру и обязанности;

– структуру и положения плана кризисного управления.

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

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

План кризисного управления содержит активацию:

– средств пожаротушения и процедур эвакуации;

– средств предотвращения наводнения и процедур эвакуации;

– средств предотвращения взрыва бомбы и процедур эвакуации;

– специальных расследований технических атак;

– специальных расследований мошенничества в ИС.

4.5. Правовая экспертиза

Если в ходе предыдущей оценки была определена серьезность инцидента ИБ и необходимость сбора доказательств, ГРИИБ должна провести правовую экспертизу инцидента для дисциплинарного или судебного разбирательства. В целях проведения более тщательной экспертизы конкретного инцидента ИБ необходимо применять следственные методы и средства, основанные на ИТ и поддерживаемые документированными процедурами, которые до этого не использовались в управлении инцидентами ИБ.

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

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

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

Со временем, несомненно, возникнет необходимость разработки требований к анализу свидетельств правовой экспертизы в контексте многообразия инцидентов ИБ, включая мошенничество, кражу и акты вандализма. Следовательно, для содействия ГРИИБ потребуется большее число средств, основанных на ИТ, и вспомогательных процедур для получения необходимой информации в информационной системе, сервисе и/или сети, включая восстановление информации, подвергшейся стиранию, шифрованию или искажению. Эти средства должны учитывать все аспекты, связанные с известными типами инцидентов ИБ и документироваться в процедурах ГРИИБ.

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

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

Общий процесс правовой экспертизы должен охватывать следующие виды деятельности:

– обеспечение защиты целевой системы, сервиса и/или сети в процессе проведения правовой экспертизы от появления недоступности, изменений или другой компрометации, включая вредоносное ПО (в том числе вирусы), и каких-либо влияний на их нормальную работу;

– назначение приоритетов сбора доказательств, т.е. рассмотрение их от наиболее до наименее изменчивых (что в значительной степени зависит от характера инцидента ИБ);

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

– восстановление как можно большего числа стертых файлов и других данных;

– раскрытие IP-адресов, имен хостов, сетевых маршрутов и информации Web-сайтов;

– извлечение содержимого скрытых, временных файлов и файлов подкачки, используемых как прикладное, так и системное ПО;

– доступ к содержимому защищенных или зашифрованных файлов (если это не запрещено законодательством);

– анализ всех возможно значимых данных, найденных в специальных (обычно недоступных) областях памяти на дисках;

– анализ времени доступа к файлу, его создания и изменения;

– анализ логов системы / сервиса / сети и приложений;

– определение деятельности пользователей и/или приложений в системе / сервисе / сети;