Статья начальника отдела ИБ ООО "IT-TEAM SERVICE" Антона Ракитского вышла в журнале «Управление предприятием», издаваемом Международным центром финансово-экономического развития - Узбекистан. Статья вышла в журнале №1 за январь 2021 г.
Полную версию статьи можно прочитать на сайте издания, в электронной версии журнала. Она доступна на русском и узбекском языках. Ниже приводится авторская редакция статьи.

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

Так как же формировать эту (производственную) культуру и стимулировать положительные изменения в поведении сотрудников? К сожалению, простого ответа на этот вопрос нет. Но начать стоит с того, чтобы понять, в чём же причина нежелательного поведения, почему люди не хотят следовать правилам и рекомендациям? И в этот момент обычно выясняется:
- они не считаю проблемы информационной (да и не только) безопасности такими уж серьезными, считают их преувеличенными. И уж точно не касающимися их лично.
- они не чувствуют, что они ответственность за обеспечение безопасности лежит именно на них. Есть профильные службы, вот пусть они этим и занимаются.
- они не понимают, какой именно вклад в обеспечение безопасности вносят, как их работа может повлиять на безопасность предприятия.
    Другой аспект проблемы   чаще всего отношение сотрудников к службе безопасности очень скептичное, скорее негативное. Службу физической безопасности, охрану могут воспринимать как бездельников. А службу информационной безопасности чуть ли не как шпионов, которые следят за сотрудниками и готовы «подловить» на нарушениях, которые могут незримо вмешиваться в работу и тайну личной жизни, читать отправляемые с рабочего компьютера письма, прослушивать телефонные переговоры. И в целом весь процесс обеспечения безопасности воспринимается как помеха на пути всех процессов. Часто даже высокое руководство, финансовый менеджмент, видит безопасность как «бездонную бочку», поглощающую деньги в увеличивающихся объемах и не приносящих никакой пользы, кроме обозначенных выше помех.

Для достижения сколько-нибудь заметного успеха на пути повышения безопасности, руководителю предприятия нужно решить две задачи:
1. Персонализировать процесс обеспечения безопасности. Т.е. сотрудники должны знать   кто именно на предприятии занимается обеспечением информационной безопасности. Например, часть инструктажей или лекций могут проводить сотрудники, занимающиеся ИБ. Ещё лучше, если между коллективом и службой безопасности завяжется доверительный диалог   по части вопрос можно будет обратиться напрямую в службу безопасности, т.е. рядовые пользователи будут знать своих «киберзащитников» лично. Пока же часто происходит ровно наоборот - служба безопасности это самое закрытое подразделение на предприятии, кто и чем занимается - секрет, а с пользователями на связь выходят только для расследования нарушений, проступков и для последующего наказания. Если сотруднику звонят из службы безопасности, то такой звонок обычно не предвещает ничего хорошего. И наоборот - звонить в службу безопасности не принято. Так как это означает, что пользователь не читал инструкций, не помнит материала инструктажа и сам в этом открыто признаётся. Такой подход нужно менять. У безопасности должно быть «человеческое лицо» и в первую очередь для сотрудников своего предприятия. Современные практики предлагаю включить в этот процесс геймификацию, придать какой-то игровой, соревновательный характер. Например, как-то отметить/премировать самый интересный вопрос в службу безопасности. Поддерживать и стимулировать бдительность - если рядовой сотрудник обнаружил серьезную проблему и сообщил о ней службе безопасности, нужно это поощрить, поддержать такую инициативу. Совсем необязательно требовать сообщать обо всех нарушениях соседа по кабинету (вопрос о доносительстве/информировании о нарушениях коллег очень полемичен и неоднозначен), но отметить действительно важное сообщение обязательно нужно. Только если бизнес-подразделения и служба безопасности поймут что все они «в одной лодке», то и службу безопасности будут понимать и уважать, а не бояться.

2. Упрощение и разъяснение процедур безопасности. Пример: сотрудник ушел в отпуск и служба безопасности тут же заблокировала его учётную запись в информационной системе. Вернувшись из отпуска, сотрудник недоволен   ему нужно куда-то звонить и просить включить его учётную запись. Ему нужно объяснить, что это делается не только для безопасности предприятия, но и чтобы защитить самого сотрудника. Чтобы в его отсутствия никто от его имени ничего не сделал в системе, не подставил его тем самым. Тогда он поймёт и значение этой меры и даже свою заинтересованность в ней. И так по каждой процедуре - сотрудник не только должен понимать что́ он должен делать, но и для чего.

Итак, нужно перестать воспринимать сотрудников как «слабое звено» в безопасности. Грамотные и лояльные сотрудники это наоборот - самый ценный актив. А далее   всячески поддерживать формирование правильных навыков, привычек, и в конечно счёте - культуры безопасности. Процесс очень непростой, но другого пути нет.

Статья начальника отдела ИБ ООО "IT-TEAM SERVICE" Антона Ракитского вышла в журнале «Управление предприятием», издаваемом Международным центром финансово-экономического развития - Узбекистан. Статья вышла в журнале №11 за ноябрь 2020 г.
Полную версию статьи можно прочитать на сайте издания, в электронной версии журнала. Она доступна на русском и узбекском языках. Ниже приводится авторская редакция статьи.

Для управления информационными технологиями на крупных предприятиях есть отдельные специалисты - ИТ-директора или CIO (англ. Chief Information Officer). Именно они ведут большую часть дел, связанных с информатизацией. Но базовые принципы и проблемы внедрения новых ИТ систем и появляющиеся риски нужно понимать и высшему руководству предприятия.

