Интерфейсы взаимодействия у средств защиты

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

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

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

• наличие стандартных интерфейсов для передачи логов работы системы; если у вас уже есть какая-то система сбора и корреляции логов или вы предполагаете что она может появится, то конечно же следует сразу проверять что ваше средство защиты умеет выдавать логи по syslog или какому-то другому стандартному протоколу. 

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

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

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

Agile - новое слово в ИБ ?

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

Интересна особенность этой тенденции в том, что это инициатива "сверху", т.е в компаниях ее сверху толкают топ-менеджеры или собственники. При этом, конечно же, они не сильно вникают в детали того что же скрывается за термином agile, скорее всего не очень в курсе, что уже появилось немало людей, считающих что agile мертв (вот тут Matthew Kern прямо таки камня на камне не оставляет от  agile своими аргументами), и наверное меньше всего хотели бы столкнуться вот с таким проявлением agile

Но agile это однозначно не зло, хотя с ним как с сахаром или солью, если переборщить, то обязательно будет плохо. Да и пытаться применить его везде где только можно тоже не самый разумный подход (см. картинку выше). С точки зрения разработки программного обеспечения мы у себя в компании  R-Vision, например, применяем agile подходы, правда за годы работы уже выработали свою собственную модель, которая отличается от классических практик.

Давайте посмотрим что же такое agile и как он может быть реализован в ИБ. Эта идеология строится всего на 4 основных постулатах:

• Люди и взаимодействие важнее процессов и инструментов. ИБ обеспечивают люди, работать приходится с людьми, люди самое слабое звено в безопасности и т.п. Поэтому конечно же этот постулат применим к ИБ и его можно также интерпретировать как то, что прежде чем покупать очередную дорогую игрушку (DLP, SIEM и проч.) нужно понять каким образом текущие коммуникации и деятельность людей будет улучшена / автоматизирована / оптимизирована, т.к первоочередными являются именно они, а не средства их обеспечения. 

• Работающий продукт важнее исчерпывающей документации. Вроде все верно, внедренные и эффективно работающие средства защиты и процессы обеспечения безопасности важнее тонны написанной бумаги (получите, бумажные безопасники!). Но есть, конечно же, ньюансы. Если вы часто общаетесь с регуляторами, то знаете что для них бумага важнее, что далеко ходить, даже в СТО БР или 382-П математика оценки соответствия составлена так, что если у вас нет документов, то получите 0 и претензии со стороны регулятора. Поэтому если не вдаваться в крайности этот постулат можно интерпретировать как то, что актуализация документации, ее 100% соответствие текущей реальности по приоритетам должна быть ниже чем актуализация и совершенствование сами средств защиты и процессов.

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

• Готовность к изменениям важнее следования первоначальному плану. Любой план не более чем ориентир. Жизнь постоянно меняется и вы должны быть готовы меняться что называется "на ходу". Этот постулат требует довольно серьезной, фундаментальной перестройки. Вы сами, ваша команда, внедряемые вами практики и механизмы, реализуемые вами проекты, все это должно создаваться и развиваться в идеологии готовности к любым изменениям в любой момент. Тут очень непростым окажется вопрос взаимодействия с внешними подрядчиками. Не даром же на любые работы или системы изначально пишется ТЗ, в соответствии с которыми они реализуются. Так что возможность постоянно менять условия и требования для внешних подрядчиков выльется в дополнительные расходы, хотя, возможно, позволит избежать еще больших и, что самое важное, совершенно неэфффективных трат.  

Вообще тема agile очень большая и в один пост все не уложишь.  Кому интересна тематика советую сходить на конференцию AgileDays, но сразу оговорю что это мероприятие, ориентированное в первую очередь на разработчиков и тех, кто управляет разработкой. Но как знать, может быть какие-то идеи из смежных областей вы сможете с успехом перенести в ИБ. Успехов !