Русский
Русский
English
Статистика
Реклама

Анализ уязвимостей

Прочитай и сделай проводим сканирование сети самостоятельно

04.08.2020 16:15:07 | Автор: admin
В свете последних событий в мире много компаний перешли на удаленный режим работы. При этом для сохранения эффективности бизнес-процессов на сетевые периметры были вынесены приложения, которые не предназначены для прямого размещения на периметре, например внутрикорпоративные веб-приложения, на эту тему недавно было наше исследование. Если между службами ИТ и ИБ нет тесной связи, возникают ситуации, когда на сетевом периметре появилось бизнес-приложение, о котором у службы ИБ нет информации.

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

Ping-сканирование


Первый рассматриваемый вид сканирования ping-сканирование. Основная задача обнаружить живые узлы в сети. Под ping-сканированием понимают широковещательную рассылку пакетов ICMP. Сканер рассылает пакеты типа Echo REQUEST по указанным IP-адресам и ожидает в ответ пакеты типа Echo REPLY. Если ответ получен, считается, что узел присутствует в сети по указанному IP-адресу.

Протокол ICMP широко используется администраторами сетей для диагностики, поэтому, чтобы избежать разглашения информации об узлах, важна корректная настройка средств защиты периметра. Для корпоративных сетей такой вид сканирования не релевантен при внешнем сканировании, потому что большинство средств защиты по умолчанию блокируют протокол ICMP либо ответы по этому протоколу. При отсутствии нестандартных задач в корпоративной сети на выход, как правило, разрешены следующие виды ICMP-сообщений: Destination Unreachable, Echo REQUEST, Bad IP header, а на вход разрешены Echo REPLY, Destination Unreachable, Source Quench, Time Exceeded, Bad IP header. В локальных сетях не такая строгая политика безопасности, и злоумышленники могут применять этот способ, когда уже проникли в сеть, однако это легко детектируется.

Сканирование портов


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

  1. TCP SYN,
  2. TCP CONNECT,
  3. UDP scan.

Метод TCP SYN наиболее популярен, используется в 95% случаев. Его называют сканированием с установкой полуоткрытого соединения, так как соединение не устанавливается до конца. На исследуемый порт посылается сообщение SYN, затем идет ожидание ответа, на основании которого определяется статус порта. Ответы SYN/ACK говорят о том, что порт прослушивается (открыт), а ответ RST говорит о том, что не прослушивается.
Если после нескольких запросов не приходит никакого ответа, то сетевой трафик до порта узла назначения фильтруется средствами межсетевого экранирования (далее будем использовать термин порт фильтруется). Также порт помечается как фильтруемый, если в ответ приходит сообщение ICMP с ошибкой достижимости (Destination Unreachable) и определенными кодами и флагами.

Метод TCP CONNECT менее популярен, чем TCP SYN, но все-таки часто встречается на практике. При реализации метода TCP CONNECT производится попытка установить соединение по протоколу TCP к нужному порту с процедурой handshake. Процедура заключается в обмене сообщениями для согласования параметров соединения, то есть служебными сообщениями SYN, SYN/ACK, ACK, между узлами. Соединение устанавливается на уровне операционной системы, поэтому существует шанс, что оно будет заблокировано средством защиты и попадет в журнал событий.

UDP-сканирование медленнее и сложнее, чем TCP-сканирование. Из-за специфики сканирования UDP-портов о них часто забывают, ведь полное время сканирование 65 535 UDP-портов со стандартными параметрами на один узел занимает у большинства автоматизированных сканеров до 18 часов. Это время можно уменьшить за счет распараллеливания процесса сканирования и рядом других способов. Следует уделять внимание поиску UDP-служб, потому что UDP-службы реализуют обмен данными с большим числом инфраструктурных сервисов, которые, как правило, вызывают интерес злоумышленников.

На сетевых периметрах часто встречаются UDP-сервисы DNS (53), NTP (123), SNMP (161), VPN (500, 1194, 4500), RDG (3391). Реже встречаются сервисные службы типа echo (7), discard (9), chargen (19), а также DAYTIME (13), TFTP (69), SIP (5060), сервисы NFS (2049), RPC (111, 137-139, 761 и др.), СУБД (1434).

