Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

BDD-Security

No description
by

Krystian Piwowarczyk

on 27 November 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of BDD-Security

bezpieczeństwo
Zautomatyzowane testy bezpieczeństwa
oparte o techniki BDD
BDD-Security
Prepared by: Krystian Piwowarczyk
Submitted on: 25.11.2014
Version: 1.2
$ whoami
Krystian Piwowarczyk (mów mi bro)
Pentester/Researcher w Vector Synergy Używam lustrzanych emotikonek (-;

„System jest bezpieczny wtedy i tylko wtedy, gdy uruchomiony jest on w stanie bezpiecznym i nie może przejść do stanu niebezpiecznego.”

Q&A
„Minion is a security testing framework built by Mozilla to bridge the gap between developers and security testers. To do so, it enables developers to scan their projects using a friendly interface.”

Zestaw wrapperów na narzędzie takie jak m.in. : OWASP ZAP, Skipfish, nmap

… ale to temat na inną prezentację (-;
BDD-Security też jest formą/próbą uporządkowania testów bezpieczeństwa. Tyle, że poprzez ubranie je w czytelne dla większego grona scenariusze testowe i ukrycie pod nimi właściwej implementacji.

BDD-Security
podsumowanie
BDD-Security
teoria
[Tworzenie bezpiecznego oprogramowania]* jest jak seks nastolatków. Wszyscy mówią, że to robią. Wszyscy myślą, że inni robią to lepiej. Ci, którzy rzeczywiście to robią, robią to źle.
* lub BigData, TDD, Agile, Java, C++ itd.
naglący czynnik ekonomiczny
brak zasobów
brak wiedzy
Domain Specific Language aims at bridging the communication gap between domain experts and developers by binding business readable behavior specifications and examples to the underlying implementation.

Jeśli Domain Specific Language jest wystarczająco dobry, żeby biznes pisał wymagania to jest też wystarczająco dobry, żeby experci z domeny Security zdefiniowali przy jego użyciu scenariusze.

Problem związany z komunikacją nie występuje wyłącznie na styku biznesu i developmentu.
Testy penetracyjne to bardzo luźna dziedzina. Dynamiczna (nawet bardziej niż sam rozwój oprogramowania), przez co trudna do uporządkowania. Dopiero na przestrzeni ostatnich lat pojawiły się próby standaryzacji testów bezpieczeństwa:
BDD-Security praktyka
Początkujący pentesterzy miewają problemy z zebraniem (wyselekcjonowaniem) informacji wartościowych dla ich klientów
„To co, że nie ma listy zaleceń. Za to mój proof-of-concept ataku na Apacha jest niesamowity!”.
Penetration Testing Execution Standard
dla pentestów jako takich
OWASP Testing Guide
,
OWASP ASVS
(Application Security Verification Standard),
OWASP Top 10
dla testów aplikacji internetowych
EVIL User Stories
BDD-Security nie obala Seven testing principles, ale pomaga osłabić siłę kilku zasad. O ile oczywiście firma zdecyduje się na zmianę myślenia i wdrożenie odpowiednich kroków do SDLC
Seven testing principles tyczy się oczywiście też testowania bezpieczeństwa (tego typowego, non BDD-Security).
bazuje na jBehave
BDD-Security fakty:
autorstwa Stephena de Vriesa (resty-Burp!)
rozwijany od prawie 3 lat (luty 2012) – ostatni commit sprzed miesiąca, więc projekt nadal żyje
obecnie w wersji 0.7
wspiera Firefoxa (słabiej) i Chroma (lepiej)
Czas na puszczanie filmików (-:

Wymagania BDD-Security:
„Jakich narzędzi użyć, o co poprosić Pentestera i
czego nauczyć Inżynierów z działu QA, aby każdego ranka cieszyć się z miarodajnego raportu dotyczącego poziomu bezpieczeństwa rozwijanej aplikacji webowej?”
Czego nauczyć Inżynierów z działu QA?
A: Dać im wiedzę z zakresu bezpieczeństwa aplikacji internetowych.

Czy BDD-Security może się spopularyzować?
Resty Burp - A REST/JSON API to the Burp Suite security tool.

Pozwala na bardzo wygodny dostęp do Burp’a, czyli do znacznie bardziej rozbudowanego kombajnu niż OWASP ZAP. Resty Burp nie został zintegrowany w BDD-Security przede wszystkim dlatego, że współpracuje jedynie z płatną, wypasioną wersją Burp Suite.
Efektywność
Automatyzacja
Komunikacja
Przesadna ekscytacja technologią
samą w sobie
Prosty pomysł: weźmy jBehave, dodajmy możliwość zaglądania do HTTP, dodajmy komunikację z ZAP’em, piszmy scenariusze testujące bezpieczeństwo.
Dlaczego to ma mieć sens? Nie lepiej użyć gotowych narzędzi do testowania podatności?
Więc trzeba poświęcić czas na przygotowanie scenariuszy? To wymaga sporo pracy.

Testy bezpieczeństwa klasy Enterprise – dostosowane do projektu, głęboko z nim powiązane i powtarzalne
Testing shows the presence of bugs
Exhaustive testing in impossible
– zwłaszcza kiedy automaty nie są po prostu świadome przepływu danych w systemie
Early testing
– audyt na etapie „skończyliśmy development teraz fixujemy bugi i robimy premierę” to czasem za późno
Defect clustering
– miejsca takie jak zarządzanie sesją, styk z bazą danych, warstwa prezentacji danych to typowe gniazda podatności
The pesticide paradox
– krótka lista payloadów XSS i SQLi może dawać mylne wrażenie bezpieczeństwa
Testing is context dependent
Absense of errors fallacy
– system może być jednocześnie bezpieczny i niezdatny do użytku
Testing shows the presence of bugs
Exhaustive testing in impossible
– testy szyte na miarę mogą znaleźć przepływy, które w typowym audycie pozostałyby nierozpoznane
Early testing
– chyba nie wymaga wyjaśnień
Defect clustering -
predefiniowane scenariusze
The pesticide paradox
– scenariusze wyszukujące XSS i SQLi można podpiąć do wspólnego źródła payloadów, (fuzzdb to the rescue!)
Testing is context dependent
– testy szyte na miarę są bardzo context dependent (-;
Absense of errors fallacy
Zalety:
ma dostęp do poziomu HTTP
dogaduje się z OWASP ZAP (skanowanie)
pozwala się relatywnie łatwo zintegrować do procesu CI
pozwala na przygotowanie szczegółowych i powtarzalnych testów dla konkretnej platformy
posiada wiele wbudowanych scenariuszy
scenariusze mają dużą reużywalność między projektami
ma wartość edukacyjną
korzysta z Page Object Pattern
niszowy produkt (dla hipsterów oprogramowania)
testuje TLS/SSL - Heartbleed & POODLE
Wady:
brak obsługi czegoś mniejszego/lżejszego phantomjs?
słaba reklama (-;
niszowy produkt (dla niehipsterów oprogramowania)
open source
wymaga przygotowania scenariuszy – potrzebna jest wiedza i potrzebny jest czas, a obie rzeczy kosztują
Jesteś tutaj (-:
JDK >= 1.6

Apache Ant >= 1.6
OWASP ZAP - najnowszy
Jakich narzędzi użyć?
A: BDD-Security oraz inne, podobne koncepcje (Mozilla Minion)
O co poprosić Pentestera?
A: O wysoko-poziomowe scenariusze. O stałe konsultacje lub dołączenie do projektu na pewien czas.
open source
jeśli jakimś cudem nie chrypię (-:
Full transcript