forked from CloudSecurityAlliance/continuous-audit-metrics
-
Notifications
You must be signed in to change notification settings - Fork 0
/
metrics-catalog.html
1903 lines (1854 loc) · 110 KB
/
metrics-catalog.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<html>
<head>
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin="true">
<link href="https://fonts.googleapis.com/css2?family=Montserrat:wght@400;700&display=swap" rel="stylesheet">
<style>
body {
font-family: "Montserrat", sans-serif;
width: 1250px;
margin-left: auto;
margin-right: auto;
}
.metric {
display: grid;
grid-template-columns: 25% auto;
gap: 5px;
background: #eee;
padding: 10px;
border-radius: 5px;
}
.metric .key {
font-weight: bold;
padding: 12px;
color: white;
}
.metric .value {
padding: 12px;
background: white;
}
.green {
background: #3ba573;
border-left: solid 14px #29895c;
}
.orange {
background: #ff9b1a;
border-left: solid 14px #fa8526;
}
.blue {
background: #0372c7;
border-left: solid 14px #00549e;
}
code {
color: #700;
font-size: 125%;
}
.collapsible {
border-radius: 5px 5px 0 0;
margin-top: 1em;
background-color: #eee;
font-weight: bold;
color: black;
cursor: pointer;
padding: 1em;
width: 100%;
border: none;
text-align: left;
outline: none;
font-size: 125%;
}
.active, .collapsible:hover {
background-color: #aaa;
}
.collapsible:after {
content: "\002B";
color: black;
font-weight: bold;
float: right;
margin-left: 5px;
}
.active:after {
content: "\2212";
}
.content {
padding: 0 18px;
max-height: 0;
overflow: hidden;
transition: max-height 0.2s ease-out;
background-color: #f7f7f7;
border-radius: 0 0 5px 5px;
}
@media print {
.content {
max-height: none;
}
}
</style>
<script>
window.addEventListener("load", (event) => {
const coll = document.querySelectorAll(".collapsible");
coll.forEach(function(item) {
item.addEventListener("click", function() {
this.classList.toggle("active");
let content = this.nextElementSibling;
if (content.style.maxHeight){
content.style.maxHeight = null;
} else {
content.style.maxHeight = content.scrollHeight + "px";
}
});
});
});</script>
</head>
<body>
<h1>Continuous Audit Metrics Catalog, version 1.0.0</h1>
<p>Generated on 2022-09-07 22:55:05 UTC</p>
<div>
<p>This document has been automatically generated from the YAML source file at <a href="https://github.com/cloudsecurityalliance/continuous-audit-metrics/tree/main/data/primary-dataset.yml">https://github.com/cloudsecurityalliance/continuous-audit-metrics/tree/main/data/primary-dataset.yml</a></p>
<p>To make changes to the catalog, please <a href="https://github.com/cloudsecurityalliance/continuous-audit-metrics/edit/main/data/primary-dataset.yml">make changes</a> to the YAML file or <a href="https://github.com/cloudsecurityalliance/continuous-audit-metrics/issues">create an issue</a> on github describing your requested changes.</p>
<p><strong>The content of this repository, including this file, is (c) Cloud Security Alliance, 2022</strong>. See the LICENSE file for details.</p>
<h2>Acknowledgments</h2>
<h3>Authors:</h3>
<ul>
<li>Jonathan Lewis Christopherson </li>
<li>Willy Fabritius</li>
<li>Raj Krishnamurthy</li>
<li>Daniele Catteddu</li>
<li>Kevin Murphy </li>
<li>Alain Pannetrat </li>
<li>Chris Pedigo </li>
<li>Mosi Platt</li>
<li>Max Pritikin (co-chair) </li>
<li>Anthony Scarfe </li>
<li>Carlos Victoria</li>
</ul>
<h3>Contributors:</h3>
<ul>
<li>Christian Banse </li>
<li>Michael Bently </li>
<li>James Condon </li>
<li>John DiMaria </li>
<li>Tinsae Erkailo </li>
<li>Alexandre Higuchi </li>
<li>Michaela Iorga </li>
<li>Amanda King </li>
<li>Julien Mauvieux </li>
<li>Brian Milbier</li>
<li>Dili Origbo</li>
<li>Judy Owen </li>
<li>Massimiliano Rak </li>
<li>Louis Seefried </li>
<li>Jonathan Villa</li>
</ul>
<h2>Context</h2>
<p>The Cloud Security Alliance (CSA) has launched an initiative to create a <a href="https://cloudsecurityalliance.org/research/working-groups/continuous-audit-metrics/">continuous assessment framework for cloud security</a>. As part of that work, CSA is building a <strong>Continuous Audit Metrics Catalog</strong> for the cloud to help organizations assess the security of information systems on a near-continuous basis. </p>
<p>For a detailed description of the context, purpose and terminology used in this work, we refer the reader to sections 1, 2 and 3 of <a href="https://cloudsecurityalliance.org/artifacts/the-continuous-audit-metrics-catalog/">version 1.0 of the continuous audit metrics catalog</a>.</p>
</div>
<div>
<h3>Table of content</h3>
<ul><li><a href="#metric-AIS-05-M1">Metric AIS-05-M1</a></li></ul>
<ul><li><a href="#metric-AIS-05-M2">Metric AIS-05-M2</a></li></ul>
<ul><li><a href="#metric-AIS-05-M3">Metric AIS-05-M3</a></li></ul>
<ul><li><a href="#metric-AIS-06-M1">Metric AIS-06-M1</a></li></ul>
<ul><li><a href="#metric-AIS-07-M3">Metric AIS-07-M3</a></li></ul>
<ul><li><a href="#metric-AIS-07-M6">Metric AIS-07-M6</a></li></ul>
<ul><li><a href="#metric-BCR-06-M1">Metric BCR-06-M1</a></li></ul>
<ul><li><a href="#metric-CCC-03-M1">Metric CCC-03-M1</a></li></ul>
<ul><li><a href="#metric-CCC-07-M1">Metric CCC-07-M1</a></li></ul>
<ul><li><a href="#metric-CEK-03-M2">Metric CEK-03-M2</a></li></ul>
<ul><li><a href="#metric-CEK-04-M1">Metric CEK-04-M1</a></li></ul>
<ul><li><a href="#metric-DCS-06-M1">Metric DCS-06-M1</a></li></ul>
<ul><li><a href="#metric-DSP-04-M2">Metric DSP-04-M2</a></li></ul>
<ul><li><a href="#metric-DSP-04-M3">Metric DSP-04-M3</a></li></ul>
<ul><li><a href="#metric-DSP-05-M1">Metric DSP-05-M1</a></li></ul>
<ul><li><a href="#metric-DSP-05-M2">Metric DSP-05-M2</a></li></ul>
<ul><li><a href="#metric-GRC-04-M1">Metric GRC-04-M1</a></li></ul>
<ul><li><a href="#metric-IAM-07-M1">Metric IAM-07-M1</a></li></ul>
<ul><li><a href="#metric-IAM-08-M2">Metric IAM-08-M2</a></li></ul>
<ul><li><a href="#metric-IAM-09-M1">Metric IAM-09-M1</a></li></ul>
<ul><li><a href="#metric-IPY-03-M2">Metric IPY-03-M2</a></li></ul>
<ul><li><a href="#metric-IVS-04-M1">Metric IVS-04-M1</a></li></ul>
<ul><li><a href="#metric-LOG-03-M1">Metric LOG-03-M1</a></li></ul>
<ul><li><a href="#metric-LOG-05-M1">Metric LOG-05-M1</a></li></ul>
<ul><li><a href="#metric-LOG-10-M1">Metric LOG-10-M1</a></li></ul>
<ul><li><a href="#metric-LOG-13-M2">Metric LOG-13-M2</a></li></ul>
<ul><li><a href="#metric-SEF-05-M1">Metric SEF-05-M1</a></li></ul>
<ul><li><a href="#metric-SEF-06-M1">Metric SEF-06-M1</a></li></ul>
<ul><li><a href="#metric-SEF-06-M2">Metric SEF-06-M2</a></li></ul>
<ul><li><a href="#metric-STA-07-M3">Metric STA-07-M3</a></li></ul>
<ul><li><a href="#metric-STA-07-M5">Metric STA-07-M5</a></li></ul>
<ul><li><a href="#metric-TVM-03-M1">Metric TVM-03-M1</a></li></ul>
<ul><li><a href="#metric-TVM-07-M1">Metric TVM-07-M1</a></li></ul>
<ul><li><a href="#metric-TVM-10-M1">Metric TVM-10-M1</a></li></ul>
<ul><li><a href="#metric-UEM-04-M1">Metric UEM-04-M1</a></li></ul>
<ul><li><a href="#metric-UEM-05-M1">Metric UEM-05-M1</a></li></ul>
<ul><li><a href="#metric-UEM-09-M1">Metric UEM-09-M1</a></li></ul>
<ul><li><a href="#metric-BCR-08-M1">Metric BCR-08-M1</a></li></ul>
<ul><li><a href="#metric-BCR-08-M2">Metric BCR-08-M2</a></li></ul>
</div>
<h2 id="metric-AIS-05-M1">Metric AIS-05-M1</h2>
<div class="metric">
<div class="key green">Primary CCMv4 Control ID</div>
<div class="value">AIS-05</div>
<div class="key green">Primary Control Description</div>
<div class="value">Implement a testing strategy, including criteria for acceptance of
new information systems, upgrades and new versions, which provides application
security assurance and maintains compliance while enabling organizational speed
of delivery goals. Automate when applicable and possible.
</div>
<div class="key green">Related CCMv4 Control IDs</div>
<div class="value"></div>
<div class="key orange">Metric ID</div>
<div class="value"><strong>AIS-05-M1</strong></div>
<div class="key orange">Metric Description</div>
<div class="value">This metric measures the percentage of running production code that passed static application security testing.</div>
<div class="key orange">Expression</div>
<div class="value">
<div>Formula: <code>(A/B)*100</code>
</div>
<p>Where: <ul>
<li>
<code>A</code>: Total number of units of production code that have successfully passed static application security testing.<ul><li>ID: prod_apps_with_sast</li></ul>
</li>
<li>
<code>B</code>: Total number of units of code that are deployed in production.<ul><li>ID: prod_apps_deployed</li></ul>
</li>
</ul></p>
</div>
<div class="key orange">Rules</div>
<div class="value">
<p><strong>Production Code</strong> is code deployed to the production runtime environment(s)
within the scope of the Information Security Program defined in the CCMv4 GRC-05
control objective. A static application security test of a unit of code is
considered <strong>successfully passed</strong> if:</p>
<ul>
<li>the testing tools are defined by the organization's security policy.</li>
<li>the testing tools follow the organization's minimum coverage requirements.</li>
<li>the testing tools are up-to-date and reflect industry best practices.</li>
<li>the testing tools do not report any issues, with the exception of issues that
have been accepted by the organization (i.e. false-positives or accepted risks).</li>
</ul>
</div>
<div class="key orange">Sampling period</div>
<div class="value">None</div>
<div class="key blue">SLO Recommendation</div>
<div class="value"><div>Minimum: 100%</div></div>
</div>
<button class="collapsible">Implementation guidelines</button><div class="content">
<p>See implementaionGuidelines for AIS-06-M1.</p>
</div>
<h2 id="metric-AIS-05-M2">Metric AIS-05-M2</h2>
<div class="metric">
<div class="key green">Primary CCMv4 Control ID</div>
<div class="value">AIS-05</div>
<div class="key green">Primary Control Description</div>
<div class="value">Implement a testing strategy, including criteria for acceptance of
new information systems, upgrades and new versions, which provides application
security assurance and maintains compliance while enabling organizational speed
of delivery goals. Automate when applicable and possible.
</div>
<div class="key green">Related CCMv4 Control IDs</div>
<div class="value"></div>
<div class="key orange">Metric ID</div>
<div class="value"><strong>AIS-05-M2</strong></div>
<div class="key orange">Metric Description</div>
<div class="value">This metric measures the percentage of running production code that has been tested to show that it adheres to its desired behavior or specification.</div>
<div class="key orange">Expression</div>
<div class="value">
<div>Formula: <code>(A/B)*100</code>
</div>
<p>Where: <ul>
<li>
<code>A</code>: Total number of units of production code that have successfully been tested to show that they adhere to their desired behavior or specification.<ul><li>ID: prod_apps_with_testing</li></ul>
</li>
<li>
<code>B</code>: Total number of units of code that are deployed in production.<ul><li>ID: prod_apps_deployed</li></ul>
</li>
</ul></p>
</div>
<div class="key orange">Rules</div>
<div class="value">
<p><strong>Production Code</strong> is code deployed to the production runtime environment(s)
within the scope of the Information Security Program defined in the CCMv4 GRC-05
control objective.
Testing may be applied at the unit, system, integration or functional level, or any
combination thereof. Testing requirements and coberage should be be pre-defined in
the organization's software development policy. </p>
</div>
<div class="key orange">Sampling period</div>
<div class="value">None</div>
<div class="key blue">SLO Recommendation</div>
<div class="value"><div>Minimum: 100%</div></div>
</div>
<button class="collapsible">Implementation guidelines</button><div class="content">
<p>Software bugs in code represent an opportunity for the introduction of security
vulnerabilities. The goal of this metric is to measure how extensively code is
tested in order to reduce the likelyhood of introducing such vulnerabilities.
See implementaionGuidelines for AIS-06-M1.</p>
</div>
<h2 id="metric-AIS-05-M3">Metric AIS-05-M3</h2>
<div class="metric">
<div class="key green">Primary CCMv4 Control ID</div>
<div class="value">AIS-05</div>
<div class="key green">Primary Control Description</div>
<div class="value">Implement a testing strategy, including criteria for acceptance of
new information systems, upgrades and new versions, which provides application
security assurance and maintains compliance while enabling organizational speed
of delivery goals. Automate when applicable and possible.
</div>
<div class="key green">Related CCMv4 Control IDs</div>
<div class="value"></div>
<div class="key orange">Metric ID</div>
<div class="value"><strong>AIS-05-M3</strong></div>
<div class="key orange">Metric Description</div>
<div class="value">This metric measures the percentage of running production applications that have passed dynamic application security testing.</div>
<div class="key orange">Expression</div>
<div class="value">
<div>Formula: <code>(A/B)*100</code>
</div>
<p>Where: <ul>
<li>
<code>A</code>: Total number of production applications that have successfully passed static application security testing.<ul><li>ID: prod_apps_with_dast</li></ul>
</li>
<li>
<code>B</code>: Total number of deployed applications in production.<ul><li>ID: prod_apps_deployed_integrated</li></ul>
</li>
</ul></p>
</div>
<div class="key orange">Rules</div>
<div class="value">
<p><strong>Production Code</strong> is code deployed to the production runtime environment(s)
within the scope of the Information Security Program defined in the CCMv4 GRC-05
control objective.
A dynamic application security test is considered <strong>successfully passed</strong> if:</p>
<ul>
<li>the testing tools are defined by the organization's security policy.</li>
<li>the testing tools follow the organization's minimum coverage requirements.</li>
<li>the testing tools are up-to-date and reflect industry best practices.</li>
<li>the testing tools do not report any issues, with the exception of issues that
have been accepted by the organization (i.e. false-positives or accepted risks).</li>
</ul>
</div>
<div class="key orange">Sampling period</div>
<div class="value">None</div>
<div class="key blue">SLO Recommendation</div>
<div class="value"><div>Minimum: 100%</div></div>
</div>
<button class="collapsible">Implementation guidelines</button><div class="content">
<p>See implementaionGuidelines for AIS-06-M1.</p>
</div>
<h2 id="metric-AIS-06-M1">Metric AIS-06-M1</h2>
<div class="metric">
<div class="key green">Primary CCMv4 Control ID</div>
<div class="value">AIS-06</div>
<div class="key green">Primary Control Description</div>
<div class="value">Establish and implement strategies and capabilities for secure, standardized,
and compliant application deployment. Automate where possible.
</div>
<div class="key green">Related CCMv4 Control IDs</div>
<div class="value">DCS-06, GRC-05</div>
<div class="key orange">Metric ID</div>
<div class="value"><strong>AIS-06-M1</strong></div>
<div class="key orange">Metric Description</div>
<div class="value">This metric measures the percentage of running production code that can be directly traced back to automated security and quality tests that verify the compliance of each build.</div>
<div class="key orange">Expression</div>
<div class="value">
<div>Formula: <code>(A/B)*100</code>
</div>
<p>Where: <ul>
<li>
<code>A</code>: Total number of pieces of Production Code that have an Associated Verification Step<ul><li>ID: prod_apps_with_verification</li></ul>
</li>
<li>
<code>B</code>: Total number of pieces of Production Code<ul><li>ID: prod_apps_deployed</li></ul>
</li>
</ul></p>
</div>
<div class="key orange">Rules</div>
<div class="value">
<p><strong>Production Code</strong> is code deployed to the production runtime environment(s)
within the scope of the Information Security Program defined in the CCMv4 GRC-05
control objective. An <strong>Associated Verification Step</strong> is a capability in the
deployment process that ties production code back to a build with traceable results
for quality, security, and privacy tests.</p>
</div>
<div class="key orange">Sampling period</div>
<div class="value">30 days</div>
<div class="key blue">SLO Recommendation</div>
<div class="value"><div>Minimum: 95%</div></div>
</div>
<button class="collapsible">Implementation guidelines</button><div class="content">
<p>There must be a Software Inventory of Deployed Production Code (DCS-06). Production code must be quantified based on the definition of deployed code running in production (e.g. microservices, builds, releases, packages, libraries, serverless functions, etc.). This should be the same number used to measure AIS-07. The definition of <strong>deployed production code</strong> used for the software inventory should be aligned with application security scanning, testing, and/or reporting methods where possible to simplify measurement. The likelihood of standardized deployments can decrease as the number of different deployment systems increases. If the Software Deployment Pipeline has multiple stages where change could be introduced, and end-to-end validation cannot be performed, then the metric <strong>Percentage of steps in the Software Deployment Pipeline that have an associated verification step</strong> may be more suitable for an organization. There should be a mechanism to identify deviations, and if deviations from the standard are approved, then the system should account for (and manage) the exception as approved. This metric should at least be aligned with an organization's development or release cycle to provide timely input for correction in the next deployment or release. For example, if an organization uses an Agile development methodology with two-week sprints, then the metric should be measured at least every two weeks to provide data for review at sprint retros.</p>
</div>
<button class="collapsible">Audit guidelines</button><div class="content">
<p>this is the audit guideline for AIS-06-M1</p>
</div>
<h2 id="metric-AIS-07-M3">Metric AIS-07-M3</h2>
<div class="metric">
<div class="key green">Primary CCMv4 Control ID</div>
<div class="value">AIS-07</div>
<div class="key green">Primary Control Description</div>
<div class="value">Define and implement a process to remediate application security
vulnerabilities, automating remediation when possible.
</div>
<div class="key green">Related CCMv4 Control IDs</div>
<div class="value">AIS-02, AIS-06, TVM-07, DCS-06</div>
<div class="key orange">Metric ID</div>
<div class="value"><strong>AIS-07-M3</strong></div>
<div class="key orange">Metric Description</div>
<div class="value">This metric measures the coverage for application vulnerability remediation across the production code.</div>
<div class="key orange">Expression</div>
<div class="value">
<div>Formula: <code>(A/B)*100</code>
</div>
<p>Where: <ul>
<li>
<code>A</code>: Number of deployed production applications with acceptable level of risk from application security vulnerabilities<ul><li>ID: prod_apps_deployed_with_acceptable_vuls</li></ul>
</li>
<li>
<code>B</code>: Total Number of deployed production applications<ul><li>ID: prod_apps_deployed</li></ul>
</li>
</ul></p>
</div>
<div class="key orange">Rules</div>
<div class="value">
<p>Production Application = Applications tracked within the software inventory established in CCMv4 DCS-06. Acceptable level of risk from application security vulnerabilities: Vulnerabilities categorized as medium or low risk as well as critical or high vulnerabilities marked or identified as \'Accepted\' (i.e. remediation not required). Examples of accepted vulnerabilities can be false positives or vulnerabilities with compensating controls that make the residual risk of exploitation acceptable.</p>
</div>
<div class="key orange">Sampling period</div>
<div class="value">30 days</div>
<div class="key blue">SLO Recommendation</div>
<div class="value"><div>Minimum: 80%</div></div>
</div>
<button class="collapsible">Implementation guidelines</button><div class="content">
<p>There must be a Software Inventory of Deployed Production Code (see DCS-06 for more info). Production code must be quantified based on the organization's definition of deployed code running in production (e.g. microservices, builds, releases, packages, libraries, serverless functions, etc.). This should be the same number used to measure AIS-06. The definition of deployed production application used for the software inventory should be aligned with application security scanning, testing, and/or reporting methods where possible to simplify measurement. Acceptable Level of Risk should be defined by the organizations vulnerability management guidelines (e.g. only Critical and High vulnerabilities, or Medium Vulnerabilities and Higher, etc. Classification of vulnerabilities as High or Critical risk, etc. should be defined in the Vulnerability Management tool based on industry-accepted scoring system such as the Common Vulnerability Scoring System (CVSS) (<a href="https://nvd.nist.gov/vuln-metrics/cvss">https://nvd.nist.gov/vuln-metrics/cvss</a>). For instance, vulnerabilities with a CVSS score of 9 or higher are Critical, and vulnerabilities with CVSS scores between 7 and 9 could be defined as High risk.)</p>
</div>
<h2 id="metric-AIS-07-M6">Metric AIS-07-M6</h2>
<div class="metric">
<div class="key green">Primary CCMv4 Control ID</div>
<div class="value">AIS-07</div>
<div class="key green">Primary Control Description</div>
<div class="value">Define and implement a process to remediate application security
vulnerabilities, automating remediation when possible.
</div>
<div class="key green">Related CCMv4 Control IDs</div>
<div class="value">AIS-03, TVM-10, GRC-02</div>
<div class="key orange">Metric ID</div>
<div class="value"><strong>AIS-07-M6</strong></div>
<div class="key orange">Metric Description</div>
<div class="value">This metric measures the percentage of critical vulnerabilities that are not fixed or marked as accepted within the time specified by policy.</div>
<div class="key orange">Expression</div>
<div class="value">
<div>Formula: <code>(A/B)*100</code>
</div>
<p>Where: <ul>
<li>
<code>A</code>: Number of unaccepted critical or high vulnerabilities in production applications with an age greater than the policy defined maximum age<ul><li>ID: nc_vuln_remediation_in_prod_apps</li></ul>
</li>
<li>
<code>B</code>: Total number of critical or high vulnerabilities in production applications within this period<ul><li>ID: risky_vulns_in_prod_apps</li></ul>
</li>
</ul></p>
</div>
<div class="key orange">Rules</div>
<div class="value">
<p>Production Application = Applications tracked within the software inventory established in CCMv4 DCS-06. Acceptable level of risk from application security vulnerabilities: Vulnerabilities categorized as medium or low risk as well as critical or high vulnerabilities marked or identified as Accepted (i.e. remediation not required). Examples of accepted vulnerabilities can be false positives or vulnerabilities with compensating controls that make the residual risk of exploitation acceptable.</p>
</div>
<div class="key orange">Sampling period</div>
<div class="value">30 days</div>
<div class="key blue">SLO Recommendation</div>
<div class="value"></div>
</div>
<button class="collapsible">Implementation guidelines</button><div class="content">
<ol>
<li>Classification of vulnerabilities as High or Critical risk should be defined in the Vulnerability Management tool based on industry-accepted scoring system such as the Common Vulnerability Scoring System (CVSS) (<a href="https://nvd.nist.gov/vuln-metrics/cvss">https://nvd.nist.gov/vuln-metrics/cvss</a>). For instance, vulnerabilities with a CVSS score of 9 or higher are Critical, and vulnerabilities with CVSS scores between 7 and 9 could be defined as High risk. </li>
<li>Date and time of vulnerability discovery could be obtained from the Vulnerability Management tool as it scans and detects vulnerabilities. </li>
<li>Date and time of vulnerability remediation or acceptance could be obtained in the following ways:
<ul>
<li>From the Vulnerability Management tool as it scans and finds that a previously detected vulnerability is no longer present/detected; </li>
<li>From the patch deployment tool (e.g. SCCM) as it successfully deploys and installs a patch that fixes an identified vulnerability; </li>
<li>From the application / code release tool as it moves into production the new version of the application that no longer contains the code vulnerability.</li>
</ul>
</li>
</ol>
<p>Frequency of evaluation should be aligned with the frequency of vulnerability scans. (Scans should happen at LEAST monthly, but more frequently is recommended).</p>
<p>Vulnerability scans can be done at a predefined frequency or whenever new code is built, or deployed.</p>
</div>
<h2 id="metric-BCR-06-M1">Metric BCR-06-M1</h2>
<div class="metric">
<div class="key green">Primary CCMv4 Control ID</div>
<div class="value">BCR-06</div>
<div class="key green">Primary Control Description</div>
<div class="value">Exercise and test business continuity and operational resilience
plans at least annually or upon significant changes.
</div>
<div class="key green">Related CCMv4 Control IDs</div>
<div class="value">BCR-01, BCR-02</div>
<div class="key orange">Metric ID</div>
<div class="value"><strong>BCR-06-M1</strong></div>
<div class="key orange">Metric Description</div>
<div class="value">This metric reports the percentage of critical systems that passed BCR tests.</div>
<div class="key orange">Expression</div>
<div class="value">
<div>Formula: <code>(A/B)*100</code>
</div>
<p>Where: <ul>
<li>
<code>A</code>: Number of critical systems that passed BCR tests during the sampling period<ul><li>ID: bcr_tests_critical_systems</li></ul>
</li>
<li>
<code>B</code>: Total number of critical systems operating during the sampling period<ul><li>ID: critical_systems_count</li></ul>
</li>
</ul></p>
</div>
<div class="key orange">Rules</div>
<div class="value">
<p>Criteria for system criticality must be defined and there must be a list of critical systems identified. Recovery Point Objective(s) and Recovery Time Objective(s) must be defined for critical systems. This metric does not attempt to measure the appropriateness of the recovery point or time objectives (RPOs or RTOs). This metric is dependent on control BCR-02 providing reasonable assurance of sufficient RPOs and RTOs for critical systems. BCR testing intervals must be defined.</p>
</div>
<div class="key orange">Sampling period</div>
<div class="value">365 days</div>
<div class="key blue">SLO Recommendation</div>
<div class="value"><div>Minimum: 80%</div></div>
</div>
<button class="collapsible">Implementation guidelines</button><div class="content">
<p>Critical systems should be identified in accordance with the CCMv4 implementation guidelines for BCR-02. For this metric, passed means achieving the RPO(s) within the RTO(s) defined for each critical system in the scope of the assessment/audit, according to the CCMv4 implementation guidelines for BCR-02. The sampling period for this metric should align with the testing intervals defined by the business continuity plan in accordance with the CCMv4 implementation guidelines for BCR-04. BCR tests should include Chaos Testing, where possible. According to wikipedia, Chaos engineering is the discipline of experimenting on a software system in production in order to build confidence in the system's capability to withstand turbulent and unexpected conditions.</p>
</div>
<h2 id="metric-CCC-03-M1">Metric CCC-03-M1</h2>
<div class="metric">
<div class="key green">Primary CCMv4 Control ID</div>
<div class="value">CCC-03</div>
<div class="key green">Primary Control Description</div>
<div class="value">Manage the risks associated with applying changes to organization
assets, including application, systems, infrastructure, configuration, etc.,
regardless of whether the assets are managed internally or externally (i.e.,
outsourced).
</div>
<div class="key green">Related CCMv4 Control IDs</div>
<div class="value">DCS-06</div>
<div class="key orange">Metric ID</div>
<div class="value"><strong>CCC-03-M1</strong></div>
<div class="key orange">Metric Description</div>
<div class="value">Percentage of all assets that have change management technology integrated</div>
<div class="key orange">Expression</div>
<div class="value">
<div>Formula: <code>(A/B)*100</code>
</div>
<p>Where: <ul>
<li>
<code>A</code>: Number of assets that have change management technology integrated<ul><li>ID: assets_under_change_management</li></ul>
</li>
<li>
<code>B</code>: Total number of assets<ul><li>ID: total_assets_count</li></ul>
</li>
</ul></p>
</div>
<div class="key orange">Rules</div>
<div class="value">
<p>Change management technology covers release management tools that enable automated deployment and rollback of software builds in production.</p>
</div>
<div class="key orange">Sampling period</div>
<div class="value">30 days</div>
<div class="key blue">SLO Recommendation</div>
<div class="value"><div>Minimum: 80%</div></div>
</div>
<button class="collapsible">Implementation guidelines</button><div class="content">
<p>This metric requires the implementation of CCMv4 DCS-06 Asset Cataloging and Tracking and the capability to determine which assets or asset groups are deployed using change management technology that can rollback changes and/or stop deployment of risky changes based on automated test results. Given the dynamic nature of cloud environments, the metric can provide more value if the variations in the release management system's coverage over the population of assets is reported over time. The percentage of assets that fall within an accepted number of deviations provides stakeholders assurance of whether change control is getting better, worse, or being maintained. Larger populations of more than 1,000 assets can use 6 standard deviations as an acceptable level of change over time (i.e. Six Sigma). Smaller populations of assets will need to use less standard deviations as an acceptable level of change, perhaps even just 1 deviation. For more information on the use of standard deviation in security metrics, see this excerpt of Andrew Jaquith's Security Metrics book.</p>
</div>
<h2 id="metric-CCC-07-M1">Metric CCC-07-M1</h2>
<div class="metric">
<div class="key green">Primary CCMv4 Control ID</div>
<div class="value">CCC-07</div>
<div class="key green">Primary Control Description</div>
<div class="value">Implement detection measures with proactive notification in case
of changes deviating from the established baseline.
</div>
<div class="key green">Related CCMv4 Control IDs</div>
<div class="value">DCS-06, CCC-03</div>
<div class="key orange">Metric ID</div>
<div class="value"><strong>CCC-07-M1</strong></div>
<div class="key orange">Metric Description</div>
<div class="value">This metric measures the percent of positive test results from all configuration tests performed.</div>
<div class="key orange">Expression</div>
<div class="value">
<div>Formula: <code>(A/B)*100</code>
</div>
<p>Where: <ul>
<li>
<code>A</code>: Number of configuration items that were tested and passed successfully<ul><li>ID: config_items_passing_tests</li></ul>
</li>
<li>
<code>B</code>: Total number of configuration items that were tested<ul><li>ID: total_config_items</li></ul>
</li>
</ul></p>
</div>
<div class="key orange">Rules</div>
<div class="value">
<p>This metric captures the number of tests passed out of the total number of tests defined. Each test is assumed to verify a configuration item which is arbitrarily defined as any component for which a test can be defined.</p>
</div>
<div class="key orange">Sampling period</div>
<div class="value">7 days</div>
<div class="key blue">SLO Recommendation</div>
<div class="value"><div>Minimum: 95%</div></div>
</div>
<button class="collapsible">Implementation guidelines</button><div class="content">
<p>This metric assumes that CCC-03 has been successfully implemented and thus assumes that enough configuration items, at least in terms of number of CCMv4 DCS-06 assets, have change management technology to make this metric meaningful. This metric does not take into account a measure of risk for the configuration tests that have failed. The resulting flat percentage may not tell the full story of risk incurred from a control failure. Future work may incorporate risk measures such as high and critical configuration tests. The frequency of reporting this metric should tie in to the frequency of deployments/expected changes, minimally once a week. This metric should be measured on an automated, continuous basis. Since the scope is under the control of the organization, the metric results should be relatively high. The signal from this metric is that the existing system for change management is working or failing. A low percentage may not indicate a significant cybersecurity risk, but it may be a leading indicator of future security risk if the practice doesn't improve. This is different than IVS-04 which measures the number of hardening tests against all assets.</p>
</div>
<h2 id="metric-CEK-03-M2">Metric CEK-03-M2</h2>
<div class="metric">
<div class="key green">Primary CCMv4 Control ID</div>
<div class="value">CEK-03</div>
<div class="key green">Primary Control Description</div>
<div class="value">Provide cryptographic protection to data at-rest and in-transit,
using cryptographic libraries certified to approved standards.
</div>
<div class="key green">Related CCMv4 Control IDs</div>
<div class="value">CEK-04, DCS-06, CEK-01</div>
<div class="key orange">Metric ID</div>
<div class="value"><strong>CEK-03-M2</strong></div>
<div class="key orange">Metric Description</div>
<div class="value">This metric measures if the cryptographic module continues to be up to approved standards.</div>
<div class="key orange">Expression</div>
<div class="value">
<div>Formula: <code>(A/B)*100</code>
</div>
<p>Where: <ul>
<li>
<code>A</code>: Number of assets responsible for data at-rest or in-transit where the cryptographic library has passed Automated Cryptographic Validation Protocol tests or equivalent tests<ul><li>ID: acvp_approved_data_assets</li></ul>
</li>
<li>
<code>B</code>: Total number of assets responsible for data at-rest or in-transit<ul><li>ID: data_at_rest_in_transit_assets</li></ul>
</li>
</ul></p>
</div>
<div class="key orange">Rules</div>
<div class="value"></div>
<div class="key orange">Sampling period</div>
<div class="value">30 days</div>
<div class="key blue">SLO Recommendation</div>
<div class="value"><div>Minimum: 85%</div></div>
</div>
<button class="collapsible">Implementation guidelines</button><div class="content">
<p>This leverages asset management and off-the-shelf automated functionalities while allowing for flexibility against policy (which has previously passed CCMv4 CEK-01 audit). See AVCP: <a href="https://csrc.nist.gov/Projects/Automated-Cryptographic-Validation-Testing">https://csrc.nist.gov/Projects/Automated-Cryptographic-Validation-Testing</a></p>
</div>
<h2 id="metric-CEK-04-M1">Metric CEK-04-M1</h2>
<div class="metric">
<div class="key green">Primary CCMv4 Control ID</div>
<div class="value">CEK-04</div>
<div class="key green">Primary Control Description</div>
<div class="value">Use encryption algorithms that are appropriate for data protection,
considering the classification of data, associated risks, and usability of the
encryption technology.
</div>
<div class="key green">Related CCMv4 Control IDs</div>
<div class="value">CEK-05</div>
<div class="key orange">Metric ID</div>
<div class="value"><strong>CEK-04-M1</strong></div>
<div class="key orange">Metric Description</div>
<div class="value">This metric measures the percentage of assets with cryptographic functions that meet an organization's defined cryptographic requirements.</div>
<div class="key orange">Expression</div>
<div class="value">
<div>Formula: <code>(A/B)*100</code>
</div>
<p>Where: <ul>
<li>
<code>A</code>: Number of assets with a cryptographic function that meets cryptographic requirements<ul><li>ID: compliant_crypto_assets</li></ul>
</li>
<li>
<code>B</code>: Total number of assets with a cryptographic function<ul><li>ID: total_crypto_assets</li></ul>
</li>
</ul></p>
</div>
<div class="key orange">Rules</div>
<div class="value">
<p>The specification should be reported for all the adopted cryptographic suites.</p>
</div>
<div class="key orange">Sampling period</div>
<div class="value">30 days</div>
<div class="key blue">SLO Recommendation</div>
<div class="value"><div>Minimum: 90%</div></div>
</div>
<button class="collapsible">Implementation guidelines</button><div class="content">
<p>For a Minimum Viable Product, the scope of evaluation may be limited to public-facing services, in which case a scan of all externally facing assets should be made and the scanned values compared against the requirements of the policy. The SLO used for this metric may need to be increased or decreased based on the scope of assets covered by the metric. This metric depends on the data classification tool in CCMv4 DSP-03, and requires that an organization determine the appropriate level of encryption for each classification, then requires comparison of the expected encryption applied versus the actual encryption applied, and reports on the difference. CCMv4 IPY-03 covers a subset of this measurement.</p>
</div>
<h2 id="metric-DCS-06-M1">Metric DCS-06-M1</h2>
<div class="metric">
<div class="key green">Primary CCMv4 Control ID</div>
<div class="value">DCS-06</div>
<div class="key green">Primary Control Description</div>
<div class="value">Catalogue and track all relevant physical and logical assets located
at all of the CSP's sites within a secured system.
</div>
<div class="key green">Related CCMv4 Control IDs</div>
<div class="value">LOG-05</div>
<div class="key orange">Metric ID</div>
<div class="value"><strong>DCS-06-M1</strong></div>
<div class="key orange">Metric Description</div>
<div class="value">This metric measures the ratio of managed assets (i.e. catalogued and tracked) to detected assets. The goal is to provide a signal if the asset cataloging and tracking system stops working.</div>
<div class="key orange">Expression</div>
<div class="value">
<div>Formula: <code>(A/B)*100</code>
</div>
<p>Where: <ul>
<li>
<code>A</code>: Number of distinct assets seen in security audit logs during the sampling period that are in an asset catalog<ul></ul>
</li>
<li>
<code>B</code>: Number of distinct assets seen in security audit logs during the sampling period<ul></ul>
</li>
</ul></p>
</div>
<div class="key orange">Rules</div>
<div class="value">
<p>The assumption is that the design of the DCS-06 control process(es) was found to be effective by internal or external audits.</p>
</div>
<div class="key orange">Sampling period</div>
<div class="value">1 day</div>
<div class="key blue">SLO Recommendation</div>
<div class="value"><div>Minimum: 95%</div></div>
</div>
<button class="collapsible">Implementation guidelines</button><div class="content">
<p>This relies on the security audit logs as defined in CCMv4 LOG-05 and the asset catalog defined in CCMv4 DCS-06. This assumes LOG-05 is inclusive of logs of a number of events such as network traffic, network scanning, physical asset inventory. It assumes that the logs include network traffic logging, and logs from other assets, and are sufficient to detect unexpected assets. We assume everything that is worthy is logged. This is a dependency on the auditor to ensure the logging is complete enough. This is consistent with the metric for UEM-04. Implementers may benefit from the similarities. Any 3rd party CSPs used by the organization where shared responsibility of controls resides in the organization should be included as logical assets for this catalog. This is likely dependent on the maturity of STA-01 - STA-06 and the SSRM. For example if a CSP provides a microservice inherent in the operations of an offering that microservice is a logical asset. This ensures that metrics where DCS numbers are used in the denominator include those micro-services. This is intended to ensure the coverage is accurate and inclusive of 3rd party CSPs where the organization is responsible for the controls.</p>
</div>
<h2 id="metric-DSP-04-M2">Metric DSP-04-M2</h2>
<div class="metric">
<div class="key green">Primary CCMv4 Control ID</div>
<div class="value">DSP-04</div>
<div class="key green">Primary Control Description</div>
<div class="value">Classify data according to its type and sensitivity level.
</div>
<div class="key green">Related CCMv4 Control IDs</div>
<div class="value">DSP-01, DSP-03, DSP-04, DSP-05</div>
<div class="key orange">Metric ID</div>
<div class="value"><strong>DSP-04-M2</strong></div>
<div class="key orange">Metric Description</div>
<div class="value">This metric measures the ratio of data assets that have been classified according to data classification policies specific to each organization. An organization may have a predefined list of data types (e.g. health care record, payment card record, identification number, etc.) and / or data sensitivity levels (e.g. Confidential, Internal Use Only, Public).</div>
<div class="key orange">Expression</div>
<div class="value">
<div>Formula: <code>(A/B)*100</code>
</div>
<p>Where: <ul>
<li>
<code>A</code>: Total number of data records classified by type and/or sensitivity<ul></ul>
</li>
<li>
<code>B</code>: Total number of data records stored<ul></ul>
</li>
</ul></p>
</div>
<div class="key orange">Rules</div>
<div class="value">
<p>Total number of records classified by type and/or sensitivity - this is a count of all data assets that have a defined classification by type or sensitivity level (Undefined classifications are not counted for this variable). Total number of records stored - this is a count of all data assets that have been collected and are stored in the system such as DSP-03. This metric measures data in terms of distinct data records, not distinct data types.</p>
</div>
<div class="key orange">Sampling period</div>
<div class="value">30 days</div>
<div class="key blue">SLO Recommendation</div>
<div class="value"><div>Minimum: 99%</div></div>
</div>
<button class="collapsible">Implementation guidelines</button><div class="content">
<p>All data records must have corresponding metadata related to its data type and / or sensitivity. A defined list of data types and sensitivity levels must be defined. Records that do not meet any of the data classification types or sensitivity levels will have an undefined classification and are not considered as classified for this metric.</p>
</div>
<h2 id="metric-DSP-04-M3">Metric DSP-04-M3</h2>
<div class="metric">
<div class="key green">Primary CCMv4 Control ID</div>
<div class="value">DSP-04</div>
<div class="key green">Primary Control Description</div>
<div class="value">Classify data according to its type and sensitivity level.
</div>
<div class="key green">Related CCMv4 Control IDs</div>
<div class="value">DSP-01, DSP-03, DSP-04, DSP-05, DCS-06</div>
<div class="key orange">Metric ID</div>
<div class="value"><strong>DSP-04-M3</strong></div>
<div class="key orange">Metric Description</div>
<div class="value">This metric measures the ratio of assets in the asset catalog that have been classified according to data classification policies specific to each organization. An organization may have a predefined list of data types (e.g. health care record, payment card record, identification number, etc.) and / or data sensitivity levels (e.g. Confidential, Internal Use Only, Public).</div>
<div class="key orange">Expression</div>
<div class="value">
<div>Formula: <code>(A/B)*100</code>
</div>
<p>Where: <ul>
<li>
<code>A</code>: Total number of assets in the asset catalog that are classified by type and/or sensitivity of the data on that asset<ul></ul>
</li>
<li>
<code>B</code>: Total number of assets in the organization's asset catalog<ul></ul>
</li>
</ul></p>
</div>
<div class="key orange">Rules</div>
<div class="value">
<p>Total number of assets classified by type and/or sensitivity of the data contained on the asset - this is a count of all assets that have a defined classification by type or sensitivity level (Undefined classifications are not counted for this variable). Total number of assets - this is a count of all assets that have been collected and are stored in the system such as DSC-06.</p>
</div>
<div class="key orange">Sampling period</div>
<div class="value">30 days</div>
<div class="key blue">SLO Recommendation</div>
<div class="value"><div>Minimum: 99%</div></div>
</div>
<button class="collapsible">Implementation guidelines</button><div class="content">
<p>All asset records must have corresponding metadata related to the type and / or sensitivity of data stored on the asset. A defined list of data types and sensitivity levels must be defined. Assets that do not contain data of the data classification types or sensitivity levels will have an undefined data classification and are not considered as classified for this metric.</p>
</div>
<h2 id="metric-DSP-05-M1">Metric DSP-05-M1</h2>
<div class="metric">
<div class="key green">Primary CCMv4 Control ID</div>
<div class="value">DSP-05</div>
<div class="key green">Primary Control Description</div>
<div class="value">Create data flow documentation to identify what data is processed,
stored or transmitted where. Review data flow documentation at defined intervals,
at least annually, and after any change.
</div>
<div class="key green">Related CCMv4 Control IDs</div>
<div class="value">DSP-03</div>
<div class="key orange">Metric ID</div>
<div class="value"><strong>DSP-05-M1</strong></div>
<div class="key orange">Metric Description</div>
<div class="value">This metric measures the percentage of records from the data inventory required by control DSP-03 (CCMv4) that are included in data flow documentation. Cloud service providers and their stakeholders can use this metric to determine whether the volume of data covered by the data flow documentation is sufficient or needs to be updated to satisfy defined business requirements.</div>
<div class="key orange">Expression</div>
<div class="value">
<div>Formula: <code>(A/B)*100</code>
</div>
<p>Where: <ul>
<li>
<code>A</code>: Number of data records or data stores from the CCMv4 DSP-03 inventory correctly included in the data flow documentation<ul></ul>
</li>
<li>
<code>B</code>: Total number of data records or data stores in the CCMv4 DSP-03 inventory<ul></ul>
</li>
</ul></p>
</div>
<div class="key orange">Rules</div>
<div class="value">
<p>This metric can be measured by counting the number of records in a data store or by simply counting the data stores themselves. CORRECTLY INCLUDED means that the data record or data store is represented in the data flow documentation in accordance with the organization's defined requirements for representing inventories in the documentation. Generally, this means it exists in the documentation and is properly labeled with appropriate CCMv4 DSP-04 classifications if appropriate. Note: The CCMv4 DSP-03 control objective is to Create and maintain a data inventory, at least for any sensitive data and personal data. The CCMv4 DSP-04 control objective is to Classify data according to its type and sensitivity level.</p>
</div>
<div class="key orange">Sampling period</div>
<div class="value">15 days</div>
<div class="key blue">SLO Recommendation</div>
<div class="value"><div>Minimum: 80%</div></div>
</div>
<button class="collapsible">Implementation guidelines</button><div class="content">
<p>This metric supports an incomplete DSP-03 inventory so long as it is a statistically significant random sampling of at least any sensitive data and personal data (e.g. meets the DSP-03 control language objective). This metric makes the assumption that the data flow diagram(s) is available in a machine-readable format but does not measure automated creation of the data inventory or the data flow documentation. The generation of the data flow document MAY be manual although the result MUST be digitized in order to perform automated comparisons against discovered data repositories. This metric assumes the data flow documentation is in the form of a graph with nodes and edges where data stores are nodes in that graph. In order to count the number of records, there needs to be metadata with the number of records for each datastore. It measures the percentage of data stores (and their records) that are correctly captured as nodes in the graph. For reference, a data flow inventory similar to DSP-03 is required by CSA GDPR Code of Conduct Control</p>
</div>
<h2 id="metric-DSP-05-M2">Metric DSP-05-M2</h2>
<div class="metric">
<div class="key green">Primary CCMv4 Control ID</div>
<div class="value">DSP-05</div>
<div class="key green">Primary Control Description</div>
<div class="value">Create data flow documentation to identify what data is processed,
stored or transmitted where. Review data flow documentation at defined intervals,
at least annually, and after any change.
</div>
<div class="key green">Related CCMv4 Control IDs</div>
<div class="value"></div>
<div class="key orange">Metric ID</div>
<div class="value"><strong>DSP-05-M2</strong></div>
<div class="key orange">Metric Description</div>
<div class="value">This metric measures the percentage of data streams from the data inventory required by control DSP-03 (CCMv4) that are included in the data flow documentation. Cloud service providers and their stakeholders can use a metric like this to determine whether the different uses of data covered by the data flow documentation is sufficient or needs to be updated to satisfy defined business requirements.</div>
<div class="key orange">Expression</div>
<div class="value">
<div>Formula: <code>(A/B)*100</code>
</div>
<p>Where: <ul>
<li>
<code>A</code>: Number of data streams from the CCMv4 DSP-03 inventory correctly included in the data flow documentation<ul></ul>
</li>
<li>
<code>B</code>: Total number of data streams in the CCMv4 DSP-03 inventory<ul></ul>
</li>
</ul></p>
</div>
<div class="key orange">Rules</div>
<div class="value">
<p>Data streams are the connections from data sources to data consumers illustrated in data flow diagrams. These connections should be included in the data inventory required by control DSP-03 (CCMv4). This may be a complete inventory of all data streams or a reasonable sample of data streams.</p>
</div>
<div class="key orange">Sampling period</div>
<div class="value">15 days</div>
<div class="key blue">SLO Recommendation</div>
<div class="value"><div>Minimum: 80%</div></div>
</div>
<button class="collapsible">Implementation guidelines</button><div class="content">
<p>This metric supports an incomplete inventory of data streams so long as it is a reasonable sampling of streams for at least any sensitive data and personal data (e.g. is intended to measure flows of data of the types that meet the DSP-03 control language objective regarding data inventories). Sampled data streams should be captured from live data streams of user and system activities. This metric assumes the data flow documentation is available in a machine-readable format. The generation of the data flow document MAY be manual although the result MUST be digitized in order to perform automated comparisons against discovered data flows. For reference, a data flow inventory similar to DSP-03 is required by CSA GDPR Code of Conduct Control</p>
</div>
<h2 id="metric-GRC-04-M1">Metric GRC-04-M1</h2>
<div class="metric">
<div class="key green">Primary CCMv4 Control ID</div>
<div class="value">GRC-04</div>
<div class="key green">Primary Control Description</div>
<div class="value">Establish and follow an approved exception process as mandated by
the governance program whenever a deviation from an established policy occurs.
</div>
<div class="key green">Related CCMv4 Control IDs</div>
<div class="value">AIS-07</div>
<div class="key orange">Metric ID</div>
<div class="value"><strong>GRC-04-M1</strong></div>
<div class="key orange">Metric Description</div>
<div class="value">This metric measures the effectiveness of the governance program's exception handling process.</div>
<div class="key orange">Expression</div>
<div class="value">
<div>Formula: <code>(A/B)*100</code>
</div>
<p>Where: <ul>
<li>
<code>A</code>: Number of active policy exceptions where the time to resolution is within the documented timeline for resolution, during the sampling period<ul></ul>
</li>
<li>
<code>B</code>: Total number of active policy exceptions, during the sampling period<ul></ul>
</li>
</ul></p>
</div>
<div class="key orange">Rules</div>
<div class="value">
<p>An Exception Policy must be defined and must cover the entire lifecycle of an exception. Active policy exceptions that happen during the sampling period but which are not resolved yet are counted in B, not A.</p>
</div>
<div class="key orange">Sampling period</div>
<div class="value">30 days</div>
<div class="key blue">SLO Recommendation</div>
<div class="value"><div>Minimum: 90%</div></div>
</div>
<button class="collapsible">Implementation guidelines</button><div class="content">
<p>This metric requires organizations to maintain records of policy exceptions that include the approval date and resolution date for calculation of mean time to resolution. The records could be as simple as entries in a spreadsheet or as complex as records for exception tracking in a GRC or vulnerability management system. This metric also requires organizations to define the threshold(s) for acceptable resolution time(s). The definition could be as simple as a statement in a policy document that applies to all exceptions, or individually-defined target dates for resolution of each exception based on risk. In the case of the latter, the requirements for setting the target resolution date(s) should be established in a policy and the target date(s) will need to be tracked in the policy exception records. For example if there is a ticketing system for remediation this tracks if the close date for the ticket was met. If an org has very few exceptions then slipping on even one will dramatically affect their percentage. This is inherent in statistics and is not seen as a problem for now.</p>
</div>
<h2 id="metric-IAM-07-M1">Metric IAM-07-M1</h2>
<div class="metric">
<div class="key green">Primary CCMv4 Control ID</div>
<div class="value">IAM-07</div>
<div class="key green">Primary Control Description</div>
<div class="value">De-provision or respectively modify access of movers / leavers or
system identity changes in a timely manner in order to effectively adopt and
communicate identity and access management policies.
</div>
<div class="key green">Related CCMv4 Control IDs</div>
<div class="value">IAM-03, IAM-06, IAM-10</div>
<div class="key orange">Metric ID</div>
<div class="value"><strong>IAM-07-M1</strong></div>
<div class="key orange">Metric Description</div>
<div class="value">This metric measures the percentage of users leaving the organization that were de-provisioned from the identity management system in compliance with the identity and access management policies.</div>
<div class="key orange">Expression</div>
<div class="value">
<div>Formula: <code>(A/B)*100</code>
</div>
<p>Where: <ul>
<li>
<code>A</code>: Number of terminated users deprovisioned within policy guidelines during the sampling period<ul></ul>
</li>
<li>
<code>B</code>: Total number of terminated users during the sampling period<ul></ul>
</li>
</ul></p>
</div>
<div class="key orange">Rules</div>
<div class="value">
<p>The time lapse between a user's termination and account deactivation must be measured in seconds. The time lapse between user's termination and account deactivation = time stamp of account deactivation event - time stamp of employee termination or role change event recorded in the HR system.</p>
</div>
<div class="key orange">Sampling period</div>
<div class="value">30 days</div>
<div class="key blue">SLO Recommendation</div>
<div class="value"><div>Minimum: 99%</div></div>
</div>
<button class="collapsible">Implementation guidelines</button><div class="content">
<p>Steps to compute this may look like: </p>
<ol>
<li>Account deactivation timestamps can be obtained from the identity management system. </li>
<li>Employee termination or change event timestamps can be obtained from the Human Capital Information System (e.g. Workday). </li>
<li>Count of [(User De-Provisioning date - User Termination Date) > Policy Duration)]/Total Number of Terminated Users for the period). This metric only evaluates termination/deprovisioning events as an indicator of efficacy. It does not measure job role change, which can be captured in IAM-08. The recommended sampling period for this metric is monthly, but cloud service providers should ensure the sampling period aligns and frequency of evaluation align with their rate of change and risk tolerance.</li>
</ol>
</div>
<h2 id="metric-IAM-08-M2">Metric IAM-08-M2</h2>
<div class="metric">
<div class="key green">Primary CCMv4 Control ID</div>
<div class="value">IAM-08</div>
<div class="key green">Primary Control Description</div>
<div class="value">Review and revalidate user access for least privilege and separation
of duties with a frequency that is commensurate with organizational risk tolerance.
</div>
<div class="key green">Related CCMv4 Control IDs</div>
<div class="value">IAM-03, IAM-05, IAM-06, IAM-10</div>
<div class="key orange">Metric ID</div>
<div class="value"><strong>IAM-08-M2</strong></div>
<div class="key orange">Metric Description</div>
<div class="value">This metric measures the time elapsed since the last recertification for all types of privileges (including user roles, group memberships, read/write/execute permissions to files/databases/scripts/jobs, etc). The metric returns the longest time identified. For example, if the longest time elapsed for a recertification of a privilege is 95 days. The metric will return this number. The value returned should not be greater than the frequency of privilege recertification or review defined in the organization policies.</div>
<div class="key orange">Expression</div>
<div class="value">
<div>Formula: <code>(A/B)*100</code>
</div>
<p>Where: <ul>
<li>
<code>A</code>: Number of accounts reviewed with correct access in the Last 90 Days<ul></ul>
</li>
<li>
<code>B</code>: Total number of Accounts<ul></ul>
</li>
</ul></p>
</div>
<div class="key orange">Rules</div>
<div class="value">
<p>Date of last Recertification is the date and time that a privilege was reviewed and recertified in the most recent recertification. If a Date of last recertification does not exist, this should be replaced with the Date a privilege was granted or an account was created.</p>
</div>
<div class="key orange">Sampling period</div>
<div class="value">30 days</div>