Текст программы:

 

А.П. Добрый день! Это «Открытая безопасность». С нами коллеги из «Инфосистемы Джет» - Анна, из компании R Vision — Александр, Руслан из компании «АйТи», и на проводе у нас Никита из Новосибирска. Никита, я надеюсь, тебе там весело :)

Давайте продолжим с вами беседу во второй части, посвященной автоматизации процессов информационной безопасности.

А вот в финансовых организациях, какие процессы и какие процедуры в SOC присутствуют?

А.Б. Вот здесь я бы хотел сперва уточнить. Как ученые когда собираются, они сначала по терминам договариваются... SIEM — это класс решений. Когда мы говорим SIEM мы понимаем, что это. Когда говорим СУИБ тоже понимаем, что это. Хотя в СУИБе есть 27001, и есть это СОИБ в Стандарте Банка России. И хоть это похожие вещи, но всё равно.

А.К. Всё равно часто происходит смешение этих терминов.

А.Б. Да-да. А вот, когда мы говорим про SOC — это вообще скорее маркетинговый термин.

А.П. Давайте тогда вообще выкинем этот термин. Будем говорить про СУИБы. SIEM мы уже обсудили до этого. Давайте про СУИБы речь пойдет.

А.К. Ну, я не знаю. Мне кажется, что в том контексте, в котором мы сейчас говорим, SOC — это связка средств автоматизации и процессов, направленных на мониторинг событий ИБ, разрешение инцидентов, их расследование.

А.П. А SOC имеет отношение к автоматизации процессов?

А.К. Ну конечно. Управление инцидентами — это один из тех же СУИБов.

А.Б. Автоматизация — она же тоже достаточно широкая. Ведь когда мы делаем что-то с инцидентами с помощью SIEM — решений, мы автоматизируем процесс. Да. И это можно назвать SOC. SOC — это security operation center. Operation, то есть операция, какая-то текущая деятельность. Когда мы говорим про СУИБ, про менеджмент, там не всегда есть операция, текущая деятельность. Риск-менеджмент — это не операционная деятельность. Это деятельность скорее стратегическая, связанная с планированием . Верхнеуровневое управление — на уровне ресурсов, тех же самых планов, задач, сompliance тот же самый. Есть в нем и операционные какие-то задачи, есть высокоуровневые вещи. Так что, если рассматривать SOC, что это операционная какая-то деятельность, то да.

Р.Р. SOC - он все равно ограничен какими-то подпроцессами. Туда можно включать что-то, но все равно он больше network security,  риск-менеджмент туда тоже часто включают. Часто хотят от него response, управление aset, управление инцидентами. Но все-таки я бы дальше повел беседу о СУИБах, потому что это процессный подход к управлению безопасностью.

А.П. Ладно, какие процессы в СУИБе?

Р.Р. В СУИБе очень много процессов. И мы отталкиваемся всегда от заказчика. Будет это управление осведомленностью, управление носителями, инцидентами, документацией, отчетностью — что угодно. От заказчика. Всегда это сastom’ное решение. Когда заказчик говорит, что у меня там кейсы такие-то и такие-то, мы отталкиваемся от этого и предлагаем ему автоматизировать отдельные вот эти подпроцессы. А уже дальше он... Платформа - вообще в принципе GRC будто или автоматизация СУИБа, - это всегда платформа, на которую уже можно накладывать модули. Причем «съедобные» модули во всех смыслах: будет это один модуль Александра, другой модуль от Ани, третий — от меня. Но оно на этой платформе должно жить и должно работать и приносить ценность заказчику. Тогда это действительно GRC, СУИБ. Единственный на мой взгляд возможный вариант существования СУИБ — модульный.

А.П. Ну главное щас тут GRC не говорить:) Про процедуры. Никита, вот по твоему опыту, какие процедуры и процессы при построении таких центров мониторинга изначально не видны, а потом появляются? И в них необходимость появляется?