Жизненный цикл информационных систем.
Всё чаще в управлении информационными технологиями и безопасностью применяется термин «жизненный цикл». Это развитие системы, продукта, услуги, проекта, начиная со стадии разработки и заканчивая прекращением применения. Когда говорят про управление на протяжении всего жизненного цикла, то имеется в виду, что охвачены все его периоды. И безопасность должна обеспечиваться на необходимом уровне на каждом из них. Ведь, согласитесь, если утечка конфиденциальной информации произойдёт из устаревшей и снятой с эксплуатации системы - предприятию от этого будет не легче, а ущерб от этого не станет меньше. Подробнее о жизненном цикле программного обеспечения можно узнать в государственных стандартах Oʻz DSt ISO/IEC/IEEE 12207:2018 «Информационная технология. Процессы жизненного цикла программного обеспечения» и Oʻz DSt ISO/IEC 14764:2008 «Разработка программного обеспечения. Процессы жизненного цикла программного обеспечения. Сопровождение программных средств».
Разработка технического задания.
Планирование создания новой информационной системы желательно начинать с подготовки технического задания. Разрабатывать его от простого - к сложному. Заказчик системы и её будущие пользователи описывают желаемый функционал, что и как система должна делать, входные и выходные данные. Очень важно ещё на этапе планирования подключить к процессу все заинтересованные стороны. Ведь систему в дальнейшем будет эксплуатировать, поддерживать ИТ-служба предприятия, вводить данные кадровая служба, канцелярия, бухгалтерия и т.д. Например, ИТ-службе нужно будет понимать техническую специфику новой системы, заложить её совместимость с уже имеющейся инфраструктурой. Важен и методический аспект - предусмотрено ли обучение новой системе. Ведь, к сожалению, часто всё происходит ровно наоборот - на презентации был показан проект, который понравился руководству. Его волюнтаристски внедряют. Но как работать с новой системой пользователи элементарно не знают, а у ИТ-службы может не хватить для работы системы ни технических средств (элементарно нет свободного сервера), ни знаний. В итоге новая и, возможно, хорошая система саботируется большей частью коллектива.

Другая очень распространённая проблема - отсутствие инструкций по работе с системой. Когда потребитель приобретает любую сложную бытовую технику - от пылесоса до автомобиля, то в комплекте всегда идёт инструкция по эксплуатации. Некоторые даже её читают. А при разработке новых систем этот этап часто пропускается. Поэтому особенно важно именно на стадии составления требований к новой системе, подготовки ТЗ, заложить в него создание подробных инструкций. Причём отдельно для рядовых бизнес-пользователей, для администратора систем, инструкции по технической поддержке. Ведь без инструкции, при возникновении проблемы, пользователю будет просто не к кому обратиться с вопросом. Также на уровне ТЗ оговариваются языки, на которых будет доступен интерфейс системы, при разработке мобильных приложений - поддерживаемые платформы (Android, iOS), форматы данных, формы отчётов. Если этого не сделать то разработчики всё сделают по собственному разумению и будут формально правы, ведь они не могут предугадать всех пожеланий заказчиков. В итоге возникают взаимные претензии между заказчиками и исполнителями, разбирательства, а доработка или переделка требует времени и денег. Поэтому тщательное и подробное техническое задание очень важно. Существует практика, когда техническое задание на систему пишет сам разработчик. Нарушения в этом нет, но, очевидно, что формулировки в этом случае будут скорее выгодны ему для успешной сдачи работ, чем заказчику. В любом случае, лучше всё прописать и, что называется, «договориться на берегу», чем потом спорить - что́ имелось в виду изначально, а что́ появилось по ходу работ.
Кроме чисто функциональных требований к системе, которые предъявляет бизнес, существуют ещё дополнительные специфические требования:
1. Для органов государственного и хозяйственного управления, органов государственной власти на местах при разработке технических заданий необходимо учитывать требования государственного стандарта O'z DSt 1987:2018 «Техническое задание на создание информационной системы». В нём содержатся примеры и даже рекомендуемая структура технического задания. Стандарт будет полезен всем, как минимум в качестве справочника, чтобы случайно не упустить что-то важное.
2. Также для госорганов при разработке и внедрении систем необходимо учитывать специальный документ по информационной безопасности - Требования обеспечения информационной безопасности органов государственного и хозяйственного управления, государственной власти на местах (Приложение № 2 к протоколу Техсовета №7 от 17.11.2017 г.)
3. Если в составе программного комплекса планируется использовать средства криптографической защиты информации (проще - шифрование), то нужно иметь в виду, что обязательной сертификации подлежат средства технической и криптографической защиты информации, если они разрабатываются как часть ПО (см «Перечень производимых в Республике Узбекистан и ввозимых на ее территорию видов продукции, подлежащих обязательной сертификации», приложение № 1 к постановлению Кабинета Министров от 28 апреля 2011 года № 122). При этом сама деятельность по проектированию, разработке, производству, реализации, ремонту и использованию средств криптографической защиты информации является лицензируемым видом деятельности. Лицензирующий орган - Служба государственной безопасности. Будут ли входить в состав разрабатываемого ПО функционал по криптрографической защите? Есть ли у разработчика соответствующие лицензии?
А вот деятельность, связанная с применением средств электронной цифровой подписи (ЭЦП), обеспечивающих её создание в электронном документе и подтверждение подлинности - лицензированию не подлежит (ПКМ № 242 21.11.2007).
4. Для госорганов может существовать необходимость согласовывать разработанное техническое задание в различных службах. Например, ТЗ на информационно-коммуникационные технологии, аппаратные средства и программные продукты, средства защиты и иные технические средства согласовываются в обязательном порядке с Центром кибербезопасности (№ПП-4024 21.11.2018).
Т.е. составление технического задания может потребовать привлечения ещё и юридической службы. Иначе есть риск, что вновь внедрённая система в результате будет нарушать требование каких-то регламентов.
Всё больше систем делаются доступными извне самой организации. Или изначально разрабатываются доступными для неограниченного круга пользователей. Примеры - сайты организации, информационные порталы, службы обратной связи с потребителями и др. Во многом, именно такая информационная система становится «лицом» организации. Особенно для сервисных организаций, служб доставки, интернет-магазинов. Поэтому, внедряя такую систему, нужно предусмотреть отказоустойчивость системы. Также, работа в публичном пространстве автоматически возлагает требования по соблюдению целого ряда нормативов. Самый яркий пример - закон «О персональных данных». Если пользователи системы, регистрируясь в системе, сообщают свои персональные данные, то нужно явным образом получать согласие на их обработку, декларировать сроки и цели такой обработки, обеспечивать должным образом их безопасность (подробнее об этом см. статью в журнале №11 (149) за ноябрь 2019 г.)

