Full disclosure: I requested the book from the publisher 2 years ago, and I have met and like the author. I have no competing (financial or other) interests.Since the 2nd ed. launched in Nov 2018 (mod the publisher blurb and 2-3 lines reviews on Amazon) no one has written a more i- depth review, in part because it’s not for beginners (neither students, nor teachers).You need a pedagogically experienced subject matter expert with memory spanning decades to make the material come alive and relevant to today’s environment. This requires grasping complex theory and conveying why said theory is relevant today, then mapping it to practical modern real-life issues and systems such as blockchain, ledgers, CD/CI, SaaS, FaaS, CDN infrastructure (google APNIC Huston “Death of Transit"). The putative pedagogue must be willing and able to explain the link between HRU and undecidability viz the so-called ‘safety problem’ (see screenshots; this security version of the halting problem - can you reach an insecure state? ) which directly impacts language design (google “JPL C coding” to get a feeling for the C of NASA’s flight software expressly reduced to allow for safety guarantees) which in turn affects the security yield of static source code analysis techniques on such code bases. There are many more such links to be expounded upon.Another deep passage is given in Sec. 4.8 trust assumption (see screenshot) :"Trust underlies all policies and enforcement mechanisms. [..] Understanding the assumptions and the trust involved in any policies and mechanisms deepens one’s understanding of the security of a system."Spectre and Rowhammer vectors are likely the most prominent recent examples of deepening our understanding of the security of a hardware system (see screenshot and google "Mcilroy Verwaest 2019 Spectre is here to stay").Why weren’t these vulnerabilities identified and remedied decades ago? The answer is that horribile dictu vulnerabilities are created by dynamics in adversarial environments, rather than inherent feature of systems, as heretical as this may sound. Spectre thus illustrates what happens when specific assumptions are violated; in this case the assumption of a hardware threat model scoped to random errors (ie Nature is cruel - stray neutrinos perhaps - but not malicious) had to make way to a hardware threat model including non-random, intelligent adaptive adversaries.Adversarial dynamics can create brand new attack surfaces, emphasizing the need to understand "the assumptions and the trust involved in any policies and mechanisms", as Bishop stated in Sec. 4.8. Google "CTF solution ret2 systems "Hotel California" Intel TSX jail challenge" to see another example of a novel CPU bug discovery as unintended consequence of a CTF challenge.Part III discusses Policy at length, among them classic seemingly old-fashioned models such as the Bell-LaPadula model for Confidentiality and the Biba low watermark Integrity model. Grokking these models and their characteristics is crucial to understanding why eg the AWS S3 access control model is broken (google "An API Worm In The Making: Thousands Of Secrets Found In Open S3 Buckets") and one needs professional assistance to set the S3 access control permission properly (google "Zelkova: AWS automated SMT reasoning on resource policies").Parts of the book seem not to have been updated in twenty years (eg many ftp, rsh illustrations). In my opinion, this is a valid but quite minor critique since those examples remain valid for the one-off concepts Bishop needs to illustrate. Some of the most interesting tidbits are buried in the research issues (eg Sec. 9.8).Summa summarum: This hefty work (1440+ pages, 2250+ references) can be made to shine, but it will not be easy. The publisher's stated target audience - junior / senior undergraduates – is in my professional opinion wildly and impossibly optimistic. Even at first rate institutions it will be a very hard sell on account of the sometimes-excruciating plain dryness of the material. It took me as a motivated PhD SME 4 weeks of 6 hours of work per day, 4 days a week working through and warming to the 1st edition 17 years ago.I endeavored to make a short case for Bishop's immense value. Any failing in this regard is mine alone and not the author’s. If push came to shove as a computer security pedagogue and professional, you would need three books; this one by Bishop, Anderson's "Security Engineering" and Ericksson's "Hacking: The Art of Exploitation". The rest is, as they say, commentary.Daniel Bilar, Norwich University, Northfield VT.