Wikipedia:Propozycje do Artykułów na Medal/Bezpieczeństwo teleinformatyczne

Dodaj linki
Z Wikipedii, wolnej encyklopedii

Bezpieczeństwo teleinformatyczne[edytuj | edytuj kod]

Dyskusja zakończona
Rozpoczęcie: 29 września 2006 01:11:24 Zakończenie: 29 października 2006 01:11:24
Wynik: Przyznano

Udało się nam przekształcić wiszący od wielu lat kulawy stub w dobrze udokumentowany, przekrojowy artykuł, który przewyższa czytelnością en.wiki. Zgłaszam go więc za namową paru osób, bo nie ma chyba sensu bawić się w głuchy telefon.

Widzę, że mamy bodajże jeden medalowy artykuł dotyczący informatyki (ciasteczka), więc liczę się z tym, że może być ciężko, choćby ze względu na brak przyjętego złotego standardu... ale nawet jeśli tak będzie, albo jeśli mylę się w ocenie formy tego artykułu, PAnM może tylko tylko prowadzić do jego dalszej poprawy, więc czemu nie :-) -- (lcamtuf) 01:11, 29 wrz 2006 (CEST)

 Za

  1. --<A.J.>--<?>-- 12:19, 30 wrz 2006 (CEST)
  2.  Za, no to promujemy :) -- PawelS Dyskusja 16:20, 30 wrz 2006 (CEST)
  3. Herr Kriss 16:29, 30 wrz 2006 (CEST)
  4. DingirXul Dyskusja 16:32, 30 wrz 2006 (CEST)
  5. Szczepan Dyskusja 16:52, 30 wrz 2006 (CEST)
  6. Za --Pmgpmg 22:22, 1 paź 2006 (CEST)
  7. Migatu 22:25, 1 paź 2006 (CEST) Bardzo porządny kawałek tekstu.
  8. --WarX <talk> 23:21, 1 paź 2006 (CEST) więcej takich fachowych artykułów
  9. Jak najbardziej  Za Gardomir riposta? 10:28, 2 paź 2006 (CEST)
  10. Dodek D 19:08, 2 paź 2006 (CEST)
  11. pbm 22:56, 2 paź 2006 (CEST)
  12. alx d 23:38, 2 paź 2006 (CEST) Panie, panowie, czapki z głów!
  13. – jozef-k ? 22:33, 3 paź 2006 (CEST)
  14. Winiar✉ 08:42, 4 paź 2006 (CEST)
  15. Gdarin dyskusja 12:20, 5 paź 2006 (CEST) ale proszę o uzupełnienie czerwonych linków - czytelnik może się zastanawiać co to jest np. spisek - np. mnie słowo to się nie kojarzy wcale z informatyką i chętnie poznam jego specjalistyczne znaczenie
    Eee tam, czerwone linki są wadą Wikipedii a nie artykułu: jak tak razi ten link, to po prostu go usuń, nie tak łatwo jest napisać encyklopedycznie o spiskach: ujęcie historyczne to by było od Jakuba i Ezawa do Watergate :) --<A.J.>--<?>-- 13:11, 5 paź 2006 (CEST)
    Skoro tu chodzi o taki zwykły spisek, to po co link? I tak nie przebije to artykułu kaczka po pekińsku, którą trzeba było piec: po 45 minut kolejno na każdym boku. Nie linkujmy każdego fajnego słowa jakie się pojawi w tekście... Aż się boję teraz pytać o inne czerwone linki - ale o prywatność z sekcji "Zobacz też" zapytać muszę, bo nie mogę oczyma wyobraźni dojrzeć tego co tam ma być, a zaczynam węszyć nowy spisek. ;)Gdarin dyskusja 13:33, 5 paź 2006 (CEST)
    Nie linkuję każdego słowa, spisek podlinkowałem po części jako prowokację, bo fajnie byłoby mieć o tym dobry artykuł (zwłaszcza o współczesnych zmowach/spiskach w świecie biznesu) ;-) Prywatność to inna bajka, w informatyce oraz prawie ma dość konkretne znaczenie i jest szerokim tematem (en:Internet privacy, en:privacy). Tu przydałyby się chociaż stuby. -- (lcamtuf) 13:37, 5 paź 2006 (CEST)
    Będę to powtarzał w kółko - czerwone linki nie są żadną wadą artykułu - one są potrzebne - one są po to aby ktoś kiedyś napisał odpowiedni artykuł, jeśli takiego nie ma. Usuwanie linku tylko z tego powodu, że jest czerwony, albo zapełnianie go na siłę jednolinijkowym stubem jest dla rozwoju wikipedii szkodliwe. Polimerek 14:45, 8 paź 2006 (CEST)
  16. LeinaD dyskusja 15:17, 8 paź 2006 (CEST)
  17.  Za, Abram 22:38, 9 paź 2006
  18.  Za Baqu11 21:31, 13 paź 2006 (CEST) Świetny artykuł.

 Przeciw