Для определения статуса порта посылается пустой UDP-заголовок, и если в ответ приходит ошибка достижимости ICMP Destination Unreachable с кодом Destination port unreachable, это значит, что порт закрыт; другие ошибки достижимости ICMP (Destination host unreachable, Destination protocol unreachable, Network administratively prohibited, Host administratively prohibited, Communication administratively prohibited) означают, что порт фильтруется. Если порт отвечает UDP-пакетом, значит, он открыт. Из-за специфики UDP и потери пакетов запросы повторяются несколько раз, обычно три и более. Как правило, если ответ не получен, статус порта определяется в состоянии открыт или фильтруется, поскольку непонятно, что стало причиной блокировка трафика средством защиты или потеря пакетов.

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

Редкие методы сканирования


Методы, которые практически не используются:

  1. TCP ACK,
  2. TCP NULL, FIN, Xmas,
  3. Ленивое сканирование.

Прямое назначение метода ACK-сканирования выявить правила средств защиты, а также определить фильтруемые порты. В пакете запроса при таком типе сканирования установлен только ACK-флаг. Открытые и закрытые порты вернут RST-пакет, так как порты достижимы для ACK-пакетов, но состояние неизвестно. Порты, которые не отвечают или посылают в ответ ICMP-сообщение Destination Unreachable с определенными кодами считаются фильтруемыми.

Методы TCP NULL, FIN, Xmas заключаются в отправке пакетов с отключенными флагами в заголовке TCP. При NULL-сканировании не устанавливаются никакие биты, при FIN-сканировании устанавливается бит TCP FIN, а в Xmas-сканировании устанавливаются флаги FIN, PSH и URG. Методы основаны на особенности спецификации RFC 793, согласно которой при закрытом порте входящий сегмент, не содержащий RST, повлечет за собой отправку RST в ответ. Когда порт открыт, ответа не будет. Ошибка достижимости ICMP означает, что порт фильтруется. Эти методы считаются более скрытными, чем SYN-сканирование, однако и менее точны, потому что не все системы придерживаются RFC 793.

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

Процесс выявления уязвимостей


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

Уязвимость регистрируется в MITRE CVE, а подробности публикуются в NVD. Уязвимости присваивается идентификатор CVE, а также общий балл системы оценки уязвимости CVSS, отражающий уровень риска, который уязвимость представляет для конечной системы. Подробно об оценке уязвимостей написано в нашей статье. Централизованный список MITRE CVE ориентир для сканеров уязвимостей, ведь задача сканирования обнаружить уязвимое программное обеспечение.

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

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

Параметры сканирования


За месяц периметр организации может неоднократно поменяться. Проводя сканирование периметра в лоб можно затратить время, за которое результаты станут нерелевантными. При сильном увеличении скорости сканирования сервисы могут упасть. Надо найти баланс и правильно выбрать параметры сканирования. От выбора зависят потраченное время, точность и релевантность результатов. Всего можно сканировать 65 535 TCP-портов и столько же UDP-портов. По нашему опыту, среднестатистический периметр компании, который попадает в пул сканирования, составляет две полных сети класса С с маской 24.

Основные параметры:

  1. количество портов,
  2. глубина сканирования,
  3. скорость сканирования,
  4. параметры определения уязвимостей.

По количеству портов сканирование можно разделить на три вида сканирование по всему списку TCP- и UDP-портов, сканирование по всему списку TCP-портов и популярных UDP-портов, сканирование популярных TCP- и UDP-портов. Как определить популярности порта? В утилите nmap на основе статистики, которую собирает разработчик утилиты, тысяча наиболее популярных портов определена в конфигурационном файле. Коммерческие сканеры также имеют преднастроенные профили, включающие до 3500 портов.

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

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

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

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

Параметры определения уязвимостей наиболее обширный раздел параметров сканирования, от которого зависит скорость сканирования и объем уязвимостей, которые могут быть обнаружены. Например, баннерные проверки не займут много времени. Имитации атак будут проведены только для отдельных сервисов и тоже не займут много времени. Самый долгий вид веб-сканирование.

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

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

Инструментарий


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

