raesene4

Good article even though I don't agree with all the conclusions.

I find a good way to think about things is that every single dependency you have adds another set of people you have to trust.

You're trusting the competence of the developer (i.e. that the library has no security flaws), you're trusting their intent (i.e. that they don't deliberately put malicious code into the library) and you're trusting their Operational Security practices (i.e. that their systems don't get compromised, leading to loss of control of their libraries).

Now when you think about how little you know about most of the owners of libraries you use, you can see possibility for concern.

The bit I disagree with the article about is signing. I personally think that developer signing is a useful part of this as it takes the repository owner out of the trust picture (if done correctly). Without it you're also trusting the three items above for the repository provider and it's worth noting that a large software repo. is a very tempting target for quite a few well funded attackers.

Docker at least has provided some of the technical pieces to address this in their repositories with content trust...

This is v.cool, although for the Windows version it'd be great if it became possible to swap out the virtualization back-end so it's not tied to Hyper-V.

At the moment VMWare Workstation users will be a bit left out as Windows doesn't like having two hypervisors installed on the same system...

for NPM? As far as I'm aware it's not even an available feature. None of rubygems/PyPi/NuGet require digital signatures...

What repositories were you thinking of that do require that?

A big problem with Software repositories that don't allow for /enforce cryptographic signing by the developer is that this can happen...

Ideally the developer would sign before publishing and the consumer could check the signature to validate before using.

Whilst not a silver bullet this is a kind of essential part of a secure package management solution.

Most of the programming language Package managers that I've seen either don't have the facility or it's not widely used.

Yep, at the moment, with raw docker engine, if a user has access to create containers, they're basically able to get root on the box, as the docker daemon runs as root and there isn't any authorization control by default, so it doesn't work well for that kind of scenario.

With that said there's a couple of ways this is getting addressed.

1) in 1.10 authorization plugins landed as a feature,so it's possible to add this functionality. 2) there's a number of services which run on top of Docker Engine (e.g. Docker Universal Control Plane) which have authentication/authorisation at that level.

With 1.10 you can just enable User namespaces, which allows for root in a container to map to a non-privileged user outside the container, that way it's a one-time (per instance) change.

I'd say that it's a trade-off whether you think the enhanced isolation provided by containerization/virtualization is more of a security benefit than the risks posed by the increased attack surface of another layer in the stack...

Good presentation. One thing I'd mention is that they talk about the CIS security guide, but it's currently pretty out of date as it covers 1.6 and therefore misses a lot of Docker features like Content Trust, User Namespaces and Seccomp-BPF.

In general I'd say that Docker security is getting better, although I'm really looking forward to getting a better authentication/authorisation model on the docker engine as right now it's all or nothing, which is a pretty blunt instrument. Also this model causes problems when people do things like mount docker.sock inside a container for introspection as anyone compromising that container can take over the host. A better authorisation model would allow safer introspection...

Also worth noting as it's not in the presentation, one of the key Docker security features, User Namespaces, is not switched on by default, so you need to enable it on the daemon.

Interestingly that's not the cases everywhere in the UK. for example Dumfries and Galloway saw a 10% drop in property prices last year...

Whilst other areas are expensive London it totally in a league of it's own.

Edinburgh (most expensive part of scotland) average property price £234k. London, average property price £642k

Also people in Scotland and areas like Manchester can more easily get on the property ladder by buying in cheaper nearby areas. for Edinburgh places like West Lothian (average price £164K) make a much easier starting point.

Heck with improving internet access, if you can do your job remotely the western isles are nice and cheap (average price around £100k)

For me the UKs property market is heavily split between London and the south east and "the rest of the country", a lot of the stories about expensive UK property don't seem to cover those aspects.

well whilst hardware tokens are not always the right answer, there are good reasons to resist their replacement with things like "SMS 2FA" which isn't really 2FA at all ,as you have no control over the receiving device, leading to it becoming 1+1FA in a lot of circumstances (e.g. apple continuity, skype account etc)

I've actually been disappointed to see the opposite (companies moving away from providing hardware 2FA) as other options are perceived as cheaper, despite potential weaknesses in the security model.

Yep the customer fraud guarantee is a thing in the UK as well (at the moment), and to an extent that minimizes the loss where it's one customer's app. that gets compromised.

Where I was thinking that a lot of their security challenges will lie is things like internal money processing systems. An attacker with access to a bank's internal systems could make a right mess of things...