18.11.2021
Специальная публикация NIST (Национального института стандартов и технологий США) 800-12 «Введение в информационную безопасность» (часть 7)

7 Достоверность

Информационная достоверность - это степень уверенности в том, что меры безопасности защищают информацию и системы, обеспечивая их доступность, целостность, аутентификацию, конфиденциальность и невозможность отказа от авторства. Эти меры включают обеспечение восстановления систем за счет включения возможностей защиты, обнаружения и реагирования.

Однако достоверность не является абсолютной гарантией того, что меры будут работать так, как задумано. Понимание этого различия имеет решающее значение, поскольку количественная оценка безопасности системы может быть сложной.

Тем не менее, это то, чего люди ожидают и получают, часто даже не осознавая этого. Например, человек может регулярно получать рекомендации по продукту от коллег, но не может рассматривать такие рекомендации как обеспечение уверенности.

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

Разделение между двумя категориями иногда может быть неоднозначным, поскольку имеется значительное совпадение. Хотя такие вопросы, как управление конфигурацией или аудиты, обсуждаются в рамках эксплуатационного обеспечения, они также могут иметь жизненно важное значение во время разработки системы. Обсуждение имеет тенденцию больше сосредотачиваться на технических вопросах во время проектирования и обеспечения реализации и представляет собой смесь управленческих, эксплуатационных и технических вопросов в рамках обеспечения эксплуатационного контроля.

7.1 Авторизация

Авторизация - это официальное решение руководства разрешить работу системы. Уполномоченное должностное лицо (высшее должностное лицо организации) прямо принимает на себя риск эксплуатации системы для операций организации (например, миссии, функций, имиджа, репутации), активов организации, отдельных лиц, других организаций и нации на основе выполнения согласованного -на набор мер безопасности и конфиденциальности. Между уполномоченным должностным лицом и SAOP необходимы отношения сотрудничества.

OMB A-130 дает SAOPs обзор и утверждение планов конфиденциальности до авторизации, а также обзор пакетов авторизации для систем с PII. Поэтому перед принятием решения об определении риска и принятии решения уполномоченное должностное лицо связывается с SAOP для решения любых проблем, связанных с конфиденциальностью, до принятия окончательного решения об авторизации. Процесс авторизации требует, чтобы менеджеры и технический персонал работали вместе, чтобы найти практические и экономически эффективные решения с учетом потребностей безопасности, технических и эксплуатационных ограничений, требований других атрибутов качества системы, таких как конфиденциальность, а также требований миссии или бизнеса.

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

Это включает:

• Технические характеристики (работают ли они по назначению?);

• Операционные политики и методы (работает ли система в соответствии с установленными политиками и практики?);

• Общая безопасность (есть ли угрозы, которые не устраняются с помощью мер защиты?); а также

• Остаточный риск (находится ли остаточный риск на приемлемом уровне?)

Уполномоченное должностное лицо несет ответственность за авторизацию системы до того, как она будет разрешена к работе, и за наличие плана постоянного мониторинга этой системы.

7.1.1 Авторизация и достоверность

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

Официальное лицо, выдающее разрешение, принимает окончательное решение о том, сколько и какие гарантии необходимы для системы. Чтобы принять обоснованное решение, уполномоченное должностное лицо рассматривает категоризацию системы/уровень воздействия и анализирует результаты оценки рисков. Официальное лицо, выдающее разрешение, анализирует преимущества и недостатки стоимости гарантии, стоимости контроля и риски для организации. После завершения процесса авторизации уполномоченное должностное лицо несет ответственность за принятие остаточного риска в системе.

7.1.2 Авторизация продукции на использование в аналогичной ситуации

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

7.2 Инженерия безопасности

Размер и сложность современных систем делают создание надежной системы приоритетной задачей. Разработка системной безопасности обеспечивает элементарный подход к созданию надежных систем в современной сложной вычислительной среде. Для получения дополнительной информации о проектировании безопасности обратитесь к NIST SP 800-160.

