В чем ценность уровней зрелости? Как они влияют на эффективность бизнеса? На защищенность бизнеса?
Самое большое заблуждение во всей этой истории в том, что знание эфемерного уровня зрелости никак не влияет на защищенность организации. На прибыльность организации или ее эффективность. А лишь отвлекает мысли и ресурсы на сомнительный по своей пользе анализ состояния процессов Компании, включая ИБ.
Более того, градация, позволяет давать оценочные суждения, т.е. дают возможность манипулирования. Подобные оценочные суждения, в большинстве своем крайне мало дадут пользы в случае возникновения нештатной ситуации, аварии, снижения прибыльности и других проблем, которым подвергается организация.
Сложно представить, что кто-то скажет: "Мы просто недостаточно зрелые..., по этому мы потеряли/не достигли/не смогли/нарушили и т.д."
Если о банковской сфере, то в какой-то мере свод различных рекомендаций Базельского Комитета.
Но как я и говорил ранее, если есть возможность, организации и непосредственно риск-специалисты используют разные истоничники (как отчественные рекомендации и требования от ФСТЭК и ГОСТ, так и зарубежные практики), выбирая наиболее подходящие методы и инструменты для их конкретной среды и целей бизнеса.
И да и нет. Зависит от того с какой стороны смотреть. Базис дан. Дан в различных источниках. Т.е. отправная точка для последующего развития.
Можно согласиться, с тем, что без стандартизации, растет заивисимость организации от компетенций сотрудников, что порождает различные отклонения и потенциальное снижение эффективности.
Однако, наравне с этим, управление рисками эволюционирует, во много благодаря изобретениям экспертов в этой области, кто так или иначе отклонился от предлагаемого, в сторону улучшения, упрощения, оптимизации и подстройки инструментов под свои нужды, под нужды бизнеса.
Я ориентируюсь на разные материалы, например FRM, CRISC.
Может происходить заимствование и адаптация существующей терминологии из различных стандартов, фреймворков и практик. Цель - обеспечить достижение целей организации, через один из подвидов процессов управления.
Добрый день. Если я Вас правильно понял, то Ваш вопрос – Существует ли некий стандарт, определяющий сущности, градацию и связь между всеми категориями сущностей управления риском ИТ?
Если кратко, то ответ нет, я с таким не сталкивался. Каждая организация сама определяет таксономию и языковой базис.
Если более развернуто, то в различных стандартах и фреймворках как-правило приводится общая, основная терминология. На практике, организации часто реализуют свой языковой базис в процессе управления рисками, в соответствии со своими целями и знаниями, разделяя сущности, в зависимости от потребностей и пожелания владельцев процессов и других стейкхолдеров. По опыту - финансовые институты используют более гранулированный подход к работе с рисками, если сравнивать с организациями из других сфер экономики.
Для кого-то достаточно группировки всех рисков присущих операционной деятельности организации в группу «Операционных рисков», включающую и «риски ИТ», и «риски ИБ». Какие-то организации, для удобства управления и большей гранулярности, риски ИТ и ИБ выделяют в отдельные группы равнозначные группе «Операционных рисков».
Также, таксономия, вкладываемый смысл в сущности, может зависеть от направления деятельности организации, если основной продукт организации – это разработка ПО, то терминология, например, из ITIL, Agile, COBIT, переходит и в терминологию, используемую в процессе управления рисками.
Тогда, получается, ничего не меняем? Ответственность на владельцах процессов, если что-то пойдет не так? Но если что-то пойдет не так и ответственность известна, то кому от этого легче будет?
Спасибо за Ваш комментарий. Обладая пониманием рисков, потребностей в контроле, можно более эффективно управлять ресурсами, включая человеческие. И возможно, там, где штат «раздут» или бесполезен, можно его сократить, а там, где ИТ не «вывозит», менеджмент, обладая информацией, например о потребностях в увеличении производительности, или нехватки разработчиков, может получить хороший «рычаг» и обоснованно запросить оптимизацию, закупку нового оборудования или увеличение штата.
Также, если говорить о том, кто же все это будет делать, то для ИТ и ИБ менеджмента важно понимать основы управления рисками и внутреннего контроля.
Но как-правило, в компаниях, уже существуют департаменты риск-менеджмента и СВК, более того, существуют требования к управлению рисками присущими ИТ, например для финансовых организаций действует ФЗ 716, что подразумевает финансовые затраты на организацию процесса управления рисками и внутреннего контроля.
Спасибо за Ваш комментарий! Важный момент, с которым столкнулись многие Российские компании, начиная с 2014 года и по текущий момент. Вы говорите о «Санкционном риске», «Риске поставщика». В моем понимании, в текущей ситуации, есть несколько путей решения – поиск подрядчиков, обладающих компетенциям в продуктах SAP (есть компании, которые развивают сервис поддержки SAP, Oracle и других продуктов, компаний ушедших с Российского рынка).
Другой способ, как сейчас делают многие крупные компании, это переход на ПО либо собственной разработки, либо разработки Российских поставщиков ПО (таких тоже становится все больше и больше). Но важно учитывать подобные риски (санкционные) и планировать мероприятия по их снижению.
Спасибо за комментарий. Все что Вы перечислили, фактически можно назвать элементами контроля. Статья как раз о том, чтобы помочь привнести осознанность, предсказуемость, регулярность и понятность в процесс контроля над различными процессами ИТ. С тем, чтобы "пути рисков" стали более предсказуемы, а компания и менеджмент более готовыми к возможным ситуациям, когда что-то может пойти не так, или идет не так.
Спасибо, что поделились. Думаю, всем будет полезно узнать. Сам этой методикой не пользовался, но почитаю.
По поводу нужности управления и формализации, да, к сожалению, есть такая проблема. За частую инициатива и поддержка комплексного управления рисками идет не с верху, а со стороны первых линий защиты.
Из опыта могу сказать, что в большинстве случаев все меняется при смене статуса организации на "публичную", а также после реализации рисковых событий с последствиями. Ну и при смене высшего менеджмента.
По поводу автоматизации и помех, даже в таких случаях при наличии политики управления рисками (т.е. документа обязывающего), учитывающей подход и обязанности участников процессов организации, можно встраивать управление рисками и выработку снижающих риски мероприятий в процессы разработки ПО, даже в случае например использования философии Agile.
Спасибо за вопрос, хороший вопрос. Если начать с реестра/регистра рисков – то это всего лишь инструмент. Не стоит его возводить в разряд «библии». Реестр – это живой, регулярно обновляемый инструмент.
Если говорить о том для кого-же эта статья? Признаться писал ее для широкого круга читателей, кому интересно узнать что-то новое по этой теме. За свою практику очень часто сталкивался с ситуацией, когда подход к управлению рисками ставился в обязанность служб ИТ/ИБ, бухгалтерии, налогов и т.д. Что по моему личному мнению совсем неверно. Фактически у этих служб головных болей выше крыши, а им еще набрасывают обязанность разобраться в рисках и управлять ими. Разработкой методики управления риском – занимаются люди имеющие необходимые знания. Управление риском – занимаются все (включая водителей и уборщиц).
Давайте вернемся к написанной статье, в частности к трем линиям защиты. Чтобы реализовать нечто подобное нужна личная заинтересованность высшего менеджмента, акционеров, совета директоров. Если там есть понимание необходимости и выгод, то далее просто необходимо определить 1 – методы управления и 2 – роли и ответственность участников.
Если вернуться к частностям, то я думаю любой человек кому интересна эта тема, может почитать, подготовиться и просто повысить свою экспертизу с тем, чтобы нести эти знания в корпоративную среду и тем самым формировать корпоративную среду управления риском. Об источниках знаний и вдохновения написал в ответе выше.
Живые примеры, подходы – это фактически деньги консультантов, либо коммерческая тайна организаций, которые смогли у себя реализовать количественную/качественную оценку рисков. Тут весьма маловероятно найти какое-то готовое решение.
Если вернуться к содержимому статьи, то стоит попробовать реализовать хотя бы какое-то подобие правил по оценке риска через, например - методику по оценке/политику управления риском ИТ или ИБ. Тут нужно будет подумать и дать определение, если говорить в контексте качественной оценки – что является высоким/средним/низким риском и почему. Далее в этих документах определить подход к оценке, а также роли и обязанности участников. Во всяком случае я бы с этого начал.
Регулятор, по сути, лишь хочет проверить, что в организации есть хоть какое-то подобие управляемой технологической среды в отношении присущих рисков. И да, понимаю Вашу боль:) Если говорить об источниках вдохновения то есть сертификации – FRM/CRISC/CISSP, в подготовительной литературе к этим сертификациям есть идеи которые можно у себя в организации попробовать предложить/реализовать.
Есть такой термин residual risk. Навсегда/полностью избавиться от присущих рисков вряд ли возможно, однако минимизировать их вполне можно, примером могу служить крупные банки, компании, зависящие от технологических платформ, где остановка, простой или неэффективная работа систем фактически равна денежным потерям, и как следствие неприемлемы. Возможно, стоит рассмотреть возможность оценки рисков и их снижения на раннем этапе выбора технологического решения и придерживаться общего подхода к выбору и реализации той или иной технологии.
В чем ценность уровней зрелости? Как они влияют на эффективность бизнеса? На защищенность бизнеса?
Самое большое заблуждение во всей этой истории в том, что знание эфемерного уровня зрелости никак не влияет на защищенность организации. На прибыльность организации или ее эффективность. А лишь отвлекает мысли и ресурсы на сомнительный по своей пользе анализ состояния процессов Компании, включая ИБ.
Более того, градация, позволяет давать оценочные суждения, т.е. дают возможность манипулирования. Подобные оценочные суждения, в большинстве своем крайне мало дадут пользы в случае возникновения нештатной ситуации, аварии, снижения прибыльности и других проблем, которым подвергается организация.
Сложно представить, что кто-то скажет: "Мы просто недостаточно зрелые..., по этому мы потеряли/не достигли/не смогли/нарушили и т.д."
То, с чего бы я начал, но учитывая и отечественные стандарты:
https://www.bis.org/bcbs/publ/d515.htm
https://www.bis.org/bcbs/publ/d516.htm
Если о банковской сфере, то в какой-то мере свод различных рекомендаций Базельского Комитета.
Но как я и говорил ранее, если есть возможность, организации и непосредственно риск-специалисты используют разные истоничники (как отчественные рекомендации и требования от ФСТЭК и ГОСТ, так и зарубежные практики), выбирая наиболее подходящие методы и инструменты для их конкретной среды и целей бизнеса.
И да и нет. Зависит от того с какой стороны смотреть. Базис дан. Дан в различных источниках. Т.е. отправная точка для последующего развития.
Можно согласиться, с тем, что без стандартизации, растет заивисимость организации от компетенций сотрудников, что порождает различные отклонения и потенциальное снижение эффективности.
Однако, наравне с этим, управление рисками эволюционирует, во много благодаря изобретениям экспертов в этой области, кто так или иначе отклонился от предлагаемого, в сторону улучшения, упрощения, оптимизации и подстройки инструментов под свои нужды, под нужды бизнеса.
Я ориентируюсь на разные материалы, например FRM, CRISC.
Может происходить заимствование и адаптация существующей терминологии из различных стандартов, фреймворков и практик. Цель - обеспечить достижение целей организации, через один из подвидов процессов управления.
Добрый день. Если я Вас правильно понял, то Ваш вопрос – Существует ли некий стандарт, определяющий сущности, градацию и связь между всеми категориями сущностей управления риском ИТ?
Если кратко, то ответ нет, я с таким не сталкивался. Каждая организация сама определяет таксономию и языковой базис.
Если более развернуто, то в различных стандартах и фреймворках как-правило приводится общая, основная терминология. На практике, организации часто реализуют свой языковой базис в процессе управления рисками, в соответствии со своими целями и знаниями, разделяя сущности, в зависимости от потребностей и пожелания владельцев процессов и других стейкхолдеров. По опыту - финансовые институты используют более гранулированный подход к работе с рисками, если сравнивать с организациями из других сфер экономики.
Для кого-то достаточно группировки всех рисков присущих операционной деятельности организации в группу «Операционных рисков», включающую и «риски ИТ», и «риски ИБ». Какие-то организации, для удобства управления и большей гранулярности, риски ИТ и ИБ выделяют в отдельные группы равнозначные группе «Операционных рисков».
Также, таксономия, вкладываемый смысл в сущности, может зависеть от направления деятельности организации, если основной продукт организации – это разработка ПО, то терминология, например, из ITIL, Agile, COBIT, переходит и в терминологию, используемую в процессе управления рисками.
Тогда, получается, ничего не меняем? Ответственность на владельцах процессов, если что-то пойдет не так? Но если что-то пойдет не так и ответственность известна, то кому от этого легче будет?
Хорошо, а как бы Вы поступили? Или уже реализовали?
Хорошая мысль. Стоит отдельной проработки. Однако, возможно, уже реализована в инструментах анализа кода. Спасибо, что поделились!
Привет! Спасибо, хорошая идея:) нужно подумать
Спасибо за Ваш комментарий. Обладая пониманием рисков, потребностей в контроле, можно более эффективно управлять ресурсами, включая человеческие. И возможно, там, где штат «раздут» или бесполезен, можно его сократить, а там, где ИТ не «вывозит», менеджмент, обладая информацией, например о потребностях в увеличении производительности, или нехватки разработчиков, может получить хороший «рычаг» и обоснованно запросить оптимизацию, закупку нового оборудования или увеличение штата.
Также, если говорить о том, кто же все это будет делать, то для ИТ и ИБ менеджмента важно понимать основы управления рисками и внутреннего контроля.
Но как-правило, в компаниях, уже существуют департаменты риск-менеджмента и СВК, более того, существуют требования к управлению рисками присущими ИТ, например для финансовых организаций действует ФЗ 716, что подразумевает финансовые затраты на организацию процесса управления рисками и внутреннего контроля.
Спасибо за Ваш комментарий! Важный момент, с которым столкнулись многие Российские компании, начиная с 2014 года и по текущий момент. Вы говорите о «Санкционном риске», «Риске поставщика». В моем понимании, в текущей ситуации, есть несколько путей решения – поиск подрядчиков, обладающих компетенциям в продуктах SAP (есть компании, которые развивают сервис поддержки SAP, Oracle и других продуктов, компаний ушедших с Российского рынка).
Другой способ, как сейчас делают многие крупные компании, это переход на ПО либо собственной разработки, либо разработки Российских поставщиков ПО (таких тоже становится все больше и больше). Но важно учитывать подобные риски (санкционные) и планировать мероприятия по их снижению.
Спасибо за комментарий. Все что Вы перечислили, фактически можно назвать элементами контроля. Статья как раз о том, чтобы помочь привнести осознанность, предсказуемость, регулярность и понятность в процесс контроля над различными процессами ИТ. С тем, чтобы "пути рисков" стали более предсказуемы, а компания и менеджмент более готовыми к возможным ситуациям, когда что-то может пойти не так, или идет не так.
Спасибо, что поделились. Думаю, всем будет полезно узнать. Сам этой методикой не пользовался, но почитаю.
По поводу нужности управления и формализации, да, к сожалению, есть такая проблема. За частую инициатива и поддержка комплексного управления рисками идет не с верху, а со стороны первых линий защиты.
Из опыта могу сказать, что в большинстве случаев все меняется при смене статуса организации на "публичную", а также после реализации рисковых событий с последствиями. Ну и при смене высшего менеджмента.
По поводу автоматизации и помех, даже в таких случаях при наличии политики управления рисками (т.е. документа обязывающего), учитывающей подход и обязанности участников процессов организации, можно встраивать управление рисками и выработку снижающих риски мероприятий в процессы разработки ПО, даже в случае например использования философии Agile.
Спасибо за вопрос, хороший вопрос. Если начать с реестра/регистра рисков – то это всего лишь инструмент. Не стоит его возводить в разряд «библии». Реестр – это живой, регулярно обновляемый инструмент.
Если говорить о том для кого-же эта статья? Признаться писал ее для широкого круга читателей, кому интересно узнать что-то новое по этой теме. За свою практику очень часто сталкивался с ситуацией, когда подход к управлению рисками ставился в обязанность служб ИТ/ИБ, бухгалтерии, налогов и т.д. Что по моему личному мнению совсем неверно. Фактически у этих служб головных болей выше крыши, а им еще набрасывают обязанность разобраться в рисках и управлять ими. Разработкой методики управления риском – занимаются люди имеющие необходимые знания. Управление риском – занимаются все (включая водителей и уборщиц).
Давайте вернемся к написанной статье, в частности к трем линиям защиты. Чтобы реализовать нечто подобное нужна личная заинтересованность высшего менеджмента, акционеров, совета директоров. Если там есть понимание необходимости и выгод, то далее просто необходимо определить 1 – методы управления и 2 – роли и ответственность участников.
Если вернуться к частностям, то я думаю любой человек кому интересна эта тема, может почитать, подготовиться и просто повысить свою экспертизу с тем, чтобы нести эти знания в корпоративную среду и тем самым формировать корпоративную среду управления риском. Об источниках знаний и вдохновения написал в ответе выше.
Спасибо:)
Живые примеры, подходы – это фактически деньги консультантов, либо коммерческая тайна организаций, которые смогли у себя реализовать количественную/качественную оценку рисков. Тут весьма маловероятно найти какое-то готовое решение.
Если вернуться к содержимому статьи, то стоит попробовать реализовать хотя бы какое-то подобие правил по оценке риска через, например - методику по оценке/политику управления риском ИТ или ИБ. Тут нужно будет подумать и дать определение, если говорить в контексте качественной оценки – что является высоким/средним/низким риском и почему. Далее в этих документах определить подход к оценке, а также роли и обязанности участников. Во всяком случае я бы с этого начал.
Регулятор, по сути, лишь хочет проверить, что в организации есть хоть какое-то подобие управляемой технологической среды в отношении присущих рисков. И да, понимаю Вашу боль:) Если говорить об источниках вдохновения то есть сертификации – FRM/CRISC/CISSP, в подготовительной литературе к этим сертификациям есть идеи которые можно у себя в организации попробовать предложить/реализовать.
Есть такой термин residual risk. Навсегда/полностью избавиться от присущих рисков вряд ли возможно, однако минимизировать их вполне можно, примером могу служить крупные банки, компании, зависящие от технологических платформ, где остановка, простой или неэффективная работа систем фактически равна денежным потерям, и как следствие неприемлемы. Возможно, стоит рассмотреть возможность оценки рисков и их снижения на раннем этапе выбора технологического решения и придерживаться общего подхода к выбору и реализации той или иной технологии.