Н.Р. Ты говоришь про СУИБ, я говорю про SOC, — это немножко другое. Документации наплодить можно очень много, это зависит от потребности. В моем случае, мы сделали 2 вещи. Мы написали процедуры реагирования для определенных видов инцидентов, в том числе, написали какое время реагирования, за какое время мы реагируем и прочее. Мы насколько смогли изменили общие процедуры IT по внедрению систем и изменений, чтобы быть уверенными, что у нас не отъедет SIEM и пр. Потому что кто-то внедрит там систему новую, кто-то изменит правила на межсетевом экране, а мы об этом узнаем через два месяца. И что бы я хотел еще сделать, и что у нас не сделано — это формальный процесс добавления новых фильтров и правил и ревью старых. Пока в текущей ситуации мне достаточно будет.

А.П. Никит, Руслан сказал такую фразу — прости, Господи — GRC. Ты вообще как, сталкивался с инструментами GRC именно? C SAP, Oracle. Можешь рассказать свой опыт, что это такое? Какое это вообще отношение имеет?

Н.Р. Да, я сталкивался с несколькими видами GRC решений. Вам начать со специализированных или с самого лучшего?

А.П. Расскажи опыт и которое тебе понравился.

Н.Р. Пока больше всего мне нравится Excel... Это самое coast effective-решение :) Если раскладывать GRC на govenance, risk и compliance, то мне понравился compliance-модуль как раз от R-Vision. Он недорогой и делает то, что нужно . Если говорить о крупных решениях, которые покрывают всё, то я сталкивался с RSA Archer и metricstream. metricstream — это…, я никому его не могу рекомендовать. Т.е. это делали чужие для хищников.

А.П. Враги, короче говоря.

Н.Р. Да-да. RSA Archer достаточно непростой в освоении и достаточно детализированный tool, но если в нем научиться работать, то его можно успешно использовать. Я могу сказать, что он мне понравился. Могу рассказать о примере GRC на пальцах.

Однажды у меня была встреча с одним из акционеров нашего банка, мы обсуждали утечки. Утечки персональных данных наших клиентов. И обсуждали, что с этим делать, а что не делать. Анализировали месяца 2, откуда могут утечь, какие могут быть риски, какие объемы. В итоге оформили предложение, в котором было описание, что будут делать люди, какое нужно решение, сколько оно будет стоить. За полторы минуты провел в своей голове весь этот GRC. Когда я ему все рассказал, он говорит: «Ок, я все понимаю, в принципе, вам нужно два человека, платить я за них буду в среднем 200 тыс. руб в месяц, вам еще нужны лицензии — около млн рублей. За всё вместе я заплачу где-то 3,5 млн руб в год. Так, а за это что я получу?»

А.П. Спокойствие.

Н.Р. Я ему отвечаю: за это вы получите, что эти люди будут ежедневно мониторить вот эти вещи, на них будут реагировать за 8 часов. С физической безопасностью мы договоримся, если что, как с людьми мы договоримся, чтоб они стерли с email и пр. Подумал он, видно было, что в голове он у себя взвешивает, хочет он за это платить 3,5 млн или нет. В итоге, он сказал — да. Я спокойно ушел за своими лицензиями. Это пример того, как у человека в голове произошел и compliance-оценка и риск-оценка ...

А.П. Но ведь это у человека должен быть опыт хороший. Иметь хорошую базу за плечами.

Р.Н. У него нет никакого опыта. Это бизнесмен в чистом виде. Он об этом знает очень мало. Он у меня спросил, сколько он заплатит и что за это он получит. В голове взвесил, что за 3,5 млн он может открыть одну точку продаж или сделать этот процесс.

А.П. Понятно.

А.К. Мне кажется, у нас пока не сложилось такого целостного понимания, что такое GRC, и какой функционал такие платформы должны нести. В целом, у меня лично есть ощущение, как сейчас СУИБы часто ассоциируются с 27001 и с такими околобумажными процессами, так и ...вообще GRC могут быть использованы качественно и хорошо для автоматизации таких процессов. И есть ряд платформ, которые позволяют подстроить процессы, реализованные в рамках этой платформы к тем процессам, которые есть фактически в компании. Потому что несмотря на то, что в СУИБах, как Александр говорил, которые строятся в соответствии с 27001, хотя там очень много похожего — ну как там: некие реперные точки, которые в этих процессах должны быть. Всё равно в этих процессах есть своя специфика, кто как внутри в этих процессах участвует, какие подразделения взаимодействуют - и здесь разнообразие может быть достаточно большим. И здесь, наверно, чтобы качественно автоматизировать процессы СУИБа, платформа GRC должна быть не с жестко зашитыми процессами, как это часто встречается. А с возможностью подстраивать эти процессы под то, как это есть у вас. И здесь, пожалуй, когда — как у нас в начале был вопрос: каковы предпосылки при переходе от SIEM к SOC, - так и здесь вообще необходимо в первую очередь задаться вопросом, какие предпосылки к использованию GRC платформы.

