Forgot your password?
typodupeerror
Books Security Book Reviews

Book Review: Security Without Obscurity 51

Posted by samzenpus
from the read-all-about-it dept.
benrothke (2577567) writes Having worked at the same consulting firm and also on a project with author J.J. Stapleton (full disclosure); I knew he was a really smart guy. In Security without Obscurity: A Guide to Confidentiality, Authentication and Integrity, Stapleton shows how broad his security knowledge is to the world. When it comes to the world of encryption and cryptography, Stapleton has had his hand in a lot of different cryptographic pies. He has been part of cryptographic accreditation committees for many different standard bodies across the globe. Keep reading for the rest of Ben's review.
Security without Obscurity: A Guide to Confidentiality, Authentication and Integrity
author J.J. Stapleton
pages 355
publisher Auerbach Publications
rating 8/10
reviewer Ben Rothke
ISBN 978-1466592148
summary Great guide to enterprise authentication from an expert
The premise of the author and the need for the book is that the traditional information security CIA triad (confidentiality, integrity, availability) has led to the situation where authentication has to a large part gotten short shrift. This is a significant issue since much of information security is built around the need for strong and effective authentication. Without effective authentication, networks and data are at direct risk for compromise.

The topic itself is not exactly compelling (that is, unless you like to read standards such as ANSI X9.42-2003: Public Key Cryptography for the Financial Services Industry: Agreement of Symmetric Keys Using Discrete Logarithm Cryptography, ISO/IEC 9798-1:2010: Information technology — Security techniques — Entity authentication,etc.), so the book is more of a detailed technical reference. Those looking for a highly technical overview, interoperability guidance, and overall reference will find the book most rewarding.

For those who don't have a general background on the topic; it may be a book too deep and technical for those looking for something more in line of a CISSP preparation guide.

For those that want to know the deep underpinnings of how encryption algorithms work; they can simply read the RFC's and standards themselves. What the book brings to the table are details about how to effectively implement the standards and algorithms in the enterprise; be it in applications, policies; or the specific procedures to meet compliance and standards requirements. And that is where Stapleton's many decades of experience provide significant and inestimable value.

There are many reasons why authentication systems fail and many times it is due to interoperability issues. Stapleton details how to ensure to minimize those faults in order to achieve seamless authentication across multiple technologies and operating systems.

The 7 chapters cover a dense amount of information around the 3 core topics. The book is for the reader with a solid technical background. While it may be listed as an exploratory text, it is not like a For Dummies title.

As per its title, it covers confidentiality, authentication and integrity; in addition to other fundamental topics of non-repudiation, privacy and key management.

One of the ways Stapleton brings his broad experience to the book is in the many areas where he compares different types of cryptosystems, technologies and algorithms. This enables the reader to understand what the appropriate type of authentication is most beneficial for the specific requirement.

For example, in chapter 7, the book provides a really good comparison and summary of different cryptographic modules, including how they are linked to various standards from NIST, NSA, ANSI and ISO. It does the same for a comparison of cryptographic key strengths against various algorithms.

An interesting observation the book makes when discussing the DES encryption algorithm, is that all of the talk of the NSA placing backdoors in it are essentially false. To date, no known flaws have been found against DES, and that after being around for over 30 years, the only attack against DES is an exhaustive key attack. This type of attack is where an adversary has to try each of the possible 72 quadrillion key (256permutations – as the key is 56 bits long) until the right key is discovered.

That means that the backdoor rumors of the NSA shortening the length of the substitution ciphers (AKA s-boxes), was not to weaken it necessarily. Rather it was meant to block DES against specific types of cryptanalytic attacks.

While the book is tactical; the author does bring in one bit of trivia when he writes that the ISO, often known as the International Organization for Standardization, does not in truth realty stand for that. He notes that the organizations clearly states on its web page that because International Organization for Standardization would have different acronyms in different languages (IOS in English, OIN in French for Organization internationale de normalization, etc.); its founders decided to give it the short form ISO. ISO is derived from the Greek isos, meaning equal. Whatever the country, whatever the language, the short form of the name is always ISO.

While that is indeed ultimately a trivial issue, I have seen certification exams where they ask what that acronym stands for. Perhaps a lot of CISSP's need to have their credentials revoked.

While Stapleton modifies the CIA triad, the book is not one of a security curmudgeon, rather of a security doyen. For anyone looking for an authoritative text on how to fully implement cross-platform security and authentication across the enterprise, this is a valuable reference to get that job done.