7.2.1 Планирование и достоверность

Для новых систем или для обновлений системы требования доверия начинаются на этапе планирования жизненного цикла системы. Планирование гарантий как часть системных требований также практично и помогает уполномоченным должностным лицам принимать рентабельные решения при построении системы или при покупке компонентов/оборудования, необходимых для обеспечения гарантий для более старой системы.

7.2.2 Обеспечение проектирования и реализации

Гарантия проектирования и реализации касается структуры системы, а также того, соответствуют ли функции системы, приложения или компонента требованиям и спецификациям безопасности.

Гарантия проектирования и реализации изучает проектирование, разработку и установку системы и обычно связано с фазой разработки / приобретения и реализации жизненного цикла системы. Однако его также можно рассматривать на протяжении всего жизненного цикла по мере модификации системы.

7.2.2.1 Использование расширенных или доверенных разработок

При разработке как готовых коммерческих (COTS) продуктов, так и специализированных систем использование передовых или надежных системных архитектур, методологий разработки или программного обеспечения.

инженерные методы могут обеспечить уверенность. Примеры включают анализ безопасности проектирования и разработки, формальное моделирование, математические доказательства, методы качества ISO 9000, ISO 15288 (стандарт проектирования систем безопасности) или использование концепций архитектуры безопасности, таких как доверенная вычислительная база (TCB).

Поскольку уверенность в продуктах информационных технологий не может быть полностью гарантирована, существуют признанные процессы оценки, позволяющие установить уровень уверенности в том, что функции безопасности этих продуктов ИТ и меры обеспечения безопасности, применяемые к этим продуктам ИТ, соответствуют определенным требованиям. 

Общие критерии (CC) позволяют сравнивать результаты между независимыми оценками. CC полезен в качестве руководства для разработки, оценки и приобретения ИТ-продуктов с функциями безопасности. Для получения дополнительной информации о CC см. http://www.commoncriteriaportal.org или https://buildsecurityin.us-cert.gov/articles/bestpractices/requirements-engineering/the-common-criteria.

7.2.2.2 Использование надежной архитектуры

Некоторые системные архитектуры по своей сути более надежны, например системы, в которых используются функции отказоустойчивости, избыточности, теневого копирования или избыточного массива независимых дисков (RAID). Эти примеры в первую очередь связаны с доступностью системы.

7.2.2.3 Использование надежной защиты

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

7.2.2.4 Оценки

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

7.2.2.5 Документация по обеспечению достоверности

Способность описывать требования безопасности и то, как они были выполнены, может отражать степень, в которой разработчик системы или продукта понимает применимые проблемы безопасности. Без всестороннего понимания требований дизайнер вряд ли сможет их удовлетворить.

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

7.2.2.6 Гарантии, заявления о добросовестности и обязательства

Гарантии - это дополнительный источник уверенности. Производитель, системный разработчик или интегратор, который желает исправить ошибки в определенные сроки или к следующему выпуску, дает системному менеджеру чувство приверженности продукту, а также говорит о качестве продукта. Заявление о целостности - это официальная декларация или сертификация продукта. Его можно дополнить обещанием (а) отремонтировать товар (т. е. гарантию) или (б) оплатить убытки (т. е. ответственность), если продукт не соответствует заявлению о целостности.

7.2.2.7 Опубликованные утверждения производителя

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

7.2.2.8 Гарантия распространения

Часто важно знать, что программное обеспечение прибыло в неизмененном виде, особенно если оно распространяется в электронном виде. В таких случаях проверочные биты или цифровые подписи могут обеспечить высокую уверенность в том, что код не был изменен. Антивирусное программное обеспечение можно использовать для проверки программного обеспечения, которое поступает из источников с неизвестной надежностью (например, интернет-форумы).

7.3 Операционное обеспечение

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

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

Организации используют три основных метода для обеспечения операционной уверенности:

