Как мы инструктируем наших сотрудников, чтобы защитить себя от Heartbleed?

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

Масштабы ущерба, вызванного ошибкой, до сих пор в значительной степени неизвестны, большая часть ущерба была потенциально нанесена в прошлом и будет продолжать оказывать влияние на Интернет в течение длительного времени. Мы просто не знаем, какие секреты были украдены, когда и кем.

Например: Google OpenSSL сердце кровоточит в течение года. Неизвестные противники собирают серверы и ищут интересные секреты - опять же, у нас нет возможности узнать, сделали ли они это или нет - пока они не найдут учетную запись, принадлежащую кому-то с авторизованным доступом к другой системе, например, Twitter.com или AnyBank. co.uk или dev.redhat.com. Имея доступ к таким учетным записям, они потенциально могут продолжать копать, получать доступ к другим системам, наносить другой ущерб (видимый или нет), еще больше скомпрометировать другие учетные записи - и никто не будет подозревать о происхождении нарушения. На данном этапе вы уже далеко от истекающих кровью серверов OpenSSL, и это одно из самых неприятных последствий Heartbleed. К этому следует добавить риск компрометации закрытых ключей серверов.

Укрепление доверия занимает много времени и может быть быстро потеряно. Я не говорю, что у нас не было проблем с доверием в Интернете, но Heartbleed определенно не помог. Восстановление ущерба займет много времени, и понимание этого является частью понимания того, как вы можете защитить себя и своих сотрудников / клиентов / боссов и т. Д. - и как вы не можете. Есть некоторые вещи, которые вы можете контролировать, чтобы ограничить подверженность уязвимости, и есть вещи, которые вы не можете контролировать, но они все равно будут влиять на вас. Например, вы не можете контролировать, как все остальные решают отреагировать на эту уязвимость - АНБ, как сообщается, обнаружило ошибку, но молчал. Это было довольно плохо для всех нас, но у нас не было способа защитить нас от этого.

Как пользователь интернета вы можете и должны:

• Понять, насколько плоха ошибка
• НЕ отвечайте на / переходите по ссылкам в электронных письмах, сообщающих вам, чтобы сбросить пароль - вместо этого зайдите на сайт компании / организации напрямую и активно сбросьте свой пароль. В такие времена мошенники любят заниматься фишингом
• Проверьте свой телефон Android на Heartbleed. Есть приложение от Lookout Mobile Security, которое проверяет вашу версию OpenSSL.

• Проверьте сайты, которые вы посещаете на предмет Heartbleed (неполный контрольный список):

  1. Использует ли сервер OpenSSL?

     • Нет: на вас это напрямую не влияет (эта ошибка). Продолжайте использовать сайт, но измените свой пароль, если другой сервер, прямо или косвенно затронутый этой ошибкой, имел доступ к вашему паролю. Это предполагает, конечно, что все такие серверы в этой сети были исправлены, выпущены новые сертификаты... и т. Д.
     • Да: перейдите к 2.

  2. Находится ли сервер в версии OpenSSL без сердечных сокращений? Удостоверьтесь, что инструмент check-for-heartbleed действительно проверяет уязвимость, а не заголовок HTTP или какой-либо другой "индикатор".

     • Нет: не передавайте никаких секретов на сайт, но, если возможно, отправьте заметку веб-мастеру.
     • Да: перейдите к 3.

  3. Была ли в предыдущей версии OpenSSL Heartbleed?

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

Здесь мы возвращаемся к доверию: когда вы теряете чье-то доверие, это плохо. Особенно, если этот кто-то является вашим пользователем / клиентом / начальником. Чтобы восстановить их доверие, вы должны начать строить снова и открыть для диалога.

Вот что веб-администратор может опубликовать, чтобы начать это:

• Предыдущие версии OpenSSL (уязвимы / не уязвимы)
• Текущая версия и когда она была обновлена

И если предыдущая версия OpenSSL была уязвимой:

• Когда был создан текущий сертификат SSL
• Подробное описание того, как старый сертификат был отозван
• Гарантия того, что новый секрет был использован для нового сертификата
• Предложения для пользователей на основе вышеуказанной информации

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