Security Engineering is free on the author's website :) http://www.cl.cam.ac.uk/~rja14/book.html

Oh yes. Grad school is all reading. I recall reading these books in their entirety.

Security Engineering. Ross Anderson

The Formal Semantics of Programming Languages. Glynn Wynskell.

Communicating Sequential Processes. Tony Hoare. This book is surprising in its compactness and lucidity.

Pi Calculus. Robin Milner.

Semantics With Applications. Hanne Riis Nielson

On Concurrent Programming. Fred Schneider.

Specifying Systems with TLA+. Leslie Lamport.

Distributed Algorithms. Nancy Lynch.

Reliable Distributed Computing. Ken Birman and Robert Van Renesse.

I'm sure I'll recall more as soon as I hit "reply".

Reading that letter makes me proud of the Security Group at Cambridge University. Ross Anderson took us for a couple of Security courses in second/third year Computer Science and was interesting, direct and completely no-nonsense. He emphasised that policy and ignorance were often the main causes of failures, especially with LAS, NHS centralisation (UK government projects). I find strong individuals like Anderson inspiring when they take on organisations who attack knowledge rather than being hands-on and fixing their systems.

The Security II course is especially relevant. I am not sure that everyone can access these resources but the lecture notes cover a variety of modern hardware approaches to security (including chip-and-pin). Try:
http://www.cl.cam.ac.uk/teaching/1011/SecurityII/

I highly recommend Anderson's Security Engineering, the first edition is available online:
http://www.cl.cam.ac.uk/~rja14/book.html

That, and the overall physical security standards require the communication lines to be buried in concrete.

Ross Anderson's Security Engineering has a fun chapter on this topic.

Hmm. My picks would be very different, aside from 'The Pragmatic Programmer', which is worth reading early in your career.

Leo Brodie, 'Thinking Forth'

Roland, 'Program Construction'

Ullman, 'Elements of ML Programming'

De Marco, 'The Deadline'

Brooks, 'The Mythical Man-Month'

Skiena, 'The Algorithm Design Manual'

Hunt, 'The Pragmatic Programmer'

Stevens, 'Advanced Programming in the Unix Environment'

Stevens, 'TCP/IP Illustrated, Vol. 1'

Ross Anderson, 'Security Engineering'

Also, the Phoenix Project is a ripoff of Goldratt's 'The Goal.' I suggest reading Goldratt instead, and then think very carefully about what transfers from manufacturing to software.

I have immense respect for the author, and I know these are just notes, but the tone of technologists who talk about Snowden is very annoying.

We know certain technologies like Tor and OTR are safe because of the weight of scientific research that support them, and the immense effort of the developers. Not because someone said so at an event. Statements like "gpg ciphertexts with RSA 1024 were returned as fails" are totally meaningless.

