|
ADV_FSP.2 Детализация вопросов безопасности в функциональной спецификации; |
|
|
ADV_IMP.2 Полное отображение представления реализации функций безопасности объекта оценки; |
|
|
FDP_IFC.1 Ограниченное управление информационными потоками]. |
|
|
Разработчик должен провести поиск скрытых каналов для реализуемых ОО [выбор: политики управления информационными потоками; политики управления доступом; [назначение: иные политики] ]. |
|
|
Разработчик должен представить документацию по анализу скрытых каналов. |
|
|
Элементы содержания и представления документированных материалов |
|
|
В документации по анализу скрытых каналов должны быть идентифицированы скрытые каналы и должна содержаться оценка их пропускной способности. |
|
|
Документация по анализу скрытых каналов должна содержать описание процедур, использованных для вынесения заключения о существовании скрытых каналов, и информацию, необходимую для анализа скрытых каналов. |
|
|
Документация по анализу скрытых каналов должна содержать описание всех предположений (быстродействие процессора, системная конфигурация, объем памяти и (или) иных), сделанных при анализе скрытых каналов. |
|
|
Документация по анализу скрытых каналов должна содержать описание метода, использованного для оценки пропускной способности канала для наиболее опасного сценария. |
|
|
Документация по анализу скрытых каналов должна содержать описание наиболее опасного сценария использования каждого идентифицированного скрытого канала. |
|
|
Оценщик должен подтвердить, что информация, представленная разработчиком в документированных материалах, удовлетворяет всем требованиям к содержанию и представлению документированных материалов, изложенным в AVA_CCA_EXT.1.1C - AVA_CCA_EXT.1.5C. |
|
|
Оценщик должен подтвердить, что результаты анализа скрытых каналов, выполненного разработчиком, свидетельствуют об удовлетворении ОО соответствующих функциональных требований (по управлению информационными потоками, управлению доступом и (или) иных). |
|
|
Оценщик должен подтвердить правильность результатов анализа скрытых каналов, выполненного заявителем (разработчиком, производителем). |
|
|
ADV_FSP.2 Детализация вопросов безопасности в функциональной спецификации; |
|
|
Оценщик проводит анализ уязвимостей с целью выявления типовых ошибок программирования и иных дефектов, приводящих к возникновению уязвимостей. Проведение анализа уязвимостей Оценщиком включает выполнение следующих работ. 1. Оценщик должен выполнить выявление известных и типовых уязвимостей в ОО. Оценщик должен выполнить поиск информации в общедоступных источниках, чтобы идентифицировать потенциальные уязвимости в ОО. Выявление уязвимостей включает в себя: - выявление известных уязвимостей в сетевых службах; - выявление типовых уязвимостей в веб-приложениях; - выявление известных уязвимостей в программном обеспечении; - выявление учетных записей с паролями, содержащимися в словарях, используемых при проведении исследования. Известные уязвимости могут быть выявлены следующими способами: - идентификацией наименований и версий программного обеспечения ОО, сред его разработки и функционирования с последующим поиском в базах данных известных для них уязвимостей; - запуском тест-программ (эксплойтов), воспроизводящих в полном объеме или частично выполнение компьютерных атак с использованием известных уязвимостей. Сообщения об уязвимостях программного обеспечения рекомендуется получать из различных источников, таких как: - база данных уязвимостей в составе банка данных угроз безопасности информации ФСТЭК России (www.bdu.fstec.ru); - уведомления Центра мониторинга и реагирования на компьютерные атаки в кредитно-финансовой сфере Банка России (ФинЦЕРТ Банка России); - уведомления, публикуемые центрами реагирования на компьютерные инциденты (например, уведомления CERT), платежными системами (например, уведомления платежной системы VISA), производителями технических и программных средств (например, уведомления компании ORACLE); - уведомления, публикуемые в общедоступных базах данных уязвимостей, а также распространяемые по подписке (например, www.cve.mitre.org); - сообщения об уязвимостях в ППО, направляемые сторонними специалистами в адрес организации БС Российской Федерации или публикуемые ими в общедоступных источниках, для чего рекомендуется предусматривать способы оперативной связи с соответствующими специалистами организации БС Российской Федерации. Для веб-приложений должен быть выполнен поиск следующих типов известных уязвимостей: - инъекции, в особенности SQL-инъекции, команды операционной системы, LDAP, SSI и XPath-инъекции; - подбор аутентификационных данных; - небезопасная передача данных, в том числе в процессе аутентификации; - ошибки в контроле доступа (например, небезопасные прямые ссылки на объекты, невозможность ограничения доступа по URL и обход директорий); - межсайтовый скриптинг (XSS); - подделка межсайтовых запросов (CSRF); - расщепление запроса HTTP, сокрытие ответа HTTP; - раскрытие информации о директориях/сценариях; - предсказуемое расположение ресурсов; - раскрытие защищаемой информации; - обратный путь в директориях; - небезопасная конфигурация сервера; - внедрение внешних сущностей (XML, IMAP/SMTP); - загрузка и выполнение произвольного кода; - недостатки защиты от атак типа Clickjacking; - недостатки защиты от атак на функции форматирования строк; |
|
|
Исследование производится путем анализа данных веб-форм, отправки веб-серверу тестовых запросов с варьируемыми значениями параметров запроса и анализа ответов. Идентификация известных уязвимостей программного обеспечения включает в себя: - инвентаризацию программного обеспечения, установленного на исследуемом техническом средстве, с идентификацией наименований и версий программ, а также установленных обновлений безопасности; - выборку из базы данных уязвимостей, относящихся к идентифицированным версиям программ; - исключение из полученной выборки уязвимостей, устранение которых обеспечено установленными обновлениями безопасности. |
|
|
2. Оценщик должен выполнить динамический анализ кода ОО с целью выявления уязвимостей. Динамический анализ кода осуществляется путем выполнения или эмуляции выполнения программы на определенной совокупности наборов тестовых исходных данных. Перед выполнением или в процессе выполнения программа иногда инструментируется путем дополнения ее функциями трассировки выполнения для задания и контроля инвариантов, предусловий, постусловий и др. Динамический контроль проводится с использованием специализированных автоматизированных средств и может включать в себя, в частности: а) исследование особенностей исполнения потенциально опасных функций при задании заведомо некорректных аргументов; б) построение динамических путей исполнения программы и идентификацию точек принятия решений, существенных для выполнения функций обеспечения ИБ; в) поиск защищаемой информации в оперативной памяти и в аргументах функций; г) исследование особенностей исполнения программы при типовых атаках (переполнение буфера, внедрение операторов SQL в данные, используемые для формирования запросов к СУБД). Вне зависимости от применяемых способов и методов анализа кода при его осуществлении рекомендуется использование классификаторов типовых ошибок программирования, например, Общего перечня недостатков (Common Weakness Enumeration, CWE), а также способов выявления различных типов ошибок. Выявленным в рамках контроля кода уязвимостям в коде разрабатываемых компонентов ОО целесообразно присваивать оценку степени их критичности (например, высокая, средняя, низкая). Для каждой выявленной уязвимости с учетом ее критичности принимается решение о доработке программного компонента ОО (и о приоритетности доработки) или о принятии рисков, связанных с наличием уязвимости. |
|
|
При тестировании на проникновение исследователь выполняет поиск уязвимостей ОО, воспроизводя действия злоумышленника. Перед началом работ для исследователя создаются условия, эквивалентные тем, в которых действует потенциальный злоумышленник. Перед проведением тестирования на проникновение рекомендуется определить начальные условия его проведения. Рекомендуется учитывать, что максимальная полнота оценки достигается при внутреннем тестировании на проникновение с использованием предоставленного доступа к среде функционирования ОО. Тестирование на проникновение подразделяется на исследования с предоставлением доступа к ОО и без предоставления такого доступа. При исследовании с предоставлением доступа Оценщику предоставляются учетные записи для доступа к ОО. При исследовании без предоставления доступа к ОО задача самостоятельного получения учетных записей пользователей ОО является составной частью тестирования на проникновение. При необходимости тестирование проводится с разными правами доступа в ОО. |
|
|
При тестировании на проникновение могут использоваться две стратегии предоставления исследователю информации об ОО. При стратегии "черного ящика" исследователь оперирует только теми сведениями об ОО, которые получены им самостоятельно в ходе тестирования на проникновение. При стратегии "белого ящика" исследователю заблаговременно предоставляется вся доступная информация об ОО, включая (при наличии) проектную и эксплуатационную документацию, исходные коды программных компонентов ОО и возможность просмотра параметров настройки компонентов ОО. По расположению разработчика относительно сетевого периметра ОО тестирование на проникновение разделяется на внешнее и внутреннее. Тестирование на проникновение, в зависимости от типа ОО, может включать в себя следующие направления исследований, применимые к ОО и среде его функционирования: а) оценка защищенности веб-приложений; б) оценка защищенности специализированных банковских приложений (специализированного ПО) финансовых организаций; в) оценка защищенности мобильных устройств. При проведении оценки защищенности веб-приложений рекомендуются следующие мероприятия: а) выявление уязвимостей, связанных с раскрытием защищаемой информации о приложении, в том числе путем отправки некорректных сообщений, анализа стандартных системных сообщений об ошибках, поиска защищаемой информации в коде и комментариях веб-страниц; б) получение сведений о структуре файловой системы перебором путей и имен файлов (полный перебор, перебор по словарю, проверка наличия стандартных файлов используемых платформ и средств разработки, поиск резервных копий файлов); в) проверка корректности обработки специальных символов в параметрах запроса (символы форматирования вывода, перевода строки и возврата каретки, перехода в вышестоящий каталог, двойное URL-кодирование); г) проверка корректности обработки параметров различной длины; д) проверка корректности обработки числовых параметров, в том числе не предусмотренных технологией обработки больших величин, отрицательных и нулевых значений; е) проверка корректности приведения и преобразования типов параметров; ж) проверка корректности обработки различного представления пользовательских данных, в том числе дублирование заголовков запроса, дублирование параметров сценария; з) проверка корректности обработки параметров универсального идентификатора ресурса (URI - uniform resource identifier), в том числе возможности подключения произвольного внешнего источника данных или перенаправления на внешний или внутренний веб-сайт, возможности обращения к сетевым протоколам, возможности замены полного пути к ресурсу на относительный; |
|
|
и) проверка наличия ошибок, связанных с обработкой загружаемых файлов, в том числе с обработкой имен файлов без расширения, несоответствием расширения типу файла, альтернативными расширениями для файлов одного типа, специальными символами (включая нулевой символ) в имени файла; к) проверка корректности исполнения сценариев при манипулировании входными параметрами, в том числе атрибутами безопасности, используемыми при управлении доступом; л) проверка возможности подбора аутентификационных данных (паролей, включая словарные, идентификаторов сессий, атрибутов, используемых для восстановления паролей); м) проверка корректности обработки идентификаторов сессий пользователей, в том числе обработки событий завершения сессии, интервалов неактивности, сопоставление идентификатора сессии с дополнительными атрибутами, прямо или косвенно идентифицирующими пользователя или его рабочее место, предотвращение повторного и множественного использования идентификаторов сессий; н) проверка корректности реализации механизмов авторизации; о) проверка корректности противодействия атакам на клиентские приложения, в том числе с использованием межсайтового выполнения сценариев и подделки межсайтовых запросов; п) проверка корректности обработки входных параметров сценариев при внедрении в них команд операционных систем, синтаксических конструкций языков программирования и разметки; р) проверка невозможности обхода средств межсетевого экранирования прикладного уровня путем фрагментации данных, смешивания параметров, замены алгоритма кодирования и формата представления данных, замены специальных символов их альтернативными представлениями. |
|
|
При проведении оценки защищенности специализированных банковских приложений (специализированного ПО) финансовых организаций рекомендуются следующие мероприятия: а) прослушивание сетевого трафика и поиск в нем защищаемой информации, включая пароли и хеш-значения паролей пользователей, идентификаторы сессий, авторизационные маркеры, криптографические ключи; б) запуск программ с различными параметрами, в том числе нестандартными, в том числе с использованием значений различной длины, дублирование отдельных параметров с присвоением им разных значений, включение в значения параметров специальных символов, команд операционной системы, операторов интерпретируемых языков программирования; в) мониторинг характера взаимодействия приложения с операционной системой в процессе функционирования, включая идентификацию файлов данных, содержащих защищаемую информацию, трассировку системных вызовов; г) проверка прав доступа к файлам данных, содержащим защищаемую информацию, а также контроль целостности исполняемых файлов приложения. |
|
|
При проведении оценки защищенности мобильных устройств рекомендуются следующие мероприятия: а) проверка наличия защищаемой информации в файлах данных, журналах регистрации событий, в оперативной памяти устройства, а также передачи защищаемой информации в незашифрованном виде; б) проверка возможности чтения ключей шифрования и электронной подписи, а также записи и замены сертификатов ключей; в) идентификация протоколов взаимодействия и проверка возможности принудительного навязывания устройству использования незащищенных версий протоколов (HTTP вместо HTTPS, TELNET вместо SSH, SSH1 вместо SSH2); г) проверка корректности обработки мобильным приложением входящих параметров, в том числе с использованием значений различной длины, дублирование отдельных параметров с присвоением им разных значений, включение в значения параметров специальных символов, команд операционной системы, операторов интерпретируемых языков программирования; д) проверка наличия в мобильном приложении средств защиты от исследования и возможность неавторизованного доступа к интерфейсу программирования приложений. |
|
|
Элементы содержания и представления документированных материалов |
|
|
Документация анализа уязвимостей Оценщиком должна содержать: а) перечень исследованных компонентов ОО и среды его функционирования с указанием наименований и версий программ, а также установленных обновлений безопасности; б) перечень баз данных уязвимостей, по которым проводился поиск; в) результаты анализа, выполненного для поиска способов, которыми потенциально может быть нарушена реализация ФТБ; г) идентификацию проанализированных предполагаемых уязвимостей; д) перечень выявленных уязвимостей, оценку степени их критичности. Оценку критичности уязвимостей рекомендуется определять в соответствии с методикой Common Vulnerability Scoring System (CVSS); е) рекомендации по устранению выявленных уязвимостей; ж) сведения об устранении обнаруженных уязвимостей; з) демонстрацию для всех выявленных уязвимостей, что ни одна из них не может быть использована в предполагаемой среде функционирования ОО. |
|
|
Результаты анализа уязвимостей Оценщиком должны оформляться протоколами анализа уязвимостей, подписываемыми Оценщиками - непосредственными исполнителями разработки ОО и лицами, участвовавшими в его проверке, с отражением в протоколе сведений о дате мероприятия, проверенной части ОО, выявленных уязвимостях и иных дефектах (при наличии), повторном контроле ОО с подтверждением устранения выявленных уязвимостей, дефектов. |
|
|
1. Отчет о тестировании на проникновение должен содержать: а) описание начальных условий исследования и постановку задачи; б) описание последовательности действий, которые приводили к выявлению уязвимостей или изменению возможностей исследователя, а также решения об отказе от выполнения запрашиваемых действий; в) описание выявленных уязвимостей, оценку степени их критичности; |
|
|
Оценщик должен подтвердить, что информация, представленная заявителем в документированных материалах, удовлетворяет всем требованиям к содержанию и представлению документированной информации, изложенным в AVA_VAN.5.1C. |
|
|
Оценщик должен выполнить поиск информации в общедоступных источниках, чтобы идентифицировать потенциальные уязвимости в ОО. |
|
|
Поиск и проверка устранения в ОО и средах его функционирования известных (подтвержденных) уязвимостей (в том числе уязвимостей "нулевого дня") проводится по результатам анализа общедоступных источников информации об уязвимостях. Сообщения об уязвимостях программного обеспечения рекомендуется получать из различных источников, таких как: а) база данных уязвимостей в составе банка данных угроз безопасности информации ФСТЭК России (www.bdu.fstec.ru); б) уведомления Центра мониторинга и реагирования на компьютерные атаки в кредитно-финансовой сфере Банка России (ФинЦЕРТ Банка России); в) уведомления, публикуемые центрами реагирования на компьютерные инциденты (например, уведомления CERT), платежными системами (например, уведомления платежной системы VISA), производителями технических и программных средств (например, уведомления компании Oracle); г) уведомления, публикуемые в общедоступных базах данных уязвимостей, а также распространяемые по подписке (например, www.cve.mitre.org); д) сообщения об уязвимостях в ППО, направляемые сторонними специалистами в адрес организации БС Российской Федерации или публикуемые ими в общедоступных источниках, для чего рекомендуется предусматривать способы оперативной связи с соответствующими специалистами организации БС Российской Федерации; е) информация об инцидентах защиты информации направляется посредством технической инфраструктуры Банка России - автоматизированной системы обработки инцидентов Центра мониторинга и реагирования на компьютерные атаки в кредитно-финансовой сфере Департамента информационной безопасности Банка России (АСОИ ФинЦЕРТ). |
|
|
В качестве потенциальных должны быть также рассмотрены известные (подтвержденные) уязвимости, выявленные в отличных от сертифицируемых версиях ОО, а также однотипных ОО. Поиск информации о потенциальных уязвимостях необходимо сосредоточить на источниках, в которых содержится информация об однотипном с ОО прикладном программном обеспечении, а также на источниках, содержащих информацию о типовых уязвимостях, ошибках, недостатках языков программирования, используемых при разработке ОО. Результатом такого поиска является выявление всех возможных способов, которыми может быть нарушена реализация функциональных возможностей безопасности ОО. В качестве источников информации о потенциальных уязвимостях наряду с документацией заявителя должны рассматриваться базы данных уязвимостей и угроз безопасности информации, включая Общий перечень недостатков (CWE), Общий перечень шаблонов атак (CAPEC), рассылки и форумы по безопасности, "хакерские" форумы в сети Интернет, в которых сообщается об уязвимостях в конкретных технологиях и атаках на эти технологии. Оценщику не следует ограничиваться рассмотрением общедоступной информации вышеупомянутых источников, ему следует рассмотреть любую другую доступную информацию, имеющую отношение к уязвимостям ОО или среды функционирования ОО при их использовании в представлении реализации ОО. Процесс идентификации проблемных конструкций может быть итерационным (повторяющимся), т.е. идентификация одной проблемной конструкции может привести к идентификации другой проблемной конструкции, которая требует дальнейшего исследования. В случае обнаружения в ОО пригодных для использования известных уязвимостей сертификационные испытания могут быть продолжены только после их устранения разработчиком. |
|
|
Оценщик должен провести независимый методический анализ уязвимостей ОО с использованием документации руководств, функциональной спецификации, проекта ОО, описания архитектуры безопасности и представления реализации, чтобы идентифицировать потенциальные уязвимости в ОО. |
|
|
Независимый методический анализ уязвимостей должен включать выявление типовых ошибок программирования и иных дефектов, приводящих к возникновению уязвимостей. При этом выявлению подлежат уязвимости кода и уязвимости конфигурации ОО. Идентификация потенциальных уязвимостей предусматривает формирование перечня предполагаемых, но не подтвержденных уязвимостей в ОО по результатам исследований доступных документированных материалов и источников информации об уязвимостях. Предположения основываются на допустимых сценариях реализации угроз безопасности информации в заданных средах функционирования ОО. Оценщик должен выполнить контроль информационных объектов различных типов (например, локальных переменных, глобальных переменных, внешних переменных и т.п.). С этой целью оценщик должен исследовать представленную документацию инструментальных средств разработки, чтобы сделать заключение о том, имеются ли в определении языка программирования проблемные конструкции, которые могут быть применены к информационным объектам. В качестве источников информации о проблемных конструкциях языка программирования, которые могут быть применены к информационным объектам, наряду с документацией заявителя должны также рассматриваться базы данных уязвимостей и угроз безопасности информации, включая Общий перечень недостатков (CWE), Общий перечень шаблонов атак (CAPEC), рассылки и форумы по безопасности, "хакерские" форумы в сети Интернет, в которых сообщается об уязвимостях в конкретных технологиях и атаках на эти технологии. В качестве таких проблемных конструкций, которые могут быть применены к информационным объектам, могут выступать, например, преобразование информационного объекта из одного типа данных в другой, использование псевдонимов (альтернативных имен, которые позволяют ссылаться на одну и ту же часть памяти различными способами), указателей (ссылок) на произвольные области памяти, использование стека для передачи фактических параметров между функциональными объектами, динамическое выделение памяти информационным объектам и т.п. Оценщик должен исследовать представление реализации, с тем чтобы сделать заключение о том, что любое использование проблемных конструкций языка программирования применительно к информационным объектам не вносит уязвимостей. Оценщику следует также удостовериться, что конструкции, не предусмотренные соответствующим стандартом языка программирования, не используются в представлении реализации. Оценщик должен также сделать заключение о том, что ввод данных пользователем обрабатывается ФБО таким способом, при котором ФБО защищены от внесения в них искажений вводимыми данными. Следует отметить, что части ОО, которые не относятся к ФБО, могут не исследоваться, если оценщиком проведено обоснование отсутствия их влияния на ФБО. Результатом идентификации потенциальных уязвимостей должен быть перечень потенциальных уязвимостей, которые являются предметом тестирования проникновения и применимы к ОО. Из рассмотрения могут быть исключены потенциальные уязвимости, для которых обосновано, что используемые в среде функционирования меры защиты информации исключают возможность эксплуатации (использования) этих уязвимостей. |
|
|
Оценщик должен провести тестирование проникновения, основанное на идентифицированных уязвимостях, чтобы сделать заключение о том, что ОО является стойким к нападениям, выполняемым нарушителем, обладающим высоким потенциалом нападения. |
|
|
Тестирование проникновения должно проводиться относительно всех идентифицированных потенциальных уязвимостей в ОО из составленного перечня. Для тестирования проникновения разрабатываются тесты, которые должны охватывать все возможные допустимые сценарии реализации угроз безопасности информации в заданных средах функционирования ОО (шаблоны атак). Тесты проникновения должны позволять оценить все возможности нарушителя по эксплуатации (использованию) идентифицированных потенциальных уязвимостей в ОО. Наиболее тщательно должны быть подготовлены и проведены тесты проникновения, связанные с тестированием уязвимостей, которые потенциально могут быть использованы нарушителем для обхода, отключения или преодоления функций безопасности, реализующих основные функциональные возможности ОО, определяемые видом и типом ОО. Для каждой идентифицированной потенциальной уязвимости из составленного списка должны быть разработаны способы тестирования, учитывающие интерфейсы ОО, используемые для выполнения функций безопасности, определены исходные данные и условия, которые необходимы для тестирования, средства тестирования, необходимые для инициирования интерфейсов, а также возможность использования при анализе уязвимостей тестов, которые выполнялись ранее. Результаты тестирования проникновения должны подтверждать стойкость ОО к действиям нарушителя с высоким потенциалом нападения. Если результаты показывают, что ОО, находящийся в заданных средах функционирования, имеет уязвимости, пригодные для использования нарушителем, по компоненту доверия в целом не может быть вынесена положительная оценка. Результаты анализа уязвимостей отражаются в отдельном протоколе, в котором, как минимум, указываются: а) перечень проанализированных источников информации; б) перечень идентифицированных потенциальных уязвимостей (с указанием источника информации, описанием, указанием последствий от использования нарушителем, минимального уровня компетентности нарушителя для подготовки и реализации уязвимости, времени, возможности по доступу, оборудования, требуемого ему для использования уязвимости); |
|
|
1. Проверяющая организация должна выполнить действия в соответствии с пунктом 14.2.5 национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 18045-2013 "Информационная технология. Методы и средства обеспечения безопасности. Методология оценки безопасности информационных технологий" для нарушителя с высоким потенциалом нападения. 2. Результаты анализа уязвимостей отражаются в отдельном протоколе, в котором, как минимум, указываются: а) перечень проанализированных источников информации; б) перечень идентифицированных потенциальных уязвимостей (с указанием источника информации, описанием, указанием последствий от использования нарушителем, минимального уровня компетентности нарушителя для подготовки и реализации уязвимости, времени, возможности по доступу, оборудования, требуемого ему для использования уязвимости); |
|
- Гражданский кодекс (ГК РФ)
- Жилищный кодекс (ЖК РФ)
- Налоговый кодекс (НК РФ)
- Трудовой кодекс (ТК РФ)
- Уголовный кодекс (УК РФ)
- Бюджетный кодекс (БК РФ)
- Арбитражный процессуальный кодекс
- Конституция РФ
- Земельный кодекс (ЗК РФ)
- Лесной кодекс (ЛК РФ)
- Семейный кодекс (СК РФ)
- Уголовно-исполнительный кодекс
- Уголовно-процессуальный кодекс
- Производственный календарь на 2025 год
- МРОТ 2024
- ФЗ «О банкротстве»
- О защите прав потребителей (ЗОЗПП)
- Об исполнительном производстве
- О персональных данных
- О налогах на имущество физических лиц
- О средствах массовой информации
- Производственный календарь на 2024 год
- Федеральный закон "О полиции" N 3-ФЗ
- Расходы организации ПБУ 10/99
- Минимальный размер оплаты труда (МРОТ)
- Календарь бухгалтера на 2024 год
- Частичная мобилизация: обзор новостей