Pragmatic view on Electronic Signature directive 1999 93Pawel Krawczyk
Discussion of legal and technical issues with EU Directive 1999/93/EC that prevented it from being adopted by European market. See http://ipsec.pl/ for more details.
Are electronic signature assumptions realisticPawel Krawczyk
A retrospective analysis of basic legal and technical assumptions that were laid at base of EU Directive 1999/93/EC on electronic signatures and subsequent technical standards (CWA). See http://ipsec.pl/ for more details.
Pragmatic view on Electronic Signature directive 1999 93Pawel Krawczyk
Discussion of legal and technical issues with EU Directive 1999/93/EC that prevented it from being adopted by European market. See http://ipsec.pl/ for more details.
Are electronic signature assumptions realisticPawel Krawczyk
A retrospective analysis of basic legal and technical assumptions that were laid at base of EU Directive 1999/93/EC on electronic signatures and subsequent technical standards (CWA). See http://ipsec.pl/ for more details.
PLNOG14: Analiza obecnych zagrożeń DDoS według najnowszego raportu bezpieczeń...PROIDEA
Marek Karczewski - Radware
Language: Polish
2014 był rokiem przełomowym w dziedzinie bezpieczeństwa. Ataki cybernetyczne osiągnęły punkt krytyczny pod względem ilości, złożoności oraz celów ataków. Sytuacja zaskoczyła nawet firmy, które posiadały “wzorcowe” systemy i mechanizmy ochrony.
Raport firmy Radware „Bezpieczeństwo Aplikacji i Sieci 2014” prezentuje kompleksowy i obiektywny przegląd ataków cybernetycznych w 2014 r. z perspektywy biznesowej i technicznej oraz określa zestaw najlepszych praktyk dla organizacji planujących ochronę przed atakami w 2015 r.
Zarejestruj się na kolejną edycję PLNOG już teraz: krakow.plnog.pl
Krótka historia obejmująca zarówno koncepcje jak i dane na temat tego jak tworzymy, składujemy i konsumujemy informacje we współczesnym środowisku chmurowym
OWASP Mobile TOP 10 na przykładzie aplikacji bankowych - Semafor 2016 - Mateu...Logicaltrust pl
Wnioski z technicznego badania kilkudziesięciu polskich aplikacji bankowych przeznaczonych na platformy Android oraz iOS pod kątem występowania w nich podatności z OWASP Mobile TOP 10. Prezentacja rzeczywistych błędów w oprogramowaniu mobilnym, praktycznych porad jak zabezpieczyć aplikacje oraz odniesienie uzyskanych rezultatów do badań przeprowadzonych w innych krajach.
Większość banków stosuje w swoich systemach bankowości internetowej i mobilnej metody autoryzacji transakcji (np. hasła SMS, "podpis elektroniczny", tokeny OTP, tokeny challenge-response). Stosowanie tego typu metod nie jest ograniczone tylko do systemów finansowych, są np. szeroko stosowane do autoryzowania operacji odzyskiwania hasła w różnego rodzaju aplikacjach.
Autoryzacja transakcji ma ograniczać skutki wynikające z działania wrogiego oprogramowania na stacji użytkownika, przechwytywania sesji oraz zgadywania czy kradzieży haseł.
W ostatnich latach widzimy jednak, że strategie działania grup przestępczych dostosowują się do tych zabezpieczeń i niejednokrotnie skutecznie je omijają. Prezentacja ma na celu skonfrontowanie obecnych metod autoryzacji operacji ze współczesnymi scenariuszami ataku przy użyciu malware oraz wskazanie typowych błędów w implementacji, które mogą przyczynić się do możliwości obejścia tych zabezpieczeń.
Agenda (draft):
- Krótka prezentacja metod autoryzacji transakcji.
- Kilka "case study" - jak malware obchodzi autoryzacje transakcji (w tym własne doświadczenia zdobyte podczas analizy przypadków ataków w bankach).
- Jak wybrać skuteczną metodę autoryzacji transakcji?
- Na co uważać? Typowe błędy implementacji, które mogą przyczynić się do osłabienia mechanizmu autoryzacji transakcji.
Docker, Jenkins, network topology, system configuration and software delivery management - all of these are the bread and butter of each DevOps team, but can be also a recipe for a disaster. Walk through the most devastating security failures in DevOps environments I've seen in real life, including network architecture, security controls design and implementation.
This is a security awareness presentation on impact of developing and using insecure applications in organisations. Number of case studies of data leaks, defacements and regulatory fines are presented as example.
PLNOG14: Analiza obecnych zagrożeń DDoS według najnowszego raportu bezpieczeń...PROIDEA
Marek Karczewski - Radware
Language: Polish
2014 był rokiem przełomowym w dziedzinie bezpieczeństwa. Ataki cybernetyczne osiągnęły punkt krytyczny pod względem ilości, złożoności oraz celów ataków. Sytuacja zaskoczyła nawet firmy, które posiadały “wzorcowe” systemy i mechanizmy ochrony.
Raport firmy Radware „Bezpieczeństwo Aplikacji i Sieci 2014” prezentuje kompleksowy i obiektywny przegląd ataków cybernetycznych w 2014 r. z perspektywy biznesowej i technicznej oraz określa zestaw najlepszych praktyk dla organizacji planujących ochronę przed atakami w 2015 r.
Zarejestruj się na kolejną edycję PLNOG już teraz: krakow.plnog.pl
Krótka historia obejmująca zarówno koncepcje jak i dane na temat tego jak tworzymy, składujemy i konsumujemy informacje we współczesnym środowisku chmurowym
OWASP Mobile TOP 10 na przykładzie aplikacji bankowych - Semafor 2016 - Mateu...Logicaltrust pl
Wnioski z technicznego badania kilkudziesięciu polskich aplikacji bankowych przeznaczonych na platformy Android oraz iOS pod kątem występowania w nich podatności z OWASP Mobile TOP 10. Prezentacja rzeczywistych błędów w oprogramowaniu mobilnym, praktycznych porad jak zabezpieczyć aplikacje oraz odniesienie uzyskanych rezultatów do badań przeprowadzonych w innych krajach.
Większość banków stosuje w swoich systemach bankowości internetowej i mobilnej metody autoryzacji transakcji (np. hasła SMS, "podpis elektroniczny", tokeny OTP, tokeny challenge-response). Stosowanie tego typu metod nie jest ograniczone tylko do systemów finansowych, są np. szeroko stosowane do autoryzowania operacji odzyskiwania hasła w różnego rodzaju aplikacjach.
Autoryzacja transakcji ma ograniczać skutki wynikające z działania wrogiego oprogramowania na stacji użytkownika, przechwytywania sesji oraz zgadywania czy kradzieży haseł.
W ostatnich latach widzimy jednak, że strategie działania grup przestępczych dostosowują się do tych zabezpieczeń i niejednokrotnie skutecznie je omijają. Prezentacja ma na celu skonfrontowanie obecnych metod autoryzacji operacji ze współczesnymi scenariuszami ataku przy użyciu malware oraz wskazanie typowych błędów w implementacji, które mogą przyczynić się do możliwości obejścia tych zabezpieczeń.
Agenda (draft):
- Krótka prezentacja metod autoryzacji transakcji.
- Kilka "case study" - jak malware obchodzi autoryzacje transakcji (w tym własne doświadczenia zdobyte podczas analizy przypadków ataków w bankach).
- Jak wybrać skuteczną metodę autoryzacji transakcji?
- Na co uważać? Typowe błędy implementacji, które mogą przyczynić się do osłabienia mechanizmu autoryzacji transakcji.
Docker, Jenkins, network topology, system configuration and software delivery management - all of these are the bread and butter of each DevOps team, but can be also a recipe for a disaster. Walk through the most devastating security failures in DevOps environments I've seen in real life, including network architecture, security controls design and implementation.
This is a security awareness presentation on impact of developing and using insecure applications in organisations. Number of case studies of data leaks, defacements and regulatory fines are presented as example.
7. TECHNIKI UWIERZYTELNIANIA
Sektor publiczny Sektor prywatny
Podpis kwalifikowany Hasła statyczne (~2000)
(2001-2010) Hasła jednorazowe
Wysoki poziom (~2002)
bezpieczeństwa
Hasła SMS (~2005)
8. DOSTĘP DO USŁUG
ELEKTRONICZNYCH W POLSCE
Sektor prywatny Sektor publiczny
• „Wystarczający poziom bezpieczeństwa” • „Wysoki poziom bezpieczeństwa”
• 2010 – 8,4 mln • 2010 – 250 tys.
– 22% obywateli – 0,94% obywateli
Dostęp do usług elektronicznych w Polsce
10000
8000
Liczba użytkowników [tys]
6000
4000
2000
0
2001 2002 2003 2004 2005 2006 2007 2008 2009 2010
Rok
9. BEZPIECZEŃSTWO A REGULACJA (*)
Kilka rozpowszechnionych mitów
„Bezpieczeństwo jest najważniejsze”
Ale 100% bezpieczeństwa = 0% aktywności
Każde działanie stanowi kompromis bezpieczeństwa
„Więcej bezpieczeństwa to lepiej”
Ale to także większy koszt i mniejsza efektywność
„Tylko X zapewni wysoki poziom bezpieczeństwa”
Ale czy tutaj potrzebujemy wysokiego poziomu?
10. GWARANCJE NA OPROGRAMOWANIE
• Niezawodne oprogramowanie istnieje
– Formalne metody dowodzenia poprawności kodu
– ADA SPARK, JOVIAL, SPIN, systemy klasy „trusted”
– BNF, ASN.1
• Ale tworzenie go jest bardzo kosztowne
– Common Criteria EAL2 – od 50 tys. €, 12 miesięcy
– Common Criteria EAL4 – od 150 tys. €, 18 miesięcy
• Czy chcemy powszechnych gwarancji na
oprogramowanie?
– Ja nie chcę! Wolę program za 300 zł, który działa wystarczająco
dobrze
11. DROGA DO RACJONALNOŚCI
Analiza ryzyka
Co mamy? Przed czym to chcemy chronić?
Ile kosztuje ryzyko? Ile kosztują zabezpieczenia?
Analiza kosztów i korzyści (cost-benefit
analysis)
Techniki
Drzewa decyzyjne (decision trees)
Applied Information Economics
12. PRZYKŁAD – WIRUSY
Skutki infekcji wirusa Skutki antywirusa
Sieć 1000 użytkowników Sieć 1000 użytkowników
6 godzin przestoju/osobę Strata 5 minut/dzień
3 roczne etaty
5000 min/dzień
Naprawa 10 rocznych etatów
0,12 rocznego etatu
Koszt: 440 tys. zł
Koszt: 130 tys. zł
Rocznie
Za jeden incydent!
13. PRZYKŁAD – SZYFROWANIE
DYSKÓW 1000 UŻYTKOWNIKÓW
60 kradzieży laptopów rocznie Full-Disk Encryption
Średnio 80 rekordów Roczna licencja 53 zł/laptop
osobowych/laptop Koszt licencji
Koszt obsługi 1 rekordu 53 tys. zł
Koszt wsparcia technicznego
115 zł
12 tys. zł
Roczny koszt incydentów
552 tys. zł
14. WSKAŹNIKI DO OCENY RACJONALNOŚCI
EKONOMICZNEJ
• Zwrot z inwestycji
– ROI - Return on Investment
• Zwrot z inwestycji w bezpieczeństwo
– ROSI – Return on Security Investment
– Inne danych wejściowe, to samo znaczenie
• Wynik – mnożnik zainwestowanego kapitału
15. ROI VS ROSI
G – „jak bardzo ograniczymy E – koszt ingorowania ryzyka
straty?” [zł] [zł]
C – koszt zabezpieczenia [zł] Sm – skuteczność
zabezpieczenia [%]
Sc – koszt zabezpieczenia
[zł]
17. PRZYKŁAD – LOGISTYKA (ROI)
Prognozowane
Zabezpieczenie "Zysk" Koszt ROI
straty roczne
Żadne € 75,000.00 € 0.00 € 0.00 0.00
Eskorta ochrony € 1,000.00 € 74,000.00 € 100,000.00 -0.26
Telemetryka € 2,000.00 € 73,000.00 € 1,000.00 72.00
18. WYZWANIA
• Skąd dane wejściowe?
– Własne dane historyczne, tablice aktuarialne, SLA
dostawców, statystyki branżowe
• Dane obarczone dużym poziomiem niepewności
– Średnia, mediana, odchylenie standardowe
– Przedziały minimum-maksimum (widełki)
– Rząd wielkości
• Co wpływa na jakość wskaźnika?
– Analiza ryzyka
– Koszty incydentów
– Koszty zabezpieczeń
19. WYZWANIA – KOSZTY INCYDENTÓW
Utracone korzyści
Czas pracy, naruszenia SLA
Kary i odszkodowania
Monitoring, odszkodowanie, kary za zaniedbania, kary za
naruszenie SLA
Koszty naprawy i śledztwa
Personel wew/zew, narzędzia śledcze
21. ZALETY
• Możliwość porównania racjonalności ekonomicznej
– Podobnych zabezpieczeń
• Antywirus A versus antywirus B
– Różnych zabezpieczeń
•Edukacja użytkowników versus system wykrywania
wycieków danych (DLP)
• Obiektywizacja kryteriów wyboru zabezpieczeń
• Fakty zamiast ogólników
– „zważywszy na niniejsze wydaje się iż pewne przesłanki mogą
wskazywać na zasadność, jednakże...”
• Uzasadnienie zmiany jeśli zmienią się warunki
wejściowe