Куда я попал?
CIS Critical Security Controls v7.1 (SANS Top 20)
Framework
CSC 4.2
Для проведения оценки соответствия по документу войдите в систему.
Список требований
-
CSC 4.2 Change Default Passwords
Before deploying any new asset, change all default passwords to have values consistent with administrative level accounts.Обязательно для implementation Group 1 2 3
Похожие требования
CIS Critical Security Controls v8 (The 18 CIS CSC):
4.7
4.7 Manage Default Accounts on Enterprise Assets and Software
Manage default accounts on enterprise assets and software, such as root, administrator, and other pre-configured vendor accounts. Example implementations can include: disabling default accounts or making them unusable.
Manage default accounts on enterprise assets and software, such as root, administrator, and other pre-configured vendor accounts. Example implementations can include: disabling default accounts or making them unusable.
Russian Unified Cyber Security Framework (на основе The 18 CIS CSC):
4.7
4.7 Реализовано управление учетными записями по умолчанию на устройствах и в программном обеспечении
Пересмотрены и обновлены настройки всех предварительно настроенных учетных записей, например, root, administrator и так далее.
Пересмотрены и обновлены настройки всех предварительно настроенных учетных записей, например, root, administrator и так далее.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 8.3.5
8.3.5
Defined Approach Requirements:
If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they are set and reset for each user as follows:
Defined Approach Requirements:
If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they are set and reset for each user as follows:
- Set to a unique value for first-time use and upon reset.
- Forced to be changed immediately after the first use.
Customized Approach Objective:
An initial or reset password/passphrase assigned to a user cannot be used by an unauthorized user.
Defined Approach Testing Procedures:
An initial or reset password/passphrase assigned to a user cannot be used by an unauthorized user.
Defined Approach Testing Procedures:
- 8.3.5 Examine procedures for setting and resetting passwords/passphrases (if used as authentication factors to meet Requirement 8.3.1) and observe security personnel to verify that passwords/passphrases are set and reset in accordance with all elements specified in this requirement.
Purpose:
If the same password/passphrase is used for every new user, an internal user, former employee, or malicious individual may know or easily discover the value and use it to gain access to accounts before the authorized user attempts to use the password.
If the same password/passphrase is used for every new user, an internal user, former employee, or malicious individual may know or easily discover the value and use it to gain access to accounts before the authorized user attempts to use the password.
Guideline for a healthy information system v.2.0 (EN):
10 STANDARD
/STANDARD
ANSSI sets out a collection of rules and best practices in terms of the choice and size of passwords. The most critical one is to make users aware of the risks involved in choosing a password that is too easy to guess, and even the risks of reusing the same password from one application to another, especially for personal and professional mailboxes.
To supervise and confirm that these choice and size rules are being applied, the organization may use different measures, including:
ANSSI sets out a collection of rules and best practices in terms of the choice and size of passwords. The most critical one is to make users aware of the risks involved in choosing a password that is too easy to guess, and even the risks of reusing the same password from one application to another, especially for personal and professional mailboxes.
To supervise and confirm that these choice and size rules are being applied, the organization may use different measures, including:
- blocking accounts following several failed logins;
- deactivating anonymous login options;
- using a password robustness checking tool.
In advance of such procedures, communication aiming to explain the reason for these rules and raise awareness of their importance is fundamental.
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.9.4.2
A.9.4.2 Безопасные процедуры входа в систему
Мера обеспечения информационной безопасности: Когда этого требует политика управления доступом, доступ к системам и приложениям должен управляться посредством безопасной процедуры входа в систему
Мера обеспечения информационной безопасности: Когда этого требует политика управления доступом, доступ к системам и приложениям должен управляться посредством безопасной процедуры входа в систему
A.9.1.1
А.9.1.1 Политика управления доступом
Мера обеспечения информационной безопасности: Политика управления доступом должна быть разработана, документирована и должна пересматриваться с учетом требований бизнеса и информационной безопасности
Мера обеспечения информационной безопасности: Политика управления доступом должна быть разработана, документирована и должна пересматриваться с учетом требований бизнеса и информационной безопасности
A.9.2.2
A.9.2.2 Предоставление пользователю права доступа
Мера обеспечения информационной безопасности: Должен быть реализован формализованный процесс назначения или отмены прав доступа пользователей к системам и сервисам
Мера обеспечения информационной безопасности: Должен быть реализован формализованный процесс назначения или отмены прав доступа пользователей к системам и сервисам
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 8.3.5
8.3.5
Определенные Требования к Подходу:
Если пароли/парольные фразы используются в качестве факторов аутентификации в соответствии с требованием 8.3.1, они устанавливаются и сбрасываются для каждого пользователя следующим образом:
Определенные Требования к Подходу:
Если пароли/парольные фразы используются в качестве факторов аутентификации в соответствии с требованием 8.3.1, они устанавливаются и сбрасываются для каждого пользователя следующим образом:
- Устанавливается на уникальное значение при первом использовании и при сбросе.
- Принудительно заменяется сразу после первого использования.
Цель Индивидуального подхода:
Первоначальный или сброшенный пароль/кодовая фраза, назначенные пользователю, не могут быть использованы неавторизованным пользователем.
Определенные Процедуры Тестирования Подхода:
Первоначальный или сброшенный пароль/кодовая фраза, назначенные пользователю, не могут быть использованы неавторизованным пользователем.
Определенные Процедуры Тестирования Подхода:
- 8.3.5 Изучите процедуры установки и сброса паролей/парольных фраз (если они используются в качестве факторов аутентификации в соответствии с требованием 8.3.1) и понаблюдайте за персоналом службы безопасности, чтобы убедиться, что пароли/парольные фразы установлены и сброшены в соответствии со всеми элементами, указанными в этом требовании.
Цель:
Если один и тот же пароль / кодовая фраза используется для каждого нового пользователя, внутренний пользователь, бывший сотрудник или злоумышленник могут знать или легко обнаружить значение и использовать его для получения доступа к учетным записям до того, как авторизованный пользователь попытается использовать пароль.
Если один и тот же пароль / кодовая фраза используется для каждого нового пользователя, внутренний пользователь, бывший сотрудник или злоумышленник могут знать или легко обнаружить значение и использовать его для получения доступа к учетным записям до того, как авторизованный пользователь попытается использовать пароль.
Strategies to Mitigate Cyber Security Incidents (EN):
2.6.
Protect authentication credentials. Remove CPassword values (MS14-025). Configure WDigest (KB2871997). Use Windows Defender Credential Guard. Change default passphrases. Require long complex passphrases.
Relative Security Effectiveness: Excellent | Potential User Resistance: Medium | Upfront Cost: Medium | Ongoing Maintenance Cost: Low
Relative Security Effectiveness: Excellent | Potential User Resistance: Medium | Upfront Cost: Medium | Ongoing Maintenance Cost: Low
ГОСТ Р № ИСО/МЭК 27002-2021 от 30.11.2021 "Информационные технологии. Методы и средства обеспечения безопасности. Свод норм и правил применения мер обеспечения информационной безопасности":
9.2.2
9.2.2 Предоставление пользователю права доступа
Мера обеспечения ИБ
Должен быть реализован формализованный процесс назначения или отмены прав доступа пользователей к системам и сервисам.
Руководство по применению
Процесс предоставления доступа для назначения или аннулирования прав доступа для идентификаторов пользователей должен включать в себя:
- a) получение разрешения от владельца информационной системы или сервиса на использование этой информационной системы или сервиса (см. 8.1.2); также может быть целесообразным разделение подтверждения прав доступа от управления;
- b) проверку того, что предоставляемый уровень доступа соответствует политикам доступа (см. 9.1) и согласуется с другими требованиями, такими как разделение обязанностей (см. 6.1.2);
- c) обеспечение того, что права доступа не будут активированы (например, поставщиками услуг) до завершения процедур аутентификации;
- d) ведение централизованной регистрации прав доступа, связываемых с идентификатором пользователя, к информационным системам и сервисам;
- e) корректировку прав доступа пользователей, у которых поменялись роли или задачи, а также немедленное удаление или блокирование прав доступа пользователей, покинувших организацию;
- f) периодический пересмотр права доступа совместно с владельцами информационных систем или сервисов (см. 9.2.5).
Дополнительная информация
Следует рассмотреть вопрос о создании ролей пользователей, которые вытекают из требований бизнеса и определяют права доступа для пользователей, объединяя ряд прав доступа в типовые профили доступа пользователей. Запросы на доступ и пересмотр прав доступа (см. 9.2.4) легче обрабатывать на уровне таких ролей, чем на уровне отдельных прав.
Следует рассмотреть вопрос включения в контракты с работниками и подрядчиками положений, предусматривающих санкции в случае совершения работником или подрядчиком попыток несанкционированного доступа (см. 7.1.2, 7.2.3, 13.2.4; 15.1.2).
9.4.2
9.4.2 Безопасные процедуры входа в систему
Мера обеспечения ИБ
Когда этого требует политика управления доступом, доступ к системам и приложениям должен управляться посредством безопасной процедуры входа в систему.
Руководство по применению
Должны быть выбраны подходящие методы аутентификации для подтверждения заявленной личности пользователя.
Там, где требуется строгая аутентификация и проверка личности, должны использоваться методы аутентификации, альтернативные паролям, такие как криптографические средства, смарт-карты, токены или биометрические средства.
Процедура входа в систему или приложение должна быть разработана таким образом, чтобы минимизировать возможность несанкционированного доступа. Таким образом, процедура входа в систему должна раскрывать минимум информации о системе или приложении, во избежание оказания какой-либо неумышленной помощи неавторизованному пользователю. Разработанная надлежащим образом процедура входа должна:
- a) не отображать идентификаторы системы или приложения до тех пор, пока процесс входа успешно не завершен;
- b) выводить общее предупреждение, что доступ к компьютеру предоставляется только авторизованным пользователям;
- c) не предоставлять подсказок во время процедуры входа, которые могли бы помочь неавторизованному пользователю;
- d) осуществлять подтверждение информации для входа только после завершения ввода всех данных. Если возникает ошибка, система не должна указывать, какая часть данных для входа является правильной или неправильной;
- e) защищать от попыток входа в систему методом полного перебора (грубой силы);
- f) регистрировать неуспешные и успешные попытки входа;
- g) фиксировать событие безопасности при обнаружении попыток или фактов успешного нарушения процедуры входа;
- h) отображать следующую информацию по завершении успешного входа в систему:
- - дата и время предыдущего успешного входа;
- - сведения всех неудачных попыток входа с момента последнего успешного входа;
- i) не отображать вводимый пароль;
- j) не передавать пароли в открытом виде по сети;
- k) завершать неактивные сессии после определенного периода бездействия, особенно в местах повышенного риска, таких как общественные места или точки за пределами организации, которые не попадают под контроль системы менеджмента информационной безопасности организации, или на мобильных устройствах;
- l) ограничивать время соединения для обеспечения дополнительной защиты приложений с высоким риском и снижения возможности несанкционированного доступа.
Дополнительная информация
Пароли являются наиболее распространенным способом обеспечения идентификации и аутентификации на основе использования секрета, который знает только пользователь. То же самое может быть достигнуто при использовании криптографических средств и протоколов аутентификации. Надежность аутентификации пользователя должна соответствовать категории информации, к которой осуществляется доступ.
Если пароли передаются по сети в открытом виде во время процедуры входа, они могут быть перехвачены программой анализа сетевого трафика.
9.1.1
9.1.1 Политика управления доступом
Мера обеспечения ИБ
Политика управления доступом должна быть разработана, документирована и периодически пересматриваться с учетом требований бизнеса и ИБ.
Руководство по применению
Владельцы активов должны определить соответствующие правила управления доступом, права доступа и ограничения для конкретных пользовательских ролей по отношению к своим активам с уровнем детализации и строгостью мер, отражающих риски, связанные с обеспечением ИБ.
Меры по управлению доступом могут быть как логическими, так и физическими (раздел 11), и должны рассматриваться совместно. Пользователи и поставщики услуг должны получить четкое представление о требованиях бизнеса, которым должны удовлетворять меры управления доступом.
Политика должна учитывать следующее:
- a) требования безопасности бизнес-приложений;
- b) политики распространения информации и авторизации, например принцип "необходимого знания", уровни ИБ и категорирование информации (см. 8.2);
- c) соответствие между правами доступа и политиками категорирования информации для систем и сетей;
- d) соответствующие законодательные и любые договорные обязательства, касающиеся ограничения доступа к данным или сервисам (см. 18.1);
- e) управление правами доступа в распределенных средах и сетях, которые допускают все типы соединений;
- f) разделение ролей по управлению доступом, например запрос доступа, авторизация доступа, администрирование доступа;
- g) требования к формальной авторизации запросов доступа (см. 9.2.1 и 9.2.2);
- h) требования к периодическому пересмотру прав доступа (см. 9.2.6);
- i) аннулирование прав доступа (см. 9.2.6);
- j) архивирование записей всех значимых событий, касающихся использования и управления идентификаторами пользователей и секретной аутентификационной информацией;
- k) роли с привилегированным доступом (см. 9.2.3).
Дополнительная информация
Следует уделять особое внимание установлению правил управления доступом и учитывать следующее:
- a) установление правил, основанных на утверждении "Все в общем случае запрещено, пока явно не разрешено", а не на более слабом принципе "Все в общем случае разрешено, пока явно не запрещено";
- b) изменения маркировки информации (см. 8.2.2), которые инициируются автоматически средствами обработки информации и которые инициируются пользователями;
- c) изменения в правах пользователей, которые инициируются автоматически информационной системой, и те, которые инициируются администратором;
- d) правила, которые требуют определенной процедуры утверждения до вступления в силу, и те, которые этого не требуют.
Правила управления доступом должны быть зафиксированы в формальных процедурах (см. 9.2, 9.3, 9.4), и под них определены обязанности (см. 6.1, 9.3).
Управление доступом на основе ролей - это подход, успешно используемый многими организациями для связи прав доступа с бизнес-ролями.
Есть два часто применяемых принципа, определяющих политику управления доступом:
- e) принцип "необходимого знания": вам предоставляется доступ только к той информации, которая вам необходима для выполнения ваших задач (различные задачи/роли подразумевают различные "необходимые знания" и следовательно различные профили доступа);
- f) принцип "необходимого использования": вам предоставляется доступ только к тем средствам обработки информации (ИТ-оборудование, приложения, процедуры, помещения), которые необходимы для выполнения задачи/работы/роли.
Связанные защитные меры
Ничего не найдено
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.