А.П. Но она будет параллельно строиться с самим SOC, СУИБом? Или она будет строится внутри него?

А.К. Мне кажется, здесь нет такой зависимости. Потому что если мы рассматриваем SOC как платформу мониторинга, расследований инцидентов, это как бы отдельная задача действительно операционного уровня: повышение осведомленности о том, что происходит на бизнес-системах и объектах инфраструктуры с технической точки зрения. GRC это то, что позволяет реализовать ту тактическую, стратегическую составляющую в информационной безопасности. Т. е. по сути, на мой взгляд, в идеале, эта GRC платформа должна стать интерфейсом безопасности на уровне руководства. То есть, когда мы на нашем техническом уровне из SOC, SIEM или как мы это назовем, получаем данные о том, что происходит с точки зрения безопасности, из каких-то других систем мы понимаем, какие у нас уязвимости , или какие проблемы с точки зрения управления доступом, или какие у нас проблемы с точки зрения контроля мониторинга утечек по разным каналам. Когда вот из этих кубиков операционной деятельности в части безопасности мы собираем всю информацию, каким-то образом раскладываем ее по процессам, анализируем и представляем ее уже не на техническом уровне, а когда всё это переводим на язык уже понятный, как Никита сказал, людям, которые никак не связанным с информационной безопасностью.

А.П. Бизнесу

А.К. Да, когда мы понимаем, что инцидент на конкретном объекте инфраструктуры на какие бизнес-процессы он может повлиять. Инцидент один и тот же, одного и того же уровня критичности с точки зрения правил, заведенных в SIEM, может оказаться инцидентом, который захватывает, например, ключевые критичные бизнес-процессы, либо может распространяться на какие-то поддерживающие процессы.

А.П. Или на какие-то процессы, которые менее важны сейчас.

А.К. Да. И вот такого рода платформа, будет ли она называться GRC или по-другому, сможет перевести всю ту информацию, которая у нас есть — организационную и техническую - на язык, понятный бизнесам.

А.П. А вот автоматизированный СУИБ должен ли включать в себя процессы GRC?

А.Б. Мне кажется, не совсем правильно построенный вопрос. Если мы говорим про GRC, хотя хотели отказаться. Аня правильно сказала, даже Gartner начинает сейчас дробить эту область. Потому что GRC — это слишком большая бездна. И если мы говорим просто GRC — это вообще не информационная безопасность.

А.К. Изначально это бизнес...

А.Б. … где ИБ это небольшая составляющая этого GRC. GRC — это класс решений, направленных на автоматизацию определенных верхнеуровневых процессов, и переносим это на плоскость ИБ, где тоже есть такие верхнеувроневые процессы: риски, compliance и пр. вещи. Если мы будем говорить про GRC как про инструмент автоматизации этих процессов, и это тоже самое, что автоматизация СУИБ, потому что СУИБ рождает собой необходимость менеджмента ИБ, то тогда ответ такой. Решения такого класса они направлены как раз на то, чтобы эти процессы автоматизировать. Что касается связи с SOC, то здесь вопрос — не раньше/позже, а вопрос скорее интеграции. Но могут быть разные варианты. Идеальный вариант, наверно, когда есть и то и другое. Все между собой интегрировано. Есть операционный уровень и уровень руководящий. Но вполне может существовать одно без другого. Вполне может существовать операционный центр без какой-либо автоматизации процессов, то есть вообще нет менеджмента. Сидят такие прожженные технари, айтишники чаще всего. Айтишникам тоже нужен SIEM, мы же не говорим, что это только для безопасников.И они решают свои конкретные задачи, мониторят инфраструктуру - все, им больше ничего не надо. Так может и обратная ситуация: без операционного центра есть элемент автоматизации процессов, просто потому что это нужно с точки зрения соответствия требованиям законодательства или внутренним политикам. И это можно назвать и SOC, в том числе.