--83.26.20.210 22:28, 1 paź 2006 (CEST) - niezalogowany -- (lcamtuf) 23:26, 1 paź 2006 (CEST)


  • Dyskusja:

Uwagi Gardomira
Ogółem artykuł wydaje się bardzo dobry, choć niezbyt znam się na informatyce. Niżej kilka moich uwag, po ich uwzględnieniu będę za:

  • Nagłówek jest za krótki – powinien streszczać w kilku zdaniach cały artykuł
  • Do przykładów można zaliczyć utratę sondy NASA Mariner 1 w 1962 na skutek błędu w kodzie napisanym w języku FORTRAN, czy śmierć pacjentów na skutek wadliwego oprogramowania maszyn Therac-25 w latach 80.- brakuje przypisów.
  • Spory dotyczące kategoryzacji – czy można trochę rozwinąć tą sekcję? Wydaje się niezrozumiała, choć może to tylko wrażenie laika.
  • w dużej mierze wynikają z historycznej budowy protokołu SMTP. – co to znaczy, że budowa jest historyczna?
  • Formalne dowodzenie poprawności – przydałyby się źródła do tej sekcji
  • Zgodnie ze sformułowaniem jednego z czołowych specjalistów do spraw bezpieczeństwa, Bruce Schneiera, bezpieczeństwo to proces, nie produkt. – należy podać źródło cytatu.
  • Statystyki phishingu w latach 2004/2005 – warto by to było zaktualizować i przetłumaczyć na polski (ale to akurat tylko sugestia)
  • Jeśli to możliwe należałoby podać przynajmniej jedna zbiorczą pozycję bibliograficzną.

Pozdrawiam i gratuluję autorowi, Gardomir riposta? 08:53, 2 paź 2006 (CEST)

  • Gardomirze - dzięki za wnikliwe przejrzenie tekstu i poprawki stylistyczne. Co do pytań: 1) nagłówek za chwilę dopracuję; 2) są przypisy w podlinkowanych pod słowa 'Mariner 1' i 'Therac-25' artykułach (artykuł Therac-25 zresztą sam pisałem); wydaje mi się, że wstawianie przypisów, które nie są bezpośrednio związane z omawianym tematem, byłoby tutaj po prostu sztuką dla sztuki; 3) spory - również rzucę okiem za chwilę; 4) SMTP to wiekowy protokół, postaram się to ładniej sformułować; 4) formalne dowodzenie - OK, dodam; 5) źródła cytatu - racja, nawet pamiętam dodawanie, musiało mi się przyśnić ;-) poprawię; 6) statystyki - to raczej do speców od SVG, nie ma sensu robić kolejnej nieedytowalnej bitmapy; 7) będzie trudno, ale coś wymyślę. Za godzinę-dwie wrzucę wspomniane poprawki. Pozdrawiam, -- (lcamtuf) 10:03, 2 paź 2006 (CEST)
Zrobione, poza bibliografią zbiorczą - w tej chwili ciężko mi wymyślić jakąkolwiek całościową pozycję, która nie przedstawia dość konkretnej metodologii i światopoglądu. Lepsze są prawdopodobnie linki do SANS i Securityfocus, gdzie można znaleźć sporo przydatnych zestawień literatury z komentarzami... aczkolwik będę szukał dalej. -- (lcamtuf) 10:25, 2 paź 2006 (CEST)
To chyba trzeba podać wiele linków? alx d 20:05, 2 paź 2006 (CEST)
Uwagi Alxa

