Действия после уязвимости
Чтобы защитить виновных, я буду избегать имен...
Я знаю сайт, который прошлой ночью пошел вниз. Вроде, как бы, что-то вроде. В течение примерно 5 часов все запросы к этому сайту asp.net производили YSOD. Изложенные сведения включали тег олицетворения, показывающий, что сайт работает под учетной записью администратора, и включали пароль. Этот конкретный сайт принимает личные данные и данные кредитной карты для 10K+ человек в год.
Здесь много очевидных проблем, самая большая из которых, что учетные данные были выставлены в течение 5 часов. Во-вторых, они запустили этот веб-сайт с учетными данными администратора, которые знают, как долго. В-третьих, они выкладывают экраны YSOD на публику в ситуации ошибки.
Если бы вам было поручено работать с этим клиентом, чтобы помочь решить эту проблему, снизить риск и определить масштаб потенциального компромисса, что бы вы предложили сделать? Я думаю сказать им, что они должны...
- нанять стороннюю консалтинговую фирму по безопасности, чтобы провести тщательный аудит сервера, истории запросов и других элементов, чтобы определить, на каком уровне произошел какой-либо компромисс.
- Они должны на самом деле перейти на другой сервер
- Восстановите код из исходного источника, а не копию того, что было на сервере
- рассмотрите возможность уведомления клиентов, чьи кредитные карты находятся под угрозой, в случае обнаружения признаков подделки
Хозяин заявил, что они не хранят номера кредитных карт, но я утверждаю, что если было совершено так много основных ошибок, вы не можете доверять тому, что они говорят. Они могут думать, что не хранят номера карт, но это не значит, что они не делают это случайно.
2 ответа
Вам поручено "работать с этим клиентом"... но вы не говорите за что. Исправить их применение? Установить новые компьютеры? Подметать полы?
Если вам нужно решить эту конкретную проблему, с которой вы столкнулись, прежде всего сервер должен быть немедленно отключен и перестроен с нуля на другом сервере. Этому серверу больше нельзя доверять. И вы можете определить, был ли он взломан или нет, оставив все на старом сервере нетронутым, но в автономном режиме.
По закону они могут быть обязаны уведомлять пользователей о том, что они пострадали от нарушения, если оно действительно произошло. Если вам самим не хватает ресурсов, чтобы определить, произошло ли нарушение, наймите стороннего консультанта, чтобы определить это.
По крайней мере, кажется, что в их файле web.config есть неверные настройки. Эти подробные сообщения об ошибках должны выдаваться только локально, а не удаленно. Они также могут иметь debug="true" ON, который НЕ ПРАВИЛЬНО в производстве. Их приложению больше нельзя доверять.
Что, черт возьми, YSOD?
Позвольте мне предвосхитить мой ответ, сказав, что это основано на моем понимании того, что нарушение имело место и что преступление, вероятно, было совершено. С этим сказал...
Все вышеперечисленное уместно, однако вам следует переместить элемент "сторонней охранной компании" в пункт после действия и заменить его на "связаться с правоохранительными органами (ФБР?), Чтобы начать расследование". Я не юрист, но это кажется благоразумным, если не обязательным, учитывая, что они занимаются коммерцией.
Утверждение, что они обрабатывают, но не хранят номера кредитных карт, не имеет никакого отношения к связям с общественностью. Если они что-то обрабатывают, это помещается в память. (Не берите в голову факт, что это могло быть записано в файл подкачки...) Все, что находится в памяти, может быть восстановлено, особенно в скомпрометированной системе. Особенно, если вы не доверяете качеству своего кода.
Вероятно, произойдет колоссальный откат, но мне кажется, что это будет правильно.
Принимая во внимание, что учетные данные пользователя задействованы, запрос рекомендуемого сброса пароля также может быть разумным.
-Waldo