К основному контенту

Пять фактов о безопасности в 2021

 


В "ковидные времена" многие ушли на удалённую работу и вместе с тем, медленно и незаметно, в течение 2020 года сильно возросли риски информационной безопасности для компаний и организаций (будь то общеобразовательные, медицинские или муниципальные учреждения) в их инфраструктуре, программных и аппаратных средствах. Этот тренд будет только расти, и об этом уже показательно заявляют самые известные люди в среде информационной безопасности и защиты информации, такие как Евгений Касперский (статья).

Как это может заботить обывателя? Вообще то, целью злоумышленников, как правило, являются как раз таки обычные люди, занимающие "посты" на предприятиях, работающие с оборудованием или программным обеспечением. Поэтому, от того как защищены мы (или, насколько мы соблюдаем меры безопасности), заивисит как наша с вами безопасность, так и безопасность целых компаний, организаций и людей. Крайне важно обеспечить свою личную защиту даже находясь дома и работая или учась удалённо.

Ниже я приведу несколько фактов об информационной безопасности, которые являются довольно известными для специалистов, но врядли так очевидны для обывателя. Я привожу эти факты для того, чтобы читатель мог чуть глубже понять как работают средства обеспечения информационной безопасности и почему всё бывает так "сложно". Надеюсь, эти факты станут пищей для размышлений, заставят немного больше "погуглить" и сделать соответствующие действия для своей безопасности в непростое время:

  1. Невозможно сделать невзламываемое шифрование. Иначе говоря, любой шифр можно взломать. Именно поэтому криптография, наука о шифровании, фокусируется на способах защиты от так называемого "прямого перебора", при котором шифр можно взломать просто перебрав все возможные кобминации цифр и/или букв в наборе.

    Для примера, совеременные компьютеры способны перебрать ваш PIN код кредитной карты, состоящий из 4 цифр от 0 до 9, за меньше чем секунда. Именно поэтому нам не дают ввести код более чем 3 раза, после чего блокируют ввод. Этот, и множество других способов защиты от прямого перебора, попросту делают этот процесс либо слишком дорогим, либо слишком долгим.

    Если вы являетесь разработчиком, то вам следует постоянно следить за обновлениями фреймворков и библиотек, чтобы избежать наличия в них "дыр", которые позволят обойти защиту от прямого перебора. Например, вы не должны использовать алгоритм шифрования 3DES в ваших программах, а я знаю что огромное количество библиотек и API всё ещё используют именно его. Давно существует AES/Rijndael, который подтвердил свою стойкость, по крайней мере на данный момент 2021 года.

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

    Пароли на сайтах не должны храниться в открытом виде, думаю, это знают все. Но не все следят за тем, чтобы использовать последние доступные алгоритмы хэширования, такие как SHA256 или bcrypt/scrypt вместо MD5, SHA1 или SHA2.


  2. Никто не заботится о безопасности, пока беда не настигает. Если вы отвечаете за IT инфраструктуру предприятия, то не будьте слишком наивными, постарайтесь избежать паттерна "героя" и убедить начальство в необходимости аудита и привлечения сторонних специалистов для обеспечения настоящего периметра информационной безопасности. "Белые" хакеры (white hat) - это официальные компании и люди, которые могут помочь вам найти пробелы и уязвимости, слабо продуманные места, заглянуть в те уголки, о которых вы давно забыли, так как "глаз замылился". Мы все люди, и невозможно уследить за каждой деталью быстро развивающегося предприятия.

    К примеру, ваша инфраструктура давно должна использовать последнюю доступную версию TLS для подключения к сайтам компании через HTTP(S): и эта версия должна быть выше, чем TLS 1.0 или TLS 1.1. К сожалению, я всё ещё вижу многие сайты на HTTP, либо на HTTP(S) с неподтвержденными и "протухшими" сертификатами. Последние версии браузеров просто не дадут вашим клиентам войти на сайт, так что вы теряете не только в защите, но и в прибыли.

  3. В большинстве случаев, самым слабым звеном оказываются люди. 

    • Пароли на бумажках, раскиданных по офису. 
    • Случайно "улетевшие" номера телефонов, адреса, ключи и подписи в Instagram.
    • Копии персональных документов, как паспорта и контракты, прямо в социальных сетях с публичным доступом.

     Это малая доля примеров, которые я лично знаю и вижу почти каждый день. Просто проверьте себя на "вшивость" прямо сейчас по этим пунктам. Вполне вероятно, что вы найдёте о себе что-то "интересное".

  4. Безопасть это не только о шифровании. На самом деле, шифрование это довольно узко употребимая деталь, о которой не обязательно знать обывателю. Как я упомянул выше, создать невзламываемый шифр нельзя, поэтому всё прятать совсем не обязательно и даже вредно.

    Так называемые, Open Source программные продукты давно зарекомендовали себя как вполне стабильные. Хотя и в них регулярно находятся уязвимости, но таковые есть и в "закрытых" проприетарных продуктах, просто мы не обо всех знаем. Приходится обновлять и следить за безопасностью ЛЮБОГО, хоть открытого, хоть закрытого ПО.

    В Open Source ПО есть один замечательный плюс: специалист может удостовериться в том, что там есть и чего там нет, а также, при достаточной квалификации, может доработать продукт. В этом вся разница. Но это настолько неочивдная и не всем доступная опция, что я бы пренебрёг ею. Выбор ПО для защиты инфраструктуры должен делаться не исходя из его открытых или закрытых исходников, а исходя из вашей возможности его поддерживать и обновлять с точки зрения финансовых и временных затрат.

  5. Недостаточно использовать последние версии Linux. На самом деле тут и тут детально описано, как сделать Linux безопаснее и почему по умолчанию он "то ещё решето".

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

