Важно, чтобы были налажены такие процедуры, как мониторинг событий, своевременное удаление неиспользуемых учетных записей, контроль и мониторинг действий пользователей, контроль над действиями системных администраторов и пр. В одной из компаний был зафиксирован следующий инцидент: при увольнении с работы системный администратор украл разрабатываемый в компании программный продукт и передал его конкурентам, которые выпустили программу на рынок под своим товарным знаком. Кроме этого, он внес изменения в информационную систему, в результате которых после его ухода функционирование определенных ее компонентов было нарушено. Привлечь администратора к ответственности в данном случае оказалось невозможно, так как, во-первых, не выполнялась регистрация его действий, во-вторых, администратор мог удалить все доказательства своих неправомерных действий и, в-третьих, не была налажена процедура сбора улик об инциденте. Кроме этого, в компании просто не знали, как следует поступать в таких случаях (например, можно было обратиться в специализированную компанию по расследованию инцидентов или подать заявление в суд).
Для описания процедуры управления инцидентами безопасности используется классическая модель непрерывного улучшения процессов, получившая название от цикла Шухарта-Деминга — модель PDCA (Планируй, Plan — Выполняй, Do — Проверяй, Check — Действуй, Act). Стандарт ISO 27001 описывает модель PDCA как основу функционирования всех процессов системы управления информационной безопасностью. Естественно, что и процедура управления инцидентами подчиняется модели PDCA (см. рисунок).
Обнаружение и регистрация инцидента. Инцидент информационной безопасности может заметить пользователь или администратор системы. Как правило, администраторы знают, что следует делать в случае обнаружения инцидентов, чего не всегда можно сказать о пользователях. Для пользователей следует разработать инструкцию, которая, как правило, содержит описание, в каком виде сотрудник должен сообщить о возникновении инцидента, координаты ответственных лиц, а также перечень действий, которые сотрудник может выполнить самостоятельно (или предупредить о том, что выполнять какие-либо действия самостоятельно запрещено). Такой отчет должен содержать подробное описание инцидента, перечисление сотрудников, вовлеченных в инцидент, фамилию сотрудника, зафиксировавшего инцидент и дату возникновения и регистрации инцидента. Таким образом, каждый сотрудник получает инструкцию, определяющую, каковы должны быть его действия, например, в случае, если он продолжил работу с документом и заметил, что с прошлого раза в его документ были внесены изменения, не соответствующие действительности, при этом автор изменений неизвестен.
Далее требуется разработать инструкцию для специалиста, в обязанности которого входит регистрация инцидента. Сотрудник, обнаруживший инцидент, связывается с сотрудником, ответственным за регистрацию инцидента и выполнение дальнейших действий. В небольших компаниях сотрудники обращаются напрямую к специалисту, который может устранить последствия и причины инцидента (например, к системному администратору или администратору безопасности). В достаточно крупных компаниях, как правило, выделяют сотрудника, который регистрирует инцидент и передает информацию об инциденте соответствующим специалистам. Такая инструкция может содержать, например, правила и срок регистрации инцидента, перечень необходимых первоначальных инструкций для сотрудника, обнаружившего инцидент, кроме того, описание порядка передачи информации об инциденте соответствующему специалисту, порядок контроля за устранением последствий и причин инцидента.
Устранение причин, последствий инцидента и его расследование. Инструкция по устранению причин и последствий инцидента включает описание общих действий, которые необходимо предпринять (конкретные действия для каждого вида инцидента определять трудоемко и не всегда целесообразно), а также сроки, в течение которых следует устранить последствия и причины инцидента. Сроки устранения последствий и причин инцидента зависят от уровня инцидента. Следует разработать классификацию инцидентов — определить количество уровней критичности инцидентов, описать инциденты каждого уровня и сроки их устранения. Документ, определяющий, какие события в компании следует считать инцидентом, также может описывать и уровни инцидентов.
Таким образом, инструкция по устранению последствий и причин инцидента может включать: описание действий, предпринимаемых для устранения последствий и причин инцидента, сроки устранения и указание на ответственность за несоблюдение инструкции.
Расследование инцидента включает в себя определение виновных в его возникновении, сбор доказательств и улик инцидента, определение соответствующих дисциплинарных взысканий. В крупных компаниях, как правило, выделяют комиссию по расследованию инцидентов информационной безопасности (в состав которой может входить сотрудник, регистрирующий инциденты). Инструкция по расследованию инцидентов должна описывать: действия по расследованию инцидента (в том числе определение виновных в его возникновении), правила сбора и хранения улик (особенно в случае, если может потребоваться использование улик в судебных органах) и правила внесения дисциплинарных взысканий.
Корректирующие и превентивные действия. После устранения последствий инцидента и восстановления нормального функционирования бизнес-процессов компании, возможно, потребуется выполнить действия по предотвращению повторного возникновения инцидента. Для определения необходимости реализации таких действий следует провести анализ рисков, в рамках которого определяется целесообразность корректирующих и превентивных действий. В некоторых случаях последствия инцидента незначительны по сравнению с корректирующими и превентивными действиями, и тогда целесообразно не совершать дальнейших шагов после устранения последствий инцидента.
Мы рассмотрели все этапы модели PDCA применительно к процессу управления инцидентами информационной безопасности. Далее, для того чтобы процедура выполнялась правильно и эффективно, все эти этапы должны непрерывно и последовательно повторяться. Через определенное время (как правило, через полгода или год) необходимо заново пересмотреть перечень событий, называемых инцидентами, форму отчета и пр., внедрить обновленную процедуру в информационную систему, проверить ее функционирование и эффективности и реализовать превентивные действия. Таким образом, цикл модели PDCA будет непрерывно повторяться и гарантировать четкое функционирование процедуры управления инцидентами и, главное, ее постоянное улучшение.
Во многих крупных компаниях внедрена служба поддержки Service Desk, в обязанности которой входит управление инцидентами в области информационных технологий. Процедура управления ИТ-инцидентами регулируется стандартом ISO/IEC 20000:2005, пришедшим на смену BS 15000:2002, который, в свою очередь, взял за основу библиотеку ITIL. Заметим, что все ISO/IEC серий 9000, 14000, 20000, 27000 и другие стандарты ISO/IEC, описывающие правила создания систем управления различными процессами, гармонично сочетаются друг с другом. Все они в качестве основы управления подконтрольными процессами используют процессный подход, который рассматривает управление как процесс, а именно как набор взаимосвязанных непрерывных действий. Процессный подход акцентирует внимание на достижении поставленных целей, а также на ресурсах, затраченных для этого. Кроме этого, стандарты указанных серий используют модель PDCA как структуру жизненного цикла всех процессов системы управления.
Естественно, что ISO 20000, описывает как систему управления ИТ-сервисами, так и процедуру управления инцидентами, но также рассматривает ИТ-инциденты. Сама процедура управления инцидентами ИТ очень близка к процедуре управления инцидентами информационной безопасности с той лишь разницей, что в последнем случае больший упор делается на его расследование, сбор улик, наказание виновных (вплоть до обращения в суд).
Управление инцидентами информационной безопасности, как правило, возлагается на службу поддержки, обрабатывающую инциденты ИТ (в том случае, если такая служба существует в компании). Это еще раз доказывает то, что целесообразно разработать одну систему управления всеми процессами в компании, так как управление схожими процессами в разных областях ее деятельности часто выполняется по одной схеме
Важно, чтобы ни один инцидент не остался незамеченным, было проведено расследование, выявлены виновные, и, самое главное, выполнены корректирующие и превентивные действия. Главной особенностью инцидентов в области информационной безопасности является то, что они не всегда заметны (не всегда мешают в работе пользователей), однако возможный ущерб от таких инцидентов сложно недооценить. Следовательно, необходима четкая процедура регистрации и расследования инцидентов безопасности, а также информирование пользователей о правилах определения инцидентов.
Необходимо понимать, что управление инцидентами не предупреждает нанесение ущерба компании (как правило, компания уже понесла ущерб, связанный с инцидентом), однако расследование инцидента и своевременное внедрение превентивных и корректирующих мер снижает вероятность его повторения (и, следовательно, вероятность повторения нанесения ущерба). Отметим также, что статистика инцидентов информационной безопасности представляет особую ценность для компании как показатель эффективности функционирования системы управления информационной безопасностью. Статистику инцидентов следует регулярно анализировать в рамках аудита системы управления информационной безопасностью.