Прощайте границы компетенций между ИТ и ИБ

9

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

Новые угрозы

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

Но гипотетически каждое изменение бизнес-системы несёт в себе угрозы. Новые строчки кода могут нести в себе уязвимости или намеренные закладки. Новая учётная запись сотрудника во внутренней системе или клиента во внешней может быть создана с легко подбираемым паролем или с необоснованно высокими привилегиями. Также и новый процесс может содержать в себе возможности для мошенничества. Поэтому при «навесной» архитектуре безопасности каждое изменение в бизнес-системе должно вести к перенастройке системы защиты. Еще пять лет назад такой проблемы не было – изменения информационных систем проходили хорошо, если раз в месяц, а чаще – раз в квартал, было время не спеша провести тестирование системы в лаборатории и обезопасить себя, заказав сторонний аудит безопасности. Сегодня в большинстве банковских систем изменения идут уже раз в 2-3 дня, в промышленности существенно реже, а в электронной коммерции наоборот, чаще. В этих условиях у служб, отвечающих за информационную безопасность, теоретически есть возможность изучить новые функции и изменить настройки «навесных» систем защиты. Однако, что и как смогут сделать защитники информации с системами защиты, если изменения будут идти каждый час, каждую минуту? В чём смысл пентеста (от “penetration test”– “тест на проникновение”), если он длится неделю, а изменения идут ежедневно? О защищённости какой системы вы получите отчёт после пентеста?

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

Ретроспектива ИБ 

Если посмотреть на стадии развития отношений систем защиты с защищаемым объектом, то можно увидеть, что прямо сейчас происходит смена парадигм. Было время, когда защита бизнес-систем была организована одинаково, независима от того, что они защищали, без учёта их особенностей. Затем защищаемые системы стали достаточно сложными и появились «адаптивные» системы защиты, изучающие объект защиты перед тем, как его защищать и настраивающие систему защиты под конкретное состояние объекта. Расцвет таких систем породил огромное количество сканеров безопасности, однако такие сканеры были пассивными и не интегрированными в систему защиту, что привело к расцвету концепции «пассивной безопасности». Она подразумевает, что системы защиты не отражают атаки самостоятельно, а сообщают о подозрительных событиях и аномалиях, а решения об активной защите на основе этой информации принимают сотрудники службы защиты. Такой подход возник из-за того, что современные системы защиты недостаточно хорошо справляются с точностью определения атак, генерируя большое количество ложных срабатываний. Если дать им возможность принимать решения, а не просто информировать дежурную службу об аномалиях, то слишком много чувствительных для бизнеса процессов будет остановлено. Как следствие, в компаниях растёт количество сотрудников службы информационной безопасности, для поддержки работы систем пассивной безопасности на важных бизнес-приложениях вводятся круглосуточные дежурные смены.

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

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

Agile-примеры

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

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

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

Или ИТ и ИБ поменяются, адаптируясь под новые требования безопасности бизнеса. Или интересы бизнеса сместят нас...


4401
Коментарии: 9

