Данная процедура является необходимым средством безопасности для большинства организаций. Организация особенно уязвима, когда обнаруживается вторжение в ее сеть или когда она сталкивается со стихийным бедствием. Нетрудно представить, что произойдет в последующие минуты и часы, если интеллектуальная собственность компании составляет миллионы или миллиарды долларов.
Процедуру реагирования на события иногда называют процедурой обработки событий или процедурой реагирования на инциденты. Практически невозможно указать отклики на все события нарушений безопасности, но нужно стремиться охватить основные типы нарушений, которые могут произойти.
Вот некоторые примеры нарушений безопасности: сканирование портов сети, атака типа «отказ в обслуживании», компрометация хоста, несанкционированный доступ и др.
Данная процедура определяет:
· каковы обязанности членов команды реагирования;
· какую информацию следует регистрировать и прослеживать;
· как обрабатывать исследование отклонений от нормы и атаки вторжения;
· кого уведомлять и когда;
· кто может выпускать в свет информацию и какова процедура ее выпуска;
· как должен выполняться последующий анализ и кто будет в этом участвовать.
В команду реагирования могут быть включены должностные лица компании, менеджер отдела маркетинга (для связи с прессой), системный и сетевой администраторы и представитель соответствующих правоохранительных органов. Процедура должна указать, когда и в каком порядке они вызываются.
Процедура управления конфигурацией. Процедура управления конфигурацией обычно определяется на корпоративном уровне или уровне подразделения. Эта процедура должна определить процесс документирования и запроса изменений конфигурации на всех уровнях принятия решений. В принципе, должна существовать центральная группа, которая рассматривает все запросы на изменения конфигурации и принимает необходимые решения.
Процедура управления конфигурацией определяет:
· кто имеет полномочия выполнять изменения конфигурации аппаратного и программного обеспечения;
· как тестируется и инсталлируется новое аппаратное и программное обеспечение;
· как документируются изменения в аппаратном и программном обеспечении;
· кто должен быть проинформирован, когда вносятся изменения в аппаратном и программном обеспечении.
Процесс управления конфигурацией важен по нескольким причинам:
· он документирует внесенные изменения и обеспечивает возможность аудита;
· он документирует возможный простой системы;
· он дает способ координировать изменения так, чтобы одно изменение не помешало другому.
1.2.4 Разработка политики безопасности организации
Разработка политики безопасности является ключевым этапом построения защищенной информационной системы или сети. Следует отметить, что составление политики безопасности или политик является только началом осуществления общей программы обеспечения безопасности организации. Детальная программа обеспечения безопасности необходима для создания эффективной системы безопасности организации на основе разработанной политики безопасности.
Ниже перечислены основные этапы определения ценности технологических и информационных активов организации:
· оценка рисков этих активов (сначала путем идентификации тех угроз, для которых каждый актив является целевым объектом, а затем оценкой вероятности того, что эти угрозы будут реализованы на практике);
· установление уровня безопасности, определяющего защиту каждого актива, то есть мер безопасности, которые можно считать рентабельными для применения;
· формирование на базе предыдущих этапов политики безопасности организации;
· привлечение необходимых финансовых ресурсов для реализации политики безопасности, приобретение и установка требуемых средств безопасности;
· проведение разъяснительных мероприятий и обучения персонала для поддержки сотрудниками и руководством требуемых мер безопасности;
· регулярный контроль пошаговой реализации плана безопасности с целью выявления текущих проблем, учета изменения внешнего окружения и внесение необходимых изменений в состав персонала.
Опыт показал, что в целом организации получают существенную выгоду от реализации хорошо разработанной методологии решения указанных выше задач.
К политикам безопасности предъявляются следующие основные требования. Политики безопасности должны:
· указывать цели и причины, по которым нужна политика;
· описывать, что именно охватывается этими политиками:
· определить роли, обязанности и контакты;
· определить, как будут обрабатываться нарушения безопасности.
Политики безопасности должны быть:
· реальными и осуществимыми;
· краткими и доступными для понимания;
· сбалансированными по защите и производительности.
Первыми шагами по разработке политики безопасности являются следующие:
· создание команды по разработке политики;
· принятие решения об области действия и целях политики;
· принятие решения об особенностях разрабатываемой политики;
· определение лица или органа для работы в качестве официального интерпретатора политики.
Ко всем разрабатываемым политикам безопасности целесообразно применять унифицированный процесс проектирования с единообразными требованиями к политикам.
Одним из первых шагов является создание команды по разработке политики безопасности организации. Иногда эту команду называют группой, комиссией или комитетом. Команда создается руководством организации, которое должно осознавать важность информационной безопасности и полностью реализовать свою позитивную роль в успешной разработке, принятии и внедрении этой политики.
В состав команды следует включать квалифицированных специалистов, хорошо разбирающихся в требованиях бизнеса, информационных технологиях и безопасности, юриста и члена руководства, который сможет проводить в жизнь эту политику безопасности. К работе этой команды должны быть также привлечены администраторы безопасности и системные администраторы, представитель от сообщества пользователей.
Размер команды по разработке политики зависит от масштаба и области действия политики. Крупномасштабные политики могут потребовать команды из 5-10 человек, в то время как политики небольшого масштаба могут потребовать только одного или двух человек.
Как только создана такая команда, ее первым шагом является анализ требований бизнеса. Члены команды с различными позициями и точками зрения должны проанализировать требования бизнеса к использованию компьютерных и сетевых сервисов. Когда мнения некоторых членов этой команды не совпадают, столкновения их интересов и пересечения разных отраслей знания при обсуждении требований бизнеса позволяют получить более полную и объективную картину, чем при обычном опросе людей, работающих в области маркетинга, продаж или разработки.
На этом этапе анализируются и решаются следующие вопросы: какие компьютерные и сетевые сервисы требуются для бизнеса и как эти требования могут быть удовлетворены при условии обеспечения безопасности? Сколько сотрудников зависит от доступа в Интернет, использования электронной почты и доступности интранет-сервисов? Зависят ли компьютерные и сетевые сервисы от удаленного доступа к внутренней сети? Имеются ли требования по доступу к веб? Требуются ли клиентам данные технической поддержки через Интернет? При анализе каждого сервиса следует обязательно спрашивать: «Имеется ли требование бизнеса на этот сервис?» Это самый важный вопрос.
После анализа и систематизации требований бизнеса команда по разработке политики безопасности переходит к анализу и оценке рисков. Использование информационных систем и сетей связано с определенной совокупностью рисков. Анализ рисков является важнейшим этапом формирования политики безопасности (рис. 2.2).
Рис. 2.2. Схема разработки политики безопасности
Иногда этот этап называют также анализом уязвимостей или оценкой угроз. Хотя эти термины имеют несколько различающиеся толкования, конечные результаты сходны.
На этапе анализа рисков осуществляются следующие действия:
· идентификация и оценка стоимости технологических и информационных активов;
· анализ тех угроз, для которых данный актив является целевым объектом;
· оценка вероятности того, что угроза будет реализована на
· практике;
· оценка рисков этих активов.
Оценка риска выявляет как наиболее ценные, так и наиболее уязвимые активы, она позволяет точно установить, на какие проблемы нужно обратить особое внимание. Отчет об оценке рисков является ценным инструментом при формировании политики сетевой безопасности.
После оценки рисков активов можно переходить к установлению уровня безопасности, определяющего защиту каждого актива, то есть мер безопасности, которые можно считать рентабельными для применения.
В принципе, стоимость защиты конкретного актива не должна превышать стоимости самого актива. Необходимо составить подробный перечень всех активов, который включает такие материальные объекты, как серверы и рабочие станции, и такие нематериальные объекты, как данные и программное обеспечение. Должны быть идентифицированы директории, которые содержат конфиденциальные файлы или файлы целевого назначения. После идентификации этих активов должно быть проведено определение стоимости замены каждого актива с целью назначения приоритетов в перечне активов.
Для контроля эффективности деятельности в области безопасности и для учета изменений обстановки необходима регулярная переоценка рисков.
После проведения описанной выше работы можно переходить к непосредственному составлению политики безопасности. В политике безопасности организации должны быть определены используемые стандарты, правила и процессы безопасности.
Стандарты указывают, каким критериям должно следовать управление безопасностью. Правила подробно описывают принципы и способы управления безопасностью. Процессы должны осуществлять точную реализацию правил в соответствии с принятыми стандартами.
Кроме того, политика безопасности должна определить значимые для безопасности роли и указать ответственности этих ролей. Роли устанавливаются во время формирования процессов.
Обычно процесс состоит из одного или более действий, где каждое действие включает четыре компонента (рис. 2.3):
1. Вход, например запрос пользователем нового пароля.
2. Механизм, который реализует данное действие и указывает средства или роли, с помощью которых это действие выполняется. Другими словами, он определяет, какие роли вовлечены в это конкретное действие. В нашем примере такими ролями являются пользователь, запрашивающий новый пароль, и администратор безопасности.
3. Управление - описывает алгоритм или условия, которые управляют этим действием. Например, стандарт может задать следующее условие: при запросе нового пароля инициатор запроса должен успешно пройти аутентификацию.
4. Выход - является результатом этого действия. В нашем примере таким выходом является сообщение пользователю нового пароля.
Рис. 2.3. Графическое представление действия в рамках процесса
Связывая вместе все действия, входящие в процесс, мы получаем точное представление результирующего процесса и ролей, необходимых для его исполнения. В данном примере процесс состоит из одного действия - обновления пароля пользователя; роли идентифицируются как Пользователь и Администратор безопасности. Стандарты, правила и процессы должны быть документированы в рамках политики для целей аудита.