• улучшение производительности систем, процессов инцидент-менеджмента и непрерывности бизнеса повышает предсказуемость и надежность процессов организации, то есть устойчивость и выживаемость организации.;

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

1.6. ПОДВОДЯ ИТОГИ

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

ПРИЛОЖЕНИЕ 1.1. ПРИМЕРЫ НЕДОСТАТОЧНОГО

ВНИМАНИЯ К УПРАВЛЕНИЮ РИСКОМ ИТ

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

Пример 1

Россия. Компания – разработчик технического и промышленного оборудования. В компании проводился регулярный аудит финансовой отчетности, в рамках которого независимый аудитор должен оценить влияние ряда рисков, присущих ИТ, на надежность процесса формирования финансовой отчетности и на достоверность самой отчетности8. В какой-то момент на протяжении финансового года возникла угроза заражения систем компании вирусом-шифровальщиком PETYA (если интересно, в сети Интернет вы можете найти более детальную информацию о «вирусе»). При этом менеджмент компании регулярно игнорировал отчеты аудитора о недостатках в области управления рисками ИТ. Вирус проник в системы компании и заразил (зашифровал) больше половины всех систем компании, в том числе системы резервного копирования и часть ключевых систем, участвующих в процессе формирования финансовой отчетности.

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

• наличие антивирусного ПО и его своевременное и регулярное обновление;

• наличие своевременного и регулярного процесса установки обновлений и критических «заплаток» для систем компании;

• наличие процесса информирования и обучения пользователей основам информационной безопасности;

• наличие эффективно защищенного хранилища резервных копий с ключевой, значимой для компании информацией.

Пример 2

США. Крупная розничная торговая сеть.

На момент описываемого события компания обладала сетью из порядка 800 магазинов в разных штатах США. В каждом магазине были установлены POS9-терминалы и два POS-сервера, ежедневно собирающие информацию о продажах магазинов. Так как магазинов много, то система POS как для терминалов, так и для серверов настраивалась централизованно в главном офисе. После того как новая версия системы была готова, специалисты устанавливали ее во все магазины либо удаленно, либо с физического носителя.

Потенциальная проблема возникла в момент, когда в результате аудита выяснилось, что в образе (образ – готовая, настроенная для установки POS-система на диске) обнаружились учетные записи администраторов, уволенных либо переведенных на другие должности несколько лет назад, еще до аудита.

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

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

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

• сократить количество предустановленных учетных записей до необходимого минимума и регулярно проверять их актуальность каждый раз, когда проводилась установка новых или обновление существующих систем;

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

Пример 3

Европа. Крупнейший производитель пива.

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

После анализа собранной информации оказалось, что у команды подрядчика, который осуществлял настройку системы SAP ERP, были неограниченные полномочия (SAP_ALL, DEBUG), при этом анализ действий пользователей с подобными полномочиями не проводился на регулярной основе. После внутреннего расследования и выяснения деталей компания прекратила контрактные отношения с подрядчиком, а также существенно обновила команду сотрудников ИТ и менеджмента, отвечающих за реализацию продукции и управление мастер-данными, нормативно-справочной информацией.

Этой ситуации можно было бы избежать, снизив риски нарушения принципов разграничения полномочий и несогласованных изменений, например:

• запретить или максимально ограничить доступ к таким полномочиям, как SAP_ALL, DEBUG.

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

• внедрить регулярный мониторинг активности пользователей с подобными полномочиями;

• реализовать механизм, позволяющий осуществлять контроль, с тем чтобы любые произведенные в системе и согласованные заказчиком изменения затем оставались неизменными либо в дальнейшем изменялись только по согласованию с заказчиком или непосредственно владельцем системы;

• журналировать, то есть производить периодическую фиксацию критических действий в отдельном хранилище, недоступном для пользователей с доступом SAP_ALL, DEBUG;

• ограничить доступ подрядчику определенным промежутком времени либо продолжительностью контракта.

Пример 4

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