Сетевые сканеры: Masscan, Zmap, nmap. На самом деле утилит для сканирования сети намного больше, однако для сканирования периметра вряд ли вам понадобятся другие. Эти утилиты позволяют решить большинство задач, связанных со сканированием портов и служб.

Поисковики по интернету вещей, или онлайн-сканеры важные инструменты для сбора информации об интернете в целом. Они предоставляют сводку о принадлежности узлов к организации, сведения о сертификатах, активных службах и иную информацию. С разработчиками этого типа сканеров можно договориться об исключении ваших ресурсов из списка сканирования или о сохранении информации о ресурсах только для корпоративного пользования. Наиболее известные поисковики: Shodan, Censys, Fofa.

Для решения задачи не обязательно применять сложный коммерческий инструмент с большим числом проверок: это излишне для сканирования пары легких приложений и сервисов. В таких случаях будет достаточно бесплатных сканеров. Бесплатных веб-сканеров много, и тяжело выделить наиболее эффективные, здесь выбор, скорее, дело вкуса; наиболее известные: Skipfish, Nikto, ZAP, Acunetix, SQLmap.

При тщательном ручном анализе будут полезны инструменты Burp Suite, Metasploit и OpenVAS. Недавно вышел сканер Tsunami компании Google.
Отдельной строкой стоит упомянуть об онлайн-поисковике уязвимостей Vulners. Это большая база данных контента информационной безопасности, где собирается информация об уязвимостях с большого количества источников, куда, кроме типовых баз, входят вендорские бюллетени безопасности, программы bug bounty и другие тематические ресурсы. Ресурс предоставляет API, через который можно забирать результаты, поэтому можно реализовать баннерные проверки своих систем без фактического сканирования здесь и сейчас. Либо использовать Vulners vulnerability scanner, который будет собирать информацию об операционной системе, установленных пакетах и проверять уязвимости через API Vulners. Часть функций ресурса платные.

Коммерческие сканеры уязвимостей


Все коммерческие системы защиты поддерживают основные режимы сканирования, которые описаны ниже, интеграцию с различными внешними системами, такими как SIEM-системы, patch management systems, CMBD, системы тикетов. Коммерческие сканеры могут присылать оповещения по разным критериям, а поддерживают различные форматы и типы отчетов. Все разработчики систем сканирования используют общие базы уязвимостей, а также собственные базы знаний, которые постоянно обновляются на основе исследований.

Основные различия между коммерческими сканерами поддерживаемые стандарты, лицензии государственных структур, количество и качество реализованных проверок, а также направленность на тот или иной рынок сбыта, например поддержка сканирования отечественного ПО. Статья не призвана представить качественное сравнение сканеров уязвимостей. На наш взгляд, у каждого сканера есть свои преимущества и недостатки. Для анализа защищенности подходят все перечисленные средства, можно использовать их комбинации: Qualys, Max Patrol 8, Tenable SecurityCenter.

Как работают сканеры уязвимостей


Режимы сканирования реализованы по трем схожим принципам:

  1. Аудит, или режим белого ящика.
  2. Комплаенс, или проверка на соответствие техническим стандартам.
  3. Пентест, или режим черного ящика.

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

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

Авторизованному пользователю, в роли которого выступает сканер, значительно проще получать детальную информацию об узле, его программном обеспечении и конфигурационных параметрах. При сканировании используются различные механизмы и транспорты операционных систем для сбора данных, зависящие от специфики системы, с которой собираются данные. Список транспортов включает, но не ограничивается WMI, NetBios, LDAP, SSH, Telnet, Oracle, MS SQL, SAP DIAG, SAP RFC, Remote Engine с использованием соответствующих протоколов и портов.

Комплаенс режим проверки на соответствие каким-либо стандартам, требованиям или политикам безопасности. Режим использует схожие с аудитом механизмы и транспорты. Особенность режима возможность проверки корпоративных систем на соответствие стандартам, которые заложены в сканеры безопасности. Примерами стандартов являются PCI DSS для платежных систем и процессинга, СТО БР ИББС для российских банков, GDPR для соответствия требованиям Евросоюза. Другой пример внутренние политики безопасности, которые могут иметь более высокие требования, чем указанные в стандартах. Кроме того, существуют проверки установки обновлений и другие пользовательские проверки.

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

  1. баннерные проверки,
  2. имитация атак,
  3. веб-проверки,
  4. проверки конфигураций,
  5. опасные проверки.

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

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

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

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

