что такое информационные риски

Информационные риски.

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

ИТ-риски можно разделить на две категории:

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

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

Классификация информационных рисков

Все информационные риски можно классифицировать на различные группы на основании нескольких критериев:

1. По источникам информационные риски делятся на внутренние и внешние;

2. По характеру – на преднамеренные и непреднамеренные;

3. По виду – прямые или косвенные;

4. По результату – нарушение достоверности информации, нарушение актуальности информации, нарушение полноты информации, нарушение конфиденциальности и др.

5. По механизму воздействия: стихийные бедствия, аварии, ошибки специалистов и др.

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

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

Информационные риски, которые наносят ущерб предприятию, являющийся следствием воздействия рисков на бизнес-процессы предприятия или внешнюю среду, будем называть косвенными информационными рисками.

Процесс минимизации ИТ-рисков:

· Выявление возможных проблемы, а затем определение способов их решения.

· Определение сроков интеграции новых технологий при необходимости, по причине преобразования или слияния организации.

· Оптимизация бизнес-процессов организации.

· Обеспечение защиты интеллектуальной собственности организации и ее клиентов.

· Разработка порядка действий при форс-мажорных обстоятельствах.

· Определение фактических потребностей информационных ресурсов.

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

Политические риски.

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

Политические риски подразделяются на группы:

Риск потери собственности (например, национализация или экспроприация без надлежащей компенсации).

Риск трансферта, связанный с ограничением экспорта продукции или ресурсов, с ограничениями относительно конвертации локальной валюты в иностранную и осуществлением расчётов по внешнеэкономическим контрактам.

Контрактный риск, т.е. риск расторжения контракта вследствие действий правительства страны, в которой находится компания-контрагент.

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

Операционный риск, который затрагивает свободу действий руководителей компаний.

Риск военных действий, гражданских беспорядков, смены власти.

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

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

Также политические риски можно разделить на:

· риск, вызванный регулятивными мерами, затрагивающими всех субъектов;

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

· риск, вызванный выборочным вмешательством, которое влияет на деятельность одного определенного предприятия.

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

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

· действия органов власти:

· политического характера (конфискация активов, введение эмбарго, изменение законодательства);

· административного характера (аннулирование лицензий);

· макроэкономического характера (запрет на конвертацию или перевод средств за границу, кардинальные изменения в проводимой экономической политике);

· микроэкономического или финансового характера (одностороннее расторжение контракта государственным предприятием, неплатеж со стороны государственных покупателей, несоблюдение арбитражных постановлений, непоставка продукции).

Источник

Что такое информационные риски

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

Программа разработана совместно с АО «Сбербанк-АСТ». Слушателям, успешно освоившим программу, выдаются удостоверения установленного образца.

Обзор документа

Разъяснения Банка России от 11 ноября 2020 г. № 716-Р-2020/11 «О видах риска информационной безопасности»

Кроме того, какие риски следует относить к другим видам риска, указанным в абзаце втором пункта 7.2 Положения Банка России N 716-П?

2. Соответствует ли определение «компьютерная атака», используемое в Положении Банка России N 716-П, определению термина «компьютерная атака», используемому в следующий стандартах: Р 50.1.053-2005, Р 51275-2006, Р 50.1.056-2005?

3. Согласно пункту 4.1 приложения 5 к Положению Банка России N 716-П к прямым потерям от реализации событий риска информационной безопасности, в том числе киберриска, относятся выплаты компенсаций клиентам и контрагентам в результате осуществления переводов денежных средств без согласия клиента. Просим пояснить, относятся ли данные компенсации клиентам и контрагентам, выполняемые кредитной организацией на добровольной основе, к прямым потерям от реализации событий риска информационной безопасности, в том числе киберриска?

4. Какие события риска информационной безопасности, в том числе киберриска, могут привести к качественным потерям, указанным в пункте 4.3 приложения 5 к Положению Банка России N 716-П, в частности к «возникновению уязвимостей в объектах информационной инфраструктуры, программном обеспечении и приложениях, банковских процессах», а также какие потери могут быть отнесены к виду «другие потери качества объектов информационной инфраструктуры кредитной организации»?

5. Каким образом следует учитывать в соответствии с требованиями Положения Банка России N 716-П риск информационной безопасности, который не был реализован, но в то же время может являться источником потерь в будущем?

