Индивидуальный проект по информационной безопасности

Как выбрать тему

Тема по информационной безопасности чаще всего рассыпается на одном месте: формулировка называет угрозу целиком — «кибербезопасность», «хакерские атаки», «защита персональных данных» — а не конкретный сценарий или измеримое поведение, которое можно проверить за отведённое время.

Рабочая тема проходит три проверки:

1. Есть конкретная задача, которую решает продукт. Не «защита от фишинга», а «инструмент, который проверяет письмо на признаки фишинга по десяти критериям, и его точность на тестовой выборке писем».
2. Материал ограничен по объёму. Названы конкретный тип угрозы, конкретная система или конкретная выборка людей — не «информационная безопасность» целиком, а один сценарий с измеримым результатом.
3. Есть чем доказывать. Результаты тестирования на собственном стенде, данные опроса, разбор конкретных инцидентов — а не общие рассуждения об опасности интернета.

Тему стоит приносить руководителю с тремя пунктами: задача, на чём тестируется (свой стенд, публичные данные, опрос), какой продукт получится на выходе. На «хочу про кибербезопасность» возразить нечем конкретному, а на «хочу собрать тестовый набор фишинговых писем, проверить на нём простой классификатор и сделать памятку по распознаванию» руководитель сразу видит объём и материал.

Таблица показывает общий принцип: правая колонка всегда называет конкретный сценарий и способ его проверить, левая — только область или общую угрозу. Если тема формулируется как «опасность Х» без указания, что именно будет протестировано или измерено — исследовать в ней нечего, и до защиты она не доживёт в исходном виде.

15 тем для быстрого старта

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

1. Фишинговое письмо: разбор десяти реальных кейсов и признаки, по которым их узнать
2. Стойкость паролей одноклассников к перебору: анонимный опрос и расчёт времени взлома
3. Утечки в мобильных приложениях: анализ разрешений у двадцати популярных приложений
4. Двухфакторная аутентификация: почему её не включают — опрос и анализ причин отказа
5. Публичный Wi-Fi: какие данные реально видны при перехвате на открытой сети
6. Социальная инженерия в переписке: разбор пяти сценариев обмана из открытых источников
7. Цифровой след школьника: что можно узнать по открытым соцсетям за час поиска
8. Антивирус против современных угроз: сравнение эффективности на тестовом наборе файлов
9. Шифрование переписки: как работает сквозное шифрование на примере одного мессенджера
10. VPN и приватность: что реально скрывает сервис, а что — маркетинговое обещание
11. Резервное копирование данных: сравнение схем на примере домашней сети
12. Кража аккаунтов в играх: разбор типичных сценариев и как их предотвратить
13. Родительский контроль: что он реально ограничивает — тестирование на своём устройстве
14. Утечки данных компаний: как искать себя в открытых базах скомпрометированных аккаунтов
15. Безопасность интернета вещей: тестирование настроек по умолчанию на одном устройстве

Первые пять тем строятся на одном сценарии и одном источнике данных — они самые компактные и подходят, если сроки сжаты. Темы 6–10 требуют сопоставления нескольких источников или технического стенда и объёмнее по материалу — их логичнее брать в 10–11 профильном информатическом классе. Темы 11–15 — про инфраструктуру и организационные меры, там материал собирается через тестирование конкретных настроек или разбор публичных данных, и это отдельная методика, требующая аккуратности с тем, что законно проверять, а что нет.

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

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

• От атаки на чужую систему — к своему стенду. Не «взлом Wi-Fi сети», а «настройка защиты собственной домашней сети и проверка, что перехватывается на открытом канале».
• От угрозы вообще — к одному типу инцидента. Не «утечки данных», а «утечки конкретного типа в одной категории мобильных приложений».
• От технологии целиком — к одной настройке. Не «шифрование данных», а «одна конкретная реализация шифрования в одном инструменте».

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

План и структура: по главам

