Czy kiedykolwiek powinieneś wypuścić coś, co sam możesz zhakować?

12

Będąc twórcą programu, prawdopodobnie jesteś w lepszej sytuacji niż ktokolwiek inny, aby mieć świadomość luk w zabezpieczeniach i potencjalnych włamań. Jeśli znasz lukę w systemie, który napisałeś, czy jest to znak, że MUSI być dodane zwiększone bezpieczeństwo przed wydaniem, czy też należy to oceniać indywidualnie dla każdego przypadku, aby określić wagę luki w zabezpieczeniach?

security release

— Morgan Herlocker
źródło

7

Jasne, NSA robi to cały czas :)

— Jaap

3

@Jaap: NSA ciągle się o to oskarża . W jednym przypadku zdaję sobie sprawę z tego, gdzie ludzie dowiedzieli się, co się naprawdę wydarzyło, że będąc standardem szyfrowania DES, okazuje się, że modyfikacje NSA sprawiły, że szyfrowanie jest silniejsze , a nie słabsze, co zmniejsza ryzyko włamania przez technikę że nikt poza NSA nawet jeszcze tego nie odkrył, ponieważ wiedzieli, że ktoś inny w końcu to rozwiąże.

— Mason Wheeler,

6

@MasonWheeler Myślę, że ostatnie wydarzenia sprawiły, że Twój komentarz, tutaj od 2012 roku, jest nieaktualny.

— aceinthehole

6

Powiedziałbym, że należy to zrobić indywidualnie dla każdego przypadku. Jesteś autorem, znasz wiele dziur. Niektóre luki mogą być znane tylko Tobie. Oczywiście oznacza to, że jeśli którykolwiek z nich zostanie wykorzystany, możesz mieć trudne pytania, więc jeśli to możliwe, dobrym pomysłem jest ograniczenie tych luk. Ważniejsze jest to, czy ktoś może łatwo zhakować go jako system blackbox.

— FrustratedWithFormsDesigner
źródło

3

Szkoda tylko, że nie znałem wszystkich luk w oprogramowaniu, które napisałem. Potem mógłbym to wykorzystać, aby znaleźć wszystkie błędy, i znacznie łatwiej byłoby poprawnie napisać te rzeczy.

— David Thornley

1

@David: Ok, wiele ...

— FrustratedWithFormsDesigner

31

Miałem niefortunne doświadczenie podwójnej sytuacji. W obu przypadkach firma wystawiała produkty z poważnymi problemami bezpieczeństwa z bardzo wrażliwymi danymi.

W obu przypadkach firma wydawała się nie przejmować, pomimo moich najlepszych starań, aby uświadomić im, jakie ryzyko podejmują.

Jedyne, co możesz zrobić, to protestować tak głośno * (i profesjonalnie), jak to możliwe, jak najdokładniej o potencjalnych konsekwencjach i podczas gdy robisz ten dokument, wszystko . Wydrukuj odpowiednie wiadomości e-mail w formacie PDF i zachowaj te pliki w domu, lub ukryj swój osobisty adres e-mail lub w inny sposób. Jest to jedyne rozwiązanie, gdy nieuchronnie dzieje się coś złego.

Miałbyś nadzieję, że kierownictwo uszanuje cię za twoją poradę techniczną i weź to pod uwagę, ale niestety musisz szanować każdego, kto podejmie decyzję pod koniec dnia. Każdego dnia podejmowane są złe decyzje biznesowe.

Edycja: jasonk wspomniał „Proszę zachować ostrożność przy BCC ustalaniu adresu domowego” i bardzo się zgadzam. Nie naruszaj zasad firmy i ryzykuj, że luka w zabezpieczeniach będzie bardziej widoczna niż jest obecnie.

— As w dziurze
źródło

21

+1 za DOKUMENT WSZYSTKO !!! Kiedy dojdzie do poważnej katastrofy, a praca menedżera jest na linii, zrobi WSZYSTKO, aby zrzucić winę w KAŻDY sposób, w jaki może. Jeśli dokumentujesz problemy, e-maile, powiadomienia, notatki i inną dokumentację związaną z decyzją, chronisz się przed złą sytuacją.

— wałek klonowy

11

Af -cking-men. Każdy, kto jest wystarczająco sprytny, aby świadomie wysłać poważnie wadliwy produkt, może i zrobi * wszystko, aby uniknąć ostatecznej kuli.

— Peter Rowell

Zachowaj ostrożność przy BCC podając swój adres domowy.

— jasonk

2

@jasonk: Dlaczego tak mówisz? BCC oznacza, że inni odbiorcy go nie widzą ...

— Mason Wheeler,

3

@Mason: Odbiorcy nie mogą, ale dział IT może, a jeśli wysyłasz poufne informacje (które z pewnością są zagrożone) poza siedzibą, prawdopodobnie dostaniesz się w świat zranienia.

— Zaćmienie

12

Byłbym przeciwny - będąc twórcą, często jesteś zbyt blisko kodu, aby zobaczyć luki w zabezpieczeniach.

Jeśli znasz luki w zabezpieczeniach lub są ci mówione, są one jak każdy inny błąd - oceniaj, ustalaj priorytety, a następnie napraw.

— DaveE
źródło

+1: Wiesz, jak powinien działać mój program i do pewnego stopnia myślisz tylko o takim użyciu. Posiadanie kogoś, kto nie zna „poprawnego” sposobu korzystania z programu, jest jednym z najlepszych testów, jakie możesz zrobić.

