scip AG

Labs

Die scip Labs ist unsere hauseigene Forschungsabteilung, die einerseits mit der Erarbeitung des Verständnisses für neue Technologien beschäftigt ist, andererseits eigene Entwicklungen in den technischen Bereichen Auditing, Exploiting und Forensics vorantreibt. Im Blog werden regelmässig Neuigkeiten und Forschungsberichte veröffentlicht.

► 12.06.2013 – Kurzanalyse des Windows Privilege Escalation Exploit

Am 15. Mai 2013 hat Tavis Ormandy, ein bei Google angestellter Sicherheitsexperte, Informationen zu einer möglichen Schwachstelle im Windows Kernel in seinem Blog veröffentlicht. Details dazu finden sich ebenfalls in unserer Verwundbarkeitsdatenbank. Der Finder einer Schwachstelle hat immer mehrere Möglichkeiten mit selbiger umzugehen:

• Die für uns alle schlechteste Option wäre die Entwicklung eines Exploits und der anschliessende Verkauf dessen auf dem Schwarzmarkt.
• Eine weitere Möglichkeit wäre die Schwachstelle an den Hersteller der Software, in diesem Falle Microsoft, zu melden. Der Hersteller bekäme so die Möglichkeit die Schwachstelle zu schliessen und einen Patch dafür zu veröffentlichen. Danach kann der Finder die Details zur Schwachstelle veröffentlichen. Dies wäre dann eine sogenannte verantwortungsvolle Veröffentlichung (Responsible Disclosure) oder eine koordinierte Veröffentlichung (Coordinated Disclosure).
• Oder man wählt den Weg des Full Disclosure. Hierbei werden alle Details zur Schwachstelle direkt im Internet publiziert. Dies wird meistens gewählt, um den Druck auf den Hersteller zu erhöhen und um Spezialisten die Möglichkeit zu geben, eigenständig Schutzmassnahmen ergreifen zu können.

Natürlich erhöht so ein Full Disclosure auch das Risiko dass die Schwachstelle für kriminelle Zwecke missbraucht wird. Tja, in diesem Fall hat der Finder den Weg des Full Disclosure gewählt. Zusammen mit progmboy, ein versierter Programmierer, hat Tavis einen Proof of Concept (PoC) Exploit erstellt und veröffentlicht. Der Code zu diesem Exploit ist ebenfalls frei im Internet verfügbar.

Kurzanalyse der Schwachstelle und PoC

Auf verschiedenen Webseiten, unter anderem auf heise.de, wurden Artikel über die Schwachstelle und dessen Exploit veröffentlicht. Ebenfalls sind auf der Full Disclosure Mailinglist alle Informationen über die Schwachstelle wie auch der Code des PoC ersichtlich.

Eine Zusammenfassung der veröffentlichten Informationen sieht in etwa so aus:

• Die Funktion EPATHOBJ::pprFlattenRec() des Windows Kernel hat einen Bug.
• Der Code dieser Funktion ist angeblich über 20 Jahre alt.
• Man kann beliebigen Code injizieren und mit den Rechten von SYSTEM ausführen.
• Das Memory wird beschäftigt, um danach den Code zu injizieren (Memory Corruption).
• Der PoC wurde für Windows 7 SP1 32bit geschrieben.

Der veröffentlichte Code des PoC wurde in C++ geschrieben und kann ohne Änderungen kompiliert werden. Das Ziel des PoC ist es, ein Command Prompt Fenster zu erhalten, welches unter den Rechten von SYSTEM ausgeführt wird.

Für eine erfolgreiche Ausführung muss der Exploit mehrmals gestartet werden. Mehrmals heisst hier, dass es schon mal vorkommen kann, dass auch nach dem hundertsten Start ein Erfolg ausbleibt. Ebenfalls ist es während des Tests auch einige Male vorgekommen, dass das System nicht mehr reagierte oder so instabil wurde, dass es sich mit einem BlueScreen verabschiedete. Dies verwundert eigentlich nicht, immerhin handelt es sich ja um eine Memory Corruption Schwachstelle.

Der PoC wurde von mir auf allen 32bit und 64bit Windows Versionen getestet, welche seit Windows XP/2003 von Microsoft herausgebracht wurden. Einzig auf folgenden 32bit Systemen ist der Code ohne Anpassungen lauffähig:

• Windows 2008
• Windows 7
• Windows 8 (BlueScreen und Freezes extrem häufig)

Ebenfalls muss das Software Paket Visual C++ Redistributable for Visual Studio von Microsoft auf dem Rechner installiert sein, damit das Programm ausgeführt werden kann.

Einsatz des Exploits

Mit dem bekannten und für jedermann zugänglichen PoC Code stehen Systeme, welche ein interaktives Login anbieten, zuoberst auf der Liste der gefährdeten Ziele. Hierbei spielt es keine Rolle, ob es sich um ein lokales Endgerät, eine Citrix XenApp Sitzung oder Remote Desktop Verbindung handelt. Wobei natürlich gerade ein Citrix XenApp Server ein hervorragendes erstes Angriffsziel abgibt.

Die erste Frage, die sich hier aber stellt ist ob überhaupt noch Windows 2008 32bit Systeme mit Citrix XenApp im Einsatz sind. Die meisten Installationen sind heutzutage 64bit und für selbige müsste der Code angepasst werden. Somit ist der PoC Exploit, gepaart mit zusätzlichen Angriffsvektoren (z.B. Social Engineering), vor allem für 32bit Endgeräte und deren Windows Domäne gefährlich.

Jetzt gibt es aber viele begabte Programmierer auf dieser Welt und wie in allen Berufen gibt es auch da nicht nur nette. Schnell ist einem klar, dass die Funktionen, welche im PoC Exploit gebraucht werden, in Bibliotheken abgelegt sind, welche sogar von einem Gast Benutzer aufgerufen werden dürfen. Folgende DLLs werden benötigt:

• gdi32.dll
• kernel32.dll
• user32.dll
• shell32.dll

Diese Bibliotheken können nicht nur von einem in C++ geschriebenen Programm aufgerufen werden, sondern von jeglichem auf einem Windows Rechner ausführbaren Programm. Dies beinhaltet auch interpretierten Code wie Java und VBA. Ich bin mir sicher dass der eine oder andere Tüftler den PoC Code schon am Umschreiben und/oder Verbessern ist.

Schutzmassnahmen

Hier wird es sehr trickreich. Vor allem möchte ich die Angreifer in zwei Gruppen teilen:

• Zuerst sind da die Script-Kiddies welche den PoC Code herunterladen, kompilieren und versuchen ihn auf Windows Rechner auszuführen, um so an erhöhte Benutzerrechte zu gelangen.
• Die zweite Gruppe umfasst alle Angreifer die mit dem Code was anfangen können und fähig sind den Code so anzupassen damit er auf 64bit Systemen lauffähig wird. Ebenfalls können dieses Personen den Code so verändern oder mit anderen Exploits paaren, was die Gefahr massiv erhöht.

So, wie wehre ich mich nun gegen den PoC Code? Zu meinem Erstaunen hat sich beim ersten Ausführen der lokal installierte Virenscanner gemeldet und das Ausführen mit einer Warnmeldung verzögert. Hier wurde nicht der Pattern-basierte Scanner aktiv, sondern wurde beim Ausführen in der Sandbox (Umgebung, in der eine Applikation ausgeführt wird um zu schauen was selbige macht) erkannt, dass das Programm auf heikle Systemdateien zugreift. Viele Virenscanner bieten eine Sandbox oder ein ähnliches Verfahren an.

Nach dem Deaktivieren des Virenscanners waren aber keine anderen Schutzmassnahmen auf dem System vorhanden. Hier würde sich nun eine Software Restriction Policy oder eine AppLocker Policy anbieten. In Windows 8 und Server 2012 sind weitere Massnahmen standartmässig aktiv, welche ein Ausführen von unsignierten Applikationen verhindern kann.

Sich gegen den Angriff mit geändertem Code zu wehren, wird ein bisschen schwieriger. Vor allem wenn der Code interpretiert wird. Ich habe mir eine Liste zusammengestellt, was es zu beachten gibt und was für Massnahmen es gibt:

• Virenscanner: Virenscanner mit Sandbox oder äquivalenter Funktion einsetzen
• Whitelisting: AppLocker oder auf pre Windows 7 Systemen Software Restriction Policy einsetzen. (Blog zum Thema)
• System Hardening: Je besser ein System gehärtet wurde, desto schwieriger wird es für einen Angreifer Code auf ein System zu kopieren und auszuführen. (Blog zum Thema)
• Code Signing: Nur signierter Code oder Applikationen zur Ausführung zulassen. VBA oder Java Code lässt sich signieren. Die Interpreter lassen sich so konfigurieren, dass nur signierter Code ausgeführt werden darf. Nicht signierte Applikation lassen sich seit Windows 8/2012 mit On-Board Mitteln blockieren.
• Systemschutz: Zugriffe auf heikle Systembereiche sollten protokolliert (Blog zum Thema) oder noch besser verhindert werden. Um dies zu erreichen gibt es nebst dem Windows Audit-Log auch eine Vielzahl an IDS/IPS Agents für Server und Client Systeme.
• Perimeter Sicherheit: Schutz des Clients durch Umsysteme. Was seit vielen Jahren gang und gäbe ist gilt immer noch. Der Download oder das Empfangen via E-Mail von Executables, Dateien mit Code und Script Code und komprimierten Dateien etc. sollte sehr restriktiv behandelt werden. (Blog zum Thema)
• Restriktiver Datenaustausch: Der Austausch von Daten via Wechseldatenträger sollte eingeschränkt oder unterbunden aber mit Sicherheit protokolliert werden.
• Application Virtualization: Eine weite Möglichkeit ist das Virtualisieren der Applikationen. Hierbei gibt es Lösungen wo man die Zugriffe einer solchen Applikation genauestens festlegen und überwachen kann. (Blog zum Thema)

Diese Liste ist nicht als abschliessend zu betrachten, sondern sollte mehr als Gedankenanregung dienen. Ziel sollte es sein, alles ausführen zu dürfen, was nötig ist und alles andere zu verbieten. Dieses Ziel ist natürlich nicht ganz einfach zu erreichen. Vor allem bei grösseren und komplexen Umgebungen kann es mit viel Aufwand verbunden sein.

Fazit

Ein einzelnes Allheilmittel gibt es, wie in den meisten Fällen, auch hier nicht. Doch man steht dem Problem nicht hilflos gegenüber. Man kann sich mit Windows On-Board Mitteln schon relativ gut gegen die Bedrohung zur Wehr setzen. Unterstützt durch das eine oder andere Software-Produkt, kann man das Risiko auf ein Minimum reduzieren. Wenn man sich schon seit längerem nicht mehr mit dem Hardening der Systeme befasst hat, wäre jetzt sicher eine gute Gelegenheit, die Systeme zu prüfen und gegebenenfalls Massnahmen zur Erhöhung der Sicherheit zu ergreifen.

Pascal Schaufelberger | G+ (1467 Wörter)

► 06.06.2013 – Are we even moving?

As I’m writing this late May 2013, arguably one of the coldest and gloomiest months we had in decades here in Zurich, it’s tough not to get in a bit of a ranty mood. So I apologize in advance if this article seems to be written by a grumpy old man.

Recently, I visited a number of events targeted at CISO and similar roles here in Switzerland. All of those events were excellently organized, provided great food and drink as well as plenty of opportunities for discussions and the occasional vendor pitch. Whenever I have the time for it, I enjoy going to these events. Not because of the food – well, not only because of the food – but because I think it is important to discuss current problems with a significant number of people from different industries and backgrounds in order to come up with good ways to tackle them. At scip, we work for a very wide variety of customers, so understanding different needs and views is making our life a lot easier.

But I digress. When I was at one of said events lately, I had a prolonged discussion with the CISO of a large Swiss industrial corporation which will remain unnamed for privacy reasons. While we never worked together before, he was familar with my work and wanted to ask me some questions. Aren’t attacks from within more critical than those from the Internet? What products can I use to protect from external attacks? What about sophisticated attacks? And so on.

If you work in security for a while, you will probably have heard all of those questions before. I for sure have. That does not mean that they are bad or silly questions, it’s actually quite the opposite. If those questions get asked so frequently, their answers must be rather important. But for some reason, the answers are way less persistent than the question itself. There seems to be no FAQ for general security questions like those and I think this is a problem we, as an industry, need to solve.

For example: The problem of internal attacks remains, at its core, unchanged for decades. Yes, technology has changed a lot lately. We are dealing with new problems, that make it easier for internal threats to cause damage and we counter those new problems with new solutions.

The problem is: We still spend so much effort, time and money on discussing the same things over and over again adding new buzzwords created by security vendors to sell new solutions for old problems. The industry is, in my personal opinion, highly reluctant to move out of its comfort zone, to identify and tackle new problems with new approaches. So instead, it’s keeping itself busy with the same couple of things that worked in the past. It’s a steam engine that keeps dozens of security vendors alive without actually making our evolving digital world significantly more secure.

We need to create some sort of persistence in our information security programs. As most of you who read our scip labs regularly know, I’ve spent a good amount of time researching the Apple iOS platform. Among other interesting things, I analyzed a good number of applications, some of them very deeply.

The most unsettling thing about security problems in iOS applications is, that a lot of these problems are ancient. We are talking about authentication in cleartext, password storage in cleartext. I even saw a glorious recreation of the old Javascript Authentication with the actual password in the HTML sourcecode issue, when an application performed local authentication against a password it just received over an unencrypted GET request.

A whole generation of application developers that started to program web applications in the late 90’s have learned the hard way that these things are not good ideas. And, happily, they have stopped doing them, mostly. We frown upon websites that do not allow authentication via HTTPS, but at the same time, iOS apps haven’t gotten the memo yet.

I remember having discussions with Marc in 2007 about a project called Tractatus he did back then. His goal was to define simple and clear facts about computer security much alike Ludwig Wittgenstein did so for general philosophy. And now, with the complexity of information security growing faster and faster, I feel like this approach is something worth re-visiting.

We should not discuss the same questions over and over again. We should discuss the iteration of the question, we should add detail where useful and new solutions where necessary. But approaching information security problems should be structured, based on a legacy of previous decisions, experience and knowledge. Not a vendor pitch. We simply cannot afford to start at square one every time a new technology, type of device or business model comes along.

Attackers evolve quickly, because they need to in order to succeed and make money. The security industry does not need to keep up to make money. Even old problems generate money, as firewall sales show impressively. But we need to keep up to do our job, and that’s to defend and stay safe.

Stefan Friedli | G+ (882 Wörter)

► 04.06.2013 – Interview zu Wardriving in der Schweiz

In der Tageszeitung 20 Minuten ist der Artikel Mit dem Motorrad auf WLAN-Jagd erschienen. In diesem kommt Stefan Friedli zu Wort, der sich zu den historischen Hintergründen des Wardriving äussert. Leider wurde das spannende Interview nur zu Teilen abgedruckt, weshalb wir hier den kompletten Beitrag bereitstellen:

Wardriving in der Schweiz?

Stefan Friedli: Wardriving war früher mal eine ziemlich populäre Sache, insbesondere Anfang der Nullerjahre als WLANs im privaten Bereich immer grössere Verbreitung fanden und meistens gar nicht (keine Verschlüsselung/Authentisierung) oder nur schwache Verschlüsselungsmechanismen (WEP) verwendeten. Hier ist eine Karte von Zürich, Stand 2004.

Technische Schwierigkeit?

Stefan Friedli: Technisch ist das Ganze sehr einfach: Benötigt wird ein Wireless Adapter mit aktiviertem Monitor Mode (für die meisten gängigen Adapter machbar, auch in billigeren Laptops/Netbooks), ein GPS Empfänger und eine entsprechende Software (Kismet war und ist sehr populär für Linux, für Windows ist NetStumbler wohl die gängigste Lösung).

Heutzutage sind alle diese Komponenten in gängigen Android Smartphones verbaut, theoretisch könnte man heute also damit problemlos Wardriving betreiben.

Dazu kommt dann optional noch eine Antenne. Die meisten Wardriver hatten natürlich das Ziel, möglichst viele Netzwerke aufzuspüren, entsprechend wurde gern und viel in Antennen mit grosser Reichweite investiert. Theoretisch ist das aber eigentlich eine Nebensache, auch mit einem normalen Laptop werden Sie heute in Zürich mehr als genügend Access Points finden.