Оставайтесь в безопасности!

Picture taken from open source assets

Комментарии

Популярные сообщения из этого блога

Делаем себе бесплатный VPN на Amazon EC2

Читать этот пост в Telegraph. Другие посты в канале в Telegram. Кто только не расписывал уже пошаговые инструкции по этой теме. Однако, время идёт, ПО меняется, инструкции нуждаются в обновлении, а люди в современной России всё больше нуждаются в применении VPN. Я собираюсь описать все шаги для создания бесплатного сервера на Amazon EC2 с операционной системой Linux и необходимые команды для настройки VPN сервера на нём. Чтобы не повторяться о деталях, которые были много раз описаны на русскоязычных и англоязычных ресурсах, по ходу статьи я просто приведу целую кипу ссылок, где можно почерпнуть необходимую информацию, а где информация устарела - опишу подробнее что нужно сдеать. В итоге, сервер будет доступен для вас из любой точки планеты, с любой операционной системы, и бесплатно (с определёнными ограничениями по трафику). Шаг первый - Регистрируемся на Amazon AWS Нужно зайти на сайт https://aws.amazon.com/ru и сразу перейти к Регистрации, нажав одноимённую кнопку. При р

В помощь программисту: инструкции по работе с Ubuntu сервером

Программистам чаще приходится писать код и заботиться о его чистоте, правильных абстракциях в коде, корректных зависимостях и прочих сложностях профессии. При этом, настройка и обслуживание серверов, хоть и связанная область - это отдельный навык, необходимый не каждому, и помнить о котором в деталях сложно. Поэтому, я делаю ряд микро-инструкций, которыми буду пользоваться и сам, когда необходимо. Это не статьи, а пошаговые помощники, которые я буду дополнять и наполнять по мере надобности. Делаем бесплатный VPN на Amazon EC2 Создание ключей SSH Подключение к серверу через SSH Передача файла с Linux сервера наWindows машину Делаем VPN сервер на Ubuntu 20.04 используя OpenVPN и EasyRSA  Отображение GUI с Linux сервера на Windows машине

Выбираем все плюсы из трех парадигм Entity Framework

Между парадигмами разработки с Entity Framework (Code First, Model First, Database First) я выбрал промежуточную, потому что ни одна меня не устраивала полностью. В Code First меня радуют чистые POCO классы, но не устраивает невозможность моделирования базы. В Database First и Model First мне не нравится генерация EDMX и другого всего лишнего. Таким образом, я нашел для себя такое решение: 1. Я моделирую схему в любой удобной программе (тут любая внешняя программа моделирования, генерирующая SQL Server-совместимые скрипты генерации базы) Рис. Смоделированная схема БД. 2. Создаю базу в SQL Management Studio 3. Делаю Reverse Engineering базы в POCO классы (как в Code First) с помощью плагина Entity Framework Power Tools Рис. Установленный плагин для Reverse Engineer. Рис. Вот так делается Reverse Engineer базы данных в POCO классы. Рис. Результат генерации POCO классов на основе базы данных: папочка Models с готовым контекстом, классами объектов и маппинг-классами.