— unholysampler

Jako ktoś stosunkowo nowy w QA, przyłączyłem się do pracy, oczekując, że błędy związane z „luką w zabezpieczeniach” zostaną spełnione z niezwykłą powagą. Odkryłem jednak, że etykieta „bezpieczeństwo” nie zawsze stanowi odpowiedź na zero tolerancji. Niektóre firmy są całkowicie zadowolone z podejmowania ryzyka bezpieczeństwa, jeśli luka nie wydaje się zagrażać reputacji marki lub oferuje hakerom niewiele do zyskania, a przyszłe wydania prawdopodobnie i tak zawierają poprawkę (lub zmianę funkcji).

— Greg Gauthier

4

Myślę, że odpowiedź zależy od stopnia szkód, które wystąpiłyby, gdyby zainfekowany system został zainfekowany przez złośliwego hakera. Oczywiście inżynier budownictwa nie mógł z czystym sumieniem zatwierdzić projektu niebezpiecznego mostu. Budowa takiego mostu może spowodować obrażenia lub śmierć. Byłoby to nielegalne, gdyby inżynier świadomie to robił, ale fakt, że inżynierowie oprogramowania (przynajmniej w USA) nie są prawnie związani w ten sam sposób, nie zwalnia ich z profesjonalnego obowiązku przeciwstawienia się wadliwym systemom. Niestety Twoja firma może nie potrzebować Twojego podpisu do wydania oprogramowania.

Nie określasz dokładnej natury systemu, nad którym pracujesz. Jeśli jest to związane z dokumentacją medyczną, bankowością, kontrolą ruchu lotniczego lub inną naprawdę istotną infrastrukturą, powiedziałbym, że należałoby uzasadnić naleganie na najwyższy możliwy poziom bezpieczeństwa przed wydaniem.

— PeterAllenWebb
źródło

+1 W kontekście chciałbym dodać, że wszelkie dane, które obejmują numery ubezpieczenia społecznego, numery identyfikacyjne lub numery kart kredytowych, powinny również zwracać uwagę na bezpieczeństwo. Systemy, które nie przechowują żadnej z tych informacji i nie są systemami krytycznymi, zawierają dane niskiego ryzyka i nie musisz się martwić o bezpieczeństwo.

— wałek klonowy

3

Tak, powinieneś to naprawić przed wydaniem wersji. Nigdy nie lekceważ pomysłowości hakera. Czy pojechałbyś na tydzień na wakacje z szeroko otwartymi tylnymi drzwiami? Czy twoją wymówką byłoby

„Och, jest z tyłu i nie wychodzi bezpośrednio na ulicę. Nikt nie widziałby, żeby była szeroko otwarta…”

Prawdopodobnie nie.

Ale dzisiaj rozumiem u premiera, że najświętsza data premiery jest ważniejsza niż potencjalnie ogromny problem z bezpieczeństwem. Jeśli tak jest w twoim przypadku, sugeruję zwrócenie na to uwagi, zarejestrowanie problemu, upewnienie się, że jest dobrze udokumentowane, dobrze znane, a ryzyko jasno wyjaśnione, i niech premier zdecyduje, co robić.

Jeśli premier podejmie złą decyzję i zdecyduje się zignorować to i pójdzie dalej zgodnie z harmonogramem, to jesteś zwolniony z odpowiedzialności, ponieważ dmuchnąłeś w gwizdek.

W przeciwnym razie, jeśli znajdziesz to i zatrzymasz dla siebie, a coś się stanie, wówczas możesz osobiście ponosić odpowiedzialność za konsekwencje.

Wybór nalezy do ciebie.

— wałek klonowy
źródło

4

Przynajmniej w Stanach Zjednoczonych nie jest to potencjalnie ogromny problem z odpowiedzialnością, ponieważ w przybliżeniu żadne oprogramowanie nie ma żadnej gwarancji. Oprogramowanie urządzeń medycznych jest wyjątkiem i prawdopodobnie istnieją inne, ale większość oprogramowania i usług opartych na oprogramowaniu jest zasadniczo „bez gwarancji”.

— David Thornley

1

Bez gwarancji? Dlaczego nie powiesz tego milionom klientów Sony, którym skradziono numery ubezpieczenia społecznego i inne poufne dane z powodu DOKŁADNIE takich luk bezpieczeństwa, jakie sugeruje OP?

— wałek klonowy

2

Chociaż David ma rację, brak możliwej do wyegzekwowania odpowiedzialności cywilnej może być zimnym komfortem, gdy reputacja twojej firmy jest zrujnowana, lub twoja mała firma jest po prostu wykluczona przez większą.

— PeterAllenWebb

@maple_shaft: A jaką odpowiedzialność ponosi Sony? Oferowali rok ochrony kredytowej, ale nie sądzę, aby ponosili oni jakąkolwiek odpowiedzialność prawną. Jest to hit ich reputacji, ale przetrwali już wcześniej.

— David Thornley

1

@Rory: Spójrzmy na to za dwa lata. Chciałbym myśleć, że fiasko rootkitów, arbitralne usunięcie OtherOS i ten wyciek sprawi, że Sony będzie mniej popularne na dłuższą metę, ale nie jestem wcale pewien.

— David Thornley,