Управление риском ИТ. Основы - страница 5

Пример 2

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

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

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

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

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

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

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

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

Пример 3

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

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

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

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

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

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

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