среда, 31 августа 2016 г.

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

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

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

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

четверг, 25 августа 2016 г.

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

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

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


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

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