Информационная безопасность в свете ITIL

Библиотека стандартов ITIL сегодня очень популярна в ИТ-индустрии и широко используется в больших компаниях. Однако, традиционно ITIL воспринимается как best practice проектирования различных сервисов и ИТ-инфраструктуры компании. Но на ITIL можно обратить внимание и с точки зрения информационной безопасности. Ведь в требованиях к проектированию ИТ-инфраструктуры предъявляется и  обязательное обеспечение конфиденциальности информации.  Отчасти сюда же можно отнести и отказоустойчивость, как элемент свойства доступности информации.

В сегодняшней публикации мы совсем кратко коснемся вопросов рассмотрения ИБ в свете библиотеки стандартов ITIL

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

Введение в ITIL

В первую очередь необходимо разобраться, что представляет собой библиотека ITIL и как она связана с безопасностью. Итак, библиотека ITIL (IT Infrastructure Library) была разработана около 20 лет назад Центральным агентством по вычислительной технике и телекоммуникациям (Central Computer and Telecommunications Agency, CCTA) в Великобритании. Перед CCTA стояла задача структурирования всех существующих методов успешного использования IT-ресурсов и разработки способов их качественного применения. Таким образом, библиотека ITIL призвана оптимизировать набор процессов, направленных на обеспечение высокого качества IT-услуг и повышение уровня предоставляемых услуг. Результатом применения ITIL в организации должно стать повышение конкурентоспособности компании в целом.

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

Особо отметим, что библиотека ITIL содержит отдельную книгу по управлению IT-безопасностью, которая называется Security Management. Она помогает гармонично интегрировать процесс управления IT-безопасностью в общую систему управления информационными технологиями в компании.

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

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

Согласно ITIL, процесс обеспечения IT-безопасности состоит из нескольких этапов (см. рисунок).

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

Первые шаги нового стандарта

На нулевом шаге процесса задача поставщика заключается в том, чтобы обеспечить заказчику базовый уровень IT-безопасности. Здесь сразу же следует заметить, что в качестве поставщика и заказчика необязательно выступают различные организации, скажем консалтинговая фирма и коммерческая компания. Напротив, библиотека ITIL позволяет оптимизировать IT-процессы даже в рамках одной организации. Так, заказчиком может стать отдел маркетинга или продаж, а поставщиком — IT-департамент или служба IT-безопасности.

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

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

Далее IT-департамент проводит комплексный анализ всех требований заказчика и определяет возможность реализации их на практике (согласование сроков, соответствие выделенного бюджета намечаемой работе, обеспечение необходимого уровня IT-безопасности и т.п.). Если IT-департамент решает, что предпочтения заказчика по каким-то причинам не могут быть выполнены, например из-за несогласованности требований с бюджетом или же с базовым уровнем безопасности, то весь процесс возвращается на шаг назад. Представитель IT-департамента еще раз встречается с заказчиком, чтобы предоставить анализ требований, высказать пожелания и прийти к взаимовыгодному соглашению. На данном этапе все зависит от навыков ведения переговоров у представителя поставщика. От того, сумеет ли он доказать заказчику, что первоначальные требования не принесут ожидаемых результатов и что для эффективной безопасности необходимо выделить дополнительные средства, зависят условия дальнейшего сотрудничества.

Процесс обеспечения IT-безопасности в рамках ITIL

SLA — сердце ITIL

Придя к консенсусу, поставщик и заказчик фиксируют свои договоренности в разделе о безопасности документа SLA (Service Level Agreement) — соглашении об уровне услуг, по сути являющемся основой взаимодействия между заказчиком и поставщиком. В SLA определяется степень ответственности обеих сторон, причем все условия оговариваются в нетехнических терминах, на уровне понимания заказчика.

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

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

Внедрение SLA: неочевидные проблемы

Политика IT-безопасности компании и существующая система управления IT-безопасностью в организации — вот базис, на котором строится вся защита. А что делать, если политика расходится с основными необходимыми требованиями IT-безопасности, то есть грубо нарушается базовый уровень? Например, сотрудники компании никогда не создавали учетные записи. Они уверены, что запоминание паролей, трата времени на авторизацию — занятие бессмысленное. Заказчик IT-услуг не хочет менять сложившиеся традиции в компании и категорически отказывается вводить пароли, потому что не видит в них особого смысла. Конечно, такой пример может показаться тривиальным, но на практике требования заказчика зачастую бывают еще более абсурдными.

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