Reviewed by Ben Rothke

You can purchase Security without Obscurity: A Guide to Confidentiality, Authentication and Integrity from amazon.com. Slashdot welcomes readers' book reviews (sci-fi included) -- to see your own review here, read the book review guidelines, then visit the submission page. If you'd like to see what books are available from our review library please let us know.
This discussion has been archived. No new comments can be posted.

Book Review: Security Without Obscurity

Comments Filter:
  • by jellomizer (103300) on Monday June 16, 2014 @02:13PM (#47247753)

    The first rule is the following.
    Code it so you yourself couldn't get in without proper authorization.

    Now this doesn't mean your program in invulnerable or someone with more skill could get in. But it gets you thinking in the right mindset.

    Back in the good old days, it was common to have a back door. So you could get in if something went wrong. This wasn't a bad idea at the time, because most people wouldn't try going thew the back door that they don't know about, because they didn't know about it... However today many of these hacks are automated. And hit your system not because you have been pegged as worthy of getting broken into, but because the system found an opening and took advantage of it.

    So if you can get in without your authorization then you need to work harder to secure your system.

  • Meta-review (Score:5, Insightful)

    by MobyDisk (75490) on Monday June 16, 2014 @02:22PM (#47247831) Homepage

    These Slashdot book reviews have become useless. In general, if you have a book review, go put it on Amazon.com.

    In this case, the review is confusing and spends too much time on anecdotes, trivia, and debunking misconceptions. It's also totally in conflict with itself:

    The topic itself is not exactly compelling..., so the book is more of a detailed technical reference. Those looking for a highly technical overview, interoperability guidance, and overall reference will find the book most rewarding.

    So is the book a detailed technical reference, a highly technical overview, or an overall reference? I'm totally confused.

    A good review might start with an expanded table of contents, explaining the topics in the book, what level of expertise is required, and which ones were most poignant. If the reviewer has read other books on the subject, perhaps compare them.

    (Next: someone will post a review of this comment, producing a meta-review-review)

  • by DJ Jones (997846) on Monday June 16, 2014 @02:28PM (#47247877) Homepage
    "To date, no known flaws have been found against DES" : Er, differential calculus? Why do you think we created Triple-DES? Because we like things in threes? Supposedly the NSA made it more difficult to use differential calculus against DES by changing the S-Box permutations but it is still possible.

    There was a time when the NSA had integrity....
  • by Anonymous Coward on Monday June 16, 2014 @02:46PM (#47248059)

    There was a time when the NSA had integrity....

    Good joke.

    In 1975-76, Diffie and Martin Hellman criticized the NBS proposed Data Encryption Standard, largely because its 56-bit key length was too short to prevent Brute-force attack. An audio recording survives of their review of DES at Stanford in 1976 with Dennis Branstad of NBS and representatives of the National Security Agency.[5] Their concern was well-founded: subsequent history has shown not only that NSA actively intervened with IBM and NBS to shorten the key size, but also that the short key size enabled exactly the kind of massively parallel key crackers that Hellman and Diffie sketched out. When these were ultimately built outside the classified world, they made it clear that DES was insecure and obsolete. In 2012, a $10,000 commercially available machine can recover a DES key in days.

    http://en.wikipedia.org/wiki/W... [wikipedia.org]

    Yeah, real integrity there...

  • by Anonymous Coward on Monday June 16, 2014 @03:06PM (#47248169)

    The problem is that we, as coders and engineers want to do the right thing from the ground up.

    However, a lot of companies don't want to pony up for doing it "right". They want their guys in the offshore bargain basement dev house to make it "secure", while paying the bottom rupee amount needed to ship the product. Since it is viewed by a lot of PHBs that security has no ROI, why pay more than lip service?

    As for back doors, it isn't that hard to make one that is still secure. You have two sections. One part of the code hides the door, the other secures it. That way, when (not if) someone does find it, it can't be used for ingress. An example of this would be port knocking and incoming ssh using RSA keys (and no other forms of authentication allowed). The port knocking keeps the sshd process hidden. The RSA keys combined with fail2ban keep the sshd as a means for entry secure if someone does find it.

    The car equivalent would be a strong box that slides out from under the vehicle with a push of a button. An attacker might find the strong box, but it will take some time to either separate it from the vehicle or cut into the box to fetch the goodies in.

"Well hello there Charlie Brown, you blockhead." -- Lucy Van Pelt

Working...