Перечисленные случаи хищения денежных средств у клиентов кредитной организации относятся к «другим видам риска информационной безопасности, связанным с обработкой (хранением, уничтожением) информации без использования объектов информационной инфраструктуры», указанному в абзаце третьем пункта 7.2 Положения Банка России N 716-П, то есть не являются событиями киберриска, определенными в абзаце втором пункта 7.2 Положения Банка России N 716-П, так как они совершаются без преднамеренных действий в целях нарушения или прекращения функционирования объектов информационной инфраструктуры кредитной организации, а только лишь используют работающую инфраструктуру кредитной организации для целей хищения путем применения незаконно полученных кодов авторизации операций, доступа или иных критериев идентификации вне информационной инфраструктуры кредитной организации. Кредитная организация вправе самостоятельно разработать в соответствии с пунктом 3.4 Положения Банка России N 716-П дополнительную классификацию видов (способов) несанкционированного получения клиентских кодов авторизации или идентификации в рамках дополнительной классификации источников событий риска информационной безопасности по источнику «внешние причины» в соответствии с пунктом 2.4 приложения 5 к Положения Банка России N 716-П, а также самостоятельно разработать в соответствии с пунктом 3.8 Положения Банка России N 716-П для разновидностей этих случаев последующие уровни классификации в рамках типа события «преднамеренные действия третьих лиц», указанного в подпункте 3.6.2 пункта 3.6 Положения Банка России N 716-П.

Термин «компьютерная атака» применяется в Положении Банка России N 716-П в значении, определенном в перечисленных в вопросе ГОСТах.

В соответствии с подпунктом 3.12.3 пункта 3.12 Положения Банка России N 716-П компенсации потерь клиентов из-за действий третьих лиц, выплаченные кредитной организацией во внесудебном порядке, являются прямыми потерями от реализации операционного риска и должны регистрироваться в базе событий безотносительно того, принудительно или по собственной инициативе («доброй воле») кредитная организация осуществила данную компенсацию, с признанием или не признанием своей «вины».

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

Обращаем внимание, что категория «другие потери качества объектов информационный инфраструктуры кредитной организации» создана для того, чтобы кредитные организации могли относить к данной категории другие потери, не перечисленные в приложении 5 к Положению Банка России N 716-П.

В целях регулирования работы кредитной организации с операционными рисками, которые не реализовались в настоящий момент, но могут реализоваться в будущем, Положением Банка России N 716-П предусмотрены процедуры управления операционным риском, определяемые в соответствии с подпунктом 2.1.1 пункта 2.1 Положения банка России N 716-П (идентификация операционного риска), подпунктом 2.1.4 пункта 2.1 Положения банка России N 716-П (например, оценка ожидаемых потерь от операционного риска), подпункта 2.1.5 пункта 2.1 Положения банка России N 716-П (качественная оценка операционного риска, которая предусматривает проведение самооценки операционного риска, где есть возможность анализировать вероятность и влияние не реализовавшихся рисков, но которые могут реализоваться). Также подпункт 2.1.5 пункта 2.1 Положения банка России N 716-П предусматривает проведение сценарного анализа операционного риска в отношении операционных рисков, а также их источников, которые не реализовались в кредитной организации, но у которых есть вероятность реализации с высоким уровнем потерь или других последствий.

Все вышеперечисленные процедуры применимы к управлению риском информационной безопасности как части операционного риска.

Обращаем внимание, что организатором и ответственным за методологию данных процедур является подразделение, ответственное за организацию управления операционным риском.

Обзор документа

Банк России выпустил разъяснения по видам рисков информационной безопасности, по их отнесению к событиям киберриска, а также по прямым потерям от реализации операционного риска.

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

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

Источник

Как управлять рисками IT-проекта

Если какая-нибудь неприятность может произойти, она случится — гласит закон Мерфи. И сфера ИТ не исключение.

Команда SEBEKON рассказывает, как работать с рисками в IT-проекте, чтобы риски не стали управлять проектом.

В этой статье под IT-проектом подразумевается разработка сложного веб-ресурса — например, b2b-портала или интернет-магазина с множественными интеграциями с внешними системами.

Дилемма управления рисками любого IT-проекта простая: перестраховаться и заложить все угрозы в бюджет проекта, который вырастет до небес, или пропустить часть рисков — и тогда будет велика вероятность не завершить проект вовсе или получить неудовлетворительный результат.

Но даже если принять первый вариант как единственно верный, от рисков никто не застрахован.

Менеджер проектов компании SEBEKON

Генеральный директор компании SEBEKON

Как работать с рисками

Обычно ожидаемая реализация проекта не совпадает с реальной работой:

На практике управление рисками — это тонкий баланс между разумным и достаточным.

