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

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

Определите, какие правила необходимо разработать

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

Сколько различных правил безопасности необходимо разработать? Не хотелось бы отвечать вопросом на вопрос, но, тем не менее, сколько различных видов деятельности и задач поставлено перед вами вашим бизнесом? Для каждой системы, обеспечивающей ваш бизнес, и каждой подзадачи, на которые может быть разбита глобальная цель вашего бизнеса, необходимо разработать отдельный документ. Абсолютно нормально разрабатывать антивирусную защиту отдельно от правил использования Internet. Общепринятая ошибка заключается в попытках втиснуть описание политики безопасности в один документ, который обрисовывает только общие принципы. В результате появляется обширный документ, с которым очень трудно работать, который, возможно, никогда не будет прочитан и не получит никакой поддержки. На рис. 1.1 представлен примерный перечень разрабатываемых правил информационной безопасности.

Рис. 1.1. Примерный список систем, поддерживающих бизнес, для которых разрабатываются правила безопасности

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

Оценка риска/Анализ или аудит

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

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

Некоторые администраторы полагают, что они могли бы исследовать систему, определить степень риска и провести инвентаризацию предприятия сами, без посторонней помощи. Несмотря на то. что они, возможно, и могли бы выполнить соответствующую работу всегда лучше пригласить для этого кого-то со стороны. Главная причина заключается в том, что люди извне не знают систему, излюбленных приемов работы и другой информации, которая могла бы подтолкнуть их к предвзятому мнению. Сторонний представитель может прийти в компанию и исследовать системы глазами хакеров. Здесь мы видим широкое поле для творчества. Давайте посмотрим, какая будет от этого польза? Сторонние представители могут выявить уязвимые места, слабости защиты и другие проблемы, которые следует учесть при разработке правил информационной безопасности.

Почему нужно нанимать людей со стороны для оценки степени риска?
Некоторые полагают, что сделать оценку степени риска могут их собственные профессионалы в области систем и защиты информации. Позволим себе не согласиться с этим мнением. Несмотря на то, что люди, работающие в компании, могут быть весьма компетентными, они слишком близко знакомы с технологическим процессом, чтобы суметь отличить технический риск от технологического. Люди извне не обладают такой информацией, поэтому они не будут предвзято утверждать, мол "так должно быть — и точка".
При выборе внешней компании для оценки степени риска, нужно быть уверенным, что ее представители обладают самой последней информацией в сфере защиты и достаточно оснащены технически, чтобы суметь сделать полную оценку степени риска. Они должны понимать, что риски касаются всех аспектов информационной технологии. Поскольку специализированные компании делают это ежедневно, они лучше понимают, какой результат следует ожидать при выполнении своих тестов. Эта объективная точка зрения будет неоценимой для формирования политики безопасности компании.

Критическая оценка, утверждение и претворение в жизнь

Любой корпоративный документ обычно подвергается критической оценке. Правила информационной безопасности - это документы различные по содержанию. В процессе рецензирования должны рассматриваться не только технические аспекты безопасности, но и юридические аспекты, поскольку это имеет непосредственное отношение к организации. До начала разработки правил любого уровня должно быть проведено детальное обследование объекта. Понятно, что предварительное обследование должно быть выполнено разработчиками правил безопасности, и лишь после этого должно выполняться обследование на более низких уровнях. Если в компании есть СIO (Chief Information Officer — руководитель информационной службы компании), то он должен быть в составе комиссии по обследованию объекта. Руководители департаментов или руководители отделов, которые будут иметь непосредственное отношение к разработке правил, также могут участвовать в рецензировании и делать комментарии. И. наконец, поскольку неразбериха в делах никому не нравится, юристы корпорации также должны принимать в этом участие. Юристы понимают раздел правил безопасности, касающийся правоприменения, и знают, каким образом придать правилам законною силу.

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

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