На этом же этапе собираются баннеры CMS и плагинов приложения, по которым проводится баннерная проверка на известные уязвимости. Следующий этап основные веб-проверки: поиск SQL Injection разных видов, поиск недочетов системы аутентификации и хранения сессий, поиск чувствительных данных и незащищенных конфигураций, проверки на XXE Injection, межсайтовый скриптинг, небезопасную десериализацию, загрузку произвольных файлов, удаленное исполнение кода и обход пути. Список может быть шире в зависимости от параметров сканирования и возможностей сканера, обычно при максимальных параметрах проверки проходят по списку OWASP Top Ten.

Проверки конфигураций направлены на выявление ошибок конфигураций ПО. Они выявляют пароли по умолчанию либо перебирают пароли по короткому заданному списку с разными учетными записями. Выявляют административные панели аутентификации и управляющие интерфейсы, доступные принтеры, слабые алгоритмы шифрования, ошибки прав доступа и раскрытие конфиденциальной информации по стандартным путям, доступные для скачивания резервные копии и другие подобные ошибки, допущенные администраторами IT-систем и систем ИБ.

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

Сканирование и результаты


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

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

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

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

Устранение уязвимостей


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

Можно применять компенсирующие меры по настройке, то есть исключать использование уязвимого компонента или приложения. Еще вариант использовать специализированные средства защиты, такие как IPS или application firewall. Конечно, правильнее не допускать появления нежелательных сервисов на сетевом периметре, но такой подход не всегда возможен в силу различных обстоятельств, в особенности требований бизнеса.

Приоритет устранения уязвимостей


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

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

Итоги


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

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

Автор: Максим Федотов, старший специалист отдела онлайн-сервисов, PT Expert Security Center, Positive Technologies
Подробнее..

Оценочный уровень доверия (ОУД4) и ГОСТ Р ИСОМЭК 15408-3-2013. Введение

18.02.2021 10:20:32 | Автор: admin

Привет, Хабр!


В настоящее время в ИТ индустрии крайне актуальна тема построения процесса безопасной разработки ПО (по англ. Secure SDLC или Secure software development life cycle). Некоторые организации и команды самостоятельно приходят к необходимости такого процесса в своих продуктах, свободно выбирают подходящий фреймворк, инструменты и выстраивают свой вариант безопасной разработки. Другие, подпадающие под внешние регуляции, вынуждены разбираться с конкретными, заранее выбранными регуляторами фреймворками или стандартами. Ко второму варианту относятся многочисленные финансовые организации, деятельность которых регулируется Банком России. В нормативах последнего с мая 2018 года стали фигурировать вопросы анализа уязвимостей и появилась аббревиатура ОУД 4.

Этой статьёй я хочу начать цикл, освещающий процессы безопасной разработки в контексте стандартов серии ГОСТ Р ИСО/МЭК 15408. Моя задача последовательно, фундаментально и лаконично изложить этот фреймворк, чтобы уменьшить порог вхождения в предмет. Материал предназначен для разработчиков, менеджеров, методологов и других людей, которые в силу обстоятельств, вынуждены погружаться в безопасную разработку в контексте ОУД и требований Банка России. В подготовке материала мне помогал независимый эксперт и специалист по информационной безопасности - Рустам Гусейнов.


Подробнее под катом

Оглавление

  1. Введение и цели цикла

  2. История и эволюция фреймворка

  3. Центральный банк как популяризатор ОУД4

  4. Общие положения и концепции ОУД4

  5. Заключение

  6. Полезные ссылки и материалы

  7. Приложение (список сокращений)

Введение и цели цикла

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

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

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

История и эволюция фреймворка

