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

Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А

ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022


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

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

ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 9. Требования к защите информации на этапах жизненного цикла автоматизированных систем и приложений":
ЖЦ.9 Контроль (тестирование) полноты реализации мер системы защиты информации АС (функционально-технических требований к системе защиты информации АС)
ЖЦ.13 Контроль (тестирование) полноты реализации мер системы защиты информации АС (функционально-технических требований к системе защиты информации АС) в промышленной среде
CIS Critical Security Controls v8 (The 18 CIS CSC):
4.2 Establish and Maintain a Secure Configuration Process for Network Infrastructure
Establish and maintain a secure configuration process for network devices. Review and update documentation annually, or when significant enterprise changes occur that could impact this Safeguard. 
4.1 Establish and Maintain a Secure Configuration Process 
Establish and maintain a secure configuration process for enterprise assets (end-user devices, including portable and mobile; non-computing/IoT devices; and servers) and software (operating systems and applications). Review and update documentation annually, or when significant enterprise changes occur that could impact this Safeguard 
18.2 Perform Periodic External Penetration Tests
Perform periodic external penetration tests based on program requirements, no less than annually. External penetration testing must include enterprise and environmental reconnaissance to detect exploitable information. Penetration testing requires specialized skills and experience and must be conducted through a qualified party. The testing may be clear box or opaque box. 
12.2 Establish and Maintain a Secure Network Architecture 
Establish and maintain a secure network architecture. A secure network architecture must address segmentation, least privilege, and availability, at a minimum. 
18.5 Perform Periodic Internal Penetration Tests
Perform periodic internal penetration tests based on program requirements, no less than annually. The testing may be clear box or opaque box. 
16.7 Use Standard Hardening Configuration Templates for Application Infrastructure
Use standard, industry-recommended hardening configuration templates for application infrastructure components. This includes underlying servers, databases, and web servers, and applies to cloud containers, Platform as a Service (PaaS) components, and SaaS components. Do not allow in-house developed software to weaken configuration hardening. 
18.1 Establish and Maintain a Penetration Testing Program
Establish and maintain a penetration testing program appropriate to the size, complexity, and maturity of the enterprise. Penetration testing program characteristics include scope, such as network, web application, Application Programming Interface (API), hosted services, and physical premise controls; frequency; limitations, such as acceptable hours, and excluded attack types; point of contact information; remediation, such as how findings will be routed internally; and retrospective requirements. 
NIST Cybersecurity Framework (RU):
DE.DP-2: Деятельность по обнаружению соответствует всем применимым требованиям 
RS.AN-5: Установлены процессы для получения, анализа и реагирования на уязвимости организации обнаруженные с помощью анализа внутренних и внешних источников (например, внутреннее тестирование, бюллетени по безопасности или исследователи безопасности).
ID.RA-1: Идентифицированы и задокументированы уязвимости активов 
PR.IP-12: Разработан и внедрен план управления уязвимостями
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 11.4.1
Defined Approach Requirements: 
A penetration testing methodology is defined, documented, and implemented by the entity, and includes:
  • Industry-accepted penetration testing approaches.
  • Coverage for the entire CDE perimeter and critical systems.
  • Testing from both inside and outside the network.
  • Testing to validate any segmentation and scopereduction controls.
  • Application-layer penetration testing to identify, at a minimum, the vulnerabilities listed in Requirement 6.2.4.
  • Network-layer penetration tests that encompass all components that support network functions as well as operating systems.
  • Review and consideration of threats and vulnerabilities experienced in the last 12 months.
  • Documented approach to assessing and addressing the risk posed by exploitable vulnerabilities and security weaknesses found during penetration testing.
  • Retention of penetration testing results and remediation activities results for at least 12 months. 
Customized Approach Objective:
A formal methodology is defined for thorough technical testing that attempts to exploit vulnerabilities and security weaknesses via simulated attack methods by a competent manual attacker. 

