Hotwash development CISSP


Estimated Reading Time: 4 minutes

Categorization is not Equality – This Weeks CISSP Firestorm

Unless you were completely off the grid this past week, you no doubt saw the firestorm that resulted in an article on InfoSecurity.com about how the U.K. NARIC determined the CISSP was ” …granted a qualification level equal to that of a master’s degree across Europe.

Now, while I was a bit surprised at the assertion the article made, it only took a tiny bit of google-fu to find the actual breakdown of the eight levels of the EU’s European Qualifications Framework (EQF). These eight qualification levels are defined as “…a set of descriptors indicating the learning outcomes relevant to qualifications at that level in any system of qualifications.”

In fact, the definition for Category 7 of the EQF reads as follows:

KnowledgeSkillsResponsibility and autonomy
Highly specialised knowledge, some of which is at the forefront of knowledge in a field of work or study, as the basis for original thinking and/or research Critical awareness of knowledge issues in a field and at the interface between different fieldsSpecialised problem-solving skills required in research and/or innovation in order to develop new knowledge and procedures and to integrate knowledge from different fieldsManage and transform work or study contexts that are complex, unpredictable and require new strategic approaches; take responsibility for contributing to professional knowledge and practice and/or for reviewing the strategic performance of teams

In reviewing the knowledge, skills, and responsibilities that are required for inclusion into the EQF Category 7, I would argue that most people would say they sum up what a hiring manager expects to see when someone touts a CISSP on their resume. However, much to the chagrin of the Twittersphere, nowhere within this set of descriptors does it state that any degrees or certifications which have been granted a common category are interchangeable, only that they set a minimum baseline of expectations. To quote, well, myself from a tweet earlier in the week, “Categorization implies similarity, not equality. A Vespa is not equal to a Winnebago, even though they are both categorized as motorized vehicles.

Now, while I understand that, to some degree, all reporters sensationalize for their headlines, I don’t necessarily feel the lack of clarity and vagueness in the article was intentional. When re-reading the article after reading how Catagory 7 was defined, I can see why and how the piece evolved, especially after reading the ISC2 executive summary. To ISC2’s credit, they did attempt to clarify the matter in a blog post later in the week, however, as in most cases, the clarification received far less press and attention than the attention-grabbing headlines from earlier in the week.

At the end of the day, nothing in what the U.K. NARIC or ISC2 published even remotely suggested that a CISSP was a replacement for a Masters Degree. They both have their benefits and their weaknesses – which one is more important depends strictly on one thing, the position I’m looking to fill.

Why The Secure Software Development Lifecycle Must be Elevated

Much like last week’s Hotwash, this week we once again have to touch on the process of software development. This past week, Microsoft released 111 patches as part of this month’s Patch Tuesday, 56 of which addressed ‘elevation-of-privilege’ vulnerabilities. Stop and consider that for a moment. One of the oldest software development companies in the world, one who has been scratching out code for 45 years, just fixed 111 bugs Just. This. Month. If you consider that fact, it truly makes you wonder how the average, everyday enterprise development team could possibly get this right.

Then, as if to add insult to injury, another report was published this week about how 9 in 10 enterprise applications contain outdated open-source code. Yes, read that right. 9 in 10 applications. Oh – but wait – there’s more! It’s not just that the open-source components are outdated… No…No…No… that’s too easy. The reality is that 91% of the applications reviewed by the testing firm found that they relied on open-source modules that had been completely abandoned or had not been updated in more than four years. Seriously?!?

Yes – seriously. Secure Application Development has been the proverbial ‘elephant in the room’ for decades. Neverending complaints about the ‘roadblocks’ that security tools put in the way of developers’ productivity, or, how additional validation checks were unnecessary because ‘no one would ever do that’ have been the longstanding argument against any type of built-in risk mitigation. Over time, however, those arguments are falling by the wayside. Nightly static code scans, IDE integration, and pre-production security scoring have made the argument against building security into the development process a losing position.

In fact, in some peer discussions during RSA this past year, some forward-thinking organizations revealed that they are using key security metrics in a part of their annual developer performance review process. Not only are they tracking normal bugs, but they are also paying special attention to security-related bugs that are making their way into the QA/UAT process, which also includes the independent security vulnerability test. If any of the OWASP Top-10 vulnerabilities made it into the QA code, the build immediately failed QA and went back to development for correction. Just imagine what a difference it would make it every developer was held accountable for ensuring a basic level of security was built into every application. What a refreshing approach that would be.

Along these lines, this past week, Github announced that it is now offering a free static code scanner for all Github projects. This tool, based on the CodeQL tool that they acquired as part of the Semmle purchase last year, will scan projects stored in the repository for common security vulnerabilities and weaknesses. While the tool certainly assists in identifying insecure development practices, it still doesn’t force developers to do the right thing. That will always belong to the leadership of the development team, and ultimately, the leadership of the company.

Only time will tell if tools like this will truly make an impact, but now there’s no excuse if it doesn’t happen.


The Chronicles of a CISO Weekly Hotwash is a recap of critical stories and news that occurred over the past week. The goal is to hopefully share some insight and perspective on how these stories may impact our industry, our careers, or our companies.


Copyright © 2002-2020 John Masserini. All rights reserved.


Leave a comment

Your email address will not be published. Required fields are marked *