Playing Capture The Flag with a team on location is something completely different than performing penetration tests, security assessments or even trying to solve CTF challenges over the Internet.

At Defcon 23 I joined a team of really knowledgeable, nice and friendly people for the OpenCTF competition. It was an exhilarating ride from setting up all equipment to the glorious finish. Playing Capture The Flag on Defcon was educational but foremost fun, fun and fun.

So why would you spend a good chunk of 48 hours sitting in a chair behind a screen while there is so much more to see and experience at Defcon ? In one word: The undescribable exciting atmosphere of playing during a conference, of competing against all these bright people from all over the world, desperately trying to solve the challenges.

Here are some of my personal notes on how to get the most out of competing in an OpenCTF competition with a team:

• Allow plenty of time before the competition to set up (and harden - don't be a fool like me) your machine. Make sure you have all necessary tools and notes.
• Make sure beforehand that all team members have one communication channel (eg. IRC …

Some observations:

I had the chance to visit CrikeyCon February 2015, which was held in Brisbane

It was the second time this event was held, but it already got the looks and feel of a professional organization behind it. The program was really diverse, from social engineering and awkward hugs to iOS runtime hacking, and everything in between.

Takeaway ? Well, it surprised me to hear that there's still a general feeling of us versus them. We the security gods who lay bare all the faults and stupid mistakes the others make.

As a security professional, especially as a pentester, it's your job to find vulnerabilities and weaknesses. It's your job to hunt for other people's mistakes, lack of knowledge, or constrained security budgets. Security falls into the quality assurance department.

This means that most of the time you're telling other people what's wrong with an application. Unfortunately it's not your job to tell them how awesome their web application is, how well it scales, or the nifty features it has.

One of the more challenging issues when for instance presenting a pentest report to a group of developers is to get everybody on board, to get everybody to work together. And if …

MSYS can best be described as a Bash shell and some GNU tools, which facilitate compiling sources under and for a Windows environment. It's the environment to use when compiling for instance OpenSSL or Emacs on Windows.

MSYS2 is the 'new and improved' version of MSYS.

One of its biggest advantages is better package management. MSYS2 has pacman, a package manager from Arch Linux. Upgrading can finally be done from within the shell session itself, with only a few basic commands.

# download package descriptions from the remote repositories
pacman -Sy
# upgrade MSYS2 core components and the shell itself
pacman --needed -S bash pacman msys2-runtime
# restart MSYS2 if any package needed updating, then update the rest
pacman -Su

This was 'somewhat more difficult' under MSYS.

Another advantage is the Bash version - currently at 4.3.30 versus 3.1.17 on MSYS. Bash 4 means support for functions like associative arrays and fancier redirections:

# redirect stdout and stderr at the same time
command &> output

# same command in Bash 3 syntax
command > output 2>&1

# pipe stdout and stderr at the same time
command |& someothercommand

# same command in Bash 3 syntax
command 2>&1 \| someothercommand

The third big plus is that it's …

Black Hat Europe was held in Amsterdam in October, 2014. The so called Briefings (tech talks) were extremely versatile, ranging from Android pentesting to SCADA hacks. It was difficult to choose which talk to attend - there were around 50 or so, each title vying for your attention ("Hack Your ATM with Friend's Raspberry.Py" [sic], or "Endrun - Secure Digital Communications for Our Modern Dystopia").

I really enjoyed the technical depth of some talks, and it was great to hear someone like Adi Shamir, one of the inventors of the famous RSA algorithm, talk about his current research.

Because of the sheer size I couldn't find one generic takeaway, or see the, or a current bigger picture in information security land. Even all of the vendors' offerings looked similar.

Now that I come to think of it, that actually IS the key takeaway: Genericity.

DevOps is a worldwide phenomenon, which is reflected by the global popularity of its major event, the DevOps Days.

I was fortunate enough to attend the DevOps Days 2014 in Brisbane.

The keynote speaker was Sidney Dekker, a Dutchman who has extensive experience on human factors and safety. He argued that a lot of major incidents don't have any precursor events.

You can have a clean track record with regards to security and still suffer a huge incident. Do I agree ? Not completely, but nonetheless thought provoking.

Personally I think that the inverse will always hold true: There is a higher chance on a major security incidents after a number of several minor security incidents. Cluttered desks mean cluttered minds after all.

Some buzzwords and issues that were (frequently) discussed:

• Docker - A lightweight virtualization platform (can it live up to its sky-high expectations ?)
• Microservices - Build small, independently deployable services
• ChaosMonkey
• Terminate random virtual machines to test (and improve) resiliency
• Edwards Deming - The godfather of Devops ?

For me the key takeaway was that DevOps doesn't really changes your (level of operational) security. Whether system administrators deploy code built by developers or developers push their own code to an environment - in both …

I'm by no means a crypto expert. Still I'm frequently getting (and answering) questions regarding the use of RC4 in SSL/TLS. Should you disable it? Or keep it enabled?

March 2015 update - A 'new' attack method (Bar Mitsvah Attack) using a previously known RC4 vulnerability was presented, thereby reducing the RC4 security even more.

February 2015 update - RFC 7456 has been published, which effectively prohibits the use of RC4 in TLS.

This document requires that Transport Layer Security (TLS) clients

and servers never negotiate the use of RC4 cipher suites when they

establish connections. This applies to all TLS versions.

See http://tools.ietf.org/html/rfc7465

Here is my reasoning to disable all ciphersuites using RC4:

• RC4 is a stream cipher that has been around since 1987. The number and quality of attacks on RC4 (in SSL/TLS) increases. Fact: Attacks on encryption algorithms only get better, they never get worse.
• A lot of sites still enable RC4 in their ciphers, to support a wide browser base. Fact: Even Internet Explorer on Windows XP supports DES-CBC3-SHA (an alternative to one of the RC4 ciphers)
• RC4 is one of the few ciphers that is resistant to the BEAST attack …