Zertifikate auf Nokias
May 20th, 2008
SQL Injections
April 28th, 2008
Microsoft’s SDL has Saved the World!!
April 20th, 2008
Surety
April 16th, 2008
April 2008 Critical Patch Update Released
April 16th, 2008
Jeder Security Patch muss appliziert werden
March 29th, 2008
Separation of Duties vs. Concept of Least Privilege
March 27th, 2008
Oracle Security Masterclass mit Pete Finnigan
March 9th, 2008
Tutorial on Defending Against SQL Injection
February 9th, 2008
Da ist es ja, das SQL Injection Tutorial von Oracle. Bei jedem Security CAC immer angekündigt, taucht es plötzlich ohne weiteres Announcement auf der Oracle Server Technologies Homepage auf.
Es handelt sich um die interne Schulung für die Oracle Development Teams, ist aber natürlich für jeden PL/SQL Entwickler oder Consultant sehr empfehlenswert. SQL Injection geht jeden an!
Ein guter Schachzug von Oracle, um den lädierten Ruf in Security-Belangen etwas aufzubessern.
Darauf gestossen bin ich via Lutz’ Blog (der auch immer seltener schreibt).
Die Psychologie des Patchens
February 5th, 2008
Die Digital Soapbox hat einen Artikel über The Psychology of Patching…
I’m not saying patching isn’t critical and important, don’t get me wrong – but it shouldn’t be as “all-important” as some people from our security realm would dictate. If you don’t patch to the latest Oracle patch-bundle, the sky won’t fall if your application design is security-conscious.
Ausgelöst durch einen Blog von Eric Maurice, via ZDNets Zero Day Blog. Die Frage war, ob man Patchen einfach einplanen muss, oder ob es gute Gründe gibt, die gegen das Applizieren jedes Security Patches sprechen.
Da gilt es immer zu beachten, dass nicht nur Patchen direkt Kosten verursacht, sondern Nichtpatchen indirekt auch Kosten verursachen kann. Die lassen sich aber schlecht quantifizieren, so dass man sie in extrem kostenbewussten Environments am liebsten ganz ignoriert.
Und dafür den den Applikationsteam als Hausaufgabe mitgibt, die Applikation securitybewusst zu entwickeln… und damit die Kosten einfach verlagert. Anhand dieser Argumentation sieht man immer gut, ob jemand eher aus dem IT-Infrastruktur-Lager kommt, oder aus Development-Team.