Motivation und Legalität?

Stefan Friedli: Spannende Frage. Dass sich Andzakovic im Artikel zu erkennen gibt, wundert mich nicht. Das reine Entdecken und Identifizieren von WLANs ist meines Erachtens so oder so nicht illegal, zumal ja keine Sicherheitsmassnahmen umgangen werden. Es passiert im Grunde genommen nichts anderes, als wenn sie auf ihrem Smartphone die verfügbaren WLANs anzeigen lassen. Nur schneller und technisch etwas gewiefter, so dass auch Netzwerke erkannt werden, die ihre Kennung (ESSID) nicht aktiv propagieren.

Kurz: Solange er sich nicht effektiv Zugang zu einem geschützten Netz verschafft, sehe ich da im Hinblick auf die Legalität keine massiven Schwierigkeiten. Von der Schwierigkeit, so etwas nachzuweisen ganz zu schweigen.

Im Artikel wird ebenfalls erwähnt, dass Andzakovic mittels Deauth Angriffen verbundene Clients aus dem Netz werfen sowie Pakete zur späteren Analyse mitschneiden kann. Um das in Kontext zu setzen: Dieses Verfahren wurde früher (vor allem zu WEP Zeiten) genutzt, um genügend Pakete für eine Berechnung des Schlüssels zu sammeln. Ein Gerät wurde deauthentisiert (die entsprechenden Pakete sind fälschbar) und muss sich neu mit dem WLAN verbinden. Diese Neuverbindung generiert Kommunikationspakete, die der Angreifer mitschneidet. Der Vorgang wird solange wiederholt, bis der Angreifer genügend Pakete hat, um das Passwort des WLANs aufgrund einer Schwachstelle im WEP-Verfahren zu berechnen. Bei WPA2-PSK (was heute gängigerweiseeingesetzt wird), ist die Sache entscheidend aufwendiger geworden.

Andzakovic sagt auch klar, dass er das Equipment im Rahmen von Penetration Tests einsetzen möchte, ein Geschäftsfeld auf das sich meine Firma (scip AG) spezialisiert hat. In diesem Rahmen ist das Angreifen und Eindringen in Kundennetzwerke explizit erwünscht und vertraglich mit den Kunden geregelt. Wir haben selber diverse derartige WLAN-Penetrationtests für Grosskunden umgesetzt – mit Erfolg. Die selben technischen Methoden werden übrigens auch genutzt, um sogenannte Rogue Access-Points (privat oder anderweitig unerlaubt platzierte Access Points) innerhalb von Kundennetzwerken zu identifizieren und zu entfernen.

scip AG | G+ (586 Wörter)

► 30.05.2013 – Blog Digest Mai 2013

• A Saudi Arabia Telecom’s Surveillance Pitch (thoughtcrime.org)
• Anatomy of a VB Virus (resources.infosecinstitute.com)
• Android Forensics (securitylearn.net)
• Anti-virus Software is Dead – Really? (blogs.technet.com)
• Are all telephone calls recorded and accessible to the US government? (guardian.co.uk)
• Bits from Debian – Debian 7.0 Wheezy released! (bits.debian.org)
• Cloud-based scanner identifies new malware by its ancestry (cso.com.au)
• Computer Science Culture Clash (blog.regehr.org)
• Diablo III Economy Broken by an Integer Overflow Bug (reddit.com)
• Disable ASLR on iOS applications (securitylearn.net)
• DOM Clobbering (thespanner.co.uk)
• Forensics Investigations: Do not forget the database! (blog.opensecurityresearch.com)
• From a Site Compromise to Full Root Access – Symlinks to Root (blog.sucuri.net)
• Goading Around Firewalls (blog.strategiccyber.com)
• Harvard Professor Re-Identifies Anonymous Volunteers In DNA Study (forbes.com)
• I AM Adam Kujawa a malware reverse engineer and researcher (reddit.com)
• I Contribute to the Windows Kernel. We Are Slower Than Other (blog.zorinaq.com)
• Identify Back Doors in Firmware By Using Automatic String Analysis (blog.ioactive.com)
• Introducing the Burp Notes Extension (blog.spiderlabs.com)
• Scanning binaries for PE format anomalies (research.zscaler.com)
• Security Configuration Hardening (blog.redscan.com)
• Security ‘for free’? (blog.isc2.org)
• The ASP.NET Internals (resources.infosecinstitute.com)
• Top 10 Encryption Benefits (infosecisland.com)
• Web Storage Security (blog.whitehatsec.com)
• What happens when pirates play a game development simulator (greenheartgames.com)
• What is ‘up to date anti-virus software’? (isc.sans.edu)
• Where did all the HTTP referrers go? (smerity.com)
• xkcd: Is It Worth the Time? (xkcd.com)

Marc Ruef | G+ (471 Wörter)

► 23.05.2013 – Sicherheitsverantwortlichkeiten und Risikosteuerung

Für eine systematische Risikosteuerung innerhalb eines Unternehmens ist es unerlässlich, dass Verantwortlichkeiten und Rollen glasklar definiert und umgesetzt werden. Besonders Sicherheitsverantwortlichkeiten bilden zentrale Rollen für die Sicherheit von Business, Services und IT-Infrasturktur. Diese werden typischerweise in gesamten Ownership-Konzepten und Policies oft vernachlässigt bzw. zu vage abgehandelt.

Nebst den typischen Verantwortlichkeiten, die Ownern zugewiesen werden – ist es aus dem Sicherheitsmanagment heraus – grundlegend eben auch Sicherheitsverantwortlichkeiten zu postulieren, die in der Vernatwortung von bestehenden Ownern liegen oder in der Pflicht von sog. separaten, eigenständigen Security-Ownern stehen.

Der Vorligende Artikel ist ein Versuch aufzuzeigen, wie Sicherheitsverantwortlichkeiten in einem Unternehmen als exemplarische Umsetzungsoption strukturiert werden könnten, um Risiken methodisch exakt und umfassend zu behandeln und bewältigen.

Security Owner haben den Auftrag und die Kompetenz, über Sicherheitsziele und Risiken in ihrem Verantwortungsbereich zu entscheiden. Darauf basierend werden nun im weiteren Verlauf die Aufgaben, Kompetenzen und Verantwortlichkeiten der Security Owner beschrieben. Dabei wird festgelegt:

• Wer trägt die Verantwortung für Sicherheitsrisiken von Business Services, Applikationen und IT-Infrastruktur
• Welche Sicherheitsaufgaben bestehen für Sicherheitsverantwortliche
• Wer ist verantwortlich und – wenn möglich-, zuständig für diese Sicherheitsaufgaben

Die hier vorgeschlagene Austellung geht davon aus, dass das Thema immer Teil eines unternehmensweiten, einheitlichen Sicherheitsmanagements ist. Entsprechend muss es aus der Perspektive des Unternehmens adaptiert und formuliert werden.

Die Umsetzung solcher Ownershipkonzepte, kann ja nach Unternehmensgrösse bedingen, dass einzelnen Geschäftsbereichen eine gewisse Autonomie attestiert wird, da Business-, IT- und Entwicklungsprozessen in diversen Geschäftsbereichen eines Unternehmens durchaus unterschiedlich ausgeprägt sein könnten.

Rahmenbedingungen: Anforderungen auf Ebene der Policy bzw. Sicherheitspolitik

Die benötigten Rollen der Sicherheitsverantwortlichen müssen auf dem Niveau einer Weisung, Policy oder Sicherheitspolitik definiert und institutionalisiert werden.

Vorgängig ist ein Aufteilung der Verantwortlichkeiten in den typische Bereiche nötig:

• Business Services / Applikationen
• IT- Infrastruktur
• Entwicklungen

Die Verantwortung für die Sicherheit von Business Services, Applikationen und IT-Infrastruktur wird durch sogenannte Sicherheitsverantwortliche (Security Owner) wahrgenommen, die durch die Geschäftsleitung nominiert und mit Entscheidungskompetenzen bezüglich Festlegung von Sicherheitszielen und Risikoakzeptanz versehen werden. Sicherheitsverantwortliche sind in der Regel Mitglieder des höheren oder mittleren Managements.

