А что вообще означает "разделено на части"? если это означает, что между частями бытия есть небытие - то тогда понятно почему это абсурд, но и не интересно т.к. почти очевидно.
Я изначально восприняла "разделено на части" как то, что разные части никак не влияют друг на друга и мы не можем из одной части никаким образом увидеть другую часть. Вот этот вопрос уже более интересный.
Статья интересная, спасибо. Мне пришлось сделать над собой усилие, чтобы не написать гневный комментарий ещё в начале прочтения, но в итоге как-то смогла дочитать и писать его расхотелось)
Про утверждения Парменида о бытии, думаю надо подробнее пояснить, т.к. мне его выводы неочевидны. Например, почему разные части бытия должны быть разделены именно небытием и ничем другим? Если вспомнить многомировую интерпретацию квантовой механики, то разные миры (=части бытия) просто возникают параллельно друг другу, безо всякого пространственно-временного разделителя.
Про классификацию я вроде поняла мысль. Тогда действительно всё просто, про это можно и не писать, т.к. любой аналитик старается упрощать требования за счёт группировки/обобщения сущностей. К безопасности это не имеет отношения.
Про структуру статьи. На самом деле, это вообще всё - про сбор требований.
Я не пишу в статье про сбор всех требований к продукту, только про требования безопасности. Если безопасность не является целевой функцией продукта, то естественно, что начинать нужно не с неё. Начинать нужно с того, что делает продукт нужным и осмысленным. Про это написано много хороших книг, и это не тема данной статьи. Когда мы пришли к пониманию, ради чего мы делаем продукт и описали основные функции/сценарии продукта хотя бы верхнеуровнево (предположим, что с безопасностью они не связаны), тогда уже можно переходить к требованиям безопасности и к содержанию данной статьи.
Законы и стандарты - это нормативные требования, их тоже надо собирать. Я советую начинать именно с них при проработке требований безопасности, а не с вопросов/чеклистов, потому что на нормативные требования мы как правило не можем повлиять. Это значит, что они нам сразу сильно ограничат пространство возможных требований и решений. Зачем тратить время на обсуждение идей, которые не проходят по нормативке?
Модель угроз - это наиболее надёжный способ выявить остальные требования безопасности, кроме нормативных. Без модели невозможно в общем случае обосновать, почему мы предъявляем одно требование безопасности и не предъявляем другое. Ответы на вопросы по чеклисту не дадут полной картины, если они применяются не в рамках построения модели, а как получится. Модель угроз это действительно сложная практика и хорошо, если есть возможность доверить её специалисту. Альтернатив этой практике в плане надёжности и системного подхода к вопросу я не знаю.
То, что я назвала импровизацией - делает то же самое, что и модель угроз, но менее надёжно из-за ситуативного применения.
Ну и самое интересное. Проработка требований к продукту - процесс нелинейный и после каждого из четырёх пунктов возможен возврат к одному из предыдущих. Нормативные требования могут перелопатить всю концепцию продукта. Модель угроз может выявить необходимость в описании дополнительных пользовательских сценариев. И так далее. Если аналитик не задумается о безопасности, то он и не узнает вовремя про необходимость изменения концепции продукта или дополнения пользовательских сценариев. Ну не получается писать требования всегда вот так линейно и по порядку.
Про голосование. Можно применить блокчейн, можно разделение секрета, можно один из известных криптографических протоколов голосования, а можно ещё что-то придумать. Если блокчейн, то ещё алгоритм консенсуса надо выбрать. В любом случае, ничего простого и очевидного я тут не вижу.
Про пропуск сбора требований я совсем не поняла, если честно. Я такого не писала и не имела в виду.
Про классификацию информации мы возможно про разное говорили. Я думала, речь про ценность информации самой по себе (или соответствующий ущерб в случае реализации угрозы), без привязки к способу реализации защиты. Тут классификации можно разные придумать. Если я бы написала "ну, там классов всего 2-3, обычно и так всё понятно", то ко мне пришли бы с закономерным вопросом, а собственно как эти классы определять? И была бы всё равно претензия, что тема не раскрыта. Если же речь про способ защиты единицы информации от разных угроз, то указанный чеклист будет полезен, я сама использую подобные ему. Опять же, немного другими словами я про это писала в статье.
У вас при ЛЮБОМ взаимодействии возникают эти вопросы :) Это просто база, которая собственно все и определяет. Условно аксиоматика. Если хотите, дайте пример и посмотрим.
Мой комментарий про нестандартную систему скорее относился к утверждениям вроде "Имено ИТ безопасность является уже давно и успешно стандартизированной областью, где опыт одного проекта элементарно переносится на другой". Для интереса можно рассмотреть систему подсчёта голосов избирателей, где каждый из участников (организатор, голосующий, наблюдатель) может быть нарушителем. Это уже не так просто взять и откуда-то скопировать, несмотря на то что некоторые подходы к этой задаче известны давно. Или как вариант, государственная биометрическая система, или задача создания безопасного ИИ.
Уязвимость - это по сути невыполнение требоаний, которые вы собрали ранее. Но если вы их не собрали - тогда вам банально сложно формулировать, а что такое уязвимость.
Согласна, поэтому я и написала статью для аналитиков, их часть работы тут очень важна. Но аналитик не соберёт такие требования, из которых будет понятно, что уязвимость, а что нет, если специально этим не озаботится. Само собой это не получается. Чтобы получилось, нужно научиться думать определённым образом, о чём я попыталась рассказать в статье.
Про классификацию информации - если бы я начала рассказывать ещё и об этом, то статью вообще никто бы не осилил :) вообще в статьях на подобные темы, как ни напиши - обязательно кому-нибудь покажется, что часть темы недостаточно освещена. Давайте делать скидку на то, что материал предназначен для людей, которые раньше про безопасность не сильно задумывались.
Действовать по стандарту/чеклисту это прекрасно, когда стандарт/чеклист покрывает интересные нам случаи и применим к нашей системе. Но:
Что если система нестандартная и непонятно, какой чеклист к ней применить?
Что если мы хотим не допустить уязвимости в бизнес-логике, которые не встречаются нигде, кроме нашего приложения? Такие "уникальные и индивидуальные" уязвимости есть в очень многих приложениях.
И вот тут приходится уже думать и делать что-то другое.
По поводу ответов на вопросы - тактика действительно полезная, я про неё написала в начале раздела про импровизацию, просто немного другими словами. Классификация типов информации по ценности тоже помогает, просто не хотелось в неё здесь углубляться, важнее было объяснить азы - что такое риск и из чего он состоит.
А что вообще означает "разделено на части"? если это означает, что между частями бытия есть небытие - то тогда понятно почему это абсурд, но и не интересно т.к. почти очевидно.
Я изначально восприняла "разделено на части" как то, что разные части никак не влияют друг на друга и мы не можем из одной части никаким образом увидеть другую часть. Вот этот вопрос уже более интересный.
Статья интересная, спасибо. Мне пришлось сделать над собой усилие, чтобы не написать гневный комментарий ещё в начале прочтения, но в итоге как-то смогла дочитать и писать его расхотелось)
Про утверждения Парменида о бытии, думаю надо подробнее пояснить, т.к. мне его выводы неочевидны. Например, почему разные части бытия должны быть разделены именно небытием и ничем другим? Если вспомнить многомировую интерпретацию квантовой механики, то разные миры (=части бытия) просто возникают параллельно друг другу, безо всякого пространственно-временного разделителя.
Это ладно, главное что они там наслаждаются тропической жарой и влажностью, очень способствующей умственному труду :)
Про классификацию я вроде поняла мысль. Тогда действительно всё просто, про это можно и не писать, т.к. любой аналитик старается упрощать требования за счёт группировки/обобщения сущностей. К безопасности это не имеет отношения.
Про структуру статьи. На самом деле, это вообще всё - про сбор требований.
Я не пишу в статье про сбор всех требований к продукту, только про требования безопасности. Если безопасность не является целевой функцией продукта, то естественно, что начинать нужно не с неё. Начинать нужно с того, что делает продукт нужным и осмысленным. Про это написано много хороших книг, и это не тема данной статьи. Когда мы пришли к пониманию, ради чего мы делаем продукт и описали основные функции/сценарии продукта хотя бы верхнеуровнево (предположим, что с безопасностью они не связаны), тогда уже можно переходить к требованиям безопасности и к содержанию данной статьи.
Законы и стандарты - это нормативные требования, их тоже надо собирать. Я советую начинать именно с них при проработке требований безопасности, а не с вопросов/чеклистов, потому что на нормативные требования мы как правило не можем повлиять. Это значит, что они нам сразу сильно ограничат пространство возможных требований и решений. Зачем тратить время на обсуждение идей, которые не проходят по нормативке?
Модель угроз - это наиболее надёжный способ выявить остальные требования безопасности, кроме нормативных. Без модели невозможно в общем случае обосновать, почему мы предъявляем одно требование безопасности и не предъявляем другое. Ответы на вопросы по чеклисту не дадут полной картины, если они применяются не в рамках построения модели, а как получится. Модель угроз это действительно сложная практика и хорошо, если есть возможность доверить её специалисту. Альтернатив этой практике в плане надёжности и системного подхода к вопросу я не знаю.
То, что я назвала импровизацией - делает то же самое, что и модель угроз, но менее надёжно из-за ситуативного применения.
Ну и самое интересное. Проработка требований к продукту - процесс нелинейный и после каждого из четырёх пунктов возможен возврат к одному из предыдущих. Нормативные требования могут перелопатить всю концепцию продукта. Модель угроз может выявить необходимость в описании дополнительных пользовательских сценариев. И так далее. Если аналитик не задумается о безопасности, то он и не узнает вовремя про необходимость изменения концепции продукта или дополнения пользовательских сценариев. Ну не получается писать требования всегда вот так линейно и по порядку.
Про голосование. Можно применить блокчейн, можно разделение секрета, можно один из известных криптографических протоколов голосования, а можно ещё что-то придумать. Если блокчейн, то ещё алгоритм консенсуса надо выбрать. В любом случае, ничего простого и очевидного я тут не вижу.
Про пропуск сбора требований я совсем не поняла, если честно. Я такого не писала и не имела в виду.
Про классификацию информации мы возможно про разное говорили. Я думала, речь про ценность информации самой по себе (или соответствующий ущерб в случае реализации угрозы), без привязки к способу реализации защиты. Тут классификации можно разные придумать. Если я бы написала "ну, там классов всего 2-3, обычно и так всё понятно", то ко мне пришли бы с закономерным вопросом, а собственно как эти классы определять? И была бы всё равно претензия, что тема не раскрыта. Если же речь про способ защиты единицы информации от разных угроз, то указанный чеклист будет полезен, я сама использую подобные ему. Опять же, немного другими словами я про это писала в статье.
Мой комментарий про нестандартную систему скорее относился к утверждениям вроде "Имено ИТ безопасность является уже давно и успешно стандартизированной областью, где опыт одного проекта элементарно переносится на другой". Для интереса можно рассмотреть систему подсчёта голосов избирателей, где каждый из участников (организатор, голосующий, наблюдатель) может быть нарушителем. Это уже не так просто взять и откуда-то скопировать, несмотря на то что некоторые подходы к этой задаче известны давно. Или как вариант, государственная биометрическая система, или задача создания безопасного ИИ.
Согласна, поэтому я и написала статью для аналитиков, их часть работы тут очень важна. Но аналитик не соберёт такие требования, из которых будет понятно, что уязвимость, а что нет, если специально этим не озаботится. Само собой это не получается. Чтобы получилось, нужно научиться думать определённым образом, о чём я попыталась рассказать в статье.
Про классификацию информации - если бы я начала рассказывать ещё и об этом, то статью вообще никто бы не осилил :) вообще в статьях на подобные темы, как ни напиши - обязательно кому-нибудь покажется, что часть темы недостаточно освещена. Давайте делать скидку на то, что материал предназначен для людей, которые раньше про безопасность не сильно задумывались.
Действовать по стандарту/чеклисту это прекрасно, когда стандарт/чеклист покрывает интересные нам случаи и применим к нашей системе. Но:
Что если система нестандартная и непонятно, какой чеклист к ней применить?
Что если мы хотим не допустить уязвимости в бизнес-логике, которые не встречаются нигде, кроме нашего приложения? Такие "уникальные и индивидуальные" уязвимости есть в очень многих приложениях.
И вот тут приходится уже думать и делать что-то другое.
По поводу ответов на вопросы - тактика действительно полезная, я про неё написала в начале раздела про импровизацию, просто немного другими словами. Классификация типов информации по ценности тоже помогает, просто не хотелось в неё здесь углубляться, важнее было объяснить азы - что такое риск и из чего он состоит.