Этап конкретизации в SLA

После того как политика IT-безопасности приведена в соответствие с базовым уровнем, стороны переходят к согласованию конкретных действий по реализации требуемого уровня IT-безопасности.

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

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

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

После того как общие принципы «защиты от дурака» определены и основные роли пользователей назначены, заказчик и поставщик IT-услуг согласовывают технические средства для обеспечения IT-безопасности: оговаривают средства шифрования информации, методы разграничения доступа и т.д. В принципе, особо важная и сверхсекретная информация может нуждаться в физической защите и физическом наблюдении. Если требуется организовать видеонаблюдение или предоставить охрану, заказчик и поставщик должны оговорить данный вопрос отдельно. Каждому разделу SLA назначаются ответственные люди, которые осуществляют контроль своих направлений. Кроме того, указываются отчетный период и форма отчетности.

В SLA заказчик и поставщик IT-услуг оговаривают так называемые форс-мажорные обстоятельства. Для обеспечения непрерывности бизнеса определяются стратегически важные объекты, возможность их восстановления и альтернативные способы работы в случае критичных сбоев. Подробное описание данного раздела одинаково важно как для бизнеса заказчика, так и для поставщика (будь он консалтинговой компанией или внутренним IT-департаментом). Бизнес в лице заказчика стремится обеспечить конкурентное преимущество на рынке за счет непрерывности бизнес-процессов. Поставщик IT-услуг, в свою очередь, заинтересован в обеспечении максимальной надежности предоставляемых им услуг. Однако все непредвиденные обстоятельства учесть невозможно, да и особого смысла в этом нет. Какова, например, вероятность землетрясения в Центральном федеральном округе? Она практически равна нулю. Поэтому включать эту угрозу в план по обеспечению непрерывности работы бизнеса в случае землетрясения нецелесообразно. Таким образом, важно соблюдать баланс и руководствоваться правилами логики и здравого смысла. 

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

Операционное соглашение об уровне услуг (OLA)

Зафиксировав все договоренности в SLA, поставщик заключает операционное соглашение об уровне услуг (Operating Level Agreement, OLA) с исполнителями, которые прописаны в SLA как ответственные за то или иное направление. Непосредственными исполнителями могут выступать внутреннее IT-подразделение компании (тогда OLA заключается с представителем IT-департамента), сам поставщик, а также любая сторонняя компания. 

В OLA поставщик IT-услуг и исполнитель конкретизируют договоренности о том, как именно будет достигнут необходимый уровень сервиса. Например, если в SLA зафиксировано, что некоторый особо важный объект должен быть обеспечен физической защитой, в OLA оговариваются детали защиты: скрытое наблюдение, охрана, ограничение доступа и т.п.

В частности, в рамках OLA происходит определение, разработка и формулирование внутренних требований безопасности для IT-услуг. Кроме того, исполнитель отвечает за мониторинг стандартов безопасности. Если стандарты безопасности поменялись, исполнитель должен сообщить об этом поставщику. Поставщик IT-услуг, в свою очередь, встречается с заказчиком и предлагает внести определенные изменения в SLA согласно новому стандарту.  

В OLA поставщик IT-услуг и исполнитель фиксируют роли, задействованные в выполнении OLA, а также определяют ответственных на более низком уровне.  

Этапы реализации

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

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

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

Заключение

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

Библиотека ITIL предоставляет возможность IT-специалистам изучить лучшие примеры из практики по оптимизации работы IT-услуг, чтобы разработать свой, уникальный метод повышения качества IT-услуг. Другими словами, на практике следует использовать ITIL, чтобы адаптировать IT-услуги наилучшим образом для достижения целей бизнеса и ожиданиям заказчика. Такие гранды, как Microsoft, IBM и Hewlett-Packard, уже внедрили ITIL, создав тем самым для себя дополнительные конкурентные преимущества.

За материалы спасибо Compress