> Security model, яка побудована на obscurity... Вона не "побудована" на obscurity, просто багато де "так склалося". Ну от, нема хорошої продуманої security моделі, але все якось працює, то і добре.
> ... хакнули приватне репо майкрософту на гітахбі і що? ... і то, що можна гадати, яка кількість дірок в майкрософтівських кодах і/або сервісах, які експлуатували після цього інциденту досі і експлуатуватимуть в майбутньому, була знайдена чи зроблена в результаті цього хаку.
> (а) дірки в коді вони знайдуть навіть без доступа до сирців - просто по непрямим ознакам, (б) захист коду - > це дуже вторинне. Бо якщо треба, то серйозні люди просто .... Це все правда, але: (a) захист власне коду -- лише один з аспектів, в репозиторія є багато всього іншого. Юзернейми/паролі, hash salt'и, порти/ReST-API-запроси для backdoor доступу, записані відкритим текстом в гілках розробників я не придумав, а бачив на власні очі. Не скажу, де і коли :) (b) "серйозні люди" бувають. Тут як з замками/дверима, аналогія з захистом житла, яку ми недавно згадували, пасує ідеально. Від "серйозного" наїзду не врятують і металеві двері з десятком замків, бо серйозні люди, коли треба, зайдуть в твою хату чи квартиру разом з тобою. Але "серйозні люди" -- це лише частина можливих security-related проблем. Часто -- помітно менша частина. Від опортуністичного бомжа чи навіть боязливого злодія без конкретної наводки замок на міцніших дверях допоможе. Так і тут: значна частина проблем значної частини корпорацій йде не від серйозних людей, a від дрібніших шахраїв, які вичисляють ту чи іншу діру в системі, і потрохи її доять. Але це "потрохи" додається достатньо, щоби втрати ставали відчутчими. В результаті, шукаєш зовнішні сервіси, які будудь тебе берегти. Я в одному з таких сервісів якраз і працюю зараз: клієнт приходить, каже, що його обкрадають, ми дивимося, що можемо зробити, описуємо наші можливості і виставляємо цінник. Після чого якісь клієнти платять нам, якісь вирішують самі себе ремонтувати/охороняти, а якісь вирішують, що ті півмільйона на рік, які в ник крадуть через цю дірку, дешевше продовжувати платити, ніж хоч щось міняти. Я бачив усі три сценарії. Так от, в цьому смислі, security by obscurity працює, ще й як. Кількість онлайн шахрайства, якє стається навколо, просто неймовірна. Я собі навіть не уявляв! Але поки про ту чи іншу діру знають лише кілька зловмисників, ніхто не чухається. А коли і чухається, то дуже трошки. Оптимізують не TTF чи TTR, а EBITDAthisquarter; максимум -- EBITDAthisyear. (c) не "по ознакам" а "за ознаками"
> Є ситуації де це має сенс, але в більшості випадків ... Ця "більшість", вона у твоїх спостереженнях, чи за якимись об'єктивними вимірами? Я, як ти знаєш, в індустрії відносно недавно, не претендую, що бачив багато різноманітного софтверного продукту. Тобто, за останній рік з гаком бачив багатенько чужих проблем, але чужий код не читав, хоча часом можна було здогататися, звідки в коді ростуть ноги них проблем. Але навіть в тих трьох місцях, де я працював, спущена зверху всякими просвітленими менеджерами і cost-saving віцепрезидентами мантра "be your own QA" була абсолютно, категорично неправильною. Словом, не маю причин сумніватися, що можливі сценарії, де це працює, але я особисто таких сценаріїв не бачив :) Напевне, я бачив меншість. Думаю (знову вбрав капітанську шапку), все залежить від області, де ти працюєш. Я стикався, переважно, з різного роду Data Product кодом (ETL / ML / visualizations) різних областей. Плюс, пару років працював в команді, яка, власне, розробляла збір логів в мережах (WAN), то бачив і власне log generation/transmission/processing/storage код, і весь код командування мережею. З тих пір і не можу позбутися глибинного цинізму стосовно всього, зв'язаного з мережами і просто комп'ютерами. Шукаю луддитів-однодумців :)))))
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
Date: 2021-12-31 01:28 am (UTC)Вона не "побудована" на obscurity, просто багато де "так склалося". Ну от, нема хорошої продуманої security моделі, але все якось працює, то і добре.
> ... хакнули приватне репо майкрософту на гітахбі і що? ...
і то, що можна гадати, яка кількість дірок в майкрософтівських кодах і/або сервісах, які експлуатували після цього інциденту досі і експлуатуватимуть в майбутньому, була знайдена чи зроблена в результаті цього хаку.
> (а) дірки в коді вони знайдуть навіть без доступа до сирців - просто по непрямим ознакам, (б) захист коду -
> це дуже вторинне. Бо якщо треба, то серйозні люди просто ....
Це все правда, але:
(a) захист власне коду -- лише один з аспектів, в репозиторія є багато всього іншого. Юзернейми/паролі, hash salt'и, порти/ReST-API-запроси для backdoor доступу, записані відкритим текстом в гілках розробників я не придумав, а бачив на власні очі. Не скажу, де і коли :)
(b) "серйозні люди" бувають. Тут як з замками/дверима, аналогія з захистом житла, яку ми недавно згадували, пасує ідеально. Від "серйозного" наїзду не врятують і металеві двері з десятком замків, бо серйозні люди, коли треба, зайдуть в твою хату чи квартиру разом з тобою. Але "серйозні люди" -- це лише частина можливих security-related проблем. Часто -- помітно менша частина. Від опортуністичного бомжа чи навіть боязливого злодія без конкретної наводки замок на міцніших дверях допоможе. Так і тут: значна частина проблем значної частини корпорацій йде не від серйозних людей, a від дрібніших шахраїв, які вичисляють ту чи іншу діру в системі, і потрохи її доять. Але це "потрохи" додається достатньо, щоби втрати ставали відчутчими. В результаті, шукаєш зовнішні сервіси, які будудь тебе берегти. Я в одному з таких сервісів якраз і працюю зараз: клієнт приходить, каже, що його обкрадають, ми дивимося, що можемо зробити, описуємо наші можливості і виставляємо цінник. Після чого якісь клієнти платять нам, якісь вирішують самі себе ремонтувати/охороняти, а якісь вирішують, що ті півмільйона на рік, які в ник крадуть через цю дірку, дешевше продовжувати платити, ніж хоч щось міняти. Я бачив усі три сценарії. Так от, в цьому смислі, security by obscurity працює, ще й як. Кількість онлайн шахрайства, якє стається навколо, просто неймовірна. Я собі навіть не уявляв! Але поки про ту чи іншу діру знають лише кілька зловмисників, ніхто не чухається. А коли і чухається, то дуже трошки. Оптимізують не TTF чи TTR, а EBITDAthisquarter; максимум -- EBITDAthisyear.
(c) не "по ознакам" а "за ознаками"
> Є ситуації де це має сенс, але в більшості випадків ...
Ця "більшість", вона у твоїх спостереженнях, чи за якимись об'єктивними вимірами? Я, як ти знаєш, в індустрії відносно недавно, не претендую, що бачив багато різноманітного софтверного продукту. Тобто, за останній рік з гаком бачив багатенько чужих проблем, але чужий код не читав, хоча часом можна було здогататися, звідки в коді ростуть ноги них проблем. Але навіть в тих трьох місцях, де я працював, спущена зверху всякими просвітленими менеджерами і cost-saving віцепрезидентами мантра "be your own QA" була абсолютно, категорично неправильною. Словом, не маю причин сумніватися, що можливі сценарії, де це працює, але я особисто таких сценаріїв не бачив :) Напевне, я бачив меншість.
Думаю (знову вбрав капітанську шапку), все залежить від області, де ти працюєш. Я стикався, переважно, з різного роду Data Product кодом (ETL / ML / visualizations) різних областей. Плюс, пару років працював в команді, яка, власне, розробляла збір логів в мережах (WAN), то бачив і власне log generation/transmission/processing/storage код, і весь код командування мережею. З тих пір і не можу позбутися глибинного цинізму стосовно всього, зв'язаного з мережами і просто комп'ютерами. Шукаю луддитів-однодумців :)))))