• Системная оценка. Событие или непрерывный процесс оценки безопасности. Оценка может широко варьироваться по объему: она может исследовать всю систему с целью авторизации или может исследовать единичное аномальное событие;

• Системный аудит. Независимый обзор и проверка записей и действий для оценки адекватности системного контроля и обеспечения соответствия установленным политикам и операционным процедурам; а также

• Системный мониторинг. Процесс поддержания постоянной осведомленности об информационной безопасности, уязвимостях и угрозах для поддержки решений по управлению рисками организации.

В целом, чем больше активность «в реальном времени», тем больше она попадает в категорию мониторинга. Это различие может привести к ненужным языковым раздражениям, особенно в отношении журналов аудита, генерируемых системой. Ежедневный или еженедельный просмотр журнала аудита на предмет попыток несанкционированного доступа обычно считается мониторингом, тогда как исторический обзор журнала за несколько месяцев (например, отслеживание действий конкретного пользователя) обычно считается аудитом.

Однако конкретные термины, применяемые к деятельности, связанной с доверием, гораздо менее важны, чем реальная работа по поддержанию операционного доверия.

7.3.1 Оценка контроля безопасности и конфиденциальности

Оценки могут касаться качества системы в том виде, в котором она построена, внедрена или эксплуатируется. Оценки могут выполняться на протяжении всего цикла разработки, после установки системы и на протяжении всего этапа ее эксплуатации. Методы оценки включают собеседования, экзамены и тестирование. Некоторые распространенные методы тестирования включают функциональное тестирование (чтобы убедиться, что данная функция работает в соответствии с его требованиями) или тестирование на проникновение (чтобы увидеть, можно ли обойти безопасность).

Эти методы могут варьироваться от опробования нескольких тестовых примеров до углубленных исследований с использованием показателей, автоматизированных инструментов или нескольких подробных тестовых примеров. См. Руководство по оценке в NIST SP 800-53A.

7.3.2 Методы и инструменты аудита

Аудит, проводимый для обеспечения эксплуатационной уверенности, проверяет, соответствует ли система заявленным или подразумеваемым требованиям безопасности, а также политикам системы и организации. Некоторые аудиты также проверяют, соответствуют ли требования безопасности, хотя это выходит за рамки оперативного обеспечения. Менее формальные аудиты часто называют проверками безопасности.

Аудиты могут быть самостоятельными или независимыми, то есть они могут проводиться внутренними или внешними организациями. Оба типа могут предоставить отличную информацию о технических, процедурных, управленческих и других аспектах безопасности. Существенное различие между самостоятельным аудитом и независимым аудитом - объективность. 

Проверки, проводимые персоналом управления системой, часто называемые самоаудитами/оценками, представляют собой неотъемлемый конфликт интересов. У сотрудников управления системой может быть мало стимулов сообщать, что система была плохо спроектирована или эксплуатируется небрежно. С другой стороны, они могут быть мотивированы сильным желанием улучшить безопасность своей системы. Кроме того, они хорошо осведомлены о системе и могут находить скрытые проблемы.

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

Существует множество методов и инструментов, которые можно использовать для аудита, некоторые из которых описаны здесь.

7.3.2.1 Автоматизированные инструменты

Даже в небольших многопользовательских системах проверка функций безопасности вручную может потребовать значительных ресурсов. Автоматизированные инструменты позволяют проверять даже большие системы на наличие различных недостатков безопасности.

Есть два типа автоматизированных инструментов: (1) активные инструменты, которые находят уязвимости, пытаясь их использовать; и (2) пассивные тесты, которые только исследуют систему и делают вывод о существовании проблем на основании состояния системы.

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

7.3.2.2 Аудит внутреннего контроля

Аудитор может проверить существующие средства контроля и определить, являются ли они эффективными. Аудитор часто анализирует как системные, так и несистемные средства контроля. Используемые методы включают опрос, наблюдение и тестирование как данных, так и самих элементов управления. Аудит также может выявить незаконные действия, ошибки, нарушения или несоблюдение законов и нормативных актов. Могут использоваться планы безопасности системы и тестирование на проникновение, обсуждаемые ниже.

