Docstoc

BSI-MM-Outline-base

Document Sample
BSI-MM-Outline-base Powered By Docstoc
					This document contains the activities documented in the BSI-MM, created by Gary McGraw, Ph.D.,
Migues.

I liked the concept immediately, and downloaded the PDF describing the program in early April 20
Once "on the coolaid", I ran into some difficulty trying to find a simple, flexible listing of the BSI
could be easily sliced, diced, rearranged, and ultimately translated into a formal project plan.

I put this workbook together for our own work, and to faciliate yours. Here's how it works.

The "Summary" sheet ( red ) contains the full listing of all steps in the same order as they are listed i

The data is broken into columns for each data element, and summary fields are built up from conc
Additional columns have been added to facilitate re-sequencing the activities, in the Pivot sheet, b
sequence decisions and needs. If you don't know how pivot tables are used, there are many good

[ for example, http://www.ozgrid.com/Excel/excel-pivot-tables.htm ]

The basic operations allow you to drag the column headings in the pivot table to re
worksheet. Slice and dice! It's nice!

In this case, we have taken a quick pass, decided which things made sense to us for phase 1, and
welcome to change those values in the "Summary" sheet. To refresh the pivot table, right
to "refresh data". At that point any changes you made to data in the Summary sheet, in the column
or "Implementation Priority" will drive the data display in the pivot table.

This works for Data Pilot in OpenOffice as well.

In addition, a project file in MS Project (& OpenProj ) format has also been submitted to the BSI
will help study, slice and dice the activity info, the Project file will facilitate a true Project Implemen
drag the activities to arrange them in the phases or groupings you need.


David Kadow
kadowd@gmail.com
eated by Gary McGraw, Ph.D., Brian Chess, Ph.D., & Sammy


ng the program in early April 2009.
 e, flexible listing of the BSI-MM contents, in a format that
 into a formal project plan.

 Here's how it works.

same order as they are listed in the BSI-MM document.

 ry fields are built up from concatenations of these data.
e activities, in the Pivot sheet, based upon your own project
are used, there are many good websites for this info.



pivot table to re-group, re-order the data held in another


de sense to us for phase 1, and at what priority. You are
 the pivot table, right-click in the middle of it, and pull down
 Summary sheet, in the columns for "Implementation Phase"




 been submitted to the BSI-MM team. Where the spreadsheet
 ilitate a true Project Implementation. Copy or click-click-
                                                                                                           BSI-MM Program Ph1



Implementa Implementati
 tion Phase on Priority              Practice                            Activity                                         Objective                     Objective-code
        1            1 ATTACK MODELS                                                               understand attack basics
                                                       build and maintain a top N possible attacks list                                                 AM.1.1
                       CODE REVIEW                                                                 know which bugs matter to you
                                                       create top N bugs list (real data preferred) (T: training)                                       CR.1.1
                       COMPLIANCE AND POLICY           identify PII obligations                    promote privacy                                      CP.1.2
                                                       create/interface with incident response know what to do when something bad happens
                       CONFIGURATION MANAGEMENT AND VULNERABILITY MANAGEMENT                                                                            CMVM.1.1
                       PENETRATION TESTING                                                                                                              PT.1.1
                                                       use external pen testers to find problems demonstrate that your organization's code needs help too
                       SECURITY FEATURES AND DESIGN    engage SSG with architecture                inject security thinking into architecture group     SFD.1.2
                       SOFTWARE ENVIRONMENT            ensure host/network security basics in placeprovide a solid host/network foundation for software SE.1.2
                       STANDARDS AND REQUIREMENTS      create security portal                                                                           SR.1.2
                                                                                                   ensure that everybody knows where to get latest and greatest
                       STRATEGY AND METRICS                                                        make the plan explicit
                                                       publish process (roles, responsibilities, plan), evolve as necessary                             SM.1.1
                       TRAINING                        provide awareness training                                                                       T.1.1
                                                                                                   promote culture of security throughout the organization
                     2 ARCHITECTURE ANALYSIS           perform security feature review             get started with AA                                  AA.1.1
                       ATTACK MODELS                   collect and publish attack stories          understand the organization's history                AM.1.4
                       COMPLIANCE AND POLICY                                                       understand compliance drivers (FFIEC, GLBA, OCC, PCI, SOX, SAS 70, HIPAA)
                                                       know all regulatory pressures and unify approach                                                 CP.1.1
                                                       identify software bugs found in             use and feed back to dev
                       CONFIGURATION MANAGEMENT AND VULNERABILITY MANAGEMENT ops monitoringops data to change dev behavior                              CMVM.1.2
                       PENETRATION TESTING                                                         fix what you find to show
                                                       feed results to defect management/mitigation (T: config/vuln mgmt)real progress                  PT.1.2
                       SECURITY FEATURES AND DESIGN                                                create proactive security guidance around security features protocols)
                                                                                                                                                        crypto,
                                                       build/publish security features (authentication, role management, key management, audit/log, SFD.1.1
                       SECURITY TESTING                share security results with QA              facilitate security mindset                          ST.1.2
                       SOFTWARE ENVIRONMENT            use application input monitoring            watch software                                       SE.1.1
                       STANDARDS AND REQUIREMENTS                                                  compliance strategy
                                                       translate compliance constraints to requirements                                                 SR.1.3
                       STRATEGY AND METRICS            educate executives                          secure executive buy-in                              SM.1.3
                       TRAINING                        include security resources in onboarding ensure new hires enhance culture                        T.1.2
                     3 ARCHITECTURE ANALYSIS                                                       demonstrate value of AA with real data
                                                       perform design review for high-risk applications                                                 AA.1.2
                       COMPLIANCE AND POLICY           create policy                                                                                    CP.1.3
                                                                                                   meet regulatory needs or customer demand with a unified approach
                       PENETRATION TESTING             use pen testing tools internally            create internal capability                           PT.2.1
                       SECURITY TESTING                                                              condition testing
                                                       ensure QA supports edge/boundary valueexecute adversarial tests beyond functional                ST.1.1
                       STANDARDS AND REQUIREMENTS                                                  meet demand for security features
                                                       create security standards (T: sec features/design)                                               SR.1.1
                     4 ARCHITECTURE ANALYSIS                                                       have lightweight approach                            AA.1.4
                                                       use risk questionnaire to rank apps standardizeaapproach using attack to risk classification and prioritization
                       STANDARDS AND REQUIREMENTS      create secure coding standards              tell people what to look for in code review          SR.1.4
Grand Total




             e86a304b-8fd1-40db-b6aa-66ec7f8f67a6.xls                                                                 33                                                       10/25/2012
                                           Practice-Code
row       Domain          Practice
  2   GOVERNANCE   STRATEGY AND METRICS    SM
  3   GOVERNANCE   STRATEGY AND METRICS    SM
  4   GOVERNANCE   STRATEGY AND METRICS    SM
  5   GOVERNANCE   STRATEGY AND METRICS    SM
  6   GOVERNANCE   STRATEGY AND METRICS    SM
  7   GOVERNANCE   STRATEGY AND METRICS    SM
  8   GOVERNANCE   STRATEGY AND METRICS    SM
  9   GOVERNANCE   STRATEGY AND METRICS    SM
 10   GOVERNANCE   STRATEGY AND METRICS    SM
 11   GOVERNANCE   STRATEGY AND METRICS    SM
 12   GOVERNANCE   STRATEGY AND METRICS    SM

13    GOVERNANCE   COMPLIANCE AND POLICY   CP

14    GOVERNANCE   COMPLIANCE AND POLICY   CP

15    GOVERNANCE   COMPLIANCE AND POLICY   CP

16    GOVERNANCE   COMPLIANCE AND POLICY   CP

17    GOVERNANCE   COMPLIANCE AND POLICY   CP

18    GOVERNANCE   COMPLIANCE AND POLICY   CP

19    GOVERNANCE   COMPLIANCE AND POLICY   CP

20    GOVERNANCE   COMPLIANCE AND POLICY   CP

21    GOVERNANCE   COMPLIANCE AND POLICY   CP

22    GOVERNANCE   COMPLIANCE AND POLICY   CP

23    GOVERNANCE   COMPLIANCE AND POLICY   CP

24    GOVERNANCE   TRAINING                  T
25    GOVERNANCE   TRAINING                  T

26    GOVERNANCE   TRAINING                  T
27    GOVERNANCE   TRAINING                  T

28    GOVERNANCE   TRAINING                  T
29    GOVERNANCE   TRAINING                  T
30    GOVERNANCE   TRAINING                  T

31    GOVERNANCE   TRAINING                  T
32    GOVERNANCE   TRAINING                  T
33   GOVERNANCE      TRAINING                 T
34   GOVERNANCE      TRAINING                 T
35   GOVERNANCE      TRAINING                 T
36   INTELLIGENCE    ATTACK MODELS           AM

37   INTELLIGENCE    ATTACK MODELS           AM
38   INTELLIGENCE    ATTACK MODELS           AM
39   INTELLIGENCE    ATTACK MODELS           AM

40   INTELLIGENCE    ATTACK MODELS           AM
41   INTELLIGENCE    ATTACK MODELS           AM

42   INTELLIGENCE    ATTACK MODELS           AM
43   INTELLIGENCE    ATTACK MODELS           AM

44   INTELLIGENCE    ATTACK MODELS           AM
45   INTELLIGENCE    ATTACK MODELS           AM
                     SECURITY FEATURES AND
46   INTELLIGENCE    DESIGN                  SFD
                     SECURITY FEATURES AND
47   INTELLIGENCE    DESIGN                  SFD
                     SECURITY FEATURES AND
48   INTELLIGENCE    DESIGN                  SFD
                     SECURITY FEATURES AND
49   INTELLIGENCE    DESIGN                  SFD
                     SECURITY FEATURES AND
50   INTELLIGENCE    DESIGN                  SFD
                     SECURITY FEATURES AND
51   INTELLIGENCE    DESIGN                  SFD
                     SECURITY FEATURES AND
52   INTELLIGENCE    DESIGN                  SFD
                     STANDARDS AND
53   INTELLIGENCE    REQUIREMENTS            SR
                     STANDARDS AND
54   INTELLIGENCE    REQUIREMENTS            SR
                     STANDARDS AND
55   INTELLIGENCE    REQUIREMENTS            SR
                     STANDARDS AND
56   INTELLIGENCE    REQUIREMENTS            SR
                     STANDARDS AND
57   INTELLIGENCE    REQUIREMENTS            SR
                     STANDARDS AND
58   INTELLIGENCE    REQUIREMENTS            SR
                     STANDARDS AND
59   INTELLIGENCE    REQUIREMENTS            SR
                     STANDARDS AND
60   INTELLIGENCE    REQUIREMENTS            SR
                     STANDARDS AND
61   INTELLIGENCE    REQUIREMENTS            SR
                     STANDARDS AND
62   INTELLIGENCE    REQUIREMENTS            SR
63   SSDL TOUCHPOINTSARCHITECTURE ANALYSIS   AA
64   SSDL TOUCHPOINTSARCHITECTURE ANALYSIS   AA

65   SSDL TOUCHPOINTSARCHITECTURE ANALYSIS   AA

66   SSDL TOUCHPOINTSARCHITECTURE ANALYSIS   AA
67   SSDL TOUCHPOINTSARCHITECTURE ANALYSIS   AA

68   SSDL TOUCHPOINTSARCHITECTURE ANALYSIS   AA
69   SSDL TOUCHPOINTSARCHITECTURE ANALYSIS   AA
70   SSDL TOUCHPOINTSARCHITECTURE ANALYSIS   AA

71   SSDL TOUCHPOINTSARCHITECTURE ANALYSIS   AA
72   SSDL TOUCHPOINTSCODE REVIEW             CR

73   SSDL TOUCHPOINTSCODE REVIEW             CR

74   SSDL TOUCHPOINTSCODE REVIEW             CR
75   SSDL TOUCHPOINTSCODE REVIEW             CR
76   SSDL TOUCHPOINTSCODE REVIEW             CR
77   SSDL TOUCHPOINTSCODE REVIEW             CR

78   SSDL TOUCHPOINTSCODE REVIEW             CR
79   SSDL TOUCHPOINTSCODE REVIEW             CR
80   SSDL TOUCHPOINTSCODE REVIEW             CR
81   SSDL TOUCHPOINTSCODE REVIEW             CR

82   SSDL TOUCHPOINTSCODE REVIEW             CR
83   SSDL TOUCHPOINTSSECURITY TESTING        ST
84   SSDL TOUCHPOINTSSECURITY TESTING        ST

85   SSDL TOUCHPOINTSSECURITY TESTING        ST

86   SSDL TOUCHPOINTSSECURITY TESTING        ST

87   SSDL TOUCHPOINTSSECURITY TESTING        ST
88   SSDL TOUCHPOINTSSECURITY TESTING        ST
89   SSDL TOUCHPOINTSSECURITY TESTING        ST
90   SSDL TOUCHPOINTSSECURITY TESTING        ST
91   SSDL TOUCHPOINTSSECURITY TESTING        ST

92   DEPLOYMENT      PENETRATION TESTING     PT
93   DEPLOYMENT      PENETRATION TESTING     PT
94   DEPLOYMENT      PENETRATION TESTING     PT

95   DEPLOYMENT      PENETRATION TESTING     PT
96   DEPLOYMENT      PENETRATION TESTING     PT

97   DEPLOYMENT      PENETRATION TESTING     PT
98   DEPLOYMENT      PENETRATION TESTING     PT

99   DEPLOYMENT      SOFTWARE ENVIRONMENT    SE
100   DEPLOYMENT   SOFTWARE ENVIRONMENT    SE

101   DEPLOYMENT   SOFTWARE ENVIRONMENT    SE

102   DEPLOYMENT   SOFTWARE ENVIRONMENT    SE

103   DEPLOYMENT   SOFTWARE ENVIRONMENT    SE

104   DEPLOYMENT   SOFTWARE ENVIRONMENT    SE
                   CONFIGURATION
                   MANAGEMENT AND
                   VULNERABILITY
105   DEPLOYMENT   MANAGEMENT             CMVM
                   CONFIGURATION
                   MANAGEMENT AND
                   VULNERABILITY
106   DEPLOYMENT   MANAGEMENT             CMVM
                   CONFIGURATION
                   MANAGEMENT AND
                   VULNERABILITY
107   DEPLOYMENT   MANAGEMENT             CMVM
                   CONFIGURATION
                   MANAGEMENT AND
                   VULNERABILITY
108   DEPLOYMENT   MANAGEMENT             CMVM
                   CONFIGURATION
                   MANAGEMENT AND
                   VULNERABILITY
109   DEPLOYMENT   MANAGEMENT             CMVM
                   CONFIGURATION
                   MANAGEMENT AND
                   VULNERABILITY
110   DEPLOYMENT   MANAGEMENT             CMVM
                   CONFIGURATION
                   MANAGEMENT AND
                   VULNERABILITY
111   DEPLOYMENT   MANAGEMENT             CMVM
                   Objective
make the plan explicit
build support throughout organization
secure executive buy-in
establish SSDL gates (but do not enforce)
define success
foster transparency (or competition)
change behavior
create broad base of support
make clear who's taking the risk
know where all apps in your inventory stand
create external support
understand compliance drivers (FFIEC, GLBA,
OCC, PCI, SOX, SAS 70, HIPAA)

promote privacy
meet regulatory needs or customer demand
with a unified approach

promote privacy

ensure accountability for software risk

align practices with compliance

ensure vendors don't screw up compliance

gain executive buy-in

demonstrate compliance story

manage third-party vendors

keep policy aligned with reality
promote culture of security throughout the
organization
ensure new hires enhance culture
act as informal resource to leverage teachable
moments
create social network tied into dev

build capabilities beyond awareness
see yourself in the problem
keep staff up-to-date and address turnover
reduce impact on training targets and delivery
staff
educate/strengthen social network
align security culture with career path
spread security culture to providers
market security culture as differentiator
understand attack basics
prioritize applications by data
consumed/manipulated
understand the "who" of attacks
understand the organization's history

provide resources for security testing and AA
understand technology-driven attacks

stay current on attack/vulnerability environment
communicate attacker perspective

get ahead of the attack curve
arm testers and auditors
create proactive security guidance around
security features

inject security thinking into architecture group
create proactive security design based on
technology stacks

address the need for new architecture

practice reuse

formalize consensus on design

promote design efficiency

meet demand for security features
ensure that everybody knows where to get
latest and greatest

compliance strategy

tell people what to look for in code review

educate third-party vendors

formalize standards process

reduce SSG workload

manage open source risk
gain buy-in from legal department and
standardize approach

manage open source risk
get started with AA
demonstrate value of AA with real data

build internal capability on security architecture
have a lightweight approach to risk
classification and prioritization
model objects
promote a common language for describing
architecture
build capability organization-wide
build capabilities organization-wide

build proactive security architecture
know which bugs matter to you

review high-risk applications opportunistically
spread software security around without any
process
drive efficiency/consistency with automation
drive behavior objectively
find bugs earlier

know which bugs matter (for training)
make most efficient use of tools
drive efficiency/reduce false positives
combine assessment techniques
handle new bug classes in an already scanned
codebase
execute adversarial tests beyond functional
facilitate security mindset

use encapsulated attacker perspective
start security testing in familiar functional
territory
move beyond functional testing to attacker's
perspective
include security testing in regression
teach tools about your code
probe risk claims directly
drive testing depth
demonstrate that your organization's code
needs help too
fix what you find to show real progress
create internal capability

promote deeper analysis
sanity check constantly

keep up with edge of attacker's perspective
automate for efficiency without losing depth

watch software
provide a solid host/network foundation for
software
protect IP and make exploit development
harder

guide operations on application needs

watch software
protect apps (or parts of apps) that are
published over trust boundaries



know what to do when something bad happens



use ops data to change dev behavior


be able to fix apps when they are under direct
attack



use ops data to change dev behavior



know where the code is



learn from operational experience



use ops data to change dev behavior
                                                                                                           Objective-code



                                                                                                                            Implementatio
                                                                         Maturity Level




                                                                                                                            n Phase
                                                                                          Item #
                                   Activity
publish process (roles, responsibilities, plan), evolve as necessary        1              1       SM.1.1                       1
create evangelism role/internal marketing                                   1              2       SM.1.2
educate executives                                                          1              3       SM.1.3                       1
identify gate locations, gather necessary artifacts                         1              4       SM.1.4
identify metrics and drive initiative budgets with them                     1              5       SM.1.5
publish data about software security internally                             2              1       SM.2.1
enforce gates with measures and track exceptions                            2              2       SM.2.2
create or grow social network/satellite system                              2              3       SM.2.3
require security sign-off                                                   2              4       SM.2.4
use internal tracking application with portfolio view                       3              1       SM.3.1
run external marketing program                                              3              2       SM.3.2

know all regulatory pressures and unify approach                            1              1       CP.1.1                       1

identify PII obligations                                                    1              2       CP.1.2                       1

create policy                                                               1              3       CP.1.3                       1

identify PII data in systems (inventory)                                    2              1       CP.2.1

require security sign-off for compliance-related risk                       2              2       CP.2.2

implement/track controls for compliance                                     2              3       CP.2.3

paper all vendor contracts with SLAs compatible with policy                 2              4       CP.2.4

promote executive awareness of compliance/privacy obligations               2              5       CP.2.5

create regulator eye-candy                                                  3              1       CP.3.1

impose policy on vendors                                                    3              2       CP.3.2

drive feedback from SSDL data back to policy (T: strategy/metrics)          3              3       CP.3.3

provide awareness training                                                  1              1       T.1.1                        1
include security resources in onboarding                                    1              2       T.1.2                        1

establish SSG office hours                                                  1              3       T.1.3
identify satellite during training                                          1              4       T.1.4
offer role-specific advanced curriculum (tools, technology stacks, bug
parade)                                                                     2              1       T.2.1
create/use material specific to company history                             2              2       T.2.2
require annual refresher                                                    2              3       T.2.3

offer on-demand individual training                                         2              4       T.2.4
hold satellite training/events                                              2              5       T.2.5
reward progression through curriculum (certification or HR)             3   1   T.3.1
provide training for vendors or outsource workers                       3   2   T.3.2
host external software security events                                  3   3   T.3.3
build and maintain a top N possible attacks list                        1   1   AM.1.1    1

create data classification scheme and inventory                         1   2   AM.1.2
identify potential attackers                                            1   3   AM.1.3
collect and publish attack stories                                      1   4   AM.1.4    1

build attack patterns and abuse cases tied to potential attackers       2   1   AM.2.1
create technology-specific attack patterns                              2   2   AM.2.2

gather attack intelligence                                              2   3   AM.2.3
build internal forum to discuss attacks (T: standards/req)              2   4   AM.2.4
have a science team that develops new attack methods arm testers
and auditors                                                            3   1   AM.3.1
create and use automation to do what the attackers will do              3   2   AM.3.2
build/publish security features (authentication, role management, key
management, audit/log, crypto, protocols)                               1   1   SFD.1.1   1

engage SSG with architecture                                            1   2   SFD.1.2   1
build secure-by-design middleware frameworks/common libraries (T:
code review)                                                            2   2   SFD.2.2

create SSG capability to solve difficult design problems                2   3   SFD.2.3

find/publish mature design patterns from the organization               2   3   SFD.2.3
form review board or central committee to approve and maintain
secure design                                                           3   3   SFD.3.3

require use of approved security features and frameworks (T: AA)        3   1   SFD.3.1

create security standards (T: sec features/design)                      1   1   SR.1.1    1

create security portal                                                  1   2   SR.1.2    1

translate compliance constraints to requirements                        1   3   SR.1.3    1

create secure coding standards                                          1   4   SR.1.4    1

communicate standards to vendors                                        2   1   SR.2.1

create a standards review board                                         2   2   SR.2.2

create standards for technology stacks                                  2   3   SR.2.3

identify open source in apps                                            2   4   SR.2.4

gain buy-in from legal department and standardize approach              2   5   SR.2.5

control open source risk                                                3   1   SR.3.1
perform security feature review                                         1   1   AA.1.1    1
perform design review for high-risk applications                           1   2   AA.1.2   1

have SSG lead review efforts                                               1   3   AA.1.3

use risk questionnaire to rank apps standardize approach using attack      1   4   AA.1.4   1
define/use AA process                                                      2   1   AA.2.1

standardize architectural descriptions (include data flow)                 2   2   AA.2.2
make SSG available as AA resource/mentor                                   2   3   AA.2.3
have software architects lead review efforts                               3   1   AA.3.1
drive analysis results into standard architectural patterns (T: sec
features/design)                                                           3   2   AA.3.2
create top N bugs list (real data preferred) (T: training)                 1   1   CR.1.1   1

have SSG perform ad hoc review                                             1   2   CR.1.2

establish coding labs or office hours focused on review                    1   3   CR.1.3
use automated tools along with manual review                               2   1   CR.2.1
enforce coding standards                                                   2   2   CR.2.2
make code review mandatory for all projects                                2   3   CR.2.3
use centralized reporting (close knowledge loop, drive training) (T:
strategy/metrics)                                                          2   4   CR.2.4
assign tool mentors                                                        2   5   CR.2.5
use automated tools with tailored rules                                    3   1   CR.3.1
build a factory                                                            3   2   CR.3.2

build capability for eradicating specific bugs from entire codebase        3   3   CR.3.3
ensure QA supports edge/boundary value condition testing                   1   1   ST.1.1   1
share security results with QA                                             1   2   ST.1.2   1
integrate black box security tools into the QA process (including
protocol fuzzing)                                                          2   1   ST.2.1

allow declarative security/security features to drive tests                2   2   ST.2.2

begin to build/apply adversarial security tests (abuse cases)              2   3   ST.2.3
include security tests in QA automation                                    3   1   ST.3.1
perform fuzz testing customized to application APIs                        3   2   ST.3.2
drive tests with risk analysis results                                     3   3   ST.3.3
leverage coverage analysis                                                 3   4   ST.3.4

use external pen testers to find problems                                  1   1   PT.1.1   1
feed results to defect management/mitigation (T: config/vuln mgmt)         1   2   PT.1.2   1
use pen testing tools internally                                           2   1   PT.2.1   1

provide pen testers with all available information (T: AA & code review)   2   2   PT.2.2
periodic scheduled pen tests for app coverage                              2   3   PT.2.3
use external pen testers to perform deep dive (one-off bugs/fresh
thinking)                                                                  3   1   PT.3.1
have SSG customize pen testing (tools and scripts)                         3   2   PT.3.2

use application input monitoring                                           1   1   SE.1.1   1
ensure host/network security basics in place                             1   2   SE.1.2     1

use code protection                                                      2   1   SE.2.1

publish installation guides created by SSDL                              2   2   SE.2.2

use application behavior monitoring and diagnostics                      2   3   SE.2.3

use code signing                                                         3   1   SE.3.1



create/interface with incident response                                  1   1   CMVM.1.1   1



identify software bugs found in ops monitoring and feed back to dev      1   2   CMVM.1.2   1



have emergency codebase response                                         2   1   CMVM.2.1



track software bugs found during ops through the fix process             2   2   CMVM.2.2



develop operations inventory of apps                                     2   3   CMVM.2.3


fix all occurrences of software bugs from ops in the codebase (T: code
review)                                                                  3   1   CMVM.3.1


enhance dev processes (SSDL) to prevent cause of software bugs
found in ops                                                             3   2   CMVM.3.2
Implementatio



                Sequence
n Priority
                Project



                                         Decision notes
    1                      really need to DEFINE the process first

    2




    2              2

    1              1

    3              3




    1
    2
1



2




2   requires appdev satellites

1   no arch grp at Natixis, but we can engage each team




3

1   easy. Low hanging fruit

2

4




2   Step 1 is define review process and criteria
3



4




1

    Need more staff than we have

    unlikely at Natixis




3
2   Step 1 create official QA function




1
2
3




2
1




1



2
                                             Practice-
row       Domain            Practice          Code
  2   GOVERNANCE   STRATEGY AND METRICS    SM
  3   GOVERNANCE   STRATEGY AND METRICS    SM
  4   GOVERNANCE   STRATEGY AND METRICS    SM
  5   GOVERNANCE   STRATEGY AND METRICS    SM
  6   GOVERNANCE   STRATEGY AND METRICS    SM
  7   GOVERNANCE   STRATEGY AND METRICS    SM
  8   GOVERNANCE   STRATEGY AND METRICS    SM
  9   GOVERNANCE   STRATEGY AND METRICS    SM
 10   GOVERNANCE   STRATEGY AND METRICS    SM
 11   GOVERNANCE   STRATEGY AND METRICS    SM
 12   GOVERNANCE   STRATEGY AND METRICS    SM
 13   GOVERNANCE   COMPLIANCE AND POLICY   CP
 14   GOVERNANCE   COMPLIANCE AND POLICY   CP
 15   GOVERNANCE   COMPLIANCE AND POLICY   CP
 16   GOVERNANCE   COMPLIANCE AND POLICY   CP
 17   GOVERNANCE   COMPLIANCE AND POLICY   CP
 18   GOVERNANCE   COMPLIANCE AND POLICY   CP
 19   GOVERNANCE   COMPLIANCE AND POLICY   CP
 20   GOVERNANCE   COMPLIANCE AND POLICY   CP
 21   GOVERNANCE   COMPLIANCE AND POLICY   CP
 22   GOVERNANCE   COMPLIANCE AND POLICY   CP
 23   GOVERNANCE   COMPLIANCE AND POLICY   CP
 24   GOVERNANCE   TRAINING                T
 25   GOVERNANCE   TRAINING                T
 26   GOVERNANCE   TRAINING                T
 27   GOVERNANCE   TRAINING                T
 28   GOVERNANCE   TRAINING                T
 29   GOVERNANCE   TRAINING                T
 30   GOVERNANCE   TRAINING                T
 31   GOVERNANCE   TRAINING                T
 32   GOVERNANCE   TRAINING                T
 33   GOVERNANCE   TRAINING                T
 34   GOVERNANCE   TRAINING                T
 35   GOVERNANCE   TRAINING                T
                    Objective
make the plan explicit
build support throughout organization
secure executive buy-in
establish SSDL gates (but do not enforce)
define success
foster transparency (or competition)
change behavior
create broad base of support
make clear who's taking the risk
know where all apps in your inventory stand
create external support
understand compliance drivers (FFIEC, GLBA, OCC, PCI, SOX, SAS 70, HIPAA)
promote privacy
meet regulatory needs or customer demand with a unified approach
promote privacy
ensure accountability for software risk
align practices with compliance
ensure vendors don't screw up compliance
gain executive buy-in
demonstrate compliance story
manage third-party vendors
keep policy aligned with reality
promote culture of security throughout the organization
ensure new hires enhance culture
act as informal resource to leverage teachable moments
create social network tied into dev
build capabilities beyond awareness
see yourself in the problem
keep staff up-to-date and address turnover
reduce impact on training targets and delivery staff
educate/strengthen social network
align security culture with career path
spread security culture to providers
market security culture as differentiator
                                                                           Maturity             Objective-
                                   Activity                                 Level     Item #       code
publish process (roles, responsibilities, plan), evolve as necessary           1         1     SM.1.1
create evangelism role/internal marketing                                      1         2     SM.1.2
educate executives                                                             1         3     SM.1.3
identify gate locations, gather necessary artifacts                            1         4     SM.1.4
identify metrics and drive initiative budgets with them                        1         5     SM.1.5
publish data about software security internally                                2         1     SM.2.1
enforce gates with measures and track exceptions                               2         2     SM.2.2
create or grow social network/satellite system                                 2         3     SM.2.3
require security sign-off                                                      2         4     SM.2.4
use internal tracking application with portfolio view                          3         1     SM.3.1
run external marketing program                                                 3         2     SM.3.2
know all regulatory pressures and unify approach                               1         1     CP.1.1
identify PII obligations                                                       1         2     CP.1.2
create policy                                                                  1         3     CP.1.3
identify PII data in systems (inventory)                                       2         1     CP.2.1
require security sign-off for compliance-related risk                          2         2     CP.2.2
implement/track controls for compliance                                        2         3     CP.2.3
paper all vendor contracts with SLAs compatible with policy                    2         4     CP.2.4
promote executive awareness of compliance/privacy obligations                  2         5     CP.2.5
create regulator eye-candy                                                     3         1     CP.3.1
impose policy on vendors                                                       3         2     CP.3.2
drive feedback from SSDL data back to policy (T: strategy/metrics)             3         3     CP.3.3
provide awareness training                                                     1         1     T.1.1
include security resources in onboarding                                       1         2     T.1.2
establish SSG office hours                                                     1         3     T.1.3
identify satellite during training                                             1         4     T.1.4
offer role-specific advanced curriculum (tools, technology stacks, bug parade) 2         1     T.2.1
create/use material specific to company history                                2         2     T.2.2
require annual refresher                                                       2         3     T.2.3
offer on-demand individual training                                            2         4     T.2.4
hold satellite training/events                                                 2         5     T.2.5
reward progression through curriculum (certification or HR)                    3         1     T.3.1
provide training for vendors or outsource workers                              3         2     T.3.2
host external software security events                                         3         3     T.3.3

                                                                                               ..
                                                    Practice-
row       Domain                 Practice             Code
  2   INTELLIGENCE   ATTACK MODELS                  AM
  3   INTELLIGENCE   ATTACK MODELS                  AM
  4   INTELLIGENCE   ATTACK MODELS                  AM
  5   INTELLIGENCE   ATTACK MODELS                  AM
  6   INTELLIGENCE   ATTACK MODELS                  AM
  7   INTELLIGENCE   ATTACK MODELS                  AM
  8   INTELLIGENCE   ATTACK MODELS                  AM
  9   INTELLIGENCE   ATTACK MODELS                  AM
 10   INTELLIGENCE   ATTACK MODELS                  AM
 11   INTELLIGENCE   ATTACK MODELS                  AM
 12   INTELLIGENCE   SECURITY FEATURES AND DESIGN   SFD
 13   INTELLIGENCE   SECURITY FEATURES AND DESIGN   SFD
 14   INTELLIGENCE   SECURITY FEATURES AND DESIGN   SFD
 15   INTELLIGENCE   SECURITY FEATURES AND DESIGN   SFD
 16   INTELLIGENCE   SECURITY FEATURES AND DESIGN   SFD
 17   INTELLIGENCE   SECURITY FEATURES AND DESIGN   SFD
 18   INTELLIGENCE   SECURITY FEATURES AND DESIGN   SFD
 19   INTELLIGENCE   STANDARDS AND REQUIREMENTS     SR
 20   INTELLIGENCE   STANDARDS AND REQUIREMENTS     SR
 21   INTELLIGENCE   STANDARDS AND REQUIREMENTS     SR
 22   INTELLIGENCE   STANDARDS AND REQUIREMENTS     SR
 23   INTELLIGENCE   STANDARDS AND REQUIREMENTS     SR
 24   INTELLIGENCE   STANDARDS AND REQUIREMENTS     SR
 25   INTELLIGENCE   STANDARDS AND REQUIREMENTS     SR
 26   INTELLIGENCE   STANDARDS AND REQUIREMENTS     SR
 27   INTELLIGENCE   STANDARDS AND REQUIREMENTS     SR
 28   INTELLIGENCE   STANDARDS AND REQUIREMENTS     SR
                       Objective
understand attack basics
prioritize applications by data consumed/manipulated
understand the "who" of attacks
understand the organization's history
provide resources for security testing and AA
understand technology-driven attacks
stay current on attack/vulnerability environment
communicate attacker perspective
get ahead of the attack curve
arm testers and auditors
create proactive security guidance around security features
inject security thinking into architecture group
create proactive security design based on technology stacks
address the need for new architecture
practice reuse
formalize consensus on design
promote design efficiency
meet demand for security features
ensure that everybody knows where to get latest and greatest
compliance strategy
tell people what to look for in code review
educate third-party vendors
formalize standards process
reduce SSG workload
manage open source risk
gain buy-in from legal department and standardize approach
manage open source risk
                                                                 Maturity               Objective-
                             Activity                             Level    Item #         code
build and maintain a top N possible attacks list                    1         1      AM.1.1
create data classification scheme and inventory                     1         2      AM.1.2
identify potential attackers                                        1         3      AM.1.3
collect and publish attack stories                                  1         4      AM.1.4
build attack patterns and abuse cases tied to potential attackers   2         1      AM.2.1
create technology-specific attack patterns                          2         2      AM.2.2
gather attack intelligence                                          2         3      AM.2.3
build internal forum to discuss attacks (T: standards/req)          2         4      AM.2.4
have a science team that develops new attack methods arm testers3and auditors 1      AM.3.1
create and use automation to do what the attackers will do          3         2      AM.3.2
                                                                    1         2      SFD.1.2
build/publish security features (authentication, role management, key management, audit/log, crypto, protocols)
engage SSG with architecture                                        1         2      SFD.1.2
                                                                    2
build secure-by-design middleware frameworks/common libraries (T: code review)2      SFD.2.2
create SSG capability to solve difficult design problems            2         3      SFD.2.3
find/publish mature design patterns from the organization           2         3      SFD.2.3
                                                                    3
form review board or central committee to approve and maintain secure design 3       SFD.3.3
require use of approved security features and frameworks (T: AA) 3            1      SFD.3.1
create security standards (T: sec features/design)                  1         1      SR.1.1
create security portal                                              1         2      SR.1.2
translate compliance constraints to requirements                    1         3      SR.1.3
create secure coding standards                                      1         4      SR.1.4
communicate standards to vendors                                    2         1      SR.2.1
create a standards review board                                     2         2      SR.2.2
create standards for technology stacks                              2         3      SR.2.3
identify open source in apps                                        2         4      SR.2.4
gain buy-in from legal department and standardize approach          2         5      SR.2.5
control open source risk                                            3         1      SR.3.1
                                                                                     ..
                                                                                     ..
                                                                                     ..
                                                 Practice-
row          Domain               Practice        Code
  2   SSDL TOUCHPOINTS   ARCHITECTURE ANALYSIS      AA
  3   SSDL TOUCHPOINTS   ARCHITECTURE ANALYSIS      AA
  4   SSDL TOUCHPOINTS   ARCHITECTURE ANALYSIS      AA
  5   SSDL TOUCHPOINTS   ARCHITECTURE ANALYSIS      AA
  6   SSDL TOUCHPOINTS   ARCHITECTURE ANALYSIS      AA
  7   SSDL TOUCHPOINTS   ARCHITECTURE ANALYSIS      AA
  8   SSDL TOUCHPOINTS   ARCHITECTURE ANALYSIS      AA
  9   SSDL TOUCHPOINTS   ARCHITECTURE ANALYSIS      AA
 10   SSDL TOUCHPOINTS   ARCHITECTURE ANALYSIS      AA
 11   SSDL TOUCHPOINTS   CODE REVIEW                CR
 12   SSDL TOUCHPOINTS   CODE REVIEW                CR
 13   SSDL TOUCHPOINTS   CODE REVIEW                CR
 14   SSDL TOUCHPOINTS   CODE REVIEW                CR
 15   SSDL TOUCHPOINTS   CODE REVIEW                CR
 16   SSDL TOUCHPOINTS   CODE REVIEW                CR
 17   SSDL TOUCHPOINTS   CODE REVIEW                CR
 18   SSDL TOUCHPOINTS   CODE REVIEW                CR
 19   SSDL TOUCHPOINTS   CODE REVIEW                CR
 20   SSDL TOUCHPOINTS   CODE REVIEW                CR
 21   SSDL TOUCHPOINTS   CODE REVIEW                CR
 22   SSDL TOUCHPOINTS   SECURITY TESTING           ST
 23   SSDL TOUCHPOINTS   SECURITY TESTING           ST
 24   SSDL TOUCHPOINTS   SECURITY TESTING           ST
 25   SSDL TOUCHPOINTS   SECURITY TESTING           ST
 26   SSDL TOUCHPOINTS   SECURITY TESTING           ST
 27   SSDL TOUCHPOINTS   SECURITY TESTING           ST
 28   SSDL TOUCHPOINTS   SECURITY TESTING           ST
 29   SSDL TOUCHPOINTS   SECURITY TESTING           ST
 30   SSDL TOUCHPOINTS   SECURITY TESTING           ST
                           Objective
get started with AA
demonstrate value of AA with real data
build internal capability on security architecture
have a lightweight approach to risk classification and prioritization
model objects
promote a common language for describing architecture
build capability organization-wide
build capabilities organization-wide
build proactive security architecture
know which bugs matter to you
review high-risk applications opportunistically
spread software security around without any process
drive efficiency/consistency with automation
drive behavior objectively
find bugs earlier
know which bugs matter (for training)
make most efficient use of tools
drive efficiency/reduce false positives
combine assessment techniques
handle new bug classes in an already scanned codebase
execute adversarial tests beyond functional
facilitate security mindset
use encapsulated attacker perspective
start security testing in familiar functional territory
move beyond functional testing to attacker's perspective
include security testing in regression
teach tools about your code
probe risk claims directly
drive testing depth
                                                                 Maturity            Objective-
                            Activity                              Level      Item #    code
perform security feature review                                      1          1    AA.1.1
perform design review for high-risk applications                     1          2    AA.1.2
have SSG lead review efforts                                         1          3    AA.1.3
use risk questionnaire to rank apps standardize approach using attack1          4    AA.1.4
define/use AA process                                                2          1    AA.2.1
standardize architectural descriptions (include data flow)           2          2    AA.2.2
make SSG available as AA resource/mentor                             2          3    AA.2.3
have software architects lead review efforts                         3          1    AA.3.1
                                                                     3          2
drive analysis results into standard architectural patterns (T: sec features/design) AA.3.2
create top N bugs list (real data preferred) (T: training)           1          1    CR.1.1
have SSG perform ad hoc review                                       1          2    CR.1.2
establish coding labs or office hours focused on review              1          3    CR.1.3
use automated tools along with manual review                         2          1    CR.2.1
enforce coding standards                                             2          2    CR.2.2
make code review mandatory for all projects                          2          3    CR.2.3
                                                                     2          4    CR.2.4
use centralized reporting (close knowledge loop, drive training) (T: strategy/metrics)
assign tool mentors                                                  2          5    CR.2.5
use automated tools with tailored rules                              3          1    CR.3.1
build a factory                                                      3          2    CR.3.2
build capability for eradicating specific bugs from entire codebase3            3    CR.3.3
ensure QA supports edge/boundary value condition testing             1          1    ST.1.1
share security results with QA                                       1          2    ST.1.2
                                                                     2          1
integrate black box security tools into the QA process (including protocol fuzzing) ST.2.1
allow declarative security/security features to drive tests          2          2    ST.2.2
begin to build/apply adversarial security tests (abuse cases)        2          3    ST.2.3
include security tests in QA automation                              3          1    ST.3.1
perform fuzz testing customized to application APIs                  3          2    ST.3.2
drive tests with risk analysis results                               3          3    ST.3.3
leverage coverage analysis                                           3          4    ST.3.4
                                                    Practice-
row         Domain                Practice            Code
  2   DEPLOYMENT     PENETRATION TESTING            PT
  3   DEPLOYMENT     PENETRATION TESTING            PT
  4   DEPLOYMENT     PENETRATION TESTING            PT
  5   DEPLOYMENT     PENETRATION TESTING            PT
  6   DEPLOYMENT     PENETRATION TESTING            PT
  7   DEPLOYMENT     PENETRATION TESTING            PT
  8   DEPLOYMENT     PENETRATION TESTING            PT
  9   DEPLOYMENT     SOFTWARE ENVIRONMENT           SE
 10   DEPLOYMENT     SOFTWARE ENVIRONMENT           SE
 11   DEPLOYMENT     SOFTWARE ENVIRONMENT           SE
 12   DEPLOYMENT     SOFTWARE ENVIRONMENT           SE
 13   DEPLOYMENT     SOFTWARE ENVIRONMENT           SE
 14   DEPLOYMENT     SOFTWARE ENVIRONMENT           SE
                     CONFIGURATION MANAGEMENT AND
15    DEPLOYMENT     VULNERABILITY MANAGEMENT       CMVM
                     CONFIGURATION MANAGEMENT AND
16    DEPLOYMENT     VULNERABILITY MANAGEMENT       CMVM
                     CONFIGURATION MANAGEMENT AND
17    DEPLOYMENT     VULNERABILITY MANAGEMENT       CMVM
                     CONFIGURATION MANAGEMENT AND
18    DEPLOYMENT     VULNERABILITY MANAGEMENT       CMVM
                     CONFIGURATION MANAGEMENT AND
19    DEPLOYMENT     VULNERABILITY MANAGEMENT       CMVM
                     CONFIGURATION MANAGEMENT AND
20    DEPLOYMENT     VULNERABILITY MANAGEMENT       CMVM
                     CONFIGURATION MANAGEMENT AND
21    DEPLOYMENT     VULNERABILITY MANAGEMENT       CMVM
                           Objective
demonstrate that your organization's code needs help too
fix what you find to show real progress
create internal capability
promote deeper analysis
sanity check constantly
keep up with edge of attacker's perspective
automate for efficiency without losing depth
watch software
provide a solid host/network foundation for software
protect IP and make exploit development harder
guide operations on application needs
watch software
protect apps (or parts of apps) that are published over trust boundaries

know what to do when something bad happens

use ops data to change dev behavior

be able to fix apps when they are under direct attack

use ops data to change dev behavior

know where the code is

learn from operational experience

use ops data to change dev behavior
                                                                                 Maturity            Objective-
                                      Activity                                    Level     Item #     code
use external pen testers to find problems                                           1          1     PT.1.1
feed results to defect management/mitigation (T: config/vuln mgmt)                  1          2     PT.1.2
use pen testing tools internally                                                    2          1     PT.2.1
provide pen testers with all available information (T: AA & code review)            2          2     PT.2.2
periodic scheduled pen tests for app coverage                                       2          3     PT.2.3
use external pen testers to perform deep dive (one-off bugs/fresh thinking)         3          1     PT.3.1
have SSG customize pen testing (tools and scripts)                                  3          2     PT.3.2
use application input monitoring                                                    1          1     SE.1.1
ensure host/network security basics in place                                        1          2     SE.1.2
use code protection                                                                 2          1     SE.2.1
publish installation guides created by SSDL                                         2          2     SE.2.2
use application behavior monitoring and diagnostics                                 2          3     SE.2.3
use code signing                                                                    3          1     SE.3.1

create/interface with incident response                                             1         1      CMVM.1.1

identify software bugs found in ops monitoring and feed back to dev                 1         2      CMVM.1.2

have emergency codebase response                                                    2         1      CMVM.2.1

track software bugs found during ops through the fix process                        2         2      CMVM.2.2

develop operations inventory of apps                                                2         3      CMVM.2.3

fix all occurrences of software bugs from ops in the codebase (T: code review)      3         1      CMVM.3.1

enhance dev processes (SSDL) to prevent cause of software bugs found in ops         3         2      CMVM.3.2
                                    Practice-Descrs
row   Domain             Practice

 2    GOVERNANCE         STRATEGY AND METRICS

 3    GOVERNANCE         COMPLIANCE AND POLICY
 4    GOVERNANCE         Training
 5    INTELLIGENCE       ATTACK MODELS
                         SECURITY FEATURES AND
 6    INTELLIGENCE       DESIGN
                         STANDARDS AND
 7    INTELLIGENCE       REQUIREMENTS

 8    SSDL TOUCHPOINTS   ARCHITECTURE ANALYSIS

 9    SSDL TOUCHPOINTS   CODE REVIEW

 10   SSDL TOUCHPOINTS   SECURITY TESTING
 11   DEPLOYMENT         PENETRATION TESTING
                         SOFTWARE
 12   DEPLOYMENT         ENVIRONMENT
                         CONFIGURATION
                         MANAGEMENT AND
                         VULNERABILITY
 13   DEPLOYMENT         MANAGEMENT




                                       Page 32
                                                Practice-Descrs
Purpose
Planning, assigning roles and responsibilities, identifying software security goals, determining
budgets, identifying metrics and gates.
Identifying controls for compliance regimens, developing contractual controls (COTS SLA), setting
organizational policy, auditing against policy.

Threat modeling, abuse cases, data classification, technology-specific attack patterns.

Threat modeling, abuse cases, data classification, technology-specific attack patterns.
Explicit security requirements, recommended COTS, standards for major security controls,
standards for technologies in use, standards review board.
Capturing software architecture diagrams, applying lists of risks and threats, adopting a process for
review, building an assessment and remediation plan.
Use of code review tools, development of customized rules, profiles for tool use by different roles,
manual analysis, ranking/measuring results.
Use of black box security tools in QA, risk driven white box testing, application of the attack model,
code coverage analysis.
Vulnerabilities in final configuration, feeds to defect management and mitigation.
OS and platform patching, Web application firewalls, installation and configuration documentation,
application monitoring, change management, code signing.


Patching and updating applications, version control, defect tracking and remediation, incident
handling.




                                                     Page 33

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:1
posted:10/25/2012
language:English
pages:33