Secure Software Development Pattern: #012

[Tobias]

This is to start the discussion that shall lead to the development of a new pattern on secure software development.
As always the trickiest part will be to focus and simplify so much that we can express some of the core controls and activities in one diagram and with little text, in an area where many books and papers have been written.

We are looking for participants that have worked on this subject for many projects.
The community will thank for your contributions

Pattern goal: map the contributions/activities of the core roles to different phases of the system development against NIST controls and complement with special controls where appropriate.


Some of the better references that we have been collecting so far are:

SOAR report on software security assurance:
http://csrc.nist.gov/publications/draft ... ision2.pdf

NIST report on Security Consideration in the System Development Life Cycle (NIST 800-64 Rev2):
http://csrc.nist.gov/publications/nistp ... ision2.pdf

Microsofts "Patterns and Pratices Index" for Security Engineering:
http://msdn.microsoft.com/en-us/library/ms998404.aspx
http://msdn.microsoft.com/en-us/security/default.aspx

OWASP's CLASP:
http://www.owasp.org/index.php/Category ... SP_Project

SecurityPattern.org on secure software development:
http://www.securitypatterns.org/blog/20 ... pment.html

[Pekka]

I suggest to start with a minimal set of roles:
- project manager
- business owner
- security expert
- developer
- test engineer
- (security) architect


And a minimal set of phases and then develop a list of activities with which these roles contribute during those phases:
- conception
- design
- implementation
- test
- (post) deployment


We could start with a matrix that would list the key activity and goals for the above two axis...

Anyone eager to contribute? review?

[phaedrus]

Hey- just a few more links of interest. I try and post some brainier stuff later this week

SANS top 25 coding errors:
http://www.sans.org/top25errors/#s4
http://news.bbc.co.uk/1/hi/technology/7824939.stm

More than coding mistakes at fault in bad software (perhaps a bit of process too....):
http://www.informationweek.com/blog/mai ... codin.html

MS08-078 and the SDL
http://blogs.msdn.com/sdl/archive/2008/ ... e-sdl.aspx

Blue hat SDL sessions (some video)
http://blogs.msdn.com/sdl/archive/2008/ ... ap-up.aspx

Insecure by design???
http://arstechnica.com/news.ars/post/20 ... esign.html

Applying SDL principles to legacy code
http://blogs.msdn.com/sdl/archive/2008/ ... -code.aspx

[snajsoft]

Hey count me in... Developed software based on crypto and digital signature... now an architect...

[Tobias]

I appreciate all the contributions.
Just wanted to update on a recent publication of SANS we should reflect as well:

http://www.sans.org/top25errors/

I will work in the coming weeks with Pekka and the other interestees to draft the text into the template, then we can draft the first diagram.

[Tobias]

Hi,

Progress is not quite as fast as I imagined... but I wanted to make aware of an intermediate result:

http://www.opensecurityarchitecture.org ... arison.pdf

Next step as was mentioned earlier, we should work on a matrix that has SDLC phases on one axis, roles on the other axis and core activities in cells

Cheers
Tobias

[spinoza]

Thanks for the work so far. I like the overview a lot and feel confident that this will already be valuable (I know it will for me ). I hope to have some time to contribute in the next 1-2 weeks.
All the best.

[phaedrus]

This SANS poster from 2008 -> http://www.sans.org/whatworks/poster_2008.pdf
uses the CWE (Common Weakness Enumeration) classification from MITRE to generate a great tree diagram showing the programming common errors.

I think it may be useful background material for the SDLC pattern.

More details on CWE here -> http://cwe.mitre.org/data/

[Tobias]

I posted a first draft of the OSA SDLC description. As was previously suggested, we created a matrix that lists core activities per role and SDLC phase.

You can find it here:
http://www.opensecurityarchitecture.org ... IX_v01.pdf

[spinoza]

Some comments:

• Consider adding Operation/Maintenance, and Decommissioning Phases to the life-cycle?
• Consider adding Data Architect as part of the architecture roles?
• Add Data/Information owner as one of the roles?

I need to perform a more detailed review on the controls but so far I like the approach, particularly as it starts to bring much needed clarity to this complex space.

What other artifacts do you see being developed for this pattern?

[phaedrus]

Building Security In- Maturity model. Has some useful input....perhaps to be added to the chart

http://bsi-mm.com/

From the website-

"The Building Security In Maturity Model
The Building Security In Maturity Model (BSIMM) described on this website is designed to help you understand and plan a software security initiative. BSIMM was created through a process of understanding and analyzing real-world data from nine leading software security initiatives. Though particular methodologies differ (think OWASP CLASP, Microsoft SDL, or the Cigital Touchpoints), many initiatives share common ground. This common ground is captured and described in BSIMM. As an organizing feature, we introduce and use a Software Security Framework (SSF), which provides a conceptual scaffolding for BSIMM. Properly used, BSIMM can help you determine where your organization stands with respect to real-world software security initiatives and what steps can be taken to make your approach more effective."

[lpr]

Appreciating the matrix, I can see three potential extensions:

a) naming the column of roles

b) adding the role of a "business application owner" that is the sponsor or initiator of an IT project -- often the one "owns" the business data

c) adding a "residual risk acceptance" control to both, the current "application owner" and the newly added "business application owner".

If adding a business application owner, I can imagine adding another control for "business project risk acceptance" to the phase after the requirements analysis.

In more general terms, I, personally, would add a 'kind of' "risk acceptance" after each "analysis" or "testing" to the governing role of such a process.

What do you think?

Best regards
Lukas

[Tobias]

Hi Lukas,

I think you make some very valuable points here. I implemented them quasi 1:1.
The new version is here:

http://www.opensecurityarchitecture.org ... IX_v02.pdf