DEVOXX on Security

My Call For Paper post for the DEVOXX Belgium 2015 conference, where I’m track lead of the “Architecture and Security” track.

http://devoxx.be

TL;DR

We, the DEVOXX 2015 Security track team, want to increase security awareness among software and hardware developers. We want to make this year’s track about understanding how to break things, and knowing that this understanding allows developers to design and build more secure systems. Security has to be by design, not by feature, use case or layer.

In this spirit, we would like to invite you to submit talks around the subjects on how to stress security of software projects and on how to deal with these aspects as a developer and architect. Any submission of topic ideas is very welcome too.

Statement

“The security situation is catastrophic in our modern ICT world!”

Discussion

This sentence reads like a gossip magazine headline. Unfortunately, it is an accurate description of today’s reality.

Nowadays, even coffee machines are connected to the Internet. People read their morning mails on their phone in bed before even taking a shower. The internet has become an integral part of our infrastructure (emphasis on this word), in the same way as electricity, radio, and warm water.

Yet the basic pillars on which the internet is built were designed in the technological stone age: 1973- first specifications of TCP (IP was part of this), 1983 – DNS, 1995 – SSH-1 (after a password sniffing attack), 1988 – POP3 (1984 – POP1), 1995 – SSL2 (by Netscape), 1999 – TLS1 (successor of SSL), 2006 – TLS1.1 (major security improvements), 1971 – FTP, 1998 – FTP with IP6 support, 1982 – SMTP, 2008 – Extended SMTP (what we use today)… and so on!  (Sources: Wikipedia and Living Internet)

Obviously, the idea of having these designs as the foundation of a world-wide network in the 21st century – one that handles 99% of modern communication and is of critical importance to world’s economy and real-world security – never crossed the minds of the many early technology pioneers. As a consequence, security has never been a principal design goal, and the security requirements we have today were simply unimaginable at that time.

While probably agreeing with the above statements, you may certainly be wondering why you are reading these conclusions in the blog of a Java and JVM-centric developer conference.

The answer is simple: you are concerned! Excessively concerned!

It is obvious that everybody is concerned by software and hardware security – and that includes non-techy “civilians”, who became painfully aware of this when the most popular web site for “adult dating” was hacked at the beginning of 2015.

But we are developers! We are the people building the systems running on this global network and dealing with a colossal amount of information – and even the most innocuous of data can become sensitive when used in the right context or linked to other “innocent” looking information. And we are building on shaky fundamentals.

Not only are we developers are the first line of defense when it comes to security – the millions of coders world-wide are also often the only line of defense.

Being realistic, let’s think about how much code we write that deviates from the “happy path”. Once code is “committed”, chances are that nobody will ever test these special situations again. And speaking of tests: How many level unit, integration, functional, mutant, smoke and other tests do we write to address actual security related situations in our common code? How can we even test the “unknown”? Do we have to test underlying libraries or should we put all our trust in unverified complexity and quality? What is the risk of often blindly trusting (expensive) black-box test products which claim to verify the “security” of our interfaces?

Generally, we, the makers of increasingly complex software and hardware devices, delegate security to frameworks, to protocols, to specialised code reviewers and to mostly automated pen-testing tools. We often see security as feature, while in reality it is, it has to be, a central concern.

Security has to be by design, not by functionality, nor use case or layer. Think that’s obvious to most people? Wrong! Examples to the contrary are legion: just look at CVE-2014-3120, CVE-2015-0984, CVE-2015-2052 and so many more…

What can we do to evolve this situation for the better? Some good points to consider are: awareness, knowledge and understanding.

Being aware that security has to be part of our fundamental thinking and design process, as well as understanding of how it’s possible to break the things we are building, is pivotal to naturally increasing the level of security of the devices we build.

This is the point where we finally come to our mission at DEVOXX. We, the DEVOXX 2015 Security track team, wish to increase awareness of security of software and hardware developers. We want to put this year’s track focus on understanding how to break things, knowing that this understanding allows developers to design and build more secure systems. Security has to be by design, not by feature, use case, or layer.

In this spirit, we would like to invite you to submit talks based on how you go about stressing the security of software projects, and how to deal with these aspects as a developer and architect. Any submission of topic ideas is very welcome too.

Code safe, be safe! :)

Leave a Reply

Your email address will not be published. Required fields are marked *