“So, Brook, in your last post you pointed to the necessity, underlined a requirement for “secure design”. But what does that mean, and how do I proceed?”
It’s a fair question that I get asked regularly: How does one get security architecture started? Where can I learn more, and grow towards mastery?
It used to be that the usual teaching method was to “shadow” (follow) a seasoned or master practitioner as she or he went about their daily duties. That’s how I learned (way back in the “Dark Ages” of security architecture) and how I’ve helped dozens of others. That methods works, at least some of the time and with some people. But shadowing has its limits.
One of the tasks that I’ve set before myself[i] is to try to figure out techniques for imparting the requisite knowledge set. Obviously, many of my publications are dedicated to this task[ii].
Still, I thought in this post that I’d set down at a very high level that set of skills that I find most of the great practitioners that I know bring to bear on the problems in secure design. In my next book (Confessions of a Cyber Security Architect) I hope to explain what security architects need to know and to delve into how one might go about gaining the knowledge. The following quote is a peek at a bit of that book:
“One may think of security architecture as the application of information security practices to digital systems (as I proposed in Securing Systems). It is more properly the intersection of a number of disciplines:
Security knowledge:
- Information security, and especially, the situationally appropriate application of security controls
- A working knowledge of existing and potential threat actors (“threat agents”)
- Digital attack types and exploits, which must include the nature of vulnerability and misuse
- Risk as it relates to software and digital systems
- Applied cryptography (at least at an architectural level)
Specific areas in software:
- Software development practices
- Software design
- Software and system architectures
General computer science:
- Computer languages and their compilation and execution
- Software interactions with underlying hardware
- Communication and data exchange protocols
- Data storage mechanisms and protocols
- Runtime and execution models and environments
- Operating systems
- Central processing unit (CPU) execution, and machine language execution in general
- Random access memory (RAM) usage and misusage”[iii]
As you may see from the list, much of the knowledge set (from computer languages onward in my list) is basic computer science, as any computer science university student, probably anywhere in the world, is likely to know.
The items in my list (above) from the top through “Applied cryptography” are the security specialist’s body of knowledge. The middle section lists those areas of software development that I believe are required in order to integrate this working knowledge into software development. Further, as I propose with developer-centric security, securing development practices as well as helping developers deliver secure designs and implementations requires security people to fit easily and organically into development practices.
In my experience, a security architect must first and foremost be a software and system architect, conversant in software and system structures and structuring, in architecture theory and practice. Understanding security without the requisite architecture and design skills means that the practitioner cannot integrate their knowledge properly into a structure and design as it evolves.
How does one gain the requisite knowledge?
Like many skill-sets that require analytic skills, it is experience, lots of practice, and indeed, learning from multiple mistakes that are excellent teachers. Learning takes time and concerted effort. Only the preternaturally gifted will attend a single secure design class and then emerge fully formed, ready and able to confront an organization’s secure design challenges. The rest of us must stumble along attempting to apply what we’ve learned, gathering scars from the inevitable errors along the way.
However, there is an emerging set of knowledge, some of which might help to shorten the learning process.
As a follow-up to my post that pointed out the continuing importance of secure design, I’d like to offer the following collection of resources as pointers that may help to build secure design skills. These have all been made publicly available for your use. Hopefully one or more the following will help you build or improve your secure design skills and/or programme?
Resources:
Threat modeling:
Avoiding the Top 10 Software Security Design Flaws
https://safecode.org/wp-content/uploads/2017/05/SAFECode_TM_Whitepaper.pdf
https://www.owasp.org/index.php/Application_Threat_Modeling
https://owasp.org/www-pdf-archive/AppSecEU2012_PASTA.pdf
Risk evaluation:
Prioritizing Information Security Risks
Just Good Enough Risk Rating (JGERR): http://brookschoenfield.com/?page_id=271
https://owasp.org/www-community/Threat_Modeling
FAIR standard: http://pubs.opengroup.org/onlinepubs/9699919899/toc.pdf
Attack methods study:
https://mitre.github.io/attack-navigator/mobile/
I hope that this list will be of some use.