Dowiedziałem się sporo ciekawych rzeczy z tego artykułu, jednak...

  • Drugi paragraf wprowadzenia wciąż brzmi jak wyjęty z ulotki propagandowej. Tam powinno znajdować się krótkie i przystępne streszczenie wszystkich ważniejszych zagadnień o objętości 2-3 akapitów. Trzeba dać szansę tym, którzy nie mają czasu, aby czytać tak długie opracowanie.
  • Brak informacji o Common Criteria to poważna luka.
  • Wydaje się, że przy okazji Błędów projektowych warto wspomnieć o błędach w protokołach i podać jako przykład en:Needham-Schroeder protocol.
  • Rzeczy typu buffer overflow, format string attack czy integer overflow powinny byc wyeliminowane, istnieja polskie odpowiedniki, nazwy angielskie w nawiasach.
  • Sekcja Odpowiedni dobór algorytmów i interfejsów opisuje zagadnienie protokołów i interfejsów użytkownika, a nie algorytmów i interfejsów.
  • Promowanie programowania ekstremalnego jako techniki tworzenia bezpiecznego oprogramowania jest dosyć kontrowersyjne. Musi być opatrzone opisem, w jakich warunkach, oraz referencją. Lepiej usunąć.
  • Statyczna analiza, w odróżnieniu od przeglądu kodu, z zasady nie jest prowadzona ręcznie.
  • Rozbicie sekcji Statyczna analiza kodu źródłowego na podsekcje po dwukropku jest dosyć niestandardowym rozwiązaniem edytorskim.
  • Formalne dowodzenie poprawności - trudno powiedzieć, żeby było najbardziej obiecujące. Może "potencjalnie najwięcej dające"?
  • Zdanie Przykładem takiego kontrowersyjnego porównania była sponsorowana przez firmę Microsoft analiza, która wykazała, że Linux jest bardziej podatny na ataki, niż Windows[12]. powinno być opatrzone referencją do tego, gdzie ta kontrowersja była stwierdzona, inaczej dociera tylko do "linuksowców".
  • Niby bezpieczeństwo teleinformatyczne, a nie ma ani słowa o zabezpieczeniach dla telefonów komórkowych oraz w ogólności dla sieci radiowych (nie tylko 803.11).