• Sicherheitsverantwortliche für Business Services / Applikationen: Für jeden Business Service und jede geschäftsrelevante Applikation wird ein Sicherheitsverantwortlicher ernannt. Er stuft den Service, bzw. die Applikation und die damit bearbeiteten Daten bezüglich Verfügbarkeits-, Vertraulichkeits- und weiteren Sicherheits- und Compliance-Anforderungen ein und definiert dadurch die Sicherheitsziele für Entwicklung und Betrieb. Der Sicherheitsverantwortliche entscheidet über Sicherheitsmassnahmen und trägt die Verantwortung für die Sicherheitsrisiken während des gesamten Lebenszyklus.

• Sicherheitsverantwortliche IT- Infrastruktur: Für IT-Infrastrukturen, namentlich für Netzwerke, Plattformen, Storage-, Enterprise Systems Management- und Sicherheitsinfrastrukturen, sowie für Service Applications, werden Sicherheitsverantwortliche ernannt. Sie stufen die ihnen zugeordnete Komponente bezüglich Verfügbarkeits-, Vertraulichkeits- und weiteren Sicherheits- und Compliance-Anforderungen ein und definieren dadurch die Sicherheitsziele für Entwicklung und Betrieb der Komponente. Sie entscheiden über Sicherheitsmassnahmen und tragen die Verantwortung für die Sicherheitsrisiken während des gesamten Lebenszyklus der Komponente.

• Sicherheitsverantwortliche für Entwicklungen: Sicherheitsverantwortliche für Entwicklungen von Software oder IT-Infrastrukturlösungen sind verantwortlich für das Erreichen der vorgegebenen Sicherheitsziele, die Definition und Umsetzung der dafür notwendigen Massnahmen, sowie generell für die Einhaltung der Sicherheitsmanagementprozesse, Sicherheitsvorgaben und -standards während Entwicklungsvorhaben.

• Information Owner: Der Information Owner ist verantwortlich für die Behandlung und den Schutz der Informationen und Geschäftsunterlagen, welche der ihm anvertrauten Informationssammlung angehören. Insbesondere ist er zuständig für: die Bestimmung der Klassifizierung und die Festlegung von allfälligen erhöhten Sicherheitsanforderungen bezüglich der Informationssammlung sowie die bedarfsgerechte Erteilung und Löschung der Zugriffs- und Zutrittsberechtigungen zur Informationssammlung.

Abgrenzung

Diser Artikel befasst sich ausschliesslich mit sicherheitsrelevanten Aufgaben und Verantwortungen. So wird dann auch von Sicherheitsverantwortlichen oder Security Owners und nicht generell von IT- oder Business-Owners gesprochen.

Es ist selbstverständlich möglich und u.U naheliegend, die Rolle eines Security Owner Business Service dem Business Owner eines Services zuzuweisen, sofern der betreffende Geschäftsbereich des Unternehmens die Rolle des Business Owners implementiert hat. Entsprechendes gilt für die Rolle des IT-Owners und des Sicherheitsverantwortlichen IT-Infrastruktur.

Begriffsbestimmungen

In diesem Dokument werden die Rollen der Sicherheitsverantwortlichen für Business Services oder Applikationen und der Sicherheitsverantwortlichen für IT-Infrastruktur beschrieben. Diese Rollen beziehen sich auf folgende Definitionen:

• Applikation: ein Anwendungsprogramm (kurz Anwendung) ist ein Computerprogramm, das eine für den Anwender nützliche Funktion ausführt.

• Business Service:Geschlossene Einheit von Applikationen, die zusammen einen IT-Service für das Business liefern.

• IT Infrastruktur: Storage, Plattformen (Hardware + Betriebssystem), Netz, Unternehmes Systems Management, Service Applikationen; sowie u.a. folgende Sicherheitskomponenten: Security Standards (Hardening Guides, Anti-Malware, etc.) Authentisierungs- und Autorisierungsservices, Verschlüsselungs-Services, Disaster Recovery- und Security Event Management-Systeme etc.

Im Zusammenhang mit der Risikoverantwortung von Sicherheitsverantwortlichen gilt:

• Sicherheitsrisiko: Möglichkeit, dass ein Sicherheitsziel oder mehrere Sicherheitsziele nicht erreicht werden.

• Sicherheitsziel, Sicherheitsniveau: Zu erfüllende Sicherheitsanforderung. Durch das Erreichen aller Sicherheitsziele erlangt ein Business Service, eine Applikation oder IT-Infrastruktur das angestrebte Sicherheitsniveau.

• Risikoverantwortung: Verantwortung für das Management von Risiken: für Identifikation, Messung und Beurteilung von Risiken, für die Erarbeitung von Massnahmenplänen und die Risikosteuerung.

• Risikosteuerung: Entscheidung über den Umgang mit Risiken (Umsetzung von Massnahmen, Risikoakzeptanz).

Rollenbeschreibungen

In einer ersten Betrachtung werden nun die Rollen der Sicherheitsverantwortlichen in abstrakter zusammenfassender Form beschrieben. Ein Zuordnung der Verantwortlichkeiten für die anfallenden Sicherheitsaufgaben, sowie eine Erläuterung der spezifischen Risikoverantwortung von Sicherheitsverantwortlichen erfolgt in den nachfolgenden Kapiteln.

Sicherheitsverantwortliche für Business Services / Applikationen

Sicherheitsverantwortliche für Business Services / Applikationen sollten die Gesamtverantwortung für die Sicherheit der Applikation, bzw. des Business Services und der mit damit zu bearbeitenden Daten während des gesamten Lebenszyklus der Applikation, bzw des Business Services tragen.

• Information Owner im Sinne der Group Weisung 1.9 [5]
• tragen Verantwortung für Sicherheitsrisiken und entscheiden – im Rahmen ihres Kompetenzbereichs – über Risikoakzeptanz und Umsetzung von Sicherheitsmassnahmen
• bestimmen Sicherheitsanforderungen die Applikation bzw. Business Service
• bestimmen Sicherheitsanforderungen den Betrieb der Applikation bzw. Business Services
• kontrollieren vor Inbetriebnahme und periodisch die Einhaltung der Sicherheitsanforderungen

Für jeden Business Service und für jede geschäftsrelevante Applikation, die nicht einem Business Service zugeordnet ist, wird ein Sicherheitsverantwortlicher ernannt.

Sicherheitsverantwortliche für IT-Infrastruktur

Sicherheitsverantwortliche für IT-Infrastruktur sollten die Gesamtverantwortung für die Sicherheit der IT-Infrastruktur während des gesamten Lebenszyklus der IT-Infrastruktur tragen. Falls es die IT-Infrastruktur eigene Datenbestände hat, sind die Sicherheitsverantwortlichen für IT-Infrastruktur auch verantwortlich für Sicherheit der zugehörigen Daten.

• Information Owner (vgl. oben)
• tragen Verantwortung für Sicherheitsrisiken, bzw. -schwachstellen und entscheiden – im Rahmen ihres Kompetenzbereichs – über Risikoakzeptanz und Umsetzung von Sicherheitsmassnahmen
• bestimmen Sicherheitsanforderungen an IT-Infrastruktur in Abstimmung mit dem zuständigen Technical Product Manager
• bestimmen Sicherheitsanforderungen an den Betrieb der IT-Infrastruktur
• kontrollieren vor Inbetriebnahme und periodisch die Einhaltung der Sicherheitsanforderungen
• informieren betroffene Sicherheitsverantwortliche für Business Services / Applikationen über sicherheitsrelevante Änderungen der IT-Infrastruktur

Sicherheitsverantwortliche für Entwicklung

Sicherheitsverantwortliche für Entwicklung verantworten die Umsetzung der Sicherheitsanforderungen und die Einhaltung der sicherheitsrelevanten Prozessvorgaben bei der Entwicklung von Software oder beim Engineering von IT-Infrastruktur.
Sie

• verantwortlich für die Spezifikation der Sicherheitsanforderungen aufgrund der Vorgaben des Sicherheitsverantwortlichen für Business Services / Applikation oder IT-Infrastruktur und der anwendbaren verbindlichen internen Vorgaben.
• verantworten die korrekte Umsetzung der Sicherheitsanforderungen
• stellen sicher, dass bei Entwicklung/Engineering die anwendbaren und verbindlichen Vorgaben zur Entwicklung sicherer Software bzw. Infrastruktur eingehalten werden
• verantwortlich für die Erstellung der Sicherheitsdokumentation

