raesene4

I was referring to cryptographic package signing (e.g. with PGP) so you validate the signature of the package before installing, this lets you validate that the package hasn't been modified since it was signed.

curl|bash ing a script does not provide this protection.

One important distinction to make is that this very much depends on what package manager you're talking about.

Linux package managers tend to use signing and other mechanisms to check content.

Software library package managers (e.g. npm, rubygems, etc) generally don't. Some of them offer signing but almost no packages are actually signed, and they don't do any curation of content.

The thing I don't see in this article, which I do regard as (another) drawback to curl|bash is that you're not just trusting the software developer, you're also trusting their hosting provider.

Anyone who gets access to modify that script on their server can change the content.

Now it could be that they're hosting on a dedicated system, in a datacentre that they own, with no 3rd party access, but that's very much not the norm for most companies these days, and it's impossible for a customer to verify.

This is a problem which is solved with good package signing practices, where the developer signs the content on a system they control before distribution, so at least you can verify that what you're installing is what they released.

This looks cool, although for the Windows install I'd have hoped that there would be an option to integrate Hyper-V with it instead of Virtualbox, seeing as Hyper-V is available on all Windows 8.1/10 pro/enterprise systems, and having multiple virtualization platforms active on a system is generally a bad idea...

You could of course read the source (although it's likely very few people do), but how do you assure that the code you download and install from the Firefox Add-On store is the same as the code that you read?

As to it being computer operation 101, not to run code you don't trust, how do you establish the trustworthiness of all the pieces of code that run on your computer? there's far too much for anyone to audit by themselves and there is no good way of assessing the security or intent of most of the organisations that you get code from.

I'd suggest that unfortunately the incentives for sites like Kickstarter/Indiegogo/GoFundMe etc are to get as many projects successfully funded as possible that that predicates against rigorous scrutiny of them and exclusion of dubious projects.

There have now been quite a few examples of crowd-funded projects that just haven't delivered and never will (Eyez was a good early example https://www.kickstarter.com/projects/zioneyez/eyeztm-by-zion... $343,000 taken in with nothing to show for it)

exactly, I'd actually argue that Tor exit nodes are, on average, more likely to be untrustworthy than a standard ISP connection, as the incentives are there for people to run them to capture exactly the kind of traffic people want to remain secret, and Tor exit node + root CA certificate is a great model for government level attackers to hoover up data which is likely to be sensitive.

The problem is that as Docker hub doesn't support digital signing of images uploaded to it, you are always trusting docker as well as the provider of the image, as anyone who has access (authorised or unauthorised) to their platform can just change the image.

Good point, it's becoming harder to know how to establish trust in projects. Particularly things like security-related software, and software which opens network ports on your systems, where there's increased impacts if it turns out to be malicious/insecure.

Whilst I'm not the parent commenter I do work in the same industry..

>>These are not real infosec firms, they are parasites.

>The entire consulting penetration testing market is setup to encourage this behavior. There is no way to prove you actually did anything correct. Someone can write a wonderful PDF analysis by hand and still leave the system full of glaring holes. Customers can't tell a system is broken until it gets hacked.

So a good company should be able to provide a methodology detailing the tests they do, you'll also see some who report the tests conducts and the results (positive or negative), so asking for sample reports from consultancies would help to find one closer to your specific needs. Personally I prefer reporting all test results as it keeps both parties straight on what has and has not been covered.

>>More specifically, we ask for it and we receive it, and we do exceedingly well. If people keep paying us five figures a week to perform a penetration test, we're not going to stop asking for it or reduce our prices.

>Right, but many times I've seen companies do it because they are desperate to do it for compliance purposes. :/ Essentially there is a non-trivial portion of the market held up by regulatory demand.

Yeah where people are getting tests for purely compliance reasons there is a tendency to go with cheap suppliers as there's not really good perceived benefit.

>>Strictly "policy" audits such as PCI compliance differ a bit, but in general they should still involve a technical deep dive into your product's infrastructure, conducted by consultants with expertise in multiple tech stacks and overall experience in a variety of frontend and backend frameworks.

>I'm curious. Do you review every line of code in a customer's codebase? What about the code of every library they import? If you don't review imports, do you leave a big caveat in your report that says their code looks okay, but the libraries could be full of vulnerabilities?

Heh this is one of the huge gaping holes in security at the moment. Most applications are now constructed of piles of code acquired from repos (npm, nuget, rubygems etc) that provide absolutely no curation of content and anyone can put any code they like up there. There is (from what I've seen) very little appetite from companies to actually try and audit their whole stack, generally due to the cost of doing that. Manual code review is expensive and when you start importing 100Kloc of 3rd party code into your solution it would not be a cheap excercise to validate...

I'd be interested to hear if you have an example of a company that did read the source code of apps. used?

Also which law do you think they would be breaking by not reading the source code of products used?

Given that in the mobile field, Android is perceived as the leader, this line of thinking doesn't really seem to hold.

Not sure about CPU but you can get Windows 8.1 devices with 1GB of RAM which run fine (and that's full desktop 8.1, not a cut down IoT build that this is likely to be)

For me it's the lower limit of what's possible and it's slow if you load up many apps, but definitely possible.

Well I did say at the top of this thread that the proposal had glaring problems :) I was interested to hear if other people had alternate suggestions which would address the issue.

I'm not sure where I said hope was a strategy, I said insiders might have information that's of value to attackers (unless I got my threads mixed here)

Indeed, however in the same way as it's not up to you to "address" the "problem" nor is it up to me :)

Doing nothing would seem like a losing response given the current swing of events but I'll defer to your greater experience.

well I'm not a legislator, and if you're looking to pick holes, trust me you would be able to :)

The question is, is that the best approach and if not, what is? Once an approach is agreed then the inevitable x years of wrangling on details could occur.

BTW I'd respond to the other threads but HN seems to object to deep threads.

On "flaws fixed rather than concealed" sure in a perfect world they do, but limited resources == prioritization and some systems and packages inevitably get left behind, insiders know which those are..

In this case what are the firms who pay these rates doing with the information?

Defensive work (e.g. IPS vendors) well after they've got their early day protection they can just sell on to the vendor.

Offensive (e.g. "cyberweapons" ugh I had that term). well that's the point I'm making that whole industry is bad for defensive security as it involves keeping vulns secret as long as possible, so they can be used by them.

Gov's have to make a choice whether that's an industry they want to encourage, be neutral to, or discourage.

But given this line of thinking is one you'd disagree with, what option for addressing the problem do you prefer?

that's not what I was intending to describe. I was suggesting that insiders have inside information and sometimes that is relevant to attacking companies, such that hiring those insiders could be useful to them.

and definitely not hoping that reverse engineers won't notice, I've been in security long enough to see all my pronouncements of "you know someone could do x" and more come true...

The answer is obviously complex and difficult, but I think it's fair to say the current approach isn't working well..

So you need something new to address the problem. I think that the answer is government legislation.

To be clear, I think that it's a terrible answer, in fact everything I'm about to write has glaring problems, I just can't come up with a better alternative.

So software suppliers have to be held responsible for the security of the products they supply, it would obviously be a long and arduous process, and would likely have serious repercussions on the industry as it stands today.

Flip-side is that you try to regulate the market for vulns to reduce their use in malware etc. you could do this by requiring companies to buy discovered vulns and require researchers to sell to the developers.

One of the many major issues with this approach is, what do you do about open source software. There's no money, so liability has no meaning. Here, if it's constituted into a commercial product (think all the lovely "appliances" out there) the liability passes to the guy making the money. Where an end-user company directly uses open source, they get the liability to go with it.

Along-side this you start slowly ramping up the security compliance requirements for companies and organisations processing transactions or personal data on the Internet.

I'd compare this to security becoming like "health & safety" . I don't think most companies really want to spend money on it, and I think a huge amount of money is wasted in unneeded process, but compared to the alternative, it has been seen to be the best approach.

As another slightly less draconian approach than actually trying to ban vulnerability research, what about mandating a market where researchers have to sell to the developers and developers are obliged to buy from the researcher, with a middle-party setting the prices.

That might serve to provide incentives to the vendors who aren't already working actively on their security to do so, and also reduce (although obv. it wouldn't eliminate) the number of vulns going straight to offensive products.