I wish people had more confidence in good old science (like Anderson's works) than glamorous events like this. You should all check out Security Engineering by the same author, it's free! www.cl.cam.ac.uk/~rja14/book.html

A couple I've learned from (I've left out heavily topic-specific books like Cryptography Engineering since I assume you're asking for books about general information security):

Hacking, 2nd Edition - Introduces the foundations of memory and network exploitation

[Security Engineering](https://www.cl.cam.ac.uk/~rja14/book.html) - An overview of a huge array of info sec topics, from "E-policy" to nuclear command security.

Advanced Penetration Testing - Focuses on simulating APT attacks, using the author's penetration testing experiences to illustrate each point.

Trezor's security features list [0] mentions firmware verification, JTAG, and welding - strongly implying that intends on at least some resistance to physical attack. This is not uncommon for hardware cryptography modules. Since 2001, the federal government has had a certification program, FIPS 140-2 [1], recognizing four different levels of physical attack resistance.

The security engineering industry is very interested in the capability to physically ship secrets to potentially hostile actors inside devices that limit their use or duplication. There are many many applications:

- Payment cards: EMV credit/debit, transit, laundry, parking, prepaid electric meters, etc.

- DRM: Widevine for Netflix, DCP for your local movie theater, anti-piracy and anti-cheat in your Xbox.

- Privacy: the iPhone's Secure Element only decrypts user data given the right PIN, rate limits or caps attempts, resists extraction of private key, much to FBI's disappointment.

- Root of trust: enterprise HSMs for PKI will only enable signing operations with their internal private keys after the presentation of a quorum of operator credentials [2].

Ross Anderson's Security Engineering has a great chapter on this [3].

[0] https://trezor.io/security/
[1] https://en.wikipedia.org/wiki/FIPS_140-2
[2] https://www.cloudflare.com/dns/dnssec/root-signing-ceremony/
[3] https://www.cl.cam.ac.uk/~rja14/Papers/SEv3-ch18-dec18.pdf

Around 2003 I was a chief technical architect at a startup. We had to secure access to the products and I realised I had no clue. I read Security Engineering by Ross Anderson and was hooked. Went on to do a Masters in Information Security while still coding, and gradually moved into the security field.

I still spend a lot of time with developers, currently doing a lot on integrating security with continuous deployment and agile projects.

I was talking with a developer recently, who said he loves coding, so that's why he does it for a living. I replied that I also love coding, and that's why I don't do it for a living!

Security Engineering 2nd edition by Ross Anderson. https://www.cl.cam.ac.uk/~rja14/book.html

Ross Anderson: Security Engineering - A Guide to Building
Dependable Distributed Systems

Matt Bishop: Computer Security: Art and Science

The very depressing opposite conclusion was discovered in the late 70's:

DE Denning, PJ Denning, M Schwartz, ‘‘The tracker: a threat to statistical database security’’, in ACM Transactions on Database Systems v 4 no 1 (1979) pp 76–96

A general tracker can always be found, unless the data released is extremely restricted. Almost anything is personally identifiable as it can be used to build a tracker into the database.

I am aware of this result from chapter 9 of Security Engineering (http://www.cl.cam.ac.uk/~rja14/book.html) by Ross Anderson, if you are more generally interested.

Chapter 26 of Ross Anderson's Security Engineering covers the probability distribution involved in finding bugs, and its impact on software vulnerabilities:

http://www.cl.cam.ac.uk/~rja14/book.html

I really need to get up to speed on cryptography. I've been a software developer for a while but haven't had a chance to get into it. Part of the reason is time, the other reason is that I haven't a clue where to start. I've heard about the books Security Engineering and Cryptography Engineering. Are they good books for someone new to all this?

OP here. Some stuff that has been suggested to me in PM (various other communication channels):

- Mastodon documentation [1]

- Nextcloud whitepapers and case studies [2]

- Book on security of distributed systems:
Security Engineering: A Guide to Building Dependable Distributed Systems [3]

----------

[1] https://docs.joinmastodon.org

[2] https://nextcloud.com/whitepapers/

[3] https://www.amazon.com/Security-Engineering-Building-Dependa...

Sadly that is not the case. Major problems with chip and pin:

- the chips used (32kb 90s-style smartcards AIUI) are simple to read and save, making chip and pin readers susceptible to the same social engineering attacks as magnetic stripe cards (btw, in the UK there have been skimmers for chip and pin for some time)

- most terminals on the market transmit the pin in the clear from one part of the unit to the other, so it is trivial to doctor a legitimate chip and pin unit

- it is difficult for the consumer to verify the trustworthiness of an unfamiliar chip and pin unit

- in the UK, people often still try to walk away with my card, just as when we had magnetic stripe

- transactions can be conducted offline in most configurations (true for example in the UK, but not in Germany)

IMO the main selling point of Chip and PIN to UK retail banks is that they allow banks to reassign liability to for fraud to the customer. When your signature is forged, existing law clearly says you are not liable. When you PIN is discovered and used to send transactions, existing law is unclear and currently this allows banks to convince the customer to accept the liability. IIRC, American consumer fraud law is pretty strict, which is why the US has been slower to adopt the machines than eg the UK.

In the UK, Chip and PIN seemed to cut fraud for a while, until attacks like skimming were applied. Now fraud is back on the rise :(

There is good coverage of this in chapter 10 of Security Engineering 2nd edition by Ross Anderson, a book I highly recommend!

Security Engineering: A Guide to Building Dependable Distributed Systems by Ross Anderson is available online for reading -- http://www.cl.cam.ac.uk/~rja14/book.html

A couple of other resources:

- 7 Security Measures to Protect Your Servers [0]

- SSH best practices [1]

In case one doesn't prefer to be overwhelmed with documentation, one could refer to: My First 5 Minutes On A Server; Or, Essential Security for Linux Servers [2].

[0] https://www.digitalocean.com/community/tutorials/7-security-...

[1] http://www.cl.cam.ac.uk/~rja14/book.html

[2] https://plusbryan.com/my-first-5-minutes-on-a-server-or-esse...

Security mindset: read the book Security Engineering (it is online), less for specific technical info than for the many war stories etc. which will help you guard against vulnerabilities and unforeseen consequences.

Basics of cryptography: there are many dumb errors to avoid.

Antirez's general advice about "10x programmers" is good: http://antirez.com/news/112

Thorough (not just basic) knowledge of SQL, if you don't count that as a language. The sqlite.org "technical and design documents" about sqlite's virtual machine and its query planner are well worth reading, and apply to other databases as well. ORM's are less important than SQL, and are usually language specific as someone mentioned.

Reasonable clue about socket programming, even if you're doing everything with libraries that wrap the details.

Comfort using debugging and profiling tools.

Lots of other stuff, I'm sure.

I think the lesson came in earlier in the NUMA and MPP machines where they kept trying to cram more stuff on boards that were themselves pluggable into the larger system. This convergence has happened from several directions. It's not all the different from the earlier one that started in the 1960's where they fought cost and inefficiency by getting as few components per box sharing as much as possible. Moores Law temporarily reversed it (transistors and memory are free!) then reality check hits that this seems to be a fundamental principle.

My design a while back was to put it all on PCI cards on a PCI backplane. I saw backplanes that basically look like motherboards full of PCI slots that load into racks. I wanted to make the cards nothing but CPU and memory whose software communicated over efficient networking (not TCP/IP) through PCI DMA. My design had IO/MMU functionality in the backplane or PCI cards. At least one card having full-featured stack for management and at least one I/O card for external interface. I figured the backplane itself could be extended for that, too, with a dedicated port like motherboards do integrated GigE. Management and I/O could come through remote DMA over dedicated wires like many servers do with Ethernet so all the PCI slots could be dedicated to compute.

Dumbest thing about Facebook's model is them destroying drives. The first thing to notice, due to Ross Anderson's Security Engineering, is that those pieces still contain a lot of data if they weren't degaussed first. Next is to remember the fastest way to destroy data: use clustered, encrypting filesystems so that secrets never touch the drive. Then, you just have to delete the keys to loose the secrets. No need to trash the drives at all. The crypto can happen at the storage manager or at hardware interface with HW acceleration available for both types. I'm surprised they haven't already built this with all the smart people they have working on big-data stacks.