Часто возникает необходимость, чтобы действия пользователей в системе были юридически значимыми. А документы и подписи на них приравнивались к собственноручным. Для этого применяются механизмы электронной цифровой подписи (ЭЦП). Применение таких технологий требует особой тщательности, чтобы исключить компрометации данных и поддерживать доверие пользователей к таким системам. В этой связи кроме чисто технических мер, нужно ещё и явно демонстрировать пользователям, какие данные и как накапливаются в системе, какие документы и для чего он подписывает своей ЭЦП. Яркие примеры таких систем - системы дистанционного банковского обслуживания, единый портал интерактивных государственных услуг, система электронных счетов-фактур.

Любая сложная система, особенно после внедрения, это «живой организм», в который постоянно вносятся изменения и исправления. За такой модернизацией нужно следить не менее тщательно чем за первоначальной разработкой. Скорее всего, сопровождением системы будет заниматься та же организация, что и разрабатывала её. На уровне официального соглашения, договора, необходимо оговорить не только обязательства по конфиденциальности, но и правила по модернизации информационной системы (статья об аутсорсине ИТ-услуг вышла в нашем журнале №3 (141) за 2019 г.)
Каждое изменение, вносимое в систему, должно сначала тестироваться, отрабатываться на опытном стенде, и только потом изменение вносится в «боевую» систему. Иначе, устраняя одну проблему, можно «сломать» что-то в другом месте. Каждое такое изменение должно чётко документироваться и одобряться владельцем системы. Т.е. должна быть возможность отследить когда появился тот или иной функционал в системе, по чьей заявке, кто проводил тестирование и кто одобрил ввод в эксплуатацию.
У разработчиков-программистов существует практика создавать копию основной системы - тестовый стенд. И все изменения проверять, тестировать сначала на этом стенде. Для создания максимальной правдоподобности такого тестирования велик соблазн просто взять и скопировать все данные из основной системы в тестовую. Такой подход таит очень большие риски. Ведь доступ к тестовой системе защищается не так тщательно, как к основной. Штатные службы безопасности практически не контролируют деятельность разработчиков. Представьте, что такая тестовая среда создается для автоматизированной банковской системы, заполняется реальными данными, а потом из этой тестовой среды происходит утечка данных. Последствия такой утечки будут такими же, как если бы это случилось с основной системой. Только найти виновных - значительно сложнее. Поэтому хорошей практикой является наполнение тестовых систем фиктивными, вымышленными данными. Если всё-таки необходимо работать с неким подобием реальных данных, то применяется маскирование. Например, все имена и фамилии, адреса обрезаются до первых двух-трёх букв, а остальные заменяются каким-нибудь символом, например звёздочками.

Другая мера - чётко разделить среду разработки и основную промышленную систему. Пользователи и разработчики должны чётко понимать, работают ли они в тестовой или в основной системе. Этой простой мерой часто пренебрегают и возникает ситуация, когда программист, думая, что работает с тестовой системой, вносит глобальные изменения в основную систему, выводит её из строя. У любого опытного разработчика множество историй о таких простых, досадных, но разрушительных ошибках.
Даже такая сугубо технологичная вещь как разработка программного обеспечения требует особого подхода не только со стороны бизнеса, но и юридической, кадровой службы, и особо - со стороны высшего руководства. Любая сложная работа чревата ошибками, разработка современных информационных систем как раз такой случай. Иногда ошибка программиста может привести к утечке данных, хищению средств, полному выходу из строя. Т.е. программист должен не только выполнить техническое задание - создать систему по запросу бизнеса, но и придать ей защитные функции, постараться сделать устойчивой к атаке злоумышленников. На практике, разработчикам ставятся конкретные сроки, в которые они должны уложиться и сдать работающую систему. Вопросы безопасности часто даже не ставятся и не обсуждаются. Но руководство предприятия должно понимать, что сжатые сроки при разработке лишают разработчиков возможности дополнительного тестирования, испытания. Да и спешка сама по себе провоцирует ошибки. Что важнее - запустить систему точно в срок, но с возможными проблемами, или чуть сдвинуть, отложить запуск, но дать больше времени на проверку? Это решение может принять только руководитель предприятия. В некоторых случаях вопросы безопасности и защиты данных имеют очень высокое, а то и определяющее значение. Например, банковские приложения. Финансы, медицина, транспорт, пищевая промышленность - в этих сферах безопасность имеет высший приоритет.

Обеспечение безопасности при разработке ПО это целое направление в технологиях. Но, т.к. заказчики при формировании технического задания никак не обозначают вопросы защиты данных, то программисты и не акцентируют на этом своё внимание. Хорошей практикой является направление сотрудников за счёт предприятия на специальные курсы по обеспечению информационной безопасности при разработке ПО.
Вообще, вопросы безопасности должны озвучиваться на уровне высшего руководства, нужно дать понять всем, особенно разработчикам, что их усилия в этой сфере оцениваются. Ведь если от программиста требуют «быстрее и дешевле», наивно ожидать, что он будет стараться сделать ещё и «безопасно».
Относительно недавно (последние лет 10) появился ещё независимый аудит исходного кода и специальные инструменты по автоматизации поиска ошибок и уязвимостей в разработках. Такой подход позволяет обнаружить многие критические проблемы ещё до выпуска системы в промышленную эксплуатацию. И этот инструментарий будет всё шире применяться. Ведь сейчас сложно представить, что какой-то автомобиль будет запущен в эксплуатацию без краш-теста, когда он на заданной скорости сталкивается с препятствием и определяется, уцелеют ли его пассажиры? Для серьезных информационных систем тоже обязательно должны проводиться подобные испытания - справится ли система с нагрузкой, удастся ли отразить атаки по сети. И после каждого существенного изменения такие тесты нужно проводить снова.
Задача современного руководителя понимать, что кроме несомненных удобств, информатизация несёт ещё и специфические риски. Необходимо определить, задекларировать и придерживаться в работе баланса между безопасностью и скоростью разработки, внедрения новых функций. Сформировать доброжелательную атмосферу, когда допущенные ошибки тщательно анализируются, выявляются истинные причины их возникновения. Ну и всячески поддерживается обратная связь с пользователями систем, которые тоже могут сообщать о проблемах в информационных системах.
Руководителям, которые хотят ещё подробнее узнать об обеспечении безопасности при внедрении и разработке информационных систем рекомендуем раздел «14 Приобретение, разработка и обслуживание информационных систем» государственного стандарта Oʻz DSt ISO/IEC 27002:2016 «Информационная технология. Методы обеспечения безопасности. Практические правила управления информационной безопасностью».

