devsecopsmaturitymodel / DevSecOps-MaturityModel

GNU General Public License v3.0
492 stars 288 forks source link

Is this model easily extendable? #35

Closed hectoralicea closed 9 months ago

hectoralicea commented 3 years ago

Is this model easily extendable? for example, in this yaml Implementation.yaml

I would like to add a few additional categories to the metadata, such as implementationApproach as shown below.

  Infrastructure as Code:
    risk: No tracking of changes in systems might lead to errors in the configuration. In additions, it might lead to unauthorized changes. An examples is jenkins.
    measure: Systems are setup by code. A full environment can be provisioned. In addition, software like Jenkins 2 can be setup and configured in in code too. The code should be stored in a version control system.
    difficultyOfImplementation:
      knowledge: 3
      time: 5
      resources: 4
    usefulness: 4
    level: 3
    implementation: GitOps, Ansible, Chef, Puppet, Jenkinsfile
    implementationApproach: ClientX will implement this by using using the Ansible Tower Framework along with Ansible playbooks executed via Jenkins or on the CLI on the build machine.
    samm2: o-environment-management|A|1
    iso27001-2017:
      - not explicitly covered by ISO 27001 - too specific
      - 12.1.1
      - 12.1.2
wurstbrot commented 3 years ago

Hi @hectoralicea, that is possible. In case you open source (at least some of) your additions to the model, I will implement that for you. Deal?

wurstbrot commented 3 years ago

Just to mention, I do understand that you want multiple extra fields. Your "implementationApproach" might allign with the existing field "evidence", see https://github.com/wurstbrot/DevSecOps-MaturityModel#usage.

hectoralicea commented 3 years ago

Hi @hectoralicea, that is possible. In case you open source (at least some of) your additions to the model, I will implement that for you. Deal?

Deal. but, I'm also a developer and am open to making changes myself and submitting a pull request with the changes. Just need some pointers to where in the area of code should go to to review and make proposed changes.

Let me finalize the list.

The even more difficult part will be to be able to edit these new entries from the web app.

wurstbrot commented 3 years ago

The even more difficult part will be to be able to edit these new entries from the web app.

Can you elaborate more your use case?

wurstbrot commented 3 years ago

See https://github.com/wurstbrot/DevSecOps-MaturityModel/pull/36

hectoralicea commented 3 years ago

The even more difficult part will be to be able to edit these new entries from the web app.

Can you elaborate more your use case?

for example, I would like to manipulate the data as such 1.) mark if we have achieved that step, like we can now by clicking on the maturity bullet on this page: http://localhost:81/spiderweb.php 2.) When you click on it perhaps a popup entry box comes up in which you can describe how you met that maturity model. Describe your SOP (standard operating procedure) or technology (e.g. Jenkins, Ansible, etc), free form notes that can be used to capture that info 3.) perhaps add an owner of the process, or an example implementation.

wurstbrot commented 3 years ago

What about this workflow which I am having in mind since a while: Every DSOMM-Activity is in a separate file containing an identifier. e.g.

  Building and testing of artifacts in virtual environments:
    risk: While building and testing artifacts, third party systems, application frameworks
      and 3rd party libraries are used. These might be malicious as a result of vulnerable
      libraries or because they are altered during the delivery phase.
    measure: Each step during within the build and testing phase is performed in a separate virtual
      environments, which is destroyed afterward.
    id: CUHPfdrcUx40X6Kq4U0SGKodFm2VgcqHJt3nyCzTtCyv6AF9ud
    meta: 
      implementationGuide: Depending on your envirnoment, usage of virtual machines or container technoligy is a good way. After the build, the filesystem should not be used again in other builds.
    difficultyOfImplementation:
      knowledge: 2
      time: 2
      resources: 2
    usefulness: 2
    implementation:
      - Container technologies and orchestration like Docker, Kubernetes
      - CI/CD Tools, e.g. Jenkins
    samm2: i-secure-build|A|2
    iso27001-2017:
      - 14.2.6

As a DSOMM-user, I can place a yaml containing the customized information in a folder like data-customized, e.g.

id: CUHPfdrcUx40X6Kq4U0SGKodFm2VgcqHJt3nyCzTtCyv6AF9ud
risk: I do know better how to describe this risk
meta:
  exampleImplementation: Please take a look at https://internal.local/xyz

The final merged result:

  Building and testing of artifacts in virtual environments:
    risk: I do know better how to describe this risk
    measure: Each step during within the build and testing phase is performed in a separate virtual
      environments, which is destroyed afterward.
    id: CUHPfdrcUx40X6Kq4U0SGKodFm2VgcqHJt3nyCzTtCyv6AF9ud
  meta: 
      implementationGuide: Depending on your envirnoment, usage of virtual machines or container technoligy is a good way. After the build, the filesystem should not be used again in other builds.
      exampleImplementation: Please take a look at https://internal.local/xyz
    difficultyOfImplementation:
      knowledge: 2
      time: 2
      resources: 2
    usefulness: 2
    implementation:
      - Container technologies and orchestration like Docker, Kubernetes
      - CI/CD Tools, e.g. Jenkins
    samm2: i-secure-build|A|2
    iso27001-2017:
      - 14.2.6

Modifications are tracked in git, so you get a history of changes.

Folder structure:

data
  dimension
    maturity level
      fileX.yaml
      fileY.yaml
data-customized
  dimension
    maturity level # overrides the level given in data 
      file1.yaml
      file2.yaml
hectoralicea commented 3 years ago

That would work really well. Just to clarify, for the changes tracked in git, we would have to fork the repo and the changes would be saved in our own git repo, right? Just validating.

wurstbrot commented 3 years ago

Not sure if you need a fork, I think about layer container images, placing the data-customized into /var/www/html.

MrNHQ commented 2 years ago

Hello I am looking at the same thing. I would like to add a new sub-dimension under implementation. I created a file under 'data\dimensions-subdimensions-activities\Implementation\Resiliency.yaml'

  Implementation:
    Resiliency:
      Local Redundancy:
        risk:
        - Application is down in case of data center disaster.
        measure: enable local redundancy.
        difficultyOfImplementation:
          knowledge: 1
          time: 1
          resources: 1
        usefulness: 5
        level: 2
      Zone Redundancy:
        risk:
        - Application is down in case of regional disaster.
        measure: enable zone redundancy.
        difficultyOfImplementation:
          knowledge: 1
          time: 1
          resources: 1
        usefulness: 5
        level: 3
      Geo Redundancy:
        risk:
        - Application is down in case of multiple geo disaster.
        measure: enable geo redundancy.
        difficultyOfImplementation:
          knowledge: 2
          time: 2
          resources: 1
        usefulness: 5
        level: 4 

When I look at the result, I can see my new sub dimension in the matrix. However, the spiderweb is messed up (see picture below). Could you tell me the correct way to extend the model? image

MrNHQ commented 2 years ago

Replying to myself: See #103