ОУД расшифровывается как оценочный уровень доверия. Из самого названия следует цель фреймворка гарантировать соответствие продукта определенным критериям, заявленным в соответствующих стандартах, чтобы пользователи (заказчики, владельцы, физические лица и т.д.) могли доверять программному или аппаратному обеспечению, прошедшему необходимые проверки и декларирующему через них соответствие необходимым требованиям. Чтобы не уходить в длинную лекцию о разработке, уязвимостях, их эксплуатации и сопутствующих рисках, напомним, что любая ИТ-система теоретически (а на деле чаще всего и практически были бы ресурсы!) несовершенна. Поэтому в силу различных недостатков, связанных с:

- архитектурой (дизайном);

- разработкой (кодированием архитектуры в конечный продукт);

- внедрением (настройкой);

- эксплуатацией (обслуживанием).

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

Рисунок 1. Иллюстрация вектора атаки

Корни фреймворка уходят в становление индустрии ИБ в США в семидесятых и восьмидесятых годах прошлого века. По мере автоматизации и развития системного подхода силовые ведомства стремились гарантировать надежность системных компонентов, используемых государственными структурами для защиты информации. В течение какого-то времени несколько подобных стандартов существовали в различных юрисдикциях параллельно, пока не были объединены международными организациями ISO/IEC в новый, единый фреймворк ISO/IEC 15408 Common Criteria for Information Technology Security Evaluation (или просто Common Criteria то есть Общие Критерии). Любопытные до истории и фактов могут изучить подробности хроники по ссылкам внизу статьи, нас же интересует тот факт, что отечественные стандартизаторы с 2012 года начали анализировать и перерабатывать указанное семейство стандартов, чтобы издать их официально на русском под эгидой Стандартинформа.

Здесь стоит сделать небольшое отступление про статус подобных стандартов. На фоне вступления России в ВТО и либерализации законодательства национальные стандарты перестали быть обязательными на территории Российской Федерации. Сегодня, в соответствии со ст. 27Федерального закона 162-ФЗ О стандартизации, ГОСТы на территории России являются обязательными тогда, когда на них явно ссылаются какие-то нормативно-правовые акты уполномоченных органов государственной власти. Здесь на сцену выходит Центральный Банк России.

Рисунок 2. Титульный лист ГОСТ Р 15408-1-2012

Центральный банк как популяризатор ОУД4

Примерно в то время, когда Стандартинформ публикует первые документы семейства ГОСТ 15408, Банк России, в соответствии с международными трендами, начинает ужесточать требования к информационной безопасности платежей и кредитных организаций. Его целью является обеспечение устойчивости и надежности платежной и банковской системы, в том числе борьба с мошенничеством и несанкционированными переводами. Летом 2012 года принимается знаменитое положение 382-П, которое на следующие 8 лет становится основным нормативом по информационной безопасности для организаций, занимающихся денежными переводами на территории РФ (не считая более нишевых и специфичных требований, вроде стандарта PCI DSS, которые существовали и до этого).

С положения 382-П начинается внедрение ОУД 4 в жизнь финансовых организаций. В мае 2018 года Банк России, сталкиваясь с фактами печальной статистики уязвимостей ДБО и иных публично доступных интерфейсов взаимодействия с клиентами, вносит изменения в упомянутое Положение. Среди них содержится п. 2.5.5.1, цитата:

необходимо обеспечить: использование для осуществления переводов денежных средств прикладного программного обеспечения автоматизированных систем и приложений, сертифицированных в системе сертификации Федеральной службы по техническому и экспортному контролю на соответствие требованиям по безопасности информации, включая требования по анализу уязвимостей и контролю отсутствия недекларированных возможностей, в соответствии с законодательством Российской Федерации или в отношении которых проведен анализ уязвимостей по требованиям к оценочному уровню доверия не ниже чем ОУД 4 в соответствии с требованиями национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 15408-3-2013 .

В последующие годы это требование, в уточненном и видоизмененном виде, появлялось в других нормативах ЦБ, и по состоянию на 2021 год прямо или косвенно вытекает из:

- 672-П (через ссылку на ГОСТ Р 57580.1-2017, где в требованиях ЖЦ.8 и ЖЦ.20 косвенно формулируется ежегодный ОУД4);

- 683-П;

- 684-П;

- 719-П.

