митигирующие действия что это
Митигация рисков
Что такое митигация рисков?
Митигация (или митигирование) рисков — это термин, происходящий от английского слова mitigation, означающего «смягчение» или «смягчение последствий». Прямой перевод с английского уже частично описывает суть митигации рисков — это снижение последствий от их реализации.
Изначально термин «митигация» применялся в отношении различного рода катастроф и чрезвычайных ситуаций (в понимании способов снижения тяжести их последствий), но в последнее время он нередко используется и в теории управления рисками. Особенно часто этот термин применяется в таких областях как промышленная безопасность и управление рисками в производстве.
При этом, если мы говорим об управлении рисками, митигация означает усилия, направленные не только на уменьшения тяжести последствий реализации риска, но также и на снижение вероятности реализации рискового события.
Фактически, мероприятия воздействия на риск из стандарта «ГОСТ Р ИСО 31000:2010. Менеджмент риска. Принципы и руководство», как раз и являются митигацией рисков.
План митигации рисков
План митигации рисков (англ. mitigation strategy) — это план мероприятий по управлению рисками, направленный на:
Уменьшение вероятности реализации рисков может быть обеспечено за счет создания так называемых «проактивных» барьеров — контрольных процедур, основной задачей которых является недопущение рискового события или значительное снижение вероятности его возникновения. Вероятность достаточно снизить до приемлемого для организации уровня, а не до нуля.
Снижение тяжести последствий реализации рисков обеспечивается за счет создания «реактивных» барьеров — мероприятий по минимизации ущерба от реализации риска.
Разработка и внедрение «проактивных» и «реактивных» барьеров на пути риска как раз и является задачей мероприятий по управлению риском или его митигации (митигирования).
Методы реагирования на риск могут включать в себя:
Основные стратегии митигации рисков с примерами описаны в этом видео на английском языке:
Немного теории об управлении рисками
Вводная информация по управлению рисками
Ответы же на все вопросы в каждой конкретной ситуации придется искать самостоятельно – так что не стоит видеть в процессе управления рисками какой-то панацеи от всех бед, либо немедленного и радикального улучшения процесса разработки. Впрочем, несмотря на это, я считаю управление рисками обязательной частью хорошего процесса управления проектами.
Определение риска
Определений рисков огромное множество и все они, в принципе, общеизвестны и интуитивно понятны. Приведу тут лишь несколько запомнившихся мне цитат.
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) – в будущем это даст нам необходимые статистические данные.
Постскриптум
Хочется отметить, что информация, приведенная выше, является выжимкой из большой, официальной и предельно формализованной процедуры по менеджменту рисков, которую я создал для компании, в которой работаю. Опущены некоторые формальные этапы (например, планирование управления рисками, контроль), для приведенных этапов дано описание их сути, что помогает понять их, но оставляет определенную свободу выбора и гибкость при применении на различных проектах.
Стратегия и общая характеристика мер митигации
Митигация — это понятие, которое охватывает все действия, предпринимаемые гос.стр-рами и населением до наступления ЧС, включая обеспечение готовности и долгосрочные меры по уменьшению риска.
В более широком смысле митигация подразумевает планир-е и реализацию мер по снижению риска, связ-го с прир., техноген., экологич. и биолого-соц.ЧС, а также процесс планир-я эффектив.реагирования на них при их возникновении.
Цель стратегии по митигации — снижение потерь при будущей ЧС. При этом главной целью является снижение числа жертв и пострадавших людей, а второстепенной — снижение ущерба и экономич.потерь, нанесенных инфраструктуре, а также снижение потерь собств-ти населения в той степени, в к-ой они влияют на общество в целом. Одна из целей стратегии — вызвать у людей желание защитить себя по мере возм-ти. Особенно это касается экологических ЧС, так как митигацией ЧС природного, техногенного биолого-социального характера занимаются государственные структуры по защите населения в более полном объеме.
Общими направлениями митигации явл:
— разработка концепции национальной безопасности;
-создание гос структур, решающих проблемы митигации защиты населения при возникновении ЧС и ликвидации их последствий;
— создание и совершенствование правовой базы, обеспечивающей эффективную работу гос структур по защите населения и подготовке населения к действиям по предотвращению ЧС, выживанию в них или снижению возможных ущербов; проведение комплекса мероприй по предупреждению ЧС;
— планирование подготовки и реагирования на ЧС;
-подготовка объектов экономики и систем жизнеобеспечения населения к работе в условиях ЧС;
-декларирование промышленной безопасности;
-лицензирование деятельности опасных производственных объектов;
-страхование ответственности за причинение вреда при эксплуатации опасного производственного объекта;
-проведение государственной экспертизы в области предупреждения ЧС;
-гос.надзор и контроль по вопросам прир.техногенной экологической биолого- социальной безопасности.
Митигация —это сложный процесс решения как долгосроч., так и краткосроч.проблем подготовки к ЧС.
20. Особенности подготовки планирования и реагирования на чрезвычайные ситуации
Реагирование на возникающие ЧС обычно начинается с разработки государственными структурами планов по митигации, мероприятий по предупреждению ЧС и защите населения в них. Эта задача вытекает из требований законов Республики Беларусь, постановлений правительства и других документов.
Планирование подготовки и реагирования на ЧС включает:
— выявление потенциально опасных источников ЧС;
— определение возможных масштабов воздействия поражающих факторов источников ЧС на людей, экономику и природную среду;
— определение риска ЧС;
— проведение комплекса мероприятий по снижению риска чс;
— определение степени уязвимости населения, экономики и природной среды от источников чс;
— проведение комплекса мероприятий по снижению уязвимости населения, экономики и природной среды в ЧС;
— оценку наличия организационных ресурсов и потенциала для прогнозирования, оценки, предупреждения и ликвидации последствий чс;
— анализ и оценку чрезвычайных ситуаций по секторам;
— подготовку сил и средств для решения задач прогнозирования и других проблем митигации;
— уточнение функций государственных структур по защите населения и обязанностей должностных лиц;
— планирование деятельности для достижения уровня подготовки, необходимого для своевременного и эффективного реагирования на произошедшую ЧС и др.
Митигация уязвимостей: операционная система в помощь?
Каждый, кто начинает изучать уязвимости программного обеспечения и их эксплуатацию, рано или поздно начинает задаваться вопросами: откуда берутся методики написания эксплойтов? Почему современное ПО содержит уязвимости? Насколько операционные системы с точки зрения проведения атак на ПО отличаются друг от друга? В данной статье будет рассмотрен подход к исследованию уязвимого ПО на различных операционных системах: какие есть особенности, какую систему лучше выбрать в качестве тестовой и какие выводы можно сделать.
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. Узнать подробнее о курсе и посмотреть запись бесплатного демо-урока можно по этой ссылке.
Управление Поставщиками: Как Эффективно Управлять Риском Поставщика
Стоит отметить, что скорость развития в этом направлении впечатляет.
Но… риски в цепях поставок растут прямо пропорционально такому развитию.
Цепи поставок становятся более подверженными срывам. Каждая компания, относящая себя к транснациональному уровню, испытывает на себе последствия экстенсивного роста чуть ли не каждый год. Например, цунами в Японии и землетрясения в Таиланде, через шесть месяцев после этого, явно показали слабые звенья в цепях поставок автомобильной и электронной индустрии.
Поэтому, каждый Заказчик должен быть максимально готов быстро реагировать на любые изменения, будь то изменение спроса, изменение цен на сырье, рост стоимости перевозок либо что-нибудь, связанное с погодными явлениями и многое-многое другое.
Предлагаю рассмотреть следующую модель для митигации риска работы с Поставщиками:
1) Управлять Риском Поставщика – понять, какой риск несет каждый поставщик или подрядчик для Заказчика.
2) Митигация / предусмотрение действий на случай реализации риска – принять защитные меры, иметь возможность переключиться на другой источник обеспечения, иметь запасы и т.д.
3) Контролировать Риск Поставщика – увеличить прозрачность производственного процесса и использовать программы, позволяющие контролировать работу Поставщика.
Применение этих приемов позволит быть немного более уверенными в том, что цепь поставок готова справиться с непредвиденными ситуациями, а потери для Заказчика не будут колоссальными.
1) Управлять Риском Поставщика
Источники рисков
Хочу предложить расширить этот список, и пройти, от так называемых «известных — неизвестных» — управляемых до «неизвестных-неизвестных» — неуправляемых.
Для работы с управляемыми рисками – достаточно ежедневно выполнять свою работу, неуправляемые никак не проконтролировать – эта аксиома глубоко засела в мозгах наших людей. Попробую с ней поспорить.
На основании этих данных, можно подготовиться, например:
— Оценить эффект для компании, определить что можно сделать, чтобы подобные удары не парализовали работу цепи поставок;
— Добавить в свою цепь поставок таких свойств как гибкость, определение дополнительных складов для хранения продукции, поиск альтернативных поставщиков;
— Определить для себя, что вы не будете долго подсчитывать убытки, а быстро реагировать.
Рассчитываем влияние рисков
Так или иначе, основные риски Заказчика связаны с его Поставщиками. Помимо того, что необходимо Управлять Поставщиками, еще предлагаю рассчитывать Риски Поставщика. Т.е. сколько будет стоить Заказчику восстановить объемы производства/продаж, если Поставщик не сможет осуществить текущую законтрактованную поставку. Да, будут штрафы по контракту (чаще всего мизерные), но я говорю об упущенной выгоде, непроизведённой продукции, не допроданной продукции.
Как это сделать? Не сложно:
Эти шаги достаточно просты и доступны каждому. В этом их «фишка», если хотите.
2) Стратегии Митигации Рисков
Термин митигация (от англ.mitigation) — смягчение, ослабление, облегчение, уменьшение, снижение (например, рисков). Это все действия, предпринимаемые для смягчения, предотвращения рисков.
После составления «карты рисков», переходим к разработке стратегии митигации рисков, начиная с наиболее «дорогого» риска. Здесь главное не допустить ошибку, совершаемую 90% менеджеров. Закупку любых небольших изделий относят к наименее рисковым процессам. НО, например, если от двигателя автомобиля отвалится оригинальная запчасть, которую ждать 3-4 недели, сможет ли машина ездить? А ведь деталь маленькая и, с первого взгляда, не значительная. Также, показательный пример – запчасти для трансформаторов печей крупных индустриальных предприятий. Если такой трансформатор ломается, то новый ждать 8-9 месяцев. Доставка запчастей может занять от 2-3 месяцев. Сроки просто разрушительны для бизнеса. А всё из-за того, что неправильно спланировали, не подумали, что с Поставщиком что-то сможет случиться – в общем не придали должного внимания этой номенклатуре с точки зрения митигации риска.
Стратегий для митигации рисков существует немало, кратко, приведу несколько: Привлечение альтернативных поставщиков, увеличение гибкости производства, в том числе, путем совершенствования переналадки оборудования, увеличение запасов, повышение гибкости в поставках на различные предприятия (унификация требований, техники, оборудования). Каждый случай требует тщательного подхода.
3) Мониторинг Риска Поставщиков
После того, как выявили риски и продумали стратегии их митигации, наступает пора постоянного контроля над ситуацией. Мы писали ранее про инструменты коммуникации в Управлении Цепями Поставок. Так вот, именно они и могут являться той самой платформой, где в любой момент вы можете узнать, как обстоят дела у ваших контрагентов. Безусловно, здесь важно и то, чтобы контрагенты были готовы работать с вами по такому же принципу, в конце концов – это в их же интересах. Принести вам, как клиенту, очередную ценность, а именно – максимально снизить риски срывов поставок и потери прибыли. Наш век высоких технологий позволяет реализовать такую коммуникацию и сделать работу с Поставщиками предсказуемей.
Прозрачность Поставщиков должна быть интегрирована в систему коммуникации Заказчика, с тем, чтобы «красные флажки» выскакивали, если у Поставщика, например, подходят к концу запасы, срывается объем производства, происходит замена сырья (несогласованная с Заказчиком) и в других случаях. В этом случае Заказчик наглядно представляет, какие ресурсы имеются в его распоряжении, и соответственно выстраивает свою стратегию дальнейшей работы.
С учетом глобализации значительное число Заказчиков ищет возможности производить товары по всему миру: ближе к источнику сырья, с меньшей стоимостью трудовых ресурсов и др. В этой ситуации, помимо приобретения конкурентного преимущества – снижения себестоимости – Заказчики приобретают серьезные риски в другом важном аспекте – Сервисе для Клиента. Мы перечислили немало рисков, в том числе контролируемых, которым подвергается практически любая транснациональная компания в сегодняшней ситуации. Бороться с ними или оставлять на волю случая – зависит от каждого из нас.
Ведь, к примеру, если из-за одного сбоя в цепи поставок по вине Поставщика, я не найду в магазине H&M футболку, то уйду в соседний магазин, допустим, TOPSHOP и куплю ее там. H&M потеряет клиента, прибыль, а все из-за того, что не работали над управлением риска поставщиков. Задумайтесь, если так сделает не один, а 1000 человек? Вы работаете над митигацией рисков поставщиков? Какими методами?
(прим. от ред. в реальности H&M работает над митигацией рисков, используется для примера)