Вы находитесь в разделе Типовых решений систем безопасности
Защита от инсайдеров. решение может быть только комплексным ,часть1,В последнее время защита от инсайдерских атак (защита данных от хищения санкционированными – допущенными к обработке информации на компьютере в рамках выполнения своих служебных обязанностей, пользователей) приобрела особую актуальность. Это обусловлено, с одной стороны, ростом прагматической заинтересованности в совершении атак на корпоративные ресурсы, с другой стороны, отсутствием эффективных средств ее защиты, в частности, обусловливаемой неспособностью реализации эффективной защиты с использованием встроенных в современные универсальные ОС возможностей. Естественно, что все это приводит к увеличению потребительского спроса на средства защиты от инсайдеров, как следствие, к желанию разработчиков средств защиты максимально быстро заполнить данный сегмент рынка. Подобная ситуация объективно не может не сказаться на качестве создаваемых в спешке средств, на качестве предоставляемых услуг, в конечном счете – на эффективности решения задачи защиты информации. Наверное, сначала, необходимо разобраться, в чем же состоит задача защиты от инсайдеров, каковы требования, выдвигаемые к средству защиты в части противодействия инсайдерским атакам. При этом априори очевидно, что задача защиты от инсайдеров на порядки сложнее, чем от сетевых атак (защита должна осуществляться от локального пользователя, имеющего права доступа к компьютерным ресурсам), поэтому без профессионально реализованного комплексного средства защиты при решении этой задачи не обойтись. Любое средство защиты характеризуется требованиями к достаточности набора механизмов защиты, применительно к условиям его использования, и к корректности реализации механизмов защиты. В чем же заключаются эти требования в рассматриваемых приложениях, можно ли без реализации данных требований создать эффективное средство защиты? А как сравнить альтернативные подходы к решению задачи (или различные средства защиты), когда требования не определены, по каким параметрам их сравнивать? Альтернативные подходы к построению системных средств и средств защиты Когда речь заходит об информационных технологиях, можно выделить два их основных приложения – это личное использование в домашних условиях, либо корпоративное использование – на предприятии. Если задуматься, то разница требований к средствам защиты, в данных приложениях огромна. В чем же она состоит. Например, когда речь идет о личном использовании компьютера в домашних условиях, мы сразу же начинаем задумываться о предоставляемых системным средством сервисах – это максимально возможное использование устройств, универсальность приложений, мечтаем о всевозможных играх, проигрывателях, графике и т.д. и т.п. Важнейшими же условиями использования средств защиты в данных приложениях является следующее:
Теперь посмотрим, какие же подходы к построению защиты оказались на практике наиболее востребованными в данных приложениях. Естественно, что подобными решениями стали не средства защиты, а средства контроля, в первую очередь – это всевозможные антивирусные средства, основанные на сигнатурном анализе. Очевидно, что средства защиты, требующие определенной квалификации для настройки (а просто эффективную защиту не обеспечить), в данных приложениях малопригодны. Контроль же предполагает простейших действий от пользователя – нажал кнопку, и готово. Все вопросы, требующие квалифицированного решения, здесь перекладываются на плечи разработчиков антивирусных средств, в частности, поддержание базы вирусов в максимально актуальном состоянии. Заметим, что, так как никакого администрирования не предполагается, весь диалог осуществляется с конечным пользователем, а не с администратором, что, кстати говоря, даже при использовании средств контроля, подчас, ставит пользователя в тупик. Даже подобная малая автоматизация принятия решений - право принятия решения предоставляется пользователю (на экран выводится соответствующий вопрос о необходимых действиях), в большинстве своем, для данных приложений является неприемлемой, т.к. требует повышения квалификации пользователя, а ему этого объективно не нужно. Насколько эффективны такие средства? Естественно, что с точки зрения обеспечения какого-либо приемлемого уровня защиты информации, подобные средства неэффективны. Это утверждение очевидно – в любой момент времени база выявленных сигнатур не полна (полной она не может быть даже теоретически). Однако не стоит критически относиться к подобным средствам. Без всякого сомнения, для рассматриваемых приложений они необходимы, и единственно приемлемы для практического использования. Здесь ведь встает вопрос: либо простые средства, либо никакие – какая уж тут эффективность защиты - сложные средства в этих приложениях никто использовать не станет. Так уж лучше как-нибудь, чем никак! Если же мы начинаем говорить о корпоративных приложениях, то в этих приложениях, как условия использования системных средств, так и требования к средству защиты не то, чтобы были кардинально иные, они прямо противоположны рассмотренным выше. В частности, здесь уже нет необходимости в большой номенклатуре устройств, приложений, игрушки и прочее являются отвлекающим от служебной деятельности фактором, возможность их запуска в принципе желательно предотвратить, и т.д. и т.п. Именно в данных приложениях средств защиты и решается рассматриваемая нами задача противодействия инсайдерам. Важнейшими условиями использования средств защиты в данных приложениях является следующее:
Видим, что в этих приложениях уже во главу угла ставится задача эффективной защиты информации, которая должна решаться профессионально, т.к. есть, что защищать. Не случайно, что защита информации в данных приложениях регламентируется соответствующими нормативными документами, средства защиты предполагают их сертификацию (анализ функциональных возможностей), а автоматизированная система (АС) обработки информации – аттестацию, а все в совокупности - квалифицированный анализ достаточности и корректности реализации механизмов защиты. Основу обеспечения информационной безопасности в данных приложениях уже составляют именно механизмы защиты, реализующие разграничительную политику доступа к ресурсам, а не простейшие механизмы контроля, что очень важно. Функции контроля в данных приложениях следует рассматривать лишь как некую опциональность, в дополнение к механизмам защиты, реализующим разграничительную политику доступа к ресурсам, которые сложны в разработке, требуют квалификации при настройке, но только с применением этих механизмов можно обеспечить эффективное решение задачи защиты информации! Рассмотрев внимательно то, насколько отличны, а подчас, противоречивы требования к средству защиты для альтернативных приложений (личное и корпоративное использование), не сложно сделать вывод, что средство защиты не может в принципе быть универсальным, как бы не позиционировали средство защиты его разработчики, оно может быть создано либо для личного, либо для корпоративного использования. Потребитель средства защиты должен это понимать – если он действительно хочет обеспечить эффективную защиту, то необходима соответствующая квалификация ответственных лиц и соответствующие затраты на приобретение и установку средств защиты – простейшими средствами без соответствующих затрат может быть обеспечена лишь иллюзия защиты. Все это в полной мере относится и к современным универсальным ОС, в частности, ОС Windows, из анализа механизмов защиты которых (основной используемый в них принцип защиты – принцип полного доверия к пользователю) следует, что основная их область применения – использование в личных целях. Отсюда, во многом, и их проблемы с безопасностью. В корпоративных приложениях именно санкционированный пользователь, допущенный к обработке конфиденциальной информации в рамках выполнения своих служебных обязанностей, вполне обоснованно, позиционируется в качестве наиболее вероятного злоумышленника (инсайдера). Это обусловливается тем, что реализовать успешную локальную атаку (по ряду объективных и существующих сегодня субъективных причин) на порядки проще, чем удаленную (из сети). Сейчас ведется много весьма странных разговоров о риске человеческого фактора, о необходимости обучения пользователей основам ИТ-безопасности, что якобы снизит инсайдерскую угрозу (это бессмысленная попытка решить задачи защиты не техническими, а надуманными организационными мерами, исходящая из того, что встроенными в современные универсальные ОС средствами технически данные задачи не решить). Наверное, подобные разговоры идут от непонимания проблем защиты и задач, которые должны решаться в данных приложениях средствами защиты. Владеет пользователь основами ИТ-безопасности, не владеет – это ничего не меняет. Ни при каких условиях он не должен иметь возможности хищения информации. Естественно, что кто-то за все это должен отвечать (кто-то же должен настраивать средство защиты), а это – администратор безопасности, вот для него-то и вступает в силу понятие риска человеческого фактора. Именно он должен пользоваться необходимым доверием со стороны руководства и обладать необходимой квалификацией в области ИТ-безопасности, т.к. именно он, являясь доверенным лицом, решает вопросы защиты информации. Задачи защиты конфиденциальной информации от несанкционированного доступа (НСД) Задача изменения области приложений системного средства Как отмечали ранее, одним из принципиальных отличий системных средств, созданных для личного и корпоративного использования, является их универсальность, в части использования устройств и приложений (ПО). Подобная универсальность не только избыточна для корпоративных приложений, но и несет в себе угрозу информационной безопасности. Задача управления подключением (монтированием) устройств Большинство подключаемых к системе устройств, в той или иной мере, предназначено для работы с информацией, т.е. практически любое дополнительно подключенное к системе устройство может рассматриваться в качестве потенциального канал, который может использоваться злоумышленником для хищения информации. Соответственно, к нему должен контролироваться доступ пользователей. Другими словами, любое устройство, которое может быть подключено (примонтировано) к системе, должно рассматриваться в качестве защищаемого ресурса - являться объектом контроля доступа при реализации разграничительной политики доступа к ресурсам. Как следствие, актуальной становится задача выполнения требований к достаточности – полноте набора механизмов защиты, применительно к условиям использования системного средства. Обратимся к соответствующему нормативному документу в области защиты информации, и попытаемся определить сформулированное в нем основополагающее требование к достаточности – полноте набора механизмов защиты, применительно к условиям использования системного средства. Будем рассматривать требования, применительно к защите конфиденциальной информации (требования к АС 1Г). Требованием к достаточности набора механизмов защиты в данном документе является следующее:
На наш взгляд (с позиций требований в достаточности), однозначная трактовка данного требования появляется при следующей его формулировке:
Рассмотрим примеры. Ресурсом является собственно системное средство (ОС), доступ к нему (вход в ОС) должен разграничиваться, что реализуется механизмами идентификации и аутентификации. Ресурсом являются файловые объекты, используемые для хранения данных, исполняемых файлов, объекты реестра ОС, всевозможные устройства, буфер обмена, сетевые ресурсы и т.д. и т.п., доступ к ним должен разграничиваться. Например, если невозможно разграничить доступ к остаточной информации (она уже не является файловым объектом) – ее не должно присутствовать (не должно быть ресурса – он должен быть исключен), что реализуется механизмом гарантированного удаления данных при модификации и удалении файловых объектов. Что очень важно. Если средство защиты не обеспечивает контроль доступа к какому-либо ресурсу – это уязвимость данного средства, т.к. появляется угроза того, что к ресурсу может быть реализован несанкционированный доступ. Теперь приведем основные принципы, которые должны быть реализованы в части обеспечения выполнения рассматриваемого требования (на наш взгляд, эти правила, в качестве основополагающих, могут использоваться и при аттестации объекта информатизации). Принцип 1. Если средство защиты не контролирует доступ к какому-либо компьютерному ресурсу, и невозможно гарантированно исключить техническими средствами из состава защищаемого объекта тот ресурс (ресурсы), к которому средством защиты не контролируется доступ (например, реестр ОС), этого средства защиты недостаточно, применительно к данным условиям использования, т.к. оно обладает уязвимостью. Принцип 2. Если средство защиты не контролирует доступ к какому-либо компьютерному ресурсу, и невозможно гарантированно исключить техническими средствами из состава защищаемого объекта тот ресурс (ресурсы), к которому средством защиты не контролируется доступ, должна использоваться совокупность (набор) средств защиты, совместно обеспечивающих выполнение требования к достаточности набора механизмов защиты. Уточним следующий тезис: гарантированно исключить его техническими средствами из состава защищаемого объекта - это очень важно. Речь идет о таком способе исключения ресурса (о каких-либо организационных мерах речь здесь идти просто не может), при котором, он не может быть использован в принципе. Например, если средство защиты не имеет в своем составе механизма контроля доступа к сетевым ресурсам, естественно, что оно не обладает достаточностью для защиты компьютеров в составе сети, однако это отнюдь не означает, что это средство достаточно, применительно к защите автономного компьютера. Это обусловливается тем, что собственно ресурс доступа в сеть в компьютере присутствует – вот и уязвимость! Условием достаточности здесь будет наличие механизма контроля монтирования (подключения) устройств. Этим механизмом должна быть предотвращена возможность подключения к системе устройства доступа в сеть – не будет ресурса, не будет и уязвимости. Теперь сформулируем требования к корректности реализации данного важнейшего механизма защиты. Требование 1. Требование к реализации индуктивности модели безопасности. Модель безопасности принято называть индуктивной, если для системы, однажды установленной в безопасное состояние, гарантируется ее нахождение в безопасном состоянии в последующие моменты времени. Основополагающим условием реализации индуктивной модели безопасности является реализация разрешительной разграничительной политики: Все, что не разрешено – явно не прописано, то запрещено, которая, применительно к рассматриваемому механизму защиты, состоит в следующем: Все устройства, которые явно не разрешено монтировать (подключать) к системе, монтировать запрещено. Другими словами, данное требование предполагает, что механизмом защиты должны задаваться (естественно, что настройка механизма должна допускаться только с правами администратора безопасности) разрешенные к монтированию устройства, с предотвращению возможности подключения любого устройства, не вошедшего в список разрешенных для монтирования. Отметим, что только при реализации разрешительной разграничительной политики может быть выполнено одно из ключевых требований к реализации механизмов защиты от НСД, которое для СВТ 5 класса (защита конфиденциальной информации) в соответствующем нормативном документе сформулировано следующим образом:
В порядке замечания отметим, что в ОС Windows, все наоборот. Администратору предоставляется возможность отключать (запрещать) те устройства, которые ранее были подключены к системе. Но это же универсальная, а не специализированная для корпоративного использования ОС. Требование 2. Требование к однозначности идентификации ресурса (устройства). В общем случае при контроле монтирования устройств интерес представляет возможность однозначной идентификации конкретного устройства (например, разрешается подключать не любое Flash-устройство, а конкретное физическое устройство). Заметим, что только при подобной реализации механизма можно обеспечить эффективную реализацию соответствующего требования к организационным мероприятиям, являющегося обязательным при внедрении СЗИ от НСД при защите конфиденциальной информации (требование к АС 1Г):
А как иначе маркировать внешний накопитель и при этом быть уверенным, что именно он используется для хранения конфиденциальных данных (не будем забывать, что на сегодняшний день именно угроза хищения данных санкционированным пользователем, доминирует, т.е. рассматривается в качестве наиболее вероятной)? Единственным идентификационным признаком устройства, позволяющим его однозначно идентифицировать (отличать от иных подобных устройств одного класса), является серийный номер устройства. Следовательно, при контроле монтирования (подключения) к системе устройств, устройства должны идентифицироваться по серийным номерам. Отметим, что возможность однозначной идентификации устройств существенно расширяет функциональные возможности (потребительскую стоимость) СЗИ от НСД, позволяя не только корректно реализовать обязательные организационные меры при защите конфиденциальной информации (а как еще осуществить учет защищаемых носителей информации, как однозначно определить, что именно тот мобильный накопитель, на котором сохранены конфиденциальные данные), но и противодействовать вводу парольной и ключевой информации с ключа-копии и т.д. Однако не будем далее останавливаться на рассмотрении этих вопросов, когда потребитель СЗИ от НСД столкнется с задачей разработки политики безопасности, он в полной мере ощутит преимущества данного подхода. Задача управления запуском программ Возможность неконтролируемого запуска на защищаемом компеьютере программ несет в себе основную угрозу ИТ-безопасности. Подобные программы (деструктивный код) могут быть весьма разнородны – это и эксплойты, и трояны, и вирусы, и шпионские программы и т.д. и т.п. Для инсайдера возможность неконтролируемого запуска программ предоставляет инструментарий для взлома системы защиты. Вместе с тем, корпоративные приложения отличаются тем, что для работы пользователя на практике, как правило, набор используемого ПО жестко регламентирован его функциональными обязанностями, т.е. подобное универсальное свойство системы в данных приложениях просто избыточно. Как мы ранее отмечали, для решения задач защиты в корпоративных приложениях средства контроля неуместны. Это касается и рассматриваемой задачи. Как видим, атаки с использованием деструктивного кода разнородны по своей сути, причем для некоторых их разновидностей (например, эксплойты) сама возможность создания базы деструктивного кода проблематичная (если принципиально возможна). Подтвердим сказанное результатами одного исследования:
Основной принцип защиты, который должен быть реализован при решении рассматриваемой задачи, состоит в следующем. Принцип 1. Общий подход к решению состоит в локализации на защищаемом компьютере возможности запуска программ механизмом контроля доступа к ресурсам (разграничения прав доступа к исполняемым файловым объектам), при условии выполнения требований к полноте и к корректности реализации разграничительной политики доступа. Требование 1 к полноте разграничительной политики доступа. Требование к полноте реализации разграничительной политики доступа в данном случае состоит в необходимости разграничить доступ “на выполнение” для всех компьютерных ресурсов, с которых возможен запуск программы. Требование 2 к корректности разграничительной политики доступа. Требование к корректности реализации разграничительной политики доступа в данном случае состоит в необходимости предотвращения любой возможности модификации разрешенных к запуску исполняемых файлов, а также в предотвращении любой возможности запуска под их именем (под видом санкционированных) других (несанкционированных для выполнения) исполняемых файлов. Очевидно, что при реализации на защищаемом компьютере подобного решения, любая сторонняя программа, в том числе, и любая вредоносная программа, не сможет быть запущена. Общность данного решения состоит в том, что не требуется какого-либо анализа (сравнения с эталоном) кода, который в общем случае не может быть осуществлен корректно, не требуется каких-либо выявления сигнатур, составления баз и т.д., т.к. все, что не разрешено, то запрещено, а разрешается запуск только тех программ, в которых мы уверены, при этом предотвращается любая возможность их модификации. Заметим, что при таком решении уже становится неважно, что несанкционированная программа каким-либо способом занесена на компьютер – ее все равно невозможно запустить! Другими слова, не требуется противодействовать занесению вредоносного кода на защищаемый компьютер, что существенно упрощает задачу защиты. Однако не следует забывать о разнородности вредоносного кода, что, в том числе, определяет и различные способы его запуска. Дело в том, что деструктивные программы могут запускаться, как под учетной записью пользователя, так и под системными учетными записями, например, System, что, в первую очередь, и характерно для эксплойтов. При этом необходимо учитывать, что ошибки программирования, которые, в том числе, могут быть использованы для осуществления атаки инсайдером, могут обнаруживаться как в системном, так и в прикладном ПО. При этом сразу возникает достаточно важный момент, образующий весьма не простую для технической реализации проблему, состоящий в том, что системное средство должно обеспечивать возможность запрещать для модификации системный диск, в том числе, и системным пользователям, в частности, пользователю System. Другая проблема состоит в том, что исполняемых файлов, которые необходимо разрешать на запуск в системе, на самом деле, достаточно много, т.к. к ним относятся исполняемые файлы всех системных процессов. Как следствие, решение, связанное с контролем запуска собственно исполняемых файлов, отпадает, как таковое (здесь речь идет не об оптимальности, а вообще о разумности такого подхода). На наш взгляд, единственно осмысленное решение рассматриваемой задачи защиты состоит в следующем. Средство защиты должно контролировать выполнение исполняемых файлов из папок (объектом разграничений должен выступать не исполняемый файл, а папка, например, каталог) – должна реализовываться разрешительная разграничительная политика – запуск исполняемых файлов должен разрешаться только из задаваемых папок. С учетом необходимости контроля запуска, в том числе, и системных процессов, к подобным папкам (из которых необходимо разрешать запуск исполняемых файлов, при запрете их модификации) следует отнести каталоги Windows и Program Files на системном диске (при необходимости, еще какие-либо папки). При этом становится невозможным запустить программу иначе, чем из указанных папок, которые невозможно модифицировать – задача защиты решена, деструктивный код становится невозможно запустить. Однако, специалист, представляющий себе архитектуру современных ОС семейства Windows, нам возразит – при подобных разграничениях система работать не будет, мы увидим синий экран, и он окажется прав. Дело в том, что некоторые системные процессы должны иметь право записи в соответствующие файловые объекты на системном диске. Их не так много. К таким процессам, например, могут быть отнесены: winlogon.exe, lsass.exe, csrss.exe, svchost.exe, services.exe и некоторые другие. Заметим, что данное свойство современных ОС семейства Windows определяет огромный их архитектурный недостаток – невозможность запретить модификацию системного диска системным пользователям (в частности, System), как следствие, и всем системным процессам, а также иным процессам, запускаемым под этой учетной записью. Результат – невозможность какого-либо противодействия атакам, связанным с уязвимостями, предоставляющими возможность получение злоумышленником системных прав – записывай на системный диск эксплойт и запускай! Для решения данного противоречия в средстве защиты должна присутствовать возможность разграничивать права доступа процессов к ресурсам. В этом случае можно для каждого из системных процессов, требующих запись на системный диск, определить и разрешить необходимые им для корректного функционирования системы эксклюзивные (разграничения для пользователя в этом случае учтены не будут) права доступа, причем данные “разрешения” не скажутся на эффективности защиты, т.к. подобные системные процессы не имеют пользовательского интерфейса. Таким образом, эффективное решение рассматриваемой задачи защиты существует. Итак, мы решили задачу изменения области приложений системного средства, разрешив подключать к системе только необходимые пользователю для работы устройства и запускать необходимые программы. Однако это решение нельзя признать полным. Обусловливается это тем, что функционал некоторых приложений, которые необходимы пользователю для выполнения своих служебных обязанностей, может быть им существенно расширен, за счет внедрения макро-вирусов. Макро-вирусы являются побочным эффектом идеи тотальной автоматизации приложений, к которым, в первую очередь, следует отнести офисные приложения Microsoft, за счет использования макросов. Если какая-либо задача часто выполняется, ее выполнение можно автоматизировать с помощью макроса. Макрос — это набор команд и инструкций, выполняемых как одна команда. Макросы, как правило, используются для решения следующих задач:
Высокая распространенность макро-вирусов имеет очень простое объяснение. Во-первых, это высокое распространение объектов их поражения, т.е. офисных приложений. Сегодня практически нет таких людей, которые бы не использовали в своей повседневной работе текстовый процессор, электронные таблицы, систему обработки базы данных или мастер презентаций. Во-вторых, простота создания макро-вирусов. Для того чтобы написать вирус, например, для MS Word, достаточно изучить азы языка программирования VBA. Несмотря на то, что он является самым простым и доступным среди всех остальных языков, вместе с тем, данный язык предоставляет злоумышленникам достаточно возможностей для того, чтобы похитить или уничтожить важную информацию, либо надолго вывести компьютер из строя. Стоит также сказать, что в последнее время макро-вирусы все чаще используются совместно с другими вирусными атаками. Так, например, Kukudro.A – это макро-вирус, внедряющий на зараженные компьютеры троян Downloader.JIH. В части противодействия инсайдерам, задача защиты в рассматриваемом случае состоит в защите системных ресурсов от воздействия макро-вирусов (именно их модификация может привести к последующему хищению конфиденциальной информации). Естественно, что никакие периодические контроли документов по сигнатурам здесь не помогут. Задача защиты в рассматриваемом случае принципиально иная. Инсайдер (санкционированный пользователь), запустив офисное приложение, может сам создать макрос и его запустить. Антивирусный периодический (а период должен быть большим, в противном случае вычислительное средство начнет работать исключительно на защиту) контроль здесь неуместен. Что же мы имеем – ряд приложений, которым мы априори не доверяем, доступ которых к системным ресурсам (к системным файловым объектам и к объектам реестра ОС) необходимо разграничивать – получаем задачу реализации разграничительной политики доступа к системным ресурсам для субъекта доступа процесс. Принцип 1. Общий подход к решению защиты системных ресурсов от атак со стороны макро-вирусов состоит в реализации разграничительной политики доступа процессов офисных приложений к файловым объектам и к объектам реестра ОС. Требование 1 к комплексной реализации разграничительной политики доступа к ресурсам. Для возможности реализации разграничительной политики доступа к ресурсам в общем случае, должны быть реализованы следующие схемы задания разграничительной политики доступа к ресурсам:
Таким образом, в качестве субъекта доступа может рассматриваться либо только пользователь, либо только процесс, либо пара – процесс и пользователь. Таким образом, необходимо разрешить офисному приложению только те действия, которые необходимы для его корректного функционирования. Любые иные действия, к которым может привести запуск макро-вируса, не должны разрешаться. Проведем исследование на примере наиболее часто используемых офисных приложений возможности и сложности (сложности администрирования механизма защиты) решения данной задачи. Исследования будем проводить в следующих предположениях: Операционная система - Microsoft Windows XP; Рассматриваемые офисные приложения – Microsoft Office Word 2003, Microsoft Office Excel 2003, Microsoft Office Outlook 2003; Операционная система установлена на диске C; Все приложения инсталлированы в каталог C:\Program files; Обработка информации осуществляется под учетной записью User 1; Для хранения обрабатываемых данных пользователем используется каталог С:\OOD1. К защищаемым системным ресурсам в данных предположениях, в первую очередь, следует отнести каталоги C:\Windows и C:\Program files и объект реестра HKEY_LOCAL_MACHINE. Часть 2 Читайте далее:  Security 50 – лучшие в мире 50 компаний в области безопасности по объему продаж 01 - 03 февраля 2008 года 1.4. действия сил охраны 25 - 29 февраля 2008 года 07 - 13 апреля 2008 года ,рынок it, 21 - 27 апреля 2008 года ,рынок it, Адаптер sb-1 для монтажа видеокамер на столбах 01- 04 мая 2008 года ,рынок it, 12 - 18 мая 2008 года ,рынок безопасности, 26 - 31 мая 2008 года ,рынок безопасности, Техническое задание на создание интегрированной системы безопасности объекта Шараж-монтаж Заземление в системах промышленной автоматизации ,часть 1, Мы увидим симбиоз айтишников и безопасников Как отремонтировать видеомонитор?
|
