Hello, let us talk about Metric collector and analyzer. My name is Timo Pagl. I'm a Devsecops trainer and strategist. I'm an open source fan and an open knowledge fan boy and I'm a university lecturer. In this talk I will provide you now with an introduction. Afterwards we will take a look at the architecture of Metrica and then we will come to an outlook. I am also the leader of the devsector Ops maturity model and the question first is I say why do you need security maturity models when you want to enhance the security in your area of influence? Then you ask yourself how to enhance the security and there are so many options you have that you need to think about how to prioritize to understand the options. I like to categorize in DevOps strategies. So how do you harden your DevOps processes and technologies? And then the question is how can you enhance your security through DevOps strategies? So how can you utilize the strategies which are already there? For example, you can utilize a build process to integrate security testing there or you're having information gathering maybe with a stack like Prometheus and Grafana which collection the different metrics. So there you just need to adjust the metrics that you're getting alerted when there is security incidents. I regularly perform assessments and these assessments are performed quarterly, yearly or bi yearly. But as a product team I want fast feedback for my performed security activities to stay motivated. So as a product team I want to implement an activity and then get feedback. An example in the area of security testing is the meantime to respond to vulnerabilities. I might have performed very well. Then I want to see it reflected in the feedback. And in case I haven't performed very well, I also want to get notified. Hey, it's currently not going as planned and there are things which we can automate. So the question is how do we automate devsecops assessments? And the solution is Metrica. In Metricca we have manual assessments which we perform in a YAmL structure and automatic assessments where we pull the information from various sources like Jira, other security tools like dependency track, confluence, maybe even from Azure active directory. So there are various tools where we can get information from the metric collector and analyzer. Here you see an overview for it. So on the bottom you have two different or three different YAML files. You have activities per team and per application. So some activities are per application and some activities per team. So when you have for example a security champion per team then this is team based and the activity status is inherited to the applications of that team. You have a one to n relationship here and then you have maturity model definitions. So on which level is a specific activity? What is the threshold for that activity that you say it is performed for an application or it's not performed, that are the information we store in a configuration yaml. But manual assessments have a lag. So for example, when you do thread modeling, you document the thread modeling in your tool, for example in confluence. And afterwards you need to document it again in YAML, or the product owner or the product team needs to document it in the YAML. In addition, there the collector comes into place. The collector automatically collection from various different sources like confluence, in case you document your threat modeling in confluence. And then you maybe have a label on that page called threat modeling. And on the top you have information when did it happen and who the participants and very important, the application id. And then we fetch that information automatically with the collector and afterwards both sources. So with a collector source and the different YAML files are getting analyzed by the analyzer. And then we push that information to Grafana security dashboard. And in Grafana you might be able also to configure alerts, automatically alerts. For example when a threat modeling is missing, you might say I want to perform a threat modeling every quarter and a team hasn't performed it within the last three months. And you can send out a warning, hey, you should very soon perform a quick split modeling so that this process is also automated. Here you see an overview of how product owners or the team can handle the yamls in the repository. So you have a repository and the product owner maybe pulls the repository or uses a web UI to perform changes. So for example, hey, I read all the needed security policies and I confirm it in the YaML file. Then the product owner pushes it. These changes to the repository create the pull request and then a security architect could review these changes, approves or denies it, and then see changes are reflected in case the pull request is accepted. Here we see how the flow is for the thresholds. So there is a trigger, for example the pull request. Then we transfer the meter model information to Java objects. We combine the Yaml files and the collector information. Then we check the threshold for that team in that particular level, for example the mean time to patch. Then we generate dashboards out of it. The dashboards will be already half thresholds which we generate from the Java application. So we want to stay independent from the grafana. We want to be able to put any other option there as well, any other data source, for example the maturity, the devsec option, maturity model itself, or even other sources. This is a very big overview of the architecture. So in GitHub we are building the whole application so that you can utilize it in your organization and with your data. We are also planning to make the architecture very flexible so that you can define, so that you can have your own activity definition. That's why we came up with this class diagram where we have the spring component, the date component and the integer component with an interface. And then the activity has all these different types, so you can combine these types as you like. And in this case, the main developer here is Rafael Vespi, who came up with this diagram and is implementing be very the YAML file should be very generic so that you can have your own activity definitions per application or team. You have the activities YAML and the team YAML and you have the very generic configuration Yaml, which is there only once, in which you define what activities are there and what are the thresholds and what are the levels for these different activities. In the configuration yaml, you have the application id, you have the target level, and then for the activities, the level, in case you have implemented the activity on which level this activity should be performed. And we're currently not having a structure for the threshold, but that will come. Here is an example for the activities YAml. You have again an application id and the different activities. We also want to generate a schema so that when the pull request happens you can, or the product owner can receive there is a mistake in the provided YaML file. I have to say it's not a silver bullet. You always have people and processes. You need to say as a team you still need to perform these activities. You need to put it into the YAML files. So that's all something where you need to do a lot of cultural work. And I recommend to use the collector in the future rather than the YAML. So the yamls are there for static things which you cannot automate easily, but everything you can automate, you should automate with the collection. As you have already mentioned, currently we are in a draft status or the implementation phase. Currently we can perform changes very easily. So in case you have any ideas how to enhance this, please talk with me. Come to the overslack channel, to the DSM channel, or if you like, you can also send an email. Here are my information. The access Switzerland is sponsoring this project and we currently estimate that it will be implemented by the end of 2023. Thank you and see you soon.