Структура проекта по информационной безопасности устроена так же, как у любого другого технического предмета, но содержание глав — про угрозу и защиту от неё:

1. Титульный лист, содержание.
2. Введение — актуальность, задача, объект (система, сценарий или группа людей), предмет (конкретная угроза или мера защиты), цель, задачи.
3. Глава 1 — теоретическая: как устроена угроза или технология защиты, обзор источников по теме.
4. Глава 2 — практическая: тестирование на своём стенде, анализ данных или опрос с таблицей результатов.
5. Заключение — вывод по каждой задаче из введения, а не общие слова о важности кибербезопасности.
6. Список литературы — техническая документация, статьи по информационной безопасности, открытые отчёты.
7. Приложения — логи тестирования, код (если есть), анкеты, скриншоты настроек.

Ключевая ошибка главы 1 — она превращается в пересказ статьи про «топ-10 киберугроз» без выхода на тему проекта. Общий обзор уместен на абзац для контекста, дальше должен идти разбор именно той угрозы или технологии, которая тестируется в главе 2, а не список всех существующих угроз подряд.

Ориентировочный объём по главам для 9 класса — 12–18 страниц без приложений:

Для 10–11 профильного класса пропорции те же, но растёт глубина тестирования и число источников — до 18–25 страниц и до 15–20 источников против 6–10 в девятом.

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

Актуальность: первое, что проверяет руководитель

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

Рабочий ход: сначала фиксируется наблюдение в одном-двух предложениях (одноклассники используют слабые пароли, но никто не считал, сколько времени займёт их подбор; приложение запрашивает разрешения, которые не связаны с его функцией, но пользователи их не читают), потом объясняется, почему это стоит проверить именно сейчас — не «кибербезопасность важна», а «конкретная угроза касается конкретной группы людей вокруг вас, и данных для проверки достаточно». Продукт сразу отвечает на вопрос «кому пригодится» — одноклассникам для памятки по цифровой гигиене, учителю информатики для урока, родителям для настройки родительского контроля.

Подробный разбор актуальности с готовыми оборотами — в статье про введение индивидуального проекта.

Практическая часть: как работать с тестированием и данными

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

• Стенд собирается первым и документируется отдельно. Что использовалось (виртуальная машина, домашняя сеть, тестовые аккаунты), какие настройки менялись — это идёт в приложение и делает результат воспроизводимым.
• Результаты фиксируются в таблице по каждому тесту. Столбцы: сценарий, что менялось, что получилось. Из таблицы потом вырастает вся глава 2.
• Опрос нужен только для тем о поведении людей — какие пароли используют, включают ли двухфакторную аутентификацию, замечают ли фишинг. Для тем про техническую уязвимость опрос ничего не докажет, нужно тестирование.
• Разбор инцидентов строится только на открытых источниках — новости, отчёты компаний о раскрытых уязвимостях, публичные базы утечек. Никогда — на собственной попытке воспроизвести чужую атаку без разрешения.

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

Где искать источники

Без вторичных источников теоретическая глава превращается в пересказ популярных статей без технической точности, а это первое, что спрашивает комиссия: «а откуда эти данные». Рабочие места для поиска:

• «КиберЛенинка» и eLibrary — статьи по информационной безопасности и защите данных из технических журналов, часто в открытом доступе целиком.
• Официальная документация технологий — стандарты шифрования, документация мессенджеров и браузеров по безопасности — точное описание того, как что-то работает на самом деле.
• Отчёты об инцидентах от компаний и регуляторов — публичные разборы утечек и атак с указанием причин, без домыслов.
• Открытые базы проверки скомпрометированных данных — сервисы, которые публикуют статистику утечек без раскрытия личных данных конкретных людей.

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

Продукт: что показать на защите

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

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

Продукт выбирается под тему, а не по принципу «что легче сделать за вечер»:

Подробнее про требования к продукту — в статье про продукт индивидуального проекта.

Пример целиком: от идеи до плана