Trzymam kciuki i pozdrawiam, alx d 20:05, 2 paź 2006 (CEST)

  • Dzięki za przejrzenie tekstu. Odnośnie uwag: 1) rozmawialiśmy o tym na IRCu, nie mam pomysłu, jak to poprawić, żeby zadowolić wszystkich (też siebie ;-). Tak czy tak, jest to raczej kwestia gustu (mam nadzieję); 2) Jest wzmianka o Trusted Computer System Evaluation Criteria, czyli poprzedniku CC, zaktualizuję ją do CC; 3) N-S - ok, pomyślę o zgrabnym zintegrowaniu; 4) z odpowiednikami jest ślisko - buffer overflow ma odpowiednik, reszta raczej nie ma przyjętych wersji w .pl, dotychczas artykuły pisane przez innych używały nazw anglojęzycznych, więc trzeba zrobić ew. ogólną burzę mózgów w tym temacie i pozamiatać (linkowanie w stylu [[nazwa ang|nazwa pol]] byłoby w tej chwili mylące); 5) ok, postaram się z synchronizować język; 6) nie promuję, wspominam, bo jest traktowane jako panaceum także na problemy security; postaram się to zaznaczyć; 7) to edycja Jaggera, o ile pamiętam; 8) ok, poprawiam; 9) racja, poprawiam; 10) poprawiam; 11) mówimy ogólnie o sieciach i systemach, ale spróbuję wpleść zgrabnie jakąś jasną referencję. Pozdrawiam i idę poprawiać. -- (lcamtuf) 20:22, 2 paź 2006 (CEST)
    Załatwione: 2, 3, 5, 6, 7, 8, 9, 10, 11. Nie załatwione, ale mam nadzieje nie będące kwestią życia i śmierci: 1 (patrz wyżej), 4 (głębsza dyskusja dla całej kategorii, jw). -- (lcamtuf) 20:45, 2 paź 2006 (CEST)
    4) pewnie tak, ale są przecież słowniki, w których terminy te się pojawiają i jest wiele książek, w których się takich terminów używa. Oczywiście daleko nie zawsze istnieje tutaj jeden termin (jak w angielskim). Również dobrą praktyką - dla bardziej leniwych - jest najpierw pogóglowanie, potem wpisanie najzgrabniejszego rozwiązania, a następnie dopisanie w nawiasie angielskiego odpowiednika. Wprowadzanie tych terminów żywcem jest po prostu zaśmiecaniem języka. Dla powyższych przykładów można użyć np.: "przepełnienie bufora", "atak z użyciem sekwencji formatujących" i "przekroczenie zakresu liczb". alx d 21:25, 2 paź 2006 (CEST)
    Problem w tym, że nie wydaje mi się, by istniały uznane i zgodnie cytowane przez wszystkie źródła tłumaczenia terminów format string vulnerability czy integer overflow. Podane przez Ciebie przykłady są długie i nieintuicyjne (sekwencje formatujące? co w nich sekwencyjnego? co formatują? format string to przyjęta nazwa własna, którą rozpoznaje każdy programista; przekroczenie zakresu liczb - to zjawisko, przy którym wiele języków generuje wyjątek; jakie są implikacje dla bezpieczeństwa?). Niektóre pozycje wymyślają tłumaczenia, ale część z nich trąci dwumlaskiem i manipulatorem stołokulotocznym. Ale tak czy tak, to jest formalność - jeśli będzie plan przemianowania istniejących artykułów, poprawa linków to parę sekund. -- (lcamtuf) 21:39, 2 paź 2006 (CEST)
    • Z pierwszym zdaniem zgodziłem się już w drugim zdaniu mojej poprzedniej wypowiedzi.
    • Sugestia, aby podawać nazwy angielskie w nawiasie, wynikała właśnie z tego, aby nieszczęśni programiści nie pogubili się.
    • Nie upieram się przy moich propozycjach, bo wiem, że są mniej lub bardziej arbitralne, ale też wiem, że tu i ówdzie przyjęte.
    • Pytanie jakie są konsekwencje dla bezpieczeństwa w wypadku przekroczenia zakresu liczb jest tak samo mądre jak pytanie o konsekwencje przepełnienia bufora.
    • Nie sugeruję, aby wybierać te, podane przez Ciebie, najgorsze wersje tłumaczeń. Sugeruję pewną metodologię pozwalającą zmniejszyć ryzyko pojawienia się takich kwiatków.
    • Jeśli chodzi o plany, to ja nie mam zasobów do zorganizowania stosownej akcji. Mam zasoby, aby dziś krytycznie przeczytać ten artykuł. Jestem zdania, że artykuł na polskiej Wikipedii powinien być napisany po polsku. Takie angielskojęzyczne wstawki wychodzą poza zakres tego języka i moim zdaniem nie powinny mieć miejsca w pokazowym artykule na medal. Ale to tylko moje prywatne zdanie - może wśród innych głosujących przeważy przeciwne. alx d 22:18, 2 paź 2006 (CEST)
    Jeśli odebrałeś mój komentarz negatywnie, to przepraszam, nie taki był mój zamiar. Po prostu, jak mówiłem, dobrych odpowiedników nie znam, nie stosuje się w innych artykułach, a i w literaturze jest z nimi kiepsko. Wiele nowych terminów w informatyce jest zresztą zapożyczonych z en, i nie każdy voxel i exploit się tłumaczy, i mam wrażenie, że i tak jest w tym przypadku. Zmiana tego we wszystkich artykułach nie jest prosta, i byłaby bardzo w moim odczuciu kontrowersyjna. Zmiana tylko w tym byłaby wysoce niekonsekwentna... więc zastanawiam się, czy nie wylewamy dziecka razem z kąpielą w imię spolszczania za wszelką cenę (mimo, że ja też nie jestem zwolennikiem zapożyczeń). -- (lcamtuf) 22:27, 2 paź 2006 (CEST)
    A co powiesz na wprowadzone teraz zmiany? -- (lcamtuf) 22:42, 2 paź 2006 (CEST)
    Kul. alx d 23:36, 2 paź 2006 (CEST)
  • Co do 7, to mam wrażenie, że statyczna analiza kodu, to poprostu analiza kodu źródłowego (statyczna, bo bez uruchamiania programu). Ale upierał się nie będę (bo i moja wiedza na ten temat li tylko z życia wzięta, a nie z dokumentów poważnych, o ile takowe istnieją;) ;) Jagger σ 20:55, 2 paź 2006 (CEST)
    • Alx ma rację, że termin ten jednak częściej jest używany jako określenie metod automatycznych (zwłaszcza w angielskim). O ile nie jest karygodnym błędem nazwanie przejrzenia kodu przez człowieka analizą statyczną, może być to nieco mylące, a tego lepiej unikać. Zmieniłem to więc na bardziej neutralne sformułowanie. -- (lcamtuf) 21:12, 2 paź 2006 (CEST)
      Usunięcie analizy statycznej z artykułu nie jest dobrym rozwiązaniem, bo to jest jeden z najważniejszych obecnie trendów przy poprawianiu bezpieczeństwa oprogramowania [1]. alx d 21:25, 2 paź 2006 (CEST)
    Jedno zdanie niestety opisywało oba zjawiska, więc chciałem uniknąć przeładowania terminów. Ok, poprawiam żeby ładnie wymienić obie nazwy, bez konfuzji... done. -- (lcamtuf) 21:39, 2 paź 2006 (CEST)

