The title is very generic though, not indicating what type of systems. Like if I am working in embedded systems, should I read the book? I skimmed through a few pages, still no idea..
(disclaimer: I worked on the book)
171–180 of 227 posts
The title is very generic though, not indicating what type of systems. Like if I am working in embedded systems, should I read the book? I skimmed through a few pages, still no idea..
(disclaimer: I worked on the book)
> In our experience, when you use a hardened data library such as TrustedSqlString (see “SQL Injection Vulnerabilities: TrustedSqlString” on page 252) That is not my experience. Yes, the most simple SQL injection a newbie attacker would try, is running a query directly on your database using stuff like" ' OR '1' =='1' " However, one can do a lot of other things like getting the schema, table names and the actual data…
One clever trick is to return fake data if you detect a smart ass is trying to access data he shouldn't, rather then tell him he is forbidden. Let him enjoy his fake data. :) That sounds like a lot of effort for something that should never happen if your real security systems are working, and a huge problem if something breaks and returns fake data to real users. It would look like their accounts have been compromise…
Earlier quoted context omitted.
One clever trick is to return fake data if you detect a smart ass is trying to access data he shouldn't, rather then tell him he is forbidden. Let him enjoy his fake data. :) That sounds like a lot of effort for something that should never happen if your real security systems are working, and a huge problem if something breaks and returns fake data to real users. It would look like their accounts have been compromise…
It's also a big problem if the hack gained any publicity. Who's actually going to believe "no no, it was actually fake data that got stolen"?
Piotr and Anthony: any relations?
Le*v*andowski != Le*w*andowski
Seriously though, there is no relation that I am aware of. It's a very common surname in Poland (source: https://en.wikipedia.org/wiki/Lewandowski).(I'm Piotr Lewandowski.)
Can any mod here restore the comments?
Earlier quoted context omitted.
I will answer in mostly reverse order. I was trying to avoid being over-pedantic. By safely, I mean mitigating the risk to an appropriate level. So, to reword the statement. I mean, "If the risk can not be mitigated to an acceptable level, then we should not do that thing." The appropriate level of risk depends on the action in question. If it involves human lives, then society should evaluate the acceptable amount o…
> Personally, I believe software that reduces the risk appropriately can be made, so I believe we can make software to manage these systems which is contrary to what you think I believe. I think you're just grossly overestimating the "risk" for most software. > I glossed over the point that the bug bounty should generally be order of magnitude the cost of discovery The bug bounty is the order of magnitude of the cost…
That does not mean that a "better" inadequate solution is not a path to adequate, it could very well be if the "better-ness" can scale all the way, but that is hard to judge. One strategy for doing so is trying to estimate how far you are from good, that is the point of quantitative analysis. Using the tree to the moon example, if you could estimate the distance to moon, you would quickly realize that every tree you know of is pretty far from the moon, so maybe a different strategy is warranted. In this case, I want to estimate the "security" of an adequate solution. Is $1 enough, $1K, $1M, $1B? For what problem domain? How far are "best practices" from that goal? That is how I would decide if best security practices are worth listening to. The other point of quantification is to compare systems, you claim Google has better security practices, how much better? 10%, 50%, 100%, 1000%? That would change how compelling listening to their practices over others would be.
As you stated above, bug bounties are order of magnitude cost of discovery which, in my opinion, is a reasonably good quantitative security proxy. The Pixel 4 kernel code execution bounty is up to $250K. The iOS kernel code execution bounty is up to $1M. That appears to indicate that Google's offering is less secure by this metric. Even ignoring that, is $1M enough protection for a phone model line (since a bug in one is a bug in all, so a zero-click kernel code execution could potentially take over all phones, though in practice it will probably not even assuming such a vulnerability were used to achieve mass infection)? There were more than 200 million iPhones sold last year, so that is only a per-phone value of 0.5 cents, is that an adequate amount of security? Personally, I think no and I would bet the average iPhone buyer would be less than pleased if they were told that (still might not change their buying habit though). What do I think is adequate? Not sure. $50 is probably fine, $5 seems a little low, $500 is probably high since that is approaching the cost of the phone itself. If I use $50 as the metric of adequate, they are 10,000x off from the measure of adequate which seems pretty far to me. Think about the difference in practices between $100 and $1M and that needs to happen again, how do you even conceptualize that? Even at $0.50 they are still off by a factor of 100x, 1% of adequate from this perspective.
On the point of overestimating the "risk" for most software, I half agree. I believe the truth is that almost nobody cares about security, so the cost of problem for insecurity is almost nil. Companies get hacked and they just keep on going their merry way, sometimes even having their stock prices go up. However, I believe this is also an artifact of misrepresenting the security of their systems. If people were told that the per-unit security of an iPhone is 0.5 cents, they might think a little differently, but instead they are told that the new iPhones are super, duper secure and all those pesky vulnerabilities were fixed, so it is now totally secure again, this time we promise, just ignore the last 27 times it was not true.
On the other hand, large scale systemic risks are massively underestimated. Modern car models are internet connected with each model using a single software version maintained through OTA. This means that all cars in a single model run the same software meaning that bugs are shared on all the cars. If a major vulnerability were discovered, it could potentially allow take over of the steering, throttle, and brakes by taking over the lane-assist, cruise control, and ABS systems. If this is done to all cars of a given model at the same time, it is extremely likely that at least thousands would die. Even ignoring the moral implications of this, that would be a company-ending catastrophe which puts the direct economic cost of problem at value of the company which is a few billion to tens of billions for most car companies. Again, $1M is pretty far from this level, and there is no evidence that such techniques scale 1000x. Any solution that only reaches the $1M level, even if it is "best practices", is not only inadequate for this job, it is criminally negligent in my opinion and I believe most people would agree if it were properly explained to them.
Hey everyone - Seth from Google here. Thank you for all the positive comments about the book. I'll be around to answer any questions you might have. As noted, the book can be downloaded for free in digital formats. PDF: https://landing.google.com/sre/static/pdf/SRS.pdf EPUB: https://landing.google.com/sre/static/pdf/srs-epub.epub MOBI: https://landing.google.com/sre/static/pdf/srs-mobi.mobi
Are these books suitable for a software engineer who is new to security, or is it an advanced text with pre-reqs?
(disclaimer: I worked on the book)
In a somewhat cynic remark (and having nothing against the authors), I cannot think of a better timing to assuage someone about Google's competency after the numerous outgages in GCP these weeks. The "Compliments of Google Cloud" sticker on the cover makes sure to reinforce the association.
(disclaimer: I worked on the book)
Earlier quoted context omitted.
It's also a big problem if the hack gained any publicity. Who's actually going to believe "no no, it was actually fake data that got stolen"?
It's not about making the attacker think the data is valid. It's about not letting him know whether the data is valid or not.
If that's the strategy you want to use that's up to you, but I think it's immensely risky and provides no practical benefit.