Главная страница
Навигация по странице:

  • 13.2 Использование процессного подхода в управлении информационной безопасностью на основе модели PDCA: планирование - реализация - проверка - улучшение. Перечень действий на каждой стадии модели.

  • Программно-аппаратная защита информации 1. Средства защиты информации, встроенные в системное программное обеспечение.

  • Аутентифика́ция

  • Авториза́ция

  • 1.4 Процедура аудита, осуществляемого средствами операционной системы. Сущность аудита, его роль в обеспечении безопасности и выполняемые функции.

  • Аудит входа в систему

  • Аудит доступа к объектам

  • Аудит доступа к службе каталогов

  • «Дополнительные параметры безопасности»

  • «Аудит доступа к объектам»

  • Аудит изменения политики

  • Аудит изменения привилегий

  • Аудит отслеживания процессов

  • Аудит системных событий

  • Аудит событий входа в систему

  • Аудит управления учетными записями

  • 1.5 Журналы событий и безопасности Windows. Порядок использования содержания журналов для получения сведений в целях обеспечения безопасности.

  • госы. ГОСы шпоры. Теория информационной безопасности и методология защиты информации Система обеспечения информационной безопасности в Российской Федерации. 1 Понятие система обеспечения информационной безопасности


    Скачать 2.75 Mb.
    НазваниеТеория информационной безопасности и методология защиты информации Система обеспечения информационной безопасности в Российской Федерации. 1 Понятие система обеспечения информационной безопасности
    Дата05.11.2022
    Размер2.75 Mb.
    Формат файлаdocx
    Имя файлаГОСы шпоры.docx
    ТипДокументы
    #771088
    страница9 из 17
    1   ...   5   6   7   8   9   10   11   12   ...   17

    13. Механизмы менеджмента информационной безопасности.

    13.1 Управление информационной безопасностью предприятия на основе положений  ГОСТ Р ИСО/МЭК 27001-2006.

    ГОСТ Р ИСО/МЭК 27001-2006 является копипастой международного стандарта управления безопасностью ISO/IEC 27001 и предназначен для разработки Системы Менеджмента Информационной Безопасности (СМИБ) организации вне зависимости от ее сферы деятельности. В данном стандарте собраны описания лучших мировых практик в области управления информационной безопасностью. 27001 устанавливает требования к системе менеджмента информационной безопасности для демонстрации способности организации защищать свои информационные ресурсы.

    Стандарт 27001 определяет процессы, представляющие возможность бизнесу устанавливать, применять, пересматривать, контролировать и поддерживать эффективную систему менеджмента информационной безопасности; устанавливает требования к разработке, внедрению, функционированию, мониторингу, анализу, поддержке и совершенствованию документированной системы менеджмента информационной безопасности в контексте существующих бизнес рисков организации.

    13.2 Использование процессного подхода в управлении информационной безопасностью на основе модели PDCA: планирование - реализация - проверка - улучшение. Перечень действий на каждой стадии модели.

    Модель PDCA

    Программно-аппаратная защита информации

    1. Средства защиты информации, встроенные в системное программное обеспечение.

    1.1 Общая характеристика системы защиты информации, встроенной в современную операционную систему. Понятие, сущность и общая характеристика процессов аутентификации, авторизации и аудита.

    Аутентифика́ция — процедура проверки подлинности, например: проверка подлинности пользователя путём сравнения введённого им пароля с паролем в базе данных пользователей;

    Авториза́ция — предоставление определённому лицу или группе лиц прав на выполнение определённых действий; а также процесс проверки (подтверждения) данных прав при попытке выполнения этих действий.

    • В информационных технологиях посредством авторизации устанавливаются права доступа к информационным ресурсам и системам обработки данных.

    Аудит (auditing) — фиксация в системном журнале событий, связанных с досту­пом к защищаемым системным ресурсам. Средства учета и наблюдения обеспечивают возможность обнаружить и зафиксировать важные события, связанные с безопасностью, или любые попытки создать, получить до­ступ или удалить системные ресурсы. Аудит используется для того, чтобы засе­кать даже неудачные попытки «взлома» системы.

    Протоколирование/аудит традиционно являлись последним рубежом обороны, обеспечивающим анализ последствий нарушения информационной безопасности и выявление злоумышленников. Такой аудит можно назвать пассивным. В современный арсенал защитных средств вошел активный аудит, направленный на выявление подозрительных действий в реальном масштабе времени. Активный аудит включает два вида действий: выявление нетипичного поведения (пользователей, программ или аппаратуры);

    выявление начала злоумышленной активности.

    1.2 Теоретические основы аутентификации пользователя вычислительной системы. Особенности аутентификации в операционных системах Windows семейства NT. База данных SAM, служба каталогов Active Directory. Технологическая схема аутентификации. Преимущества и недостатки программной аутентификации.

    Пользователи определяются в Windows(R) NT путем создания учетных записей с помощью инструмента "Диспетчер пользователей".

    Учетная запись, содержащая в качестве элементов другие учетные записи, называется группой. Группы дают администраторам Windows NT возможность предоставлять права доступа всем пользователям некоторой группы одновременно. Учетные записи групп, как и учетные записи пользователей, определяются и обслуживаются с помощью базы данных Диспетчера прав доступа (SAM).В доменах Windows Server 2000/2003 такой базой является Active Directory.

    Active Directory («Активный каталог», AD) — LDAP-совместимая реализация службы каталогов корпорации Microsoft для операционных систем семейства Windows NT. Active Directory позволяет администраторам использовать групповые политики для обеспечения единообразия настройки пользовательской рабочей среды, разворачивать программное обеспечение на множестве компьютеров через групповые политики или посредством System Center Configuration Manager (ранее Microsoft Systems Management Server), устанавливать обновления операционной системы, прикладного и серверного программного обеспечения на всех компьютерах в сети, используя Службу обновления Windows Server. Active Directory хранит данные и настройки среды в централизованной базе данных. Сети Active Directory могут быть различного размера: от нескольких десятков до нескольких миллионов объектов.

    Представление Active Directory состоялось в 1999 году, продукт был впервые выпущен с Windows 2000 Server, а затем был модифицирован и улучшен при выпуске Windows Server 2003. Впоследствии Active Directory был улучшен в Windows Server 2003 R2, Windows Server 2008 и Windows Server 2008 R2 и переименован в Active Directory Domain Services. Ранее служба каталогов называлась NT Directory Service (NTDS), это название до сих пор можно встретить в некоторых исполняемых файлах.

    В отличие от версий Windows до Windows 2000, которые использовали в основном протокол NetBIOS для сетевого взаимодействия, служба Active Directory интегрирована с DNS и TCP/IP. Для аутентификации по умолчанию используется протокол Kerberos. Если клиент или приложение не поддерживает аутентификацию Kerberos, используется протокол NTLM[1].

    1.3 Процедура авторизации и ее сущность. Защита информации от несанкционированного доступа. Авторизация на основе мандатного и избирательного доступа. Централизованная и децентрализованная схема авторизации. Процедура авторизации на примере базовой системы безопасности Windows – Kerberos. Управление доступом.

    Средства авторизации контролируют доступ легальных пользователей в систему, предоставляя им права, которые были определены администратором системы. ... к информации, устройствам, система может так же контролировать выполнение пользователем различных действий.

    Могут быть использованы различные формы правил предоставления доступа, которые принято разделять на два класса:

    • Системы с избирательным доступом

    • Системы с мандатным доступом

    В наиболее распространенном варианте первого подхода определенные операции над ресурсом разрешаются или запрещаются пользователю (или группе пользователей) который явно указан своим идентификатором. Избирательные права доступа реализуются в операционных системах общего назначения.

    Мандатный доступ заключается в том, что вся информация разделяется на уровни в зависимости от уровня секретности. Все пользователи сети так же разделяются на группы, образующие иерархии в соответствии с уровнем доступа к информации. В отличии от систем с избирательными правами доступа в системах с мандатным доступом пользователи не имеют возможности изменить уровень доступности информации.

    Процедура авторизации реализуется программными средствами, при этом данные средства могут работать на базе двух схем:

    • Централизованная схема авторизации

    • Децентрализованная схема авторизации

    Централизованная схема — в ней сервер управляет процессом предоставления ресурсов пользователю. Главная цель этих систем — реализовать принцип единого входа. В соответствии с централизованной схемой пользователь один раз входит в систему и получает на все время работы некоторый набор разрешений. Наиболее известный протокол реализующий данную схему: Kerberos.

    Децентрализованная схема — рабочая станция в этой схеме сама является защищенной, то есть средства защиты работают на каждом компьютере и сервер для защиты информации здесь не требуется. При данном подходе доступ к каждому приложению должен контролироваться средством безопасности самого приложения.

    В крупных сетях часто применяется комбинированный подход предоставления прав доступа к ресурсам сети. В этом подходе сервер удаленного доступа ограничивает доступ пользователя к подсетям или серверам корпоративной сети (укрупненным элементам корпоративных сетей). А каждый отдельный сервер ограничивает доступ к своим внутренним ресурсам.


    1.4 Процедура аудита, осуществляемого средствами операционной системы. Сущность аудита, его роль в обеспечении безопасности и выполняемые функции.

    При попытке совершения какого- либо действия, описанного ниже в журнал безопасности записывается “Успех” или “Отказ” в зависимости от результата действия.

    Аудит входа в систему. Текущая политика определяет, будет ли операционная система пользователя, для компьютера которого применяется данная политика аудита, выполнять аудит каждой попытки входа пользователя в систему или выхода из нее. Например, при удачном входе пользователя на компьютер генерируется событие входа учетной записи. События выхода из системы создаются каждый раз, когда завершается сеанс вошедшей в систему учетной записи пользователя. Аудит успехов означает создание записи аудита для каждой успешной попытки входа в систему. Аудит отказов означает создание записи аудита для каждой неудачной попытки входа в систему.

    Аудит доступа к объектам. Данная политика безопасности выполняет аудит попыток доступа пользователей к объектам, которые не имеют отношения к Active Directory. К таким объектам можно отнести файлы, папки, принтеры, разделы системного реестра, которые задаются собственными списками в системном списке управления доступом (SACL). Аудит создается только для объектов, для которых указаны списки управления доступом, при условии, что запрашиваемый тип доступа и учетная запись, выполняющая запрос, соответствуют параметрам в данных списках.

    Аудит доступа к службе каталогов. При помощи этой политики безопасности вы можете определить, будет ли выполняться аудит событий, указанных в системном списке контроля доступа (SACL), который можно редактировать в диалоговом окне«Дополнительные параметры безопасности» свойств объекта Active Directory. Аудит создается только для объектов, для которых указан системный список управления доступом, при условии, что запрашиваемый тип доступа и учетная запись, выполняющая запрос, соответствуют параметрам в данном списке. Данная политика в какой-то степени похожа на политику «Аудит доступа к объектам». Аудит успехов означает создание записи аудита при каждом успешном доступе пользователя к объекту Active Directory, для которого определена таблица SACL. Аудит отказов означает создание записи аудита при каждой неудачной попытке доступа пользователя к объекту Active Directory, для которого определена таблица SACL.

    Аудит изменения политики. Эта политика аудита указывает, будет ли операционная система выполнять аудит каждой попытки изменения политики назначения прав пользователям, аудита, учетной записи или доверия. Аудит успехов означает создание записи аудита при каждом успешном изменении политик назначения прав пользователей, политик аудита или политик доверительных отношений. Аудит отказов означает создание записи аудита при каждой неудачной попытке изменения политик назначения прав пользователей, политик аудита или политик доверительных отношений.

    Аудит изменения привилегий. Используя эту политику безопасности, вы можете определить, будет ли выполняться аудит использования привилегий и прав пользователей. Аудит успехов означает создание записи аудита для каждого успешного применения права пользователя. Аудит отказов означает создание записи аудита для каждого неудачного применения права пользователя.

    Аудит отслеживания процессов. Текущая политика аудита определяет, будет ли операционная система выполнять аудит событий, связанных с процессами, такими как создание и завершение процессов, а также активация программ и непрямой доступ к объектам. Аудит успехов означает создание записи аудита для каждого успешного события, связанного с отслеживаемым процессом. Аудит отказов означает создание записи аудита для каждого неудачного события, связанного с отслеживаемым процессом.

    Аудит системных событий. Данная политика безопасности имеет особую ценность, так как именно при помощи этой политики вы можете узнать, перегружался ли у пользователя компьютер, превысил ли размер журнала безопасности пороговое значение предупреждений, была ли потеря отслеженных событий из-за сбоя системы аудита и даже вносились ли изменения, которые могли повлиять на безопасность системы или журнала безопасности вплоть до изменения системного времени. Аудит успехов означает создание записи аудита для каждого успешного системного события. Аудит отказов означает создание записи аудита для каждого неудачного завершения системного события.

    Аудит событий входа в систему. При помощи этой политики аудита вы можете указать, будет ли операционная система выполнять аудит каждый раз при проверке данным компьютером учетных данных. При использовании этой политики создается событие для локального и удаленного входа пользователя в систему. Члены домена и компьютеры, не входящие в домен, являются доверенными для своих локальных учетных записей. Когда пользователь пытается подключиться к общей папке на сервере, в журнал безопасности записывается событие удаленного входа, причем события выхода из системы не записываются. Аудит успехов означает создание записи аудита для каждой успешной попытки входа в систему. Аудит отказов означает создание записи аудита для каждой неудачной попытки входа в систему.

    Аудит управления учетными записями. Эта последняя политика тоже считается очень важной, так как именно при помощи нее вы можете определить, необходимо ли выполнять аудит каждого события управления учетными записями на компьютере. В журнал безопасности будут записываться такие действия как создание, перемещение и отключение учетных записей, а также изменение паролей и групп. Аудит успехов означает создание записи аудита для каждого успешного события управления учетными записями. Аудит отказов означает создание записи аудита для каждого неудачного события управления учетными записями

    Как видите, все политики аудита в какой-то степени очень похожи и если вы для каждого пользователя свой организации установите аудит всех политик, то рано или поздно вы просто запутаетесь в них. Поэтому необходимо вначале определить, что именно необходимо для аудита. Например, чтобы удостовериться в том, что к одной из ваших учетных записей постоянно пытаются получить несанкционированный доступ методом подбора пароля, вы можете указать аудит неудачных попыток входа. В следующем разделе мы рассмотрим простейший пример использования данных политик.

    1.5 Журналы событий и безопасности Windows. Порядок использования содержания журналов для получения сведений в целях обеспечения безопасности.

    Журнал событий англ. Event Log — в Microsoft Windows стандартный способ для приложений и операционной системы записи и централизованного хранения информации о важных программных и аппаратных событиях. Служба журналов событий сохраняет события от различных источников в едином журнале событий, программа просмотра событий позволяет пользователю наблюдать за журналом событий, программный интерфейс (API) позволяет приложениям записывать в журнал информацию и просматривать существующие записи.

    Записи журнала событий хранятся в ключе реестра

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog



    Данный ключ содержит подключи, называемые файлами журнала. По умолчанию имеются:

    • файл журнала приложений — для событий приложений и служб;

    • файл журнала безопасности — для событий системы аудита;

    • файл системного журнала — для событий драйверов устройств.

    Имеется возможность создавать дополнительные журналы. Для каждого источника событий в журнале создаётся отдельный подключ. События от каждого источника могут включаться в определяемые отдельно для каждого источника категории. События должны принадлежать к одному из пяти предопределённых типов.

    Тип

    Описание

    Информация

    События указывают редкие и важные успешные операции.

    Предупреждение

    События указывают проблемы, которые не требуют немедленного вмешательства, но могут привести к ошибкам в будущем. Примером такого рода событий может служить исчерпание ресурсов.

    Ошибка

    События указывают существенные проблемы, обычно приводящие к потере функциональности или данных. Примером может служить невозможность запуска службы при загрузке.

    Успешный аудит

    События безопасности, которые происходят при успешном обращении к аудируемым ресурсам. Примером может служить успешный вход в систему.

    Не успешный аудит

    События безопасности, которые происходят при неуспешном обращении к аудируемым ресурсам. Примером может служить попытка открыть файл, не имея соответствующих прав доступа.

    Запись о событии включает в себя: идентификатор события, тип события, категорию события, массив строк и дополнительные, специфичные для события, двоичные данные. Каждый источник событий должен зарегистрировать свой файл сообщений, в котором хранятся строки описания идентификаторов сообщений, категорий и параметров. Строка описания может содержать места для вставки строк из массива, указанного при записи события, например:

    Невозможно открыть %1, ошибка %2

    Администраторы могут осмотреть и очищать журнал, разделить права на чтение и очистку невозможно. Кроме того, администратор может использовать специальную утилиту Winzapper для удаления записей о конкретных событиях из журнала. По этой причине, в случае если учетная запись администратора была взломана, история событий, содержащихся в журнале событий, становится недостоверной. Противостоять этому можно путем создания удаленного сервера журнала, доступ к которому будет осуществляться лишь посредством консоли.

    Как только журнал достигает максимально допустимого размера, он может либо перезаписывать старые события, либо остановить запись. Это делает его восприимчивым к атакам, в которых нарушитель пытается переполнить журнал путем создания большого числа новых событий. Частично против этого может помочь увеличение максимального размера журнала. Таким образом, для переполнения журнала потребуется инициировать большее количество событий. Можно дать команду журналу не перезаписывать старые события, но это может стать причиной сбоя.

    Ещё один способ атаковать журнал событий - зарегистрироваться под учетной записью администратора и изменить политику аудита, а именно - остановить запись в журнал несанкционированной активности. В зависимости от настроек политики аудита, её изменение может быть записано в журнале. Запись об этом событии можно очистить с помощью Winzapper. С этого момента активность не будет фиксироваться в журнале событий.

    Конечно, доступ к журналу нужен не для всех атак. Но зная о том, каким образом работает журнал событий, можно принять меры предосторожности во избежание обнаружения. Например, пользователь, желающий войти в систему под учетной записью сослуживца по корпоративной сети, может ждать до тех пор, пока не сможет незаметно воспользоваться компьютером. Далее он использует аппаратные средства для подбора пароля и регистрируется в системе. Затем имя учетной записи пользователя передается в службу терминалов сWi-Fi Hotspot, IP-адрес которого не возможно будет отследить и выйти через него на взломщика.

    После того как журнал очищается через окно просмотра событий, сразу создается одна запись в свежеочищенный журнал, отмечая время очистки и администратора-исполнителя. Эта информация может стать отправной точкой в расследовании подозрительных действий.

    Кроме журнала событий Windows, администраторы также могут проверить журнал безопасности Брандмауэра Windows
    1   ...   5   6   7   8   9   10   11   12   ...   17


    написать администратору сайта