Недавно Центральный банк РУз выпустил два важных документа по информационной безопасности. Пожалуй, основным изменением стала отмена большого числа инструкций и положений по безопасности, на которых «выросло» не одно поколение банковских специалистов по ИБ в Узбекистане за последние двадцать лет.
Оба эти положения Центральный банк выпустил только на узбекском языке.
Мы своими силами подготовили перевод обоих этих положений на русский язык и готовы поделиться переводом с вами.

1. Положение о защите информации в автоматизированных системах коммерческих банков Республики Узбекистан (рег. в МинЮсте №3224 10.03.2020) на русском языке. (текст документа на узбекском языке), ссылка на документ на Lex.uz.
2. Положение об обеспечении информационной безопасности в платежных системах операторов платежных систем и поставщиков платежных услуг (рег. в МинЮсте № 3268 30.06.2020) на русском языке. (текст документа на узбекском языке), ссылка на документ на Lex.uz.

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

Статья начальника отдела ИБ ООО "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.
Случай из нашей практики - мы обнаружили серьезную уязвимость в информационной системе крупной торговой сети. Руководствуясь принципами экспертной этики, мы постарались тут же уведомить об этом специалистов организации. Отправили по всем адресам электронной почты, которые нашли на сайте торговой сети, подробное описание уязвимости. Но никакой реакции не последовало. Или наши сообщения затерялись среди писем со спамом, или попали в руки некомпетентных специалистов и они не поняли или не приняли всерьез наше письмо. Только после того как мы отправили заказное бумажное письмо на имя генерального директора   проблему признали и вскоре её устранили. Будут ли другие доброжелатели как мы «пробивать стену»? Возникнет ли у нас снова желание так безвозмездно помогать этой торговой сети? Очевидно - нет.

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

Статья Антона Ракитского вышла в журнале «Справочник по кадровым вопросам», в №9 (165) за сентябрь 2020 г.
Полную версию статьи можно прочитать на сайте издания, в электронной версии журнала. Она доступна на русском и узбекском языках. Ниже приводится авторская редакция статьи.

Как обеспечить информационную безопасность при работе с кадрами

Найти грамотного специалиста и сформировать кадровый резерв - сложная задача, но только самое начало работы сотрудника кадровой службы. Для того чтобы занять привлекательные позиции, соискатели могут вводить в заблуждение кадровиков. Кто-то без явного обмана, просто умолчит о части своей биографии. Самые отчаянные могут представить поддельные документы, отзывы, характеристики. Как сделать так, чтобы новый сотрудник компании стал действительно ценностью, а не «миной замедленного действия» и рассказывает статья. Акцент делается на работе с документами и информацией, полученной от сотрудника. Также рассматриваются задачи кадровой службы по обеспечению информационной безопасности на всех этапах работы с сотрудниками.

Зачем вообще нужны какие-то проверки будущих сотрудников? Стандарт по информационной безопасности O‘z DSt ISO/IEC 27002:2016 говорит, что это нужно чтобы «обеспечить уверенность в том, что персонал и работающие по договору понимают свою ответственность и соответствуют тем должностям, на которые они рассматриваются». Т.е. при трудоустройстве работодатель хочет быть уверенным, что нанимает того, кого нужно, и он оправдает ожидания. Сами проверочные мероприятия достаточно трудозатратны и предприятие должно решить для себя насколько сильно и глубоко проверять каждую категорию специалистов. При наборе линейного персонала - операторы, курьеры, продавцы такие проверки могут носить минимально-достаточный характер - получение по списку документов, необходимых для учёта сотрудника. А вот для специалистов, от которых зависит сам факт существования компании - проверки могут простираться очень далеко. Примером таких ключевых должностей является и всё высшее руководство, финансовый сектор, а в последнее время для высококонкурентных рынков всё большую ролю играет, например, фигура PR-менеджера. Одна какая-нибудь сомнительная акция в соцсетях или грубый ответ на запрос клиента и компанию обсуждают и осуждают все, а клиенты уходят к конкурентам.
Примечание: да, на многих крупных предприятиях (особенно государственных) уже есть свои системы проверок, чаще по линии режимно-секретного отдела, иногда какие-то проверки проводит служба безопасности. Для качественного управления персоналом кадровой службе нужно выяснить, кто и как проводит такие проверки и учитывать их результаты в своей работе.
Работа с сотрудниками в кадровой службе длится на протяжении всего «жизненного цикла» - до трудоустройства, во время работы, после увольнения.

