Tuesday, 6 September 2011

Comments on the Interim report on DigiNotar breach

I have been following DigiNotar incident for some days now. It serves as an excellent example how PKI can be reach and misused for snooping on people Internet traffic.

Yesterday, Fox-IT released the report that shows interim results from the investigations. It makes for very interesting reading. The report is now at this URL and I have uploaded it to my DropBox just in case it is pulled from the page in the future.

Let now have a look at what the report says about weak security controls that potentially allowed the breach to occur (section 4.4 in the report). My comments are included under each point.


  • The successful hack implies that the current network setup and / or procedures at DigiNotar are not sufficiently secure to prevent this kind of attack.
See my comment at the end of the blog post. A much tighter system to assess public Root CAs must be put in place.
  • The most critical servers contain malicious software that can normally be detected by anti-virus software. The separation of critical components was not functioning or was not in place. We have strong indications that the CA-servers, although physically very securely placed in a tempest proof environment, were accessible over the network from the management LAN.
The logical segregation of the key systems, such as CA, is mandatory. When I have implemented a PKI architecture previously, a root CA was only accessible physically in a secure room and we use a Hardware Security Module to protect private keys. 
  • The network has been severely breached. All CA servers were members of one Windows domain, which made it possible to access them all using one obtained user/password combination. The password was not very strong and could easily be brute-forced.
One domain for those critical servers? Would make more sense to have these servers in workgroup so they can stand individually. Also, two-factor authentication to access the servers would make sense.
  • The software installed on the public web servers was outdated and not patched. No antivirus protection was present on the investigated servers.
This is incredible and there is no excuse. 
  • An intrusion prevention system is operational. It is not clear at the moment why it didn‟t block some of the outside web server attacks. No secure central network logging is in place.
I suspect NIPS was not configured to actually look for specific signatures. As you know, most IDS are left i the default installation settings by vendor. These settings are optimised for speed, not signature coverage. And central logging and analysis is really key.

On the other hand, DigiNotar claimed that revenues from the PKI operations is €100k for first 6 months in 2011 (link here). Given these low revenues, I am not surprised they did no invest enough resources into the security of their CA system. But that is not excuse for individuals and companies that allowed DigiNotar Root CA to be placed into our computers and browsers!

Overall, the findings indicate that a proper security architecture and threat modelling has not been implemented very well at DigiNotar. I would understand if some of these lapses in security, as above, were present in a non IT company. However, this is a Certificate Authority that has root certificate in almost all computers in the world! How did it get there? What auditing processes was conducted to make sure that DigiNotar has necessary security controls in place? 

If other Certificate Authorities have had similar weak audits, we cannot trust the CA system at all
The audit bodies that decide to place root certificates to browsers and operating systems should look at Common Assurance Maturity Model @CommonAssurance for a system how to measure maturity of public Certificate authorities.


Reactions:

0 comments:

Post a Comment