Нуб по безопасности? 🔐 Рекомендации для разработчиков 🧑💻👨🏾💻👩💻
Звучит немного скучно, и часто это выяснение и исправление этих вещей, это также самое важное из соображений, и его часто оставляют напоследок, когда вы создаете новый продукт или услугу.
Если вы не на вершине безопасности и есть серьезное нарушение, вы рискуете стать корпоративной охотой на ведьм и потерять работу. Вы также рискуете потерять контракты и, возможно, даже стать банкротом, если вам придется выплатить компенсацию за потерянный бизнес, сбой или кражу, список можно продолжить. Слишком часто деловые люди предполагают, что страховка покроет это, а технические специалисты не думают о последствиях для бизнеса.
Я говорю вам сейчас, страховая, вероятно, не покрывает это. Кроме того, никто не хочет потерять работу из-за чего-то подобного, верно?
Итак, о чем следует помнить, когда речь заходит о безопасности? Ничего, мы просто оставим это, пока специалист по тестированию на проникновение не вернется и не расскажет нам?
Ну нет… вы должны были обдумать все эти вещи задолго до этого момента.
Тестирование на проникновение 🧪
Что охватывает тестирование пера? Что ж, это, конечно, не исчерпывающий список… но обычно он охватывает следующее: аудит безопасности и сопоставление сети, сканирование уязвимостей, анализ пакетов, атаки «Человек посередине», атаки грубой силы.
Я не говорю, что вы должны попытаться выполнить узкоспециализированную работу пен-тестера, который обучается годами и имеет много конкретных знаний. Но знание некоторых инструментов, методов и распространенных ошибок может действительно помочь. Также невозможно ожидать, что кто-то за пару дней проведет какие-то тесты и будет иметь абсолютно тщательный подход к обнаружению всех возможных уязвимостей, которые у вас могут быть. Многие из них требуют постоянного тестирования и проверки, поскольку природа кибербезопасности — это действительно повседневное требование, а не разовое событие. Это также ОГРОМНАЯ область, и я никак не могу отдать ей должное.
Если вы сомневаетесь, обратитесь к специалисту по безопасности.
Аудит безопасности и сопоставление сети
Если вы хотите почувствовать, что работаете в «Матрице», вам нужно подумать о сопоставлении сети и инструменте для аудита безопасности вашей системы, таком как Nmap.
Если у вашей команды есть возможности, я бы порекомендовал вам рассмотреть возможность запуска решения, такого как Nmap, через регулярные промежутки времени, чтобы определить состояние прослушивающих служб в вашей системе. Который бесплатный и с открытым исходным кодом. Запускается неавторизованная программа? Настроил ли злоумышленник демона (фонового процесса), чтобы разрешить себе доступ к одной из ваших систем?
Это не интуитивно понятно, но вполне может стоить хлопот в зависимости от вашего уровня подверженности риску и отсутствия специализированных ресурсов.
Краткое руководство по NMap здесь:
и тут…
https://nmap.org/book/nmap-overview-and-demos.html
Сканирование уязвимостей
Инструменты сканирования, такие как Nessus, сканируют системы, чтобы предоставить тестировщику на проникновение список потенциальных векторов атаки для получения доступа к целевой сети или системе. Nessus — это коммерческий продукт, но у него есть бесплатный уровень. Если вы заинтересованы в работе в области кибербезопасности, то это может быть хорошим бесплатным инструментом для начала.
https://www.tenable.com/products/nessus
Анализ сети
Сниффинговая атака или снифферная атака в контексте безопасности сети соответствует краже или перехвату данных путем перехвата сетевого трафика с помощью сниффера (приложения, предназначенного для перехвата сетевые пакеты). Когда данные передаются по сети, если пакеты данных не зашифрованы, данные в сетевом пакете могут быть прочитаны с помощью сниффера. [1] Используя приложение сниффера, злоумышленник может проанализировать сеть и получить информацию, чтобы в конечном итоге вызвать сбой или повреждение сети, или чтение сообщений, происходящих в сети.[2]”
Очевидные способы защиты от атак с перехватом пакетов — убедиться, что вы используете безопасные протоколы и шифрование: HTTPS, SSH, VPN, убедитесь, что ваш сетевой трафик зашифрован. Инструменты сетевого мониторинга и сканирования должны быть настроены для проверки, чтобы предупредить ваши команды о возможных злоумышленниках.
Не позволяйте вашим разработчикам входить в рабочие учетные записи любого типа через общедоступные интернет-соединения. Звучит очевидно, но я видел это в мире стартапов… им следует использовать VPN для работы из дома. Опять же, это звучит очевидно.
Обнюхивание сети, по сути, перехватывает и регистрирует трафик или эти аномалии. Чтобы провести аудит вашей сети и проверить наличие вредоносных уязвимостей, вам понадобится такой инструмент, как Wireshark.
Человек посередине атакует
Для оптимального подхода к смягчению атак «Человек посередине» вы должны учитывать следующее:
Надежное шифрование WEP/WAP на точках доступа
Надежные учетные данные для входа в маршрутизатор
Виртуальная частная сеть
Принудительно HTTPS
Аутентификация на основе пары открытых ключей
Такие продукты, как BurpSuite, — это инструменты, которые многие пен-тестеры используют для проверки уязвимостей. Тем не менее, есть много бесплатных альтернатив их услугам.
Атаки грубой силы
«В криптографии атака грубой силы состоит в том, что злоумышленник вводит множество паролей или фраз-паролей в надежде в конечном итоге правильно угадать комбинацию. Злоумышленник систематически проверяет все возможные пароли и парольные фразы, пока не найдет правильный».
Как вы смягчаете это? Что ж, некоторые общие рекомендации, которые должны быть в вашем списке требований к безопасности паролей.
Ограничение количества неудачных попыток входа в систему.
Сделайте пользователя root недоступным по SSH, отредактировав файл sshd_config.
Не используйте порт по умолчанию, отредактируйте строку порта в файле sshd_configfile.
Использовать Captcha — (полезно для защиты от DDoS-атак, но имеет свои уязвимости).
Ограничить количество входов в систему указанным IP-адресом или диапазоном.
Двухфакторная аутентификация (лучше трехфакторная).
Уникальные URL-адреса для входа.
Отслеживайте журналы сервера на наличие аномалий.
Последнее, что я бы добавил к этому, — это состояние сеанса. Убедитесь, что если ваш пользователь не выходит из системы, срок его сеанса истекает. Я заметил, что это пропущено несколько раз, особенно в веб-приложениях стартапов, потенциально раскрывающих их клиентов. Чтобы получить полное изложение этого, прокрутите вниз до раздела состояния сеанса на странице OWASP. (Их серия шпаргалок по вопросам безопасности очень тщательна).
https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html
Вы можете использовать такие инструменты, как John the Ripper, для проверки паролей на уязвимости.
Итак, мы рассмотрели кое-что из того, что должен охватывать тестер на проникновение, но что мы должны учитывать в нашей повседневной работе по разработке? Прежде чем мы наймем этого пентестера и повесим головы от стыда перед списком ужасов, которые могут вернуться? Что ж, есть несколько передовых подходов и соображений, которые я начал перечислять ниже со ссылками на ресурсы и людей, более осведомленных, чем я.
Управление секретами 🤫
У вас есть политика? Что вы собираетесь делать, когда один из вашей команды уйдет? В день отъезда у них больше не должно быть доступа к вашим системам и службам. Большинство крупных организаций покрывают это, но потом вы слышите историю о том, что разработчик имеет доступ к репозиторию Github компании... 🙄
Но поразительно, насколько это просто, и истории о том, что об этом забывают, заставят вас съежиться.
Различие между секретами и идентификаторами — поставщики облачных услуг делают это с помощью различных инструментов, AWS использует продукты хранилища параметров (коды лицензий, строки базы данных, полные конфигурации и пароли) и диспетчера секретов (пароли и ключи API). Для идентификаторов AWS имеет управление идентификацией и доступом, чтобы ограничить доступ к службам для определенных сценариев (у других облачных провайдеров есть что-то подобное). Создание и идентификация ролей для конкретных разрешений пользователей, по сути, установление круга доверия между этими отношениями. Но это также принципы разделения, и их следует учитывать независимо от сложности вашего решения.
Шифровать данные с помощью KMS 🔑
Вы должны иметь возможность шифровать целые файлы с помощью ключа шифрования и отдельные фрагменты данных в этом файле с помощью другого ключа шифрования. Таким образом, вы будете делиться только определенными частями данных, не рискуя остальными данными. Это ограничивает радиус любой потенциальной атаки. У большинства облачных провайдеров есть решения для этого. Подробнее о решениях AWS можно прочитать здесь.
Часто меняйте секреты
Секреты могут быть просочены через журналы и данные кеша. Их можно использовать совместно для целей отладки, а не изменять или отзывать после завершения отладки. Это довольно очевидно раскрывает уязвимость для хакеров. Ротация секретов — простое решение для этого. В таких продуктах, как AWS Secrets Manager, можно установить расписание. Но это снова хороший базовый принцип, и у вас должна быть политика для этого с точки зрения того, как вы управляете своими системами и службами. То же самое касается автоматизации паролей для доступа к системам и управления ими. Здесь важны готовые решения. Я видел, как разработчики пытались создать свои собственные индивидуальные решения... 🤦♀️ Пожалуйста, не делайте этого, если у вас действительно нет подавляющего варианта использования.
Клиентоориентированность
Для веб-приложений и мобильных приложений, предназначенных для клиентов, вы можете рассмотреть такие продукты, как AWS Cognito, который обеспечивает безопасную интеграцию входа в систему через учетные записи социальных сетей.
https://aws.amazon.com/cognito/
Храните секреты ответственно 🤐
Управление паролями должно обеспечивать создание паролей с использованием стандартизированных продуктов управления секретами (см. выше). Любое совместное использование паролей должно осуществляться с использованием одного и того же инструмента через токены с истекающим сроком действия.
Обнаружение несанкционированного доступа ⛔️
Что ж, кибербезопасности есть что рассказать, каждый конкретный тип атаки — отдельная тема. В этой статье я затронул лишь некоторые из наиболее распространенных. Тем не менее, внедрение SQL действительно является одним из наиболее распространенных типов.
Атаки путем внедрения SQL-кода
Итак… что это такое и как их предотвратить? Что ж, Меган Качановски проделала гораздо лучшую работу, чем я когда-либо буду описывать здесь. Я предлагаю вам прочитать ее статью.
DevSecOps
Типичный код рабочего процесса DevOps — зафиксировать — собрать и настроить — проверить и протестировать — выпустить — развернуть.
Здесь явно чего-то не хватает?
Ну, его безопасность, и в результате этого родился DevSecOps. Ключевые компоненты DevSecOps приведены здесь:
Короткий итеративный жизненный цикл разработки программного обеспечения со встроенными автоматическими проверками безопасности.
Повторяющиеся среды разработки с однородными элементами управления безопасностью.
Конвейер непрерывной интеграции с контролем версий.
Процесс внесения изменений в указанные конвейеры в масштабах всей организации или команды для облегчения расследований безопасности после инцидентов.
Надежная документация, желательно с использованием декларативных методов, обеспечивающих безопасность как код.
Культура поощрения инноваций и терпимости к сопровождающим их неудачам.
Вы можете прочитать больше о различиях и о том, как они сочетаются друг с другом здесь. 👀
Интересно, что это не было стандартом де-факто раньше, если честно.
Если вы читаете это и думаете 💭 «Я до сих пор не знаю, что такое DevOps», то, возможно, вы захотите пройти краткий курс, любезно предоставленный Freecodecamp ниже, или… возможно, вы попали не на ту страницу? В этот момент, почему ты все еще здесь? 🤔
DevOps: вводное руководство
Чтобы получить исчерпывающее краткое руководство по безопасности для разработчиков, вам нужно посмотреть Nanna Baars — Security for Developers. Многие из них все еще очень актуальны, несмотря на то, что они были записаны в 2018 году. Он является одним из основателей и ведущих разработчиков проекта с открытым исходным кодом Web Goat, который представляет собой учебный инструментарий для изучения безопасности веб-приложений. После того, как вы посмотрели его презентацию, вы можете проверить WebGoat.
Многие примеры, которые он приводит, — это вещи, которые каждая команда должна рассматривать как часть своего SDLC, и они действительно являются лучшими практиками для обеспечения безопасности.
WebGoat 🕸 🐐
Основы безопасности веб-приложений
Гуру архитектуры решений практически для всего — Мартин Фаулер. Это было написано несколько лет назад, но до сих пор очень актуально. Я предлагаю прочитать 📖 и действительно следить за блогом Мартина Фаулера в целом, который бесконечно полезен.
Начало криптографии и не только
Безопасность сейчас является одной из самых больших забот руководителей бизнеса. Киберпреступность взорвалась с началом пандемии коронавируса.
Стартапы, возникшие в этом пространстве, неизменно бесполезны. На каждое добросовестное инновационное решение приходится много шумихи и мало реальной защиты от все более изощренных преступников.
Безопасность также является сложной областью для изучения и работы. Вы должны быть заинтересованы в решении проблем, которые вы должны найти и найти. Чтобы быть заинтересованным и мотивированным таким образом, требуется особое мышление. Кроме того, на обучение уходят годы, и она является узкоспециализированной. Это также то, что увеличивает зарплаты, но для тех, кто заинтересован и мотивирован, это действительно может стать увлекательной карьерой и хорошим комфортным доходом. Нехватка навыков не исчезнет в ближайшее время. Может стать только хуже, чем лучше.
Независимо от уровня вашего интереса, знание этого даже базового знания не только сделает вас более ценным членом команды, но и может спасти чей-то бизнес, репутацию и много бессонных ночей.
Чувствуете себя в безопасности сейчас? Поверьте мне, я архитектор. 👩🏻🔧
