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

CIS Critical Security Controls v8 (The 18 CIS CSC)

Framework

16.3

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

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

Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 6.3.1
6.3.1
Defined Approach Requirements: 
Security vulnerabilities are identified and managed as follows:
  • New security vulnerabilities are identified using industry-recognized sources for security vulnerability information, including alerts from international and national computer emergency response teams (CERTs). 
  • Vulnerabilities are assigned a risk ranking based on industry best practices and consideration of potential impact. 
  • Risk rankings identify, at a minimum, all vulnerabilities considered to be a high-risk or critical to the environment.
  •  Vulnerabilities for bespoke and custom, and third-party software (for example operating systems and databases) are covered. 
Customized Approach Objective:
New system and software vulnerabilities that may impact the security of account data or the CDE are monitored, cataloged, and risk assessed. 

Applicability Notes:
This requirement is not achieved by, nor is it the same as, vulnerability scans performed for Requirements 11.3.1 and 11.3.2. This requirement is for a process to actively monitor industry sources for vulnerability information and for the entity to determine the risk ranking to be associated with each vulnerability. 

Defined Approach Testing Procedures:
  •  6.3.1.a Examine policies and procedures for identifying and managing security vulnerabilities to verify that processes are defined in accordance with all elements specified in this requirement. 
  • 6.3.1.b Interview responsible personnel, examine documentation, and observe processes to verify that security vulnerabilities are identified and managed in accordance with all elements specified in this requirement. 
Purpose:
Classifying the risks (for example, as critical, high, medium, or low) allows organizations to identify, prioritize, and address the highest risk items more quickly and reduce the likelihood that vulnerabilities posing the greatest risk will be exploited 

Good Practice:
Methods for evaluating vulnerabilities and assigning risk ratings will vary based on an organization’s environment and risk-assessment strategy. 
When an entity is assigning its risk rankings, it should consider using a formal, objective, justifiable methodology that accurately portrays the risks of the vulnerabilities pertinent to the organization and translates to an appropriate entity-assigned priority for resolution. 
An organization’s processes for managing vulnerabilities should be integrated with other management processes—for example, risk management, change management, patch management, incident response, application security, as well as proper monitoring and logging of these processes. This will help to ensure all vulnerabilities are properly identified and addressed. Processes should support ongoing evaluation of vulnerabilities. For example, a vulnerability initially identified as low risk could become a higher risk later. Additionally, vulnerabilities, individually considered to be low or medium risk, could collectively pose a high or critical risk if present on the same system, or if exploited on a low-risk system that could result in access to the CDE. 

Examples:
Some organizations that issue alerts to advise entities about urgent vulnerabilities requiring immediate patches/updates are national Computer Emergency Readiness/Response Teams (CERTs) and vendors. 
Criteria for ranking vulnerabilities may include criticality of a vulnerability identified in an alert from Forum of Incident Response and Security Teams (FIRST) or a CERT, consideration of the CVSS score, the classification by the vendor, and/or type of systems affected. 

Further Information:
Trustworthy sources for vulnerability information include vendor websites, industry newsgroups, mailing lists, etc. If software is developed inhouse, the internal development team should also consider sources of information about new vulnerabilities that may affect internally developed applications. Other methods to ensure new vulnerabilities are identified include solutions that automatically recognize and alert upon detection of unusual behavior. Processes should account for widely published exploits as well as “zero-day” attacks, which target previously unknown vulnerabilities. 
For bespoke and custom software, the organization may obtain information about libraries, frameworks, compilers, programming languages, etc. from public trusted sources (for example, special resources and resources from component developers). The organization may also independently analyze third-party components and identify vulnerabilities. 
For control over in-house developed software, the organization may receive such information from external sources. The organization can consider using a “bug bounty” program where it posts information (for example, on its website) so third parties can contact the organization with vulnerability information. External sources may include independent investigators or companies that report to the organization about identified vulnerabilities and may include sources such as the Common Vulnerability Scoring System (CVSS) or the OWASP Risk Rating Methodology 
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.14.2.1
A.14.2.1 Политика безопасной разработки 
Мера обеспечения информационной безопасности: Правила разработки программного обеспечения и систем должны быть установлены и применены к разработкам в рамках организации 
CIS Critical Security Controls v7.1 (SANS Top 20):
CSC 18.6 CSC 18.6 Ensure Software Development Personnel are Trained in Secure Coding
Ensure that all software development personnel receive training in writing secure code for their specific development environment and responsibilities.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 6.3.1
6.3.1
Определенные Требования к Подходу:
Уязвимости в системе безопасности выявляются и устраняются следующим образом:
  • Новые уязвимости в системе безопасности выявляются с использованием признанных в отрасли источников информации об уязвимостях системы безопасности, включая оповещения от международных и национальных групп реагирования на компьютерные чрезвычайные ситуации (CERT).
  • Уязвимостям присваивается рейтинг рисков на основе лучших отраслевых практик и учета потенциального воздействия.
  • Рейтинги рисков определяют, как минимум, все уязвимости, которые считаются высокорискованными или критичными для окружающей среды.
  • Рассматриваются уязвимости для индивидуального и пользовательского программного обеспечения, а также программного обеспечения сторонних производителей (например, операционных систем и баз данных).
Цель Индивидуального подхода:
Новые системные и программные уязвимости, которые могут повлиять на безопасность данных учетной записи или CDE, отслеживаются, каталогизируются и оцениваются риски.

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

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

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

Примеры:
Некоторые организации, которые выпускают предупреждения для информирования организаций о срочных уязвимостях, требующих немедленных исправлений/обновлений, - это национальные группы компьютерной готовности к чрезвычайным ситуациям/ реагирования (сертификаты) и поставщики.
Критерии ранжирования уязвимостей могут включать критичность уязвимости, выявленной в предупреждении от Форума Групп реагирования на инциденты и безопасности (FIRST) или сертификата, рассмотрение оценки CVSS, классификацию поставщиком и/или тип затронутых систем.

Дополнительная информация:
Надежные источники информации об уязвимостях включают веб-сайты поставщиков, отраслевые группы новостей, списки рассылки и т.д. Если программное обеспечение разрабатывается собственными силами, внутренняя команда разработчиков должна также рассмотреть источники информации о новых уязвимостях, которые могут повлиять на приложения, разработанные внутри компании. Другие методы обеспечения выявления новых уязвимостей включают решения, которые автоматически распознают и предупреждают об обнаружении необычного поведения. Процессы должны учитывать широко опубликованные эксплойты, а также атаки “нулевого дня”, нацеленные на ранее неизвестные уязвимости.
Для программного обеспечения, изготовленного на заказ и изготовленного на заказ, организация может получать информацию о библиотеках, фреймворках, компиляторах, языках программирования и т.д. из общедоступных надежных источников (например, специальных ресурсов и ресурсов от разработчиков компонентов). Организация также может самостоятельно анализировать сторонние компоненты и выявлять уязвимости.
Для контроля над программным обеспечением, разработанным собственными силами, организация может получать такую информацию из внешних источников. Организация может рассмотреть возможность использования программы “вознаграждение за ошибки”, в рамках которой она размещает информацию (например, на своем веб-сайте), чтобы третьи стороны могли связаться с организацией с информацией об уязвимостях. Внешние источники могут включать независимых исследователей или компании, которые сообщают организации о выявленных уязвимостях, и могут включать такие источники, как Общая система оценки уязвимостей (CVSS) или Методология оценки рисков OWASP
ГОСТ Р № ИСО/МЭК 27002-2021 от 30.11.2021 "Информационные технологии. Методы и средства обеспечения безопасности. Свод норм и правил применения мер обеспечения информационной безопасности":
14.2.1
14.2.1 Политика безопасной разработки

Мера обеспечения ИБ
Правила разработки программного обеспечения и систем должны быть установлены и применены к разработкам в рамках организации.

Руководство по применению
Безопасная разработка - это требование для создания безопасного сервиса, архитектуры, программного обеспечения и системы. В рамках политики безопасной разработки должны быть учтены следующие аспекты:
  • a) безопасность среды разработки;
  • b) руководство по безопасности в жизненном цикле разработки программного обеспечения:
  1. безопасность в методологии разработки программного обеспечения;
  2. правила по безопасному программированию для каждого используемого языка программирования;
  • c) требования безопасности на этапе проектирования;
  • d) контрольные точки по проверке безопасности в рамках основных этапов проекта;
  • e) безопасные репозитории;
  • f) безопасность в управлении версиями;
  • g) необходимые знания по безопасности приложений;
  • h) способность разработчиков избегать, находить и исправлять уязвимости.
Методы безопасного программирования должны применяться как в отношении новых разработок, так и в случае повторного использования кода, при разработке которого использованы неизвестные стандарты или использованные стандарты не соответствуют лучшим практикам. Следует рассмотреть и, в случае необходимости, сделать обязательными для применения стандарты безопасного программирования. Разработчики должны быть обучены применению этих стандартов и тестированию, а анализ кода должен служить проверкой их использования.
Если разработка осуществляется на аутсорсинге, организация должна получить гарантии того, что внешняя сторона соблюдает правила по безопасной разработке (см. 14.2.7).

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

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

Ничего не найдено

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