1. До трудоустройства
Кроме минимально набора документов, которые необходимы для трудоустройства по трудовому законодательству, существует ещё несколько дополнительных способов проверки, в том числе нужно иметь в виду:
- Наличие положительных рекомендаций. Если соискатель приносит рекомендательные письма нужно проверить их подлинность. Скорее всего, не составит труда связаться с поручителем, давшим рекомендацию. К сожалению, встречаются и явные мошенники, которые сами пишут рекомендательные письма, характеристики, подписывают их именами, вызывающее доверие, указывают контактные данные (номер телефона), на котором сидит «свой человек», который подтвердит подлинность отзыва. Поэтому здесь и далее при телефонных звонках лучше использовать те номера телефонов, которые вы найдете сами в справочнике. Тогда у вас будет уверенность, что вы звоните именно в необходимую организацию.
- Резюме претендента. Если в нём содержаться сведения, которые сильно влияют на принятие решение о трудоустройстве, то их необходимо проверить. Большим подспорьем для этого являются социальные сети. А вот если у современного специалиста нет профиля это очень подозрительно. Существует даже профильная сеть LinkedIn, ориентированная на поиск специалистов, публикацию отзывов и характеристик.
- дипломы и сертификаты. Дипломы о высшем образовании можно проверить по сайтам ВУЗов, сейчас многие из них публикуют списки выпускников по годам. В других случаях можно сделать официальный запрос в ВУЗ, выдавался ли в такой диплом. С учебными центрами сложнее - многие из них «живут» совсем недолго, т.е. проверить сертификат об обучении, выданный несколько лет назад может быть затруднительно.
- Паспорт. Маловероятно, что сотрудник будет предоставлять поддельный паспорт. Современные документы хорошо защищены и подделки легко обнаружить. Но лучше всё-таки проверить документы, особенно, если приходится работать с копиями документов. Проще всего это сделать через сервис ГНК по проверке ИНН. Сервис сразу подтвердит и существование паспорта с конкретным номером, и дату рождения человека, и правильность представленного ИНН. Адрес сервиса - https://my.soliq.uz/searchtin/index?user_type=1
- В некоторых случаях, когда требуется совсем уж тщательная проверка сотрудника, может быть запрошена его кредитная история. Но, согласно действующему законодательству Узбекистана, запрос такой информации из кредитных бюро осуществляется только с согласия субъекта (ст.19 закона РУЗ «Об обмене кредитной информацией»). Т.е. законно сделать запрос такой информации невозможно сделать без уведомления самого потенциального сотрудника невозможно. Да и для запроса такой информации необходим договор с кредитным бюро. Основными пользователями услуг кредитных бюро являются банки, ломбарды - они и отправляют и получают информацию о своих клиентах.
Вообще, при всех проверках, когда о сотруднике запрашиваются данные, напрямую не связанные с выполняемой работой, следует иметь в виду этическую сторону вопроса. Так, наличие у соискателя непогашенных кредитов, фактов долгого пребывания за границей, наличия обязательств по алиментам, погашенные судимости, напрямую не говорят о профессиональных качествах ничего однозначно. Однако, отказ в работе именно со ссылкой на какую-то подобную деталь в биографии может быть причиной обвинения в дискриминации. Идеальных людей не бывает, и, задавшись целью, можно найти сомнительные детали в биографии у любого, поэтому лучше сразу определиться, что кадровой службе делать с полученными данными. Компромиссом является ранжирование «глубины» проверки биографии сотрудников в зависимости от занимаемой должности, её критичности. Кстати, обратите внимание, что почти всегда проверка биографии сотрудников производится только разово при приёме на работу, а потом годами судьба человек никак не отслеживается. Поэтому рациональной считается практика перепроверки при любом изменении должности или на периодической основе, если никаких перемещений нет.
Говоря о проверке компетентности сотрудников проще, когда существуют формальные процедуры подтверждения, например допуск на работу с электроустановками, к высотным работам, управление транспортным средством определённой категории. Такие знания подтверждаются строго определённым документом. Однако, особенно в ИТ, невозможно проверить уровень знаний сотрудников, особенно если предполагается, что сотрудник будет проходить обучение или стажировку уже после трудоустройства. В этих случаях важнее выявить наличие навыков обучения, понять, подойдёт ли сотруднику эта работа. Ещё важнее - стоит ли в него вкладывать средства и силы? Определить это в одиночку вряд ли под силу кадровику, даже очень опытному. Поэтому в тех случаях, когда решение принимается нелинейно, эффективным может быть проведение собеседование, в этом случае суждение о соискателе принимает некоторая группа, проводившая собеседование. Чтобы члены этой группы ответственно относились к процедуре собеседования может применяться практика, когда результат собеседование фиксируется, например в виде краткого резюме от каждого участника и этот документ приобщается к кадровому делу. В любом случае, такое собеседование даст более объективный результат, чем отзывы и характеристики, которые принесёт сам соискатель, ведь они всегда и у всех исключительно положительные. В этом случае окончательное решение о трудоустройстве принимается по совокупности факторов - проверка документов и резюме по итогам собеседования.
Мы уже не раз писали о практике передачи части функций на аутсорсинг, всё чаще это ИТ, бухгалтерия, юридические консультации, языковые переводы. Такие работы оформляются на договорной основе, кадровая служба никак не включена в этот процесс. А ведь сотрудники на аутсорсинге часто имеют доступ к очень важным, критичным данным. Поэтому целесообразно и их включить в процедуры проверок благонадёжности. Т.к. взаимоотношения с исполнителями в этом случае регулируются договором, то нужно внести в него пункты о том, что исполнитель заранее согласовывает с заказчиком кандидатуры исполнителей и согласен предоставить необходимые документы для проведения проверок. Для уже действующих договоров это можно оформить дополнительным соглашением. Иначе ситуация напоминает установку металлической двери в шалаш - штатные сотрудники проходят драконовские проверки, а на аутсорсинге работают «случайные» люди.
Необходимо обратить внимание, на принятый недавно в Узбекистане закон «О персональных данных» , он вводит дополнительное регулирование в области кадрового учёта. Хотя в нём и предусмотрены некоторые упрощения - нет необходимости регистрировать базы данных, которые ведутся в соответствии с законодательством о труде, тем не менее, от получения согласия на обработку персональных данных работодатель не освобождается. Получение согласия в явном виде особенно актуально при проведении проверок сторонних специалистов, работающих на аутсорсинге, по договору подряда и т.д. Образец документированного согласия на обработку персональных данных доступен в тексте статьи в самом журнале и на сайте издания.
Во время трудоустройства, в ходе подписания трудового договора и сопроводительных документов закладывается фундамент правовых взаимоотношений с сотрудником. Сейчас практически любой сотрудник получает доступ к каким-то данным в информационных системах - данные клиентов, адреса, перечни заказов, цены. Значительная доля этих данных - исключительно для внутреннего использования, содержат коммерческую тайну или персональные данные клиентов. Что остановит сотрудника от разглашения конфиденциальных данных? Как минимум это информирование его о правилах работы с информацией и разъяснение его обязанностей и ответственности. Сотрудник может действительно не знать особенностей работы, что можно и что нельзя. Поэтому сотрудника нужно сначала проинформировать о его обязанностях. На всех крупных предприятиях есть политика информационной безопасности, необходимо как минимум ознакомиться с ней. Ещё лучше, если будет проведен вводный инструктаж. По его итогам   провести тест, чтобы убедится, что будущий сотрудник понял основные требования по безопасности. А документально подтвердить обязанности сотрудника призвано обязательство о неразглашении, в котором описываются требования и во время трудовых отношений и на некоторое время после их окончания - как правило, от года до пяти лет. К экспертизе текста обязательства лучше привлечь и юриста, и кадровика, и представителя профсоюзного комитета - тогда документ получится гармоничным и более «устойчивым» в случае каких-то разбирательств в суде. Подписывая обязательство о неразглашении, человек соглашается с тем, что он понял требования к нему и несёт ответственность за их выполнение. Да, человека осознанного идущего на преступление эти документы не остановят, но мировая практика показывает, что большинство утечек происходят по неосторожности или отсутствию опыта, неосведомлённости. Все эти мероприятия по обучению и проверке нужно выполнить до начала работы сотрудника с реальными данными, чтобы он сразу не наломал дров.