Pytanie Pana Camela

Mam pytanie odnosnie tego hasla. Czy glownym tematem artykulu/(intencja autora) jest bezpieczenstwo rozumiane jako "zabezpieczenie przed nieautoryzowanym uzyciem/utraty poufnych danych itp." czy bezpieczenstwo systemow teleinformatycznych w kontekscie ich niezawodnosci? Pozdrawiam, Pan Camel 11:09, 6 paź 2006 (CEST)

  • Niezawodność jest związana z bezpieczeństwem (system, który nie zawsze pracuje zgodnie z założeniami, nie może być bezpieczny), więc nie można tego rozgraniczyć (i dlatego przytoczona tam definicja systemu bezpiecznego różni się raptem trzema słowami od definicji systemu niezawodnego, dodając dodatkowy warunek). Ale patrz dyskusja artykułu: ujęć bezpieczeństwa jest wiele, trzeba wybrać takie, które jest możliwie przekrojowe, ale przy okazji zgodne z przyjętymi zwyczajami. -- (lcamtuf) 12:15, 6 paź 2006 (CEST)
    • No w takim razie to mógłbym mieć zarzut(?). Jeśli będące tematem tego artykułu bezpiecześnstwo to "security + reliability" (użyje angielskich terminów, żeby nam się nie myliło), to ten artykuł ma proporcje zdecydowanie przesunięte w stronę "security". Być może to jest świadomy zabieg, bo w kontekście artykułu "reliability" jest ważne w celu wspomagania "security" (które ma być głównym tematem tego artykułu). Ale jeśli oba zagadnienia są tak samo ważne, to kwestie zapewnienia tego "reliability" są praktycznie nieporuszone i wtedy miałbym dużo uwag. Pan Camel 15:30, 7 paź 2006 (CEST)
      • Może tak: niezawodność jest warunkiem, który musi być spełniony zanim formalnie uznamy system za bezpieczny, a ocena niezawodności jest kluczowym elementem zarządzania ryzykiem. Ze względu na to, pojęcia te są ściśle związane. Tym niemniej, niezawodność jest oddzielnym przedmiotem studiów, która wykracza poza bezpieczeństwo ściśle informatyczne, i zwykle nie jest z nim mieszana w literaturze (a to dobry wyznacznik!). Niezawodność od strony projektowej i implementacyjnej jest zupełnie inną dziedziną (en:Reliability engineering), a od strony operacyjnej (backupy, redundancja, itp) - problemem dotyczącym zdecydowanie bardziej ciągłości biznesowej, bezpieczeństwa operacyjnego, i zarządzania ryzykiem - wszystko to w ujęciu daleko wykraczającym poza technikę. Na stronie dyskusji artykułu piszę trochę szerzej, gdzie postawiłem granicę, czemu, i czemu chcę uniknąć interdyscyplinarnego mętliku, do którego może prowadzić opisywanie w jednym przerażająco długim artykule zagadnień tak różnych jak buffer overflowy, SOX, budowę sieci, niezawodność protokołów, audyty wewnętrzne, czy ochronę fizyczną i trzymanie gaśnic w serwerowniach (wszystko to z bezpieczeństwem teleinf się wiąże, ale nie jest jego częścią z punktu widzenia informatyki). Rzuć na tamtą dyskusję okiem. Rozwiązaniem, które wydaje mi się najlepsze, jest stopniowe opisanie zagadnień związanych z testowaniem oprogramowania, QA, niezawodnością i ciągłością biznesową, i wlinkowywanie je do tekstu jako "zobacz też". Ale robienie tego teraz, gdy tych artykułów nie ma, to sianie czerwonych linków dla sztuki, bez pożytku dla zrozumienia tekstu. -- (lcamtuf) 15:51, 7 paź 2006 (CEST)

