This article over on Computerworld Australia seems to have a couple of conflicting items that have been bugging me since I read it the other day. The article begins by mentioning potential changes to federal government legislation:

The changes will give employers power to intercept all Internet-based communications without consent, including e-mails and instant message (IM) discussions.

It’s at this point that all of sudden we go on a massive tangent, whereby the Attorney-General is saying that these legislative changes are a counter-terrorism measure, and that these changes could prevent breaches occurring:

…similar to the Estonian Denial of Service (DoS) attacks in which a 19 year-old hacker disabled the Web sites of banks, schools and the Prime Minister’s office.

Hopefully someone out there can explain to me exactly how allowing employers monitoring rights to their employees is a control against denial of service attacks? Or even better, how exactly a denial of service attack equates to a breach? Especially after they’ve done such a good job of defining what an Information Security Breach is in the “Draft Voluntary Information Security Breach Notification Guide“.

An information security breach occurs when personal information is exposed to unauthorised access, use, disclosure or modification as a result of a breach of an agency’s or organisation’s information security.

The only saving grace in the article was the comment from Nick Elsmore from SIFT where he states that these new laws will have minimal impact on businesses due to most enterprises having provisions for Internet monitoring within employee contracts. My experience in a few different enterprises has proven this to be the case.

Just had a quick play with Don’s Windows Incident Response Script and am very happy that someone else has put in the time and effort for something as useful as this, and then provided it for all. Some of the useful information it captures includes:

• User Account Information – Account name, Full name, SID, LocalAccount
• System Information – Hostname, manufacturer, OS Type, version, SP etc
• PreFetch File Information (this is AWESOME) – the metadata of about the last 128 programs that were executed
• Installed Software
• Windows Setup Log
• USBSTOR Registry Key
• Windows Firewall Exception List
• Log On and Off Events (if auditing is turned on of course)
• Event Logs
• Temp Internet Information
• Running Processes
• Active Network Connections (ahh netstat)
• Anti-malware logs (dependant on your AV vendor)

So yeah, go check it out.

While I really enjoyed the research performed by Matthew Lewis on his PoC biometric logger, or “BioLogger”, (white paper available from darknet here), I still think that the old-school method of hacking biometric systems is damn cool. 11 steps (with pictures) on how to capture someones fingerprint from a beer bottle. Fantastic!

But what I think Lewis’ research did highlight is something that I’ve thought for a long time, and that is that physical access control systems are more and more relying on network protocols for communication, and more often than not they do not implement security controls all that well. Whilst some of the vulnerabilities can be mitigated with network controls, in the constant drive to provide more accessible systems it is often not possible to apply ACLs to constrain traffic.

A good example is a common, enterprise access control architecture, fairly similar to that as demonstrated by Lewis. To allow the system to be scalable an access control server has to communicate with a number of access control panels. Usually this is facilitated by a TCP/IP accessible network to serial adaptor, or a terminal server. To provide client access to the system the access control server also has to be accessible by clients. Throw into the mix the fact that the client computer is usually accessing the access control server via a web browser (possibly even IE6). All of these channels provide a potential avenue to disrupt an access controls operations, or even to compromise confidentiality or integrity.

Most systems provide client access using HTTP channels, which as we know has a whole host of vulnerabilities, and usually because they assume the systems are being deployed in isolated networks don’t spend much effort in protecting themselves from exploitation. On the other hand, the network to serial adaptors are more often designed as a ‘dumb’ type of device, with management provided over archaic interfaces (such as Telnet), and not developed to withstand a DoS attack. What do you think would occur to a network to serial adaptor if it was flooded and therefore unavailable? The access control server would not be able to communicate with the access control panels, and therefore the doors. Records of building entry might be lost. Alarms might not be raised if doors are forcefully opened. Centralised control of doors is lost. Etc.

While in many environments these risks are mitigated through air-gaps in the network, the common theme occuring these days is integration. “We want the access control system to integrate with the HR system.” “We want our physical security operators to access the system from outside the building.” “We want to integrate the system with our corporate network for email alerting.” “We need our vendors to be able to provide remote diagnostics.” By providing these entry and exit points into these types of systems we obviously increase the risk of them being exploited.

There’s lots of things that can be done to reduce these risks, but I think this post is big enough for the moment.