7.3.2.3 Использование плана безопасности системы (SSP)

План обеспечения безопасности системы предоставляет подробные сведения о реализации, по которым система может быть проверена. Этот план, обсуждаемый в разделе 10.12, описывает основные аспекты безопасности системы, включая вопросы управления, эксплуатации и технические вопросы. Одним из преимуществ использования плана безопасности системы является то, что он отражает уникальную среду безопасности системы, а не общий список элементов управления. Могут быть разработаны наборы средств управления безопасностью, включая национальные или организационные политики и практики безопасности (часто называемые базовыми). SSP также используется для исторических целей, и в таких случаях, когда существует системное соединение, может потребоваться совместное использование с другими организациями.

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

7.3.2.4 Тестирование на проникновение

Тестирование на проникновение может использовать множество методов для попытки взлома системы. Помимо использования активных автоматизированных инструментов, как описано выше, тестирование на проникновение можно проводить «вручную». Самый полезный тип тестирования на проникновение включает использование методов, которые могут быть использованы против системы. Для хостов в Интернете это, безусловно, будет включать автоматизированные инструменты. Для многих систем слабые процедуры или отсутствие внутреннего контроля в приложениях являются распространенными уязвимостями, на которые может быть нацелено тестирование на проникновение. Еще один метод - это социальная инженерия, при которой пользователи или администраторы обманывают информацию о системах, включая их пароли.

7.3.3 Методы и инструменты мониторинга

Мониторинг безопасности - это постоянная деятельность, направленная на поиск уязвимостей и проблем безопасности. Многие методы аналогичны тем, которые используются для аудита, но выполняются более регулярно или, для некоторых автоматизированных инструментов, в режиме реального времени.

7.3.3.1 Просмотр системных логов

Периодический просмотр или использование автоматических инструментов для анализа журналов, созданных системой, может обнаружить проблемы безопасности, включая попытки превышения полномочий доступа или получения доступа к системе в необычные часы.

7.3.3.2 Автоматизированные инструменты

Несколько типов автоматизированных инструментов контролируют систему на предмет проблем с безопасностью. Ниже приведены некоторые примеры:

• Сканеры вредоносного кода - популярное средство проверки на заражение вредоносным кодом. Эти программы проверяют наличие вредоносного кода в исполняемых программных файлах;

• Функции контрольной суммы генерируют математическое значение, используемое для обнаружения изменений данных на основе содержимого файла. Когда проверяется целостность файла, для текущего файла генерируется контрольная сумма и сравнивается с ранее сгенерированным значением. Если два значения равны, проверяется целостность файла. Выполнение контрольной суммы в программах позволяет обнаруживать вредоносный код, случайные изменения файлов и другие изменения файлов. Однако они могут подлежать скрытой замене злоумышленником. Цифровая подпись, которая защищает не только от случайных изменений файлов и значительно превосходит контрольную сумму, также может использоваться для проверки целостности файла;

