Должны ли вы когда-нибудь выпустить что-то, что вы могли бы взломать?


12

Будучи создателем программы, вы, вероятно, в лучшем положении, чем кто-либо, знаете об уязвимостях безопасности и потенциальных взломах. Если вы знаете об уязвимости в написанной вами системе, это ДОЛЖЕН быть добавлен признак того, что повышенная безопасность должна быть выпущена до выпуска, или это следует оценивать в каждом конкретном случае для определения серьезности разрыва в безопасности?


7
Конечно, АНБ делает это все время :)
Jaap

3
@Jaap: АНБ постоянно обвиняют в этом . В одном случае мне известно о том, где люди узнали о том, что на самом деле происходило, что, будучи стандартом шифрования DES, оказывается, что модификации АНБ фактически сделали шифрование более сильным , а не более слабым, что снижает вероятность его взлома техникой. что никто, кроме АНБ, даже не обнаружил, потому что они знали, что кто-то еще в конце концов это выяснит.
Мейсон Уилер

6
@MasonWheeler Я думаю, что последние события сделали ваш комментарий здесь, с 2012 года, устаревшим.
aceinthehole

Ответы:


6

Я бы сказал, что это должно быть сделано в каждом конкретном случае. Вы автор, вы знаете много дыр. Некоторые уязвимости могут быть известны только вам. Конечно, это означает, что если какой-либо из них будет эксплуатироваться, у вас могут возникнуть трудные вопросы, на которые можно ответить, поэтому было бы неплохо по возможности уменьшить эти уязвимости. Более важно, если кто-то может легко взломать его как систему черного ящика.


3
Я только хотел бы знать все дыры в программном обеспечении, которое я написал. Тогда я мог бы использовать это, чтобы найти все ошибки, и было бы намного легче правильно написать материал.
Дэвид Торнли

1
@ Дэвид: Хорошо, многие ...
FrustratedWithFormsDesigner

31

У меня был неудачный опыт нахождения в ситуации дважды. В обоих случаях бизнес выпускал продукты с серьезными проблемами безопасности с очень конфиденциальными данными.

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

Единственное, что вы можете сделать, это протестовать как можно громче * (и профессионально), как можно яснее о возможных последствиях, и пока вы делаете этот документ, все . Распечатайте ваши соответствующие электронные письма в PDF-файлы и храните эти файлы дома, или скрывайте свой личный адрес электронной почты, или как вы это делаете. Это единственное решение, когда неизбежно случается что-то плохое.

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

Изменить: Джейсон упомянул "Пожалуйста, будьте очень осторожны, BCCing ваш домашний адрес", и я очень согласен. Пожалуйста, не нарушайте политику компании и рискуйте раскрыть уязвимость безопасности больше, чем она есть.


21
+1 за ДОКУМЕНТ ВСЕ !!! Когда происходит крупная катастрофа и работа менеджера на линии, он / она сделает НИЧЕГО, чтобы свалить вину ЛЮБЫМ способом. Если вы документируете проблемы, электронные письма, уведомления, заметки и другую документацию, связанную с решением, то вы защищаете себя от плохой ситуации.
maple_shaft

11
Af cking-men. Любой, кто достаточно лукав, чтобы сознательно отправлять серьезно дефектный продукт, может и сделает все, чтобы избежать возможной пули.
Питер Роуэлл

Пожалуйста, будьте очень осторожны, BCCing ваш домашний адрес.
Джейсон

2
@jasonk: Почему ты так говоришь? BCC означает, что другие получатели не могут видеть это ...
Мейсон Уилер

3
@ Мейсон: получатели не могут, но ИТ-специалисты могут, и если вы отправляете конфиденциальную информацию (какие уязвимости безопасности наиболее определенно являются) удаленными, вы, вероятно, попадете в мир вреда.
Затмение

12

Я бы сказал обратное - будучи создателем, вы часто слишком близки к коду, чтобы увидеть уязвимости.