Realistically in my experiences every large company has "skeletons", which are primarily known to insiders and of which outsiders have less knowledge.

Be that a product which is known not to have as rigorous a security regime as others, or perhaps a service which is considered "legacy" and not developed actively.

When offensive companies start hiring people to get access to that information to use against their prior employers, I think that's not great for overall security.

I didn't think I was implying that keeping flaws secret in the long term was desirable, I don't think it is.

Also whilst I agree it's naive to suggest that only insiders know most flaws, I feel that it's also reasonable to suggest that insiders have information which would be useful to attackers, and that could be tapped by hiring them.

As I said originally that was just one example of where I think potential problems could arise from "vulnerabilities as a product", but I'd be interested to hear what you think are the downsides to vulnerability markets.

interesting idea, to an extent this already exists with bug bounty programmes that a number of companies have in place.

The risk is where either the company doesn't have a programme of that kind, or where the value of the bug is substantially higher to the offensive industry, than the product company...

FWIW, I think that the idea of software bugs (vulnerabilities) as a product is a scary concept and a bad precedent for overall security.

Once you have legitimate corporations who's goal is to find software vulnerabilities, combine them with delivery systems and sell to either specific entities (e.g. the US government) or the highest bidder, I think that the incentives for people involved in software development and testing get odd, and not in a good way.