А.П. Есть примеры компаний, где реализованы элементы автоматизации GRC без SOC? И без SIEM. В России вообще есть такие?

А.Б. Конечно.

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

А.П. То есть, не просто мониторинг инцидента, а влияние на какие-то процессы. С приоритезацией.

Р.Н. Да, и это не просто хорошо ложится. Как фанат интеграции, я согласен с тем, чтобы это строилось на одной платформе.

А.П. Александр, а все ли процессы можно автоматизировать. Мы с тобой как-то рассуждали на ZeroNights, ты сказал, что далеко не все можно.

А.Б. Я бы сказал так: далеко не все аспекты этих процессов можно автоматизировать. И можно даже посмотреть шире: не все их нужно автоматизировать.

А.П. Ну понятно, перемещение бумажек, например, нет смысла автоматизировать.

А.Б. Как сказать, а вот документооборот электронный. Почему нет. Когда мы говорим про менеджмент, когда мы поднимаемся над технической составляющей, мы понимаем, что без людей нам не обойтись. Если мы говорим только про технику... Сейчас, может, этого и нет, но технологии так или иначе к этому двигаются. Например, компания Cisco активно разрабатывает self defense в сети, то есть когда инфраструктура сама по себе реагирует на какие-то инциденты. То есть на техническом уровне постоянно растет степень автоматизации, степень автономности. Когда мы поднимаемся на уровень процессов, то без людей не обойтись. Их может быть будет меньше, но люди будут всегда. Поэтому невозможно автоматизировать стратегическое планирование информационной безопасности. На эту тему есть очень интересная вещь, с точки зрения риск-менджмента. В нашей системе, когда производится оценка рисков, система предлагает, как можно обработать тот или иной риск. И некоторые заказчики говорят, что было бы здорово: нажал на кнопочку отработать риск, а я может потом подумаю и скажу: согласен или нет. Здесь есть один принципиально важный момент: система должны быть настолько умной, чтоб понимать при этом, что у человека есть ограниченный бюджет. Потому что если просто поставить системе максимально снизить риски. Она выберет самые дорогие, самые сложные системы защиты и предложит в качестве плана обработки риска. А это дурацкий совершенно подход, потому что..

А.П. Расходы превысят потери.

А.Б. Да, понятно что можно подумать над какими-то вариантами, чтобы она ориентировалась на степень снижаемого риска. Но это просто зарисовка, что не все, конечно, же может быть автоматизировано, либо эта автоматизация, которая никому не нужна. Как Никита пример привел, все равно потом будет сидеть в конце человек принимающий решение — бизнесмен. Он будет прикидывать другими категориями, опять же здесь он не будет полагаться на машину. Хотя из банковской отрасли пример: выдача кредитов. Очень много вещей автоматизировано в плане анализа первичной информации, первичного рейтинга, на основе которого затем будет уже приниматься решение все равно человеком. Полностью все автоматизировать нельзя, но ресурсов все меньше будет в компаниях, кто этими вопросами занимается, и нагрузка будет больше. Стало быть, не стоит вопрос автоматизировать или нет, все равно будешь — никуда не денешься.

А.К. Да, я здесь полностью согласна. Кроме момента того, что нужно... понятно, что с развитием систем будет появляться все больше механизмов такого условного принятия решений. Как раз с условиями принятия решений нужно быть очень аккуратным. Как Александр говорит, в плане обработки рисков нельзя проставить галочку «выполнить все», и чтоб оно еще само как-то и выполнилось автоматически и отрапортовало, что все хорошо. И здесь, наверно, стоит говорить про то, что все системы, работающие с данными и дающие выкладки по процессам, это должны быть, по сути, системы поддержки принятия решений. То есть, в рамках этих систем, если мы говорим смело про автоматизацию процессов управления безопасностью, там должно все выкладываться так, чтобы дать человеку, принимающему решения, максимальную информацию, что происходит, что можно сделать, какие последствия будут от того или иного решения.

