Kees Leune

Everyone with some form of security training should be aware of the fact that information security is commonly defined in terms of Integrity, Confidentiality and Availability. Integrity & Confidentiality is what most security pro's think of when they are securing an infrastructure. We deploy layers of defense, harden applications, encrypt data, develop (implement and monitor) policies and what not.

The availability part is often only addressed in a business continuity / disaster recovery plan. In such a plan, we worry about how a server's outage influences our ability to deliver value to the business and we make educated decisions on the amount of redundancy we need to implement to prevent interruptions or service degradations.

Today's weather is a perfect trigger to go review your business continuity plan. Areas of the USA have been hit by tornado's, the Mid-West is littered with severe weather alerts and other areas are threatened by tropical storms. It has not stopped raining here on the East Coast and it is coming down in buckets.

Are you ready to deal with leaks in the building that houses your primary data processing facilities? Do you have equipment in basements that might be affected by flooding? Have you made your backups (and checked that you can restore them) and stored them in a waterproof location off-site? How quickly can you relocate your critical systems? Do you even know what the critical systems (other than Facebook and Twitter) to your organization are? Is your key personnel aware of the fact that you have a business continuity plan? Are they familiar with it? Do you have an up-to-date call-list? Do you have (several) hardcopies of your plans?

You should have worried about this a long time ago, but if you haven't, now would be a good time to start.

Every now and then, I need to scratch a technical itch. Fortunately, Chris Christianson had the good taste to post Ceasar's Challenge just as it manifested itself.

The challenge was the following:

4500 00c8 21c4 4000 8006 dee4 c0a8 3c01
c0a8 3c35 0014 0841 ea5d efe1 32e0 3fa1
5018 ffff 2c6d 0000 1f8b 0808 d92d 074a
0203 6669 6c65 005d 8ecb 9104 210c 43ef
1385 4210 fe01 e1b8 7ae8 fc43 1871 d8cb
faa0 924b cf82 4812 6419 3aaa e5b4 2e8e
81fd ec8d 87bd e00f c79f f344 767d 41a3
098e 034f f31b 0c39 3f88 9e89 3a46 18dd
af28 706f f8f0 82f7 5db7 d2d0 fc17 634c
54d6 914c 43ed 72c4 532f 6a72 c329 4925
48cb db9c 8564 2cc4 1baf b81c 7a5c cde9
b7af f4b5 5882 c5f9 45c4 852e 62b1 3f3f
c173 e305 f500 0000

After looking at this for a while, it became obvious that this is a IPv4 packet. The first few bytes (4500) are a dead giveaway. Using the SANS TCP/IP cheat sheet, I was able to confirm that this was indeed an IPv4 packet.

First order of business: get this in a workable format. I started with dumping this in a file (challenge.1) and converting it to binary:

xxd -r -p challenge.1 challenge.2

Opening challenge.2 in a hex editor gave me a little more insight into what I was doing. I used hexedit on Linux and notepad++ on Windows.

The payload of the TCP packet started after 20 bytes (5*32/8), or at offset 0x14. Repeating the process of copying the payload into challenge.3 and making it binary using xxd, I got a resulting file challenge.4. The Linux command-line file challenge.4 told me that it was gzip'ed data.

Copying challenge.4 to challenge.5.gz and gunzipping the file yielded challenge.5, which after viewing it in a hex editor turned out to be another IP packet. This time the packet contained a UDP payload going from source port 23149 to destination port 514 on the same two hosts. The payload of the UDP packet looked like syslog, and that is confirmed by the port numbers:

<15>Jun  3 13:16:19 DDDDDDDD GenericLog    0    VWRS VPHOOLQJ SDFNHW SOHDVH

Remember the title of the challenge? Exactly, a Ceasarian shift. Fortunately, it took not too long to figure out that the offset was '3', which resulted in the answer: STOP SMELLING PACKET PLEASE.

I have recently expanded my involvement with SANS by signing up as a Gold adviser. In addition to guiding students through writing their papers, advisers also review work that has been graded by the primary adviser. This endorsement creates an independent quality control review and makes it harder for sub-par papers to go through.

Some of the papers that I have reviewed recently are worth mentioning:

Robert Vandenbrink authored IOScat - a Port of Netcat's TCP functions to Cisco IOS. In the paper, he describes how to implement netcat-like functionality in Cisco IOS using the Tcl language. Any security pro should know about netcat and be familiar with how to use it, so a paper describing how to bring some of its functionality to IOS is a must read. 

As an aside: In a long and dark past, I also used to dabble with that language, and as a matter of fact, it is still the most popular download on this site. The tool I made is used by flightsim fananatics and is called PCProxy

Chris Mohan wrote Virtual Rapid Response Systems. The paper proposes to use virtual machines in incident response scenarios where there is no qualified handler on-site. While the approach may not scale up to large corporate environments without some tweaking, some of the ideas that were proposed are interested and can apply directly to users working for small and medium-sized enterprises.

As always with incident response, make sure that you keep records of what you do. Taking excellent notes is an absolute requirement, as is keeping track of the big pictures. I still develop a tool that assists with the latter: The application for incident response teams (AIRT) supports CSIRTS with the administrative overhead of incident response. The tool is currently in use by several national CSIRTs and institutes for higher education. If you are looking for an incident management product, please drop me a line and we'll talk.

Thanks to Hoff's tweet earlier today, I watched a presentation titled Enterprise Cloud Risk and Security.Not only is the presentation an excellent use of a slide deck (no narration necessary), but some of the observations that are outlined in it are representative of the thought processes of someone who gets it.

"Fundamentally, engineering is about knowing and respecting the limitations of one's materials. ICT systems are built with software being one of the key materials. And software is thoughstuff. For an engineer of thoughtstuff, the limitations of mathematics and cognitive science are the limitations of the material"

Masterson goes on by arguing that "We need to stop thinking in terms of security and start thinking in terms of health". This argument is based on the premise that any time a fairly simple and controlled solution is scaled up, complexity is introduced that invalidates many of the controls meant to keep it secure.

A little later, Masterson introduces another interesting concept: Redundant Arrays of Independent Clouds (RAIC). Brilliant ;) The simple (and compelling) reason for RAIC is a bit of knowledge derived from biology and in particular, ecosystems: diversity = health.

Issues covering legacy security technologies such as firewalls are also briefly touched upon:

"Concept like 'firewall' embody Russellian assumptions, and are only useful in the small. Instead, consider concepts like quarantine, sterilization chambers, and disinfection, for example."

This is not to say that firewalls cannot be useful, but as we see more and more distribution in our computing infrastructure and our data being spread globally, local perimeters will continue to be necessary, but no longer sufficient.

All and all a very interesting presentation in a novel format, bringing some good things to think about. Go watch it.