Tanya Janca (She hacks purple) hat ihre Firma “We hack purple” an Bright verkauft, einem Hersteller eines SAST-Tools. Das wäre nun nichts so tolles, aber ihre Kurse, wie man Application Security angeht, sind nun KOSTENFREI und kosteten vorher mehrere hundert Dollar/Kurs! (Quelle)
Tanyas Buch „Alice & Bob learn Application Security“ (Wiley) hilft sehr gut in das Thema Application Security einzutauchen, daher sind ihre Kurse ebenfalls für Einsteiger gut geeignet.
Das drahtlose Netzwerk in unserem Haus wird von mir immer als unsicher angesehen, da ich der „Sicherheit“ dieser Art der Datenübertragung grundsätzlich mistraue. Wer einmal gesehen hat, wie leicht man sich mittels einiger kleiner Werkzeuge Zugang zum WLAN des Nachbarn verschaffen kann, der weiß was ich meine. Selbst der Standard WPA3 hat nichts daran geändert.
Nun habe ich zumindest mal nzyme installiert, was nun sich noch etwas justieren muss, aber dazu dient, damit man potenzielle Angriffsversuche von außen auf das WLAN angezeigt bekommt. Es ist ein Wifi-Intrusion-Detection-System (WIDS) als Ergänzung zu meiner UTM Appliance (Unified Threat Management), welches diese Services alles abdeckt: Internet-Gateway, Firewall, Virtual Private Network (VPN) Gateway, Virus Protection, Intrusion Detection System, Contentfilter, Spam Protection, Endpoint Protection, Surf Protection, Authentifizierung, Quality of Service (QoS) und Reporting.
Bei mir ist alles wichtige gekabelt und hinter der UTM. Der NAS (Network Attached Storage) und DSL-Zugang sind nicht von außen erreichbar und alles an Zusatzprodukten ist abgeschaltet, schon immer. So empfiehlt es auch die c’t in ihrem Heftchen c’t Security Tipps, woher ich auch die Anleitung genommen habe – und funzt einwandfrei.
Ich werde über meine Erfahrungen berichten. Bei mir läuft es auf einem Raspberry Pi 4 (wo schon Pi-Hole und Flightradar24 drauf laufen). Die Antenne ist eine Alfa AWUS036H mit Realtek RTL 8187L-Chipsatz.
Ich habe seit Ende 2016, auf Basis von Informationen, die hauptsächlich von Declan O’Riordan stammen, angenommen, die Grundidee der Interactive Application Security Testing Technik beruhe auf dem Metadata Facility Framework, welches unter dem JSR 175 in Java eingeführt wurde. Matthias Rohr hielt am 23. Oktober 2019 einen Vortrag im Rahmen des OWASP Stammtisches in Hamburg und war über meine Nachfrage, warum er dies unerwähnt gelassen habe, sehr verwundert, da er nur die Instrumentierung des Codes als Schlüssel zum Erfolg darstellte, und so habe ich Jeff Williams, Gründer und (Mit-) Erfinder der Technik und eines der IAST-Tools, direkt via LinkedIn angefragt und die korrigierende Aussage am 27. November 2019 bekommen:
„Hi Jogi – we don’t use JSR175. We use standard Java Instrumentation API. That’s the breakthrough innovation that enabled Contrast to exist. We use all our own sensors and analysis engine on top of that API. We had to invent different instrumentation techniques for .NET, .NET core, Node.js, Ruby and Python.“
Jeff Williams, Co-Founder and CTO at Contrast
Nun, an den Ergebnissen der Technik ist in meinen Präsentationen nichts falsch, da ich sie ja auch selber durchgeführt habe, nur ist es eben etwas anderes, wenn man durch Code-Instrumentierung Aktionen auslöst (Dtrace, den Tracer von Sun, den ich immer als Vergleich auf Betriebsystemebene herangezogen habe, macht dieses nämlich auch!) oder „mitlaufende“ Metadaten analysiert werden. Der Code wird zur Laufzeit in dem Application Container „angefasst“ (verändert) während das bspw. bei Ausnutzung der JSR 175 nicht unbedingt notwendig gewesen wäre, da die Metadaten ja „mitlaufen“.
Danke an Matthias Rohr für den Hinweis, der mich dazu nötigte meine unreflektierte Übernahme einer Aussage nun zu korrigieren. Ich werde die Dokumente, sofern sie unter meiner Kontrolle sind, entsprechend anpassen.
Security Testing durch Instrumentierung verspricht bei DevSecOps bessere und schnellere Ergebnisse als gängige Scan-Verfahren. Erfahren Sie in Theorie und Praxis, was hinter der Methode steckt.
Scannen Sie noch oder instrumentieren Sie schon? Denn neue Test-Methoden können die Anwendungssicherheit während der Entwicklung und im laufenden Betrieb effizient steigern. Hören Sie nicht nur die Theorie vom Hersteller, sondern auch den Praxisbezug des QA-Spezialisten Jörg Sievers von der Ponton GmbH in Hamburg und seine Erfahrungen mit neuen Security-Testmethoden aus Anwendersicht.
Quellcode zu scannen (Static Application Security Testing, SAST) und Anwendungen dynamisch zu testen (Dynamic Application Security Testing, DAST) sind wichtige Bestandteile funktionierender DevSecOps-Prozesse, generieren jedoch zu viele Falschmeldungen oder liefern nicht ausreichend Ergebnisse. Weiterhin ist Scanning mittels SAST sehr zeitintensiv oder DAST benötigt Experten zum Vorbereiten von Tests und deren Interpretation. Manuelles Pentesting kommt schon aus Zeitgründen nicht jedes Mal zum Einsatz.
Für DevOps, die ShiftLeft-Methodology und mehrfaches Deployment am selben Tag sind Interactive Application Security Testing (IAST) und Runtime Application Self-Protection (RASP) wesentlich besser geeignet. IAST und RASP ermöglichen zeitnah akkurat Ergebnisse für unterschiedliche Anwenderrollen in den jeweils präferierten Werkzeugen.
Wir freuen uns auf Ihre Teilnahme!
Ihre Referenten:
Mirko Brandner Jörg Sievers
Senior Sales Engineer / QA Specialist
Technical Evangelist Ponton GmbH
Contrast Security
Quelle: https://www.security-insider.de/agile-applikationssicherheit-in-echtzeit-fuer-devops-v-41422-12645/
