Far from proposing you a full formation to ISO 27005, this short post will introduce to you the basis to keep in mind before starting any new Security Project.
Indeed, contrary to other investments, security won’t bring new value to your company Business; instead, it gives you the promise to protect your current value. As I’ve already discussed with students in a recent lecture, I gave on the Risks of IT Outsourcing, when you subscribe to a new outsourcing contract, concerning security, the External Service Provider (ESP) has an obligation of means he should apply rather than results. For this reason, Key Performance Indicators relative to IT security are particularly tricky to define.
As containers became a standard in IT applications, enumerating a few security best practices is now a business need. Therefore I’ve defined those three golden rules to keep in mind before pushing a new image for production to your company container repository.
I Careful with share volumes you will be
Contrary to a Virtual Machine, a Docker container uses the host kernel directly, so in case of a kernel vulnerability restricted permissions on shared resources won’t protect you from an attacker.
For example, the vulnerability Dirty Cow 1 is still used to get a root access on stock Android rom up to Nougat 2.
I won’t make a video on how to exploit this vulnerability, but if you’re interested in, you can find a very detailed blog post on Aqua Security blog 3.
Let’s now deal with a more enjoyable subject.
In my precedent posts, it was essentially related to Sysadmin aspects, I wrote those articles as I wasn’t able to find any satisfyingly complete reference online, so I’ve decided to write them. However, you probably see in my description corner that I am an Amazon Web Services certified, adept of DevOps and with a strong focus on the security aspects.
As I’ve got freshly, AWS Security Specialty certified, it was high time I approached an AWS security oriented subject; I’m not going to describe how I’ve built and deployed this website, I myself found all the needed information here.
Unfortunately, deploying a good TLS implementation is far less common, also as I was browsing Troy Hunt blog, I fell on his impressive article The 6-Step “Happy Path” to HTTPS.
As I recently had to manage an integration project for the Security Operation Center service of a big company, I had to configure applicative logs forwarding to the nearest SIEM syslog collector for each service included in the scope.
I’ve found that the rsyslog agent is usually preinstalled in any Unix distribution with default operating system log folders configured out of the box so that the system log forwarding is most of the time almost as simple as service rsyslog start1.
In other cases, if you want to forward certain log files only, for example, your application user login history in order to detect any brute force attempt, it may be better to configure them directly through the rsyslogimfile module.
To introduce this post, let’s imagine you have a very bad IT provider which delivers you anon configured server. This server is so badly configured that although you have a CentOS machine installed on it, you only have access to the server management interface. Of course for project deadline reason, sending it back to your integrator, so that he can configure it a bit better, isn’t an option. OMG, what can we do?