А.П. То есть, ни в коем случае нельзя последнее слово оставлять за машиной?

А.К. Пока нет.

Р.Р. Я бы хотел добавить, что автоматизация безопасности для меня - она ключевая. И мы проводили различные research-и с различными вузами,  приходим к тому, что какие-то элементы можно автоматизировать до какого-то уровня. И нужно выделять всегда приемлемый уровень автоматизации. Как приемлемый уровень риска, так и приемлемый уровень автоматизации. Ну и понятно, что мы всегда поддерживаем концепцию: рутина — машинам; решения — людям. Не должны люди заниматься рутиной. Той, что можно автоматизировать. Наша некая непреодолимая мечта - так же как абсолютно защищенная компания, так и максимальная автоматизация в ИБ.

А.К. Сбудится тренд, что людей скоро вообще не останется в ИБ.

А.Б. Есть же замечательный советский мультфильм, когда Вовка в Тридевятом царстве наткнулся на двух: а вы еще и есть за меня будете? Вот тоже самое. Человек окажется просто ненужным. Нет, это к вопросу, что любой руководитель в организации понимает, что если у него начнут сокращать бюджет, то лучше от этого не будет. То есть это палка о двух концах. С одной стороны — давление все равно идет. С другой — если ты сам же начнешь активно в этом направлении идти, то вполне возможно, что очень скоро и тебя попросят.

А.П. А чего сложного? Включил коробочку, она все отработала. И выключил.

А.Б. Это конечно фантастика пока.

А.П. Ну вот недавно же Владимиру Владимировичу показали робота, который ездит на внедорожнике.

А.Б. Ну он же не сам. Там есть человек, который им управляет.

А.П. Через 50 лет будет один человек на все банки страны, который будет нажимать кнопки, и все банки будут у нас защищены.

А.Б. А человек будет в Центральном банке, видимо.

А.П. Да. Он будет выдавать распоряжения, которые будет сам же выполнять, в соответствии со своими требованиями.

А.К. Опять же если возвращаться к самому началу нашей беседы. То мы заговорили о том, что аутсорсинг — это вопрос нашей ментальности. Нашего представления о том, как это может быть. Может, и те вопросы, которые мы сейчас обсуждаем, они пока еще тоже вопросы нашей ментальности, и лет через ...дцать мы так или иначе придем.

А.П. Будем надеяться, что хотя бы наши дети начнут уже внедрят все в облака, все в облака. Никит, с какими примерами, с какими процессами ты сталкивался, которые легко можно автоматизировать, а какие достаточно сложно?

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

А.П. Ну это IDM обычные?

Н.Р. Не то чтобы IDM, это может быть что-то из палочек и веревочек. Здесь классические безопасники, и я в том числе. Мы очень любим сначала придумать политику безопасности, где все должно замыкаться на согласовании одного-двух-трех людей. Это различные акты и формы по согласованию. И в итоге, организация начинает тратить достаточно много времени, чтобы согласовать и предоставить доступ. Если мы переходим на GRC, то мое мнение, их использовать имеет смысл только в том случае, если организация очень большая.

А.П. По количеству людей или распределенности?

Р.Н. По количеству людей и по количеству организационных единиц. Я раньше работал в мультинациональной американской корпорации, там работало 300 тыс. людей, 100 различных бизнесов, и всем там надо было соответствовать SOX’у. Что вы с этим будете делать без различных средств автоматизации. Потому что раз в год аудиторы приезжали во все локации они требовали, чтоб отчетность везде была одинакова. Вне зависимости, что это: завод в Бразилии или банк в России. Чтоб они были одинаковые.

А.П. Ну это организация должна быть далеко от ларьков ЧП Аракелян. Должны быть масштабы огромные.

Р.Н. ИЧП Аракелян когда задумается о SIEM, будет уже очень здорово. Если говорить о Российских организациях. В России есть очень крупные организации, у них развита филиальная сеть: сильно самостоятельная. Они сдают отчетность, они сами устанавливают какие-то внутренние правила и пр. В этом случае, есть смысл в автоматизации и GRC, чтоб все report'или одинаково, чтобы они могли сравнить филиал в Казани и филиал во Владивостоке по одинаковым метрикам, не тратя время, чтобы позвонить и уточнить, что они имели в виду и почему они в разных форматах прислали информацию.

