Анонс: методические рекомендации по подготовке проектной работы для ВсОШ по информационной безопасности. В материале собран практический маршрут: как выбрать тему, найти актуальность, сформулировать проблему, сделать продукт, проверить результат и подготовить ученика к защите.
Методические рекомендации по подготовке проектной работы для ВсОШ по информационной безопасности: от идеи до защиты
Проектная работа по информационной безопасности — это не просто интересная тема, набор современных терминов и презентация на несколько слайдов. Сильный проект должен пройти понятный путь: от проблемы к решению, от решения к работающему продукту, от продукта к проверке, от проверки к защите.
Об авторской адаптации. Материал подготовлен как авторская методическая переработка подходов к сопровождению проектной работы. В основу легли идеи, обсуждавшиеся на мастер-классе проведенном МИЭМ НИУ ВШЭ в рамках подготовки к ВСОШ по информатике - "Информационная безопасность". Это не дословное воспроизведение слайдов, а инструкция, адаптированная для школьной практики, наставников и участников ВсОШ по информационной безопасности.
Для кого этот материал: для наставников, учителей информатики, руководителей проектных работ и школьников, которые готовят проект по информационной безопасности и хотят пройти путь от идеи до понятной защиты.
Безопасность прежде всего: проекты по информационной безопасности лучше выполнять на учебных стендах, синтетических данных, собственных сервисах или специально разрешённых площадках. Реальные чужие сайты, персональные данные и внешняя инфраструктура не должны становиться объектом экспериментов без разрешения.
1. Почему проектная работа часто проседает
Чаще всего проект «сыпется» не потому, что тема плохая. Обычно проблема в другом: ученик не успевает превратить интерес в исследовательский вопрос, идею — в продукт, а продукт — в доказанный результат.
Типичная ситуация выглядит так: тема выбрана интересная, но слишком широкая; продукт вроде бы есть, но непонятно, что именно он улучшает; проверка проведена формально; презентация рассказывает о процессе, но не доказывает качество результата.
Для информационной безопасности это особенно критично. Здесь важна не только сложность темы, но и доказательная логика работы.
проблема → метод → реализация → проверка → выводы → защита
Если эта связка видна, даже не самый большой проект может выглядеть сильным. Если связки нет, даже эффектная тема воспринимается как набор разрозненных действий.
Итог хорошей подготовки — не только презентация. К защите у ученика должны быть: сформулированная проблема, рабочий продукт или прототип, понятная проверка результата, список ограничений, демонстрационный сценарий и ответы на возможные вопросы жюри.
2. Главный принцип наставника
Наставник не должен писать проект за ученика. Это звучит очевидно, но на практике граница быстро размывается. Сначала наставник помогает сформулировать тему, потом «немного» правит текст, затем подсказывает архитектуру, потом пишет фрагменты кода, а в конце ученик защищает работу, которую не до конца понимает.
На защите это почти всегда становится заметно.
Задача наставника другая: помочь ученику удержать рамку работы. Не дать готовый ответ, а задать правильный вопрос. Не заменить самостоятельную деятельность, а помочь ученику понять, что он делает и зачем.
Наставник помогает
- сузить тему;
- увидеть реальную проблему;
- сформулировать исследовательский вопрос;
- выбрать посильный метод;
- построить план;
- проверить результат;
- подготовиться к вопросам жюри.
Наставник задает рамку, темп и вопросы; ученик делает проект и понимает свой результат.
3. Формула подготовки: «расскажи → покажи → сделай сам»
Проектная подготовка не должна превращаться в лекцию. Ученик может внимательно слушать, соглашаться, кивать — и при этом не продвинуть свой проект ни на шаг.
Поэтому полезна формула: расскажи → покажи → сделай сам.
Расскажи
Объяснить логику проектной работы: что оценивает жюри, зачем нужна проблема, почему важна проверка, чем продукт отличается от красивой идеи.
Покажи
Разобрать примеры слабой, средней и сильной работы. Так ученик начинает видеть качество не по внешнему виду презентации, а по глубине проекта.
Сделай сам
Дать ученику действие: сформулировать проблему, записать вопрос, описать продукт, предложить проверку, назвать ограничения.
Каждый блок подготовки должен заканчиваться действием. Иначе проект остается разговором о проекте.
4. Что реально оценивается в проекте
Проектную работу удобно рассматривать через три крупных блока: исследовательская часть, продукт и защита.
Исследовательская часть
Здесь важно показать, что участник понимает предметную область: какую проблему он увидел, почему она важна, какие есть аналоги, что именно он хочет улучшить или проверить, какие ограничения есть у работы.
В материалах муниципального этапа 2025–2026 года по профилю «Информационная безопасность» участникам 9–11 классов предлагался выбор между направлениями Red Team и Blue Team: первое связано с исследованием, доказательством и демонстрацией уязвимостей, второе — с разработкой решения, повышающего уровень безопасности.
Продукт и техническая реализация
В проекте должен быть предъявляемый результат: скрипт, стенд, анализатор, набор правил, учебный инструмент, демонстрационный прототип, методика проверки или другой технический продукт.
- что именно сделал участник;
- что запускается;
- что проверяется;
- что автоматизировано;
- какие данные использовались;
- можно ли повторить результат.
Защита
Защита — это не пересказ презентации. Это проверка понимания. Участник должен спокойно объяснить проблему, выбранный подход, самостоятельный вклад, способ проверки, ограничения и возможное развитие проекта.
5. Слабая, средняя и сильная работа
| Уровень | Как выглядит | Главный риск |
|---|---|---|
| Слабая | Есть интересная тема, но нет доказательной базы. Проблема общая, продукт не проверен, выводы не связаны с результатами. | «Мы сделали что-то полезное», но не доказали, что это работает. |
| Средняя | Есть прототип и частичная проверка, но мало метрик, ограничения названы поверхностно, защита не всегда уверенная. | Работа уже полезная, но доказательность пока недостаточная. |
| Сильная | Видна связка «замысел → реализация → проверка → выводы», есть воспроизводимость, критерии успеха, ограничения и самостоятельность автора. | Главный риск снижен: участник понимает работу и может доказать качество результата. |
Сильная работа — это не обязательно самая сложная тема. Это работа, где участник может доказать качество своего результата.
6. Где брать идеи, материалы и актуальность
Хороший проект по информационной безопасности редко начинается с готового названия. Обычно сначала появляется интерес: форензика, веб-безопасность, сеть, фишинг, CTF, мониторинг, защита учебной инфраструктуры. Но одного интереса мало.
актуальная проблема → открытые источники → понятный пользователь → технический продукт → проверка результата
Подбор темы лучше начинать не с названия, а с вопроса: где в информационной безопасности есть подтверждаемая проблема, которую школьник может исследовать, смоделировать, частично автоматизировать или показать на безопасном учебном стенде?
Официальные материалы ВсОШ
Первый источник — материалы самой олимпиады: архив заданий, решения, критерии проектного тура, видеоразборы, требования конкретного этапа. В московском архиве материалов 2025–2026 учебного года по информационной безопасности опубликованы задания, решения, критерии и видеоразборы, в том числе по категориям forensics, web, network, crypto, privesc и другим направлениям.
Важно: проект не должен быть копией задания прошлых лет. Задания и разборы полезны как ориентир по стилю мышления, уровню требований и типам задач.
MITRE ATT&CK и MITRE D3FEND
MITRE ATT&CK помогает связать тему проекта с реальными тактиками и техниками злоумышленников: например, показать, какая техника используется, какие признаки можно искать и какие данные нужны для обнаружения. D3FEND полезен для проектов, связанных с защитой: обнаружением, изоляцией, усилением, проверкой или ограничением действий.
Пример: если проект связан с анализом логов, можно выбрать одну технику ATT&CK и сделать учебный детектор признаков этой техники на безопасном наборе данных.
OWASP Top 10
OWASP Top 10 удобно использовать для проектов по веб-безопасности: авторизация, инъекции, ошибки конфигурации, небезопасный дизайн, уязвимые компоненты.
Пример: вместо темы «SQL-инъекции» лучше сформулировать проект как «учебный стенд для демонстрации и обнаружения ошибок валидации пользовательского ввода в веб-приложении».
CVE, NVD, CVSS и CISA KEV
Для проектов про уязвимости полезны базы CVE и NVD, система оценки серьезности CVSS и каталог CISA Known Exploited Vulnerabilities. На их основе можно делать учебные приоритизаторы обновлений, анализаторы риска и модели принятия решений.
Пример: не просто «система учета уязвимостей», а «учебный приоритизатор обновлений, который показывает, какие уязвимости опаснее с учетом серьезности, факта эксплуатации и применимости к учебной инфраструктуре».
7. Тематические направления и примеры проектов
Ниже — не готовые названия «для копирования», а направления, из которых можно получить проект. Каждую тему нужно уточнять под ученика, сроки, инструменты и возможность проверки.
Web и API
Темы: учебный стенд по ошибкам авторизации; анализатор HTTP-заголовков; стенд по ошибкам валидации данных; чек-лист безопасной разработки.
Формулировка: разработка учебного стенда для демонстрации и обнаружения типовых ошибок авторизации в веб-приложениях.
Продукт: мини-веб-приложение, безопасные сценарии, тесты, инструкция, таблица «ошибка → риск → способ исправления».
Форензика
Темы: анализатор артефактов из логов; учебный сценарий расследования инцидента; автоматизация первичного анализа дампа или набора артефактов.
Формулировка: автоматизация первичного анализа учебного набора артефактов инцидента информационной безопасности.
Продукт: скрипт, набор учебных данных, сценарий инцидента, протокол проверки, сравнение ручного и автоматизированного анализа.
Network / мониторинг
Темы: анализатор сетевых логов; классификация подозрительных DNS-запросов; honeypot для учебной локальной сети; визуализация сетевой активности.
Формулировка: учебный анализатор сетевой активности для выявления подозрительных подключений на основе логов.
Мониторинг и детекция
Темы: правила обнаружения для учебного стенда; сопоставление логов с техниками ATT&CK; мини-SIEM; генератор учебных событий безопасности.
Формулировка: учебный стенд для сопоставления событий безопасности с техниками MITRE ATT&CK.
Фишинг и документы
Темы: анализатор признаков подозрительных офисных документов; тренажер по распознаванию опасных вложений; безопасная демонстрация цепочки «письмо → вложение → риск» без вредоносного кода.
Криптография и секреты
Темы: тренажер по ошибкам использования шифрования; демонстрация слабых паролей и хеширования; учебная система проверки стойкости пароля без хранения паролей; тренажер по безопасному хранению API-ключей.
Безопасность школьной или учебной инфраструктуры
Здесь важно не исследовать реальные системы без разрешения. Только учебный стенд, собственные ресурсы или специально выделенная среда.
Хорошая формулировка: методика и учебный инструмент для оценки базовой безопасности школьного образовательного сайта.
Продукт: чек-лист, демонстрационный стенд, скрипт проверки открытых HTTP-заголовков, отчет, рекомендации.
8. Как отличить хорошую тему от красивой, но слабой
Перед тем как утверждать тему, наставнику полезно задать ученику несколько вопросов.
- Какая конкретная проблема решается?
- Кто потенциальный пользователь результата?
- Что будет продуктом?
- Как проверить, что продукт работает?
- Какие данные или сценарии будут использоваться?
- Что ученик сможет показать на защите?
- Какие ограничения у решения?
- Чем проект отличается от готовых аналогов?
Если на эти вопросы нет ответов, тему лучше сузить.
Как улучшить формулировку
| Было | Стало |
|---|---|
| Фишинг и способы защиты | Разработка учебного тренажера для распознавания признаков фишинговых сообщений на основе безопасных примеров |
| SQL-инъекции | Учебный стенд для демонстрации ошибки валидации пользовательского ввода и способов ее исправления |
| Анализ сетевой безопасности | Анализатор учебных сетевых логов для выявления подозрительных подключений по заранее заданным признакам |
| Защита паролей | Тренажер по типовым ошибкам хранения паролей и секретов в учебных программных проектах |
9. Формула хорошей темы
Удобно дать ученику простой шаблон:
Разработка [продукта] для [аудитории], позволяющего [действие] по [объекту/данным] с проверкой по [критерию успеха].
Пример 1: разработка учебного анализатора сетевых логов для участников CTF, позволяющего выявлять подозрительные подключения по заданным признакам с проверкой на размеченном наборе событий.
Пример 2: разработка тренажера по распознаванию фишинговых сообщений для школьников, позволяющего отработать признаки социальной инженерии с проверкой результата до и после прохождения.
Пример 3: разработка учебного стенда по ошибкам авторизации для начинающих разработчиков, позволяющего показать риск неправильной проверки доступа с демонстрацией исправления.
Мини-паспорт проекта
Перед началом работы полезно заполнить короткий паспорт проекта. Он помогает быстро увидеть, есть ли у идеи проблема, продукт, проверка и понятный демонстрационный результат.
| Поле | Что записать |
|---|---|
| Тема | Рабочее название проекта. Лучше, если оно начинается с действия: разработка, исследование, анализ, создание, автоматизация. |
| Проблема | Какая конкретная трудность, риск или задача рассматривается. Не «кибербезопасность важна», а что именно нужно улучшить или проверить. |
| Цель | Какой результат должен быть получен к концу работы. |
| Пользователь | Кому потенциально нужен результат: школьнику, учителю, участнику CTF, начинающему разработчику, администратору учебной инфраструктуры. |
| Продукт | Что будет создано: скрипт, стенд, тренажёр, анализатор, методика, набор правил, прототип, чек-лист, демонстрационная лаборатория. |
| Данные или стенд | На каких безопасных данных или в какой учебной среде будет проверяться работа. |
| Критерий успеха | Как понять, что продукт действительно работает: точность, время выполнения, количество найденных признаков, успешность прохождения тренажёра, снижение числа ошибок. |
| Ограничения | Где решение может не сработать, какие случаи не рассматриваются и почему. |
| Демонстрация | Что ученик покажет на защите: запуск, скриншоты, запись экрана, таблицу результатов, схему, тестовый сценарий. |
Мини-пример: если ученик делает тренажёр по фишингу, в паспорте должны быть не только тема и цель, но и набор безопасных примеров писем, критерии оценки, проверка до и после прохождения тренажёра, а также ограничения: тренажёр не заменяет полноценную систему защиты почты и не должен использовать реальные фишинговые рассылки на людях.
10. Что не стоит брать в проект
Чтобы проект был безопасным и корректным, лучше избегать тем, где ученик:
- проверяет реальные чужие сайты без разрешения;
- собирает персональные данные;
- делает вредоносный код;
- показывает обход защиты на реальных системах;
- публикует рабочие эксплойты;
- сканирует внешнюю инфраструктуру;
- имитирует фишинг на реальных людях без согласования;
- использует чужой код без понимания и указания источника.
Безопасная альтернатива почти всегда есть: учебный стенд, синтетические данные, локальная лаборатория, демонстрационная модель, чек-лист или анализ открытых источников.
11. Типичные ошибки
Ошибки в теме
- тема слишком широкая;
- нет конкретной проблемы;
- интерес подменяет исследовательский вопрос;
- цель звучит красиво, но не измеряется;
- задачи не ведут к результату.
Ошибки в продукте
- продукт не запускается;
- нет инструкции;
- используется чужой код без понимания;
- непонятно, что сделал сам участник;
- результат нельзя воспроизвести.
Ошибки в проверке
- проверка проведена на одном примере;
- нет тестовых сценариев;
- нет критериев успеха;
- не показаны ограничения;
- не объяснено, где метод может не сработать.
Ошибки в защите
- участник читает текст со слайдов;
- не укладывается в регламент;
- не может объяснить термины;
- теряется на вопросе «что сделано самостоятельно?»;
- вместо ответа повторяет фрагмент презентации.
Чаще всего проект проигрывает не из-за идеи, а из-за слабой доказательности.
12. Три роли наставника
Наставник в проекте не всегда делает одно и то же. На разных этапах нужны разные роли.
Фасилитатор
На старте помогает ученику думать: не предлагает готовую тему, а помогает из интереса выйти к проблеме.
Вопросы: что заинтересовало? где есть проблема? кто с ней сталкивается? как поймешь, что результат получился?
Консультант
В середине помогает не утонуть в технических деталях: подсказывает инструмент, источник, способ проверки, но не забирает проект себе.
Тренер
Перед защитой помогает отработать выступление, тайминг, демонстрацию и ответы на вопросы.
Лучше один раз спокойно «провалиться» перед наставником, чем впервые столкнуться с неудобным вопросом уже перед жюри.
13. Дорожная карта проекта
Проект лучше готовить не рывком перед дедлайном, а по этапам.
| Этап | Что делает ученик | Результат этапа |
|---|---|---|
| 1. Тема и проблема | Выбирает направление, формулирует интерес, ищет конкретную проблему, смотрит аналоги. | Тема, проблема, черновая цель, список источников и аналогов. |
| 2. План и среда | Определяет инструменты, данные, сценарий работы, критерии успеха. | Технический план, схема продукта, минимальный сценарий проверки. |
| 3. Первый прототип | Собирает MVP — небольшой, но работающий. | Прототип, первые тесты, список ошибок и доработок. |
| 4. Проверка | Тестирует продукт, собирает результаты, сравнивает подходы, фиксирует ограничения. | Протокол проверки, метрики, таблица результатов, выводы. |
| 5. Защита | Оформляет записку, презентацию, демонстрацию и ответы на вопросы. | Финальный текст, презентация, демонстрационный сценарий, банк вопросов. |
14. Лестница вопросов: от интереса к гипотезе
Хороший проект редко начинается сразу с точной формулировки. Обычно ученик приходит с интересом. Задача наставника — помочь ему подняться по «лестнице вопросов».
| Ступень | Пример |
|---|---|
| Интерес | Мне интересна форензика памяти Windows. |
| Проблема | При анализе дампа памяти сложно быстро выделить подозрительные процессы и сетевые соединения. |
| Исследовательский вопрос | Можно ли сократить время первичного анализа дампа памяти за счет автоматизации поиска типовых артефактов? |
| Гипотеза | Если разработать скрипт для автоматического извлечения процессов, сетевых соединений и подозрительных строк, то время первичного анализа сократится без потери ключевых признаков инцидента. |
| Проверка | Сравнить ручной анализ и анализ с использованием скрипта на нескольких подготовленных дампах. |
Эта лестница помогает ученику уйти от общей темы к проверяемой работе.
15. Банк вопросов жюри
Хороший способ подготовки — заранее пройтись по вопросам, которые быстро показывают глубину проекта.
Замысел
- Какую проблему решает проект?
- Почему она важна?
- Почему выбрана именно эта тема?
- Кто может использовать результат?
Реализация
- Что именно вы сделали самостоятельно?
- Какая часть проекта автоматизирована?
- Какие инструменты использовались?
- Какие данные или сценарии использовались?
Проверка
- Где тестировался проект?
- Какие критерии успеха выбраны?
- Какие метрики использовались?
- Где решение может не сработать?
Понимание и развитие
- Какие есть аналоги?
- Чем ваш подход отличается?
- Какие ограничения есть у проекта?
- Что бы вы улучшили в следующей версии?
Если ученик не может ответить на эти вопросы, проект нужно не украшать, а дорабатывать.
16. Шесть проверок перед защитой
- Проблема и фокус. Участник может за 30 секунд объяснить, какую проблему решает проект.
- Логика решения. Понятна связка: цель, задачи, реализация, проверка, выводы.
- Техническая часть. Участник понимает, как устроен продукт и где его ограничения.
- Проверка результата. Есть тестирование, критерии успеха и понятный протокол проверки.
- Демонстрация. Подготовлен рабочий показ: запуск, скриншоты, запись экрана, схема или демонстрационный сценарий.
- Ответы на вопросы. Участник готов говорить не только о сильных сторонах, но и об ограничениях, ошибках и следующем шаге.
17. Как встроить подготовку проекта в цифровую экосистему
Подготовка проектной работы становится сильнее, если она не живет отдельно от общей образовательной системы.
Контур обучения
Методические материалы, требования, шаблоны, критерии.
Контур практики
Мини-задания, технические упражнения, проверка гипотез.
Контур проекта
Тема, план, прототип, результаты проверки, защита.
Контур коммуникации
Консультации, вопросы, разбор ошибок, репетиции.
Контур витрины
Примеры проектов, инструкции, обезличенные материалы, рекомендации.
Так проект перестает быть разовой работой «к дедлайну» и становится частью понятного маршрута.
Заключение
Проект для ВсОШ по информационной безопасности должен быть не только интересным, но и доказательным. В нем должна быть видна логика: какая проблема выбрана, почему она важна, что сделал участник, как он проверил результат и какие ограничения увидел.
Роль наставника здесь особенно важна. Но хороший наставник не пишет проект за ученика. Он помогает удерживать рамку, задавать правильные вопросы, проверять результат и готовить участника к защите.
Ученик должен выйти на защиту не с заученным текстом, а с пониманием своей работы.
Именно это отличает сильный проект от формально оформленного материала.
Полезные источники
- Архив материалов ВсОШ в Москве, 2025–2026 учебный год
- Официальная страница организаторов регионального этапа ВсОШ по информационной безопасности
- Муниципальный этап, профиль «Информационная безопасность»: задания проектного тура
- Муниципальный этап, профиль «Информационная безопасность»: критерии оценивания
- MITRE ATT&CK
- MITRE D3FEND
- OWASP Top Ten Web Application Security Risks
- CVE
- NVD — National Vulnerability Database
- CVSS — Common Vulnerability Scoring System
- CISA Known Exploited Vulnerabilities Catalog