2. Во время работы
Обеспечение информационной безопасности во время операционной деятельности, каждодневной работы - сложнейшая тема, предмет изучения ряда дисциплин. Однако применительно к кадровой службе, необходимо обратить внимание на следующий вопросы:
1. После вводного инструктажа, сотрудник должен и дальше иметь возможность проконсультироваться по вопросам работы с данными. Он должен знать, к кому обратиться.
2. Быть мотивированным и в соблюдении действующих правил, и в продолжении обучения, освоения новых технологий. Тут на помощь могут прийти и традиционные премии, но и какие-то нематериальные поощрения - благодарность от руководства, звание самого бдительного, полезного сотрудника и т.д. - всё это отдаётся на откуп кадровой службе.
3. Ещё лучше, если на предприятии будет создан или «телефон доверия» или какой-то ящик для обращений по вопросам конфиденциальности и безопасности данных. Ведь многие сотрудники не рискнут обращаться напрямую лично в технические службы, т.к. опасаются, что их обвинят в непрофессионализме, некомпетентности, мол ответы на все вопросы можно найти в документах, сотрудник должен об этом знать из инструктажа. Без действенного механизма обратной связи многие просто промолчат о явных нарушениях, а предприятию, в конечном счёте, это будет стоить очень дорого.
4. Вовлеченность руководства во все вопросы безопасности и защиты данных. Если руководство не обращает внимание на вопросы конфиденциальности и информационной безопасности, то и у сотрудников возникает ощущение, что это совсем неважный аспект работы. Этот эффект хорошо известен в педагогике - дети берут пример с родителей.
Сейчас любой специалист сталкивается с изменениями - бухгалтера с постоянным уже в течение многих лет изменением налоговой политики, сотрудники банка - с постоянным внедрением новых систем - и внутрибанковских, и для клиентов. Есть и примеры более масштабных изменений сразу для всех сфер производства - принятие закона «О персональных данных». Самым разумным шагом является регулярное проведение тренингов для сотрудников. Руководство в первую очередь должно быть заинтересовано, чтобы они не превращались в формальность. Раз уж предприятие тратится на обучение сотрудников, процесс нужно контролировать и убеждаться, что знания «доходят» до персонала. Для всех сотрудников полезным будет прохождение инструктажа по всем видам безопасности на предприятии - производственной, пищевой, экологической, информационной. И отдельно - по специфическим направлениям. Как и при вводном инструктаже - проверять усвоение материала. Все свидетельства об обучении, результаты тестирования сохраняются в личном деле сотрудника.
Если обучение не организуется на предприятии, бо́льшая часть сотрудников заниматься самообразованием не будет никогда.
Важно заранее предупредить специалистов о существующих на предприятии мерах дисциплинарного взыскания. Это не инструмент устрашения, а механизм сдерживания, стимулирующий сотрудника придерживаться правил. Специалист должен понимать, какую ответственность он несёт в зависимости от тяжести нарушения, понимать процедуру применения взыскания. Без такой процедуры у работодателя очень мало мер воздействия, причём диапазон их применения явно неадекватен, их всего три - абстрактный выговор, увольнение, и в самых тяжелых случаях   уголовное преследование. Т.е. между выговором и увольнением инструментов нет. Первое - никого не напугает, второе - может быть бо́льшим ударом для самого предприятия, чем для сотрудника.

3. При увольнении.
Увольнение процесс обычно малоприятный, лояльность увольняющегося сотрудника к предприятию низкая. Поэтому задача по защите интересов предприятия после увольнения должна решаться заранее. Маловероятно, что уходящий сотрудник согласится подписывать дополнительные обязательства. Лучше взяв их заранее (при трудоустройстве) при увольнении деликатно напомнить ему о них, например, выдав копию.
Другая важная задача кадровой службы - проинформировать все заинтересованные службы об увольнении сотрудника, а ещё лучше при любом его долгом отсутствии. Уведомление об увольнении должны тут же получить ИТ-служба (блокируется доступ к системам), служба безопасности (отзываются доступы на объекты), склад/гараж и прочие службы. В некоторых случаях, когда сотрудник взаимодействует с внешними органами и поставщиками, проинформировать ещё и их об увольнении, представить нового сотрудника, чтобы у ушедшего не было соблазна воспользоваться тем, что его ассоциируют с прошлым местом работы. Многие предприятия имеют практику подписания обходных листов, но она не гарантирует обеспечения желаемого уровня безопасности. Часто обходные листы подписываются спустя недели и месяцы после фактического прекращения работы. Всё это время человек продолжается «числиться» в списках сотрудников. Известны случаи, когда у уволившегося сотрудников сохраняется доступ к информационным системам самого предприятия и к аккаунтам предприятия в социальных сетях, связанных с предприятием. Поэтому все ключевые подразделения должны быть оповещены о прекращении трудовых отношений сразу же. А сама процедура увольнения должны по возможности быть простой, не приносящей дополнительных трудностей бывшему сотруднику - так больше шансов сохранить его лояльность к предприятию.

