zurück zur Übersicht

The State of Application Security 2017 – geht’s schon besser?

Application Security Testing ist mehr als die Suche der Nadel im HeuhaufenApplication Security ist manchmal ein umstrittenes Thema. Einige, vor allem die aus der Security Ecke, sagen, dass sich der Sicherheitsstand der Anwendungen mit der Zeit kaum geändert hat. Hingegen behaupten manche Architekten und Entwickler: Doch, der Fortschritt ist sichtbar und messbar, da in der modernen Entwicklung an Sicherheit schon ab der Design-Phase gedacht wird.

Was zeigt aber die Praxis? Veracode, ein führender Lösungsanbieter im Bereich Application Security Testing, hat dazu einen interessanten Bericht vorgelegt.

Die ausgewerteten Daten wurden in der Cloud gesammelt und stammen aus mehr als 400 000 statischen und dynamischen Scans, die in den letzten 12 Monaten durchgeführt wurden.

Eine komplette Analyse wäre an dieser Stelle zu viel des Guten. Stattdessen gehen wir gleich zu den interessantesten und überraschendsten Ergebnissen.

Interessante Findings

  • Fast 50% der Issues bleiben mehr als 90 Tage geöffnet.

Dies kann verschiedene Ursachen haben. Die Mehrheit der Findings hat eine niedrige Kritikalitätsstufe, es ist anzunehmen, dass hier einfach die Prorität zurückgestuft wurde. Allerdings ist in manchen Fällen auch das Gegenteil der Fall: Es ist möglich, dass die Problembehebung und Klärung vor allem bei Architektur- und Infrastrukturschwachstellen nicht in der Macht eines Teams liegt, oder eine längere Diskussion bzw. aufwändigere Workarounds oder gar eine Neustrukturierung der Architektur erforderlich sind.

  • Mehr als 30% der Anwendungen bestehen die OWASP TOP 10 Prüfung.

Die Zahl ändert sich natürlich jedes Jahr, jedoch nicht radikal. Ein externer Faktor ist, dass ungefähr alle drei Jahre eine neue OWASP Top 10 Liste kommt, in der potenziell neue Schwachstellen priorisiert werden können. Dennoch ist das eine recht passable Quote.

  • Externe Anwendungen erreichen weniger gute Punkte als Eigenentwicklungen.

Dies sollte nicht überraschend sein, da eigene Anwendungen von vornherein interne Sicherheitslinien erfüllen und oft einen Testprozess durchlaufen müssen. An die externen Anwendungen werden zwar manchmal vom Auftraggeber auch Sicherheitsanforderungen gestellt. Leider wird deren Umsetzung aber oft nicht – oder nicht rechtzeitig – getestet. In der Zukunft wird hoffentlich die Anzahl der auf Sicherheit getesteten und zertifizierten Anwendungen steigen. Bis dahin gilt die alte Weisheit: Willst Du, dass es richtig gemacht wird? Dann mach es selbst!

  • Überlappung zwischen den häufigsten und gefährlichsten Schwachstellen.

Die zehn häufigsten Schwachstellen in der Statistik haben logischerweise eine Überlappung mit der OWASP TOP 10 2013 und Mobile OWASP TOP 10 Liste, es gibt jedoch Befunde wie Code Quality, die nicht zu den kritischen Problemen zählen. Des Weiteren soll ergänzt werden, dass nicht alle OWASP TOP 10 Schwachstellen zuverlässig automatisiert identifiziert werden können. Probleme mit der Business Logik und Attacken wie  CSRF (Cross-Site Request Forgery) können zuverlässig nur mittels eines Penetrationstests gefunden werden.

Ein weiterer Unterschied zwischen der Statistik und OWASP Liste ist, dass in der Statistik auch die Testergebnisse von den nicht Webanwendungen mitwirken. Programmiersprachen wie C/C++, Perl und SQL-Skripte zählen dazu.

  • Die häufigste Schwachstelle lautet: „Information Leakage“.

Die Kategorie Information Leakage hat den hohen Rang verdient. Das Problem kommt sowohl bei mobilen Apps als auch Webanwendungen(z.B. HTTP Server Responses) oft vor. Die auf der Verwendung alter standards wie SSLv2, SSLv3 und TLS1.0, auf denen in den letzten Jahren gefundene Schwachstellen wie BEAST, POODLE und DROWN basieren, begründen teilweise den Platz 2 (Cryptographic Issues).

