10.12.2013

Agile security или непрерывно меняющаяся безопасность

Весной, когда горячо любимая компания ICL КВО ВС спрашивала меня о том, что я мог бы прочитать на IT & Security Forum, я предложил несколько тем, которые на мой взгляд должны были быть интересными слушателям. В итоге были выбраны две - "Альтернативный курс по информационной безопасности" и "Бизнес-модели в деятельности безопасника". Еще одна предложенная тема была связана с измерением эффективности ИБ и, наконец, про agile-методологию в области информационной безопасности. Вот к последней мне и хотелось бы вернуться.

Подтолкнул меня к этому диалог с Геннадией Атамановым, который на сайте BISA высказал (тут и тут) не новую, но на мой взгляд тупиковую в современных условиях идею, что нельзя ни в коем случае улучшать и предлагать изменения в документы ФСТЭК, ФСБ, Совета Федерации, пока не будет изменена вся концепция защиты информации в России. У Геннадия якобы есть своя всеобъемлющая теория безопасности и она является единственной верной и правильной, а все, что делает ФСТЭК, ФСБ, Совет Федерации и иже с ними - пустая трата времени и никому не нужна, т.к. эти действия похожи на метания без цели и "заплаточный метод". Я все-таки не сторонник перефразированного Интернационала "весь старый мир мы разрушим до основанья, а затем мы наш, мы новый мир построим...", скорее наоборот.

И вот тут на память приходит аналогия с методологией agile-разработки программного обеспечения, основными идеями которой являются (цитирую по Википедии):

  • люди и взаимодействие важнее процессов и инструментов;
  • работающий продукт важнее исчерпывающей документации;
  • сотрудничество с заказчиком важнее согласования условий контракта;
  • готовность к изменениям важнее следования первоначальному плану.
Применительно к информационной безопасности это могло бы означать:
  • безопасность обеспечивают живые люди, от поддержки которых руководством и доверия к ним, зависит эффективность конечного результата и всего процесса;
  • важно не "бумажное" соответствие, а реальная система защиты, нацеленная на потребности бизнеса;
  • сотрудничество с людьми (сотрудниками, клиентами, различными подразделениями, партнерами) важнее формального выполнения редко меняющихся требований политик и концепций;
  • в условиях динамичности защищаемой среды, постоянного изменения ландшафта угроз и непрерывно меняющегося законодательства необходимо быть готовым к изменениям и необходимо внедрять изменения по мере их появления, не дожидаясь окончания очередного этапа какого-нибудь жизненного цикла.
В Казани я хотел рассказывать про agile-методологию только применительно к теме законодательства и коснуться вопроса - "как выполнять различные требования различных нормативных актов в условиях их непрерывного изменения". Сейчас же я понимаю, что тема agile близка ИБ в целом, а в последнее время особенно. 

Разумеется, у agile-подхода есть и недостатки. Основной из них - отсутствие четкого плана действий. Задачи решаются по мере их поступления и зачастую такие решения могут противоречить прежним решениям. Но такова жизнь. Жить по плану в ИБ можно в области защиты государственной тайны, в которой объектов контроля не так много, доступ к ним сильно ограничен и количество изменений на этих объектах ничтожно мало. А вот на "коммерческих объектах" жизнь по плану малоэффективна - его не удается зафиксировать и приходится часто отходить от первоначальной задумки. Но если в agile-методологии - это норма, то при классическом построении системы защиты - любое отступление от плана рассматривается как катастрофа.

Геннадий (см.выше) сторонник именно традиционного подхода. Он считает, что ФСТЭК (и другие регуляторы) должна сначала методологически правильно и теоретически верно выстроить общую идеологию защиты информации, а потом последовательно закрывать ее элементы отдельными нормативными актами. Лет 20 назад такой подход был бы верен. Сегодня, к сожалению, он не соответствует реалиям. Еще в прошлом году на слуху у всех была мобильность, в этом облака, а в следующем уже будут "Большие данные". Через год-другой "Интернет вещей" активно вольется в практику обеспечения ИБ российского предприятия. Каждый раз перестраивать концепцию защиты?.. Утопия. Необходимо идти маленькими шажками и закрывать насущные проблемы и задачи^ что ФСТЭК и делает.





Аналогичная agile-методология может найти свое применение (и можеь быть даже в большей степени) и в корпоративной среде, которая более динамична, чем государственные или мниципальные учреждения.

4 коммент.:

Алексей Т. комментирует...

Противоречивый пост... С одной стороны agile-подход, а с другой опять же картинка ФСТЭК со структурой документации. Я бы просто сказал, что сотрудники ФСТЭК сейчас делают все, что они могут сделать в условиях отсутствия четкой концепции (хоть как ее назови), а может даже в условиях ее "неформального" присутствия... Картинки со структурой документов не новы, я только не примомню исторического момента, когда хотя бы одна из таких картинок была реализована :-)))

Turkish комментирует...

Agile-разработка существует только потому, что "время-деньги", что вполне очевидно с точки зрения вывода продукта на рынок или его (продукта) обновления, и совсем не очевидно с точки зрения формирования защиты информации. Обычный процессный подход и формирование ЗИ на основе системы управления рисками уже отвечает требованиям гибкого реагирования на возникающие угрозы и/или новые технологии. А вот что на выходе у нас получается от регуляторов - большой вопрос, но точно не agile-security.

Алексей Лукацкий комментирует...

Алексей Т.: сейчас картинка уже реализована процентов на 50

Sergey Soldatov комментирует...

Алексей, полностью согласен!
Особенно неэффективность "системного подхода" заметна, если есть опыт работы в коммерческой компании и государственной. Проблема "системного подхода" в том, что его построение занимет время, за которое "собака могла подрасти". Именно поэтому по одной из теорий вымерли динозавры - при их размере тела убогая нервная система не могла обеспечить своевременную доставку рефлексов во все его части.....
Примерно о том же, но с конкретным ответом что делать я писал в январе 2013:
тут