COBIT 5 for Risk: основные области ИТ-рисков

Risk-Scenarios-Using-COBIT-CoverМы уже писали о публикации Risk Scenarios using COBIT5 for Risk. Кроме того, ей был посвящен недавно прошедший вебинар CleverTALK. В этой заметке хочу подвести краткие итоги того, какие области рисков в ИТ, по мнению авторов, являются наиболее критичными и нуждаются в пристальном внимании. Несмотря на то, что публикация содержит лишь примеры, так называемых, сценариев и не является исчерпывающим перечнем ИТ-рисков, выводы о том, где висят грозовые тучи, сделать можно и, на мой взгляд, весьма любопытные.

Большое внимание авторы COBIT5 for Risk уделяют инсайдерской угрозе. Собственные сотрудники могут нарушать работу процессов, модифицировать клиентскую информацию, проводить фиктивные транзакции в финансовых системах, проводить несанкционированные изменения или, например, вступая в сговор, способствовать утечкам конфиденциальной информации за пределы компании. Реализацию этой угрозы делают возможной, в первую очередь, ошибки в разграничении доступа. Важные контроли – разделение полномочий, практики управления доступом и работа с персоналом.

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

Кроме того, человеческий фактор может проявляться в ошибках при исполнении стандартных операций, вроде установки обновлений или бэкапирования, что при определенных обстоятельствах может приводить к потере данных и/или прерываниям ИТ-услуг.

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

Основные риски в части ПО – несанкционированные изменения. Практики по управлению доступом и управлению изменениями снимут вопрос с повестки. Еще одна болевая точка – ненадлежащий уровень тестирования (отсутствие сред, моделей и сценариев тестирования), а как следствие с высокой вероятностью инциденты в продуктиве.  

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

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

В этой заметке я постарался выделить только самое важное. Всего же в Risk Scenarios using COBIT 5 for Risk достаточно подробно описаны 60 сценариев, большинство которых кажутся довольно релевантными и нашим реалиям. 

*Нужно отметить, что в COBIT5 for Risk ИТ-риск определен как бизнес-риск, связанный с приобретением, адаптацией, использованием, владением, функционированием и эксплуатацией ИТ в организации.

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

COBIT Основы COBIT 5

Подробный трёхдневный учебный курс.
 

Узнайте больше!

Комментарии и мнения

  1. Андрей

    Соглашусь с тем, что нибольшую реальную урозу представляют собственные сотрудники. Максимум, что может сделать внешний хакер, без инсайдерской поддержки — положить вашу систему. А вот чтобы украсть тем или иным способом денежные средства компании, внешнему хакеру обязательно нужен внутренний помпшник, который знает, как работают системы. Но по сути тут нет ничего нового. Это те же преступления (воровство, подлог, причинение вреда и т.д.), только выполненые новыми технологическим способами. И принцип борьбы с этими преступлениями тот же — неотвратимость наказания. Как правило у сотрудника достаточно обоснованных прав, чтобы не только выполнять свои прямые служебные обязанности, но сделать что-то не предусмотренное регламентом. И единственно, что его может остановить — осознание того, что его найдут и накажут. Основной инструмент — агентурная сеть, в ИТ мире это сбор журнальных записей с дальнейшим анализом действий сотрудников, представленных в логах учетными записями, на соответствие моделям нарушителя. Но все это работает только в том случае, если в компании внедрена нормальная система управления учетными записями.

    1. Андрей Яковлев

      Есть стандаты  ISO2700x последние версии 2013, посвященные ИБ, там класный принцип: оцениваем свои информационные активы, оцениваем риски, принимаем решение что с каким риском делать. Есть там хитрое противоречие — с одной стороны, я могу проигноривать какие-то риски, ан сертификат скорее все потребует исполнение всех  требований, в самом начале я могу забить на риск, так как любая политика по снижению рисков — затратна. Стандарты для сертификации 27001 и 27002, первый — описание, второй  - методичка. Вообще сертификат — дорогое удовольствие, он на площадку , так как  там требования к физзащите и СКУД. Это я к чему, велосипед зачем изобретать? Стандарт лучше прочитать, выбрать только нужные разделы и их применить, сколько не пытаюсь объяснить, что стандарт хорошо продуман и выглядит логичным, сертификат мало кому нужен да и дороговат.  А вот разумная политика. Но про ИТ политики я молчу. 

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Empty