Антон Ракитский, эксперт по информационной безопасности ООО «IT-TEAM SERVICE»
Айгуль Жуматаева, руководитель подразделения по управлению рисками, АО «Казахстанская фондовая биржа».

Управление ИТ рисками

Статья вышла в журнале «Управление предприятием», издаваемом Международным центром финансово-экономического развития - Узбекистан, в журнале №8 (158) за август 2020 г. Полную версию статьи можно прочитать на сайте издания, в электронной версии журнала. Она доступна на русском и узбекском языках. Ниже приводится авторская редакция статьи.

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

Пожалуй, основная проблема, мешающая внедрить риск-менеджмент - отсутствие понимания у высшего руководства. Проще всего понять риск как прямые финансовые потери, т.е. измерять риск деньгами. Стоит лишь выразить производственные процессы, риски через деньги, как все понимают, о чём речь. Простейший пример - предприятие решает заняться грузовыми перевозками и берёт к перевозке ценный груз. Что произойдёт, если автомобиль попадёт в тяжелую аварию, пусть даже водитель чудом не пострадает? Нужно будет полностью компенсировать стоимость груза заказчику, полностью утрачен дорогой автомобиль и другие затраты. Реален ли такой риск? Более чем. Разве даже самый опытный водитель может дать гарантию, что довезёт груз в целости и сохранности? Даже в таком относительно простом действии есть тысяча подводных камней. Чтобы не потерять сразу всё, предпринимается множество мер по снижению риска аварии - проводится техосмотр, мед освидетельствование водителя, движение осуществляется по подготовленному маршруту, сам груз, а также автомобиль и здоровье водителя страхуются в страховой компании. Поэтому, даже при самом неблагоприятном развитии событий предприятие не теряет сразу всё, а получает частичное или полное финансовое возмещение.

Управление рисками существует практически в любом бизнесе - производство, услуги, финансы. Далее в примерах используются приёмы управления информационными рисками. Основные термины, используемые в риск-менеджменте:
Риск - влияние неопределённости на цели. Чуть проще - вероятность того, что произойдёт какое-то плохое событие, которое повлияет на цели бизнеса, приведёт к убыткам.
Угрозы - потенциальная причина нежелательного инцидента, при котором возможно причинение ущерба системе или организации. Внешние воздействия, способные привести к выходу из строя систем, утечкам данных, прямым убыткам, штрафам, потере репутации.
Уязвимости - слабости активов, использование которых позволяет реализоваться угрозам.

    Первый шаг в управлении рисками - создание перечня информационных активов, включенных в систему. Буквально составляется перечень всех сколько-нибудь важных для предприятия систем и ресурсов:
● система бухгалтерского учёта (1C Бухгалтерия)
● база кадровой службы
● системы управления предприятием (ERP)
● система взаимодействия с клиентами (CRM)
● сервер электронной почты (email)
● web-сайт предприятия
● офисная АТС
● система электронного документооборота (ЭДО)
● сотрудники, работающие удалённо.

Да, ключевыми активами могут быть и сотрудники, ведь для многих предприятий именно они играют ключевую роль - преподаватели, журналисты, консультанты.
Следующий шаг - для каждого актива определяются наиболее актуальные угрозы и уязвимости активов, через которые эти угрозы могут быть реализованы. Для каждого актива перечень угроз и уязвимостей может быть свой. Рассмотрим выявление угроз и уязвимостей на примере двух активов: Система бухгалтерского учёта и сотрудников, работающих удалённо. Угрозы, которым подвержены активы и их уязвимости для удобства можно свести в таблицу.
На следующих этапах приблизительно подбирается вероятность реализации угрозы и уровень возможного ущерба - такой подход называется «экспертный метод».
На начальном этапе управления рисками уровни ущерба могут быть оценены в виде относительных показателях. В дальнейшем лучше уже перейти к абсолютным значениям убытков. Т.е. перейти от качественных к количественным критериям. Простейшая шкала оценки уровня ущерба может быть такой:
Малый - Незначительные финансовые потери, которые быстро восстанавливаются, или незначительные последствия для репутации предприятия
Умеренный - Заметные финансовые или умеренные последствия для репутации предприятия
Средний - Существенные финансовые потери или значительный урон репутации предприятия
Большой - Большие потери материальных активов и большой урон репутации предприятия
Критический - Критические финансовые потери или полная потеря репутации предприятия на рынке, что делает невозможным ее дальнейшую деятельность.
Подобную же шкалу можно подготовить и для вероятности реализации угрозы. Для ориентира берётся какой-то период времени, например один календарный год, и вероятность приводится для него. Напомним, что вероятность измеряется в долях единицы. 0 - событие исключено, 1 - событие точно произойдёт. Шкалу вероятности реализации угрозы можно представить таким образом:
Очень низкая - угроза практически никогда не будет реализована. Соответствует числовому интервалу вероятности от 0 до 0,25.
Низкая - вероятность реализации угрозы достаточно низкая. Соответствует числовому интервалу вероятности 0,25 до 0,5.
Средняя - вероятность реализации угрозы приблизительно равна 0,5
Высокая - угроза скорее всего будет реализована. Соответствует числовому интервалу вероятности от 0,5 до 0,75.
Очень высокая - угроза почти наверняка будет реализована. Соответствует числовому интервалу вероятности от 0,75 до 1.
В результате комбинации этих показателей получается собственно риск. Как отмечалось выше, в идеале риск выражается в деньгах, конкретной сумме. Но в начале процесса можно попробовать задать условную шкалу - низкий риск, средний, высокий. Ещё лучше, если риски будут измерены непосредственно в деньгах. Проще свести все эти данные в таблицу.

