Триада CIA: конфиденциальность, целостность и доступность

Триада CIA — это модель, с помощью которой специалисты по безопасности говорят, что именно защищает та или иная мера. Она называет три свойства информации и систем: конфиденциальность (confidentiality), целостность (integrity) и доступность (availability). Большинство мер защиты нужны для того, чтобы одно или несколько из этих свойств сохранялись. Если вы можете сказать, какое свойство нарушило событие, вы уже знаете характер ущерба и то, какого рода мера должна была его остановить.

Эта статья продолжает материал Что такое кибербезопасность?. Там безопасность описана как защита информации и систем от вреда. Здесь эта мысль сужается до трёх целей, и вы получите способ раскладывать по ним реальные события.

#Что такое триада CIA

Каждое свойство отвечает на свой вопрос:

• Конфиденциальность: кому разрешено это читать?
• Целостность: осталось ли это неизменным и действительно ли исходит от того, кто указан автором?
• Доступность: могут ли нужные люди пользоваться этим, когда им надо?

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

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

#Почему свойств три, а не одно

За формулой «сделать безопасно» прячутся компромиссы. Система может хранить секреты и при этом быть бесполезной, потому что до неё никто не может достучаться. Она может всё время работать и отдавать неверные данные. Она может быть точной, всегда доступной и всё равно сливать записи не тем людям. Три названных свойства дают возможность задать точный вопрос о каждом и подобрать меры, которые на него отвечают.

Другие фреймворки добавляют термины: подлинность, подотчётность, неотказуемость. Некоторые определения включают подлинность и неотказуемость в целостность, так делает FIPS 199. Какое бы определение вы ни взяли, общей отправной точкой остаётся модель из трёх свойств, поэтому начинайте с неё.

#Конфиденциальность: утёкший файл

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

Конфиденциальность определяет, кто может читать данные, и касается данных при хранении (на диске, в базе), при передаче (по сети) и при использовании (открытых в памяти или на экране).

#Типичные меры для конфиденциальности

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

#Необязательная проверка: шифрование в действии

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

printf 'Patient: J. Example, diagnosis: placeholder\n' > record.txt
export DEMO_PASS='lab-only-passphrase'
openssl enc -aes-256-cbc -pbkdf2 -salt -pass env:DEMO_PASS -in record.txt -out record.enc
od -A x -t x1z record.enc | head -3
openssl enc -d -aes-256-cbc -pbkdf2 -pass env:DEMO_PASS -in record.enc
openssl enc -d -aes-256-cbc -pbkdf2 -pass pass:wrong -in record.enc -out /dev/null

На машине, где это запускалось (Windows 11, Git Bash, OpenSSL 3.2.4), вывод был таким:

