Classification system for a set of processes /
function
Shows characteristics of processes over
different levels
Examples
CMMI (DEV, SVC, ACQ)
SSE-CMM
BSIMM, openSAMM, etc
Maturity Models
Open Software Assurance Maturity Model
OWASP Project
Open framework to help organizations
Formulate
Implement
Strategy for software security
Tailored to the specific risks facing the
organization
openSAMM
Recognizes 4 type of
business functions
Any organization
performing software
development would
have these (names
could be different)
openSAMM
3 business practices for each function
3 objectives (for levels) under each practice
0 (implied starting point, not included)
1 (initial understanding and ad hoc provision of practice)
2 (increase efficiency / effectiveness of practice)
3 (comprehensive mastery of the practice)
openSAMM - Security
Practices
Perform practices / activities for level 1
Keep assessing it till you are satisfied and the
scorecard tells you to
Inform management with the updated roadmap
in a periodic manner
Move to next level after you are done with the
previous one
Step 4 - Execute with
periodic reviews
Talk about how this talk is going to benefit people who want to stay connected to security but are finding it difficult to do so in the absence of a formal transition (e.g., developer, tester, etc.). Also tell them how it is a very good thing to do if you want to jump onto the technical side of security but are currently in some other job that has little relationship with security
Ask them about what they think of this image, and get onto the different perceptions that everyone has for their work and its impact on the business (bottomline – every role / work is important towards client satisfaction, but no-one is ready to accept it, except business)
Ask everyone about their work, and how do they go about it … then move onto why it is a process (a way of doing things), and why any change in either of the three (people, process, and technology) results in a better client satisfaction
Talk about how many things have forced people to come to terms now that application security should be implemented from the beginning, and not patched in the end (otherwise money just piles up).
So it gives rise to SecureSDLCs. However, in the absence of a structured approach to implement it, and a way to measure our progress and benchmarking, management sometimes make unrealistic plans / schedules, which look like this:-
This is how managementusually expects people to implement security
Can you tell me what is lacking here (people, process or technology)?