Некоторые шероховатости формулировок и весьма общее указание на границы применимости ОУД в историческом 382-П, где было упомянуто прикладное ПО для осуществления перевода денежных средств, породили разночтения и длительные споры участников рынка об области применения ОУД. Стал популярным вопрос: надо ли проводить работы по ОУД в отношении всех информационных систем, участвующих в переводе денежных средств (например в отношении АБС), или все же речь идет о каких-то наиболее критичных/высокорискованных системах? Впоследствии эти вопросы были разрешены официальной позицией регулятора. Забегая вперед скажем, что требования к работам по ОУД касаются лишь того ПО, которое соответствует одному из двух условий (либо обоим):

  1. ПО распространяется клиентам организации (физическим или юридическим лицам);

  2. ПО доступно через интернет неограниченному кругу лиц (а не закрыто VPN или иными ограничителями).

Рисунок 3. Границы применимости ОУД для приложений финансовых организаций

Рассмотрим, для примера, как эта логика работает для банков. Из п. 4.1 Положения 683-П, которое устанавливает требования к ИБ кредитных организаций, вытекает необходимость работ по ОУД для ПО распространяемого кредитной организацией клиентам для совершения действий в целях осуществления банковских операций, а также {ПО}, обрабатывающего информацию на участках, используемых для приема электронных сообщений, к исполнению в автоматизированных системах и приложениях с использованием {} Интернет . В информационном письме Банка России от 8 июля 2020 г. N ИН-014-56/110, посвященном ОУД, приведена ссылка на Профиль Защиты Прикладного ПО, как на методику проведения анализа уязвимостей (подробнее об этом документе поговорим ниже). В свою очередь в п. 2.3.1 упомянутого Профиля развернуто сформулированы критерии подпадания прикладного ПО под работы в соответствии с ОУД4: клиентское ПО и/или выход в интернет. В упомянутой цитате из профиля находим:

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

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

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

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

Таким образом, спор о границах применимости ОУД был разрешен, а широкая формулировка границ применимости, проистекающая из 382-П уйдет в небытие вместе с указанным положением (оно утрачивает силу 01 января 2022 года на основании положения Банка России 719-П). Остается единственный вопрос как быть, если несколько приложений подпадают под требования? Наш ответ неоригинален риск-ориентированный подход и приоритизация проектов по ОУД внутри организации, особенно в условиях жестко лимитированного бюджета. Такую приоритизацию можно выстраивать на основании масштаба финансовых переводов, с учетом количества обрабатываемых персональных данных или исходить из других, менее очевидных соображений, например возможностей команды разработки оказывать поддержку проекту. В любом случае у вас наверняка есть более критичные каналы взаимодействия с клиентами и есть менее критичные. Если бюджет проекта ограничен, а количество различных приложений подпадающих под ОУД велико, самый простой критерий принятия решения - финансовый.

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

Общие положения и концепции ОУД4

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

Ключевыми документами, для понимания фреймворка, являются упомянутые в ссылках ГОСТы, которые не только вводят терминологию, но и содержат многочисленные разъяснения и примеры его различных аспектов. Ниже перечень, на наш взгляд, наиболее интересных и полезных:

  1. ГОСТ 15408-1-2012

  2. ГОСТ 15408-2-2013;

  3. ГОСТ 15408-3-2013;

  4. ГОСТ 18045-2013;

  5. ГОСТ 57628-2017;

  6. ГОСТ Р 58143-2018.

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

Рис 4. Управление конфигурацией и жизненный цикл продукта (согласно ГОСТ Р 15408-1-2012)

Этапы работ, формирующих ОУД, описываются в третьей части стандарта ГОСТ 15408, как показано на следующем рисунке.

Рис 5. Компоненты, формирующие ОУД

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

  1. Ключевых концепций и ролей;

  2. Базовых процессов (взаимодействий) и их результатов.

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

А. Заказчик (может совпадать с пользователем или владельцем), который использует некий продукт и требует соответствие этого продукта неким установленным требованиям к ИБ;

Б. Разработчик, который создает этот продукт и выстраивает его жизненный цикл, в соответствии с требованиями Заказчика;

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

