Александр Иванович ДоронинБизнесразведка
 Скачать 1.89 Mb.
|
|
Глава 9. Информационно- аналитическая работа: создание интегрированного банка данных службы безопасности предприятия 1. Введение В настоящее время еще достаточно велик про- цент руководителей служб безопасности хозяйствую- щих субъектов, с недоверием относящихся к использо- ванию новых информационных технологий. Правиль- но считая агентурную работу приоритетной, они недо- оценивают возможность получения аналогичных дан- ных путем аналитической обработки различных (в том числе и открытых) источников информации{Главным отличием аналитической разведки от методов инфор- мационно-поисковой работы является использование вторичных источников оперативных данных (отчетов, справок, докладов, публикаций и т.д.).}. Как правило, это связано в основном с отсутстви- ем основанной на опыте методологии информацион- но-аналитической работы, что не дает возможность на конкретных результатах по достоинству оценить ее эф- фективность. В данной главе мы с вами попытаемся рассмотреть как конкретные методики аналитической разведки, ис- пользуемые в практической деятельности, так и при- мер создания самого важного инструмента аналити- ческой разведки{Аналитическая разведка – получение новых знаний об объекте оперативного интереса или явлении на основании аналитической обработки ра- нее добытой разведывательной информации и сведе- ний об известных фактах.} – информационной систе- мы службы безопасности предприятия. Сегодня, когда практически любое предприятие рас- полагает значительными информационными массива- ми, аналитическая разведка является первым (устано- вочным) этапом информационной работы, когда опре- деленным образом систематизированные сведения, оформленные в виде электронных баз и банков дан- ных, выступают в качестве исходных данных, предва- ряющих оперативные и оперативно-технические меро- приятия, ориентируя последние на конкретных лиц и события, связанные со сферой оперативных интере- сов службы безопасности. Таким образом, применение современных техноло- гий информационно-аналитической работы способно минимизировать затраты рабочего времени оператив- ного состава и значительно повысить качество ин- формационно-поисковой работы службы безопасно- сти, вывести ее на качественно новый уровень обес- печения безопасности хозяйствующего субъекта. 2. Краткая историческая справка Информация об объектах оперативного интереса накапливалась в компетентных органах издавна. Уже в незапамятные времена, когда письменность еще не получила широкого развития, молва о лиходеях-раз- бойниках расходилась далеко от их промысловых мест. Одной из самых первых попыток постановки кри- минального элемента на учет была методика клейме- ния преступников. Не будем вдаваться в обсуждение этичности этого мероприятия с точки зрения общече- ловеческих ценностей, хотя стоит отметить, что наи- большее распространение этот обычай получил имен- но в странах «просвещенной» Европы. Дальнейшим этапом развития «информационных технологий» стала систематизация информации о пре- ступниках в форме создания вначале простейших, а затем более сложных картотек, с помощью которых можно было идентифицировать их личности. Начало массового использования картотек относится к 70-80-м годам XIX века, когда учеты преступников и их сообщ- ников стали непременным атрибутом полиции и спец- служб многих страны. Не обошли новинки полицейской мысли и Россию. Так, например, уже летом 1871 года по секретному циркуляру началось создание «Алфавита лиц, полити- чески неблагонадежных» и альбомов с их фотографи- ями, куда заносились «все лица, которые почему-либо обращают на себя внимание правительства, преиму- щественно в отношении политической неблагонадеж- ности». Технология накопления этих материалов состояла из объединенной системы учета агентурной информа- ции и картотеки «алфавитных списков». Для учета и контроля поступавшей агентурной ин- формации на каждого секретного сотрудника заводи- лась особая тетрадь (книжка), куда заносились все по- лученные от него сведения. В конце тетради в алфа- витном порядке перечислялись фамилии и псевдони- мы (партийные клички) тех, о ком агент упоминал в сво- их сообщениях, со ссылкой на страницу, где это сооб- щение находилось. В свою очередь картотека «алфавитных списков» функционировала следующим образом: персональ- ные листы объектов оперативного учета нанизывались на специальную дугу общего архива и вносились в ре- гистратор всех лиц, проходивших по внутреннему и внешнему наблюдению. Если у революционера име- лось несколько псевдонимов, то на каждый из них со- ставлялся персональный учетный лист со ссылками на другие листы. В листах также имелись ссылки на ре- гистратор агентуры или номер агента, который явился источником информации. Сведения на одного фигуранта, поступающие от разных агентов, заносились на особый лист, где кон- центрировалась вся информация. Листы со сведени- ями о членах одной и той же организации нанизыва- лись на отдельный регистратор, на который делалась ссылка в листе, находящемся на дуге. Таким образом, уже в 1902 году спецслужбы царской России распола- гали именной картотекой, включавшей 65 тысяч учет- ных карточек, а архивы включали до 200 тысяч фо- тографий «государственных преступников» и «полити- ческие алфавитные списки лиц, разыскиваемых поли- цией с приложением фотографии и состоявших под негласным надзором»{Галвазин С.Н. Охранные струк- туры Российской империи. Формирование аппарата, анализ оперативной практики. – М., 2001.}. «Шьется дело!» – устало хмыкали сотрудники Де- партамента полиции, скрепляя досье «цыганской» иглой с суровой ниткой. Каждая категория объектов разработки, агентов и секретных сотрудников, каждая форма учета имела собственный цвет документации. Это позволяло ис- ключительно быстро находить любые материалы. В годы после Октябрьской революции многое из этого передового опыта с успехом применялось на Лубянке для нужд Советской власти. В качестве зарубежного примера можно привести механическую систему картотечной обработки инфор- мации, разработанную директором ФБР Эдгаром Гу- вером. Он предложил заполнять сведения о преступ- никах на специальных карточках, на которых поми- мо анкетных данных указывались ответы на много- численные вопросы о преступной «специализации» каждого фигуранта картотеки. Каждый положитель- ный ответ фиксировался путем перфорации соответ- ствующего поля карточки. При необходимости отбора подозреваемых по совокупности определенных при- знаков сквозь соответствующие отверстия (указываю- щие на необходимые признаки) продевались метал- лические спицы, и таким образом, отбирались ис- комые подозреваемые{Костин В.П. Тайная полиция США. ФБР: прошлое и настоящее, М.: Мысль, 1981.}. После появления компьютеров правоохранитель- ные органы и спецслужбы стали одними из самых пер- вых и благодарных их пользователей. «Призыв на се- кретную службу» компьютеров, способных за доли се- кунды обрабатывать тысячи записей, положил конец эре картотек, заполненных сотнями тысяч бумажных карточек. 3. Модели представления данных в электронных базах данных Внедрение новых информационных технологий не обошлось без трудностей, так как поначалу поиск в электронных картотеках оказался хотя и очень бы- стрым, но зачастую гораздо менее эффективным, чем поиск в обычной картотеке или традиционное изучение архивных дел. Это во многом было связано с тем, что в то время доступ к обрабатываемым данным осуще- ствлялся прикладными программами напрямую, а са- ми данные были организованы в виде плоских файлов. Возрастающие потребности в обработке информа- ционных массивов стали мощным стимулом развития теоретических основ информационных технологий и их практической реализации. Возникавшие проблемы с логической целостностью данных, а также невозмож- ность представить логические связи между ними в ука- занных выше системах стали причиной возникновения первой модели данных – иерархической. На сегодняшний день существует четыре модели{Моделирование данных – это выявление сущ- ностей (объектов), которые должны быть предста- влены в базе данных, и связей между ними.} пред- ставления данных: иерархическая, сетевая, реляци- онная (объектно-реляционная) и объектно-ориентиро- ванная. Между собой они различаются в основном спо- собами представления взаимосвязей между объекта- ми. Иерархическая модель данных стала применять- ся в системах управления базами данных в начале 60-х годов{Программные продукты, призванные рабо- тать со структурированными информационными мас- сивами, стали называться системы управления база- ми данных (СУБД). Система управления базами дан- ных предоставляет возможность контролировать зада- ние структуры и описания своих данных, работу с ними и организацию коллективного использования этой ин- формации. СУБД также существенно увеличивает воз- можности и облегчает каталогизацию и ведение боль- ших объемов хранящейся информации. СУБД включа- ет в себя три основных типа функций: определение (задание структуры и описание) данных, обработка и управление данными.}. Она представляет собой совокупность элементов, расположенных в порядке их подчинения от общего к частному и образующих перевернутое дерево (граф). Иерархическая модель данных строится по принци- пу иерархии типов объектов, то есть один тип объекта является главным, а остальные, находящиеся на низ- ших уровнях иерархии, – подчиненными. Между глав- ным и подчиненными объектами устанавливается вза- имосвязь «один ко многим». Иными словами, для данного главного типа объек- та существует несколько подчиненных типов объек- та. В то же время для каждого экземпляра главного объекта может быть несколько экземпляров подчинен- ных типов объектов. Таким образом, взаимосвязи ме- жду объектами напоминают взаимосвязи в генеалоги- ческом дереве за единственным исключением: для ка- ждого порожденного (подчиненного) типа объекта мо- жет быть только один исходный (главный) тип объекта. То есть иерархическая модель данных допускает толь- ко два типа связей между объектами: «один к одному» и «один ко многим». При моделировании событий, как правило, необхо- димы связи типа «многие ко многим». Как одно из возможных решений снятия этого ограничения можно предложить дублирование объектов. Однако дублиро- вание объектов создает возможности рассогласования данных. Приведу пример: объект «Иванов» может про- ходить как подчиненная связь объекта «Петров», и од- новременно имеется объект «Иванов» с подчиненной связью «Петров». Установить реально существующие связи ближайшего окружения «Иванова» и «Петрова» в этом случае достаточно проблематично. Иерархические базы данных по существу являются навигационными, т.е. доступ возможен только с помо- щью заранее определенных связей. Достоинство иерархической базы данных в том, что ее навигационная природа обеспечивает очень бы- стрый доступ при следовании вдоль заранее опреде- ленных связей. Однако негибкость модели данных и, в частности, невозможность наличия у объекта несколь- ких родителей, а также отсутствие прямого доступа к данным делают ее непригодной в условиях частого выполнения запросов, не запланированных заранее. Еще одним недостатком иерархической модели дан- ных является то, что информационный поиск из ниж- них уровней иерархии нельзя направить по вышележа- щим узлам. Чтобы устранить ограничения, свойственные иерар- хической модели данных, в начале 60-х годов, задол- го до появления компьютерных сетей, проектировщики баз данных создают сетевую модель данных, описы- вающую сети связей между данными. В сетевой модели данных понятия главного и подчи- ненных объектов несколько расширены. Любой объект может быть и главным, и подчиненным (в сетевой мо- дели главный объект обозначается термином «владе- лец набора», а подчиненный – термином «член набо- ра»). Один и тот же объект может одновременно вы- ступать и в роли владельца, и в роли члена набора. Это означает, что каждый объект может участвовать в любом числе взаимосвязей. Сетевая модель базы данных похожа на иерархи- ческую, однако характер отношений основных ее со- ставляющих принципиально иной. В сетевой модели принята свободная связь между элементами разных уровней, т.е. она допускает связи «многие ко многим». В качестве примера используемой на сегодняшний день СУБД, поддерживающей принципы сетевой моде- ли данных, можно привести инструментальную СУБД «Cronos Plus». Понятие реляционная модель ввел в 1970 г. Э.Ф. Кодц. В реляционной модели данных объекты и взаи- мосвязи между ними представляются с помощью та- блиц. Взаимосвязи также рассматриваются в качестве объектов. Каждая таблица представляет один объект и состоит из строк и столбцов. В реляционной базе данных каждая таблица должна иметь первичный ключ (ключевой элемент) – поле или комбинацию полей, которые единственным образом идентифицируют ка- ждую строку в таблице. Благодаря своей простоте и естественности представления реляционная модель получила наибольшее распространение среди СУБД для персональных компьютеров. Название «реляционная» (relational) связано с тем, что каждая запись в такой базе данных содержит ин- формацию, относящуюся (related) только к конкретно- му объекту. Кроме того, с данными двух типов можно работать как с единым целым, основанным на значе- ниях связанных между собой данных. Преимуществом реляционной модели перед други- ми моделями является простая и удобная для пользо- вателя схема данных, представляемая в виде таблиц. Физическая независимость реляционной модели со- стоит в том, что модель данных не включает ника- ких физических описаний. В действительности физи- ческое представление отношений и путей доступа опи- сывается независимо от описания логической схемы отношений. Недостатком реляционной модели данных является избыточность по полям (из-за создания связей). В качестве примера можно привести реляционные СУБД Microsoft Access и Borland Paradox. Объектно-ориентированная модель данных в от- личие от вышеописанных моделей, в которых инфор- мация и процедуры хранились раздельно (данные и связи между ними – в базе данных, а процедуры – в прикладной программе), позволяет хранить процеду- ры обработки сущностей вместе с данными. Такое со- вместное хранение считается шагом вперед в методах управления данными. Но объектно-ориентированные базы данных являются навигационными, что предста- вляется шагом назад. Объектно-ориентированная модель непосредствен- но поддерживает связи типа «многие ко многим». 4. Общие принципы создания информационной системы службы безопасности предприятия Как правило, при создании информационной систе- мы службы безопасности предприятия имеются три основные составляющие решения этой проблемы: на- личие вычислительной техники, программного обес- печения и квалифицированных специалистов, способ- ных ее создать и эксплуатировать. Самое главное, с чего необходимо начинать, – четкое определение за- дач, для решения которых будет приобретаться ком- пьютерная техника и программное обеспечение. Существует всего два пути создания информацион- ной системы. Первый – поставить техническое зада- ние и, продвигаясь путем проб и ошибок, попытаться создать «самое-самое крутое». Как правило, это доро- га в никуда, вымощенная крупными купюрами… Гораздо экономичнее купить готовое. Программное обеспечение, позволяющее организовать собствен- ный интегрированный банк данных, широко предста- влено на российском рынке, это «Cronos Plus», «Би- нар», «Саиб», «Лагуна», «Галактика», «Ватсон». Во- прос только в том, насколько приемлемым окажется соотношение цена/качество. В качестве базового программного продукта для со- здания информационной системы СБ предприятия мы с вами будем рассматривать программный комплекс, реализованный на базе системы управления базами данных «Cronos Plus». Инструментальная СУБД «Cronos Plus» предназна- чена для комплексной автоматизации широкого спек- тра информационных задач, от справочных до ситуа- ционных и экспертных, в организациях, чья деятель- ность требует анализа разнородных слабоструктури- рованных сведений об экономической, социальной, политической и иной обстановке. «Cronos Plus» это минимум ограничений и макси- мум возможностей, доступность и эффективность, гиб- кость и способность к совершенствованию. Систе- ма имеет четырехлетнюю практику эксплуатации. Эта ИСУБД позволяет отказаться от услуг штата програм- мистов и самостоятельно решать свои информацион- ные, аналитические и прогностические задачи. Систе- ма весьма проста в освоении и эксплуатации. Она обладает мощным поисковым аппаратом, многоуров- невой системой разграничения и контроля доступа к информации и режимам ее обработки, телекоммуни- кационным доступом к удаленному банку через Ин- тернет. Компактно хранит данные и фотографии, име- ет возможность «перенастройки» наполненного бан- ка без процедур реорганизации самим пользователем, аппарат вычисляемых полей и логических выражений обработки данных. В число пользователей ИСУБД входят: Главное управление Администрации Президента РФ, ФСБ РФ, МВД РФ, ФСНП РФ, Государственный таможенный ко- митет РФ, ГУ Центробанка по некоторым областям России, ряд крупных банков, таких, как Сбербанк РФ, «Менатеп-СПб», Внешторгбанк и Альфа-банк. Систе- ма «Cronos Plus» установлена на ряде крупных пред- приятий, в число которых входят: АО «АНТК им. Тупо- лева», Сахалинское морское пароходство, АО «Неф- тяная компания ЮКОС» и многие другие. Относительно невысокая цена, возможность бы- строго освоения системы пользователями-непрограм- мистами, а также гибкость пакета по отношению как к первоначальной настройке, так и к реорганизации наполненного банка данных, служит причиной его ис- пользования многими коммерческими структурами. Как мы с вами уже отмечали ранее, деятельность любого российского предприятия сопряжена с рисками экономического, криминального, социально-политиче- ского, административно-правового и техногенного ха- рактера. Источниками таких рисков могут выступать: – партнеры и контрагенты, экономическое состоя- ние которых может создать угрозу нанесения ущерба предприятию; – криминальные структуры, стремящиеся приобре- сти акционерское и иное влияние на предприятие; – недобросовестные конкуренты; – лица, вынашивающие противоправные и иные де- структивные намерения в отношении нормально функ- ционирующих негосударственных объектов экономи- ки; – отдельные сотрудники предприятия, пытающиеся удовлетворить личные коммерческие интересы за его счет; – негосударственные организации и отдельные ли- ца, специализирующиеся на проведении промышлен- ного шпионажа; – спецслужбы иностранных государств, ставящие своей целью добывание экономической и научно-тех- нической информации, а также осуществляющие под- рывные акции в отношении российских хозяйствующих субъектов и т.д. Как показывает практика, признаки угроз и кризис- ных ситуаций проявляются в разное время и со сто- роны различных объектов, фиксируются с различной степенью полноты и детализации различными источ- никами, для распознавания связи между ними требу- ются данные из многих источников. Установление при- чинно-следственной связи между происходящими со- бытиями требует проведения многофакторного анали- за всей поступающей на предприятие информации. Опыт внедрения информационных систем в служ- бах безопасности российских предприятий показыва- ет, что создание обособленных банков данных по каждой из указанных проблем не решает проблему комплексного управления экономической разведкой и контрразведкой. Для своевременного распознавания и правильно- го реагирования на возникающие угрозы необходима единая система накопления, обработки и выдачи ин- формации, используемая как непосредственно для из- учения источников риска или объектов интереса пред- приятия (лиц, организаций, сегментов рынка), так и для задач управления предприятием (кадры, перего- воры, документооборот, реклама и др.), которая позво- лит свести в единое целое все разрозненные сведе- ния, поступающие от руководства и производственных звеньев, отдела маркетинга, отдела кадров, службы безопасности, информационного отдела, из средств массовой информации, внешних компьютерных баз данных и других источников. Основными целями внедрения информационной си- стемы СБ предприятия являются: – упреждающее выявление угроз финансово-эконо- мического, социально-психологического и иного харак- тера внутри предприятия и в сфере его интересов; – информационная поддержка расследования служ- бой безопасности фактов нанесения ущерба предпри- ятию, систематизация результатов расследования для последующего использования; – информационная экспресс-оценка партнеров, кли- ентов, контрактов на предмет связи с источниками рис- ка; – информационный контроль развития инфраструк- туры рынка, конкурентов, их рекламных мероприятий; – информационное сопровождение собственных ак- тивных мероприятий на рынке (публикации, реклама, выставки, дезинформация); – комплексный контроль состояния защищенности важнейших объектов, ресурсов, коммуникаций, конфи- денциальных сведений; – обеспечение координации и взаимодействия функциональных подразделений предприятия на основе взаимного обмена информацией о его окруже- нии. Решение поставленных задач реализуется на осно- ве технологии интегрированного банка данных (ИБД) – инструментария, обеспечивающего автоматическое объединение (интеграцию) в общем банке данных раз- нородных данных по одним и тем же объектам (ли- цам, фирмам, адресам) путем их идентификации и отождествления (слияния). В процессе интеграции образуются цепочки взаимо- связанных объектов, выражающих признаки рисковых ситуаций, каналы нанесения ущерба предприятию, ка- налы экономической разведки конкурента, партнера и др. С помощью этого инструмента решаются как учет- но-справочные и статистические (кадры, контакты, со- бытия, партнеры, конкуренты, реклама и др.), так и ин- формационно-логические задачи (экспресс-оценка де- лового партнера, оценка инвестиционного риска, ана- лиз событий, изучение деловых связей конкурента, оценка сферы влияния, конфликтных и кризисных си- туаций и т.д.). Так, например, для комплексной оценки рисков ин- вестиционных устремлений к предприятию аналитик должен учитывать и оценивать следующие данные: – предложения по приобретению акций предприятия (в том числе устные и анонимные) со стороны внешних лиц и организаций, с фиксацией характера их осведо- мленности о предприятии и прозвучавших в предложе- ниях ссылок на третьи лица; – учредительские, акционерные, деловые и иные связи указанных лиц и организаций, их участие в за- регистрированных сделках с ценными бумагами пред- приятия, их связи с сотрудниками предприятия, воз- можные связи в криминальной среде; – акционеры предприятия, в том числе из числа со- трудников, динамика перераспределения акций; – факты давления на акционеров, создания вокруг них ситуаций, провоцирующих продажу ими своих па- кетов акций, и др. Перечисленные сведения рассредоточены по цело- му ряду источников, включая: а) структурные подразделения предприятия (отдел кадров, служба безопасности, отдел ценных бумаг); б) реестр акционеров предприятия; в) фондовые биржи (торговые площадки), на кото- рых обращаются ценные бумаги предприятия; г) органы государственной регистрации (налоговые инспекции, управления государственной статистики); д) средства массовой информации. Сведение воедино содержащейся в них информа- ции позволяет: – выявить инвестиционные устремления к предпри- ятию со стороны фирм и организаций, контролируе- мых криминальными структурами, установить круг ве- роятных авторов «анонимных» обращений; – распознать негативные тенденции в перераспре- делении акций (приобретение монопольного влияния на предприятие со стороны «портфельных спекулян- тов», иных недобросовестных партнеров); – предотвратить криминальные устремления к акци- онерам из числа руководителей и сотрудников пред- приятия, обеспечить необходимую фактуру для обра- щения в правоохранительные органы. В качестве конкретного примера давайте рассмо- трим историю «любви» крупнейшего германского кон- церна «Сименс» к предприятиям российского энерге- тического машиностроения (одной из немногих отра- слей нашего родного и многострадального ВПК, кото- рой в 90-е годы удалось не только уцелеть, но и серьез- но укрепить свои рыночные позиции). Во-первых, «Сименс» – это не только марка бытовой техники, но и один из ведущих производителей энерге- тического оборудования. Если обратиться к статисти- ке, то на долю «Дженерал электрик» приходится 35% мирового рынка, на долю «Сименса» – 24,1%, на долю АББ – 21%, а России остается лишь 2,2%. Во-вторых, на территории России находится более 700 электростанций общей мощностью свыше 215 млн. кВт, и в ближайшее время предстоит обновление значительной части их оборудования (в том же самом нуждаются и десятки объектов по всему миру, постро- енные в свое время СССР). А это миллиарды и милли- арды долларов. Правда, генератор для ГЭС от «Сименса» стоит при- мерно 2 млн. долл., а аналогичный генератор, произве- денный на российских предприятиях, – 800 тыс. долл. при одинаковом качестве. Естественно, что, получив контроль над российски- ми предприятиями, «Сименс» одним махом решает сразу обе проблемы – устраняет опасных конкурентов в лице предприятий «знергомаша» (ЛМЗ и «Электро- сила») и одновременно перехватывает выгодный заказ на модернизацию электростанций российского произ- водства. В результате активной скупки акций у «Сименса» оказалось 20% акций ЛМЗ и столько же «Электро- силы». Дальнейшие действия иностранного концерна точно ложатся в схему вышеуказанных логических по- строений. «Сименс» инициирует процесс банкротства ЛМЗ, и в результате представители концерна зани- мают ключевые позиции в комитете кредиторов ЛМЗ (шесть из девяти человек). Правда, закончилась эта история достаточно бла- гополучно. В результате усилий многих структур одна российская группа купила у «Сименса» долги ЛМЗ, и завод с первого полугодия 2000 года стал активно фор- мировать портфель заказов. Эффект от внедрения интегрированного банка дан- ных заключается в значительной экономии на коли- честве используемых компьютеров и обслуживающе- го персонала за счет слияния воедино всех информа- ционных и обрабатывающих ресурсов, устранения ду- блирования одних и тех же данных, прежде предста- вленных в различных учетах. Упрощается информаци- онное взаимодействие подразделений, и уменьшается время получения сведений. 4.1. Концепция построения интегрированного банка данных службы безопасности предприятия 4.1.1. Принципы построения системы: – головная роль службы безопасности в создании и эксплуатации системы в связи с ее ведущей ролью в комплексном противодействии угрозам безопасно- сти предприятия (СБ выступает в качестве основного потребителя информации ИБД, поставщика наиболее конфиденциальных данных, организатора и исполни- теля комплекса мер по защите ИБД как объекта); – поэтапная организация создания системы и посте- пенная доработка (с задач, по которым уже имеются электронные массивы данных – кадры, партнеры, кон- такты), начиная с минимальной технической конфигу- рации, наращиваемой по мере увеличения числа ра- бочих мест; – коллективный характер создания и эксплуатации ИБД (участие многих подразделений как в пополнении банка данных, так и в получении сведений из него по запросам способствует и взаимному учету интересов подразделений); – независимость работ по созданию, эксплуатации и развитию банка данных от разработчиков ИБД и иных специалистов в области программирования; – минимизация трудозатрат на эксплуатацию систе- мы (настройка на привычные формы организационных документов, получение данных в электронной фор- ме от подразделений абонентов, минимизация объема накапливаемой информации по каждому объекту уче- та); – разграничение доступа к данным и процедурам их обработки, симметричность данных на каждом уровне доступа для всех пользователей (от любого доступно- го объекта можно проследить связи к любому интере- сующему объекту); – стратегия наполнения банка данных – от собствен- ной инфраструктуры, объектов, персон и документов к внешним связям (формирование среды интересов). Затем фиксация значимых событий и изменений, про- исходящих с объектами этой среды. Опыт внедрения ИБД показывает, что к цели созда- ния единой комплексной системы в условиях дефици- та людских и материальных ресурсов следует двигать- ся поэтапно. Выделяются приоритетные направления для перво- очередной автоматизации (как правило, это – кадры, рынок, инвестиции), в рамках которых уже имеются электронные массивы данных. Осуществляется авто- матизированный перевод этих массивов в структуру ИБД с помощью штатного режима «Экспорт-импорт». При этом обычно расширяется круг задач, решае- мых на этих массивах. Затем в ИБД переводятся массивы данных, логи- чески связанные с уже введенными сведениями (на- пример, данные о регистрации, адресах и учредителях фирм – клиентов, партнеров и контрагентов предпри- ятия, их рекламе в прессе, арбитражные дела и т.д.), Также вводятся данные, непосредственно фиксируе- мые СБ: факты и события, связанные с нарушениями режимных мер на предприятии, утечкой конфиденци- альной информации, промышленным шпионажем, вы- могательством, шантажом и др. Первая практическая отдача от внедрения ИБД ча- сто отмечается вскоре после первого же объедине- ния разнородных массивов информации: так, объеди- нение данных о сотрудниках предприятия с данными об учредителях, руководителях и адресах регистра- ции фирм в регионе создает условия для «прозрач- ности» побочных коммерческих интересов сотрудни- ков, выявления каналов использования отдельными из них денежных средств и информации, похищенных на предприятии. По мере расширения тематики накапливаемых дан- ных происходит наращивание конфигурации ИБД от единственного компьютера до локальной или распре- деленной информационной сети, охватывающей не- сколько подразделений предприятия. 4.1.2. Порядок создания интегрированного банка данных на базе ИСУБД «Cronos Plus» 1. Разработка службой безопасности предприятия предложений по созданию интегрированного банка данных. 2. Подготовка и оформление высшим руководством распоряжения о создании ИБД. Выводы о необходимо- сти создания. 3. Ответственные подразделения начинают пред- проектное обследование информационных потребно- стей предприятия в создании ИБД: – интервью с руководством предприятия; – интервью с руководителями структурных подраз- делений предприятия. В данных интервью должны быть получены и проработаны ответы на следующие вопросы: – задачи СБ в функциональных обязанностях и пер- спективы их изменения; – потребности в информации для решения конкрет- ных информационных задач: – предметная область ИБД; – источники получения интересующей информации; – форма и регламент поступления информации из структурных подразделений предприятия; – примерные объемы поступающей информации; – форма выдачи информации в заинтересованные подразделения; – требования к взаимодействию между структурны- ми подразделениями предприятия по сбору информа- ции; – способы обращения к данным при решении кон- кретной информационной задачи: – регламент поступления заявок на информацион- ное обслуживание; – поисковые условия обращения к данным: опосре- дованные и не опосредованные; – условия на обработку; – ревизия имеющихся в наличии средств автомати- зации; – требования по доступу к накапливаемым инфор- мационным массивам. Чем больше информации о задачах, которые будут поставлены перед банком данных, вы соберете, тем лучше. Завершает этот этап отчет, где ясно и четко про- писываются вышеизложенные вопросы. 4. Концептуальное проектирование структуры ИБД. Четкое определение классов объектов учета и их свя- зей между собой. 5. Установка программно-технического обеспече- ния, настройка прикладного программного обеспече- ния, настройка на состав объектов учета на пред- мет связей и характеристик, формирование словарей (справочников). 6. Подготовка инструкций по эксплуатации и ввод ИБД в эксплуатацию. 4.1.3. Концептуальное проектирование типовой структуры ИБД Исследование предметной области А теперь, получив необходимый объем теорети- ческих знаний, давайте попытаемся описать модель предметной области интегрированного банка данных службы безопасности предприятия. Сложность ее мо- делирования, как мы уже говорили, основывается на том, что информация об объектах оперативного инте- реса СБ, как правило, слабо структурирована, т.е. но- сит отрывочный и разрозненный характер. Это связано с тем, что она добывается при помощи различных ме- тодов и средств из сильно отличающихся друг от друга источников. К сожалению, в настоящий момент такая область ин- формационно-аналитической работы, как теория ло- гического проектирования специальных баз и банков данных, незаслуженно обойдена вниманием как в спе- циальной, так и научно-популярной литературе. Для проведения качественной информационно-ана- литической работы требуется разноплановая инфор- мация, характеризующая различные взаимосвязан- ные аспекты анализируемой проблемы. Также требу- ются данные о структуре решаемой задачи, которая должна, как мозаику, соединить между собой различ- ные информационные фрагменты и образовать макси- мально приближенную к реальности полную и целост- ную картину предметной области. Предметная область представляет собой весьма сложную систему, так как в круг интересов хозяйствую- щего субъекта вовлекается большое количество физи- ческих и юридических лиц, взаимосвязанных различ- ными отношениями политического, экономического и социального характера. Для изучения и нейтрализа- ции факторов риска, активизация которых может на- нести моральный или материальный ущерб защища- емому хозяйствующему субъекту, оценки и прогнози- рования складывающейся оперативной обстановки на предприятии и вокруг него применяются специальные методы формализации и интеграции полученной ин- формации. Помимо этого при моделировании принципиальное значение имеет связное представление информации. Построение модели предметной области базы или банка данных – это искусство выявления объектов, ко- торые должны быть там представлены, с дальнейшим выстраиванием связей между ними. Прежде всего, следует решить, для чего все-таки со- здается банк данных, т.е. какие задачи он должен ре- шать и какая информация в нем будет храниться. Ис- ходя из этого, можно определить, какие базы данных будут входить в банк данных. И из каких полей должны состоять эти базы данных. Таким образом, для опре- деления структуры банка данных необходимо сначала исследовать предметную область. При моделировании предметной области интегриро- ванного банка данных необходимо не только выделить и описать элементы (базы данных) данной области, но и установить отношения (связи) между ними для воз- можности динамического отображения в ИБД структу- ры взаимодействия объектов оперативного учета. В процессе накопления информации эти взаимодей- ствия позволяют моделировать изменяющиеся с тече- нием времени организационные структуры, фиксиро- вать и прогнозировать происходящие в них процессы, определяющие существенные свойства и закономер- ности изучаемой предметной области. Определение баз данных. Структуру интегриро- ванного банка данных определяет конкретный состав баз данных в банке и их связи между собой. Спроек- тировать структуру банка означает определить все ин- формационные единицы (базы данных, состав полей) и связи между ними; задать их имена. Основными элементами предметной области ИБД службы безопасности предприятия являются объекты оперативного учета: физические лица, организации, документы, адреса, телефоны, рефераты, автотранс- портные средства, договоры и переговоры. При проектировании базы данных каждый такой элемент будет описан в соответствующей базе дан- ных. Структура базы данных – характеристики инфор- мационного объекта, отражаемые при ведении опера- тивного учета. Кроме того, информация, описывающая состояние связи между объектами оперативного учета, будет фиксироваться в специальных БД связей: связь между физическим лицом и организацией (учредитель, руко- водитель, сотрудник), связь между двумя физически- ми лицами (дружеские, служебные, криминальные, не установленного характера), связь между физическим лицом и адресом (место прописки, проживания, посе- щения) и т.д. Такая структура банка данных позволяет накапли- вать дополнительную информацию об опосредован- ных взаимосвязях и их структуре. Эта информация может быть получена путем динамического отслежи- вания не только прямых, но и ассоциативных связей лиц производственно-экономического (договорные от- ношения – связь через документ, соучредительство – связь через организацию или документ, совместная ра- бота – связь через организацию) или криминального характера (участие в преступной группировке или со- общение – связь через организацию, соучастие в пре- ступлении – связь через событие). Подобный интегрированный банк данных обладает достаточной эволюционной самостоятельностью и по- зволяет организовать интеграцию разнородных сведе- ний по одним и тем же объектам (лицам, фирмам, адресам, телефонам, автотранспортным средствам) путем их идентификации и слияния по мере поступле- ния новых данных. Таким образом, при введении но- вых объектов происходит установление связей между ними и уже имевшимися объектами, а также дополне- ние уже имевшихся объектов новыми характеристика- ми. В результате наращивается сетевая структура свя- зей объектов и образуется «производная» информа- ция, не вводившаяся в явном виде в банк данных, ста- новится возможным проследить цепочки взаимосвя- занных объектов, выражающих признаки рисковых си- туаций. Идея интеграции этих сведений состоит в том, что, если в процессе работы лицо или адрес раньше по- являлись по другому сообщению, система при заклад- ке информации вторично сама, без какой-либо коман- ды со стороны пользователя сливает по указанным объектам учета то, что было, и то, что внесено в дан- ный момент. Как раз при таком слиянии образуются и наращиваются цепочки причинно-следственных свя- зей. При закачке разнородной информации именно на ее стыках и получаются самые интересные вещи. До- пустим, сливается база данных отдела кадров, база данных регистрационных органов, из текстовых фай- лов заносится информация о рекламе, в результате дальнейшей информационно-поисковой работы служ- бы безопасности по подтверждению информации ИБД отрабатывается ряд моделей возможных связей объ- екта оперативного интереса. В условиях такого описания структуры предметной области достаточно выйти на один информационный объект, чтобы по связям исследовать его окружение. Но здесь нужно учитывать то, что между двумя объек- тами уже где-то на пятом-шестом уровне можно обна- ружить связь, которая может не иметь никакого отно- шения к исследуемой проблеме. Выделим в типовом интегрированном банке данных следующие основные базы данных. 1. «Лицо» – физические лица (как субъекты или участники различных событий). 2. «Организация» – организации (юридические ли- ца, предприниматели без образования юридического лица, общественные организации и партии, преступ- ные группировки или сообщества). 3. «Адрес» – адреса (место события, жительства, работы, дислокации организации), телефон (контакт- ный, домашний, служебный и т.д.). 4. «Документ» – документ, используемый лицом для идентификации своей личности. 5. «Реферат» – реферат (текст статьи, сообщения доверительного помощника, документа, устного сооб- щения и т.д.). 6. «Автотранспортное средство», автотранспортное средство (принадлежит лицу или организации, упра- вляется по доверенности, указано в реферате). 7. «Договор», договор (исполненный, заключенный и т.д.). 8. «Переговоры» – переговоры (состоявшиеся, гото- вящиеся). Базы данных связей: 9. «Связь между лицами». 10.«Связь между лицами и адресами». 11.«Связь между лицами и телефонами». 12.«Связь между лицами и организациями». 13.«Связь между лицами и автотранспортными средствами». 14.«Связь между организациями». 15.«Связь между организациями и адресами». 16.«Связь между организациями и телефонами». 17.«Связь между организациями и автотранспорт- ными средствами». 18.«Связь между адресами и телефонами». Логическая модель данных, реализуемая средства- ми ИСУБД «Cronos Plus», обладает гибкостью, имеет- ся возможность многовариантных перекрестных ссы- лок из одного свойства на различные объекты опера- тивного учета. Механизм взаимосвязей классов в ИСУБД «Cronos Plus» позволяет учитывать не только многовариант- ность, но и направленность ссылок между объектами банка данных. Ссылки могут быть равноправными или иерархическими. Навигация по банку данных «Cronos Plus» между объектами, связанными системой равно- правных отсылок, никак не ограничена и может осу- ществляться в любых направлениях, как вперед, так и назад, так как на этапе ввода информации при за- дании «прямой» ссылки на объект, связанный с исход- ным объектом равноправной отсылкой, «обратная» от- сылка устанавливается автоматически. В случае ис- пользования иерархических отсылок пользователь бу- дет видеть только те объекты, на которые идут ссылки из данного объекта, но не увидит объектов, из которых идут на него ссылки. Определение полей баз данных. На этом этапе определяется, из каких полей должна состоять ба- за данных, т.е. какую информацию она должна со- держать. Каждое поле должно соответствовать общей смысловой направленности базы данных. Сведения, отражаемые в базе данных «Лицо»: – функциональные обязанности, материальная от- ветственность; – проблематика деятельности; – условия приема на работу, кто рекомендовал; – поощрения, взыскания, профилактические меро- приятия; – прежние места работы, характер функций; – участие в мероприятиях с участием внешних парт- неров предприятия (приемы, командировки, интервью, презентации); – получение денежных вознаграждений от третьих лиц; – тяжелые психические заболевания, неуживчивый характер; – наличие судимостей; – побочные коммерческие интересы вне предприя- тия. Сведения, отражаемые в базе данных «Рефе- рат»: – факты противодействия установкам руководства; – контакты в криминальной среде; – попытки внесения самостоятельных изменений в финансово-хозяйственную деятельность предприя- тия; – конфликты в связи с пребыванием на работе в со- стоянии алкогольного или наркотического опьянения; – внерабочие конфликты в связи со служебной дея- тельностью; – участие в разборе споров с помощью «третьих лиц», в том числе навязывание криминальной «кры- ши»; – противоречия и споры с государственными органа- ми; – участие предприятия в арбитражных спорах; – факты утечки информации через сотрудников предприятия; – факты краж оборудования, материальных ценно- стей, документов; – факты участия предприятия в операциях повы- шенного риска; – факты невозврата предприятию финансовых средств за отгруженную продукцию; – умышленные нарушения финансовой дисциплины персоналом; – фальсификация финансовой документации; – срыв экономических программ и проектов пред- приятия в результате ошибок персонала; – кража, разрушение магнитных носителей с данны- ми закрытого характера. Выводы На сформированной таким образом информацион- ной базе решается широкий спектр задач в интересах различных подразделений предприятия: – выявление среди партнеров, а также разовых по- сетителей предприятия лиц и организаций, имеющих признаки связи с вероятными источниками угроз (кон- курентами, мошенниками, фирмами-банкротами, кри- минальными структурами, предъявителями фальши- вых документов, участниками иных чрезвычайных про- исшествий и событий в окружении банка); – оценка кандидатов при приеме на работу (места прежней работы, репутация кандидата и фирм, где он работал; возможные связи с конкурентами, партнера- ми по рынку, криминальными и мошенническими струк- турами; причастность к всевозможным ЧП, характер и объекты собственных коммерческих интересов и др.); – анализ инвестиционных предложений предприя- тию (учредительские, акционерные, иные связи инве- стора (агента на фондовом рынке), его зависимость от крупнейших стратегических инвесторов, партнерские связи и опыт деятельности на фондовом рынке, пере- сечение связей с другими акционерами предприятия, цели и стратегия инвестора, чьи интересы он выра- жает, оценка рентабельности инвестиционного проек- та для предприятия и риска его внешней зависимости); – первичная оценка и текущий контроль экономи- ческого состояния крупных партнеров и контрагентов предприятия (оценка платежеспособности, контроль исполнения договоров, участие в поиске цепочек пога- шения задолженностей); – оценка надежности и устойчивости банков и иных категорий партнеров предприятия; – поиск условий и обстоятельств, конкретных участ- ников событий, приведших к нанесению ущерба пред- приятию. Изучение связей участников (выход на ис- точники угроз предприятию, аналогичные факты в про- шлом, конфликты интересов внутри предприятия); – поиск признаков подготовки и нанесения ущерба персоналу, руководству, объектам предприятия; – поиск каналов и источников изучения конкурентов предприятия через их учредительные, акционерные, партнерские, территориальные связи; – отслеживание макроэкономических изменений и конкретных событий, свидетельствующих о новых фак- торах конкурентной борьбы, взаимоотношениях с госу- дарством, правовых условиях хозяйствования; – поиск данных о совершенных и планируемых пе- реговорах, командировках, выставках, публикациях, иных внешних контактах функциональных подразде- лений предприятия, относящихся к данным пробле- мам, объектам, регионам (в интересах постановки службой безопасности задач по экономической раз- ведке и контрразведке, поиска источников дополни- тельной информации о внешней среде предприятия); – поиск всех прямых и опосредованных связей за- данного объекта (проблемы, документы, лица) в ин- фраструктуре предприятия, а также данных о защите соответствующих каналов административными, орга- низационными и оперативными мероприятиями. Интегрированный банк данных может помочь как в оценке степени достоверности оперативной информа- ции, так и в контроле «чистоты» аппарата доверитель- ных помощников. По классике жанра информация счи- тается достоверной, если ее подтверждают три раз- личных источника. Однако, как правило, одному опе- ративнику бывает достаточно сложно получить три не- зависимых сообщения об одном и том же объекте или событии. Учитывая постоянную загруженность оперсо- става и конспиративную специфику его работы, труд- но рассчитывать, что три оперативных работника, по- лучивших аналогичные сообщения от своих агентов, смогут самостоятельно обнаружить совпадения или противоречия в информации и сделать из этого пра- вильные выводы. Помимо этого банк данных может дать ответы на во- прос, имеются ли у СБ возможности, способные допол- нить полученную информацию, а также выяснить, ка- кие приемы применялись раннее в аналогичных ситу- ациях и к чему это привело. В качестве подтверждения этого тезиса приведу еще один пример, из прессы поступает сообщение о пред- стоящем инвестиционном конкурсе на предприятии смежной отрасли. Как обычно, информации о продава- емом предприятии и участниках конкурса крайне мало, чтобы принять решение об участии в конкурсе и такти- ке поведения на нем. Однако в имеющейся интегриро- ванной среде мы находим введенные отделом кадров данные о сотруднике одного из подразделений наше- го предприятия, который ранее работал в дочерней фирме продаваемого концерна. Затем через его воз- можности получаем интересующую информацию, обо- гащая ее данными из средств массовой информации и данными службы безопасности, экономя при этом несколько сотен долларов, которые стоила бы соот- ветствующая экономическая справка, заказанная в ин- формационном агентстве. Задачи, решаемые на интегрированной информаци- онной базе, не затрагивают процессов принятия упра- вленческих решений руководителями подразделений предприятия, но позволяют по запросу получить в виде «досье» структуру прямых и опосредованных связей изучаемого объекта и очертить среди них «проблем- ные точки» (выходы на источники угроз или объекты интереса предприятия). По некоторым необходимо ве- сти детальный анализ с подключением всех информа- ционных ресурсов предприятия. Использование собственного ИБД позволяет макси- мально ограничить число и содержание заказываемых у внешних источников запросов с соответствующей экономией средств на оплату информационных услуг и исключает вероятность утечки информации к объек- ту оперативного интереса. |