ЧАСТЬ ПЯТАЯ. СУГГЕСТИЯ И БЕЗОПАСНОСТЬ

26 (2).3. Выявление скрытых образований

(проблема исследования алгоритма)

Тем и страшен невидимый взгляд,
Что его невозможно поймать;
Чуешь ты, но не можешь понять,
Чьи глаза за тобою следят.

А.Блок.

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

Прежде чем приступить к исследованию этой задачи еще раз посмотрим - а каким образом суггестивные включения попадают в систему?

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

Жизненный цикл любого программно-аппаратного комплекса условно может быть поделен на следующие этапы:

1) разработка;

2) производство;

3) доставка и установка у потребителя;

4) функционирование у потребителя.

Программно-аппаратная закладка может быть включена на любом из перечисленных этапов.

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

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

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

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

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

первый этап - закладка на генетическом уровне - относится к родителям системы;

второй этап - закладка в процессе получения базовых знаний (язык, правила поведения и т.п.) - относится к раннему детству;

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

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

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

Почему? Где корни этого поступка? Как предсказать подобный поступок и самое главное, как предотвратить его?

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

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

Компьютер вдруг замерцает экраном в такт мигания светодиодов у дисководов.

Писатель сожжет второй том "Мертвых душ".

Итак, представим в качестве исходных данных следующие объекты:

1) исполняемый код системного программного обеспечения

(операционную систему);

2) человека;

3) народ.

Задача заключается в разработке метода выявления скрытно внедренных средств в управляющие механизмы вышеперечисленных информационных самообучающихся систем.

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

Проверку того, что программа должна выполнять, с тем, что она реально выполняет, принято называть тестированием.

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

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

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

1) проверка на наличие контактов, во время которых могло быть осуществлено скрытое заражение со стороны противника;

2) проверка на "детекторе лжи";

3) проверка на наличие психических отклонений.

Что интересно, названные приемы не дают и не могут дать 100%-ой гарантии в том, что изучаемый объект заражен или не заражен. В чем тогда смысл всей этой работы?

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

Если же рекомендации кадровой службы не принимаются во внимание или накладывается запрет на проведение ею соответствующих проверок, то это неизбежно приводит к ослаблению уровня безопасности.

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

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

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

Что же тогда получится?

Итак, начнем с проверки на наличие контактов, в ходе которых возможно скрытое заражение. Для программного обеспечения данная проверка заключается в минимизации контактов предполагаемых к использованию программ и данных с какими бы то ни было людьми ли, организациями ли. Желательно чтобы продукт поступал непосредственно от разработчика напрямую. В том случае, если программное обеспечение предполагается использовать в сфере управления государством (в сфере обеспечения безопасности) идеальным вариантом была бы разработка его коллективом, которому государство может доверять, т.е. коллективу, который сам прошел соответствующую кадровую проверку. Тогда данное программное обеспечение можно было бы назвать довершенным. Именно это, кстати, утверждал в 1983 году лауреат премии Тьюринга К. Томпсон: "До какой степени можно полагаться на утверждение, что программа не содержит "троянских коней"? Возможно, более важно - полагаться на людей, написавших эту программу."

Если Заказчик полагается на Исполнителя, тогда все остальные проверки (за исключением общепринятого тестирования) являются избыточными.

Рассматривать програмный продукт в отрыве от его производителя в корне неверно еще и потому, что нельзя из потока версий одной и той же программы выделить одну.Они только все вместе образуют ту систему, которой свойственно самообучение, в которой существует обратная связь через пользователей и разработчиков.Продукт плюс разработчик - вот основные составляющие того что принято называть программным обеспечением.

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

Прежде чем ответить на вопрос: Что означает термин "детектор лжи" в приложении к программному обеспечению? - исследуем принципы функционирования "детектора лжи" применительно к выявлению тайн человека. Здесь и далее понятие "детектор лжи" имеет не обычную, а несколько расширенную трактовку, под "детектором лжи" понимается алгоритм работы некоего человеко-машинного комплекса, позволяющий организовать информационное взаимодействие с исследуемым объектом таким образом, чтобы в процессе этого взаимодействия выявлять наличие у исследуемого объекта скрытых знаний по определенной теме. При этом алгоритм работы детектора лжи во многом опирается на принципы хранения и извлечения данных из памяти. У такой самообучающейся системы, как человек, для поиска данных привлекаются все возможные ассоциативные связи, во многом обусловленные эмоциональными переживаниями. У компьютера эмоциональных переживаний пока нет и поиск в его базах определяется соответствующими индексами и указателями. Достаточно сложно на сегодняшнем уровне развития программного обеспечения предложить для ЭВМ те методы проверки, которые разработаны К.Г.Юнгом и замечательно обыграны в рассказе К.Чапека "Эксперимент профессора Роусса" [103]. Суть метода профессора Роусса в том, чтобы дать простор подсознательным ассоциациям, т.е. в ответ на услышанное слово говорить первое, что придет в голову.

Вопрос:
- Дорога
- Прага
- Спрятать
- Чистка
- Тряпка
- Лопата
- Яма
- Труп!
Ответ:
- Шоссе
- Бероун
- Зарыть
- Пятна
- Мешок
- Сад
- Забор
?

- ...Вы зарыли его под забором у себя в саду, - решительно повторил Роусс. - Вы убили Чепелку по дороге в Бероун и вытерли кровь в машине мешком. Все ясно.

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

Аналогичным образом может работать "детектор лжи" при выявлении не только скрытых знаний, но и скрытых способностей. Например, резкий выброс в скорости набора на клавиатуре отдельных слов позволяет утверждать, что они ранее чаще других набирались испытуемым, а значит - он имеет к ним более "близкое" отношение [76].

Так какие вопросы задавать и как оценивать ответы должен "детектор лжи", объектами которого являются программные продукты?

Вернемся к данному выше определению "детектора лжи". "Детектор лжи" предназначен для выявления знаний у исследуемого объекта исключительно по определенной теме. Какие темы в приложении к программным средствам скрытого информационного воздействия могут нас так заинтересовать, что придется применять "детектор лжи"? В первую очередь:

1) способен ли исследуемый программный продукт скрытно фиксировать в незащищенном виде для последующего изъятия вводимые оператором пароли?

2) способен ли исследуемый продукт при определенной комбинации условий уничтожить или методично искажать обрабатываемые им данные и результаты?

Психология bookap

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

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