Nie chcę dzielić wlos na czworo i przepychać sie z tą granicą (co jeszcze się zmieści jako "reliability" w artykule, a co już nie) ;-), zasygnalizuję tylko kilka potencjalnych "białych plam", sam uznasz czy to mieści sie w formule artykułu ktorą przyjąłeś.

  • test - opisany dosyć wybiórczo i powierzchownie z luźną uwagą na końcu Najlepsze efekty daje zwykle połączenie kilku spośród tych metod. Przecież w rzeczywistych, dużych projektach teleinformatycznych, test towarzyszy całemu procesowi tworzenia softwaru i jest kluczowy dla zapewnienia jakości (a co za tym idzie, bezpieczeństwa) Systemu. Na różnych etapach projektu, stosuje się różne rodzaje testu wspomniane w artykule, a także wiele innych. Oczywiście nie dzieje się tak podczas tworzenia aplikacji webowych, gdzie ryzykuje się co najwyżej irytację użytkownika, ale na przykład w telekomunikacji, gdzie dostawcy wbrew temu co napisałeś ponoszą odpowiedzialność (konkretna umowa - kary umowne, jeśli system nie działa dłużej niż 6 minut w ciągu roku), czy podczas tworzenia softwaru od którego może zależeć zdrowie/lub życie ludzi. Można tu też poruszyć kwestie używanych metodologii (Extreme Programming kontra "cięzkie" metodologie jak RUP) i planowania strategii testu podczas projektu. No i w kontekście bezpieczngo systemu testy obciązeniowe (performance test) też powinny się moim zdaniem znależć w artykule.
  • "Wybór metod programistycznych" - generalnie przesłanie w tym paragrafie jest takie: C++ i Java niedoskonałe, są lepsze np. Ada, ale się ich nie używa, jest jeszcze pare innych postulatów co do podniesienia jakości oprogramowania, ale trudno je zastosować w praktyce. I z tym czytelnik jest pozostawiony sam sobie. To znaczy, że co? Nie ma nadziei ;-) ?
    • Może lepiej opisać ogólniej jak ważne są pierwsze etapy projektowania softwaru (i inspekcje dokumentów które są inputem do dalszych faz projektu, w tym kodowania).
    • Można poruszyć kwestie Unit Testu, który powinien zaprojektować Designer, dla tworzonej klasy/metod/bloku funkcyjnego/etc (w zależności od stosowanego paradygmatu programowania), jako pierwszej metody wyłapywania błędu .
  • Uważam, że w artykule o bezpieczeństwie teleinformatycznym powinno paść słowo redundancja i jakiś przykład z nią związany.
  • Support od dostawcy systemu to też ważna kwestia informatyczna. Przecież system żyje, a zgodnie z przytoczonym przez Ciebie zdaniem: bezpieczeństwo to proces, nie produkt. Pojawiają się problemy - dostawca powinien zareagować, odpowiednią korekcją systemu. System powinien być zaprojektowany tak, aby łatwo można określić przyczynę (logowanie informacji o zdarzeniach w systemie, możliwość włączenia dodatkowych trejsów podczas odtwarzania sytuacji która spowodowała błąd, etc. ). Dostawca powinien mieć infrastrukturę (specjaliści, środowiska testowe), która pozwolą sprawnie zareagować na różne nieprzewidziane sytuacje. System to nie tylko software, ale związana z nim dokumentacja projektowa. Jaki system będzie bezpieczny, jeśli dokumentacja będzie słabej jakości, albo podczas konserwacji/rozbudowy zacznie się "rozjeżdzać" z rzeczywistą implementacją? Dalsza rozbudowa czy poprawianie błędów będzie obarczone dużym ryzykiem, szczególnie gdy będzie zajmować sie tym firma trzecia.