Applicability Notes:
Testing from inside the network (or “internal penetration testing”) means testing from both inside the CDE and into the CDE from trusted and untrusted internal networks. 
Testing from outside the network (or “external penetration testing”) means testing the exposed external perimeter of trusted networks, and critical systems connected to or accessible to public network infrastructures. 

Defined Approach Testing Procedures:
  • 11.4.1 Examine documentation and interview personnel to verify that the penetration-testing methodology defined, documented, and implemented by the entity includes all elements specified in this requirement. 
Attackers spend a lot of time finding external and internal vulnerabilities to leverage to obtain access to cardholder data and then to exfiltrate that data. As such, entities need to test their networks thoroughly, just as an attacker would do. This testing allows the entity to identify and remediate weakness that might be leveraged to compromise the entity’s network and data, and then to take appropriate actions to protect the network and system components from such attacks. 

Good Practice:
Penetration testing techniques will differ based on an organization’s needs and structure and should be suitable for the tested environment—for example, fuzzing, injection, and forgery tests might be appropriate. The type, depth, and complexity of the testing will depend on the specific environment and the needs of the organization. 

Penetration tests simulate a real-world attack situation intending to identify how far an attacker could penetrate an environment, given differing amounts of information provided to the tester. This allows an entity to better understand its potential exposure and develop a strategy to defend against attacks. A penetration test differs from a vulnerability scan, as a penetration test is an active process that usually includes exploiting identified vulnerabilities. 
Scanning for vulnerabilities alone is not a penetration test, nor is a penetration test adequate if the focus is solely on trying to exploit vulnerabilities found in a vulnerability scan. Conducting a vulnerability scan may be one of the first steps, but it is not the only step a penetration tester will perform to plan the testing strategy. Even if a vulnerability scan does not detect known vulnerabilities, the penetration tester will often gain enough knowledge about the system to identify possible security gaps. 
Penetration testing is a highly manual process. While some automated tools may be used, the tester uses their knowledge of systems to gain access into an environment. Often the tester will chain several types of exploits together with the goal of breaking through layers of defenses. For example, if the tester finds a way to gain access to an application server, the tester will then use the compromised server as a point to stage a new attack based on the resources to which the server has access. In this way, a tester can simulate the techniques used by an attacker to identify areas of potential weakness in the environment. The testing of security monitoring and detection methods—for example, to confirm the effectiveness of logging and file integrity monitoring mechanisms, should also be considered. 

Further Information:
Refer to the Information Supplement: Penetration Testing Guidance for additional guidance. 
Industry-accepted penetration testing approaches include: 
  • The Open Source Security Testing Methodology and Manual (OSSTMM) 
  • Open Web Application Security Project (OWASP) penetration testing programs. 
CIS Critical Security Controls v7.1 (SANS Top 20):
CSC 18.11 CSC 18.11 Use Standard Hardening Configuration Templates for Databases
For applications that rely on a database, use standard hardening configuration templates. All systems that are part of critical business processes should also be tested.
CSC 5.1 CSC 5.1 Establish Secure Configurations
Maintain documented security configuration standards for all authorized operating systems and software.
CSC 11.1 CSC 11.1 Maintain Standard Security Configurations for Network Devices
Maintain documented security configuration standards for all authorized network devices.
CSC 20.2 CSC 20.2 Conduct Regular External and Internal Penetration Tests
Conduct regular external and internal penetration tests to identify vulnerabilities and attack vectors that can be used to exploit enterprise systems successfully.
CSC 20.1 CSC 20.1 Establish a Penetration Testing Program
Establish a program for penetration tests that includes a full scope of blended attacks, such as wireless, client-based, and web application attacks.
CSC 5.5 CSC 5.5 Implement Automated Configuration Monitoring Systems
Utilize a Security Content Automation Protocol (SCAP) compliant configuration monitoring system to verify all security configuration elements, catalog approved exceptions, and alert when unauthorized changes occur.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 11.4.1
Определенные Требования к Подходу:
Методология тестирования на проникновение определяется, документируется и внедряется организацией и включает:
  • Общепринятые в отрасли подходы к тестированию на проникновение.
  • Охват всего периметра CDE и критически важных систем.
  • Тестирование как внутри сети, так и за ее пределами.
  • Тестирование для проверки любых элементов управления сегментацией и областью действия.
  • Тестирование на проникновение на уровне приложений для выявления, как минимум, уязвимостей, перечисленных в требовании 6.2.4.
  • Тесты на проникновение на сетевом уровне, которые охватывают все компоненты, поддерживающие сетевые функции, а также операционные системы.
  • Обзор и рассмотрение угроз и уязвимостей, возникших за последние 12 месяцев.
  • Документированный подход к оценке и устранению рисков, связанных с уязвимостями, которые могут быть использованы, и слабостями безопасности, обнаруженными в ходе тестирования на проникновение.
  • Сохранение результатов тестирования на проникновение и результатов мероприятий по исправлению в течение как минимум 12 месяцев.