Risikosteuerung

Sicherheitsverantwortlicher IT-Infrastruktur

Sicherheitsverantwortliche für IT-Infrastruktur sind zuständig für die Steuerung der Sicherheitsrisiken, die dem Unternehmen aufgrund von Schwachstellen der IT- Infrastruktur in seinem Verantwortungsbereich entstehen. Entscheidungsgrundlagen für die Risikosteuerung sind das angestrebte Sicherheitsniveau der IT-Infrastruktur, sowie die identifizierten und bewerteten Risiken und Schwachstellen.

Die Entscheidung über die Umsetzung von Massnahmen zur Risikominderung und die Akzeptanz von Risiken erfolgt durch den Sicherheitsverantwortlichen.

Sicherheitsverantwortlicher Business Service / Applikation

Der Sicherheitsverantwortliche eines Business Services oder einer Applikation ist zuständig für die Steuerung der Sicherheitsrisiken, die das Unternehmen durch den Business Service, bzw. die Applikation entstehen.

Entscheidungsgrundlagen für die Risikosteuerung sind das angestrebte Sicherheitsniveau des Business Services / der Applikation und die identifizierten und bewerteten Risiken.

Die Entscheidung über die Umsetzung von Massnahmen zur Risikominderung und die Akzeptanz von Risiken erfolgt durch den Sicherheitsverantwortlichen

Der Sicherheitsverantwortliche eines Business Services / einer Applikation kann bei der Risikosteuerung voraussetzen, dass der IT-Infrastrukturbetreiber die für die IT-Infrastrukturkomponenten vereinbarten Sicherheitsniveaus einhält.

Risikoausschuss der Unternehmensführung

Der Risikoausschuss entscheidet über Unternehmensweite Sicherheitsmassnahmen und die Akzeptanz von Geschäftsbereichübergreifende Sicherheitsrisiken. Darüberhinaus ist der Risikoausschuss Eskalationsgremium bei Meinungsverschiedenheiten über Risikoeinschätzungen.

Sicherheitsaufgaben

Der folgende Abschnittg identifiziert die im Zusammenhang mit der Sicherheit von Business Services, Applikationen oder IT-Infrastruktur anfallenden Aufgaben und ordnet Verantwortlichkeiten zu.

Im Fokus sind dabei die generell für Sicherheitsverantwortliche anfallenden Aufgaben. Ausnahmen, in denen auf einige dieser Aufgaben verzichtet werden kann oder Ausnahmefälle, in denen zusätzliche Aufgaben zu erledigen sind, werden nicht betrachtet.

Die Zuordnung von Aufgaben zu Funktionen erfolgt zweistufig. Es wird jeweils angegeben, welche Funktion die Verantwortung für die korrekte und termingerechte Ausführung der Aufgabe trägt und –soweit aus exemplarischer Unternehmenssicht möglich-, welche Funktion die zuständig für die Ausführung der Aufgabe ist. Es werden folgende Abkürzungen verwendet:

• SB: Sicherheitsverantwortlicher Business Service oder Applikation
• SI: Sicherheitsverantwortlicher IT-Infrastruktur
• SE: Sicherheitsverantwortlicher Entwicklung
• D: Delegation: Unterschiedlich, abhängig von den jeweiligen internen Prozessen eines Geschäftsbereichs
• CSO: Chief Security Officer

Risikoverantwortung

Klassifikation von Informationen

Sicherheitsanforderungen festlegen und umsetzen

Sicherheitsadministration

Betriebliche Sicherheitsaufgaben

Audits

Umsetzungsoptionen

Es sollte im Verantwortungs- und Kompetenzbereich der Geschäftsbereiche eralubt sein, die Umsetzung dieses Konzepts entsprechend der Bereichsinternen Prozesse zu gestalten. Im folgenden werden einige Varianten für die Umsetzung in Geschäftsbereichen aufgezeigt.

Falls ein Geschäftsberiech z.B Rollen wie Business Owner oder Business Operation Owner etabliert haben, dann bieten sich folgende Optionen an:

• Vergabe der Rolle Sicherheitsverantwortlicher Business Service / Applikation an den Business Owner des Business Services, bzw. der Applikation.

• Delegation einiger Aufgaben, die unter der Verantwortung des Sicherheitsverantwortlichen für Business Service / Applikation stehen, zur Ausführung an den Business Operation Owner. Dabei ist sicherzustellen, dass die Delegation nachvollziehbar bleibt und die Kontrolle weiterhin dem Hauptverantwortlichen obliegt.

Beispiele: Definition der Sicherheitsanforderungen an den Betrieb, Prüfung/Freigabe von Zugriffsanträgen, Durchführung der fachgerechten Archivierung, Aktualisierung der Kommunikationsmatrix

Weitere Optionen

• Vergabe der Rolle Sicherheitsverantwortlicher IT-Infrastruktur an den IT-Owner der Infrastruktur.

• Vergabe der Rolle Sicherheitsverantwortlicher Entwicklung an den Sicherheitsverantwortlichen Business Service / Applikation, bzw. an den Sicherheitsverantwortlichen IT-Infrastruktur.

• Delegation der Aufgabe Dokumentation der betrieblichen Sicherheitsanforderungen in der verbindlichen Vereinbarung an einen Service Manager

Fazit

Verantwortung ist ein schönes Wort: Das allerdings typischerweise dann an edlem Glanz verliert, wenn es konkret werden soll – Wer trägt wem gegenüber welche Verantwortung? In Unternehmen wird oft der Eindruck erweckt, dass in Bezug auf die Ownership alles klar definiert ist und es keine Verantwortungskonflikte geben kann.

Das mag aus der Vogelperspektive wohl stimmen, aber Verantwortung zerfällt bei genauerem Hinschauen in viele Partikular-Verantwortungen, die nicht unbedingt miteinander harmonieren. Es herrscht ja bei weitem nicht immer Einklang der Interessen und somit natürlich auch nicht der Verantwortungen. Daher ist es von eminenter Bedeutung, sich darüber im Klaren zu werden, welche Aufgaben und Verantwortungen an welcher Stelle durch wen wargenommen werden müssen, um die Risiken in einem Unternehmen umfassend und lückenlos zu steuern.

Flavio Gerbino | G+ (2613 Wörter)

► 16.05.2013 – Computer Forensik – Ein Überblick

Ich beschäftige mich seit einigen Jahren mit Computer Forensik. In diversen Gesprächen ist mir aufgefallen, dass man im Allgemeinen ein völlig falsches Bild von dieser Disziplin hat. In diesem Artikel werde ich mich bemühen, weitere Aspekte der Computer Forensik nahe zu bringen. Dies ist meine und die Meinung anderer Fachpersonen. Wie immer werden Sie auch Fachpersonen finden, welche diesen Ansichten wiedersprechen werden.

Die schiefe Optik

Sobald ich jemandem von Computer Forensik erzählt habe, kam oft und schnell diese Aussage: Ach ja, das sind doch die vom CSI im Fernsehen. Ehrlich gesagt, habe ich CSI noch nie länger als 5 Minuten gesehen. Aber diese 5 Minuten haben genügt, um sagen zu können, Nein, nicht wie die vom CSI. In der Computer Forensik schaut man nicht auf eine Festplatte und weiss danach, was der Mörder zum Mittagessen hatte.

Ein weiteres falsches Bild, das viele Personen haben, ist die Datenrettung. Ja, Datenrettung ist eine Teildisziplin der Computer Forensik und wir haben und kennen verschiedene Tools, um die versehentlich oder absichtlich gelöschten Daten wieder herzustellen. Diese Fähigkeit sollten Sie aber mehr als Mittel-zum-Zweck ansehen, als die Kernkompetenz eines Forensikers. Damit er die Spuren auswerten kann, benötigt er die Daten, und diese können auch nur noch als Daten-Fragmente existieren und müssen daher wiederhergestellt werden. Wenn Sie einen grossen Datenverlust haben, gibt es aber auch Spezialisten, die sich nur um dieses Problem kümmern.

Was ist es dann