Если вы знаете или говорите об уязвимостях, они, как и любая другая ошибка - оценивают, расставляют приоритеты, а затем исправляют.


+1: Вы знаете, как должна работать моя программа, и в некоторой степени думаете только об ее использовании. Наличие кого-то, кто не знает «правильного» способа использования программы, является одним из лучших тестов, которые вы можете сделать.
unholysampler

Как кто-то относительно новичок в QA, я приступил к работе, ожидая, что ошибки "недостатка безопасности" будут встречены с чрезвычайной серьезностью. Но я обнаружил, что ярлык «безопасность» не всегда является потребностью в ответе с нулевой терпимостью. Некоторые компании с радостью рискуют безопасностью, если уязвимость не угрожает репутации бренда или не дает хакерам никакой выгоды, а в будущих выпусках, скорее всего, будет исправление (или изменение функции).
Грег Готье

4

Я думаю, что ответ зависит от степени вреда, который может возникнуть, если система будет взломана злоумышленником. Очевидно, что инженер-строитель не мог с чистой совестью одобрить проект небезопасного моста. Строительство такого моста может привести к травме или смерти. Для инженера также было бы незаконно сознательно делать это, но тот факт, что разработчики программного обеспечения (по крайней мере, в США) юридически не связаны таким же образом, не освобождает их от профессиональной обязанности выступать против неисправных систем. К сожалению, вашей компании может не потребоваться ваша подпись для выпуска программного обеспечения.

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


+1 Для контекста я бы добавил, что любые данные, которые включают в себя номера социального страхования, идентификационные номера или номера кредитных карт, также должны учитывать безопасность. Системы, которые не хранят эту информацию и не являются критически важными системами, имеют данные с низким уровнем риска, и вам не придется беспокоиться о безопасности.
maple_shaft

3

Да, вы ДОЛЖНЫ исправить это до выхода релиза. Никогда не стоит недооценивать изобретательность хакера. Вы бы отправились в отпуск на неделю с широко распахнутой задней дверью? Будет ли ваше оправдание,

«О, он сзади, и он не смотрит прямо на улицу. Никто бы не увидел, что он широко открыт ...»

Возможно нет.

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

Если премьер-министр примет плохое решение и решит проигнорировать это и продолжить выпуск в соответствии с графиком, тогда вы освобождаетесь от ответственности, поскольку вы опровергли свисток.

В противном случае, если вы обнаружите это и сохраните это для себя, и что-то произойдет, ВЫ будете нести личную ответственность за последствия.

Выбор ваш.


4
По крайней мере, в США это не является потенциально огромной проблемой ответственности, потому что примерно ни одно программное обеспечение не поставляется с какой-либо гарантией. Программное обеспечение для медицинских устройств является исключением, и, вероятно, есть и другие, но большинство программных и программных услуг, по существу, основаны на принципах «без гарантий».
Дэвид Торнли

1
Нет гарантии? Почему бы вам не рассказать об этом миллионам клиентов Sony, у которых украли их номера социального страхования и другие конфиденциальные данные из-за ТОЧНО таких дыр в безопасности, как предлагает ОП.
maple_shaft

2
Хотя Дэвид прав, отсутствие принудительной гражданской ответственности может быть холодным утешением, когда репутация вашей компании разрушена, или ваша маленькая фирма просто перестает существовать из-за более крупной.
PeterAllenWebb

@maple_shaft: А какая ответственность у Sony? Они предложили год услуг по защите кредитов, но я не думаю, что они несут юридическую ответственность. Это удар по их репутации, но они пережили такое раньше.
Дэвид Торнли

1
@Rory: Давайте посмотрим на это через два года. Я хотел бы думать, что фиаско руткита, произвольное удаление OtherOS и эта утечка сделали бы Sony менее популярной в долгосрочной перспективе, но я совсем не уверен.
Дэвид Торнли
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.