CSSLP - A Secure Development Practitioner
Gaining a ISC2 CSSLP certificate in Secure Development and what to do about it. The art is in understanding the frameworks so much to be able to tailor them to the culture and risk appetite for the company at hand.
My current projects these days are mostly about security requirements - how to implement specific customer requirements and how to analyze the security impact on a delivery. It's yet another new field for the test advisor. One example could be that I assist a development team in figuring out how to improve their secure development procedure and harden their solution in the best way.
Secure development and security requirements are as much as a "things that happen in the end", "afterthought" and insurance theater, as testing has ever been. If it's successful in addressing the issues it's invisible, but if systemic issues arise it get's all the blame. Stakeholders would rather do without extensive work in the space, and similarly with many of the security controls.
Certificates are nice and all
To boost my skills in the security space I recently passed the exam for the ISC2 Certified Secure Software Development Lifecycle Practitioner (CSSLP). Yeah! Apparently I am now among one of the few in Denmark to have the CSSLP. And it seems most other take this along with the other ISC2 certificates in compliance and cyber security on order to have all the ISC2 certificates in the belt.
I will acknowledge that it was a tough exam to sit with hundreds of multiple choice questions. I like to think I passed based on industry experience and having diligently having gone through the self-phased training. During the exam I took my time, read into the options and tried to remember all acronyms and their meaning. I'm remembered that I'm not so good at memorizing acronyms, but have a working knowledge of reading into the meanings of the questions.
As with all certificates this one states that I can learn and understand a new domain and it gives me a vocabulary with in a framework. But it's in no way practical nor 100% percent applicable for all.
Most educated people can take any old framework and execute based on the templates and procedures. The art is in understanding the frameworks so much to be able to tailor them to the culture and risk appetite for the company at hand.
A relevant advisor
One catch that security and compliance have compared to functional testing have is the legal requirements and direct impact on organizational continuity. If the security and compliance posture is not in place the company license to operate is in dire straits - with no MTV. Hence the security narrative is more impactful to the stakeholders that any functional quality would generally have.
As a security advisor the practices, though, are similar to what a good test lead & test coach would work from. Sometimes we need to let the delivery team handle security, other times the security team needs to play a more active part. Some of the topics to discuss are:
- Shifting security left, making it tool-supported early
- Enable the teams on multiple levels based on where they are at
- Clear requirement traceability, clear auditable documentation
- Relational collaboration
- and People problems
It's always a people problem in the end. As always. Solve something that matters to the stakeholder and the there is amble time and money.
