So Docker 1.10 has just landed and with it a number of great new security enhancements. One of the main ones is the enabling of User Namespaces. This adds an extra level of protection as processes running in a container as root will not be running as root on the host Operating System, which makes it harder for a rogue process to break out of the container.
One of the perenial problems of being an infrequent blogger is of course, you forget exactly how you used to do things…
Following on from my last post on Using Docker for Security Testing, I thought it would be interesting to see if we can set-up an even more automated environment by using Docker Compose. Docker Compose is a means of creating a linked set of containers, which you can configure to be started up together, so useful where you want to make use of multiple systems at the same time.
Following on from my previous post about Docker, I’ve been giving some thoughts to how I could make use of this in my day-to-day work of security testing.
I’ve been spending some time this weekend looking more at docker and where I think it could be useful for my workflows, and along the way I’ve learned a couple of things which I didn’t know, so I thought it would be worth recording them, in case they’re useful to others. None of this is particularly earth shattering but hey could save someone some time :)
I realised the other day that I’ve been doing public speaking for quite a while now (started with doing internal training courses back in the 90’s, and graduated on to doing external speaking at seminars and conferences about 10 years back).
One of the perennial problems in security is the lack of hard data, so it’s been good to see over the last couple of years a growing number of reports coming out which seek to shed a bit more light on what’s happening in InfoSec. One of the more prominent of these reports is the Verizon Data Breach Investigation report and I always read it as it has some interesting insights into what’s happening in areas that I don’t get too much exposure too.
Last week I did a presentation for the Securi-Tay Conference. The title of the talk was “Security and ‘modern’ software development”, and the main theme of the talk was looking at library repositories like Rubygems, npm and NuGet and how an attacker could try and place malicous content into those locations.
Like most web application testers, I’m a fan of using Burp Suite for automation and generally making the process of completing a test a whole lot easier.
I’ve had cause to work with some of the more common Vulnerability Assessment scanners recently, and I couldn’t help but notice that a lot of the findings related to incorrect configuration of, or bugs with, SSL implementations.