А.Б. И добавлю, где еще на практике может быть полезна автоматизация. Приходится сталкиваться в нашем случае, потому что мы поставляем продукт в организацию, когда необходимые компетенции аналитические, самый яркий пример, управление рисками - в организации просто нет. Задача стоит так: надо очень быстро решить проблему. Это как если представить себе мир —где автомобилей не существуют, но продают запчасти. И человеку стоит задача: нужно очень быстро собрать автомобиль и на нем поехать. И нужно, чтоб он развивал скорость километров до 100. Человек ни разу не собирал автомобиль, но он может получить детали. Но как их потом скрепить между собой — очень большой вопрос. К нему приходят с готовым автомобилем и говорят: на, садись и езжай. Это и есть автоматизация. Ему нужно научиться только рулить, но ему не нужно разбираться в устройстве автомобиля особо.

Р.Н. А можно я добавлю. Я согласен на 100%. Я упустил этот момент. Когда нужно, например, господам аудиторам показать что у тебя есть процесс риск-assessment, то купить готовое решение с методикой встроенной, в принципе, это здорово. Как с аналогией с автомобилем, если человек не разбирается в процессах риск-менеджмента, то весь tool — это будет как машина, которая будет выжимать 50 км в час. Если человеку нужно ехать со скоростью 50 км в час, грубо говоря, показать кому-то бумажки, то это будет идеальное решение. Ему дадут готовую методику, над которой думало очень много умных людей, ему дадут tool, в идеале — с подсказками различными. Он все это сделает. Если он пойдет с этой аналитикой к людям, которые принимают решения, скорее всего он узнает много нового о компетенциях своих :) Но с другой стороны, для него будет обучающий момент. В следующий раз он сделает уже лучше. Но с другой стороны, он за день забабахает отчет, который, например, PCI DSS-аудитору будет выше крыше. И он уйдет довольный и через полгода выдаст с сертификатом.

А.П. Понятно.

А.К. Можно и я добавлю, что разговор, который здесь сейчас произошел, отражает и те мнения, которые есть на рынке сейчас. Что те процессы, которые связаны с формализацией, либо это compliance , не важно подо что, либо это для очень зрелых организаций, которые эволюционно дошли до идеи управления ИБ в соответствии с какими-то лучшими практиками. Почему у нас пока как-то не складывается золотой середины? Возможно, эти идеи, связанные с настоящим управлением ИБ, по-прежнему в головах всем помнится, что они дороги. Потому что если посмотреть на GRC системы международные ,как обсуждал Никита, то они зачастую действительно стоят как самолет или как крыло от самолета. Мне кажется, что да, некая наша тенденция двигаться в сторону, того что нормальное, эффективное и полезное управление безопасностью может быть доступным не только для корпораций международного уровня, но и для компаний, независимо от того, какого они размера и какой отраслью занимаются.

Р.Н. Я бы еще добавил, что мы все равно работаем для заказчика. И у заказчика, как правило, требования прозрачности бизнеса, прозрачности безопасности. И этот инструмент позволяет дать прозрачность, увидеть безопасность, позволяет показать слабые места, дать рекомендации. И в соответствии от зрелости решения, показать насколько это будет эффективно. И какой уровень автоматизации выберет уже заказчик.

А.П. Резюме: построить такой сложный механизм как грамотный SOC или СУИБ — это пусть каждый решает сам, самостоятельно можно. Все зависит от вашей цели. Если ваша цель: научиться на собственных ошибках, обучить сотрудников и в итоге через пару лет выйти с системой, процентов на 80-100, можете делать сами. Конечно, этот путь родит в вашей организации качественную, грамотную команду: уже побитую, у кого-то не будет руки, у кого-то будет глаз подбит. Но эти люди родят просто вот вам эту полноценную систему. А если вам нужно в короткие сроки решить задачу по построению и автоматизации процессов ИБ в организации и обойти все возможные камни, обращайтесь к профессионалам.

Спасибо коллеги. Спасибо, что приняли участие в этой программе. С вами была программа «Открытая безопасность». Пишите в наши группы в LinkedIn и Facebook. До новых встреч!