At the RSA Conference in 2009 I presented “Top Threats to Personally Identifiable Information” for SafeNet where I attempted to prove from breach data that PCI DSS was having a tangible positive effect. My charts illustrated that despite breaches overall in a rise a filter for PCI DSS revealed a decline for industries adopting prescriptive compliance controls.

It was a tough illustration because of so many moving parts and the quality of data. My prediction that overall breaches would go down, because they already were going down in specific areas, was fun to try and prove. Yet everyone seemed to ask for more data on the biggest breaches instead of analysis of the overall trends. That is how my following presentations turned into the popular series called “Top 10 Breaches“.

Well, that’s not entirely the case. Each time I ran into Robert Hanson (RSnake) he asked for updates on the overall breach trend analysis. He kept reminding me that more people needed to see my contrariness. So credit goes to him for encouraging me to update the analysis and data for a presentation called “Message in a Bottle” for MetriCon. Unfortunately the Metricon presentation did not happen. It feels like it might be time to dust it off. This week I ran into an interesting update from Nigeria.

The Central Bank of Nigeria (CBN) announced six months ago that it was increasing compliance controls based on PCI DSS to combat financial fraud

…due to the failure of the nation’s banks to obey the CBN’s ATM regulatory framework and ensure compliance with these rules the apex bank rolled out penalties for non compliance with Payment Card Industry Data Security Standards (PCIDSS)

Modest fines were linked to the presence of audit trails and timeliness of response

…an ATM deployer would be made to refund the full amount involved in any fraud perpetrated on its ATM for failure to provide video recordings on the disputed transaction when required.

It pointed out that failure to respond to the customer or to the CBN on ATM complaints within 72 hours would attract a fine of N50, 000 [USD$300] per day for each complaint after the 72 hours until the response is received, adding that failure to resolve any ATM dispute with evidence of resolution within 14 days, would result in the deployer refunding the total amount involved in the fraud.

Similarly, the CBN stated that non-compliance with migration to EMV after September 30, 2010, will attract a fine of N50, 000 and the issuer will bear full liability for any fraud perpetrated with the magnetic-stripe card, adding that failure to provide audit trails and journals for ATM transactions would attract a fine of N50, 000 per week.

It further stated that for non-compliance with Payment Card Industry Data Security Standards (PCIDSS), a fine of N50, 000 per week will apply to the defaulter until compliance is established. It, however, said that non-compliance of ATM terminals with EMV levels 1 and 2, would attract a fine of N50, 000 and temporary suspension of the affected terminal unit until compliance is established.

Then, just this past week, the CBN reported that its compliance program has had a dramatic effect on ATM fraud

The Central Bank of Nigeria has said that the banking sector was on the way to recovery as banks Automated Teller Machine (ATM) frauds reduced by 90 per cent.

The governor of the apex bank and chairman, Steering Committee on Financial System Strategy 2020(FSS2020), Mallam Sanusi Lamido Sanusi, made this known on Wednesday in Abuja at the opening of the Strategy Execution Master Class of the FSS 2020.

In the banking sector, he said there had been a drastic drop in the level of non-performing loans adding that there had been structured growth of banks in the areas of capitalisation, capital adequacy and liquidity ratio.

They have not yet released data points to support this news. I am a skeptical believer and wonder how such a profound change can be extrapolated to the future from such a short time. It was announced with a suspicious amount of confidence. There must be more to the story than meets the eye. I can’t wait to see the numbers and roll them to the global data I collect for analysis of the trends and effects of compliance.

It has been nearly 20 years since VLANs were introduced. A move to make them virtual with VXLAN (Virtual Extensible VLAN) is now generating some interesting threads of resistance. A thread by Ken Duda tries to tease out architecture concerns.

Denton: the simple way to think about VXLAN is that each neighbor VTEP [VXLAN Tunnel End Point] is like a switchport (bridging endpoint) and ordinary 802.1d MAC learning/aging/unknown-DA-flooding applies, where IP multicast takes the place of LAN broadcast. So, when some endstation moves, the next time they send a broadcast or send a unicast to you, you say to yourself, “gee, I didn’t expect to see that (segment, MAC address) come from that VTEP IP source address,” and then you update your MAC table accordingly. Just like ordinary layer 2 bridging. Likewise with VRRP [Virtual Router Redundancy Protocol] — if the new VRRP active router sends gratuitous ARP requests (as per the VRRP spec), then these ARPs are delivered via VXLAN-encapsulated IP multicast to all VTEP’s (that carry the router interface’s segment and thus subscribed to the IP multicast group), and they all then update the router’s MAC address in their MAC tables accordingly.

Encapsulation of MAC in IP might seem scary and more prone to hijack, but then again encapsulation logically follows computers inside computers.

The question should not be whether we can get old tools to handle all change. That’s always a risk of progress and it can be a good problem to have — market for new tools.

Given that tools evolve a question also then is not whether we lose the ability to see inside (encapsulated does not have to mean opaque/crypto), but whether encapsulated assets can be given controls as secure/robust as their wrapper.

To this end, Denton Gentry has written up a nicely illustrated follow-up to the thread started by Ken.

The encapsulated packet retains its Inner MAC header and optional Inner VLAN, but has no Inner CRC. When VMs send packets to other VMs within a server they do not calculate a CRC, one is added by a physical NIC when the packet leaves the server. As the VTEP is a software component within the server, prior to hitting any NIC, the frames have no CRC when the VTEP gets them. Therefore there is no integrity protection end to end, from the originating VM to receiving. This is another case where even on L2 networks, the Ethernet CRC does not work the way our intuition would suggest.

Example from Springsource, as explained by Wouter Coekaerts, showing why clients should not be trusted.

Affected: Applications that have Spring AOP on the classpath and deserialize a stream from an untrusted source
Result: Arbitrary code execution

Short version: The problem is that the JdkDynamicAopProxy, DefaultListableBeanFactory and some other Spring classes are Serializable and can be configured to execute arbitrary code when the application uses these deserialized objects.

[…]

The vulnerability has been fixed in Spring by making it impossible to deserialize a DefaultListableBeanFactory except through the SerializedBeanFactoryReference. And the id used by the SerializedBeanFactoryReference has been made easier to configure because it should not be predictable by a client.

Springsource has the announcement of the CVE posted but the NIST site gives only this error:

ERROR, “CVE-2011-2894” is valid CVE format, but CVE was not found.