Комментарии 10
Наверное, один из самых интересных вопросов — это вопрос о том, какая архитектура системы (или, например, организация производства) минимизирует риск. А тут "неожиданно" возникает такая проблема: нам нужна эффективная организация работы — значит, нужны эффективные СУБД — значит, нужны эффектвиные операционные системы и вычислительные сети — значит, нужна эффективная архитектура самих компьютеров. В результате, каждый уровень рассмотрения делает свой вклад в риск, и этот риск не устраним. Остаётся, только, минимизировать риск. А хотелось бы некоторые вещи совсем сократить.
Есть такой термин residual risk. Навсегда/полностью избавиться от присущих рисков вряд ли возможно, однако минимизировать их вполне можно, примером могу служить крупные банки, компании, зависящие от технологических платформ, где остановка, простой или неэффективная работа систем фактически равна денежным потерям, и как следствие неприемлемы. Возможно, стоит рассмотреть возможность оценки рисков и их снижения на раннем этапе выбора технологического решения и придерживаться общего подхода к выбору и реализации той или иной технологии.
Можете ли посоветовать какую-то живую с практической точки зрения методику качественной оценки рисков ИТ?
Основная пролема всех этих методологий, что разрыв между теорией (как написанов этой стаье) и практикой огромный. Обычно риски формально считаются из-за требований регулятора, но вот что бы ИТ-шники сами добровольно начали считать эти риски по структуированым методикам, не слышал. Такие организации если и есть, то это единицы и обычно банки/фин. организации.
Очень бы хотелось бы видеть живые практические примеры и уровень детализации этого процесса, который жизнеспосоен на практике.
(давно занимаюсь рисками ИБ, так что эти неблагодарные авгиевы конюшни понимаю)
Живые примеры, подходы – это фактически деньги консультантов, либо коммерческая тайна организаций, которые смогли у себя реализовать количественную/качественную оценку рисков. Тут весьма маловероятно найти какое-то готовое решение.
Если вернуться к содержимому статьи, то стоит попробовать реализовать хотя бы какое-то подобие правил по оценке риска через, например - методику по оценке/политику управления риском ИТ или ИБ. Тут нужно будет подумать и дать определение, если говорить в контексте качественной оценки – что является высоким/средним/низким риском и почему. Далее в этих документах определить подход к оценке, а также роли и обязанности участников. Во всяком случае я бы с этого начал.
Регулятор, по сути, лишь хочет проверить, что в организации есть хоть какое-то подобие управляемой технологической среды в отношении присущих рисков. И да, понимаю Вашу боль:) Если говорить об источниках вдохновения то есть сертификации – FRM/CRISC/CISSP, в подготовительной литературе к этим сертификациям есть идеи которые можно у себя в организации попробовать предложить/реализовать.
Из собственного опыта пока видел только одну вменяемую на практике методику оценки рисков - IRAM. Но еси честно, если ИБ это еще как-то нужно, то ИТшникам, в век всеобщей диджитализации и ускорения - никакие ткие формализации не нужны, даже наоборот - это их отвлекает от "творения". Обычно через общую матрицу оценки рисков ИБ можно закрыть процентов на 80 и оценку рисков и ИТ, т.к. целостность, доступность - оценивается и в ИБ тоже, конфиденциальность актуальна там и там.
Спасибо, что поделились. Думаю, всем будет полезно узнать. Сам этой методикой не пользовался, но почитаю.
По поводу нужности управления и формализации, да, к сожалению, есть такая проблема. За частую инициатива и поддержка комплексного управления рисками идет не с верху, а со стороны первых линий защиты.
Из опыта могу сказать, что в большинстве случаев все меняется при смене статуса организации на "публичную", а также после реализации рисковых событий с последствиями. Ну и при смене высшего менеджмента.
По поводу автоматизации и помех, даже в таких случаях при наличии политики управления рисками (т.е. документа обязывающего), учитывающей подход и обязанности участников процессов организации, можно встраивать управление рисками и выработку снижающих риски мероприятий в процессы разработки ПО, даже в случае например использования философии Agile.
Спасибо за статью, очень интересно и есть много нового для меня, которое ещё нужно "переварить". Управление рисками - это та область в которой мне ещё нужно сложить знания в пазл :) Потому и вопрос такой.
Кто является целевой аудиторией когда подготавливается оценка рисков и кому показывается регистр рисков? Эти регистры стали просить показывать многие, в том числе учебные организации, финансирующие организации и т.п. Они во время показа регистра просто сдерживаются от впадения в спячку.
Но моё впечатление такое, что они полезны только на работе, когда например идёт встреча по проекту в рабочей группе и нужно объяснить или обсудить с членами рабочей группы и руководителем какие есть риски, насколько они вероятны, насколько вредны и какой план действий. Насколько понимаю, полезно ещё для руководства компании - помогает планировать. Есть кто-то ещё, кому они будут полезны?
Спасибо за вопрос, хороший вопрос. Если начать с реестра/регистра рисков – то это всего лишь инструмент. Не стоит его возводить в разряд «библии». Реестр – это живой, регулярно обновляемый инструмент.
Если говорить о том для кого-же эта статья? Признаться писал ее для широкого круга читателей, кому интересно узнать что-то новое по этой теме. За свою практику очень часто сталкивался с ситуацией, когда подход к управлению рисками ставился в обязанность служб ИТ/ИБ, бухгалтерии, налогов и т.д. Что по моему личному мнению совсем неверно. Фактически у этих служб головных болей выше крыши, а им еще набрасывают обязанность разобраться в рисках и управлять ими. Разработкой методики управления риском – занимаются люди имеющие необходимые знания. Управление риском – занимаются все (включая водителей и уборщиц).
Давайте вернемся к написанной статье, в частности к трем линиям защиты. Чтобы реализовать нечто подобное нужна личная заинтересованность высшего менеджмента, акционеров, совета директоров. Если там есть понимание необходимости и выгод, то далее просто необходимо определить 1 – методы управления и 2 – роли и ответственность участников.
Если вернуться к частностям, то я думаю любой человек кому интересна эта тема, может почитать, подготовиться и просто повысить свою экспертизу с тем, чтобы нести эти знания в корпоративную среду и тем самым формировать корпоративную среду управления риском. Об источниках знаний и вдохновения написал в ответе выше.
Хорошая, структурированная статья! Большое спасибо!
Публикации
Управление риском ИТ