Реагирование на инциденты информационной безопасности в РФ

От качества реагирования на события и инциденты в компании зависит очень многое:

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

Безусловно, СМИБ (система менеджмента информационной безопасности) призвана заниматься не только этим — общая политика компании, обучение сотрудников, вопросы производительности и эксплуатации систем не менее важны, но именно группа реагирования на инциденты информационной безопасности (ГРИИБ) либо группа реагирования на инциденты защиты информации (ГРИЗИ) и выработанные методики, определяющие их действия, являются ядром всей вашей системы защиты. Существуют разнообразные нормативы реагирования на инциденты компьютерной безопасности, но все они достаточно похожи на ГОСТ Р ИСО/МЭК ТО 18044-2007. Разберемся с понятиями события и инцидента информационной безопасности, а также с общим направлением взаимодействия с ними, согласно вышеназванному ГОСТу.

Определение инцидента и события информационной безопасности

Событие информационной безопасности (information security event): Идентифицированное появление определенного состояния системы, сервиса или сети, указывающего на возможное нарушение политики ИБ или отказ защитных мер, или возникновение неизвестной ранее ситуации, которая может иметь отношение к безопасности. Инцидент информационной безопасности (information security incident): Появление одного или нескольких нежелательных или неожиданных событий ИБ, с которыми связана значительная вероятность компрометации бизнес-операций и создания угрозы ИБ. Близкие по духу термины мы найдем и в других документах, в частности в комплексе Стандартов Банка России. Событий может быть много — но не все они будут инцидентами. Инциденты же, в свою очередь, могут иметь свои градации, но тут важно понимать, что даже «незначительный» инцидент может стать «значительным» или даже «критическим» спустя время или в случае его неправильной обработки. Поэтому даже если у инцидентов может быть ограниченная степень опасности, важность реагирования и контроля над ними очень высока во всех обнаруженных случаях.

Работа с инцидентами информационной безопасности

Далее ГОСТом предлагается следующая стратегия по инцидент-менеджменту:

1. Планирование и подготовка (политика и система менеджмента инцидентов ИБ, тестирование этой системы; создание команды реагирования; инструктаж и обучение сотрудников, план реагирования и т. д.);
2. Реагирование (обнаружение событий ИБ и оповещение о них — обычно происходит через логи и сообщения от сотрудников и пользователей, здесь важна настройка SIEM-системы; оценка и принятие решения: является ли данное событие инцидентом ИБ — тут обычно двухступенчатая проверка, в первый раз определяет круглосуточная служба, и вот если они посчитали событие инцидентом, то идет на расследование к ГРИИБ которым это надо подтвердить или опровергнуть; реагирование на инцидент ИБ, включая правовую экспертизу — здесь сотрудники противостоят открытой атаке, ищут следы, в идеале есть бекапы и мощности для параллельного запуска процессов, дабы не прерывать ведение бизнеса, пока фиксируется состояние систем и изучается проблема);
3. Анализ (дополнительная правовая экспертиза; обобщение накопленного опыта; определение методов улучшения (повышения) безопасности; определение методов улучшения системы менеджмента инцидентов ИБ);
4. Улучшение (провести уточнение результатов анализа рисков безопасности и менеджмента; инициировать улучшение безопасности; провести улучшения системы менеджмента инцидентов ИБ).

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

Реагирование на инциденты информационной безопасности

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

1. Как ГРИИБ/ГРИЗИ получает информацию об инцидентах, по каким каналам/критериям?
2. Кто и как должен подключиться к реагированию?
3. Какие средства и метода реагирования имеются в арсенале?
4. Пошаговая инструкция по действиям в ходе реагирования (изоляция сети, информирование заинтересованных лиц и пр.)

Расследование инцидентов информационной безопасности сторонними силами

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

Порядок расследования инцидентов информационной безопасности

Расследование инцидентов кибербезопасности начинается с фиксации, сбора и анализа свидетельств. Затем происходит поиск ответственных и виновных лиц, а также установление непосредственных причин, по которым инцидент ИБ произошел. Далее происходит анализ IT-инцидента, в котором также выявляют недостатки документов и методик, на основе чего создаются рекомендации по реагированию на инциденты и настройке защиты таким образом, чтобы реагирование и расследование было возможным. Подготавливается отчет экспертизы с приложенными данными, который можно использовать для расследования инцидента информационной безопасности на предприятии как своими силами, так и через другие службы. По форме ниже я принимаю заявки круглосуточно — и даже если я не успею помочь до конца атаки, я смогу помочь с последствиями, а также фиксированием всех необходимых свидетельств, что исключит вероятность их отклонения как «недопустимые» в предстоящем разбирательстве. Вы получите подтвержденные третьей стороной логи, выписки, конфигурации, журналы и итоговый отчет с выводами относительно обстоятельств инцидента; данные могут быть подтверждены мной, как экспертом, в суде. Срок проведения расследования не может превышать два календарных дня, а срок реакции на заявки — семи часов. Чем быстрее вы обратитесь за помощью, чем свежее будет инцидент — тем больше шансов не только собрать достоверную информацию о состоянии систем, но и, возможно, помочь в преследовании злоумышленника на основе собранных данных. Отчет о расследовании инцидента информационной безопасности Практика показывает, что самым эффективным будет оформление отчета (акта) по расследованию инцидента по правилам судебной экспертизы (см. 25 статью 73-ФЗ "О государственной судебно-экспертной деятельности в Российской Федерации") В частности отчет должен включать:

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

Автор статьи: Царев Евгений