• Средства проверки надежности паролей проверяют пароли по словарю (либо «обычному» словарю, либо специализированному словарю с легко угадываемыми паролями, либо и тем, и другим, а также проверяют, являются ли пароли распространенными перестановками идентификатора пользователя. Примерами специальных словарных статей могут быть названия региональных спортивных команд и звезд. Обычными перестановками могут быть обратное написание идентификатора пользователя или добавление цифр или специальных символов после общих паролей;

• Программы проверки целостности могут использоваться приложениями для поиска доказательств подделки данных, ошибок и упущений. Методы включают проверки согласованности и разумности и валидацию во время ввода и обработки данных. Эти методы могут проверять данные элементы - в качестве входных или обработанных - против ожидаемых значений или диапазонов значений; анализировать транзакции на предмет правильного выполнения, последовательности и авторизации; или исследуйте элементы данных на предмет ожидаемых отношений. Программы проверки целостности включают в себя важный набор процессов, предназначенных для уверенности людей в том, что несоответствующие действия, как случайные, так и преднамеренные, будут обнаружены. Многие программы проверки целостности полагаются на регистрацию действий отдельных пользователей;

• Системы обнаружения вторжений на основе хоста анализируют журнал системного аудита на предмет действий, которые могут представлять собой несанкционированные действия, в частности, вход в систему, соединения, вызовы операционных систем и различные параметры команд. Обнаружение вторжений описано в разделах 10.1 и 10.3; а также

• Мониторинг производительности системы анализирует журналы производительности системы в режиме реального времени для поиска проблем с доступностью, включая активные атаки, замедление работы системы и сети и сбои.

7.3.3.3 Управление конфигурацией

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

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

Изменения в системе могут иметь последствия для безопасности. Такие изменения могут ввести или уменьшить уязвимости и могут потребовать обновления плана действий в чрезвычайных ситуациях, анализа рисков или авторизации. Дополнительные сведения об управлении конфигурацией см. В разделе 10.5.

7.3.3.4 Торговая литература/публикации/электронные новости

Помимо мониторинга системы, полезно отслеживать внешние источники информации.

Такие источники, как отраслевая литература, как печатная, так и электронная, содержат информацию об уязвимостях, исправлениях и других областях, влияющих на безопасность. Форум групп реагирования на инциденты (FIRST) имеет список электронной рассылки, в который поступает информация об угрозах, уязвимостях и исправлениях. Национальная база данных уязвимостей (NVD) - это хранилище основанных на стандартах данных об управлении уязвимостями, представленных с помощью протокола автоматизации безопасности содержимого (SCAP). Эти данные позволяют автоматизировать управление уязвимостями, измерение безопасности и соответствие требованиям. NVD включает в себя базы данных контрольных списков безопасности, связанных с безопасностью недостатков программного обеспечения, неправильных конфигураций, названий продуктов и показателей воздействия.

Группа готовности к компьютерным чрезвычайным ситуациям США (US-CERT), компонент DHS, реагирует на серьезные инциденты, анализирует угрозы и обменивается важной информацией о кибербезопасности с доверенными партнерами по всему миру. Кроме того, Центры обмена и анализа информации (ISAC) передают важную отраслевую информацию о физических, киберугрозах и мерах по их устранению, чтобы поддерживать ситуационную осведомленность в масштабах всего сектора.

7.4 Взаимозависимости

Гарантия - это проблема для всех средств контроля и защиты, обсуждаемых в этой публикации. Здесь следует еще раз подчеркнуть один важный момент: гарантия предназначена не только для технических средств контроля, но и для оперативных средств контроля. Хотя в этой главе основное внимание уделяется системному обеспечению, также важно иметь уверенность в том, что средства управления работают должным образом. Поддерживаются ли идентификаторы пользователей и права доступа в актуальном состоянии? Был ли протестирован план действий в чрезвычайных ситуациях? Можно ли подделать журнал аудита? Насколько эффективна программа безопасности? Понятны ли правила и соблюдаются ли они? Как отмечалось во введении к этой главе, потребность в уверенности более распространена, чем люди часто понимают.

Достоверность тесно связана с планированием безопасности в жизненном цикле системы. Системы могут быть спроектированы для облегчения различных видов тестирования на соответствие заданным требованиям безопасности. Планируя такое тестирование на раннем этапе процесса, можно снизить затраты. Некоторые виды уверенности невозможно получить без надлежащего планирования.

7.5 Соображения стоимости

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

Гарантия также может быть довольно дорогой, особенно если проводится обширное тестирование. Чтобы принять наиболее выгодное решение, полезно оценить степень полученной уверенности в отношении затрат. В целом расходы на персонал увеличивают стоимость гарантий. Автоматизированные инструменты обычно ограничиваются решением конкретных проблем, но, как правило, менее дороги.


Читайте также


Комментарии 0