• минимальные разрешения на директории пользователей должны быть: 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. Структура политики безопасности
Рекомендуемая структура документов политики безопасности:
• описание основных целей и задач защиты информации,
• определение отношения руководства компании к политике безопасности,
• обоснование путей реализации политики безопасности,
• определение ролей и обязанностей ответственных за организацию режима информационной безопасности в компании,
• определение требуемых правил и норм безопасности,
• определение ответственности за нарушение политики,
• определение порядка пересмотра и контроля положений политики безопасности.
Основное назначение политики безопасности. Основное назначение политики безопасности – информирование сотрудников и руководства компании о существующих требованиях по защите информационных активов компании. Политика также определяет механизмы и способы, используемые для достижения выполнения этих требований. Для этого в политике безопасности должны быть определены показатели и критерии защищенности активов компании, в соответствии с которыми будут приобретаться и настраиваться средства защиты. Политика также служит основой для последующей разработки стандартов, процедур, регламентов безопасности.
Связь со стандартами и процедурами безопасности. Политика безопасности содержит ожидания руководства по обеспечению безопасности, цели и задачи организации режима информационной безопасности. Для того чтобы быть практичной и осуществимой, политика безопасности должна реализовываться в процедурах, руководствах и стандартах, обеспечивающих детальную интерпретацию положений политики безопасности для сотрудников, партнеров и клиентов компании. При этом рекомендуется начинать разработку стандартов, процедур и руководств безопасности после принятия политики безопасности и внедрения соответствующих механизмов контроля выполнения ее требований.