Security: основная статья

Карта РФ ИБ

База

Коварно ввели admin/admin, обстоятельства непреодолимой силы не позволяли обновить php, хак утилита cat и привилигерованный контейнер 🤣😁

https://disk.yandex.ru/i/Pn4ToLvOz7pMVg

Пару примеров о том, что детально описано ниже, до огромной статьи.

• ИБ – это про «может поможет, а может нет, думайте сами и никаких гарантий».
• почему “лычки” в ИБ всегда были и будут и они важны на примере яндекс облака – сначала говорим о них, потом о фактических мерах, хоть и безусловно хороших, я ниже сохранил только техническую часть, лычки тут

Технический уровень
Чтобы обеспечить конфиденциальность и целостность данных, Yandex Cloud шифрует их на уровне физической инфраструктуры и на уровне Storage Layer. Доступность данных в Storage Layer обеспечивается путем их размещения в трёх зонах доступности и репликации между зонами.

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

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

Для обеспечения безопасности Yandex Cloud использует и другие средства и методы защиты, в том числе:
- инструменты контроля выполнения AppArmor и Seccomp, которые формируют среду изоляции и отслеживают работу приложений;
- систему обнаружения вторжений, которая собирает логи с хостов (в том числе логи AppArmor и Seccomp), дополняет их при помощи утилиты osquery и отправляет в систему Security Information and Event Management (SIEM);
- несколько типов межсетевых экранов и пакетных фильтров;
систему мониторинга и оповещения о подозрительном поведении.

В соответствии с СУИБ всё установленное ПО регулярно проверяется на наличие уязвимостей и обновляется до последних версий. Конфигурации операционных систем описываются кодом и хранятся в репозитории. Все изменения конфигураций перед переносом в продуктивную среду проходят обязательную проверку в тестовых средах.

Администраторы инфраструктуры и разработчики провайдера имеют доступ к продуктивной среде через бастионный хост, который записывает сессию пользователя. Информация из записанных сессий передается в SIEM и регулярно анализируется. Для доступа используются аппаратные ключи, на которых хранятся аутентификационные данные.

• bi.zone в checklists-BIZONE-experts-2021
• (Github, security) для РФ использование опасно github и аналогичных продуктов –  после СВО банились РФ репозитории с open source версиями продуктов. Пример импортозамещения git – gitverse. Так же инфа с курса LPIC (по факту качается, но прецеденты явно были) – с РФ без vpn можно не скачать и репы, например grafana, elastic.
• в крупных (банки) и даже не очень компаниях часто поднимаются приватные репозитории для обновлений пакетов/ОС/докер-образов и прочих вещей, плюсы такого:
  • Всем устройствам не нужен доступ в интернет
  • Могут распространяться сделанные «in house» версии пакетов
  • Пакеты могут дополнительно проверяться – заливаться только стабильные/безопасные их версии
• (security, cisco catalyst, fortigate) SMI (Smart Install) нужно отключать/или защищать строгими ACL, так же как и зачастую другие управляющие интерфейсы (SNMP/WEB/SSL VPN и даже SSH) сетевых устройств, есть уязвимости и на SNMP и на SMI (port 4786) и на SSL VPN (Fortigate)
• Хорошая статья от сбера о sim swapping / угон симкарт

Использование двухфакторной аутентификации через SMS-сообщения не является панацеей при защите от мошенников. Ведь после перевыпуска SIM-карты с номером жертвы у неё отключаются все услуги связи. Это одна из основных причин, по которой мы рекомендуем использовать в Сбербанк ОнЛайн PUSH-уведомления: они привязаны не к SIM-карте, а к мобильному устройству.

Если вы всё же стали жертвой атаки SIM-своперов, то знайте, что в первые 24 часа после перевыпуска SIM-карты операторы связи блокируют или ограничивают услуги отправки и получения SMS-сообщений, в том числе в кредитно-финансовые организации. Поэтому некоторые сервисы будут недоступными. И у вас есть ровно сутки, чтобы восстановить доступ к своей SIM-карте без серьёзных последствий. Сделать это поможет личный визит в офис оператора связи либо звонок на горячую линию.

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

• Интересное интервью от Positive Technologies
  • ИБ строится от недопустимых событий (их невозможности в идеале как ответственности ИБ) для конкретной компании/гос структуры тк защитится от всех рисков невозможно. Далее уже, зная недопустимые события, анализируются векторы атак, которые к ним могут привести.
  • 
  • Ред тиминг/киберучения и баг баунти, причем регулярные – реальные мерила твоей киберзащищенности
    • 6 раз привлекали внешние компании ред тима для взлома себя же Позитив
    • Ред тиминг часто незрелые заказчики ограничивают скоупом работ, тем самым делая ситуацию менее реальной, чем будет с потенциальным хакером (атакуйте только 5/2, туда ходите, туда не ходите, вложения не отсылайте, zero day не используйте). По факту например больше всего атак в ночь с пятницу на субботу!
  • “Текущий уровень защищенности он в целом таков, что скорей всего хакеры вас взломают и я давал бы индульгенцию руководителям ИБ, которые открыто говорят об этом бизнесу”, при этом не повод действовать с логикой “все можно сломать, поэтому безопасностью можно не заниматься”
• simple методика scan 10 CVSS & patch, scan 9-7 CVSS & patch от Viavi “Security hardening validation methodology” на базе TeraVM
• что нужно делать организациям для обеспечения безопасности (часть про Россию удалил) в checklist от Fortinet. По каждому пункту подробнее так же можно почитать в самой статье Fortinet.

Key Takeaways
Patching: Ensure that all systems are fully patched and updated
Protection Databases: Make sure your security tools have the latest databases 
Backup: Create or update offline backups for all critical systems
Phishing: Conduct phishing awareness training and drills 
Hunt: Proactively hunt for attackers in your network using the known TTPs
Emulate: Test your defenses to ensure they can detect the known TTPs
Response: Test your incident response against fictitious, real-world scenarios
Stay up to Date: Subscribe to threat intelligence feeds like Fortinet Threat Signals 

• Стек технологий/направлений трафика сетевой безопасности от Cisco

• Мои базовые советы по работе с банками с точки зрения клиентской безопасности
• Sharkbot – пример более-менее продвинутого трояна для Android – phishing banking app page, keylogging, SMS intercept.

Latest Android Banking Malware Sharkbot Distributed on Google Play Store

It can detect when a targeted banking app is open and display a phishing page to steal the victim's credentials. Keylogging and SMS intercept features are implemented to intercept all the accessibility events produced by the victim when "Accessibility Permissions & Services" is enabled.

Взлом matrix.org – пример очень показательного взлома с точки зрения множество важнейших принципов, описанных ниже. Сам хакер очень подробно все описал.

https://archive.md/MfrjB
в матриксе крутили на х.ю самые обычные бестпрактисы. Молодцы, че 

I noticed in your blog post that you were talking about doing a postmortem and steps you need to take. As someone who is intimately familiar with your entire infrastructure, I thought I could help you out.

• Отсутствие 2FA/MFA для ssh (я после этой истории поставил 😉)

[SECURITY] 2FA is gud
2FA is often touted as one of the best steps you can take for securing your servers, and for good reason! If you'd deployed google's free authenticator module (sudo apt install libpam-google-authenticator), I would have never been able to ssh into any of those servers.
Alternatively, for extra security, you could require yubikeys to access production infrastructure. Yubikeys are cool. Just make sure you don't leave it plugged in all the time, your hardware token doesn't do as much for you when it's always plugged in and ready for me to use.
Alternate-Alternatively, if you had used a 2FA solution like Duo, you could have gotten a push notification the first time I tried to ssh to any of your hosts, and you would have caught me on day one. I'm sure you can setup push notifications for watching google-authenticator attempts as well, which could have at least given you a heads up that something fishy was going on.
Anyways, that's all for now. I hope this series of issues has given you some good ideas for how to prevent this level of compromise in the future. Security doesn't work retroactively, but I believe in you and I think you'll come back from this even stronger than before.
Or at least, I hope so -- My own information is in this user table... jk, I use EFNet.

• Лишние привилегии (даешь рут для всех :/) – почему нельзя использовать root по умолчанию, лучше использовать sudoedit, принцип least privilage и все такое 🙂

[SECURITY] Principle of Least Privilege
Escalation could have been avoided if developers only had the access they absolutely required and did not have root access to all of the servers. I would like to take a moment to thank whichever developer forwarded their agent to Flywheel. Without you, none of this would have been possible.

• Отсутствие аудита логов безопасности

[SECURITY] Monitor log files to avoid relying on external whitehats
Let's face it, I'm not a very sophisticated attacker. There was no crazy malware or rootkits. It was ssh agent forwarding and authorized_keys2, through and through. Well okay, and that jenkins 0ld-day. This could have been detected by better monitoring of log files and alerting on anomalous behavior. Compromise began well over a month ago, consider deploying an elastic stack and collecting logs centrally for your production environment.

• Отсутствие постоянных обновлений критичных для безопасности систем (CI Jenkins)

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

• Прямой доступ из интернета НА ВСЕ СЕРВЕРА без каких то глупых VPN/reverse-proxy/bastion-host
  • на SSH сервера
  • на сервер CI Jenkins

[SECURITY] Controlled Production Access
I was able to login to all servers via an internet address. There should be no good reason to have your management ports exposed to the entire internet. Consider restricting access to production to either a vpn or a bastion host.

[SECURITY] Jenkins Slave listening to SSH on the internet
Once I was in the network, a copy of your wiki really helped me out and I found that someone was forwarding 22226 to Flywheel. With jenkins access, this allowed me to add my own key to the host and make myself at home. There appeared to be no legitimate reason for this port forward, especially since jenkins tunnel was being used to establish the communication between Themis and Flywheel.

Ну и чуть более сложные:

• Хранение ключей для создания подписей СВОИХ МЕГА БЕЗОПАСНЫХ ПРИЛОЖЕНИЙ на рабочих серверах, а не на изолированном хосте

[SECURITY] Signing keys in production?!?
There I was, just going about my business, looking for ways I could get higher levels of access and explore your network more, when I stumbled across GPG keys that were used for signing your debian packages. It gave me many nefarious ideas. I would recommend that you don't keep any signing keys on production hosts, and instead do all of your signing in a secure environment.

• Включенный “проброс ключа ForwardAgent” в ssh – позволяет с одного сервера подключаться на другой без пароля, форвардом ключа от первого сервера второму

[SECURITY] SSH Agent Forwarding
Complete compromise could have been avoided if developers were prohibited from using ForwardAgent yes or not using -A in their SSH commands. The flaws with agent forwarding are well documented.

• Хранение в Git репозитории всех важных данных и полностью репа заливалась на хосты, хотя по факту в этом нужды не было

[SECURITY] Git is not a secret store
The internal-config repository contained sensitive data, and the whole repository was often cloned onto hosts and left there for long periods of time, even if most of the configs were not used on that host. Hosts should only have the configs necessary for them to function, and nothing else.

Саммари простых советов от Гоуслуг по безопасности

https://gu-st.ru/content/lending/secure_kids.pdf
https://gu-st.ru/content/lending/secure_phone.pdf
https://gu-st.ru/content/lending/secure_phraze.pdf
https://gu-st.ru/content/lending/secure_pass.pdf
https://gu-st.ru/content/lending/secure_mobile.pdf

• • Используйте сложные пароли длиной 12 знаков, которые содержат заглавные и строчные буквы, цифры и специальные символы
  • Используйте для паролей случайную комбинацию букв, цифр и других символов. Подойдут забавные фразы, которые нужно записывать буквами разного регистра и добавляя цифры и символы
  • Не используйте для паролей личные данные или другую информацию, которую публикуете вы или ваши близкие в социальных сетях
  • Храните пароли в специальных программах — менеджерах паролей/password manager ((лучше браузеров т.к. приложение с сайтом напрямую не работает!))
  • Используйте разные пароли для каждой важной учётной записи
  • Не храните пароли на бумажных носителях, в электронных блокнотах, заметках и браузерах
  • Обязательно используйте двухфакторную аутентификацию

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

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

• • Не паникуйте. Просто скажите «я вам перезвоню» и завершите разговор
  • Ни под каким предлогом не называйте личные данные, реквизиты карты и секретную информацию: CVC/CVV‑код на обратной стороне карты, коды из смс и ПИН-коды
  • Не переводите деньги на счета незнакомых вам людей
  • Не устанавливайте на смартфон приложения из непонятных источников
  • Всегда набирайте официальный номер банка. Он указан на официальном сайте или на обратной стороне карты. Расскажите оператору о проблеме
  • Любые вопросы решайте в рамках закона
  • Установите программу, которая проверяет звонки и умеет блокировать спам-вызовы

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

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

Источники

• Большая часть информации ниже взята из открытых источников, которые изучались по мере прохождения:
  • прекрасного базового курса Coursera от Google по безопасности
  • материалов для подготовки к новому Cisco CCNP/CCIE Security (SCOR, SNCF экзамены)
• Очень хороший github repo h4cker.org в котором Omar Santos (автор курса SCOR) собрал разную информацию в контексте сетевой безопасности. Например там есть,
  • хорошая таблица по тому, какие алгоритмы хеширования и шифрование рекомендуется/не рекомендуется использовать. Какие являются будущим.
  • довольно полный список разных утилит для reverse-engineering

А теперь перейдем от практики к непосредственно теории.

Обеспечение безопасности — это не разовое мероприятие, а постоянный процесс, основанный на следующих принципах:

• • планирование технических и организационных мер с учетом имеющихся рисков и угроз;
  • выполнение этих мер;
  • мониторинг и анализ функционирования вашей системы;
  • совершенствование применяемых инструментов защиты.

Стандартизация

• NIST Cybersecurity Framework (National Institute of Standards and Technology) – совокупность индустриальных стандартов и наилучших практик для защиты организаций в контексте кибербезопасности от гос. органа США (всего более 500 штук). Одной из основных целей стандартизации является управление рисками кибербезопасности критической инфраструктуры эффективно и не дорого. Framework может использоваться как основа для любой организации. В целом публикации NIST охватывают широкий круг вопросов безопасности (от контроля доступа до беспроводной безопасности) и являются очень ценным источником информации.

- The National Institute of Standards and Technology (NIST) is a well-known organization that is part of the U.S. Department of Commerce.
- Currently, there are more than 500 NIST information security–related documents.
- NIST Cybersecurity Framework is a collection of industry standards and best practices to help organizations manage cybersecurity risks.
- One of the main goals is to address and manage cybersecurity risk in a cost-effective way to protect critical infrastructure.
- Although designed for a specific constituency, the requirements can serve as a security blueprint for any organization.
- From access controls to wireless security, the NIST publications are truly a treasure trove of valuable and practical guidance.

• ISO/EIC 27000 (ISO27k) – набор стандартов (порядка 50) о информационной безопасности от ISO (International Organization for Standardization) и IEC (International Electrotechnical Commission). Первые же 6 документов рассматривают большой пул вопросов касающихся развертывания/поддержки/мониторинга/аудита систем управления ИБ (ISMS). Организации могут/проходят процедуру соответствия этим сертификациям.

The ISO/IEC 27000 series (also known as the ISMS Family of Standards, or ISO27k for short) comprises information security standards published jointly by the ISO and the International Electrotechnical Commission (IEC).
The first six documents in the ISO/IEC 27000 series provide recommendations for “establishing, implementing, operating, monitoring, reviewing, maintaining, and improving an Information Security Management System (ISMS)”.

• Регулирующие процедуры особенно развиты в США. Яркий пример – процедура в США, обязательная Federal Civilian Executive Branch (FCEB), но рекомендованная всем: в течении двух недель после анонса Cybersecurity & Infrastructure Security Agency (CISA) закрыть уязвимость существующим патчем.

  The Cybersecurity & Infrastructure Security Agency (CISA) added CVE-2022-21882 to the list of known publicly exploited vulnerabilities on February 4, 2022.
  
  This means that all Federal Civilian Executive Branch (FCEB) agencies are now required to patch all systems against this vulnerability within two weeks, until February 18.
  
  While Binding Operational Directive 22-01 (BOD 22-01) only applies to FCEB agencies, CISA strongly urges all private and public sector organizations to reduce their exposure to ongoing cyberattacks by adopting this Directive and prioritizing mitigation of vulnerabilities included in its catalog of actively exploited security flaws.

• NSA/US government активно вкладывались и вкладываются в направление ИБ, участвовали в разработке The Ghidra, спонсировали такие проекты как snort/suricata (и использовали snort) и методологии тестирования IDS. author Victor Julien <victor@inliniac.net>

What the Suricata development by the OISF has shown in my opinion is that we’ve managed to create a very promising new Open Source project out here. In little over a year, funded for about $600k by the US government and with heavy (and growing) industry support, we’ve produced a new IDS/IPS engine mostly compatible with Snort but build on a all new code base an incorporating some very interesting fresh ideas. We’re already seeing a community form around our project with a lot of support from that new community.

This work has been funded by the National Security Agency INFOSEC University Research Program under Contract Number DOD-MDA904-93-C-4084. 

Терминология (словарь/dictionary)

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

• • целостность подразумевает что данные защищены от порчи, подмены (имитозащита). Чаще всего технически задача целостности решается хешированием. Так же шифрованием, цифровыми подписями, контролем процессов, тестированиями кода, анализ логов, мониторинг (напр. контроль целостности файлов), тренинги персонала.
    
    • Воровство пароля админа в последующим изменением конфигурации сервисов/серверов/устройств – тоже атака на целостность.
    • Malware которое модифицирует/уничтожает системные файлы, необходимые для загрузки – пример неавторизованной манипуляции, атаки на целостность.
    • Подмена/удаление медицинских или банковских данных.
  • доступность подразумевает что сервис доступен (напр. сайт online retailing, ISP provider, cloud provider) для легитимных пользователей. Самой частой атакой против доступности является DoS (denial-of-service). Показателем доступности является uptime (сколько времени в процентах сервис доступен), например ISP/датацентры часто публикуют данные/подписывают договоры (SLA) с 99.999% доступностью (99.999% uptime). В среднем мы более уязвимы к проблемам доступности в сравнении с проблемами конфиденциальности и целостности. Методы митигации угроз доступности включают контроль доступа, мониторинг, отказоустойчивость, виртуализация, административные меры (процедуры, планирование).

Какой из этих аспектов CIA triad более важен? Во первых они связаны – например, потеря пароля может привести к проблемам по любому из аспектов. Во вторых компания должна решать сама на основе ее целей, сервисов, регламентов и соглашений.

CIA - triad of confidentiality, integrity, and availability is at the heart of information security. "Confidentiality" signifies that data is only viewable by those authorized to view it; "Integrity" denotes that data won't be manipulated or corrupted; and "Availability" means that services remain reachable and available.

Еxamples of security mechanisms designed to preserve confidentiality:
- Logical and physical access controls
- Encryption
- Controlled traffic routing


Integrity is basically the ability to make sure that a system and its data has not been altered or compromised. In other words, is the information the same as it was intended to be? Integrity applies not only to data, but also to systems. 
- For instance, if a threat actor changes the configuration of a server, firewall, router, switch, or any other infrastructure device, it is considered that he or she impacted the integrity of the system.
- Malware that corrupts some of the system files required to boot the computer is an example of deliberate unauthorized manipulation.
- What if you are injured, unconscious, and taken to the emergency room of a hospital, and the doctors need to look up your health information. You would want it to be correct, wouldn’t you?
- Or think of your dismay if you check your bank balance after making a deposit and find that the funds have not been credited to your account!
- Safeguards that protect against the loss of integrity include access controls, such as encryption and digital signatures; process controls, such as code testing; monitoring controls, such as file integrity monitoring and log analysis; and behavioral controls, such as separation of duties, rotation of duties, and training.

The last component of the CIA triad is availability, which states that systems, applications, and data must be available to authorized users when needed and requested. The most common attack against availability is a denial-of-service (DoS) attack. User productivity can be greatly affected, and companies can lose a lot of money if data is not available. For example, if you are an online retailer or a cloud service provider and your ecommerce site or service is not available to your users, you could potentially lose current or future business, thus impacting revenue.

You might have heard the expressions “uptime” and “5- 9s” (99.999% uptime). This means the systems that serve Internet connections, web pages, and other such services will be available to users who need them when they need them. Service providers frequently use service level agreements (SLAs) to assure their customers of a certain level of availability.

We are more vulnerable to availability threats than to the other components of the CIA triad. Safeguards that address availability include access controls, monitoring, data redundancy, resilient systems, virtualization, server clustering, environmental controls, continuity of operations planning, and incident response preparedness.

Correlation
- Integrity and confidentiality are interrelated. If a user password is disclosed to the wrong person, that person could in turn manipulate, delete, or destroy data after gaining access to the system with the password he obtained. Many of the same vulnerabilities that threaten integrity also threaten confidentiality. 
- You may be wondering which is most important: confidentiality, integrity, or availability? The answer requires an organization to assess its mission, evaluate its services, and consider regulations and contractual agreements.

• Защищать сложнее чем атаковать – атакующему зачастую достаточно провести успешно только одну атаку из 100, чтобы взломать систему. При этом защищающийся может успешно отразить 99 атак и система все равно будет взломана.
• Risk (риск, управление рисками) и идеальная безопасность – возможность понести потери в случае атаки на систему (реализации угрозы). Безопасность вся основывается на рисках – определение рисков, определение вероятности атак, разработка/проектирование систем для минимизации рисков этих атак (простейший пример из жизни – переход дороги). В контексте безопасности есть аксиома, что невозможно полностью исключить риск – невозможно сделать идеально защищенную систему (impossible to make absolutely secure) т.к. полностью безопасная система – отключенная от сети, питания, к ней нет доступа ни у кого. Но это не повод не делать ничего (даже в контексте безопасности дома – все закрывают двери). Правильный подход – это идентифицировать риск, принять меры по уменьшению и мониторить, приняв его как остаточный риск (residual risk). С риском ассоциируются понятия assets (активы), threats (угрозы) и vulnerabilities (уязвимости). Для “работы” с рисками правительство США разработало risk management framework (RMF) на базе публикации NIST 800-37.

- Risk is the probability or likelihood of the occurrence or realization of a threat.
- Security is all about determining risks or exposure understanding the likelihood of attacks; and designing defenses around these risks to minimize the impact of an attack.
- No organization can ever be 100 percent secure. There will always be some risk left over. This is known as residual risk, which is the amount of risk left after safeguards and controls have been put in place to protect the asset.
-There are three basic elements of risk: assets, threats, and vulnerabilities.
- To deal with risk, the U.S. federal government has adopted a risk management framework (RMF). NIST Special Publication 800-37, “Guide for Applying the Risk Management Framework to Federal Information Systems,” transforms the traditional Certification and Accreditation (C&A) process into the six-step Risk Management Framework (RMF).

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

    An asset is any item of economic value owned by an individual or corporation. Assets can be real—such as routers, servers, hard drives, and laptops—or assets can be virtual, such as formulas, databases, spreadsheets, trade secrets, and processing time. Regardless of the type of asset discussed, if the asset is lost, damaged, or compromised, there can be an economic cost to the organization.

    • Risk assessment (оценка рисков) – начинается с threat modeling (моделирования угроз). Подразумевается идентификация возможных источников угроз (векторов атак, таких, как уязвимости) для систем (критичных систем/критичных данных) с точки зрения потенциального атакующего, приоритизация этих угроз в зависимости от вероятности и серьезности (например, для уязвимости – можно ли использовать ее удаленно, вероятность ее использования, тип доступа, который получит атакующий в результате эксплойта). 

Threat modeling is the process of identifying likely threats to your systems or network, and assigning them priorities. This is the first step to assessing your security risks.

Things to consider when evaluating a vulnerability are how likely it is to be exploited, the type of access an attacker could get, and whether or not the vulnerability is exploitable remotely.

• Страхование от киберрисков
  • страхование с оценкой уровня защищенности, которая влияет на размер выплаты и стоимость страховки – это лучшее, что я видел, чтобы люди начали думать головой. В такой страховке нужно не просто указать что есть МЭ, а производителя, модель, версию прошивки, какие подписки куплены. 
    
  • Нужно чтобы клиент понимал, что деньги придется отдать все-равно, но либо сюда либо сюда.
• Как для ИБ, так и для эксплуатации ситуация и логика «лучше бы ничего не происходило» является предочтительной, но она довольно ущербна с точки зрения развития
• Безопасность во многом – это меры предотвращения инцидентов и реагирования на них. «Хороший пожар — это тот, который не произошел, (((или хуже))) мы его потушили до того момента, как он разгорелся», — цитата, которая отражает роль безопасности в обеспечении непрерывности бизнеса. 

Reducing the attack surface should be your first goal.

• Trade-off (компромис) – во многих темах безопасности встречаются темы компромиссов между безопасностью и удобством:
  • безопасный  пароль ! = пароль который легко запомнить,
  • максимальная длина ключа != максимальная скорость работы,
  • цена/безопасность аппаратной реализации != цена/безопасность программной
  • безопасность 3FA != удобству 1FA
  • удаленный доступ со своего девайса (вместо rdp/VM) != безопасный доступ
  • и так далее

There is frequently a trade-off between security effectiveness and performance. Because of this trade-off, it is important to judge a product’s security effectiveness within the context of its performance (and vice versa). This ensures that new security protections do not adversely impact performance and security shortcuts are not taken to maintain or improve performance.

Из комментов:
Помню, как-то один прожектманагер, когда я заикнулся о том, как делать авторизацию, заявил: «Как говорил X X-ич X-ов, когда речь заходит о безопасности, работа останавливается.» Кто такой этот хрен, которого он цитировал, я так и не выяснил, да и имя сразу же забыл, но имею основания полагать, что такая точка зрения весьма распространена, и вертеть на х.ю вопросы безопасности как раз-таки входит в бестпрактисы дефективных манагеров.

• Vulnerability (уязвимость) – недостаток в системе (программной или аппаратной), который может быть использован для компроментации системы. Уязвимость не всегда имеет эксплойт (особенно публичный) и не всегда даже может быть эксплуатирована (подробнее ниже). Уязвимость может быть обнаружена в любой системе (application, OS, hardware) – не существует полностью неуязвимых систем. Вендоры/исследователи обычно после обнаружения уязвимости назначают ей номер CVE (Common Vulnerabilities and Exposure) и исправляют, но это не всегда так – вендор/пользователь может не исправлять уязвимость из-за простого отсутствия финансов. Так же уязвимость может не исправляться т.к. библиотека уже всеми забыта. Поддержкой CVE базы занимается организация MITRE. Пример конкретной уязимости CVE-2017-3881. Пример аппаратных уязвимостей – Spectre, Meltdown. Пример базы с уязвимостями ФСТЭК. 

Не все уязвимости имеют Exploit, такие уязвимости часто называют “theoretical vulnerabilities”, но нужно всегда иметь ввиду, что если вы не нашли или не придумали эксплойт, это не значит его нельзя найти (напр. глубоко в darkweb) или придумать и скрытно использовать (напр. спецслужбами). Поэтому в природе не бывает полностью “theoretical vulnerabilities”.

Почему не стоит говорить, что Windows всегда худший выбор для безопасности в сравнении с Linux.

• • Android ОС работает на базе ядра Linux и все прекрасно знают, что Android – не эталон в плане безопасности
  • Интересная статистика Fortinet. В топе по защищаемым IPS атакам D-Link, Linux! (Linux.Kernel.TCP.SACK.Panic.DoS), PHP.
  • Fortiguard первым ставит атаки на Linux как перспективы роста в ближайшее время
  • МИФ – на Linux серверах не нужны средства защиты, обязательные для Windows
  • Top 5 IPS: 2-3 атаки из TOP 5 на CPE устройства несмотря на период выборки

1 D-Link.Devices.HNAP.SOAPAction-Header.Command.Execution 23
2 Linux.Kernel.TCP.SACK.Panic.DoS 21
3 ThinkPHP.Controller.Parameter.Remote.Code.Execution 21
4 PHPUnit.Eval-stdin.PHP.Remote.Code.Execution 18
5 Dasan.GPON.Remote.Code.Execution 17

# другая неделя (через несколько мес после первой)
1 D-Link.Devices.HNAP.SOAPAction-Header.Command.Execution 21
2 Apache.Log4j.Error.Log.Remote.Code.Execution 20
3 Dasan.GPON.Remote.Code.Execution 20
4 Telerik.Web.UI.RadAsyncUpload.Handling.Arbitrary.File.Upload 20
5 HTTP.XXE 19

Although no one can predict the future, here are five up-and-coming threats we're keeping an eye on at FortiGuard Labs.
1. Linux Attacks
2. Satellite Network Attacks
3. Attacks Targeting Crypto Wallets
4. Attacks on OT Systems
5. Attacks on the Edge

• • Интересная статистика по уязвимостям в разных операционных системах. Как ни странно, первые не продукты Windows. Но статистика не совсем честная – Windows разбит по мажорным версиям, а Linux/MacOS/Android – нет. НО с другой стороны, если сделать выборку только по 2021 для Windows 10 и Linux/Android – статистика особо не изменится. Поэтому уязвимостей не мало везде – сотни за год. И даже в “защищенном” iOS.

A vulnerability is a weakness in a system or in a system design implementation that can be actually in software/hardware. No software or hardware immune to vulnerability. Vendors, security researchers, and vulnerability coordination centers typically assign vulnerabilities an identifier that’s disclosed to the public. This identifier is known as the Common Vulnerabilities and Exposures (CVE). CVE is an industry-wide standard. MITRE maintains the CVE list and its public website, manages the CVE Compatibility Program, oversees the CVE Naming Authorities (CNAs).

All software has vulnerabilities. Altough most organizations attempt to find and fix vulnerabilites, some organizations lack sufficient funds for securing their networks.

- There isn’t always an exploit for a given vulnerability.
- In some cases, users call vulnerabilities without exploits “theoretical vulnerabilities.” One of the biggest challenges with “theoretical vulnerabilities” is that there are many smart people out there capable of exploiting them. If you do not know how to exploit a vulnerability today, it does not mean that someone else will not find a way in the future. In fact, someone else may already have found a way to exploit the vulnerability and perhaps is even selling the exploit of the vulnerability in underground markets without public knowledge.
PSIRT personnel should understand there is no such thing as an “entirely theoretical” vulnerability. Sure, having a working exploit can ease the reproducible steps and help to verify whether that same vulnerability is present in different systems. However, because an exploit may not come as part of a vulnerability, you should not completely deprioritize it.

• 0-day vulnerability, zero-day exploit – уязвимость нулевого дня – уязвимость, которая неизвестна производителю продукта, но известна хакеру. 0 дней подразумевает за сколько нужно ее починить (или сколько дней известно о уязвимости) 😀 По факту зачастую даже после патча чинится куда дольше – нужно время для его “разливки”.

Sometimes no one may even know the vulnerability exists, and it is exploited. That is known as a zero-day exploit.
The time required to deploy and install the software patch on production servers and workstations exposes an organization’s IT infrastructure to an additional period of risk.

• Exploit – софт или набор шагов, который использует (эксплуатирует) уязвимость в системе. 

- Exploit is a soft that take advantage of vulnerability.
- An exploit is a concrete manifestation, either a piece of software or a collection of reproducible steps, that leverages a given vulnerability to compromise an affected system.

Пример базы с exploit-ами – популярный http://exploit-db.com/ от Offensive Security или github. Есть так же очень удобный command-line tool “searchsploit“, который позволяет выгрузить копию exploit database и в консоли искать эксплойты. Exploit’ы чаще всего продают в dark web. Exploit’ы не всегда выкладываются для злого умысла или зарабатывания денег – они являются proof-of-concept (POC).

- There are several places where people trade exploits for malicious intent. The most prevalent is the “dark web.”
- Not all exploits are shared for malicious intent. For example, many security researchers share proof-of- concept (POC) exploits in public sites such as The Exploit Database (or Exploit-DB) and GitHub.
- There is a command-line tool called searchsploit that allows you to download a copy of the Exploit Database so that you can use it on the go.

• Threat – в общем случае это любая потенциальная угроза. Это может быть угроза использования уязвимости (возможная атака), угроза отказа в обслуживании, угроза воровства данных, отказа объекта КИИ (stuxnet), угроза пожара или другого катаклизма и проч. В общем случае угроза может приводить к любым проблемам CIA (Confidentiality, Integrity, Availability). Сущность, получающая профит от использования уязвимости известна как malicious actor (threat actor – подробнее отдельно), а путь используемый этим actor для осуществления атаки известен как threat agent/threat vector.

A threat is an any potential danger to the asset. The entity that takes advantage of the vulnerability is known as the malicious actor, and the path used by this actor to perform the attack is known as the threat agent or threat vector.
From a security professional’s perspective, threats can be categorized as events that can affect the confidentiality, integrity, or availability of the organization’s assets. These threats can result in destruction, disclosure, modification, corruption of data, or denial of service.
Examples of the types of threats an organization can face include the following:
- Natural disasters, weather, and catastrophic damage
- Hacker attacks
- Cyberattack
- Viruses and malware
- Disclosure of confidential information
- DoS/DDoS

• Threat actor, malicious actor – личность или группа личностей, осуществляющих атаку или ответственные за security инцидент. Типы:
  • script kiddies (используют написанные другими инструменты),
  • organized crime groups (в основном занимаются воровством информации и зарабатыванием денег),
  • state governments (серьезные ребята),
  • hacktivists (занимаются этим по идеологическим причинам),
  • terrorist groups (групп мотивированные политическими или религиозными целями). 

Threat actors are the individuals (or group of individuals) who perform an attack or are responsible for a security incident that impacts or has the potential of impacting an organization or individual.

• Script kiddies: People who use existing “scripts” or tools to hack into computers and networks. They lack the expertise to write their own scripts.
• Organized crime groups: Their main purpose is to steal information, scam people, and make money.
• State sponsors and governments: These agents are interested in stealing data, including intellectual property and research-and- development data from major manufacturers, government agencies, and defense contractors.
• Hacktivists: People who carry out cybersecurity attacks aimed at promoting a social or political cause.
• Terrorist groups: These groups are motivated by political or religious beliefs.

• Attack vector (вектор атаки) – метод или механизм, которые атакующий может использовать для атаки сети/системы. Примеры векторов атак – вложения в почте, сетевые протоколы/сервисы. В зависимости от используемого приложения могут быть наиболее “актуальные” те или иные веторы атак, к примеру есть очень известный список OWASP TOP-10 (линк на непосредственно сайт OWASP – Open Web Application Security Project), в который включены самые опасные атаки на WEB приложения (SQL injection, auth implementation problems,  sensitive data exposure, XXE, XSS, url, deserialization, security misconfiguration, unsecure components, using components with known vulnerabilities, insufficient logging & monitoring, etc).

An attack vector can be thought of as any route through which an attacker can interact with your systems and potentially attack them.

Для тренировки с уязвимостью XSS и другими WEB-уязвимостями, которые рассмотрены в проекте OWASP можно использовать тулзу OWASP Juice Shop, можно на практике посмотреть уязвимости OWASP top 10 и другие (подробнее в XSS).

• Attack scope (совокупность векторов атаки) – совокупность векторов атак

The attack surface describes all possible ways that an attacker could interact and exploit potential vulnerabilities in the network and connected systems.

• Attack – непосредственно атака на систему. Одна атака может иметь тысячи вариаций.
• Defense in depth (эшелонированная защита) – концепция наличия нескольких наложенных систем защиты. Может быть реализована даже в рамках одного продукта (например, Firewall). 1) Нельзя полагаться на одну систему (SPOF) 2) Каждый из элементов защиты может быть не идеален, но он является потенциальным барьером, который может помочь отразить или как минимум замедлить атаку. Пример практического обоснования Defense in depth.

A defense-in-depth strategy uses a series of mechanisms to slow the advance of an attack that aims at acquiring unauthorized access to data.

Как в замке.

Отказоустойчивость в вопросе безопасности зачастую так же критична (а иногда и критичнее), чем работа непосредственно сервиса. Причем система может не упасть и ты не будешь знать что она не работает, а кто-то тем временем будет пользоваться уязвимостью в ней. К примеру,

• • Яркий пример – это куча эксплойтов у ведущих вендоров, позволяющих обойти аутентификацию. Почему ОБЯЗАТЕЛЬНО нужно закрывать доступ к устройствам на уровне протоколов (ACL), использовать серую адрессацию, а не только полагаться на аутентификацию в соотвествующих протоколах (SSH, SNMP, telnet, etc).

    https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20170629-snmp
    https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190501-nexus9k-sshkey

  • best practice настраивать и sshd_config и iptables для защиты подключения по ssh на сервер
  • как бы плохи антивирусы не были, они хорошо защищают от популярных известных атак (модель blacklist). Конечно, с точки зрения безопасности лучше иметь binary whitelisting software (bit9) – который будет запрещать все, кроме того что явно не разрешено (концепция implicit deny ниже), но это очень неудобно, особенно если он не полагается на signing PKI (концепция trade-off выше ;)), но недостаток есть и у них – если доверять всему подписанному, не смотря внутрь, то, в тот момент, когда подделают подпись – тебе хана (примеры подобных атак были).
  • как бы не были плохо функции защиты port security и MAC authentication, если они не накладывают серьезных недостатков в поддержании актуальными баз адресов – они могут быть полезны
  • То же самое и про firewall – помимо классических сетевых устройств, должны быть и host-based firewall, у которых будут примерно такие же правила, как у классического устройства или даже больше (защита внутри сети от зараженных устройств внутри сети за файрволом) или защита mobile юзера.

Defense in depth involves multiple layers of overlapping security. So, deploying both host- and network-based firewalls is recommended.

Antivirus software operates off a blacklist, blocking known bad entities. This means that brand new, never-before-seen malware won't be blocked. Binary whitelisting software operates using a whitelist, blocking everything by default, unless it's on the whitelist.

A host-based firewall can provide protection to systems that are mobile and may operate in untrusted networks. It can also provide protection from compromised peers on the same network.

• Implicit deny/whitelisting/default deny и концепция о том, что нужно отключать/удалять ненужные сервисы (или ограничивать к ним доступ) и не давать лишние доступы (всем права админа – это не соответствует best practice концепции “least privilege”). А если быть еще более точным – разрешать только то, что нужно. И именно так считается наиболее правильно настраивать Firewall’ьные политики. Встречается везде и нужно использовать везде – даже на клиентских устройствах (host-based firewall). Чем больше сервисов работает, тем больше поверхность (векторов) атак. Отсюда же например вытекает implicit deny в ACL (на роутерах Cisco или в iptables на INBOUND) – концепция из сетевого мира, которая подразумевает, что все, что явно не разрешено, должно быть запрещено – это относится как к входящему трафику, так и к исходящему. Это намного более безопасная концепция, чем black listing, хотя и менее удобная. 

Shut down everything that you do not need.
Implicit deny means that everything is blocked, unless it's explicitly allowed.
Every unnecessary component represents a potential attack vector. The attack surface is the sum of all attack vectors. So, disabling unnecessary components closes attack vectors, thereby reducing the attack surface.

• Fail-closed – близкая к Implicit deny концепция,  только описывает что делать с трафиком после сбоя (default action в таком случае)
• Физическая изоляция (англ. air gap / airgap «воздушный зазор»^[1]) — одна из мер обеспечения информационной безопасности, которая заключается в том, что безопасная компьютерная сеть физически изолирована от небезопасных сетей: интернета и локальных сетей с низким уровнем безопасности^[2]. Физическая изоляция применяется в компьютерных сетях при необходимости обеспечить высокий уровень безопасности. Но есть проблематика, что такие сегменты, хотя и изолированы, по факту имеют связность с миром через промежуточные устройства, для решения разнообразных задач (напр. сбор телеметрии, обновление приложений, обновление прошивок, обновление сигнатур антивирусных/ips и проч баз), что несет в себе ряд рисков, поэтому в таких случаях осуществляют ряд проверок (av, sandbox, dlp, checksum) и регламентов (журналирование, контроль доступа). По устройствам используются: 
  • чаще всего это usb флешки, перетаскиваемые в них. Флешки могут представлять опасность (stuxnet и проч), если за ними нет какого то особого контроля (физического, регламента форматирования перед каждой заливкой и проч).
  • так же это могут быть промежуточные ПК, имеющие доступ в сегмент, но не маршрутизирующие трафик; вариацией такого компа можно назвать и решение айтибастион синоникс (по сути три rpi в одном сервере)

• Machine Learning Security – частично в Machine Learning, частично в DNS security
• Internal Attack Team – есть во многих организациях, включая Google. Хакеры в белых шляпах.
• BYOD – Bring Your Own Device, remote work. К концу 2021 30% рабочей силы перейдет на постоянную удаленную работу (Global Workspace Analytics). Актуальная статистика Cisco – большая часть сотрудников счастливы от Hybrid work (совмещение работы в офисе с удаленной) и более мотивированы.

• OSINT (Open sourceintelligence) — Разведка на основе анализа открытых источников информации, разведывательная дисциплина, включающая в себя поиск, выбор и сбор разведывательной информации из общедоступных источников, а также её анализ. Примером можно считать avinfobot telegram бот, который из открытых источников агрегирует информацию по номерам авто/телефонам или ФИО.
• Survival Time системы без защиты, патчей (что не менее важно) и с неактуальной версией системы (Windows XP, god forbid), смотрящие “голо” в интернет – час. Потом ее хакнут. Поэтому безопасность – это важно.
• Security Misconfiguration – неправильная конфигурация продукта с точки зрения безопасности (напр. использование устаревших типов шифрования, устаревших методов аутентификации). Частая проблема, особенно в свете того, что дефолтные конфиги зачастую уже имеют заложенные недостатки с точки зрения безопасности.

Security Misconfiguration. Security misconfiguration is the most commonly seen issue. This is commonly a result of insecure default configurations, incomplete or ad hoc configurations, open cloud storage, misconfigured HTTP headers, and verbose error messages containing sensitive information. Not only must all operating systems, frameworks, libraries, and applications be securely configured, but they must be patched/upgraded in a timely fashion.

• Security Education – обучение по безопасности, обязательно в компаниях, которые заботятся о своей безопасности. Обучать нужно всех сотрудников, не только сотрудников SoC/IRP. Должно включать самые распространенные способы атаки (почтовые вложения, зеркала, пароли) и способы защиты от них. 

IT security training for employees should be designed to educate them on how to keep themselves and the organization secure, and to encourage a culture of security.

• Third party security – безопасность сторонней организации с которой взаимодействует твоя организация. Нужно проверять сторонние организации на соответствие политикам безопасности (внутренним внутри организации и зачастую даже твоим политикам) через VSAQ (Vendor security assessment questionnaries, быстрый и эффективный способ) или даже тестировать (audit, vulnerability test, pentest) их решения на безопасность. Пример VSAQ от Google.

You're trusting this third party to have reasonable security in place to protect the data or access you're entrusting them with.

A security assessment questionnaire allows you to quickly and efficiently get a broad understanding of what security measures a vendor company has in place. If available, any reports detailing penetration testing results or security assessments would also be valuable.

• Zero Trust не доверяем никому и ничему по умолчанию (пользователям, приложениям, трафику, данным или узлам) до тех пока не проведем их проверку. ZTNA (Zero Trust Network Access) – повторяющаяся проверка доверия, а не однократная – идентификация/аутентификация и оценка соответствия устройства при каждом соединении/доступе/новом запросе (посессионная). Доступ только к выбранным приложениям.

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

Ну если по полной играть в zero-trust, то, в идеале, надо бы ngfw (или что-то в этом роде)  иметь на каждом хосте. Иначе никакого чистого zero-trust-a не получится....

Zero Trust это концепция постоянной проверки того, что в данном потоке трафика работает тот самый пользователь и передает те самые данные того самого приложения. По сути это более точная проверка передаваемого трафика, обеспечиваемая движками DPI, User-ID, IPS, AV, TI, DLP. Когда эту концепцию Джон Киндерваг из Forrester озвучил, то производители NGFW поняли что это про них и стали ее рекламировать. https://www.forrester.com/blogs/the-definition-of-modern-zero-trust/

• Bastion host – хост, на входе в какую то (какие-то) IT системы. Позволяет получить доступ к каким то системам с себя/через себя, но на него наложены политики безопасности (аутентификации/авторизации, логгирования, мониторинга). Пример хоста см. выше в кейсе yandex cloud.

Bastion hosts are special-purpose machines that permit restricted access to more sensitive networks or systems. By having one specific purpose, these systems can have strict authentication enforced, more firewall rules locked down, and closer monitoring and logging.

• Advanced Persistent Threat (APT) – атака с внедрением в сеть и незаметным там нахождением существенное время. Advanced – потому что зачастую это таргетированная атака, при которой нет почти ограничения по времени/ресурсам. Чаще всего угроза постоянна – поэтому persistent.
  • Пример класса атак, который чаще всего ассоциируется с APT – атаки на цепочку поставок (supply chain) — это киберинциденты, в которых злоумышленник получает доступ к инфраструктуре компании через третьи организации ((два примера таких атак)).
  • Примеры конкретных атак – Stuxnet, атака на RSA SecurID в 2011 (потенциально на Lockheed Martin).

Advanced persistent threat (APT): It could be that the hacker has targeted you as part of a nation-state attack or your company has been targeted because of its sensitive data. Two examples include Stuxnet and the APT attack against RSA in 2011. These attackers might spend significant time and expense to gain access to critical and sensitive resources.

• Data leak prevention (DLP) – системы предотвращения данных. Могут анализировать любую активность, включая даже данные, копируемые по RDP.
• Data Sanitization, Secure Erase, File Shredder, Data Destruction – множество аббревиатур о безопасном удалении данных. Пример реализации в софте – удаление данных Disk Utility MacOS (подробнее). Пример стандартов/подходов/алгоритмов по уничтожению данных:
  • DoD 5220.22-M
  • GOST R 50739-95
  • NAVSO P-5239-26
  • RCMP TSSIT OPS-II
  • CSEC ITSG-06
  • HMG IS5
  • NCSC-TG-025
  • AFSSI-5020
  • AR 380-19
  • VSITR
  • Gutmann
  • Schneier
  • Pfitzner
  • Secure Erase
  • Random Data
  • Writes a Zero
• Персональные данные (ПД: personally identifiable information, PII) – данные которые позволяют идентифицировать персону. Защищаются законами в большинстве стран и требуют ‘особую’ защиту (напр. ГОСТ шифрование). Потеря таких данных может стать причиной судебного преследования компании, помимо потери доверия клиентов. Примеры персональных данных/информации:
  • PII – personally identifiable information (ФИО, адрес, телефон; биометрические: отпечатки пальцев, сетчатка глаза, ДНК),
  • NPPI – nonpublic personal information (национальность, политические взгляды),
  • PHI – personal health information (сосостояние здоровья),
  • PCI – payment card information.

For instance, if your organization experiences a breach and detailed customer information is exposed (for example, personally identifiable information [PII]), such a breach could have potential liabilities and loss of trust from your customers.

Чтобы получать и обрабатывать персональные данные, необходимо соблюдать требования Федерального закона №152-ФЗ. Этот закон даёт определение персональных данных, описывает права субъектов персональных данных, то есть тех людей, чьи данные вы собираете и обрабатываете, и ваши обязанности как оператора.
Исходя из положений ((нашего)) законодательства, персональные данные могут быть четырёх категорий, категория персональных данных влияет на уровень их защиты, который должен обеспечить оператор:

• специальные: например национальность, политические взгляды, состояние здоровья;
• биометрические: фото, отпечатки пальцев;
• общедоступные: например ФИО, дата рождения, номер телефона;
• иные: например, какие покупки делал конкретный человек в вашем интернет-магазине.

Требуемый уровень защищенности персональных данных зависит от типа угрозы, категории персональных данных, числа субъектов, данные о которых хранятся в вашей системе (больше или меньше 100 000), и от того, являются ли эти субъекты сотрудниками вашей компании. Существует четыре уровня защищенности. Определить подходящий уровень поможет таблица.

Разведка угроз (Threat Intelligence)

Разведка угроз (Threat Intelligence) – это знания о существующих и появляющихся угрозах к активу (asset). Основное применение – информирование бизнеса относительно рисков и последствий угроз для актива. Threat Intelligence включает информацию о активе, внутренних и внешних угрозах, контекст (context), механизмы (mechanisms), индикаторы компрометации (Indicators of Compromise, IoCs), последствия (implications), действия (actionable advice). Вся эта информация является критической для Security Operations Centers (SOC). IoC могут быть получены как от частных компаний, так и от гос. органов. Там описываются данные напр. IP адреса/порты/доменные имена/сигнатуры, которые можно использовать в качестве задания в системы – monitoring/netflow, firewall, endpoint и прочие.

- Threat intelligence is referred to as the knowledge about an existing or emerging threat to assets, including networks and systems. 
- Threat intelligence’s primary purpose is to inform business decisions regarding the risks and implications associated with threats.
- Threat intelligence is referred to as the information about the observables, indicators of compromise (IoCs) intent, and capabilities of internal and external threat actors and their attacks.
- This type of data can be beneficial for the security operations center (SOC) of any organization.
- Сyber threat intelligence allows you to bring more focus to cybersecurity investigation because instead of blindly looking for “new” and “abnormal” events, you can search for specific IoCs, IP addresses, URLs, or exploit patterns.

В целом использование опыта других – это полезно (немного капитаним).

Threat intelligence extends cybersecurity awareness beyond the internal network by consuming intelligence from other sources Internet- wide related to possible threats to you or your organization. For instance, you can learn about threats that have impacted different external organizations. Subsequently, you can proactively prepare rather than react once the threat is seen against your network.

Процесс threat intelligence можно разбить на этапы: планирование (planning), сбор (collection), обработка (processing), подготовка/аналитика/внедрение (analysis and production) и распространение (dissemination).

Существует ряд стандартов разработанных в контексте Threat Intelligence. Первые три основаны MITRE, поддерживаются сейчас OASIS.

• STIX – Structured Threat Information eXpression – язык для обмена информацией о атаках, может включать IP адреса/домены контрольных серверов (Command-and-control, C2, CNC), хеши malware и прочее. 
• TAXII – Trusted Automated eXchange of Indicator Information – отрытый транспортный механизм, который стандартизировал автоматический обмен информацией о гибер-угрозах. Использует формат STIX для передачи cyber threat intelligence (CTI).
• CybOX – Cyber Observable eXpression
• OpenIOC – Open Indicators of Compromise – информация о гибер-угрозах в машинном виде (machine-digestible format).
• OpenC2 – Open Command and Control

Cybersecurity & Information Security (InfoSec)

Кибербезопасность включает в себя традиционные вопросы информационной безопасности, но и добавляет дополнительные требования – контроль всех соединений, контроль данных на этапе хранения/передачи и обработки, управление софтом и аппаратным обеспечением, управление инцидентами.

Many individuals confuse traditional information security with cybersecurity. In the past, information security programs and policies were designed to protect the confidentiality, integrity, and availability of data within the confines of an organization. Unfortunately, this is no longer sufficient. Organizations are rarely self- contained, and the price of interconnectivity is exposure to attack.

Cybersecurity programs recognize that organizations must be vigilant, resilient, and ready to protect and defend every ingress and egress connection as well as organizational data wherever it is stored, transmitted, or processed. Cybersecurity programs and policies expand and build upon traditional information security programs, but also include the following:
• Cyber risk management and oversight
• Threat intelligence and information sharing
• Third-party organization, software, and hardware dependency management
• Incident response and resiliency

ОЦЕНКА уровня угроз (CVSS)

Common Vulnerability Scoring System (CVSS) – оценка уровня угрозы (совокупность рисков) конкретной уязвимости. Можно встретить двух версий – CVSSv2, CVSSv3 (чаще). CVSS является стандартом, используемым security специалистами во всем мире и поддерживается организацией FIRST (Forum of Incident Response and Security Teams). Примеры расчета оценок CVSS на основе анализа реальных уязвимостей есть у самого FIRST.

CVSS is an industry standard maintained by the Forum of Incident Response and Security Teams (FIRST) that is used by many PSIRTs to convey information about the severity of vulnerabilities they disclose to their customers.

Each vulnerability represents a potential risk that threat actors can use to compromise your systems and your network. Each vulnerability carries an associated amount of risk with it. One of the most widely adopted standards to calculate the severity of a given vulnerability is the Common Vulnerability Scoring System (CVSS)

CVSS оценка имеет градацию на низкий/средний/высокий/критический уровень. Во ФСТЭК градация почти аналогичная CVSSv3. Примером критичной уязвимости можно считать уязвимость, которая позволяет атакующему удаленно компроментировать систему и получить полный контроль над ней. 

CVSS
Textual severity ratings of None (0), Low (0.1-3.9), Medium (4.0-6.9), High (7.0-8.9), and Critical (9.0-10.0)[10] were defined, similar to the categories NVD defined for CVSS v2 that were not part of that standard .[11]

ФСТЭК
- низкий уровень, если 0,0 ≤ V ≤ 3,9;
- средний уровень, если 4,0 ≤ V ≤ 6,9;
- высокий уровень, если 7,0 ≤ V ≤ 9,9;
- критический уровень, если V = 10,0.

The score for the base group is between 0 and 10, where 0 is the least severe and 10 is assigned to highly critical vulnerabilities. For example, a highly critical vulnerability could allow an attacker to remotely compromise a system and get full control.

In numerous instances, security vulnerabilities are not exploited in isolation. Threat actors exploit more than one vulnerability “in a chain” to carry out their attack and compromise their victims. By leveraging different vulnerabilities in a chain, attackers can infiltrate progressively further into the system or network and gain more control over it. This is something that PSIRT teams must be aware of. Developers, security professionals, and users must be aware of this because chaining can change the order in which a vulnerability needs to be fixed or patched in the affected system. For instance, multiple low-severity vulnerabilities can become a severe one if they are combined.

Performing vulnerability chaining analysis is not a trivial task. Although several commercial companies claim that they can easily perform chaining analysis, in reality the methods and procedures that can be included as part of a chain vulnerability analysis are pretty much endless. PSIRT teams should utilize an approach that works for them to achieve the best end result.

CVSS оценка состоит из трех компонентов, каждый из которых имеет свою оценку от 0 до 10 и описывает различные характеристики уязвимости и то, как атакующий может эти характеристики использовать:

• Базового (base)
• Временного (temporal)
• Среды (environmental)

CVSS has three components: base, temporal, and environmental scores. Each component is presented as a score on a scale from 0 to 10.
The formula used to obtain the score takes into account various characteristics of the vulnerability and how the attacker is able to leverage these characteristics.

Подробнее о каждом:

• • Базовый (base) – самый важный компонент и единственный обязательный (mandatory) компонент, представляет собой характеристики, присущие уязвимости, которые неизменны со временем и не зависят от пользовательской среды. Сам компонент состоит из трех метрик:
    
    • Эксплуатируемость (exploitability) – условия, при которых возможна эксплуатация уязвимости.
      • Вектор атаки (Attack Vector, AV) – уровень доступа к уязвимой системе, при которых возможна эксплуатация уязвимости. Бывает четырех типов:
        • Сетевой (Network, N)
        • Смежный (Adjacent, A)
        • Локальны (Local, L)
        • Физический (Physical, P)
      • Сложность атаки (Attack Complexity, AC) – описывает условия, которые не контролируются атакующим, которые должны существовать для эксплуатации уязвимости.
        • Низкая сложность (Low, L)
        • Высокая сложность (High, H)
      • Требуемые привелегии (Privileges Required, PR) – представляет из себя уровень привилегий, которыми атакующий должен обладать на уязвимой системе.
        • Не требуются (None, N)
        • Низкие (Low, L)
        • Высокие (High, H)
      • Взаимодействие с пользователем (User Interaction, UI) – требуется ли взаимодействие с пользователем для осуществления атаки.
        • Не требуется (None, N)
        • Требуется (Requred, R)
    • Влияние на CIA (impact) – влияние на ключевые аспекты безопасности (CIA)
      • Влияние на Конфиденциальность (Confidentiality, C)
        • Низкое (Low, L)
        • Среднее (Medium, M)
        • Высокое (High, H)
      • Влияние на Целостность (Integrity, I)
        • Низкое (Low, L)
        • Среднее (Medium, M)
        • Высокое (High, H)
      • Влияние на Доступность (Availability, A)
        • Низкое (Low, L)
        • Среднее (Medium, M)
        • Высокое (High, H)
    • Зависимые системы (scope change, S) – влияние на другие системы, которые не имеют уязвимости, но зависимы от уязвимой (напр. из-за “падения” роутера с уязвимостью страдают все подключенные к нему устройства, если не имеют backup)
      • Нет влияния (Unchanged, U)
      • Есть влияние (Changed, C)

The base group defines Exploitability metrics that measure how the vulnerability can be exploited, as well as Impact metrics that measure the impact o nconfidentiality, integrity, and availability. In addition to these two metrics, a metric called Scope Change (S) is used to convey the impact on other systems that may be impacted by the vulnerability but do not contain the vulnerable code. For instance, if a router is susceptible to a denial-of-service vulnerability and experiences a crash after receiving a crafted packet from the attacker, the scope is changed, since the devices behind the router will also experience the denial-of-service condition. 

The Exploitability metrics include the following:
• Attack Vector (AV) represents the level of access an attacker needs to have to exploit a vulnerability.
• Attack Complexity (AC) represents the conditions beyond the attacker’s control that must exist in order to exploit the vulnerability.
• Privileges Required (PR) represents the level of privileges an attacker must have to exploit the vulnerability. 
• User Interaction (UI) captures whether a user interaction is needed to perform an attack. 

• Scope (S) captures the impact on systems other than the system being scored. The values are as follows:
• Unchanged (U)
• Changed (C)

The Impact metrics include the following:
• Confidentiality (C) measures the degree of impact to the confidentiality of the system.
• Integrity (I) measures the degree of impact to the integrity of the system. 
• Availability (A) measures the degree of impact to the availability of the system.

• • Временный (temporal) – изменяемые характеристики уязвимости, зафиксированные на момент оценки
    
    • Наличие эксплойтов (Exploit Code Maturity, E)
    • Наличие средств защиты от уязвимости (Remediation Level, RL) 
    • Полнота знаний об уязвимости (Report Confidence, RC)

The temporal group includes three metrics:
• Exploit Code Maturity (E), which measures whether or not public exploit is available
• Remediation Level (RL), which indicates whether a fix or workaround is available
• Report Confidence (RC), which indicates the degree of confidence in the existence of the vulnerability

• • Среды (environmental) – характеристики уязвимости с учетом среды организации
    • Требования к безопасности (Security Requirements CR, IR, AR) для уязвимой и зависимых систем
    • Модифицируемые метрики (Modified Base Metrics,  MAV, MAC, MAPR, MUI, MS, MC, MI, MA) на основе конкретной среды организации

The environmental group includes two main metrics:
• Security Requirements (CR, IR, AR), which indicate the importance of confidentiality, integrity, and availability requirements for the system
• Modified Base Metrics (MAV, MAC, MAPR, MUI, MS, MC, MI, MA), which allow the organization to tweak the base metrics based on specific characteristics of the environment

For example, a vulnerability that might allow a remote attacker to crash the system by sending crafted IP packets would have the following values for the base metrics:
• Access Vector (AV) would be Network because the attacker can be anywhere and can send packets remotely.
• Attack Complexity (AC) would be Low because it is trivial to generate malformed IP packets (for example, via the Scapy Python tool).
• Privilege Required (PR) would be None because there are no privileges required by the attacker on the target system.
• User Interaction (UI) would also be None because the attacker does not need to interact with any user of the system to carry out the attack.
• Scope (S) would be Unchanged if the attack does not cause other systems to fail.
• Confidentiality Impact (C) would be None because the primary impact is on the availability of the system.
• Integrity Impact (I) would be None because the primary impact is on the availability of the system.
• Availability Impact (A) would be High because the device could become completely unavailable while crashing and reloading.

Виды хакеров (hacker, Cracker, white-list)

Изначально термин hacker означал – компьютерный энтузиаст. Далее журналисты начали так же называть личностей, которые занимаются взломом с злыми намерениями. Индустрия предложила в таком случае использовать термин cracker (black hat hackers), а тех, которые “добрые” white hat hacker (ethical hacker). “Добрые” хакеры считают, что вы должны подходить к безопасности инфраструктуры используя хакерские утилиты и идеи. Различают так же и серых хакеров (grey hat hackers), которые в основном выступают в роли “белых” хакеров, но иногда становятся и “черными”. Таких сотрудников лучше не нанимать.

Originally, the term hacker was used for a computer enthusiast. A hacker was a person who enjoyed understanding the internal workings of a system, computer, and computer network and who would continue to hack until he understood everything about the system. Over time, the popular press began to describe hackers as individuals who broke into computers with malicious intent. The industry responded by developing the word cracker, which is short for a criminal hacker. The term cracker was developed to describe individuals who seek to compromise the security of a system without permission from an authorized party.
With all this confusion over how to distinguish the good guys from the bad guys, the term ethical hacker was coined. An ethical hacker is an individual who performs security tests and other vulnerability-assessment activities to help organizations secure their infrastructures. Sometimes ethical hackers are referred to as white hat hackers. Their belief is that you must examine your network in the same manner as a criminal hacker to better understand its vulnerabilities.
Gray hat hackers: these individuals usually follow the law but sometimes venture over to the darker side of black hat hacking. It would be unethical to employ these individuals to perform security duties for your organization because you are never quite clear where they stand.

  like: your_host <-->socks5 <--> http <--> socks4 <--> target_host

Us special agencies teacher will teach you how Russia is bad :))) this is ridiculuous.

Это не white hat hacker! Это профессионал под прикрытием, который делает свое дело за деньги ЦРУ, теперь только обучает не NSA, а наивных и глупых людей. “NSA on your side hahha”. И ничего смешного по факту в этом нет. В России мы называем это диванные войска. Вы только раздражаете, как комары в лесу и не более, не обольщайтесь - никакой пользы Украине от ваших действий нет абсолютно, тупое вредительство обычным людям в России, которые к принятию решений никакого отношения не имеют.  Вы настолько на западе отупели, что думаете, что Путину есть толк до каких то там сайтов (любых, не говоря про то, что действительно падало - мелочи типо подачи счетчиков и покупки шмоток), когда вопросы жизни России и союзников стоят на кону? Ахаххахахах ебанько не понимают что это в обе стороны работает «there’is sometimes when you have to fight, when evil enters your backyard, even the pacifist among us”.

Виды атак

Malware (вредоносный софт)

• Для защиты от исполняемых угроз обычно достаточно запретить исполнение из отдельных директорий

  • А достаточно было запретить запуск исполняемых файлов/скриптов и прочего из временных папок, и папок дефолтных загрузок файлов… % на 80 в случае с обычным пользователем это защитит его от этого

  • От остальных 20% компанию защитит отсутствие сетевых дисков 🙂

• virustotal.com – крутой сайт для проверки всем чем можно (в текущий момент 58 антивирусов) файлов
• www.talosintelligence.com/reputation – Cisco Talos File Reputation Lookup, можно по sha256 сделать поиск является конкретный файл опасным или нет (ниже скрин для wannacry), посмотреть репутацию ip/domain и прочее
• www.hybrid-analysis.com – проверка файлов в sandbox и решение о вредоностности на основе поведения файла в системе (Windows, Linux, Android). Много аналитики поведения (напр. обращения к сетевым хостам).

Several sites are available that can help analyze suspect malware. These online tools can provide a quick and easy analysis of files when reverse engineering and decompiling is not possible. Most of these sites are easy to use and offer a straightforward point-and-click interface. These sites generally operate as a sandbox.

Существует огромное количество разновидностей malware и ущерба, которые они делают (от рекламных сообщений до уничтожения физических устройств). Писатели malware стараются обойти методы их обнаружения применяя методы обфускации. Примеры зловредов можно найти уже в 80е годы.

Malicious software, or malware, includes viruses, ransomware, rootkits, worms, Trojan horses, backdoors, covert channel tools, spyware, and advanced persistent threats (APTs). Malware can cause a wide range of damage, from displaying messages, to making programs work erratically, encrypting files and asking for a ransom to decrypt them, to even to destroying data or hard drives.
Viruses have a history that dates back to the 1980s.

• Viruses and worms – вирус отличается от червя тем, что требует пользовательского действия для инфицирования и распространения. Червь же может распространятся без пользовательских действий.

One thing that makes viruses unique is that a virus typically needs a host program or file to infect. Viruses require some type of human interaction. A worm can travel from system to system without human interaction. When a worm executes, it can replicate again and infect even more systems. For example, a worm can email itself to everyone in your address book and then repeat this process again and again from each user’s computer it infects.

• Adware
• Spyware – в общем случае софт, перехватывающий без разрешения пользовательские данные (вводы, куки, поведение, etc) и передающий для последующего анализа (хакерам, маркетологам, статистам, etc).

Spyware is installed without your consent or knowledge, hidden from view, monitors your computer and Internet usage, and is configured to run in the background each time the computer starts. It is usually used for one of two purposes: surveillance, advertising.

• • keylogger – бывают как программные (перехватывают на программном уровне сигналы клавиатуры/мыши или тапы телефона), так и аппаратные – например в виде накладок на банковские терминалы, врезка в USB кабель от устройства ввода информации и проч. Так же могут быть проводным/беспроводными. Кейлогеры могут устанавливаться как легитимное ПО для слежки за сотрудниками, в таком случае рекомендуется CERT SEI использовать формулировку с предупреждением этих сотрудников о слежке – иначе можно получить иск. Пример аппаратного решения для перехвата – KeyHost (записывает данные с клавиатуры, которые можно потом прочитать на другом ПК). Много програмных решений можно найти в интернете (как платно, так и бесплатно). 

- Keystroke recorders have been around for years. Hardware keyloggers can be wireless or wired. 
- Spyware steals information from the user and also eats up bandwidth. If that’s not enough, spyware can also redirect your web traffic and flood you with annoying pop-ups. Many users view spyware as another type of virus.
- There are ways to make keyloggers completely invisible to the OS and to those examining the file system. To accomplish this, all the hacker has to do is use a hardware keylogger.
- To stay on the right side of the law, employers who plan to use keyloggers should make sure that company policy outlines their use and how employees are to be informed. The CERT Division of the Software Engineering Institute (SEI) recommends a warning banner similar to the following: “This system is for the use of authorized personnel only. If you continue to access this system, you are explicitly consenting to monitoring.”
- One such example of a wired keylogger is KeyGhost, a commercial device that is openly available. The device looks like a small adapter on the cable connecting one’s keyboard to the computer. This device requires no external power, lasts indefinitely, and cannot be detected by any software.
- Numerous software products that record all keystrokes are openly available on the Internet.

• Ransomware – шифрует данные в системе и требует перевода денег за ключи дешифрования. Чаще всего после перевода денег ключи не предоставляются. Крайне популярны сейчас (wannacry, pyeta, notpetya, bad rabbit). Могут шифровать особые файлы в системе (файлы баз данных, excel, word), а могут все (включая, например, master boot record).

Over the past few years, ransomware has been used by criminals making money out of their victims and by hacktivists and nation-state attackers causing disruption. Ransomware can propagate like a worm or a virus but is designed to encrypt personal files on the victim’s hard drive until a ransom is paid to the attacker. Ransomware has been around for many years but made a comeback in recent years.
Ransomware can encrypt specific files in your system or all your files, in some cases including the master boot record of your hard disk drive.

• Trojan (троян) – легитимное приложение осуществляет зловредную деятельность помимо/вместо основной функции.

Trojans are programs that pretend to do one thing but, when loaded, actually perform another, more malicious act.A user might think that a file looks harmless and is safe to run, but after the file is executed, it delivers a malicious payload. 

Трояны могут быть похожими на легитимные PDF, email, Word/Excel/PowerPoint документы, но по факту содержать malware код, который сделает все что угодно с вашей системой.

Trojans work because they typically present themselves as something you want, such as an email with a PDF, a Word document, or an Excel spreadsheet. Trojans work hard to hide their true purposes.
The payload is executed if the attacker can get the victim to open the file or click the attachment. That payload might allow a hacker remote access to your system, start a keystroke logger to record your every keystroke, plant a backdoor on your system, cause a denial of service (DoS), or even disable your antivirus protection or software firewall.

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

Unlike a virus or worm, Trojans cannot spread themselves. They rely on the uninformed user.

Существуют разные виды троянов:

• • RATs (Remote Access Trojans) – предоставляют полный контроль над жертвой, пример такого трояна Poison Ivy

• Remote access: Remote-access Trojans (RATs) allow the attacker full control over the system. Poison Ivy is an example of this type of Trojan. Remote-access Trojans are usually set up as client/server programs so that the attacker can connect to the infected system and control it remotely. 

  • Data hiding (ransomware) – прячем пользовательские данные и требуем с него $. По сути это ransomware распространенный методом “trojan”.

• Data hiding: The idea behind this type of Trojan is to hide a user’s data. This type of malware is also sometimes known as ransomware. This type of Trojan restricts access to the computer system that it infects, and it demands a ransom paid to the creator of the malware for the restriction to be removed. 

  • E-banking – перехватывает финансовые данные пользователя (напр. Zeus)

E-banking: These Trojans (Zeus is one such example) intercept and use a victim’s banking information for financial gain. Usually, they function as a transaction authorization number (TAN) grabber, use HTML injection, or act as a form grabber. The sole purpose of these types of programs is financial gain.

• • DoS – предназначены для DoS активности (подробнее о dos/ddos)

• Denial of service (DoS): These Trojans are designed to cause a DoS. They can be designed to knock out a specific service or to bring an entire system offline. 

  • Proxy – позволяет действовать от имени компьютера жертвы, а не от своего, что позволяет сложнее идентифицировать атакующего или подставить кого-то

• Proxy: These Trojans are designed to work as proxy programs that help a hacker hide and allow him to perform activities from the victim’s computer, not his own. After all, the farther away the hacker is from the crime, the harder it becomes to trace him.

  • Security software disablers – отключают антивирусы/файрволы для упрощения последующей malware активности

Security-software disablers: These Trojans are designed to attack and kill antivirus or software firewalls. The goal of disabling these programs is to make it easier for the hacker to control the system.

• • Poison apple, USB key drop и даже USB cable drop – оставляем где-то зараженную USB флешку (или даже USB кабель со встроенным чипом, напр. USBNinja) и ждем пока ее кто-то подберет и заразится. Обычно оставляется в офисе (напр. столовой) конкретной компании.

One way an attacker can spread a Trojan is through a poison apple attack or USB key drop. Using this technique, the attacker leaves a thumb drive (USB stick) in the desk drawer of the victim or maybe in the cafeteria of the targeted company. Perhaps in a key chain along with some keys and a photo of a cat to introduce a personal touch. The attacker then waits for someone to find it, insert it in the computer, and start clicking on files to see what’s there. Instead of just one bite of the apple, it’s just one click, and the damage is done!

Цели троянов бывают разные – от уничтожения компьютерных систем до обнаружения специальной информации. Обычно трояны пишутся для воровства банковских данных и цифровых кошельков, паролей, apt и простой файловой шары.

Not all Trojans were designed for the same purpose. Some are destructive and can destroy computer systems, whereas others seek only to steal specific pieces of information.
Common targets of Trojans include the following:
- Credit card data
- Electronic or digital wallets
- Passwords
- Information
- APT
- Data storage (movies, music, illegal sotware warez, pornography)

• Rootkit
• Backdoor – софт/доступы – что может использоваться взломщиками, для возможности доступа на машину после успешного взлома. Причем некоторые backdoor написаны так, что соединение устанавливается с зараженной машины на командный центр, а не наоборот. Такая концепция опасна тем, что трафик из защищенного периметра в общем случае анализируется менее тщательно, чем в этот периметр. Кроме того это позволяет обойти NAT. Backdoor на уровне государства может закладываться в софт и даже стандарты шифрования (см. Elliptic Curve Back Door – Computerphile BY NIST).

- If a hacker can get a backdoor program loaded on an internal device, the hacker can then come and go at will.
- Some of the programs spawn a connection on the victim’s computer connecting out to the hacker. The danger of this type of attack is the traffic moving from the inside out, which means that from inside the organization to the outside Internet. This is usually the least restrictive because companies are usually more concerned about what comes in the network than they are about what leaves the network.

• Rootkit
• Botnet (подробнее о dos/ddos)
• Logic Bomb

Существуют разные способы передачи вирусов (первые три самые популярные):

• Master boot record infection – самый первый способ

Master boot record infection: This is the original method of attack. It works by attacking the master boot record of the hard drive.

• File infection – полагается на то, что пользователь запустит исполняемый файл (.com, .exe). После запуска загружаются в RAM (немного капитанства). А для того, чтобы они загружались после перезагрузки системы malware могут прописать свой запуск как запуск драйвера, windows service или просто в стартап.

- File infection: This includes malware that relies on the user to execute the file. Extensions such as .com and .exe are usually used.
- Some viruses forgo a life of living exclusively in files and load themselves into RAM.

• Macro infections (Excel, Word, PowerPoint, etc) – использование malware кода в макросах Microsoft Office.

Macro infection: Macro viruses exploit scripting services installed on your computer. Manipulating and using macros in Microsoft Office.

• BIOS infection – крайне опасен тем, что может вызвать полный отказ – еще даже до прохождения POST девайс зависнет

BIOS infection: This could completely make the system inoperable or the device could hang before passing Power On Self-Test (POST).

• Propogating over the network (many types)
• Multipartite – использование сразу нескольких способов передачи – например Boot sector + program files. Примером вируса является NATAS.

Multipartite: This style of virus can use more than one propagation method and targets both the boot sector and program files. One example is the NATAS (Satan spelled backward) virus.

Соединения поверх сети интернет являются наиболее чаще используемым каналом передачи данных для распространения malware – это могут быть email attachments (самый часто используемый тип, обычно идущий вместе с социальной инженерией), peer-to-peer сети, instant messaging (IM), internet relay chat (IRC), browser/browser extension vulnerabilities, SMS, infected mobile apps (или видимая копия популярного mobile app с трояном по меньшей цене чем оригинал), watering hole (заражение сайта который посещает выбранная жертва), freeware (ничто не бесплатно в этом мире) и проч и проч. Но никуда не делся и классический способ – физический доступ (слив данных флешкой, установка жучков/кейлогеров и проч).

- Email attachments: Attachments are another common way to spread a Trojan. To get you to open them, these hackers might disguise the message to appear to be from a legitimate organization. The message might also offer you a valuable prize, a desired piece of software, or similar enticement to pique your interest. If you feel that you must investigate these attachments, save them first and then run an antivirus on them. Email attachments are the number-one means of malware propagation. You might investigate them as part of your information security job to protect network users.
- Browser and browser extension vulnerabilities: Many users don’t update their browsers as soon as updates are released. Web browsers often treat the content they receive as trusted. The truth is that nothing in a web page can be trusted to follow any guidelines. A website can send to your browser data that exploits a bug in a browser, violates computer security, and might load a Trojan.
- SMS messages: SMS messages have been used by attackers to propagate malware to mobile devices and to perform other scams.
- Impersonated mobile apps: Attackers can impersonate apps in mobile stores (for example, Google Play or Apple Store) to infect users. Attackers can perform visual impersonation to intentionally misrepresents apps in the eyes of the user. Attackers can do this to repackage the application and republish the app to the marketplace under a different author. This tactic has been used by attackers to take a paid app and republish it to the marketplace for less than its original price.
- Watering hole: The idea is to infect a website the attacker knows the victim will visit. Then the attacker simply waits for the victim to visit the watering hole site so the system can become infected.
- Freeware: Nothing in life is free, and that includes most software. Users are taking a big risk when they download freeware from an unknown source. Not only might the freeware contain a Trojan, but freeware also has become a favorite target for adware and spyware.
- Physical access: If a hacker has physical access to a victim’s system, he can just copy the Trojan horse to the hard drive (via a thumb drive).

Other observed tactics include the use of image files in the emails that are very tiny in scale and report back to the hosting server so that the attacker can determine if the email was viewed or not. Of course, this depends on whether the recipient chooses to download images or not.

Сам код вируса может располагаться как в начале инфицированного файла (prepender), так и в конце (appender).

Malware known as a prepender infects programs by placing its viral code at the beginning of the infected file, whereas an appender places its code at the end of the infected file. Both techniques leave the file intact, with the malicious code added to the beginning or the end of the file.

Анализ malware

Вообще анализ malware это “целая наука” и это зачастую крайне сложный процесс.

Malware analysis can be extremely complex.

В своем базовом сценарии malware анализ бывает двух типов:

• static анализ – используются методы реверс-инженеринга с инструментами в виде декомпиляторов/дизасемблеров (примеры софта – IDA Pro Hex-Rays, Binary Ninja, Evan’s Debugger edb, The Ghidra – сюда контрибьютил NSA, OllyDbg), OllyDbg, BinText (находит текст в исполняемых файлах). Этот софт позволяет (не всегда – подробнее в evasions) “восстановить” source code исполняемого файла. В целом довольно полный список разных утилит есть в github repo h4cker.org. 

Static analysis is concerned with the decompiling, reverse engineering and analysis of malicious software. Static analysis makes use of disassemblers and decompilers to format the data into a human-readable format.
IDA Pro: An interactive disassembler that you can use for decompiling code. It’s particularly useful in situations in which the source code is not available, such as with malware. IDA Pro allows the user to see the source code and review the instructions that are being executed by the processor. IDA Pro uses advanced techniques to make that code more readable.
Ghidra: A software reverse engineering tool developed by the US NSA Research.

• dynamic анализ – система динамического анализа файлов, создается специальная среда (testbed, например в VM/docker) обычно в безопасном окружении sandbox (созданной вручную или автоматически; подробнее ниже, поиск по sandbox) в которую помещается malware и анализируется его поведение в этой среде и сети с попыткой 1) не привлечь внимание атакующих к тому, что исполняемая среда является фейковой 2) ни в коем случае не допустить распространение malware дальше изолированной среды (подробнее в sandbox, поиск по “malware contained”). Подготовка правильного testbed требует зачатую не мало времени.

Популярные sandbox:

• •   FortiSandbox
  •   Trend Micro Deep Discovery
  •   FireEye NX, EX, FX
  •   CheckPoint Sandblast
  •   McAfee Advanced Threat Defense
  •   Palo Alto WildFire
  •   ESET Dynamic Threat Defense
  •   CrowdStrike (Falcon Sandbox)

Dynamic analysis relates to the monitoring and analysis of computer activity and network traffic. This requires the ability to configure the network device for monitoring, look for unusual or suspicious activity and try not to alert attackers. This approach requires the preparation of a testbed.

В malware так же существует понятие search routine – malware делает поиск новых файлов/пространства ОП для заражения. Далее посредством infection routine происходит заражение уязвимых хостов. Payload routine подразумевает непосредственные действия, для которых был написан софт – шифрование диска, отображение текста, отправка зловреда всем твоим друзьям и проч. Trigger routine – счетчик, когда стартует payload routine.

Search routine: responsible for locating new files, disk space or RAM to infect.
Infection routine: the search routing is useless if the virus doesn't have a way to take advantage of these findings.
Payload routine: the purpose of the payload routine might be to erase the hard drive, display a message to the monitor, or possibly send the piece of malware to people in your address book, etc.
Trigger routine: The goal of the trigger routine is to launch the payload at a given date and time. The trigger can be set to perform a given action at a given time.

Так же существует понятия profiling – сбор информации о системе и изменения поведения malware для минимизации обнаружения. Это может включать anti-forensics/antidetection routine техники (обфускация, защита от реверс-инженеринга), включенные в malware.

The search routine could include "profiling". Profiling could be used to identify the environment and morph the malware to be more effective and potentially bypass detection.
Antidetection routine: Many viruses might also have an antidetection routine. Its goal is to help make the virus more stealth-like and avoid detection.

Network attacks (сетевые атаки) & Network security

Network attacks:

• DHCP attacks (rogue DHCP => dhcp snooping)
• DNS cache poisoning (dns response flood after request => DNSSEC, версия DNS с аутентификацией и шифрованием)
• Data exfiltration (неавторизованная передача данных с хоста),
• MitM – Man-in-the-middle – session/cookie hijacking, arp spoofing, arp flood/scan, ip spoofing
• rogue AP
• evil twin => DAI, IPSG, 802.1x, network separation
• DoS/DDoS – подробнее о dos/ddos

Сетевая безопасность (network security; наличие firewall, ids/ips, шифрование важных данных, мониторинг/алертинг, использование Wi-Fi, использование VPN, аутсорсинг управления сетью, какое оборудование используется, наличие бекапов конфигов, наличие политик по управлению инфраструктурой – обновление конфигов/софта/проч) крайне важна – сетевые устройства это первая линия обороны в IT инфраструктуре против внешних атакующих.

Your network is the foundation of your IT infrastructure and the first line of defense against external attackers.

Скорость распространения

Вирусы отличаются скоростью распространения:

fast infection – вирус инфицирует любой файл “до которого может дотянуться”

sparse infection – вирус не инфицирует все подряд во избежание раннего обнаружения

Fast-infection viruses infect any file that they are capable of infecting. Others limit the rate of infection. This type of activity is known as sparse infection. Sparse infection means that the virus takes its time in infecting other files or spreading its damage.

СОБЫТИЯ и ИНЦИДЕНТЫ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ (security incidents & ALARMS)

Security incident – выявленная или неминуемая проблема в безопасности (NIST 800-61), например – слив, модификация или уничтожение персональных данных (PII, NPPI, PCI, PHI), неавторизованный доступ к интеллектуальной собственности, нарушение сервисов (DoS). По сути любой негатив для CIA triad.

A computer security incident is a violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices.

• • От disaster отличается тем, что касается подрыва ключевых аспектов CIA, а не широкого бедствия
  • От security event отличается тем, что явно несет какой-то ущерб для компании.

A cybersecurity incident is an adverse event that threatens business security and/or disrupts service.

Sometimes confused with a disaster, an information security incident is related to loss of confidentiality, integrity, or availability (CIA), whereas a disaster is an event that results in widespread damage or destruction, loss of life, or drastic change to the environment.

NIST Special Publication 800-61:
“An event is any observable occurrence in a system or network. Events include a user connecting to a file share, a server receiving a request for a web page, a user sending email, and a firewall blocking a connection attempt. Adverse events ((incidents)) are events with a negative consequence, such as system crashes, packet floods, unauthorized use of system privileges, unauthorized access to sensitive data, and execution of malware that destroys data.”

Examples of incidents include exposure of or modification of legally protected data, unauthorized access to intellectual property, or disruption of internal or external services. 
• Attacker sends a crafted packet to a router and causes a denial-of-service condition.
• Attacker compromises a point-of-sale (POS) system and steals credit card information.
• Attacker compromises a hospital database and steals thousands of health records.
• Ransomware is installed in a critical server and all files are encrypted by the attacker.

Само понятие инцидента должно быть определено в компании – что является индидентом, а что нет. Сам же факт произошедшего инцидента должен триггерить процедуру ответных действий на него. Причем не все инциденты одинаковы по приоритету – дыра, которая привела к сливу персональных данных (PII, NPPI, PCI, PHI), обычно требует более строгое и быстрое расследование т.к. потенциально придется отчитываться перед контролирующими органами по нему. Приоритет инциденту обычно выставляется инцидент-менеджером или сотрудником ИБ, занимающимся расследованием. Приоритет обычно определяет сроки устранения и список эскалации о инциденте.

The starting point of incident management is to create an organization-specific definition of the term incident so that the scope of the term is clear. Declaration of an incident should trigger a mandatory response process.  

Not all incidents are equal in severity. Included in the incident definition should be severity levels based on the operational, reputational, and legal impact to the organization. Corresponding to the level should be required response times as well as minimum standards for internal notification.
For example, a breach of personally identifiable information (PII) typically requires strict disclosure under many circumstances.
Incidents are classified by severity relative to the impact they have on an organization. This severity level is typically assigned by an incident manager or a cybersecurity investigator. Each level has a maximum
response time and minimum internal notification requirements.

Incident handling, incident response, incidents priority

Incident handling, incident response – управление инцидентами – подразумевает, по сути, предсказуемый ответ на разные ситуации (инциденты). Incident response program обычно состоит из ряда документов, которые согласовываются на уровне руководства компании –

• политики – систематизируют документы,
• планы – описывают подходы,
• процедуры – подробно описывают конкретные шаги,
• людей – так же Incident response program включает ведущих инцидент людей (incident response team, SoC), ответственных за определеные зоны, процессы взаимодействия между людьми.

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

An incident response program is composed of policies, plans, procedures, and people.
- Incident response policies codify management directives.
- Incident response plans (IRPs) provide a well-defined, consistent, and organized approach for handling internal incidents as well as taking appropriate action when an external incident is traced back to the organization.
- Incident response procedures, standard operating procedures (SOPs) are detailed steps needed to implement the plan. ((подробнее о них ниже в примере NIST))

Having a good incident response plan and incident response process will help you minimize loss or theft of information and disruption of services caused by incidents.
.. Senior management approval of the incident response plan ..
.. How the incident response team will communicate with the rest of the organization and with other organizations ..

The important thing to remember is that not all policies need to be defined on the first day.

Ключевой персонал управления инцидентами – координаторы, дежурные, члены IRT, внешние советники.

• IRC – (Incident Response Coordinator) (дежурный), член команды IRC. Является ключевой точкой для всех инцидентов. Получает информацию об инциденте, проверяет и логгриует его, нотифицирует при необходимости соответствующий персонал, включая менеджера, ответственного за инцидент (Designated Incident Handler)
• DIH – (Designated Incident Handler) – менеджер, ответственный за инцидент, имеющий навыки кризис-менеджмента и навыки коммуникаций, опыт, знания и стойкость для управления инцидентом. Взаимодействует с топ-менеджментом и IRT. DIH подключает членов команды IRT для решения инцидента.
• IRT – команда Incident Response Team, подробнее в CSIRT.

Key incident management personnel include incident response coordinators, designated incident handlers, incident response team members, and external
advisors. In various organizations, they may have different titles, but the roles are essentially the same.

The incident response coordinator (IRC) is the central point of contact for all incidents. Incident reports are directed to the IRC. The IRC verifies and logs the incident. Based on predefined criteria, the IRC notifies appropriate personnel, including the designated incident handler (DIH). The IRC is a member of the incident response team (IRT) and is responsible for maintaining all non-evidence-based incident-related documentation.

DIHs are senior-level personnel who have the crisis management and communication skills, experience, knowledge, and stamina to manage an incident. DIHs are responsible for three critical tasks: incident declaration, liaison with executive management, and managing the IRT. The IRT team as directed by the DIH is responsible for further analysis, evidence handling and documentation, containment, eradication and recovery, notification (as required), and post- incident activities.

Для помощи организациям в понимании как нужно обрабатывать security инциденты несколько письменных рекомендаций было создано, например, NIST Special Publication 800-61 – в документе подробно рассказано о работе с инцидентами – определение инцидента и связанных терминов, приоритизация, уведомления, документы и процедуры (policies, plans, procedures), координирование инцидентов, взаимодействие с третьими сторонами, ответственность и ее зона у ролей сотрудников/менеджмента, цели и объекты процедур, зона охвата процедур и проч, проч.

Several industry resources were created to help organizations establish a computer security incident response program and learn how to handle cybersecurity incidents efficiently and effectively. One of the best resources available is NIST Special Publication 800-61

Section 2.3 of NIST Special Publication 800-61 Revision 2 goes over the incident response policies, plans, and procedures, including information on how to coordinate incidents and interact with outside parties.
The policy elements described in NIST Special Publication 800-61 Revision 2 include the following:
• Definition of computer security incidents and related terms
• Prioritization or severity ratings of incidents
• Reporting and contact forms
• Statement of management commitment
• Purpose and objectives of the incident response policy
• The scope of the incident response policy
• Organizational structure and definition of roles, responsibilities, and levels of authority
• Performance measures

NIST also defines standard operating procedures (SOPs) as “a delineation of the specific technical processes, techniques, checklists, and forms used by the incident response team. SOPs should be reasonably comprehensive and detailed to ensure that the priorities of the organization are reflected in response operations.”

Incident handling, incident response в соответствии с NIST 800-601 включает 4 основные фазы:

1. подготовку – на основе оценки рисков проводится
   • обучение incident response team/SoC и обычных сотрудников,  зачастую в виде игр и даже учений (tabletop exercises, playbooks) на уровне технического персонала (technical simulations) или менеджеров (risk-based exercises), которые включают подготовку/проведение и отчетность
   • создание/развитие/закупка программных и аппаратных инструментов и ресурсов для их работы (анализ инцидентов, устранение инцидентов и проч) – примерами могут быть knowledge base, topology maps, inventory tables, log collection/correlation
   • оценка защищенности и целостности (конфигураций, времени и проч) всех элементов и устранение выявленных проблем.
2. обнаружение проблемы, анализ/обнаружение влияния и последствий (в том числе root cause), приоритизация – зачастую это самая сложная фаза, ряд инцидентов обнаружить легко (напр. DoS), но многие инциденты остаются необнаруженными из-за “blind spots” в сети (network visibility), существующим в вашей инфраструктуре, недели и месяцы! Эти blind spots надо устранять, используя разные инструменты (сканеры, аналитика). Источниками информации при инцидентах могут быть те, которые описаны выше, простой googl’инг, снифинг пакетов, ids/ips, netflow/ipfix (подробнее о network visibility и netflow в отдельной статье).
3. сдерживание разрастания проблемы (containment strategy, напр. через ограничение сетевого доступа или даже отключения уязвимых хостов), устранение и восстановление последствий. Так же в эту фазу включается сбор доказательств, определение ущерба (повреждения/воровства/недоступности сервисов и проч), необходимые ресурсы (временные/материальные) для сдерживания/устранения/восстановления, тип выбранного решения по покрытию инцидента (полное, частичное покрытие), тип выбранного решения по времени (аварийное, временное, постоянное). 
4. активность после инцидента “lessons learned/post-mortem” – изменение процедур/инфраструктуры для минимизации повторного возникновения. Кроме того в эту фазу включается сохранение доказательств. Все это применимо и к инцидентам, касающимся безопасности.

The preparation phase includes creating and training the incident response team, as well as deploying the necessary tools and resources to successfully investigate and resolve cybersecurity incidents.
In this phase, the incident response team creates a set of controls based on the results of risk assessments.
- Making sure that the organization has appropriate incident analysis hardware and software as well as incident mitigation software.
- Making sure the organization has appropriately deployed host security, network security, and malware prevention solutions
- Developing user awareness training
- Keep all host clocks synchronized.
Establishing a robust response capability ensures that the organization is prepared to respond to an incident swiftly and effectively. IRT should receive training specific to their individual and collective responsibilities. Recurring tests, drills, and challenging incident response exercises can make a huge difference in responder ability. Knowing what is expected decreases the pressure on the responders and reduces errors. It should be stressed that the objective of incident response exercises isn’t to get an “A” but rather to honestly evaluate the plan and procedures, to identify missing resources, and to learn to work together as a team.

Many organizations take advantage of tabletop (simulated) exercises to further test their capabilities. These tabletop exercises are an opportunity to practice and also perform gap analysis on their incident response processes and procedures. In addition, these exercises may allow them to create playbooks for incident response. Developing a playbook framework makes future analysis modular and extensible. When developing playbooks, focus on organization and clarity within your own framework.  
Tabletop exercises could be technical and also at the executive level. You can create technical simulations for your incident response team and also risk-based exercises for your executive and management staff. A simple methodology for an incident response tabletop exercise includes the following steps:
1. Preparation: Identify the audience, what you want to simulate, and how the exercise will take place.
2. Execution: Execute the simulation and record all findings to identify all areas for improvement in your program.
3. Report: Create a report and distribute it to all the respective stakeholders. Narrow your assessment to specific facets of incident response. You can compare the results with the existing incident response plans. You should also measure the coordination among different teams within the organization and/or external to the organization. Provide a good technical analysis and identify gaps.


The detection and analysis phase is one of the most challenging phases. Although some incidents are easy to detect (for example, a denial-of-service attack), many breaches and attacks are left undetected for weeks or even months. This is why detection might be the most difficult task in incident response. The typical network is full of “blind spots” where anomalous traffic goes undetected. Implementing analytics and correlation tools is critical to eliminating these network blind spots.
• Use Internet search engines for research.
• Run packet sniffers to collect additional data.

NIST Special Publication 800-61 Revision 2 also defines the following criteria for determining the appropriate containment, eradication, and recovery strategy:
• The potential damage to and theft of resources, Service availability
• The need for evidence preservation
• Time and resources needed to implement the strategy
• Effectiveness of the strategy (for example, partial containment or full containment)
• Duration of the solution (for example, emergency workaround to be removed in four hours, temporary workaround to be removed in two weeks, or permanent solution)


The post-incident activity phase includes lessons learned, how to use collected incident data, and evidence retention. NIST Special Publication 800-61 Revision 2 includes several questions that can be used as guidelines during the lessons learned meeting(s):
• Exactly what happened, and at what times?
• How well did the staff and management perform while dealing with the incident?
• Were the documented procedures followed? Were they adequate?
• What information was needed sooner?
• Were any steps or actions taken that might have inhibited the recovery?
• What would the staff and management do differently the next time a similar incident occurs?
• How could information sharing with other organizations be improved?
• What corrective actions can prevent similar incidents in the future?
• What precursors or indicators should be watched for in the future to detect similar incidents?
• What additional tools or resources are needed to detect, analyze, and mitigate future incidents?

Управление security инцидентами (так же как и compliance) должно раcпространяться на третьи стороны – эти организации нужно на контрактной основе обязывать уведомлять о фактах произошедших у них индидентов. Кроме того, о инцидентах в вашей компании зачастую придется так же взаимодействовать с третьими сторонами – правоохранительными органами, партнерами, медиа, провайдерам, интеграторами, программными и аппаратными вендорами, а так же в поисках внешней экспертизы (координационные центры, другие команды SoC/incident response). Так же могут быть центры обмена подобной информацией в целом или для конкретной индустрии – например, FS-ISAC (Financial Services Information Sharing and Analysis Center). Взаимодействие со всеми этими внешними организациями, так же как и со внутренними, должно быть описано в incident response plan. Обмен информацией о событиях ИБ с неавторизованными участниками (и зачастую даже с неавторизованными представителями! авторизованных участников) должен быть запрещен во избежание слива информации. 

Incident management extends to third-party environments. Business partners and vendors should be contractually obligated to notify the organization if an actual or suspected incident occurs.

During the investigation and resolution of a security incident, you might also need to communicate with outside parties regarding the incident. Examples include, but are not limited to, contacting law enforcement, fielding media inquiries, seeking external expertise, and working with Internet service providers (ISPs), the vendor of your hardware and software products, threat intelligence vendor feeds, coordination centers, and members of other incident response teams. You can also share relevant incident indicator of compromise (IoC) information and other observables with industry peers. A good example of information- sharing communities is the Financial Services Information Sharing and Analysis Center (FS-ISAC).

Avoid leaking sensitive information regarding security incidents with unauthorized parties. These actions could potentially lead to additional disruption and financial loss. 

You should also maintain a list of all the contacts at those external entities, including a detailed list of all external communications for liability and evidentiary purposes.

Incident reporting:

• Должен быть простым, так, чтобы любой сотрудник мог это сделать
• Приоритет инциденту, выставляемый инициатором не может являться конечным т.к. зачастую тот, кто обнаружил инцидент не имеет всех знаний и компетенций для понимания его приоритета
• Зачастую люди не сообщают о инцидентах – их боязни ошибиться, лени, нежелании быть “в каждой бочке затычкой” или просто хотят “лишний раз не высовываться”. Компания же, при всем при этом, должна приветствовать и даже поощрять заведение инцидентов и негативно не реагировать на false positive заведенные инциденты.

Incident reporting is best accomplished by implementing simple, easy-to-use mechanisms that can be used by all employees to report the discovery of an incident. Employees should be required to report all actual and suspected incidents. They should not be expected to assign a severity level, because the person who discovers an incident may not have the skill, knowledge, or training to properly assess the impact of the situation.

People frequently fail to report potential incidents because they are afraid of being wrong and looking foolish, they do not want to be seen as a complainer or whistleblower, or they simply don’t care enough and would prefer not to get involved. These objections must be countered by encouragement from management. Employees must be assured that even if they were to report a perceived incident that ended up being a false positive, they would not be ridiculed or met with annoyance. On the contrary, their willingness to get involved for the greater good of the company is exactly the type of behavior the company needs! They should be supported for their efforts and made to feel valued and appreciated for doing the right thing.

Нужно держать как можно меньшее количество активных инцидентов, закрывать уязвимости еще до того, как они будут эксплуатированы. После же инцидентов нужно обязательно искать “root-cause” (если не нашли во время устранения) оценивать эффективность его обработки и составлять “lessons learned/post-mortem” – выученные уроки с инцидента.

Incident response plan will help you enhance your incident response program by using lessons learned and information obtained during the security incident.
.. Metrics for measuring the incident response capability and its effectiveness ..

Разумно предовращать эти индиденты (incident preparedness), осуществляя:

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

In general terms, incident management is defined as a predicable response to damaging situations.

The first step is incident detection, because you need to be aware of an ongoing incident before you can react to it. Once you've detected the incident, you can begin containment to minimize the impact of the incident.

Ideally, you'd figure out what caused the incident in the first place, and make changes to avoid a similar incident from occurring in the future.

Keeping the number of incidents as low as possible should be an organizational priority. That means as much as possible identifying and remediating weaknesses and vulnerabilities before they are exploited.

A sound approach to improving an organizational security posture and preventing incidents is to conduct periodic risk assessments of systems and applications.

Incident preparedness includes having policies, strategies, plans, and procedures. Organizations should create written guidelines, have supporting documentation prepared, train personnel, and engage in mock exercises. An actual incident is not the time to learn. Incident handlers must act quickly and make far- reaching decisions—often while dealing with uncertainty and incomplete information. They are under a great deal of stress. The more prepared they are, the better the chance that sound decisions will be made.

Forensic analysis – криминалистический анализ логов/данных с хостов, серверов или сетевых устройств (digital forensic evidence). Чаще всего криминалистический анализ делается на битовой копии данных утилитами, во избежание изменения оригинальных данных (софт начал выпиливаться после того, как увидел, подозрительную для себя активность – напр. недоступность интернета). Оригинальная зараженная система при этом должна быть переведена в режим read only – например, используя джамперы на HDD (сейчас уже редко встретишь, да и данные зачастую в облаке) или, например, аппаратными или программными write blocker. Так же крайне желательно хранить носитель с доказательствами в антистатической сумке или forensic room (и такое бывает, хотя у нас это скорее защищенная “переговорка”) в которой реализована клетка Фарадея (Faraday cage), клетки из проводящих материалов, препятствующих радио волнам попадать внутрь клетки и выбраться из клетки (mobile, wi-fi, наводкаи, etc). 

В контексте криминалистической экспертизы так же крайне важно сохранение каждого чиха (chain of custody), который делался по расследованию инцидента и работе с доказательствами вплоть до судебного процесса – как вы узнали об инциденте, когда/как/кем собраны доказательства, как хранили/перевозили (lockable container?)/кто имел доступ к доказательству (желательно, чтобы ответственный всегда был с доказательством).

Digital forensic evidence is information in digital form found on a wide range of endpoint, server, and network devices—basically, any information that can be processed by a computing device or stored on other media.

A method often used for evidence preservation is to work only with a copy of the evidence—in other words, you do not want to work directly with the evidence itself. This involves creating an image of any hard drive or any storage device.

To prevent or minimize contamination of the suspect’s source device, you can use different tools, such as a piece of hardware called a write blocker, on the specific device so you can copy all the data (or an image of the system). 

А full bit-for-bit copy is the preferred forensic process. The file created on the target device is called a forensic image file.
The imaging process is intended to copy all blocks of data from the computing device to the forensics professional evidentiary system. This is sometimes referred to as a “physical copy” of all data, as distinct from a logical copy, which copies only what a user would normally see. Logical copies do not capture all the data, and the process will alter some file metadata to the extent that its forensic value is greatly diminished, resulting in a possible legal challenge by the opposing legal team.

According to the National Institute of Standards and Technology (NIST), the investigator follows a set of procedures designed to prevent the execution of any program that might modify the disk contents. These procedures involve a layered defense against any modifications to the source disk using the following strategies:
- Where possible, set a hardware jumper to make the disk read only.
- Use an operating system and other software that are trusted not to write to the disk unless given explicit instructions.
- Use a hard disk write block tool to intercept any inadvertent disk writes.
You must prevent electronic static or other discharge from damaging or erasing evidentiary data. Special evidence bags that are antistatic should be used to store digital devices. It is very important that you prevent electrostatic discharge (ESD) and other electrical discharges from damaging your evidence.

Some organizations even have cyber-forensic labs that control access to only authorized users and investigators. One method often used involves constructing what is called a Faraday cage. This “cage” is often built out of a mesh of conducting material that prevents electromagnetic energy from entering into or escaping from the cage. Also, this prevents devices from communicating via Wi-Fi or cellular signals.

Chain of custody is the way you document and preserve evidence from the time that you started the cyber- forensics investigation to the time the evidence is presented in court. It is extremely important to be able to show clear documentation of the following:
• How the evidence was collected • When it was collected
• How it was transported
• How is was tracked
• How it was stored
• Who had access to the evidence and how it was accessed
What’s more, transporting the evidence to the forensics lab or any other place, including the courthouse, has to be done very carefully. It is critical that the chain of custody be maintained during this transport. When you transport the evidence, you should strive to secure it in a lockable container. It is also recommended that the responsible person stay with the evidence at all times during transportation.

Security Operations Centers (SOC), Incident Response Teams (CSIRT, PSIRT, CERT, MSSP), InfoSec

Существуют различные типы incident response команд и других security команд. Все они призваны минимизировать риски, возникающие от инцидентов ИБ. Стоимость потенциальных угроз зачастую значительно выше содержания в штате специалистов ИБ, которые позволят этим угрозам или не стать инцидентами или устранить эти инциденты с минимальными потерями для бизнеса. Так же есть опция аутсорса подобных услуг (MSSP, подробнее ниже).

Determining the value of a CSIRT can be challenging. One of the main questions that executives will ask is, what is the return on investment for having a CSIRT? The main goals of the CSIRT are to minimize risk, contain cyber damage, and save money by preventing incidents from happening—and when they do occur, to mitigate them efficiently. 

Many studies in the past have covered the cost of security incidents and the cost of breaches. Also, the Ponemon Institute periodically publishes reports covering these costs. It is a good practice to review and calculate the “value add” of the CSIRT. This calculation can be used to determine when to invest more, not only in a CSIRT, but also in operational best practices. In some cases, an organization might even outsource some of the cybersecurity functions to a managed service provider, if the organization cannot afford or retain security talent.

• InfoSec/SoC – команда ИБ.
• CSIRT (Computer Security Incident Response Team) – наиболее популярный тип IRT (Incident Response Team). Плотно работает с InfoSec (командой ИБ) и другими IRT, в небольших организациях CSIRT и InfoSec объединены. В крупных CSIRT отвечает за инциденты ИБ, а InfoSec за эксплуатацию и деплой. В очень крупных бывает несколько CSIRT команд, каждая со своей специализацией. Хорошее описание работы/целей/ответственности CSIRT сделали в CERT.ORG. Подключать члена CSIRT к инциденту или нет решает менеджер по инциденту (DIH). Обычно в CSIRT находятся члены с разными “скилами” – менеджмент, ИБ, физическая безопасность, ИТ, право, комплаенс, HR, взаимодействие с клиентами и прессой. Какие то члены участвуют во всех инцидентах, другие – когда необходимы. Поэтому и задачи крайне разнообразные – управление инцидентом, анализ ситуации, разработка и реализация методик сдерживания/исправления инцидента, взаимодействие с клиентами и органами власти, анализ root cause и lessons learned. 

The CSIRT is typically the team that works hand in hand with the information security teams (often called InfoSec). In smaller organizations, InfoSec and CSIRT functions may be combined and provided by the same team. In large organizations, the CSIRT focuses on the investigation of computer security incidents, whereas the InfoSec team is tasked with the implementation of security configurations, monitoring, and policies within the organization. Depending on the size of the organization, there may be a single team or multiple teams, each with its own specialty. 

The IRT members generally represent a cross-section of functional areas, including senior management, information security, information technology (IT), operations, legal,compliance, HR, public affairs and media relations, customer service, and physical security. Some members may be expected to participate in every response effort, whereas others (such as compliance) may restrict involvement to relevant events.

Tasks assigned to the IRT include but are not limited to the following:
• Overall management of the incident
• Triage and impact analysis to determine the extent of the situation
• Development and implementation of containment and eradication strategies
• Compliance with government and/or other regulations
• Communication and follow-up with affected parties and/or individuals
• Communication and follow-up with other external parties, including the board of directors, business partners, government regulators (including
federal, state, and other administrators), law enforcement, representatives of the media, and so on, as needed
• Root cause analysis and lessons learned
• Revision of policies/procedures necessary to prevent any recurrence of the incident

• PSIRT (Product Security Incident Response Team) – рассматривают инциденты по ИБ, относящиеся к продукту-ам компании вендора (напр. Omar Santos из Cisco инженер из команды PSIRT). PSIRT узнают о уязвимостях в продукте из разных источников – во время внутреннего тестирования, во время разработки или уже из внешних источников (во время тендеров, при деплое, эксплуатации). Практически невозможно на этапе дизайна и разработке устранить все уязвимости, поэтому в компании, разрабатывающей security продукты должен быть внедрен SDL (подробнее в SDL). Так же при работе команда PSIRT анализирует какой TPS (third party software) используется, смотрит на наличие уязвимостей в этом софте (подробнее в SDL -> TPS).
• MSSP (Managed Security Service Provider) – компания, предоставляющая услуги по обслуживанию сервисов ИБ (включая зачастую IRT) для компании-заказчика. На этом рынке работает и Cisco. Аутсорсинг Security услуг с каждым годом все более популярен.

Cisco, along with several other vendors, provides incident response and managed security services to its customers. These incident response teams and outsourced CSIRTs operate a bit differently because their task is to provide support to their customers. However, they practice the tasks outlined earlier in this chapter for incident response and CSIRTs.
Outsourcing has been a long practice for many companies, but the onset of the complexity of cybersecurity has allowed it to bloom and become bigger as the years go by in the world of incident response.

• National CSIRT/CERT (Computer Emergency Response Team) – национальный ERT. Большая часть представлена на сайте FIRST (Forum of Incident Response and Security Teams). Примерами являются:
  • US-CERT
  • Indian Emergency Response Team
  • CERT Australia

Из Российских там три:

• • Центробанковский CERT, в которой стекаются инцидент со всего фин. сектора
  • Kaspersky CERT
  • Infosecurity CERT

Национальные CERT, помимо обеспечения безопасности/расследования инцидентов в ключевых для страны сегментах (финансовом, медицинском, индустриальном, IT и т.д) и информации о разных уязвимостях, обычно предоставляют какое-то обучение, best-practices.

These national CERTS and CSIRTs aim to protect their citizens by providing security vulnerability information, security awareness training, best practices, and other information.

“US-CERT’s critical mission activities include:
• Providing cybersecurity protection to Federal civilian executive branch agencies through intrusion detection and prevention capabilities.
• Developing timely and actionable information for distribution to federal departments and agencies; state, local, tribal and territorial (SLTT)governments; critical infrastructure owners and operators; private industry; and international organizations.
• Responding to incidents and analyzing data about emerging cyber threats.
• Collaborating with foreign governments and international entities to enhance the nation’s cybersecurity posture.”

• Coordination center – буквально несколько организацией в мире, которые помогают координировать уязвимости вендорам, провайдерам и исследователям, проводят исследования ИБ, проводят курсы/семинары/вебинары/подкасты, разрабатывают инструменты, анализируют ваши регламенты и практики на соответствие best practice. В общем оказывают большое количество consulting услуг. Один из лучших примеров – cert.org (CERT Division of the Software Engineering Institute). Они взаимодействуют с правительственными организациями U.S. Department of Defense, Department of Homeland Security, FBI, CIA и ключевыми организациями.

There are different types of incident response teams. The most popular is the computer security incident response team (CSIRT). Others include the following:
• Product security incident response team (PSIRT)
• National CSIRT and computer emergency response team (CERT)
• Coordination center
• The incident response team of a security vendor and managed security service provider (MSSP)

Software and hardware vendors may have separate teams that handle the investigation, resolution, and disclosure of security vulnerabilities in their products and services. Typically, these teams are called product security incident response teams (PSIRTs).

A PSIRT can learn about a vulnerability in a product or service during internal testing or during the development phase. However, vulnerabilities can also be reported by external entities, such as security researchers, customers, and other vendors.

-- тут инфа про то как создается CSIRT в организации -- (имхо ненужная по большому счету инфа
Establishing a CSIRT involves the following steps:
Step 1. Defining the CSIRT constituency
Step 2. Ensuring management and executive support
Step 3. Making sure that the proper budget is allocated
Step 4. Deciding where the CSIRT will reside within the organization’s hierarchy
Step 5. Determining whether the team will be central, distributed, or virtual
Step 6. Developing the process and policies for the CSIRT
It is important to recognize that every organization is different, and these steps can be accomplished in parallel or in sequence. However, defining the constituency of a CSIRT is certainly one of the first steps in the process. When defining the constituency of a CSIRT, one should answer the following questions:
• Who will be the “customer” of the CSIRT?
• What is the scope? Will the CSIRT cover only the organization or also entities external to the organization? For example, at Cisco, all internal infrastructure and Cisco’s websites and tools (that is, cisco.com) are the responsibility of the Cisco CSIRT, and any incident or vulnerability concerning a Cisco product or service is the responsibility of the Cisco PSIRT.
• Will the CSIRT provide support for the complete organization or only for a specific area or segment? For example, an organization may have a CSIRT for traditional infrastructure and IT capabilities and a separate one dedicated to cloud security.
• Will the CSIRT be responsible for part of the organization or all of it? If external entities will be included, how will they be selected?


---- COORDINATION CENTER ----
Several organizations around the world also help with the coordination of security vulnerability disclosures to vendors, hardware and software providers, and security researchers.
One of the best examples is the CERT Division of the Software Engineering Institute (SEI). Their website can be accessed at cert.org, and their “About Us” page summarizes well their role and the role of many coordination centers alike:
“CERT Division of the Software Engineering Institute (SEI), we study and solve problems with widespread cybersecurity implications, research security vulnerabilities in software products, contribute to long-term changes in networked
systems, and develop cutting-edge information and training to help improve cybersecurity.
“We are more than a research organization. Working with software vendors, we help resolve software vulnerabilities. We develop tools, products, and methods to help organizations conduct forensic examinations, analyze vulnerabilities, and monitor large-scale networks. We help organizations determine how effective their security-related practices are. And we share our work at conferences; in blogs, webinars, and podcasts; and through our many articles, technical reports, and white papers. We collaborate with high-level government organizations, such as the U.S. Department of Defense and the Department of Homeland Security (DHS); law enforcement, including the FBI; the intelligence community; and many industry organizations.

Типы alert/alarm/incidents в security устройствах IDS/IPS:

False positive (ложное срабатывание) – по сути false alarm. Срабатывание системы безопасности на легитимный трафик. Могут быть совсем не безобидным явлением, когда таких эвентов будет много – они будут требовать время на отработку и отвлекать от настоящих security events/incidents.

The term false positive is a broad term that describes a situation in which a security device triggers an alarm but there is no malicious activity or an actual attack taking place. In other words, false positives are “false alarms,” and they are also called “benign triggers.” False positives are problematic because by triggering unjustified alerts, they diminish the value and urgency of real alerts. If you have too many false positives to investigate, it becomes an operational nightmare, and you most definitely will overlook real security events.

False negative (ложное несрабатывание) – несрабатывание системы безопасности на malicious трафик.

There are also false negatives, which is the term used to describe a network intrusion device’s inability to detect true security events under certain circumstances. In other words, a malicious activity that is not detected by the security device.

True positive (правильное срабатывание) – успешное обнаружение security events и срабатывание механихмов защиты на него.

A true positive is a successful identification of a security attack or a malicious event.

A true negative is when the intrusion detection device identifies an activity as acceptable behavior and the activity is actually acceptable.

MALWARE EVASIONS

Malware всегда пытаются скрыть свои действия и минимизировать вероятность обнаружения пользователем или продуктами безопасности их активности. Malware развиваются в соответствии с развитием продуктов безопасности. Вирус может мутировать при распространении – это называется полиморфизм. Полиморфный вирус может изменять себя каждый раз при реплицировании и заражении нового файла – в итоге он может не обнаружится антивирусным ПО в каждом конкретном файле.

- Most malware writers want to avoid detection for as long as possible, 
they go to great lengths to hide their activity and keep their actions hidden. 
- As the antivirus and security companies have developed better ways to detect malware, malware authors have fought back by trying to develop malware that is harder to detect.
- A polymorphic virus can change its signature every time it replicates and infects a new file. This technique makes it much harder for the antivirus program to detect it.

Методы, которые усложняют static анализ вирусов с использованием декомпиляторов/дизасемблеров – шифрование, обуфскация, кодирование, Anti-VM, Anti-debugger.

Don’t expect malware writers to make the analysis of their code easy. Many techniques can be used to make disassembly challenging:
• Encryption
• Obfuscation
• Encoding
• Anti-VM
• Anti-debugger

Кроме того вирусы сегодня не распространяются так широко как ранее – они пишутся под конкретную цель, что в итоге делает сложным обнаружения семпла вируса и написания сигнатуры на него. Что своего рода тоже “evasion technique”.

One of the biggest changes is that malware creators don’t massively spread viruses and other malware the way they used to. Much of the malware today is written for a specific target. By limiting the spread of the malware and targeting only a few victims, malware developers make finding out about the malware and creating a signature to detect it much harder for antivirus companies.

Распространятся malware софт может в wrappers – пакетах программ, включающих два или более исполняемых файла. Так же софт может распространятся в packers в архивах подобных WinZip, Rar, Tar. <Скрыться на хосте несложно, берешь packer, который перепаковывает malware и обходишь таким образом антивирус.> Еще одним типом является droppers – по сути тоже самое что wrappers. Crypters шифруют код malware используя алгоритмы шифрования или преобразования данных. Делаются все эти манипуляции (wrappers, packers, droppers, crypters) для обфускации обнаружения/активности malware антивирусным/ips ПО при установке malware в систему жертвы.

- A wrapper is a program used to combine two or more executables into a single program. Wrappers are also referred to as binders, packagers, and EXE binders because they are functional equivalent of binders for Windows Portable Executable files. Besides allowing you to bind a program, wrappers add additional layers of obfuscation and encryption around the target file, essentially creating a new executable file.
- Packers are similar to programs such as WinZip, Rar and Tar because they compress files. However, whereas compression programs compress files to save space, packers do this to obfuscate the activity of the malware. The idea is to prevent anyone from viewing the malware's code until it is placed in memory. Packers serve a second valuable goal to the attacker in that they work to bypass network security protection mechanisms, such as host- and network-based intrusion detection systems. The malware packer will decompress the program only when in memory, revealing the program’s original code only when executed. This is yet another attempt to bypass antimalware detection.
- Droppers are software designed to install malware payloads on the victim's system. Droppers try to avoid detection and evade security controls by using several methods to spread and install the malware payload. Basically, a dropper is just another name for a wrapper, because a dropper is a standalone program that drops different types of standalone malware to a system.
- Crypters function to encrypt or obscure the code. Some crypters obscure the contants of the malware by applying an encryption algorithm. Crypters can use anything from AES, RSA to even Blowfish or might use more basic obfuscation techniques such as XOR, Base 64 encoding, or even ROT13.

Malware может использовать многоуровневые подходы к обвускации и шифрования своего кода и единичное или совокупное использование всех этих манипуляций (wrappers, packers, droppers, crypters) приводит к тому, что обнаружение malware cтановится все более сложной задачей.

The fact is that malware detection is much more difficult today than in the past. Today, it is not uncommon for attackers to use multiple layers of techniques to obfuscate code, make malicious code undetectable from antivirus, and employ encryption to prevent others from examining malware. The result is that modern malware improves the attackers’ chances of compromising a computer without being detected. These techniques include wrappers, packers, droppers, and crypters.

Примеры сокрытия в ОС:

• для запуска после перезагрузки – ключи регистра, startup folder, файлы Win.ini. и System.ini
• для блокировки апдейтов от вендоров ИБ или редиректа трафика клиента куда угодно (напр. подмена рекламы) добавляем необходимые адреса в файле hosts (на неработающие в случае вендоров ИБ, на необходимые в случае редиректа)

- To force the spyware to restart each time the system boots, code is usually hidden in the Registry run keys, the Windows Startup folder, the Windows load= or run= lines found in the Win.ini file, or the Shell= line found in the Windows System.ini file.
- Spyware, like all malware, may also make changes to the hosts file. This is done to block the traffic to all the download or update servers of the well-known security vendors or to redirect traffic to servers of their choice by redirecting traffic to advertisement servers and replacing the advertisements with their own.

Depix is a tool for recovering passwords from pixelized screenshots.
This implementation works on pixelized images that were created with a linear box filter.
In this article I cover background information on pixelization and similar research.

# python3 depix.py -p pic2.png -s images/searchimages/black-shell-dict-putty.PNG -o output2.png
INFO:root:Loading pixelated image from pic2.png
INFO:root:Loading search image from images/searchimages/black-shell-dict-putty.PNG
INFO:root:Finding color rectangles from pixelated space
INFO:root:Found 494 same color rectangles
INFO:root:480 rectangles left after moot filter
INFO:root:Found 77 different rectangle sizes
INFO:root:Finding matches in search image
INFO:root:Removing blocks with no matches
INFO:root:Splitting single matches and multiple matches
INFO:root:[3 straight matches | 23 multiple matches]
INFO:root:Trying geometrical matches on single-match squares
INFO:root:[3 straight matches | 23 multiple matches]
INFO:root:Trying another pass on geometrical matches
INFO:root:[3 straight matches | 23 multiple matches]
INFO:root:Writing single match results to output
INFO:root:Writing average results for multiple matches to output
INFO:root:Saving output image to: output2.png

Network evasions

Примеры:

• fragmentation
• segmentation
• polymorphic like obfuscation/encoding/encryption (HTTP, SMTP, etc)
• time delay attacks
• attacks under load
• промежуточные системы типо proxy (подмена IP/PORTS)
• туннелирование – любое

The following are some of the most common evasion techniques against traditional IDS and IPS devices:
• Fragmentation: When the attacker evades the IPS box by sending fragmented packets.
• Using low-bandwidth attacks: When the attacker uses techniques that use low bandwidth or a very small number of packets in order to evade the system.
• Address spoofing/proxying: Using spoofed IP addresses or sources, as well as using intermediary systems such as proxies to evade inspection.
• Pattern change evasion: Attackers may use polymorphic techniques to create unique attack patterns.
• Encryption: Attackers can use encryption to hide their communication and information.

Трояны (как и большая часть другого malware) обычно пытаются скрытно взаимодействовать с сетью/внешним миром (covert; covert channel), нежели открыто передавать данные (overt). Одним из первых документов описывающих концепцию скрытного взаимодействия (передачи информации) является Trusted Computer System Evaluation Criteria (TCSEC).

Trojans can communicate in several ways. Some use covert communications. These programs make no attempt to hide the transmission of data as it is moved on to or off of the victim’s computer. Most use covert communication channels. This means that the hacker goes to lengths to hide the transmission of data to and from the victim.

If you look at the history of covert communications, you will see that the Trusted Computer System Evaluation Criteria (TCSEC) was one of the first documents to fully examine the concept of covert communications and attacks.

Скрытые коммуникации могут быть реализованы на базе практически любого протокола, который используется в сети для обмена данными между конечными хостами, особенно часто этим протоколом является один из следующих: IPv4/IPv6, TCP, UDP, ICMP, DNS.

How do covert communications work? Well, the design of TCP/IP offers many opportunities for misuse. The primary protocols for covert communications include IPv4/IPv6, TCP, UDP, ICMP, DNS.

IPv6 используется для этой задачи часто т.к. edge устройства зачастую не сконфигурированы или даже не поддерживают распознавание IPv6 трафика и он на них не запрещен. Кроме того (по мнению US-CERT) недостатком считается функционал IPv6 autoconfiguration. В итоге возможно туннелирование сетевого трафика приватной сети поверх сети Интернет используя тулзы вроде 6tunnel, socat, nt6tunnel, relay6. Нужно понимать, что даже если продукты информационной безопасности поддерживают распознавание IPv6, эти же продукты могут не справится с задачей корректного анализа IPv6, когда он инкапсулирован в IPv4.

- IPv6 is like all protocols in that it can be abused or manipulated to act as a covert channel. This is primarily possible because edge devices might not be configured to recognize IPv6 traffic even though most operating systems have support for IPv6 turned on. According to US-CERT, Windows misuse relies on several factors:
• Incomplete or inconsistent support for IPv6
• The IPv6 autoconfiguration capability
• Malware designed to enable IPv6 support on susceptible hosts
• Malicious application of traffic “tunneling,” a method of Internet data transmission in which the public Internet is used to relay private network data
- There are plenty of tools to tunnel over IPv6, including 6tunnel, socat, nt6tunnel, and relay6. 
- The best way to maintain security with IPv6 is to recognize that even devices supporting IPv6 may not be able to correctly analyze the IPv6 encapsulation of IPv4 packets.

Точно так же как IPv6, ICMP протокол может так же использоваться для туннелирования трафика. Это не говоря про DNS, TCP over HTTP (ssh -> netcat -> HTTP) или даже создания таннеля за счет передачи информации через файл.

The second protocol that might be tunneled at the Internet layer is ICMP.

How does it work?
The program starts a TCP listener, and when a connection is received it writes the TCP data into a file. This same file is read by the counterpart program, which establishes a TCP connection and onforwards the TCP data. To avoid the shared file growing indefinitely, it is purged whenever it gets larger than 10 MB.

А вот чем занимаются американские школьники, когда им блокируют интернет в школе (см. README): https://github.com/NateChoe1/tcp-over-http

BACKDOOR.WIN32.ACKCMD
- Клиентская часть запускается на компьютере злоумышленника и позволяет отправлять команды серверной части, установленной на компьютере жертвы. В качестве параметра при запуске необходимо указать адрес заражённой машины.
- Особенность этого бекдора в том, что для связи он использует только ACK-пакеты. В данном случае стандартное соединение не происходит, а сразу передаются данные, причём через ACK-пакеты. Эта особенность позволяет троянцу обходить некоторые межсетевые экраны.

Although SYN packets occur only at the beginning of the session, ACKs may occur thousands of times. They confirm that data was received. That is why packet-filtering devices build their rules on SYN segments. It is an assumption on the firewall administrator’s part that ACKs occur only as part of an established session. It is much easier to configure, and it reduces workload. To bypass the SYN blocking rule, a hacker may attempt to use TCP ACK packets as a covert communication channel. Tools such as AckCmd serve this exact purpose.

В контексте UDP он может вообще не логгироваться как соединение в файрволе или по умолчанию иметь разрешающее правило для DNS трафика. Примером backdoor на основе DNS являются: UDP tunnel (туннелируем TCP в UDP пакетах), DNSCAT (туннелируем данные в DNS протокол). Безусловно резкий скачек DNS трафика может быть подозрителен для администраторов/ИБ, но особо умные делают его отправку по расписанию.

UDP is stateless and, as such, may not be logged in firewall connections; some UDP-based applications such as DNS are typically allowed through the firewall and might not be watched closely by network and firewall administrators.This means it’s also open for attackers to use as a potential means to exfiltrate data.

Domain Name System (DNS) can be used for application layer tunneling.   You can easily detect a spike in DNS traffic; however, many times attackers move data using DNS without being detected for days, weeks, or months. They schedule the DNS exfiltration packets in a way that makes it harder for a security analyst or automated tools to detect.

There are several UDP tunnel tools that you should check out, including the following:
- UDP Tunnel: Also designed to tunnel TCP traffic over a UDP connection. 
- dnscat: Another option for tunneling data over an open DNS connection. 
This tool is designed to create an encrypted command-and-control (C&C) channel over the DNS protocol, which is an effective tunnel out of almost every network.

В контексте туннелирования на уровне приложения возможны сценарии использования HTTP(S), SSH, DNS и туннелирования в них данных других протоколов. Используя netcat можно передать данные поверх HTTP, а используя cryptcat поверх HTTPS.

- Application layer tunneling uses common applications that send data on allowed ports. For example, a hacker might tunnel a web session, port 80, through SSH port 22 or even through port 443. Because ports 22 and 443 both use encryption, it can be difficult to monitor the difference between a legitimate session and a covert channel.
- HTTP might also be used. Netcat is one tool that can be used to set up a tunnel to exfiltrate data over HTTP. If HTTPS is the transport, it is difficult for the network administrator to inspect the outbound data. Cryptcat (http://cryptcat.sourceforge.net) can be used to send data over HTTPS.

Social engineering (социальная инженерия)

• Фишинг/phishing/fishing
• Существуют целые компании, которые занимаются только эмуляцией фишинга – вводишь почты сотрудников, сложность фишинга (для распознания). Отсылаются сообщения, предоставляет статистика, по проблемным сотрудникам может быть проведено обучение/выговоры и т.д. и повторная компания на них (до тех пор, пока не станут фишинг-устойчивыми). 
• Социальный инжениринг это основной способ зайти в периметр. 80-90% крупных взломов происходит с той или иной составляющей социальной инженерии. При этом не нужно считать что пользователи тупые т.к. именно они чаще всего являются входной точкой, они могут не знать безопасных концепций/практик и нужно их просвещать, а думая и говоря что юзеры тупые ты их отталкиваешь от кооперации.

Phishing (fake email, spear phishing, email spoofing), Baiting (usb-drive), Tailgating (access to restricted area) – чаще всего решаются через обучение персонала

Encouraging people to lock their screens when they walk away from their computer is a very important behavior to reinforce. The same goes for checking the address of the website they're authenticating to, to make sure it's not a fake phishing site. It's also important that people are comfortable asking security questions when they're unsure.

Интересный кейс внедрения фишинг кода в 500 Android APP с аудиторией в 100 МЛН человек. Проверки Google Play на код видимо проходятся – судя по схеме нет опасного в самом коде. Андройд или ОПСОСы по описанию частично виноваты (не только пользовательская невнимательность/фишинг) – пользователь бы

• • явно не соглашался ни на каких подписки если бы знал, что они платные
  • вероятнее всего не согласился бы отдавать свои geolocation данные приложению “для котиков”

Dark Herring distributes malicious android applications through Google Play and third-party application stores.
Once installed, the infected device communicates with the first-stage URL that is hosted on CloudFront. The response contains the links to JavaScript files for instructing the application to communicate with C&C servers, exposing the geolocation of the victim's IP. Subsequently, the malware redirects victims to their geo-specific webpage to request phone numbers for verification. 
But in fact, the threat actors are submitting the victims' phone number to a Direct Carrier Billing service that begins the subscription by charging them 15 USD from their mobile bill every month. It is said that the threat actor published around 470 applications on the Google Play Store, with more than 105 million users having installed this scamware. 

Direct carrier billing (DCB) is an online mobile payment method which allows users to make purchases by charging payments to their mobile phone carrier bill. The global direct carrier billing market was valued at US$ 29.8 billion in 2019.

Software Development (атаки на софт)

• Безопасность на этапе разработки продукта: SDL, DevSecOps. Наиболее защищенные системы и приложения — те, для которых безопасность была ключевым моментом с самого начала. Безопасностью занимаются во время, а не после разработки.
  • DevSecOps – безопасность проектируется/исследуется/дорабатывается еще на этапе разработки продукта, автоматизируются проверки на безопасность продукта в CI/CD pipeline.

Команды, построенные по типу DеvSecOps, рассматривают безопасность как важнейший элемент создания приложения, наравне с его разработкой.
- Безопасность может смещаться и «влево», и «вправо». Возможность «смещения влево» для решения проблем безопасности на этапе разработки помогает отследить уязвимости на ранних этапах. Но важно, чтобы практика обеспечения безопасности «смещалась вправо», поддерживая работоспособность приложений в производственной среде.
- Безопасность проектируется, а не приделывается постфактум
- Безопасность — общая ответственность - В недавнем исследовании ESG 27% респондентов признались, что их команды по разработке приложений и DevOps не работают с командами кибербезопасности из-за опасений, что это замедлит их работу.
Внедрение DevSecOps требует изменения культуры. Основная идея DevSecOps в том, что каждый член команды принимает решения, держа в голове важность кибербезопасности. Недостаточно просто объединить три отдела под одним руководителем, придется изменить майндсет.
- И DevOps, и DevSecOps ставят во главу угла упрощение процессов за счет автоматизации. Такой подход позволяет командам автоматизировать обнаружение уязвимостей и методы обеспечения безопасности.

• • Secure Development Life сycle (SDL) – повторяемый и измеряемый процесс разработки, нужен для того, чтобы продукты были максимально безопасными и устойчивыми даже в случае обнаружения уязвимостей в них. Практически невозможно на этапе дизайна и разработке устранить все уязвимости, поэтому в компании, разрабатывающей security продукты должен быть внедрен SDL.

Every application and service, whether on-premises or in the cloud, needs to be designed with security in mind. For example, a denial-of-service attack might prevent customers from reaching your website or services and block you from doing business.

SDL обычно включает не только программирование:

• • Описание требований по безопасности к продукту
  • Безопасность третих сторон (Third-party software, TPS) – важный аспект т.к. в сегодняшних реалиях почти любая компания использует open-source и third-party (платный/бесплатный) софт. Получается PSIRT нужно отслеживать какие библиотеки используются (для этого есть специальные утилиты по скану source code/binaries), какие у них уязвимости и инициировать патчи этих уязвимостей. Так же нужно быть готовыми к тому, что вы не можете управлять продуктом третьей стороны полноценно – например, зачастую, уязвимости в них могут патчится месяцами и даже годами.
  • Дизайн безопасности
  • Безопасное программирование
  • Аналитика безопасности
  • Тестирование на уязвимости

Cisco Secure Development Lifecycle
Repeatable. Measurable. Resilient. Trustworthy.

The goal of the SDL is to provide tools and processes that are designed to accelerate the product development methodology, by developing secure, resilient, and trustworthy systems.

The dream of any vendor is to be able to find and patch all security vulnerabilities during the design and development phases. However, that is close to impossible. On the other hand, that is why a secure development life cycle (SDL) is extremely important for
any organization that produces software and hardware. Cisco has an SDL program that is documented at the following URL.
Cisco defines its SDL as “a repeatable and measurable process we’ve designed to increase the resiliency and trustworthiness of our products.” Cisco’s SDL is part of Cisco Product Development Methodology (PDM) and ISO9000 compliance requirements. 

It includes, but is not limited to, the following:
• Base product security requirements
• Third-party software (TPS) security • Secure design
• Secure coding
• Secure analysis
• Vulnerability testing

TPS security is one of the most important tasks for any organization. Most of today’s organizations use open source and third-party libraries. This approach creates two requirements for the product security team. The first is to know what TPS libraries are used, reused, and where. The second is to patch any vulnerabilities that affect such library or TPS components. For example, if a new vulnerability in OpenSSL is disclosed, what do you have to do? Can you quickly assess the impact of such a vulnerability in all your products?

If you include commercial TPS, is the vendor of such software transparently disclosing all the security vulnerabilities, including in its software? Nowadays, many organizations are including security vulnerability disclosure SLAs in their contracts with third-party vendors. This is very important because many TPS vulnerabilities (both commercial and open source) go unpatched for many months—or even years.

Many tools are available on the market today to enumerate all open source components used in a product. These tools either interrogate the product source code or scan binaries for the presence of TPS.

• Баги софта (bugs) – ошибки программирования, которые могут приводить к разного уровня угрозам – от мирных/незначительных инцидентов, до полной катастрофы. Как избежать: проводить code review, обновление языков программирования/библиотек/модулей/приложений, отключение ненужных приложений, ограничение доступа к нужным приложениям
• Неправильные практики программирования
  • validating input & sanitizing user input (подробнее в sql injection, XSS, buffer overflow)
  • hardcoded сенситивная информация (api credentials, passwords, пути, старый код)
  • комментарии с такой информацией, слив такой информации в публичные или плохо защищенные приватные репозитории – существует публично доступный список типов уязвимостей Common Weakness Enumeration (CWE), в котором слив информации через комменты обозначен отдельным ID – CWE-615
  • отсутствие error handling или наоборот слишком подробный error handling выдаваемый пользователю
  • небезопасные практики API (шифрование, аутентификация, несоответствие стандарту, отсутствие документации и проч) в API любого типа (SOAP+XML, REST+JSON, GraphQL, etc) – используем такие вещи как SWAGGER OpenAPI

Programming and development errors, often called “bugs,” can range in severity from benign to catastrophic.

CWE-615: Inclusion of Sensitive Information in Source Code Comments
While adding general comments is very useful, some programmers tend to leave important data, such as: filenames related to the web application, old links or links which were not meant to be browsed by users, old code fragments, etc.

Lack of Error Handling and Overly Verbose Error Handling
Improper handling of errors can introduce a variety of security problems for a web site. The most common problem is when detailed internal error messages such as stack traces, database dumps, and error codes are displayed to the user (hacker). These messages reveal implementation details that should never be revealed. Such details can provide hackers important clues on potential flaws in the site and such messages are also disturbing to normal users.

Примеры атак на аутентификацию и авторизацию:

1. Brute forcing
2. Session hijacking
3. Redirecting
4. Использование default или weak credentials
5. Использование authn/authz/encryption/hash уязвимостей (напр. WEP, RC5, MD5, DES, Kerberos)

Brute force

• Большое количество словарей тут
• Password attacks напр. brute force, dictionary обычно митигируются путем использования strong passwords, 2FA, captcha, IPS
• Brute force так же используется как атака для взлома шифрования (подробнее ниже)
• Offline атаки на пароли (попытка найти пароль на основе hash/зашифрованного content, как, например в Wi-Fi) более опасны в сравнении с online – т.к.
  1. их попытки не логгируются и не обрабатываются в системах, доступ к которым пытается получить взломщик – после ряда неудачных попыток  аутентификации – не будет паузы/блокировки аккаунта/запроса каких-то доп. данных/reCAPTCHA. Причем капчи бывают очень разные – от простого распознавания симполов/цифр и ротации изображения, до решения математических или визуальных задач.
  2. возможен перебор намного большего количества credentials в секунду.

Online brute-force attacks: In this type of attack, the attacker actively tries to log in to the application directly by using many different combinations of credentials. Online brute-force attacks are easy to detect because you can easily inspect for large numbers of attempts by an attacker.
Offline brute-force attacks: In this type of attack, the attacker can gain access to encrypted data or hashed passwords. These attacks are more difficult to prevent and detect than online attacks. However, offline attacks require significantly more computation effort and resources from the attacker.

В brute-force мы пытаемся угадать ключ/пароль к зашифрованным или захешированным данным, защита через длину ключа/выбора хеш функции, но технически говоря, считается что 100% защиты от brute force не существует – все упирается во времени и ресурсах, если они безграничны – любая система в теории может быть взломана. Какие рекомендации – использовать сложный пароль, использовать salt/nonce, прогонять пароль и соль через hashing алгоритм много раз (до сотен) раз. 

A brute-force password attack involves guessing the password. So, having complex and long passwords will make this task much harder and will require more time and resources for the attacker to succeed. Incorporating salts into password hashes will protect against rainbow table attacks, and running passwords through the hashing algorithm lots of times also raises the bar for an attacker, requiring more resources for each password guess.

Strong password & 2FA/MFA

Очень часто администраторы и пользователи не меняют пароль на устройства (свичи, роутеры, AP и даже Firewalls). Для таких есть поговорка – зачем вам нужны хакеры, если вы используете дефолтные пароли.

Слабо защищенные и не ротируемые credentials являются основной причины компрометации учетных данных. Чем более устойчивый к подбору пароль вы используете – тем лучше (немного капитаним). Еще лучше использовать 2FA/MFA как дополнительный этап аутентификации – они значительно уменьшают вероятность атак на базе простого подбора.

- Many organizations and individuals leave infrastructure devices such as routers, switches, wireless acces s points, and even firewalls configured with default passwords.Attackers can easily identify and access systems that use shared default passwords.
- Weak credentials are one of the major causes of credential compromise. The more complex and the longer a password (credential), the better. An even better approach is to use multifactor authentication (MFA). The use of MFA significantly reduces the probability of success for these types of attacks.

Незащищенные пароли – пароли можно найти в code девелопе и скриптах автоматизации.

Attackers can easily obtain default passwords and identify Internet-connected target systems.

Passwords can be found in product documentation and compiled lists available on the Internet. An example is http://www.defaultpassword.com, but there are dozens of other sites that contain default passwords and configurations on the Internet. It is easy to identify devices that have default passwords and that are exposed to the Internet by using search engines such as Shodan (https://www.shodan.io).

Strong password не должен полагаться только на замену букв на созвучные буквы/цифры (типо f1rst), это учтенные вещи во многих password cracking tools. Обычно политики создания/обновления паролей задаются централизованно через AD, IPA (Identity Policy Audit) и уже AD/IPA проверяют пароли на политики – длина, наличие спец. символов, повторяемость, отсутствие словарных слов и прочее. И безусловно нельзя – передавать пароль, записывать на бумажке, использовать один пароль в нескольких системах. Пароли нужно периодически ротировать.

A good balance of a strong but useable password is at least 8 characters, includes a mixture of punctuation characters, and rotates periodically, but not too frequently.
Attackers can easily identify and access systems that use shared default passwords. It is extremely important to always change default manufacturer passwords and restrict network access to critical systems. A lot of manufacturers now require users to change the default passwords during initial setup, but some don’t.

• Аутентификационная стойкость пароля является функцией от его сложности.
• Основное – длина пароля.
  • bi.zone в checklists-BIZONE-experts-2021 рекомендует минимум 15
  • CISA рекомендует минимум 16!
• В пароле должны присутствовать:
  • Спец. символы
  • Разный регистр
  • Цифры и буквы
• Рекомендуется регулярная ротация парольной информации
• На уровне приложения
  • должна быть реализована защита от brute force как минимум на уровне rate limit
  • рекомендуется реализовать обязательную смену пароля при первичной настройке
• Использование одного пароля везде серьезно увеличивает вероятность взлома
• CISA рекомендует использование password manager с запоминанием пароля только от него

2FA/MFA

РФ mfa:

• multifactor.ru
• Auth.as
• Индид
• Алладин
• Аванпост

2FA/MFA – Уровень аутентификации обычно определяется по уровню угроз. Но в общем случае чем безопасней, тем лучше – даже геймеры используют MFA уже годы. Примеры данных, на основе которых проводят аутентификацию – по username/password, PIN, карта, по ключу, по смс, по токену (physical/software), face ID/IRIS scan/fingerprint, связка методов (2FA/MFA). К 2024 70% доступа к приложениям будет использовать многофактурную аутентификацию (10% на сегодня) (Gartner Magic Quadrant for Access Management)

Почему нельзя использовать только пароль: haveibeenpwned.com

Большое количество примеров есть на сайте Cisco Duo. Так же про Cisco duo в статье про AAA.

- SMS 2FA
- TOTP 2FA
- Push-Based 2FA
- U2F Tokens
- WebAuthn

При том, что когда говорят про 2FA, обычно подразумевают два несвязанных способа (фактора) аутентификации:

There are many ways to authenticate users, such as based on what a person knows, has, or is.

• по тому, что ты знаешь (пароль, пин, ответ на вопрос),
• по тому, что ты имеешь (токен/смарткарта, телефон, ключ, сертификат, карта rfid для доступа в помещение),
• по тому, чем ты являешься (некий биометрический/biometric ID – face ID/IRIS scan/fingerprint; signature dynamic, keystroke dynamic),
  • отпечатки пальцев легко подделать с помощью клея
  • signature/keystroke dynamic считаются не очень надежными способами т.к. системы на их основе изначально спроектированы с вероятностью ошибок (подробнее об ошибках работы с биометрическими системами ниже)
• по тому, где вы находитесь (geo IP),
• по тому, когда вы работаете с системой (рабочие часы или наоборот)

Knowledge factor: "Something you know." The knowledge factor may be any authentication credentials that consist of information that the user possesses, including a personal identification number (PIN), a user name, a password or the answer to a secret question.

Possession factor: "Something you have." The possession factor may be any credential based on items that the user can own and carry with them, including hardware devices like a security token or a mobile phone used to accept a text message or to run an authentication app that can generate a one-time password or PIN.

Inherence factor: "Something you are." The inherence factor is typically based on some form of biometric identification, including finger or thumb prints, facial recognition, retina scan or any other form of biometric data.

Location factors of authentication confirm the identity of a user based on their location in the world. If a user had registered an account in one country, for example, and suddenly there are login attempts from another, location factors could trigger and attempt to verify the identity of the new user. Many location factors are based on the IP address of the original user and compares the address to that of the new attempt to access information.

Time factors of authentication verify the identity of a user by challenging the time of the access attempt. This is based on the assumption that certain behaviors (like logging into a work computer) should happen within predictable time ranges. If an attempt to access a platform happens outside of the usual time range, the attempt can be challenged or terminated until a user can verify their identity.

• Single factor – когда только один из перечисленных факторов используется
• Multifactor (MFA) – когда используются несколько
• Multilayer – когда один и тот же фактор проверяется два и более раз
• Out-of-band authentication – когда аутентификация производится по независимому от данных каналу

Single-factor authentication is when only one factor is presented. Multifactor authentication is when two or more factors are presented. Multilayer authentication is when two or more of the same type of factor are presented.
Out-of-band authentication requires communication over a channel that is distinct from the first factor.

В контексте аутентификации важным вопросом является session management – как проверяющая сторона принимает/передает/сохраняет информацию об аутентифицируемом объекте (клиенте/сервере). Чаще всего в WEB приложениях используется Session ID, который сохраняется на сервере как соответствие конкретному клиенту и передается клиентом в каждом запросе к серверу. Сессии должны быть уникальны и сложно математически вычисляемыми.

Пароли в правильных реализациях хранятся не в виде clear text, а в виде hash. Аналогичное справедливо и для биометрических данных – они не хранятся в том виде, в котором существуют.

They’re creating fake fingerprints using things like glue, allowing friends to mark each other as present if they’re late or skip school.

If a biometric characteristic, like your fingerprints, is compromised, your option for changing your "password" is to use a different finger. This makes "password" changes limited. Other biometrics, like iris scans, can't be changed if compromised. If biometric authentication material isn't handled securely, then identifying information about the individual can leak or be stolen.

• Type 1 – False Rejection eRrors (FRR) – система откланяет валидного пользователя
• Type 2 – False Acceptance eRrors (FAR) – система аутентифицирует невалидного пользователя (напр. атакующий выдает себя за валидного пользователя)

Использование encryption/authn/authz уязвимостей (напр. WEP, RC5, MD5, DES, Kerberos)

При шифровании процесса аутентификации с использованием уязвимых протоколов шифрования можно потерять credentials. Очень хорошая табличка на этот счет есть у Cisco (скопировал только первые три строки).

Weak cryptographic algorithms (such as RC4, MD5, and DES) allow attackers to easily crack passwords.

Тоже самое справедливо для WEP – его плохой дизайн приводит к потере пользовательских credentials.

In addition to weak encryption or hashing algorithms, poorly designed security protocols such as Wired Equivalent Privacy (WEP) introduce avenues of attack to compromise user and application credentials.

Сохранение hash паролей без salt/nonce приводит к возможности использования rainbow tables (подробнее поиском по randbow).

Also, if hashed values are stored without being rendered unique first (that is, without a salt), it is possible to gain access to the values and perform a rainbow table attack.

Session hijcking

Существуют разные способы “воровства сессии”:

• Предсказание токена сессии – должно быть рандомизированно, иначе это всегда возможно
• Прослушивание сессии (обычно происходит из-за отсутствия шифрования)
• MitM атака
• MitB атака (Man-in-the-browser attack) – по сути MitM, только в качестве объекта по середине выступает зараженный браузер.

- Predicting session tokens: This is why it is important to use non-predictable tokens.
- Session sniffing: This can occur through collecting packets of unencrypted web sessions.
- Man-in-the-middle attack: With this type of attack, the attacker sits in the path between the client and the web server.
- Man-in-the-browser attack: This attack is similar in approach to a man-in-the-middle attack; however, in this case, a browser (or an extension or a plugin) is compromised and used to intercept and manipulate web sessions between the user and the web server.

Injection attackS

SQL injection attack (SQLi) – приводят к сливам/изменению SQL базы за счет доступа к ней напр. используя спец. символы, логические операторы и уязвимости приложения по их обработке. Вообще помимо SQL injection существуют и другие виды injection атак, основанных на том же принципе отправки “некорректных” данных – HTML script injection (ниже подробнее), Command Injection (ниже подробнее), Dynamic code evaluation, Object injection, Remote file inclusion, Uncontrolled format string, Shell injection. Как избежать: изменение кода, good software principles like validating input & sanitizing user input (часто включено в WEB frameworks), изоляция переменных, переиспользование функций. Для демо атаки можно использовать DVWA, OWASP WEBGOAT (линки на них поиском по OWASP), BurpSuite (прокси перехватывающее транзакцию между браузером и сервером) + sqlmap (подменяем запросы в сохраненной BurpSuite транзакции, узнаем название базы и сливаем ее с попыткой подбора по хешам паролей на основе словаря).

Injection. Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.

Successful exploitation can lead to the disclosure of sensitive information, manipulation of data, denial-of-service conditions, and more.

Examples of code injection vulnerabilities include the following:
• SQL injection
• HTML script injection
• Dynamic code evaluation
• Object injection
• Remote file inclusion
• Uncontrolled format string 
• Shell injection

In an SQL injection attack, the attacker inserts, or injects, partial or complete SQL queries via the web application. The attacker injects SQL commands into input fields in an application or a URL in order to execute predefined SQL commands. If an application does not sanitize user input, an attacker can supply crafted input in an attempt to make the original SQL statement execute further actions in the database.

As a penetration tester you can start by adding a single quote or a semicolon to the field or parameter in a web form. The single quote is used in SQL as a string terminator. If the application does not filter it correctly, you may be able to retrieve records or additional information that can help enchance your query or statement.
You can also use comment delimiters such as -- or /* */, as well as other SQL keywords, including AND and OR operands. Another simple test is to insert a string where a number is expected.

Examples: 
1) weril' OR 1='1 # добавляем в запрос вместо просто "weril" statement 1=1, в итоге все записи будут выгружены из базы
2) 123 OR 1=1

Input validation is an important part of mitigating SQL injection attacks. The best mitigation for SQL injection vulnerabilities is to use immutable queries such as following:
- Static queries
- Parameterized queries
- Stored procedures (if they do not generate dynamic SQL)
Immutable queries do not contain data that could get interpreted. In some cases, they process the data as a single entity that is bound to a column without interpretation.

“Ручная” инъекция используя OWASP WEBGOAT

“Автоматическая” инъекция используя DVWA + BurpSuite + sqlmap.

Способы эксплуатации SQL injection (примеры красным выше в выводе sqlmap; способы могут быть комбинированы вместе):

• Union operator: поддержка оператора объединения, в итоге можно сделать несколько запросов к базе в одном SQL statement

Union operator: this is typically used when a SQL injection vulnerability allows a SELECT statement to combine two queries into a single result or a set of results.

• Boolean: проверка на true/false.

Boolean: this is used to verify whether certain conditions are true or false.

• Error-based technique: учимся на получаемых ошибках и улучшаем запрос.

Error-based technique: this is used to force the database to generate an error in order to enchance and refine an attack (injection).

• Time delay: использование задержки в ответе.

Time delay: it is possible to use database commands to delay answers. An attacker may use this technique when he or she doesn't get any output or error messages from the application.

Категории SQL injection атак:

• In-band SQLi – атакующий получает данные используя тот же канал, что для запроса (т.е. данные выгружаются непосредственно в web application или web page). Базовая форма SQL injection.

In-band SQL injection: With this type of injection, the attacker obtains the data by using the same channel that is used to inject the SQL code. This is the most basic form of an SQL injection attack, where the data is dumped directly in a web application (or web page).

• Out-of-band SQLi – атакующий получает данные используя канал отличный от того, который использовался для запроса (напр. email, ftp, IM, http/scp/etc connection to different server).

Out-of-band technique: this is typically used to obtain records from the database by using a different channel. For example, it is possible to make an HTTP connection to send the results to a different web server or a local machine running a web service.

• Blind (or inferential) SQLi – приложение при такой атаке не отображает и не передает какие-либо данные, атакующий реконструирует информацию путем отправки SQL запросов и просмотра поведения приложения и базы данных (вода конечно, при детальном разборе нужно подробнее).

Blind (or inferential) SQL injection: With this type of injection, the attacker does not make the application display or transfer any data; rather, the attacker is able to reconstruct the information by sending specific statements and discerning the behavior of the application and database.

HTML injection – пользователь может инъецироать HTML код в web-приложение, что в итоге может приводить к потере cookies, изменению контента на сайте, XSS и другим проблемам.

An HTML injection is a vulnerability that occurs when an unauthorized user is able to control an input point and able to inject arbitrary HTML code into a web application. Successful exploitation could lead to disclosure of a user’s session cookies; an attacker might do this to impersonate a victim or to modify the web page or application content seen by the victims. HTML injection vulnerabilities can lead to cross-site scripting (XSS).

Защита от SQL инъекций бывает разной:

• проверка на корректность входных переменных (input validation)
• параметризируемые запросы в базу (parameterized/bin/placeholders)
• экранирование специальных символов (escaping)
• ограничение доступа к базу только необходимым (least privilege)

Pattern check
Integer, float or boolean, string parameters can be checked if their value is valid representation for the given type. Strings that must follow some strict pattern (date, UUID, alphanumeric only, etc.) can be checked if they match this pattern

Parameterized statements
With most development platforms, parameterized statements that work with parameters can be used (sometimes called placeholders or bind variables) instead of embedding user input in the statement.

Escaping
A straightforward, though error-prone way to prevent injections is to escape characters that have a special meaning in SQL.

Database permissions
Limiting the permissions on the database login used by the web application to only what is needed may help reduce the effectiveness of any SQL injection attacks that exploit any bugs in the web application.

Command injection – атакующий исполняет команды, которые он не авторизован исполнять из-за уязвимости в приложении. Command injection отличается code execution/code injection атак тем, что он не использует уязвимости buffer overflow, а использует уязвимости некорректной валидации данных получаемых от пользователя (вообще довольно спорное утверждение, особенно что эта причина зачастую является следствием и buffer overflow).

A command injection is an attack in which an attacker tries to execute commands that he or she is not supposed to be able to execute on a system via a vulnerable application. Command injection attacks are possible when an application does not validate data supplied by the user (for example, data entered in web forms, cookies, HTTP headers, and other elements). The vulnerable system passes that data into a system shell.

With command injection, an attacker tries to send operating system commands so that the application can execute them with the privileges of the vulnerable application. Command injection is not the same as code execution and code injection, which involve exploiting a buffer overflow or similar vulnerability.

Buffer overflow attacks

Buffer overflow (подтипом являются атаки возврата в библиотеку, ret2libc) – переполнение буфера. Атака, как и многие другие (SQL injection, XSS) является причиной недостаточного input validation/sanitation/escape technique – блок данных при записи переполняет выделенный буфер под эти данные, что приводит или к отказу в обслуживании или к (зачастую еще хуже) использованию участков памяти, предназначенных под другие данные (heartbleed, buffer over-read), что в свою очередь может приводить к remote/arbitrary code execution (RCE), чтению/изменению персональных данных или ключей шифрования и прочим радостям жизни. Обычно сама проблема возникает в системных языках типо C, C++. Сама проблема buffer overflow часто обнаруживается при использовании fuzzing утилит.

Для избежания buffer overflow (особенно с последующим code execution) могут быть использованы техники ОС:

• • ASLR – Address Space Layout Randomization – рандомизируем адресацию памяти
  • Canaries – сознательно оставляем пустое пространство между буферами
  • Stack smashing protection – защищает от code execution т.к. обнаруживает buffer overflow (stack smashing) и потенциально может вычистить проблемный сегмент памяти
  • ASCII Armoring – при использовании техники адрес каждой системной библиотеки (напр. libc) начинает содержать нулевой байт в начале при хранении в памяти, в итоге исполняемый участок памяти не уникален относительно первого байта и нужно вызывать overflow нулевого байта.
  • Non execute bit (NX-bit) – не защищает от самого buffer overflow, но защищает от code execution нового кода после buffer overflow

A “return-to-libc” (or ret2libc) attack typically starts with a buffer overflow. In this type of attack, a subroutine return address on a call stack is replaced by an address of a subroutine that is already present in the executable memory of the process. This is done to potentially bypass the no-execute (NX) bit feature and allow the attacker to inject his or her own code. Operating systems that support non-executable stack help protect against code execution after a buffer overflow vulnerability is exploited. On the other hand, a non-executable stack cannot prevent a ret2libc attack because in this attack, only existing executable code is used.

A technique called ASCII armoring can be used to mitigate ret2libc attacks. When you implement ASCII armoring, the address of every system library (such as libc) contains a NULL byte (0x00) that you insert in the first 0x01010101 bytes of memory. This is typically a few pages more than 16MB and is called the ASCII armor region because every address up to (but not including) this value contains at least one NULL byte. When this methodology is implemented, an attacker cannot place code containing those addresses using string manipulation functions such as strcpy(). Of course, this technique doesn’t protect the system if the attacker finds a way to overflow NULL bytes into the stack.

Another technique, called stack-smashing protection, can prevent or obstruct code execution exploitation because it can detect the corruption of the stack and can potentially “flush out” the compromised segment.

A better approach is to use the address space layout randomization (ASLR) technique, which mitigates the attack on 64-bit systems. When you implement ASLR, the memory locations of functions are random. ASLR is not very effective in 32-bit systems, though, because only 16 bits are available for randomization, and an attacker can defeat such a system by using brute-force attacks.

Пример кода C скрипта содержащего уязвимость buffer overflow и эксплуатацию этой уязвимости с последующим code execution функции “secretFunction” (которая не вызывается вообще непосредственно кодом скрипта) с использованием objdump + edb (Evan’s Debugger) + немного python.

C script

basic usage, overflow usage, objdump start

objdump end, edb run

edb exception run

edb: get overflow memory address value

objdump (secret function address) + overflow with memory address value

XSS, CSRF attacks

• XSS (cross-site scripting) – добавление зловредного кода на сайт например для session/cookie hijacking/account compromise пользователей этого сайта, установки зловредного кода или даже простого перенаправления пользователя (напр. зеркало легитимного сайта). Несмотря на то, что в атаке XSS используется уязвимость WEB приложения, жертвой обычно является конечный пользователь этого приложения. Очень популярная атака. Самое противное – чаще всего атака проходит незаметно для жертвы.

Cross-Site Scripting XSS. XSS flaws occur whenever an application includes untrusted data in a new web page without proper validation or escaping, or updates an existing web page with user-supplied data using a browser API that can create HTML or JavaScript. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.

Successful exploitation of XSS could result in installation or execution of malicious code, account compromise, session cookie hujacking, revelation or modification of local files, or site redirection.

Examples of methods of delivery for XSS exploits are phishing emails, messaging applications, and search engines.

Even though XSS vulnerabilities are flaws in a web application, the attack typically targets the end user.

One of the effects of any type of XSS attack is that the victim typically does not realize that an attack has taken place.

Существует три типа XSS атак:

• • Stored (persistent) – уязвимая страница/скрипт сохранена в постоянной памяти (в базе/в файле) на сервере с XSS уязвимостью. Чаще всего веб-сервер/веб-приложение с XSS уязвимостью является “доверенным” для клиента.
  • Reflected (non-persistent) – уязвимая страница не сохранена в постоянной памяти. К примеру, пользователь может пройти по линку, который будет включать XSS скрипт с уязвимостью.
  • DOM-based

Уязвимость XSS обычно обнаруживается в следующих местах: поля для поиска, HTTP заголовки, формы ввода, сообщения об ошибках с пользовательским текстом, спрятанные поля с пользовательскими данными.

Stored, or persistent, XSS attacks occur when the malicious code or script is permanently stored on a vulnerable or malicious server, using a database. These attacks are typically carried out on websites hosting blog posts (comment forms), web forums, and other permanent storage methods. An example of a stored XSS attack is a user requesting the stored information from the vulnerable or malicious server, which causes the injection of the requested malicious script into the victim’s browser. In this type of attack, the vulnerable server is usually a known or trusted site.

Reflected XSS attacks (non-persistent XSS) occur when malicious code or scripts are injected by a vulnerable web application using any method that yields a response as part of a valid HTTP request. An example of a reflected XSS attack is a user being persuaded to follow a malicious link to a vulnerable server that injects (reflects) the malicious code back to the user’s browser. This causes the browser to execute the code or script. In this case, the vulnerable server is usually a known or trusted site.

The Document Object Model (DOM) is a cross-platform and language-independent application programming interface that treats an HTML, XHTML, or XML document as a tree structure. DOM-based attacks are typically reflected XSS attacks that are triggered by sending a link with inputs that are reflected to the web browser. In DOM-based XSS attacks, the payload is never sent to the server. Instead, the payload is only processed by the web client (browser). In a DOM-based XSS attack, the attacker sends a malicious URL to the victim, and after the victim clicks on the link, it may load a malicious website or a site that has a vulnerable DOM route handler. After the vulnerable site is rendered by the browser, the payload executes the attack in the user’s context on that site. DOM-based applications use global variables to manage client-side information. Often developers create unsecured applications that put sensitive information in the DOM (for example, tokens, public profile URLs, private URLs for information access, cross-domain OAuth values, and even user credentials as variables). It is a best practice to avoid storing any sensitive information in the DOM when building web applications.

You typically find XSS vulnerabilities in:
- search fields that echo a search string back to the user
- HTTP headers
- Input fields that echo user data
- Error messages that return user-supplied text
- Hidden fields that may include user input data
- Applications (or websites) that displays user-supplied data

Методы защиты от XSS (как на уровне серверной так и на уровне клиентской стороны) описаны в статье на wiki.

• не даем пользователю (потенциальному атакующему) вводить что угодно (экранируем в зависимости от контекста пользовательский ввод и проверяем ввод):
  • Contextual output encoding/escaping of string input
  • Safely validating untrusted HTML input
• ограничиваем или запрещаем работу cookie и скриптов на клиентской стороне (потенциальной жертве)
  • Cookie security – привязываем cookie к конкретному IP (воровство клиентского cookie не даст клиентский доступ, если не использовать его IP) или не отдаем cookie на клиент вообще
  • SameSite cookie parameter – запрещаем xss или ограничиваем его только ro операциями, отослав от сервера клиенту cookie с определенным параметром
  • Disabling scripts or Selectively disabling scripts – отключаем скрипты полностью/на уровне домена/анализируя их автоматически

Хороший пример самой атаки так же описан в статье на wiki.

Для тренировки с уязвимостью XSS и другими WEB-уязвимостями, которые рассмотрены в проекте OWASP можно использовать тулзы OWASP Juice Shop, OWASP WEBGOAT, OWASP ZAP (Zed Attack Proxy) или DVWA (Damn Vulnerable Web Application)  –  можно на практике посмотреть уязвимости OWASP top 10 и другие. К примеру вместо “omar was here” можно сгенерировать “please relogin” и перенаправить пользователя на фейк страницу, на которой собирать учетки. Примеры атак XSS. Чаще всего XSS/CSRF уязвимости являются причиной недостаточного input validation/sanitation/escape technique. 

OWASP Juice Shop is probably the most modern and sophisticated insecure web application! It can be used in security trainings, awareness demos, CTFs and as a guinea pig for security tools! Juice Shop encompasses vulnerabilities from the entire OWASP Top Ten along with many other security flaws found in real-world applications!

• CSRF/XSRF (Cross-site Request Forgery, one-click attack, session riding) – подделка пользовательских запросов. Атака отличается от XSS, где уязвимым хостом является сервер – тут уязвимость эксплуатируется на пользователе. Эксплуатируется то, что сайт считает, что пользователь авторизован на это действие, а по факту действие инициировано не самим пользователем и пользователь об этом действии обычно не знает. Может приводить к списанию средств (покупка/перевод средств от вашего лица), изменению вашего пароля, получению доступа к приватной информации и прочим прелестям. Чаще всего XSS/CSRF уязвимости являются причиной недостаточного input validation/sanitation/escape technique (как и многие многие другие атаки). 

Cross-site request forgery (CSRF or XSRF) attacks occur when unauthorized commands are transmitted from a user that is trusted by the application. CSRF attacks are different from XSS attacks because they exploit the trust that an application has in a user's browser. CSRF vulnerabilities are also referred to as "one-click attack" or "session riding".
- CSRF attacks typically affect applications (or websites) that rely on a user's identity.
- Attackers can trick the user's browser into sending HTTP requests to a target website.
- An example of a CSRF attack is a user authenticated by the application by a cookie saved in the browser unwittingly sending an HTTP request to a sшеe that trusts the user, subsequently triggering an unwanted action.

MISC ATTACKS

• Cookie manipulations attacks, DOM-based attacks – уязвимое пользовательское приложение сохраняет пользовательский ввод в DOM как часть ответа. Атакующий может изменить эти данные в сookies. Влияние зависит от того, как эти cookie обрабатываются внутри приложения.

Cookie manipulation is possible when vulnerable applications store user input and then embed that input in a response within a part of the DOM. This input is later processed in an unsafe manner by a client-side script. An attacker can use a JavaScript string (or other scripts) to trigger the DOM-based vulnerability. Such scripts can write controllable data into the value of a cookie. An attacker can take advantage of stored DOM-based vulnerabilities to create a URL that sets an arbitrary value in a user’s cookie. The impact of a stored DOM- based vulnerability depends on the role that the cookie plays within the application.

• Race Condition (TOCTOU attack; time of check to time of use) – когда несколько процессов пытаются прочитать/записать один и тот же ресурс (напр. файл) в один момент времени, при этом система на это не рассчитана. Считается сложной для эксплуатации атакой т.к. система при race condition дает в общем случае лишь малое окно времени, в которую можно получить profit от успешно проведенной атаки race condition.

A race condition occurs when a system or an application attempts to perform two or more operations at the same time. However, due to the nature of such a system or application, the operations must be done in the proper sequence in order to be done correctly. When an attacker exploits such a vulnerability, he or she has a small window of time between when a security control takes effect and when the attack is performed. The attack complexity in race conditions is very high. In other words, race conditions are very difficult to exploit.

• Unprotected APIs – многие API плохо контролируются, не мониторятся и сложны в своей логике. В самом API (REST/SOAP, без разницы) может быть реализовано все самое новое (что еще в roadmap), а в документации все тщательно описано, что позволит хакерам чувствовать себя у вас как дома.

Unfortunately, many APIs lack adequate controls and are difficult to monitor. The breadth and complexity of APIs also make it difficult to automate effective security testing. An API often provides a roadmap that describes the underlying implementation of an application. This roadmap can give penetration testers valuable clues about attack vectors they might otherwise overlook. API documentation can provide a great level of detail that can be very valuable to a security professional, as well to attackers.

• XEE (XML External Entities) – использование уязвимостей обработчиков XML (напр. перенаправления URI handler, внутренние share, remote code execution, DoS)

XML External Entities (XXE). Many older or poorly configured XML processors evaluate external entity references within XML documents. External entities can be used to disclose internal files using the file URI handler, internal file shares, internal port scanning, remote code execution, and denial of service attacks.

• Insecure Deserialization – неправильное хранение или передача десерализованных данных может приводить к rce (remote code execution), атакам на повторение (replay attacks), атаках на инъекцию (injection) и повышение привилегий (privilege escalation).

Insecure Deserialization. Insecure deserialization often leads to remote code execution. Even if deserialization flaws do not result in remote code execution, they can be used to perform attacks, including replay attacks, injection attacks, and privilege escalation attacks.

• Using components with known vulnerabilities – библиотеки, фреймворки и модули (напр. open source) имеющие известные уязвимости используются в системе.

Using Components with Known Vulnerabilities. Components, such as libraries, frameworks, and other software modules, run with the same privileges as the application. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications and APIs using components with known vulnerabilities may undermine application defenses and enable various attacks and impacts.

• Insufficient logging & monitoring – приводит к проблемам при forensics, отстутствию понимания причин/уровня ущерба и зараженных систем, поздному обнаружению заражения (или даже отсутствию этого обнаружения)

Insufficient Logging & Monitoring. Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems, and tamper, extract, or destroy data. Most breach studies show time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.

• Directory traversal, path traversal, dot-dot-slash attack – уязвимость состоит в том, что мы можем выходить из пределов директории web сайта в директорию системы и манипулировать там с файлами (как минимуму read). Вместо точек иногда получается использовать закодированные символы %2e, %2f, которые по сути означают тоже самое (точка и слеш) или комбинацию этих символов со стандартными. Протестировать эксплуатацию уязвимости можно используя DVWA (о нем подробнее по поиску). Для защиты от уязвимости нужно не давать пользователю вводить пути файловой системы, использовать политики разграничения, которые можно наложить в зависимости от ОС, не сохранять важные файлы в web root directory. Пример path traversal уязвимости – в Cisco ASA и Cisco Firepower при включенном webvpn возможна атака path traversal с изменением и удалением системных файлов CVE-2020-3187, CVSS 9.1.

https://weril.me/../../../../etc/password
Best practices to mitigate directory traversal:
- Understand how the OS processes filenames provided by a user or application
- Never store sensitive config files in the web root directory
- Prevent user input when using file system calls

Cryptology (криптография)

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

Steganography involves hiding messages from discovery instead of encoding them.

• Cryptology/cryptography (криптография). Шифруем что-то, чтобы не увидели другие. Реализация принципов CIA: конфеденциальность, целостность, аутентификация. Теме тысячи лет, но особенно она развивается сейчас. 
• Cryptosystem – взаимосвязь алгоритмов генерации ключа шифрования, шифрования и дешифрования данных.

• A cryptosystem is a collection of algorithms for key generation, encryption/decryption

• Cryptanalysis – криптоанализ. Попытка расшифровать данные, даже если неизвестны какие-то необходимые элементы для этого (ключи/алгоритмы). Например, путем взлома алгоритма шифрования или его имплементации.

Cryptanalysis - the study of how to crack encryption algorithms or their implementations.

• • Лингвистический анализ – подход для старых алгоритмов
    • Frequency analysis – практика изучения частоты появления букв в зашифрованном тексте. Frequency analysis основан на том, что в письменном языке: 1) определенные буквы встречаются чаще, чем другие (English: e, t, a, o) 2) определенные буквы чаще группируются вместе с другими (English: er, th, an, on).  Frequency analysis может быть использован для таких методов шифрования как Letter transposition/substitution т.к. они сохраняют частоту букв в шифре.
  • Математический анализ + автоматизация – подход для новых алгоритмов. Подразумевает, как вычисления на базе обычных CPU, так и на основе видеокарт или даже квантовых компьютеров. Несмотря на то, что современные криптосистемы считаются очень стойкими, риски взлома с использованием современных же методов и разработок вполне реальны (напр. квантовые вычисления и простота операции факторизации числа (разложение на множители) для них, при этом аксиома сложности этой операции для больших числе заложена например в RSA) .

It’s been said that the advent of modern computing has spelled the death of the field of cryptanalysis; but the practice is still alive and well -- it’s the methodology that’s changed as technology has transformed the landscape. As quantum computing continues to develop, there’re concerns that modern encryption could be at risk of being broken. This is because most modern encryption algorithms are based on large prime number factorization being computationally difficult, something that can be significantly sped up by quantum computing. Because of this, quantum computing would allow for significantly faster factorization and brute-force attacks on encryption keys, making the future of modern cryptography questionable in the looming quantum computing era.

• Encryption Algorithm (Алгоритм шифрования) – алгоритм, на основе которого шифруются данные – DES, AES, RSA. Являются по сути дизайном, а не реализацией. Этот дизайн в последующем имплементируют разработчики в реализацию – софтовую, хардварную. Важными параметром алгоритма являются:
  • криптостойкость
  • скорость и потребность в ресурсах для шифрования -операция шифрования частая, даже одни данные могут несколько раз шифроваться, поэтому нужно чтобы быстро и максимально ненапряжно для системы. Поэтому часто hardware (Intel/AMD CPU имеют AES инструкции встроенные в CPU). 
  • простота реализации – важна не только из-за скорости time-to-market, стоимости реализации, но и из-за вероятности баги в сложной имплементации. Очень часто проблема заложена не в алгоритме или разрядности, отданной под ключ, а в реализации алгоритма на практике – такие вещи как AES и DES правильно реализовать непросто. 
• Cipher – шифр. Набор правил (алгоритм) как выполнять шифрование/дешифрование.

A cipher is a set of rules, which can also be called an algorithm, about how to perform encryption or decryption. 

• • Security through obscurity (безопасность через неясность) – плохой шифр состоит только из encryption algorithm. Основан на том, что никто не знает какой алгоритм мы используем (совсем базого – ключ под ковриком двери, пароль под клавой). 
    • Шифр подстановки (Transposition cipher, Letter transposition) – простое перемещение букв. 

• • • Шифр замены (Substitution cipher, letter substitution) – простая статичная замена одних букв/пары или тройки букв, на другие. Это совсем базовое шифрование, основанное только на encryption algorithm. Например, шифр
      • Caesar Cipher (шифр Цезаря), в котором замещение символа происходило символом, находящимся на некотором постоянном числе позиций левее или правее него в алфавите. Формально тут есть ключ – количество символов и направление смещения, но он слишком простой и зная логику, можно подобрать ключ.

• • • • ROT13, в котором замещение символа происходило символом, находящимся на 13 позиций левее него в алфавите. Частный случай шифра Цезаря. В интернет-форумах для оскорблений других используюется иногда 😉 По сути это частный пример шифра цезаря с ключем 13. Причем число 13 (половина от английского алфавита) позволяет добиться эффекта, что шифр симметричный (смещаемся на 13 символов для кодирования символа и еще на 13 символов для декодирования = начальный символ) – можно использовать тот же ключ для дешифрования, что и для шифрования. 
      • Poly alphabetic ciphers – по сути substitution cipher на основе нескольких алфавитов. Переключение алфавита происходит по особому символу.
  • Kerckhoffs’s principle (Shannon‘s maxim, “the enemy knows the system”) – хороший шифр состоит из двух компонентов – encryption algorithm + key. Такой encryption algorithm как RSA не разберешь без PhD в математике. Ключ добавляет что-то уникальное в шифр, что с одной стороны, имея ключ, позволяет расшифровать исходные данные, с другой – не позволяет расшифровать шифр, зная даже используемый алгоритм, а во многих случаях и публичный ключ.

A cryptosystem should be secure even if everything about the system, except the key, is public knowledge.

• Постквантовая криптография описывает проблемы (уязвимость алгоритмов на базе факторизации, эллиптических кривых) и потенциальные методы решения (использование симметричных алгоритмов, увеличение длины ключа, использование квантовых методов обмена ключами вместо алгоритмов на основе открытого ключа). Рекомендации от 2024 NSA (АНБ) включают рекомендации использования AES-256 и SHA-384/SHA-512 (интересно, что нет SHA-256).

https://habr.com/ru/company/neobit/blog/332942/
https://www.securitylab.ru/blog/personal/Business_without_danger/344134.php

Считается, что симметричные ключевые шифры, такие как AES, являются квантово-безопасными, тогда как многие шифры с открытым ключом, такие как RSA, как известно, не являются. 

Как показывают многочисленные исследования криптоалгоритмы, базирующиеся на сложности факторизации целых чисел (например, RSA) или дискретного логарифмирования (например, Эль-Гамаль или эллиптические кривые), находятся под ударом - они не являются квантовобезопасными, так как не могут адаптироваться к квантовым атакам просто увеличивая длину ключа (Диффи-Хеллман тоже уязвим).

Симметричные алгоритмы AES или ГОСТ Р 34.12-2015 считаются квантовобезопасными, так как всего лишь достаточно увеличить длину ключа (считается, что квантовые компьютеры снижают эффективную длину криптографических ключей в два раза - ГОСТ с длиной ключа 256 бит для квантового компьютера - это тоже самое, что и ГОСТ с длиной ключа 128 бит для обычного компьютера).

Элементы управления, которые, как известно, в некоторой степени уязвимы для квантовой атаки, но могут быть легко переработаны, включающие алгоритмы, использующие симметричные ключи, такие как AES, которые можно быстрее разрушить на квантовом компьютере, выполняющем алгоритм Гровера, чем на классическом компьютере. Однако квантовый компьютер можно заставить работать так же сложно, как обычный компьютер, удвоив длину ключа шифра. Это означает, что AES-128 так же трудна для классического компьютера, как AES-256 для квантового компьютера.

• Encryption – шифрование. Применение к исходным данным (plaindata, plaintext) какого то encryption algorithm (DES/RSA/AES) с ключем, чтобы при передаче данные были зашифрованы (cipherdata, ciphertext).

An encryption algorithm is the specific function or steps taken to convert plaintext into encrypted ciphertext.

• Decryption – дешифрование. Применение к зашифрованным данным (cipherdata, ciphertext) какого-то decryption algorithm с ключем, для получения исходных данных (plaindata, plaintext). Основные типы шифрования различаются по методу decryption:
  • Symmetric (симметричное) – используют один ключ для шифрования и дешифрования
  • Assymetric (ассиметричное) или Public key/private key – используют разные ключи для шифрования и дешифрования.

Сразу несколько определений по картинке ниже:

ciphertext.

• Encryption Key (ключ шифрования) – используется для кодирования данных. Важные процессы в контексте ключей – его
  • key size/length (размер/длина ключа) – чем больше, тем лучше. Пишется в битах (напр. в DES 56 bit = 72kkkkk, квадриллион или 72000 триллионов возможных ключей). Определяет количество бит, которые составляют ключ шифрования. Или другими словами – максимальное количество возможных ключей, которое может сгенерировать алгоритм шифрования. Длина ключа влияет на ряду со стойкостью самого алгоритма (зачастую важнее, но в идеальной ситуации, когда криптоалгоритм неуязвим, можно только атаковать ключ, например brute force’ом пытаясь угадать его) на максимальную потенциальную криптостойкость системы. The larger the key, the more secure the encrypted data will be. The security of a symmetric cryptosystem is a function of two things: the strenght of the algorithm and the length of the key.
    
    • key generation (генерация ключа) – может являться комбинацией нескольких ключей (ключ алгоритма + ключ IV). Тут появляется вопрос псевдо-рандом (см. DSA и Sony) или рандом. Генерация может основываться на базе
      • факторизации числа (number factorization)
      • эллиптических кривых (elliptic curves)
    • key exchange (распространение ключей) – для безопасного распространения симметричного ключа может использоваться ассиметричное шифрование или Diffie Hellman алгоритм (подробнее ниже)
    • повторное использование (защита с использованием initialization vector, IV)
    • FS (forward secrecy) или PFS (perfect forward secrecy) – фича протокола, которая позволяет избежать зависимости сессионных ключей между собой – компрометации старых сессионных ключей при компрометации новых и наоборот. 

      • Perfect Forward Secrecy (PFS), also referred to as Forward Secrecy (FS), is a cryptographic feature that aims at preventing session keys used for the transmission of information to be breached even if the server private key is breached later on. In the traditional mode of encryption, for instance, if an opponent secures the private key she or he can decipher past communication encrypted with the given key. FS reduces this risk by creating a fresh session key when a communication session is established. This is because even if an attacker gains a long term key, he/she cannot decrypt old communications because each session key is random and used for only one communication session only.

      • ECDHE-X25519 — алгоритм обмена ключами на основе эллиптических кривых. Он обеспечивает forward secrecy: даже если закрытый ключ сервера станет доступен, трафик прошлых сессий останется защищённым.

• Random generator – Random является крайне важной темой в безопасности, т.к. многие системы безопасности полагаются на отсутствие логики в нем.
  • Random number generator (NG) – генератор (не псевдо) случайных чисел. Обычно аппаратный, например TPM (Trusted Platform Module). Пример полезного сайта для генерации настоящего (как утверждают на основе погодных данных) рандома – random.org. Широко используется в лотереях – по факту, при простой трансляции экрана, не защищает от подмены сайта в hostname и поддержки зеркалом; правильно было бы еще иметь возможность генерировать обратный url с ID запрашивающего на random.org для проверки результата.

 RANDOM.ORG offers true random numbers to anyone on the Internet. The randomness comes from atmospheric noise, which for many purposes is better than the pseudo-random number algorithms typically used in computer programs. People use RANDOM.ORG for holding drawings, lotteries and sweepstakes, to drive online games, for scientific applications and for art and music. The service has existed since 1998 and was built by Dr Mads Haahr of the School of Computer Science and Statistics at Trinity College, Dublin in Ireland. Today, RANDOM.ORG is operated by Randomness and Integrity Services Ltd.

• • Pseudo-random number generator (PNG, Генератор псевдослучайных чисел) – алгоритм, порождающий последовательность чисел, элементы которой почти независимы друг от друга и подчиняются заданному распределению (обычно равномерному). В операционных системах для генерации рандома используется entropy pool – источник рандомных данных (время, состояние диска, фаза луны..), которые используют генераторы рандома. 
• Initialization vector (IV, вектор инициализации), представляет собой произвольное число, которое может быть использовано вместе с секретным ключом для шифрования данных. В результате получается схема: shared master key + one-time encryption IV key (передается открыто). Пример использования – 802.11 WEP шифрование, AES. Использование IV предотвращает повторение шифрования данных, что делает процесс взлома более трудным для хакера с помощью атаки по словарю, в попытках найти шаблоны и сломать шифр.
• Nonce – рандомная последовательность, которая может быть использована только один раз при взаимодействии (once). Часто используется в Initialization Vector (IV).

In cryptography, a nonce is an arbitrary number that can be used just once in a cryptographic communication.

% openssl rand -base64 6
Ouu6+EmZ

$ cat /dev/urandom | tr -dc 'a-zA-Z0-9' | head -c 10
dyxJRKldvp

$ cat /dev/urandom | tr -dc 'a-zA-Z0-9-_!@#$%^&*()_+{}|:<>?=' | fold -w 10 | grep -i '[!@#$%^&*()_+{}|:<>?=]' | head -n 1
MSF4wj@vP0

Symmetric encryption (симметричное шифрование)

• Symmetric key cryptography is also known as preshared key cryptography (PSK)
• Ключ для дешифрования = Ключ для шифрования (подробнее в общем разделе Криптография, шифр ROT13). Этот ключ должен держаться в секрете.

Symmetric just means that the same key is used to encrypt/decrypt. Assymetric means that one key encrypts and a different key decrypts (and that the reverse is also true).

• В сравнении с ассиметричным шифрованием легче для реализации, проще использовать, быстрее для шифрования большого количества данных. Кто-то (книги) говорит в 500 раз быстрее симметричное шифрование – по факту it depends (алгоритм, hardware offload), но понимание того, что быстрее однозначно есть. Но симметричность может быть неудобна и даже не безопасна – например
  • Ассиметричное шифрование позволяет безопасно обмениваться данными по незащищенному каналу без предварительной передачи общего ключа шифрования, как в симметричном шифровании
  • если пароль Wi-Fi украден, нужно менять пароль на всех устройствах
  • если нужно дать какой-то большой группе людей временный доступ, ты же не будешь им давать постоянный пароль, тебе нужен временный, но Virtual SSID не все роутеры поддерживают
• Многие протоколы/схемы используют как симметричное шифрование, так и ассиметричное, на основе лучших качеств обоих:
  • для обмена симметричными ключами (symmetric encryption key/shared secret) используется ассимметричное шифрование (secure key exchange is a common application for assymetric algorithms)
  • для последующего обмена (шифрования/дешифрования) данными используется симметричное шифрование на основе полученных ключей
• Симметричное шифрование бывает реализовано
  
  • блочным (block ciphers) шифрованием – несколько символов (статичное количество, притом, что если данных недостаточно – добавляются) шифруется в один. Обратное от поточных.
  • поточным (stream ciphers) шифрованием – один символ шифруется в один символ (1к1). Работают быстрее и проще для реализации, но обычно менее безопасны. 

A stream cipher takes data in as a continuous stream, and outputs the ciphertext as a continuous stream, too. A block cipher encrypts the data in chunks, or blocks.

Примеры популярных симметричных алгоритмов

- DES, 3DES, RC4, and AES # are all symmetric encryption algorithms (все блочные)
- Kerberos использует симметричное шифрование

Rivest Cipher 4 (RC4) – симметричных поточных алгоритм,  поддерживает ключи от 40 бит до 2048 бит. Был очень широко распространен из -за простоты реализации и скорости работы. Сейчас не рекомендуется к использованию т.к. сам алгоритм (не длина ключа) признан слабым (например. RC4 NOMORE attack). RC4 используется во многих протоколах – TLS (старом), 802.11 WEP, 802.11 WPA. Многие браузеры отказались от поддержки RC4 (preferred secure browser/web server configuration: TLS 1.2 with AES GCM). 

Data Encryption Standard (DES) (так же известен как ) – придуман в 1970 IBM + USA Nation Security Agency и принят как стандарт под названием Federal Information Processing Standard (FIPS) в USA (т.е. может использоваться для шифрования правительственных данных). Является симметричным блочным шифром (работает с блоками в 64 бита), использует 56-битный ключ (64 бита всего, из них 8 бит используются под проверку четности, parity checking – простейшую и малоэффективную проверку на ошибки). Длина ключа в 56 бит изначально закрывала все вопросы, но потом, с ростом вычислительных мощностей, то что предполагалось только в теории, произошло – в 1998 EEF дешифровала ключ DES всего за 56 часов.

Advanced Encryption Standard (AES или Rinjndael, рэндал) – замена DES. Единственный публичный алгоритм, который разрешено использовать для секретных данных USA Nation Security Agency. В текущий момент является по сути “стандартом” шифрования. Создан Винсент Рэймен, Йоан Даймен.

• • By default является симметричным блочным шифром (работает с блоками в 128 бит), использует ключи 128, 192 или 256 бит. Из-за размера ключа AES brute force атака на него в текущий момент только теоретически возможна (как в 70х годах с DES).
  • AES GCM (Galois/Counter Mode) – специальный режим работы AES, в котором блочный шифр по сути превращается в поточный. GSM супер-популярный из-за того что он безопасный, простой в реализации, очень быстрый и может быть запущен параллельно. Preferred secure browser/web server configuration: TLS 1.2 with AES GCM. Так же AES GCM лучше всего оффлоудится с использованием AES-NI и используется в задачах шифрования данных диска (at rest, ). На моей практике использование режима GCM существенно (в 3-5 раз) увеличивает производительность шифрования.

AES-128/256 (c WinRAR 5) активно используется для шифрования файлов в WinRAR, 7z. Они не хранят пароли, а хранят hash от них (на основе PBKDF2). Проверку пароля Winrar делает на основе hash HMAC-SHA256 от пароля (ключа) и, если hash от пароля совпадает с hash, хранимым в архиве – дешифруют данные на основе этого ключа.

WinRAR has changed its encryption standard from AES 128 to AES 256 with its „RAR 5.0“ format. Thus we highly recommend using the RAR 5.0 format in order to use the stronger AES Encryption.

However, the AES – 128 Bit is strong as well and it is used by governments and military installations alike to encrypt secret classified information.
The password based key derivation function is now based on (PBKDF2) using HMAC-SHA256, the core of the WinRAR security mechanism.

WinRAR does not check a password at all. It passes a password through the hash function to set a 128/256 Bit AES encryption key and then uses this key to encrypt the file data valid until RAR 4.x format. The new RAR 5.x format detects wrong passwords even before starting extraction and does not extract garbage. RAR 5.x stores a special password hash generated by one way hash function. Consequently the knowledge of this hash does not allow to know a password of the encryption key. When password is entered RAR compares its hash to stored hash in case of no match it rejects the wrong password early. This one way hash function is intentionally slow and based on PBKDF2, therefore it does not allow to increase the brute force attack performance noticeably.

В контексте шифрования RAR стоит отметить что – всегда лучше использовать шифрования и содержимого и методанных “encrypt file names” – это вытекает из реальных взломов старых версий и того, что там используются “спец” алгоритм by Winrar (даже в новой версии).

If archive headers are not encrypted (“encrypt file names” option is disabled), file checksums for encrypted RAR 5.0 files are modified using a special password dependent algorithm to prevent third parties from guessing file contents based on checksums.

Assymetric encryption, public key cryptography (ассиметричное шифрование, Криптографическая система с открытым ключом)

• Assymmetric key cryptography is also known as public key cryptography.
• Ключ для дешфирования != Ключ для шифрования

Symmetric just means that the same key is used to encrypt/decrypt. Assymetric means that one key encrypts and a different key decrypts (and that the reverse is also true).

• Основное преимущество ассиметричного шифрования – оно позволяет организовать защищенную связь по незащищенному каналу

By exchanging public keys for encrypting data, asymmetric encryption securely exchanges information over untrusted channels.

• Симметричное шифрование более сложное для реализации/вычислений, поэтому медленнее работает
• В отличии от симметричных алгоритмов шифрования ассиметричное шифрование предоставляет
  • конфиденциальность (см. базовый алгоритм шифрования/деширофвания)
  • аутентификацию и невозможность изменения данных (см. сертификат открытого ключа, цифровая подпись) (confidentiality, authenticity, non-repudiation)

Confidentiality is provided by the encryption and decryption functionality, while authenticity and non-repudiation are ensured by the signing and verification processes.

• Ассиметричное шифрование позволяет безопасно обмениваться данными по незащищенному каналу без предварительной передачи общего ключа шифрования, как в симметричном шифровании
• Многие протоколы/схемы используют как симметричное шифрование, так и ассиметричное, на основе лучших качеств обоих:
  • для обмена симметричными ключами (symmetric encryption key/shared secret) используется ассимметричное шифрование (secure key exchange is a common application for assymetric algorithms)
  • для последующего обмена (шифрования/дешифрования) данными используется симметричное шифрование на основе полученных ключей
• В assymetric encryption данные шифруются public key, причем он может быть и у злоумышленника, но расшифровать их можно только с помощью private key. Сила шифрования основывается на принципе односторонней функции (вычислительной сложности вычисления private key на основе public key).

The generation of such keys depends on cryptographic algorithms based on mathematical problems to produce one-way functions.
In such a system, any person can encrypt a message using the receiver's public key, but that encrypted message can only be decrypted with the receiver's private key.

Разрыв между сложностью прямого и обратного преобразований определяет криптографическую эффективность односторонней функции

Basic algorithm (Базовый алгоритм работы)

• Оба участника генерируют (каждый свой) private key
• Используя private key оба участника генерируют (каждый свой) public key
• Участники обмениваются своими public key (а если быть точным – public key signature, см. ниже почему)
• При передаче информации другому участнику
  • мы шифруем информацию полученным от участника public key
  • отсылаем участнику
  • участник, при приеме информации, дешифрует информацию используя свой private key
  • enjoy

Public Key infrastructure (PKI), Public Key Signature (Сертификат Открытого Ключа), Certification authority (ЦЕНТР СЕРТИФИКАЦИИ), Digital signature (ЦИФРОВАЯ ПОДПИСЬ)

Все бы хорошо в базовом алгоритме, только возможно такое, что злоумышленник выдаст свой public key представляясь тобой (dns spoofing, arp spoofing, reroute,  все что угодно) и другой участник будет обмениваться данными с злоумышленником, думая, что обменивается с тобой.

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

Поэтому тут появляется Public Key Signature (Сертификат Открытого Ключа). Сертификат открытого ключа позволяет на получающей стороне сопоставить публичный ключ с отправителем, проверить неизменность сообщения.

Public Key Infrastructure (PKI) – это инфраструктура (Infrastructure) по работе с публичными ключами (Public Key).

PKI – критичная часть в безопасности соединений в интернете сегодня. PKI является системой, которая определяет создание, сохранение, распространение и отзыв/аннулирование (revocation) цифровых сертификатов для public/private keys. PKI позволяет реализовать authentication, confidentiality, non-repudiation, integrity.

Базовая схема PKI.

PKI is a set of identities, roles, policies, and actions for the creation, use, management, distribution and revocation of public and private keys.

Digital Certificate (цифровой сертификат) – файл, который подтверждает что сущность (сервер или сервера) является владельцем определенного публичного ключа. Существуют разные типы сертификатов. Один сертификат может быть выдан на несколько hostname или даже wildcard, что обозначает любой хостнейм в одном домене.

• SSL/TLS server certificate – сервер предоставляет клиенту во время начала SSL/TLS коннекта, клиент проверяет доверяет ли он CA и что субъект в сертификате совпадает с hostname к которому он подключается.
• SSL/TLS client certificate (и чуть подробней вообще о client certificate) – опциональный компонент SSL/TLS коннекта и встречается реже чем серверный сертификат. Используются для аутентификации клиента на сервере (часто используется для аутентификации в VPN системах, Wi-Fi). Этот сертификат не выпускается public CA (обычно выпускается внутренним CA, например компании, для этого CA компании сначала добавляется в trust store, хранилище сертификатов на клиенте). Для проверки клиентского сертификата (сертификата открытого ключа) используется не схема с электронной подписью (как для серверных сертификатов), а challenge-response механизм (как в U2F) – сервер отсылает challenge клиенту, который клиент шифрует своим private key и отсылает обратно на сервер, тот его дешифрует public key клиента.

In order to issue client certificates, an organization must setup and maintain CA infrastracture to issue and sign certificates.

• Code signing certificate – используются для подписи исполняемых программ, позволяет пользователям программ проверять подпись и убедиться, что программа не изменена/создана производителем (см. MD-5 и Flame Malware Microsoft case). 

Сертификат состоит из открытого ключа отправителя, методанных (информация о владельце, времени действия, области применения ) и самое главное – электронной подписи от Certification Authority (CA), который сначала сам, используя Registration Authority (RA) (обычно CA и RA один сервер), проверяет принадлежность ключа владельцу (например, то что домен weril.me находится на том же веб-сервере, с которого идет запрос на сертификат), а потом, проверив, подтверждает принадлежность публичного ключа для других с помощью своей электронной подписи в сертификате. По сути сертификат устанавливает соответствие публичного ключа и владельца.

Сертификат открытого ключа (сертификат ЭП, сертификат ключа подписи, сертификат ключа проверки электронной подписи - электронный или бумажный документ, содержащий открытый ключ, информацию о владельце ключа, области применения ключа, подписанный выдавшим его Удостоверяющим центром и подтверждающий принадлежность открытого ключа владельцу.

The certificate authority is the entity that signs, issues, and stores certificates.
A digital certificate contains the public key information, along with a digital signature from a CA. It also includes information about the certificate, like the entity that the certificate was issued to.

Registration Authority - RA perform certification registration process. Confirm the identity and initiate certification process with CA.

Сертификаты хранятся в central repository – это позволяет certificate management system (системе управления сертификатами) безопасно хранить и индексировать ключи, управлять ими (отзывать, выдавать). 

Стандарт X.509 (x509 version 3)  – представляет из себя сертификат, который включает ваш идентификатор (Subject: fqdn, mail), публичный ключ (Subject Public Key Info) вместе с доп. информацией (срок действия, адрес CRL, etc), который подписан УЦ (CA). Подробнее ниже поиском по “Пример сертификата”. Такой (в виде сертификата) способ передачи публичного ключа:

• • понимают все современные системы
  • масштабируется

описывает формат цифровых сертификатов, первично появился в 1988. Текущая версия номер 3 (RFC 2459 от 1999). Так же определяет certification revocation list (CRL)  – способ распределения списка сертификатов, которые больше не валидны. CRL представляет собой список (по сути – файл) отозванных сертификатов (serial numbers сертификатов), который распространяется CA.

To verify a certificate, the period of validity must be checked, along with the signature of the signing certificate authority, to ensure that it's a trusted one.

CRL stands for "Certificate Revocation List." It's a list published by a CA, which contains certificates issued by the CA that are explicitly revoked, or made invalid.

Пример сертификата, на основе моего сайта.

• Version – 3 – версия x.509
• Serial number – серийный номер сертификата назначенный CA (позволяет легко управлять им)
• Certificate Signature Algorithm – 03 08 … – указывает какой алгоритм используется для шифрования публичного ключа и какой хеширующий алгоритм используется для подписи сертификата 
• Issuer Name – US Let’s Encrypt Authority X3 – кем выдан сертификат (кем подписан)
• Validity – not valid before 08.01.2019, not valid after 08.04.2019 – когда сертификат валиден. Not valid before поле введено т.к. возможен выпуск сертификатов на будущее (заранее), которые не должны быть активны сейчас, а должны быть только в будушем, not valid after – стандартный expiration date.
• Subject – weril.me – кому выдан сертификат
• Subject Public Key Info – E8 43.., RSA – включает публичный ключ, алгоритм шифрования публичного ключа
• Signature – 94 AE.. – подпись (по сути ID) сертификата от CA, используется для проверки сертификата
• Certificate Signature Value – подпись CA
• Certificate Fingerprint – не включается в сертификат, это значения, рассчитанные на клиенте при проверке сертификата (hash от сертификата)

Сертификатом может быть подписан софт – для проверки что софт является безопасным. Производитель софта подписывает софт подписывает своим приватным ключем,  подпись проверяется на хосте, который запускает приложение путем дешифрования через public key. Так же проверяется trust chain public ключа в сертификате.

CERTIFICATION AUTHORITY (ЦЕНТР СЕРТИФИКАЦИИ)

Электронная подпись открытого ключа делается Certification Authority. Certification Authority (Центр Сертификации, Удостоверяющий Центр) – заведомо доверенная организация. Мы, доверяя центру сертификации, устанавливаем сертификат открытого ключа получателя и начинаем с ним обмен. Валидация центра сертификации происходит по электронной подписи CA в сертификате открытого ключа. Аутентичность подписи сертификата проверяется с помощью открытого ключа CA, которой заранее (до обмена, чаще всего идет с дистрибутивом OS, причем они могут обновляться, а браузеры чаще всего используют сертификаты системы) есть в системе всех участников. Подробнее о калькуляции и работе с цифровой подписью ниже. Примером CA в мире WEB является просто крутейший Let’s Encrypt, который позволяет автоматизировать процесс получения сертификата SSL для сайта (здоровья тебе, let’s encrypt).

Для решения этой проблемы открытый ключ Алисы вместе с сопроводительной информацией (именем, сроком действия и прочим) подписывается центром сертификации. Конечно же, предполагается, что центр сертификации честный и не подпишет ключ злоумышленника. И второе требование: открытый ключ центра сертификации распространяется настолько широко, что ещё до установления связи Алиса и Боб будут иметь этот ключ, и злоумышленник ничего не сможет с этим поделать.

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

Весь PKI основан на доверии между участниками – создается chain of trust (цепочка доверия) начинающийся с Root Certificate Authority (root CA, корневого CA, который self-signed). Существует международный best practice держать Root CA полностью offline во избежание взлома. Слишком большая на нем “ответственность”. Аналогия – АЭС.

Корневой CA может (и делает, в случае WEB) делегировать полномочия по подписи нижестоящим CA (устанавливает в сертификате поле CA=true, что делает выданный сертификат intermediary/subordinate CA их может быть несколько по дереву) – он подписывает своим private ключем публичный ключ нижестоящему CA в виде сертификата, а тот может подписать своим клиентам (intermediary CA или end-entity/leaf certificate – сертификат без права CA, права выдачи сертификатов). Это “поведение” называется anchor of a trust в PKI. При этом широкоизвестный ключ нужно иметь только корневому CA, но честными должны быть все члены цепочки. Корневые сертификаты являются self-signed (самоподписанными), такой сертификат можно сделать и самому – например, сайт без доступа в интернет даже для возможности получения сертификата (по сути это подписание своего public ключа с помощью private ключа). Такой сертификат не будет считаться валидным до тех пор, пока ты не согласишься доверять этому сертификату (в случае корневых CA – по умолчанию). 

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

Пример списка установленных корневых сертификатов в операционную систему.

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

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

OCSP – Online Certificate Status Protocol. Протокол проверки валидности сертификатов. Отвечает, в том числе, за CRL.

DIGITAL SIGNATURE (ЦИФРОВАЯ ПОДПИСЬ) или как работает Public Key Signature

Кратко

Цифровая подпись – это зашифрованный приватным ключем хеш от данных (напр. публичного ключа). Клиент такую подпись может легко проверить имея публичный ключ + сами данные.

1. К данным применяется hash алгоритм
2. Цифровая подпись расшифровывается на основе публичного ключа
3. Значения полученные на предыдущих шагах сравниваются, в случае валидной подписи и данных – будут совпадать

Подробнее

CA, при выдаче сертификата, применяет hash функцию со своим private ключем к данными сертификата (публичный ключ + методанные), который он выдает. Результатом является цифровая/электронная подпись в виде зашифрованного hash. По сути, тут обратный процесс от описанного Базового алгоритма работы ассиметричного шифрования:

The private key is used to sign data. This allows a third party to verify the signature using the public key, ensuring that the signature came from someone in possession of the private key.

1. формируется цифровая подпись сертификата у CA: данные, в нашем случае все данные (публичный ключ отправителя + методанные), шифруются private ключем на стороне CA, с применением HASH функции (SHA1, MD5) + алгоритма шифрования (если говорить последовательно – сначала берется hash, потом он шифруется)
2. отправитель отправляет сертификат (публичный ключ + методанные + цифровая подпись CA)
3. получатель, используя public ключ CA, расшифровывает цифровую подпись и получает результат HASH функции для данных в сертификате, который рассчитан CA
4. расшифровав подпись, мы рассчитываем hash от данных (публичный ключ отправителя + методанные) в сертификате, применяя туже hash функцию, что CA
5. сравниваем значение hash из цифровой подписи, с результатом hash функции от данных в сертификате
6. если совпадает – все ок, если нет – подделка сертификата или данных

Все это прекрасно расписано в wiki (тут есть и вполне понятное формальное описание) и stackoverflow.

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

With a digital signature, you are trying to prove that the document signed by you came from you. To do that, you need to use something that only YOU have: your private key.

A digital signature in its simplest description is a hash (SHA1, MD5, etc.) of the data (file, message, etc.) that is subsequently encrypted with the signer's private key. Since that is something only the signer has (or should have) that is where the trust comes from. EVERYONE has (or should have) access to the signer's public key.

So, to validate a digital signature, the recipient

1) Calculates a hash of the same data (file, message, etc.),
2) Decrypts the digital signature using the sender's PUBLIC key, and
3) Compares the 2 hash values.
If they match, the signature is considered valid. If they don't match, it either means that a different key was used to sign it, or that the data has been altered (either intentionally or unintentionally).

У внимательного человека появляется вопрос, почему то, что зашифровано private key, расшифруется public key. Ведь по идее то что зашифровано публичным ключем расшифруется приватным (как в базовом алгоритме работы). 

My understanding was that the keys were not symmetric... that is, objects encrypted with a public key are able to be decrypted by the private key, but that this relationship did not work inversely... more specifically, I did not think objects encrypted with the private key could be decrypted by the public key. If that is indeed the case, than this definitely answers my question. 

Но ответ простой – это не ошибка и не симметричное шифрование. Так оно работает – то, что зашифровано публичным ключем, может быть расшифрованное приватным И НАОБОРОТ – то, что зашифровано приватным, может быть расшифровано публичным.

The keys work inversely to each other. Encrypted something with your public key? Decrypt it with your private key. Conversely, if you encrypted something with your private key, you decrypt it with your public. Such is the nature of asymmetric cryptography. 

Symmetric just means that the same key is used to encrypt/decrypt. Assymetric means that one key encrypts and a different key decrypts (and that the reverse is also true). 

Web of Trust

Web of Trust является альтернативой системы PKI. Сами конечные люди (end-entity/leaf certificate в терминологии PKI) выдают сертификаты другим людям. Верификация identity при этом идет с помощью согласованного механизм (например, с помощью традиционных методов – паспорт, права, etc). После проверки ты подписываешь сертификат другого человека и ручаешься за него (схеме по сути аналогична PKI). Причем процесс обычно двунаправленный – оба партнера подтверждают ключи друг друга. В результате организуется Key Signing Parties (посиделка людей с подписанными друг дружкой ключами ;)). Причем как и в PKI, мы доверяем сертификатам, которым доверяют те, которым мы уже доверились (кого мы идентифицировали).

Message Authentication Codes (MACs)

Существуют разные коды с разной реализацией

HMAC – keyed-Hash Message Authentication Code. По сути это hashing with key (data + key на входе в hash функцию).

• Хеш позволяет убедится в том, что данные те, что нужно (integrity)
• а authentication позволяет убедится в том, что они пришли от проверенного источника и не подменены

Информация, которая позволяет аутентифицировать отправителя сообщения (authenticity) и проверить отсутствие модификации сообщения (data integrity). По сути это функциональный аналог public key signature. MAC отправляется вместе с сообщением.

A MIC can be thought of as just a checksum or hash digest of a message, while a MAC uses a shared secret to generate the checksum. This also makes it authenticated, since the other party must also have the same shared secret, preventing a third party from forging the checksum data.

В HMAC MAC генерируется на основе двух вещей:

• Ключ – в технической реализации MAC отличается – в отличии от ассиметричного способа валидации public key, один ключ используется для шифрования и дешифрования MAC – т.е. используется симметричное шифрование.
• Криптографическая hash-функция (SHA-1, MD-5). От него во многом зависит безопасность полученного MAC. 

При приеме принимающая сторона вычисляет MAC на основе данных в сообщении и ключа сам и сравнивает с MAC в сообщении и по аналогии с public key signature: “если совпадает – все ок, если нет – подделка сертификата или данных”.

CMAC – Cipher-basedMessage Authentication Code. MAC на основе блочных/поточных симметричных шифров (AES/DES). Процесс очень похож на CMAC, просто вместо hash функции для генерации проверяемой на получении последовательности MAC используется шифр.

CBC-MAC – Cipher Block Chaining Message Authentication Code. Для генерации проверяемой на получении последовательности MAC используется блочный шифр, который работает в CBC режиме. CBC режим подразумевает включение предыдущего зашифрованного блока текста в следующий блок незашифрованного текста. В результате создается цепочка (Chain) зашифрованных блоков, которые требуют полной немодифицированной цепочки для расшифрования. Эта цель взаимосвязанно зашифрованных блоков подразумевает что любая модификация текста приведет к изменению вывода в конце цепочки, нарушив в результате целостность данных. 

Примеры популярных ассимметричных алгоритмов

RSA – одна из первых ассиметричных криптографических систем. Название в честь создателей – Ron Rivest, Adi Shamir, Leonard Adleman. Запатентована в 1983, стало публичной в 2000. RSA система определяет как механизм генерации и обмена ключами, так и механизм шифрования и дешифрования этими ключами. RSA основан на серьезной математической базе. Генерация ключей зависит от выбора двух уникальных, обычно очень крупных числа.

DSA (Digital Signature Algorithm) – другой пример ассиметричной криптосистемы. Используется для подписания и проверки данных. Запатентован в 1991, является частью правительственного стандарта USA. Подобно RSA, DSA описывает процесс генерации ключей с подписью и проверку данных с использованием ключевых пар. Безопасность этой системы зависит от рандомного исходного значения, которое используется для подписания. Если об этом рандомном значении стало известно или его можно как-то вычислить/угадать (например, т.к. число, которое используется как значение, не является по настоящему random) –  тогда у атакующего есть возможность выяснить private key. Это и произошло в 2010 у Sony с их PS3. Выяснилось, что они не обеспечили рандом этого значения для каждой подписи. Это позволило хакерам failOverflow восстановить private key, который Sony использовала для подписи софта в своей платформе. В результате стало возможно писать/подписывать и запускать софт на Sony, который она запустит, несмотря на то, что софт не из платформы. Это привело к пиратству игр в платформе Sony. 

Diffie-Hellman

Diffie-Hellman (DH) – алгоритм безопасного обмена ключами. Предназначен изначально только для обмена ключами, не для шифрования данных (хотя для этого так же пытался использоваться). DH решает ту же задачу, что и ассиметричное шифрование, когда оно используется для обмена shared-key, который в последующем будет использоваться в симметричном алгоритме шифрования. Используется в PKI системе (Public Key Infrastructure System). 

Пример работы DH (По описанию похож на симметричное шифрование):

1. Стороны обмены согласуют стартовое число (shared number). Оно должно быть рандомное, очень большое и отличаться для каждой сессии. Подразумевается небезопасным (т.е. от безопасности этого элемента не зависит система).
2. Каждая сторона выбирает еще одно крупное рандомное число, но это число уже хранится в тайне (secret number). 
3. Каждая сторона складывает shared number со своим secret number, в результате получая общее число (combined number)
4. Стороны обмениваются результатом сложения между собой. 
5. Далее стороны складывают полученные данные (combined number соседа) со своим secret number.
6. Результатом является shared number + secret numbet соседа + secret number свой. И это значение одинаково на обеих сторонах. При этом secret number обеих сторон остаются неизвестными (ну относительно неизвестными, т.к. операция вычитания из combined number потенциально украденного shared number приведет к получению secret number одной из сторон). 

ELLIPTIC CURVE CRYPTOGRAPHY (Эллиптическая криптография)

ECDH, ECDSA– вариации Diffie-Hellmen (DH) и Digital Signature Algorithm (DSA), которые работают с элиптическими кривыми

Elliptic curve cryptography (ECC, элиптическая криптография) – криптографическая система с открытым ключем, которая использует алгебраическую структуру эллиптических кривых над конечными полями для генерации безопасных ключей.

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

В отличии от традиционных систем с открытым ключем (RSA), которые используют факторизацию (разложение на множители) больших целых чисел, как сложность для инверсии public-private key системы на базе эллиптической криптографии используют дискретное логарифмирование.

Эллиптическая кривая состоит из набора координат, которые входят в алгебраическое уравнение. Такая кривая имеет несколько интересных и уникальных свойств:

• Горизонтальная симметрия (кривая вверх от х равна отраженной  кривой вниз от х)
• Любая не-вертикальная линия пересечет кривую максимум в трех местах – именно это свойство используется в шифровании

Польза эллиптических кривых состоит в том, что они способны достигать такого же уровня безопасности, как традиционные системы с открытым ключем, при этом используя меньший размером ключ. Например, 256 битный elliptic curve key сопоставим с 3,072 битным RSA ключем (внизу таблица). Это позволяет сильно сэкономить количество данных, которое нужно для хранения и передачи, при работе с ключами. Элиптические кривые с ключем 384 bit EC можно использовать для шифрования top secret данных в USA. Но так же в USA озабочены потенциальной уязвимостью EC к атакам на базе квантовых вычислений (однако тоже самое выше и про факторизацию числа, см. поиском factorization).

Сопоставление (на одной строке сопоставимые) уровня безопасности ECC и RSA ключей на основе информации NIST.

При этом производительность (на примере решения F5 Viprion) с элиптическим шифрованием пока значительно ниже “классического”.

https://www.f5.com/company/news/features/ssl-performance-results-f5-viprion-b4450-test-with-ixia-cloudstorm-100ge

More businesses move to ECC cipher suites for perfect forward secrecy

Hashing

Hashing или hash function – тип функции, которая принимает набор данных произвольной длины на входе и выводит фиксированный набор данных (hash/digest) на выходе. Это константа. Криптографические hash функции похожи на симметричные блочные шифры т.к. работают с блоками данных (и даже больше – многие hash функции основаны на модифицированных блочных шифрах).

Идеальная hash функция

• на разный набор входных данных производит всегда разный результат, т.е. hash от входящих данных уникален => нет вероятности коллизии, когда от разных данных будет один hash (привет, DES-3028 и Broadcom)

If two different files result in the same hash, this is referred to as a hash collision. Hash collisions aren't awesome, as this would allow an attacker to create a fake file that would pass hash verification.

• криптографическое хеширование и hash’и похожи тем, что из понятного текста появляется какая-то хрень, но hash сильно отличается от шифрования тем, что hash функция должна быть однонаправленной – не должно быть возможно из результата hash получить исходный текст (one-way function).

Hash functions, by definition, are one-way, meaning that it's not possible to take a hash and recover the input that generated the hash. Encryption, on the other hand, is two-directional, since data can be both encrypted and decrypted.

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

$ echo "Hello world" | md5sum # в MacOS просто md5
f0ef7081e1539ac00ef5b761b4fb01b3
$ echo "hello world" | md5sum
6f5902ac237024bdd0c176cb93063dc4

• функция должна быть быстрой

Hash используются во многих местах, например:

• в криптографии для
  • уникальной идентификации данных. К примеру,
    • сохранение паролей пользователей в виде hash в базе/файле like .htdigusers. Причем пароль может прогоняться через hash функцию несколько раз, в некоторых случаях с тысячами итераций. 
    • проверка на то, что файл не модифицирован напр. совпадение hash для ISO образа ОС или приложения – по факту ломали Linux Mint и bittorent, выкладывали зараженное ПО на оффициальный сайт и юзеры его качали. В таком случае наличие hash в отдельном!!! (не в одном!) от места хранения образов месте может защитить пользователя (но не факт, если это место тоже хакнут :)).

A common approach used in data transmission is for the sender to create a unique fingerprint of the data by using a one-way hashing algorithm. The hash is sent to the receiver along with the data. The receiver recalculates the data's hash and compares it to the original to ensure that the data wasn't lost or modified in transit.

• • проверки целостности
  • цифровых сертификатах
• Hash таблицы используются для ускорения lookup в таблице
• для идентификации (для удаления, просто обнаружения, etc) дублирующихся данных
• в оборудовании (например, сетевом), для экономии памяти

Так как применение абсолютно разное, существует огромное количество разных hash функций, в том числе “самописных” (привет еще раз DES-3028 и Broadcom).

rainbow tables (радужные таблицы) – используются хакерами для ускорения процесса восстановления паролей из украденных hash. Такая таблица представляет собой просто предрасчитанную таблицу из password – hash. С ней достаточно сделать lookup в таблице по hash, чтобы найти пароль, не рассчитывая пароль самому, как в случае с brute force.

Attackers can also use statistical analysis and rainbow tables against systems that improperly protect passwords with a one-way hashing function. A rainbow table is a precomputed table for reversing cryptographic hash functions and for cracking password hashes. Such tables can be used to accelerate the process of cracking password hashes.

Такие таблицы есть в интернете для популярных паролей и хеш-функций.

For a list of publicly available rainbow tables, see http://project-rainbowcrack.com/table.htm.

Защитой от таких таблиц является соль (salt/nonce) – дополнительные рандомные данные, которые добавляются к паролю перед применением к нему hash функции. В результате, в таблице, на основе которой происходит аутентификация, сохраняется и hash и salt. Поэтому общие таблицы из интернета тут не подойдут и нужно расчитывать пароль на основе hash самому, что сложно, особенно если соль большая по длине. Но и этим занимаются – например популярный в свое время http://gpuhash.me, который активно использовался для взлома Wi-Fi предлагал и предлагает даже бесплатные проверки на основе перехваченного вами handshake. Ранние UNIX системы использовали под разрядности соли 12 бит, что составляет 4096 возможных комбинаций соли. Получается для каждого пароля и соли в базе нужно генерировать hash для всех 4096 возможных salt. В новых системах типо Linux/BSD используется 128 бит под соль. Это бесконечность вариантов (340 + 36 нулей) и rainbow таблицы бесполезны тут. 

Instead of computing every hash, a rainbow table is a precomputed table of hashes and text. Using a rainbow table to lookup a hash requires a lot less computing power, but a lot more storage space.

Примеры hash функций (часть просто alias для shasum -a <length>)

# ls /usr/bin/*sum | tr ' ' '\n'
/usr/bin/b2sum
/usr/bin/cksum
/usr/bin/md5sum
/usr/bin/sha1sum
/usr/bin/sha224sum
/usr/bin/sha256sum
/usr/bin/sha384sum
/usr/bin/sha512sum
/usr/bin/shasum
/usr/bin/sum

# man shasum
-a, --algorithm 1 (default), 224, 256, 384, 512, 512224, 512256

MD-5 – крайне популярная криптографическая hash функция. Разработана еще в далеком 1992. Она работает на блоки из 512 бит и генерирует 128-битный hash digest. Серьезные проблемы в MD-5 обнаружены уже в 1996, что привело к рекомендациям использования в качестве замены SHA-1. В 2004 обнаружено, что MD-5 подвержен коллизиям HASH, что позволяет хакеру создать зараженный файл, который будет иметь такой же MD-5 digest, что и настоящий файл. В 2008 так же смогли создать и fake SSL сертификат, с таким же MD-5 hash, что настоящий. С 2010 рекомендовано не использовать MD-5 в криптографических приложениях. В 2012 эта коллизионность была использована в Flame malware, что привело к тому, что вредоносное ПО было подписано сертификатом от Microsoft и система думала, что это софт Microsoft. Сам Flame вирус долгое время считался “произведением искусства” – он распространялся по сети, записывал аудио, клавиатурную активность, делал скриншоты и делал попытки скачивания контактной информации с блютус устройств, которые располагались рядом с зараженным компьютером.

In 2012, Flame was believed to be the most sophisticated malware to date. Flame has the ability to spread to other systems over a local network. It can record audio, screenshots, and keyboard activity, and it can turn infected computers into Bluetooth beacons that attempt to download contact information from nearby Bluetooth-enabled devices.

SHA-1 (Secure Hash Algorithm) – набор функций для генерации hash. Создано мин. обороной США, NSA (National Security Agency). SHA-1 заменил MD-5 hash функцию. Является более безопасным в сравнении с MD-5. Но признан устаревшим с 2010 года. Современные браузеры не используют с 2017 года и пометят сайт с sha-1 подписью в сертификате небезопасным. SHA-1 работает на блоки из 512 бит и генерирует 160-битный hash digest. Используется в TLS/SSL , PGP SSH, IPSec, GIT/SVN VCS (для определения ревизий и обеспечения целостности данных). Имеет уязвимости (обнаружены в том числе Винсентом Рейменом, создателем AES), хотя и полную коллизию можно получить только с использованием больших вычислений с CPU (первоначально 2.7кк$), но при изменении способа атаки и добавлении GPU, что выяснилось в последствии, результат можно получить уже за 100-100к$ ресурсов cloud cpu+gpu. В 2017 получена первая коллизия на базе двух разных PDF при использовании CPU+GPU, на это потребовалось огромные вычислительные ресурсы – примерный эквивалент в 6500 лет одного CPU + 110 лет одного GPU. 

$ sha1sum shattered*
38762cf7f55934b34d179ae6a4c80cadccbb7f0a shattered-1.pdf
38762cf7f55934b34d179ae6a4c80cadccbb7f0a shattered-2.pdf

SHA-2/SHA-3/SHA-256 – наследники SHA-1. Рекомендуются (особенно SHA-3/SHA-256) к использованию вместо SHA-1 с 2010 года.

BLAKE2 – хеш-функция BLAKE2, потенциально способная заменить уязвимые MD5/SHA1 без просадки по производительности (в тестировании замены /dev/random даже более чем двухкратный прирост).

Так как алгоритм BLAKE2s опережает SHA1 по производительности, то его применение также положительно отразилось на производительности генератора псевдослучайных чисел (тестирование на системе с процессором Intel i7-11850H показало увеличение скорости на 131%).

MD5SUM, SHASUM

Пример проверки checksum сразу по списку файлов.

% cat checksums.txt
b79079ad71cc3c5ceb3561fff348a1b67ee37f71f4cddfec09480d4589c191d6 CentOS-7-x86_64-NetInstall-2009.iso
07b94e6b1a0b0260b94c83d6bb76b26bf7a310dc78d7a9c7432809fb9bc6194a CentOS-7-x86_64-Minimal-2009.iso

% shasum -c checksums.txt
CentOS-7-x86_64-NetInstall-2009.iso: OK
CentOS-7-x86_64-Minimal-2009.iso: OK

% echo "123" >> centOS-7-x86_64-Minimal-2009.iso

% shasum -c checksums.txt
CentOS-7-x86_64-NetInstall-2009.iso: OK
CentOS-7-x86_64-Minimal-2009.iso: FAILED
shasum: WARNING: 1 computed checksum did NOT match

В первой части, используя MD5SUM/SHASUM рассчитываем hash для входных данных, а так же проверяем корректность рассчитанного hash. Во второй части, сначала копируем содержимое предыдущего файла в файл с новым именем, видим, что hash для нового файла не отличается от hash предыдущего – hash берется от содержимого, а не от методанных (напр. имени). Далее, добавив пробел в исходный текст, мы проверяем, что hash меняется и проверка относительно старого hash не проходит. Видим, что hash меняется кардинально, даже из-за изменения/добавления одного символа.

# PART 1
$ echo 'This is some text in a file, just so we have some data' > file.txt

$ md5sum file.txt > file.txt.md5 # generate the MD5 sum for the file and store it

$ cat file.txt.md5

$ md5sum -c file.txt.md5 # you can also verify that the hash is correct, and that the original file hasn't been tampered with since the sum was made.


# PART 2
$ cp file.txt badfile.txt # create new file
md5sum badfile.txt > badfile.txt.md5 # generate a new md5sum for the new file

$ cat badfile.txt.md5 file.txt.md5 # Note that the resulting hash is identical to the hash for our original file.txt despite the filenames being different. This is because hashing only looks at the data, not the metadata of the file.

$ echo " " >> badfile.txt # add a space to the end of the file
md5sum -c badfile.txt.md5 # Now that you've made a very minor change to the file, try verifying the hash again. It should fail verification this time, showing that any change at all will result in a different hash.

$ md5sum badfile.txt > new.badfile.txt.md5 # To see how different the hash of the edited file is, generate a new hash and inspect it
cat new.badfile.txt.md5 file.txt.md5

Все тоже самое справедливо для SHA. По умолчанию генерируется SHA-1 hash, поведение можно изменить задав алгоритм через опцию -a (-a 256 для SHA-256).

# ONE WAY (работает даже на MacOS)
shasum file.txt > file.txt.sha1
cat file.txt.sha1
shasum -c file.txt.sha1
shasum -a 256 file.txt > file.txt.sha256
cat file.txt.sha256
shasum -c file.txt.sha256

# ANOTHER WAY (работает на Debian)
sha1sum
sha256sum

MIC (Message Integrity Check) – hash/digest от сообщения. По сути checksum для сообщения, который обеспечивает только целостность данных (аналог CRC) и при этом не предоставляет никакой защиты. Не путать с MAC (как с MAC address, так и с Message Authentication Check). В отличии от MAC, MIC не использует секретные ключи (т.е. не требует аутентификации) -> MIC не может никак защитить от того, атакующий изменит сообщение, пересчитает checksum и модифицирует MIC для сообщения. 

A MIC can be thought of as just a checksum or hash digest of a message, while a MAC uses a shared secret to generate the checksum. This also makes it authenticated, since the other party must also have the same shared secret, preventing a third party from forging the checksum data.

Applications

• Security/NGFW SSL inspection: Зашифрованный (в том числе HTTPS/TLS) трафик превалирует в сети как с точки зрения легитимного (вплоть до 90%), так и с точки зрения зловредного (до 70% payload).
• В этой статье далеко не вся информация про TLS, больше информации в статье NGFW
  • Про ESNI Бывает ESNI (encrypted), а бывает простой SNI – он cleartext и его можно подменить: • Cleartext SNI extension indicates where client may be going – spoofable
  • MITM TLS инспекция подробно описана в статье NGFW, защита от MITM так же прописана в статье по ссылке (ssl pinning, client certificate authentication, custom encryption)

HTTPS – HTTP over SSL (old, 3.0 deprecated from 2015)/TLS (secure from 1.2). TLS инкапсулирует данные HTTP для их защиты, аутентификации (обычно только сервера) и проверки целостности. Про SSL/TLS offload/acceleration cards и методах реализации перехвата/дешифрования (с MITM или без) в NGFW.

• Secure Sockets Layer (SSL) is broken, obsolete and no longer in use 

TLS – Transport Layer Security. Используется не только для защиты/аутентификации в HTTP (HTTPS), но и во многих других местах – VoIP звонки, такие как Skype или Google Hangouts, API, SSL/TLS VPN, email, instant messaging, Wi-Fi network security. Использует как asymmetric encryption (ключи), так и symmetric (данные). Помимо этого TLS использует и хеширование (целостность). В итоге получается набор шифров (cipher suite).

TLS использует salt/nonce.

SSL/TLS use asymmetric algorithms to securely exchange information used to derive a symmetric encryption key.

(Дублируется в TLS, TLS inspection)

10k cps для HTTPS это по сути предел commodity девайса.

TLS шифрует url запроса, но доменное имя передается в cleartext в TLS clienthello пакете в поле SNI. Есть конечно encrypted SNI (eSNI), который шифрует и FQDN, но он используется редко на текущий момент.

https://stackoverflow.com/questions/499591/are-https-urls-encrypted

Server Name (the domain part of the URL) is presented in the ClientHello packet, in plain text.

summary:

- FQDN (the domain part of the URL) MAY be transmitted in clear inside the ClientHello packet if SNI extension is used

- The rest of the URL (/path/?some=parameters&go=here) has no business being inside ClientHello since the request URL is a HTTP thing (OSI Layer 7), therefore it will never show up in a TLS handshake (Layer 4 or 5). That will come later on in a GET /path/?some=parameters&go=here HTTP/1.1HTTP request, AFTER the secure TLS channel is established.

Стандарт TLS 1.3 (RFC-8446) – вышел в 2018 году, TLS стал быстрее и безопаснее.

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

Performance has a major impact on user experience. TLS 1.3 represents a pivotal turning point for HTTPS performance.

Modern mobile networks will routinely add over 100ms of latency to each request. TLS 1.3 makes page load times significantly faster for mobile devices, improving the user experience for your visitors.

Utilizing Cloudflare’s global content delivery decreases the physical distance between your content and your visitors resulting in shorter physical round trip connection times (latency). The combination of reduced round trip connections and shorter distance results in enormous performance gains when establishing a secure connection.

• • Безопаснее за счет
    • удаления старых протоколов и подходов, которые делали протокол уязвимым к ряду атак
    • добавления новых протоколов и подходов, которые призваны сделать протокол более безопасным
    • В TLS 1.3 по сути используется двойное шифрование – двойной обмен DH

Data integrity is critical to your entire community. TLS 1.3 represents a significant leap forward for security. TLS 1.3 removes all primitives and features that have contribute to a weak configurations and enabled common vulnerability exploits like DROWN, Vaudenay, Lucky 13, POODLE, SLOTH, CRIME and more. TLS 1.3 has also introduced more improvements than any previous version of the protocol. Additional features have been added to enhance the security and robustness of the protocol.

При перехвате TLS 1.3 дампа можно ошибиться т.к. одной из первых строк (Version) будет версия отличная от 1.3. По факту версия указывается в определенном поле (Preferred version) в опциях ниже.

https://networkengineering.stackexchange.com/questions/55752/why-does-wireshark-show-version-tls-1-2-here-instead-of-tls-1-3
https://www.cloudshark.org/captures/64d433b1585a

Sorry, for the confusion, I was missing the exact TLS 1.3 semantics: For instance, in the Client Hello, the field "version" must contain the fixed value 0x0303 (TLS 1.2), while the prefered version is contained in the extension "supported versions".

Session reuse (resumption) – сервер запоминает сессию с клиентом и при следующем handshake по запросу клиента он происходит неполный – нет по сути криптографических вычислений вовсе т.к. в новой сессии используется старый ключ. Как итог вычислительная нагрузка ниже и на сервер и на клиент, так же меньший оверхед для трафика. Слайд из презентации Дениса Батранкова PaloAlto Networks. Fortinet в своих тестах Fortigate 7121F отключали полностью session resumption.

TLS предоставляет три вещи:

• Безопасный канал связи (encryption) – передаваемые по каналу данные защищены от подслушивания
• Аутентификация (authentication) – возможность аутентификации одной (1-way/simple) и/или обеих сторон (2-way/mutual) во взаимодействии используя сертификаты (часто) или пароль (крайне редко)
  • 1-way/simple обычно при использовании SSL/TLS только сервер аутентифицируется клиентом.
  • 2-way/mutual в некоторых случаях помимо проверки сертификата сервера клиентом, аналогичную проверку может делать сервер по отношению к клиенту (проверка сертификата клиента)
  • TLS-SRP (Secure Remote Password) – аутентификация клиента сервером путем запроса пароля (не проверки сертификата), не используется сейчас почти нигде

• Целостность сообщений (integrity) – есть проверка на то, что данные не потерялись и не изменены при передаче

Для организации безопасного канала связи используется TLS handshake – (пример однонаправленной проверки, только сервера):

• клиент устанавливает соединение по TCP (TCP handshake),
• отсылает TLS Client Hello (client info: максимальная поддерживаемая версия TLS, список поддерживаемых шифров, опции),
• далее происходит отправка сервером TLS Server Hello сертификата+шифров+hello (server info: максимальная версия TLS на основе версии клиента и поддерживаемой сервером, выбранные список шифров, цифровой сертификат),
• проверка сертификата на клиенте выбор метода обмена ключами (для последующего согласования shared secret в виде session key, который будет использоваться с symmetric encryption cipher для шифрования последующих данных)
• ChangeCipherSpec сигнализирует начало обмена с применением шифрования (смена с незащищенного на защищенное) – тут происходит обмен симметричным ключем, созданными на базе секретного (сессионного) ключа
• обмен данными зашифрованными симметричным ключем (напр. AES)

Session key получается из public-private key и в случае компрометации private key у атакующего есть возможность декодировать все предыдущие сообщения, связанные этим private key. Для защиты от этого есть концепция forward secrecy, это свойство криптографической системы, который обеспечивает защиту session key в условиях компрометации private key.

JA3 ssl fingerprint – метод идентификации клиента по информации передаваемой в handshake ssl. Можно добавить как поле в wireshark.

Because SSL negotiations are transmitted in the clear, it’s possible to fingerprint and identify client applications using the details in the SSL Client Hello packet. JA3 is a method of TLS fingerprinting that JA3 gathers the decimal values of the bytes for the following fields in the Client Hello packet; SSL Version, Accepted Ciphers, List of Extensions, Elliptic Curves, and Elliptic Curve Formats. It then concatenates those values together in order, using a "," to delimit each field and a "-" to delimit each value in each field.

Heartbleed – бага в OpenSSL библиотеке (реализует TLS) состоящая в обработке TLS сообщений hearbeat (сообщение одной стороны, что оно хочет сохранять сессию живой). heartbleed – пример уязвимости, которая находится прямо в ядре софта. Просто отключить такой софт до патча не получится т.к. он мега критичный. Одним из вариантов, до патча, был пересбор (перекомпиляция) OpenSSL с флагом, отключающим hearbeat сообщения.

Очень хорошо с картинками описано в вики.

Атака подразумевает отправку TLS hearbeat request и
1) аллоцирование на получающей стороне памяти под каждый такой request – это так и должно быть
2) использовании баги реализации обработки hearbeat сообщений в OpenSSL – он аллоцировал память (потом это исправили патчем) на основе значения в поле lenght, не на основе фактических данных. При такой аллокации (п2) уязвимые версии OpenSSL могли выдавать любую информацию (равную длине, запрашиваемой в поддельном heartbeat сообщении, которые называют heartbleed сообщениями) за пределами отведенного буфера – включая закрытые ключи/куки/данные других соединений и проч

Уязвимые версии OpenSSL читали память за пределами отведённого буфера (RFC предписывает не отвечать на такие пакеты). За пределами буфера могут встретиться любые данные, в том числе (очень редко) закрытые ключи шифрования сервера, данные других соединений, содержащие идентификационные cookie и многое другое.
Heartbleed осуществляется отправкой некорректно сформированного Heartbeat-запроса, в котором реальный размер строки очень мал, а число, символизирующее длину передаваемой строки, очень велико. Так можно получить в ответ от сервера больше всего скрытой информации. Таким образом, у жертвы возможно за один запрос узнать до 64 килобайт памяти, которая была ранее использована OpenSSL.
Heartbeat-запрос выглядит так: «Верни мне слово тест, которое состоит из 4 букв», и получает ответ «тест». Heartbleed-запрос выглядит иначе: «Верни мне слово „тест“, которое состоит из 500 букв», и получает ответ, состоящий из слова «тест» и еще 496 символов, лежащих у жертвы в активной памяти.
Несмотря на то, что злоумышленник имеет некоторый контроль над размером блока памяти, он никак не может управлять положением этого блока, и поэтому единственным способом увеличить вероятность получения ценных данных — многократный повтор эксплуатации ошибки.

Пример проблем подключения к серверу – сервер не выдал сертификат описан в статье APC RPDU.

Пример установления реального TLS соединения с данным сайтом weril.me при использовании TLS 1.2.

$ openssl s_client -connect weril.me:443 -tls1_2
CONNECTED(00000005)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = weril.me
verify return:1
---
Certificate chain
0 s:/CN=weril.me
i:/C=US/O=Let's Encrypt/CN=R3
1 s:/C=US/O=Let's Encrypt/CN=R3
i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
......cert.....
-----END CERTIFICATE-----
subject=/CN=weril.me
issuer=/C=US/O=Let's Encrypt/CN=R3
---
No client certificate CA names sent
Server Temp Key: ECDH, X25519, 253 bits
---
SSL handshake has read 3094 bytes and written 285 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-CHACHA20-POLY1305
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-CHACHA20-POLY1305
Session-ID: 029032CEE7FD53C3CDB33617835C93771E73025890D21C0E226FA2828A3DBEA4
Session-ID-ctx:
Master-Key: 1CD8D38AAAAC963BEF6A79EB75B242181439163DE964AE8951BB4F77B0975B26E28FDA99D3CD5ECD3112B97232D12DFD
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 5b 65 8d b9 6e b3 2f fe-f8 fa 17 1e 75 82 60 9a [e..n./.....u.`.
0010 - f9 0d 90 d5 c9 57 d6 49-df e6 1c 15 04 e8 cf c8 .....W.I........
0020 - 3f b8 a4 a0 56 60 5b af-64 2a 46 cb ea 3f 64 b9 ?...V`[.d*F..?d.
0030 - 28 f0 e6 7b 8b 38 ac 55-95 1f b6 86 80 a9 bc a9 (..{.8.U........
0040 - 36 7d 5c db 93 91 bf 5b-ed c7 d1 06 0f 6b ca e9 6}\....[.....k..
0050 - 61 9d 66 c4 76 3d 56 8f-f1 fa d7 e7 58 1f 03 0b a.f.v=V.....X...
0060 - 99 eb 24 b8 7e 78 bb 63-1d 44 61 10 2a 60 5b 16 ..$.~x.c.Da.*`[.
0070 - 5c ad 5d 5c d8 60 38 59-f2 13 65 f5 24 f5 6d ca \.]\.`8Y..e.$.m.
0080 - 78 f6 8c e9 86 dd 55 34-c1 f8 a4 9e 9b 2f 2f 6b x.....U4.....//k
0090 - 43 33 61 30 17 2c 75 47-d9 49 0b d5 f6 64 76 82 C3a0.,uG.I...dv.
00a0 - 27 3c 6a e8 e5 2c ad d4-b6 00 2f e1 17 9c 1f db '<j..,..../.....
00b0 - 75 e8 7d 74 93 18 e0 76-95 0d 53 d8 d3 e4 fd 56 u.}t...v..S....V

Start Time: 1619119850
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---

HTTP/1.1 400 Bad Request
Date: Thu, 22 Apr 2021 19:31:07 GMT
Server: Apache/2.4.38 (Debian)
Content-Length: 301
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
</p>
<hr>
<address>Apache/2.4.38 (Debian) Server at weril.me Port 443</address>
</body></html>
closed

Попытка подключения с TLS 1.1 безуспешна.

$ openssl s_client -connect weril.me:443 -tls1_1
CONNECTED(00000005)
write:errno=54
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.1
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Start Time: 1619120086
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---

Пример успешного подключения по TLS 1.1 к ya.ru.

$ openssl s_client -connect ya.ru:443 -tls1_1
CONNECTED(00000005)
depth=3 C = PL, O = Unizeto Sp. z o.o., CN = Certum CA
verify return:1
depth=2 C = PL, O = Unizeto Technologies S.A., OU = Certum Certification Authority, CN = Certum Trusted Network CA
verify return:1
depth=1 C = RU, O = Yandex LLC, OU = Yandex Certification Authority, CN = Yandex CA
verify return:1
depth=0 C = RU, L = Moscow, OU = ITO, O = Yandex LLC, CN = *.yandex.az
verify return:1 r
---
Certificate chain
0 s:/C=RU/L=Moscow/OU=ITO/O=Yandex LLC/CN=*.yandex.az
i:/C=RU/O=Yandex LLC/OU=Yandex Certification Authority/CN=Yandex CA
1 s:/C=RU/O=Yandex LLC/OU=Yandex Certification Authority/CN=Yandex CA
i:/C=PL/O=Unizeto Technologies S.A./OU=Certum Certification Authority/CN=Certum Trusted Network CA
2 s:/C=PL/O=Unizeto Technologies S.A./OU=Certum Certification Authority/CN=Certum Trusted Network CA
i:/C=PL/O=Unizeto Sp. z o.o./CN=Certum CA
---
Server certificate
-----BEGIN CERTIFICATE-----
......cert.....
-----END CERTIFICATE-----
subject=/C=RU/L=Moscow/OU=ITO/O=Yandex LLC/CN=*.yandex.az
issuer=/C=RU/O=Yandex LLC/OU=Yandex Certification Authority/CN=Yandex CA
---
No client certificate CA names sent
Server Temp Key: ECDH, X25519, 253 bits
---
SSL handshake has read 5352 bytes and written 239 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.1
Cipher : ECDHE-RSA-AES128-SHA
Session-ID: B554589EA58D3797C47A1E1F770312674833D7A03C558DEDC0D6EB5D24116E03
Session-ID-ctx:
Master-Key: FECED800BB7BE9A90016DB206D3DCF8FB76026C0A2B329491C8426AACC3030B044E150FF597FB553595796CDCA14FC7D
TLS session ticket lifetime hint: 100800 (seconds)
TLS session ticket:
0000 - 2c 4d ae b5 f3 0d 94 86-dc 46 85 ee 73 ea ad fc ,M.......F..s...
0010 - 63 0e 62 d4 cc 21 01 0b-13 ec ef a1 6a 84 2c 8f c.b..!......j.,.
0020 - cc 87 a8 86 9d a5 cc e0-27 12 5f a2 26 22 39 75 ........'._.&"9u
0030 - 46 59 1d 57 88 e5 ef 8b-f1 2e 25 a3 b8 86 54 e9 FY.W......%...T.
0040 - 6a ec f1 e4 aa 69 5d 16-36 68 1f a5 91 d7 e6 51 j....i].6h.....Q
0050 - 6c 9d bc 8e 24 33 70 70-e3 c0 26 54 9d 3e 63 00 l...$3pp..&T.>c.
0060 - 7d 39 b1 4d 5d 59 2e d2-81 d8 c9 69 71 55 c9 23 }9.M]Y.....iqU.#
0070 - 40 ac 14 3d 56 b0 b2 45-40 2c e1 8d 38 0d 73 70 @..=V..E@,..8.sp
0080 - d8 8a fd 2b 11 91 92 0d-0b 97 76 79 c8 e5 af 0a ...+......vy....
0090 - 15 52 94 b1 1a 56 14 59-41 23 92 b9 e6 33 ef 8c .R...V.YA#...3..

Start Time: 1619120199
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---

1. openssl version –a
2. Найти дирректорию с конфигурацией (OPENSSLDIR): напр. "/usr/lib/ssl"
3. В папке открыть CNF-файл
4. Найти строчку с level и установить значение в 0

openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -sha256 -days 3650 -nodes -subj '/CN=localhost'

openssl x509 -in cert.pem -text -noout


You can also add -nodes (short for no DES) if you don't want to protect your private key with a passphrase. Otherwise it will prompt you for "at least a 4 character" password.
The days parameter (365) you can replace with any number to affect the expiration date. It will then prompt you for things like "Country Name", but you can just hit Enter and accept the defaults.
Add -subj '/CN=localhost' to suppress questions about the contents of the certificate (replace localhost with your desired domain).

SSH

Secure Shell (SSH) – безопасный сетевой протокол, который использует шифрование для предоставление доступа к сетевому ресурсу по небезопасной сети.  Является гибким и модульным – поддерживает различные алгоритмы обмена ключами (DH), различные симметричные протоколы шифрования данных, различные методы аутентификации (включая даже кастомные). 

Изначально задуман как замена небезопасным telnet/rlogin/r-exec, поэтому чаще всего используется для безопасного доступа к командной строке (remote login to command-line based systems). Но может использоваться и для других вещей, включая, например, туннелирование/проксирование трафика через SSH. 

В общем случае SSH использует public key cryptography для аутентификации удаленной машины, к которой подключается клиент.

Кроме того, SSH опционально поддерживает и клиентскую аутентификацию через client certificates (двухстронняя проверка). В таком случае Пользователь генерирует ключевую пару public key/private key, public ключ затем передается на те системы, на которые пользователь хочет подключиться. В последующем сервер при авторизации проверяет private ключ пользователя (который находится только у пользователя) по его открытому ключу (который хранится на сервере).

PGP/GPG

• в git config можно указать даже pgp/gpg ключ для подписи коммитов
• GPG (также известный как GnuPG) создавался как свободная альтернатива несвободному PGP.
• RHEL7 хранит  GPG ключи в
  /etc/pki/rpm-gpg/

Pretty Good Privacy (PGP) – приложение по ассиметричному шифрованию, которое позволяет аутентифицировать данные, обеспечивать приватность от третих лиц.

Разработан PGP Phil Zimmerman в 1991, и распространялось (soft + source code) бесплатно, несмотря на требования об экспорте усиленного шифрования (key larger then 40 bits, в то время как в PGP минимальным размером ключа было 128 бит) от регулятора в USA. Зиммерман обошел это требование опубликовав source code в виде книги (воспользовался первой поправкой к конституции).

Несмотря на свою относительную старость PGP считается безопасным приложением – явные уязвимости до сих пор не найдены, хотя многие (в том числе ведущие криптографы) рекомендуют отказаться от него. Он сопоставим с военным шифрованием. Существует огромное количество кейсов, когда полиция и правительство не могло получить доступ к данным, зашифрованным PGP. PGP полагается на ассиметричное шифрование. Чаще всего используется для encrypted email communications, но так же может шифровать данные в системе – файлы, папки или даже весь диск. 

PGP первоначально использовал RSA алгоритм, но потом, во избежание проблем с лицензированием, стал использовать DSA. 

VPN

• Все статьи про VPN
  • Базовая теория (эта статья)
  • DMVPN
  • L2VPN
  • Remote Access VPN
  • IPsec VPN и множественные его реализации, site-to-site VPN
  • Пример практической настройки IPSec
    • IPSec VPN на Linux
    • IPSec VPN на Zyxel Keenetic

VPN (Virtual Private Network) – механизм, который позволяет хосту (remote access VPN) или сети (site-to-site VPN) удаленно подключится к частной сети, для передачи данных по публичному каналу, такому как Internet. Своего рода зашифрованный туннель.

Существует огромное количество VPN решений, каждое со своими плюсами и минусами. Под VPN обычно используется отдельная сеть/vlan и возможно отдельные правила мониторинга/ограничения безопасности этой сети – это менее безопасная среда (дополнительная потенциальный вектор атаки), чем обычная корпоративная LAN. Изначально VPN решения развивались для замены leased lines – отдельный физических каналов между объектами, но сейчас он используется не только для задачи site-to-site. В общем случае считается, что поверхность атаки для UDP-based реализаций VPN меньше в сравнении с TCP-based – UDP приложение чаще сложнее обнаружить, атаки на кол-во сессий (syn flood) чаще всего реализуются с помощью TCP.

Существует огромное количество протоколов, реализующих VPN, самые популярные:

• PPTP – разработка Cisco, использовал MPPE протокол на базе deprecated шифрования RC4
• L2F – разработка Cisco, не обеспечивает шифрование
• L2TP – не обеспечивает шифрование
• GRE – используется site-to-site, не обеспечивает шифрование
• MPLS VPNs – используется site-to-site, не обеспечивает шифрование
  • L2VPN
  • L3VPN
• IPSec VPN – используется site-to-site и remote-access (реже), крайне популярен сейчас, особенно в связке с GRE (GRE over IPsec, подробнее ниже); обеспечивает шифрование
• SSL/TLS – remote-access, крайне популярен сейчас; обеспечивает шифрование

Существует огромное количество реализаций VPN, например:

• Linux реализации VPN
  • xSwan (StrongSwan, LibreSwan) и реализации на основе них (напр. ipsec-vpn-server ниже)
  • SoftEther
  • Racoon
  • Accel-ppp (bras средне-провайдерского/энтерпрайз уровня)
•  SD-WAN
  • Cisco SD-WAN
  • VMware SD-WAN
• DMVPN

• Cisco реализации VPN

  •  
  • IPSec Traditional site-to-site based on crypto-maps
  • EZVPN
  • DMVPN
  • Get VPN
  • Flex VPN

L2TP (Layer 2 Tunneling Protocol) – по сути не VPN решение и не обеспечивает шифрование, но позволяет передать модифицированные пакеты из одной сети в другую инкапсулируя эти пакеты. Чаще всего реализовывается в связке L2TP over IPsec (RFC 3193). Так же может использоваться без VPN – например ISP могут предоставлять доступ в сеть на основе L2TP ;).

The tunnel is provided by L2TP which permits the passing of unmodified packets from one network to another.
The secure channel, on other hand, is provided by IPsec, which provides confidentiality, integrity, and authentication of data being passed.

У крупных провайдеров, использующих L2TP как основной способ организации связи клиент-BRAS, чаще всего IPSec отключен. т.е. туннель создается, но он не шифруется и промежуточные устройства (DPI/СОРМ/хакеры) могут перехватить и прочитать трафик, если он не зашифрован еще каким-то образом (напр. перехваченный трафик содержит взаимодействие с google по HTTPS).

Работа L2TP over IPsec:

• • устанавливается IPSec туннель в соответствии с фазами (подробнее в IPSec)
  • устанавливается L2TP туннель, в результате L2TP пакеты упаковываются в IPsec

SSL/TLS

SSL/TLS так же могут использоваться для создания VPN tunnel. Например, Cisco clientless VPN на базе Cisco ASA.

OpenVPN

Cryptographic Hardware

TPM (Trusted Platform Module), TAM (Trust Anchor Module), АПМДЗ (Аппаратно-программный модуль доверенной загрузки) – аппаратное устройство, обычно интегрированное аппаратно в компьютер(ную систему). Есть стандарт, описывающий TPM. TPM по сути выступает как выделенный крипто-процессор для системы. TPM имеет свой RSA (или другой) ключ, который зашит в hardware во время производства (это основной недостаток TPM, производитель может знать ключ и прошить его на другое устройство). TPM бывают различных версий, Microsoft со своим решением BitLocker для FDE рекомендует использовать TPM 1.2 и выше для шифрования диска. 

российские решения: ПМДЗ ViPNet SafeBoot, ПАК Соболь

Может быть реализован:

• как отдельный чип – классическим TPM, наиболее безопасная реализация т.к. в таком случае есть защита от физического взлома в виде tamper protection. Пример реализации – Trusted Anchor module (TAm) Cisco на базе FPGA, который недавно поломали :D. На его основе весь сок железа работает, включая Security Devices типо ASA/Firepower.

хотя с использованием электронного микроскопа и оборудования с точностью микрон исследователь смог получить доступ ко всему содержимому TPM через манипуляцию с микросхемой TPM (подключился к незашифрованной data bus внутри TPM и послушал незашифрованные данные) - но это крайне сложно и требует много времени

What is Cisco’s Trust Anchor?
Cisco Secure Boot is a secure startup process that ensures the integrity of the firmware running on Cisco hardware devices. To perform this validation each time the device resets, Cisco developed a separate, special-purpose hardware device, known as the Trust Anchor module (TAm), as a root of trust for the secure boot process. After system power-on, the TAm runs the first instructions, which immediately verify the integrity of the bootloader. Should any failure be detected by PGA anchor, the device alerts the user and reboots the device, thus preventing the device from executing the modified bootloader.

Trust Anchor Module (TAm) ((IN CISCO ISR 4000 SERIES)
• HW Authenticity Check
• Secure PnP
• Integrity Verification 
• Anti-Tamper Chip Design
• Built-In Crypto Functions
• Secure Storage
• Tamperproof ID for the device
• Binds the hardware identity to a key pair in a cryptographically secure X.509 certificate PID during manufacturing
• Anchors Secure Boot in Hardware to Create a Chain of Trust
• Only authentic signed Cisco software boots up on a Cisco platform
• Each physical router is uniquely identified by the chassis ID and certificate serial number
• Certificate is stored in on-board Temper Proof Module (TPM)
- Installed during manufacturing process
• Certificate is signed by Avnet root CA
- Trusted by Control Plane elements
• DigiCert root CA chain of trust is used to validate Control Plane elements
• Alternatively, Enterprise root CA chain of trust can be used to validate Control Plane elements
- Can be automatically installed during ZTP

• интегрирован в другой чип – на мобильных устройствах чаще всего сделано так, встроен в процессор или материнскую плату, несет название secure element
• виртуализирован на гипервизоре
• реализован в качестве прошики/софта

TPM предоставляют:

A TPM can be used for remote attestation, ensuring that a host is a known good state and hasn't been modified or tampered (from a hardware and a software perspective). TPMs can also seal and bind data to them, encrypting data against the TPM. This also allows it to be decrypted by the TPM, only if the machine is in a good and trusted state.

• Platform integrity – TPM оценивают целостность платформы и предотвращают неавторизованные изменения системы как с точки зрения hardware, так и с точки зрения software (воровство диска, клонирование диска, изменение других hardware)
  • Hardware authentication (с использованием зашитого RSA ключа) – TPM может обнаружить неавторизованные изменения hardware с системой. 
  • Remote attestation – система аутентифицирует свой софт и аппаратную конфигурацию для удаленной системы (отдает результат, например, в виде hash на основе зашитого ключа RSA), что дает понять удаленной системе целостна ли наша  (Playstation, Xbox)
• FBE (File Based Encryption) – шифрование конкретных файлов/папок (HOMEDIR) на диске. 
• FDE (Full Disk Encryption) – TPM часто используется для шифрования всего содержимого диска (не отдельных файлов).
• Secure generation of keys
• Random number generation
• Data binding and sealing – использование секретного зашитого ключа RSA для получения уникального ключа, который используется для шифрования данных. По сути это привязывает зашифрованные данные к TPM (к системе на которой находится эта TPM), т. к. только аппаратный ключ сможет дешифровать данные. В случае sealing все аналогично с описанным выше для случая binding, только TPM должен находится в специальном состоянии.
• Trusted Execution Environment (TEE) – новая концепция в secure elements. TEE предоставляет полномасштабную изолируемую среду для исполнения, которая позволяет изолировать приложения от основной OS и других приложений, которые установлены в OS. Так же изолируются и безопасные процессы друг от друга, которые запущены в TEE. 

FDE

FDE (Full Disk Encryption) – шифрование всего содержимого диска (не отдельных файлов) для защиты от воровства/изменения данных. Решения бывают разные, так же возможны разные способы миграции между этими решениями, в большинстве решений есть возможноcть восстановления доступа к данным при забытых паролях (key escrow, ниже о нем). Получить доступ к данным обычно можно с помощью пароля или ключа. Но сами данные, в “back end”, всегда шифруются/дешифруется ключами (при пароле – получение доступа к ключу). Чаще всего операция делается незаметно для пользователя – пароль для дешифрования (для ключа дешифрования) = пароль входа в систему.

With the contents of the disk encrypted, an attacker wouldn't be able to recover data from the drive in the event of physical theft. An attacker also wouldn't be able to tamper with or replace system files with malicious ones.

FDE повсеместно используется во многих мобильных устройствах – ноутбуки, телефоны, планшетники. Но рекомендуется и для декстопов/серверов. 

Возможные реализации FDE:

• TPM – причем TPM может запрещать unlock диска если system configuration изменился (см. TPM platform integrity)
• PGP
• Bitlocker от Microsoft (Windows 10), интегрируется с TPM/USB drive или просто по паролю пользователя в систему (XTS-AES with 128 bit key)

- Скорость шифрования по моей практике примерно 100GB/h для USB 2.0 с узким местом в скорости записи/чтения (одновременно) с диска (25MB/s оба; производительность 2.0 - 60MB)
- При первичном шифровании всего диска (если выбрали этот вариант), крайне нежелательно отключать диск до окончания шифрования или как минимум прерывания процесса шифрования - данные могут быть потеряны. При этом в последующем такая проблема так же возможна, но только для файла, который шифруется (не для всей файловой системы).
- При включении bitlocker ошибка отказано в доступе (access denied) возможно если мы пытаемся включить bitlocker по RDP

• Filevault 2 от Apple (XTS-AES-128 with 256 bit key)
• dm-crypt , LUKS – open source для Linux: 
• Encryption is a technique that protects data from unauthorized access by using a secret key to transform the data into an unreadable form. Encryption can be implemented at the disk level, by using tools such as dm-crypt or LUKS, or at the file system level, by using tools such as eCryptfs or EncFS.
• veracrypt – windows

https://veracrypt.eu/en/System%20Encryption.html

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

FDE конфигурация включает один физический/логический раздел, который включает данные для мест, которые требуют шифрования (обычно root volume, где установлена OS). Данные шифруются не полностью – boot partition (kernel, bootloader, netRD) (чтобы BIOS смог запустить его) и окно авторизации (чтобы дешифровать данные) остаются незашифрованными. Чаще всего при использовании FDE невозможно по сети (если только это не IP-KVM) перезагрузить машину и ввести пароль после перезагрузки – сетевые службы чаще всего не стартуют до дешифрования FDE. 

В теории, через подмену незашифрованных данных (kernel, bootloader, netRD), можно атаковать зашифрованные данные, но подобная атака сложна и кроме того есть защита от атаких атак в UEFI в виде реализации протокола SBP (Secure Boot Protocol). SBP использует public key cryptography для шифрования/дешифрования этих элементов boot процесса. Изначально SBP настроен для использования platform key (зашит в прошивку UEFI) – публичный ключ, соответствующий приватному, который используется для шифрования файлов. В момент загрузки с помощью этого ключа происходит дешифрование (проверка подписи) файлов и только корректно подписанные файлы будут запущены в итоге. 

key escrow – позволяет восстановить ключ шифрования без пользовательского пароля авторизованному лицу. У авторизованного лица (админа) может быть для этого специальный ключ (escrow key), админский пароль, вход в учетную запись (icloud).

Key escrow allows the disk to be unlocked if the primary passphrase is forgotten or unavailable for whatever reason.

Использование OpenSSL

OpenSSL поддерживает ГОСТ шифрование, в том числе 2012 года.

Какая разница между gostengy и gost_capi?
gostengy для OpenSSL >= 1.1.0, поддерживает ГОСТ 2012
gost_capi для OpenSSL от 1.0.0 до 1.0.2, НЕ поддерживает ГОСТ 2012
openssl req -x509 -newkey gost2012_256 -pkeyopt paramset:A -nodes -keyout key.pem -out cert.pem

Для типичной работы ГОСТ TLS в nginx (сначала ГОСТ потом RSA), следует использовать приоритет шифросюит (сначала ГОСТ потом всё остальное), например так:
ssl_ciphers GOST2012-GOST8912-GOST8912:GOST2001-GOST89-GOST89:HIGH;

OpenSSL библиотеку использовали в lab’е ниже для

1. генерации private key на базе RSA и создания public key на основе private key (key pair)
2. шифрования/деширования данных
3. генерации hash от данных и проверки на основе hash

OpenSSL is a commercial-grade utility toolkit for Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols. It’s also a general-purpose cryptography library. OpenSSL is licensed under an Apache-style license, which means that you’re free to get it and use it for commercial and non-commercial purposes (subject to some simple license conditions).

Generate RSA private and public key pairs using the OpenSSL utility.

Before you can encrypt or decrypt anything, you need a private and a public key, so let’s generate those first!

Remember, a key pair consists of a public key that you can make publicly available, and a private key that you need to keep secret. Shhhh. 🙂 When someone wants to send you data and make sure that no one else can view it, they can encrypt it with your public key. Data that’s encrypted with your public key can only be decrypted with your private key, to ensure that only you can view the original data. This is why it’s important to keep private keys a secret! If someone else had a copy of your private key, they’d be able to decrypt data that’s meant for you. Not good!

First, let’s generate a 2048-bit RSA private key, and take a look at it. To generate the key, enter command “openssl genrsa -out private_key.pem 2048” into the terminal. This command creates a 2048-bit RSA key, called “private_key.pem”. The name of the key is specified after the “-out” flag, and typically ends in “.pem”. The number of bits is specified with the last argument.

$ openssl genrsa -out private_key.pem 2048
Generating RSA private key, 2048 bit long modulus
................................................................................................+++
.......................................................................................................+++
e is 65537 (0x10001)

$ cat private_key.pem 
-----BEGIN RSA PRIVATE KEY-----
MIIEpAIBAAKCAQEA2CGpoeY8FZ+AiWnvo837bbahhU86991GkrbXfb4sgtGCFTMS
yjvXtlbuDr/WO6F3ANwf/H8pU+CWYAsstyqbJ96UpKGBPTKXzE0SstTTtDHNPixw

Now, let’s generate the public key from the private key, and inspect that one, too. Now that you have a private key, you need to generate a public key that goes along with it. You can give that to anyone who wants to send you encrypted data. When data is hashed using your public key, nobody will be able to decrypt it unless they have your private key. To create a public key based on a private key, enter the command below.

$ openssl rsa -in private_key.pem -outform PEM -pubout -out public_key.pem
writing RSA key

$ cat public_key.pem
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2CGpoeY8FZ+AiWnvo837

Use the key pair to encrypt and decrypt some small amount of data.

You’ll simulate someone encrypting a file using your public key and sending it to you, which allows you (and only you!) to decrypt it using your private key. Similarly, you can encrypt files using other people’s public keys, knowing that only they will be able to decrypt them.
echo ‘This is a secret message, for authorized parties only’ > secret.txt

This creates the file “secret.enc”, which is an encrypted version of “secret.txt”. Notice that if you try to view the contents of the encrypted file, the output is garbled. This is totally normal for encrypted messages because they’re not meant to have their contents displayed visually. To encrypt the file using your public key, enter this command:

$ openssl rsautl -encrypt -pubin -inkey public_key.pem -in secret.txt -out secret.enc

$ cat secret.enc
i!:_p3
AVh~
Y9yą35!`'Fե

The encrypted file will now be ready to send to whoever holds the matching private key. Since that’s you, you can decrypt it and get the original contents back. Remember that we must use the private key to decrypt the message, since it was encrypted using the public key. Go ahead and decrypt the file, using this command:

$ openssl rsautl -decrypt -inkey private_key.pem -in secret.enc
This is a secret message, for authorized parties only

Use the key pair to sign and verify data to ensure its accuracy.

Now, you’ll create a hash digest of the message, then create a digital signature of this digest. Once that’s done, you’ll verify the signature of the digest. This allows you to ensure that your message wasn’t modified or forged. If the message was modified, the hash would be different from the signed one, and the verification would fail.

This creates a file called “secret.txt.sha256” using your private key, which contains the hash digest of your secret text file. To create a hash digest of the message, enter this command:

$ openssl dgst -sha256 -sign private_key.pem -out secret.txt.sha256 secret.txt

$ cat secret.txt.sha256
dv}ëi}Ь

GW"\+-IEA
QY+eOFd+i+_-@_abbi+ ~]

With this file, anyone can use your public key and the hash digest to verify that the file hasn’t been modified since you created and hashed it. To perform this verification, enter this command:

$ openssl dgst -sha256 -verify public_key.pem -signature secret.txt.sha256 secret.txt
Verified OK

AAA

• Подробнее о Cisco ISE, Radius, Tacacs в отдельной статье

AAA (Authentication Authorization Accounting)

Authentication is proving that an entity is who they claim to be, while authorization is determining whether or not that entity is permitted to access resources.

Authentication (authn) – проверяем что аутентифицируемый объект (клиент/сервер) является тем, кем он говорит, что он является.

• Идентификация – ты говоришь, кто ты.
• Аутентификация – проверяется что ты являешься тем, кем представляешься.

Аутентификация включает идентификацию и проверку личности. Идентификация включена в процесс аутентификации, она позволяет описать объект уникально (например, адрес почты уникально идентифицирует объект).

• не должны быть предсказуемыми и речь не только о парольных данных, это относится и к логину (напр. использование логина admin не рекомендуется)
• выданы безопасным образом (secure issuance)
• отозваны при необходимости

Аутентификация должна быть реализована правильно, некорректная реализация может привести к компрометации учетных записей, токенов/ключей сессий и прочим проблемам. Такой кейс частый, поэтому Broken Authentication problem является вторым в топ 10 OWASP для WEB applications.

Broken Authentication. Application functions related to authentication and session management are often implemented incorrectly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities temporarily or permanently.

Примеры систем, которые аутентифицируют клиента (и не только – чаще всего используются для полного перечня AAA):

• LDAP (подробнее в Directory Services)
• Kerberos (подробнее в Directory Services)
• RADIUS (подробнее в ААА)
• Diameter – (подробнее в ААА)
• TACACS+ – (подробнее в ААА)

Могут контролировать доступ к любым ресурсам – сети (802.1x, VPN, Wi-Fi), серверам, ресурсам.

Многие из них используют EAP (Extensible Authentication Protocol), для согласования наиболее безопасных протоколов аутентификации для работы между клиентом и сервером. Данные пользователей зачастую хранятся в базе (иногда база и RADIUS – отдельные сущности), но некоторые системы могут работать и с обычными файлами (.htdigusers). RADIUS и TACACS, помимо задач аутентификации (пользователь тот, за кого себя выдает), решают и задачи авторизации (дать доступ туда/к тем командам, но не дать туда/к этим командам).

Clients don't actually interact directly with the RADIUS server; the authentication is relayed via the Network Access Server.

Электронные КАРТЫ (SMART CARDS)

1. карта вставляется в читатель кард,
2. далее читатель извлекает данные с карты,
3. запрашивает от пользователя пароль/pin,
4. пользователь вводит пароль/pin,
5. читатель путем применения операции хеша к паролю сравнивает пароль пользователя и хешированный пароль/pin, сохраненный на карте

• user private key
• генератор OTP
• карта может отвечать на challenge-response

• вместо магнитной ленты на карте используется чип
• карта сама проверяет пользовательские данные, а не читатель – на чипе находится микропроцессор, который получает питание при инсерте карты в читатель

Токены (Tokens)

Токены обычно ротируют коды (пароли) каждые n секунд (60 секунд для RSA SecureID), коды являются одноразовыми (OTP – One Time Password/Pad). СМС считаются менее надежными в сравнении с токенами – они не шифруются по умолчанию, их зачастую можно перехватить при хорошей тех. подготовке (или даже просто звонке оператору), сильная зависимость от организации безопасности у оператора связи.

One-Time Pad (OTP) - a key used only one time.

Примеры токенов на основе того с какими токенами работает Cisco Duo.

HOTP <serial number>,<HOTP secret key>[,<HOTP counter>]
TOTP <serial number>,<TOTP secret key>[,<TOTP time step>]
YubiKey <serial number>,<private identity>,<secret key> # Компании Facebook и Google используют YubiKey для аутентификации сотрудников и пользователей.

Токены:

• TOTP (RSA, time-based one time password/token) – в токен и на сервер включается одинаковое seed value (рандомно изначально сгенерированное значение ключа, которое хранится на сервере и на токене: (random seed/repeatable random – часто используется генераторами трафика), далее на основе времени (которое 1) всем известно 2) должно быть относительно синхронизировано) происходит ротация ключа, причем
  • сервер может учитывать смещение во времени у токена в рамках нескольких минут
  • перехват кода OTP не так страшен т.к. он валиден только на одну попытку аутентификации ((проверено на данном блоге)).
• COTP (counter-based one time password/token) –  так же как и в OTP токен и на сервер включается одинаковое seed value, но вместо времени включается секретное значение счетчика, которое меняется каждый раз, когда пароль генерируется на устройстве. Считается более безопасной реализацией токена т.к. атакующему нужно выявить не только seed value, но и counter. Кроме того, если жертва продолжает пользоваться токеном, то быстро выявится взлом (токен перестанет работать т.к. значение счетчика на сервере != значению счетчика на токене). 

• U2F (Universal 2nd Factor, security keys) – эволюция физических токенов. Поддерживается браузерами (Google Chrome), большим количеством сервисов:

Браузер (Google Chrome) имеет встроенную поддержку протокола U2F
- Браузер "знает", что полученный запрос на U2F-аутентификацию надо направить на
U2F-токен
- Браузер "умеет" это делать безо всяких дополнительных плагинов и пр. 

Google все сервисы (Drive, Cloud, Gmail, YouTube, Wallet, Google+)
GitHub
WordPress
Dropbox
Linux PAM
OpenSSH

Представляют собой маленькие устройства или встроенные в устройства криптопроцессоры (по сути TPM, в котором хранятся ассиметричные ключи и дополнительное пространство для запуска встроенного кода). Включает challenge-response, механизм вместе с криптографией на базе публичного ключа, для реализации более безопасного и, как ни странно, удобного решения second-factor authentication. Поддержка U2F встроена в Chrome/Opera браузеры. Защищает от клонирования или подделки т.к. внутри них есть уникальный секретный ключ, который защищен. Не защищает напрямую от Man-in-the-middle атак, но подразумевается, что использование U2F (аутентификация посредством U2F), должно проходить поверх TLS, который эту защиту обеспечит. Как работает secure key:

• • Регистрация ключа для сайта или сервиса. Во время регистрации secure key генерирует пару ключей private/public key для этого сайта (уникальных для этого сайта, на случай компрометации сайта) и отправляет public key на сайт для регистрации. Он так же идентифицирует сайт и сохраняет его public key. 
  • После регистрации, во время аутентификации, сайт запросит логин/пароль, как обычно. Но после авторизации сайт так же запросит security key (например, в виде USB drive с кнопкой или подключения телефона и нажатия кнопки – гарантия что вирус не авторизуется за вас без вашего знания). Challenge-response подразумевает уникальную сессию, которую нельзя повторить (repay attack), в рамках каждой аутентификации – клиент шифрует challenge сервера своим private ключем при каждой аутентификации и отправляет на сервер, сервер проверяет challenge, дешифруя его public key клиента. Что делает схему крайне безопасной. 

SSO (Single Sign-On) – один раз авторизовался, а далее успешная авторизация позволяет заходить в сервисы, проходя окно авторизации (OpenID, Citrix SSO, SAML, LTPA IBM). Очень удобно – позволяет не хранить кучу разных паролей, не терять время пользователя на постоянные реавторизации и обслуживание систем с паролями. Недостаток в безопасности – один взлом (напр. традиционный или новый – воровство session cookie/token/ticket) потенциально дает доступ ко всему . Поэтому SSO обычно используется только в схеме 2FA/MFA.

SSO может быть реализован по разному, например:

• путем аутентификации на центральном сервере аутентификации (напр. LDAP, Kerberos), далее LDAP/Kerberos предоставляет cookie/token/ticket, который может использоваться чтобы получить доступ к приложениям, которые сконфигурированы с возможностью использования SSO. 
• с использованием SAML (WEB SSO) и identity providers (подробнее ниже).

SSO - an authentication concept that allows users to authenticate once to be granted access to a lot of different services and applications. 

SSO allows one set of credentials to be used to access various services across sites. This reduces the total number of credentials that might be otherwise needed. SSO authentication also issues an authentication token after a user authenticates using username and password. This token then automatically authenticates the user until the token expires. So, users don't need to reauthenticate multiple times throughout a work day.

• Relaying Parties – приложения/сайты, к которым пользователь получает доступ
• Federated Identify (ID) or Centralized Identity or Linked Identity – пользовательские данные, хранящиеся на центральном сервере (federated identity system)
• Federated Identity System/Provider – система, которая обрабатывает запросы SSO на аутентификацию/авторизацию, так же передает/обменивается пользовательскими атрибутами между identity providers и relaying parties. В ней можно управлять пользователями. Identity provider (IdP) – сервис (application, web site) ответственный за координацию identities между пользователями и клиентами. IdP может обеспечить пользователя идентифицируемой информацией и передавать эту информацию сервисам, когда пользователь запрашивает доступ. 
• Federated identity management – совокупность разделяемых протоколов, которые позволяют управлять пользовательскими id в организации
• Delegation – SSO использует его для вызова внешнего api для аутентификации/авторизации пользователей, используется чтобы в приложении не хранились пользовательские данные (user/pass)
• Domain – сеть, в которой все пользователи и ресурсы (приложения) подключены к одной центральной базе (Federated identity system)
• Factor – вектор, посредством которого может быть подтверждена личность при аутентификации
• Forest – коллекция доменов, управляемых централизованной системой
• Multitenancy – термин, который обозначает то, что в архитектуре предусмотрена возможность полного логического разделения, которая позволяет использовать сервис/приложение/устройство разными пользователями независимо друг от друга. Пример multitenancy – SAAS (microsoft 365, google docs, yandex music).
• Passwordless – метод доступа без использования пароля, обычно на основе токена/смс/email/biometric sensors
• Social ID provider (social IDp) – тип identity provider на основе социальной сети (google, facebook, twitter)
• webID – идентифицируемые данные обычно получаются из http запроса, часто они получаются из аутентифицированного email
• Windows ID – пользовательская информация в active directory
• ws-federation – стандарт для информации о identity используемый в веб приложениях и браузерах, используемый в windows identity foundation (фреймворк созданный microsoft для создания identity aware applications)

WS-Federation defines mechanisms for allowing different security realms to broker information on identities, identity attributes and authentication.

1. 1. Пользователь хочет открыть в браузере консоль управления Yandex Cloud.
   2. Если пользователь уже проходил аутентификацию и время жизни cookie в его браузере не истекло, то он переходит на главную страницу консоли управления. Если это не так, то консоль отправляет его на сервер поставщика удостоверений для аутентификации.
   3. Пользователь переходит на страницу аутентификации на сервере поставщика удостоверений и вводит свои логин и пароль.
   4. Если аутентификация прошла успешно, сервер поставщика удостоверений переадресует пользователя обратно на страницу входа в консоль управления.
   5. Поставщик удостоверений направляет сервису IAM облака подписанное сообщение (SAML Response) с информацией о том, что пользователь прошел аутентификацию.

Методы аутентификации в WEB (кратко, подробно поиском по каждому в этой статье):

1. 1. SSL/TLS authentication на базе digital certificate PKI (подробнее PKI)
   2. HTTP Basic Auth – крайне простая аутентификация: никаких handshake, никаких cookie, никакого шифрования (нужно использовать SSL/TLS). В каждом запросе в HTTP header к серверу клиент в открытом виде передает закешированные учетные данные. Недостатки крайне серьезные: нет стандартного логаута, не кастомизируется форма по вводу логин-пароль (или других credentials), существующие реализации имеют уязвимости, несмотря на простоту самой концепции.
   3. HTTP Form-based Auth – самый популярный способ аутентификации. В сравнении с Basic Auth
      • форма по вводу учетных данных кастомизируется как угодно, но при этом стандартизации в реализации нет
      • данные так же передаются в открытом виде и требуется использование шифрования SSL/TLS
   4. DAA (Digest Access Authentication) – по сути аналог Basic Auth, но вместо передачи в открытом виде каждый раз учетных данных передается MD5 hash от этих данных и так же nonce для защиты от атак на повторение (repay). Нужно учитывать, что MD5 небезопасен (уязвим для атак на коллизии хеша), поэтому хоть это и лучше чем в clear-text, но полагаться на эту защиту вообще не стоит.
   5. LTPA (Lightweight Third-Party Authentication) – IBM proprietory метод для SSO.
   6. OAuth, OAuth2
   7. OpenID, OpenID Connect (OID)
   8. SAML (security assertion markup language) – открытый стандарт аутентификации и авторизации на основе XML, так же как OpenID есть возможность передавать Attribute пользователя (напр. email/phone).  SAML поддерживается Active Directory и Google Workspace. Используется для обмена аутентификационными/авторизационными данными между identity providers. Раньше требовал использования SOAP over HTTP, но в версии SAML2 это больше не требуется. SAML широко используется для реализации SSO.

OpenID (OID) – open decentralized authentication system. Используется обычно в связке с OAuth. Открытый стандарт, который позволяет участвующим сайтам, известным как Relying Parties, аутентифицировать пользователей используя третью сторону (какой-то сервер аутентификации, Identity Provider – Google, Microsoft, Yahoo, FaceBook, etc). Похожая на SSO вещь, но аутентификация зачастую не сквозная. В результате сайты аутентифицирует пользователей, не требуя от пользователя данных и не требуя реализации аутентифиции на самом сайте. Так же пользователи могут посещать сайт, не создавая аккаунт. Хотя это зачастую и сложно реализовать/поддерживать, это очень удобно для клиента, который не хочет плодить сущности без нужды. Для работы сайту нужно создать shared secret с провайдером и все (используется для обмена сообщениями). После редиректа клиента, в результате успешной авторизации у третьего лица и подтверждения что клиента хочет авторизоваться на сайте, сайт получает факт успешной аутентификации и какие-то данные (Attribute Exchange Extension – напр. email/phone) + токен (не пароль).

OpenID allows authentication to be delegated to a third-party authentication service.

OAuth2 – открытый протокол/стандарт авторизации, используемый многими API и современными приложениями. Является крайне популярным методом авторизации, похожий на OpenID. Самый главный плюс OAuth – пользовательские учетные данные никогда не передаются непосредственно приложению. Приложению передается только временный token (должен быть временным, по факту конечно можно реализовать и “криво”) который сопоставляется с пользователем и может быть отозван провайдером OAuth/пользователем. OAuth2 требует использования TLS для шифрования данных.

Схема работы OAuth очень похожа на OpenID, только вместо аутентификации, сайт получает какой-либо доступ от имени пользователя (например, отправлять сообщения/почту). Обычно OpenID используется совместно с OAuth – OpenID Connect это уровень аутентификации, встроенный в OAuth 2.0. По сути как RADIUS и TACACS, объединение задач аутентификации и авторизации. Для relaying parties/third party services позволяет аутентифицировать пользователей и при этом не хранить у себя пользовательские учетные данные, что зачастую является очень весомым аргументом (правовые аспекты). 

OAuth is an open authorization protocol that allows account access to be delegated to third parties, without disclosing account credentials directly.

В отличии от чистого OpenID провайдер OAuth авторизации знает все о том, кто решил проверить клиента, так же OAuth привязан к конкретному провайдеру, в отличии от OpenID. И это огромный плюс для таких крупных игроков как google/facebook/vk. Полезно для небольших сайтов, например блогов – можно только таким пользователям давать возможность комментирования. В OAuth встроена поддержка Redirect URI – после авторизации OAuth (напр. в Google) происходит перенаправление “обратно” на исходный сайт это как удобно, так и позволяет избежать определенных векторов атак.

Пример совместной работы OAuth и OpenID. Так же OAuth работает и с SAML.

Authorization (authz)/Авторизация – выдача полномочий на основе аутентификации (куда имеет доступ аутентифицированный entity).  Авторизация (так же как и аутентификация) должна быть реализована правильно, некорректная реализация может привести к компрометации учетных записей, токенов/ключей сессий и прочим проблемам. Такой кейс частый, поэтому Broken Access Control является пятым в топ 10 OWASP для WEB applications. Подходом к контролю доступа (access control) называют политикой безопасности (security posture).

Можно ли авторизоваться без предварительной аутентификации? (Да/Нет)

Можно. Если доступ к ресурсу или объекту открыт для всех пользователей интернета.

Есть два основных подхода к контролю доступа:

• по умолчанию запретить (implicit or explicit deny/default deny, в то числе zero trust)  – доступ который не разрешен = запрещен, подход чаще всего используемый на устройствах реализующих безопасность ((подробнее о implicit deny выше))
• fail close/fail open (fail-close, fail-open) – что делаем по умолчанию в случае проблем (напр. отказ обработчика на трафик) – пропускаем проблемный трафик (и трафик «за ним») или блокируем. Для тестирования по netsecopen DUT должен быть настроен в fail close режиме. Но в целом кейсы бывают разные In some environments, network interruption can be a greater concern than security, leading to the choice to fail open. (BMWG IETF 111) Fail open фиксировали в лаборатории EANTC, когда устройство под нагрузкой пропускало “все” т.к. не справлялось. Причем судя по удивлению в выражении главы в виде “utter disgrace” – не ожидали пропуски.

[bpm] The DUT must be configured in ""fail close"" mode. We will describe this under section 4. Any failure scenarios like ""fail open"" mode is out of scope.

Also "Fail-Open" behavior MUST be disabled on the DUT/SUT.

https://blogs.keysight.com/blogs/tech/nwvs.entry.html/2020/05/20/fail_closed_failop-ZYAt.html

FAIL CLOSED
This strategy is common in situations where security concerns override the need for access.
To prioritize security: In an IP network, security appliances like firewalls can be configured to fail closed, to prevent incoming Internet traffic from being passed into your internal network when the firewall is unable to confirm that the packet is allowed.
It’s important to note that the fail closed strategy, even for a device like a firewall, has not always been the rule. In some environments, network interruption can be a greater concern than security, leading to the choice to fail open. This was more frequently the case in the early days of firewall deployment, when organizations were learning how to balance the need for security inspection with network availability.

• по умолчанию разрешить (default allow) – доступ который не запрещен = разрешен, подход чаще всего используемый когда безопасность или не нужна или не является критичным фактором (в сравнении со скоростью deploy, например), примером устройства можно считать коммутатор

Так же в контексте контроля доступа существуют принципы безопасности:

• обоснованность доступа (need to know, need-to-know) – есть причины, по которым нужен доступ к информации/системе
• наименьшие привилегии (least privilege) – нужно предоставлять минимально необходимый уровень доступа требуемый для выполнения работы

Broken Access Control. Restrictions on what authenticated users are allowed to do are often not properly enforced. Attackers can exploit these flaws to access unauthorized functionality and/or data, such as access other users’ accounts, view sensitive files, modify other users’ data, change access rights, etc.

An organization’s approach to access controls is referred to as its security posture. There are two fundamental approaches—open and secure. Open, also referred to as default allow, means that access not explicitly forbidden is permitted. Secure, also referred to as default deny, means that access not explicitly permitted is forbidden. Access decisions should consider the security principles of need to know and least privilege. Need to know means having a demonstrated and authorized reason for being granted access to information. Least privilege means granting subjects the minimum level of access required to perform their job or function.

sudoedit /etc/default/grub 

- Sudoedit allows the system administrator to only allow sudo rights for editing certain files, not specific commands or all files in general. It allows the administrator to control which files a user (or groups of users) can edit with elevated privileges.
- What's more, the user can use his/her preferred editor, not one that is specified by the administrator.

Контроль авторизации бывает на основе разных схем:

• Mandatory Access Control (MAC) – политики, которые не может поменять владелец информации (как понимаю, напр. требования регулятора). В MAC объектам назначается security label с категорией объекта. Субъектам назначается уровень видимости в соответствии с принципами need to know (категория), least privilege (уровень доступа) используемыми категориями объектов. При попытке доступа субъекта к объекту происходит сравнение (напр. на базе ОС) уровня видимости/доступа и категории объекта. Уровень субъекта должен быть не ниже уровня объекта  и у субъекта должен быть доступ к категории объекта. Реализуется зачастую по требованиям регулятора (правительственные/военные системы).
  
• Discretionary Access Controls (DAC) – политики, заданные владельцем информации/ресурса. Широко используются в коммерческих операционных системах. Владелец информации создает ACL, в котором описывает какие пользовательские id/групповые id имеют доступ к каким данным. Разрешения при использовании групп кумулятивные – если группа имеет права только read, а учетная запись в этой группе write – то в итоге пользователь сможет и читать и записывать. 
• Role-Based Access Control (RBAC, так же называют non discretionary controls) – политики на основе роли или функции. Права не назначаются на группу или пользователя. Администраторы выдают разрешения для роли, пользователям присваиваются роли (одна роль на пользователя, без возможности кастомизации под учетные записи). Для кастомизации создаем новую роль и применяем ее к пользователю. В итоге это очень гибкая система.
• Rule-Based Access Control – доступ осуществляется независимо от пользователя или группы (напр. время суток, местоположение, src/dst address, workstation). Критерий и правила определяются владельцем ресурса. Правила можно комбинировать с другими методами доступа – напр. DAC/RBAC
• Attribute-Based Access Controll (ABAC) – модель контроля доступа на основе оценки атрибутов объекта и субъекта, который получает доступ к объекту, с использованием кастомизированной логики. ABAC имею поддержку булевой логики, которая может оценивать большое количество атрибутов. Такие правила могут быть очень гибкими и сложными. Пример access control фреймворка, который включает ABAC – extensible access control markup language (XACML).

Once authentication is complete, an authorization model defines how subjects access objects. Mandatory access controls (MACs) are defined by policy and cannot be modified by the information owner. Discretionary access controls (DACs) are defined by the owner of the object. Role-based access controls (RBACs, also called nondiscretionary) are access permissions based on a specific role or function. In a rule-based access controls environment, access is based on criteria independent of the user or group account, such as time of day or location.

• Object capability – на базе характеристик объекта, к которому организуется доступ.
• Security labels – на базе лейбла безопасности,  такого как confidential, secret, top secret.
• ACL – на базе критерия, который можно задать в access control list (user id, group, location, day)

Object capability used programmatically and is based on a combination of unforgible reference and an operational message
Security labels are mandatory access controls embedded in object and subject properties
Acls are used to determine access based on some combination of specific criteria such as a user id, group membership, classification, location, address, day.

Примеры двух уязвимостей в WEB приложениях, относящихся к авторизации:

• HTTP Parameter Pollution (HPP) – уязвимость возможна, когда несколько HTTP параметров имеют одно имя. Атакующий при эксплуатации уязвимости может обойти проверку ввода, вызывать ошибки в приложения или модифицировать значения внутренних переменных. Атакующий может найти уязвимость анализируя формы и действия которые доступны для пользовательского ввода в веб-приложении, в последующем атакующий может добавить в GET/POST данные несколько переменных с одним именем, но разным значением и посмотреть на поведение приложения – если ответы отличаются (impedance mismatch), то потенциально возможно наличие уязвимости.

HPP vulnerabilities can be introduced if multiple HTTP parameters have the same name. An attacker may take advantage of HPP vulnerabilities to bypass input validation, trigger application errors or modify internal variable values.
An attacker can find HPP vulnerabilities by finding forms or actions that allow user-supplied input. Then the attacker can append the same parameter to the GET or POST data - but with different value assigned.

https://weril.me/?s=test&s=test2&s=test3

• Insecure Direct Object Reference – приложение предоставляет доступ к объекту на основе пользовательского ввода, что в итоге может приводить к authorization bypass и доступ к sensitive data (база/файлы и проч). Сделать тестовую атаку можно используя OWASP WEBGOAT + OWASP ZAP (линки на них поиском по OWASP). Приложение не делает input validation/sanitation/escape technique и не реализует корректную авторизацию. К примеру – по ID пользователя мы получаем информацию о нем, хотя этим пользователем не являемся или меняем ему пароль.

Application provides direct access to objects based on user-supplied input. You can bypass authorization and access sensitive data.
This vulnerability occurs when an application does not sanitize user input and does not perform appropriate authorization checks. An attacker can take advantage of Insecure Direct Object References vulnerabilities by modifying the value of a parameter used to directly point to an object. 

https://store.h4cker.org/buy?customerID=1245 
In this example, the value of the customerID parameter is used as an index in a table of a database holding customer contacts. The application takes the value and queries the database to obtain the specific customer record. An attacker may be able to change the value 1245 to another value and retrieve another customer record.

https://store.h4cker.org/changepassd?user=omar
In Example 1-2, the value of the user parameter (omar) is used to have the system change the user’s password. An attacker can try other usernames and see if it is possible to modify the password of another user.
Mitigations for this type of vulnerability include input validation, the use of per-user or -session indirect object references, and access control checks to make sure the user is authorized for the requested object.

ACL (Access Control Lists) – бывают не только на сетевом оборудовании, но например в файловой системе (разграничение по правам в Windows тоже делаются через Access Control Lists). Папка или отдельный файл может иметь список лиц/групп-лиц, которые могут иметь те или иные (R/W/E) права к папке/файлу. Индивидуальные разрешения для объекта называются Access Control Entries, они составляют ACL. 

Accounting

• Accounting-ом зачастую пренебрегают, но он крайне важен для обнаружения/расследования взломов.
• Нужно защищать данные аккаунтинга – там зачастую содержаться сенситив данные, поэтому доступ к ним должен быть ограничен.
• Нужно учитывать желание хакеров замести следы путем манипуляции/уничтожения аккаунтинг данных.
• Обмен в случае RADIUS защищается путем использования разделяемого ключа между клиентом и сервером. Можно настроить периодические RADIUS аккаунтинг пакеты между клиентом и сервером (напр. Cisco ISE) для отслеживания активных сессий на текущий момент. 

Accounting – сохранение данных о том, куда ходил/что делал пользователь в системе. Критичным компонентом accounting является Аудит, потому что сам запись в accounting не означает, что кто-то его смотрит (как с мониторингом). “Классический” TACACS используется как syslog – по сути кто, что ввел в консоли устройства. “Классический” RADIUS accounting часто используется для биллинга ISP – он записывает большое количество данных, которые могут использоваться для анализа достижения квоты (ограничить доступ в это время, ограничить полосу когда выкачал столько то):

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

Accounting involves recording resource and network access and usage. Auditing is reviewing these usage records by looking for any anomalies.

Network security

• 802.1x в отдельной статье

Network hardening – процесс улучшения безопасности сети путем уменьшения потенциальных рисков через конфигурационные изменения и соблюдение политик. Implicit deny, monitoring & analyzing traffic. 

Мониторинг трафика (в том числе возможно и с клиентских устройств и приложений, не только логов с файрвола и аутентификаций; полезно и при разборе уже состоявшихся взломов в рамках post-fail analysis/post-mortem, чтобы предотвратить повтор/понять масштаб взлома) и анализ логов (причем чаще всего автоматический анализ, не ручной) крайне важен т.к. сначала нужно понять корректные паттерны поведения пользователей в сети, чтобы потом понять нетипичные, которые возможно говорят о взломе/заражении.

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

Centralized logging is really beneficial, since you can harden the log server to resist attempts from attackers trying to delete logs to cover their tracks. Keeping logs in place also makes analysis on aggregated logs easier by providing one place to search, instead of separate disparate log systems.

В контексте того, что нужно логгировать и сколько хранить, нужно найти середину:

• слишком много данных очень часто плохо – во первых дорого для хранения, во вторых избыточные “мусорные” данные зачастую не позволяют найти важное
• слишком мало – тоже плохо, можно не слоггировать то, что нужно было логгировать

SIEMS – Security Information and Event Management System – по сути централизованный сервер логов для СБ, с возможностью анализа логов. Примеры: rsyslog, Splunk (очень поплурный open-source), IBM Security Qradar, RSA Security analytics.

Технология SIEM обеспечивает анализ в реальном времени событий (тревог) безопасности, исходящих от сетевых устройств и приложений, и позволяет реагировать на них до наступления существенного ущерба

Системы по автоматическому анализу логов (logs analysis system, например Splunk):

• часто лог системы позволяют нормализировать данные из разных источников (например на входе поменять YYYY-MM-DD на DD.MM.YYYY), зачастую позволяя реализовать correlation analysis (анализ взаимосвязей событий) между разными системами

Logs from various systems may be formatted differently. Normalizing logs is the practice of reformatting the logs into a common format, allowing for easier storage and lookups in a centralized logging system.

• могут алармить на преднастроенные правила (после стольких то попыток неудачных аутентификаций слать аларм), но лучше правила задавать и самому – только ты знаешь где у тебя критичная БД и кто должен к ней обращаться, какие протоколы могут быть использованы для подключения, а какие (даже попытки) – не должны происходить вовсе. На эти настроенные правила можно настраивать оповещения в зависимости от категории/приоритета.

MACSEC

• Пример настройки в Linux
• Пример кейса применения macsec – шифрование между своими стойками в арендном ДЦ.

• uplink macsec – switch-switch
• downlink macsec – host-switch с использованием MKA (macsec key agreement)

• Auth only
• Auth + encryption
• Encryption only

Network separation – разделение сети на разные элементы, полезно в сетевой безопасности (разные vlan, подсети, vrf, контексты) – можно изолировать проблемы, проще мониторить трафик между элементами и проч.

Firewall, NGFW, NGIPS – подробнее в отдельной статье

Proxy и Reverse Proxy – подробнее в статье про proxy. 

HoneyPot – приманки для атакующих. Их огромное количество. Бывают универсальные, а бывают под конкретное направление – могут например даже эмулировать industrial сеть с SCADA контроллерами и управляющими сообщениями, передаваемыми посредством Modbus.

SCADA/ICS decoys

ConPot emulates a number of operational technology control systems infrastructure, including protocols like MODBUS, DNP3 and BACNET. It comes with a web-server that can emulate a SCADA HMI as well.

GasPot emulates a Veeder Root Gaurdian AST that is commonly used for monitoring in the oil and gas industry.

Или могут предоставлять функционал, которые расписывает подробно все действия вирусов в системе используя sandboxing – какой код запускался, какой файл/регистр изменился, состояние памяти, чем обменивался с сетью и проч. И самое главное безопасно для того, кто этим занимается. Примеры sandbox решений – Cisco Threat Grid, Cuckoo Sandbox. Пример в статье NGFW для Cisco (Dynamic Analysis), пример в отдельной статье для PaloAlto.

A sandbox is simply a standalone environment that allows you to safely view or execute the program while keeping it contained. A good example of sandbox services is the Cisco ThreatGrid. This great tool and service tracks changes made to the file system, Registry, memory, and network.

Cuckoo Sandbox is not really a honeypot, but it’s a great sandbox for malware analysis. You can safely and programmatically execute possible malware samples, including binaries, Microsoft Office documents and emails within a Cuckoo VM and receive a full report on what code executed, what file / registry changes were made, and what network callbacks were observed. Pair it with VMCloak to automatically build sandbox VM’s that are harder for malware to fingerprint.

Создать своего рода sandbox можно вручную, главное защитится от ситуации, когда вирус из виртуальной среды инфицирует host машину – нужна полная изоляци и отключение всех шарингов между host машиной и виртуальной.

Remember that the number-one goal is to keep the malware contained. If you allow the host system to become compromised, you have defeated the entire purpose of the exercise. Virtual systems share many resources with the host system and can quickly become compromised if the configuration is not handled correctly. Here are a few pointers for preventing malware from escaping the isolated environment to which it should be confined:
1. Install a virtual machine (VM).
2. Install a guest operating system on the VM.
3. Isolate the system from the guest VM.
4. Verify that all sharing and transfer of data is blocked between the host operating system and the virtual system.
5. Copy the malware over to the guest operating system and prepare for analysis.

Вообще не любой malware код запустится в sandbox среде – вирусописатели люди тоже не глупые и зачастую реализовывают методы проверки. malware код не стартует:

• Если обнаружено, что запуск произведен в VM среде (напр. по коду OUI извлеченного из MAC адреса).
• Если обнаружено, что на хосте отсутствует сетевое подключение (тут может помочь утилита FakeNet)

- Malware authors sometimes use anti-VM techniques to thwart attempts at analysis. If you try to run the malware in a VM, it might be designed not to execute. For example, one simple way is to get the MAC address; if the Organizationally Unique Identifier (OUI) matches a VM vendor, the malware will not execute.
- The malware may also look to see whether there is an active network connection. If not, it may refuse to run. One tool to help overcome this barrier is FakeNet. FakeNet simulates a network connection so that malware interacting with a remote host continues to run. 

Wi-Fi Security

• WPA3 – по идее самая безопасная версия WPA. В контексте безопасности кажется что лучше всего использовать WPA3, но по факту вот мой ответ знакомому на вопрос стоит ли это того (актуально в 2023).

Привет, в теории он должен быть лучше вплане безопасности, но по факту это шлак 1) я когда смотрел были глюки на кинетике - подключение дольше, иногда не проходило 2) если делать нормально с защитой от понижения версии то это надо чтобы все девайсы поддерживали, а это сказки 3) в нем уже нашли уязвимости😁

Плюс есть тонна багов со стороны девайсов
https://help.keenetic.com/hc/ru/articles/360014406080-С-чем-может-быть-связано-снижение-скорости-некоторых-мобильных-клиентов-при-работе-в-смешанном-режиме-WPA2-WPA3

лучше акцентироваться на доп. мерах:
1) изолировать wifi клиентов от внутренней сети
2) уменьшать соту/покрытие
3) сделать доп. аутентификацию (мак, в идеале что то более сложное, вплоть до токена или портала аутентификации/captive portal)
https://help.keenetic.com/hc/ru/articles/360000501439-Captive-Portal

• OWE (поддерживается Keenetic) – шифрование открытых сетей без паролей, защита от подслушивания only.
• Покрытие беспроводной сети должно быть минимально необходимым, не заходя за пределы помещения/объекта

Сюда все из IT раздела.

WEP (Wired Equivalent Privacy) – уже через после нескольких лет использования перевод звучит как стеб. Разбирать как он работает нет смысла – его нельзя использовать (если только в качестве honey pot)

Причины: в основном из-за некорректного использования RC4 (должна быть сменяемость ключа постоянная, а не статичный shared ключ, как в WEP), слабости самого RC4, IV используемого в нем - передаваемого plain/text и небольшого по размеру.

The RC4 stream cipher had a number of design flaws and weaknesses. WEP also used a small IV value, causing frequent IV reuse. Lastly, the way that the encryption keys were generated was insecure.

WPA (Wi-Fi Protected Access) – изначально придумывался как временное решение, которое позволит заменить WEP на том же оборудовании, на котором работает WEP, через простую перепрошивку. Тут появился TKIP – temporary key integrity protocol, в нем реализованы новые (по сравнению с WEP) фичи:

• Более безопасный способ генерации ключа (используется и в WPA2)
  • позволил более безопасно реализовать добавление IV (initialization vector) к per packet encryption key (не простой конкатенацией, а применением hash-функции).
  • Pre-shared key не используется напрямую для шифрования трафика – PSK передается PBKDF2 (password-based key derivation function 2) вместе с SSID (как соль для защиты от rainbow table атак) и поверх этого прогоняется HMAC-SHA1 функция 4094 раз

Сам ключ может быть задан напрямую 64-значный 16-и ричный ключ или используя password ASCII 8-63 символа, который прогоняется через PBKDF2. 

• Добавлен sequence счетчик (TSC), для защиты от атак повтора (отброс пакетов, которые непоследовательны)
• 64-битный MIC использовался для защиты от подделки/изменения пакетов
• Большая разрядность ключа (256 бит)

При этом TKIP так же продолжает использовать RC4 алгоритм, но на каждый пакет генерируется свой уникальный ключ, в отличии от WEP.

WPA ввел возможность использовать разные методы авторизаций:

• WPA/WPA2 personal/PSK – на основе PSK
• WPA/WPA2 enterprise – на основе 802.1x. WPA2 enterprise считается самым защищенным вариантом. PMK в таком случае генерируется на основе выбранного метода EAP, например EAP-TLS mutual auth – требует полноценного и правильно реализованного PKI, RADIUS сервера и AP. Обычно в качестве RADIUS сервера для аутентификации используются Microsoft Network Policy Server (NPS), Cisco Secure Access Control Server (ACS) или FreeRADIUS.

WPA2 Enterprise would offer the highest level of security for a WiFi network. It offers the best encryption options for protecting data from eavesdropping third parties, and does not suffer from the manageability or authentication issues that WPA2 Personal has with a shared key mechanism. WPA2 Enterprise used with TLS certificates for authentication is one of the best solutions available.

WPA2 – добавил еще безопасности, во первых он отказался от RC4 в пользу AES (TKIP WPA2 – неполноценный WPA, по сути). CCMP (AES GCM – Counter Mode CBC-MAC Protocol) – он позволил реализовать аутентифицированное шифрование (данные конфиденциальны и аутентифицированы), через механизм authenticate & encrypt.

WPA2 uses CCMP. This utilizes AES in counter mode, which turns a block cipher into a stream cipher.

1. Довольно безопасный стандарт, но все таки его можно взломать в версии PSK через offline bruteforce attack процесса four way handshake. Если атакующий перехватывает все пакеты four way handshake (Nonce и MAC получаются из этих пакетов), то можно brute-force пытаться угадать PMK (см. утилиты типо aircrack). Для защиты нужен хороший пароль + необычный SSID. Для взлома GPU-cloud (прогонять 4094 раз через hash SHA-1 функцию) или ranbow table. Иначе, если SSID какой-то стандартный и предполагается что и пароль стандартный – для 1k top most SSID и 1kk top most password есть таблицы.

Because the SSID is used as a salt, it should be something unique to protect against rainbow table attacks. A long, complex password will protect against brute-force attacks.

Сначала рассчитывается CBC-MAC digest, затем результирующий authentication code шифруется вместе с сообщением, используя блочный шифр (напр. AES в режиме counter, что превращает его в stream cipher, используется seed value с инкрементирующимся counter для создания key stream, который шифруются данные).

Как клиент проходит аутентификацию (four-way handshake).

1. AP отправляет nonce клиенту
2. клиент отправляет nonce AP
3. AP отправляет GTK
4. клиент отправляет ACK

В результате успешной аутентификации (AP понимает, что у клиента есть Preshared Master Key PMK, без непосредственного обмена им) генерируется временный ключ шифрования (Pairwise Transient Key PTK), который будет использоваться для шифрования данных от клиента и к нему. PTK генерируется из многих вещей – PMK, AP nonce, Client nonce (рандомные данные), AP MAC addr, Client MAC addr (конкатинируются и прогоняются через hash). PTK состоит из 5-ти ключей – два ключа для encryption и подтверждения EAPoL, два ключа для отправки/приема integrity check, ключ для шифрования данных (temporal key). Так же AP передает GTK – Groupwise Transient Key (шифруется EAPoL encryption key из PTK), который используется для broadcast/multicast пакетов (поэтому GTK разделяется между всеми клиентами одной сети), он периодично обновляется и переотправляется клиентам (или по событию отключения клиента).

WPS в любой его форме рекомендуют отключать. Скан утилита для проверки что WPS везде выкл – wash.

You should disable WPS entirely if you can. If you need to use it, then you should use a lockout period to block connection attempts after a number of incorrect ones.

WPS бывает не только по кнопке:

• PIN entry authentication
  • клиент генерирует PIN и вводит его на AP
  • PIN зашит в прошивку AP
• NFC/USB
• push-button

Зашитый PIN в прошивку чаще всего ругают в контексте ругани WPS – его легко ломают brute force, причем метод вообще говно т.к. двумя частями отправляется pin (сначала первая часть и если она ок!!!!!!, то вторая). В результате за 11к попыток можно перебрать все варианты (без rate limit можно было взломать меньше чем за 4 часа, пока в спецификации не сделали тресхолд 3 неправильные попытки в минуту, но даже это воркэраунд = 3 дня).

The WiFi Protected Setup (WPS) PIN is susceptible to a brute force attack. A design flaw that exists in the WPS specification for the PIN authentication significantly reduces the time required to brute force the entire PIN because it allows an attacker to know when the first half of the 8 digit PIN is correct. The lack of a proper lock out policy after a certain number of failed attempts to guess the PIN on many wireless routers makes this brute force attack that much more feasible.

Packet sniffing (tcpdump, wireshark, aircrack-ng, kismet)

Port mirroring, RSPAN

Отдельные статьи:

• wireshark
• tcpdump

Обычно это происходит автоматически при запуске инструментов для снифинга, но перехват трафика требует помещение интерфейса в promiscuous (неразборчивый) режим, чтобы сетевая карта не дропала пакеты, которые не предназначены ей. В Wi-Fi карточку так же можно переместить в Monitor mode – она будет слушать даже пакеты в других (не только в подключенном) SSID и на других частотах.

Обновление ПО/системы/драйверов устройств (security updates)

В контексте атак типо OpenSSL heartbleed и множества других подобных проблем с безопасностью софта (например баги с Java, Adobe Flash Player, ОС или даже драйверами устройств) крайне важны инструменты, которые будут уведомлять о новых патчах/новых версиях софта. Зачастую это встроено в антивирусы, но есть и специализируемые инструменты типо Microsoft SCCM, Puppet Labs, которые позволяют изучить какой софт глобально установлен на всех ПК и обновить его при необходимости.

Case1 Уязвимость пару лет назад закрыта, а системы непропатченны - и довольно безопасная по своей архитектуре сеть центра сертификации посыпалась. Центр сертификации закрылся.

Case2 Matrix не обновил вовремя Jenkins и все посыпалось (в header статьи)

As vulnerabilities are discovered and fixed by the software vendor, applying these updates is super important to protect yourself against attackers.
Software updates or patches can fix recently discovered vulnerabilities or close ones that you weren't aware of.

Общая практика – поддерживать работу только последней версии софта и запрещать явно ненужное/разрешать явно нужное. Под последней версией часто подразумевается именно стабильная последняя версия т.к. самая последняя версия может быть с багами.

Разрешенное унифицировано обновлять (унифицировано – чтобы иметь единообразный софт везде, упростив эксплуатацию и уменьшив attack surface). Ограничить использования софта определенной версией/запретить использование определенного софта (blacklist)/разрешить использования определенного софта (whitelist) можно через политики AD. Причем под софтом подразумеваются даже расширения в браузере – которые часто недооценивают в контексте безопасности. Они могут собирать/подменять информацию на сайтах, на которые пользователь ходит, отправлять на удаленные сервера user input и прочее.

• • известная ОС WindRiver на основе Linux, использует далеко не самое свежее ядро
  • могут не обновляться приложения если компания боится, что с апдейтами получит троян

Безопасность в Chrome OS
Under the hood ядро Linux (как и во многих других новых ОС).

Отличительная особенность Crome OS – простота и безопасность:

• Основным приложением является Chrome Browser.
• Chrome browser запускается из под пользователя и не может нарушить работу системы. При этом extension в CromeOS Chrome Browser так же опасны, как и в Chrome Browser на Windows – не нужно ставить непроверенные.
• Большая часть данных пользователя хранится в облаке. Но часть (downloaded files, cookies, bookmarks, caches), для ускорения работы или offline использования – локально. Информация, которая хранится локально, шифруется паролем пользователя + крипто-ключами с TPM (в новых версиях ChromeOS – H1, защита, например, от воровства диска и попытки подобрать пароль на другом устройстве). Так происходит для каждой пользовательской директории – это называется vault.

By having the hard drive encrypted both with the cryptographic device and with the user's password, Chrome OS ensures that the user's data can't be accessed by an attacker.

• По умолчанию все настройки выставлены “безопасными” и не нужно ничего делать – например, апдейты автоматически скачиваются и устанавливаются.

By implementing automatic updates, Chrome OS ensures that security updates are applied on time, keeping the system secure.

• Так же Chrome OS состоит из нескольких уровней безопасности, реализуя модель defence in depth (если один уровень не отрабатывает – есть другие).

Defense in Depth is the concept of having multiple, overlapping systems of defense to protect IT systems. This is exactly what Chrome OS offers.

• Каждый процесс и вкладка Chrome является уникальным процессом, изолированы на уровне ОС от остальных (sandboxing). Исключением является только данные на HDD под эти вкладки/процессы (cookie, cache, bookmarks), причем к данным одной вкладки безусловно не может обратится процесс другой вкладки.

Sandboxing refers to the fact that each tab in a Chrome browser - as well as each of the system services - runs in a separate process, completely independent of the others.

OS Recovery Mode – У Chrome OS простой процесс восстановления, в случае повреждения/изменения системных файлов система входит в режим восстановления и помогает пользователю восстановить ее.

Powerwash – позволяет легко сбросить ОС к заводским настройкам (как телефон), персональные данные восстанавливаются из облака. Причем powerwash стирает ключи пользователей отчищаемой системы из памяти, делая невозможным восстановление данных с ЖД (т.к. они шифруются данными пароля пользователя + ключами с TPM – см. ниже). 

Verified Boot

Verified Boot – проверяет целостность системы при загрузке. Если в с систему были внесены изменения – она не загрузится, вместо этого запустится процесс восстановления. Так же Verified Boot не даст загрузить систему, версия которой помечена как уязвимая.

Verified Boot is a process that verifies the integrity of the operating system being used, from start to finish. So that the user can trust that the contents of the OS come from a reliable source.

Состоит из четырех компонентов:

read-only firmware – прошивка с которой поставляется Chrome OS устройство. Изменить прошивку без физических изменений машины невозможно – прошивка защищена от удаленных атак. В прошивку включаются криптографические ключи, которые проверяет что последующий компонент (read-write fw) при загрузке из доверенного источника и что в последующем компоненте нет лишнего кода. Если проверка завершена успешна – исполняется код из read-write fw, если не успешна – read-only fw попытается восстановить систему из последнего backup read-write fw (предварительно проверив, что он валиден). Если и в backup какая то дрянь – система будет загружена в режиме восстановления (recovery mode).

If the read-only firmware can't validate either of the two versions of the read-write firmware, it will automatically start the Recovery Mode

read-write firmware – прошивка, которая может автоматически обновляться по необходимости. Проверяет непосредственно ОС (ядро ОС из доверенного источника) примерно таким же алгоритмом, что и read-only fw (алгоритм точно такой же – если найдено несоответствие – загружаем другой OS kernel или уходим в восстановление ОС).

If the read-write firmware can't validate either of the two kernels and their root partitions, it will automatically start the Recovery Mode

OS kernel – при загрузке kernel проверит целостность root file system, которую использует. Алгоритм точно такой же – если найдено несоответствие – загружаем другую Root File System или уходим в восстановление ОС.

Root file system – хранит непосредственно данные ОС и пользователя.

Причем Kernel и Root File System хранятся на разных разделах. И их два – read only (который используется при обычной работе), read-write (меняется софтом при обновлениях).

Vulnerability scanners (сканеры на уязвимости)

Vulnerability Management – Системы анализа защищенности и сканеры уязвимостей

VM-решения:

•   Rapid7 InsightVM
•   Qualys VMDR
•   Tenable.sc
•   Tenable.io

Сканеры уязвимостей:

•   Nexpose Vulnerability Scanner
•   Tenable Nessus Pro
•   GFI LanGuard
•   Tripwire IP360

A vulnerability scanner will scan and evaluate hosts on your network. It does this by looking for misconfigurations or vulnerabilities, then compiling a report with what it found.


FROM NESSUS
Today, Nessus is trusted by more than 27,000 organizations worldwide as one of the most widely deployed security technologies on the planet - and the gold standard for vulnerability assessment.

Our research team works closely with the security community to discover new vulnerabilities and provide insights into published vulnerabilities to help organizations quickly detect them in their environment.
More than 100 zero-day vulnerabilities discovered over the past 3 years. New plugins released within 24 hours of vulnerability disclosure (on average)

Nessus has the industry's lowest false positive rate with six-sigma accuracy (*.32 defects per 1 million scans).
Nessus has the deepest and broadest vulnerability coverage in the industry.
Nessus is trusted by more than 27,000 organizations, with 2 million downloads worldwide.

Примерный алгоритм работы:

1. Сканят сеть на хосты с помощью разных способов – ping sweep, port scanning
2. Детальный скан запускается на каждый обнаруженный хост
3. Делается попытка определения сервисов за портами
4. Делается попытка взлома сервисов на основе баз известных уязвимостей  и мисконфигураций (напр. неоптимальные ciphers, пароли по умолчанию. Nessus проверяет как понимаю не реальными атаками, а их моделированием на основе Nessus attack scripting language. Базу с уязвимостями нужно регулярно обновлять (ничего нового), иначе не будет скана на новые уязвимости. 
5. Отправляется репорт для последующего анализа/обработки, который включает уязвимые хосты/сервисы, уязвимости приоритезируются и категоризируются, можно почитать подробно о каждой найденной уязвимости (софтовой баги или даже неправильно настроенного сервиса или даже наличия бекдора в системе), иногда так же есть информация как можно избавится от нее/включается информация о том, есть ли возможность удаленного эксплойта найденной уязвимости и прочая важная информация для анализа.

Пример репорта из Nesus:

Тесты на проникновение (penetration testing)

Тесты на проникновение (penetration testing) – практика попытки взлома системы/сети для проверки корректности работы систем безопасности. Хакеры в белых шляпах. Использование эксплойтов и систем типо hacking linux (kali linux). 

Penetration Testing is the practice of attempting to break into a system or network to verify the systems in place.

Осуществление регулярных pentest и формирование/разбор отчетов по ним не менее важный аспект в безопасности, чем регулярные vulnerability scanning. Позволяет проверить что системы обнаружения/блокирования/логгирования вторжений работают корректно. Сами тесты (как pentest, так и vulnerability scan) могут производится как внутренними сотрудниками ИБ (in-house), так и внешней аудит организацией (third-party testing). Рекомендуют использование одновременно обоих подходов.

Стандарты в области безопасности

PCI DSS (Payment Card Industry Data Security Standard) – пример всеобъемлющего стандарта безопасности, которому нужно следовать, в случае если компания обрабатывает платежи по кредитным картам.

У стандарта 6 основных задач: 

• Построение безопасной сети и систем – например, путем использования файрволов, запрета на использование паролей по умолчанию в системах. К примеру, вплоть до того, что должно быть под контролем на уровне файрвола – запрет на установку соединений из небезопасной сети в системы, которые хранят/обрабатывают данные cardholder (держателей карт). 
• Защита данных cardholder – защита сохраненных данных, шифрование (криптостойкое, с указанием примеров) данных по карточкам при передаче по открытым сетям (включая методы по реализации это передачи), политики по предельному времени хранения данных перед авто-удалением (data retention policies, к примеру, после авторизации платежа не сохранять данные, необходимые для аутентификации платежа, карты, а безопасно удалять их).
• Поддерживать программу по управлению уязвимостями (vulnerability management program) – реализовывать и поддерживать безопасные системы и приложения. К примеру, защищать все системы от вредоносного ПО, регулярно проверять наличие антивирусного ПО на системах (patching), обновлять антивирусное ПО, обновлять ПО (особенно security patches, в пределах месяца после выпуска), иметь логи. Причем интересный факт – в общем случае, чем более важный сервер/сервис для компании, тем менее вероятнее что он будет пропатчен из-за того, что добавление патча зачастую сопровождается прерыванием сервиса и потенциальным влиянием на стабильность и надежность работы приложения.

The more critical the server, the slower it is usually patched. Management might be afraid of interrupting the server or afraid that the patch might affect stability or performance.

• Реализация мер по разграничению доступа (access control measures) – ограничение к данным cardholder политикой business need-to-know (проверяем что доступ к данным действительно нужен), аутентифицировать доступ к системам (пароли, 2FA/MFA), ограничить физический доступ к данным.
• Регулярно мониторить и тестировать сети (regularly monitor and test networks) – отслеживать все попытки доступа к системам/сетевым ресурсам/cardholder data, регулярно тестировать системы безопасности и процессы. Тут помогут системы по логгированию (SIEMS), обнаружению вторжений (IDS/IPS), автоматические сканы посредством спец. утилит на уязвимости (vulnerability scanning utilities, например Nessus, OpenVAS, Qualys), сканы отработки защиты и систем аутентификации на атаки (penetration testing) – все это крайне важно в контексте безопасности. 
• Поддерживать политику по ИБ (maintain an information security policy) – поддерживать политику ИБ, которая относится ко всему персоналу/пользователям систем. Следовать ей должны все сотрудники, не только сотрудники ИБ. Политика должна быть продуманной (well-thought-out), но при этом простой для понимания (и нахождения). Должны быть созданы обучающие программы, которые в деталях описывают политику ИБ.

Privacy Policy

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

Privacy policies are meant to govern the access and use of sensitive data for authorized parties. Sensitive data should be treated with care so that an unauthorized third-party doesn't gain access. Ensuring this data is encrypted is an effective way to safeguard against unauthorized access.

Sensitive data exposure является третим в топ 10 OWASP для WEB applications – очень часто персональные данные хранят/обрабатывают не так, как нужно.

Sensitive Data Exposure. Many web applications and APIs do not properly protect sensitive data, such as financial, healthcare, and PII. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data may be compromised without extra protection, such as encryption at rest or in transit, and requires special precautions when exchanged with the browser.

Cloud security

Облака:

• Теорию можно посмотреть тут
• Решения Huawei по организации облаков на базе их продуктов тут
• Есть так же хороший конспект на git
• Почитать про вопросы облачной безопасности тут
• Вопросы/ответы на HCNA Cloud экзамен тут
• SaaS security позволяет конторолировать SaaS приложения, такие как google drive, one drive

Облачная безопасность, как и традиционная, ставит вопросы защиты критичной информации от воровства, извлечения и удаления данных, приватность.

Cloud security includes protecting critical information from theft, data exfiltration and deletion, as well as privacy.

Большое количество вопросов при сохранении данных в публичных облаках к тому – что вы начинаете доверять облачному провайдеру (не важно какому), что он обеспечивает необходимую защиту ваших данных (shared responsibility client & cloud provider). shared responsibilities (пример описания AWS) зависит от типа используемой cloud модели (IaaS, PaaS, SaaS) – в SaaS вы не отвечаете мало за что, в IaaS за многое. Shared responsibilities подразумевает и разделение вопросов по закрытию уязвимостей ПО и patch management в облаке для моделей IaasS, PaaS. В SaaS за patch management в облаке и уязвимости ПО полностью отвечает провайдер, в отличии от других моделей, где за что-то отвечает клиент.

Division of compliance responsibilities between cloud provider and cloud customer must be determined before any contracts are signed or service is started.












 


 

К примеру, при использовании облаков требуется обеспечение облачными сервисами физической безопасности носителей данных клиентов (СКУД, камеры, физические замки, юридическая ответственность и прочие вопросы). Кроме того, все чаще требуется соблюдение требований регуляторов, под которые подпадают данные клиентов (подобные законы существуют в Europe, USA, Russia, etc).

Примеры атак, которые справедливы для облачной среды:

• Authentication and authorization attacks
• API attacks – использование уязвимостей/небезопасных конфигураций в APU)
• Session/traffic hijacking – перехвата трафика
• DNS phishing attacks – подмена легитимного сайта через изменение DNS записи
• XSS and many web application attacks (for example OWASP TOP 10)
• SQL injection attacks
• CSRF (session riding) attacks
• DDoS attacks
• MiTM attacks
• Side-channel attacks – виртуалка атакующего находится на той же хост машине или максимально приближена к жертве, атакующий пытается использовать эту близость для взлома жертвы эксплуатируя баги изоляции между vm/containers

В контракте письменно провайдер должен подтвердить требования по ИБ, которые вы выдвигаете этому провайдеру. Примеры правильных вопросов облачному провайдеру до подписания с ним договора:

• Кто имеет доступ к облаку
• Какие регуляторные требования у провайдера (могут сильно отличаться от региона к региону)
• Можно ли проводить аудит работы провайдера
• Можно ли проводить penetration testing (pentests) и как их проводить – Penetration testing  в облаке поднимает дополнительные вопросы в сравнении с «классическим» pentest, ответы на эти вопрос зачастую можно найти на отдельной странице облачного провайдера. К примеру, что ты можешь и не можешь делать в этом облаке.
• Какой будет SLA и сколько будет стоить нужный уровень?
• Шифрование
  • Используется ли шифрование при передаче и хранении моих данных? 
  • Какие криптоалгоритмы и их реализации используются?
  • Чьи ключи шифрования используются для хранения/при передаче (провайдера или клиента)?
  • Где хранятся ключи?
• Data classification
  • Разделяете ли вы данные по типу (data classification)?
  • Как особо чувствительные по классификации данные хранятся/обрабатываются/кто у ним имеет досту
• Как мои данные разграничены с данными других людей? На уровне виртуализации или физическом уровне?
• Проводите ли вы тренинги сотрудников? как проводится обучение сотрудников? какую квалификацию они имеют?
• Что будет в случае появления уязвимости у провайдера, которая влияет на сервисы/данные клиента (кто будет ответственным, какие действия будут предприниматься и проч. Будет ли по законодательству провайдер отвечать при взломе.
• Есть ли у cloud provider business continuity и disaster recovery (BCP/DR) планы. Какая реакция будет на подобные инциденты и какие гарантии (и стоимость) при их появлении в продолжении предоставления сервиса/защиты от потери данных.
• Что будет с вашими данными после того, как контракт с cloud provider будет расторгнут (завершен)

Top secret — Cryptologic and communications intelligence
Secret — Select military plans
Confidential — Data indicating the strength of ground forces
Sensitive unclassified — Data tagged “For Official Use Only”
Unclassified — Data that may be publicly released with authorization

Insufficient due diligence is one of the biggest issues when moving to the cloud. Security professionals must verify that issues such as encryption, compliance, incident response, and so forth are all worked out before a contract is signed.

Cisco Cloudlock

Cisco Cloudlock контролирует доступ к облачным приложениям и является DLP решением для облака. Cloudlock – изначально купленная Cisco компания. Это CASB (Cloud Access Security Broker) решение, которое обеспечивает видимость и проверку на соответствие (compliance checks) для защиты от некорректного использования (misuse), вывода данных (data exfiltration, DLP) и защиты от угроз (напр. ransomeware). Cisco Cloud Lock интегрируется с облачными провайдерами типа DropBox, GSuite, Office 365 (O365) и многими другими.

What is the function of Cisco Cloudlock for data security - DLP.

https://www.cisco.com/c/en/us/products/security/cloudlock/index.html#~features The Cloudlock Apps Firewall discovers and controls cloud apps connected to your corporate environment.

• Cisco cloudlock предоставляет composite risk score – уровень риска на основе оценки разных факторов использования cloud app – совокупность business risk, usage risk, vendor compliance.

• На главном dashboard можно увидеть различные аномалии, риски безопасности, активности, гео карту и проч.

• Dashboard по инцидентам – записях о событиях (напр. DLP), объектах, приложениях, которые вызывают (срабатывают на) политики CloudLock. инциденты включают объекты (и зачастую, напр. DLP, содержание объектов), которые подпадают под нарушение, адресную информацию (адреса/доменные имена/платформы/аккаунты). Все действия администратора записываются в логи аудита.

• Инцидент в CloudLock обычно создается когда asset (документ, объект, поле, пост, приложение вызывавшие эвент) который мониторится на платформе CloudLock подпадает под три критерия:
  • Asset создан или изменен
  • Asset мониторится активной политикой
  • Asset нарушается по политике

• Политики можно создавать пользовательские, а можно использовать созданные. Пользовательские политики могут быть разных категорий:
  • Context only – игнорирует контекст, содержащийся в asset и мониторит только как широко asset расшарен, тип файлов и другие метаданные в облачной среде, которую вы мониторите.
  • Custom Regex – мониторит контент asset с использованием вами созданных регулярных выражений.
  • Event analysis – мониторит эвенты платформы, которую вы выбрали. Эвенты отличаются в зависимости от того, какая платформа мониторится. Можно получать сырые эвенты, можно работать с нормализованными – как угодно и с разными комбинациями.

• Возможна интеграция cloudlock с другими продуктами – например с Salesforce. Активности по экспорту таких репортов Salesforce Report Export Activity при этом будут логгироваттся.

Cisco Tetration

Пример продукта Cisco, который реализует облачную безопасность: Cisco Tetration. Функционал крайне широк.

Когда виртуальных машин или контейнеров становится несколько тысяч (например, в Cisco несколько тысяч виртуальных машин и контейнеров используются для обеспечения нашей внутренней работы), то задача статического определения, куда можно, а куда нельзя перемещаться контейнерам и виртуальным машинам, становится неподъемной. Ровно эту задачу – автоматизацию управления виртуальными машинами, контейнерами, приложениями внутри ЦОДа и внутри облака – и решает Cisco Tetration. С помощью специальных алгоритмов он описывает структуру сети, структуру ЦОДа и облака, позволяет прописать и динамически отслеживать правила взаимодействия виртуальных машин, приложений, контейнеров между собой, блокировать их перемещения в неразрешенные места, увязывает это все с политиками доступа внутри корпоративной сети, например, с теми же самыми Cisco ISE и Cisco Stealthwatch, с защитой периметра и дает возможность оценивать уязвимость приложений и виртуальных машин, которые используются в ЦОДе. И опять же динамически, опираясь на информацию об уязвимостях, усиливать или понижать уровень защиты тех или иных корпоративных ресурсов. То есть Tetration – это инструмент, который позволяет сегментировать приложения, виртуальные машины и контейнеры внутри ЦОДа и облаков и делать это динамически.

INDUSTRIAL SECURITY

OT security / SCADA security – Решение для защиты промышленных сетей от угроз. Системы выявления атак в сетях АСУ ТП и нарушений регламентов ИБ.

Популярные продукты:

• •   Dragos Platform
  •   Nozomi Networks Platform
  •   Claroty Platform

Вообще Industrial безопасность (Industrial Control Systems, ICS) стала важным вектором в ИБ и частично это из-за того, что Industrial сети начали реализовывать на базе IP (ICS moving to Ethernet/IP increases threat exposure).

• В США проводятся Hacking class using real world targets!!! Показывали как незащищенны scada системы, без атак их.
• DoS SCADA систем крайне опасен.

IoT security

В целом о IoT читаем тут.

Проблемы безопасности IoT устройств:

• Общая концепция – IoT устройства не должны быть доступны напрямую через Интернет т.к. мы по умолчанию не можем эти устройства защитить средствами, которые в них встроены.
• Строго говоря к IoT безопасности не относится, но основной способ взлома CCTV камер: default пароли, слабые пароли и уязвимости в remote password change механизмах вендора камеры.
• При прямом доступе устройства из внешней сети безопасность IoT устройства организовать сложнее, в сравнении с промежуточным контроллером/fog edge устройством (по сути тот же самый NAT).
• Технологии IoT вроде INSTEON, Zigbee, Z-Wave, LoRaWAN и многие другие не разработаны с учетом безопасности, хотя и были улучшены в этом контексте в сравнении с изначальными реализациями. Например современный, Zigbee полагается на безопасность на основе сервисов безопасности стандарта IEEE 802.14.5 MAC layer, который поддерживает AES шифрование.

IoT technologies like INSTEON, Zigbee, Z-Wave, LoRaWAN and others were not designed with security in mind. (however, they have improved)
Zigbee takes advantage of the underlying security services provided by the IEEE 802.14.5 MAC layer. IEEE 802.14.5 supports AES encryption.

• Большинство устройств сегмента IoT дешевые, крайне ограничены в количестве памяти/вычислительных ресурсах и не поддерживают развивающиеся технологии безопасности/шифрования, бекапы соединений и проч

Numerous IoT devices are inexpensive devices with little to no security capabilities. IoT devices are typically constrained in memory and compute resources and do not support complex and evolving security and encryption algorithms.
Several IoT devices are deployed with no backup connectivity if the primary connection is lost.

• При этом большинство таких устройств требуют безопасное удаленное управление при развертывании и во время эксплуатации

Numerous IoT devices require secure remote management during and after deployment (onboarding).

• Большим вопросом является устойчивость шифрования с учетом, что многие IoT устройства разработаны на десятилетия работы (напр. умные счетчики)

Crypto resilience is a challenge in many IoT environments.
Embedded devices (such as smart meters) are designed to last decades without being replaced.

• Физическая безопасность устройств для IoT девайсов – вопрос который поднимается еще более серьезно в сравнении с “обычными” устройствами

Physical protection is also another challenge, because any IoT device could be stolen, moved or tampered with.

• Для IoT устройств справедливы большинство атак на “обычные” устройства и сервисы, но есть и особые, применимые только к IoT (мультиметры, осцилографы, UART дебагеры и даже паяльник)

Many of the tools and methodologies for hacking applications and network apply to IoT hacking; however, several specialized tools perform IoT 

Еxample of tools and methods to hack IoT devices.
Hardware tools: 
• Multimeters
• Oscilloscopes
• Soldering tools
• UART debuggers and tools
• Universal interface tools like JTAG, SWD, I2C, and SPI tools
• Logic analyzers
Reverse engineering tools, such as
disassemblers and debuggers:
• IDA
• Binary Ninja • Radare2
• Ghidra
• Hopper
Wireless communication interfaces and tools:
• Ubertooth One (for Bluetooth hacking)
• Software-defined radio (SDR), such as HackRF and BladeRF, to perform assessments of Z-Wave and Zigbee implementations

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

IoT devices often require the management of multiparty networks. Governance of these networks is often a challenging task. For example, who will accept liability for a breach? Who is in charge of incident response? Who has provisioning access? Who has access to the data?

• Administrations should pay attention to how the IoT device authenticates to multiple networks securely.

• несанкционированный доступ к медицинскому оборудованию – одно из самых опасных в контексте IoT безопасности. Cisco видит решение в обеспечении безопасности еще “до” этих потенциально уязвимых устройств в случае стационарных усройств – через создание изолированного сегмента в котором эти устройства работают, в который нет доступа почти никогда и даже когда есть, строго определенным хостам и протоколам (как в органах власти и гос компаниях). Ограничение предполагается делать на базе Cisco Firepower/ISA 3000. В случае нестационарных, думаю, реализуемо аналогичное.

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

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

Для защиты периметра сегментов, где установлены интернет-вещи, мы используем традиционные Cisco Firepower. Для агрессивных сред, в которых устанавливается промышленное или медицинское оборудование, используются наши специализированные промышленные файерволы или промышленные системы обнаружения атак под названием ISA 3000.

Точки входа хакера в компанию/enterprise, пример

Пример политики безопасности для небольшой компании

Authentication system

• Для аутентификации на компьютерах нам нужна централизованная система аутентификации на основе LDAP, например такая, как ActiveDirectory совместно с вводом кода из программного/аппаратного токена (2FA/MFA)
• Для аутентификации на сетевых устройствах не обязательно разворачивать RADIUS сервер т.к. сетевых устройств в компании немного. Достаточно организовать доступ на оборудование по локальной учетной записи только для администраторов с помощью SSH/HTTPS на базе аутентификации паролю и/или приватному ключу.
• Использовать дополнительную аутентификацию по учетной записи к базе SQL, в которой хранятся пользовательские данные.

External website security

• Для шифрованного обмена данными между сайтом и клиентами для доменного имени сайта будет получен SSL сертификат (HTTPS)
• Сервер с сайтом будет находиться в dmz зоне firewall за reverse proxy:
  • DMZ позволит разграничить внешний сайт от других внутренних ресурсов компании и при этом наложить ряд ограничений для взаимодействия извне с самим сайтом (анти-дос)
  • Reverse proxy позволит реализовать решение по отказоустойчивости и балансировке нагрузки для сервера с сайтом (прокси необходим т.к. ретейл – основной бизнес компании)

Internal website security

• Для доменного имени внутреннего сайта будет сгенерирован собственный SSLсертификат
• Внутренний сайт будет находиться внутри сети компании (за firewall)
• Внешний доступ к внутреннему сайту будет ограничен использованием private адресации для внутреннего сайта

Remote access solution

• Для remote-access клиентов нужно попасть во внутреннюю сеть (vpn решение на базе firewall или reverse-proxy за firewall) для взаимодействия с внутренним сайтом и другими внутренними ресурсами компании
• Аутентификация в VPN/reverse proxy на основе логина+пароля/сертификата и программного/аппаратного токена (2FA/MFA)
• Для доступа на ПК администраторов из под поднятого VPNможно поднять RDP

Firewall and basic rules recommendations

• Использовать по умолчанию implicit deny
• Использовать firewall в качестве remote-access VPN server
• Включить stateful firewall для доверенной зоны
• Ограничить доступ к сетевым устройствам, LDAP серверу и SQL серверу, хранящему данные пользователей, только подсетью администраторов

Wireless security

РеализоватьWPA2 enterprise (AES GCM encryption + 802.1x RADIUS authentication)

VLAN configuration recommendations

Создать VLAN и подсети в соответствии с группами пользователей

Laptop security configuration

• FDE иintegrity check на базе TPM
• На компьютеры должны распространяться корпоративные политики AD, касающиеся безопасности (подробнее ниже)

Application policy recommendations

• Обновление приложений
• Отключение и удаление ненужных приложений
• Ограничение доступа к приложениям с помощью политик, например RBAC
• Создавать backupвсех важных данных
• Использование наилучших практик с точки зрения программирования (например. использование поддерживаемых версий языков/библиотек/модулей, изоляция переменных, проверка и чистка пользовательского ввода от спец. символов, уменьшение количества кода путем его переиспользования с помощью функций, так далее)

Security and privacy policy recommendations

• Логгирование/разграничение доступа к данным клиентов
• Отключить административные права для обычных пользователей
• Политики по паролям (длина, спец символы, словарные слова, ротация)
• Использовать корпоративный антивирус/binary whitelisting и host-based файрволл/ips
• Регулярные тесты на уязвимости и проникновение
• Регулярные обязательные обучения персонала по темам ИТ-безопасности

Intrusion detection or prevention for systems containing customer data

Внедрить системы NIDS/NIPS, HIDS/HIPS для анализа трафика сотрудников внутри сети компании. Настройка систем в случае обнаружения угроз (атаки, вирусная активность, неавторизованный скан сети) – уведомление администраторов, ограничение доступа, карантин определенных систем.