18 Бумажная работа

В наше время достаточно сложно найти специалиста в области ИТ, который любил бы бумажную работу, однако, как говорится, порядок должен быть!

Начнем с того, что когда вам доведется проводить аудит ИС согласно модели «белого ящика», вы будете просто обязаны попросить документацию. Хороший специалист всегда попросит документацию к системе, но только лучший ознакомится со всей документацией предприятия, имеющей отношение к данной ИС и не выходящей за рамки его компетенции. Тут мы имеем в виду, что требовать документы из бухгалтерии вряд ли будет хорошей идеей. Для этого есть другие аудиторы, не будем отбирать у них хлеб.

Рассмотрим основные причины не пренебрегать столь важным, хотя и, на наш взгляд, несколько скучным занятием.

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

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

Третья причина касается вашего взаимодействия с коллегами. Обычно работники ИТ-сферы — люди умные и привыкли делить между собой ответственность за различные ИС. В этом есть огромный плюс — когда человек не распыляется на множество систем, он начинает работать лучше и эффективнее. Однако есть

230    Глава 18  •  Бумажная работа

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

истоять отдельно.

Четвертая причина касается больше работы самого предприятия. Хотя специалистами по ИБ и не разбрасываются, однако текучесть кадров никто не отменял. Для предприятия будет большим риском передавать системы в управление новому сотруднику без наличия должной документации.

Всегда следует помнить о том, что управление документацией — это процесс. Современные реалии, особенно в мире ИБ, меняются очень стремительно, что требует постоянного пересмотра и корректировки различных пунктов нормативных документов.

Теперь, ощутив важность наличия документации как таковой, рассмотрим основные типы документов и коротко коснемся их содержания.

Политика безопасности

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

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

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

Стандарты    231

Теперь коснемся содержания данного документа. Следует понимать, что политика безопасности создается прежде всего для пользователей и руководства компании и только потом для ИТ-сотрудников. Это, в свою очередь, означает, что она должна быть как можно более краткой и понятной. Следует избегать упоминания конкретных технологий или ПО, сложных для понимания непрофессионалами формулировок и перегрузки терминологией. Однако в случаях, когда без технических терминов не обойтись, обязательно нужно их разъяснить. Если политика не будет соответствовать этим критериям, ее попросту никто не будет читать. А ведь мы хотим создать настоящую работающую безопасность, а не формально соответствующую заданным критериям.

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

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

Необходимо учесть, что политика должна быть реальной и исполняемой. А это значит, что придется соблюдать баланс между удобством использования ИС и их безопасностью.

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

Каждый сотрудник, имеющий доступ к ИС организации, должен ознакомиться с данным документом.

Стандарты

Согласно Википедии, стандарт в широком смысле слова — это образец, эталон, модель, принимаемые за исходные для сопоставления с ними других подобных объектов.

Стандарты являются документами более низкого уровня по отношению к политике безопасности и предназначены для более узкой аудитории, в основном для ИТ-специалистов.

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

232    Глава 18  •  Бумажная работа

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

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

Впротивном случае вы столкнетесь с тем, что хотя документ и принят, но по факту никем не исполняется.

Вконтексте данного раздела рекомендуем ознакомиться с такими стандартами, как:

ISO/IEC 17799:2002 — один из самых известных стандартов, он создан на основе BSI и рассматривает практические вопросы по управлению информационной безопасностью;

BSI — стандарт разработан в Германии и посвящен, в отличие от предыдущего, подробному освещению более частных вопросов;

ISO 15408 — стандарт создан на основе опыта коллег из США и Канады, описывает общие критерии безопасности информационных технологий.

Безусловно, это не полный список, а всего лишь отправная точка для дальнейших исследований.

Процедуры

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

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

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

Вслучае, если пользователю требуются расширенные права доступа, для их присвоения необходима отдельная процедура.