Security by Obscurity / Security by Design — принципиальная разница?
Скажем, SSH. Если используется SbO, то это например установка SSH не на дефолтный порт, если SbD, то сложный пароль, верно я понимаю?
Но ведь и в том и в другом случае, безопасность основывается на том, что атакующий не имеет какой-то информации об атакуемой системе — только в одном случае эта информация — порт, на котором висит демон, а в другом — пароль.
Так в чём разница? Хотя я уже догадываюсь, что разница в том, что если безопасность основана на секретном алгоритме, то он может быть подобран по частям и затраты на избежание компрометации — полная смена алгоритма, а в случае ключа, можно быстро сменить ключ целеком.
Но это всё, больше принципиальной разницы между SbO и SbD нету?
Угу, SbO это если бы исходники были закрыты, использовались хрен знает какие самопальные алгоритмы шифрования и т.п.
А порт это да, можно считать еще одним компонентом пароля, как ключ или логин\пасс, заставляющий всё время его указывать при подключении 🙂
>Если используется SbO, то это например установка SSH не на дефолтный порт Спроси у nmap’а, что висит на недефолтном порту.
Security through Obscurity это метод защиты, главная часть которого основана на скрытии алгоритма защиты. То есть, если злоумышленник узнает алгоритм, то дальнейшая работа ему очень облегчается. Канонический пример — стеганография.
Security by Design — это когда даже при известном алгоритме сложность атаки все равно очень большая. Например, алгоритм РСА известен каждому школьнику, но пока нету методов взлома за приемлемое время.
недефолтный порт — мера только против хакеров-ботов. 22 закрыто, переходят к следующему IP.
А если IPS и при скане портов бан, а сам порт где-то выше 15000?
SbO — это не только проблемы со сменой алгоритма, а еще куча проблем с реализацией/стандартизацией, а главное — форсированное развитие велосипедостроения.
Но это всё, больше принципиальной разницы между SbO и SbD нету?
Это все. Мало? Эти подходы часто объединяют, особенно, военные. Но лучше при расчете степени надежности системы SbO не учитывать, пусть будет дополнительным «бонусом».
Что касается порта SSH — то он не может рассцениваться как часть ключа/пароля, ибо может подбираться независимо. Т.е. этим самым вы не усложняете перебор не _в_ 65535 раз, а _на_ 65535 операций. Конечно, можно запустить на каждый TCP порт по SSH-подобному демону, который будет симулировать начало соединения по SSH, но отвергать любой пароль, тогда перебор действительно усложнится в разы. Но нафиг оно надо, если увеличение длины пароля на 3 символа дает результат не хуже.
> А если IPS и при скане портов бан, а сам порт где-то выше 15000?
А если злоумышленник сидит на канале между вами и сервером, и может достать номер заветного порта просто поймав один пакет от вашего общения с сервером?
> Но нафиг оно надо, если увеличение длины пароля на 3 символа дает результат не хуже.
Что бы уменьшить потребление системных ресурсов (ведь на проверку подлинности надо довольно много вычислений) демоном ssh и не загрязнять логи мусором
> Что бы уменьшить потребление системных ресурсов (ведь на проверку подлинности надо довольно много вычислений)
На проверку подлинности. чего? Демон SSH существенно есть проц только при расшифровке симметричного ключа, который приходит от клиента. И то, это занимает примерно 200мсек одного ядра современного проца. К паролю и к его длине эта операция не имеет никакого отношения.
В логи пишется пароль? Чего только не узнаешь на ЛОРе.
Принципиальная разница простая. В твоём случае у «сложного пароля» пространство значений сильно больше чем пространство значений портов. В случае велоалгоритма разница тоже простая: если этот секрет индивидуален для каждого абонента — можно думать, но в практическом аспекте смысла в таком решении не много. А если велоалгоритм распределен между всеми участниками, то компрометация алгоритма одним участником ведет к жопе у всех. В отличии от «пароля», который опять же, индивидуален для всех участников процесса.
Но самое интересное начинается тогда, когда велоалгоритм придумывают левые люди, без апробаций, консультаций и вообще обсуждений. SbO же.
>алгоритм РСА известен каждому школьнику
не наговаривай на школьников
Исходя из принципа, что всё тайное может стать явным, а так же настоящая безопасность не должна базироваться на секретности алгоритма/метода, то SbO можно игнорировать, уделяя внимание SbD.
А смысл тогда перевешивать, только потом лишние ключи добавлять к sftp или scp, например, теряется унифицированность. Логи и так замусоренными не будут, я об этом писал недавно http://www.linux.org.ru/jump-message.jsp?msgid=6406186&cid=6408225
В логи пишется пароль? Чего только не узнаешь на ЛОРе.
Это как в бубунте при установке?
> если злоумышленник узнает алгоритм, то дальнейшая работа ему очень облегчается. Канонический пример — стеганография.
В стеганографии тоже используются открытые алгоритмы и закрытые ключи, ровно та же security by design.
Ну, бубунта писала же пароль первичного пользователя (который в sudoers с полными правами, так что он — администратор) в логи установки, читаемые всеми подряд. Ты не знал?
Я думал, это все знают.
В незашифрованном виде, конечно.
И какой путь к логу?
Гугли. Это была эпичная бага ;).
Не знал. И не догадывался — слишком уж грубое нарушение безопасности.
В стеганографии тоже используются открытые алгоритмы и закрытые ключи, равно та же security by design.
Ты о чем? Стеганография — это способ скрытой передачи информации в незашифрованном виде путем скрытия самого факта передачи. Можно, безусловно, комбинировать ее с криптографией, но это уже не будет стеганография в чистом виде.
Бубунта — она такая.
> путем скрытия самого факта передачи.
Вот именно. Давай рассмотрим типичное приложение стеганографии — водяную метку. Предположим, что у тебя есть сто тысяч изображений с этими метками, и ты хочешь использовать этот факт для подтверждения своих авторских прав на них в случае нарушений этих прав.
Есть несколько вариантов: 1) ты используешь один алгоритм для всех изображений, при необходимости доказательства раскрываешь алгоритм, остальные изображения у тебя крадут, производя такие искажения, что твой алгоритм не распознаёт метку; 2) используешь уникальные алгоритмы для каждого изображения — без комментариев; 3) используешь один хорошо проработанный алгоритм, стойкий к искажениям изображения, с использованием ключа, для доказательства предъявляешь ключ от конкретного изображения.
Какой вариант тебе больше по душе?
>Стеганография — это способ скрытой передачи информации в незашифрованном виде путем скрытия самого факта передачи.
4.2 Стеганография — это просто скрытие факта существования сообщения. Никакого «в незашифрованном виде» в определении нет. В классической стеганографии сообщения передавались незашифрованными, да, но это не есть признак, присущий стеганографии как таковой, а признак необязательный. В современной стеганографии симметричное шифрование используется как просто ещё один способ скрыть факт наличия сообщения. Не зная пароля, ты не сможешь определить, есть ли в картинке сообщение, даже зная алгоритм скрытия.
Операционная система, ориентированная на безопасность
Аутентификация
Многофакторная аутентификация
Авторизация
Безопасность, ориентированная на данные
Обфускация кода
Шифрование
Брандмауэр
Система обнаружения вторжений
Система обнаружения вторжений на основе хоста (HIDS)
Информация о безопасности и управление событиями
Мобильный безопасный шлюз
Самозащита рабочего приложения
Безопасность веб-приложений
Безопасный по дизайну (SBD) в разработке программного обеспечения означает, что программные продукты разрабатывались с самого начала для обеспечения безопасности .
Альтернативные тактики и шаблоны безопасности рассматриваются в начале разработки программного обеспечения, лучшие выбираются и применяются архитектурой, и они используются в качестве руководящих принципов для разработчиков . Также рекомендуется использовать шаблоны проектирования, которые положительно влияют на безопасность, даже если эти шаблоны проектирования изначально не были разработаны с учетом требований безопасности.
Secure by Design все больше становится основным подходом к разработке для обеспечения безопасности и конфиденциальности программных систем. При таком подходе безопасность встроена в систему с нуля и начинается с надежной архитектуры. Решения по проектированию архитектуры безопасности основаны на хорошо известных тактиках безопасности и шаблонах, определяемых как методы многократного использования для достижения конкретных требований к качеству. Тактики / шаблоны безопасности предоставляют решения для обеспечения необходимой аутентификации , авторизации, конфиденциальности, целостности данных , конфиденциальности, подотчетности, доступности, безопасности и неотказуемости, даже когда система подвергается атаке. Для обеспечения безопасности программной системы важно не только разработать надежную архитектуру безопасности (предназначенную), но также необходимо сохранить (реализованную) архитектуру в процессе эволюции программного обеспечения.
СОДЕРЖАНИЕ
Ожидайте атак
Следует предполагать наличие злонамеренных атак на программное обеспечение, и следует принимать меры для минимизации воздействия. Ожидаются уязвимости системы безопасности, а также недопустимый ввод данных пользователем . Тесно связана практика использования «хорошего» дизайна программного обеспечения, такого как дизайн на основе предметной области или облачный дизайн , как способ повышения безопасности за счет снижения риска ошибок, связанных с открытием уязвимостей, даже несмотря на то, что используемые принципы проектирования не были изначально задуманы для обеспечения безопасности. целей.
Избегайте безопасности через безвестность
Как правило, хорошо работающие дизайны не полагаются на секретность . Часто секретность снижает количество злоумышленников за счет демотивации подмножества угроз. Логика заключается в том, что если для злоумышленника увеличивается сложность, то злоумышленник прилагает больше усилий для компрометации цели. Хотя этот метод подразумевает снижение неотъемлемых рисков, практически бесконечный набор действующих лиц и методов, применяемых с течением времени, приведет к сбою большинства методов секретности. Хотя это и не является обязательным, надлежащая безопасность обычно означает, что каждому разрешено знать и понимать дизайн, потому что он безопасен . Это имеет то преимущество, что многие люди смотрят на компьютерный код , что увеличивает вероятность того, что любые недостатки будут обнаружены раньше (см . Закон Линуса ). Злоумышленники также могут получить код, что также облегчит им поиск уязвимостей .
Меньше привилегий
Также важно, чтобы все работало с наименьшими возможными привилегиями (см. Принцип наименьших привилегий ). Например, веб-сервер , работающий от имени администратора («root» или admin), может иметь право удалять файлы и пользователей, которым не принадлежат. Недостаток такой программы может поставить под угрозу всю систему, в то время как веб-сервер, который работает в изолированной среде и имеет только привилегии для требуемых функций сети и файловой системы , не может поставить под угрозу систему, в которой он работает, если только безопасность вокруг него не будет нарушена. сам тоже ущербный.
Методологии
Безопасный дизайн следует учитывать на всех этапах жизненного цикла разработки (независимо от выбранной методологии разработки ).
Существуют некоторые предварительно созданные методологии разработки Secure By Design (например, жизненный цикл разработки безопасности Microsoft ).
Жизненный цикл разработки безопасности Microsoft
Microsoft выпустила методологию и руководство, основанные на классической спиральной модели .
Стандарты и законодательство
Стандарты и законодательство существуют для поддержки безопасного проектирования, контролируя определение слова «безопасный» и предоставляя конкретные шаги для тестирования и интеграции безопасных систем.
Некоторые примеры стандартов, которые охватывают или затрагивают принципы Secure By Design:
ETSI TS 103 645, который частично включен в «Предложения правительства Великобритании по регулированию кибербезопасности интеллектуальных продуктов»
Серия ISO / IEC 27000 охватывает многие аспекты безопасного проектирования.
Серверная / клиентская архитектура
В архитектурах сервер / клиент программа на другой стороне может не быть авторизованным клиентом, а клиентский сервер может не быть авторизованным сервером. Даже если это так, атака «человек посередине» может поставить под угрозу связь.
Часто самый простой способ нарушить безопасность системы клиент / сервер — это не обращаться к механизмам безопасности, а вместо этого обойти их. Атака человека посередине — простой пример этого, потому что вы можете использовать ее для сбора деталей, чтобы выдать себя за пользователя. Вот почему важно учитывать шифрование , хеширование и другие механизмы безопасности в вашем проекте, чтобы гарантировать, что информация, собранная от потенциального злоумышленника, не позволит получить доступ.
Еще одна ключевая особенность системы безопасности клиент-сервер — это хорошие методы кодирования . Например, следование известной структуре проектирования программного обеспечения, такой как клиент и брокер, может помочь в разработке хорошо построенной структуры с прочной основой. Кроме того, если программное обеспечение будет изменено в будущем, еще более важно, чтобы оно следовало логической основе разделения между клиентом и сервером. Это потому, что если программист приходит и не может четко понять динамику программы, он может в конечном итоге добавить или изменить что-то, что может добавить брешь в безопасности. Даже при лучшем дизайне это всегда возможно, но чем лучше стандартизован дизайн, тем меньше шансов на то, что это произойдет.
