Страница:
Стандарты реализуются с помощью практик и/или процедур. Практики являются реализацией стандартов в операционных системах, приложениях и информационных системах. В них детализируются сервисы, устанавливаемые на операционных системах, порядок создания учетных записей и т. д. Процедуры документируют процессы запроса и подтверждения доступа к определенным сервисам, например VPN.
Рассмотрим особенности предлагаемого подхода IBM (рис. 2.3) на следующем примере:
• проблемная ситуация – сотрудники загружают программное обеспечение из сети Интернет, что приводит к заражению вирусами, а в конечном счете к уменьшению производительности работы сотрудников компании;
• в политику безопасности добавляется строка – «информационные ресурсы компании могут быть использованы только для выполнения служебных обязанностей». Политика безопасности доступна для ознакомления всем сотрудникам компании;
• создается стандарт безопасности, в котором описывается, какие сервисы и программное обеспечение разрешены для использования сотрудниками;
• практика безопасности описывает, как настроить операционную систему в соответствии с требованиями стандарта безопасности;
• процедура безопасности описывает процесс запроса и получения разрешения на использование дополнительных сервисов или установку дополнительного программного обеспечения сотрудниками;
• устанавливаются дополнительные сервисы для контроля выполнения требований политики безопасности.
Рис. 2.3. Подход IBM к разработке документов безопасности
2.1.2. Пример стандарта безопасности для ОС семейства UNIX
Цель и область действия стандарта: документ определяет требования по защите компьютеров, работающих под управлением ОС семейства UNIX.
Аудитория: персонал служб информационных технологий и информационной безопасности.
Полномочия: отдел информационной безопасности наделяется всеми полномочиями для разрешения возможных проблем, связанных с безопасностью серверов информационной системы компании, и несет за это ответственность. Департамент управления информационными рисками утверждает все отклонения от требований данного стандарта.
Срок действия: с 1 января до 31 декабря … года.
Исключения: все отклонения от выполнения данного стандарта должны получить подтверждение в отделе информационной безопасности.
Поддержка: по всем вопросам, связанным с этим стандартом, обращаться в отдел информационной безопасности.
Пересмотр стандарта: стандарт пересматривается ежегодно.
СТАНДАРТ БЕЗОПАСНОСТИ ОС СЕМЕЙСТВА UNIX
УЧЕТНЫЕ ЗАПИСИ ПОЛЬЗОВАТЕЛЕЙ И ГРУПП
Настройки по умолчанию. Операционная система и права доступа к файлам должны быть настроены в режиме защищенной конфигурации при использовании umask по умолчанию, что гарантирует надлежащие разрешения доступа. Все пароли, установленные вендорами по умолчанию, должны быть изменены перед промышленной эксплуатацией системы.
Администрирование учетных записей пользователей и групп:
• учетные записи с привилегиями, равными привилегиям учетной записи root, запрещены;
• все идентификаторы групп и пользователей должны быть изменены таким образом, чтобы не было одинаковых учетных записей и владение учетной записью могло быть отслежено;
• выдача привилегированных учетных записей должна производиться с разрешения владельца системы;
• каждый пользователь системы должен иметь учетную запись с уникальным именем, идентификатором пользователя и паролем;
• все системные администраторы должны иметь свою собственную учетную запись;
• непосредственный доступ к учетной записи root для выполнения повседневных администраторских задач запрещен;
• только учетным записям администраторов предоставляется право повышения уровня привилегий;
• процесс регистрации в системе должен отображать данные о предыдущем входе в систему;
• неактивные учетные записи пользователей должны быть удалены;
• все пользовательские shell должны быть в списке легальных shell операционной системы;
• добавление нового shell осуществляется системными администраторами с разрешения владельца системы.
Профили пользователей. Все глобальные профили должны иметь значение umask, равное 0 2 3, то есть полный доступ – для владельца, доступ на чтение и выполнение – для членов группы владельцев и доступ на чтение – для всех остальных пользователей. Администраторы должны проверять индивидуальные профили для обеспечения целостности системы. Запрещено использовать текущую директорию в переменной shell PATH.
Политика использования паролей. Пароли должны удовлетворять требованиям, описанным в Инструкции по использованию паролей.
Домашние директории. Домашние директории обязательны для любой учетной записи, если только это не требуется для какого-нибудь приложения.
Совместно используемые директории. Директории могут использоваться совместно несколькими учетными записями, принадлежащими к одной группе или объединенными общей функциональной потребностью. Членам такой группы разрешается доступ на запись в директорию. Группа (ее идентификатор) является собственником всех файлов и вложенных директорий.
Совместно используемые учетные записи. Использование одной пользовательской учетной записи для совместной работы несколькими пользователями запрещено. Разрешается совместно использовать только специальные администраторские учетные записи или учетные записи для операций восстановления, при этом данные учетные записи не должны иметь права повышать свои привилегии.
Привилегированные учетные записи. Эти учетные записи имеют право повышать свои привилегии до уровня root. Совместное их использование строго запрещается. Обязательно журналирование таких учетных записей, и выданы они могут быть только системным администраторам и администраторам приложений.
Приветственное приглашение. При регистрации пользователя в системе должно появляться приветственное приглашение. Это сообщение должно иметь следующее содержание:
• эта система предназначена для использования только авторизованными пользователями;
• пользователи, использующие систему без авторизации или превысившие свои полномочия, являются нарушителями режима информационной безопасности, их действия в системе будут записаны и проанализированы системными администраторами;
• регистрация действий пользователей в системе может осуществляться при ненадлежащем использовании ими системы или при проведении регламентных работ;
• любое использование системы пользователями подтверждает правомерность мониторинга действий пользователей в системе, и, в случае нарушения режима информационной безопасности, системные администраторы вправе предоставлять записи действий пользователей в правоохранительные органы для проведения расследований.
СЕТЕВОЙ ДОСТУП УДАЛЕННЫЙ ДОСТУП
Команды удаленного управления. Удаленный доступ к системе с использованием r-команд семейства BSD для удаленного управления (rlogin, rexec) должен быть отключен, если только не существует другого способа управлять приложениями и системой. Если такой доступ необходим для выгрузки/загрузки файлов, то должна быть создана специальная учетная запись таким образом, чтобы нельзя было с ее помощью получить shell. Использование r-команд для удаленного управления запрещено.
Устройства удаленного доступа. Установка и использование любых устройств удаленного доступа, за исключением специально предназначенных для этих целей систем, запрещены. Для указанных систем все действия регистрируются.
Удаленный доступ под учетной записью root. Непосредственный доступ в систему под учетной записью root запрещен. Администраторы должны регистрироваться в системе под своей персональной учетной записью и использовать команду su для повышения привилегий.
Удаленный доступ для привилегированных пользователей и администраторов. Все сетевые протоколы, передающие пароли в незашифрованном виде, запрещены для подключения. Такие протоколы могут быть подключены только в случае использования криптозащищенного туннеля.
Цепочка доверия. Цепочки доверия между компьютерами не должны включать системы, которые не удовлетворяют требованиям этого стандарта.
Сервис TFTP. Сервис TFTP не должен разрешать выгрузку файлов.
Сервис FTP. Запрещено использование скриптов для автоматической регистрации в FTP. Для анонимного доступа по FTP должна быть использована непривилегированная учетная запись. Разрешения на доступ к дереву каталога, используемого сервисом FTP, должны гарантировать целостность системы и запрещать неконтролируемую загрузку файлов. Если сервис доступен из Интернета, то для выгрузки файлов необходимо использовать отдельную файловую систему.
Сервис HTTP. Перед установкой Web-cepeepa обязательным является получение разрешения у владельца системы. Web-приложения не должны нуждаться в административных привилегиях ни для администрирования, ни для функционирования.
Приветственное приглашение. При попытке пользователей войти в систему должно появляться приветственное приглашение. Приглашение должно отображать сообщение в формате, описанном выше. Там, где возможно, приглашение должно скрывать название операционной системы и ее версию.
ПРИЛОЖЕНИЯ
Учетные записи. Необходимо создавать учетные записи владельцев информационных ресурсов. Администраторы приложений должны иметь возможность повышения привилегий. При этом для таких учетных записей повышение привилегий до уровня root недопустимо, если только без этого приложение не будет работать.
Владение процессом сетевого сервиса. Процессы, которые обеспечивают удаленный доступ к некоторым приложениям, не должны выполняться под привилегированными учетными записями и иметь возможность повышать привилегии учетной записи. Приложения, которые используют привилегированные порты, должны убрать такие привилегии до инициализации сетевого уровня.
Совместно используемые директории и файлы. Если файловая подсистема использует семантику BSD, то файлы и директории, совместно используемые несколькими приложениями и/или группами пользователей, должны принадлежать к определенной дополнительной группе, к которой принадлежат все авторизованные UID. Следует использовать настройки, предупреждающие неавторизованное удаление и кражу файлов. Должны быть использованы списки контроля доступа, если система предлагает расширенные механизмы безопасности из POSIX.
ЦЕЛОСТНОСТЬ СИСТЕМЫ
Сетевые сервисы. Все неиспользуемые сервисы должны быть отключены даже для локальных пользователей. Для «демонов» сетевых сервисов, которые не имеют возможности использовать списки контроля доступа, необходимо использовать TCP-упаковщики (wrappers) или подобные инструменты. Сервисы сетевого тестирования и отладки, включая echo, chargen, spray, должны быть отключены.
Разрешения на доступ к файлам:
• минимальные разрешения на директории пользователей должны быть: read, write, execute – для владельца; read, execute – для группы, в которую входит пользователь; «нет доступа» – для всех остальных пользователей;
• разрешения по умолчанию не должны допускать доступа извне;
• разрешения на специальные файлы (fifos, AF_UNIX sockets, devices, memory) должны строго контролироваться;
• возможность изменять конфигурацию системы должны иметь только администраторы;
• любые файлы, которыми владеет неизвестный пользователь, должны быть удалены после проведения расследования.
Свойства монтирования файловой системы. Везде, где это возможно:
• файловые системы, выделенные для хранения данных и иерархии пользователей, должны быть смонтированы с опциями, эквивалентными nosuid и nodev;
• файловые системы, выделенные для временных областей тестирования, типа /tmp, где создание и запись файлов предоставлены всем, должны быть смонтированы с опциями, эквивалентными nosuid, nodev и nоехес.
Файлы управления заданиями. Доступ к механизмам управления заданиями, таким, как at или cron, должен быть разрешен только системным администраторам или администраторам приложений.
Повышение пользовательских привилегий:
• запрещено использование SUID/SGID-скриптовых shell;
• запрещено использование cheap fork/exec SUID-бинарников в качестве упаковщиков;
• повышение привилегий для упаковщиков должно использовать механизм SGID там, где это возможно;
• запрещены любые команды SUID/SGID, которые могут заканчиваться в shell escape;
• администраторы систем и приложений, обладающие возможностью повышения привилегий до уровня root, должны повышать их только с использованием упаковщиков shell, таких, как sudo, calife, super. Эти упаковщики необходимо устанавливать так, чтобы только администраторы могли выполнять набор разрешенных им команд. Должен быть организован тщательный анализ аргументов командной строки.
Журналирование. Журналы системной активности должны храниться минимум один месяц на локальных или внешних носителях информации. Для критичных журналов необходимо обеспечить маркировку и хранение за пределами предприятия.
Синхронизация времени. Синхронизация времени должна происходить из доверенного источника.
КРИТИЧНЫЕ СИСТЕМЫ И СИСТЕМЫ, ДОСТУПНЫЕ ИЗ ИНТЕРНЕТА
УЧЕТНЫЕ ЗАПИСИ ГРУПП И ПОЛЬЗОВАТЕЛЕЙ
Глобальные профили пользователей. Все глобальные профили пользователей должны использовать минимальную umask 0 2 7, то есть полный доступ – для владельца, read и execute – для владельца группы, «нет доступа» – для всех остальных пользователей.
Учетные записи конечных пользователей. Учетные записи конечных пользователей запрещены. Должны быть доступны только учетные записи системных администраторов.
Обновление паролей. Все пароли должны обновляться в соответствии с политикой использования паролей.
Профили пользователей. После выхода из системы файлы, содержащие перечень введенных команд, должны быть очищены. Их содержание может быть перед этим скопировано в защищенную от доступа область для дальнейшего анализа.
УДАЛЕННЫЙ ДОСТУП
Использование r-команд BSD. Использование этих команд строго запрещено.
Удаленный доступ для привилегированных пользователей и администраторов. Для организации такого доступа необходимо использовать механизмы шифрования. Все другие протоколы, передающие пароли открытым текстом, запрещены.
ПРИЛОЖЕНИЯ
Сетевые приложения. Сетевые приложения должны быть интегрированы и сконфигурированы таким образом, чтобы взлом приложения не привел к взлому самого сервера.
Совместно используемые директории и файлы. Приложения должны иметь возможность осуществлять операции чтения и выполнения только над ограниченным списком файлов и директорий. Доступ на запись должен быть запрещен везде, где это возможно.
Уязвимости программного обеспечения. Системные администраторы и администраторы приложений отвечают за установку последних обновлений от производителей используемого программного обеспечения.
Инструменты разработки. Установка любых средств разработки и отладки, включая компиляторы и отладчики, запрещена.
ЦЕЛОСТНОСТЬ СИСТЕМЫ
Уменьшение поверхности атак. Все неиспользуемые сервисы должны быть отключены.
Файлы управления заданиями. Все внешние команды в заданиях должны использовать абсолютные пути, а не относительные.
Безопасность критичных системных файлов и файлов данных:
• все критичные системные файлы и критичные файлы приложений должны регулярно проверяться по базе сигнатур (владелец, разрешения, дата последнего изменения, MD5-cyммa);
• появление файлов дампов ядра должно быть немедленно обнаружено, и по этому поводу необходимо провести расследование;
• поиск, журналирование новых файлов и директорий, не представленных в базе данных, и создание отчетов о них должны быть автоматизированы и анализироваться администраторами;
• появление выполняемых или специальных файлов во временных директориях должно быть немедленно обнаружено, по этому поводу необходимо провести расследование.
Журналирование. Журналы активности приложений и системы должны храниться как минимум один месяц на локальных носителях информации и как минимум шесть месяцев на внешних.
Журналы для систем типа серверов аутентификации удаленных пользователей должны храниться на внешних носителях информации в течение одного года.
Синхронизация времени. Системы должны использовать как минимум два надежных источника времени.
Свойства монтирования файловой системы. Файловые системы, используемые для /bin, /sbin, /usr, и любые другие каталоги, которые считаются статическими, должны быть смонтированы в режиме «только для чтения».
Сервисы каталогов. Использование непроверенных сервисов типа внешних DNS-серверов запрещено, если это может оказать негативное влияние на системы или сервисы.
Уязвимости программного обеспечения. Системные администраторы отвечают за установку последних обновлений от производителей используемого программного обеспечения для поддержания требуемого уровня безопасности системы.
Аудитория: персонал служб информационных технологий и информационной безопасности.
Полномочия: отдел информационной безопасности наделяется всеми полномочиями для разрешения возможных проблем, связанных с безопасностью серверов информационной системы компании, и несет за это ответственность. Департамент управления информационными рисками утверждает все отклонения от требований данного стандарта.
Срок действия: с 1 января до 31 декабря … года.
Исключения: все отклонения от выполнения данного стандарта должны получить подтверждение в отделе информационной безопасности.
Поддержка: по всем вопросам, связанным с этим стандартом, обращаться в отдел информационной безопасности.
Пересмотр стандарта: стандарт пересматривается ежегодно.
СТАНДАРТ БЕЗОПАСНОСТИ ОС СЕМЕЙСТВА UNIX
УЧЕТНЫЕ ЗАПИСИ ПОЛЬЗОВАТЕЛЕЙ И ГРУПП
Настройки по умолчанию. Операционная система и права доступа к файлам должны быть настроены в режиме защищенной конфигурации при использовании umask по умолчанию, что гарантирует надлежащие разрешения доступа. Все пароли, установленные вендорами по умолчанию, должны быть изменены перед промышленной эксплуатацией системы.
Администрирование учетных записей пользователей и групп:
• учетные записи с привилегиями, равными привилегиям учетной записи root, запрещены;
• все идентификаторы групп и пользователей должны быть изменены таким образом, чтобы не было одинаковых учетных записей и владение учетной записью могло быть отслежено;
• выдача привилегированных учетных записей должна производиться с разрешения владельца системы;
• каждый пользователь системы должен иметь учетную запись с уникальным именем, идентификатором пользователя и паролем;
• все системные администраторы должны иметь свою собственную учетную запись;
• непосредственный доступ к учетной записи root для выполнения повседневных администраторских задач запрещен;
• только учетным записям администраторов предоставляется право повышения уровня привилегий;
• процесс регистрации в системе должен отображать данные о предыдущем входе в систему;
• неактивные учетные записи пользователей должны быть удалены;
• все пользовательские shell должны быть в списке легальных shell операционной системы;
• добавление нового shell осуществляется системными администраторами с разрешения владельца системы.
Профили пользователей. Все глобальные профили должны иметь значение umask, равное 0 2 3, то есть полный доступ – для владельца, доступ на чтение и выполнение – для членов группы владельцев и доступ на чтение – для всех остальных пользователей. Администраторы должны проверять индивидуальные профили для обеспечения целостности системы. Запрещено использовать текущую директорию в переменной shell PATH.
Политика использования паролей. Пароли должны удовлетворять требованиям, описанным в Инструкции по использованию паролей.
Домашние директории. Домашние директории обязательны для любой учетной записи, если только это не требуется для какого-нибудь приложения.
Совместно используемые директории. Директории могут использоваться совместно несколькими учетными записями, принадлежащими к одной группе или объединенными общей функциональной потребностью. Членам такой группы разрешается доступ на запись в директорию. Группа (ее идентификатор) является собственником всех файлов и вложенных директорий.
Совместно используемые учетные записи. Использование одной пользовательской учетной записи для совместной работы несколькими пользователями запрещено. Разрешается совместно использовать только специальные администраторские учетные записи или учетные записи для операций восстановления, при этом данные учетные записи не должны иметь права повышать свои привилегии.
Привилегированные учетные записи. Эти учетные записи имеют право повышать свои привилегии до уровня root. Совместное их использование строго запрещается. Обязательно журналирование таких учетных записей, и выданы они могут быть только системным администраторам и администраторам приложений.
Приветственное приглашение. При регистрации пользователя в системе должно появляться приветственное приглашение. Это сообщение должно иметь следующее содержание:
• эта система предназначена для использования только авторизованными пользователями;
• пользователи, использующие систему без авторизации или превысившие свои полномочия, являются нарушителями режима информационной безопасности, их действия в системе будут записаны и проанализированы системными администраторами;
• регистрация действий пользователей в системе может осуществляться при ненадлежащем использовании ими системы или при проведении регламентных работ;
• любое использование системы пользователями подтверждает правомерность мониторинга действий пользователей в системе, и, в случае нарушения режима информационной безопасности, системные администраторы вправе предоставлять записи действий пользователей в правоохранительные органы для проведения расследований.
СЕТЕВОЙ ДОСТУП УДАЛЕННЫЙ ДОСТУП
Команды удаленного управления. Удаленный доступ к системе с использованием r-команд семейства BSD для удаленного управления (rlogin, rexec) должен быть отключен, если только не существует другого способа управлять приложениями и системой. Если такой доступ необходим для выгрузки/загрузки файлов, то должна быть создана специальная учетная запись таким образом, чтобы нельзя было с ее помощью получить shell. Использование r-команд для удаленного управления запрещено.
Устройства удаленного доступа. Установка и использование любых устройств удаленного доступа, за исключением специально предназначенных для этих целей систем, запрещены. Для указанных систем все действия регистрируются.
Удаленный доступ под учетной записью root. Непосредственный доступ в систему под учетной записью root запрещен. Администраторы должны регистрироваться в системе под своей персональной учетной записью и использовать команду su для повышения привилегий.
Удаленный доступ для привилегированных пользователей и администраторов. Все сетевые протоколы, передающие пароли в незашифрованном виде, запрещены для подключения. Такие протоколы могут быть подключены только в случае использования криптозащищенного туннеля.
Цепочка доверия. Цепочки доверия между компьютерами не должны включать системы, которые не удовлетворяют требованиям этого стандарта.
Сервис TFTP. Сервис TFTP не должен разрешать выгрузку файлов.
Сервис FTP. Запрещено использование скриптов для автоматической регистрации в FTP. Для анонимного доступа по FTP должна быть использована непривилегированная учетная запись. Разрешения на доступ к дереву каталога, используемого сервисом FTP, должны гарантировать целостность системы и запрещать неконтролируемую загрузку файлов. Если сервис доступен из Интернета, то для выгрузки файлов необходимо использовать отдельную файловую систему.
Сервис HTTP. Перед установкой Web-cepeepa обязательным является получение разрешения у владельца системы. Web-приложения не должны нуждаться в административных привилегиях ни для администрирования, ни для функционирования.
Приветственное приглашение. При попытке пользователей войти в систему должно появляться приветственное приглашение. Приглашение должно отображать сообщение в формате, описанном выше. Там, где возможно, приглашение должно скрывать название операционной системы и ее версию.
ПРИЛОЖЕНИЯ
Учетные записи. Необходимо создавать учетные записи владельцев информационных ресурсов. Администраторы приложений должны иметь возможность повышения привилегий. При этом для таких учетных записей повышение привилегий до уровня root недопустимо, если только без этого приложение не будет работать.
Владение процессом сетевого сервиса. Процессы, которые обеспечивают удаленный доступ к некоторым приложениям, не должны выполняться под привилегированными учетными записями и иметь возможность повышать привилегии учетной записи. Приложения, которые используют привилегированные порты, должны убрать такие привилегии до инициализации сетевого уровня.
Совместно используемые директории и файлы. Если файловая подсистема использует семантику BSD, то файлы и директории, совместно используемые несколькими приложениями и/или группами пользователей, должны принадлежать к определенной дополнительной группе, к которой принадлежат все авторизованные UID. Следует использовать настройки, предупреждающие неавторизованное удаление и кражу файлов. Должны быть использованы списки контроля доступа, если система предлагает расширенные механизмы безопасности из POSIX.
ЦЕЛОСТНОСТЬ СИСТЕМЫ
Сетевые сервисы. Все неиспользуемые сервисы должны быть отключены даже для локальных пользователей. Для «демонов» сетевых сервисов, которые не имеют возможности использовать списки контроля доступа, необходимо использовать TCP-упаковщики (wrappers) или подобные инструменты. Сервисы сетевого тестирования и отладки, включая echo, chargen, spray, должны быть отключены.
Разрешения на доступ к файлам:
• минимальные разрешения на директории пользователей должны быть: read, write, execute – для владельца; read, execute – для группы, в которую входит пользователь; «нет доступа» – для всех остальных пользователей;
• разрешения по умолчанию не должны допускать доступа извне;
• разрешения на специальные файлы (fifos, AF_UNIX sockets, devices, memory) должны строго контролироваться;
• возможность изменять конфигурацию системы должны иметь только администраторы;
• любые файлы, которыми владеет неизвестный пользователь, должны быть удалены после проведения расследования.
Свойства монтирования файловой системы. Везде, где это возможно:
• файловые системы, выделенные для хранения данных и иерархии пользователей, должны быть смонтированы с опциями, эквивалентными nosuid и nodev;
• файловые системы, выделенные для временных областей тестирования, типа /tmp, где создание и запись файлов предоставлены всем, должны быть смонтированы с опциями, эквивалентными nosuid, nodev и nоехес.
Файлы управления заданиями. Доступ к механизмам управления заданиями, таким, как at или cron, должен быть разрешен только системным администраторам или администраторам приложений.
Повышение пользовательских привилегий:
• запрещено использование SUID/SGID-скриптовых shell;
• запрещено использование cheap fork/exec SUID-бинарников в качестве упаковщиков;
• повышение привилегий для упаковщиков должно использовать механизм SGID там, где это возможно;
• запрещены любые команды SUID/SGID, которые могут заканчиваться в shell escape;
• администраторы систем и приложений, обладающие возможностью повышения привилегий до уровня root, должны повышать их только с использованием упаковщиков shell, таких, как sudo, calife, super. Эти упаковщики необходимо устанавливать так, чтобы только администраторы могли выполнять набор разрешенных им команд. Должен быть организован тщательный анализ аргументов командной строки.
Журналирование. Журналы системной активности должны храниться минимум один месяц на локальных или внешних носителях информации. Для критичных журналов необходимо обеспечить маркировку и хранение за пределами предприятия.
Синхронизация времени. Синхронизация времени должна происходить из доверенного источника.
КРИТИЧНЫЕ СИСТЕМЫ И СИСТЕМЫ, ДОСТУПНЫЕ ИЗ ИНТЕРНЕТА
УЧЕТНЫЕ ЗАПИСИ ГРУПП И ПОЛЬЗОВАТЕЛЕЙ
Глобальные профили пользователей. Все глобальные профили пользователей должны использовать минимальную umask 0 2 7, то есть полный доступ – для владельца, read и execute – для владельца группы, «нет доступа» – для всех остальных пользователей.
Учетные записи конечных пользователей. Учетные записи конечных пользователей запрещены. Должны быть доступны только учетные записи системных администраторов.
Обновление паролей. Все пароли должны обновляться в соответствии с политикой использования паролей.
Профили пользователей. После выхода из системы файлы, содержащие перечень введенных команд, должны быть очищены. Их содержание может быть перед этим скопировано в защищенную от доступа область для дальнейшего анализа.
УДАЛЕННЫЙ ДОСТУП
Использование r-команд BSD. Использование этих команд строго запрещено.
Удаленный доступ для привилегированных пользователей и администраторов. Для организации такого доступа необходимо использовать механизмы шифрования. Все другие протоколы, передающие пароли открытым текстом, запрещены.
ПРИЛОЖЕНИЯ
Сетевые приложения. Сетевые приложения должны быть интегрированы и сконфигурированы таким образом, чтобы взлом приложения не привел к взлому самого сервера.
Совместно используемые директории и файлы. Приложения должны иметь возможность осуществлять операции чтения и выполнения только над ограниченным списком файлов и директорий. Доступ на запись должен быть запрещен везде, где это возможно.
Уязвимости программного обеспечения. Системные администраторы и администраторы приложений отвечают за установку последних обновлений от производителей используемого программного обеспечения.
Инструменты разработки. Установка любых средств разработки и отладки, включая компиляторы и отладчики, запрещена.
ЦЕЛОСТНОСТЬ СИСТЕМЫ
Уменьшение поверхности атак. Все неиспользуемые сервисы должны быть отключены.
Файлы управления заданиями. Все внешние команды в заданиях должны использовать абсолютные пути, а не относительные.
Безопасность критичных системных файлов и файлов данных:
• все критичные системные файлы и критичные файлы приложений должны регулярно проверяться по базе сигнатур (владелец, разрешения, дата последнего изменения, MD5-cyммa);
• появление файлов дампов ядра должно быть немедленно обнаружено, и по этому поводу необходимо провести расследование;
• поиск, журналирование новых файлов и директорий, не представленных в базе данных, и создание отчетов о них должны быть автоматизированы и анализироваться администраторами;
• появление выполняемых или специальных файлов во временных директориях должно быть немедленно обнаружено, по этому поводу необходимо провести расследование.
Журналирование. Журналы активности приложений и системы должны храниться как минимум один месяц на локальных носителях информации и как минимум шесть месяцев на внешних.
Журналы для систем типа серверов аутентификации удаленных пользователей должны храниться на внешних носителях информации в течение одного года.
Синхронизация времени. Системы должны использовать как минимум два надежных источника времени.
Свойства монтирования файловой системы. Файловые системы, используемые для /bin, /sbin, /usr, и любые другие каталоги, которые считаются статическими, должны быть смонтированы в режиме «только для чтения».
Сервисы каталогов. Использование непроверенных сервисов типа внешних DNS-серверов запрещено, если это может оказать негативное влияние на системы или сервисы.
Уязвимости программного обеспечения. Системные администраторы отвечают за установку последних обновлений от производителей используемого программного обеспечения для поддержания требуемого уровня безопасности системы.
2.2. Подход компании Sun Microsystems
Как считают в Sun, политика безопасности является необходимой для эффективной организации режима информационной безопасности компании. Здесь под политикой безопасности понимается стратегический документ, в котором ожидания и требования руководства компании к организации режима информационной безопасности выражаются в определенных измеримых и контролируемых целях и задачах. При этом Sun рекомендует реализовать подход «сверху-вниз», то есть сначала разработать политику безопасности, а затем приступать к построению соответствующей архитектуры корпоративной системы защиты информации. В противном случае политика безопасности будет создана сотрудниками службы автоматизации произвольно. При этом архитектура корпоративной системы защиты информации будет разрозненной, затратной и далеко не оптимальной.
Определение ролей и обязанностей. К разработке политики безопасности рекомендуется привлечь сотрудников таких подразделений компании, как:
• управление бизнесом,
• техническое управление,
• отдел защиты информации,
• департамент управления рисками,
• департамент системных операций,
• департамент разработки приложений,
• отдел сетевого администрирования,
• отдел системного администрирования,
• служба внутреннего аудита и качества,
• юридический отдел,
• отдел кадров.
Определение ролей и обязанностей. К разработке политики безопасности рекомендуется привлечь сотрудников таких подразделений компании, как:
• управление бизнесом,
• техническое управление,
• отдел защиты информации,
• департамент управления рисками,
• департамент системных операций,
• департамент разработки приложений,
• отдел сетевого администрирования,
• отдел системного администрирования,
• служба внутреннего аудита и качества,
• юридический отдел,
• отдел кадров.
2.2.1. Структура политики безопасности
Рекомендуемая структура документов политики безопасности:
• описание основных целей и задач защиты информации,
• определение отношения руководства компании к политике безопасности,
• обоснование путей реализации политики безопасности,
• определение ролей и обязанностей ответственных за организацию режима информационной безопасности в компании,
• определение требуемых правил и норм безопасности,
• определение ответственности за нарушение политики,
• определение порядка пересмотра и контроля положений политики безопасности.
Основное назначение политики безопасности. Основное назначение политики безопасности – информирование сотрудников и руководства компании о существующих требованиях по защите информационных активов компании. Политика также определяет механизмы и способы, используемые для достижения выполнения этих требований. Для этого в политике безопасности должны быть определены показатели и критерии защищенности активов компании, в соответствии с которыми будут приобретаться и настраиваться средства защиты. Политика также служит основой для последующей разработки стандартов, процедур, регламентов безопасности.
Связь со стандартами и процедурами безопасности. Политика безопасности содержит ожидания руководства по обеспечению безопасности, цели и задачи организации режима информационной безопасности. Для того чтобы быть практичной и осуществимой, политика безопасности должна реализовываться в процедурах, руководствах и стандартах, обеспечивающих детальную интерпретацию положений политики безопасности для сотрудников, партнеров и клиентов компании. При этом рекомендуется начинать разработку стандартов, процедур и руководств безопасности после принятия политики безопасности и внедрения соответствующих механизмов контроля выполнения ее требований.
Основные идеи политики безопасности. К основным идеям политики безопасности относятся:
определение ценности информационных активов;
Разработка политики безопасности компании основана на необходимости защиты ценных информационных активов компании. Это означает, что нужно уделить пристальное внимание категорированию информационных ресурсов, определению их владельцев, определению критически важных для компании информационных потоков.
управление остаточными рисками;
Для создания реалистичной политики безопасности компании необходимо, чтобы она была адекватной целям и задачам развития бизнеса компании. Для этого нужно воспользоваться концепцией управления информационными рисками. В теории управления финансами категория риска определяется следующим образом:
R = H × P,
где Н – денежная оценка ущерба в результате инцидента;
Р – вероятность инцидента.
Представим, например, защиту источника питания хранилища данных некоторого коммерческого банка. Источник питания стоит 10 млн. долларов. Если принять вероятность полного разрушения источника питания, например в результате теракта, как 1:1 000 000 000, то риск будет равен произведению этих величин и составит всего 1 цент.
Теперь представим персональный счет клиента, который защищен лишь 4-значным пин-кодом. Вероятность подбора такого кода равна 0,001. Если представить, что средняя сумма на балансе составляет 3 тыс. долларов, то риск составит 30 центов. То есть риск взлома банковского счета может быть в 30 раз выше риска потери источника питания стоимостью 10 млн. долларов.
Следует сказать, что задача управления рисками состоит не в том, чтобы определять риск исключительно количественно с высокой точностью и достоверностью. Здесь достаточно просто понимания природы риска и определения такой метрики риска, которая позволяет измерять, сравнивать, наблюдать и оптимизировать остаточные риски компании и тем самым устанавливать, насколько политика безопасности соответствует требованиям бизнеса.
управление информационной безопасностью;
Необходимо четко представлять, что только одна компонента корпоративной системы защиты информации (пусть даже самая важная) не обеспечит приемлемую безопасность информационных активов компании. Политики безопасности будут эффективны только в контексте целостной архитектуры безопасности, то есть все системы контроля доступа, межсетевые экраны, криптосистемы, системы управления ключами и другие средства защиты информации должны работать как единое целое.
обоснованное доверие.
Доверие – основа всех деклараций безопасности компании. Для доверия нужно понимать и принимать основные положения политики безопасности и обладать уверенностью в том, что они отвечают заявленным ожиданиям руководства компании.
Принципы безопасности. Формулирование принципов обеспечения информационной безопасности является первым важным шагом при разработке политики безопасности, так как они определяют сущность организации режима информационной безопасности компании. К ним относятся принципы:
• ответственности – ответственность за обеспечение безопасности информационных систем компании должна быть явно определена;
• ознакомления – собственники информации, пользователи информационных систем, а также клиенты и партнеры по бизнесу должны быть проинформированы о правилах утвержденной политики безопасности компании, а также о степени ответственности при работе с конфиденциальной информацией компании;
• этики – обеспечение информационной безопасности компании должно осуществляться в соответствии со стандартами этики, применимыми к деятельности компании;
• комплексности – политики, стандарты, практики и процедуры безопасности должны охватывать все уровни обеспечения безопасности: нормативно-методический, экономический, технологический, технический и организационно-управленческий;
• экономической оправданности – обеспечение безопасности компании должно быть экономически оправданным;
• интеграции – политики, стандарты, практики и процедуры безопасности должны быть скоординированы и интегрированы между собой;
• своевременности – обеспечение безопасности компании должно позволять своевременно реагировать на угрозы безопасности и парировать их;
• описание основных целей и задач защиты информации,
• определение отношения руководства компании к политике безопасности,
• обоснование путей реализации политики безопасности,
• определение ролей и обязанностей ответственных за организацию режима информационной безопасности в компании,
• определение требуемых правил и норм безопасности,
• определение ответственности за нарушение политики,
• определение порядка пересмотра и контроля положений политики безопасности.
Основное назначение политики безопасности. Основное назначение политики безопасности – информирование сотрудников и руководства компании о существующих требованиях по защите информационных активов компании. Политика также определяет механизмы и способы, используемые для достижения выполнения этих требований. Для этого в политике безопасности должны быть определены показатели и критерии защищенности активов компании, в соответствии с которыми будут приобретаться и настраиваться средства защиты. Политика также служит основой для последующей разработки стандартов, процедур, регламентов безопасности.
Связь со стандартами и процедурами безопасности. Политика безопасности содержит ожидания руководства по обеспечению безопасности, цели и задачи организации режима информационной безопасности. Для того чтобы быть практичной и осуществимой, политика безопасности должна реализовываться в процедурах, руководствах и стандартах, обеспечивающих детальную интерпретацию положений политики безопасности для сотрудников, партнеров и клиентов компании. При этом рекомендуется начинать разработку стандартов, процедур и руководств безопасности после принятия политики безопасности и внедрения соответствующих механизмов контроля выполнения ее требований.
Основные идеи политики безопасности. К основным идеям политики безопасности относятся:
определение ценности информационных активов;
Разработка политики безопасности компании основана на необходимости защиты ценных информационных активов компании. Это означает, что нужно уделить пристальное внимание категорированию информационных ресурсов, определению их владельцев, определению критически важных для компании информационных потоков.
управление остаточными рисками;
Для создания реалистичной политики безопасности компании необходимо, чтобы она была адекватной целям и задачам развития бизнеса компании. Для этого нужно воспользоваться концепцией управления информационными рисками. В теории управления финансами категория риска определяется следующим образом:
R = H × P,
где Н – денежная оценка ущерба в результате инцидента;
Р – вероятность инцидента.
Представим, например, защиту источника питания хранилища данных некоторого коммерческого банка. Источник питания стоит 10 млн. долларов. Если принять вероятность полного разрушения источника питания, например в результате теракта, как 1:1 000 000 000, то риск будет равен произведению этих величин и составит всего 1 цент.
Теперь представим персональный счет клиента, который защищен лишь 4-значным пин-кодом. Вероятность подбора такого кода равна 0,001. Если представить, что средняя сумма на балансе составляет 3 тыс. долларов, то риск составит 30 центов. То есть риск взлома банковского счета может быть в 30 раз выше риска потери источника питания стоимостью 10 млн. долларов.
Следует сказать, что задача управления рисками состоит не в том, чтобы определять риск исключительно количественно с высокой точностью и достоверностью. Здесь достаточно просто понимания природы риска и определения такой метрики риска, которая позволяет измерять, сравнивать, наблюдать и оптимизировать остаточные риски компании и тем самым устанавливать, насколько политика безопасности соответствует требованиям бизнеса.
управление информационной безопасностью;
Необходимо четко представлять, что только одна компонента корпоративной системы защиты информации (пусть даже самая важная) не обеспечит приемлемую безопасность информационных активов компании. Политики безопасности будут эффективны только в контексте целостной архитектуры безопасности, то есть все системы контроля доступа, межсетевые экраны, криптосистемы, системы управления ключами и другие средства защиты информации должны работать как единое целое.
обоснованное доверие.
Доверие – основа всех деклараций безопасности компании. Для доверия нужно понимать и принимать основные положения политики безопасности и обладать уверенностью в том, что они отвечают заявленным ожиданиям руководства компании.
Принципы безопасности. Формулирование принципов обеспечения информационной безопасности является первым важным шагом при разработке политики безопасности, так как они определяют сущность организации режима информационной безопасности компании. К ним относятся принципы:
• ответственности – ответственность за обеспечение безопасности информационных систем компании должна быть явно определена;
• ознакомления – собственники информации, пользователи информационных систем, а также клиенты и партнеры по бизнесу должны быть проинформированы о правилах утвержденной политики безопасности компании, а также о степени ответственности при работе с конфиденциальной информацией компании;
• этики – обеспечение информационной безопасности компании должно осуществляться в соответствии со стандартами этики, применимыми к деятельности компании;
• комплексности – политики, стандарты, практики и процедуры безопасности должны охватывать все уровни обеспечения безопасности: нормативно-методический, экономический, технологический, технический и организационно-управленческий;
• экономической оправданности – обеспечение безопасности компании должно быть экономически оправданным;
• интеграции – политики, стандарты, практики и процедуры безопасности должны быть скоординированы и интегрированы между собой;
• своевременности – обеспечение безопасности компании должно позволять своевременно реагировать на угрозы безопасности и парировать их;