Цель Индивидуального подхода:
Официальная методология определена для тщательного технического тестирования, которое пытается использовать уязвимости и слабые места в системе безопасности с помощью имитируемых методов атаки компетентным злоумышленником вручную.

Примечания по применению:
Тестирование внутри сети (или “внутреннее тестирование на проникновение”) означает тестирование как внутри CDE, так и в CDE из доверенных и ненадежных внутренних сетей.
Тестирование извне сети (или “внешнее тестирование на проникновение”) означает тестирование открытого внешнего периметра доверенных сетей и критических систем, подключенных к общедоступным сетевым инфраструктурам или доступных для них.

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

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

Тесты на проникновение имитируют реальную ситуацию атаки с целью определения того, как далеко злоумышленник может проникнуть в среду, учитывая различные объемы информации, предоставляемой тестировщику. Это позволяет организации лучше понять свою потенциальную уязвимость и разработать стратегию защиты от атак. Тест на проникновение отличается от сканирования уязвимостей, поскольку тест на проникновение - это активный процесс, который обычно включает в себя использование выявленных уязвимостей.
Сканирование на наличие уязвимостей само по себе не является тестом на проникновение, и тест на проникновение не является адекватным, если основное внимание уделяется исключительно попытке использовать уязвимости, обнаруженные при сканировании уязвимостей. Проведение проверки на уязвимость может быть одним из первых шагов, но это не единственный шаг, который тестировщик проникновения выполнит для планирования стратегии тестирования. Даже если проверка на уязвимость не обнаруживает известных уязвимостей, тестировщик проникновения часто получает достаточно знаний о системе, чтобы выявить возможные пробелы в безопасности.
Тестирование на проникновение - это в высшей степени ручной процесс. Хотя могут использоваться некоторые автоматизированные инструменты, тестировщик использует свои знания о системах для получения доступа к среде. Часто тестировщик связывает несколько типов эксплойтов вместе с целью прорыва через слои защиты. Например, если тестировщик найдет способ получить доступ к серверу приложений, он затем будет использовать скомпрометированный сервер в качестве точки для проведения новой атаки на основе ресурсов, к которым сервер имеет доступ. Таким образом, тестировщик может имитировать методы, используемые злоумышленником для выявления областей потенциальной уязвимости в среде. Следует также рассмотреть возможность тестирования методов мониторинга и обнаружения безопасности — например, для подтверждения эффективности механизмов ведения журнала и контроля целостности файлов.

Дополнительная информация:
Дополнительные указания см. в Информационном дополнении: Руководство по тестированию на проникновение.
Принятые в отрасли подходы к тестированию на проникновение включают:
  • Методология и руководство по тестированию безопасности с открытым исходным кодом (OSSTMM)
  • Программы тестирования на проникновение Open Web Application Security Project (OWASP).
SWIFT Customer Security Controls Framework v2022:
7 - 7.3A Penetration Testing
7.3A Penetration Testing
NIST Cybersecurity Framework (EN):
DE.DP-2 DE.DP-2: Detection activities comply with all applicable requirements
PR.IP-12 PR.IP-12: A vulnerability management plan is developed and implemented
ID.RA-1 ID.RA-1: Asset vulnerabilities are identified and documented
RS.AN-5 RS.AN-5: Processes are established to receive, analyze and respond to vulnerabilities disclosed to the organization from internal and external sources (e.g. internal testing, security bulletins, or security researchers)
Приказ ФСТЭК России № 235 от 21.12.2017 "Требования к созданию систем безопасности значимых объектов критической информационной инфраструктуры Российской Федерации и обеспечению их функционирования":
V п.37
37. В рамках совершенствования безопасности значимых объектов критической информационной инфраструктуры структурное подразделение по безопасности, специалисты по безопасности должны проводить анализ функционирования системы безопасности и состояния безопасности значимых объектов критической информационной инфраструктуры, по результатам которого разрабатывать предложения по развитию системы безопасности и меры по совершенствованию безопасности значимых объектов критической информационной инфраструктуры.
Анализ функционирования системы безопасности, а также разработка предложений по совершенствованию безопасности значимых объектов критической информационной инфраструктуры осуществляются структурным подразделением по безопасности, специалистами по безопасности с участием подразделений (работников), эксплуатирующих значимые объекты критической информационной инфраструктуры, и подразделений (работников), обеспечивающих функционирование значимых объектов критической информационной инфраструктуры.
Предложения по совершенствованию безопасности значимых объектов критической информационной инфраструктуры представляются руководителю субъекта критической информационной инфраструктуры (уполномоченному лицу).
В соответствии с решением руководителя субъекта критической информационной инфраструктуры (уполномоченного лица) предложения по совершенствованию безопасности значимых объектов критической информационной инфраструктуры включаются в план мероприятий, разрабатываемый в соответствии с пунктами 29 - 33 настоящих Требований.
V п.36
36. Контроль проводится ежегодно комиссией, назначаемой субъектом критической информационной инфраструктуры. В состав комиссии включаются работники структурного подразделения по безопасности, специалисты по безопасности, работники подразделений, эксплуатирующих значимые объекты критической информационной инфраструктуры, и подразделений, обеспечивающих функционирование значимых объектов критической информационной инфраструктуры. По решению субъекта критической информационной инфраструктуры в состав комиссии могут включаться работники иных подразделений субъекта критической информационной инфраструктуры.
Для оценки эффективности принятых организационных и технических мер по обеспечению безопасности значимых объектов критической информационной инфраструктуры могут применяться средства контроля (анализа) защищенности.
Результаты контроля оформляются актом, который подписывается членами комиссии и утверждается руководителем субъекта критической информационной инфраструктуры (уполномоченным лицом).
В случае проведения по решению руководителя субъекта критической информационной инфраструктуры внешней оценки (внешнего аудита) состояния безопасности значимых объектов критической информационной инфраструктуры внутренний контроль может не проводиться.
Для проведения внешней оценки привлекаются организации, имеющие лицензии на деятельность в области защиты информации (в части услуг по контролю защищенности информации от несанкционированного доступа и ее модификации в средствах и системах информатизации).
Замечания, выявленные по результатам внутреннего контроля или внешней оценки (внешнего аудита), подлежат устранению в порядке и сроки, установленные руководителем субъекта критической информационной инфраструктуры (уполномоченным лицом).

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

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

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

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

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

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

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

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

Размещение ключевых систем в отдельных безопасных зонах / контурах безопасности и ограничение доступа в эти выделенные сегменты позволяет защитить наиболее критичные системы в случае компрометации основных сегментов сети компании.
В зависимости от особенностей компании в отдельные сегменты выделяют:
  • Технологические, производственные сети
  • Банковские системы
  • Инфраструктуру SWIFT
  • ПК руководства
  • Ключевые бизнес-системы
  • Системы персональных данных
Способы сегментации: 
  • Логический, с помощью технологий VLAN на сетевом оборудовании
  • Логический, на уровне управления виртуальной инфраструктурой
  • Физический, путем создания отдельных ЛВС для ключевых сегментов
Сегментирование предполагает ограничение/контроль доступа между сегментами на базовом уровне. Использование расширенного контроля средствами межсетевого экранирования выделено в отдельную защитную меру.

Рекомендации к заполнению карточки:
  • Указать перечень сегментов и их назначение 
  • Пояснить способы/технологии сегментации
  • Описать как настроено ограничение доступа (ACL)
  • Если сети учитываются в реестре активов - привязать их к карточке в качестве инструментов (тип актива Локальная сеть).
1 28 / 82
Сканирование внешнего сетевого периметра на наличие уязвимостей
Еженедельно Автоматически Техническая Детективная
11.02.2022 1 28 / 82
Цель: управление техническими уязвимостями
Регулярное сканирование всех публичных IP адресов компании сканером уязвимостей. Сканирование проводится из Интернета (из вне инфраструктуры).
Варианты реализации
  1. Купить соответствующую услугу у компании, занимающейся информационной безопасностью
  2. Развернуть собственный экземпляр сканера уязвимостей (или его агент) на внешних, облачных серверах
  3. Купить подписку на облачный сканер уязвимостей
  4. Воспользоваться бесплатными инструментами
    Например: Сканер уязвимостей Qualys Community Edition позволяет проводить регулярное полноценное сканирование ограниченного количества публичных IP адресов
Результаты сканирования могут загружаться в SECURITM (модуль VM) и обрабатываться в рамках процесса управления техническими уязвимостями.

Рекомендации к заполнению карточки:
  • Указать название сканера, область и периодичность сканирования.
  • Сканер (актив) привязать к карточке как инструмент
  • Если ведётся реестр публичных адресов - привязать адреса к карточке как инструмент.
  • Если сканирование запускается вручную - создать в карточке шаблон задачи на проведение регулярного сканирования
3 3 / 48
Приведение конфигурации IP телефонов в соответствие требованиям безопасности
Ежегодно Вручную Техническая Превентивная
29.07.2021 3 3 / 48
Цель: защита IP телефонов от несанкционированного доступа и эксплуатации.

Пример требований безопасности к конфигурации IP телефонов:
  1. Смена пароля для учетной записи администратора
  2. Обновление прошивки IP телефонов до крайней стабильной версии
  3. Отключение неиспользуемых/небезопасных портов/протоколов
    1. HTTP (порт 80)
    2. Telnet (порт 23)
    3. VxWorks debugger (порт 17185) 
  4. Настройка встроенного межсетевого экрана
Отключение портов/протоколов осуществляется или соответствующими пунктами меню (например у Yealink) или через настройку встроенного межсетевого экрана (например у D-Link).

Инструкция к регулярной задаче
  1. Найти в локальной сети все IP телефоны
    Для поиска IP телефонов можно использовать nmap с такими параметрами: nmap -p 5060,5061 --open
  2. Проверить текущие настройки и версию прошивки.
  3. Если требуется - провести настройку в соответствии с установленными требованиями
Рекомендации к заполнению карточки:
  • Описать требования к безопасной конфигурации
  • Добавить в заметки к мере Инструкции по настройке IP телефонов различного типа
  • Добавить шаблон регулярной задачи по проверке и настройке конфигурации IP телефонов;
11 / 52
Проведение тестирования на проникновение
Ежеквартально Вручную Техническая Детективная
02.06.2021 11 / 52
Цель: определение возможностей злоумышленника по компрометации инфраструктуры организации. 

Тестирование на проникновение (пентест, pentest).
Способы проведения: white box, gray box, black box
Области тестирования:
  1. Внешний пентест (тестирование внешнего периметра)
  2. Внутренний пентест (тестирование локальной сети)
  3. Тестирование сетей WiFi
  4. Тестирование методами социальной инженерии
  5. Тестирование web приложений
Пентесты проводятся преимущественно внешними подрядчиками, которых рекомендуется менять на регулярной основе для исключения эффекта замыливания.

Рекомендации к заполнению карточки:
  • Создать шаблон регулярной задачи по проведению тестирования на проникновение (периодичность ежеквартально или ежегодно);
  • В отчете о выполнении задачи приводить краткие результаты тестирования или ссылку на отчет;