├── ComplianceIntegrityTaxonomyPaper-v1.0.pdf ├── ComplianceIntegrityTaxonomyPaper-v1.1.pdf ├── FIRST-IntelligentProcessLifecycle-FINAL.pdf ├── IHK-Präsentation-SteuerungVonITDienstleistern-public.pdf ├── IntelligentProcessLifecycle-Extended-Area41-public.pdf ├── Poster_IntelligentProcessLifecycle_V1.0.pdf ├── Poster_IntelligentProcessLifecycle_V1.1.pdf ├── README.md ├── ResolutionCategories-DetectionFailureReason.json ├── ResolutionCategories-IntegrityComplianceMonitoring.json ├── ResolutionCategories-VulnerabilityDetectionErrors.json ├── ResolutionCategories-VulnerabilityRemediationDelayReason.json └── SCS-CIDailySOCOperations-public.pdf /ComplianceIntegrityTaxonomyPaper-v1.0.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/d3sre/IntelligentProcessLifecycle/b7ec0ba416bf972cd84f27646437e2c02db2c67b/ComplianceIntegrityTaxonomyPaper-v1.0.pdf -------------------------------------------------------------------------------- /ComplianceIntegrityTaxonomyPaper-v1.1.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/d3sre/IntelligentProcessLifecycle/b7ec0ba416bf972cd84f27646437e2c02db2c67b/ComplianceIntegrityTaxonomyPaper-v1.1.pdf -------------------------------------------------------------------------------- /FIRST-IntelligentProcessLifecycle-FINAL.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/d3sre/IntelligentProcessLifecycle/b7ec0ba416bf972cd84f27646437e2c02db2c67b/FIRST-IntelligentProcessLifecycle-FINAL.pdf -------------------------------------------------------------------------------- /IHK-Präsentation-SteuerungVonITDienstleistern-public.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/d3sre/IntelligentProcessLifecycle/b7ec0ba416bf972cd84f27646437e2c02db2c67b/IHK-Präsentation-SteuerungVonITDienstleistern-public.pdf -------------------------------------------------------------------------------- /IntelligentProcessLifecycle-Extended-Area41-public.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/d3sre/IntelligentProcessLifecycle/b7ec0ba416bf972cd84f27646437e2c02db2c67b/IntelligentProcessLifecycle-Extended-Area41-public.pdf -------------------------------------------------------------------------------- /Poster_IntelligentProcessLifecycle_V1.0.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/d3sre/IntelligentProcessLifecycle/b7ec0ba416bf972cd84f27646437e2c02db2c67b/Poster_IntelligentProcessLifecycle_V1.0.pdf -------------------------------------------------------------------------------- /Poster_IntelligentProcessLifecycle_V1.1.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/d3sre/IntelligentProcessLifecycle/b7ec0ba416bf972cd84f27646437e2c02db2c67b/Poster_IntelligentProcessLifecycle_V1.1.pdf -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # IntelligentProcessLifecycle 2 | The Intelligent Process Lifecycle of Active Cyber Defenders 3 | 4 | ## Description 5 | This github hosts the poster related files of false positive and error categories in security operation services. The goal is to define an open source reporting standard for Security Operation Center reports. The hereby published KPIs are focused on creating statistics relevant for continuous improvement of operational cyber defense tasks. 6 | 7 | This information was first presented at FIRST 2020 together with [Eireann Leverett](https://github.com/blackswanburst)(who injected his experience in regards to risk management), the video is available here: https://www.youtube.com/watch?v=pR02cZlPakU 8 | The peer reviewed paper created for this content can be found here: https://dl.acm.org/doi/10.1145/3499427 9 | 10 | The recording of the talk i gave at SwissCyberStorm 2021 about the taxonomy for integrity as well as compliance configuration monitoring can be found here: https://www.youtube.com/watch?v=ra4LZouxIyk 11 | 12 | The recording of the talk I gave at Area41 2022 about the problems in vulnerability management can be found here: https://www.youtube.com/watch?v=qdgY6aAfUAk 13 | 14 | # Quick Overview 15 | Discipline: | Security Monitoring | Configuration Anomalies | Vulnerability Management 16 | :-------------------------- | :-------------------------- |:----------------------------------------------------| :----- | 17 | Validation via: | SIEM Use Cases, EDR /AV Logs, IDS/IPS, NDR Logs | Integrity Monitoring, Compliance Configuration Monitoring | Vulnerability Scans, Patch Verification 18 | Paper published: | [Peer Reviewed Version](https://dl.acm.org/doi/10.1145/3370084) | [Self published paper](https://github.com/d3sre/IntelligentProcessLifecycle/blob/main/ComplianceIntegrityTaxonomyPaper-v1.1.pdf) | [Peer Reviewed Paper](https://dl.acm.org/doi/10.1145/3499427) 19 | Presentation link: | [Hack.Lu 2019 Youtube](https://www.youtube.com/watch?v=NifSKzogSrI) | [SwissCyberStorm 2021 Youtube](https://www.youtube.com/watch?v=ra4LZouxIyk) | [Area41 2022 Youtube](https://www.youtube.com/watch?v=qdgY6aAfUAk) 20 | Slides: | [Hack.Lu 2019 Slides](https://github.com/d3sre/Use_Case_Applicability/blob/master/Hack.lu-FingerpointingPresentation.pdf) | [SwissCyberStorm 2021 Slides](https://github.com/d3sre/IntelligentProcessLifecycle/blob/main/SCS-CIDailySOCOperations-public.pdf) | [Area41 Slides](https://github.com/d3sre/IntelligentProcessLifecycle/blob/main/IntelligentProcessLifecycle-Extended-Area41-public.pdf) 21 | JSON Taxonomy file: | [MISP JSON File Security Monitoring](https://github.com/d3sre/Use_Case_Applicability/blob/master/machinetag.json) | [MISP JSON file Integrity Compliance Monitoring](https://github.com/d3sre/IntelligentProcessLifecycle/blob/main/ResolutionCategories-IntegrityComplianceMonitoring.json) | [MISP JSON file Vuln Mgmt](https://github.com/d3sre/IntelligentProcessLifecycle/blob/main/ResolutionCategories-VulnerabilityDetectionErrors.json) & [MISP JSON file Detection failures](https://github.com/d3sre/IntelligentProcessLifecycle/blob/main/ResolutionCategories-DetectionFailureReason.json) 22 | 23 | 24 | # Continuous Improvement metrics for integrity or technical security compliance monitoring 25 | The following metric suggestions are best correlated with values for system responsible team or source systems type. The target values are in comparison to the total amount of events generated by this service per time unit (month, week, quarter, etc). 26 | KPI | Explanation | Target Value | Owner | Risk Type | Business Impact | Motivating Example 27 | :-------------------------- |:----------------------------------------------------| :----- |:---------- |:----------|:----------------|:----------------| 28 | Number of 'legitimate violations authorized by change' | This value reflects events which usually are classic false positives, where all official change processes were correctly followed but the SOC was not included in the process and therefore could not prevent the false alarm | < 10 % | Compliance | Endogenous | Governance Risk | Officially approved change to Apache changes configuration format, and detection tools alert on the change. 29 | Number of 'configuration errors in baseline' | This value reflects what system configurations (or even configuration templates) needs improvement. | < 10 % | Compliance/ Operational | Endogenous | Change and Compliance Management Risk | The baselines for configuration templates were taken from development instead of production systems. 30 | Number of 'Limitation in verification products' found | If too many of these events were created by configurations, the causing tool should be questioned. | < 5 % | Compliance/ Operational | Endogenous | SOC Operational risk | Snort rules can't be scoped narrowly to detect the change we're interested in, but if they're given wider scope, produce false positives. 31 | Number of 'activities with no change required' | There seems to be a mismatch between the defined security scope and the verified security scope. Gaps should be verified | < 5 % | Policy | Endogenous | Policy-operational mismatch leading to overworked SOC | Sysadmin clears logfiles to save space, which needs no approval, but it triggers an alert in the SOC. 32 | Number of 'unauthorized changes without legitimate cause' | Very high numbers → Security process and IT process integration needs rework; Very low numbers → The configurations aren‘t detecting or you are safe | it depends :) | Policy | Endogenous | Potential intrusion/Prioritise investigation | IIS server has added a user and administrator denies knowledge of event. 33 | Number of changes without formal documentation | Number of legitimate violation with missed change documentation is highlighting where the SOC had no chance of automating false alerts, as well as where employees are not complying to formal processes. | <5% | Policy/Compliance | Endogenous | Shadow IT Administration Risk | Sysadmin changes configuration of Apache server without formal change management documentation (but it would have been approved). 34 | 35 | # Continuous Improvement metrics for vulnerability management 36 | The following metric suggestions are best correlated with values for system responsible team or source systems type. The target values are in comparison to the total amount of events generated by this service per time unit (month, week, quarter, etc). 37 | KPI | Explanation | Target Value | Owner | Risk Type | Business Impact | Motivating Example 38 | :-------------------------- |:----------------------------------------------------|:----- |:---------- |:----------|:----------------|:----------------| 39 | Number of delays due to unreasonable/'Bad SLA' | If this value is high very often, correlated to the applications you are running you might be able to impact either SLA or policy documents | 0 | Operational/ Contractual | Exogenous | Risk Appetite and Contractual Management teams need to match expectations | Network switches only have two change windows a year and don't get patched, but contracts still punish counter party for unpatched systems 40 | Numbers of delays due to 'resource problems' or Average # of days delays due to 'resource problems' | If this happens to often it can illustrate how your staff management is impacting the quality of security services. If occuring too often a risk entry is important | 0 | Contractual | Endogenous/Exogenous | Operational Risk management | Staff resource problems in some teams delay patching 41 | Numbers of installed patch on time | This is the goal. If it can’t be reached too often policies or failing reasons should be reviewed | >80% | Counter-Party/ Contractual | Exogenous | Cyber Risk Expectation isn't being met | 99/100 windows computers are patched on time, but 1 is considered high risk to patch. 42 | 'Context of exploitability not given' count | Very high numbers → You might not be getting honest responses or your threat identification process is faulty | it depends :) | Counter-Party/ Contractual | Exogenous | Potentially Poor Risk Acceptance Practices | The technical engineering team defer every patch as unexploitable to avoid applying resources. 43 | 44 | # Continuous Improvement metrics for Log management 45 | The following metric suggestions are best correlated with values for system responsible team or source systems type. The target values are in comparison to the total amount of events generated by this service per time unit (month, week, quarter, etc). 46 | KPI | Explanation | Target Value | Owner | Risk Type | Business Impact | Motivating Example 47 | :-------------------------- |:----------------------------------------------------|:----- |:---------- |:----------|:----------------|:----------------| 48 | Number of 'blind spots identified' | Any time a detection can not be created this should be tracked, possibly by creating risk entries. | < 5% | Operational/ Contractual | Endogenous/Exogenous | No visibility on the operational risk register | The Active Directory logs cannot be ingested by the SOC because the identity management team doesn't have enough resources. 49 | 50 | 51 | 52 | My other continuous improvement KPIs for security monitoring can be found here: https://github.com/d3sre/Use_Case_Applicability 53 | 54 | 55 | ## Authors and acknowledgment 56 | This poster was created by [Desiree Sacher](http://www.twitter.com/d3sre) with sponsorship for the artwork by layer9solutions.de 57 | 58 | 59 | ## Licence 60 | This poster was published under Creative Commons BY License: https://creativecommons.org/licenses/by/4.0/ 61 | 62 | 63 | -------------------------------------------------------------------------------- /ResolutionCategories-DetectionFailureReason.json: -------------------------------------------------------------------------------- 1 | { 2 | "namespace": "continuousimprovement-detectionfailure-reason", 3 | "expanded": "Continuous Improvement Detection Failure Reasons Resolution Categories", 4 | "description": "The detection failure reasons categories reflect standard resolution categories, to document the reasons why a detection rule can not be created at the time of evaluation. More infos can be found on: https://github.com/d3sre/IntelligentProcessLifecycle", 5 | "version": 1, 6 | "predicates": [ 7 | { 8 | "value": "events-can-not-be-logged", 9 | "expanded": "Events can not be logged", 10 | "description": "It can happen that some vulnerabilities are hard to log directly. This can for example occur when information about a backdoor gets published and the usage of such a backdoor is done in a fashion that is hardly distinguishable from normal usage. In this case it is a good idea to find a close enough approximation by identifying what might be visible before or after exploitation occurred. This can trigger more false positives, implementation therefore should be based on risk levels, and decisions and assumptions reached documented in a technical risk register." 11 | }, 12 | { 13 | "value": "detection-pattern-unclear", 14 | "expanded": "Detection pattern unclear", 15 | "description": "It can happen in an early stage of publication, that it is not well documented how a vulnerability is being exploited. This can especially happen with responsible disclosure where a patch was created by the supplier, but can not be installed due to one of the variety of reasons. It can mean that for creating such a rule, contact to the supplier needs to be initiated in hope of receiving more information. It possible that the information needed will not be forwarded for legal reasons. This situation can be very tricky and ways to resolve this challenge need to be evaluated individually. Usually, the risk of the delayed patch installation needs to be raised and implementation should be prioritized if somehow possible. If this is still not possible, projects to initiate architectural changes to the surrounding setup should be considered. Another cause of this category is analysts being unable to produce detection rules from blog posts about the vulnerability. This encompasses many sub categories ranging from lacking foundational skills in the analyst or inaccuracies in the documentation of the vulnerability and it’s exploitation. There are many resources available with ready-made detection rules, but understanding the implemented detection rules and if needed, adjusting them for the individual usage is key. If this is often the cause of a rule not being implemented, investing in analysts’ skills, and sending them to trainings will be essential." 16 | }, 17 | { 18 | "value": "log-event-ratio-unreasonable", 19 | "expanded": "Log/event ratio unreasonable", 20 | "description": "Detecting some kinds of events it is often argued that to create such logs would cost too much. SOC needs are here valued below operational needs and should be tracked and recorded as such. This is often argued for DNS, netflow logs, or logs created and stored on virtualized endpoints for analysis. These decisions should be documented for each use case and a risk entry should be created for documenting “failure of detection capabilities as log/event ratio not economical”." 21 | }, 22 | { 23 | "value": "resource-problem-detection", 24 | "expanded": "Resource problem detection", 25 | "description": "This can happen when the team is understaffed (chronic problem), or workload is particularly high temporarily (acute problem). Creation of new rules often has less priority in a SOC, as handling daily incidents and vulnerabilities is more critical for the short-term perception by the outside. As having an updated set of use cases is critical though to not only identify current threats to the company, but also employee motivation, this should never be down prioritized for long periods." 26 | }, 27 | { 28 | "value": "logs-can-not-be-delivered", 29 | "expanded": "Logs can not be delivered", 30 | "description": "This information is usually communicated by the respective engineering team. It can happen when logs are not created on site or when the network architecture of your company does not allow the delivery of the needed logs to the SIEM. This problem can not be resolved by the SOC, rather it should be verified by network architects and documented with a risk entry until the delivery situation can be resolved." 31 | }, 32 | { 33 | "value": "resource-problem-delivery", 34 | "expanded": "Resource problem delivery", 35 | "description": "Specific events require specific log settings to be able to detect right actions. If the respective engineering team does not have the resources or different priorities to create the adjustment, it is hard for the SOC to enforce the change. This type of category can either point to heavy workload of the engineering team, or lack of official support for capabilities the SOC needs to do its job. This category therefore is a valuable metric for documenting the dependency of the SOC on the other teams and combined with the information where this occurs most often, measures should be taken to improve the situation. Until the situation is resolved, the incapability to create detection rules based on this dependency should be documented in a risk entry." 36 | }, 37 | { 38 | "value": "no-tool-for-logging", 39 | "expanded": "No tool for logging", 40 | "description":"This is most often a problem for newly built SOCs. This can happen if they for example would rely on process creation events, as usually created by Sysmon or an EDR solution, but such tools have not been enforced yet by security management, or accepted be the respective engineering team. The SOC heavily relies on support by the surrounding teams and lack of detection logs should result in a documented risk entry for acceptance on invisibility on the respective systems. Security management and security architects should evaluate the risk and if reevaluation results in needed changes, support for extending the log coverage should be enforced." 41 | }, 42 | { 43 | "value": "no-process-demand-responsible-for-detection", 44 | "expanded": "No process/demand/responsible for detection", 45 | "description":"This can happen if systems or applications are not built based on official policies, inventory is incomplete or if a loose governance is implemented throughout the company. This is a challenge SOCs often face and can result in excessive amount of time used in trying to identify responsible people. In vulnerability management, where the focus should be set to avoid a critical event or lower the risk of entering into one, it is easy to detect documentation gaps and hard to react to them, because no risk-based vulnerability assessment can actually be performed. For risk-based vulnerability management to be successful, information for every system should be kept on not only what type of system it is, what is running on it, and who is responsible for it, but the whole surrounding setup has to be considered to create an actual risk assessment. To produce this regularly at scale, information about what protection measures are in place to support any software or system inquired, as well as what attack vectors these protection measure consider and where the existing measures currently have their gaps, has to be documented and be made available during the use case assessment process. The gaps identified by the SOC should be put into a fix process and information about missing stakeholders should be forwarded for clarifying the actual need of the implementation of such a detection rule. If no responsible can be found and the system still can not be removed from the network, due to political reasons (for example), a risk entry should at least document knowledge of such a device." 46 | } 47 | ], 48 | } 49 | -------------------------------------------------------------------------------- /ResolutionCategories-IntegrityComplianceMonitoring.json: -------------------------------------------------------------------------------- 1 | { 2 | "namespace": "continuousimprovement-integritycompliance-monitoring", 3 | "expanded": "Continuous Improvement Compliance and Integrity Monitoring Resolution Categories", 4 | "description": "The compliance and integrity categories reflect standard resolution categories, to clearly display what type of alarm was generated with the current compliance or integrity monitoring configuration. The full paper can be found on: https://github.com/d3sre/IntelligentProcessLifecycle/blob/main/ComplianceIntegrityTaxonomyPaper-v1.0.pdf", 5 | "version": 1, 6 | "predicates": [ 7 | { 8 | "value": "legitimate-violation-authorized-by-change", 9 | "expanded": "Legitimate violation authorized by change", 10 | "description": "This type of alert is caused by changes in monitored files (on premises or in the cloud) but 11 | the SOC did not have a direct suppression associated. The update of the baseline configuration file was either not included in the process or was not possible beforehand. This can point to configuration limitation (such as needed updates that cannot be timed or activated time controlled) or process improvements where SOC should be better included. This category requires adjustment to the baseline configuration as a follow-up task to make sure no further false alarm is triggered by the old configuration" 12 | }, 13 | { 14 | "value": "legitimate-violation-with-missed-change-documentation", 15 | "expanded": "Legitimate violation with missed change documentation", 16 | "description": "This category of alerts creates statistical values to illustrate when security and IT processes are not being correctly followed (often caused by human error). These activities are hard to detect otherwise and therefore important to track, report or otherwise communicate to system responsible teams or security/risk management authorities. This category requires adjustment to the baseline configuration as a follow up task." 17 | }, 18 | { 19 | "value": "temporary-configuration-abberation", 20 | "expanded": "Temporary configuration aberration", 21 | "description": "This type of alert is usually unpredictable and important to track as long as the temporary setup is in place. Depending on the amount of time the emergency setup is in place, either the baseline should be adjusted or can be kept. For short amount of times it can make sense to configure a suppression. For longer adjustments, a risk entry could be reasonable." 22 | }, 23 | { 24 | "value": "configuration-error-in-baseline", 25 | "expanded": "Configuration error in baseline", 26 | "description": "This category reflects misconfiguration problems based on bad quality information delivered by the system engineering teams. This information needs to be imported from outside and is usually hard to verify by SOC personnel. It should therefore not be included in SOC KPI values and rather be used to illustrate misconceptions, missing security awareness or missing security knowledge throughout the company." 27 | }, 28 | { 29 | "value": "limitation-in-verification-product", 30 | "expanded": "Limitation in verification product", 31 | "description": "The current product in use for configuration compliance or integrity monitoring is limited in its configuration possibilities and therefore causes bad alerts. This can only be improved by changing the product or applying extensive tricks or workarounds to the setup." 32 | }, 33 | { 34 | "value": "test-alert", 35 | "expanded": "Test alert", 36 | "description": "This alert reflects alerts created for testing purposes. " 37 | }, 38 | { 39 | "value": "unauthorized-change-without-legitimate-cause", 40 | "expanded": "Unauthorized change without legitimate cause", 41 | "description":"This type of resolution usually causes a security incident analysis. It is of important value for threat and risk estimations. The baseline configuration is not adjusted" 42 | }, 43 | { 44 | "value": "activity-with-no-change-documentation-required", 45 | "expanded": "Activity with no change documentation required", 46 | "description":"This category documents alerts that cannot be resolved due to missing documentation and no requirement to document changes on the system or this file type. It can also have resolved alerts, but extended analysis was needed as security policies do not regard these changes as critical. This category comprises of accepted risks, usually regulated by manageability. It can also include changes performed on systems during a penetration test that did not have to be documented by system engineers on a regular basis and therefore could not be otherwise verified. Such documentation gaps need to be verified by security management and possible influence security policy scope" 47 | } 48 | ], 49 | } 50 | -------------------------------------------------------------------------------- /ResolutionCategories-VulnerabilityDetectionErrors.json: -------------------------------------------------------------------------------- 1 | { 2 | "namespace": "continuousimprovement-vulnerability-relevance", 3 | "expanded": "Continuous Improvement Vulnerability Relevance Resolution Categories", 4 | "description": "The vulnerability relevance categories reflect standard resolution categories, to document detection errors where vulnerability scanner identified vulnerability but the responsible technical team clarifies that the vulnerability is not actually a problem. More infos can be found on: https://github.com/d3sre/IntelligentProcessLifecycle", 5 | "version": 1, 6 | "predicates": [ 7 | { 8 | "value": "faulty-vulnerability-verification-process", 9 | "expanded": "Faulty Vulnerability verification process", 10 | "description": "This category shows that the identification of vulnerabilities by your vendor/supplier is faulty or should be optimized. If your vulnerabilities are closed several times by the responsible system engineers with this category you either want to find a better vendor, improve automated detection by using host patch management verification solutions or combining the alerting with technical security compliance verification, or you want to verify your engineer’s judgement capabilities in risk/system assessment." 11 | }, 12 | { 13 | "value": "context-of-exploitability-has-not-been-given", 14 | "expanded": "Context of exploitability has not been given", 15 | "description": "If vulnerabilities are often graded down by other security measures, the identification process and the technical setup should be verified. Even though all vulnerabilities should eventually be patched, this category can point to risks that were accepted at one stage to avoid further assessments. That acceptance has not been recommunicated to the scanning team. Do not scan what you never intend to remediate and document everything you never intend to remediate." 16 | }, 17 | 18 | ], 19 | } 20 | -------------------------------------------------------------------------------- /ResolutionCategories-VulnerabilityRemediationDelayReason.json: -------------------------------------------------------------------------------- 1 | { 2 | "namespace": "continuousimprovement-vulnerabilityremediationdelays", 3 | "expanded": "Continuous Improvement Vulnerability Remediation Delay Resolution Categories", 4 | "description": "The vulnerability remediation delay categories reflect standard resolution categories, to document the reasons why technical engineers are not able to install patches in the required time. More infos can be found on: https://github.com/d3sre/IntelligentProcessLifecycle", 5 | "version": 1, 6 | "predicates": [ 7 | { 8 | "value": "resource-problem", 9 | "expanded": "Resource Problem", 10 | "description": "Low staffing, too many projects or different priorities communicated to the team can lead to too few engineers being able to properly test and roll out the needed updates on time." 11 | }, 12 | { 13 | "value": "compatibility-problem", 14 | "expanded": "Compatibility problem", 15 | "description": "Business products or solutions can rely on fixed dependencies or tight setups which break when installing an update. This can for example happen when a company relies on a product that has long stopped being supported by the vendor or skills to advance your product have left the company." 16 | }, 17 | { 18 | "value": "bad-SLA", 19 | "expanded": "Bad SLA", 20 | "description": "High service level agreement (SLA) KPIs for products, bad service design, bad service management monitoring or combinations of these elements can lead to teams not being allowed to install patches on time. This can appear in change window planning with a team only receiving change windows once a month or less but having patching times of 21 days or less." 21 | }, 22 | { 23 | "value": "support-problem", 24 | "expanded": "Support problem", 25 | "description": "The specific product version installed relies on a software component of another product (for example open source) that has been fixed in the original version, but not yet been updated by vendor you use your product version from. Documenting incurred risks due to bad vendor support should influence strategic choices for partnerships, even if they can’t be fixed short-term. 26 | }, 27 | ], 28 | } 29 | -------------------------------------------------------------------------------- /SCS-CIDailySOCOperations-public.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/d3sre/IntelligentProcessLifecycle/b7ec0ba416bf972cd84f27646437e2c02db2c67b/SCS-CIDailySOCOperations-public.pdf --------------------------------------------------------------------------------