2 deleted 74 characters in body
source | link

I've been trying to build bulletproof systems for almost ten years now. I had to learn about high assurance design techniques (e.g. EAL7), covert channels, subversion attacks, etc. Honestly, most system designers or administrators have neither the knowledge nor resources to totally secure a machine from known attacks. It's nearly impossible given business constraints. Most security decisions reflect tradeoffs between cost, features, usability, legacy compatibility, likely attacker profiles, etc.

If you want to know, here's one of my simplified breakdowns on the various levels and issues of security. (And it isn't the size of a book 8). It was addressed to a guy who thought top notch coders could make secure programs, but you can sub admin for coder and still same results. Have fun and learn the lessons less you repeat history like much of INFOSEC community does. ;)

http://www.schneier.com/blog/archives/2013/01/essay_on_fbi-ma.html#c1102869

This follow up comment has plenty of links that trace history, government factors, development requirements, etc. I also list a ton of exemplar systems and processes. Each might have flaws lurking but inspire more confidence than average product.

http://www.schneier.com/blog/archives/2013/01/essay_on_fbi-ma.html#c1105156

Nick P
Security Engineer
schneier.com frequent contributor

I've been trying to build bulletproof systems for almost ten years now. I had to learn about high assurance design techniques (e.g. EAL7), covert channels, subversion attacks, etc. Honestly, most system designers or administrators have neither the knowledge nor resources to totally secure a machine from known attacks. It's nearly impossible given business constraints. Most security decisions reflect tradeoffs between cost, features, usability, legacy compatibility, likely attacker profiles, etc.

If you want to know, here's one of my simplified breakdowns on the various levels and issues of security. (And it isn't the size of a book 8). It was addressed to a guy who thought top notch coders could make secure programs, but you can sub admin for coder and still same results. Have fun and learn the lessons less you repeat history like much of INFOSEC community does. ;)

http://www.schneier.com/blog/archives/2013/01/essay_on_fbi-ma.html#c1102869

This follow up comment has plenty of links that trace history, government factors, development requirements, etc. I also list a ton of exemplar systems and processes. Each might have flaws lurking but inspire more confidence than average product.

http://www.schneier.com/blog/archives/2013/01/essay_on_fbi-ma.html#c1105156

Nick P
Security Engineer
schneier.com frequent contributor

I've been trying to build bulletproof systems for almost ten years now. I had to learn about high assurance design techniques (e.g. EAL7), covert channels, subversion attacks, etc. Honestly, most system designers or administrators have neither the knowledge nor resources to totally secure a machine from known attacks. It's nearly impossible given business constraints. Most security decisions reflect tradeoffs between cost, features, usability, legacy compatibility, likely attacker profiles, etc.

If you want to know, here's one of my simplified breakdowns on the various levels and issues of security. (And it isn't the size of a book 8). It was addressed to a guy who thought top notch coders could make secure programs, but you can sub admin for coder and still same results. Have fun and learn the lessons less you repeat history like much of INFOSEC community does. ;)

http://www.schneier.com/blog/archives/2013/01/essay_on_fbi-ma.html#c1102869

This follow up comment has plenty of links that trace history, government factors, development requirements, etc. I also list a ton of exemplar systems and processes. Each might have flaws lurking but inspire more confidence than average product.

http://www.schneier.com/blog/archives/2013/01/essay_on_fbi-ma.html#c1105156

1
source | link

I've been trying to build bulletproof systems for almost ten years now. I had to learn about high assurance design techniques (e.g. EAL7), covert channels, subversion attacks, etc. Honestly, most system designers or administrators have neither the knowledge nor resources to totally secure a machine from known attacks. It's nearly impossible given business constraints. Most security decisions reflect tradeoffs between cost, features, usability, legacy compatibility, likely attacker profiles, etc.

If you want to know, here's one of my simplified breakdowns on the various levels and issues of security. (And it isn't the size of a book 8). It was addressed to a guy who thought top notch coders could make secure programs, but you can sub admin for coder and still same results. Have fun and learn the lessons less you repeat history like much of INFOSEC community does. ;)

http://www.schneier.com/blog/archives/2013/01/essay_on_fbi-ma.html#c1102869

This follow up comment has plenty of links that trace history, government factors, development requirements, etc. I also list a ton of exemplar systems and processes. Each might have flaws lurking but inspire more confidence than average product.

http://www.schneier.com/blog/archives/2013/01/essay_on_fbi-ma.html#c1105156

Nick P
Security Engineer
schneier.com frequent contributor