Wie immer ist es eine Frage des Blickwinkels. Vielleicht zuerst zur Klärung, wo es Computer Forensiker gibt. Einerseits finden Sie Computer Forensik Abteilungen bei der Polizei. Diese Abteilungen sind in der Regel unterstützend tätig für die Kriminalpolizei. Das bedeutet, ein Polizist der Kripo zieht einen Experten für einen Fall hinzu. Der Experte muss dabei Beweismittel aus elektronischen Geräten und Datenträger (Notebook, Mobiltelefon, PDA, eBook, Speichermedien etc.) suchen. Viele der Fälle werden wohl Drogendelikte sein. Hier gilt es die Kontakte, Nachrichten und Anruflogs eines Drogenhändlers auszuwerten und allenfalls auf weitere Personen zu kommen.

Am bekanntesten sind wohl die Fälle von verbotener Pornografie, am präsentesten die Kinderpornografie. Neben der Polizei gibt es Unternehmen, welche sich auf die Computer Forensik spezialisiert haben (es sind wenige in der Schweiz). Diese arbeiten vor allem unterstützend für die Polizeikorps und Staatsanwaltschaften.

Die nächst grössere und eventuell sogar die grössten Computer Forensik Abteilungen finden Sie in den grossen Wirtschaftsprüfungsunternehmen. Während der Fokus bei der Polizei jedoch sehr technisch ist und in der Systemanalyse liegt, ist er hier eine Ebene höher. Auch diese Forensiker können Datenwiederher- und sicherstellen. Ihr Fokus liegt jedoch in der eDiscovery, dabei geht es darum, innerhalb einer Bestimmten Zeit alle relevanten Dokumente zu sammeln und einem Reviewer zur Verfügung zu stellen.

Neben den vorgestellten Typen, finden Sie auch bei Information Security Spezialisten entsprechende Computer Forensiker. Der Vorteil von uns: Wir haben beide Blickwinkel. Wir kennen die Angreiferseite und wir kennen die Ermittlerseite. Wir können Ihnen helfen Einbrüche zu analysieren, Beweismittel sichern und Vorschläge zur Verbesserung der Sicherheit geben.

Incident

Haben Sie einen Incident, bei dem Sie vermuten, dass jemand unerlaubt auf Ihre System gelangt war? Haben Sie die Vermutung, dass ein Mitarbeiter, welcher die Firma verlassen wird Ihre Geschäftsgeheimnisse mitnimmt? Erhalten Sie E-Mail Nachrichten von unbekannten Absendern mit drohenden Aussagen?

Das sind alles Beispiele von Vorfällen, in welchen Computer Forensik zum Zug kommen könnten und sollten. Die Aufzählung ist keineswegs Abschliessend, es gibt so viele Bereiche in denen eine forensische Analyse sinnvoll sein könnte.

Forensik kurz und knapp

In der Computer Forensik (egal ob eDiscovery oder klassisch) gibt es grob gesagt drei Phasen, die durchlaufen werden.

1. Beweismittelsicherung
2. Investigation und Analyse
3. Dokumentation

Beweismitelsicherung

Bei der Beweismittelsicherung gibt es verschiedene Aspekte, die berücksichtigt werden sollen. Wenn der Auftraggeber bereits zu Beginn keine gerichtliche Auseinandersetzung anstrebt und die Untersuchung der Prävention dienen soll, kann man sich die aufwändige Arbeit der gerichtlichen Verwertbarkeit sparen.
Sollte der Kunde dies zum Startzeitpunkt noch nicht wissen, ist es von Vorteil die gängige Praxis anzuwenden. Somit hat der Kunde auch zum späteren Zeitpunkt noch die Möglichkeit ein Verfahren anzustreben.

Wo finde ich Beweise

Natürlich ist dies von Fall zu Fall unterschiedlich. Grundsätzlich können Sie die Beweismittel in jedem elektronischen Gerät mit Speicher oder auch diversen Speichermedien auffinden. Zum Beispiel:

• Mobiltelefon/Tablet
• MP3-Player
• e-Reader (Kindle, Nook, etc.)
• Spielkonsole (PS3, PSP, XBox etc.)
• Backup-Infrastruktur (Diskstorage, NAS, Magnetband, etc.)
• Server
• PC/Mac
• Netzwerk
• ...

Wichtig ist, dass man die relevanten Beweise auffinden kann. Interessant ist hier das Amerikanische Recht. Rule 401 besagt, dass ein Beweis relevant ist, sofern er die Tendenz hat, ein Fakt mehr oder weniger glaubwürdig zu sein, als ohne des Beweises.

Diese Daten können sein:

• Chat Protokolle
• Dokumente (PDF, Word, Excel, Text, etc.)
• Browser History
• Logdateien
• Digitale Bilder
• E-Mail
• ...

Kurzum: Beweise in der Computer Forensik sind Electronic Stored Information (ESI).

Sicherung

Die Sicherung dieser Beweise wird vorzugsweise durch eine Bitweise Kopie des Original-Speichermediums vorgenommen. Dabei werden zwei Kopien erstellt und der Zugriff auf das Original geschieht über einen Hardware-Schreibschutz. Die erste Kopie gilt als Best Evidence und wird in der Regel archiviert oder allenfalls später zur Kopie für weitere Arbeitsdisks beigezogen. Die zweite Kopie ist eine Arbeitsdisk. Sie wird direkt zur Untersuchung weiterverwendet.

Folgende gilt es zu beachten, damit ein Beweismittel als integer angesehen werden kann:

• Bit-weise Kopie des Originals
• Kopien werden in geschlossenen oder beschränkt zugänglichen Räumlichkeiten aufbewahrt
• Chain of Custody
• Hash Werte zur Kontrolle anlegen

Verschlüsselte oder flüchtige Speicher

Ist ein Speichermedium verschlüsselt, kann selbstverständlich versucht werden die Verschlüsselung zu brechen. In der Regel gelingt dies jedoch nicht. Der Schlüssel kann jedoch im Memory zu finden sein. Auf jeden Fall bedingt ein verschlüsseltes Medium die Akquise der logischen Partition d.h. es muss eine Software von einer DVD oder einem USB-Stick geladen werden. Dieser Schritt gilt es gut zu dokumentieren, da das Original System verändert werden muss.

Das gleiche Problem gibt es bei der Akquise von RAM (flüchgiter Speicher). Sie können zwar den RAM-Inhalt mit enormem Aufwand auch nach dem Ausschalten des Systems im Ursprungszustand behalten, jedoch mit einem enorm hohen Aufwand und nur über sehr kurze Zeit.

Übersicht

Diese verschiedenen Akquise Möglichkeiten gibt es

Investigation und Analyse

Zur Untersuchung und Analyse von Images kann man verschiedene Tools verwenden. Zwei Tools, EnCase und FTK, sind in der Branche sehr populär, es ist aber keinesfalls ein Muss, diese zu verwenden.

Memory Analyse

Im Memory können diverse interessante Informationen enthalten sein:

• Internet History
• Web E-Mail (z.B. GMX)
• Chat Sessions (z.B. Skype, Facebook-Chat)
• Netzwerkverbindungen
• Prozessinformationen

Bei der Memory Analyse muss das Zielsystem noch laufen und man benötigt Zugriff. Es muss dabei ein Tool von einer DVD oder einem USB-Stick geladen werden. Die Daten sollten dabei nicht auf das Zielsystem sondern ins Netzwerk oder auf ein USB-Medium gespeichert werden.

Gelöschte Dateien

Wie im ersten Teil erläutert, verstehen viele Leute unter der Datenwiederherstellung die eigentliche Aufgabe der Computer Forensik. Tatsächlich kann es von grossem Interesse sein gelöschte Dateien wieder herzustellen. Bekommen Leute mit, dass Sie verdächtigt werden oder sind sie einfach nur vorsichtig, so löschen Sie genau die Dateien, welche interessant sein könnten.

Nicht jede gelöschte Datei kann wieder hergestellt werden. Teilweise sind auch nur noch Dateifragmente vorhanden. Wurde der komplette Zielort auf der Disk bereits überschrieben, so ist diese Datei nicht mehr vorhanden.

Untersuchung

Bei der Untersuchung kommt es wiederum auf die eingesetzten Produkte und das Ziel an. Eine Vorgehensweise ist das Eingrenzen des Zeitrahmens und so die Relevanz der Dokumente zu bestimmen. Eine andere ist dies auf eine gewisse Gruppe von Daten einzuschränken (E-Mail, Textdokumente, Bilder, etc.).

