18 сентября, вторник 16:45
Bankir.Ru

Объявление

Свернуть
Пока нет объявлений.

Альтернативы Управления Рисками

Свернуть
X
  • Фильтр
  • Время
  • Показать
Очистить всё
новые сообщения

  • Альтернативы Управления Рисками

    Предлагаю обсудить альтернативные подходы, вместо Управления рисками и ваше мнение о них

  • #2
    альтернативные подходы - например?

    Комментарий


    • #3
      Как вариант Compliance

      Комментарий


      • #4
        Compliance - http://www.shavlik.com/netchk-compliance.aspx - это оно?

        А где написано, что данная система не работает с Рисками ?

        Комментарий


        • #5
          Compliance - http://www.shavlik.com/netchk-compliance.aspx - это оно?
          Не совесем
          Под Compliance понимают полное соответсвие тому или иному стандарту.
          http://en.wikipedia.org/wiki/Compliance_(regulation)

          Комментарий


          • #6
            Сообщение от barmalei Посмотреть сообщение
            Не совесем
            Под Compliance понимают полное соответсвие тому или иному стандарту.
            http://en.wikipedia.org/wiki/Compliance_(regulation)
            А причем здесь Риски и альтернативные подходы? Где подход?

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

            Комментарий


            • #7
              Где подход?
              Подход в том что береться и внедряеться стандарт.

              Комментарий


              • #8
                Подход в том что береться и внедряеться стандарт.
                Т.е. я беру iso 27001 (это стандарт) и ... внедряю его.
                И никакого Управления Рисками мне не понадобится.

                Я правильно понял описываемый Подход?

                Комментарий


                • #9
                  И никакого Управления Рисками мне не понадобится.
                  Не понадобилось бы если ISO 27001 опирася не на управлении рисками.
                  Я предлагаю не разводить дисскусий, а подождать участников которые знакомы с альтернативными подходами и готовы поделиться знаниями.

                  Комментарий


                  • #10
                    ok. Подождем.

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

                    Комментарий


                    • #11
                      Сообщение от box_roller Посмотреть сообщение
                      ok. Подождем.

                      Предлагаю на обсуждение: ИБ бенчмаркинг. Возьмем за эталон компанию, у которой с ИБ все в порядке и сделаем как у них.
                      Коллеги, вы хотите странного.
                      Называлось три подхода:
                      • compliance (выбираем стандарт и тупо его внедряем)
                      • ISO 27001 (выбираем security controls и их внедряем)
                      • benchmarks (выбираем метрики a la ISM3 или Cobit
                        и добиваемся нужных значений показателей)


                      Как видите, во всех трех случаях ключевое слово "выбираем". Собственно, анализ рисков - это методика выбора. От того, что выбор угроз/рисков заменится на выбор стандарта или метрик, ничего не меняется.

                      Комментарий


                      • #12
                        malotavr
                        benchmarks (выбираем метрики a la ISM3 или Cobit
                        и добиваемся нужных значений показателей


                        Не надо метрик. Берем чужой Проект и внедряем его у нас. Будем как интеграторы )))

                        А если по делу, то имхо убирая понятие Риска, мы одновременно лишаемся понятия Вероятность, Уязвимость и Угроза.
                        Как так можно будет работать... не знаю.

                        Комментарий


                        • #13
                          На самом деле тот же Compliance и управление рисками, это независимые подходы, которые все равно надо внедрять. Нельзя отказаться от одного в пользу другого.

                          Compliance - это СООТВЕТСТВИЕ чему-либо. Как правило регулятивным требованиям (СТР-К, ИББС, COBIT и т.д.). И управление рисками тут не причем.

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

                          А security benchmarking - это маркетинг, а не реально работающая методика. Даже если мы возьмем две ОЧЕНЬ ПОХОЖИЕ компании (по отрасли, объему бизнеса, числу сотрудников и т.д.), то все равно много разного мобыть внутри компании - используемые софт и железо, уровень квалификации специалистов, уровень осведомленности сотрудников, способы ведения бизнеса, ментальность руководства и т.д. Как сравнивать такие компании? Малореально. Хотя для маркетинга и самолюбования - отличный инструмент. Мы его, в частности, на http://secure.cisco.ru запустили - прикольно получилось.

                          Комментарий


                          • #14
                            Compliance - это СООТВЕТСТВИЕ чему-либо. Как правило регулятивным требованиям (СТР-К, ИББС, COBIT и т.д.). И управление рисками тут не причем.
                            В ИББС используеться управление рисками, сейчас методику все никак не напишут про классификацию ИА и управление рисками.

                            Что касается вероятностного управления рисками, то, имхо, есть методы управления рисками, не завязанные на вероятность.
                            Какие?

                            Комментарий


                            • #15
                              barmalei Какие?

                              OCTAVE

                              Комментарий


                              • #16
                                По Octave
                                На третьем этапе производится оценка и обработка рисков ИБ, включающая в себя определение величины и вероятности причинения ущерба в результате осуществления угроз безопасности с использованием уязвимостей, которые были идентифицированы на предыдущих этапах, определение стратегии защиты, а также выбор вариантов и принятие решений по обработке рисков. Величина риска определяется как усредненная величина годовых потерь организации в результате реализации угроз безопасности.
                                Источник
                                http://www.iso27000.ru/chitalnyi-zai...i-bezopasnosti

                                Комментарий


                                • #17
                                  Сообщение от box_roller Посмотреть сообщение
                                  Подход в том что береться и внедряеться стандарт.
                                  Т.е. я беру iso 27001 (это стандарт) и ... внедряю его.
                                  И никакого Управления Рисками мне не понадобится.

                                  Я правильно понял описываемый Подход?
                                  по-моему управление рисками это не 27001, а BS 7799-3

                                  Комментарий


                                  • #18
                                    Сообщение от virus Посмотреть сообщение
                                    по-моему управление рисками это не 27001, а BS 7799-3
                                    BS 7799-3 - "Руководство по управлению рисками информационной безопасности", которое может (а может и нет) использоваться в качестве основы для управления рисками в ISO 27001…. Она предоставляет конкретное руководство и рекомендации по реализации требований ISO 27001, относящихся к процессам управления рисками и связанным с ними мероприятиям.

                                    ISO 27001 "Система управления информационной безопасностью — Требования" – где создаваемая СУИБ предусматривает управление рисками. Методология может быть любая.

                                    Комментарий


                                    • #19
                                      Эх, простите меня грешного, но опять не понимаю
                                      Суть вопроса в чём?
                                      Риски есть - это, вроде, более-менее объективная реальность. Так?
                                      Рисками можно либо управлять, либо не управлять. Третьего, кажись, не дано. Так?

                                      Вот было указано для примера пока три подхода:
                                      * compliance (выбираем стандарт и тупо его внедряем)
                                      * ISO 27001 (выбираем security controls и их внедряем)
                                      * benchmarks (выбираем метрики a la ISM3 или Cobit
                                      и добиваемся нужных значений показателей)

                                      Если мы предполагаем, что, реализовав один из них, мы снизили риски, то это и есть Управление Рисками. Так?
                                      Если мы предполагаем, что, реализовав один из подходов, мы риски не снизили, то зачем мы реализовывали этот подход?

                                      Комментарий


                                      • #20
                                        Сообщение от sunny Посмотреть сообщение
                                        Суть вопроса в чём?
                                        Риски есть - это, вроде, более-менее объективная реальность. Так?
                                        А суть вопроса в том, что, если сами риски - реальность объективная, то количественная их оценка (потенциальный ущерб помноженный на вероятность реализации) есть чистой воды профанация. Потенциальный ущерб оценить еще худо-бедно можно (хотя бы по максимальному значению), а вот с вероятностью - беда.

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

                                        Комментарий


                                        • #21
                                          Вот поэтому я сторонник немного иного подхода - показать, что безопасность ДАЕТ бизнесу, а не от чего она его защищает. Риски рисками, но это действительно пока профанация.

                                          Compliance более интересная тема, т.к. тут ты либо соответствуешь, либо нет. За несоответствие есть понятный кнут. Безопасность снимает опасность кнута ;-)

                                          Есть вариант, описываемый в Val IT и ряде других схожих подходов, когда ты рассматриваещь ИБ, как ИТ и пытаешься показать ее ценность для бизнеса. Например, географическая экспансия, рост продуктивности сотрудников и т.д. Если смог продемонстрировать четкую связь, то всякие риски ИБ можно опустить и использовать это понятие только с точки зрения project management.

                                          Комментарий


                                          • #22
                                            а вот с вероятностью беда
                                            беда она бедой, но не всегда.
                                            Порой вероятность можно получить исходя из статистики.
                                            Не общемировой накопленной за 5 лет и более, а конкретной статистики полученой в фирме за время работы проекта.
                                            Если она начиналась вестись когда проект внедряли и есть статистика хотя бы за пару лет, можно на нее опираться + экспертная оценка произвоителя продукта, администратора и специалиста по ИБ может внести коррективы.
                                            Соглашусь что экспертная оценка больше похожа на прогноз погоды, на нее пологаться на 100% нельзя.
                                            Как вариант можно применять математическое моделирование.
                                            Если кому-то знакомо как это можно смоделировать прошу делиться идеями.

                                            Compliance более интересная тема, т.к. тут ты либо соответствуешь, либо нет. За несоответствие есть понятный кнут. Безопасность снимает опасность кнута ;-)
                                            У на попробуйте такое сделать когда будет обязательным ИББС.
                                            В нем чистой воды управление рисками используеться, качественная оценка.
                                            Тот же ISO 27001 на который все хотят сертифицироваться тоже использует в своей основе управление рисками.
                                            OCTAVE не читал - но судя по источнику который я приводил - там тоже используеться управление рисками.
                                            Я просто не вижу к чему можно применить Compliance

                                            Комментарий


                                            • #23
                                              Коллеги.
                                              Дело в том, что мир не черно-белый (рисково-компайнсовый), а разноцветный. В зависимости от ситуации и степени детализации одинаково применимы оба подхода.
                                              Набор защитных механизмов (контрмер, controls) на самом деле конечен и одинаков для большинства ИС. Но _реализация_ и _приоритеты_ разнятся от системы к системе.
                                              Зачем нужен анализ рисков? Обычно в двух ситуациях - обоснование перед руководством и выработка внутренних ИБ-ных приоритетов.
                                              В первом случае можно использовать статистику (яркий пример - обоснование резервного центра обработки данных). Иногда этой информации нет - и здесь вполне подходит пропагандируемый подход к безопасности как составляющей системы качества информационных услуг.
                                              В случае расстановки внутренних приоритетов зачастую вероятность не требуется, достаточно "статической" оценки степени угрозы. Тривиальной "светофорной" оценки, или более сложные методики типа CVSS (http://www.first.org/cvss/). Обратите внимание - при расчете метрик CVSS понятие вероятности не учитывается, однако ряд вполне вменяемых критериев позволяет достаточно достоверно определить степень риска связанного с технической уязвимостью.
                                              Бизнес - ориентированную "статистику" можно получить самостоятельно или "заказать". В качестве "саксесс стори" могу привести пример, когда для обоснования внедрения систем проактивной защиты рабочих станций использовались результаты "Оценки эффективности программы повышения осведомленности" (http://www.ptsecurity.ru/download/PT...ity%202007.ppt). Данные о том, что пятая часть сотрудников спокойно запустят трояна, обходящего корпоративные средства защиты произвели неизгладимое впечатление на руководство.

                                              «Комплайнз» полезен в следующих случаях: «давят свыше» или вы определились и выработали свои требования, которым соответствуете. Например, базовые технические настройки приложений и ОС. Ну, нет смысла тут мучится с анализом рисков – взяли «бест практис», CIS, NIST, утвердили стандартом корпоративным и дружно ему соответствуем. НО! Обязательно появятся исключения из этого стандарта и для их «принятия» тоже может использоваться рисковый подход.
                                              Риски опять могут всплыть когда «коплайнс» может достигаться несколькими методами. Например, для реализации требования «пароли не должны передаваться по сети в открытом виде или с использованием слабых алгоритмов шифрования» можно перевести все рабочие станции и сервисы на NTLMv2 и Kerberos, а можно просто шифровать «точка-точка» с помощью того же IPSec. Что применять в той или иной ситуации? Что будет более полезно, дешевле при внедрении и поддержке? И т.д…

                                              Комментарий


                                              • #24
                                                Сообщение от barmalei Посмотреть сообщение
                                                Порой вероятность можно получить исходя из статистики.
                                                Если она есть ;-)

                                                Сообщение от barmalei Посмотреть сообщение
                                                Не общемировой накопленной за 5 лет и более, а конкретной статистики полученой в фирме за время работы проекта.
                                                Если она начиналась вестись когда проект внедряли и есть статистика хотя бы за пару лет, можно на нее опираться
                                                2 года - это не репрезентативно ;-( К тому же, что делать, в первый год работы, когда статистики вообще нет? А если средств для сбора статистики нет?

                                                Сообщение от barmalei Посмотреть сообщение
                                                OCTAVE не читал - но судя по источнику который я приводил - там тоже используеться управление рисками.
                                                Управление рисками не всегда опирается на вероятность.

                                                Сообщение от barmalei Посмотреть сообщение
                                                Я просто не вижу к чему можно применить Compliance
                                                Персональные данные, Базель II, SOX, СТР-К...

                                                Комментарий


                                                • #25
                                                  Сообщение от Sergey Gordeychik Посмотреть сообщение
                                                  Риски опять могут всплыть когда «коплайнс» может достигаться несколькими методами. Например, для реализации требования «пароли не должны передаваться по сети в открытом виде или с использованием слабых алгоритмов шифрования» можно перевести все рабочие станции и сервисы на NTLMv2 и Kerberos, а можно просто шифровать «точка-точка» с помощью того же IPSec. Что применять в той или иной ситуации? Что будет более полезно, дешевле при внедрении и поддержке? И т.д…
                                                  Ну в данной ситуации речь идет не о рисках, а скорее о project management или investment management, т.к. требование у тебя одно и варианты его удовлетворения дают примерно одинаковый эффект, а вот затрачиваемые ресурсы (деньги, время, люди) могут отличаться на порядок. И правильный их выбор - это прерогатива investment или resource management. Риски если и всплывут, то в контексте проектных рисков.

                                                  Комментарий


                                                  • #26
                                                    ресурсы (деньги, время, люди) могут отличаться на порядок
                                                    Если говорить о "классике" рисков, то они как "вероятностно-стоймостная" характеристика должны учитывать и "стоимость" механизма защиты при рачесте остаточных рисков и эффективности контр-мер. Понятно что это не "сферический конь" и связан со многими вещами. Например можно еще ввести "степень зрелости", когда в одних подразделениях (например) или для разных систем "закрытие дыр" в Web-приложениях реализуется с помощью WAF, в других - с помощью SDLC во всей красе.

                                                    Комментарий


                                                    • #27
                                                      Как я понял из комментариев коллег, мы говорим здесь всё же не об "Альтернативах управления рисками", а об Управлении рисками в условиях недостаточного объёма количественной информации об этих рисках.
                                                      При этом основные свойства риска как объективной реальности - влияние (impact, потенциальный ущерб) и вероятность (probability, реализуемость) никуда не деваются, просто мы по каким-то причинам не можем или не хотим их количественно померять. Но хотим снизить до "приемлемого уровня".
                                                      Impact (потенциальный ущерб) - свойство процесса.
                                                      Prob (условная "вероятность") - свойство совокупности используемых этим процессом ресурсов (активов).
                                                      Задача ИБ - заставить активы функционировать так, чтобы не наступил неприемлемый impact, а уж о вероятностях бизнес как заказчик задумываться не обязан. Т.е. impact наступил => ИБ плохо работает.
                                                      Количественно измерить Impact можно очень примерно, но точность тут и не нужна особо. Три-пять диапазонов по степени "приемлемости для бизнеса", и хватит.
                                                      Количественно измерить prob - чаще невозможно, чем возможно, но нужно ли?
                                                      Последний раз редактировалось sunny; 29.02.2008, 14:38.

                                                      Комментарий

                                                      Пользователи, просматривающие эту тему

                                                      Свернуть

                                                      Присутствует 1. Участников: 0, гостей: 1.

                                                      Обработка...
                                                      X