Здесь нужно сделать оговорку, что несмотря на методологическую рекомендацию разделять описанные выше роли между субъектами во избежании конфликта интересов (например, чтобы не проверять самих себя, а привлекать третью, независимую сторону), на практике, в некоторых случаях, такое совмещение ролей допустимо и легально. Например, в последнем абзаце п. 9 Положения 684-П сказано, что анализ уязвимостей по требованиям к ОУД4 может проводиться некредитными финансовыми организациями самостоятельно, без привлечения третьей стороны (для сравнения в текущей редакции 683-П такого пункта нет, и подобные работы необходимо осуществлять с привлечением сторонней организации лицензиата ФСТЭК).

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

Какие же процессы и взаимодействия возникают в ходе работ в соответствии с фреймворком ОУД? Практически каждый процесс ИБ начинается с описания границ проекта и требований, безопасная разработка не исключение.


В общих чертах фреймворк декларирует следующую последовательность действий:

  1. Разработать документацию и политики на продукт, которые регламентируют требования к ИБ приложения и разработки;

  2. Обеспечить практическое применение документов в разработке конкретного продукта;

  3. В ходе тестов, оценки соответствия и/или анализа уязвимостей подтвердить, что установленные на уровне документации и политик требования выполняются де-факто и позволяют достичь необходимого уровня безопасности (по сути защитить продукт от нарушителя ИБ с определенным потенциалом).

Ключевым элементом фреймворка является объект оценки (или ОО, например, ДБО, или какой-то компонент внутри ДБО), к которому предъявляются функциональные требования к безопасности (или ФТБ, например, необходимая реализация системы управления доступом или стойкая криптография), формулируемые в задании по безопасности или профиле защиты (разница между двумя в том, что задание по безопасности обычно создается Заказчиком самостоятельно, под себя; а профиль тиражируется различными институциями как минимально-адекватный стандарт для какого-то класса решений, например для межсетевых экранов или антивирусов). Так как объект оценки существует не в вакууме, а актуальные уязвимости связаны не только с разработкой и проектированием, но и с настройкой и эксплуатацией объекта, важными понятиями являются среда функционирования и конфигурация среды/объекта оценки. Наконец, сам оценочный уровень доверия представляет собой гамбургер из большего или меньшего набора компонент, в зависимости от выбранного уровня (смотри рисунок 5 выше).

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

Такое подтверждение может осуществляться с помощью двух базовых сценариев:

  1. С помощью сертификации (делается специализированными лабораториями, включенными в систему ФСТЭК);

  2. С помощью оценки соответствия или анализа уязвимостей (делается самостоятельно для себя, либо сторонней организацией с лицензией ФСТЭК на ТЗКИ).

Это разделение нашло свое отражение в упомянутых по тексту положениях Банка России. В порядке убывания сложности и цены указанные сценарии можно разместить следующим образом:

  1. Сертификация;

  2. Оценка соответствия;

  3. Анализ уязвимостей.

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

При всех нюансах и вариациях имплементации необходимый минимум документации на приложение включает в себя:

  1. Описание архитектуры безопасности;

  2. Функциональные спецификации;

  3. Руководство пользователя по эксплуатации;

  4. Представление реализации;

  5. Проект объекта оценки;

  6. Задание по безопасности.

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

Заключение

Это наш первый опыт популярного изложения вопросов комплаенса (или соответствия стандартам) для широкой публики и нам важно получить обратную связь, чтобы адаптировать будущие тексты под интересы читателей и сделать их полезнее. Расскажите, пожалуйста, в комментариях - что вам понравилось в первой статье цикла, а что нет? Какие специфические темы, вопросы или примеры из жизни вы бы хотели подробно разобрать в контексте темы цикла? А может быть вы уже активно работаете с ОУД и хотите поделиться решенными проблемами, замечаниями и наблюдениями? Помимо упомянутой во введении методички по вопросам ОУД, мы планируем серию сопутствующих вебинаров, содержанием которых могут стать ответы на ваши вопросы и демонстрация реальных кейсов внедрения фреймворка. Для желающих приватности адрес электронной почты для связи: aantonov@swordfishsecurity.com

