Episode 1 – December 7, 2012

Podcast: Play in new window | Download | Embed

Subscribe: RSS

Introduction

Topics

DigiNotar Final Report

What happened?

• At least 531 certificates forged
• Resulted in MITM attacks of 600000 Iranians

How did it happen?

• vulnerable web apps (dotnetnuke)
• traversing network using credentials found (connected to MSSQL server on an internal network from external web server using credentials found on the web server)
• apparently poor hygiene (note references to weak passwords and many exceptions to firewall rules in an otherwise well designed network)

What can we learn?

• From the report:
  • Separate system admin duties from security and firewall admin duties
  • Air gap vital systems as much as possible, to make sure that they are physically separated on a network level from untrusted networks such as the Internet.
  • Update all software products on all systems with the latest patches as often as possible.
  • Subscribe to relevant mailing lists or use dedicated patch management software to support this process.
  • Harden all systems. Do not rely on default settings.
  • Make sure that the most critical systems are only being used for the critical processes that they are intended for. By limiting the amount of services on any given system, the attack surface for an attacker is limited.
  • Regularly have the security of your infrastructure and systems therein tested by penetration testers. Do not always use the same team to perform penetration tests.
  • Monitor your systems and network and make sure that anomalies trigger notifications to the appropriate employee(s).
  • Use data that can be accumulated by the OCSP responder to check if unknown serials are being validated.
  • Separate vital logging services from the systems that perform other vital functions. In an infrastructure where secure logging is vital, a logging server can be placed behind a unidirectional security gateway.
  • Ensure forensic readiness so that, for example, all events that are relevant for an incident response team are logged, that events from multiple systems can be correlated, that a balance is found in advance between business continuity and potential evidence gathering, that roles and reporting structures are defined for and communicated to all employees and external parties that take part in incident response before an incident takes place and that a feedback loop is created to learn from incidents in the past.

• My additional recommendations:
  • Focus on good password usage, or use 2 factor authentication
  • Limit the permissions of service accounts, like those used for web servers to connect to back end databases

Fun Stuff

Must read of the week: http://blog.ioactive.com/2012/11/the-future-of-automated-malware.html by Stephan Chenette from IOActive
This article describes the current arms race with malware and defenses, and where it’s likely headed. One of the most thorough posts I’ve ever read.

Book report: Douglas Hubbard’s “How to measure anything: finding the value of intangibles in business”.