Куда я попал?
SECURITM это система для корпоративных служб информационной безопасности, которая автоматизирует ключевые процессы управления: контроль соответствия требованиям, управление рисками, учет активов, планирование работ, задачи, технические уязвимости, опросы и т.д.
SECURITM помогает построить и управлять ИСПДн, КИИ, ГИС, СМИБ/СУИБ, банковскими системами защиты.
А еще SECURITM это место для обмена опытом в рамках сообщества служб безопасности.

Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 9. Требования к защите информации на этапах жизненного цикла автоматизированных систем и приложений

ГОСТ Р № 57580.1-2017 от 01.01.2018

ЖЦ.3

Для проведения оценки соответствия по документу войдите в систему.

Похожие требования

Положение Банка России № 787-П от 12.01.2022 "Обязательные для кредитных организаций требованиях к операционной надежности при осуществлении банковской деятельности в целях обеспечения непрерывности оказания банковских услуг":
п. 10
10. Кредитные организации в рамках обеспечения операционной надежности должны:
  • моделировать информационные угрозы в отношении критичной архитектуры с учетом требований к проведению качественной оценки уровня операционного риска, предусмотренных подпунктом 2.1.5 пункта 2.1 Положения Банка России N 716-П;
  • планировать применение организационных и технических мер, направленных на реализацию требований к операционной надежности, с учетом результатов идентификации риска информационной безопасности, а также его оценки, проводимой в составе процедур управления операционным риском в соответствии с требованиями глав 2 и 7 Положения Банка России N 716-П;
  • обеспечивать реализацию требований к операционной надежности на стадиях создания, ввода в эксплуатацию, эксплуатации (использования по назначению, технического обслуживания и ремонта), модернизации, вывода из эксплуатации объектов информационной инфраструктуры;
  • обеспечивать контроль соблюдения требований к операционной надежности.
Кредитные организации должны включать в порядок ведения базы событий, предусмотренный пунктом 6.2 Положения Банка России N 716-П, особенности регистрации событий операционного риска, являющихся инцидентами операционной надежности.

Кредитная организация должна регистрировать инциденты операционной надежности с учетом требований к ведению базы событий, предусмотренных главой 6 Положения Банка России N 716-П.

Кредитные организации при определении в соответствии с пунктом 3.7 Положения Банка России N 716-П дополнительных типов событий операционного риска должны предусматривать во внутренних документах классификацию типов инцидентов операционной надежности с использованием перечня типов инцидентов операционной надежности, размещаемого Банком России на официальном сайте Банка России в информационно-телекоммуникационной сети "Интернет" (далее - сеть "Интернет"), и обеспечивать их регулярную актуализацию.

По каждому инциденту операционной надежности в дополнение к информации, указанной в пункте 6.6 Положения Банка России N 716-П, кредитные организации должны обеспечить регистрацию следующей информации:
  • данных, используемых для фиксации превышения установленных значений целевых показателей операционной надежности;
  • данных, позволяющих выявить причину превышения установленных значений целевых показателей операционной надежности;
  • результата реагирования на инцидент операционной надежности (о принятых мерах и проведенных мероприятиях по реагированию на выявленный кредитной организацией или Банком России инцидент операционной надежности).
Кредитные организации должны устанавливать во внутренних документах критерии шкалы качественных оценок и методику определения оценок качественных потерь от реализации инцидентов операционной надежности в соответствии с подпунктом 3.13.2 пункта 3.13 Положения Банка России N 716-П, в случае если они не определяются в денежном выражении.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 12.2.1
12.2.1
Defined Approach Requirements: 
Acceptable use policies for end-user technologies are documented and implemented, including:
  • Explicit approval by authorized parties.
  • Acceptable uses of the technology.
  • List of products approved by the company for employee use, including hardware and software. 
Customized Approach Objective:
The use of end-user technologies is defined and managed to ensure authorized usage. 

Applicability Notes:
Examples of end-user technologies for which acceptable use policies are expected include, but are not limited to, remote access and wireless technologies, laptops, tablets, mobile phones, and removable electronic media, email usage, and Internet usage. 

Defined Approach Testing Procedures:
  • 12.2.1 Examine the acceptable use policies for end-user technologies and interview responsible personnel to verify processes are documented and implemented in accordance with all elements specified in this requirement. 
Purpose:
End-user technologies are a significant investment and may pose significant risk to an organization if not managed properly. Acceptable use policies outline the expected behavior from personnel when using the organization’s information technology and reflect the organization’s risk tolerance 
These policies instruct personnel on what they can and cannot do with company equipment and instruct personnel on correct and incorrect uses of company Internet and email resources. Such policies can legally protect an organization and allow it to act when the policies are violated. 

Good Practice:
It is important that usage policies are supported by technical controls to manage the enforcement of the policies. 
Structuring polices as simple “do” and “do not” requirements that are linked to a purpose can help remove ambiguity and provide personnel with the context for the requirement. 
Requirement 12.1.1
12.1.1
Defined Approach Requirements: 
An overall information security policy is:
  • Established.
  • Published.
  • Maintained. 
  • Disseminated to all relevant personnel, as well as to relevant vendors and business partners. 
Customized Approach Objective:
The strategic objectives and principles of information security are defined, adopted, and known to all personnel. 

Defined Approach Testing Procedures:
  • 12.1.1 Examine the information security policy and interview personnel to verify that the overall information security policy is managed in accordance with all elements specified in this requirement. 
Purpose:
An organization’s overall information security policy ties to and governs all other policies and procedures that define protection of cardholder data. 
The information security policy communicates management’s intent and objectives regarding the protection of its most valuable assets, including cardholder data. 
Without an information security policy, individuals will make their own value decisions on the controls that are required within the organization which may result in the organization neither meeting its legal, regulatory, and contractual obligations, nor being able to adequately protect its assets in a consistent manner. 
To ensure the policy is implemented, it is important that all relevant personnel within the organization, as well as relevant third parties, vendors, and business partners are aware of the organization’s information security policy and their responsibilities for protecting information assets. 

Good Practice:
The security policy for the organization identifies the purpose, scope, accountability, and information that clearly defines the organization’s position regarding information security. 
The overall information security policy differs from individual security policies that address specific technology or security disciplines. This policy sets forth the directives for the entire organization whereas individual security policies align and support the overall security policy and communicate specific objectives for technology or security disciplines. 
It is important that all relevant personnel within the organization, as well as relevant third parties, vendors, and business partners are aware of the organization’s information security policy and their responsibilities for protecting information assets. 

Definitions:
“Relevant” for this requirement means that the information security policy is disseminated to those with roles applicable to some or all the topics in the policy, either within the company or because of services/functions performed by a vendor or third party 
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.14.2.5
A.14.2.5 Принципы безопасного проектирования систем 
Мера обеспечения информационной безопасности: Принципы безопасного проектирования систем должны быть установлены, документированы, поддерживаться и применяться к любым работам по реализации информационной системы 
A.6.1.5
A.6.1.5  Информационная безопасность при управлении проектом 
Мера обеспечения информационной безопасности: Информационную безопасность следует рассматривать при управлении проектом независимо от типа проекта 
A.14.1.1
A.14.1.1 Анализ и спецификация требований информационной безопасности 
Мера обеспечения информационной безопасности: Требования, относящиеся к информационной безопасности, должны быть включены в перечень требований для новых информационных систем или для усовершенствования существующих информационных систем 
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 12.1.1
12.1.1
Определенные Требования к Подходу:
Общая политика информационной безопасности - это:
  • Определена.
  • Опубликованна.
  • Поддерживается.
  • Распространяется среди всего соответствующего персонала, а также среди соответствующих поставщиков и деловых партнеров.
Цель Индивидуального подхода:
Стратегические цели и принципы информационной безопасности определены, приняты и известны всему персоналу.

Определенные Процедуры Тестирования Подхода:
  • 12.1.1 Изучите политику информационной безопасности и опросите персонал, чтобы убедиться, что общая политика информационной безопасности управляется в соответствии со всеми элементами, указанными в этом требовании.
Цель:
Общая политика информационной безопасности организации связана со всеми другими политиками и процедурами, определяющими защиту данных о держателях карт, и регулирует их.
Политика информационной безопасности отражает намерения и цели руководства в отношении защиты его наиболее ценных активов, включая данные о держателях карт.
Без политики информационной безопасности отдельные лица будут принимать свои собственные ценностные решения в отношении средств контроля, которые требуются в организации, что может привести к тому, что организация не будет выполнять свои юридические, нормативные и договорные обязательства, а также не сможет надлежащим образом защитить свои активы последовательным образом.
Для обеспечения реализации политики важно, чтобы весь соответствующий персонал в организации, а также соответствующие третьи стороны, поставщики и деловые партнеры были осведомлены о политике информационной безопасности организации и их обязанностях по защите информационных активов.

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

Определения:
“Соответствующий” для этого требования означает, что политика информационной безопасности распространяется среди лиц, чьи роли применимы к некоторым или всем разделам политики, либо внутри компании, либо из-за услуг/функций, выполняемых поставщиком или третьей стороной
Requirement 12.2.1
12.2.1
Определенные Требования к Подходу:
Документируются и внедряются политики приемлемого использования технологий конечного пользователя, включая:
  • Явное одобрение уполномоченных сторон.
  • Приемлемое использование технологии.
  • Список продуктов, одобренных компанией для использования сотрудниками, включая аппаратное и программное обеспечение.
Цель Индивидуального подхода:
Использование технологий конечного пользователя определяется и управляется для обеспечения авторизованного использования.

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

Определенные Процедуры Тестирования Подхода:
  • 12.2.1 Изучите политику приемлемого использования технологий конечного пользователя и опросите ответственный персонал, чтобы убедиться, что процессы документированы и реализованы в соответствии со всеми элементами, указанными в этом требовании.
Цель:
Технологии для конечных пользователей являются значительными инвестициями и могут представлять значительный риск для организации, если ими не управлять должным образом. Политика приемлемого использования описывает ожидаемое поведение персонала при использовании информационных технологий организации и отражает толерантность организации к риску
Эти правила инструктируют персонал о том, что они могут и не могут делать с оборудованием компании, а также инструктируют персонал о правильном и неправильном использовании ресурсов Интернета и электронной почты компании. Такая политика может юридически защитить организацию и позволить ей действовать в случае нарушения политики.

Надлежащая практика:
Важно, чтобы политики использования поддерживались техническими средствами контроля для управления применением политик.
Структурирование политики в виде простых требований “делать” и “не делать”, связанных с целью, может помочь устранить двусмысленность и предоставить персоналу контекст для требования.
Положение Банка России № 779-П от 15.11.2021 "Обязательные для некредитных финансовых организаций требований к операционной надежности при осуществлении видов деятельности, предусмотренных частью первой статьи 76.1 Федерального закона от 10 июля 2002 года N 86-ФЗ "О Центральном банке"":
п. 1.14.
1.14. Некредитные финансовые организации, обязанные соблюдать усиленный, стандартный или минимальный уровень защиты информации, в рамках обеспечения операционной надежности должны:
  • моделировать информационные угрозы в отношении критичной архитектуры;
  • планировать применение организационных и технических мер, направленных на реализацию требований к операционной надежности, на основе результатов оценки риска реализации информационных угроз в рамках системы управления рисками (при наличии);
  • обеспечивать реализацию требований к операционной надежности на стадиях создания, эксплуатации (использования по назначению, технического обслуживания и ремонта), модернизации, снятия с эксплуатации своих объектов информационной инфраструктуры;
  • обеспечивать контроль соблюдения требований к операционной надежности в отношении элементов критичной архитектуры.
Некредитные финансовые организации, обязанные соблюдать усиленный, стандартный или минимальный уровень защиты информации, должны устанавливать во внутренних документах порядок регистрации событий операционного риска, связанных с нарушением операционной надежности. По каждому событию операционного риска, связанному с нарушением операционной надежности, некредитные финансовые организации, обязанные соблюдать усиленный, стандартный или минимальный уровень защиты информации, должны обеспечивать регистрацию:
  • данных, используемых для фиксации отклонения от значений целевых показателей операционной надежности, указанных в пункте 1.3 настоящего Положения;
  • данных, позволяющих выявить причину отклонения от значений целевых показателей операционной надежности, указанных в пункте 1.3 настоящего Положения;
  • результата реагирования на событие операционного риска, связанное с нарушением операционной надежности (принятых мер и проведенных мероприятий по реагированию на выявленное некредитной финансовой организацией или Банком России событие операционного риска, связанное с нарушением операционной надежности).

Связанные защитные меры

3
Название Дата Влияние
Community
18 10 / 86
Настройка безопасной конфигурации для серверов ОС Linux
Разово Вручную Техническая Превентивная
16.05.2022
16.05.2022 18 10 / 86
Цель: сокращение поверхности атаки.
Часть общего процесса управления безопасностью конфигураций (Hardening).

Общий алгоритм:
  1. Определить, задокументировать требования к безопасности конфигурации.
  2. Применить безопасную конфигурацию на существующих хостах.
  3. Применять безопасную конфигурацию на новых хостах в рамках процесса их ввода в эксплуатацию.
  4. Регулярно проверять конфигурацию хостов на соответствие установленным требованиям.
Источником для формирования требований к безопасности конфигурации служат:
Документирование требований осуществляется в зависимости от принятых подходов в организации.
Вариант реализации: описать требования в карточке защитной меры. Пример документа

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

Минимальные требования к безопасной конфигурации:
  • Изменить пароли по умолчанию.
  • Настроить SSH 
  • Настроить сложность паролей
  • Настроить смену (жизненный цикл) паролей 
  • Настроить политику аутентификации
  • Отключить или удалить ненужные учетные записи пользователей
  • Отключить или ограничить ненужные службы, порты и протоколы
  • Удалить ненужное программное обеспечение
  • При необходимости ограничить физические порты
  • Настроить баннеры при входе
В зависимости от выстроенной в компании инфраструктуры к требованиям безопасности конфигурации могут быть отнесены:
  • Подключение хоста к корпоративной системе мониторинга
  • Настройка передачи логов на централизованный сервер (nxlog, SEM / SIEM) 
  • Конфигурация NTP и часового пояса
Настройка может осуществляться вручную, скриптами или с использованием централизованных систем управления конфигурацией (например, Ansible).

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

Показателем эффективности процесса может являться: 
- общий процент соответствия требованиям (суммарно по всем хостам), 
- процент хостов, соответствующих требованиям.

Рекомендации к заполнению карточки:
  • Каждый из этапов процесса (определение требований, первичная настройка, ввод в эксплуатацию новых хостов, контроль соответствия) может быть описан отдельной защитной мерой.
  • Описать принятый в компании перечень требований к безопасности конфигурации.
  • Если для приведения в соответствие и/или контроля конфигураций используется ПО - зарегистрировать его в реестре активов и привязать к мере как инструмент
  • Если ведется учет (реестр) скриптов - привязать использующиеся скрипты как инструмент 
  • Добавить шаблон регулярной задачи по проверке конфигураций.
  • Добавить шаблон регулярной задачи на пересмотр/актуализацию набора требований безопасности