Dass die CRLF(Carriage Return Line Feed) Schwachstelle bereits den Platz 4 belegt, finden wir etwas überraschend. Wir rechnen das der Testmethodik von Veracodes‘ Dynamischem Scanner (dem sogenannten Deep Scan) zu. Wesentlich häufiger sehen wir das generelle Problem mit „Insufficient Input Validation“, welches manuell noch vollständiger identifiziert werden kann.

  • Was wird als Mitigationsgrund angegeben?

Interessant zu erwähnen ist, dass in 25% aller Fällen False Positives angegeben werden. False Positives lassen sich aus Prinzip nicht vollständig vermeiden. Die dynamischen und statischen Scanner haben andere Sichtweisen und wenn sich deren Ergebnisse zusammenhängen lassen, beschleunigt das auch die Bewertung von Findings. Es ist von Vorteil, wenn gewisse Ergebnisse wie klare False Positives, automatisch ausgeblendet werden können, was besser ist, als die relevanten Testregeln komplett zu überspringen.

Änderungen am Testprozess

Ein automatisierter Testprozess ist eine der Voraussetzungen für die schnell agierende DevOps Welt. Immer mehr Organisationen setzen auch auf automatisch gestartete statische Code Analyse. Die dynamische Analyse wird noch oft manuell gestartet, lässt sich aber auch automatisieren.

  • Test first,fail fast

Die Frequenz von SoftwareTesting steigt. Oft werden kleinere Teile der Anwendung getestet. Bemerkenswert ist, dass in der Statistik alle statischen Scans von der Cloud durchgeführt werden. Die dynamischen Scans konnten auch im internen Netzwerk realisiert werden. Trotzdem repräsentieren die einmaligen Scans (1x pro Jahr) immer noch 38%. Zwischen häufiger Testen und weniger Issues gibt es auch Korrelationen, denn die Mitigation verbessert auch die proaktive Security Awareness der Developer.

  • Security Awareness lohnt sich

Ebenfalls interessant bei diesem Thema: Entwickler, die ein Online- oder Live Training absolviert haben, erreichen einen besseren Sicherheitsgrad. Weitere Informationsquellen sind z.B. reguläre InfoSec Meetings, in denen die aktuellen Sicherheitsthemen zusammen besprochen werden. Eine gute verständliche How-To Dokumentation rundet Security Awareness ab.

  • Software Composition Analyse (SCA) wird immer wichtiger

Bevor der Quellcode überhaupt gescannt wird, kann schon eine sehr schnelle Vor-Analyse erfolgen: SCA. Vor allem die Teams, die auf externe Komponenten setzen, brauchen einen klaren Überblick über die Lizenzen und den aktuellen Sicherheitsstand verwendeter Libraries. Die Veracode Statistik ergibt, dass 88% der Java Anwendungen eine verwundbare Komponente beinhalten. SCA kann solche Defizite frühzeitig aufzeigen.

Leider haben fast zwei Drittel der Teams diesen Prozess noch nicht implementiert, was signifikante rechtliche und sicherheitsrelevante Auswirkungen haben kann (siehe z.B. hier).

Lessons learned

Was können wir also aus der Analyse des Reports lernen?

  • Je früher getestet wird, desto früher können die Probleme behoben werden. Klingt banal, muss man aber umsetzen.
  • Informationstransparenz über die Sicherheitsanforderungen aber auch deren Realisierung ist extrem wichtig und hilft allen Teams, rechtzeitig an die Sicherheit zu denken.
  • Application Security Testing muss mit der Build Pipeline konform und integrierbar sein. Nur so kann die Frequenz und Qualität eingehalten werden.
  • Risikomanagement von Open Source- und anderen externen Komponenten ist beim Security Testing zu betrachten. Eine Komponente, die aus rechtlichen oder sicherheitsrelevanten Gründen ad-hoc nicht verwendet werden darf, muss nicht noch auf Code getestet werden, sondern sollte gleich entfernt bzw. ersetzt werden.

Um die Eingangsfrage zu beantworten: Nicht nur die Application Security sondern auch die profitable Identifizierung und Ausnutzung von Schwachstellen durch Kriminelle hat sich weiterentwickelt. Umso wichtiger ist es, am Ball zu bleiben: Wer sich gründlich informiert und seine Teststrategie regelmäßig verbessert, kann seinen SDLC Prozess gut absichern und damit die Applikationssicherheit deutlich verbessern.

 


Links:

http://www.veracode.com/blog/security-news/our-2017-state-software-security-report-top-5-takeaways

https://blog.blackducksoftware.com/open-source-versata-litigation

https://info.veracode.com/report-state-of-software-security.html

Bild: ©iT-CUBE SYSTEMS AG 2017

 

Schreibe einen Kommentar