It’s been a while since I wanted to write this, but I also did not want to do it before understanding the feeling around the most active SEAL contributors and know better about the Certifications initiative. It is because that after much consideration, and evaluating feedback from different peers —particularly experienced with the creation of similar types of documentation— and primarily my own leading this ambitious initiative, I am suggesting a the Framework’s taxonomy below.
Please note that this is might not be the definitive road-map of the initiative, and one of the benefits of the flexibility it can provide is that it is also not written in stone. The document itself is way to communicate how I envision today where this initiative should aim to. In this latest revision I’ve come around that what we need is something that the community should understand as well, and despite that should’ve been obvious, it wasn’t.
What differentiates us from the other Security Frameworks, really differentiates us from them, and makes us be a thing on our own. And why I say this? Because if you take a look at ANY, and I mean ANY security framework, be it NIST’s, CISA’s, ISO’s, they are all created by one or several organizations, with super specifics purpose in mind. Most of them are government driven, funding with taxpayer money, or created by a succinct group of technical members that compose a committee. Probably the most similar to our situation is CIS, which is non-profit community-driven, and even then they get grants and contracts from US federal/state government contracts, memberships, offer services or security assessments and donations.
Oh, btw for the curious, I initially picked Framework’s logo, inspired in Maslow’s Pyramid, given the familiarity that approaches like maturity models have in this field. We need a way to to suggest individuals and organizations what, where and how to improve what they already have, and allow them to have a way to self-assess their situation, suggesting steps forward. And most importantly, write everything in a way that it can be easily understandable by anyone, but at the same time have a decent structure.
Before jumping straight ahead, here’s an excerpt of each key terms to get us re-familiarized. I am stripping the potential fancy names for each structure to make it easier to follow, and set a common, intuitive ground, that can help the reader grasp the concepts much faster. This might change in the future, but for now, and unless suggested otherwise, it won’t.
Frameworks is a wiki of scoped hierarchical markdown files. Each level is comprised of a subject matter, with siblings covering distinct topics (not overlapping) and children covering sub-topics.
As an exemplar, consider Wikipedia:
If you want a more verbose explanation, you can check out Appendix D. Otherwise, the previous explanation and the following structure should suffice for now.
Domain: Operational Security
├─ Category: Travel Security
│ └─ Sub-category: Border Crossing
│ └─ Sub-category: Public Wi-Fi Networks
├─ Category: Social Engineering
│ └─ Sub-category: Phishing
│ └─ Item: Spearphishing
│ └─ Item: QRishing
│ └─ Item: ...
│ └─ Sub-category: Pretexting
│ └─ Sub-category: Baiting
├─ Category: Communications Security
│ └─ Sub-category: Encrypted Messaging
│ └─ Sub-category: Metadata Protection
Implementation levels are the different "levels of security" users should strive to implement. Consider them a priority list for what users should focus on when starting with frameworks.