Es kann aber auch eine Kombination dieser Punkte sein. Wichtig scheint mir, dass man ein klares Ziel hat. Den Grundsätzlich kann eine forensische Analyse bereits eine Suche im Heuhaufen sein, durch eine offene Fragestellung wird das Spektrum nur erweitert. Wir sind aber in der Lage herauszufinden, welche Dokumente ein Benutzer wann geöffnet hat. In welchen WLAN sich dieses Gerät angemeldet hat. Hiermit lassen sich allenfalls auch Standorte identifizieren. Es ist auch möglich herauszufinden, wann ein USB-Stick angeschlossen wurde. Die Möglichkeiten sind gross und würden den Rahmen dieses Artikels sprengen.

Fazit

Nun haben Sie einen kurzen, zugegeben oberflächlichen Eindruck der Computer Forensik erhalten. Zumindest ist nun geklärt, dass wir mehr können als nur Daten wiederherzustellen. Diese Disziplin kommt in verschiedenen Fällen zum Einsatz. Gesagt werden kann, je mehr Daten ein Forensiker zum Auswerten hat, desto höher ist die Chance auf einen Erfolg.

Oliver Kunz | G+ (1544 Wörter)

► 13.05.2013 – Vortrag zu Security Testing an SGRP Veranstaltung

Am 07. Mai 2013 fand die Frühlingsveranstaltung der Sicherheitsgruppe Schweiz (SGRP) statt. im Rahmen derer wurde in den Credit Suisse Tower nach Zürich-Oerlikon geladen. Ingesamt fanden drei Vorträge, ebenfalls einer von mir zum Thema Security Testing, statt.

Im ersten stellte Stephan Murer der Credit Suisse seine auf langjähriger Erfahrung basierenden Erkenntnisse zu Testdaten vor. Dabei hat er die verschiedenen Fallstricke aufgezeigt und darauf verwiesen, dass mit synthetischen Testdaten ein Mehr an Effizienz, Zuverlässigkeit und Sicherheit erreicht werden kann.

Der zweite Vortrag wurde von Roland Schützig gehalten und besprach das Prinzip der Virtuellen Bank. In dieser werden bestehende Prozesse mit synthetischen Daten kombiniert, um die Voraussetzung für eine intelligente Testumgebung zu schaffen.

Auf der Basis dieser beiden Beiträge habe ich dann in meinem Vortrag das Thema Security Testing aufgegriffen. Dabei habe ich versucht aufzuzeigen, wie aus Sicht eines Analysten die Sicherheit einer solchen Umgebung geprüft werden kann. Das Slidedeck meines Beitrags steht hier zum Download zur Verfügung.

Im Anschluss wurde das Konzept des Smart Workplace bei Credit Suisse gezeigt und guter Wein beim Apéro genossen. Es hat mich gefreut, die vielen bekannten Gesichter – von Kunden bis zu ehemaligen Arbeitskollegen – zu sehen.

Marc Ruef | G+ (229 Wörter)

► 08.05.2013 – Staatstrojaner – Kritik am neuen Bundesgesetz

Mit der Einführung des neuen Bundesgesetzes betreffend der Überwachung des Post- und Fernmeldeverkehrs könnte in der Schweiz etwas einkehren, was bereits in Deutschland für langwierige Diskussionen gesorgt hat: Staatstrojaner, auch GovWare (Government Software) genannt.

Seit geraumer Zeit regt sich grosser Widerstand gegen die Einführung des neuen Gesetzes, wobei die GovWare einen wesentlichen Teil der Kritik darstellt. Auch wenn nicht alle Gegenargumente juristisch stichhaltig scheinen, so zeigen die mittlerweile über 3’900 Unterschriften auf büpf.ch, dass dieses Thema grosse Beachtung findet.

Die juristische Beurteilung des Gesetzes muss durch Fachleute vollzogen werden. Kritik aus diesen Kreisen ist bereits ausgeübt worden. In diesem Artikel möchte ich auf die technischen Schwierigkeiten eingehen, die sich mit dem Einsatz von Staatstrojanern ergeben. Denn wie wir bereits in einem Artikel aufgezeigt haben, bringen Staatstrojaner per se schon einige Probleme mit sich. Unsere drei Hauptpunkte waren:

• Tangierung der Privatsphäre
• Kompromittierung der Integrität
• Erhöhung der Angriffsfläche

Diese Punkte haben sich nicht verändert, sie können eher sogar noch erweitert werden:

Unklare Benutzerverhältnisse

Wie soll sichergestellt werden, dass wirklich die Zielperson das überwachte Gerät zur fraglichen Zeit bediente? Noch haben nicht alle Geräte beispielsweise eine Kamera, mit der dies zweifelsfrei festgestellt werden könnte. Die grosse Mobilität, die durch heutige Notebooks, Handys und Tablets möglich ist, verhindert zudem viele klassische Identifizierungsmöglichkeiten, wie beispielsweise versteckte, stationäre Überwachungskameras.

Der Wert einer solchen Analyse dürfte sich für eine juristische Untersuchung somit in Luft auflösen. Solange die Unschuldsvermutung gilt und die überwachte Zielperson nicht auf andere Art und Weise der zeitgleichen Benutzung überführt werden kann, besteht immer die Möglichkeit, dass jemand anderes als die beschuldigte Person zur fraglichen Zeit das Gerät bediente.

Trennung von Daten

Bei einer Überwachung mittels Staatstrojaner wäre besonders bei Geräten, die regelmässig von mehreren legitimen Benutzern bedient werden, eine Trennung der Benutzerdaten problematisch, wenn nicht gar unmöglich.

So kann beispielsweise nicht von vornherein festgestellt werden, welche Daten für eine strafrechtliche Verfolgung relevant sind und welche nicht. Somit müssten alle Daten durchforstet werden, was mitunter einen massiven Eingriff in die Privatsphäre von unbeteiligten Personen zur Folge hätte.

Zentrale Lagerung

Wie im Statement von Bundesrätin Simonetta Sommaruga nachgelesen werden kann, werden die bei den Überwachungen gesammelten Daten zentral abgelegt. Dies wiederum bringt gänzlich neue Probleme mit sich, die es ebenfalls zu adressieren gilt.

So muss der Zugriff auf die Daten strikt nach dem Datenschutzgesetz geregelt und diese Regelungen konsequent durchgesetzt werden. Denn eine derart grosse Menge an Informationen ist eine Einladung für Kriminelle und korrupte Mitarbeiter – Ein Problem, vor dem man nicht einfach die Augen verschliessen darf.

Anti-Malware

Software, die zur Aufgabe hat, Schadsoftware zu erkennen und zu entfernen, setzt hierzu mitunter heuristische Erkennungsmethoden ein. Dies ermöglicht es der Software, aufgrund des Verhaltens installierter Programme zu entscheiden, ob diese schädlicher Natur sind oder nicht.

Um diese Erkennung zu verhindern, müssten sämtliche Hersteller die Signatur des Staatstrojaners in ihre Datenbanken aufnehmen und als gutartig kennzeichnen. Dies wird aber vermutlich stark erschwert durch die Tatsache, dass viele dieser Hersteller ihre Sitze im Ausland haben und somit ein Interessenskonflikt zwischen der schweizerischen Regierung und der Regierung deren Länder besteht.

Des weiteren besteht dann die Gefahr, dass jemand, der an die Signatur des Staatstrojaners kommt, eine Malware herzustellen in der Lage ist, die von Antivirensoftware nicht mehr erkannt wird. Kriminelle könnten dann ungestört illegalen Machenschaften nachgehen, die von Benutzern grösstenteils nicht mehr aufgedeckt würden.

Diese Situation kann natürlich nur eintreten, wenn der Staatstrojaner grossflächig eingesetzt würde. Da es im letzten Jahr in der Schweiz nur zu 46 Internetüberwachungen kam, dürfte sich das Risiko in dieser Hinsicht relativieren.

Fazit

Der Einsatz von Staatstrojanern bleibt nach wie vor fragwürdig. Nicht nur, dass sie sich rechtsstaatlicher Kritik ausgesetzt sehen, auch aus technischer Sicht bestehen beträchtliche Hürden, die erst noch genommen werden müssen. Schliesslich ist das Missbrauchspotenzial bei solch invasiven Massnahmen massiv. Dies gilt es zu erkennen und einzudämmen. Ob dies allerdings gelingt, ist in Anbetracht der gegebenen Komplexität der Situation mehr als fragwürdig.

