Статья: Обеспечение кибербезопасности на открытой платформе

Источник: http://www.pcweek.ru/foss/article/detail.php?ID=182501

    Почти два года Россия живет в новой экономической реальности, вызванной снижением цены на энергоносители и санкционными ограничениями: происходят падение или стагнация рынков в реальном выражении, сокращение горизонтов планирования и капитальных инвестиций, растет стоимость привлечения капитала, из-за роста курса доллара в разы увеличивается стоимость продления поддержки технологий. Ситуация требует от служб информационной безопасности гибкости и прозрачности, управляемости удельных издержек на обеспечение безопасности одного объекта — пользователя, устройства, приложения или дополнительного офиса.

    В конце января 2016 г. автор провел анализ финансового положения и инвестиций компаний РБК-500, интересовали «голубые фишки» — лидеры секторов с выручкой больше 20 млрд. руб. и ярко выраженными тенденциями изменения финансового состояния — роста инвестиций и прибыли или падения выручки. Парадоксально, но даже в «кризисных» отраслях (нефтяной и финансовой) «кризисные» компании было найти тяжелее, чем прибыльные или инвестирующие. Поэтому сделаю оговорку, что новая экономическая реальность (и данная статья) пока актуальна в первую очередь для организаций, целесообразность пересмотра портфеля технологий ИБ в которых обусловлена не только низкой ценой на основные экспортные товары страны. Это могут быть компании с падающей выручкой, госучреждения регионального и муниципального уровней (с исторически низкими удельными ИТ-затратами), компании высококонкурентных секторов (ИТ, торговля, фармацевтика).

    В последние годы был введен в действие ряд нормативных требований — приказ ФСТЭК № 31 по защите АСУ ТП, требования по защите национальной платежной системы, PCI DSS 3.0 и СТО БР ИББС-1.0-2014, приказ правительства РФ «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд».

Open Source (ПО с открытым кодом) может стать одним из ключевых инструментов для преодоления «ножниц» между финансовыми возможностями организаций и их потребностями (обеспечения соответствия регуляторной ситуации и ландшафту угроз). А как минимум для половины рынка ИБ (государственных и муниципальных заказчиков) стратегия Open Source позволяет не проводить закупку ряда программных продуктов — не подпадать под действие соответствующего приказа правительства, в то же время получая доступ к проверенным технологиям от глобальных разработчиков Cisco (Snort, ClamAV), TrendMicro (OSSEC), AlienVault (OSSIM) и др.

Целевая аудитория Open Source

    Несмотря на то что для большинства сегментов рынка ИБ существует то или иное открытое ПО, Open Source было и будет не для всех. Из-за специфики разработки у Open Source часто слабые так называемые нефункциональные возможности: производительность, вертикальная (по производительности) и горизонтальная (географическая) масштабируемость, отказоустойчивость, централизованное управление и т. п.

    Поэтому Open Source рационально применять в следующих случаях.