Идея. Хочется сделать проект про кибербезопасность, но пока непонятно, про что именно — тема слишком общая и звучит как реклама антивируса.

Сужение. Что конкретно интересно? Фишинговые письма — их часто пересылают в чатах класса. Можно ли проверить, как их узнают? Да, если собрать реальные примеры и сделать анонимный опрос одноклассников.

Тема. «Фишинговое письмо: разбор десяти реальных кейсов и как их распознают одноклассники».

Объект. Фишинговые письма и реакция на них у группы школьников.

Предмет. Признаки фишинга и то, насколько уверенно их узнают без подготовки.

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

Задачи. 1) собрать десять реальных примеров фишинговых писем из открытых источников; 2) выделить общие признаки; 3) провести анонимный опрос — сколько признаков узнают одноклассники без подсказки; 4) сделать памятку по итогам разрыва между реальными признаками и тем, что замечают люди.

Продукт. Памятка «как узнать фишинговое письмо за 30 секунд» с примерами из собранной подборки.

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

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

Оформление и защита

Формат страницы и общий подход задаёт ФГОС, точные цифры — интервалы, отступы, требования к титульному листу — устанавливает положение конкретной школы. Специфика для технической темы:

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

Подробный разбор с примерами — в статье про оформление по ГОСТу.

Защита строится вокруг презентации на 8–12 слайдов и речи на 5–10 минут. Для темы информационной безопасности в презентацию обязательно идёт слайд с самим тестовым сценарием — комиссия должна видеть, что именно было проверено, а не только услышать вывод.

На защите проекта по информационной безопасности чаще всего спрашивают:

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

Порядок защиты — в статье про защиту проекта, готовая речь — в статье про речь для защиты, критерии оценивания — в статье про критерии оценивания проекта.

Частые ошибки

Большинство перечисленных ниже ошибок объединяет одно: тема звучит эффектно и «по-хакерски», а за ней не стоит реального тестирования на своём материале.

• Придуманный сценарий атаки. Описана уязвимость, которую школьник прочитал в статье, но не воспроизвёл даже на своём стенде.
• Попытка атаковать чужую систему. Тестирование проводилось на сети или сервисе без разрешения владельца — это не только методическая ошибка, но и юридический риск.
• Тема-лозунг вместо задачи. «Кибербезопасность в современном мире» не называет, что именно будет проверено.
• Нет описания стенда. Результат тестирования есть, а условий, при которых он получен, — нет, воспроизвести нельзя.
• Опрос вместо технической проверки и наоборот. Метод не соответствует типу вопроса — техническая уязвимость проверяется тестированием, а не мнением опрошенных.
• Продукт без проверки на пользователе. Памятка написана, но её не показали ни одному однокласснику до защиты.
• Вывод шире, чем позволяют данные. Из одного протестированного сценария делается вывод про безопасность интернета вообще.

Чек-лист перед сдачей

1. Актуальность объясняет, чего не хватает в стандартном подходе к теме и кому пригодится результат.
2. У темы есть конкретная задача, которую решает продукт, а не только область угроз.
3. Материал ограничен и назван точно — конкретный тип угрозы, конкретный стенд или выборка.
4. Стенд или методика тестирования описаны так, что результат можно воспроизвести.
5. Все тестовые сценарии законны — без атак на чужие системы без разрешения.
6. Привлечены источники за пределами кликбейтных статей про хакеров.
7. Есть таблица или график, сводящий результаты тестирования или опроса.
8. Заключение отвечает на каждую задачу из введения отдельным абзацем.
9. Продукт сделан заранее и проверен хотя бы на одном реальном пользователе.
10. Личные данные (пароли, переписка, скриншоты) в работе обезличены или удалены.
11. Презентация и речь отрепетированы вслух с таймером минимум дважды.

Что дальше

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

Матчасть по каждому шагу: структура проекта · продукт проекта · оформление по ГОСТу · защита проекта · критерии оценивания.

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