Cleaned up Literature folder

Corpus/Literature/Jaquith - Security Metrics/Jaquith_2007_1_Defining_Security_Metrics.md

@@ -0,0 +1,46 @@
+# Defining Security Metrics
+
+A metric is a consistent standard for measurement.
+
+Business leaders will ask the following:
+- How effective are my security processes?
+- Am I better off than I was this time last year?
+- How do I compare with my peers?
+- Am I spending the right amount of money?
+- What are my risk transfer options?
+
+Therefore, Good metrics:
+- Incorporate measures of time or money
+- Are well understood across the company
+- Are well understood across industries and are consistently measured. That means they lend themselves to benchmarking
+- Are calculated mechanically and can be gathered in an automated way
+
+Differently put, good metrics:
+1. are simple to explain and straightforward to calculate, clear and unambiguous. Their transparency facilitates adoption by management. 
+2. are all expressed in terms of time, money, or a measure derived from these. 
+3. readily lend themselves to benchmarking.
+
+A good metric should be
+- Consistently measured, without subjective criteria – Different people should be able to apply the method to the same data set and come up with equivalent answers.
+- Cheap to gather, preferably in an automated way 
+- Expressed as a cardinal number or percentage, not with qualitative labels like “high,” “medium,” and “low”
+- Expressed using at least one unit of measure, such as “defects,”“hours,” or “dollars” – making it easier to compare.
+
+A good metric should also ideally be Contextually specific: relevant enough (and informative enough) to decision-makers so that they can take action.
+
+“Traffic light” inputs (red-yellow-green) are not metrics at all. They contain neither a unit of measure nor a numerical scale. Traffic lights colors can be used, sparingly, as a presentation strategy to supplement numerical data or draw attention to outliers.
+
+Metrics ought to be computed at a frequency commensurate with the process’s rate of change. For most security processes “often” is better than “sometimes.”
+
+## Reservations toward ISO 17799
+My reservations about using the ISO as a metrics framework:
+- ISO 17799 portrays information security controls as things to be assessed, selected, and implemented. But it makes almost no practical recommendations about how to manage, monitor, and measure the effectiveness of these controls.
+- The recommendations are never firm; interpretation is an exercise left to the reader
+- Insufficient attention to measurement
+
+## Reservations toward Annualized Loss Expectancy
+Security events are low frequency and high severity. That makes them hard to model.
+ALE is security’s spherical cow. It encourages practitioners to think about dollar impact on an aggregate, averaged basis, in spite of the fact that losses do not gravitate to the middle; they cluster on the far edges.
+Second, practitioners of ALE suffer from a near-complete inability to reliably estimate probabilities or losses. The same is true for loss estimation.
+The third strike against ALE relates to the lack of probability-and-loss data.
+The real tragedy of ALE: it’s really just a funny little model that anyone can game for his or her own purposes.

Corpus/Literature/Jaquith - Security Metrics/Jaquith_2007_2_Diagnosing_Problems_and_Measuring_Technical_Security.md

@@ -0,0 +1,43 @@
+# Diagnosing Problems and Measuring Technical Security
+
+Using Metrics to Diagnose Problems: A Case Study 41
+Defining Diagnostic Metrics 44
+Perimeter Security and Threats 46
+	E-mail 49
+	Antivirus and Antispam 50
+	Firewall and Network Perimeter 50
+	Attacks 51
+Coverage and Control 52
+	Antivirus and Antispyware 58
+	Patch Management 59
+	Host Configuration 62
+	Vulnerability Management 65
+Availability and Reliability 68
+	Uptime 69
+	System Recovery 71
+	Change Control 72
+Application Security 73
+	Black-Box Defect Metrics 75
+	Qualitative Process Metrics and Indices 77
+	Code Security Metrics 83
+Summary
+
+
+In security, metrics help organizations:
+- Understand security risks
+- Spot emerging problems
+- Understand weaknesses in their security infrastructures
+- Measure performance of countermeasure processes
+- Recommend technology and process improvements
+
+## Defining Diagnostic Metrics
+
+Diagnostic metrics are used to assess security posture, diagnose issues, and measure security activities associated with infrastructure.
+
+This chapter focuses on technical metrics that quantify each of the following:
+- Perimeter defenses
+- Coverage and control
+- Availability and reliability
+- Application risks
+
+A large number of organizations and industry initiatives have begun creating metrics lists, notably the Corporate Information Security Working Group (CISWG), NIST, ISSEA, US CERT, and my own initiative, securitymetrics.org.

Corpus/Literature/Jaquith - Security Metrics/Jaquith_2007_3_Measuring_Program_Effectiveness.md

@@ -0,0 +1,24 @@
+# Measuring Program Effectiveness
+
+Using COBIT, ITIL, and Security Frameworks 91
+	Frameworks 91
+	Not Useful: Asset Valuation 95
+Planning and Organization 98
+	Assessing Risk 99
+	Human Resources 101
+	Managing Investments 102
+Acquisition and Implementation 104
+	Identifying Solutions 104
+	Installing and Accrediting Solutions 107
+	Developing and Maintaining Procedures 111
+Delivery and Support 112
+	Educating and Training Users 114
+	Ensuring System Security 117
+	Identifying and Allocating Costs 120
+	Managing Data 122
+	Managing Third-Party Services 123
+Monitoring 126
+	Monitoring the Process 127
+	Monitoring and Evaluating Internal Controls 128
+	Ensuring Regulatory Compliance 129
+Summary 130

Corpus/Literature/Jaquith - Security Metrics/Security Metrics by Andrew Jaquith 2007.md

@@ -0,0 +1,14 @@
+[Defining Security Metrics](Jaquith_2007_1_Defining_Security_Metrics.md)
+[Diagnosing Problems and Measuring Technical Security](Jaquith_2007_2_Diagnosing_Problems_and_Measuring_Technical_Security.md)
+[Measuring Program Effectiveness](Jaquith_2007_3_Measuring_Program_Effectiveness.md)
+
+
+## Shift Left: Relative Cost to Correct Security Defects, by Stage
+
+Stage | Relative Cost
+--- | ---
+Design | 1.0
+Implementation | 6.5
+Testing | 15.0
+Maintenance | 100.0
+

Corpus/Literature/Jaquith - Security Metrics/Security Metrics that Count – for Twilio.md

@@ -0,0 +1,19 @@
+# Security Metrics that Count
+
+Harini Rangarajan of Twilio (a customer engagement platform) has published a [blogpost](https://www.twilio.com/blog/security-metrics-count) on 30-11-2021 called 'Security Metrics that Count'.
+
+They found (by using metrics!) that different audience groups within Twilio were interested in different kinds of security metrics:
+- Executive-level leadership wanted to understand the security posture across the organization
+- VPs wanted to understand the security posture of their specific business units
+- Product managers wanted to understand the security posture of their products
+- Engineering managers wanted to understand how many open vulnerabilities were present and which ones their teams should prioritize fixing.
+
+They distinguish metrics that capture the 'health' of the organization (security wise) and metrics that capture the maturity of the security program. These metrics are shown in a table in the blogpost.
+
+To establish the current security posture of their products, they added extra fields to their (development) ticket managing system Jira for Vulnerability Category, Vulnerability Source and Business Unit.
+They then used this data to generate dashboards for different audiences.
+
+Related:
+- [[MyVault/👩🏼‍⚖️ Standards and Regulations/ISO 27001 2013/ISO 27001 C 9 Performance evaluation#9 1 Monitoring measurement analysis and evaluation]]
+- [ISO 27001 A 12.4 Logging and monitoring](../../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%2012.4%20Logging%20and%20monitoring.md)
+