1. Отсутствие коммерческих продуктов нужного класса: например, в организации 3000 сотрудников и строгая приверженность контролю затрат и lean-процессам. SMB-продукты для нее уже малы, а Enterprise слишком «тяжелы».
2. Невозможность предсказания внутреннего спроса бизнеса на ИТ из-за бурного развития бизнеса. Отсутствие закупки лицензий, возможность вносить временные решения незамедлительно и с минимальным количеством ограничений позволят компании реагировать на рост бизнеса адекватно.
3. Отсутствие отечественных продуктов нужного класса и необходимость снижения валютных рисков. Ненормально, когда организация платит дополнительные сотни миллионов рублей, к примеру, производителю СУБД, только из-за изменения курса — не захватывая новые рынки, не выводя новые продукты и не предоставляя новой ценности потребителю.
4. Требования потребителей к ИТ-продукту усреднились, продукт вышел в фазу зрелости«, не является заметным для потребителя и Open Source позволит получить примерно ту же функциональность существенно дешевле и быстрее. Примерами могут быть OpenStack, OTRS, в пользу которых сделали выбор сотни организаций.
5. Есть идея по развитию бизнеса, но средств на ее тестирование нет, а на базе Open Source можно ее проверить и затем инвестировать в решение с уже подтвержденной привлекательностью для клиентов. Например, в моду входят порталы обмена информацией с клиентами, клиентам такая возможность должна понравиться при условии, что их информация будет надежно защищена, — и тут можно обратиться к Open Source-решениям secure sharing.

    С точки зрения финансового учета затраты на Open Source относятся к постоянным операционным (OPEX, фактически ФОТ), естественным конкурентом для открытого ПО являются коммерческие продукты со схемой продажи по подписке, а также бесплатные продукты. Выбор между вариантами нужно производить не только на основе финансового анализа (ROI, PBP, NPV и др.), но и понимая, сможет ли организация внедрить полноценную Open Source-стратегию, а так же не стоит ли попробовать Open Source для тестирования «легкого» (agile-like) подхода к развитию ИТ, опираясь на высказанную главой Сбербанка Германом Грефом на Гайдаровском форуме мысль: «Те кто не освоит Agile сегодня в текущих процессах бизнес-процессах, будут лузерами завтра». Если же приоритетными для организации являются сугубо финансовые аспекты, то перед сравнением вышеупомянутых вариантов стоит еще раз проверить возможность решения задач информационной безопасности встроенными средствами уже закупленных элементов экосистем Cisco, Microsoft, Oracle, SAP, IBM и др.

    С точки зрения минимизации стоимости владения конкуренцию Open Source также составляют продукты отечественных стартапов в бурно развивающихся сегментах WAF, SSO и др. Их цены обычно на порядок ниже цен промышленных западных решений и могут конкурировать с ними, даже учитывая дополнительные затраты на администрирование Open Source.

Open Source-стратегия

    Полная реализация потенциала Open Source требует не просто дать ссылку системному администратору на Snort с указанием «заменить коммерческий IPS», но внедрить новый подход к планированию, развертыванию и использованию ИТ. Подход, который, как и продукты Open Source, более легкий, гибкий и по природе более итеративный, чем коммерческие продукты.           Потребуется привнести в информационную безопасность черты agile, получая новую ценность ежедневно и постоянно определяя будущее, а так же переосмыслить требования к инженерным компетенциям службы информационной безопасности. Такой подход для многих организаций будет полезен сам по себе и изрядно снизит риски отставания производителей коммерческих решений от потребностей клиента. К примеру, один из ведущих разработчиков решений по управлению уязвимостями ИБ пять лет не дополнял свой продукт принципиально новыми возможностями. С Open Source необходимые для противостояния угрозам и реализации требований бизнеса изменения можно было бы вносить каждый день, изменяя подход с классического «что мы можем сделать с тем, что есть?» на более адекватный современной быстро меняющейся среде «что мы должны сделать, что бы быть защищенными от актуальных угроз с учетом нового бизнес-контекста?».

«Легкий» подход

    «Легкость» ни в коем случае не обозначает хаос, приводящий к потере прозрачности или управляемости, накоплению «технического долга», системных неуправляемых зависимостей или выбору неверной архитектуры, что в перспективе приведет к неприемлемо высоким затратам на реализацию нужной функциональности. Поэтому «легкий» подход при использовании Open Source должен состоять из трех процессов:

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

    Таким образом мы перераспределяем точки контроля до операционного процесса (определяя процесс управления архитектурой) и после операционного (определяя процесс управления знаниями). Использование всех трех процессов позволит не только управлять рисками использования Open Source но и получить значительную синергию между процессами, раскрыть полный потенциал открытого ПО.

Управление технологической архитектурой ИБ

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

• Анализ финансовых, политических, социальных и юридических особенностей среды функционирования и возможностей организации. Например, платежные системы и их уровень ИБ только пару лет как стали регулироваться законодательством о Национальной платежной системе, но в силу количества данных клиентов регуляторы всегда уделяли им очень много внимания. Другой пример — в Open Source не все классы решений ИБ достигли промышленного уровня, внедрение же не достигших такой зрелости решений должно иметь вескую причину.
• Анализ потребностей организации в обеспечении ИБ. Так, распределенная организация с единой сетью может потребовать контроля обеспечения ИБ в регионах, организация с большим числом удаленных работников — удобных и защищенных каналов связи.
• Формирование целевого ландшафта автоматизации ИБ — набора архитектурных решений ИБ с учетом реального состояния и возможностей организации. Например, будем ли мы автоматизировать управление инцидентами ИБ или их количество невелико и достаточно обычных Excel, Word и Outlook.
• Формирование дорожной карты автоматизации ИБ для достижения целевого ландшафта, включающей как минимум последовательность проектов\активностей, приоритизацию и ответственных за реализацию.

    Понятно, что для многих организаций полноценный процесс управления технологической архитектурой может быть избыточным. Однако внедрение даже его элементов позволит принять обоснованные решения и сэкономить организациям сотни тысяч и миллионы рублей.         «Живое» управление архитектурой так же позволит оперативно менять решения по итогам проработки бизнес-кейсов по конкретным проектам и прогнозировать влияние изменений в технологиях, объеме и сроках проектов на смежные системы\проекты. Среди лучших практик по управлению архитектурой можно упомянуть Open Group Security Design Patterns (2004), Fujitsu Enterprise Security Architecture (2007), Open Group Open Enterprise Security Architecture (2011), функциональную модель «Управлять непрерывностью безопасности бизнеса» (2013) РАНХиГС, IBM Security Blueprint (2013) и частично классические стандарты ISO 27002, Cobit 5 for Information Security.

Выбор, тестирование и управление средствами ИБ

    В «легком» подходе отсутствует выделенный этап внедрения, так как подход подразумевает постоянные изменения и совершенствование, распределяя риски внедрения по всему жизненному циклу технологии в организации. Риски управляются в первую очередь до внедрения: при выборе технологии Open Source и в ходе тестирования при проверке реальных возможностей технологии в продуктивной среде организации.

    При выборе Open Source необходимо обратить внимание на три аспекта:

1. Гибкость технологии. Например, в сканере уязвимостей должна быть возможность настраивать не только что проверять, но и как проверять, регулируя тем самым нагрузку на проверяемые объекты инфраструктуры и предоставляя возможность проверки без использования учетной записи Администратор\root.
2. Типовые слабые места Open Source — нефункциональные возможности\качества.
3. Управление рисками использования Open Source.

    В начале выбора решений необходимо сформировать функционально-технические требования (ФТТ), описав функциональные требования (что должно делать решение, какие типы контролируемых объектов поддерживать и т. п.), нефункциональные требования (производительность, масштабируемость, отказоустойчивость и др.) и требования к первичной настройке, после завершения и приемки которой пользователями (группой управления средствами ИБ) решение будет дальше управляться в рамках операционного процесса.

    Как и для каждого бизнес-проекта, для успеха Open Source-стратегии необходимо управлять рисками. Для открытого ПО ключевых рисков два — устойчивость сообщества\компании разработчиков (что будет с решением в будущем) и достаточность технологического уровня (сколько мы потратим на его доработку).

    Устойчивость сообщества\компании разработчиков возможно проверить задав ряд вопросов.

1. Кто стоит за продуктом? В идеальном случае это ИТ-гиганты — Cisco, Trend Micro, Singtel. Хорошим вариантом будут и общеизвестные крупнейшие сообщества — Apache Foundation, Linux Foundation либо сообщества, поддерживаемые известными ИБ-компаниями, например Open Information Security Foundation (поддерживается FireEye, Proofpoint, Positive Technologies и др.).
2. Обновлялся ли продукт в последние два года? Все, что не обновлялось, вряд ли стоит рассматривать без крайней нужды.
3. Распространен ли продукт? Распространенность можно оценить как на сайте разработчика, так и проведя поиск по названию продукта в LinkedIn. Например, NAC от PacketFence встречается сотни раз — всего лишь в 10 раз меньше, чем Cisco NAC, а NAC от одного из известных производителей ИБ указали в профилях всего несколько человек на все 400 млн. пользователей LinkedIn.
4. Существует ли коммерческая поддержка? Проекты одиночек с github могут существенно помочь, но ставить бизнес в зависимость от них рискованно.

    Достаточность технологического уровня двулика: с одной стороны, каждая организация может составить свои требования к решению и сверить с функциональностью конкретного продукта Open Source, с другой — критически важно использование продукта другими компаниями отрасли. Это существенная предпосылка к тому, что решение будет соответствовать потребностям компании как сейчас, так и в перспективе.

    Соответственно формируются три эшелона решений.

