Some problems have a set of relatively simple solutions like a lot of web problems boil down to using a good framework so SQL injection, XSS and so on mostly go away and get patched from the project responsible for the framework. Picking a good framework is often left as an exercise for the reader, but there is some simple/common prescriptive advice (like how to check project health, security maturity, etc.). Some problems, like logic errors, have "simple" solutions in the sense of you just need to map out the control/logic flow and then implement it correctly (see? simple!) but the actual process to do so varies hugely.
I would suggest that some advice needs to be given otherwise people end up in stackoverflow looking at out-of-date questions/answers and... yeah. We all know where that ends up. -Kurt On Sep 8, 2021, at 1:20 PM, Chris Eng <c...@veracode.com> wrote: Is it the goal of CWE to provide prescriptive guidance on these things? If so, then you might need a working group to keep up with developments in the space, since NIST updates infrequently and usually lags behind industry best practices. Or is it enough just to have categories for insecure algorithm, insecure hashing, predictable PRNG, etc. without getting into the weeds? If our aim is simply to categorize weaknesses, then keeping up with implementation details might be out of scope. I am not opposed to it but would like to better understand what problem you are trying to solve here. *From:* Alec J Summers <asumm...@mitre.org> *Sent:* Wednesday, September 8, 2021 11:11 AM *To:* CWE CAPEC Board <cwe-capec-board-list@mitre.org> *Subject:* [EXTERNAL] Proposed action: Establishing CWE/CAPEC Crypto Working Group *This email originated from outside of Veracode.* ------------------------------ Dear Board Members, Good morning! I hope you all had an excellent holiday weekend. I wanted to update you all on a plan of action around establishing a cryptography working group. Unlike many other topics covered by CWE, cryptography requires highly specialized knowledge to perform correctly. Since CWE's early days, that knowledge has evolved, but CWE entries have not kept up with the pace of change. The CWE crypto team is nearing a point in which it must make decisions about how to represent and organize certain concepts in ways that are understandable to developers while being consistent with current perspectives and principles within the cryptography community. Accordingly, a CWE working group could provide focused discussion to give confidence that changes will be beneficial to CWE users. A cryptography working group would be very helpful to the modernization of CWE with respect to cryptography, key management, hashing, randomness/predictability, and other related concepts. The group could be drawn from CWE crypto team members, interested parties from the CWE research list, people who have provided feedback on earlier questions from the crypto team, and focused outreach to knowledgeable individuals from academia, NIST, and security consultants. The working group might start off informally with e-mail discussion on broader modernization strategies for CWE with respect to crypto, then diving into individual topics needing resolution and discussion. A monthly meeting might be appropriate for richer discussion. It is not clear how long this working group would be necessary, but regular discussions might be necessary until at least April 2021. Its benefits would pay off immediately, possibly influencing changes in CWE 4.6, scheduled for release in late October. Please let me know if you have any thoughts or objections to this plan of action. Cheers, Alec p.s. If you haven’t had a chance to provide feedback to the DRAFT CWE/CAPEC Board Charter, please do so by 9/13. -- *Alec J. Summers* Cyber Solutions Innovation Center Group Leader, Software Assurance Research & Practice Cyber Security Engineer, Lead O: (781) 271-6970 C: (781) 496-8426 *––––––––––––––––––––––––––––––––––––* *MITRE - Solving Problems for a Safer World*
