×
Few antiviral products inadequately detect 3proxy as Trojan.Daemonize,
Backdoor.Daemonize, etc and many detect 3proxy as a PUA (potentially unwanted program).
It may cause browser warning on download page.
3proxy is not trojan or backdoor and contains
no functionality except described in documentation. Clear explanation of this
fact is given, for example, in
Microsoft's
article.
2. Политики безопасности На протяжении данного документа будет много упоминаний политик. Обычно эти упоминания будут связаны с рекомендациями для определенных политик. Чтобы не повторять рекомендации о том, как создавать и передавать такую политику, читатель должен применять советы этого раздела при разработке любой политики, рекомендуемой в дальнейшем в этой книге. 2.1 Что такое политика безопасности и зачем она нужна? Любое решение связанное с безопасностью, которое вы принимаете или не принимаете как администратор, во многом определяет насколько защищена или беззащитна будет ваше сеть, как много функций она будет поддерживать и насколько просто ее будет использовать. Однако, вы не сможете принять правильных решений о безопасности не определив цели вашей безопасности. Пока вы не определитесь с целями, вы не сможете эффективно использовать любые наборы средств обеспечения безопасности, просто потому что вы не будете знать что проверять и какой уровень ограничений необходим. Например, ваши цели вероятно будут значительно отличаться от целей производителя используемого продукта. Производители стараются сделать настройку и управление продуктом как можно проще, что означает, что конфигурации по умолчанию будут настолько открыты (т.е. беззащитны), насколько это возможно. Хотя это облегчает установку новых продуктов, это так же открывает доступ к подобным системам и через них - к остальным системам, открывает доступ каждому, кто хочет пройти. Ваши цели будут во многом определены следующими ключевыми противоречиями: (1) предлагаемые услуги против обеспечиваемой безопасности - Каждая услуга, предлагаемая пользователям вносит собственные угрозы безопасности. Для некоторых услуг угроза перевешивает преимущества услуги и администратор может принять решение исключить услугу, вместо того, чтобы пытаться сделать ее безопасной. (2) простота использования против безопасности - Самая простая в использовании система это та, которая позволяет доступ пользователю и не требует пароля; т.е. в которой не может быть безопасности. Необходимость пароля делает систему чуть менее удобной, но более защищенной. Необходимость одноразового сгенерированного пароля делает систему еще менее удобной, но еще более повышает безопасность. (4) стоимость безопасность против угрозы потерь - Существует много стоимостей связанных с безопасностью: денежная (например связанная с покупкой оборудования безопасности или программного обеспечения, такого как брандмауэры или генераторы одноразовых паролей), производительность (например процедуры шифрования/дешифрования требующие времени) и простоты использования (как замечено выше). Существует так же много уровней риска: потеря секретности (например чтение информации неавторизованным персоналом), потеря данных (например повреждение или стирание информации) и потеря доступа (например исчерпание дискового пространства, вычислительных ресурсов или отказ в сетевом доступе). Все виды стоимости должны быть взвешены против всех видов потерь. Вашей целью должно быть связь со всеми пользователями, операторами и управляющим персоналом через набор правил безопасности, называемым "политикой безопасности". Мы используем этот термин вместо более узкой "политики компьютерной безопасности", поскольку эта область включает в себя все типы информационных технологий и информации хранимой и обрабатываемой в технологии. 2.1.1 Определение политики безопасности Политика безопасности это формальное заявление правил, которые должны соблюдать люди, имеющие доступ к организационным технологиям и информационным ресурсам 2.1.2 Задачи политики безопасности Основная цель политики безопасности - информирование пользователей, сотрудников и руководства о наложенных на них обязательных требованиях по защите технологии и информационных ресурсов. Политика должна определять механизмы, посредством которых эти требования могут быть выполнены. Другая задача - обеспечить базовый уровень, на котором приобретать, настраивать и наблюдать компьютерные системы и сети для соответствия политике. Таким образом попытка использования набора средств безопасности в отсутствии хотя бы подразумеваемой политики безопасности является бессмысленной. Политика правильного использования (Appropriate Use Policy, AUP) так же может быть частью политики безопасности. В ней должно быть заявлено, что пользователи должны и чего не должны делать с различными компонентами своей системы, включая типы трафика разрешенные в сети. AUP должна быть настолько подробной, насколько это возможно, чтобы исключить неопределенность или недопонимание. Например, AUP может перечислить недопустимый группы конференций. (В некоторых организациях AUP так же может быть Acceptable Use Policy - политика допустимого использования). 2.1.3 Кто должен привлекаться к формирования политики? Чтобы политика безопасности была подходящей и эффективной ей требуется принятие и поддержка на всех уровнях сотрудников организации. Особенно важно, чтобы руководство полностью поддерживало процесс политики безопасности, иначе шанс того, что от нее будет толк чрезвычайно мал. Вот список лиц, которые должны быть вовлечены в создание и рассмотрение документов политики безопасности: (1) администратор безопасности предприятия (2) технический IT-персонал (т.е. персонал вычислительного центра) (3) администраторы больших групп пользователей внутри организации (т.е. подразделений, информационных отделов университетов и т.д.) (4) команда реагирования на происшествия связанные с безопасностью (5) представители групп пользователей затронутых политикой безопасности (6) ответственный руководитель (7) юрисконсультант (если требуется) Этот список достаточно представителен для большинства предприятий, но не обязательно полон. Основная идея - чтобы представлены были все - учредители, руководители отвечающие за бюджет и подписывающих политику, технический персонал, знающий что может и что не может быть реализовано и юрист, который знает побочные явления различных вариантов политики. В некоторых организациях может потребоваться подключение внешних аудиторов. Подключение этой группы может быть важным если требуется достичь общего приятия политики. Нужно отметить, что роль юриста будет сильно зависеть от страны. 2.2 Что составляет хорошую политику безопасности? Характеристики хорошей политики безопасности следующие: (1) Она должна быть реализуема через процедуры системного администрирования, публикацию руководств по использованию или другими допустимыми методами. (2) Она должна быть обязательной, это должно быть реализовано с помощью средств безопасности, где это возможно и путем взысканий, где предотвращение технически невозможно. (3) Она должна четко определять области ответственности пользователей, администраторов и руководителей. Компоненты хорошей политики безопасности включают: (1) Руководство закупки вычислительных технологий, которое определяет требуемые или желательные возможности безопасности. Оно должно дополнять существующие политики и руководства закупок. (2) Политику конфиденциальности, которая определяет возможные ожидания конфиденциальности относительно таких вопросов как наблюдение за электронной почтой, запись клавиатурных команд и доступ к пользовательским файлам. (3) Политику доступа, определяющую права доступа и привилегии, чтобы защитить ресурсы от потери или обнаружения путем определения рекомендаций приемлемого использования для пользователей, операторов и руководства. Надо обеспечить рекомендации для внешних соединений, передачи данных, подключения устройств к сети и установке нового программного обеспечения. Необходимо так же определить все требуемые уведомления (например начальное сообщение при подключении должно содержать предупреждение о несанкционированном использовании и наблюдении за каналом, а не просто говорить "Wellcome". (4) Политика учета, которая определяет ответственности пользователей, операторов и руководства. Она должна определять возможности аудита и предоставлять руководства по обработке происшествий (например что делать и с кем связываться если обнаружено возможное вторжение). (5) Политика аутентификации, которая устанавливает доверие путем эффективной политики паролей и установки рекомендаций по аутентификации удаленных субъектов и использованию аутентифицирующих устройств (например генераторов одноразовых паролей). (6) Утверждение доступности, в соответсвии с ожиданиями пользователей доступности ресурсов. Оно должно разрешать вопросы избыточности и восстановления, а так же определять рабочие часы и периоды планового отключения. Оно так же должно включать контактную информацию для сообщения о сбоях системы и сети. (7) Политика IT систем и поддержания сети, которая определяет людей внутри организации и внешних сотрудников имеющих доступ для поддержания функционирования. Один из важных вопросов здесь, это разрешена ли внешняя поддержка и каким образом контролируется подобный доступ. Другая область рассмотрения - доступ внештатных сотрудников (outsorcing) и как он управляются. (8) Политика доклада о нарушениях, которая указывает какие типы нарушений (т.е. секретности или безопасности, внутренние или внешние) должны быть рапортованы и куда. Не угрожающая атмосфера и возможность анонимного доклада даст большую вероятность того, что нарушения будут рапортованы в случае обнаружения. (9) Справочная информация, которая обеспечивает пользователям, сотрудникам и руководству контактную информацию по каждому виду нарушения политики; рекомендации как обрабатывать исходящие запросы о происшествиях связанных с безопасностью или информацией которая может рассматриваться как личная или конфиденциальная; справочник по процедурам связанным с безопасностью и дополнительная информация, такая как политики компании и государственные законы и акты. Могут быть регулируемые законом требования, которые затрагивают некоторые аспекты вашей политики безопасности (например прослушивание линий). Создатели политики безопасности должны рассмотреть привлечение юрисконсультанта к созданию политики. Как минимум политика должна быть просмотрена юристом. После того, как ваша политика установлена она должна быть четко доведена до пользователей, сотрудников и руководства. Важной частью процесса является подписание сотрудниками соглашения, что они прочитали, поняли и согласны выполнять политику. Наконец, ваша политика должна регулярно пересматриваться на предмет полного соответствия вашим требованиям безопасности. 2.3 Поддержание гибкости политики Для того, чтобы политика безопасности оставалась пригодной на протяжении длительного времени в ней должно быть достаточно гибкости, основанной на архитектурной концепции безопасности. Политики безопасности должны быть (преимущественно) независимы от конкретной аппаратуры или программ (например что определенные системы должны заменяться или перемещаться в ночное время). Механизмы обновления политики должны быть четко указаны. В том числе процесс обновления, люди, вовлеченные в этот процесс и люди, которые должны подписаться под изменениями. Важно так же отметить, что из любого правила бывают исключения. Везде, где это возможно, политика должна указывать какие существуют исключения из общей политики. Например условия, при которых администраторы имеют право обратиться к пользовательским файлам. Или когда несколько пользователей могут использовать одну учетную запись - например "root", несколько системных администраторов могут знать пароль учетной записи супер-пользователя. Другой аспект называется "Синдромом Плюшкина" ("Синдром мусорной кучи"). Он возникает в тот момент, когда какая-либо ключевая фигура предприятия становится недостижимой (например заболевает или внезапно покидает компанию). Несмотря на то, что наибольшая безопасность заключается в нераспространении информации, риск потери критических данных возрастает, если эта информация не разделяется. Важно найти подходящую точку равновесия для вашего предприятия.