Полезные ссылки и материалы по теме:

  1. https://malotavr.blogspot.com/ блог Дмитрия Кузнецова, эксперта Positive Technologies, одного из немногих специалистов, систематически рассматривающих вопросы сертификации ПО и анализа уязвимостей по ОУД4. Написал несколько материалов про требования ЦБ и ОУД4, см. статьи за 2019 год.

  2. https://www.youtube.com/watch?v=0ZoNdaoAeyc&t=658s обзорный вебинар компании RTM Group, посвященный особенностям фреймворка, с участием компании Safe Tech, описывающий реализацию фреймворка в отношении своего продукта.

  3. Переведенные стандарты:

    a. ГОСТ 15408-1-2012;

    b. ГОСТ 15408-2-2013;

    c. ГОСТ 15408-3-2013;

    d. ГОСТ 18045-2013;

    e. ГОСТ 57628-2017;

    f. ГОСТ Р 58143-2018.

  4. https://en.wikipedia.org/wiki/Common_Criteria Обзор лучших практик по безопасной разработке статья в вики для желающих самостоятельно углубиться в исторические предпосылки.

  5. Лучшие практики безопасной разработки:

    a. https://doi.org/10.6028/NIST.CSWP.04232020 обзор актуальных практик SDLC от американского института NIST Mitigating the Risk of Software Vulnerabilities by Adopting a Secure Software Development Framework (SSDF) от 23.04.2020;

    b. https://www.iso.org/standard/55583.html стандарт ISO/IEC 27034-3:2018 Information technology Application security Part 3: Application security management process;

    c. https://www.pcisecuritystandards.org/document_library стандарты PCI SSC линейки Software Security Framework:

    i. Secure Software Requirements and Assessment Procedures;

    ii. Secure Software Lifecycle (Secure SLC) Requirements and Assessment Procedures.

  6. https://www.cbr.ru/information_security/acts/ Методический документ Банка России ПРОФИЛЬ ЗАЩИТ прикладного программного обеспечения автоматизированных систем и приложений кредитных организаций и некредитных финансовых организаций.

Приложение (список сокращений)

По тексту документа использованы следующие сокращения/условные обозначения:

  1. 382-П/Положение 382-П Положение Банка России от 9 июня 2012 г. 382-П О требованиях к обеспечению защиты информации при осуществлении переводов денежных средств и о порядке осуществления Банком России контроля за соблюдением требований к обеспечению защиты информации при осуществлении переводов денежных средств (актуальная редакция от 07.05.2018, действительно до 01.01.2022 года, отменяется 719-П);

  2. 719-П/Положение 719-П Положение Банка России от 4 июня 2020 г. 719-П О требованиях к обеспечению защиты информации при осуществлении переводов денежных средств и о порядке осуществления Банком России контроля за соблюдением требований к обеспечению защиты информации при осуществлении переводов денежных средств;

  3. 672-П/Положение 672-П Положение Банка России от 09.01.2019 N 672-П О требованиях к защите информации в платежной системе Банка России;

  4. 683-П/Положение 683-П Положение Банка России от 17 апреля 2019 г. N 683-П Об установлении обязательных для кредитных организаций требований к обеспечению защиты информации при осуществлении банковской деятельности в целях противодействия осуществлению переводов денежных средств без согласия клиента;

  5. 684-П/Положение 684-П Положение Банка России от 17.04.2019 N 684-П Об установлении обязательных для некредитных финансовых организаций требований к обеспечению защиты информации при осуществлении деятельности в сфере финансовых рынков в целях противодействия осуществлению незаконных финансовых операций;

  6. 162-ФЗ/Федеральный закон 162 ФЗ Федеральный закон О стандартизации в Российской Федерации от 29.06.2015 N 162-ФЗ;

  7. АБС автоматизированная банковская система;

  8. ГОСТ Р национальный государственный стандарт Российской Федерации;

  9. ИБ информационная безопасность;

  10. ИТ информационные технологии;

  11. ОО объект оценки;

  12. ОУД оценочный уровень доверия (см. ГОСТ/МЭК 15408);

  13. ПО программное обеспечение, приложение;

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

  15. ISO/IEC International Organization for Standardization(ISO) and theInternational Electrotechnical Commission(IEC);

  16. SDLC - Software Development Lifecycle.

Соавтор: (Рустам Гусейнов, специалист по информационной безопасности).

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru