Что такое оуд в образовании простым языком
Что такое оуд в образовании простым языком
организация управленческой деятельности
оценочный уровень доверия
общий уровень действия
Смотреть что такое «ОУД» в других словарях:
ОУД — или Оуд многозначный термин или аббревиатура: Оуд или Ауд нидерладская фамилия Оуд, Якобус Хла Оуд маленькая деревня в вымышленной вселенной Морровинд аббревиатура ОУД Оксид урана(VI) диурана(V) ОУД оценочный… … Википедия
Оуд — Оуд, Якобус Якобус Иоганнес Питер Оуд Якобус Иоганнес Питер Оуд (в некоторых транскрипциях, Ауд) (нидерл. Jacobus Johannes Pieter Oud; 9 февраля 1890, Пурмеренд 5 апреля 1963, Вассенаар) нидерланд … Википедия
Оуд, Якобус — Якобус Иоганнес Питер Оуд (нидерл. Jacobus Johannes Pieter Oud; 9 февраля 1890, Пурмеренд 5 апреля 1963, Вассенаар) нидерландский архитектор и теоретик архитектуры, один из главных представителей функционализма в архитектуре. Биография Учился… … Википедия
Хла Оуд — В Википедии есть проект «TES» В первой и третьей главах The Elder Scrolls можно посетить множество городов и поселений провинции Морровинд. Так же большое количество сведений о них встречается и в других главах в виде книг. Содержание … Википедия
однісінький — [оуд( )н’і/с ін кией] м. (на) кому/ к ім, мн. к і … Орфоепічний словник української мови
Поселения в Морровинде — В первой и третьей главах The Elder Scrolls можно посетить множество городов и поселений провинции Морровинд. Также большое количество сведений о них встречается и в других главах в виде книг. На острове Вварденфелл встречаются преимущественно… … Википедия
Вивек (город) — В Википедии есть проект «TES» В первой и третьей главах The Elder Scrolls можно посетить множество городов и поселений провинции Морровинд. Так же большое количество сведений о них встречается и в других главах в виде книг. Содержание … Википедия
Дагон Фел — В Википедии есть проект «TES» В первой и третьей главах The Elder Scrolls можно посетить множество городов и поселений провинции Морровинд. Так же большое количество сведений о них встречается и в других главах в виде книг. Содержание … Википедия
Маар Ган — В Википедии есть проект «TES» В первой и третьей главах The Elder Scrolls можно посетить множество городов и поселений провинции Морровинд. Так же большое количество сведений о них встречается и в других главах в виде книг. Содержание … Википедия
Молаг Мар — В Википедии есть проект «TES» В первой и третьей главах The Elder Scrolls можно посетить множество городов и поселений провинции Морровинд. Так же большое количество сведений о них встречается и в других главах в виде книг. Содержание … Википедия
Памятка воспитателям Доу «Пять правил проведения ОУД»
1. ОУД – это совместная деятельность с ребенком, направленная на что-то интересное и полезное для его развития, не в форме школьного урока.
2. Основа индивидуально-ориентированного обучения – это разнообразная деятельность детей.
3. В конце ОУД необходимо не только уточнять, что дети узнали, чему научились, но и выяснить, что ещё предстоит узнать.
4. Необходима связь занятий с повседневной жизнью, с субъективным опытом детей.
5. Важна цикличность: периодическое возвращение к уже пройденному, знакомому.
Обучение на ОУД независимо от формы его организации отличается, прежде всего, программностью. Педагог намечает программное содержание, которое должно быть реализовано в ходе занятия.
ОУД имеет определенную структуру, которая во многом диктуется содержанием обучения и спецификой деятельности детей. Независимо от этих факторов в любой ОУД выделяют три основные части, неразрывно связанные общим содержанием и методикой, а именно:
начало, ход ОУД (процесс) и окончание.
Начало ОУД предполагает непосредственную организацию детей: необходимо переключить их внимание на предстоящую деятельность, вызвать интерес к ней, создать соответствующий эмоциональный настрой, раскрыть учебную задачу. На основе объяснения и показа способов действий у ребенка формируется элементарный план: как ему надо будет действовать самому, в какой последовательности выполнять задание, к каким результатам стремиться.
Ход (процесс) ОУД – это самостоятельная умственная или практическая деятельность детей, заключающаяся в усвоении знаний и умений, которые определенный учебной задачей. На данном этапе занятия приемы и обучения индивидуализируются в соответствии с уровнем развития, темпом восприятия, особенностями мышления каждого ребенка. Обращения ко всем детям необходимы только в том случае, если у многих наблюдаются ошибки в выполнении учебной задачи как следствие нечеткого объяснения педагога.
Минимальная помощь оказывается тем, кто быстро и легко запоминает, внимательны, умеют анализировать, сопоставлять свои действия, результаты с указанием педагога. В случае затруднения такому ребенку бывает достаточно совета, напоминания, направляющего вопроса. Педагог дает возможность каждому воспитаннику подумать, попытаться самостоятельно найти выход из затруднительно положения.
Педагог должен стремиться к тому, чтобы у каждого ребенка получился результат, свидетельствующий о его продвижении, показывающий, чему он научился.
Окончание ОУД посвящено подведению итогов и оценке результатов учебной деятельности детей. Качество полученного результата зависит от возраста и индивидуальных особенностей детей, от сложности учебной задачи.
Для ОУД как формы организации обучения характерен ряд признаков:
1. На ОУД идет освоение детьми умений по тому или другому разделу обучения.
2. ОУД проводится со всеми детьми данной возрастной группы, с постоянным составом детей.
4. ОУД занимают особе место в системе воспитательной работы детского сада. ОУД отводится строго фиксированное время в режиме жизни детей, это утренние часы, когда умственная и физическая работоспособность детей наиболее высока.
5. При сочетании ОУД учитывается степень трудности и характер деятельности детей на каждом из них.
Шпаргалка для воспитателя «Алгоритм подготовки ОУД и создания технологической карты»
Андреева Юлия
Шпаргалка для воспитателя «Алгоритм подготовки ОУД и создания технологической карты»
Тема: Алгоритм подготовки ОУД, создания технологической карты
Шпаргалка для воспитателя
I. Определение темы и ведущих понятий
1. Четко определить и сформулировать тему (придумать соответствующее название)
2. Определить место темы в учебном плане.
3. Определить ведущие понятия, на которые опирается данная ОУД (интеграция, виды деятельности, вид, форма).
II. Определение целей и задач
Определить целевую установку ОУД для себя и для детей, понять, зачем данная ОУД вообще нужна. Обозначить обучающую, развивающую и воспитывающую функцию ОУД (триединство задач).
III. Планирование учебного материала
1. Подобрать литературу по теме. Отобрать из доступного материала только тот, который служит решению поставленных задач наиболее простым способом.
2. Серьзно продумать мотивацию, проблемную ситуацию.
3. Подобрать интересные игровые задания,целью которых является:
• воспроизведение,
• творческий подход к заданию.
4. Упорядочить игровые задания в соответствии с принципом «от простого к сложному».
IV. Продумывание «изюминки» ОУД
Каждая ОУД должно содержать что то, что вызовет удивление, изумление, восторг, одним словом, то, что дети будут помнить. При этом важно учесть возраст детей, прием, который подходит для средней, но не подходит для раннего или подготовительной группы. Это может быть интересный факт, неожиданное открытие, красивый опыт, нестандартный подход к уже известному.
V. Группировка отобранного материала
Для этого продумать, в какой последовательности будет организована работа с отобранным материалом, как будет осуществлена смена видов деятельности.
Главное при группировке — умение найти такую форму организации занятия, которая вызовет повышенную активность детей, а не пассивное восприятие нового.
VI. Планирование контроля за деятельностью детей
• как использовать результаты контроля.
Не забывать: чем чаще контролируется работа всех, тем легче увидеть типичные ошибки и затруднения, показать дошкольникам подлинный интерес педагога к их работе.
VII. Подготовка оборудования
После того как воспитатель провел ОУД необходимо провести самоанализтак как адекватная, полная рефлексия помогает педагогу самому разобраться в своих чувствах, беспристрастно посмотреть на свою работу и учесть ошибки при подготовке к последующим ОУД.
Алгоритм составления технологической карты организованной учебной деятельности (ОУД) по развитию речи
Технологическая карта – современная форма планирования педагогического взаимодействия учителя и ученика (далее – ТК, алгоритм организованной учебной деятельности (далее – ОУД, обладающий высокой степенью продуктивности этапов управленческих действий воспитателя и деятельности детей, способствующий достижению результата в обучении и воспитании.ТК можно разделить на три части: вводная; этапы деятельности; ожидаемые результаты.
При написании ТК следует учитывать программу воспитания и обучения для каждой возрастной группы, особенности образовательной области, характер и структуру ОУД, обеспечить смену деятельности, отразить годовые задачи детского сада.
Содержание базового дошкольного воспитанияи обучения направлено на формирование компетентностей по пяти образовательным областям:
«Здоровье» – формирование ЗОЖ.
«Коммуникация» – работа над развитием речи.
«Познание» – организация поисковой, экспериментальной, трудовой деятельности.
«Творчество» – развитие творческих способностей.
«Социум» – воспитание норм поведения.
Структура занятий предполагает активизацию познавательной деятельности, практические задания,активные методы работы: моделирование, игровые, оздоровительные упражнения, отработку практических навыков, рефлексию.
Подготовка к написанию вводной части
Основные параметры ТК: возрастная группа; образовательная область; раздел; тема; программные задачи; подбор материала; словарная работа; билингвальный компонент. Программные задачи делятся на обучающие – начинаются со слов побуждение, продолжение, представление о, подведение детей к, расширение знаний, знакомство, систематизация, закрепление, совершенствование, активизация и т. д. ; развивающие – со слов развитие, формирование и т. д. ; воспитательные – воспитание, привитие, побуждение и т. д.
Написание этапов деятельности
Этапы деятельности состоят из трех блоков:
Мотивационно-побудительный – с его помощью педагог использует методы и приемы, побуждающие ребенка к действию, вызывающие интерес к изучаемой теме.
Организационно-поисковый – воспитатель организует детский коллектив на решение главной задачи, активизирует поисковую деятельность.
Рефлексивно-корригирующий – заключительный блок, дети рассказывают о своих достижениях, результатах.
Мотивационно-побудительный этап включает основные дидактические задачи,которые ставятся и решаются педагогом в начале ОУД: вызвать интерес к содержанию, сконцентрировать внимание детей и раскрыть перед ними учебную задачу. Эффективным является игровой метод, он соответствует возможностям и особенностям дошкольников. В условиях игры легче активизировать внимание, удерживать его на предлагаемом содержании. Проблема определяет цель работы. Возникновение проблемной ситуации, то есть столкновение с противоречием между представлениями ребят и новой информацией, вызывает у них острое чувство удивления или затруднения,которое инициирует выполнение конкретной мыслительной работы: осознать противоречие и сформулировать вопрос. Возникает необходимость освоения нового способа действия, решения учебной задачи нового типа. Рекомендуется ОУД начинать с психолого-педагогического настроя детей на деятельность. Это может быть момент неожиданности (приход героя, внесение предмета, создание игровой ситуации, рассмотрение жизненной ситуации, использование художественного слова и т. д.). Цель этого этапа – создание эмоционального настроя, заинтересованности, сосредоточение внимания через рассматривание, беседу, выполнение упражнений, выражение своего эмоционального состояния по поводу происходящих событий и т. д.
Организационно-поисковый этап – самый объемный, содержательный и насыщенный. В соответствии с программными задачами формируется поиск решения, определение имеющихся знаний, умений и то, чему предстоит научиться для достижения цели, решения задачи, что делает более наглядным сюжетное единство ОУД, помогает детям ориентироваться в ней, придерживаться выбранного пути. Руководство деятельностью детей на занятиях осуществляется методами, которые направлены на организацию первичного восприятия материала, установление связей, расширение знаний, обеспечивают обобщение, закрепление и применение новых знаний. При их отборе учитывается цель и содержание ОУД, место в системе работы по данному разделу, возраст детей. Отличительная особенность методов обучения – наличие приемов проблемно-поискового характера, которые способствуют высокой умственной активности, обеспечивают качественное усвоение знаний, интенсивное развитие интеллекта и творческих способностей, воспитание активной личности и вместе с тем формирование основных компонентов учебной деятельности. Методы обучения,используемые для активизации мыслительной активности детей: чередование видов деятельности; задания на развитие творческого воображения; решение логических задач, проблемных ситуаций, кроссвордов, ребусов; различные виды игр (словесные, грамматические, математические, логические, настольно-печатные, подвижные, народные). Следует помнить, что в связи с приобретением старшими дошкольниками опыта деятельности изменяется удельный вес игровых приемов при постановке и решении учебных задач, позволяющих формировать осознанное отношение. Чрезмерное их использование в процессе занятий препятствует формированию привычки к систематическому труду, умению прилагать усилия, преодолевать трудности, возникновению активности, связанной с волевым напряжением. В то же время недостаточное использование, «сухая» подача учебного материала приведет к тому, что у дошкольников не будет стремления следовать указаниям педагога, выполнять предложенные задания, искать ответы на поставленные вопросы. При решении учебных задач необходимо сочетать игровой и учебный методы, а также продумывать смену деятельности, вводить мотивы, стимулирующие качественное выполнение задания. Важно обеспечить активное участие всех воспитанников и умело использовать совместную и самостоятельную деятельность.
Рефлексивно-корригирующий этап. На этом этапе происходит фиксирование индивидуального шага каждого участника учебного процесса в ходе познания, поиска, исследования. Корректировка процесса познания в целях достижения запланированного результата и его анализа. Оформление ребенком результата своей деятельности.Поиск ответа на вопрос: «Что у меня получилось, а что – нет?». Соотношение действий воспитателя, побуждающих детей к деятельности.
План-таблица рефлексивно-корригирующего этапа
Обобщение новых знаний. Выводы об усвоении знаний, корректировка деятельности детей в дальнейшем. Фиксирование результатов деятельности. Планирование дальнейшей деятельности
Осознают то, чему научились, что узнали. Связывают полученные знания с жизненными ситуациями. Слушают, рассматривают, оценивают, высказываются, осознают причины успехов и неудачи или играют, читают стихотворения, поют, и т. д. Действуют.
Планирование режимных моментов «Алгоритм дня» в старшей группе Цель: Создание благоприятного психологического климата в группе. Утро, прием детей, встреча с родителями. Индивидуальные беседы с каждым.
Алгоритм НОД «Моя Семья» Алгоритм НОД «Моя Семья» /старшая группа/ Цель: продолжать знакомить детей с понятием «семья». Задачи: 1. Образовательная: Закрепить.
Алгоритм прохождения адаптации ребенка в разновозрастной группе Первая неделя. Ребенок находится в детском саду вместе с мамой 3-4 часа (с 8.30 до 12.30). Цель: Заложить основы доверительного отношения.
Форма технологической карты занятия ДОУ Уважаемые коллеги!В настоящее время прохожу обучение на КПК по теме: «Современные педагогические технологии в условиях реализации ФГОС».Ведет.
Консультация «Алгоритм средового метода» Консультация на тему: Алгоритм средового методаЦели: расширять знания педагогов средового метода и технологии в построении образовательного.
Мастер класс создания интеллект-карты на тему «Животные Красной книги Пермского края» Летом экологическое воспитание дошкольников особо актуально. В нашем детском саду идет работа над экологическим проектом на тему: «Твой.
Методические рекомендации «Алгоритм составления рабочей программы воспитателя» Принята на заседании педагогического совета, Протокол №___ от ___20___года. Утверждаю: Заведующий МКДОУ ___ (подпись) Ф. И. О. Приказ.
Консультация для учителей «От конспекта урока к технологической карте» От конспекта урока к технологической карте. Технологическая карта урока- это новый вид методической продукции, обеспечивающей эффективное.
Примерный алгоритм самоанализа НОД Самоанализ непрерывной образовательной деятельности – это общая оценка НОД, характеризующая решение поставленных целей и задач, их реализацию.
Протокол заседания МО воспитателей «Разработка технологической карты внеклассного занятия» Протокол №5 15.03.2016 г. Присутствовало 12 Отсутствовало 5 Повестка. 1. Разработка технологической карты внеклассного занятия Пермякова.
Оценочный уровень доверия (ОУД4) и ГОСТ Р ИСО/МЭК 15408-3-2013. Введение
В настоящее время в ИТ индустрии крайне актуальна тема построения процесса безопасной разработки ПО (по англ. «Secure SDLC» или «Secure software development life cycle»). Некоторые организации и команды самостоятельно приходят к необходимости такого процесса в своих продуктах, свободно выбирают подходящий фреймворк, инструменты и выстраивают свой вариант безопасной разработки. Другие, подпадающие под внешние регуляции, вынуждены разбираться с конкретными, заранее выбранными регуляторами фреймворками или стандартами. Ко второму варианту относятся многочисленные финансовые организации, деятельность которых регулируется Банком России. В нормативах последнего с мая 2018 года стали фигурировать вопросы анализа уязвимостей и появилась аббревиатура ОУД 4.
Подробнее под катом…
Оглавление
Введение и цели цикла
История и эволюция фреймворка
Центральный банк как популяризатор ОУД4
Общие положения и концепции ОУД4
Полезные ссылки и материалы
Приложение (список сокращений)
Введение и цели цикла
На данный момент планируется как минимум три статьи, посвященные отдельным аспектам фреймворка. Первая – вводная, знакомящая читателей с историей вопроса, ключевыми терминами и концепции. Здесь описывается их взаимосвязь, дается общее представление о проблеме. Вторая статья будет описывать роль разработчика ПО, его обязанности и решаемые в рамках безопасной разработки задачи. Третья – раскрывать фреймворк, но уже с позиции оценщика, который осуществляет сертификацию, анализ уязвимостей или оценку соответствия.
Сложность темы, колоссальный объем материалов и многочисленные нюансы практической реализации фреймворка ставят перед нами необходимость выбирать, что именно войдет в цикл статей, а что останется за его скобками для самостоятельного освоения читателями. Скажу банальность, но каждый продукт существует в собственном уникальном контексте, использует свои инструменты для разработки и деплоя, несет под капотом уникальный набор рисков и задач безопасности. Поэтому, чтобы не скатиться в жанр псевдопопуляризации, абстрактной и поверхностной настолько, что в итоге она оказывается напрочь оторванной от реальности, а потому бесполезной, мы просим читателей не стесняться и давать активную обратную связь. Мы будем признательны за конкретные вопросы и аргументированные пожелания, уточнения и замечания; за обмен практическим опытом по результатам вашей работы с фреймворком, чтобы опираясь на большое количество различных примеров сделать его проще для понимания.
В будущем, по мотивам написанных материалов и обратной связи, мы допускаем создание методических материалов в формате гайдов или 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);
Некоторые шероховатости формулировок и весьма общее указание на границы применимости ОУД в историческом 382-П, где было упомянуто «прикладное ПО для осуществления перевода денежных средств», породили разночтения и длительные споры участников рынка об области применения ОУД. Стал популярным вопрос: надо ли проводить работы по ОУД в отношении всех информационных систем, участвующих в переводе денежных средств (например в отношении АБС), или все же речь идет о каких-то наиболее критичных/высокорискованных системах? Впоследствии эти вопросы были разрешены официальной позицией регулятора. Забегая вперед скажем, что требования к работам по ОУД касаются лишь того ПО, которое соответствует одному из двух условий (либо обоим):
ПО распространяется клиентам организации (физическим или юридическим лицам);
ПО доступно через интернет неограниченному кругу лиц (а не закрыто VPN или иными ограничителями).
Рисунок 3. Границы применимости ОУД для приложений финансовых организаций
Рассмотрим, для примера, как эта логика работает для банков. Из п. 4.1 Положения 683-П, которое устанавливает требования к ИБ кредитных организаций, вытекает необходимость работ по ОУД для ПО «распространяемого кредитной организацией клиентам для совершения действий в целях осуществления банковских операций, а также <ПО>, обрабатывающего информацию на участках, используемых для приема электронных сообщений, к исполнению в автоматизированных системах и приложениях с использованием <…>«Интернет» ». В информационном письме Банка России от 8 июля 2020 г. N ИН-014-56/110, посвященном ОУД, приведена ссылка на Профиль Защиты Прикладного ПО, как на методику проведения анализа уязвимостей (подробнее об этом документе поговорим ниже). В свою очередь в п. 2.3.1 упомянутого Профиля развернуто сформулированы критерии подпадания прикладного ПО под работы в соответствии с ОУД4: клиентское ПО и/или выход в интернет. В упомянутой цитате из профиля находим:
«Настоящий ПЗ определяет требования безопасности к ОО. На ОО обрабатывается защищаемая информация на участках, используемых для передачи и приема первичных документов (содержащихся в электронных сообщениях) к исполнению в автоматизированных системах и приложениях с использованием информационно-телекоммуникационной сети «Интернет» (далее – сеть «Интернет»).
ОО представляет собой прикладное программное обеспечение, предоставляемое поставщиком или разработчиком, которое используется для предоставления клиентам финансовых организаций сервисов и доступа клиентам к услугам дистанционного обслуживания. ОО размещается на технологических участках передачи и приема первичных документов (содержащихся в электронных сообщениях) к исполнению финансовой организацией с использованием сети «Интернет». При этом ОО:
устанавливается в изолированном сегменте сети, сопряженном с сетью «Интернет», на инфраструктуре финансовой организации, входит в состав автоматизированной системы финансовой организации и взаимодействует с обеспечивающими компонентами автоматизированных систем (фронт-офисное СПО);
устанавливается на отдельном устройстве или компоненте инфраструктуры клиента финансовой организации, сопряженном с сетью «Интернет», в качестве прикладного программного обеспечения – приложения (клиентское ППО).»
Теперь, когда мы изучили контекст вопроса, определились с границами применимости требований, решили в какой последовательности мы будем прогонять наши продукты через горнило ОУД, давайте поговорим о ключевых особенностях фреймворка и сделаем его обзор.
Общие положения и концепции ОУД4
В общих чертах фреймворк ОУД можно рассматривать как разновидность SDLC, в рамках которого у нас возникает стандартный набор этапов жизненного цикла продукта, типичный для подобных фреймворков. Их сопровождают популярные концепции, такие как: среда функционирования, функция безопасности, управление конфигурациями и другие.
Ключевыми документами, для понимания фреймворка, являются упомянутые в ссылках ГОСТы, которые не только вводят терминологию, но и содержат многочисленные разъяснения и примеры его различных аспектов. Ниже перечень, на наш взгляд, наиболее интересных и полезных:
Общий процесс разработки и тестирования, согласно фреймворку, описывается в первой части ГОСТ 15408. В общем случае жизненный цикл продукта может быть представлен так, как показано на рисунке ниже.
Рис 4. Управление конфигурацией и жизненный цикл продукта (согласно ГОСТ Р 15408-1-2012)
Этапы работ, формирующих ОУД, описываются в третьей части стандарта ГОСТ 15408, как показано на следующем рисунке.
Рис 5. Компоненты, формирующие ОУД
Чтобы лучше понять, как устроен процесс безопасной разработки, согласно фреймворку, попробуем разобрать его в следующих разрезах:
Ключевых концепций и ролей;
Базовых процессов (взаимодействий) и их результатов.
На базовом уровне можно выделить три ключевые роли:
А. Заказчик (может совпадать с пользователем или владельцем), который использует некий продукт и требует соответствие этого продукта неким установленным требованиям к ИБ;
Б. Разработчик, который создает этот продукт и выстраивает его жизненный цикл, в соответствии с требованиями Заказчика;
В. Оценщик, который проверяет соответствие разработанного продукта установленным требованиям.
Здесь нужно сделать оговорку, что несмотря на методологическую рекомендацию разделять описанные выше роли между субъектами во избежании «конфликта интересов» (например, чтобы не проверять самих себя, а привлекать третью, независимую сторону), на практике, в некоторых случаях, такое совмещение ролей допустимо и легально. Например, в последнем абзаце п. 9 Положения 684-П сказано, что анализ уязвимостей по требованиям к ОУД4 может проводиться некредитными финансовыми организациями самостоятельно, без привлечения третьей стороны (для сравнения в текущей редакции 683-П такого пункта нет, и подобные работы необходимо осуществлять с привлечением сторонней организации лицензиата ФСТЭК).
Таким образом, для гипотетической страховой или пенсионного фонда, с собственной разработкой личного кабинета пользователей силами штатных специалистов возможен сценарий консолидации всех ролей и компетенций внутри самой организации, а вот для банка или иной разновидности кредитной организации такой сценарий де-юре запрещен. Если возможности и законы позволяют, то наращивание внутренних компетенций может оказаться рентабельнее ежегодного приглашения внешних подрядчиков, стоимость услуг которых может превышать стоимость ПО, в отношении которого проводятся работы.
Какие же процессы и взаимодействия возникают в ходе работ в соответствии с фреймворком ОУД? Практически каждый процесс ИБ начинается с описания границ проекта и требований, безопасная разработка не исключение.
В общих чертах фреймворк декларирует следующую последовательность действий:
Разработать документацию и политики на продукт, которые регламентируют требования к ИБ приложения и разработки;
Обеспечить практическое применение документов в разработке конкретного продукта;
В ходе тестов, оценки соответствия и/или анализа уязвимостей подтвердить, что установленные на уровне документации и политик требования выполняются де-факто и позволяют достичь необходимого уровня безопасности (по сути защитить продукт от нарушителя ИБ с определенным потенциалом).
Ключевым элементом фреймворка является объект оценки (или ОО, например, ДБО, или какой-то компонент внутри ДБО), к которому предъявляются функциональные требования к безопасности (или ФТБ, например, необходимая реализация системы управления доступом или стойкая криптография), формулируемые в задании по безопасности или профиле защиты (разница между двумя в том, что задание по безопасности обычно создается Заказчиком самостоятельно, под себя; а профиль тиражируется различными институциями как минимально-адекватный стандарт для какого-то класса решений, например для межсетевых экранов или антивирусов). Так как объект оценки существует не в вакууме, а актуальные уязвимости связаны не только с разработкой и проектированием, но и с настройкой и эксплуатацией объекта, важными понятиями являются среда функционирования и конфигурация среды/объекта оценки. Наконец, сам оценочный уровень доверия представляет собой гамбургер из большего или меньшего набора компонент, в зависимости от выбранного уровня (смотри рисунок 5 выше).
В итоге Заказчик организует деятельность Разработчика таким образом, чтобы тот в результате создавал продукт, соответствующий заданным в документации требованиям. При поставке этот продукт должен безопасно и корректно разворачиваться в среде функционирования, с соблюдением всех установленных в документации требований к конфигурации и обслуживания. Оценщик же в свою очередь анализует адекватность созданного продукта установленным требованиям и декларирует свои выводы по результатам проведенного анализа.
Такое подтверждение может осуществляться с помощью двух базовых сценариев:
С помощью сертификации (делается специализированными лабораториями, включенными в систему ФСТЭК);
С помощью оценки соответствия или анализа уязвимостей (делается самостоятельно для себя, либо сторонней организацией с лицензией ФСТЭК на ТЗКИ).
Это разделение нашло свое отражение в упомянутых по тексту положениях Банка России. В порядке убывания сложности и цены указанные сценарии можно разместить следующим образом:
При всех нюансах и вариациях имплементации необходимый минимум документации на приложение включает в себя:
Описание архитектуры безопасности;
Руководство пользователя по эксплуатации;
Проект объекта оценки;
Задание по безопасности.
Для начала такого состава документов нам хватит. Что же касается качества реализации фреймворка и надежности заключений Оценщика, то независимо от выбранного сценария работ, это во многом зависит от соблюдения Заказчиком и Разработчиком установленных семейством 15408 пререквизитов. От выстроенного в организации SDLC и наличия проработанной документации на конкретный продукт. Здесь действует правило аналогичное любому типу анализа защищенности – чем более прозрачным для проверяющих будет ПО, чем полнее окажутся его описания, чем более компетентным и проактивным будет Заказчик, тем больше недостатков и уязвимостей смогут найти проверяющие и тем качественнее окажутся их заключения. Увы, в реальной жизни, в силу дороговизны работ и сложности процесса, указанные выше пререквизиты часто либо отсутствуют, либо находятся в зачаточном состоянии.
Заключение
Полезные ссылки и материалы по теме:
https://malotavr.blogspot.com/ – блог Дмитрия Кузнецова, эксперта Positive Technologies, одного из немногих специалистов, систематически рассматривающих вопросы сертификации ПО и анализа уязвимостей по ОУД4. Написал несколько материалов про требования ЦБ и ОУД4, см. статьи за 2019 год.
https://www.youtube.com/watch?v=0ZoNdaoAeyc&t=658s – обзорный вебинар компании RTM Group, посвященный особенностям фреймворка, с участием компании Safe Tech, описывающий реализацию фреймворка в отношении своего продукта.
f. ГОСТ Р 58143-2018.
https://en.wikipedia.org/wiki/Common_Criteria – Обзор лучших практик по безопасной разработке – статья в вики для желающих самостоятельно углубиться в исторические предпосылки.
Лучшие практики безопасной разработки:
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».
https://www.cbr.ru/information_security/acts/ – Методический документ Банка России «ПРОФИЛЬ ЗАЩИТЫ прикладного программного обеспечения автоматизированных систем и приложений кредитных организаций и некредитных финансовых организаций».
Приложение (список сокращений)
По тексту документа использованы следующие сокращения/условные обозначения:
382-П/Положение 382-П – Положение Банка России от 9 июня 2012 г. № 382-П «О требованиях к обеспечению защиты информации при осуществлении переводов денежных средств и о порядке осуществления Банком России контроля за соблюдением требований к обеспечению защиты информации при осуществлении переводов денежных средств» (актуальная редакция от 07.05.2018, действительно до 01.01.2022 года, отменяется 719-П);
719-П/Положение 719-П – Положение Банка России от 4 июня 2020 г. № 719-П «О требованиях к обеспечению защиты информации при осуществлении переводов денежных средств и о порядке осуществления Банком России контроля за соблюдением требований к обеспечению защиты информации при осуществлении переводов денежных средств»;
672-П/Положение 672-П – Положение Банка России от 09.01.2019 N 672-П «О требованиях к защите информации в платежной системе Банка России»;
683-П/Положение 683-П – Положение Банка России от 17 апреля 2019 г. N 683-П «Об установлении обязательных для кредитных организаций требований к обеспечению защиты информации при осуществлении банковской деятельности в целях противодействия осуществлению переводов денежных средств без согласия клиента»;
684-П/Положение 684-П – Положение Банка России от 17.04.2019 N 684-П «Об установлении обязательных для некредитных финансовых организаций требований к обеспечению защиты информации при осуществлении деятельности в сфере финансовых рынков в целях противодействия осуществлению незаконных финансовых операций»;
162-ФЗ/Федеральный закон № 162 ФЗ – Федеральный закон «О стандартизации в Российской Федерации» от 29.06.2015 N 162-ФЗ;
АБС – автоматизированная банковская система;
ГОСТ Р – национальный государственный стандарт Российской Федерации;
ИБ – информационная безопасность;
ИТ – информационные технологии;
ОУД – оценочный уровень доверия (см. ГОСТ/МЭК 15408);
ПО – программное обеспечение, приложение;
Фреймворк – здесь тоже самое, что стандарт, задающий структуру вокруг которой выстраивается какой-либо процесс или решение задачи;
Соавтор: (Рустам Гусейнов, специалист по информационной безопасности).