Saturday, June 9, 2018

Технологическая безопасность

Намедни читал сообщение от широкоизвестного производителя решений безопасности о том, как он изобрел новую революционную платформу для защиты технологических сетей (для упрощения далее буду писать "АСУТП"). Новость содержала ссылку на whitepaper из нескольких страниц, где можно узнать по новинке более детально. Я внимательно ознакомился с этой белобумагой и, поскольку подобные публикации неоднократно читал и у других вендоров, поймал себя на мысли, которой хочется поделиться.

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

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

С другой стороны,  не следует забывать АСУТП - это уже уровень приложения, автоматизирующего тот или иной бизнес-процесс. На этом уровне уже свои риски и сценарии атак (если быть точным, то в конечном счете риски одни и те же, и они бизнесовые, но на разных уровнях они выглядят по-разному, поэтому различны и подходы к их обнаружению и управлению), следовательно, свои модели нарушителей, следовательно, требуется реализация своих контролей безопасности. Риски информационной безопасности приложений всегда тесно связаны с рисками бизнес-процессов, ими автоматизируемых, правильно считать, что риски АСУТП - это проектция рисков бизнес-процессов на уровень приложения. Для какого-нибудь завода важна непрерывность технологического процесса, недопущение останова; контроль каких-то параметров работы оборудования для недопущение техногенной катастрофы; если сырье и/или готовая продукция ликвидны необходимо недопускать хищений, и т.п. Для розничной торговли на первый план выходит мошенничество (ну, безусловно простой тоже недопустим, ибо, например, для любой АЗС, точно понятна стоимость ее простоя в определенное время просто на основании статистики прошлой работы), причем здесь могут быть задействованы не только рядовые операторы POS-терминалов, но и обслуживающие ИТ-подразделения. Использование пластиковых карт для оплаты и различные программы лояльности добавляют новые риски и модели нарушителя. И так далее. В разных сетях автоматизации может быть по-разному. Важно понимать, что на уровне приложения уже следует заниматься снижением бизнес-рисков, а с вирусами и пр. стандартными вещами прекрасно справятся классические системы ИБ, от которых, как указано выше, не следует отказываться.

На практике можно делать это следующим образом: проанализировать бизнес-процессы, понять схемы мошенничества или любой другой вредоносной активности, несущей материальные риски, придумать как на уровне АСУТП эти риски адресовать; и здесь применяется концептуально тот же подход: предотвратить, если технически возможно, а если невозможно - достоверно обнаружить. Под материальным риском здесь понимаются те, что ассоциированы с реальным ущербом, никогда не следует охотиться на ведьм и приоритезироваться всегда в те 20%, которые дадут 80% результата. А достоверно обнаружить означает, что на уровне приложения и инфраструктуры риски, связанные с умышленным нарушением целостности логов, на основании которых мы судим о происходящем и фиксируем инциденты, адекватно адресованы. Security Operations Center здесь также может (и должен!) быть эффективным и результативным контролем безопасности, но в отличии от классического SOC, работающего, обычно, на уровне инфраструктуры и сражающегося в конечном счете с инструментами: сетевыми атаками, различными видами ВПО, этот, технологический SOC, будет искать мошенничество с пластиковыми картами и картами лояльности, нелегитимные изменения параметров технологического процесса, нарушение целостности метрологических систем, злоупотребления доступом и служебным положением и пр. сценарии атак и модели нарушителей, разработанные при анализе защищаемых бизнес-процессов и проектировании контролей безопасности. Организационные подходы к построению технологического SOC такие же как и в случае SOC для борьбы с инфраструктурными угрозами, но различна специализация персонала, который должен хорошо разбираться в защищаемом бизнес-процессе, чтобы корректно интерпретировать выявленные аномалии, говоря заумно, но короче, - правильно делать триаж.

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

