Требования делятся на технические и нетехнические. К техническим требованиям относится та информация, которую можно проверить с помощью средств автоматизации (выполнив команду в консоли, парсером по файлу конфигурации, через параметр реестра).
Приведу простой пример технического требования, упоминающегося в большинстве стандартов: PCI DSS 8.5.10 “Require a minimum password length of at least seven characters”, PCI DSS Requirements 5.1. “Deploy anti-virus software on all systems сommonly affected by malicious software (particularly personal computers and servers)”.
Нетехнические требования, соответственно, проверить с помощью средств автоматизации не получится. Пример такого требования — упомянутый выше ИСО/МЭК 2005 A.8.2.3.
Ни один стандарт нельзя полностью описать с помощью одних лишь технических требований. При отсутствии средств автоматизации мы можем их все считать нетехническими. Появляется возможность автоматической проверки требования — оно становится техническим. Чем больше таких требований мы сможем проанализировать (проверить выполнение их в системе), тем оперативнее можно будет снижать риски, устраняя несоответствия.
Необходимо сразу пояснить, что процесс проверки соответствия вообще принято делить на compliance (без префикса standard; имеется в виду соответствие высокоуровневым стандартам по умолчанию), regulatory compliance (требования надзорных органов, к примеру СТО БР ИББС) и policy compliance (соответствие политикам, будь то корпоративная политика или NIST). Все эти термины в рамках данной статьи мы будем понимать как «проверку на соответствие стандартам (политикам)».