Комментировать могут только авторизованные пользователи.
Предлагаем Вам в систему или зарегистрироваться.

  • Александр Громцев
    Рейтинг: 63
    ССЗ " Вымпел", ОАО
    Начальник управления по ИТ
    31.10.2016 14:29

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

  • Татьяна Орлова
    Рейтинг: 377
    ЗАО "ЕС-лизинг"
    Замдиректора по инновационной и экспериментальной деятельности, консультант по управленческим дисциплинам
    01.11.2016 17:35

    Собственно, ничего нового не произошло. Не очень понимаю, почему надо разделять ИТ и ИБ. Это, к сожалению, чисто российская специфика, имеющая место только в некоторых структурах. В остальном мире я подобного не наблюдала. Да и в России такой подход используется не везде. В моей практике, в том числе и в зоне ответственности, ИБ была частью ИТ, что подтверждается и международными управленческими стандартами. ИБ, в свою очередь, через ИТ сопрягалась с остальной безопасностью, не ИБ, а комплексной, под централизованным руководством. И защищали мы не только и не столько системы, а использовали комплекс защитных мер, где человеческий фактор всегда был составной и, зачастую, определяющей частью. Agile или не Agile - это не очень важно, т.к. это - один из управленческих подходов, который должен быть комплексно применен. Если нет грамотной системы управления, не информационной, а комплексной, т.е., если ИБ "висит в воздухе", то вряд ли изменение названия в подходе принесет существенные изменения, хотелось бы положительные, в чью-то жизнь.

    • Марк Шварцблат Татьяна
      Рейтинг: 30
      КТ "Акведук"
      ИТ-директор
      02.11.2016 14:53

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

      • Татьяна Орлова Марк
        Рейтинг: 377
        ЗАО "ЕС-лизинг"
        Замдиректора по инновационной и экспериментальной деятельности, консультант по управленческим дисциплинам
        02.11.2016 17:00

        Марк, по моему опыту тут все несколько сложнее. Часто идет структурированное делегирование полномочий. И если система стройная, то все работает в комплексе как часы. В любом случае плодить управленческие структуры, особенно там, где есть место комплексным знаниям и, соответственно, нужен качественный контроль предметной области в общей канве - критический риск. На западе уже давно ИБ подчиняется ИТ - директору с соответствующей ответственностью и с соответствующими полномочиями. И началась такая практика именно в сложных, географически распределенных структурах. Будь это госструктуры, или частные, не важно. Вся безопасность подчиняется руководству компании наравне с ИТ - директором, или выше уровнем. Конечно, речь не идет о разведке и о ей подобных структурах. У нас же, к сожалению, значимость ИБ либо сильно занижается, либо наоборот, сильно завышается. Мало где есть грамотные структуры. Как следствие мы либо имеем одного админа (или группу админов) на все, либо отдельно стоящую структуру, занимающуюся ИБ. При этом, зачастую, в таких структурах нет грамотных ИТ - специалистов, а есть, как раз, пенсионеры из спецслужб, не владеющие иностранными языками и/или ИТ на нужном уровне. Задача таких структур довольно часто сводится, при всем уважении, к доказательствам своей значимости...

        • Марк Шварцблат Татьяна
          Рейтинг: 30
          КТ "Акведук"
          ИТ-директор
          21.11.2016 12:21

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

          Всё же в больших (не семейного типа) структурах принцип "Доверяй, но проверяй" должен быть начертан на знамени ИТ-безопасности.

          • Татьяна Орлова Марк
            Рейтинг: 377
            ЗАО "ЕС-лизинг"
            Замдиректора по инновационной и экспериментальной деятельности, консультант по управленческим дисциплинам
            21.11.2016 12:34

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

  • Виктор Федько
    Рейтинг: 367
    Независимый эксперт
    Эксперт
    02.11.2016 08:33

    если изменения будут идти каждый час, каждую минуту?

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

    Да никто никого не сместит. Вообще, странное впечатление от статьи. То ли "Караул!!!", нас грабят :)))). То ли "Ну что ты стоишь, Глеб, Надо что-то думать, Ведь они убьют его" (с). ;)
    Я не думаю, что все так мрачно и бесперспективно. Более того, особых границ между ИТ и ИБ никогда и не было. ИБ - это составная части ИТ, одно из направлений. И таковым всегда останется.
    Да, чем раньше специалисты ИБ будут посвящены в тонкости новых разработок бизнес-систем, тем лучше. Еще лучше, когда при изобретении чего-то изобретается и защита. но это - аксиома, так должно быть всегда, есть далеко не всегда, но к этому надо стремиться. Только без фанатизма и заламывания рук. Не все так страшно.

  • 15.11.2016 19:42

    А по мне, так если мы проектируем и далее создаем бизнес-приложения, то такие азы как разграничение доступа, роли пользователей и т.п. - всегда должны проектироваться изначально. Без этого, нет хорошего бизнес-приложения. Если это не так - то как минимум, не профессионально .

  • Алексей Никифоров
    Рейтинг: 489
    TENNANT Russia ( Теннант Россия)
    IT директор
    30.03.2017 02:40

    В советские времена никакого agile не было. Были проектные институты, инженеры. Всё рассчитывалось, обосновывалось, проверялось и только потом внедрялось с хорошей документацией и многоуровневыми проверками. И лозунг был: "Советское, значит, отличное". Я не фанат СССР, но во всём, что касается планирования, проектирования, есть чему поучиться.
    Безусловно, можно сказать, что времена изменились и сейчас нет времени на все эти этапы: долго думаешь, быстрее тебя сделают конкуренты. Но, по личному опыту, agile часто сводится к тому, что заказчик просто не знает в начале, чего же он хочет, а agile позволяет ему "научно обоснованно" постоянно менять требования и условия задачи.

Предметная область
Отрасль
Управление
Мы используем файлы cookie в аналитических целях и для того, чтобы обеспечить вам наилучшие впечатления от работы с нашим сайтом. Заходя на сайт, вы соглашаетесь с Политикой использования файлов cookie.