Намеренно не хотел в посте ссылаться на какой-то личный опыт, чтобы никого и ничего не запалить, получилось несколько размыто, поэтому, хотя бы, подведу итоги.
1. АСУТП также крутится на инфраструктуре, поэтому классические системы инфраструктурной безопасности там также должны применяться.
2. Системы безопасности АСУТП работают на уровне приложения, поэтому, помимо контролей в инфраструктуре, они должны реализовывать меры на уровне приложений и прикладных протоколов.
2.5. Для вендоров, выросших из инфраструктурной безопасности и решивших подняться на уровень приложения, логичным кажется модульный подход, когда безопасность АСУТП (и любых других приложений, коими заинтересуется производитель) обеспечивается дополнительными компонентами к системам инфраструктурной безопасности. При таком подходе не теряется вся накопленная практика в области инфраструктуры, и продукт наделяется новыми "способностями" по обнаружению на уровне приложений. В конечном счете это разумно еще и потому, что есть масса приложений и разобр каждого из них в отдельном модуле позволит конечному заказчику, как конструктор, собирать функционал, релевантный ему.
3. Весь комплекс контролей безопасности, реализуемых на уровне инфраструктуры, как технических (например, анализ аномалий в протоколах), так и организационных (как, например, операционные сервисы безопасности: мониторнг и реагирование на инцидент, анализ соответствия требованиям и управление уязвимостями и т.п.), применим и на прикладном уровне, но с учетом соответствующей специфики. Это и есть еще одна перспектива эшелонированного подхода, когда один и тот же потенциальный сценарий атаки мы ловим на разных уровнях абстракции, используя разные подходы.
3.5 Технологический SOC - необходимое и абсолютно правильное явление, позволяющее адресовать риски на уровне бизнес-процессов посредством их обнаружения и расследования с помощью техничеких контролей, реализованных в специализированных приложениях и на инфраструктуре.
3.6 Технологический SOC может объединяться с классическим инфраструктрным SOC, например, как линия эскалации на экспертов в предметной области. Поскольку предметных областей много, как много и бизнес-процессов, и средств их автоматизации, - таких экспертных линий эскалации вполне может быть также много.


Monday, May 14, 2018

PHD'18: Threat hunting своими руками на базе open source

Привет всем любителям практической безопасности!
16 мая в 10:00 Теймур Хеирхабаров в рамках PHD будет проводить воркшоп по обнаружению атак. Настоятельно рекомендую выкачать все необходимое для этого хендзона заблаговременно, вот ссылка.

https://yadi.sk/d/qB1PNBj_3ViWHe

Увидимся на PHD!

Sunday, April 1, 2018

Сила действия равна противодействию

...во многой мудрости много печали; и кто умножает познания, умножает скорбь
(Екк. 1:18)
Сумасшедшим жить легко
(Пилот)


Я неплохо учился в институте, отчего остались различные приятные артефакты, позволяющие с улыбкой вспомнить прошедшее счастливое студенчество, поностальгировать... Однако, как бы это не странно звучало, весьма неплохие знания по предмету, отнюдь не позволяли мне просто и быстро сдавать экзамены и зачеты по ряду дисциплин. Экзамены у Алексея Евгеньевича я сдавал долго, так как по мере решения задачек, со словами что-то типа: "О, вы и это знаете?!", он давал новые, более сложные... Несмотря на кажущуюся нелогичность подхода, он абсолютно правильный: с ответственных больше спрос, а мучить нечего не знающего смысла никакого нет.
Другим воспоминанием из детства является выбор вида спорта после окончания музыкальной школы. Тогда мне казалось, что привлекательным была бы какая-то борьба, что позволит улучшить навыки самозащиты и защиты всего остального, что я считаю важным. Отец был против, аргументируя это тем, что если ты не профессиональный боец, тебя просто выключат, и быстрая потеря сознания, возможно, спасет тебе жизнь, однако, если ты будешь пытаться эффективно сопротивляться, тебя точно убьют. Мне искренне близка и сейчас мораль наших предков викингов, о том что лучшая смерть для мужчины - на поле боя, но в итоге я был отправлен на плавание...

Этот же принцип работает и в корпоративной защите. Атакующий всегда будет действовать по пути наименьшего сопротивления, с наименьшими затратами для себя. Нет никакого смысла применять сложные техники и разрабатывать продвинутый инструментарий для компании с низким уровнем ИБ. Напротив, для зрелого в части ИБ предприятия, атака будет сложной. Практически наверняка первичная компрометация закончится успехом, первоначальная мотивация заставит ребят возвращаться к вам снова и снова, а расследование инцидентов займет основную роль в вашем SecOps. Чем более продвинутой будет атака, тем сложнее будет ее обнаружить и остановить. Может сложиться так, что обнаружить атакующего можно будет только если он допустит ошибку, но, если он достаточно профессионален, вероятность, что он ошибется - невелика.
Получается, что совершенствуя защитные механизмы, мы провоцируем появление атак, которые сами же не сможем обнаружить. Если бы мы вообще ничего не делали по ИБ, нас бы примитивно ломали, что давало бы нам, в свою очередь, не напрягаясь справляться с этими взломами.
В этом случае весь SecOps можно свести к быстрому восстановлению (помните жидкого терминатора и как он здорово ожил потом). Только если уровень безопасности у нас низкий, то и атаки на нас будут простые, а поэтому расследовать и реагировать на них просто (== дешевле), так как проще решить много маленьких задачек, чем одну большую. Получаем, что помимо того. что мы вовсе не тратимся на безопасность, мы имеем еще дешевый респонс.

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

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

Tuesday, March 27, 2018

Функциональная и географическая этапность

Divide et impera! (лат)

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

Проблематика тривиальна. Если вы разрабатываете и внедряете сложную систему, то логично этот процесс построить так, чтобы эффект появился как можно быстрее и насколько возможно больший. Я верю в принцип Парето, поскольку ни раз сталкивался с его подтверждениями на практике. Исходя из него, вполне можно выделить 20% функционала системы, который даст 80% успеха. А раз так, пускай этот первичный набор "quick win-ов" и будет вашим первым функциональным этапом.
На второй функциональный этап можно отнести то, что не вошло в первый этап. Вроде бы тоже очень важные функции, но реализация их дорога и/или долга, т.е. это не будет "quick", или же, эффект от внедрения этих функций не будет столь искрометным по сравнению с другими, т.е. они не представляют собой "win".
Помня о том, что совершенство - недостижимо и можно вечно потчевать свой перфекционизм, мы получаем некоторую операционную историю постоянного совершенствования. Сюда же попадает развитие продукта, адресующее изменения в конъюнктуре рынка, вызовы времени и пр. факторы, требующие от продукта продолжать решать поставленные перед ним задачи с наилучшими показателями effectiveness и efficiency не смотря ни на что. Все это, и многое другое, включая плохо просматривающиеся, плохо понимаемые фичи, суть которых станет очевидней после появления практики использования функционала первых двух этапов, - можно отнести на третий этап, практически бесшовно переходящий в Operations.

Аналогичный подход можно применить и в географическом отношении, если вам надо внедрить проект во многих сотнях предприятий, расположенных во многих десятках регионах страны и Мира. Пусть первым этапом будут Пилоты - предприятия/регионы на которых можно собрать все возможные грабли и шишки с минимальными рисками. Скорее всего, внедрение вашей системы на предприятии будет отличаться в зависимости от особенностей предприятия (его технологической инфраструктуры, зрелости operations и т.п.). Поэтому, обычно выделяют "типовые площадки", отражающие все возможные сценарии внедрения/интеграции. Важно, чтобы в этап Пилотов попали площадки каждого типа.
Если в корпорации много дочерних предприятий, то, скорее всего, есть некий рейтинг, составленный по важным для бизнеса корпорации критериям. Это может быть прибыль, имидж, стратегический приоритет - да что угодно, важно, что сливками этого рейтинга являются Ключевые предприятия. Собрав все шишки на Пилотах и тем самым отработав порядок внедрения, можно рассматривать внедрение на Ключевых предприятиях следующим этапом, поскольку окучив их можно получить наибольший эффект от проекта в масштабах всей корпорации. Важно, однако, понимать, что характер разрабатываемой и внедряемой системы может определять внедрение на каких предприятиях даст больший корпоративный эффект. Поэтому, может сложиться так, что вторым приоритетом после Пилотов пойдут и не ключевые предприятия, но это как раз и есть тот самый контекст корпорации, с которым должна работать проектная команда, добиваясь как можно большего эффекта как можно скорее.
Отработав проблемы на Пилотах и добившись наибольшего корпоративного успеха на ключевых (или максимально релевантных проекту) предприятиях, оставшиеся предприятия - третий географический этап.

Имея функциональные и географические этапы, проект можно организовать как представлено на рисунке, выполняя параллельно работы по разным направлениям в разных географических локациях.
Что изображено на картинке?
I. Внедрение функционала первого приоритета в пилотных регионах/предприятиях.
II. Тираж функционала первого приоритета на Ключевые регионы/предприятия
III. Внедрение функционала второго приоритета там где, внедрен первичный. В остальных регионах/предприятиях – тираж функционала первого приоритета.
IV. В пилотных регионах/предприятиях – внедрение остального функционала. В остальных регионах – тираж функционала второго приоритета
V. Тираж остального функционала во всех оставшихся регионах

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

Thursday, March 15, 2018

Время материализовать облака

Мы рождены, чтоб сказку сделать былью
("Марш авиаторов", Герман-Хайт)

Спешите порадоваться спуску с горы, ибо далее придется тащить на себе санки
(Личный опыт из детства)

Абстрагируемся на время чтения этой заметки от того, что любая автоматизация всегда ведет к увеличению операционных затрат, - как бы там ни было, автоматизация - явление правильное и полезное, выводящее наши процессы на новый уровень. Разумно желание концентрироваться на основном бизнесе и не отвлекаться на различные инфраструктурные задачи, которые, собственно, и ведут к увеличению OpEx-ов, снижение которых - подтверждение эффективности разрабатываемых и обеспечиваемых нами бизнес-процессов. Однако, История держит свой путь по спирали и, несмотря на необратимость времени, мы с синусоидальной периодичностью приходим все в те же ситуации, то отвергая, то принимая вновь уже ранее обдуманные понцепты: железным инфраструктурам пришли на смену облачные, затем - гибридные, и сейчас мы становимся свидетелями балканизации, что снова нас возвращает к полностью on premise решениям, но уже на новом витке времени и понимания причин.

По моему субъективному мнению (лишний раз отмечу, что все статьи этого блога заключают в себе исключительно субъективное мнение) текущая кристаллизация on-prem из облаков создает удобную тенденцию создания хороших корпоративных продуктов из решений, ранее доступных только из облака. Посудите сами: огромная часть продуктовой инфраструктуры скрыта от глаз потребителя в облаке, что позволяет экономить на целом ряде вещей, малозначительных с точки зрения функционала, но принципиальных для on-prem решений: пользовательских интерфейсах, оптимизации аппаратных мощностей, алгоритмах обработки данных... - в целом, облачное решение даже может быть менее зрелым в функциональном плане, и все его недостатки могут быть скомпенсированы архитектурой бизнес-процессов, избытком инфраструктуры, дополнительными расходами на обслуживание. Говоря проще, - если интерфейс неудобный и требуется больше времени на решение каких-то задач - это можно скомпенсировать увеличенным количеством людей, если решение нестабильно - это можно скомпенсировать как многократным резервированием, так и усиленной ИТ-поддержкой, если код плохо оптимизирован - можно взять мощнее железо и т.д. Кроме того, в облаке можно делать полноценный Agile разработки - функционал можно расширять максимально быстро, так как связанные с этим риски можно временно скомпенсировать теми же немного завышенными расходами на людей и железо. И вот уже когда решение в облаке достигло требуемой зрелости, его можно материализовать в коробочный продукт, отвязанный от инфраструктуры вендора. Собрав все шишки и грабли в облаке, уже можно построить стабильное, красивое, удобное решение on premise, воплотившее в себе весь опыт облачного использования, решение, основанное на практике, обкатанное в "боевых" условиях. При этом, облачная инфраструктура по-прежнему останется логичной исследовательско-тестовой лабораторией для нового функционала on-prem решения, где все по тому же сценарию вызревшие в облачной эксплуатации фичи можно с минимальными рисками переносить в изолированные корпоративные инфраструктуры.

Обратный путь, - от on-prem к облаку, - нелогичен, так как несравненно сложнее, поскольку на первом же этапе надо обеспечить стабильность на миллионе комбинаций возможных инфраструктур Заказчика, с непредсказуемым operations и квалификацией персонала, более того, эти сложнейшие инфраструктурные проблемы не позволят как следует сконцентрироваться на функционале, отнеся эти, с точки зрения конечного потребителя, более важные задачи на второй план (действительно, когда там думать об удобстве пользования лопатой, если она рассыпается как только пользователь берет ее в руки!)... Поэтому правильным стратегическим решением сейчас может быть инвестирование в продуктивизацию до состояния качественного on-prem ранее исключительно облачных предложений со всеми сопутствующими артефактами успеха: обучением, документацией, сервисом продуктовой поддержки и поддержки на уровне бизнес-логики, а также процессами создания, отработки/вызревания нового функционала в облаке с последующим переносом его в изолированные корпоративные инфраструктуры. Спешите "оседлать" балканизацию, быть может, скоро спираль Истории изменит свое направление и вместо спуска по синусоиде, придется карабкаться в нее...

Saturday, February 3, 2018

Антивирусы и Песочницы

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

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

Anti-malware (АМ) движки - напротив, представляют собой реальную среду исполнения ВПО и поэтому дают максимально достоверные сведения об исполнении ПО в фактическом окружении. Реальные рабочие станции предоставляют более достоверную информацию для анализа. Но, поскольку реальные системы должны выполнять реальные задачи, а не функцию исследовательской инфраструктуры, возможно наличие ресурсных ограничений, не позволяющих "дотянуться" до всех интересующих компонентов. Ну и, конечно, ни о каких нестабильных перехватах речи идти не может.

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

Thursday, January 25, 2018

Истина по косвенным признакам

По плодам их узнаете их
(Матф.7:16)

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

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

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

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

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