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
New Google SRE book: Building Secure and Reliable Systems
211–220 of 227 posts
Re: New Google SRE book: Building Secure and Reliable Systems
#212Earlier quoted context omitted.
There is certainly a huge YAGNI danger here. 10 people shops should read this, but keep their socks on. I love the part in that other SRE book where they say to “keep it simple” right after describing probably the most involved, meticulous and vast set of software engineering practices of the last 10 years. “Simple” if you have 10B+ in the bank and 1000+ engineers to run the show.
This is why we need strong open source or liberally licensed components to build with. Small companies need to work together to keep up with the complexity of modern systems
Re: New Google SRE book: Building Secure and Reliable Systems
#213Earlier quoted context omitted.
OEMs of Windows Phone for example. My Windows 10 devices still get more security updates than a couple of Asus Android ones I have here lying around about the same age. You are the one moving the goal posts to consumer OSes, in a failed attempt to protect Google's security story. Well, if you want to go that way, then iOS has definitely a better security story than Android ever will. Every iOS powered device has the…
Then, to use your own example, why do brokers pay more for Android zero days?
Any zero days found in Android devices will never be fixed, other than on Pixel and a couple of selected flagship handsets, while everyone else will be naked with their devices.
Thus brokers will have a gold mine on their hands, being able to target thousands of devices without their owners being able to protect themselves, just like Windows XP before SP2 was released.
Re: New Google SRE book: Building Secure and Reliable Systems
#214Earlier quoted context omitted.
Then, to use your own example, why do brokers pay more for Android zero days?
Because it has 80% of the market share world wide, so any flaw makes it more worthwhile, specially given the lack of updates. Any zero days found in Android devices will never be fixed, other than on Pixel and a couple of selected flagship handsets, while everyone else will be naked with their devices. Thus brokers will have a gold mine on their hands, being able to target thousands of devices without their owners be…
I can't tell if you have a point you're making, or if you're just trying to disagree with me :/
Re: New Google SRE book: Building Secure and Reliable Systems
#215Earlier quoted context omitted.
No, my bar for proselytizing about security practices is adequate, not perfect. The distinction is that adequate is an absolute bar, not a relative one, so "better" and "worse" are irrelevant until it is achieved since a "better" solution that is inadequate is not a solution that can be used (it is inadequate) and does not provide clear directions to an adequate solution. It is like climbing trees to reach the moon,…
Your focus on bug bounties ignores the existence of other things, like grey hat big vendors and I house security teams. Tavis Ormandy doesn't get big bounty payouts from Google or Apple or Microsoft, he gets a big paycheck instead, but is more effective than pretty much any freelance big bounty hunter. And again, you consistently overestimate the value of a hack. You're not going to get root on every device. So the i…
I stated in a parenthetical that I did not believe they would actually root every device in practice. I used numbers, you can change the numbers to whatever you believe. If someone wanted to mass infect devices using a zero-click kernel code execution, how many do you think they would be able to infect? Let us call that X. $1M is order of magnitude the cost of discovery (since bug bounty ~= cost of discovery) for such a compromise on iOS. Divide $1M / X, that is the per-unit value. Does that number seem good? I said $50 is probably adequate. Therefore, for that to be adequate given this model, you would need to expect a zero-click kernel code execution deployed to mass infect would to infect 20,000 or fewer phones. Do you believe this is the case? If so, then your logic is sound and in your mind iOS security is adequate. It is not for me, since I do believe it would only infect 20,000. As a secondary point, that is only the cost of the compromise with no infrastructure. If they spent another $1M developing techniques for effective usage of the compromise such as better ways to deploy, infect, control, hide, other compromises, etc. how many do you think they would be able to infect? Let us call that Y, Y >= X. In that case I would do $2M / Y to determine the adequacy.
As a counter-example, large-scale ransomware attacks which extract minimal value from large numbers of people occur and have been increasing in frequency and extracted value. Why aren't there more given how easy it is? I don't know. Why didn't somebody crash planes into buildings before 9/11 or drive trucks into people before the 2016 Nice truck attack? These attacks were not very hard, possible for decades, and seem to be highly effective tools of terror, but for some reason they were not done. Hell, it is not like anybody can stop someone from driving a truck into people right now, why aren't terrorists doing it every day given we saw how effective it is and how hard it is to prevent? My best guess is that so few people actually want to engage in terrorism or economic hacks that only an very tiny fraction are done at this time.
This leads into the next point which is that state actors are not the only entities that CAN break into phones; financing a $1M cost of discovery is chump change for any moderately sized business. The government is just one of the few entities who want to as a matter of course and face minimal repercussions for doing so. If you are not the government and hack people for financial gain you can go to jail; not a very enticing prospect for most people. This means that the impact of a compromise is not different, it is just less probable at this time. However, that is not a very comforting prospect since it means you are easy prey, just nobody is trying to eat you yet. And this ignores the fact that since any particular target is easy, if someone is targeted in particular they are doomed. Essentially, not being compromised is at the mercy of nobody looking at you funny because if someone wants to compromise you they can. To provide an example of why this is a problem, if I were a terrorist organization, I would be running an electric power generator and transformer hacking team with an emphasis on bypassing the safety governors and permanently destroying them. It does not matter that there are more economic targets to hit, as long as they choose one in particular they can cause incomprehensibly large problems.
As for Google's security, if I use my default security assumption (based on experiences with other security organizations) that a skilled red team with $1M would be able to compromise and establish a persistent presence with material privileges and remain undetected for a week, then I believe their security is inadequate since I believe such an outcome would easily be able to extract $1M, let alone damage if the goal were just destruction. If the goal were pure damage, I believe that such presence, properly used, should be able to cause at least $100M in damage and I would not find it unreasonable if it could cause $10B in damage if the goal was optimized damage to Google in both material and market ways with no thought for the consequences if caught.
To separate this out for you, there are two primary statements here:
1. The damage that a skilled red team can cause assuming it has a persistent presence with material privileges and remains undetected for a week.
2. The cost of creating a persistent presence with material privileges that remains undetected for a week.
I assert (1) is probably ~$100M. I assert (2) is my default of $1M. Any situation where (1) is materially higher than (2) is inadequate in my opinion, so a convincing counter argument on your side would be convincing me of a value for (1) and (2) where (2) is higher than (1). I find it unlikely you would convince me of a lower number for (1). So, you would need to claim that (2) is ~100M for Google. If you believe so, what is your justification? The minimal standard that would cause me to consider further (not convince, just not directly dismiss), which you are under no obligation to provide, would be: You stating that you talked to an internal security person at Google and they firmly claim that (2) is higher than 100M (I will take you at your word). If you do not know what to ask, you can try: "If you were in charge, would you feel comfortable going to DEFCON and Black Hat and putting out a prize for $100M if anybody could do (1)?". The other requirement is you stating (again, I will take you at your word) that you talked to an internal security person at Google and they inform you that this has been tested internally using a red team with resources in the general vicinity of $100M or more. There are potentially other strategies that might pass the minimal bar, but that is one that I could think of that would be pretty solid. Again, I am not demanding you do so, but if you wish to engage on this point then I don't think any other type of response is particularly productive.
Re: New Google SRE book: Building Secure and Reliable Systems
#216Earlier quoted context omitted.
Your focus on bug bounties ignores the existence of other things, like grey hat big vendors and I house security teams. Tavis Ormandy doesn't get big bounty payouts from Google or Apple or Microsoft, he gets a big paycheck instead, but is more effective than pretty much any freelance big bounty hunter. And again, you consistently overestimate the value of a hack. You're not going to get root on every device. So the i…
I am not focusing on bug bounties, I am focusing on cost of discovery which seems like a pretty good metric. Bug bounties just provide a means of learning the cost of discovery that is publicly available and where over-stating is harmful. If you have some other good quantitative measure of security that is publicly available and where over-stating is harmful that would be very helpful. I stated in a parenthetical tha…
If not, why not? Do you believe that 20000 people would never noticed such a thing over a sustained period?
As for 2: there are public examples (again, Aurora) of teams with more funding being caught in less time. So I think you are underestimating the security capabilities of Google (and similar companies). For example, are you familiar with beyond corp?
Re: New Google SRE book: Building Secure and Reliable Systems
#217What does a lizard have to do with SRE?
Re: New Google SRE book: Building Secure and Reliable Systems
#218Earlier quoted context omitted.
> "Would the system prevent compromise by a red team with a $1 Billion... budget" Are there any such systems deployed in the world today?
jp morgan chase has a security budget of $600M/yr https://www.secureworldexpo.com/industry-news/jpmorgan-chase...
Re: New Google SRE book: Building Secure and Reliable Systems
#219Earlier quoted context omitted.
According to the first of the SRE books, engineers working under the SRE banner are expected to devote approximately 50% to operational activities and 50% to engineering intended to make the other 50% easier. Given that the usual ration is 100% : -100%, 50:50 is going to be helpful in escaping capability traps.
It's actually "at most 50% on toil". But of course it's also hard to measure exactly. It's more of a barrier that if we exceed it, the team probably needs serious help! Ultimately, Google engineers can move between teams pretty freely, so if we allow a team to descend into an operational or a deadline-induced death march, and we don't address that quickly, chances are the engineers will move to another team. It's som…
My reference to "capability traps" wasn't accidental, it's a serious risk to any business where maintenance and improvement has low observability vs production outputs[0]. In that situation economists rightly predict that effort is skewed towards what can be observed more easily ("equal compensation principle")[1].
Under those conditions it's easier to fix a time-spent target and observe time allocated, even if only approximately.
[0] https://web.mit.edu/nelsonr/www/Repenning%3DSterman_CMR_su01...
[1] https://en.wikipedia.org/wiki/Principal%E2%80%93agent_proble...
Re: New Google SRE book: Building Secure and Reliable Systems
#220Earlier quoted context omitted.
I am not focusing on bug bounties, I am focusing on cost of discovery which seems like a pretty good metric. Bug bounties just provide a means of learning the cost of discovery that is publicly available and where over-stating is harmful. If you have some other good quantitative measure of security that is publicly available and where over-stating is harmful that would be very helpful. I stated in a parenthetical tha…
If you believe a zero click iOS compromise would infect more than 20k devices, can you give an example of such a thing happening? If not, why not? Do you believe that 20000 people would never noticed such a thing over a sustained period? As for 2: there are public examples (again, Aurora) of teams with more funding being caught in less time. So I think you are underestimating the security capabilities of Google (and…
5 zero-click compromises. Thousands per week for a total of 2 years before discovery. The 5 chains being: 3 months, 6 months, 10 months, 6 months, 3 months each. At thousands per week, that is 12k, 24k, 40k, 24k, 12k new compromises per chain at a minimum, probably closer to 5x those numbers. Incidentally, at the bottom of the initial post they mention: "I shan't get into a discussion of whether these exploits cost $1 million, $2 million, or $20 million. I will instead suggest that all of those price tags seem low for the capability to target and monitor the private activities of entire populations in real time." which is consistent with my perspective. As a secondary point, I do not claim that Google does not have good offensive security techniques.
Looking at Project Aurora. The wikipedia page states that the attacks began mid-2009 and Google discovered them mid-December. So a potential 6 month window before detection. Google also declares that they lost intellectual property, though the nature of that is unclear, so could be anything from one random email to everything. Given that they already lost information, the attack could have already succeeded in its goal by the time of detection (6 months is a really long time to exfiltrate data, you could literally dump terabytes of data if you had a moderate unimpeded internet connection), "We figured out that we were robbed 6 months ago." is a failure in my book. There is also little information as to the difficulty of the attack. They say it was "sophisticated", "we have never seen this before", but that is what literally everybody says. If you have access to a specific breakdown on the techniques used that would be helpful.