CCSP How-To: A Legit Cheat-Sheet

A recent CCSP test-taker posted a blog entry (and made a related Reddit post) about their own experience in studying for/taking the exam…it is incredibly detailed and thorough, and reads very well. When I teach test-prep classes, I try to convey a list of “foot-stompers”: those elements of the material that are crucial and which candidates should really drill down on for the exam…this blog entry seems like a perfect list of foot-stompers to me. Enjoy!

“Preparation Guide for ISC2 Certified Cloud Security Professional (CCSP) Certification” by Stanislas Quastana

https://stanislas.io/2018/07/12/preparation-guide-for-isc2-certified-cloud-security-professional-ccsp-certification/

CCSP Feedback From Today

Got this from a former student today:

”I certainly don't want to scare anyone who hasn't taken it yet but I thought it was fairly difficult. Moreso than the CISSP in my opinion. Some of the questions seemed pretty out of left field based on the material we studied. And I think as we all know, the wording and phrasing of the question is super key so you have to pay very close attention to that or you'll get tripped up. Can't emphasize that enough. 180min duration and I wrapped with 7mins left but that was after I went through and reviewed EVERY answer a second time and some three times.”

Good to know.

The Flatline Cohesion Principle

This week’s CCSP class pointed out that one of the multiple-choice answers in my book of practice tests included the term “flatline cohesion principle.” They asked me what it meant, and I had to admit that I had no clue…maybe it meant that I was drinking too much scotch when I wrote the book?

Turns out, it was a nonsense term I invented as a distractor from the correct answer to that specific question. So we discussed the idea, and decided we had to come up with a definition for the completely blank term.

The consensus was that it should mean: “When you write a book of practice tests that may or may not have complicated, misleading questions in it, then use your class to crowdsource how worthy the material is for study purposes.”

I do like this. But I am very open to alternative uses for the term. If someone comes up with something better, put it in the Comments section, and I’ll send you a free copy of the book. I will be the sole judge of what constitutes “better.”

In the meantime: everyone should follow the flatline cohesion principle.

And many, many thanks to this week’s CCSP class participants: y’all were awesome, and I think you’re all gonna to conquer the exam.

CCSP Test Feedback

From a recent student:

”I found it to be quite challenging, mostly because more than a few of the questions and / or answers were so tersely worded that it was very hard to determine what was being asked.  I also ran into some test questions on concepts that weren’t covered in the course material, or if they were,  it was in passing and didn’t really justify the attention it got on the exam.  However, I passed, so it’s all behind me now.  :^) “

Ditching the ALE

At this point in my career, I deliver a lot of certification prep content, through teaching and writing. And I see certain things that were included at the outset of the industry as guidelines and suggestions that just aren't applicable anymore (or at least, not applicable in the same way as when they were proposed). My primary customer is ISC2, for the CISSP and CCSP certs, but I've taught ISACA and CompTIA certification prep courses in the past, and many of them suffer from the same problems. While I can't say for certainty exactly why all the major INFOSEC certifications suffer from the same blind spots, I can guess: most of the test writers have the same training in the same fundamental concepts, get the same certifications (from multiple vendors), and have received that content from their predecessors, and will pass it to the next generation in kind.

This leads to the possibility of stagnancy in content and approach. Which isn't terrible, for certain fundamental security concepts (say, defense-in-depth/layered approach/multiple redundant controls, or the use of two-person integrity), but there are other notions/ideas that are simply treated as sacrosanct in perpetuity, instead of being re-examined for validity, assessed as nonsense, and thrown onto the trash pile of history.

Today, I want to talk about one of the latter: the ALE formula.

If you don't what it is, consider yourself lucky. Then consider yourself unlucky, because if you're going to go get an INFOSEC cert, I can tell you for damn sure that it's going to be one of the things you're going to have to learn and memorize whether you like it or not.

Simply put, it's an approach to estimating the cost of a given type of negative impact as the result of security risk being realized. We teach INFOSEC practitioners that this value determination can be used to weigh the possible costs of controls to address a particular risk, and figure out whether or not to spend the money protecting against it.

Which is a good idea: spending too much on addressing a particular threat is just as bad as not spending enough...and, arguably, sometimes worse, because spending too much leaves you with a false sense of security and a lack of money, where not spending enough just means you have some of that risk left.

But the ALE formula is not really the best tool to accomplish this in our realm of INFOSEC, for many, many reasons. And we should stop requiring its use, and teaching it to newbies.

Why? Well, for starters, let's talk about the potential cost of a single type of incident, known in the formula as the SLE.

It's worth noting that the ALE formula works great in the physical security universe, where tangible assets can be mapped to specific losses. If I'm trying to secure a retail space selling goods that are of a particular size, shape, weight, and cost, I know some discrete, objective information about those assets. I know how many can be stolen at one time, by a single person picking them up and walking off with them. I know the amount (number and dollar value) of my inventory, based on another limiting factor: the footprint of my retail space and storage area. I know the various access points to get at my inventory: the doors/windows/loading areas. All these things can be defined and somewhat limited.

With electronic data as assets, all this numeric determination goes out the window (I mean, not the literal window, like tangible assets, but a metaphorical window, because the determination is impossible). I can't really know how many "data"s a person can steal at any given moment, because the size of files or objects or characters don't really have any meaning in the physical universe-- a flashstick that weighs less than an ounce can carry one file or a thousand files, and any given file can contain one character, or a million characters, and all of this fits inside one person's pocket, anyway (and that person doesn't need any exceptional muscles to carry even the heaviest flashstick).

So trying to determine the monetary impact of a single security event involving data is impossible, unlike the impact of a single security event involving physical assets. If someone steals one spoon in a retail environment, we know the cost of that spoon (and we actually know several costs: the wholesale cost we paid to get the spoon, the retail cost of what we would have realized in revenue if we sold that spoon, and the logistical cost of getting that spoon to the retail location)...but if someone steals a file, the value of the information in that file can vary wildly. A file might contain a photo of the user’s pet kitten (which is of value only to the user, and then only arguably at that, if the user has a copy of the photo), or it can contain the privacy data of the target organization’s entire customer base, and the relevant monetary impact can stretch into the range of millions of dollars, as the result of statutory damages assessed against the organization, or the loss of market share, or direct fraud on the part of the perpetrator using that information, and so on.

Sure, insurance companies in recent years have created various approaches to assigning value to data, but these are all just gibberish. Take, for instance, the idea of “average file cost”-- even if we were to determine the midpoint of value between the kitten photo and the customer list, that medium value would be meaningless when we suffered an actual loss: if we lost the kitten photo, and the insurance claim paid the amount of “average cost,” we’d be receiving far more in cash payout than the thing was worth, and if we lost the customer list the “average cost” claim payout would be far less than the damage we’d suffered. And what’s the size/value of an “average” file, anyway? How many files are there in a given business environment? The concept is absolutely pointless.

When the SLE is just a fictional construct, the entire ALE formula is ridiculous. We could use just this argument to eliminate the wretched thing from our industry. But there are even more reasons why ALE is stupid in the INFOSEC world-- and I’ll get to those in subsequent articles.