• 1-й эшелон. Известные средства с поддержкой известных производителей, объединений. История 10 лет+. Индустриальный стандарт де-факто, использование сотнями организаций, функциональность сравнима с коммерческими решениями сразу после установки либо донастройки в течение квартала.
• 2-й эшелон. Известные средства с поддержкой известных производителей, объединений. История 10 лет+. Индустриальный стандарт де-факто, использование сотнями организаций или функциональность сравнима с коммерческими решениями сразу после установки либо донастройки в течение квартала.
• 3-й эшелон. Остальные средства.

Класс решений	Эшелоны
	1-й	2-й
Управление уязвимостями	OpenVAS Nikto (web security)	nmap+sigvi+seccubus CFEngine (UNIX-like)
Log management\SIEM	OSSIM (AlienVault)	LOGalyze, Graylog, OpenSOC, Sagan, ELK stack, syslog
Network security monitoring	IDS Snort (Cisco), Bro, Suricata IDS GUI Security Onion, Snorby, Sguil, Squert Другое — Fail2Ban
WAF\AntiDdoS	Mod_security (Singtel) IronBee (Qualys)	TempestaFW, NAXSI
Strong authentication	WikID, LinOTP, privacyIDEA
Endpoint security	HIDS — OSSEC (TrendMicro)	Application Control: SELinux AppArmor (Novell)
Web security	Squid + SquidGuard + SAMS, DansGuardian, Zorp (Balabit)
Email security	SpamAssassin, ASSP, MailScanner
FW\UTM	ClearOS Community Edition, Pfsense, iptables + shorewall	Zentyal, Untangle NG Firewall Free Smoothwall Express, IPCop, Devil-Linux
NAC	PacketFence	OpenNAC
Secure sharing	Linagora, Pydio, Owncloud, ProjectSend
Шифрование на ПК	AxCrypt, VeraCrypt, GnuPivacy Guard, Gpg4Win
SSO	OpenAM (ForgeRock)	Gluu IdentityServerv3 WSO2 Shibboleth
Operations Management	OTRS, RT: Request Tracker
GRC	SimpleRisk, Eramba

    Как и в любой индустрии в Open Source security существуют «трудные дети» — классы решений, которые не могут похвастать богатым выбором и сильной конкурентоспособностью.

DLP

    Проект MyDLP выкуплен Comodo, официальных объявлений о его судьбе нет уже несколько лет. Проект Open DLP обновлялся еще в 2012 г.

IDM

    Существует целый ряд решений, в том числе такие именитые и финансово защищенные, как OpenIDM (ForgeRock), Syncope (Apache Foundation), OpenIAM (OpenIAM). Но на практике проектные риски внедрения такого класса решений больше любых других проектных рисков в информационной безопасности даже при условии использования ведущих производителей, отмеченных Gartner.

Антивирусы на рабочих станциях

    Распространенное мнение о возможности эффективной защиты рабочих станций Open Source антивирусом ClamAV является ложным. Официальная документация не обновлялась с 2013 г. и прямо говорит, что ClamAV предназначен для сканирования файлов, проходящих через почтовый шлюз. Остается разве что малоизвестный Moon Secure Antivirus, однако он испытывает жестокую конкуренцию со стороны бесплатных антивирусов с закрытым кодом — Immunet, Comodo, Kaspersky, Avira, Avast Business Edition Free.