Na koniec kilka uwag do sformułowań w tekście:

  • Istnieją dwa podstawowe nurty w walce z zagrożeniami bezpieczeństwa. Pierwszym z nich jest możliwie skuteczne zapobieganie powstawaniu takich usterek. (wyboldowania moje) Gdzie jest opisany drugi nurt? I w ogole jakich usterek?
  • Świadczy o tym choćby odnalezienie wielu podatności w tworzonych przez ekspertów programach OpenSSL czy OpenSSH. Podatności na co? To sformuowanie wydaje mi się, niezręczne.

Pan Camel 09:35, 8 paź 2006 (CEST)

  • Dzięki za uwagi. Kolejno: 1) Omówione zostały metody testowania stosowane w badaniu podatności aplikacji; tak jak pisałem wyżej, wydaje mi się, że ten artykuł nie powinien opisywać procesów QA w dużych firmach, bo to zdecydowanie poza zakresem jego "kompetencji" (gdybyśmy mieli dobry artykuł o QA, można dodać zdanie w stylu "Procesy te są zwykle elementem...", aczkolwiek już chyba coś w tym stylu i tak mamy, z czerwonym linkiem); 2) To już rozważania teoretyczne, ale jak dobrze pewnie wiesz, nie ma ;-) Tzn. zapewnianie bezpieczeństwa, ponieważ wymaga implementowania procesów, szkolenia programistów i płacenia im więcej za staranniejsze pisanie, jest i będzie wrogiem redukcji kosztów; dopóki producent nie czuje na swoich plecach presji ze strony użytkowników lub organów ustawodawczych, będzie jak jest; o procesach biznesowych, znowu, można wspomnieć, tylko że... no właśnie, nie ma do kąd linkować :-); 4) Pomyślę, czy można to jakoś ładnie wpleść, aczkolwiek wtedy trochę wypuszczamy kota z worka... ale OK, myślę... 5) Oczywiście, że support jest ważny, ale znowu, to jest kwestia zarządzania ryzykiem i ciągłością biznesową, stosownych umów i procesów, a nie zabezpieczania systemów od strony technologicznej. Tzn. moim zdaniem powinniśmy mieć oddzielne artykuły o tych tytułach i tam rozwijać temat. 6) Uwaga o dwóch nurtach - są omówione dwa, projektowanie i zarządzanie; 7) Ok, rzucę okiem, aczkolwiek "podatność" jest po prostu przyjętym u nas spolszczeniem pojęcia "vulnerability", więc może być rozumiane jako "błędy pozwalające na naruszenie bezpieczeństwa aplikacji". -- (lcamtuf) 10:50, 8 paź 2006 (CEST)
Źródło: „https://pl.wikipedia.org/w/index.php?title=Wikipedia:Propozycje_do_Artykułów_na_Medal/Bezpieczeństwo_teleinformatyczne&oldid=73344712”