000000 53 61 6c 74 65 64 5f 5f e4 81 09 19 9d 68 fe de  >Salted__.....h..<
000010 54 5b 6c 39 12 1a 38 01 b3 03 ac b8 66 be 3b 4b  >T[l9..8.....f.;K<
000020 68 ae 58 39 8f 74 f1 59 23 27 09 fe b7 cf cc 58  >h.X9.t.Y#'.....X<
Patient: J. Example, diagnosis: placeholder
bad decrypt
D4C00000:error:1C800064:Provider routines:ossl_cipher_unpadblock:bad decrypt:../openssl-3.2.4/providers/implementations/ciphers/ciphercommon_block.c:107:

Первые три строки показывают начало шифртекста. Байты после заголовка Salted__ выглядят случайными и меняются при каждом запуске, потому что OpenSSL всякий раз берёт новую соль, так что ваш hex будет другим. Правильная парольная фраза возвращает исходную строку. Неправильная завершается ошибкой bad decrypt, и ничего, кроме этой ошибки, неверный ключ не даёт. Содержимое из текста ошибки узнать нельзя. Код из восьми символов в её начале тоже меняется от запуска к запуску.

#Целостность: подменённая загрузка

Кто-то скачивает установщик с зеркала. Изменённый файл вполне может нормально запуститься, так что проверять надо другое: совпадают ли его байты с тем, что опубликовал вендор.

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

#Хеши: заметить изменение

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

Команды ниже создают файл, записывают его хеш SHA-256 и меняют содержимое:

printf 'Transfer: 10.00 USD to account A\n' > transfer.txt
sha256sum transfer.txt
printf 'Transfer: 1000.00 USD to account A\n' > transfer.txt
sha256sum transfer.txt

Полученный вывод:

f5ff0bd125880721c12f4eeecd95eb1a03fbc98f61dbd4ea2235cd7c902aa936 *transfer.txt
486ca9f3224c8003ff043ae09f3d1bc6cbe5008859a81c08e95da91945812b04 *transfer.txt

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

sha256sum -c release.sha256

Для исходного файла команда напечатала release.txt: OK. После подмены файла она напечатала вот что:

release.txt: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match

Команда завершается со статусом 1, так что скрипт может на этом остановиться.

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

#Цифровые подписи: доказать, кто опубликовал

Эту задачу решает цифровая подпись. Издатель подписывает файл закрытым ключом. Любой, у кого есть соответствующий открытый ключ, может проверить подпись. Атакующий без закрытого ключа не сможет создать действительную подпись для изменённого файла.

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

openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out priv.pem
openssl pkey -in priv.pem -pubout -out pub.pem
openssl dgst -sha256 -sign priv.pem -out release.sig release.txt
openssl dgst -sha256 -verify pub.pem -signature release.sig release.txt

Для исходного файла проверка напечатала Verified OK. После изменения файла та же проверка напечатала Verification failure, а за этим шли строки ошибок OpenSSL с путями к исходникам. Здесь они опущены.

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

#Типичные меры для целостности

• Хеши, опубликованные по каналу, отдельному от загрузки, чтобы атакующий, изменивший файл, не смог изменить и эталон.
• Цифровые подписи на программных пакетах, обновлениях и документах.
• Журналы аудита и управление изменениями, которые фиксируют, кто что изменил и когда. Журналы тоже надо защищать, иначе нарушитель может стереть запись.
• Контроль версий для кода и конфигурации, чтобы от изменения оставались diff и ревьюер.

#Доступность: сайт, который лежит

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

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

#Типичные меры для доступности

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

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

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

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

#Метод, который можно применять снова

1. Назовите актив: файл, базу данных, систему входа, сайт.
2. Для каждого свойства спросите, какой вред будет, если актив раскроют, изменят или он станет недоступен.
3. Оцените каждый вред как низкий, умеренный или высокий. Так же рассуждает FIPS 199 применительно к федеральным системам.
4. Подберите меры сначала для самого серьёзного вреда.
5. Спросите себя, как вы узнаете об отказе меры. Бэкапу нужна проверка восстановления, подписи нужна сверка, а парольной политике нужен способ заметить злоупотребление.

#Упражнение на бумаге: классифицируйте десять инцидентов

Прочитайте каждое описание и напишите одну букву: C (конфиденциальность), I (целостность) или A (доступность). Если подходят два свойства, выберите то, на которое описание делает больший упор, и укажите второе в скобках. Компьютер для этого не нужен. Попробуйте решить все десять, прежде чем смотреть ответы.

1. Из машины крадут ноутбук. Его диск не зашифрован, и список клиентов на нём можно прочитать.
2. Зеркало раздаёт изменённый установщик. Пользователи, которые сравнивают его хеш SHA-256 с опубликованным вендором значением, видят несовпадение.
3. Вымогатель шифрует файловый сервер компании. Три дня сотрудники не могут открыть общие файлы.
4. Сотрудник по ошибке отправляет таблицу с зарплатами на личный адрес.
5. На публичный сайт компании обрушивается поток трафика. Шесть часов клиенты видят таймауты.
6. Инсайдер редактирует запись о переводе так, что сумма показывается как 1,000 вместо 10. Запись об изменении в журнале отсутствует.
7. Атакующий фишингом получает пароль администратора базы данных и скачивает таблицу клиентов.
8. Сервис записи в больнице работает на одном сервере без резерва. Отказ диска выводит его из строя на целый день.
9. Страница оформления заказа отправляет цену из браузера на сервер, и сервер её принимает. Пользователь меняет цену со 100 на 1, и заказ записывается по цене 1.
10. Портал поддержки показывает имена и адреса других клиентов любому вошедшему пользователю.

#Ответы

1. C. Данные мог прочитать любой, у кого оказался ноутбук. Шифрование при хранении защитило бы их.
2. I. Изменённый файл больше не совпадает с опубликованным хешем. Сравнение хешей обнаружило изменение.
3. A. Сотрудники потеряли доступ к своим файлам. Шифрование, которое выполняет вымогатель, тоже меняет файлы, поэтому можно отстаивать и [I]. В описании акцент сделан на простое.
4. C. Данные о зарплатах попали на адрес за пределами компании. Это ошибочное раскрытие, и конфиденциальность всё равно потеряна.
5. A. Трафик не давал легитимным клиентам добраться до сайта.
6. I. Запись изменили без разрешения, а отсутствие записи в журнале ещё и ослабляет подотчётность.
7. C. Украденный пароль привёл к раскрытию таблицы клиентов. Аутентификация относится к мерам конфиденциальности, так что кража пароля стала первым ударом.
8. A. У единственного сервера не было резерва, поэтому один отказавший диск остановил сервис.
9. I. Сервер доверился значению, которое контролирует пользователь, поэтому записанный заказ больше не соответствует настоящей цене. Никогда не позволяйте клиенту задавать цену.
10. C. Персональные данные других клиентов видели пользователи, у которых не было на это права.

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

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

• Считать триаду рейтингом. Какое свойство важнее всего, зависит от системы. Решайте это для каждого актива.
• Думать, что шифрование решает всё. Шифрование защищает данные от тех, у кого нет ключа. Против учётной записи, у которой уже есть право их читать, оно бесполезно.
• Путать хеши и шифрование. Хеш показывает, что что-то изменилось. Содержимое он не скрывает, а хеш короткого, легко угадываемого значения можно обратить подбором.
• Доверять бэкапу, который вы не проверяли. Многие планы восстановления проваливаются при первом настоящем восстановлении.
• Называть каждый инцидент взломом. Многие серьёзные простои возникают из-за ошибки в конфигурации, отказавшего диска или случайного удаления. Триада помогает увидеть в них тоже проблемы доступности или целостности.
• Забывать, что опубликованному хешу нужен доверенный источник. Проверка надёжна ровно настолько, насколько надёжно место, откуда вы взяли эталон.

#Что дальше

Прочитайте целиком вводные разделы NIST SP 800-12 Rev. 1 и определения уровней воздействия в FIPS 199. Там используются слова, которые вы только что узнали, и с ними формальные документы читать будет проще.

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

Чтобы потренироваться, не трогая чужие системы, возьмите несколько своих файлов, запишите их хеши, измените один символ и запустите проверку ещё раз. Потом зашифруйте копию одноразовой парольной фразой, расшифруйте её и попробуйте неправильную фразу. Закончив, удалите черновые файлы. Цель упражнения — увидеть эти свойства в работе. Защищённую систему из команд оболочки вы так не построите.

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

#Источники

• NIST, An Introduction to Information Security, NIST SP 800-12 Rev. 1, June 2017: https://csrc.nist.gov/pubs/sp/800/12/r1/final
• NIST, Standards for Security Categorization of Federal Information and Information Systems, FIPS 199, February 2004: https://csrc.nist.gov/pubs/fips/199/final