Расследование инцидентов

    Набирающее популярность слово «кибербезопасность» на Западе обозначает в первую очередь технологии анализа вредоносного кода и расследования инцидентов. Сегмент новый, коммерческие внедрения общепризнанных лидеров Palo Alto\FireEye (с капитализацией на Нью-Йоркской бирже в 10\5 млрд. долл. соответственно) стартовали в России только два-три года назад. В Open Source присутствуют единичные решения по расследованию инцидентов, которые можно было бы назвать промышленными: «песочница» Cuckoo, набор для форензик-анализа The Sleuth Kit + Autopsy и агенты поиска продвинутых угроз Google Rapid Response.

    Увы, есть ряд востребованных задач клиентов, которые Open Source пока не в состоянии решить. Мониторинг баз данных (Database Activity Monitoring), управление классифицированной информацией (Information Rights Management) остаются терра инкогнито для свободного ПО. Впрочем, как и для коммерческого, ведь решения обоих классов можно пересчитать на пальцах одной руки, а магического квадранта Gartner для данных сегментов пока не существует.

Соединяя требования организации (ФТТ) и понимание доступности и возможностей Open Source средств защиты формируется шорт-лист (при наличии двух-трех решений 1-го эшелона можно просто взять их), проводится тестировании средств защиты. Необходимо в первую очередь протестировать слабые места — нефункциональные аспекты, так как именно они с наибольшей вероятностью могут вызвать проблемы, в том числе прерывания бизнес-процессов. Поэтому несоответствующие нефункциональным требованиям решения Open Source нужно применять только в случае крайне четкого бизнес-обоснования и осознанного принятия рисков нарушения доступности, невозможности или дороговизны масштабирования и т. п.

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

    Выбранное решение не выводится из пилота, а масштабируется до целевого на данном этапе размера. Производится приемка решения пользователями (User Acceptance Testing), например командой управления средствами ИБ, которой дальше придется развивать решение.

Управление знаниями в ИБ

    C момента остановки роста российской экономики в 2014 г. ландшафт угроз в очередной раз изменился — термины ShellShock, HeartBleed, фамилия Сноуден стали известны каждому сотруднику отрасли. Однако заметны не только качественные, но и количественные сюрпризы.   Так, компания Oracle выпустила 430 обновлений безопасности за IV квартал 2013 г., а за аналогичный период 2015-го уже 693, показав рост за два года в 60%.

    Сфера безопасности стремительно меняется и растет, все тяжелее поддерживать актуальность знаний о уязвимостями и угрозах, о политике и правилах применения средств защиты в текущей ситуации. При использовании коммерческих продуктов ситуация не драматична — производители понимают, что так называемый «контент» — встроенные правила и политики обновления проверок на уязвимости — является неотъемлемой частью их предложения ценности (value proposition) и содержат соответствующие лаборатории безопасности со штатом в десятки и сотни экспертов.

    В Open Source с контентом принципиально сложнее. Использование вышеупомянутых технологий 1-го "эшелона" несколько смягчит проблему, но для эффективного управления внедренными средствами защиты все же необходимо отслеживать новые тенденции и фиксировать их в разделе общей базы знаний — Project Pipeline (Воронка проекта):

    Далее служба ИБ приоритизирует требования по важности, формируя аналогично методологии Scrum так называемый Project Backlog (или Резерв проекта).

Project Backlog позволит, с одной стороны, формализовать требования к настройке — дать ориентир для оперативного планирования, с другой — дать обратную связь «с полей» процессу управления архитектурой, ведь в отличие от разработки ПО не все требования могут быть реализованы при настройке готового ПО из-за ограничений модели данных, производительности и т. п. При этом для 90% организаций гибкости Open Source будет достаточно.

    Требования из Project Backlog нужно передать в так называемый Sprint Backlog (Резерв спринта — план работ на неделю или другой период, на протяжении которого служба ИБ планирует существенный прогресс в настройке (собственно, сам «спринт»). Передача требований в Sprint Backlog происходит вместе с обсуждением реализуемости требований на базе существующих средств защиты, длительности и трудоемкости их внедрения с командой управления средствами защиты. В случае невозможности реализации обратная связь передается в процесс управления архитектурой для рассмотрения возможности изменения архитектуры, включения новых проектов в портфель проектов ИБ либо дополнения требований к идущим проектам по выбору средств защиты.

    Организации с несколькими изменениями в неделю могут совместить упомянутые артефакты (Project Pipeline, Project Backlog, Sprint Backlog) в одной таблице (плане), совмещающей три качества:

1. Запрошенные настройки (требования) нужны для повышения защищенности, обеспечения соответствия или других потребностей бизнеса.
2. Требования приоритизированы по важности уполномоченным организацией лицом.
3. Требования запланированы к реализации в конкретные сроки, и план позволяет проверить реализацию в выбранный интервал спринта (обычно одна-две недели для служб ИБ).

    Драйвером успеха является контроль прогресса реализации Sprint Backlog. Желателен двухуровневый контроль — в течение рабочего дня линейным менеджером группы управления средствами защиты и в течение периода спринта руководителем службы ИБ, аналогично процессу в заказной разработке:

    Процессная модель и ключевые артефакты «легкого» подхода приведены ниже:

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

Необходимые для «легкого» подхода компетенции

    Специфика «легкого» подхода в возрастающей важности личных качеств и снижающейся важности профессиональных навыков сотрудников для успеха. Это обусловлено более короткими циклами создания ценности\внесения изменений — меньшей цены ошибок, раннего их выявления — прозрачности, большей управляемости из-за понижения порога контроля.

Возникает парадокс «легкого» подхода: снижение средних затрат на сотрудника и, в частности, на его поиск из-за смещения фокуса с профессиональных на личные качества. Количество необходимых экспертов (часто избалованных высокими зарплатами) уменьшается, появляется возможность ориентации на молодых специалистов, региональные кадры, ИТ-администраторов общего профиля, ведь 100% соответствующих требованиям профессионалов в области управления технологиями Open Source security все равно нет.

    Нет их в штатах подразделений информационной безопасности, сотрудники которых исторически ориентируются в известных коммерческих средствах ИБ либо встроенных средствах защиты Microsoft, Cisco и др. Новый подход может потребовать переоценки компетенций сотрудников, проведения обучения\самообучения, постановки целей по изучению новых технологий, а возможно и расставания с теми сотрудниками, которые не смогут принять изменения. Для систематизации оценки рационально применение элементов и практик моделей компетенций по ИБ, таких как Skills Framework for the Information Age (SFIA), National Cybersecurity Workforce Framework и приложение к Cobit for Information Security.

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

    Глобальные корпорации ATOS, Fujitsu, NetCracker, Intel, IBM уже нанимают сотни ИТ-сотрудников в Воронеже и Казани, Нижнем Новгороде и Санкт-Петербурге, могут это делать и российские компании. 

    В свое время одна из крупнейших российских нефтегазовых компаний столкнулась со сложностью решения задачи по снижению затрат на мониторинг ИБ, так как 100% рыночных предложений по аутсорсингу были выше стоимости ее внутреннего сервиса, основанного на географически распределенной модели с операционным центром в Рязани. При этом качество мониторинга было одним из лучших в России, во многих компаниях ТОП-50 российской экономики до сих пор нет ничего подобного.

    Молодые специалисты могут работать в первую очередь не за деньги, но за опыт, знания, бренд работодателя, прозрачную карьерную перспективу — такая модель зарекомендовала себя в аудиторских компаниях Big4, которые за счет привлечения и использования труда молодых специалистов основную прибыль зарабатывают именно на них.

Заключение

    Open Source-стратегия может дать новое измерение свободы и контроля архитектуры ИБ для корпоративных служб ИБ. Важно не просто установить еще одно средство защиты, но протестировать «легкий» подход к управлению технологиями ИБ, а так же процессы управления архитектурой, провести мониторинг угроз для организации. 

    Применение описанной процессной модели позволяет сориентировать службу ИБ не просто на выполнение требований регуляторов или оперативное «тушение пожаров» хищений в ДБО, но увидеть слабые места и запустить два цикла совершенствования системы ИБ — стратегический (управление архитектурой ИБ) и тактический (управление знаниями ИБ).           Следует помнить, что внедрение Open Source-стратегии требует дисциплинированного подхода и управления рисками проекта реализации стратегии.