Статья начальника отдела ИБ ООО "IT-TEAM SERVICE" Антона Ракитского вышла в журнале «Управление предприятием», издаваемом Международным центром финансово-экономического развития - Узбекистан. Статья вышла в журнале №9 (159) за сентябрь 2020 г.
Полную версию статьи можно прочитать на сайте издания, в электронной версии журнала. Она доступна на русском и узбекском языках. Ниже приводится авторская редакция статьи.
Любая проблема, инцидент, сообщение о некачественной продукции и услуге - важный сигнал, о том, что где-то в производстве серьезные проблемы. Не обращать внимания на сообщения извне всё равно, что спуститься в урановую шахту и отключить дозиметр - какое-то время он не будет беспокоить вас писком-треском, но потом проблемы будут катастрофическими. Любая жалоба это бесплатная консультация. А въедливый потребитель - лучший аудитор. В статье рассматриваются, в том числе, рекомендации из стандарта ISO/IEC 27001:2013 по управлению системой менеджмента информационной безопасности, но эти рекомендации могут быть перенесены и в любую другую сферу производства.
Работа с инцидентами и обратная связь с клиентами - важнейшая составляющая любого бизнеса.
Инцидент это единичное событие или ряд нежелательных, непредвиденных событий, из-за которых велика вероятность компрометации бизнес-операций и угроз интересам бизнеса. Любой инцидент это сигнал о какой-то проблеме или неоптимальной системе управления. Именно поэтому очень важно фиксировать инциденты. Если скрывать и утаивать мелкие происшествия, то рано или поздно произойдёт такое, что может поставить под вопрос сам факт существования предприятия.
Попробуем кратко описать рекомендуемую систему реагирования на инциденты.
1. С самого начала нужно определить «хозяина вопроса» - подразделение или конкретное лицо, ответственное за управление инцидентами, сбор, анализ и реагирование. Примеры: клиенты жалуются на низкое качество услуг, в офисе предприятия постоянно проблемы с энергоснабжением, периодически происходят утечки конфиденциальных данных к конкурентам. Подразделение или конкретный специалист должен фиксировать все такие случаи и информировать высшее руководство о наиболее критичных из них. На крупных предприятиях разные виды инцидентов могут обрабатывать разные службы, но не должно быть ситуации, при которой информация о проблеме теряется или хотя бы не фиксируется.
2. Все сотрудники предприятия должны немедленно оповещать обо всех потенциальных проблемах, угрозах бизнесу, уязвимостях, небезопасных ситуациях. Например, сотрудники видят, как через заднюю дверь в организации незнакомые люди выносят технику или мебель, из-под двери запертого кабинета идёт дым. Что им делать? Сотрудники должен оповестить специальную службу по заранее определённым каналам связи. С одной стороны описанные ситуации могут быть и плановым ремонтом техники, который делает подрядная организация, а хозяин кабинета может просто окуривать его исрыком. А может и наоборот - неприкрытые хищения и начало пожара. Чтобы не попасть в глупую ситуацию и не прослыть паникёром, у сотрудника должно быть понимание, что к его сообщению о проблеме отнесутся с вниманием, а сообщать о подобных подозрительных событиях - его обязанность. Так же и непосредственно в рабочем процессе нужно проявлять бдительность. Часто беспричинно перезагружающийся компьютер может просигнализировать о начале вирусной эпидемии или деятельности злоумышленников. Автоматизированные средства могут и не сработать, люди по-прежнему остаются важнейшим рубежом обороны. Как и в примере с дымом выше - сотрудник не должен раздумывать об истинных причинах подозрительной активности. Он обязан сообщить о ней, а уж обработка и анализ таких сообщений - забота профильной службы.
3. Сотрудники должны сообщать не только об уже происходящих подозрительных событиях, но и обнаруженных ими потенциальных проблемах. Например, если рядовой сотрудник склада в бухгалтерской системе, кроме своих основных данных вдруг сможет получить доступ к информации о заработной плате всех сотрудников. Или сотрудник отдела кадров на рабочем файловом хранилище обнаружил файлы с какой-то явно конфиденциальной информацией (договора, протоколы переговоров), которая не нужна ему по работе. В обоих случаях, скорее всего, произошла ошибка и чем раньше о ней станет известно ИТ-администратору - тем меньше шансов что она разовьется в какой-то серьезный инцидент.
4. Разработать механизм оповещения об инцидентах. Он должен быть максимально простым. Долгое время существовала практика вывешивать ящик «для жалоб и предложений». Сейчас сбор информации можно упростить - собирать данные в электронной форме. Благо для этого есть уже множество готовых инструментов - через форму на web-сайте, через гугл-формы, через ботов или специальные аккаунты в мессенджерах (тот же Telegram). Иногда может быть полезным собирать какие-то сообщения анонимно. Многим значительно проще поделиться информацией анонимно, нужно предоставить такую возможность. Понятно, что ценность анонимных сообщений ниже, может быть и явная дезинформация. Но лучше иметь и такой канал обратной связи тоже.
5. Сообщения об инцидентах нужно накапливать и анализировать. В адаптированном виде они должны регулярно доводиться до высшего руководства. Только в этом случае можно рассчитывать на эффективные меры и, самое главное, выделение финансирования и поддержку руководством. Долгое же отсутствие сообщений о каких-то проблемах должно насторожить - значит «сломалась» обратная связь. Долго так продолжаться не может и о проблемах вскоре уже можно будет узнать из СМИ, от проверяющих органов или конкурентов.
6. Качественный сбор сообщения об инцидентах параллельно поможет решить ещё две сложные управленческие задачи:
Первая - формирование внутрифирменной базы знаний. А это, напомним, в т.ч. требование п.7.1.6 стандарта ISO 9001:2015. Т.е. в первый раз столкнувшись с проблемой нужно тщательно её зафиксировать и описать все стадии её решения. Это поможет в будущем в аналогичной ситуации. На память сотрудников полагаться не стоит, они перейдут на другую работу и «заберут» весь свой опыт с собой. А накопленная внутрифирменная база знаний будет работать как шпаргалка и дальше.
Вторая - формирование аналитической и статистической информации для качественного управления рисками. Оценить, насколько велика вероятности реализации той или иной угрозы значительно проще, если есть статистика по аналогичным инцидентам за прошедшие годы. Это необходимо в т.ч. и для формирования экономических обоснований. Пример: администратор сообщает, что за минувший год в организации было отмечено пятьсот случаев, когда на принесённых пользователями съемных носителях (флешках) были обнаружены и успешно удалены компьютерные вирусы. То есть по одной этой цифре, упрощая, можно сказать, что были предотвращены множественные вирусные эпидемии в организации. А теперь администратор просит о продлении срока действия лицензии на антивирусное программное обеспечение. Руководителю, имея даже такие данные, будет уже проще принять решение о закупке. Как видно из примера, необязательно, чтобы все фиксируемые инциденты приводили к убыткам, потере данных. Даже просто фиксация срабатывания средств защиты представляет ценную статистическую информацию для принятия решений. Без таких цифр решения придётся принимать фактически вслепую.
Просто фиксировать проблему и каждый раз устранять результаты инцидентов тоже нерационально. Идеальным является вариант предупреждения, проактивный подход. Примеры из жизни - профилактика преступлений и укрепление иммунитета должны в перспективе дать бо́льший эффект чем поиск и наказание преступника, дорогостоящее лечение от хронических заболеваний.
Популярной практикой управления инцидентами является метод поиска основной причины (англ. RCA Root Cease Analysis), который можно представить в виде четырёх этапов:
1. Идентификация и описание. детальное изложение инцидента, сопутствующих факторов, наблюдений, ущерба.
2. Хронология. Последовательное описание развития инцидента во времени от нормального состояния до самого инцидента. Выстраивание цепочки и выяснение, что было первопричиной, а что - последствиями.
3. Поиск причинно-следственных связей. Попытка определения того что было частью самого инцидента, а что - случайными совпадениями или сопутствующими факторам. Осуществляется движение от самой проблемы к её причине, всё дальше назад во времени. Таким образом, выявляется что стало «спусковыми крючками» инцидента и на каких этапах проблему можно было бы предотвратить.
4. Выявление основной причины. Самих причин может быть несколько, но руководству уже будет ясно, как действовать, чтобы снизить риск повторения инцидента.
Рассмотрим применение метода RCA на упрощённом примере.
1. Идентификация и описание - Сотруднику бухгалтерии понадобился архив базы данных за прошлый месяц, а отдел информационных технологий не смог его предоставить.
2. Хронология - в соответствии с инструкцией сотрудника отдела ИТ каждый день делал резервную копию базы данных бухгалтерии. Затем он получает запрос на восстановление данных на заданную дату. При обращении к архиву выясняется, то требуемых данных там нет - физически файл за нужную дату есть, но он пуст.
3. Поиск причинно-следственных связей. Сотрудник отдела ИТ проверяет архивы за другие даты, они тоже пусты. Проверяет за предшествующие периоды - выясняется, что все архивы за последние три месяца фактически не велись, файлы пустые. А вот до этого - всё нормально. Выясняется, что именно три месяца назад был назначен новый сотрудник, ответственный за ведение электронного архива. Делается запрос в кадровую службу и оттуда получаются данные, что он не проходил обучения по программному обеспечению для ведения архива.
4. Выявление основной причины. Несмотря на наличие инструкций, необходимого программного обеспечения, основной причиной стало отсутствие специальных знаний у технического специалиста, который последние три месяца работал неправильно.
В итоге можно сделать вывод, что существует общая для предприятия проблема, когда назначение сотрудников не сопровождается необходимым обучением. Также отсутствует контроль за работой неопытных специалистов со стороны их начальника.
Источниками сообщений об инцидентах являются не только сотрудники самого предприятия, но и потребители. Наверное, многие замечали, что в банках, офисах компаний мобильной связи стали появляться небольшие приборы с несколькими кнопками, нажав на которые, можно оценить работу оператора. Плохо, удовлетворительно, хорошо. Где-то градаций больше. Чтобы клиенты не стеснялись пользоваться системой, оценки заменяют цветными смайликами. Даже всем известная книга жалоб и предложений фактически является элементом системы управления инцидентами. Особую ценность представляют негативные отзывы - только они ведут к совершенствованию. Качественная критика это бесплатная консультация. Когда все довольны - менять ничего не надо.
С элементами поощрения обратной связи с розничным потребителем мы все встречались. Многие торговые сети предлагают бесплатно обменять обнаруженный в торговом зале продукт с истекшим сроком годности на такой же, но свежий. То же и с товаром с неправильным ценником - если покупатель обнаружит расхождение цены в ценнике и в чеке, то такой товар ему могут отдать бесплатно. Торговая сеть «вербует» добровольных инспекторов, которые будут помогать товароведам в магазине искать несоответствия. Расходы на такие условные премии добровольным помощникам, скорее всего, совсем небольшие, зато формируется лояльность покупателей и растёт качество обслуживания.
Но обратная связь на этом не заканчивается. Ответственные предприятия ещё и тщательно контролируют социальные сети, ищут любые упоминания своих брендов. Если потребитель недоволен, то на него может выйти официальный представитель и попытаться выяснить причины. Если такую работу не проводить, то на конкурентном рынке потребители быстро уйдут к более внимательным конкурентам.
Ещё большую ценность имеет обратная связь от экспертного сообщества, когда о проблемах сообщает сторонний специалист, не связанный контрактными обязательствами с компанией, которой он сообщает о проблемах. Очень распространена такая практика особенно с проблемами в области информационной безопасности. Крупные ИТ-компании специально назначают премию за обнаруженные технические уязвимости. Такая практика называется «Bug Bounty». Например, Яндекс платит за обнаруженные уязвимости до $3000, FaceBook и Google за сообщения об отдельных уязвимостях заплатили до $40000.
Случай из нашей практики - мы обнаружили серьезную уязвимость в информационной системе крупной торговой сети. Руководствуясь принципами экспертной этики, мы постарались тут же уведомить об этом специалистов организации. Отправили по всем адресам электронной почты, которые нашли на сайте торговой сети, подробное описание уязвимости. Но никакой реакции не последовало. Или наши сообщения затерялись среди писем со спамом, или попали в руки некомпетентных специалистов и они не поняли или не приняли всерьез наше письмо. Только после того как мы отправили заказное бумажное письмо на имя генерального директора проблему признали и вскоре её устранили. Будут ли другие доброжелатели как мы «пробивать стену»? Возникнет ли у нас снова желание так безвозмездно помогать этой торговой сети? Очевидно - нет.
Резюме. Качественное управление предприятием возможно только при постоянном контроле результативности, степени удовлетворённости потребителей. Также внимательно нужно относиться к сообщениям о проблемах, анализировать инциденты, всячески поощрять обратную связь с потребителем и развивать внутренние коммуникации в коллективе. Ошибки были и будут в любой деятельности. Систему управления характеризуют не ошибки, систему характеризует реакция на ошибки.