Manche Schweizer mögen sich noch gut an die 80er Jahre und an 2010 erinnern, als die sogenannten Fichenaffären ein grosses Thema waren. Das eidgenössisches Justiz- und Polizeidepartement wird sich grösstmögliche Mühe geben müssen, um die Ängste zu diesem Thema glaubwürdig zu zerstreuen. Ein einfacher Vertrauensaufruf wird in diesem Fall kaum ausreichen.

Sean Rütschi | G+ (850 Wörter)

► 02.05.2013 – Overview of Microsoft’s security toolkit EMET

Introduction

Microsoft has developed several tools that help security professionals in the difficult task to keep Windows operating systems safe, like the Microsoft Baseline Security Analyzer (MBSA) or the Security Compliance Manager (SCM). This time we like to give an overview of another interesting piece of windows security software: the Enhanced Mitigation Experience Toolkit (EMET).

EMET is an utility to help protect the Windows operating system platforms against exploitation of vulnerabilities through a series of security mitigation technologies. As any other security tools, EMET does not replace other information security solutions; it is meant to add an additional layer of defence in the existing security framework.

While it may not prevent all possible security exploits, the mitigation technologies implemented by EMET make exploitation significantly more difficult if configured properly.

Features

EMET supports client and server based operating system. The current version (4.0 beta) allows security mitigation technologies to be configured for the system and applications. Mitigations applied to the system will impact the entire system while mitigations applied to the applications will only impact the specified applications. This provides following key benefits:

• Highly configurable even on single executables base
• Application hardening support for all application without recompiling
• GUI allowing ease of configuration
• Enterprise ready (supports group policy deployment, SCCM and command line interface)
• Ongoing improvement and updates

Further, following are the most interesting new features in EMET 4.0:

• Detecting attacks that uses suspicious SSL/TLS certificates
• Allowing customers to test mitigations with an Audit Mode

Below is a table listing the used mitigation technologies:

For more information please refer to the well written EMET 4.0 user manual available via Help menu on the EMET GUI.

Not all mitigation option are supported on all operating systems and application, but Microsoft is continuously improving the software and providing support for all important platforms and application executables.

Here a short overview on supported features on platform and executables:

Another limitation is bound to the web Certificate Trust, it works only with following browsers:

• Internet Explorer 32bit desktop mode
• Internet Explorer mixed 32/64bit desktop mode

Unsupported are by now following versions:

• Win8 APP mode
• Internet Explorer in full 64bit desktop mode (security enhanced mode)

How it works

EMET is not a fire and forget toolkit, it requires you to carefully configure the policy and thoroughly test it before it can be used for production environment; also EMET is not an end-user tool like an anti-virus.

After the installation (that requires .NET Framework 4 and eventually a restart) you can begin using EMET by starting its GUI. It will the show something like this:

In the first window half you’ll see the available system features and its related status: Enabled, Application Opt-In, Application Opt-Out or Disabled; in the second half the are the systems running processes and related active mitigation features. The system mitigation settings are configurable via this panel:

The application mitigation settings are configurable on this other panel:

To add an application specific mitigation settings just push to the add button or right-click in the list of running processes, you’ll then be able to select the mitigation settings checkbox.

All action are written into the Windows application log and reported by the tray icon so if you need to analyze what happens you can filter for EMET log source there; this is important if you are running in audit mode and don’t kill processes that are violating the policy. By default processes are killed here are the configuration settings:

Certificate Trust (configurable certificate pinning)

EMET 4 provides a crypto extension module that will add additional checks during the certificate chain trust validation process. When browsing to an HTTPS website, EMET will validate the end-entity SSL certificate and the Root CA that issued that certificate against the rule configured.

Depending on the rules configured for a specific domain, EMET will detect when a variation of the issuing Root CA for a specific SSL certificate occurs. In this case EMET will only detect the anomaly, but the connection will not be stopped. Exceptions can be also configured on some properties of the Root CA certificate, such as key size, hashing algorithm, and issuer country. For example you can rise a warning if the certificate key length is lower that 2048 bit.

As a short test we can define a pinning policy that has following settings in CONFIGURE/CERTIFICATE TRUST/PINNING RULES/ADD:

• Name: TRUSTED.SSL
• Certificate: click and import GeoTrust
• Minimum Key Size: 2048
• Allowed Country: N/A
• Blocked Hash: MD2,MD4,MD5

Now go to Protected Web Site tab and add a site to test:

• Website: www.google.com
• Select the Pinning rule: TRUSTED.SSL
• be sure to check the Active checkbox

Well, this will ensure that Man in the middle attacks will generate an EMET agent warning message. Now if you like to test it just change a parameter in the pinning rule, like the key length from 2048 to 4096 or just change the Trusted Root CA.

After the changes try to access the site again and a message like this should pup up:

And the following entry inside the application log:

Conclusion

EMET is a powerful toolkit but need to be well configured and tested before going to production. Security on this level is pretty much the last layer of defense. We would recommend to use EMET to finalize your security strategy on very critical components like:

Invest time to create a policy that fits the specific machine usage; don’t try to. Once it’s done, you’ll get a very useful toolkit against Malware… and all for free!!

Andrea Covello | G+ (1623 Wörter)

► 26.04.2013 – Blog Digest April 2013

• 2013 Information Security Survey (liebsoft.com)
• 8 tips for a security incident handling plan (nakedsecurity.sophos.com)
• Apple Finally Reveals How Long Siri Keeps Your Data (wired.com)
• Before you move to the cloud (resources.infosecinstitute.com)
• Debunking Myths: Penetration Testing is a Waste of Time (infosecisland.com)
• Dilbert comic strip for 04/07/2013 (dilbert.com)
• Fuzzers Need Taming (blog.regehr.org)
• Google Uses Reputation To Detect Malicious Downloads (darkreading.com)
• How Attackers Choose Which Vulnerabilities To Exploit (darkreading.com)
• If iOS is Less Secure, Why Does Android Get Attacked? (veracode.com)
• Inside VirusTotal’s pants: VirusTotal += PCAP Analyzer (blog.virustotal.com)
• Is security really dead? Perhaps it’s your lack of depth (nakedsecurity.sophos.com)
• Is Your Scanning Vendor Cheating? (infosecisland.com)
• It’s been an epic few days: What happened? (facebook.com)
• Making Patching Work for SCADA and ICS Security (tofinosecurity.com)
• Memory Safe C/C++: Time to Flip the Switch (blog.regehr.org)
• Metasploit 4.6.0 Released! (community.rapid7.com)
• Nmap Development: Hack Attack (seclists.org)
• Password reset questions (blogs.securiteam.com)
• Secrets of FBI Smartphone Surveillance Tool Revealed in Court Fight (wired.com)
• Security Professionals Embrace Not-So-Secure Mobile Work Habits (pingidentity.com)
• The Boston Marathon Bombing: Keep Calm and Carry On (theatlantic.com)
• The CISO’s Guide to Advanced Attackers (securosis.com)
• The WordPress Brute Force Attack Timeline (blog.sucuri.net)
• When Offense and Defense Become One (pen-testing.sans.org)
• xkcd: All Adobe Updates (xkcd.com)
• xkcd: Authorization (xkcd.com)

Marc Ruef | G+ (402 Wörter)

Alle Einträge

• Letzte Beiträge
  • Kurzanalyse des Windows Privilege Escalation Exploit
  • Are we even moving?
  • Interview zu Wardriving in der Schweiz
  • Blog Digest Mai 2013
  • Sicherheitsverantwortlichkeiten und Risikosteuerung
  • Computer Forensik – Ein Überblick
  • Vortrag zu Security Testing an SGRP Veranstaltung
  • Staatstrojaner – Kritik am neuen Bundesgesetz
  • Overview of Microsoft’s security toolkit EMET
  • Blog Digest April 2013
• Archiv
  • 2013 | 2012 | 2011 | 2010 | 2009 |

• Autoren

• Blog Digest

• Blogroll
  • abuse.ch
  • c22.cc
  • computec.ch
  • darkreading.com
  • infosecisland.com
  • krebsonsecurity
  • metasploit.com
  • schneier.com
  • securiteam.com
  • stfn.ch
  • zeltser.com
  • 5e4n.ch
• Syndication
  • RSS
  • Twitter