Журнал "Information Security/ Информационная безопасность" #3, 2018

В современном мире компании все больше и больше начинают "кру- титься" вокруг приложений, но не наоборот. И получает- ся так, что, проектируя тот или иной сервис, то или иное приложение, люди про- ектируют и сам бизнес в масштабах отдельно взя- той задачи. И речь уже идет не об угрозах кибербезопас- ности со стороны Agile, а об угрозах для бизнеса. Безусловно, такая ситуация недопустима. ностью подобрать себе обувь нужного размера. Это будет происходить за счет форми- рования 3D-модели ступней клиента и не без участия мобильного приложения. – Идеология Agile в настоящее время пере- живает настоящий бум: на рынке выигрывает тот, кто первым макси- мально эффективно реа- гирует на малейшее изме- нение конъюнктуры. Но нужна ли она для инфор- мационной безопасности? В чем ее преимущество? – Вопрос скорости реаги- рования на изменения в современном мире стоит довольно остро. Как говорил классик, "пока семь раз отме- ришь, кто-то уже отрежет". Так же и в жизни e-com: кто не успел, тот опоздал, упу- стил, закрылся. Не исключение и служба информационной безопасности. Это просто адаптация ИБ к тре- бованиям нового времени. Речь идет, скорее, не о преимуще- ствах Agile в ИБ, а о том, как выжить паре бизнес + ИБ в эпоху Agile, если ее так можно назвать. Понимая суть Agile- принципов, ИБ должна транс- формироваться с их учетом. И есть реальные примеры того, что ИБ способна рабо- тать на высокой скорости изменений. К примеру, наша компания. – Как обеспечить кибер- безопасность Agile-про- ектов и реализуемых про- дуктов? – Мне сложно представить работу безопасников с клас- сическим подходом в Agile- проектах. Ведь, будучи замы- кающим звеном, ИБ становит- ся "бутылочным горлышком" и начинает приостанавливать развитие бизнеса. Такая ситуа- ция опасна как для бизнеса, так и для ИБ. В данном случае от ИБ требуется адаптировать- ся к быстрым изменениям – перестать быть проблемным местом в цепочке решения биз- нес-задач нашего времени. Главным вопросом в сло- жившейся ситуации становит- ся осознание того, что можно вынести из задач ИБ на более ранние стадии того или иного проекта. Уверен, что это на сегодняшний день единствен- ный дееспособный подход к обеспечению достойного уров- ня ИБ на Agile-проектах. Все остальное просто пере- ходит в плоскость средств достижения результатов, в частности работа с людьми в области повышения уровня осведомленности в ИБ. – Agile бросает вызов кибербезопасности. Что вы ждете от своих сотрудников? – Возможно, будет сказано громко, но сотрудники нашей компании уже воспринимают планы глобального характера как некий ориентир, но не зада- чу и находятся в постоянной готовности к изменениям, в частности, в области ИБ. Дело в том, что в современ- ном мире компании все боль- ше и больше начинают "кру- титься" вокруг приложений, но не наоборот. И получается так, что, проектируя тот или иной сервис, то или иное приложе- ние, люди проектируют и сам бизнес в масштабах отдельно взятой задачи. И речь уже идет не об угрозах кибербе- зопасности со стороны Agile, а об угрозах для бизнеса. Без- условно, такая ситуация недо- пустима. Поэтому, отвечая на данный вопрос, заявляю: в стенах нашей компании умение быстро меняться "на ходу" – это не ожидание, а, скорее, требование. То же самое каса- ется и большей части ценно- стей и принципов Agile. – Можете привести при- мер кейса применения Agile к информационной безопасности в компании WILDBERRIES? – Долгое время в компании был монолитный ИТ-отдел с единым окном по решению задач. В какой-то момент наш монолит стал подводить биз- нес по скорости: где-то это были затяжные ИБ-вопросы на стадии вывода проекта на финишную прямую, где-то отсутствие должным образом составленного ТЗ. Так или иначе, при возникновении вопросов к проектам на заключительных стадиях пере- делка функционала оставляла желать лучшего, если гово- рить о сроках реализации. Помимо всего прочего в про- цесс вклинивались задачи с большим приоритетом, что еще больше затягивало реа- лизацию. Что-то надо было делать с этой ситуацией. Биз- нес не мог так долго ждать – конкуренты ведь не дремлют. Уже позже нам стало понят- но, что мы стремились к цен- ностям Agile, но на момент становления нового подхода к разработке (именно она была двигателем ИБ в компа- нии на тот момент) в компании ориентировались на свое видение ситуации изнутри. Во время трансформации департаментов перед нами стояла глобальная задача – воспитать новое поколение сотрудников, которые пред- ставляли бы из себя некий симбиоз бизнес + разработчик + безопасник. Понимание должно было прийти к каждо- му из участников: бизнес дол- жен был понять, что такое раз- работка (включая моменты и ограничения ИБ), а разработка – научиться понимать бизнес и его бизнес-процессы. Для достижения результата по данной задаче мы пошли не проектным путем в его классическом понимании, а наделили каждый департа- мент своим ИТ-отделом. Теперь каждый руководитель департамента является руко- водителем своих ИТ-проектов и на его плечах, в частности, лежит ответственность за ИБ того или иного проекта. Пря- мая заинтересованность руко- водителей департаментов в ИБ, теперь уже Agile-проектов, – вот куда сместился вектор. Это стало своеобразным "эффектом бабочки". Так, мои собеседники удивляются тому, что сотрудники, к примеру, контактного центра знают, что такое 152-ФЗ и что попадание в информационную систему данных платежных карт недо- пустимо – это повод отреаги- ровать через инцидент ИБ. – Каких результатов удалось добиться благо- даря этому? – ИБ нашла свой путь в наших Agile-проектах. Полу- чилось не только сместить ИБ- проверки проектов на более ранние стадии и интегрировать их в процесс самой разработ- ки, но еще и заинтересовать сам бизнес в повышении уров- ня ИБ в департаментах. Ключевой показатель – коли- чество выкладок новой версии основного сайта – у нас может доходить до трех в неделю. • 7 ПЕРСОНЫ www.itsec.ru