Интересна особенность этой тенденции в том, что это инициатива "сверху", т.е в компаниях ее сверху толкают топ-менеджеры или собственники. При этом, конечно же, они не сильно вникают в детали того что же скрывается за термином agile, скорее всего не очень в курсе, что уже появилось немало людей, считающих что agile мертв (вот тут Matthew Kern прямо таки камня на камне не оставляет от agile своими аргументами), и наверное меньше всего хотели бы столкнуться вот с таким проявлением agile
Но agile это однозначно не зло, хотя с ним как с сахаром или солью, если переборщить, то обязательно будет плохо. Да и пытаться применить его везде где только можно тоже не самый разумный подход (см. картинку выше). С точки зрения разработки программного обеспечения мы у себя в компании R-Vision, например, применяем agile подходы, правда за годы работы уже выработали свою собственную модель, которая отличается от классических практик.
Давайте посмотрим что же такое agile и как он может быть реализован в ИБ. Эта идеология строится всего на 4 основных постулатах:
- Люди и взаимодействие важнее процессов и инструментов. ИБ обеспечивают люди, работать приходится с людьми, люди самое слабое звено в безопасности и т.п. Поэтому конечно же этот постулат применим к ИБ и его можно также интерпретировать как то, что прежде чем покупать очередную дорогую игрушку (DLP, SIEM и проч.) нужно понять каким образом текущие коммуникации и деятельность людей будет улучшена / автоматизирована / оптимизирована, т.к первоочередными являются именно они, а не средства их обеспечения.
- Работающий продукт важнее исчерпывающей документации. Вроде все верно, внедренные и эффективно работающие средства защиты и процессы обеспечения безопасности важнее тонны написанной бумаги (получите, бумажные безопасники!). Но есть, конечно же, ньюансы. Если вы часто общаетесь с регуляторами, то знаете что для них бумага важнее, что далеко ходить, даже в СТО БР или 382-П математика оценки соответствия составлена так, что если у вас нет документов, то получите 0 и претензии со стороны регулятора. Поэтому если не вдаваться в крайности этот постулат можно интерпретировать как то, что актуализация документации, ее 100% соответствие текущей реальности по приоритетам должна быть ниже чем актуализация и совершенствование сами средств защиты и процессов.
- Сотрудничество с заказчиком важнее согласования условий контракта. Заказчиком в данной ситуации выступает бизнес / руководство / собственники. Данный постулат говорит о необходимости выстраивания неформальных взаимоотношений, позволяющих получать быструю и конструктивную обратную связь, обеспечивающих возможность оперативного согласования и корректировки в условиях постоянно меняющихся внешних обстоятельств. В общем, меньше формализма и действий строго по должностной инструкции, а больше конструктива, сотрудничества и работы на конечный результат.
- Готовность к изменениям важнее следования первоначальному плану. Любой план не более чем ориентир. Жизнь постоянно меняется и вы должны быть готовы меняться что называется "на ходу". Этот постулат требует довольно серьезной, фундаментальной перестройки. Вы сами, ваша команда, внедряемые вами практики и механизмы, реализуемые вами проекты, все это должно создаваться и развиваться в идеологии готовности к любым изменениям в любой момент. Тут очень непростым окажется вопрос взаимодействия с внешними подрядчиками. Не даром же на любые работы или системы изначально пишется ТЗ, в соответствии с которыми они реализуются. Так что возможность постоянно менять условия и требования для внешних подрядчиков выльется в дополнительные расходы, хотя, возможно, позволит избежать еще больших и, что самое важное, совершенно неэфффективных трат.
