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...
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.
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.
FWIW, I saw that ad. Looks very interesting, but I think you may have a challenge getting someone who is a Vuln researcher/pen tester type (who most commonly have CVEs, PoCs to their name) who also has a decent knowledge of banking security, policies etc and also is looking to graduate out of technical work into team management...
Most of the pentesters/vuln researchers I know aren't huge fans of writing ISO2700x style policies documents (actually thinking about it there aren't many people who are fans of that kind of thing!)
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...
I wonder why you got downvoted for this, for me security is a key concern for the challenger banks.
What Mondo is (from my reading) trying to do is very cool but quite ambitious. A new bank in 2016 will be a serious target for quite sophisticated attackers so they're going to have to do app/inf/ops security very well do avoid damage.
On the flip-side they have the once in a lifetime golden opportunity of a green-field deployment to actually get security baked into their systems before they're live without a load of legacy cruft holding them back.
Your comment relates more, I think, to the general Docker project than subuser specifically.
The answer to your question is that it all depends on your definition of "easier".
docker/docker hub hide a lot of complexity in linux namespacing/cgroups/seccomp filtering. You can absolutely achieve the same goal with native linux tools, as long as you have the time and inclination to learn those tools.
FWIW I think this is pretty cool. The main docker use-case is not desktop software, and some of it's choices are unlikely to suit that use-case well.
So, good to see a project look at that aspect. I would quite like to be able to run all my apps which access untrusted services (e.g. all browsers) in a container which I can easily wipe/reset.
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...