For example, will we see these companies hiring ex-developers and testers from software product companies, as they might have inside knowledge of where products are weak.

Another example is, are there incentives now for people who work in development or testing, who aren't perhaps happy in their jobs, to sell knowledge of bugs or flaws to these companies? Given the prices paid, which could be several multiples of peoples annual salary, and the anonymity afforded to people who report the flaws, it could be a low risk way to make a lot of money.

And then you have open source software which is heavily used in a lot of commercial products that might get attacked. With this kind of thing there's a big incentive not to report bugs to the project but to sell them to a company who has no incentive to see them fixed...

I don't see it as an either/or decision TBH. I wouldn't suggest that WAFs are a panacea, but that doesn't mean that they can't be a useful defensive layer.

A lot of companies have difficulties getting app. patches applied quickly due to test cycles, so applying a WAF rule to block known issues (this one for example) can be a fast, low risk way of reducing the risk.

This is a really good example of why, if you have something important to your organisation on the Internet, you need to really be doing defence in depth, to either reduce the risk of compromise, and/or increase your chance of noticing when you're attacked and reacting accordingly.

So things like IDS (network and host), perhaps looking at adding a WAF to catch basic attacks, shipping all your logs off your front end servers so they can't be easily destroyed by attackers etc.

This kind of disclosure--> attack timeline now looks to be the norm, so this will become a theme and companies are either going to have to spend more on defense, or spend more on incident clean-up and then spend more on defense....

Best advice I could provide if the devs aren't too knowledgeable on application security, is use a framework where possible, know where it's likely to fail you and focus there and then make sure you stay on top of patching all your framework components to catch vulns in that layer

So for example rails handles basic things like SQL injection, XSS in standard forms fine, then you can use devise or similar for authentication and get a reasonable level of security. What you're left with are areas like authorisation which tends to be app. specific so still requires work, but you probably have less to focus on.

Also watch out for what I'd call "dangerous" functionality, things like file uploads or user generated content where you want users to enter HTML tags but still avoid XSS. Things like that need specific consideration to avoid common security issues.

Of course if you're doing something that will attract real bad guys (anything to do with payments, anything to do with bitcoin, anything to do with Intellectual property management etc) then I'd strongly recommend getting an app security person on staff as soon as you can 'cause you will get attacked probably sooner rather than later...

Cool stuff, always interesting to see a new entrant to the location services field, especially an open one.

One question though. Will ordinary users be able to directly query the database via the API? i.e. if you want to geolocate a set of Access points and you have their MAC addresses will this service provide a direct supported API for retrieving their location?

The documentation on the API page implies that this isn't really a supported application?

Specifically

"If you are developing a native application or library for a desktop operating system or Android, you can in principle use this service via its HTTPS API. Please refer to the development documentation for the details. On most other operating systems, you cannot access the required cell and WiFi network information required to call the service API. "

and

"At this stage the service is open to anyone, who wants to contribute back to the service and applications supporting the Mozilla mission. "

seem a bit vague.

you might want to review some of the literature around bypassing fingerprint readers before making that kind of statement... A large number of readers are easily fooled by copied prints. Also there's the False acceptance/false rejection rate tradeoff to consider.

Once of the major issues with biometrics is revocation. If compromised it can be difficult to change!