Существуют пять основных инструментов для работы с рисками:

Рассмотрим каждый из них подробнее.

Выявлять риски

Риски проекта определяются во время фиксации требований к проекту и отражаются в уставе или концепции проекта.

Устав проекта ― это документ, в котором зафиксирована основная информация о проекте: потребности заказчика, бизнес-задачи, высокоуровневые требования к проекту, критерии успешной реализации.

Концепция проекта ― документ, в котором собраны подробные характеристики проекта.

Выбор документа зависит от масштаба проекта.

Чтобы выявить риски, нужно проанализировать множество информации и сопоставить, как те или иные факторы влияют на возникновение рисков.

Рассказываем, что стоит сделать для этого.

Учесть опыт предыдущих проектов

Для примера возьмём согласование дизайна страниц сайта.

Дизайн всегда субъективная история, и нужно закладывать дополнительное время на решение вопросов в стиле «а давайте попробуем немного светлее или поиграем со шрифтами». Заказчик должен ещё до начала работ понимать, что любое изменение, требующее нескольких минут работы, в итоге выливается в часы и дни согласования.

Часто на стороне заказчика необходимо согласовать дизайн с несколькими департаментами — и не всегда сотрудники этих отделов могут быстро подтвердить изменения. Если речь идёт о крупной компании, то руководителю проекта придётся назначать собрание или созвон для обсуждения дизайна. И не всегда это получится сделать в ближайшие дни — часто согласование растягивается на недели, а то и на месяцы.

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

Оценить новизну критичных требований — как для заказчика, так и для исполнителя

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

Принять во внимание особенности внутренней инфраструктуры заказчика

Самый очевидный пример ― требования к безопасности, которые могут существенно отодвинуть срок старта проекта. Это связано с необходимостью получения доступов в систему заказчика или требований по использованию определённого, разрешённого на стороне заказчика ПО, которые повлекут за собой дополнительную проработку архитектуры проекта.

Не забыть про покупку серверного оборудования или про согласование хостинга

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

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

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

Заложить внедрение интеграции проекта с внутренними системами заказчика

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

В итоге когда приходит время интеграций проекта с CRM-, ERP- и другими системами работа останавливается на неопределённый срок, потому что менеджер проекта со стороны заказчика не может оперативно подготовить необходимую документацию и доступы для интеграций.

Выявить заинтересованность в проекте ключевых стейкхолдеров

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

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

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

Например, руководитель департамента логистики должен был проверить сценарий по расчёту доставки товара. Но он был занят текущей деятельностью, мельком просмотрел ТЗ и отправил с пометкой «принято». В ходе тестирования этого сценария оказалось, что он должен быть реализован другим способом. В итоге пришлось откатить проект назад: пересмотреть внесение правок в сценарий, затем внести эти правки в ТЗ, согласовать это со всеми стейкхолдерами, переделать сценарий и заново его протестировать. На всё это ушло больше месяца, а кроме того, заказчику пришлось оплатить дополнительные работы.

Для наглядности можно составить матрицу влияния стейкхолдеров на проект и методы взаимодействия с ними. Например, такую:

Изучить соответствующее законодательство, поговорить с экспертами и опытными коллегами

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

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

Оценивать риски

Риски обязательно соотносятся с критичностью или некритичностью требований к проекту в целом.

Критичные требования отвечают за целевую функцию разрабатываемого продукта, включают необходимую инфраструктуру и возможности для разработки MVP.

К некритичным относятся остальные требования.

Для каждого риска выявляют следующее:

На базе этих параметров строится матрица рисков.

Остановимся подробнее на степени управляемости рисками.

Управляемые — риски, которые можно предугадать и акцентировать на них внимание уже на начальном этапе проекта, определив для них ответственных и держа под контролем.

Самый очевидный пример ― опять же дизайн сайта. Сразу понятно, что на этапе согласования могут возникнуть сложности, доработки, переделки и бесконечные правки. Поэтому мы на старте проговариваем этот момент с заказчиком, согласовываем, кто будет лицом, принимающим окончательное решение, и письменно фиксируем максимально допустимое количество дней на согласование макета — в среднем, по нашему опыту, это обычно 5.

Неуправляемые — возможные риски, появление которых мы не можем предотвратить.

Например, один из неуправляемых рисков ― более ранний выпуск конкурентами на рынок похожего продукта.

