HN user

raesene4

267 karma

Security tester, general security type, being doing this kind of thing for 15-20 years in a variety of places. one of several raeseneX accounts for different devices I have :)

Posts1
Comments95
View on HN

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.

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!)

if you're looking for non-traditional advertising routes for this you might want to post on /r/netsec's hiring thread https://www.reddit.com/r/netsec/comments/3zfj6v/rnetsecs_q1_...

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.

You may be thinking of the lack of user namespacing in Docker. Until v1.10 root in a container was the same user as root outside the container.

This did not automatically lead to allow a contained user to breakout, but made it easier.

In 1.10 user namespacing reduces this risk as the root user in a container can be remapped to another user account outside the container.

there are two excerpts from their financial accounts in there if that makes you any happier (and justifies my use of the plural :) one from the P&L and one from the staffing section

The article is working on what's publicly available (there's a surprise), as they can hardly work on what Soundcloud hasn't released! My guess would be that if Soundcloud had managed to get into profitability that quickly then soundcloud would've got a press release out to say that.

edit - didn't realise they were a UK company. So the full accounts and company filing history are https://beta.companieshouse.gov.uk/company/06343600/filing-h...

definitely their cash position at the end of 2014 was not of the best...

I'm not sure I'd agree there's no other facts. links from the article include excerpts from their financial accounts which don't look good (losing 39M on a 17M turnover is not healthy).

And the quote from the auditor is significant, auditors don't put that kind of thing in unless they have to as it annoys their customers to be reminded that there's significant concern over their ability to continue operations.

Surely the decision about what response to make lay with the government (the receiver of the letter) and not Prince Charles (the sender of the letter)?

i.e. They had the choice not to respond or to have a aide respond, but the prime minister chose to respond.

Would you suggest that someone in the monarchy shouldn't express an opinion for fear that the receiver of the letter will pay too much attention to it?

Errr, if the government don't like anyone's opinions, they are entitled to ignore them, but in general I'd say that people are entitled to express their opinions as Prince Charles did.

In terms of "tolerated" the only thing that springs to mind that you'd be suggesting is that the labour government should have somehow stopped Prince Charles from writing the letters? but that seems like an odd thing to suggest, so perhaps I'm missing something

A very interesting post. To me this illustrates a couple of points very well.

1) VMWare likely have no idea what they lost when they cut this team. Once teams just look like just a number of people to be re-located to save costs, there tends not to be consideration of the value of a long-lived team with the experience and team spirit that this post talks about.

2) If you're an employee of a large corp, never ever stay out at a role out of "company loyalty", it's a mugs game. Not to say that that's true for all companies, but large ones seem to have a distressing tendency to treat people as numbers to be valued and shifted and cut, and loyalty shown by the person to the company means very little in these circumstances.