Użytkowniku, nie hakuj naszych aplikacji

Jeśli ktoś zastanawiał się, jaki stosunek ma CSO Oracle, Mary Ann Davidson, do wyszukiwania przez klientów podatności w oprogramowaniu tej firmy, wszelkie wątpliwości rozwiązał jej wpis na firmowym blogu z 10 sierpnia.

W skrócie, jego autorka pisze, iż klientom lub zatrudnionym przez nich ekspertom nie wolno przeprowadzać oceny kodu oprogramowania Oracle pod kątem potencjalnych luk w bezpieczeństwie, a producent w wystarczającym stopniu zabezpiecza swoje produkty. Wpis został szybko usunięty przez Oracle, ale jego kopie wciąż można znaleźć w Internecie, np. na stronie http://seclists.org/isn/2015/Aug/4.

Widać rosnącą liczbę badaczy oraz przedsiębiorstw testujących oprogramowanie pod kątem luk w bezpieczeństwie. Z uwagi na obawy dotyczące bezpieczeństwa, firmy przeprowadzają analizy używanych przez siebie aplikacji, a rosnąca rzesza ekspertów od bezpieczeństwa bada oprogramowanie korporacyjne w poszukiwaniu podatności. Częściowo to większe zainteresowanie wykrywaniem luk wynika z zainicjowania programów z nagrodami za wykrycie błędów w aplikacjach. Organizują je producenci oprogramowania, którzy oferują finansowe zachęty dla tych, którzy wykryją nowe podatności. Takie programy uruchomiły bardzo różne firmy zajmujące się tworzeniem oprogramowania od Twittera po Teslę.

Zobacz również:

Oracle zdystansował się od wypowiedzi swojej pracowniczki, wysyłając oficjalne oświadczenie do prasy. „Bezpieczeństwo naszych produktów i usług zawsze było bardzo ważne dla Oracle. Nasza firma ma rozbudowany program zapewniania bezpieczeństwa naszych produktów i współpracuje z zewnętrznymi badaczami oraz klientami, aby wspólnie poprawiać bezpieczeństwo technologii Oracle. Wpis został usunięty, ponieważ nie odzwierciedla naszych przekonań i relacji z klientami” – czytamy w oświadczeniu wypowiedź Edwarda Screvena, wiceprezesa Oracle.

Tymczasem wpis pani Davidson odbił się szerokim echem w branży bezpieczeństwa IT. Uznano za bardzo aroganckie przekonanie, że jeden producent jest w stanie zapewnić swoim klientom wystarczającą i odpowiednią ochronę przed hakerami. A przecież dla osób zajmujących się bezpieczeństwa od lat jest oczywistą sprawą, że cyberwłamywacze prowadzą dokładne analizy kodu poprzedzone inżynierią wsteczną. Ignorowanie tego faktu tylko dlatego, że przedstawiciel producenta uważa, że wszystko jest pod kontrolą, byłoby bardzo nierozsądne, żeby nie powiedzieć szalone.

Pojawiły się też głosy w obronie pani Davidson. Niektórzy eksperci uważają, że przedstawione argumenty zostały dobrze dobrane, choć nie pozbawione wad, a sam wpis został dobrze napisany, utrzymany w luźnym tonie. Jeśli pominąć na chwilę poglądy dotyczące licencji EULA, to faktycznym problemem CSO w dużej firmie okazało się, że odważne stwierdzenie na temat głównych kwestii bezpieczeństwa spotkało się z publiczną krytyką ze strony pracodawcy.

W podobnym tonie wypowiedział się Andrew van der Stock‪, kierownik projektu w OWASP Foundation: „Zgadzam się, że konieczne jest znalezienie lepszych sposobów zgłaszania podatności. Powinno wystarczyć samo przesłanie raportu wygenerowanego przez Veracode czy Nessusa bez weryfikowania, czy faktycznie ma on sens. Zgadzam się również z nią, że firmy powinny przede wszystkim zwracać uwagę na swoich pracowników. Jeśli jednak klient wykryje lukę w używanym przez z siebie oprogramowaniu, powinien przesłać informację o niej do producenta, za co absolutnie powinien zostać wynagrodzony, a nie karcony upominawczymi listami od producenta. Podsumowując, zgłaszanie podatności powinno się odbywać bez weryfikacji (Proof of Concept) i listownego nękania.”‬

Niektórzy mogą się z tym nie zgodzić. Z wypowiedzi twórców oprogramowania wynika, że nie brakuje osób korzystających z narzędzi do analizy oprogramowania, które zgłaszają raporty o wykrytych błędach okazujące się jedynie fałszywymi alarmami. Niestety tak jest w każdej profesji, że są „oszołomy”, jak i wysoko wykwalifikowani specjaliści z dobrymi intencjami, których pomoc jest nieoceniona. Niezależnie od tego, jak irytujące może być sprawdzanie zgłoszeń o wykrytych błędach, Oracle powinien reagować adekwatnie do sytuacji. Jest to bardzo duży i bogaty producent, którego produkty są powszechnie stosowane w firmach do obsługi krytycznych aplikacji. Popularność zobowiązuje do dołożenia wszelkich starań w celu poprawy bezpieczeństwa. Duża liczba fałszywych alarmów i koszty związane z ich analizą to cena za dużą popularność oprogramowania i koszt prowadzenia biznesu. Z pewnością wszyscy duzi producenci oprogramowania mają analogiczny problem i dotychczas nie słychać ich narzekań.

Gene Spafford, profesor informatyki na Purdue University powiedział, że producenci oprogramowania większość wysiłków związanych z wykrywaniem podatności przenieśli na siebie. „Jeśli producenci faktycznie zastosowaliby wszystko to, co wiemy o budowaniu solidnych, bezpiecznych aplikacji – włączając w to projektowanie, testowanie oraz wdrożenie – wypowiedź Mary Ann Davidson brzmiałaby dość sensownie. Niechlujstwo i wyścig, aby jak najszybciej wprowadzić produkt na rynek w połączeniu z tworzeniem niekorzystnych dla użytkowników licencji sprawiły, że zbudowaliśmy kulturę, w której wiele osób i organizacji czuję potrzebę samodzielnego przetestowania wszystkiego”, powiedział Spafford.

„Gdyby wpis został zakończony stwierdzeniem, że prosimy o dalsze przesyłanie zgłoszeń o błędach, które chętnie poprawimy, ale prosimy nie nadsyłać 500 stron niepotwierdzonych analiz, byłby łatwiejszy do zaakceptowania”, powiedział David Litchfield,‪ ekspert i badacz zajmujący się bezpieczeństwem oprogramowania w firmie Datacom TSS, który jest znany z tego, że znalazł wiele podatności w oprogramowaniu Oracle.


TOP 200