Другой пример — подключение платёжной системы. В описании API говорится, что в ответ на запрос придёт одна строка, а по факту приходит три. И платёжная система на своей стороне не готова вносить правку, потому что на это нужно время, при этом тысячи пользователей этой системы об этом не просили. Так как нужна именно одна строка, разработчику приходится самостоятельно решать этот вопрос, тратить больше запланированного времени на разработку и фиксацию данной ошибки.

Запланировать мероприятия по предотвращению рисков

Для предотвращения рисков нужно понимать, как от них защищаться.

Грамотно выстроенные коммуникации внутри проекта играют главную роль для защиты от рисков и оказывают огромное влияние на успех проекта. Это означает, что все процессы взаимодействия регламентированы, роли всех членов команды закреплены и всё это зафиксировано в понятном для участников формате.

Важно сразу выстроить коммуникацию с заказчиками проекта, создать большую команду из представителей обеих сторон и все вопросы решать совместно.Для этого фиксируем ответственных для каждого этапа проекта в матрице «Роли и зоны ответственности» (RACI Matrix).

В матрице предусмотрены четыре роли:

Однако просто зафиксировать ответственных мало — нужно проанализировать заполненную матрицу, чтобы не было перекоса в одну роль:

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

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

Также определяем инфраструктуру проекта:

Профессия

Project
manager

Предусмотреть действия при наступлении рисков

Стоит предусмотреть резервный план (contingency plan) на случай непредвиденных обстоятельств.

Задача этапа — выполнить его наиболее эффективным образом, а также собрать и проанализировать информацию о наступившем риске на будущее.

Не стоит тратить время на поиск виноватых — лучше предпринять всё необходимое, чтобы двигаться дальше и продолжать реализацию проекта. На этом этапе главная роль принадлежит коммуникации и поиску оптимального решения.

В нашей практике был проект, когда нужно было разделить один сайт, реализованный на Bitrix, на два. Один из них надо было интегрировать со штатной версией 1С.

Заказчик предполагал, что на разработку на своей стороне их специалисту понадобится три недели. По факту оказалось, что ранее созданная интеграция полностью кастомная — комплекты, цвета, размеры, остатки — и на стороне заказчика нет эксперта, который смог бы выполнить задачу. Пришлось подключиться нам и помочь с решением по интеграции. Дополнительно были пересмотрены сроки проекта.

Мониторить риски

Ситуация на проекте постоянно меняется ― это нужно принять как аксиому.

Например, если работать по Agile, то перед каждым новым спринтом могут меняться параметры проекта, обрисованные на этапе обсуждения. Следовательно нужно отслеживать изменения параметров рисков, корректируя внутрикомандный перечень топ-10 рисков.

На этапе мониторинга — если возвратиться к примеру с Agile, то это нужно делать в начале каждого спринта — важно отслеживать новые риски, изменять статус выявленных рисков, корректировать планы. На протяжении проекта перечень может значительно измениться.

К примеру, на крупном проекте на финальном этапе в команде заказчика появляется эксперт, который задаёт много вопросов и предъявляет новые требования к проекту, которые подразумевают изменение архитектуры проекта и кода. Если инициировать эти изменения, то есть риск сорвать плановые сроки реализации проекта.

Как вариант — провести встречу, обсудить, что беспокоит эксперта в текущей архитектуре, объяснить, почему реализовано именно так и наметить дальнейшие шаги. При этом важно постараться не увеличить объём работ проекта и не выйти за временные и финансовые рамки.

Каждый участник команды должен понимать важность работы с рисками

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

Оценка рисков и работа с ними зависят от размера и длительности проекта. Рекомендуем возвращаться к работе над рисками один раз в 1‒2 недели, в некоторых крупных проектах периодичность может быть увеличена до месяца.

Лучше составить неполный перечень рисков, чем не составить его вовсе.

В процессе общения с разработчиками или заказчиком лучше забыть фразу «все и так всё понимают»:

Главное в работе с рисками ― донести до всех участников проектной команды необходимость работы с рисками. Прежде всего нужно стараться не допускать наступления рисков, анализировать прошлый опыт и причины наступления для составления перечня возможных рисков в новых проектах, предотвращать непредусмотренные риски.

Пример перечня рисков проекта с комментариями и статусами можно посмотреть здесь.

Этапы оценки проекта: понятия, методы и полезные инструменты

Кто такой проджект менеджер, чем он занимается и как им стать

Как компаниям общаться с клиентами: ключевые тенденции и полезные советы

Мнение автора и редакции может не совпадать. Хотите написать колонку для Нетологии? Читайте наши условия публикации. Чтобы быть в курсе всех новостей и читать новые статьи, присоединяйтесь к Телеграм-каналу Нетологии.

Источник