Сразу после выявления угроз и уязвимостей нужно принимать меры по снижению рисков - установку антивирусных программ, приобретение резервного оборудования и т.д. Главное же, что получает руководитель - не только перечень рисков, но и их критичность. Очевидно, что в первую очередь нужно снижать риски, которые угрожают существованию предприятия. Например, для онлайн СМИ неработающий сайт означает полную приостановку деятельности, для службы такси с заказом через интернет такой единой точкой отказа будет сервер обработки заказов. Когда риски ключевых активов снижены до разумных значений (а это тоже определяет руководитель), снова проводится анализ, выявляются новые риски, подбираются компенсирующие меры. Иногда риск не может быть снижен техническими мерами, тогда риск может быть застрахован. В приведённом выше примере это страхование рисков ДТП, также сейчас в Узбекистане обязательно страхование ответственности работодателя. Бывают и случаи, когда на риск невозможно повлиять. Например, деятельность, которой занимается предприятие, подпадает под запрет, или работа в новых условиях фактически невозможна. Примеры - работа казино, кредитных союзов, частных нотариусов (они то запрещались, то разрешались) и т.д. В результате изменения законодательства законные ещё вчера виды деятельности становятся невозможными сегодня. Но и тут есть практика риск-менеджмента - избежание риска, т.е. не заниматься тем видом деятельности, который имеет высокие регуляторные риски.
Конечной целью управления рисков (а это, как мы помним, в идеале реальные цифры потерь в денежном эквиваленте) - снижение их до приемлемого уровня. Когда даже реализация такого риска не нанесёт серьезного ущерба предприятию, такой остаточный риск принимается, так и говорят - принятие риска. Ближайшая аналогия - выходя из дома, мы понимаем, что существует риск, что с нами в пути что-то случится. Но мы, с учётом всех мер предосторожности, принимаем такой риск и идём по делам. А вот в случае глобальной эпидемии, риски, с которыми мы можем столкнуться на улице - слишком высоки, поэтому нам предписано, по возможности, оставаться дома.
Большой сложностью при управлении рисками является определение угроз для бизнеса, уязвимостей. Например, вряд ли кто-то всерьез в прошлом году рассматривал как угрозу всемирную эпидемию какого-то вируса. Поэтому, при первом внедрении процесса можно использовать в качестве угроз те события, которые приводили к убыткам в предыдущие периоды.
Принятие решения о том, как организация поступает с рисками, т.е. как она ими управляет, называется обработкой риска. Методов обработки рисков всего четыре:
1. Распределение (передача) риска. Пример такого метода – заключение договора со страховой компанией, которая при возникновении страхового случая покроет все возникшие убытки.
2. Сохранение (принятие) риска. В этом случае руководство предприятия осознает риски, но в виду отсутствия средств и персонала никак не может повлиять на величину риска, тогда риск просто принимается как данность. Другая причина сохранения риска - если затраты на его снижение превышают величину самого риска. В любом случае, величина остаточного риска должна одобряться/приниматься руководством организации.
3. Модификация (снижение) риска. Чаще всего к критическим системам и процессам, так или иначе, применяется снижение рисков, которое позволит снизить финансовые и репутационные затраты от возникновения инцидентов. Именно такие меры предложены в нашей таблице в графе «Предлагаемые меры по снижению рисков».
4. Предотвращение (избежание) риска. Организация отказывается от всех действий, которые могут сопровождаться риском. Проще говоря, волков бояться – в лес не ходить.

Управление рисками - непрерывный процесс. После применения мер по снижению рисков их нужно снова проанализировать, определить остаточные риски, находятся ли они в приемлемых значениях или нужны дополнительные меры по их снижению.
   
В качестве основных документов и инструкций по управлению рисками можно использовать:
● ISO 31000:2018 Международный стандарт «Менеджмент риска. Руководство» - базовый рамочный стандарт по управлению рисками независимо от специфики предприятия, в нём описываются самые общие подходы к управлению рисками.
● O‘z DSt ISO/IEC 27005:2013 Государственный стандарт Узбекистана «Информационная технология. Методы обеспечения безопасности. Управление рисками информационной безопасности» - профильный стандарт, содержит более подробные инструкции по управлению рисками применительно к ИТ.
● RH 45-129:2008 Руководящий документ «Страхование информационных рисков. Инструкция по проведению экспертизы (аудита) безопасности информационных систем.»

Для государственных органов будут полезны:
● Документ, изданный ГУП «Центр кибербезопасности», «Требования обеспечения информационной безопасности органов государственного и хозяйственного управления, государственной власти на местах». Сам документ не содержит подробного описания принципов риск-менеджмента, но определяет, что управление рисками должно стоять в основе всех управленческих процессов, быть включено в руководящие документы
● Документ, изданный ГУП «Центр кибербезопасности», - «Методические пособия по разработке политики информационной безопасности на территории Республики Узбекистан». В документе более подробно описывается как политика управления рисками должна быть встроена (имплементирована) в общий производственный процесс и как отражена в политике информационной безопасности предприятия.

Совсем кратко система управления рисками состоит из трёх пунктов:
1. Определить как, когда и кем принимаются важные для организации решения.
2. Учитывать риски при принятии всех управленческих решений.
3. Обеспечить понимание того, как принимаемые решения влияют на риски предприятия.
   
У компаний, которые постоянно связаны с высокими финансовыми рисками - страховые компании, банки, инвестиционные фонды, управление рисками является чуть ли не основным производственными процессом, там используются сложные методологии. Существуют отдельные специалисты, занимающиеся исключительно вопросами управления рисками. Для более простых случаев управление рисками входит в задачи руководства ключевых подразделений. Но, независимо от размера предприятия, внедрение практики управления рисками возможно только при понимании их важности и вовлеченности высшего руководства.
Не обязательно заполнять таблицы как в приведённом примере. На начальных этапах это может быть менее формализованный процесс. Важно понимание, что только анализ и учёт рисков позволит реализовать проактивное управление - предугадывать и смягчать последствия грядущих проблем.