Митигировать что это значит
Митигация рисков
Что такое митигация рисков?
Митигация (или митигирование) рисков — это термин, происходящий от английского слова mitigation, означающего «смягчение» или «смягчение последствий». Прямой перевод с английского уже частично описывает суть митигации рисков — это снижение последствий от их реализации.
Изначально термин «митигация» применялся в отношении различного рода катастроф и чрезвычайных ситуаций (в понимании способов снижения тяжести их последствий), но в последнее время он нередко используется и в теории управления рисками. Особенно часто этот термин применяется в таких областях как промышленная безопасность и управление рисками в производстве.
При этом, если мы говорим об управлении рисками, митигация означает усилия, направленные не только на уменьшения тяжести последствий реализации риска, но также и на снижение вероятности реализации рискового события.
Фактически, мероприятия воздействия на риск из стандарта «ГОСТ Р ИСО 31000:2010. Менеджмент риска. Принципы и руководство», как раз и являются митигацией рисков.
План митигации рисков
План митигации рисков (англ. mitigation strategy) — это план мероприятий по управлению рисками, направленный на:
Уменьшение вероятности реализации рисков может быть обеспечено за счет создания так называемых «проактивных» барьеров — контрольных процедур, основной задачей которых является недопущение рискового события или значительное снижение вероятности его возникновения. Вероятность достаточно снизить до приемлемого для организации уровня, а не до нуля.
Снижение тяжести последствий реализации рисков обеспечивается за счет создания «реактивных» барьеров — мероприятий по минимизации ущерба от реализации риска.
Разработка и внедрение «проактивных» и «реактивных» барьеров на пути риска как раз и является задачей мероприятий по управлению риском или его митигации (митигирования).
Методы реагирования на риск могут включать в себя:
Основные стратегии митигации рисков с примерами описаны в этом видео на английском языке:
Митигация или как управлять правовыми рисками
Содержание статьи:
Термин митигация пришел к нам из английского языка. Он означает смягчение или уменьшение. При этом на самом деле, юристы сталкиваются с митигацией ежедневно, ведь осуществляя защиту клиентов, выступая в суде, подготавливая юридическое заключение, юристы работают над митигированием рисков, то есть заботятся об их снижении.
Юристы разных специализаций используют различные задачи в области митигации.
Например, юрист, специализирующийся на договорных отношениях, должен снизить риски судебных споров, а также неисполнения обязательств по договору. Юрист, который представляет интересы компании в суде, должен снизить риски принятия решения не в пользу компании, взыскания убытков, штрафных санкций. Юрист по налогам оценивает сделки, хозяйственные операции с точки зрения рисков доначисления налогов.
Это скорее подход на уровне бытового понимания и оценки рисков. Но митигация гораздо шире.
Впервые подход на уровне оценки рисков был использован в Банка России от 30.06.2005 N 92-Т (с изм. от 12.10.2016) «Об организации управления правовым риском и риском потери деловой репутации в кредитных организациях и банковских группах».
В данном письме были выделены как внешние, так и внутренние факторы риска.
Соответственно, выявив данные факторы риска, можно сделать вывод о том, что рисками возможно управлять. Управление правовым риском осуществляется в целях уменьшения возможных убытков, в том числе в виде выплат денежных средств на основании постановлений судов.
Какие существуют механизмы управления рисками?
Показатели могут быть различны, например, применительно к кредитной организации в качестве таких показателей рисков выделяют:
Таким образом, митигирование рисков используется юристами в повседневной работе как интуитивно, так и на основании нормативных документов.
Вопрос развития митигации в настоящее время связан с расширением в применении риск-ориентированного подхода. Такой подход широко используется в развитых странах.
Что подразумевает данный подход?
Это прежде всего, оценка любого явления, компании, бизнеса с точки зрения рисков. Данный подход применяется и государственными органами, в частности, была принята концепция и различного рода нормативные акты, касающиеся риск-ориентированного подхода в проверках.
Согласно статье 8.1. Федерального закона от 26.12.2008 N 294-ФЗ (ред. от 01.05.2017) «О защите прав юридических лиц и индивидуальных предпринимателей при осуществлении государственного контроля (надзора) и муниципального контроля» установлено применение риск-ориентированного подхода.
Риск-ориентированный подход представляет собой метод организации и осуществления государственного контроля, при котором в предусмотренных настоящим Федеральным законом случаях выбор интенсивности (формы, продолжительности, периодичности) проведения мероприятий по контролю, мероприятий по профилактике нарушения обязательных требований определяется отнесением деятельности юридического лица, индивидуального предпринимателя или используемых ими производственных объектов к определенной категории риска либо определенному классу опасности.
Критерии отнесения деятельности юридических лиц, индивидуальных предпринимателей или используемых ими производственных объектов к определенной категории риска либо определенному классу (категории) опасности определяются Правительством Российской Федерации, если такие критерии не установлены федеральным законом.
Соответственно, уже сегодня в разных областях экономической деятельности разработаны критерии.
Например, в пожарной безопасности разработано Постановление Правительства РФ от 12.04.2012 N 290 (ред. от 29.12.2016) «О федеральном государственном пожарном надзоре». Так:
а) к категории высокого риска относятся следующие объекты защиты:
б) к категории значительного риска относятся следующие объекты защиты:
Аналогичные критерии разработаны:
Немного теории об управлении рисками
Вводная информация по управлению рисками
Ответы же на все вопросы в каждой конкретной ситуации придется искать самостоятельно – так что не стоит видеть в процессе управления рисками какой-то панацеи от всех бед, либо немедленного и радикального улучшения процесса разработки. Впрочем, несмотря на это, я считаю управление рисками обязательной частью хорошего процесса управления проектами.
Определение риска
Определений рисков огромное множество и все они, в принципе, общеизвестны и интуитивно понятны. Приведу тут лишь несколько запомнившихся мне цитат.
Risks are schedule delays and cost overruns waiting to happen (by Peter Kulik)
Risk is the possibility of suffering loss (SEI, Dorofee 96)
Некоторые термины и определения
Для одного и того же риска могут разрабатываться оба плана, но в большинстве случаев – только один (тут уже надо решить что важнее – не допустить срабатывания риска, или же минимизировать потери при его срабатывании). Также при разработке mitigation plan часто руководствуются либо только стратегией снижения влияния или только стратегией снижения вероятности риска (что позволяет экономить – зачем направлять усилия на снижение влияния риска, если одновременно снижается и его вероятность).
Процесс управления рисками
С чего начать?
С чего начинается процесс управления рисками на проекте? Согласно теории – с идентификации риска(ов). Необходимо составить список рисков, которые бы наиболее полно отражали картину рисков и потенциальных проблем на проекте. Следует помнить, однако, что даже самый большой список никогда не будет полным – что-то всегда будет упущено. 😉
Анализ
При таком определении величина риска является простейшим способом определить количественную характеристику риска. Практически имеет смысл отслеживать и управлять рисками, которые находятся на главной диагонали данной матрицы или выше ее (то есть со значениями величины риска большими или равными 4 или 6).
После анализа риска мы можем составить топ10 рисков (Top 10 Risk List), выстроив риски по убыванию значения величины риска и выбрав первые десять. Следует помнить, что выбор большего числа рисков может превратить управление рисками в очень тяжелый процесс, который будет слишком дорог и неэффективен.
Планирование
Разрешение рисков
На данном этапе фактически происходит разрешение риска после того, как он сработал. То есть выполняется соотвуетствующий contingency plan. Задача этапа – выполнить его наиболее эффективным образом, а также собрать и проанализировать информацию о данном риске для следующего этапа.
Отслеживание и модификация данных по рискам
Заключение
Ключевым моментом процесса управления рисками должно быть периодическое повторение данных процессов, желательно согласованное с длительностью циклов разработки и рабочих процессов. Можно порекомендовать проводить оценку рисков один раз в 1-2 недели в зависимости от размера проекта (в некоторых особо крупных проектах периодичность может быть увеличена до месяца, однако больше я бы делать не стал).
Также хочу порекомендовать сохранять историю изменений списка рисков и их параметров (хотя бы Top 10 Risk List) – в будущем это даст нам необходимые статистические данные.
Постскриптум
Хочется отметить, что информация, приведенная выше, является выжимкой из большой, официальной и предельно формализованной процедуры по менеджменту рисков, которую я создал для компании, в которой работаю. Опущены некоторые формальные этапы (например, планирование управления рисками, контроль), для приведенных этапов дано описание их сути, что помогает понять их, но оставляет определенную свободу выбора и гибкость при применении на различных проектах.
Управление Поставщиками: Как Эффективно Управлять Риском Поставщика
Стоит отметить, что скорость развития в этом направлении впечатляет.
Но… риски в цепях поставок растут прямо пропорционально такому развитию.
Цепи поставок становятся более подверженными срывам. Каждая компания, относящая себя к транснациональному уровню, испытывает на себе последствия экстенсивного роста чуть ли не каждый год. Например, цунами в Японии и землетрясения в Таиланде, через шесть месяцев после этого, явно показали слабые звенья в цепях поставок автомобильной и электронной индустрии.
Поэтому, каждый Заказчик должен быть максимально готов быстро реагировать на любые изменения, будь то изменение спроса, изменение цен на сырье, рост стоимости перевозок либо что-нибудь, связанное с погодными явлениями и многое-многое другое.
Предлагаю рассмотреть следующую модель для митигации риска работы с Поставщиками:
1) Управлять Риском Поставщика – понять, какой риск несет каждый поставщик или подрядчик для Заказчика.
2) Митигация / предусмотрение действий на случай реализации риска – принять защитные меры, иметь возможность переключиться на другой источник обеспечения, иметь запасы и т.д.
3) Контролировать Риск Поставщика – увеличить прозрачность производственного процесса и использовать программы, позволяющие контролировать работу Поставщика.
Применение этих приемов позволит быть немного более уверенными в том, что цепь поставок готова справиться с непредвиденными ситуациями, а потери для Заказчика не будут колоссальными.
1) Управлять Риском Поставщика
Источники рисков
Хочу предложить расширить этот список, и пройти, от так называемых «известных — неизвестных» — управляемых до «неизвестных-неизвестных» — неуправляемых.
Для работы с управляемыми рисками – достаточно ежедневно выполнять свою работу, неуправляемые никак не проконтролировать – эта аксиома глубоко засела в мозгах наших людей. Попробую с ней поспорить.
На основании этих данных, можно подготовиться, например:
— Оценить эффект для компании, определить что можно сделать, чтобы подобные удары не парализовали работу цепи поставок;
— Добавить в свою цепь поставок таких свойств как гибкость, определение дополнительных складов для хранения продукции, поиск альтернативных поставщиков;
— Определить для себя, что вы не будете долго подсчитывать убытки, а быстро реагировать.
Рассчитываем влияние рисков
Так или иначе, основные риски Заказчика связаны с его Поставщиками. Помимо того, что необходимо Управлять Поставщиками, еще предлагаю рассчитывать Риски Поставщика. Т.е. сколько будет стоить Заказчику восстановить объемы производства/продаж, если Поставщик не сможет осуществить текущую законтрактованную поставку. Да, будут штрафы по контракту (чаще всего мизерные), но я говорю об упущенной выгоде, непроизведённой продукции, не допроданной продукции.
Как это сделать? Не сложно:
Эти шаги достаточно просты и доступны каждому. В этом их «фишка», если хотите.
2) Стратегии Митигации Рисков
Термин митигация (от англ.mitigation) — смягчение, ослабление, облегчение, уменьшение, снижение (например, рисков). Это все действия, предпринимаемые для смягчения, предотвращения рисков.
После составления «карты рисков», переходим к разработке стратегии митигации рисков, начиная с наиболее «дорогого» риска. Здесь главное не допустить ошибку, совершаемую 90% менеджеров. Закупку любых небольших изделий относят к наименее рисковым процессам. НО, например, если от двигателя автомобиля отвалится оригинальная запчасть, которую ждать 3-4 недели, сможет ли машина ездить? А ведь деталь маленькая и, с первого взгляда, не значительная. Также, показательный пример – запчасти для трансформаторов печей крупных индустриальных предприятий. Если такой трансформатор ломается, то новый ждать 8-9 месяцев. Доставка запчастей может занять от 2-3 месяцев. Сроки просто разрушительны для бизнеса. А всё из-за того, что неправильно спланировали, не подумали, что с Поставщиком что-то сможет случиться – в общем не придали должного внимания этой номенклатуре с точки зрения митигации риска.
Стратегий для митигации рисков существует немало, кратко, приведу несколько: Привлечение альтернативных поставщиков, увеличение гибкости производства, в том числе, путем совершенствования переналадки оборудования, увеличение запасов, повышение гибкости в поставках на различные предприятия (унификация требований, техники, оборудования). Каждый случай требует тщательного подхода.
3) Мониторинг Риска Поставщиков
После того, как выявили риски и продумали стратегии их митигации, наступает пора постоянного контроля над ситуацией. Мы писали ранее про инструменты коммуникации в Управлении Цепями Поставок. Так вот, именно они и могут являться той самой платформой, где в любой момент вы можете узнать, как обстоят дела у ваших контрагентов. Безусловно, здесь важно и то, чтобы контрагенты были готовы работать с вами по такому же принципу, в конце концов – это в их же интересах. Принести вам, как клиенту, очередную ценность, а именно – максимально снизить риски срывов поставок и потери прибыли. Наш век высоких технологий позволяет реализовать такую коммуникацию и сделать работу с Поставщиками предсказуемей.
Прозрачность Поставщиков должна быть интегрирована в систему коммуникации Заказчика, с тем, чтобы «красные флажки» выскакивали, если у Поставщика, например, подходят к концу запасы, срывается объем производства, происходит замена сырья (несогласованная с Заказчиком) и в других случаях. В этом случае Заказчик наглядно представляет, какие ресурсы имеются в его распоряжении, и соответственно выстраивает свою стратегию дальнейшей работы.
С учетом глобализации значительное число Заказчиков ищет возможности производить товары по всему миру: ближе к источнику сырья, с меньшей стоимостью трудовых ресурсов и др. В этой ситуации, помимо приобретения конкурентного преимущества – снижения себестоимости – Заказчики приобретают серьезные риски в другом важном аспекте – Сервисе для Клиента. Мы перечислили немало рисков, в том числе контролируемых, которым подвергается практически любая транснациональная компания в сегодняшней ситуации. Бороться с ними или оставлять на волю случая – зависит от каждого из нас.
Ведь, к примеру, если из-за одного сбоя в цепи поставок по вине Поставщика, я не найду в магазине H&M футболку, то уйду в соседний магазин, допустим, TOPSHOP и куплю ее там. H&M потеряет клиента, прибыль, а все из-за того, что не работали над управлением риска поставщиков. Задумайтесь, если так сделает не один, а 1000 человек? Вы работаете над митигацией рисков поставщиков? Какими методами?
(прим. от ред. в реальности H&M работает над митигацией рисков, используется для примера)
Митигация уязвимостей: операционная система в помощь?
Каждый, кто начинает изучать уязвимости программного обеспечения и их эксплуатацию, рано или поздно начинает задаваться вопросами: откуда берутся методики написания эксплойтов? Почему современное ПО содержит уязвимости? Насколько операционные системы с точки зрения проведения атак на ПО отличаются друг от друга? В данной статье будет рассмотрен подход к исследованию уязвимого ПО на различных операционных системах: какие есть особенности, какую систему лучше выбрать в качестве тестовой и какие выводы можно сделать.
Disclamer: Статья не содержит полный перечень методов и техник атак. В статью включены только те, которые могут быть интересны начинающему исследователю.
Почему существуют уязвимости и атаки
В стандартах можно найти понятие undefined behavior, используемое в разделах, посвященных портированию ПО на различные архитектуры. Термин undefined behavior обозначает любую ошибку или непонятную ситуацию, результаты которой не могут быть предсказаны наперед. В контексте ПО, написанного на С, в большинстве случаев это проблемы с памятью, работой с системами ввода/вывода, синхронизацией доступа к ресурсам информационной системы. Неопределенное поведение может случится по причине следующих ошибок при написании софта:
Вот здесь можно найти полный перечень популярных проблем. Именно из-за них есть возможность проводить атаки на ПО, поскольку каждую можно так или иначе рассматривать как уязвимость, подлежащую последующей эксплуатации в собственных целях.
Противодействие атакам
Проблемы безопасной разработки программного обеспечения известны и описаны уже давно, потому при изучении языка программирования для написания приложений используют наборы правил “хорошего” кода. Быстрый поиск в сети может предоставить большое количество таких рекомендаций.
Однако сегодня при всей комплексности кодящихся проектов и даже при использовании всех правил безопасности случаются ошибки, приводящие к образованию “ахиллесовых пят” софта. Для спасения приложений и операционной системы в этом случае существуют технологии защиты, которые интегрируются на уровне ОС.
Количество и сложность механизмов защиты от атак на ПО в разных ОС варьируется. Например, разработчики операционной системе Linux считают, что для операционной системы важнее функциональность, а не наличие защит. В противовес можно привести операционную систему Windows, которая пачками разрабатывает технологии защиты на уровне ОС. Насколько механизмы эффективны? Это вопрос отдельной статьи. В защиту операционной системы Linux можно сказать, что производились попытки её сделать более безопасной с точки зрения разработки ПО, но что-то пошло не так и теперь патчи безопасности продаются как отдельный проект.
Портирование атаки
Найти описание особенности уязвимости;
Найти или создать уязвимое приложение;
В качестве тестовых будем использовать Windows 7 x86 и Kali Linux.
Особенности уязвимости: UAF
Описание уязвимости можно найти на ресурсе. Если вкратце, то данный тип уязвимостей связан с использованием объекта после его освобождения. Следовательно, атака должна создать на месте освобождаемого объекта тот, который позволит выполнить произвольный код. Графическое представление уязвимости ниже.
В качестве упражнения попробуйте найти пример уязвимого приложения для ОС Windows (любой версии), которое будет содержать UAF. Также подобных приложений много для ОС Linux. Попробуем адаптировать одно из таких приложений: чтобы оно было скомпилировано и для Windows, и для Linux, а также уязвимость воспроизводилась на обоих системах.
Уязвимое приложение: UAF
В качестве подопытного будем использовать следующее приложение:
Скомпилируем код под Windows и Linux:
Поведение ОС: UAF
Особенности уязвимости: Stack Buffer Overflow
Уязвимость, которая имеет наибольшую популярность на сегодняшний день. Механизм работы Stack Buffer Overflow заключается в том, что данные, помещенные на стек, перетираются другими данными, заполняемыми в объекте, в котором не верно проверяется их размер. Картинка взята отсюда.
Уязвимое приложение: Stack Buffer Overflow
В качестве тестового будем использовать следующее приложение:
Скомпилируем приложение для Linux и для Windows:
Для операционной системы Windows такой список просто утилитой получить не удастся, вместо этого необходимо запустить приложение в ОС и просмотреть установленные механизмы защиты для работающего процесса. Сделать это можно например утилитой EMET. Полученный вывод для нашего приложения:
Даже не разбираясь, какой механизм от какой атаки защищает, список достаточно внушительный.
Эксплойт для уязвимого приложения: Stack Buffer Overflow
Эксплойт под Windows c применением ROP не дал результатов. Вывод его работы можно увидеть ниже.
Необходимо проводить дальнейший ресерч обходов защит системы. Против эксплойта сработали следующие механизмы защиты: SimExecFlow, DEP, SEHOP.
Вывод
Как можно заметить, подходы к обеспечению безопасной работы приложений у операционных систем Linux и Windows разные: в случае Linux получилось эксплуатировать заложенную в приложении уязвимость, в то время как Windows вовремя остановила работу приложения. Исследователям безопасности систем необходимо иметь это в виду, именно поэтому начинающему специалисту стоит взять систему Linux как начальную для тестирования уязвимых приложений, а к системе Windows обратиться для улучшения методов обхода защит операционных систем.
Данная статья была написана в преддверии старта курса Administrator Linux. Basic от OTUS. Узнать подробнее о курсе и посмотреть запись бесплатного демо-урока можно по этой ссылке.