«Дальше не придумали, импровизируй» или Agile в информационной безопасности

    Название этой статьи частично позаимствовано из одного популярного спектакля и кинофильма. «Дальше не придумали, импровизируй» – после этой фразы в фильме звучит нецензурная реакция человека, который понял, что импровизировать придется именно ему. В этой ситуации когда-нибудь оказывался или окажется каждый профессионал, работающий в сфере информационной безопасности. Это тот самый момент, когда ты встал у руля ИБ в организации нового для тебя профиля, когда в структуре компании происходят изменения уровня слияний и поглощений, или когда внезапно в 8 вечера пятницы начинают раздаваться звонки с сообщениями о неработающих банкоматах… Именно тогда в голове начинает звучать этот голос, дающий единственно верное направление дальнейших действий.



    Информационная безопасность – это сфера, которая не терпит вольного отношения. Все риски должны быть определены, возможный ущерб – оценен, а на каждое неожиданное событие должен быть заготовлен план. В соответствии с угрозами и рисками должны быть сформированы организационные и технические меры по защите компании от угроз ИБ. Этот подход в некоторых источниках именуется «Castle model of cyber security» или замковая модель. Он был сформулирован в 2004 году Деборой Фринке (Deborah Frincke) и Мэттом Бишопом (Matthew Bishop) в работе «Guarding the castle keep» и за последний десяток лет не претерпел существенных изменений. Его основные принципы – разделение всего информационного пространства на внутреннее, «безопасное», и внешнее, полное угроз и злоумышленников. Эти два сегмента разделены «стенами», возможно, построенными послойно, эшелонированно, а связь между внешним и внутренним миром обеспечивают шлюзы – «gateways». Этот подход настолько глубоко и прочно вошел в нашу жизнь, что даже часть вредоносного программного обеспечения мы именуем троянами – в честь Троянского коня, который помог внешним «злоумышленникам» проникнуть за крепостные стены Трои.

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



    В реальности все немного по-другому. Приведу пример – не из области кибербезопасности, но зато очень точно отражающий специфику замкового подхода. 1945 год, Восточная Пруссия, город-крепость Кенигсберг. Три кольца укрепленных фортов, построенных в конце 19-го века и существенно укрепленных в середине 20-го, многометровые кирпичные стены, тонны бетона и земли на укреплениях – все это оказалось бесполезным в условиях реального штурма. Изменения, которые произошли за несколько десятков лет, эволюция средств нападения и тактики привели к тому, что город был взят за несколько дней, а фортификационные сооружения не смогли остановить продвижение атакующих. Эта историческая зарисовка служит отличной иллюстрацией того, что те, кто не готовы к изменениям – не выигрывают сражений. Это верно применительно как к реальной карте мира, так и к пространству киберугроз.
    Когда мы говорим об изменениях и о том, как эффективно отвечать им, в голове автоматически возникает термин Agile. В последние пять лет он стал очень популярен, его упоминают к месту и не к месту.



    Успешные менеджеры повсеместно внедряют его для повышения эффективности, звучат заявления, что «Agile – это наше все, ключ к будущему». Чаще всего этот термин употребляется в бизнес-среде для того, чтобы подчеркнуть стремление к инновациям, или для того, чтобы посмеяться над хаотичными и неэффективными внутренними процессами.



    На самом деле Agile – это просто система ценностей, не дающая никаких практических советов. Для того, чтобы описать его, не требуются недельные курсы или кардинальное перестроение нашего образа мышления. Весь смысл Agile заключен в четырех предложениях. И вот они:

    1. Люди и их взаимодействие важнее процессов и инструментов.
    2. Работающий продукт важнее исчерпывающей документации.
    3. Сотрудничество с заказчиком важнее согласования условий контракта.
    4. Готовность к изменениям важнее следования первоначальному плану.

    В кибербезопасности идеология Agile нашла свой отклик в методологии Agile Cybersecurity Action Plan – гибком способе управления кибербезопасностью. Он противопоставляется «замковой модели» построения кибербезопасности и призван помочь CISO максимально эффективно «отрабатывать» изменения ландшафта угроз и рисков. Процесс подразумевает активную совместную работу кросс-функциональных и кросс-организационных команд для:

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

    Основные особенности Agile:

    • Итерации для планирования работ – спринты от 1 до 6 месяцев.
    • Процесс «разбей стекло» – запуск сессии ACAP вне очереди, если произошла нештатная ситуация.
    • Широкое использование потенциала человеческого взаимодействия.
    • Культура «решения проблем», подразумевающая высокий уровень вовлечения участников процесса.
    • Стратегия ИБ превращается из аксиоматичной в динамичную, отвечающую актуальным рискам и угрозам.

    Методология не ограничивается перечисленными элементами, это полноценно описанный процесс с этапами и результатами по выполнению каждого из них. При этом ACAP сложно назвать универсальным подходом: как сам ACAP, так и ценности Agile не применимы для того, чтобы тотально изменить подход к управлению кибербезопасностью. Из четырех основных элементов жизненного цикла – Predict, Prevent, Detect, Respond – Agile может работать только на стадиях Predict и Prevent, куда попадают задачи, связанные со стратегическим планированием, оценкой рисков и выработкой способа их решения.

    Так что если кто-то приходит к вам и говорит, что собирается «перевести информационную безопасность на рельсы Agile», задайте ему тот вопрос, который наверняка вертится у вас на языке: «Как, всю?» И если человек уверенно отвечает: «Конечно, всю!», мое мнение – не стоит ожидать от автора таких заявлений сногсшибательных результатов. Попросите его уточнить, как и в каких конкретных процессах он собирается применять ценности Agile. Слушая ответы, вы не только сможете составить представление о профессиональных качествах собеседника, но и узнаете, насколько хорошо он умеет импровизировать. Ведь дальше этого пока что ничего не придумали…
    Ростелеком-Солар
    Безопасность по имени Солнце

    Комментарии 10

      +1
      Спринты не являются отличительной особенностью Agile, это просто техника из скрама.
        +1
        А скрам – это методика работы в рамках принципов Agile. Если Вы приведете примеры применения спринтов не в рамках Agile, будет очень интересно о них почитать =)
          0
          Нет, смысл утверждения не в том, что спринты используются за пределами Agile, а в том, что спринты не являются отличительной особенностью Agile, так как многие практики не используют их: ни в TDD, ни в XP нет ничего о спринтах.
          Agile — это agile manifesto, и там нет требования зачем-то обязательно работать спринтами, там более общие вещи.
      • НЛО прилетело и опубликовало эту надпись здесь
          +1
          Agile не говорит, что документировать не надо. Он говорит о том, что выбор между работающим продуктом и написанной документацией должен быть сделан в пользу работающего продукта. Другими словами, если ресурс ограничен, а нужно или сделать документ, или доделать фичу, то выбор должен быть сделан в пользу фичи.
          Еще раз: нет декларации того, что документация не нужна. Документирование – крайне важная часть процесса разработки. Но ресурсы ограничены, а значит, документирование можно перенести на следующий спринт, например.
          Также важно помнить, что Agile хорош для решения коротких задач за ограниченное время. Когда мы говорим про принятие в эксплуатацию и на поддержку, например, ПАКа, Agile тут будет слабо применим.
          • НЛО прилетело и опубликовало эту надпись здесь
            • НЛО прилетело и опубликовало эту надпись здесь
          • НЛО прилетело и опубликовало эту надпись здесь
              0
              Результаты поиска на habrahabr:
              agile безопасность — 176
              блокчейн – 174

              Пора ли вводить мораторий на публикации про блокчейн?
                0
                blockchain- ещё 122 публикации. Пора.

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое