CIS Critical Security Controls v8 (The 18 CIS CSC)

6.3.1
Defined Approach Requirements: 
Security vulnerabilities are identified and managed as follows:

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:

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 

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

6.3.1
Определенные Требования к Подходу:
Уязвимости в системе безопасности выявляются и устраняются следующим образом:

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

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

Определенные Процедуры Тестирования Подхода:

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

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

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

Дополнительная информация:
Надежные источники информации об уязвимостях включают веб-сайты поставщиков, отраслевые группы новостей, списки рассылки и т.д. Если программное обеспечение разрабатывается собственными силами, внутренняя команда разработчиков должна также рассмотреть источники информации о новых уязвимостях, которые могут повлиять на приложения, разработанные внутри компании. Другие методы обеспечения выявления новых уязвимостей включают решения, которые автоматически распознают и предупреждают об обнаружении необычного поведения. Процессы должны учитывать широко опубликованные эксплойты, а также атаки “нулевого дня”, нацеленные на ранее неизвестные уязвимости.
Для программного обеспечения, изготовленного на заказ и изготовленного на заказ, организация может получать информацию о библиотеках, фреймворках, компиляторах, языках программирования и т.д. из общедоступных надежных источников (например, специальных ресурсов и ресурсов от разработчиков компонентов). Организация также может самостоятельно анализировать сторонние компоненты и выявлять уязвимости.
Для контроля над программным обеспечением, разработанным собственными силами, организация может получать такую информацию из внешних источников. Организация может рассмотреть возможность использования программы “вознаграждение за ошибки”, в рамках которой она размещает информацию (например, на своем веб-сайте), чтобы третьи стороны могли связаться с организацией с информацией об уязвимостях. Внешние источники могут включать независимых исследователей или компании, которые сообщают организации о выявленных уязвимостях, и могут включать такие источники, как Общая система оценки уязвимостей (CVSS) или Методология оценки рисков OWASP