Процедура обработки инцидентов (IRP - Incident Reporting Procedure) определяет способы реагирования на возникновение инцидентов, связанных с безопасностью. IRP определяет, кто имеет право доступа и что необходимо сделать, однако не всегда содержит описание конкретных действий.
Примечание
Если речь идет о банковской организации, название этой процедуры следует изменить (например, на "процедура обработки событий"). Термин "инцидент" имеет определенное значение в банковской сфере и необходимо избегать его использования, если событие не связано напрямую с финансовыми потерями.
Цели обработки инцидентов
Процедура IRP должна определять цели организации, достигаемые при обработке инцидента. Среди целей IRP можно выделить следующие: ◾защита систем организации; ◾защита данных организации; ◾восстановление операций; ◾пресечение деятельности злоумышленника; ◾снижения уровня антирекламы или ущерба, наносимого торговой марке.
Эти цели не являются взаимоисключающими, и в организации вполне могут быть определены несколько целей. Ключевым моментом является определение целей организации до того, как возникнет инцидент.
Идентификация событий
Идентификация инцидента является, вероятно, наиболее важной и сложной частью процедуры обработки инцидента. Некоторые события очевидны (например, несанкционированное изменение содержимого веб-сайта), другие же события могут означать либо вторжение, либо просто ошибку пользователя (например, удаление файлов).
Перед объявлением конкретного инцидента сотрудники отдела безопасности и системные администраторы должны провести небольшое исследование, чтобы определить, действительно ли инцидент имел место. В этой части процедуры могут быть выявлены события, представляющие собой очевидные инциденты, а также определены действия, которые необходимо предпринять, если событие не является очевидным инцидентом.
Совет
Оказать помощь в идентификации инцидентов может служба технической поддержки. Если ее сотрудники обучены задавать конкретные вопросы обращающимся к ним пользователям, то их можно использовать для формирования первичного представления о вероятном инциденте.
Эскалация
В IRP должна быть определена процедура эскалации данных по мере поступления информации о произошедшем событии. В большинстве организаций процедура эскалации предназначена для активизации действий группы сотрудников, которым поручена обработка инцидентов. В банковских структурах предусматривается два уровня эскалации, в зависимости от того, связано ли событие с финансовыми потерями.
В каждой организации должны быть определены сотрудники, являющиеся членами группы, ответственной за обработку инцидентов. Их следует выбирать из следующих подразделений организации: ◾отдел безопасности; ◾системные администраторы; ◾юридический отдел; ◾отдел кадров; ◾рекламный отдел.
По мере необходимости в группу могут быть добавлены и другие сотрудники.
Контроль информации
При обнаружении инцидента необходимо обеспечить контроль информации об инциденте. Количество получаемой информации зависит от того, какое влияние окажет инцидент на организацию и ее клиентскую базу. Кроме того, информацию следует оглашать таким образом, чтобы она положительно сказалась на делах организации.
Примечание
Только сотрудники отдела рекламы и юридического отдела могут обсуждать информацию об инциденте с представителями прессы, и никто более.
Обработка
Обработка инцидента напрямую вытекает из целей, определенных в IRP. Например, если целью данной процедуры является защита систем и информации, имеет смысл отключить системы от сети и провести необходимые восстановительные работы. В других случаях важнее сохранить систему в рабочем режиме и подключенном состоянии для продолжения обслуживания клиентов либо позволить злоумышленнику вернуться, чтобы собрать о нем больше данных и, возможно, идентифицировать.
В любом случае метод обработки, используемый организацией, должен обсуждаться и отрабатываться заблаговременно.
Примечание
Месть злоумышленнику никогда к добру не приводит. Такие ответные действия бывают незаконными - не делайте их никогда!
Полномочия
Важной частью IRP является определение того, кто в организации и в группе обработки инцидентов имеет полномочия на выполнение определенных действий. В этой части процедуры определяется, кто имеет полномочия на отключение системы и чьей обязанностью является контакт с клиентами, прессой и органами правопорядка. Назначается официальное лицо, которое будет заниматься именно этими вопросами. Обычно это сотрудник, входящий в группу обработки инцидентов либо внештатный консультант. В любом случае этот человек определяется в процессе разработки процедуры IRP, а не после проведенной атаки и не во время обработки инцидента. Документирование
Процедура IRP должна определять, каким образом группа обработки инцидентов будет фиксировать свои действия, включая описание данных, подлежащих сбору и сохранению. Этот момент важен по двум причинам: он помогает разобраться в последствиях инцидента и, возможно, предотвращает дальнейшие неприятности посредством привлечения органов правопорядка. Как правило, группе обработки инцидента полезно иметь набор переносных компьютеров для работы.
Тестирование процедуры
Обработка инцидентов требует тестирования. Не следует надеяться на то, что при первом запуске процедуры IRP все пройдет гладко. Сразу после разработки процедуры IRP группе обработки следует провести некоторые тесты. Необходимо проговорить ситуацию и попросить каждого члена группы обработки рассказать о действиях, которые необходимо предпринять в описанных обстоятельствах. Каждый член группы должен следовать предписаниям процедуры. С помощью этого подхода определяются очевидные недостатки процедуры с последующим их устранением.
Процедура IRP должна пройти тестирование в реальных условиях. Попросите сотрудника отдела безопасности смоделировать атаку на организацию, обработку которой произведет группа обработки инцидентов. Эти тесты могут быть как плановыми, так и внезапными.
Процедура управления конфигурацией
Процедура управления конфигурацией определяет шаги, предпринимаемые для изменения состояния компьютерных систем, сетевых устройств и программных компонентов. Целью данной процедуры является идентификация соответствующих изменений во избежание их ошибочного расценивания как инцидентов, связанных с нарушением безопасности, и для проверки новой конфигурации с точки зрения безопасности.
Начальное состояние системы
Когда новая система начинает работу, это состояние следует задокументировать. Как минимум, в этой документации необходимо указывать следующие параметры: ◾операционную систему и ее версию; ◾уровень обновления; ◾работающие приложения и их версии; ◾начальные конфигурации устройств, программные компоненты и приложения.
Кроме того, может понадобиться создать криптографические проверочные суммы для всех системных файлов и любых других файлов, которые не должны изменяться в процессе функционирования системы.
Процедура контроля над изменениями
Когда в систему необходимо внести изменения, следует выполнять процедуру контроля над конфигурацией. Эта процедура призвана обеспечить резервирование старых данных конфигурации и тестирование предлагаемых изменений перед их реализацией. В дополнение к этому в запросе об изменении следует отобразить процедуры изменения и отката изменений. После внесения изменения, конфигурацию системы нужно обновить для отражения нового состояния системы.
Методология разработки
В организациях, разрабатывающих новые системы, должна присутствовать методология разработки. Она включает множество шагов, которые не связаны с обеспечением безопасности и поэтому не будут здесь обсуждаться. Тем не менее, чем раньше в новом проекте будут рассмотрены вопросы безопасности, тем вероятнее, что конечная система будет должным образом защищена. Для каждой из фаз разработки, описанных в следующих разделах, мы обсудим вопросы безопасности, на которые следует обратить особое внимание.
Определение требований
Методология предусматривает учет требований безопасности в процессе сбора требований в любом проекте. Для некоторых требований методология должна ссылаться на политики информации и безопасности организации. Кроме того, в документе с требованиями необходимо определять секретную информацию и все ключевые требования безопасности для системы и проекта.
Разработка
В процессе разработки проекта методология предусматривает представление безопасности для обеспечения надежной защиты проекта. Сотрудники отдела безопасности могут участвовать в процессе в качестве членов группы разработки или рецензентов. Любые требования безопасности, которые не могут быть выполнены в процессе разработки, должны быть идентифицированы, при необходимости следует отказаться от защиты.
При программировании системы разработчики ПО должны быть осведомлены о проблемах программирования, таких как переполнение буфера. Перед тем как приступить к программированию, следует обучить персонал нужным аспектам компьютерной безопасности.
Тестирование
По достижении фазы тестирования необходимо осуществить проверку требований безопасности. Сотрудники отдела безопасности могут оказать помощь в написании плана тестирования. Имейте в виду, что тестирование требований безопасности зачастую оказывается сложным процессом (трудно доказать, например, что злоумышленник не сможет просматривать секретную информацию).
Примечание
Тестирование безопасности включает тесты, направленные на определение уровня защиты системы. Этот аспект можно выразить следующим вопросом: насколько вы уверены в том, что злоумышленник не сможет преодолеть средства контроля над безопасностью? Такое тестирование является очень дорогостоящим и отнимает много времени.
Реализация
Фаза реализации проекта также предусматривает требования безопасности. Группа реализации должна использовать нужные процедуры управления конфигурацией, а сотрудники отдела безопасности должны проверить систему на наличие уязвимостей и соответствие политике безопасности. Примечание
Методология разработки предназначена не только для внутренних разработок. Аналогичные шаги следует предпринимать и при работе с коммерческими проектами.
Планы восстановления после сбоев
В каждой организации должен быть предусмотрен план восстановления после сбоев (Disaster Recovery Planning - DRP) для выхода из таких экстремальных ситуаций, как пожары, атаки на переполнение буфера и другие события, выводящие систему из строя. Часто этот план отсутствует, так как считается слишком дорогостоящим, либо организация не может держать альтернативную базу для выполнения операций с оборудованием, находящимся в состоянии готовности. DRP не обязательно требует наличия запасного помещения, это план, которому будет следовать организация, в случае если произойдет наихудшее. Это может быть либо простой документ, предписывающий сбор ключевых сотрудников в соседнем ресторане в случае пожара в здании, либо достаточно сложный, определяющий порядок функционирования организации, в случае если все (или отдельные) компьютеры выйдут из строя.
Правильный план DRP должен учитывать различные уровни неполадок: отдельные системы, хранилища данных и помещения в целом. В следующих параграфах этот материал рассматривается более подробно.
Сбои отдельной системы или устройства
Наиболее часто происходит сбой отдельной системы или устройства. Такие сбои происходят в сетевых устройствах, жестких дисках, материнских платах, сетевых картах или программных компонентах. В рамках разработки данной части DRP необходимо проверить среду организации на предмет ее уязвимости в случае такого сбоя. Для каждого сбоя должен быть разработан план, позволяющий возобновить функционирование системы за приемлемый промежуток времени. Каким по длительности является этот "приемлемый" промежуток, зависит от важности рассматриваемой системы. Например, компьютерный узел, задействованный в производственном процессе и предназначенный для разработки графиков производства и оформления заказов на поставку сырья потребует восстановления в течение четырех часов, в противном случае производство остановится. Для предотвращения подобного сбоя требуется запасная система, которую можно оперативно подключить, либо кластеризация. Выбор метода зависит от стоимости решения. Независимо от того, какому решению отдается предпочтение, DRP указывает, что необходимо предпринять для продолжения работы системы без потерявших работоспособность компонентов.
Совет
План DRP должен разрабатываться совместно с функциональными подразделениями организации, чтобы их сотрудники имели понятие о том, какие шаги они должны предпринимать для продолжения нормальной работы.
События, связанные с хранением данных
План DRP должен предусматривать процедуры на случай серьезной неполадки центра хранения данных. Например, что делать в случае, если центр сгорел, как восстановить его работу? Одним из обязательных вопросов для рассмотрения является поломка оборудования. В плане должны быть предусмотрены способы подключения дополнительного оборудования.
На тот случай, если центр данных вышел из строя, а остальная часть системы функционирует нормально, план DRP должен предусматривать размещение нового оборудования, а также способы быстрого восстановления всех сетевых соединений. В данном случае можно использовать запасное помещение, однако этот способ является довольно дорогостоящим. Если наличие запасных помещений не входит в план, следует предусмотреть другие варианты восстановления компьютерных систем.
Как в случае с отдельными событиями, план DRP определяет порядок работы организация в процессе восстановления систем.
События, связанные с организацией в целом
Когда речь идет о плане DRP, обычно подразумеваются события, наносящие ущерб организации в целом. Такие события происходят не часто, но представляют наибольшую опасность. Чтобы предусмотреть в плане DRP подобные события, необходимо, чтобы каждое подразделение организации участвовало в создании этого плана. Первым шагом является выявление первоочередных систем, которые нужно восстановить для обеспечения жизнедеятельности организации. Если компания поддерживает сайт электронной коммерции, наиболее важными системами являются компьютеры и сеть. Если фирма выпускает продукцию, в первую очередь нужно восстанавливать производственное оборудование.
Тестирование DRP
План DRP - это сложный документ, и, скорее всего, вы не напишете его с первого раза. Следовательно, необходимо проводить тестирование DRP. Тестирование необходимо не только для обеспечения правильности DRP на данный момент времени, но и на будущее.
Проверка DRP может быть очень дорогостоящей операцией и привести к значительным финансовым затратам. Имея это в виду, целесообразно определить ответственных сотрудников и периодически выполнять проверку плана, а также ежегодное полномасштабное тестирование.
Создание политики
Теперь, после обсуждения всех политик, действующих в организации, давайте поговорим о создании политики, соответствующей вашей компании. Каждая компания работает по собственным правилам, следовательно, должна иметь собственную уникальную политику. Для обучения персонала разработке политики полезно использовать шаблоны политик. Однако повторение слово в слово политики другой организации не является хорошим способом создания политик.
Определение наиболее важных аспектов
Первым шагом при создании политики организации является определение наиболее важных политик. Например, компания, занимающаяся распространением информации через интернет, будет придавать большее значение плану восстановления в сравнении с политикой использования компьютеров. Сотрудники отдела безопасности организации должны выявить и описать все важнейшие политики, в противном случае необходимую информацию в этой области можно будет получить посредством оценки угроз.
Совет
Сотрудники отдела безопасности должны прибегать к помощи системных администраторов, отдела кадров и руководителей организации для определения наиболее важных политик.
Определение допустимого поведения
То, что называется допустимым поведением сотрудников, зависит от порядков, установленных в организации (культуры организации). Например, в некоторых компаниях сотрудникам разрешается неограниченно работать в интернете. Культура организации призвана обеспечить эффективность исполнения обязанностей сотрудниками и их начальниками. В других компаниях налагаются ограничения на выход сотрудников в интернет, кроме того, работают программы, ограничивающие доступ к определенным веб-сайтам.
Политики этих компаний значительно отличаются друг от друга. Действительно, сотрудники первой компании вовсе не применяют политику использования интернета. Специалисты в области информационной безопасности должны помнить, что не все политики подходят для использования. Перед началом создания политики необходимо внимательно изучить культуру организации и требования, предъявляемые к ее сотрудникам.
Определение руководителей
Политика, созданная в вакууме, редко является успешной. Имея это в виду, разработку политики должны проводить работники отдела безопасности при помощи других сотрудников организации. Отдел безопасности при разработке любых политик должен руководствоваться рекомендациями генерального директора организации и сотрудников отдела кадров. В процессе создания политик, как правило, участвуют системные администраторы, пользователи компьютеров и отдел охраны.
Другими словами, в разработке политики должны быть задействованы те лица, на которые данная политика будет распространяться, чтобы сотрудники понимали, чего ожидать в той или иной ситуации.
Определение схем политик
Разработка политики начинается с формирования схемы (одна схема уже была представлен в этой лекции). Существует множество источников качественных схем политик. Некоторые из них приведены в книгах, а некоторые доступны в интернете. Например, RFC 2196 "The Site Security Handbook" содержит перечень схем для различных политик. Разработка
При разработке политик безопасности необходимо, в первую очередь, руководствоваться вопросами безопасности. Это не означает, что отдел безопасности должен разрабатывать политики без участия других подразделений, но он должен взять на себя ответственность за проект и проконтролировать его завершение.
Процесс разработки политики следует начать со схемы и черновых набросков каждого раздела политики. В то же время следует проконсультироваться с руководителями организации и сообщить им о выполняемом проекте. Пригласите руководителей для участия в проекте. Тем из них, кто примет предложение, необходимо выслать черновой вариант политики и пригласить на собрание, на котором он будет обсуждаться и корректироваться. В зависимости от размеров организации и того, какая именно политика разрабатывается, могут рассматриваться несколько аспектов.
Руководить собранием должны сотрудники отдела безопасности. Следует проработать каждый раздел политики, выслушать все комментарии и все обсудить. Однако имейте в виду, что некоторые предложения бывают ошибочными. В этом случае сотрудники отдела безопасности должны объяснить причины того, что предлагаемые решения увеличат риск или не смогут быть правильно реализованы. Следите за тем, чтобы остальные слушатели понимали, о чем идет речь, и осознали причины выбора тех или иных решений.
Данный процесс имеет смысл повторить при работе с окончательным черновым вариантом. По завершении обсуждения проекта его следует отдать менеджерам для утверждения и реализации.
Развертывание политики
Чтобы создать политику, требуется несколько человек. Чтобы эффективно применить политику, необходимо работать со всей организацией в целом.
Понимание политики
Сотрудники каждого подразделения компании, на которое распространяется политика, должны вникнуть в ее суть. Это достигается довольно легко, так как в процессе создания политики участвуют все руководители отделов. Менеджерам отделов можно сообщить, кто из подразделений организации участвовал в процессе, голосуя за нужды своего отдела.
Также требуется согласие менеджеров с важностью политики и необходимостью ее применения. Вышестоящий менеджер зафиксирует тот факт, что политика важна для успешной и безопасной работы организации, и этим заявлением будут руководствоваться подчиненные ему менеджеры.
Обучение
Сотрудники, на которых распространяется новая политика, должны пройти обучение согласно доли своей ответственности. В обучении могут участвовать отдел кадров или учебный отдел, однако это задача отдела безопасности, в особенности когда речь идет об изменениях, которые распространяются на всех пользователей. Возьмем, к примеру, изменение политики использования паролей. По состоянию на утро понедельника все пароли пользователей должны быть длиной в восемь символов и содержать некоторый набор из букв и цифр, срок действия паролей равен 30 дням. При внесении подобного изменения в домене Windows все пароли немедленно становятся недействительными. Это вынудит каждого пользователя изменить свой пароль в понедельник утром. Без соответствующего инструктажа пользователи не смогут выбрать сильные пароли и, вероятно, начнут обращаться в службу технической поддержки. Если пользователи выберут пароли и не запомнят их, то на следующий день они опять будут звонить в службу поддержки или начнут записывать пароли на листочках. И то и другое ведет к снижению безопасности системы.
Лучше всего провести учебу по вопросам, связанным с безопасностью, и рассказать сотрудникам о вносимых изменениях и их причинах. Их можно научить, как выбирать надежные пароли, простые для запоминания. Службу поддержки следует проинформировать о возможных проблемах с паролями. Сотрудники отдела безопасности совместно с системными администраторами выяснят, возможно ли в данной ситуации провести смену паролей в несколько этапов.
Примечание
Изменения, вносимые в систему аутентификации, оказывают влияние на максимально возможное число сотрудников (на всех!) и, следовательно, должны проводиться с осторожностью.
Реализация
Как показано в предыдущем разделе, радикальные изменения в среде безопасности могут плохо повлиять на безопасность организации. Постепенный и тщательно спланированный переход всегда более предпочтителен. Имея это в виду, отдел безопасности должен совместно с системными администраторами или другими подразделениями, на которые распространяется изменение, максимально упростить это изменение. Помните, что безопасность уже рассматривалась как препятствие для работы, доказывать эту мысль сотрудникам уже не требуется. Эффективное использование политики
Политика может работать как полицейская дубинка, но она более эффективна, когда используется в качестве средства обучения. Имейте в виду, что большинство сотрудников работают, в первую очередь, в интересах организации и стараются выполнять свои обязанности по возможности лучше.
Новые системы и проекты
При запуске новых систем и проектов должны соблюдаться имеющиеся политики безопасности и процедуры разработки. Это позволяет отделу безопасности быть участником разработки проекта и на ранней стадии процесса определить требования безопасности.
Если новая система не сможет отвечать требованиям безопасности, то у компании будет время, чтобы понять суть представляемой опасности и обеспечить другой механизм защиты.
Имеющиеся системы и проекты
По мере утверждения новых политик каждая система должна проверяться на соответствие утверждаемым политикам. Отдел безопасности совместно с системными администраторами и подразделением, использующим систему, должен внести в системы соответствующие коррективы. Иногда эти коррективы требуют перепрограммирования каких-либо модулей, которое не может быть выполнено мгновенно. Отдел безопасности в этом случае должен осознать, что функционирование организации может быть прервано на некоторое время, и совместно с администраторами и другими подразделениями приложить все усилия для обеспечения скорейшего внесения изменений в рамках бюджета и структурных ограничений системы.
Аудит
Во многих организациях имеются внутренние отделы аудита, которые периодически осуществляют аудит систем на соответствие политике. Отдел безопасности должен ознакомить сотрудников этого отдела с новыми политиками и поработать некоторое время вместе, чтобы аудиторы вникли в суть политики, прежде чем будут проверять системы на соответствие.
Обмен информацией должен быть двусторонним. Отдел безопасности должен объяснить аудиторам, как была разработана политика и что ожидается от политики с точки зрения безопасности. Аудиторы должны объяснить специалистам по безопасности, каким образом будет проводиться аудит и на поиск чего он будет нацелен. Необходимо разработать соглашение о том, какие типы систем являются адекватными для различных разделов политики. Проверка политики
Даже качественно разработанная политика не вечна. Каждая политика должна регулярно проверяться на соответствие требованиям организации. В большинстве случаев достаточно проводить такую проверку раз в год. Некоторые процедуры, например процесс обработки инцидентов или план восстановления после сбоев, требуют более частых проверок.
В процессе проверки необходимо связаться со всеми руководителями и подразделениями, которые не участвовали в разработке политики. Попросите каждого сотрудника прокомментировать имеющуюся политику. Возможно, имеет смысл устроить общее собрание, если имеются какие-либо важные комментарии (например, комментарии сотрудников из отдела безопасности). Внесите корректировки в политику, получите подтверждение и возобновите процесс обучения.
