Comments 17
Скажу честно, многовато воды :(
Безопасность в ИТ по сути, это ответы на вопросы, которые возникают при доступе к чему-то, за что мы отвечаем. Причем неважно, откуда и к чему. Если это в зоне нашей ответственности, надо а них ответить. Вопросы следующие:
идентификация: кто там?
аутентификация: а ну докажи, что это ты?
авторизация: имееш ли право на доступ?
конфиденциальность: сохраняем ли факт обращения в тайне
целостность: как обеспечить, что анные запроса и ответа не будут изменены
аудит: куд запишем. чтобы потом разбираться
(иногда) персональные данные: а что если там персональные данные?
Я могу что-то пропустить, но это одна из многих вещей, которыми надо заниматься, а эти вопросы часто возникают в начало (а начало в свою очередь бывает на каждые две недели)
-------------
Важно, ответы на вопросы могут сильно зависеть от "ценности" того, к чему обращаются. И тут на помощь приходит классификация информации. Базово, самая незащищенной является публичная инфа. Остальная априори требует минимум механизмов аутентификации и авторизации. Дальше либо на помощь приходит отраслевой стандарт, либо если его нет, то часто и не надо заморачиваться (но ответить все равно надо). Тут никакой магии нет, и 20 видов информации вводить не надо. С опытом приходит
-------------
Как делать? На самом деле, используя более-менее стандартные протоколы, все решения уже придуманы за нас. Есть внешний identity - прекрасно. Нет? Собираем для себя из овна и палок (шутка). Есть key vault - отлично. Нет, куча опий как сделать.
Отраслевые стандарты обычно это прекрасно, так как не все вопросы уже есть ответы и уход возможен только в одну сторону.
Честно говоря, вот это все что написано прекрасно, но в каком-то смысле слишком много. Автор очедь быстро перешел к каким-то попыткам чего-то решать, хотя собрав "ответы на вопросы" в начале, решения придут сами собой на 95%
Но ... наверное кому-то нравится бегать и потом героически переделывать
Действовать по стандарту/чеклисту это прекрасно, когда стандарт/чеклист покрывает интересные нам случаи и применим к нашей системе. Но:
Что если система нестандартная и непонятно, какой чеклист к ней применить?
Что если мы хотим не допустить уязвимости в бизнес-логике, которые не встречаются нигде, кроме нашего приложения? Такие "уникальные и индивидуальные" уязвимости есть в очень многих приложениях.
И вот тут приходится уже думать и делать что-то другое.
По поводу ответов на вопросы - тактика действительно полезная, я про неё написала в начале раздела про импровизацию, просто немного другими словами. Классификация типов информации по ценности тоже помогает, просто не хотелось в неё здесь углубляться, важнее было объяснить азы - что такое риск и из чего он состоит.
Что если система нестандартная и непонятно, какой чеклист к ней применить?
У вас при ЛЮБОМ взаимодействии возникают эти вопросы :) Это просто база, которая собственно все и определяет. Условно аксиоматика. Если хотите, дайте пример и посмотрим.
Конечно, можно пробовать создать свой набор аксиом для той же модели, но не совсем понятно зачем. Плюс так вы гарантируете покрытие
Что если мы хотим не допустить уязвимости в бизнес-логике, которые не встречаются нигде, кроме нашего приложения?
Уязвимость - это по сути невыполнение требоаний, которые вы собрали ранее. Но если вы их не собрали - тогда вам банально сложно формулировать, а что такое уязвимость. Т.е. вы можете придумывать 100500 кейсов и тратить соответственно столько же ресурсов на их закрытие
Классификация типов информации по ценности тоже помогает, просто не хотелось в неё здесь углубляться, важнее было объяснить азы - что такое риск и из чего он состоит.
Опять же, риск сам по себе не существует. Он уже объект второго-третего порядка. Объектом первого порядка есть информация или сервис, далее есть интерфейс доступа, и уже далее риск того, что что-то в интерфейсе пойдет не так, либо будет использован "неучтенный" интерфейс :)
Классификация сразу вам даст:
цену риска, так как (на крайнем примере) кража инфы с публичного сайта не интересна, так как цена вопроса - 0
механизмы защиты
связанные с механизмами уязвимости, для которых, опять же, уже давно есть "таблетки"
Имено ИТ безопасность является уже давно и успешно стандартизированной областью, где опыт одного проекта элементарно переносится на другой. Но чтобы переносить, надо значить "аксиомы" своей системы
---------------
Ну либо выходит "много текста", который все равно меет "дырки"
У вас при ЛЮБОМ взаимодействии возникают эти вопросы :) Это просто база, которая собственно все и определяет. Условно аксиоматика. Если хотите, дайте пример и посмотрим.
Мой комментарий про нестандартную систему скорее относился к утверждениям вроде "Имено ИТ безопасность является уже давно и успешно стандартизированной областью, где опыт одного проекта элементарно переносится на другой". Для интереса можно рассмотреть систему подсчёта голосов избирателей, где каждый из участников (организатор, голосующий, наблюдатель) может быть нарушителем. Это уже не так просто взять и откуда-то скопировать, несмотря на то что некоторые подходы к этой задаче известны давно. Или как вариант, государственная биометрическая система, или задача создания безопасного ИИ.
Уязвимость - это по сути невыполнение требоаний, которые вы собрали ранее. Но если вы их не собрали - тогда вам банально сложно формулировать, а что такое уязвимость.
Согласна, поэтому я и написала статью для аналитиков, их часть работы тут очень важна. Но аналитик не соберёт такие требования, из которых будет понятно, что уязвимость, а что нет, если специально этим не озаботится. Само собой это не получается. Чтобы получилось, нужно научиться думать определённым образом, о чём я попыталась рассказать в статье.
Про классификацию информации - если бы я начала рассказывать ещё и об этом, то статью вообще никто бы не осилил :) вообще в статьях на подобные темы, как ни напиши - обязательно кому-нибудь покажется, что часть темы недостаточно освещена. Давайте делать скидку на то, что материал предназначен для людей, которые раньше про безопасность не сильно задумывались.
Для интереса можно рассмотреть систему подсчёта голосов избирателей, где каждый из участников (организатор, голосующий, наблюдатель) может быть нарушителем.
Ну так все тоже самое. Вы определяете точки взаимодействия, для них отвечаете на вопросы выше. В чем проблема то?
Ну к примеру, если вы подозреваете "организатора", то тогда правильным ответом на вопрос "авторизации" операции будет использование, к примеру, подхода, когда требуется авторизация двух и более человек, которые не могут вступить в сговор (либо такой сговор считается допустимым и должен выяляеться постфактум). Можете применить тот же блокчейн, который идеально подходит для такой среды и прописать правила авторизации транзакции в контрактах. И требования к контракту - это уже чистая бизнес аналитика по сбору требований
Просто это надо взять и, сорян за прямоту, работать. Т.е. декопозировать на операции, их классифицировать и отвечать на "вопросы" для каждого класса эквивалентности.
Вообще задача "авторизации" операций в условиях допустимого внешего или внутреннего "злоумышленника является довольно таки популярной в корпоративной среде. Те же банки, страховые все время имеют дело с подобными кейсами
Согласна, поэтому я и написала статью для аналитиков, их часть работы тут очень важна. Но аналитик не соберёт такие требования, из которых будет понятно, что уязвимость, а что нет, если специально этим не озаботится.
Он и не должен. В этом и прикол, что если вы не начали с "аксиом" - то действительно не будет понятно, что уязвимость, а что - нет :) Т.е. вы по факту пропускаете сбор требований в части ИТ безопасности, а потом ... ну вы поняли.
Но опять же, я ж не настаиваю. Может вам нравится именно так, тут вам решать
А тут сбор как раз относительно несложен, так как бы видите сами - все эти термины просты и легко находятся в обычной жизни.
Про классификацию информации - если бы я начала рассказывать ещё и об этом, то статью вообще никто бы не осилил
А тут как раз нечего рассказывать :) Ну смотрите, к примеру "голос изберателя". Идете последовательно:
идентификация: каким способом гражданин говорит что он - это "он"? Отвечаете :) Это явно будет прописано взаконе о выборах, или если это "частая лавочка" - спрашиваете заказчика
аутентификация - как это проверить. К примеру, посмотреть в паспорт, попросить наложить персональную подпись с помощью сертификата. По паспорту можно накрутить проверки, в зависимости от страны и технологии изготовления.
авторизация - если это сертификат - то тут достаточно ответа центра, что сертификат валиден, если паспорт - то токена сотрудника, который сидит в избирательной комиссии
и т.д. по вашей задаче
тут нет никакой особенной магии
У вас есть ваша дата модель, там уже есть все объекты. Для доступа к ним есть интерфейсы. Вам же важно их классифицировать не вообще, а исключительно в контектсе задачи обеспечения безопасности. А часто классов будет 2-3, так как даже тезнически проще все под одну гребенку
Про голосование. Можно применить блокчейн, можно разделение секрета, можно один из известных криптографических протоколов голосования, а можно ещё что-то придумать. Если блокчейн, то ещё алгоритм консенсуса надо выбрать. В любом случае, ничего простого и очевидного я тут не вижу.
Про пропуск сбора требований я совсем не поняла, если честно. Я такого не писала и не имела в виду.
Про классификацию информации мы возможно про разное говорили. Я думала, речь про ценность информации самой по себе (или соответствующий ущерб в случае реализации угрозы), без привязки к способу реализации защиты. Тут классификации можно разные придумать. Если я бы написала "ну, там классов всего 2-3, обычно и так всё понятно", то ко мне пришли бы с закономерным вопросом, а собственно как эти классы определять? И была бы всё равно претензия, что тема не раскрыта. Если же речь про способ защиты единицы информации от разных угроз, то указанный чеклист будет полезен, я сама использую подобные ему. Опять же, немного другими словами я про это писала в статье.
Про пропуск сбора требований я совсем не поняла, если честно. Я такого не писала и не имела в виду.
То что я указал - это скелет для сбора требований по безопасности. Мне то все равно, хотите пользуйтесь, хотите - нет
Если блокчейн, то ещё алгоритм консенсуса надо выбрать. В любом случае, ничего простого и очевидного я тут не вижу.
Ну понятно, не все сразу. Но как минимум задача декомпозирована до "простых" блоков, которые в целом независимы. А дальше уже можно есть по частям, как кочан капусты :)
ующий ущерб в случае реализации угрозы), без привязки к способу реализации защиты. Тут классификации можно разные придумать. Если я бы написала "ну, там классов всего 2-3, обычно и так всё понятно", то ко мне пришли бы с закономерным вопросом, а собственно как эти классы определять?
Если обнаружена разница. К примеру, вы продумываете аутентификацию. По сути, обычно вариантов немного и к одному "слою интерфейсов" применяется один метод аутентификации. Ну максимум два, один для внешний "пользователей", второй - для внутренних.
Тоже с целостностью. По сути вам надо решить, закрываете ли вы какую-то цепочку передачи данных, к примеру подписью, либо подписями, либо нет.
А дальше банально, мальчики налево, девочки направо :)
Опять же, немного другими словами я про это писала в статье.
Ну смотрите. Ваша статья. У вас три подхода
Следовать правилам: опираемся на законы и стандарты - это прекрасно, но как раз мимо, кроме тех случаев, когда повезло и вто-то уже все написал
Формировать своё видение: используем модель угроз и нарушителя - вы сразу начинаете с "угроз", не выписав требования. Как бы - а чему кто и как угрожает? А как понять, что это угроза?
Импровизировать! Решаем проблемы по мере поступления - ну все, решаем по мере поступления
Сам же этап сбора требований пропущен, что в целом уже все определяет. Я же нписал вам скелет для сбора требований, который сводится к простым вопросам и дает вам основу для остального.
Ну дальше табличка есть, и снова там нет СБОРА ТРЕБОВАНИЙ.
Что самое интересное, построение модели угроз - это задача, как правило, для специально обученных людей. Не то, чтобы они самые умные, просто знают до фига и имеют опыт. Я бы лично не взялся, так как банально для меня это может быть маленький этап проект, а для них - 80% времени
Может я не заметил, но где совет "собирать требования" и как это делать - я ХЗ
Про классификацию я вроде поняла мысль. Тогда действительно всё просто, про это можно и не писать, т.к. любой аналитик старается упрощать требования за счёт группировки/обобщения сущностей. К безопасности это не имеет отношения.
Про структуру статьи. На самом деле, это вообще всё - про сбор требований.
Я не пишу в статье про сбор всех требований к продукту, только про требования безопасности. Если безопасность не является целевой функцией продукта, то естественно, что начинать нужно не с неё. Начинать нужно с того, что делает продукт нужным и осмысленным. Про это написано много хороших книг, и это не тема данной статьи. Когда мы пришли к пониманию, ради чего мы делаем продукт и описали основные функции/сценарии продукта хотя бы верхнеуровнево (предположим, что с безопасностью они не связаны), тогда уже можно переходить к требованиям безопасности и к содержанию данной статьи.
Законы и стандарты - это нормативные требования, их тоже надо собирать. Я советую начинать именно с них при проработке требований безопасности, а не с вопросов/чеклистов, потому что на нормативные требования мы как правило не можем повлиять. Это значит, что они нам сразу сильно ограничат пространство возможных требований и решений. Зачем тратить время на обсуждение идей, которые не проходят по нормативке?
Модель угроз - это наиболее надёжный способ выявить остальные требования безопасности, кроме нормативных. Без модели невозможно в общем случае обосновать, почему мы предъявляем одно требование безопасности и не предъявляем другое. Ответы на вопросы по чеклисту не дадут полной картины, если они применяются не в рамках построения модели, а как получится. Модель угроз это действительно сложная практика и хорошо, если есть возможность доверить её специалисту. Альтернатив этой практике в плане надёжности и системного подхода к вопросу я не знаю.
То, что я назвала импровизацией - делает то же самое, что и модель угроз, но менее надёжно из-за ситуативного применения.
Ну и самое интересное. Проработка требований к продукту - процесс нелинейный и после каждого из четырёх пунктов возможен возврат к одному из предыдущих. Нормативные требования могут перелопатить всю концепцию продукта. Модель угроз может выявить необходимость в описании дополнительных пользовательских сценариев. И так далее. Если аналитик не задумается о безопасности, то он и не узнает вовремя про необходимость изменения концепции продукта или дополнения пользовательских сценариев. Ну не получается писать требования всегда вот так линейно и по порядку.
Про классификацию я вроде поняла мысль. Тогда действительно всё просто, про это можно и не писать, т.к. любой аналитик старается упрощать требования за счёт группировки/обобщения сущностей. К безопасности это не имеет отношения.
Ответы на перечисленные мною вопросы и есть требования ИТ безопасности :) А классификация уменьшает количество "ответов". которые надо внедрить :)
Я не пишу в статье про сбор всех требований к продукту, только про требования безопасности
Вы можете указать, где вы их собираете согласно статьи?
Законы и стандарты - это нормативные требования, их тоже надо собирать. Я советую начинать именно с них при проработке требований безопасности
Только для специфических организаций, и то частично. Тем более, что если вы посмотрите, требования выдвигается не "вообще", и применительно к определенной информации или сервисам :)
Зачем тратить время на обсуждение идей, которые не проходят по нормативке?
Потому что нормативка не полна :)
Модель угроз - это наиболее надёжный способ выявить остальные требования безопасности, кроме нормативных.
Угроз к чему, если нет требований? Как может возникнуть угроза, к примеру неавторизаванного доступа, если нет требований по авторизации? Или угроза "учетки данных", если нет требований к конфиденциальности?
Ну не получается писать требования всегда вот так линейно и по порядку.
Я вам написал почему еще в первом комметарии :) Но это ваше право продолжать строить модель угроз без требований и импровизировать. Только статьи писать не стоит :)
Если получен доступ к неработоспособному объекту, то с доступом всё хорошо, а с безопасностью - беда.
Если получен доступ к неработоспособному объекту, то с доступом всё хорошо, а с безопасностью - беда.
Я не очень понял, как это связанно с моим комментарием, сорри
Безопасность в ИТ по сути, это ответы на вопросы, которые возникают при доступе к чему-то, за что мы отвечаем.
идентификация: кто там?
аутентификация: а ну докажи, что это ты?
авторизация: имееш ли право на доступ?
конфиденциальность: сохраняем ли факт обращения в тайне
целостность: как обеспечить, что анные запроса и ответа не будут изменены
аудит: куд запишем. чтобы потом разбираться
(иногда) персональные данные: а что если там персональные данные?
Пройдя 73 аутентификации и 85 идентификаций, можно получить доступ (всё хорошо), конфиденциально, и данные, переданные будут целостными, всё будет записано в аудит, и даже персональные тож, к приложению (например), где нажимается кнопочка "покрасить", а выполняется действие "удалить" - это называется неработоспособным объектом (беда с безопасностью).
Контекст дискуссии (как пишет автор) - "разработке системы, важной с точки зрения безопасности".
Код - только часть системы
Безопасность поймешь, когда выпишешь каждый пункт того же ГОСТа в табличку вида
Пункт | требование | как выполняется/митигируется | комментарий |
Требования безопасности: пособие для аналитика