bin/xml/U_MS_SQL_Server_2014_Database_STIG_V1R6_Manual-xccdf.xml

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
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
<?xml version="1.0" encoding="utf-8"?><?xml-stylesheet type='text/xsl' href='STIG_unclass.xsl'?><Benchmark xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:cpe="http://cpe.mitre.org/language/2.0" xmlns:xhtml="http://www.w3.org/1999/xhtml" xmlns:dc="http://purl.org/dc/elements/1.1/" id="MS_SQL_Server_2014_Database_STIG" xml:lang="en" xsi:schemaLocation="http://checklists.nist.gov/xccdf/1.1 http://nvd.nist.gov/schema/xccdf-1.1.4.xsd http://cpe.mitre.org/dictionary/2.0 http://cpe.mitre.org/files/cpe-dictionary_2.1.xsd" xmlns="http://checklists.nist.gov/xccdf/1.1"><status date="2017-12-01">accepted</status><title>MS SQL Server 2014 Database Security Technical Implementation Guide</title><description>This Security Technical Implementation Guide is published as a tool to improve the security of Department of Defense (DoD) information systems. The requirements are derived from the National Institute of Standards and Technology (NIST) 800-53 and related documents. Comments or proposed revisions to this document should be sent via e-mail to the following address: disa.stig_spt@mail.mil.</description><notice id="terms-of-use" xml:lang="en"></notice><reference href="http://iase.disa.mil"><dc:publisher>DISA</dc:publisher><dc:source>STIG.DOD.MIL</dc:source></reference><plain-text id="release-info">Release: 6 Benchmark Date: 26 Jan 2018</plain-text><version>1</version><Profile id="MAC-1_Classified"><title>I - Mission Critical Classified</title><description>&lt;ProfileDescription&gt;&lt;/ProfileDescription&gt;</description><select idref="V-67357" selected="true" /><select idref="V-67359" selected="true" /><select idref="V-67361" selected="true" /><select idref="V-67365" selected="true" /><select idref="V-67367" selected="true" /><select idref="V-67369" selected="true" /><select idref="V-67371" selected="true" /><select idref="V-67373" selected="true" /><select idref="V-67375" selected="true" /><select idref="V-67377" selected="true" /><select idref="V-67381" selected="true" /><select idref="V-67383" selected="true" /><select idref="V-67385" selected="true" /><select idref="V-67389" selected="true" /><select idref="V-67391" selected="true" /><select idref="V-67393" selected="true" /><select idref="V-67395" selected="true" /><select idref="V-67397" selected="true" /><select idref="V-67399" selected="true" /><select idref="V-67401" selected="true" /><select idref="V-67403" selected="true" /><select idref="V-67405" selected="true" /><select idref="V-67407" selected="true" /><select idref="V-67409" selected="true" /><select idref="V-67411" selected="true" /><select idref="V-67413" selected="true" /><select idref="V-67415" selected="true" /><select idref="V-67417" selected="true" /><select idref="V-67419" selected="true" /><select idref="V-67421" selected="true" /><select idref="V-67423" selected="true" /><select idref="V-67425" selected="true" /><select idref="V-67427" selected="true" /><select idref="V-67429" selected="true" /><select idref="V-67431" selected="true" /><select idref="V-67433" selected="true" /><select idref="V-67435" selected="true" /><select idref="V-67437" selected="true" /><select idref="V-67439" selected="true" /><select idref="V-67441" selected="true" /><select idref="V-67443" selected="true" /><select idref="V-67877" selected="true" /></Profile><Profile id="MAC-1_Public"><title>I - Mission Critical Public</title><description>&lt;ProfileDescription&gt;&lt;/ProfileDescription&gt;</description><select idref="V-67357" selected="true" /><select idref="V-67359" selected="true" /><select idref="V-67361" selected="true" /><select idref="V-67365" selected="true" /><select idref="V-67367" selected="true" /><select idref="V-67369" selected="true" /><select idref="V-67371" selected="true" /><select idref="V-67373" selected="true" /><select idref="V-67375" selected="true" /><select idref="V-67377" selected="true" /><select idref="V-67381" selected="true" /><select idref="V-67383" selected="true" /><select idref="V-67385" selected="true" /><select idref="V-67389" selected="true" /><select idref="V-67391" selected="true" /><select idref="V-67393" selected="true" /><select idref="V-67395" selected="true" /><select idref="V-67397" selected="true" /><select idref="V-67399" selected="true" /><select idref="V-67401" selected="true" /><select idref="V-67403" selected="true" /><select idref="V-67405" selected="true" /><select idref="V-67407" selected="true" /><select idref="V-67409" selected="true" /><select idref="V-67411" selected="true" /><select idref="V-67413" selected="true" /><select idref="V-67415" selected="true" /><select idref="V-67417" selected="true" /><select idref="V-67419" selected="true" /><select idref="V-67421" selected="true" /><select idref="V-67423" selected="true" /><select idref="V-67425" selected="true" /><select idref="V-67427" selected="true" /><select idref="V-67429" selected="true" /><select idref="V-67431" selected="true" /><select idref="V-67433" selected="true" /><select idref="V-67435" selected="true" /><select idref="V-67437" selected="true" /><select idref="V-67439" selected="true" /><select idref="V-67441" selected="true" /><select idref="V-67443" selected="true" /><select idref="V-67877" selected="true" /></Profile><Profile id="MAC-1_Sensitive"><title>I - Mission Critical Sensitive</title><description>&lt;ProfileDescription&gt;&lt;/ProfileDescription&gt;</description><select idref="V-67357" selected="true" /><select idref="V-67359" selected="true" /><select idref="V-67361" selected="true" /><select idref="V-67365" selected="true" /><select idref="V-67367" selected="true" /><select idref="V-67369" selected="true" /><select idref="V-67371" selected="true" /><select idref="V-67373" selected="true" /><select idref="V-67375" selected="true" /><select idref="V-67377" selected="true" /><select idref="V-67381" selected="true" /><select idref="V-67383" selected="true" /><select idref="V-67385" selected="true" /><select idref="V-67389" selected="true" /><select idref="V-67391" selected="true" /><select idref="V-67393" selected="true" /><select idref="V-67395" selected="true" /><select idref="V-67397" selected="true" /><select idref="V-67399" selected="true" /><select idref="V-67401" selected="true" /><select idref="V-67403" selected="true" /><select idref="V-67405" selected="true" /><select idref="V-67407" selected="true" /><select idref="V-67409" selected="true" /><select idref="V-67411" selected="true" /><select idref="V-67413" selected="true" /><select idref="V-67415" selected="true" /><select idref="V-67417" selected="true" /><select idref="V-67419" selected="true" /><select idref="V-67421" selected="true" /><select idref="V-67423" selected="true" /><select idref="V-67425" selected="true" /><select idref="V-67427" selected="true" /><select idref="V-67429" selected="true" /><select idref="V-67431" selected="true" /><select idref="V-67433" selected="true" /><select idref="V-67435" selected="true" /><select idref="V-67437" selected="true" /><select idref="V-67439" selected="true" /><select idref="V-67441" selected="true" /><select idref="V-67443" selected="true" /><select idref="V-67877" selected="true" /></Profile><Profile id="MAC-2_Classified"><title>II - Mission Support Classified</title><description>&lt;ProfileDescription&gt;&lt;/ProfileDescription&gt;</description><select idref="V-67357" selected="true" /><select idref="V-67359" selected="true" /><select idref="V-67361" selected="true" /><select idref="V-67365" selected="true" /><select idref="V-67367" selected="true" /><select idref="V-67369" selected="true" /><select idref="V-67371" selected="true" /><select idref="V-67373" selected="true" /><select idref="V-67375" selected="true" /><select idref="V-67377" selected="true" /><select idref="V-67381" selected="true" /><select idref="V-67383" selected="true" /><select idref="V-67385" selected="true" /><select idref="V-67389" selected="true" /><select idref="V-67391" selected="true" /><select idref="V-67393" selected="true" /><select idref="V-67395" selected="true" /><select idref="V-67397" selected="true" /><select idref="V-67399" selected="true" /><select idref="V-67401" selected="true" /><select idref="V-67403" selected="true" /><select idref="V-67405" selected="true" /><select idref="V-67407" selected="true" /><select idref="V-67409" selected="true" /><select idref="V-67411" selected="true" /><select idref="V-67413" selected="true" /><select idref="V-67415" selected="true" /><select idref="V-67417" selected="true" /><select idref="V-67419" selected="true" /><select idref="V-67421" selected="true" /><select idref="V-67423" selected="true" /><select idref="V-67425" selected="true" /><select idref="V-67427" selected="true" /><select idref="V-67429" selected="true" /><select idref="V-67431" selected="true" /><select idref="V-67433" selected="true" /><select idref="V-67435" selected="true" /><select idref="V-67437" selected="true" /><select idref="V-67439" selected="true" /><select idref="V-67441" selected="true" /><select idref="V-67443" selected="true" /><select idref="V-67877" selected="true" /></Profile><Profile id="MAC-2_Public"><title>II - Mission Support Public</title><description>&lt;ProfileDescription&gt;&lt;/ProfileDescription&gt;</description><select idref="V-67357" selected="true" /><select idref="V-67359" selected="true" /><select idref="V-67361" selected="true" /><select idref="V-67365" selected="true" /><select idref="V-67367" selected="true" /><select idref="V-67369" selected="true" /><select idref="V-67371" selected="true" /><select idref="V-67373" selected="true" /><select idref="V-67375" selected="true" /><select idref="V-67377" selected="true" /><select idref="V-67381" selected="true" /><select idref="V-67383" selected="true" /><select idref="V-67385" selected="true" /><select idref="V-67389" selected="true" /><select idref="V-67391" selected="true" /><select idref="V-67393" selected="true" /><select idref="V-67395" selected="true" /><select idref="V-67397" selected="true" /><select idref="V-67399" selected="true" /><select idref="V-67401" selected="true" /><select idref="V-67403" selected="true" /><select idref="V-67405" selected="true" /><select idref="V-67407" selected="true" /><select idref="V-67409" selected="true" /><select idref="V-67411" selected="true" /><select idref="V-67413" selected="true" /><select idref="V-67415" selected="true" /><select idref="V-67417" selected="true" /><select idref="V-67419" selected="true" /><select idref="V-67421" selected="true" /><select idref="V-67423" selected="true" /><select idref="V-67425" selected="true" /><select idref="V-67427" selected="true" /><select idref="V-67429" selected="true" /><select idref="V-67431" selected="true" /><select idref="V-67433" selected="true" /><select idref="V-67435" selected="true" /><select idref="V-67437" selected="true" /><select idref="V-67439" selected="true" /><select idref="V-67441" selected="true" /><select idref="V-67443" selected="true" /><select idref="V-67877" selected="true" /></Profile><Profile id="MAC-2_Sensitive"><title>II - Mission Support Sensitive</title><description>&lt;ProfileDescription&gt;&lt;/ProfileDescription&gt;</description><select idref="V-67357" selected="true" /><select idref="V-67359" selected="true" /><select idref="V-67361" selected="true" /><select idref="V-67365" selected="true" /><select idref="V-67367" selected="true" /><select idref="V-67369" selected="true" /><select idref="V-67371" selected="true" /><select idref="V-67373" selected="true" /><select idref="V-67375" selected="true" /><select idref="V-67377" selected="true" /><select idref="V-67381" selected="true" /><select idref="V-67383" selected="true" /><select idref="V-67385" selected="true" /><select idref="V-67389" selected="true" /><select idref="V-67391" selected="true" /><select idref="V-67393" selected="true" /><select idref="V-67395" selected="true" /><select idref="V-67397" selected="true" /><select idref="V-67399" selected="true" /><select idref="V-67401" selected="true" /><select idref="V-67403" selected="true" /><select idref="V-67405" selected="true" /><select idref="V-67407" selected="true" /><select idref="V-67409" selected="true" /><select idref="V-67411" selected="true" /><select idref="V-67413" selected="true" /><select idref="V-67415" selected="true" /><select idref="V-67417" selected="true" /><select idref="V-67419" selected="true" /><select idref="V-67421" selected="true" /><select idref="V-67423" selected="true" /><select idref="V-67425" selected="true" /><select idref="V-67427" selected="true" /><select idref="V-67429" selected="true" /><select idref="V-67431" selected="true" /><select idref="V-67433" selected="true" /><select idref="V-67435" selected="true" /><select idref="V-67437" selected="true" /><select idref="V-67439" selected="true" /><select idref="V-67441" selected="true" /><select idref="V-67443" selected="true" /><select idref="V-67877" selected="true" /></Profile><Profile id="MAC-3_Classified"><title>III - Administrative Classified</title><description>&lt;ProfileDescription&gt;&lt;/ProfileDescription&gt;</description><select idref="V-67357" selected="true" /><select idref="V-67359" selected="true" /><select idref="V-67361" selected="true" /><select idref="V-67365" selected="true" /><select idref="V-67367" selected="true" /><select idref="V-67369" selected="true" /><select idref="V-67371" selected="true" /><select idref="V-67373" selected="true" /><select idref="V-67375" selected="true" /><select idref="V-67377" selected="true" /><select idref="V-67381" selected="true" /><select idref="V-67383" selected="true" /><select idref="V-67385" selected="true" /><select idref="V-67389" selected="true" /><select idref="V-67391" selected="true" /><select idref="V-67393" selected="true" /><select idref="V-67395" selected="true" /><select idref="V-67397" selected="true" /><select idref="V-67399" selected="true" /><select idref="V-67401" selected="true" /><select idref="V-67403" selected="true" /><select idref="V-67405" selected="true" /><select idref="V-67407" selected="true" /><select idref="V-67409" selected="true" /><select idref="V-67411" selected="true" /><select idref="V-67413" selected="true" /><select idref="V-67415" selected="true" /><select idref="V-67417" selected="true" /><select idref="V-67419" selected="true" /><select idref="V-67421" selected="true" /><select idref="V-67423" selected="true" /><select idref="V-67425" selected="true" /><select idref="V-67427" selected="true" /><select idref="V-67429" selected="true" /><select idref="V-67431" selected="true" /><select idref="V-67433" selected="true" /><select idref="V-67435" selected="true" /><select idref="V-67437" selected="true" /><select idref="V-67439" selected="true" /><select idref="V-67441" selected="true" /><select idref="V-67443" selected="true" /><select idref="V-67877" selected="true" /></Profile><Profile id="MAC-3_Public"><title>III - Administrative Public</title><description>&lt;ProfileDescription&gt;&lt;/ProfileDescription&gt;</description><select idref="V-67357" selected="true" /><select idref="V-67359" selected="true" /><select idref="V-67361" selected="true" /><select idref="V-67365" selected="true" /><select idref="V-67367" selected="true" /><select idref="V-67369" selected="true" /><select idref="V-67371" selected="true" /><select idref="V-67373" selected="true" /><select idref="V-67375" selected="true" /><select idref="V-67377" selected="true" /><select idref="V-67381" selected="true" /><select idref="V-67383" selected="true" /><select idref="V-67385" selected="true" /><select idref="V-67389" selected="true" /><select idref="V-67391" selected="true" /><select idref="V-67393" selected="true" /><select idref="V-67395" selected="true" /><select idref="V-67397" selected="true" /><select idref="V-67399" selected="true" /><select idref="V-67401" selected="true" /><select idref="V-67403" selected="true" /><select idref="V-67405" selected="true" /><select idref="V-67407" selected="true" /><select idref="V-67409" selected="true" /><select idref="V-67411" selected="true" /><select idref="V-67413" selected="true" /><select idref="V-67415" selected="true" /><select idref="V-67417" selected="true" /><select idref="V-67419" selected="true" /><select idref="V-67421" selected="true" /><select idref="V-67423" selected="true" /><select idref="V-67425" selected="true" /><select idref="V-67427" selected="true" /><select idref="V-67429" selected="true" /><select idref="V-67431" selected="true" /><select idref="V-67433" selected="true" /><select idref="V-67435" selected="true" /><select idref="V-67437" selected="true" /><select idref="V-67439" selected="true" /><select idref="V-67441" selected="true" /><select idref="V-67443" selected="true" /><select idref="V-67877" selected="true" /></Profile><Profile id="MAC-3_Sensitive"><title>III - Administrative Sensitive</title><description>&lt;ProfileDescription&gt;&lt;/ProfileDescription&gt;</description><select idref="V-67357" selected="true" /><select idref="V-67359" selected="true" /><select idref="V-67361" selected="true" /><select idref="V-67365" selected="true" /><select idref="V-67367" selected="true" /><select idref="V-67369" selected="true" /><select idref="V-67371" selected="true" /><select idref="V-67373" selected="true" /><select idref="V-67375" selected="true" /><select idref="V-67377" selected="true" /><select idref="V-67381" selected="true" /><select idref="V-67383" selected="true" /><select idref="V-67385" selected="true" /><select idref="V-67389" selected="true" /><select idref="V-67391" selected="true" /><select idref="V-67393" selected="true" /><select idref="V-67395" selected="true" /><select idref="V-67397" selected="true" /><select idref="V-67399" selected="true" /><select idref="V-67401" selected="true" /><select idref="V-67403" selected="true" /><select idref="V-67405" selected="true" /><select idref="V-67407" selected="true" /><select idref="V-67409" selected="true" /><select idref="V-67411" selected="true" /><select idref="V-67413" selected="true" /><select idref="V-67415" selected="true" /><select idref="V-67417" selected="true" /><select idref="V-67419" selected="true" /><select idref="V-67421" selected="true" /><select idref="V-67423" selected="true" /><select idref="V-67425" selected="true" /><select idref="V-67427" selected="true" /><select idref="V-67429" selected="true" /><select idref="V-67431" selected="true" /><select idref="V-67433" selected="true" /><select idref="V-67435" selected="true" /><select idref="V-67437" selected="true" /><select idref="V-67439" selected="true" /><select idref="V-67441" selected="true" /><select idref="V-67443" selected="true" /><select idref="V-67877" selected="true" /></Profile><Group id="V-67357"><title>SRG-APP-000033-DB-000084</title><description>&lt;GroupDescription&gt;&lt;/GroupDescription&gt;</description><Rule id="SV-81847r1_rule" severity="medium" weight="10.0"><version>SQL4-00-002000</version><title>SQL Server must enforce approved authorizations for logical access to information and database-level system resources in accordance with applicable access control policies.</title><description>&lt;VulnDiscussion&gt;Authentication with a DoD-approved PKI certificate does not necessarily imply authorization to access the database and all its contents. To mitigate the risk of unauthorized access to sensitive information by entities that have been issued certificates by DoD-approved PKIs, all DoD systems, including SQL Server databases, must be properly configured to implement access control policies.
 
Successful authentication must not automatically give an entity access to an asset or security boundary. Authorization procedures and controls must be implemented to ensure each authenticated entity also has a validated and current authorization. Authorization is the process of determining whether an entity, once authenticated, is permitted to access a specific asset. Information systems use access control policies and enforcement mechanisms to implement this requirement.
 
Access control policies include identity-based policies, role-based policies, and attribute-based policies. Access enforcement mechanisms include access control lists, access control matrices, and cryptography. These policies and mechanisms must be employed by the application to control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, and domains) in the information system.
 
This requirement is applicable to access control enforcement applications, a category that includes SQL Server. If SQL Server is not configured to follow applicable policy when approving access, it may be in conflict with networks or other applications in the information system. This may result in users either gaining or being denied access inappropriately and in conflict with applicable policy.&lt;/VulnDiscussion&gt;&lt;FalsePositives&gt;&lt;/FalsePositives&gt;&lt;FalseNegatives&gt;&lt;/FalseNegatives&gt;&lt;Documentable&gt;false&lt;/Documentable&gt;&lt;Mitigations&gt;&lt;/Mitigations&gt;&lt;SeverityOverrideGuidance&gt;&lt;/SeverityOverrideGuidance&gt;&lt;PotentialImpacts&gt;&lt;/PotentialImpacts&gt;&lt;ThirdPartyTools&gt;&lt;/ThirdPartyTools&gt;&lt;MitigationControl&gt;&lt;/MitigationControl&gt;&lt;Responsibility&gt;&lt;/Responsibility&gt;&lt;IAControls&gt;&lt;/IAControls&gt;</description><reference><dc:title>DPMS Target SQL Server Database 2014</dc:title><dc:publisher>DISA</dc:publisher><dc:type>DPMS Target</dc:type><dc:subject>SQL Server Database 2014</dc:subject><dc:identifier>2637</dc:identifier></reference><ident system="http://iase.disa.mil/cci">CCI-000213</ident><fixtext fixref="F-73469r1_fix">Use GRANT, REVOKE, DENY, ALTER ROLE … ADD MEMBER … and/or ALTER ROLE …. DROP MEMBER statements to add and remove permissions on database-level securables, bringing them into line with the documented requirements.</fixtext><fix id="F-73469r1_fix" /><check system="C-67935r1_chk"><check-content-ref name="M" href="DPMS_XCCDF_Benchmark_MS_SQL_Server_2014_Database_STIG.xml" /><check-content>Review the system documentation to determine the required levels of protection for securables in the database, by type of user.
 
Review the permissions actually in place in the database.
 
The database permission functions and views provided in the supplemental file Permissions.sql can help with this.
 
If the actual permissions do not match the documented requirements, this is a finding.</check-content></check></Rule></Group><Group id="V-67359"><title>SRG-APP-000089-DB-000064</title><description>&lt;GroupDescription&gt;&lt;/GroupDescription&gt;</description><Rule id="SV-81849r2_rule" severity="medium" weight="10.0"><version>SQL4-00-011200</version><title>SQL Server must generate Trace or Audit records for organization-defined auditable events.</title><description>&lt;VulnDiscussion&gt;Audit records can be generated from various components within the information system (e.g., network interface, hard disk, modem, etc.). From an application perspective, certain specific application functionalities may be audited as well.
 
The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records. Examples are auditable events, time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked.
 
Organizations define which application components shall provide auditable events.
 
The DBMS must provide auditing for the list of events defined by the organization or risk negatively impacting forensic investigations into malicious behavior in the information system.
 
Use of SQL Server Audit is recommended. All features of SQL Server Audit are available in the Enterprise and Developer editions of SQL Server 2014. It is not available at the database level in other editions. For this or legacy reasons, the instance may be using SQL Server Trace for auditing, which remains an acceptable solution for the time being. Note, however, that Microsoft intends to remove most aspects of Trace at some point after SQL Server 2016.&lt;/VulnDiscussion&gt;&lt;FalsePositives&gt;&lt;/FalsePositives&gt;&lt;FalseNegatives&gt;&lt;/FalseNegatives&gt;&lt;Documentable&gt;false&lt;/Documentable&gt;&lt;Mitigations&gt;&lt;/Mitigations&gt;&lt;SeverityOverrideGuidance&gt;&lt;/SeverityOverrideGuidance&gt;&lt;PotentialImpacts&gt;&lt;/PotentialImpacts&gt;&lt;ThirdPartyTools&gt;&lt;/ThirdPartyTools&gt;&lt;MitigationControl&gt;&lt;/MitigationControl&gt;&lt;Responsibility&gt;&lt;/Responsibility&gt;&lt;IAControls&gt;&lt;/IAControls&gt;</description><reference><dc:title>DPMS Target SQL Server Database 2014</dc:title><dc:publisher>DISA</dc:publisher><dc:type>DPMS Target</dc:type><dc:subject>SQL Server Database 2014</dc:subject><dc:identifier>2637</dc:identifier></reference><ident system="http://iase.disa.mil/cci">CCI-000169</ident><fixtext fixref="F-73471r1_fix">Design and deploy a SQL Server Audit or Trace that captures all auditable events.
 
The script provided in the supplemental file Trace.sql can be used to create a trace; edit it as necessary to capture any additional, locally-defined events.
 
The script provided in the supplemental file Audit.sql can be used to create an audit; edit it as necessary to capture any additional, locally-defined events.</fixtext><fix id="F-73471r1_fix" /><check system="C-67937r4_chk"><check-content-ref name="M" href="DPMS_XCCDF_Benchmark_MS_SQL_Server_2014_Database_STIG.xml" /><check-content>If there are no locally-defined security tables or procedures, this is not applicable.
 
If neither SQL Server Audit nor SQL Server Trace is in use for audit purposes, this is a finding.
 
If SQL Server Trace is in use for audit purposes, verify that all required events are being audited. From the query prompt:
SELECT * FROM sys.traces;
 
All currently defined traces for the SQL server instance will be listed. If no traces are returned, this is a finding.
 
Determine the trace(s) being used for the auditing requirement.
In the following, replace # with a trace ID being used for the auditing requirements.
From the query prompt:
SELECT DISTINCT(eventid) FROM sys.fn_trace_geteventinfo(#);
 
The following required event IDs should all be among those listed; if not, this is a finding.
 
Any additional events locally defined should also be in the list; if not, this is a finding.
 
14 -- Audit Login
15 -- Audit Logout
16 -- Attention
17 -- ExistingConnection
18 -- Audit Server Starts and Stops
20 -- Audit Login Failed
42 -- SP:Starting
43 -- SP:Completed
46 -- Object:Created
47 -- Object:Deleted
90 -- User-defined Event
102 -- Audit Database Scope GDR Event
103 -- Audit Object GDR Event
104 -- Audit AddLogin Event
105 -- Audit Login GDR Event
106 -- Audit Login Change Property Event
107 -- Audit Login Change Password Event
108 -- Audit Add Login to Server Role Event
109 -- Audit Add DB User Event
110 -- Audit Add Member to DB Role Event
111 -- Audit Add Role Event
112 -- Audit App Role Change Password Event
113 -- Audit Statement Permission Event
115 -- Audit Backup/Restore Event
116 -- Audit DBCC Event
117 -- Audit Change Audit Event
118 -- Audit Object Derived Permission Event
128 -- Audit Database Management Event
129 -- Audit Database Object Management Event
130 -- Audit Database Principal Management Event
131 -- Audit Schema Object Management Event
132 -- Audit Server Principal Impersonation Event
133 -- Audit Database Principal Impersonation Event
134 -- Audit Server Object Take Ownership Event
135 -- Audit Database Object Take Ownership Event
152 -- Audit Change Database Owner
153 -- Audit Schema Object Take Ownership Event
162 -- User error message
164 -- Object:Altered
170 -- Audit Server Scope GDR Event
171 -- Audit Server Object GDR Event
172 -- Audit Database Object GDR Event
173 -- Audit Server Operation Event
175 -- Audit Server Alter Trace Event
176 -- Audit Server Object Management Event
177 -- Audit Server Principal Management Event
178 -- Audit Database Operation Event
180 -- Audit Database Object Access Event
 
 
If SQL Server Audit is in use, proceed as follows.
 
The basic SQL Server Audit configuration provided in the supplemental file Audit.sql uses broad, server-level audit action groups for this purpose. SQL Server Audit's flexibility makes other techniques possible.
 
If an alternative technique is in use and demonstrated effective, this is not a finding.
 
Determine the name(s) of the server audit specification(s) in use.
 
To look at audits and audit specifications, in Management Studio's object explorer, expand
&lt;server name&gt; &gt;&gt; Security &gt;&gt; Audits
and
&lt;server name&gt; &gt;&gt; Security &gt;&gt; Server Audit Specifications.
Also,
&lt;server name&gt; &gt;&gt; Databases &gt;&gt; &lt;database name&gt; &gt;&gt; Security &gt;&gt; Database Audit Specifications.
 
Alternatively, review the contents of the system views with "audit" in their names.
 
Run the following code to verify that all configuration-related actions are being audited:
USE [master];
GO
SELECT * FROM sys.server_audit_specification_details WHERE server_specification_id =
(SELECT server_specification_id FROM sys.server_audit_specifications WHERE [name] = '&lt;server_audit_specification_name&gt;');
GO
 
Examine the list produced by the query.
 
If the audited_result column is not "SUCCESS AND FAILURE" on every row, this is a finding.
 
If any of the following audit action groups is not included in the list, this is a finding.
 
APPLICATION_ROLE_CHANGE_PASSWORD_GROUP
AUDIT_CHANGE_GROUP
BACKUP_RESTORE_GROUP
DATABASE_CHANGE_GROUP
DATABASE_OBJECT_ACCESS_GROUP
DATABASE_OBJECT_OWNERSHIP_CHANGE_GROUP
DATABASE_OBJECT_PERMISSION_CHANGE_GROUP
DATABASE_OPERATION_GROUP
DATABASE_OWNERSHIP_CHANGE_GROUP
DATABASE_PERMISSION_CHANGE_GROUP
DATABASE_PRINCIPAL_CHANGE_GROUP
DATABASE_PRINCIPAL_IMPERSONATION_GROUP
DATABASE_ROLE_MEMBER_CHANGE_GROUP
DBCC_GROUP
FAILED_LOGIN_GROUP
LOGIN_CHANGE_PASSWORD_GROUP
LOGOUT_GROUP
SCHEMA_OBJECT_ACCESS_GROUP
SCHEMA_OBJECT_CHANGE_GROUP
SCHEMA_OBJECT_OWNERSHIP_CHANGE_GROUP
SCHEMA_OBJECT_PERMISSION_CHANGE_GROUP
SERVER_OBJECT_CHANGE_GROUP
SERVER_OBJECT_OWNERSHIP_CHANGE_GROUP
SERVER_OBJECT_PERMISSION_CHANGE_GROUP
SERVER_OPERATION_GROUP
SERVER_PERMISSION_CHANGE_GROUP
SERVER_PRINCIPAL_CHANGE_GROUP
SERVER_PRINCIPAL_IMPERSONATION_GROUP
SERVER_ROLE_MEMBER_CHANGE_GROUP
SERVER_STATE_CHANGE_GROUP
SUCCESSFUL_LOGIN_GROUP
TRACE_CHANGE_GROUP</check-content></check></Rule></Group><Group id="V-67361"><title>SRG-APP-000090-DB-000065</title><description>&lt;GroupDescription&gt;&lt;/GroupDescription&gt;</description><Rule id="SV-81851r2_rule" severity="medium" weight="10.0"><version>SQL4-00-011320</version><title>Where SQL Server Audit is in use at the database level, SQL Server must allow only the ISSM (or individuals or roles appointed by the ISSM) to select which auditable events are to be audited at the database level.</title><description>&lt;VulnDiscussion&gt;Without the capability to restrict which roles and individuals can select which events are audited, unauthorized personnel may be able to prevent or interfere with the auditing of critical events.
 
Suppression of auditing could permit an adversary to evade detection.
 
Misconfigured audits can degrade the system's performance by overwhelming the audit log. Misconfigured audits may also make it more difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
 
Use of SQL Server Audit is recommended. All features of SQL Server Audit are available in the Enterprise and Developer editions of SQL Server 2014. It is not available at the database level in other editions. For this or legacy reasons, the instance may be using SQL Server Trace for auditing, which remains an acceptable solution for the time being. Note, however, that Microsoft intends to remove most aspects of Trace at some point after SQL Server 2016.
 
This version of the requirement deals with SQL Server Audit-based audit trails.&lt;/VulnDiscussion&gt;&lt;FalsePositives&gt;&lt;/FalsePositives&gt;&lt;FalseNegatives&gt;&lt;/FalseNegatives&gt;&lt;Documentable&gt;false&lt;/Documentable&gt;&lt;Mitigations&gt;&lt;/Mitigations&gt;&lt;SeverityOverrideGuidance&gt;&lt;/SeverityOverrideGuidance&gt;&lt;PotentialImpacts&gt;&lt;/PotentialImpacts&gt;&lt;ThirdPartyTools&gt;&lt;/ThirdPartyTools&gt;&lt;MitigationControl&gt;&lt;/MitigationControl&gt;&lt;Responsibility&gt;&lt;/Responsibility&gt;&lt;IAControls&gt;&lt;/IAControls&gt;</description><reference><dc:title>DPMS Target SQL Server Database 2014</dc:title><dc:publisher>DISA</dc:publisher><dc:type>DPMS Target</dc:type><dc:subject>SQL Server Database 2014</dc:subject><dc:identifier>2637</dc:identifier></reference><ident system="http://iase.disa.mil/cci">CCI-000171</ident><fixtext fixref="F-73473r1_fix">Create a database role specifically for audit maintainers, and give it permission to maintain audits, without granting it unnecessary permissions:
USE &lt;database name&gt;;
GO
CREATE ROLE DATABASE_AUDIT_MAINTAINERS;
GO
GRANT ALTER ANY DATABASE AUDIT TO DATABASE_AUDIT_MAINTAINERS;
GO
(The role name used here is an example; other names may be used.)
 
Use REVOKE and/or DENY and/or ALTER ROLE ... DROP MEMBER ... statements to remove the ALTER ANY DATABASE AUDIT permission from all users.
 
Then, for each authorized database user, run the statement:
ALTER ROLE DATABASE_AUDIT_MAINTAINERS ADD MEMBER &lt;user name&gt; ;
GO
 
Use REVOKE and/or DENY and/or ALTER SERVER ROLE ... DROP MEMBER ... statements to remove CONTROL DATABASE permission from logins that do not need it.</fixtext><fix id="F-73473r1_fix" /><check system="C-67939r2_chk"><check-content-ref name="M" href="DPMS_XCCDF_Benchmark_MS_SQL_Server_2014_Database_STIG.xml" /><check-content>If SQL Server Audit is not in use at the database level, this is not applicable (NA).
 
Obtain the list of approved audit maintainers from the system documentation.
 
Review the database roles and individual users that have the following permissions, both of which enable the ability to maintain audit definitions:
ALTER ANY DATABASE AUDIT
CONTROL ON DATABASE
 
The functions and views provided in the supplemental file Permissions.sql can assist in this review. In the following, "STIG" stands for the schema where you have deployed these views and functions. To see which logins and server roles have been granted these permissions:
    SELECT
        *
    FROM
        STIG.database_permissions P
    WHERE
        (P.[Permission] = 'ALTER ANY DATABASE AUDIT')
        OR
        (P.[Permission] = 'CONTROL' AND P.[Securable Type or Class] = 'DATABASE')
        ;
 
To see what users and database roles inherit these permissions from the database roles reported by the previous query, repeat the following for each one:
    SELECT * FROM STIG.members_of_database_role(&lt;database role name&gt;);
 
To see all the permissions in effect for a database principal (server role or login):
    SELECT * FROM STIG.server_effective_permissions(&lt;principal name&gt;);
 
If designated personnel are not able to configure auditable events, this is a finding.
 
If unapproved personnel are able to configure auditable events, this is a finding.</check-content></check></Rule></Group><Group id="V-67365"><title>SRG-APP-000133-DB-000179</title><description>&lt;GroupDescription&gt;&lt;/GroupDescription&gt;</description><Rule id="SV-81855r2_rule" severity="medium" weight="10.0"><version>SQL4-00-014900</version><title>SQL Server must be monitored to discover unauthorized changes to functions.</title><description>&lt;VulnDiscussion&gt;When dealing with change control issues, it should be noted, any changes to the hardware, software, and/or firmware components of SQL Server and/or application can potentially have significant effects on the overall security of the system.
 
If SQL Server were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process.
 
This requirement is contingent upon the language in which the application is programmed, as many application architectures in use today incorporate their software libraries into, and make them inseparable from, their compiled distributions, rendering them static and version-dependent. However, this requirement does apply to applications with software libraries accessible and configurable, as in the case of interpreted languages.
 
Accordingly, only qualified and authorized individuals shall be allowed to obtain access to SQL Server components for purposes of initiating changes, including upgrades and modifications.
 
Unmanaged changes that occur to the SQL Server software libraries or configuration, such as Functions, can lead to unauthorized or compromised installations.&lt;/VulnDiscussion&gt;&lt;FalsePositives&gt;&lt;/FalsePositives&gt;&lt;FalseNegatives&gt;&lt;/FalseNegatives&gt;&lt;Documentable&gt;false&lt;/Documentable&gt;&lt;Mitigations&gt;&lt;/Mitigations&gt;&lt;SeverityOverrideGuidance&gt;&lt;/SeverityOverrideGuidance&gt;&lt;PotentialImpacts&gt;&lt;/PotentialImpacts&gt;&lt;ThirdPartyTools&gt;&lt;/ThirdPartyTools&gt;&lt;MitigationControl&gt;&lt;/MitigationControl&gt;&lt;Responsibility&gt;&lt;/Responsibility&gt;&lt;IAControls&gt;&lt;/IAControls&gt;</description><reference><dc:title>DPMS Target SQL Server Database 2014</dc:title><dc:publisher>DISA</dc:publisher><dc:type>DPMS Target</dc:type><dc:subject>SQL Server Database 2014</dc:subject><dc:identifier>2637</dc:identifier></reference><ident system="http://iase.disa.mil/cci">CCI-001499</ident><fixtext fixref="F-73477r2_fix">Configure a SQL Server timed job that automatically checks all system and user-defined Functions for being modified.
 
(The supplemental file Track.sql, provided with this STIG, can be used to establish a monitoring job. This should be supplemented with a process for informing the appropriate personnel. Other techniques for achieving the same ends, such as the use of DDL triggers, are acceptable.)</fixtext><fix id="F-73477r2_fix" /><check system="C-67943r1_chk"><check-content-ref name="M" href="DPMS_XCCDF_Benchmark_MS_SQL_Server_2014_Database_STIG.xml" /><check-content>Check the SQL Server configuration for a timed job that automatically checks all system and user-defined Functions for being modified by running the following SQL Server query:
EXEC msdb.dbo.sp_help_job @job_name = '&lt;enter . . . job name&gt;';
 
(Alternatively, in SQL Server Management Studio, navigate to SQL Server Agent and examine the job from there.)
 
If a timed job or some other method is not implemented to check for Functions being modified, this is a finding.</check-content></check></Rule></Group><Group id="V-67367"><title>SRG-APP-000133-DB-000179</title><description>&lt;GroupDescription&gt;&lt;/GroupDescription&gt;</description><Rule id="SV-81857r2_rule" severity="medium" weight="10.0"><version>SQL4-00-015100</version><title>SQL Server must be monitored to discover unauthorized changes to triggers.</title><description>&lt;VulnDiscussion&gt;When dealing with change control issues, it should be noted, any changes to the hardware, software, and/or firmware components of SQL Server and/or application can potentially have significant effects on the overall security of the system.
 
If SQL Server were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process.
 
This requirement is contingent upon the language in which the application is programmed, as many application architectures in use today incorporate their software libraries into, and make them inseparable from, their compiled distributions, rendering them static and version-dependent. However, this requirement does apply to applications with software libraries accessible and configurable, as in the case of interpreted languages.
 
Accordingly, only qualified and authorized individuals shall be allowed to obtain access to SQL Server components for purposes of initiating changes, including upgrades and modifications.
 
Unmanaged changes that occur to the SQL Server software libraries or configuration, such as Triggers, can lead to unauthorized or compromised installations.&lt;/VulnDiscussion&gt;&lt;FalsePositives&gt;&lt;/FalsePositives&gt;&lt;FalseNegatives&gt;&lt;/FalseNegatives&gt;&lt;Documentable&gt;false&lt;/Documentable&gt;&lt;Mitigations&gt;&lt;/Mitigations&gt;&lt;SeverityOverrideGuidance&gt;&lt;/SeverityOverrideGuidance&gt;&lt;PotentialImpacts&gt;&lt;/PotentialImpacts&gt;&lt;ThirdPartyTools&gt;&lt;/ThirdPartyTools&gt;&lt;MitigationControl&gt;&lt;/MitigationControl&gt;&lt;Responsibility&gt;&lt;/Responsibility&gt;&lt;IAControls&gt;&lt;/IAControls&gt;</description><reference><dc:title>DPMS Target SQL Server Database 2014</dc:title><dc:publisher>DISA</dc:publisher><dc:type>DPMS Target</dc:type><dc:subject>SQL Server Database 2014</dc:subject><dc:identifier>2637</dc:identifier></reference><ident system="http://iase.disa.mil/cci">CCI-001499</ident><fixtext fixref="F-73479r2_fix">Configure a SQL Server timed job that automatically checks all system and user-defined Triggers for modification.
 
(The supplemental file Track.sql, provided with this STIG, can be used to establish a monitoring job. This should be supplemented with a process for informing the appropriate personnel. Other techniques for achieving the same ends, such as the use of DDL triggers, are acceptable.)</fixtext><fix id="F-73479r2_fix" /><check system="C-67945r1_chk"><check-content-ref name="M" href="DPMS_XCCDF_Benchmark_MS_SQL_Server_2014_Database_STIG.xml" /><check-content>Check the SQL Server configuration for the timed job that automatically checks all system and user-defined Triggers for being modified by running the following SQL Server query:
EXEC msdb.dbo.sp_help_job @job_name = '&lt;enter . . . job name&gt;';
 
(Alternatively, in SQL Server Management Studio, navigate to SQL Server Agent and examine the job from there.)
 
If such a job, or an alternative method of monitoring triggers for modification, does not exist, this is a finding</check-content></check></Rule></Group><Group id="V-67369"><title>SRG-APP-000133-DB-000179</title><description>&lt;GroupDescription&gt;&lt;/GroupDescription&gt;</description><Rule id="SV-81859r2_rule" severity="medium" weight="10.0"><version>SQL4-00-015200</version><title>SQL Server must be monitored to discover unauthorized changes to stored procedures.</title><description>&lt;VulnDiscussion&gt;When dealing with change control issues, it should be noted, any changes to the hardware, software, and/or firmware components of SQL Server and/or application can potentially have significant effects on the overall security of the system.
 
If SQL Server were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process.
 
This requirement is contingent upon the language in which the application is programmed, as many application architectures in use today incorporate their software libraries into, and make them inseparable from, their compiled distributions, rendering them static and version-dependent. However, this requirement does apply to applications with software libraries accessible and configurable, as in the case of interpreted languages.
 
Accordingly, only qualified and authorized individuals shall be allowed to obtain access to SQL Server components for purposes of initiating changes, including upgrades and modifications.
 
Unmanaged changes that occur to the SQL Server software libraries or configuration, such as Stored Procedures, can lead to unauthorized or compromised installations.&lt;/VulnDiscussion&gt;&lt;FalsePositives&gt;&lt;/FalsePositives&gt;&lt;FalseNegatives&gt;&lt;/FalseNegatives&gt;&lt;Documentable&gt;false&lt;/Documentable&gt;&lt;Mitigations&gt;&lt;/Mitigations&gt;&lt;SeverityOverrideGuidance&gt;&lt;/SeverityOverrideGuidance&gt;&lt;PotentialImpacts&gt;&lt;/PotentialImpacts&gt;&lt;ThirdPartyTools&gt;&lt;/ThirdPartyTools&gt;&lt;MitigationControl&gt;&lt;/MitigationControl&gt;&lt;Responsibility&gt;&lt;/Responsibility&gt;&lt;IAControls&gt;&lt;/IAControls&gt;</description><reference><dc:title>DPMS Target SQL Server Database 2014</dc:title><dc:publisher>DISA</dc:publisher><dc:type>DPMS Target</dc:type><dc:subject>SQL Server Database 2014</dc:subject><dc:identifier>2637</dc:identifier></reference><ident system="http://iase.disa.mil/cci">CCI-001499</ident><fixtext fixref="F-73481r3_fix">Configure a SQL Server timed job that automatically checks all system and user-defined Stored Procedures for modification.
 
(The supplemental file Track.sql, provided with this STIG, can be used to establish a monitoring job. This should be supplemented with a process for informing the appropriate personnel. Other techniques for achieving the same ends, such as the use of DDL triggers, are acceptable.)</fixtext><fix id="F-73481r3_fix" /><check system="C-67947r1_chk"><check-content-ref name="M" href="DPMS_XCCDF_Benchmark_MS_SQL_Server_2014_Database_STIG.xml" /><check-content>Check for the existence of a job to monitor for changes to stored procedures:
EXEC msdb.dbo.sp_help_job @job_name = '&lt;enter . . . job name&gt;';
 
(Alternatively, in SQL Server Management Studio, navigate to SQL Server Agent and examine the job from there.)
 
If such a job, or an alternative method of monitoring stored procedures for modification, does not exist, this is a finding.</check-content></check></Rule></Group><Group id="V-67371"><title>SRG-APP-000133-DB-000200</title><description>&lt;GroupDescription&gt;&lt;/GroupDescription&gt;</description><Rule id="SV-81861r1_rule" severity="medium" weight="10.0"><version>SQL4-00-015600</version><title>Database objects (including but not limited to tables, indexes, storage, stored procedures, functions, triggers, links to software external to SQL Server, etc.) must be owned by database/DBMS principals authorized for ownership.</title><description>&lt;VulnDiscussion&gt;Within the database, object ownership implies full privileges to the owned object, including the privilege to assign access to the owned objects to other subjects. Database functions and procedures can be coded using definer's rights. This allows anyone who utilizes the object to perform the actions if they were the owner. If not properly managed, this can lead to privileged actions being taken by unauthorized individuals.
 
Conversely, if critical tables or other objects rely on unauthorized owner accounts, these objects may be lost when an account is removed.&lt;/VulnDiscussion&gt;&lt;FalsePositives&gt;&lt;/FalsePositives&gt;&lt;FalseNegatives&gt;&lt;/FalseNegatives&gt;&lt;Documentable&gt;false&lt;/Documentable&gt;&lt;Mitigations&gt;&lt;/Mitigations&gt;&lt;SeverityOverrideGuidance&gt;&lt;/SeverityOverrideGuidance&gt;&lt;PotentialImpacts&gt;&lt;/PotentialImpacts&gt;&lt;ThirdPartyTools&gt;&lt;/ThirdPartyTools&gt;&lt;MitigationControl&gt;&lt;/MitigationControl&gt;&lt;Responsibility&gt;&lt;/Responsibility&gt;&lt;IAControls&gt;&lt;/IAControls&gt;</description><reference><dc:title>DPMS Target SQL Server Database 2014</dc:title><dc:publisher>DISA</dc:publisher><dc:type>DPMS Target</dc:type><dc:subject>SQL Server Database 2014</dc:subject><dc:identifier>2637</dc:identifier></reference><ident system="http://iase.disa.mil/cci">CCI-001499</ident><fixtext fixref="F-73483r1_fix">Add and/or update system documentation to include any accounts authorized for object ownership and remove any account not authorized.
 
To change the schema owning a database object in SQL Server, use this code:
USE &lt;database name&gt;;
GO
ALTER SCHEMA &lt;name of new schema&gt; TRANSFER &lt;name of old schema&gt;.&lt;object name&gt;;
GO
 
Caution: this can break code. This Fix should be implemented in conjunction with corrections to such code. Test before deploying in production. Deploy during a scheduled maintenance window.</fixtext><fix id="F-73483r1_fix" /><check system="C-67949r1_chk"><check-content-ref name="M" href="DPMS_XCCDF_Benchmark_MS_SQL_Server_2014_Database_STIG.xml" /><check-content>Review system documentation to identify SQL Server accounts authorized to own database objects.
 
If the SQL Server database ownership list does not exist or needs to be updated, this is a finding.
 
The view STIG.database_permissions, included in the supplemental file, Permissions.sql, can be of use in making this determination:
USE &lt;database name&gt;;
GO
SELECT DISTINCT
        S.[Schema/Owner] AS [Owner],
        O.[Schema/Owner] AS [Schema],
        O.[Securable]
FROM
        STIG.database_permissions O
        INNER JOIN STIG.database_permissions S
                ON S.[Securable] = O.[Schema/Owner]
                AND O.[Securable Type or Class] = 'OBJECT_OR_COLUMN'
                AND S.[Securable Type or Class] = 'SCHEMA'
WHERE
        S.[Schema/Owner] NOT IN ('dbo', 'sys', 'INFORMATION_SCHEMA' ... )
        -- Complete the "NOT IN" list with the names of user accounts authorized for ownership.
;
If any of the listed owners is not authorized, this is a finding.</check-content></check></Rule></Group><Group id="V-67373"><title>SRG-APP-000133-DB-000200</title><description>&lt;GroupDescription&gt;&lt;/GroupDescription&gt;</description><Rule id="SV-81863r1_rule" severity="medium" weight="10.0"><version>SQL4-00-015620</version><title>In a database owned by a login not having administrative privileges at the instance level, the database property TRUSTWORTHY must be OFF unless required and authorized.</title><description>&lt;VulnDiscussion&gt;SQL Server's fixed (built-in) server roles, especially [sysadmin], have powerful capabilities that could cause great harm if misused, so their use must be tightly controlled.
 
The SQL Server instance uses each database's TRUSTWORTHY property to guard against tampering that could enable unwarranted privilege escalation. When TRUSTWORTHY is 0/False/Off, SQL Server prevents the database from accessing resources in other databases. When TRUSTWORTHY is 1/True/On, SQL Server permits access to other databases (subject to other protections). SQL Server sets TRUSTWORTHY OFF when it creates a new database. SQL Server forces TRUSTWORTHY OFF, irrespective of its prior value, when an existing database is attached to it, to address the possibility that an adversary may have tampered with the database, introducing malicious code. To set TRUSTWORTHY ON, an account with the [sysadmin] role must issue an ALTER DATABASE command.
 
Although SQL Server itself treats this property conservatively, application installer programs may set TRUSTWORTHY ON and leave it on. This provides an opportunity for misuse.
 
When TRUSTWORTHY is ON, users of the database can take advantage of the database owner's privileges, by impersonating the owner. This can have particularly serious consequences if the database owner is the [sa] login (which may have been renamed in accordance with SQL4-00-010200, and disabled in accordance with SQL4-00-017100, but nonetheless can be invoked in an EXECUTE AS USER = 'dbo' statement, or CREATE PROCEDURE ... WITH EXECUTE AS OWNER ...). The [sa] login cannot be removed from the [sysadmin] role. The user impersonating [sa] - or another [sysadmin] account - is then able to perform administrative actions across all databases under the instance, including making any himself or any other login a member of [sysadmin].
 
Most of the other fixed server roles could be similarly abused.
 
Therefore, TRUSTWORTHY must not be used on databases owned by logins that are members of the fixed server roles. Further, if TRUSTWORTHY is to be used for any other database, the need must be documented and approved.
 
The system database [msdb] is an exception: it is required to be TRUSTWORTHY.&lt;/VulnDiscussion&gt;&lt;FalsePositives&gt;&lt;/FalsePositives&gt;&lt;FalseNegatives&gt;&lt;/FalseNegatives&gt;&lt;Documentable&gt;false&lt;/Documentable&gt;&lt;Mitigations&gt;&lt;/Mitigations&gt;&lt;SeverityOverrideGuidance&gt;&lt;/SeverityOverrideGuidance&gt;&lt;PotentialImpacts&gt;&lt;/PotentialImpacts&gt;&lt;ThirdPartyTools&gt;&lt;/ThirdPartyTools&gt;&lt;MitigationControl&gt;&lt;/MitigationControl&gt;&lt;Responsibility&gt;&lt;/Responsibility&gt;&lt;IAControls&gt;&lt;/IAControls&gt;</description><reference><dc:title>DPMS Target SQL Server Database 2014</dc:title><dc:publisher>DISA</dc:publisher><dc:type>DPMS Target</dc:type><dc:subject>SQL Server Database 2014</dc:subject><dc:identifier>2637</dc:identifier></reference><ident system="http://iase.disa.mil/cci">CCI-001499</ident><fixtext fixref="F-73485r1_fix">Run the SQL statements:
USE [master];
GO
ALTER DATABASE &lt;name&gt; SET TRUSTWORTHY OFF;
GO</fixtext><fix id="F-73485r1_fix" /><check system="C-67951r1_chk"><check-content-ref name="M" href="DPMS_XCCDF_Benchmark_MS_SQL_Server_2014_Database_STIG.xml" /><check-content>If the database is owned by an account that is directly or indirectly a member of a fixed (built-in) server role, this is not applicable (NA).
 
Run the query:
USE &lt;database name&gt;;
GO
SELECT
DB_NAME() AS [Database],
SUSER_SNAME(D.owner_sid) AS [Database Owner],
CASE WHEN D.is_trustworthy_on = 1 THEN 'ON' ELSE 'off' END
AS [Trustworthy]
FROM
sys.databases D
WHERE
D.[name] = DB_NAME()
AND DB_NAME() &lt;&gt; 'msdb'
AND D.is_trustworthy_on = 1;
GO
If the query returns a row indicating that the TRUSTWORTHY setting is OFF, or returns no rows, this is not a finding.
 
Review the system security plan to determine whether the need for TRUSTWORTHY is documented and approved. If not, this is a finding.</check-content></check></Rule></Group><Group id="V-67375"><title>SRG-APP-000133-DB-000200</title><description>&lt;GroupDescription&gt;&lt;/GroupDescription&gt;</description><Rule id="SV-81865r1_rule" severity="medium" weight="10.0"><version>SQL4-00-015610</version><title>In a database owned by [sa], or by any other login having administrative privileges at the instance level, the database property TRUSTWORTHY must be OFF.</title><description>&lt;VulnDiscussion&gt;SQL Server's fixed (built-in) server roles, especially [sysadmin], have powerful capabilities that could cause great harm if misused, so their use must be tightly controlled.
 
The SQL Server instance uses each database's TRUSTWORTHY property to guard against tampering that could enable unwarranted privilege escalation. When TRUSTWORTHY is 0/False/Off, SQL Server prevents the database from accessing resources in other databases. When TRUSTWORTHY is 1/True/On, SQL Server permits access to other databases (subject to other protections). SQL Server sets TRUSTWORTHY OFF when it creates a new database. SQL Server forces TRUSTWORTHY OFF, irrespective of its prior value, when an existing database is attached to it, to address the possibility that an adversary may have tampered with the database, introducing malicious code. To set TRUSTWORTHY ON, an account with the [sysadmin] role must issue an ALTER DATABASE command.
 
Although SQL Server itself treats this property conservatively, application installer programs may set TRUSTWORTHY ON and leave it on. This provides an opportunity for misuse.
 
When TRUSTWORTHY is ON, users of the database can take advantage of the database owner's privileges, by impersonating the owner. This can have particularly serious consequences if the database owner is the [sa] login (which may have been renamed in accordance with SQL4-00-010200, and disabled in accordance with SQL4-00-017100, but nonetheless can be invoked in an EXECUTE AS USER = 'dbo' statement, or CREATE PROCEDURE ... WITH EXECUTE AS OWNER ...). The [sa] login cannot be removed from the [sysadmin] role. The user impersonating [sa] - or another [sysadmin] account - is then able to perform administrative actions across all databases under the instance, including making any himself or any other login a member of [sysadmin].
 
Most of the other fixed server roles could be similarly abused.
 
Therefore, TRUSTWORTHY must not be used on databases owned by logins that are members of the fixed server roles. Further, if TRUSTWORTHY is to be used for any other database, the need must be documented and approved.
 
The system database [msdb] is an exception: it is required to be TRUSTWORTHY.&lt;/VulnDiscussion&gt;&lt;FalsePositives&gt;&lt;/FalsePositives&gt;&lt;FalseNegatives&gt;&lt;/FalseNegatives&gt;&lt;Documentable&gt;false&lt;/Documentable&gt;&lt;Mitigations&gt;&lt;/Mitigations&gt;&lt;SeverityOverrideGuidance&gt;&lt;/SeverityOverrideGuidance&gt;&lt;PotentialImpacts&gt;&lt;/PotentialImpacts&gt;&lt;ThirdPartyTools&gt;&lt;/ThirdPartyTools&gt;&lt;MitigationControl&gt;&lt;/MitigationControl&gt;&lt;Responsibility&gt;&lt;/Responsibility&gt;&lt;IAControls&gt;&lt;/IAControls&gt;</description><reference><dc:title>DPMS Target SQL Server Database 2014</dc:title><dc:publisher>DISA</dc:publisher><dc:type>DPMS Target</dc:type><dc:subject>SQL Server Database 2014</dc:subject><dc:identifier>2637</dc:identifier></reference><ident system="http://iase.disa.mil/cci">CCI-001499</ident><fixtext fixref="F-73487r1_fix">Set the TRUSTWORTHY property OFF; or remove the database owner from the fixed server role(s); or change the database owner.
 
To set the TRUSTWORTHY property OFF:
USE [master];
GO
ALTER DATABASE &lt;name&gt; SET TRUSTWORTHY OFF;
GO
Verify that this produced the intended result by re-running the query specified in the Check.
 
To determine the path or paths by which the database owner is assigned the fixed server role or roles, run this query:
 
USE &lt;database name&gt;;
GO
WITH C AS
(
SELECT
      P.name AS [Parent Server Role],
      CAST('Fixed' AS varchar(8))
                  AS [Server Role Type],
      M.name AS [Member],
      M.type_desc AS [Member Type],
      P.name AS [Root],
      1 AS [Level]
FROM
      [sys].[server_role_members] X
      INNER JOIN [sys].[server_principals] P ON P.principal_id = X.role_principal_id
      INNER JOIN [sys].[server_principals] M ON M.principal_id = X.member_principal_id
WHERE
      P.is_fixed_role = 1
UNION ALL
SELECT
      P.name AS [Parent Server Role],
      CASE WHEN M.is_fixed_role = 1 THEN CAST('Fixed' AS varchar(8)) ELSE CAST('Custom' AS varchar(8)) END
                    AS [Server Role Type],
      M.name AS [Member],
      M.type_desc AS [Member Type],
      C.[Root] AS [Root],
      C.[Level] + 1 AS [Level]
FROM
      [sys].[server_role_members] X
      INNER JOIN [sys].[server_principals] P ON P.principal_id = X.role_principal_id
      INNER JOIN [sys].[server_principals] M ON M.principal_id = X.member_principal_id
      INNER JOIN C ON P.name = C.Member
)
,
B AS
(
SELECT
      C.[Member] AS [Leaf],
      C.[Root],
      C.[Parent Server Role],
      C.[Server Role Type],
      C.[Member],
      C.[Member Type],
      C.[Level]
FROM C
WHERE
      C.[Member Type] NOT LIKE '%ROLE%'
UNION ALL
SELECT
      B.[Leaf],
      C.[Root],
      C.[Parent Server Role],
      C.[Server Role Type],
      C.[Member],
      C.[Member Type],
      C.[Level]
FROM C
INNER JOIN B
      ON C.[Member] = B.[Parent Server Role]
      AND C.[Level] = B.[Level] - 1
      AND C.[Root] = B.[Root]
)
SELECT
      DB_NAME() AS [Database],
      B.[Leaf] AS [Owner Login],
      B.[Root] AS[Top-Level Server Role],
      B.[Parent Server Role],
      B.[Server Role Type],
      B.[Member],
      B.[Member Type],
      B.[Level]
FROM B
WHERE B.[Leaf] = (SELECT SUSER_SNAME(D.owner_sid) FROM sys.databases D WHERE D.Name = DB_NAME())
ORDER BY B.[Root], B.[Level], B.[Parent Server Role], B.[Member]
;
GO
 
To remove the database owner from a fixed server role or a custom server role:
USE [master];
GO
ALTER SERVER ROLE &lt;fixed/custom server role name&gt;
      DROP MEMBER &lt;database owner name&gt;;
GO
Verify that this produced the intended result by re-running the Check query.
 
To change the database owner:
USE [master];
GO
ALTER AUTHORIZATION ON DATABASE::&lt;DB name&gt; TO &lt;new owner name&gt;;
GO
Verify that this produced the intended result by re-running the Check query.</fixtext><fix id="F-73487r1_fix" /><check system="C-67953r1_chk"><check-content-ref name="M" href="DPMS_XCCDF_Benchmark_MS_SQL_Server_2014_Database_STIG.xml" /><check-content>Run the SQL statements:
USE &lt;database name&gt;;
GO
WITH FixedServerRoles(RoleName) AS
(
      SELECT 'sysadmin'
      UNION SELECT 'securityadmin'
      UNION SELECT 'serveradmin'
      UNION SELECT 'setupadmin'
      UNION SELECT 'processadmin'
      UNION SELECT 'diskadmin'
      UNION SELECT 'dbcreator'
      UNION SELECT 'bulkadmin'
)
SELECT
      DB_NAME() AS [Database],
      SUSER_SNAME(D.owner_sid) AS [Database Owner],
      F.RoleName AS [Fixed Server Role],
      CASE WHEN D.is_trustworthy_on = 1 THEN 'ON' ELSE 'off' END
            AS [Trustworthy]
FROM
      FixedServerRoles F
      INNER JOIN sys.databases D ON D.Name = DB_NAME()
WHERE
      IS_SRVROLEMEMBER(F.RoleName, SUSER_SNAME(D.owner_sid)) = 1
AND DB_NAME() &lt;&gt; 'msdb'
AND D.is_trustworthy_on = 1;
GO
 
If the query returns any rows, this is a finding.</check-content></check></Rule></Group><Group id="V-67377"><title>SRG-APP-000226-DB-000147</title><description>&lt;GroupDescription&gt;&lt;/GroupDescription&gt;</description><Rule id="SV-81867r2_rule" severity="medium" weight="10.0"><version>SQL4-00-021210</version><title>In the event of a system failure, SQL Server must preserve any information necessary to return to operations with least disruption to mission processes.</title><description>&lt;VulnDiscussion&gt;Failure to a known state can address safety or security in accordance with the mission/business needs of the organization. The existence and reliability of database backups is an essential aspect of the ability to fail to a known state. It helps prevent a loss of confidentiality, integrity, or availability in the event of a failure of the information system or a component of the system.
 
Backups must be performed according to an appropriate schedule, and must be tested periodically to provide assurance that they can be used for restoring the database.&lt;/VulnDiscussion&gt;&lt;FalsePositives&gt;&lt;/FalsePositives&gt;&lt;FalseNegatives&gt;&lt;/FalseNegatives&gt;&lt;Documentable&gt;false&lt;/Documentable&gt;&lt;Mitigations&gt;&lt;/Mitigations&gt;&lt;SeverityOverrideGuidance&gt;&lt;/SeverityOverrideGuidance&gt;&lt;PotentialImpacts&gt;&lt;/PotentialImpacts&gt;&lt;ThirdPartyTools&gt;&lt;/ThirdPartyTools&gt;&lt;MitigationControl&gt;&lt;/MitigationControl&gt;&lt;Responsibility&gt;&lt;/Responsibility&gt;&lt;IAControls&gt;&lt;/IAControls&gt;</description><reference><dc:title>DPMS Target SQL Server Database 2014</dc:title><dc:publisher>DISA</dc:publisher><dc:type>DPMS Target</dc:type><dc:subject>SQL Server Database 2014</dc:subject><dc:identifier>2637</dc:identifier></reference><ident system="http://iase.disa.mil/cci">CCI-001665</ident><fixtext fixref="F-73489r1_fix">Modify the system security plan, to include whether the database is static, the correct recovery model to be used, the backup schedule, and the plan for testing database restoration.
 
In SQL Server Management Studio, Object Explorer, right-click on the name of the database; select Properties. Select the Options page. Set the Recovery Model field, near the top of the page, to the correct value.
 
In Object Explorer, expand &lt;server name&gt; &gt;&gt; SQL Server Agent &gt;&gt; Jobs. Create, modify and delete jobs to implement the backup schedule. (Alternatively, this may done using T-SQL code.)
 
Correct any issues that have been causing backups to fail.
 
Test the restoration of the database at least once a year; correct any issues that cause it to fail. Maintain a record of these tests.</fixtext><fix id="F-73489r1_fix" /><check system="C-67955r1_chk"><check-content-ref name="M" href="DPMS_XCCDF_Benchmark_MS_SQL_Server_2014_Database_STIG.xml" /><check-content>Review the system security plan (SSP) to determine whether the database is static, the recovery model to be used, the backup schedule, and the plan for testing database restoration. If the SSP does not state that the database is static, assume that it is not static. If any of the other information is absent, this is a finding.
 
If the database is not static, but the documented recovery model is Simple, this is a finding.
 
If the database is not static, and the documented recovery model is Bulk Logged, but the justification and authorization for this are not documented, this is a finding.
 
In SQL Server Management Studio, Object Explorer, right-click on the name of the database; select Properties. Select the Options page.
 
Observe the Recovery Model field, near the top of the page. If this does not match the documented recovery model, this is a finding.
 
In Object Explorer, expand &lt;server name&gt; &gt;&gt; SQL Server Agent &gt;&gt; Jobs.
 
Review the jobs set up to implement the backup plan. If they are absent, this is a finding.
 
Right-click on each backup job; select View History. If the history indicates a pattern of job failures, this is a finding.
 
Review evidence that database recovery is tested annually or more often, and that the most recent test was successful. If not, this is a finding.</check-content></check></Rule></Group><Group id="V-67381"><title>SRG-APP-000231-DB-000154</title><description>&lt;GroupDescription&gt;&lt;/GroupDescription&gt;</description><Rule id="SV-81871r1_rule" severity="medium" weight="10.0"><version>SQL4-00-024100</version><title>The Database Master Key must be encrypted by the Service Master Key, where a Database Master Key is required and another encryption method has not been specified.</title><description>&lt;VulnDiscussion&gt;When not encrypted by the Service Master Key, system administrators or application administrators may access and use the Database Master Key to view sensitive data that they are not authorized to view. Where alternate encryption means are not feasible, encryption by the Service Master Key may be necessary. To help protect sensitive data from unauthorized access by DBAs, mitigations may be in order. Mitigations may include automatic alerts or other audit events when the Database Master Key is accessed outside of the application or by a DBA account.&lt;/VulnDiscussion&gt;&lt;FalsePositives&gt;&lt;/FalsePositives&gt;&lt;FalseNegatives&gt;&lt;/FalseNegatives&gt;&lt;Documentable&gt;false&lt;/Documentable&gt;&lt;Mitigations&gt;&lt;/Mitigations&gt;&lt;SeverityOverrideGuidance&gt;&lt;/SeverityOverrideGuidance&gt;&lt;PotentialImpacts&gt;&lt;/PotentialImpacts&gt;&lt;ThirdPartyTools&gt;&lt;/ThirdPartyTools&gt;&lt;MitigationControl&gt;&lt;/MitigationControl&gt;&lt;Responsibility&gt;&lt;/Responsibility&gt;&lt;IAControls&gt;&lt;/IAControls&gt;</description><reference><dc:title>DPMS Target SQL Server Database 2014</dc:title><dc:publisher>DISA</dc:publisher><dc:type>DPMS Target</dc:type><dc:subject>SQL Server Database 2014</dc:subject><dc:identifier>2637</dc:identifier></reference><ident system="http://iase.disa.mil/cci">CCI-001199</ident><fixtext fixref="F-73493r1_fix">Where possible, encrypt the Database Master Key with a password known only to the application administrator. Where not possible, configure additional audit events or alerts to detect unauthorized access to the Database Master Key by users not authorized to view sensitive data.</fixtext><fix id="F-73493r1_fix" /><check system="C-67959r1_chk"><check-content-ref name="M" href="DPMS_XCCDF_Benchmark_MS_SQL_Server_2014_Database_STIG.xml" /><check-content>If no databases require encryption, this is not a finding.
 
From the query prompt:
SELECT name
FROM [master].sys.databases
WHERE is_master_key_encrypted_by_server = 1
AND owner_sid &lt;&gt; 1
AND state = 0;
(Note that this query assumes that the [sa] account is not used as the owner of application databases, in keeping with other STIG guidance. If this is not the case, modify the query accordingly.)
 
If no databases are returned by the query, this is not a finding.
 
For any databases returned, verify in the System Security Plan that encryption of the Database Master Key using the Service Master Key is acceptable and approved by the Information Owner, and the encrypted data does not require additional protections to deter or detect DBA access. If not approved, this is a finding.
 
If approved and additional protections are required, then verify the additional requirements are in place in accordance with the System Security Plan. These may include additional auditing on access of the Database Master Key with alerts or other automated monitoring.
 
If the additional requirements are not in place, this is a finding.</check-content></check></Rule></Group><Group id="V-67383"><title>SRG-APP-000231-DB-000154</title><description>&lt;GroupDescription&gt;&lt;/GroupDescription&gt;</description><Rule id="SV-81873r1_rule" severity="medium" weight="10.0"><version>SQL4-00-024200</version><title>Database Master Key passwords must not be stored in credentials within the database.</title><description>&lt;VulnDiscussion&gt;Storage of the Database Master Key password in a database credential allows decryption of sensitive data by privileged users who may not have a need-to-know requirement to access the data.&lt;/VulnDiscussion&gt;&lt;FalsePositives&gt;&lt;/FalsePositives&gt;&lt;FalseNegatives&gt;&lt;/FalseNegatives&gt;&lt;Documentable&gt;false&lt;/Documentable&gt;&lt;Mitigations&gt;&lt;/Mitigations&gt;&lt;SeverityOverrideGuidance&gt;&lt;/SeverityOverrideGuidance&gt;&lt;PotentialImpacts&gt;&lt;/PotentialImpacts&gt;&lt;ThirdPartyTools&gt;&lt;/ThirdPartyTools&gt;&lt;MitigationControl&gt;&lt;/MitigationControl&gt;&lt;Responsibility&gt;&lt;/Responsibility&gt;&lt;IAControls&gt;&lt;/IAControls&gt;</description><reference><dc:title>DPMS Target SQL Server Database 2014</dc:title><dc:publisher>DISA</dc:publisher><dc:type>DPMS Target</dc:type><dc:subject>SQL Server Database 2014</dc:subject><dc:identifier>2637</dc:identifier></reference><ident system="http://iase.disa.mil/cci">CCI-001199</ident><fixtext fixref="F-73495r1_fix">Use the stored procedure sp_control_dbmasterkey_password to remove any credentials that
store Database Master Key passwords.
From the query prompt:
EXEC SP_CONTROL_DBMASTERKEY_PASSWORD @db_name = '&lt;database name&gt;', @action
= N'drop'</fixtext><fix id="F-73495r1_fix" /><check system="C-67961r1_chk"><check-content-ref name="M" href="DPMS_XCCDF_Benchmark_MS_SQL_Server_2014_Database_STIG.xml" /><check-content>From the query prompt:
SELECT COUNT(credential_id)
FROM [master].sys.master_key_passwords
 
If count is not 0, this is a finding.</check-content></check></Rule></Group><Group id="V-67385"><title>SRG-APP-000231-DB-000154</title><description>&lt;GroupDescription&gt;&lt;/GroupDescription&gt;</description><Rule id="SV-81875r2_rule" severity="medium" weight="10.0"><version>SQL4-00-024300</version><title>Symmetric keys (other than the database master key) must use a DoD certificate to encrypt the key.</title><description>&lt;VulnDiscussion&gt;Data within the database is protected by use of encryption. The symmetric keys are critical for this process. If the symmetric keys were to be compromised the data could be disclosed to unauthorized personnel.
 
The database master key is exempt, as a password must be supplied when creating it.&lt;/VulnDiscussion&gt;&lt;FalsePositives&gt;&lt;/FalsePositives&gt;&lt;FalseNegatives&gt;&lt;/FalseNegatives&gt;&lt;Documentable&gt;false&lt;/Documentable&gt;&lt;Mitigations&gt;&lt;/Mitigations&gt;&lt;SeverityOverrideGuidance&gt;&lt;/SeverityOverrideGuidance&gt;&lt;PotentialImpacts&gt;&lt;/PotentialImpacts&gt;&lt;ThirdPartyTools&gt;&lt;/ThirdPartyTools&gt;&lt;MitigationControl&gt;&lt;/MitigationControl&gt;&lt;Responsibility&gt;&lt;/Responsibility&gt;&lt;IAControls&gt;&lt;/IAControls&gt;</description><reference><dc:title>DPMS Target SQL Server Database 2014</dc:title><dc:publisher>DISA</dc:publisher><dc:type>DPMS Target</dc:type><dc:subject>SQL Server Database 2014</dc:subject><dc:identifier>2637</dc:identifier></reference><ident system="http://iase.disa.mil/cci">CCI-001199</ident><fixtext fixref="F-73497r2_fix">Configure or alter symmetric keys to encrypt keys with certificates or authorized asymmetric keys.
In a query tool:
     ALTER SYMMETRIC KEY &lt;key name&gt; ADD ENCRYPTION BY CERTIFICATE &lt;certificate name&gt;;
     ALTER SYMMETRIC KEY &lt;key name&gt; DROP ENCRYPTION BY &lt;password, symmetric key or asymmetric key&gt;;
 
The symmetric key must specify a certificate or asymmetric key for encryption.</fixtext><fix id="F-73497r2_fix" /><check system="C-67963r2_chk"><check-content-ref name="M" href="DPMS_XCCDF_Benchmark_MS_SQL_Server_2014_Database_STIG.xml" /><check-content>In a query tool:
USE &lt;database name&gt;;
GO
SELECT s.name, k.crypt_type_desc
FROM sys.symmetric_keys s, sys.key_encryptions k
WHERE s.symmetric_key_id = k.key_id
AND s.name &lt;&gt; '##MS_DatabaseMasterKey##'
AND k.crypt_type IN ('ESKP', 'ESKS')
ORDER BY s.name, k.crypt_type_desc;
GO
 
Review any symmetric keys that have been defined against the System Security Plan.
 
If any keys are defined that are not documented in the System Security Plan, this is a finding.
 
Review the System Security Plan to review the encryption mechanism specified for each symmetric key. If the method does not indicate use of certificates, this is a finding.
 
If the certificate specified is not a DoD PKI certificate, this is a finding.</check-content></check></Rule></Group><Group id="V-67389"><title>SRG-APP-000243-DB-000128</title><description>&lt;GroupDescription&gt;&lt;/GroupDescription&gt;</description><Rule id="SV-81879r1_rule" severity="medium" weight="10.0"><version>SQL4-00-021800</version><title>Database contents must be protected from unauthorized and unintended information transfer by enforcement of a data-transfer policy.</title><description>&lt;VulnDiscussion&gt;The purpose of this control is to prevent information, including encrypted representations of information, produced by the actions of a prior user/role (or the actions of a process acting on behalf of a prior user/role) from being available to any current user/role (or current process) that obtains access to a shared system resource (e.g., registers, main memory, secondary storage) after the resource has been released back to the information system. Control of information in shared resources is also referred to as object reuse.
 
Data used for the development and testing of applications often involves copying data from production. It is important that specific procedures exist for this process, so copies of sensitive data are not misplaced or left in a temporary location without the proper controls.&lt;/VulnDiscussion&gt;&lt;FalsePositives&gt;&lt;/FalsePositives&gt;&lt;FalseNegatives&gt;&lt;/FalseNegatives&gt;&lt;Documentable&gt;false&lt;/Documentable&gt;&lt;Mitigations&gt;&lt;/Mitigations&gt;&lt;SeverityOverrideGuidance&gt;&lt;/SeverityOverrideGuidance&gt;&lt;PotentialImpacts&gt;&lt;/PotentialImpacts&gt;&lt;ThirdPartyTools&gt;&lt;/ThirdPartyTools&gt;&lt;MitigationControl&gt;&lt;/MitigationControl&gt;&lt;Responsibility&gt;&lt;/Responsibility&gt;&lt;IAControls&gt;&lt;/IAControls&gt;</description><reference><dc:title>DPMS Target SQL Server Database 2014</dc:title><dc:publisher>DISA</dc:publisher><dc:type>DPMS Target</dc:type><dc:subject>SQL Server Database 2014</dc:subject><dc:identifier>2637</dc:identifier></reference><ident system="http://iase.disa.mil/cci">CCI-001090</ident><fixtext fixref="F-73501r1_fix">Create and document a process for moving data from production to development/test systems and follow the process.
 
Modify any code used for moving data from production to development/test systems to ensure copies of production data are not left in unsecured locations.</fixtext><fix id="F-73501r1_fix" /><check system="C-67967r1_chk"><check-content-ref name="M" href="DPMS_XCCDF_Benchmark_MS_SQL_Server_2014_Database_STIG.xml" /><check-content>Verify there are proper procedures in place for the transfer of development/test data from production. Review any scripts or code that exists for the movement of production data to development/test and verify copies of production data are not left in unprotected locations.
 
If there is no documented procedure for data movement from production to development/test, this is a finding.
 
If data movement code that copies from production to development/test does exist and leaves any copies of production data in unprotected locations, this is a finding.</check-content></check></Rule></Group><Group id="V-67391"><title>SRG-APP-000251-DB-000160</title><description>&lt;GroupDescription&gt;&lt;/GroupDescription&gt;</description><Rule id="SV-81881r2_rule" severity="medium" weight="10.0"><version>SQL4-00-022500</version><title>SQL Server must check the validity of all data inputs except those specifically identified by the organization.</title><description>&lt;VulnDiscussion&gt;Invalid user input occurs when a user inserts data or characters into an application’s data entry fields and the application is unprepared to process that data. This results in unanticipated application behavior potentially leading to an application or information system compromise. Invalid user input is one of the primary methods employed when attempting to compromise an application.
 
SQL Server needs to validate the data user’s attempt to input to the application for processing. Rules for checking the valid syntax and semantics of information system inputs (e.g., character set, length, numerical range, acceptable values) are in place to verify inputs match specified definitions for format and content. Inputs passed to interpreters are prescreened to prevent the content from being unintentionally interpreted as commands.
 
A poorly designed database system can have many problems. A common issue with these types of systems is the missed opportunity to use constraints.
 
This calls for inspection of application source code, which will require collaboration with the application developers. It is recognized that in many cases, the database administrator (DBA) is organizationally separate from the application developers and may have limited, if any, access to source code. Nevertheless, protections of this type are so important to the secure operation of databases that they must not be ignored. At a minimum, the DBA must attempt to obtain assurances from the development organization that this issue has been addressed and must document what has been discovered.&lt;/VulnDiscussion&gt;&lt;FalsePositives&gt;&lt;/FalsePositives&gt;&lt;FalseNegatives&gt;&lt;/FalseNegatives&gt;&lt;Documentable&gt;false&lt;/Documentable&gt;&lt;Mitigations&gt;&lt;/Mitigations&gt;&lt;SeverityOverrideGuidance&gt;&lt;/SeverityOverrideGuidance&gt;&lt;PotentialImpacts&gt;&lt;/PotentialImpacts&gt;&lt;ThirdPartyTools&gt;&lt;/ThirdPartyTools&gt;&lt;MitigationControl&gt;&lt;/MitigationControl&gt;&lt;Responsibility&gt;&lt;/Responsibility&gt;&lt;IAControls&gt;&lt;/IAControls&gt;</description><reference><dc:title>DPMS Target SQL Server Database 2014</dc:title><dc:publisher>DISA</dc:publisher><dc:type>DPMS Target</dc:type><dc:subject>SQL Server Database 2014</dc:subject><dc:identifier>2637</dc:identifier></reference><ident system="http://iase.disa.mil/cci">CCI-001310</ident><fixtext fixref="F-73503r1_fix">Use triggers, constraints, foreign keys, etc. to validate data input.
 
Modify SQL Server to properly use the correct column data types as required in the database.</fixtext><fix id="F-73503r1_fix" /><check system="C-67969r1_chk"><check-content-ref name="M" href="DPMS_XCCDF_Benchmark_MS_SQL_Server_2014_Database_STIG.xml" /><check-content>Review DBMS code (stored procedures, functions, triggers), application code, settings, column and field definitions, and constraints to determine whether the database is protected against invalid input.
 
If code exists that allows invalid data to be acted upon or input into the database, this is a finding.
 
If column/field definitions are not reflective of the data, this is a finding.
 
If columns/fields do not contain constraints and validity checking where required, this is a finding.
 
Where a column/field is noted in the system documentation as necessarily free-form, even though its name and context suggest that it should be strongly typed and constrained, the absence of these protections is not a finding.
 
Where a column/field is clearly identified by name, caption or context as Notes, Comments, Description, Text, etc., the absence of these protections is not a finding.</check-content></check></Rule></Group><Group id="V-67393"><title>SRG-APP-000251-DB-000391</title><description>&lt;GroupDescription&gt;&lt;/GroupDescription&gt;</description><Rule id="SV-81883r2_rule" severity="medium" weight="10.0"><version>SQL4-00-031500</version><title>The DBMS and associated applications must reserve the use of dynamic code execution for situations that require it.</title><description>&lt;VulnDiscussion&gt;With respect to database management systems, one class of threat is known as SQL Injection, or more generally, code injection. It takes advantage of the dynamic execution capabilities of various programming languages, including dialects of SQL. In such cases, the attacker deduces the manner in which SQL statements are being processed, either from inside knowledge or by observing system behavior in response to invalid inputs. When the attacker identifies scenarios where SQL queries are being assembled by application code (which may be within the database or separate from it) and executed dynamically, the attacker is then able to craft input strings that subvert the intent of the query. Potentially, the attacker can gain unauthorized access to data, including security settings, and severely corrupt or destroy the database.
 
The principal protection against code injection is not to use dynamic execution except where it provides necessary functionality that cannot be utilized otherwise. Use strongly typed data items rather than general-purpose strings as input parameters to task-specific, pre-compiled stored procedures and functions (and triggers).
 
This calls for inspection of application source code, which will require collaboration with the application developers. It is recognized that in many cases, the database administrator (DBA) is organizationally separate from the application developers and may have limited, if any, access to source code. Nevertheless, protections of this type are so important to the secure operation of databases that they must not be ignored. At a minimum, the DBA must attempt to obtain assurances from the development organization that this issue has been addressed and must document what has been discovered&lt;/VulnDiscussion&gt;&lt;FalsePositives&gt;&lt;/FalsePositives&gt;&lt;FalseNegatives&gt;&lt;/FalseNegatives&gt;&lt;Documentable&gt;false&lt;/Documentable&gt;&lt;Mitigations&gt;&lt;/Mitigations&gt;&lt;SeverityOverrideGuidance&gt;&lt;/SeverityOverrideGuidance&gt;&lt;PotentialImpacts&gt;&lt;/PotentialImpacts&gt;&lt;ThirdPartyTools&gt;&lt;/ThirdPartyTools&gt;&lt;MitigationControl&gt;&lt;/MitigationControl&gt;&lt;Responsibility&gt;&lt;/Responsibility&gt;&lt;IAControls&gt;&lt;/IAControls&gt;</description><reference><dc:title>DPMS Target SQL Server Database 2014</dc:title><dc:publisher>DISA</dc:publisher><dc:type>DPMS Target</dc:type><dc:subject>SQL Server Database 2014</dc:subject><dc:identifier>2637</dc:identifier></reference><ident system="http://iase.disa.mil/cci">CCI-001310</ident><fixtext fixref="F-73505r1_fix">Where dynamic code execution is employed in circumstances where the objective could practically be satisfied by static execution with strongly typed parameters, modify the code to do so.</fixtext><fix id="F-73505r1_fix" /><check system="C-67971r1_chk"><check-content-ref name="M" href="DPMS_XCCDF_Benchmark_MS_SQL_Server_2014_Database_STIG.xml" /><check-content>Review source code in the database (stored procedures, functions, triggers) and application source code, to identify cases of dynamic code execution.
 
If dynamic code execution is employed in circumstances where the objective could practically be satisfied by static execution with strongly typed parameters, this is a finding.</check-content></check></Rule></Group><Group id="V-67395"><title>SRG-APP-000251-DB-000392</title><description>&lt;GroupDescription&gt;&lt;/GroupDescription&gt;</description><Rule id="SV-81885r2_rule" severity="medium" weight="10.0"><version>SQL4-00-031600</version><title>The DBMS and associated applications, when making use of dynamic code execution, must scan input data for invalid values that may indicate a code injection attack.</title><description>&lt;VulnDiscussion&gt;With respect to database management systems, one class of threat is known as SQL Injection, or more generally, code injection. It takes advantage of the dynamic execution capabilities of various programming languages, including dialects of SQL. In such cases, the attacker deduces the manner in which SQL statements are being processed, either from inside knowledge or by observing system behavior in response to invalid inputs. When the attacker identifies scenarios where SQL queries are being assembled by application code (which may be within the database or separate from it) and executed dynamically, the attacker is then able to craft input strings that subvert the intent of the query. Potentially, the attacker can gain unauthorized access to data, including security settings, and severely corrupt or destroy the database.
 
The principal protection against code injection is not to use dynamic execution except where it provides necessary functionality that cannot be utilized otherwise. Use strongly typed data items rather than general-purpose strings as input parameters to task-specific, pre-compiled stored procedures and functions (and triggers).
 
When dynamic execution is necessary, ways to mitigate the risk include the following, which should be implemented both in the on-screen application and at the database level, in the stored procedures:
-- Allow strings as input only when necessary.
-- Rely on data typing to validate numbers, dates, etc. Do not accept invalid values. If substituting other values for them, think carefully about whether this could be subverted.
-- Limit the size of input strings to what is truly necessary.
-- If single quotes/apostrophes, double quotes, semicolons, equals signs, angle brackets, or square brackets will never be valid as input, reject them.
-- If comment markers will never be valid as input, reject them. In SQL, these are -- or /* */
-- If HTML and XML tags, entities, comments, etc., will never be valid, reject them.
-- If wildcards are present, reject them unless truly necessary. In SQL these are the underscore and the percentage sign, and the word ESCAPE is also a clue that wildcards are in use.
-- If SQL key words, such as SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, DROP, ESCAPE, UNION, GRANT, REVOKE, DENY, MODIFY will never be valid, reject them. Use case-insensitive comparisons when searching for these. Bear in mind that some of these words, particularly Grant (as a person's name), could also be valid input.
-- If there are range limits on the values that may be entered, enforce those limits.
-- Institute procedures for inspection of programs for correct use of dynamic coding, by a party other than the developer.
-- Conduct rigorous testing of program modules that use dynamic coding, searching for ways to subvert the intended use.
-- Record the inspection and testing in the system documentation.
-- Bear in mind that all this applies not only to screen input, but also to the values in an incoming message to a web service or to a stored procedure called by a software component that has not itself been hardened in these ways. Not only can the caller be subject to such vulnerabilities; it may itself be the attacker.
 
This calls for inspection of application source code, which will require collaboration with the application developers. It is recognized that in many cases, the database administrator (DBA) is organizationally separate from the application developers and may have limited, if any, access to source code. Nevertheless, protections of this type are so important to the secure operation of databases that they must not be ignored. At a minimum, the DBA must attempt to obtain assurances from the development organization that this issue has been addressed and must document what has been discovered&lt;/VulnDiscussion&gt;&lt;FalsePositives&gt;&lt;/FalsePositives&gt;&lt;FalseNegatives&gt;&lt;/FalseNegatives&gt;&lt;Documentable&gt;false&lt;/Documentable&gt;&lt;Mitigations&gt;&lt;/Mitigations&gt;&lt;SeverityOverrideGuidance&gt;&lt;/SeverityOverrideGuidance&gt;&lt;PotentialImpacts&gt;&lt;/PotentialImpacts&gt;&lt;ThirdPartyTools&gt;&lt;/ThirdPartyTools&gt;&lt;MitigationControl&gt;&lt;/MitigationControl&gt;&lt;Responsibility&gt;&lt;/Responsibility&gt;&lt;IAControls&gt;&lt;/IAControls&gt;</description><reference><dc:title>DPMS Target SQL Server Database 2014</dc:title><dc:publisher>DISA</dc:publisher><dc:type>DPMS Target</dc:type><dc:subject>SQL Server Database 2014</dc:subject><dc:identifier>2637</dc:identifier></reference><ident system="http://iase.disa.mil/cci">CCI-001310</ident><fixtext fixref="F-73507r1_fix">Where dynamic code execution is used, modify the code to implement protections against code injection.</fixtext><fix id="F-73507r1_fix" /><check system="C-67973r1_chk"><check-content-ref name="M" href="DPMS_XCCDF_Benchmark_MS_SQL_Server_2014_Database_STIG.xml" /><check-content>Review source code in the database (stored procedures, functions, triggers) and application source code to identify cases of dynamic code execution.
 
If dynamic code execution is employed without protective measures against code injection, this is a finding.</check-content></check></Rule></Group><Group id="V-67397"><title>SRG-APP-000266-DB-000162</title><description>&lt;GroupDescription&gt;&lt;/GroupDescription&gt;</description><Rule id="SV-81887r2_rule" severity="medium" weight="10.0"><version>SQL4-00-022800</version><title>The DBMS and associated applications must provide non-privileged users with error messages that provide information necessary for corrective actions without revealing information that could be exploited by adversaries.</title><description>&lt;VulnDiscussion&gt;Any DBMS or associated application providing too much information in error messages on the screen or printout risks compromising the data and security of the system. The structure and content of error messages need to be carefully considered by the organization and development team.
 
Databases can inadvertently provide a wealth of information to an attacker through improperly handled error messages. In addition to sensitive business or personal information, database errors can provide host names, IP addresses, user names, and other system information not required for end-user troubleshooting but very useful to someone targeting the system.
 
Carefully consider the structure/content of error messages. The extent to which information systems are able to identify and handle error conditions is guided by organizational policy and operational requirements. Information that could be exploited by adversaries includes, for example, logon attempts with passwords entered by mistake as the username, mission/business information that can be derived from (if not stated explicitly by) information recorded, and personal information, such as account numbers, social security numbers, and credit card numbers.
 
It is important that detailed error messages be visible only to those who are authorized to view them; that general users receive only generalized acknowledgment that errors have occurred; and that these generalized messages appear only when relevant to the user's task. For example, a message along the lines of, "An error has occurred. Unable to save your changes. If this problem persists, please contact your help desk" would be relevant. A message such as "Warning: your transaction generated a large number of page splits" would likely not be relevant. "ABGQ is not a valid widget code" would be appropriate; but "The INSERT statement conflicted with the FOREIGN KEY constraint "WidgetTransactionFK". The conflict occurred in database "DB7", table "dbo.WidgetMaster", column 'WidgetCode'" would not, as it reveals too much about the database structure.
 
This calls for inspection of application source code, which will require collaboration with the application developers. It is recognized that in many cases, the database administrator (DBA) is organizationally separate from the application developers and may have limited, if any, access to source code. Nevertheless, protections of this type are so important to the secure operation of databases that they must not be ignored. At a minimum, the DBA must attempt to obtain assurances from the development organization that this issue has been addressed and must document what has been discovered.&lt;/VulnDiscussion&gt;&lt;FalsePositives&gt;&lt;/FalsePositives&gt;&lt;FalseNegatives&gt;&lt;/FalseNegatives&gt;&lt;Documentable&gt;false&lt;/Documentable&gt;&lt;Mitigations&gt;&lt;/Mitigations&gt;&lt;SeverityOverrideGuidance&gt;&lt;/SeverityOverrideGuidance&gt;&lt;PotentialImpacts&gt;&lt;/PotentialImpacts&gt;&lt;ThirdPartyTools&gt;&lt;/ThirdPartyTools&gt;&lt;MitigationControl&gt;&lt;/MitigationControl&gt;&lt;Responsibility&gt;&lt;/Responsibility&gt;&lt;IAControls&gt;&lt;/IAControls&gt;</description><reference><dc:title>DPMS Target SQL Server Database 2014</dc:title><dc:publisher>DISA</dc:publisher><dc:type>DPMS Target</dc:type><dc:subject>SQL Server Database 2014</dc:subject><dc:identifier>2637</dc:identifier></reference><ident system="http://iase.disa.mil/cci">CCI-001312</ident><fixtext fixref="F-73509r1_fix">Configure DBMS settings, custom database code, and associated application code not to divulge sensitive information or information useful for system identification in error messages that are displayed to general users.</fixtext><fix id="F-73509r1_fix" /><check system="C-67975r1_chk"><check-content-ref name="M" href="DPMS_XCCDF_Benchmark_MS_SQL_Server_2014_Database_STIG.xml" /><check-content>Review application behavior and custom database code (stored procedures; triggers), to determine whether error messages contain information beyond what is needed for explaining the issue to general users.
 
If database error messages contain PII data, sensitive business data, or information useful for identifying the host system or database structure, this is a finding.</check-content></check></Rule></Group><Group id="V-67399"><title>SRG-APP-000267-DB-000163</title><description>&lt;GroupDescription&gt;&lt;/GroupDescription&gt;</description><Rule id="SV-81889r2_rule" severity="medium" weight="10.0"><version>SQL4-00-022900</version><title>SQL Server must reveal detailed error messages only to the ISSO, ISSM (or their designees), SA and DBA.</title><description>&lt;VulnDiscussion&gt;If the DBMS provides too much information in error logs and administrative messages to the screen, this could lead to compromise. The structure and content of error messages need to be carefully considered by the organization and development team. The extent to which the information system is able to identify and handle error conditions is guided by organizational policy and operational requirements.
 
Some default DBMS error messages can contain information that could aid an attacker in, among others things, identifying the database type, host address, or state of the database. Custom errors may contain sensitive customer information.
 
It is important that detailed error messages be visible only to those who are authorized to view them; that general users receive only generalized acknowledgment that errors have occurred; and that these generalized messages appear only when relevant to the user's task. For example, a message along the lines of, "An error has occurred. Unable to save your changes. If this problem persists, please contact your help desk" would be relevant. A message such as "Warning: your transaction generated a large number of page splits" would likely not be relevant. "ABGQ is not a valid widget code" would be appropriate; but "The INSERT statement conflicted with the FOREIGN KEY constraint "WidgetTransactionFK". The conflict occurred in database "DB7", table "dbo.WidgetMaster", column 'WidgetCode'" would not, as it reveals too much about the database structure.
 
Administrative users authorized to review detailed error messages typically are the ISSO, ISSM, SA and DBA. Other individuals or roles may be specified according to organization-specific needs, with appropriate approval.
 
This calls for inspection of application source code, which will require collaboration with the application developers. It is recognized that in many cases, the database administrator (DBA) is organizationally separate from the application developers and may have limited, if any, access to source code. Nevertheless, protections of this type are so important to the secure operation of databases that they must not be ignored. At a minimum, the DBA must attempt to obtain assurances from the development organization that this issue has been addressed and must document what has been discovered.&lt;/VulnDiscussion&gt;&lt;FalsePositives&gt;&lt;/FalsePositives&gt;&lt;FalseNegatives&gt;&lt;/FalseNegatives&gt;&lt;Documentable&gt;false&lt;/Documentable&gt;&lt;Mitigations&gt;&lt;/Mitigations&gt;&lt;SeverityOverrideGuidance&gt;&lt;/SeverityOverrideGuidance&gt;&lt;PotentialImpacts&gt;&lt;/PotentialImpacts&gt;&lt;ThirdPartyTools&gt;&lt;/ThirdPartyTools&gt;&lt;MitigationControl&gt;&lt;/MitigationControl&gt;&lt;Responsibility&gt;&lt;/Responsibility&gt;&lt;IAControls&gt;&lt;/IAControls&gt;</description><reference><dc:title>DPMS Target SQL Server Database 2014</dc:title><dc:publisher>DISA</dc:publisher><dc:type>DPMS Target</dc:type><dc:subject>SQL Server Database 2014</dc:subject><dc:identifier>2637</dc:identifier></reference><ident system="http://iase.disa.mil/cci">CCI-001314</ident><fixtext fixref="F-73511r1_fix">Configure audit logging, tracing and/or custom code in the database or application to record detailed error messages generated by SQL Server, for review by authorized personnel.</fixtext><fix id="F-73511r1_fix" /><check system="C-67977r1_chk"><check-content-ref name="M" href="DPMS_XCCDF_Benchmark_MS_SQL_Server_2014_Database_STIG.xml" /><check-content>Review application behavior, custom database code (stored procedures; triggers) and DBMS audit and trace settings, to determine whether detailed error messages are logged or stored for review by authorized personnel.
 
If detailed error messages are not available to individuals authorized to view them, this is a finding.</check-content></check></Rule></Group><Group id="V-67401"><title>SRG-APP-000311-DB-000308</title><description>&lt;GroupDescription&gt;&lt;/GroupDescription&gt;</description><Rule id="SV-81891r2_rule" severity="medium" weight="10.0"><version>SQL4-00-031900</version><title>When supporting applications that require security labeling of data, SQL Server must associate organization-defined types of security labels having organization-defined security label values with information in storage.</title><description>&lt;VulnDiscussion&gt;Without the association of security labels to information, there is no basis for the DBMS to make security-related access-control decisions.
 
Security labels are abstractions representing the basic properties or characteristics of an entity (e.g., subjects and objects) with respect to safeguarding information.
 
These labels are typically associated with internal data structures (e.g., tables, rows) within the database and are used to enable the implementation of access control and flow control policies, reflect special dissemination, handling or distribution instructions, or support other aspects of the information security policy.
 
One example includes marking data as classified or FOUO. These security labels may be assigned manually or during data processing, but, either way, it is imperative these assignments are maintained while the data is in storage. If the security labels are lost when the data is stored, there is the risk of a data compromise.
 
 
SQL Server does not include security labeling as a standard or licensable feature. Earlier releases of this STIG suggested using the SQL Server Label Security Toolkit, from codeplex.com. However, codeplex.com has been shut down, and it is unclear whether the Toolkit is still supported. If the organization does have access to the Toolkit, it may still be used, provided the organization accepts responsibility for its support. Other implementations may also exist. Custom application code is also a viable way to implement a solution.&lt;/VulnDiscussion&gt;&lt;FalsePositives&gt;&lt;/FalsePositives&gt;&lt;FalseNegatives&gt;&lt;/FalseNegatives&gt;&lt;Documentable&gt;false&lt;/Documentable&gt;&lt;Mitigations&gt;&lt;/Mitigations&gt;&lt;SeverityOverrideGuidance&gt;&lt;/SeverityOverrideGuidance&gt;&lt;PotentialImpacts&gt;&lt;/PotentialImpacts&gt;&lt;ThirdPartyTools&gt;&lt;/ThirdPartyTools&gt;&lt;MitigationControl&gt;&lt;/MitigationControl&gt;&lt;Responsibility&gt;&lt;/Responsibility&gt;&lt;IAControls&gt;&lt;/IAControls&gt;</description><reference><dc:title>DPMS Target SQL Server Database 2014</dc:title><dc:publisher>DISA</dc:publisher><dc:type>DPMS Target</dc:type><dc:subject>SQL Server Database 2014</dc:subject><dc:identifier>2637</dc:identifier></reference><ident system="http://iase.disa.mil/cci">CCI-002262</ident><fixtext fixref="F-73513r2_fix">Develop SQL or application code or acquire a third party tool to perform data labeling.</fixtext><fix id="F-73513r2_fix" /><check system="C-67979r1_chk"><check-content-ref name="M" href="DPMS_XCCDF_Benchmark_MS_SQL_Server_2014_Database_STIG.xml" /><check-content>If security labeling is not required, this is not a finding.
 
If security labeling requirements have been specified, but the security labeling is not implemented or does not reliably maintain labels on information in storage, this is a finding.</check-content></check></Rule></Group><Group id="V-67403"><title>SRG-APP-000313-DB-000309</title><description>&lt;GroupDescription&gt;&lt;/GroupDescription&gt;</description><Rule id="SV-81893r2_rule" severity="medium" weight="10.0"><version>SQL4-00-032000</version><title>When supporting applications that require security labeling of data, SQL Server must associate organization-defined types of security labels having organization-defined security label values with information in process.</title><description>&lt;VulnDiscussion&gt;Without the association of security labels to information, there is no basis for the DBMS to make security-related access-control decisions.
 
Security labels are abstractions representing the basic properties or characteristics of an entity (e.g., subjects and objects) with respect to safeguarding information.
 
These labels are typically associated with internal data structures (e.g., tables, rows) within the database and are used to enable the implementation of access control and flow control policies, reflect special dissemination, handling or distribution instructions, or support other aspects of the information security policy.
 
One example includes marking data as classified or FOUO. These security labels may be assigned manually or during data processing, but, either way, it is imperative these assignments are maintained while the data is in storage. If the security labels are lost when the data is stored, there is the risk of a data compromise.
 
SQL Server does not include security labeling as a standard or licensable feature. Earlier releases of this STIG suggested using the SQL Server Label Security Toolkit, from codeplex.com. However, codeplex.com has been shut down, and it is unclear whether the Toolkit is still supported. If the organization does have access to the Toolkit, it may still be used, provided the organization accepts responsibility for its support. Other implementations may also exist. Custom application code is also a viable way to implement a solution.&lt;/VulnDiscussion&gt;&lt;FalsePositives&gt;&lt;/FalsePositives&gt;&lt;FalseNegatives&gt;&lt;/FalseNegatives&gt;&lt;Documentable&gt;false&lt;/Documentable&gt;&lt;Mitigations&gt;&lt;/Mitigations&gt;&lt;SeverityOverrideGuidance&gt;&lt;/SeverityOverrideGuidance&gt;&lt;PotentialImpacts&gt;&lt;/PotentialImpacts&gt;&lt;ThirdPartyTools&gt;&lt;/ThirdPartyTools&gt;&lt;MitigationControl&gt;&lt;/MitigationControl&gt;&lt;Responsibility&gt;&lt;/Responsibility&gt;&lt;IAControls&gt;&lt;/IAControls&gt;</description><reference><dc:title>DPMS Target SQL Server Database 2014</dc:title><dc:publisher>DISA</dc:publisher><dc:type>DPMS Target</dc:type><dc:subject>SQL Server Database 2014</dc:subject><dc:identifier>2637</dc:identifier></reference><ident system="http://iase.disa.mil/cci">CCI-002263</ident><fixtext fixref="F-73515r2_fix">Develop SQL or application code or acquire a third party tool to perform data labeling.</fixtext><fix id="F-73515r2_fix" /><check system="C-67981r1_chk"><check-content-ref name="M" href="DPMS_XCCDF_Benchmark_MS_SQL_Server_2014_Database_STIG.xml" /><check-content>If security labeling is not required, this is not a finding.
 
If security labeling requirements have been specified, but the security labeling is not implemented or does not reliably maintain labels on information in process, this is a finding.</check-content></check></Rule></Group><Group id="V-67405"><title>SRG-APP-000314-DB-000310</title><description>&lt;GroupDescription&gt;&lt;/GroupDescription&gt;</description><Rule id="SV-81895r2_rule" severity="medium" weight="10.0"><version>SQL4-00-032100</version><title>When supporting applications that require security labeling of data, SQL Server must associate organization-defined types of security labels having organization-defined security label values with information in transmission.</title><description>&lt;VulnDiscussion&gt;Without the association of security labels to information, there is no basis for the DBMS to make security-related access-control decisions.
 
Security labels are abstractions representing the basic properties or characteristics of an entity (e.g., subjects and objects) with respect to safeguarding information.
 
These labels are typically associated with internal data structures (e.g., tables, rows) within the database and are used to enable the implementation of access control and flow control policies, reflect special dissemination, handling or distribution instructions, or support other aspects of the information security policy.
 
One example includes marking data as classified or FOUO. These security labels may be assigned manually or during data processing, but, either way, it is imperative these assignments are maintained while the data is in storage. If the security labels are lost when the data is stored, there is the risk of a data compromise.
 
SQL Server does not include security labeling as a standard or licensable feature. Earlier releases of this STIG suggested using the SQL Server Label Security Toolkit, from codeplex.com. However, codeplex.com has been shut down, and it is unclear whether the Toolkit is still supported. If the organization does have access to the Toolkit, it may still be used, provided the organization accepts responsibility for its support. Other implementations may also exist. Custom application code is also a viable way to implement a solution.&lt;/VulnDiscussion&gt;&lt;FalsePositives&gt;&lt;/FalsePositives&gt;&lt;FalseNegatives&gt;&lt;/FalseNegatives&gt;&lt;Documentable&gt;false&lt;/Documentable&gt;&lt;Mitigations&gt;&lt;/Mitigations&gt;&lt;SeverityOverrideGuidance&gt;&lt;/SeverityOverrideGuidance&gt;&lt;PotentialImpacts&gt;&lt;/PotentialImpacts&gt;&lt;ThirdPartyTools&gt;&lt;/ThirdPartyTools&gt;&lt;MitigationControl&gt;&lt;/MitigationControl&gt;&lt;Responsibility&gt;&lt;/Responsibility&gt;&lt;IAControls&gt;&lt;/IAControls&gt;</description><reference><dc:title>DPMS Target SQL Server Database 2014</dc:title><dc:publisher>DISA</dc:publisher><dc:type>DPMS Target</dc:type><dc:subject>SQL Server Database 2014</dc:subject><dc:identifier>2637</dc:identifier></reference><ident system="http://iase.disa.mil/cci">CCI-002264</ident><fixtext fixref="F-73517r3_fix">Develop SQL or application code or acquire a third party tool to perform data labeling.</fixtext><fix id="F-73517r3_fix" /><check system="C-67983r1_chk"><check-content-ref name="M" href="DPMS_XCCDF_Benchmark_MS_SQL_Server_2014_Database_STIG.xml" /><check-content>If security labeling is not required, this is not a finding.
 
If security labeling requirements have been specified, but the security labeling is not implemented or does not reliably maintain labels on information in transmission, this is a finding.</check-content></check></Rule></Group><Group id="V-67407"><title>SRG-APP-000375-DB-000323</title><description>&lt;GroupDescription&gt;&lt;/GroupDescription&gt;</description><Rule id="SV-81897r1_rule" severity="medium" weight="10.0"><version>SQL4-00-033700</version><title>Time stamps in database tables, intended for auditing or activity-tracking purposes, must include both date and time of day, with a minimum granularity of one second.</title><description>&lt;VulnDiscussion&gt;If time stamps are not consistently applied and there is no common time reference, it is difficult to perform forensic analysis, in audit files, trace files/tables, and application data tables.
 
Time stamps generated by SQL Server must include date and time, to a granularity of one second or finer. Time is commonly expressed in Coordinated Universal Time (UTC), a modern continuation of Greenwich Mean Time (GMT), or local time with an offset from UTC. Granularity of time measurements refers to the precision available in time stamp values. Granularity coarser than one second is not sufficient for audit trail purposes, and granularity finer than one second is recommended. Time stamp values are typically presented with three or more decimal places of seconds; however, the actual granularity may be coarser than the apparent precision. For example, SQL Server's GETDATE()/CURRENT_TMESTAMP values are presented to three decimal places, but the granularity is not one millisecond: it is about 1/300 of a second.
 
The data types that can be used for this purpose in SQL Server are:
DATETIME2 - precision variable from a whole second down to a ten-millionth (subject to the actual precision of the hardware and operating system)
DATETIMEOFFSET - as datetime2, together with local offset from UTC
DATE, together with TIME (same precision considerations as for datetime2)
DATETIME - precision 1/300 of a second
Character-string data types allowing for at least 20 characters are also permissible, but not recommended.
 
SQL Server built-in functions for retrieving current timestamps are: (high precision) sysdatetime(), sysdatetimeoffset(), sysutcdatetime(); (lower precision) CURRENT_TIMESTAMP or getdate(), getutcdate().
 
Ensure that values recorded for tracking purposes in data tables are correctly defined and maintained. (Design decisions about which tables require audit-trail or activity-tracking columns are outside the scope of this STIG. This requirement applies only to the data type and maintenance of such columns if they do exist.)
 
The SMALLDATETIME data type is not precise enough for this purpose. Although it gives the impression of including a seconds component, the seconds value is always "00".
 
SQL Server offers a data type called TIMESTAMP that is not a representation of date and time. Rather, it is a database state counter and does not correspond to calendar and clock time. This requirement does not refer to that meaning of TIMESTAMP. To avoid confusion, Microsoft recommends using the newer name for this data type, ROWVERSION, instead.&lt;/VulnDiscussion&gt;&lt;FalsePositives&gt;&lt;/FalsePositives&gt;&lt;FalseNegatives&gt;&lt;/FalseNegatives&gt;&lt;Documentable&gt;false&lt;/Documentable&gt;&lt;Mitigations&gt;&lt;/Mitigations&gt;&lt;SeverityOverrideGuidance&gt;&lt;/SeverityOverrideGuidance&gt;&lt;PotentialImpacts&gt;&lt;/PotentialImpacts&gt;&lt;ThirdPartyTools&gt;&lt;/ThirdPartyTools&gt;&lt;MitigationControl&gt;&lt;/MitigationControl&gt;&lt;Responsibility&gt;&lt;/Responsibility&gt;&lt;IAControls&gt;&lt;/IAControls&gt;</description><reference><dc:title>DPMS Target SQL Server Database 2014</dc:title><dc:publisher>DISA</dc:publisher><dc:type>DPMS Target</dc:type><dc:subject>SQL Server Database 2014</dc:subject><dc:identifier>2637</dc:identifier></reference><ident system="http://iase.disa.mil/cci">CCI-001889</ident><fixtext fixref="F-73519r1_fix">Modify applications and/or column/field definitions so that the time stamps in audit-trail and activity-tracking columns/fields in application data include date and time of day, to a granularity of one second or finer, and are recorded accurately.</fixtext><fix id="F-73519r1_fix" /><check system="C-67985r1_chk"><check-content-ref name="M" href="DPMS_XCCDF_Benchmark_MS_SQL_Server_2014_Database_STIG.xml" /><check-content>Review the column definitions and contents of audit-trail and activity-tracking timestamps in database tables.
 
If these are not defined and maintained to include date and time of day, accurate to a granularity of one second or finer, this is a finding.</check-content></check></Rule></Group><Group id="V-67409"><title>SRG-APP-000428-DB-000386</title><description>&lt;GroupDescription&gt;&lt;/GroupDescription&gt;</description><Rule id="SV-81899r1_rule" severity="medium" weight="10.0"><version>SQL4-00-034700</version><title>SQL Server must implement and/or support cryptographic mechanisms to prevent unauthorized modification of organization-defined information at rest (to include, at a minimum, PII and classified information) on organization-defined information system components.</title><description>&lt;VulnDiscussion&gt;Databases holding data requiring "data at rest" protections must employ cryptographic mechanisms to prevent unauthorized disclosure and modification of the information at rest. These cryptographic mechanisms may be native to the DBMS or implemented via additional software or operating system/file system settings, as appropriate to the situation.
 
Selection of a cryptographic mechanism is based on the need to protect the integrity of organizational information. The strength of the mechanism is commensurate with the security category and/or classification of the information. Organizations have the flexibility to either encrypt all information on storage devices (i.e., full disk encryption) or encrypt specific data structures (e.g., files, records, or fields).
 
The decision whether and what to encrypt rests with the data owner and is also influenced by the physical measures taken to secure the equipment and media on which the information resides.&lt;/VulnDiscussion&gt;&lt;FalsePositives&gt;&lt;/FalsePositives&gt;&lt;FalseNegatives&gt;&lt;/FalseNegatives&gt;&lt;Documentable&gt;false&lt;/Documentable&gt;&lt;Mitigations&gt;&lt;/Mitigations&gt;&lt;SeverityOverrideGuidance&gt;&lt;/SeverityOverrideGuidance&gt;&lt;PotentialImpacts&gt;&lt;/PotentialImpacts&gt;&lt;ThirdPartyTools&gt;&lt;/ThirdPartyTools&gt;&lt;MitigationControl&gt;&lt;/MitigationControl&gt;&lt;Responsibility&gt;&lt;/Responsibility&gt;&lt;IAControls&gt;&lt;/IAControls&gt;</description><reference><dc:title>DPMS Target SQL Server Database 2014</dc:title><dc:publisher>DISA</dc:publisher><dc:type>DPMS Target</dc:type><dc:subject>SQL Server Database 2014</dc:subject><dc:identifier>2637</dc:identifier></reference><ident system="http://iase.disa.mil/cci">CCI-002475</ident><fixtext fixref="F-73521r1_fix">Where full-disk encryption is required, configure Windows and/or the storage system to provide this.
 
Where transparent data encryption (TDE) is required, deploy the necessary stack of certificates and keys, and set the Encryption Enabled to True. For guidance from the Microsoft Developer Network on how to do this, perform a web search for "SQL Server 2014 TDE".
 
Where column encryption is required, deploy the necessary stack of certificates and keys, and enable encryption on the columns in question. For guidance from the Microsoft Developer Network on how to do this, perform a web search for "SQL Server 2014 Encrypt a Column of Data".</fixtext><fix id="F-73521r1_fix" /><check system="C-67987r1_chk"><check-content-ref name="M" href="DPMS_XCCDF_Benchmark_MS_SQL_Server_2014_Database_STIG.xml" /><check-content>Review the system documentation to determine whether the organization has defined the information at rest that is to be protected from modification, which must include, at a minimum, PII and classified information.
 
If no information is identified as requiring such protection, this is not a finding.
 
Review the configuration of SQL Server, Windows, and additional software as relevant.
 
If full-disk encryption is required, and Windows or the storage system is not configured for this, this is a finding.
 
If database transparent data encryption (TDE) is called for, check whether it is enabled:
In SQL Server Management Studio, Object Explorer, expand the instance and right-click on the database name; select properties. Select the Options page, State section, Encryption Enabled parameter.
 
If the value displayed is False, this is a finding.
 
If column encryption, done via SQL Server features, is required, review the definitions and contents of the relevant tables and columns.
 
If any of the information defined as requiring cryptographic protection is not encrypted in a manner that provides the required level of protection, this is a finding.</check-content></check></Rule></Group><Group id="V-67411"><title>SRG-APP-000447-DB-000393</title><description>&lt;GroupDescription&gt;&lt;/GroupDescription&gt;</description><Rule id="SV-81901r2_rule" severity="medium" weight="10.0"><version>SQL4-00-035200</version><title>When invalid inputs are received, SQL Server must behave in a predictable and documented manner that reflects organizational and system objectives.</title><description>&lt;VulnDiscussion&gt;A common vulnerability is unplanned behavior when invalid inputs are received. This requirement guards against adverse or unintended system behavior caused by invalid inputs, where information system responses to the invalid input may be disruptive or cause the system to fail into an unsafe state.
 
The behavior will be derived from the organizational and system requirements and includes, but is not limited to, notification of the appropriate personnel, creating an audit record, and rejecting invalid input.
 
This calls for inspection of application source code, which will require collaboration with the application developers. It is recognized that in many cases, the database administrator (DBA) is organizationally separate from the application developers and may have limited, if any, access to source code. Nevertheless, protections of this type are so important to the secure operation of databases that they must not be ignored. At a minimum, the DBA must attempt to obtain assurances from the development organization that this issue has been addressed and must document what has been discovered.&lt;/VulnDiscussion&gt;&lt;FalsePositives&gt;&lt;/FalsePositives&gt;&lt;FalseNegatives&gt;&lt;/FalseNegatives&gt;&lt;Documentable&gt;false&lt;/Documentable&gt;&lt;Mitigations&gt;&lt;/Mitigations&gt;&lt;SeverityOverrideGuidance&gt;&lt;/SeverityOverrideGuidance&gt;&lt;PotentialImpacts&gt;&lt;/PotentialImpacts&gt;&lt;ThirdPartyTools&gt;&lt;/ThirdPartyTools&gt;&lt;MitigationControl&gt;&lt;/MitigationControl&gt;&lt;Responsibility&gt;&lt;/Responsibility&gt;&lt;IAControls&gt;&lt;/IAControls&gt;</description><reference><dc:title>DPMS Target SQL Server Database 2014</dc:title><dc:publisher>DISA</dc:publisher><dc:type>DPMS Target</dc:type><dc:subject>SQL Server Database 2014</dc:subject><dc:identifier>2637</dc:identifier></reference><ident system="http://iase.disa.mil/cci">CCI-002754</ident><fixtext fixref="F-73525r1_fix">Revise and deploy the source code for database program objects (stored procedures, functions, triggers) and application source code, to implement the documented behavior.</fixtext><fix id="F-73525r1_fix" /><check system="C-67991r1_chk"><check-content-ref name="M" href="DPMS_XCCDF_Benchmark_MS_SQL_Server_2014_Database_STIG.xml" /><check-content>Review system documentation to determine how input errors are to be handled in general and if any special handling is defined for specific circumstances.
 
Review the source code for database program objects (stored procedures, functions, triggers) and application source code to identify how the system responds to invalid input.
 
If it does not implement the documented behavior, this is a finding.</check-content></check></Rule></Group><Group id="V-67413"><title>SRG-APP-000494-DB-000344</title><description>&lt;GroupDescription&gt;&lt;/GroupDescription&gt;</description><Rule id="SV-81903r2_rule" severity="medium" weight="10.0"><version>SQL4-00-035800</version><title>Trace or Audit records must be generated when categorized information (e.g., classification levels/security levels) is accessed.</title><description>&lt;VulnDiscussion&gt;Changes in categorized information must be tracked. Without an audit trail, unauthorized access to protected data could go undetected.
 
For detailed information on categorizing information, refer to FIPS Publication 199, Standards for Security Categorization of Federal Information and Information Systems, and FIPS Publication 200, Minimum Security Requirements for Federal Information and Information Systems.
 
Use of SQL Server Audit is recommended. All features of SQL Server Audit are available in the Enterprise and Developer editions of SQL Server 2014. It is not available at the database level in other editions. For this or legacy reasons, the instance may be using SQL Server Trace for auditing, which remains an acceptable solution for the time being. Note, however, that Microsoft intends to remove most aspects of Trace at some point after SQL Server 2016. Note also that Trace does not support auditing of SELECT statements, whereas Audit does.
 
Since Trace does not provide for tracking SELECT statements, it is necessary to provide this tracking at the application level, if Trace is used for audit purposes.&lt;/VulnDiscussion&gt;&lt;FalsePositives&gt;&lt;/FalsePositives&gt;&lt;FalseNegatives&gt;&lt;/FalseNegatives&gt;&lt;Documentable&gt;false&lt;/Documentable&gt;&lt;Mitigations&gt;&lt;/Mitigations&gt;&lt;SeverityOverrideGuidance&gt;&lt;/SeverityOverrideGuidance&gt;&lt;PotentialImpacts&gt;&lt;/PotentialImpacts&gt;&lt;ThirdPartyTools&gt;&lt;/ThirdPartyTools&gt;&lt;MitigationControl&gt;&lt;/MitigationControl&gt;&lt;Responsibility&gt;&lt;/Responsibility&gt;&lt;IAControls&gt;&lt;/IAControls&gt;</description><reference><dc:title>DPMS Target SQL Server Database 2014</dc:title><dc:publisher>DISA</dc:publisher><dc:type>DPMS Target</dc:type><dc:subject>SQL Server Database 2014</dc:subject><dc:identifier>2637</dc:identifier></reference><ident system="http://iase.disa.mil/cci">CCI-000172</ident><fixtext fixref="F-73527r1_fix">Where SQL Server Trace is in use, implement tracking of SELECTs on categorized data at the application level, using the system stored procedure sp_trace_generateevent to write the tracking records to the Trace used for audit purposes.
 
If SQL Server Audit is in use, design and deploy an Audit that captures all auditable events and data items. The script provided in the supplemental file Audit.sql can be used as the basis for this. Supplement the standard audit data as necessary, using Extended Events and/or triggers.
 
Alternatively, to add the necessary data capture to an existing server audit specification, run the script:
USE [master];
GO
ALTER SERVER AUDIT SPECIFICATION &lt;server_audit_specification_name&gt; WITH (STATE = OFF);
GO
ALTER SERVER AUDIT SPECIFICATION &lt;server_audit_specification_name&gt; ADD (SCHEMA_OBJECT_ACCESS_GROUP);
GO
ALTER SERVER AUDIT SPECIFICATION &lt;server_audit_specification_name&gt; WITH (STATE = ON);
GO</fixtext><fix id="F-73527r1_fix" /><check system="C-67993r3_chk"><check-content-ref name="M" href="DPMS_XCCDF_Benchmark_MS_SQL_Server_2014_Database_STIG.xml" /><check-content>Review the system documentation to determine whether it is required to track categories of information, such as classification or sensitivity level. If it is not, this is not applicable (NA).
 
If neither SQL Server Audit nor SQL Server Trace is in use for audit purposes, this is a finding.
 
If SQL Server Trace is in use for audit purposes, review the application(s) using the database to verify that all SELECT actions on categorized data are being audited, and that the tracking records are written to the SQL Server Trace. If not, this is a finding.
 
 
If SQL Server Audit is in use, proceed as follows.
 
The basic SQL Server Audit configuration provided in the supplemental file Audit.sql uses the broad, server-level audit action group SCHEMA_OBJECT_ACCESS_GROUP for this purpose. SQL Server Audit's flexibility makes other techniques possible.
 
If an alternative technique is in use and demonstrated effective, this is not a finding.
 
Determine the name(s) of the server audit specification(s) in use.
 
To look at audits and audit specifications, in Management Studio's object explorer, expand
&lt;server name&gt; &gt;&gt; Security &gt;&gt; Audits
and
&lt;server name&gt; &gt;&gt; Security &gt;&gt; Server Audit Specifications.
Also,
&lt;server name&gt; &gt;&gt; Databases &gt;&gt; &lt;database name&gt; &gt;&gt; Security &gt;&gt; Database Audit Specifications.
 
Alternatively, review the contents of the system views with "audit" in their names.
 
Run the following to verify that all SELECT, INSERT, UPDATE, and DELETE actions on tables and views are being audited:
USE [master];
GO
SELECT * FROM sys.server_audit_specification_details WHERE server_specification_id =
(SELECT server_specification_id FROM sys.server_audit_specifications WHERE [name] = '&lt;server_audit_specification_name&gt;')
AND audit_action_name = 'SCHEMA_OBJECT_ACCESS_GROUP';
 
If no row is returned, this is a finding.
 
If the audited_result column is not "SUCCESS" or "SUCCESS AND FAILURE", this is a finding.</check-content></check></Rule></Group><Group id="V-67415"><title>SRG-APP-000494-DB-000345</title><description>&lt;GroupDescription&gt;&lt;/GroupDescription&gt;</description><Rule id="SV-81905r2_rule" severity="medium" weight="10.0"><version>SQL4-00-035900</version><title>Trace or Audit records must be generated when unsuccessful attempts to access categorized information (e.g., classification levels/security levels) occur.</title><description>&lt;VulnDiscussion&gt;Changes in categorized information must be tracked. Without an audit trail, unauthorized access to protected data could go undetected.
 
To aid in diagnosis, it is necessary to keep track of failed attempts in addition to the successful ones.
 
For detailed information on categorizing information, refer to FIPS Publication 199, Standards for Security Categorization of Federal Information and Information Systems, and FIPS Publication 200, Minimum Security Requirements for Federal Information and Information Systems.
 
Use of SQL Server Audit is recommended. All features of SQL Server Audit are available in the Enterprise and Developer editions of SQL Server 2014. It is not available at the database level in other editions. For this or legacy reasons, the instance may be using SQL Server Trace for auditing, which remains an acceptable solution for the time being. Note, however, that Microsoft intends to remove most aspects of Trace at some point after SQL Server 2016. Note also that Trace does not support auditing of SELECT statements, whereas Audit does.
 
Since Trace does not provide for tracking SELECT statements, it is necessary to provide this tracking at the application level, if Trace is used for audit purposes.
 
Use of SQL Server Audit's SCHEMA_OBJECT_ACCESS_GROUP causes capture of all accesses, successful and otherwise, to all schema-scoped objects. The [Succeeded] column in the audit output indicates the success or failure of the attempted action. Be aware, however, that it may report True in some cases where one would intuitively expect False. For example, SELECT 1/0 FROM SYS.ALL_OBJECTS will appear in the audit trail as successful, if the user has permission to perform that action, even though it contains an invalid expression. Some other actions that one would consider failures (such as selecting from a table that does not exist) may not appear at all.&lt;/VulnDiscussion&gt;&lt;FalsePositives&gt;&lt;/FalsePositives&gt;&lt;FalseNegatives&gt;&lt;/FalseNegatives&gt;&lt;Documentable&gt;false&lt;/Documentable&gt;&lt;Mitigations&gt;&lt;/Mitigations&gt;&lt;SeverityOverrideGuidance&gt;&lt;/SeverityOverrideGuidance&gt;&lt;PotentialImpacts&gt;&lt;/PotentialImpacts&gt;&lt;ThirdPartyTools&gt;&lt;/ThirdPartyTools&gt;&lt;MitigationControl&gt;&lt;/MitigationControl&gt;&lt;Responsibility&gt;&lt;/Responsibility&gt;&lt;IAControls&gt;&lt;/IAControls&gt;</description><reference><dc:title>DPMS Target SQL Server Database 2014</dc:title><dc:publisher>DISA</dc:publisher><dc:type>DPMS Target</dc:type><dc:subject>SQL Server Database 2014</dc:subject><dc:identifier>2637</dc:identifier></reference><ident system="http://iase.disa.mil/cci">CCI-000172</ident><fixtext fixref="F-73529r1_fix">Where SQL Server Trace is in use, implement tracking of SELECTs on categorized data at the application level, using the system stored procedure sp_trace_generateevent to write the tracking records to the Trace used for audit purposes. Include failed attempts in the tracking.
 
If SQL Server Audit is in use, design and deploy an Audit that captures all auditable events and data items. The script provided in the supplemental file Audit.sql can be used as the basis for this. Supplement the standard audit data as necessary, using Extended Events and/or triggers.
 
Alternatively, to add the necessary data capture to an existing server audit specification, run the script:
USE [master];
GO
ALTER SERVER AUDIT SPECIFICATION &lt;server_audit_specification_name&gt; WITH (STATE = OFF);
GO
ALTER SERVER AUDIT SPECIFICATION &lt;server_audit_specification_name&gt; ADD (SCHEMA_OBJECT_ACCESS_GROUP);
GO
ALTER SERVER AUDIT SPECIFICATION &lt;server_audit_specification_name&gt; WITH (STATE = ON);
GO</fixtext><fix id="F-73529r1_fix" /><check system="C-67995r3_chk"><check-content-ref name="M" href="DPMS_XCCDF_Benchmark_MS_SQL_Server_2014_Database_STIG.xml" /><check-content>Review the system documentation to determine whether it is required to track categories of information, such as classification or sensitivity level. If it is not, this is not applicable (NA).
 
If neither SQL Server Audit nor SQL Server Trace is in use for audit purposes, this is a finding.
 
If SQL Server Trace is in use for audit purposes, review the application(s) using the database to verify that all SELECT actions on categorized data, including unsuccessful attempts, are being audited; and that the tracking records are written to the SQL Server Trace used for audit purposes. If not, this is a finding.
 
 
If SQL Server Audit is in use, proceed as follows.
 
The basic SQL Server Audit configuration provided in the supplemental file Audit.sql uses the broad, server-level audit action group SCHEMA_OBJECT_ACCESS_GROUP for this purpose. SQL Server Audit's flexibility makes other techniques possible.
 
If an alternative technique is in use and demonstrated effective, this is not a finding.
 
Determine the name(s) of the server audit specification(s) in use.
 
To look at audits and audit specifications, in Management Studio's object explorer, expand
&lt;server name&gt; &gt;&gt; Security &gt;&gt; Audits
and
&lt;server name&gt; &gt;&gt; Security &gt;&gt; Server Audit Specifications.
Also,
&lt;server name&gt; &gt;&gt; Databases &gt;&gt; &lt;database name&gt; &gt;&gt; Security &gt;&gt; Database Audit Specifications.
 
Alternatively, review the contents of the system views with "audit" in their names.
 
Run the following to verify that all SELECT, INSERT, UPDATE, and DELETE actions on tables and views are being audited:
USE [master];
GO
SELECT * FROM sys.server_audit_specification_details WHERE server_specification_id =
(SELECT server_specification_id FROM sys.server_audit_specifications WHERE [name] = '&lt;server_audit_specification_name&gt;')
AND audit_action_name = 'SCHEMA_OBJECT_ACCESS_GROUP';
 
If no row is returned, this is a finding.
 
If the audited_result column is not "FAILURE" or "SUCCESS AND FAILURE", this is a finding.</check-content></check></Rule></Group><Group id="V-67417"><title>SRG-APP-000495-DB-000328</title><description>&lt;GroupDescription&gt;&lt;/GroupDescription&gt;</description><Rule id="SV-81907r2_rule" severity="medium" weight="10.0"><version>SQL4-00-036200</version><title>SQL Server must generate Trace or Audit records when privileges/permissions are modified via locally-defined security objects.</title><description>&lt;VulnDiscussion&gt;Changes in the permissions, privileges, and roles granted to users and roles must be tracked. Without an audit trail, unauthorized elevation or restriction of privileges could go undetected. Elevated privileges give users access to information and functionality that they should not have; restricted privileges wrongly deny access to authorized users.
 
In SQL Server, there is no distinction between modification of permissions and granting or dropping them. However, native SQL Server security functionality may be supplemented with application-specific tables and logic, in which case the following actions on these tables and procedures/triggers/functions are also relevant:
UPDATE
EXECUTE
 
Use of SQL Server Audit is recommended. All features of SQL Server Audit are available in the Enterprise and Developer editions of SQL Server 2014. It is not available at the database level in other editions. For this or legacy reasons, the instance may be using SQL Server Trace for auditing, which remains an acceptable solution for the time being. Note, however, that Microsoft intends to remove most aspects of Trace at some point after SQL Server 2016.&lt;/VulnDiscussion&gt;&lt;FalsePositives&gt;&lt;/FalsePositives&gt;&lt;FalseNegatives&gt;&lt;/FalseNegatives&gt;&lt;Documentable&gt;false&lt;/Documentable&gt;&lt;Mitigations&gt;&lt;/Mitigations&gt;&lt;SeverityOverrideGuidance&gt;&lt;/SeverityOverrideGuidance&gt;&lt;PotentialImpacts&gt;&lt;/PotentialImpacts&gt;&lt;ThirdPartyTools&gt;&lt;/ThirdPartyTools&gt;&lt;MitigationControl&gt;&lt;/MitigationControl&gt;&lt;Responsibility&gt;&lt;/Responsibility&gt;&lt;IAControls&gt;&lt;/IAControls&gt;</description><reference><dc:title>DPMS Target SQL Server Database 2014</dc:title><dc:publisher>DISA</dc:publisher><dc:type>DPMS Target</dc:type><dc:subject>SQL Server Database 2014</dc:subject><dc:identifier>2637</dc:identifier></reference><ident system="http://iase.disa.mil/cci">CCI-000172</ident><fixtext fixref="F-73531r1_fix">Where SQL Server Trace is in use, define and enable a trace that captures all auditable events. The script provided in the supplemental file Trace.sql can be used to do this.
 
Add blocks of code to Trace.sql for each custom event class (integers in the range 82-91; the same event class may be used for all such triggers) used in these triggers.
 
Create triggers to raise a custom event on each locally-defined security table that requires tracking of Insert-Update-Delete operations. The examples provided in the supplemental file CustomTraceEvents.sql can serve as the basis for these.
 
Execute Trace.sql.
 
Where SQL Server Audit is in use, design and deploy a SQL Server Audit that captures all auditable events. The script provided in the supplemental file Audit.sql can be used for this.
 
Alternatively, to add the necessary data capture to an existing server audit specification, run the script:
USE [master];
GO
ALTER SERVER AUDIT SPECIFICATION &lt;server_audit_specification_name&gt; WITH (STATE = OFF);
GO
ALTER SERVER AUDIT SPECIFICATION &lt;server_audit_specification_name&gt; ADD (SCHEMA_OBJECT_ACCESS_GROUP);
GO
ALTER SERVER AUDIT SPECIFICATION &lt;server_audit_specification_name&gt; WITH (STATE = ON);
GO</fixtext><fix id="F-73531r1_fix" /><check system="C-67997r2_chk"><check-content-ref name="M" href="DPMS_XCCDF_Benchmark_MS_SQL_Server_2014_Database_STIG.xml" /><check-content>Obtain the list of locally-defined security tables, procedures and functions that require tracking.
 
If there are none, this is not a finding.
 
If neither SQL Server Audit nor SQL Server Trace is in use for audit purposes, this is a finding.
 
If SQL Server Trace is in use for audit purposes, review the locally-defined security tables for the existence of triggers to raise a custom event on each Update operation. If such triggers are not present, this is a finding.
 
Verify that all required events are being audited. From the query prompt:
SELECT * FROM sys.traces;
 
All currently defined traces for the SQL server instance will be listed. If no traces are returned, this is a finding.
 
Determine the trace(s) being used for the auditing requirement.
In the following, replace # with a trace ID being used for the auditing requirements.
From the query prompt:
SELECT DISTINCT(eventid) FROM sys.fn_trace_geteventinfo(#);
 
The following required event IDs should be among those listed; if not, this is a finding:
 
42 -- SP:Starting
43 -- SP:Completed
82-91 -- User-defined Event
162 -- User error message
 
 
If SQL Server Audit is in use, proceed as follows.
 
Verify that all EXECUTE actions on locally-defined permissions-related procedures are being audited. If not, this is a finding.
 
The basic SQL Server Audit configuration provided in the supplemental file Audit.sql uses the broad, server-level audit action group SCHEMA_OBJECT_ACCESS_GROUP for this purpose. SQL Server Audit's flexibility makes other techniques possible. If an alternative technique is in use and demonstrated effective, this is not a finding.
 
Determine the name(s) of the server audit specification(s) in use.
To look at audits and audit specifications, in Management Studio's object explorer, expand
&lt;server name&gt; &gt;&gt; Security &gt;&gt; Audits
and
&lt;server name&gt; &gt;&gt; Security &gt;&gt; Server Audit Specifications.
Also,
&lt;server name&gt; &gt;&gt; Databases &gt;&gt; &lt;database name&gt; &gt;&gt; Security &gt;&gt; Database Audit Specifications.
Alternatively, review the contents of the system views with "audit" in their names.
 
Run the following to verify that all UPDATE and EXECUTE actions on any locally-defined permissions tables, procedures and functions are being audited:
USE [master];
GO
SELECT * FROM sys.server_audit_specification_details WHERE server_specification_id =
(SELECT server_specification_id FROM sys.server_audit_specifications WHERE [name] = '&lt;server_audit_specification_name&gt;')
AND audit_action_name = 'SCHEMA_OBJECT_ACCESS_GROUP';
 
If no row is returned, this is a finding.
 
If the audited_result column is not "SUCCESS" or "SUCCESS AND FAILURE", this is a finding.</check-content></check></Rule></Group><Group id="V-67419"><title>SRG-APP-000495-DB-000329</title><description>&lt;GroupDescription&gt;&lt;/GroupDescription&gt;</description><Rule id="SV-81909r2_rule" severity="medium" weight="10.0"><version>SQL4-00-036300</version><title>SQL Server must generate Trace or Audit records when unsuccessful attempts to modify privileges/permissions via locally-defined security objects occur.</title><description>&lt;VulnDiscussion&gt;Failed attempts to change the permissions, privileges, and roles granted to users and roles must be tracked. Without an audit trail, unauthorized attempts to elevate or restrict privileges could go undetected.
 
In SQL Server, there is no distinction between modification of permissions and granting or dropping them. However, native SQL Server security functionality may be supplemented with application-specific tables and logic, in which case the following actions on these tables and procedures/triggers/functions are also relevant:
UPDATE
EXECUTE
 
To aid in diagnosis, it is necessary to keep track of failed attempts in addition to the successful ones.
 
Use of SQL Server Audit is recommended. All features of SQL Server Audit are available in the Enterprise and Developer editions of SQL Server 2014. It is not available at the database level in other editions. For this or legacy reasons, the instance may be using SQL Server Trace for auditing, which remains an acceptable solution for the time being. Note, however, that Microsoft intends to remove most aspects of Trace at some point after SQL Server 2016.
 
Use of SQL Server Audit's SCHEMA_OBJECT_ACCESS_GROUP causes capture of all accesses, successful and otherwise, to the system views (and all other schema-scoped objects). The [Succeeded] column in the audit output indicates the success or failure of the attempted action. Be aware, however, that it may report True in some cases where one would intuitively expect False. For example, SELECT 1/0 FROM SYS.ALL_OBJECTS will appear in the audit trail as successful, if the user has permission to perform that action, even though it contains an invalid expression. Some other actions that one would consider failures (such as selecting from a table that does not exist) may not appear at all.&lt;/VulnDiscussion&gt;&lt;FalsePositives&gt;&lt;/FalsePositives&gt;&lt;FalseNegatives&gt;&lt;/FalseNegatives&gt;&lt;Documentable&gt;false&lt;/Documentable&gt;&lt;Mitigations&gt;&lt;/Mitigations&gt;&lt;SeverityOverrideGuidance&gt;&lt;/SeverityOverrideGuidance&gt;&lt;PotentialImpacts&gt;&lt;/PotentialImpacts&gt;&lt;ThirdPartyTools&gt;&lt;/ThirdPartyTools&gt;&lt;MitigationControl&gt;&lt;/MitigationControl&gt;&lt;Responsibility&gt;&lt;/Responsibility&gt;&lt;IAControls&gt;&lt;/IAControls&gt;</description><reference><dc:title>DPMS Target SQL Server Database 2014</dc:title><dc:publisher>DISA</dc:publisher><dc:type>DPMS Target</dc:type><dc:subject>SQL Server Database 2014</dc:subject><dc:identifier>2637</dc:identifier></reference><ident system="http://iase.disa.mil/cci">CCI-000172</ident><fixtext fixref="F-73533r1_fix">Where SQL Server Trace is in use, define and enable a trace that captures all auditable events. The script provided in the supplemental file Trace.sql can be used to do this.
 
Add blocks of code to Trace.sql for each custom event class (integers in the range 82-91; the same event class may be used for all such triggers) used in these triggers.
 
Create triggers to raise a custom event on each locally-defined security table that requires tracking of Insert-Update-Delete operations. The examples provided in the supplemental file CustomTraceEvents.sql can serve as the basis for these.
 
Execute Trace.sql.
 
Where SQL Server Audit is in use, design and deploy a SQL Server Audit that captures all auditable events. The script provided in the supplemental file Audit.sql can be used for this.
 
Alternatively, to add the necessary data capture to an existing server audit specification, run the script:
USE [master];
GO
ALTER SERVER AUDIT SPECIFICATION &lt;server_audit_specification_name&gt; WITH (STATE = OFF);
GO
ALTER SERVER AUDIT SPECIFICATION &lt;server_audit_specification_name&gt; ADD (SCHEMA_OBJECT_ACCESS_GROUP);
GO
ALTER SERVER AUDIT SPECIFICATION &lt;server_audit_specification_name&gt; WITH (STATE = ON);
GO</fixtext><fix id="F-73533r1_fix" /><check system="C-67999r4_chk"><check-content-ref name="M" href="DPMS_XCCDF_Benchmark_MS_SQL_Server_2014_Database_STIG.xml" /><check-content>Obtain the list of locally-defined security tables, procedures and functions that require tracking. If there are none, this is not a finding.
 
If neither SQL Server Audit nor SQL Server Trace is in use for audit purposes, this is a finding.
 
If SQL Server Trace is in use for audit purposes, review the locally-defined security tables for the existence of triggers to raise a custom event on each Update operation. If such triggers are not present, this is a finding.
 
Verify that all required events are being audited. From the query prompt:
SELECT * FROM sys.traces;
 
All currently defined traces for the SQL server instance will be listed. If no traces are returned, this is a finding.
 
Determine the trace(s) being used for the auditing requirement.
In the following, replace # with a trace ID being used for the auditing requirements.
From the query prompt:
SELECT DISTINCT(eventid) FROM sys.fn_trace_geteventinfo(#);
 
The following required event IDs should be among those listed; if not, this is a finding:
 
42 -- SP:Starting
43 -- SP:Completed
82-91 -- User-defined Event
162 -- User error message
 
 
If SQL Server Audit is in use, proceed as follows.
 
Verify that all EXECUTE actions on locally-defined permissions-related procedures are being audited. If not, this is a finding.
 
The basic SQL Server Audit configuration provided in the supplemental file Audit.sql uses the broad, server-level audit action group SCHEMA_OBJECT_ACCESS_GROUP for this purpose. SQL Server Audit's flexibility makes other techniques possible. If an alternative technique is in use and demonstrated effective, this is not a finding.
 
Determine the name(s) of the server audit specification(s) in use.
 
To look at audits and audit specifications, in Management Studio's object explorer, expand
&lt;server name&gt; &gt;&gt; Security &gt;&gt; Audits
and
&lt;server name&gt; &gt;&gt; Security &gt;&gt; Server Audit Specifications.
Also,
&lt;server name&gt; &gt;&gt; Databases &gt;&gt; &lt;database name&gt; &gt;&gt; Security &gt;&gt; Database Audit Specifications.
 
Alternatively, review the contents of the system views with "audit" in their names.
 
Run the following to verify that all UPDATE and EXECUTE actions on any locally-defined permissions tables, procedures and functions are being audited:
USE [master];
GO
SELECT * FROM sys.server_audit_specification_details WHERE server_specification_id =
(SELECT server_specification_id FROM sys.server_audit_specifications WHERE [name] = '&lt;server_audit_specification_name&gt;')
AND audit_action_name = 'SCHEMA_OBJECT_ACCESS_GROUP';
 
If no row is returned, this is a finding.
 
If the audited_result column is not "FAILURE" or "SUCCESS AND FAILURE", this is a finding.</check-content></check></Rule></Group><Group id="V-67421"><title>SRG-APP-000496-DB-000334</title><description>&lt;GroupDescription&gt;&lt;/GroupDescription&gt;</description><Rule id="SV-81911r2_rule" severity="medium" weight="10.0"><version>SQL4-00-036400</version><title>SQL Server must generate Trace or Audit records when locally-defined security objects are modified.</title><description>&lt;VulnDiscussion&gt;SQL Server protects its built-in security objects (tables, views, functions, procedures, etc.) from alteration by database users and administrators. However, applications sometimes have additional, security-related objects defined in the database. ALTER operations on these objects must be monitored.
 
Use of SQL Server Audit is recommended. All features of SQL Server Audit are available in the Enterprise and Developer editions of SQL Server 2014. It is not available at the database level in other editions. For this or legacy reasons, the instance may be using SQL Server Trace for auditing, which remains an acceptable solution for the time being. Note, however, that Microsoft intends to remove most aspects of Trace at some point after SQL Server 2016.&lt;/VulnDiscussion&gt;&lt;FalsePositives&gt;&lt;/FalsePositives&gt;&lt;FalseNegatives&gt;&lt;/FalseNegatives&gt;&lt;Documentable&gt;false&lt;/Documentable&gt;&lt;Mitigations&gt;&lt;/Mitigations&gt;&lt;SeverityOverrideGuidance&gt;&lt;/SeverityOverrideGuidance&gt;&lt;PotentialImpacts&gt;&lt;/PotentialImpacts&gt;&lt;ThirdPartyTools&gt;&lt;/ThirdPartyTools&gt;&lt;MitigationControl&gt;&lt;/MitigationControl&gt;&lt;Responsibility&gt;&lt;/Responsibility&gt;&lt;IAControls&gt;&lt;/IAControls&gt;</description><reference><dc:title>DPMS Target SQL Server Database 2014</dc:title><dc:publisher>DISA</dc:publisher><dc:type>DPMS Target</dc:type><dc:subject>SQL Server Database 2014</dc:subject><dc:identifier>2637</dc:identifier></reference><ident system="http://iase.disa.mil/cci">CCI-000172</ident><fixtext fixref="F-73535r1_fix">Where SQL Server Trace is in use, define and enable a trace that captures all auditable events. The script provided in the supplemental file Trace.sql can be used to do this.
 
Where SQL Server Audit is in use, design and deploy a SQL Server Audit that captures all auditable events. The script provided in the supplemental file Audit.sql can be used for this.
 
Alternatively, to add the necessary data capture to an existing server audit specification, run the script:
USE [master];
GO
ALTER SERVER AUDIT SPECIFICATION &lt;server_audit_specification_name&gt; WITH (STATE = OFF);
GO
ALTER SERVER AUDIT SPECIFICATION &lt;server_audit_specification_name&gt; ADD (SCHEMA_OBJECT_CHANGE_GROUP);
GO
ALTER SERVER AUDIT SPECIFICATION &lt;server_audit_specification_name&gt; WITH (STATE = ON);
GO</fixtext><fix id="F-73535r1_fix" /><check system="C-68001r3_chk"><check-content-ref name="M" href="DPMS_XCCDF_Benchmark_MS_SQL_Server_2014_Database_STIG.xml" /><check-content>If there are no locally-defined security tables or procedures, this is not a finding.
 
If neither SQL Server Audit nor SQL Server Trace is in use for audit purposes, this is a finding.
 
If SQL Server Trace is in use for audit purposes, verify that all required events are being audited. From the query prompt:
SELECT * FROM sys.traces;
All currently defined traces for the SQL server instance will be listed. If no traces are returned, this is a finding.
 
Determine the trace(s) being used for the auditing requirement.
In the following, replace # with a trace ID being used for the auditing requirements.
From the query prompt:
SELECT DISTINCT(eventid) FROM sys.fn_trace_geteventinfo(#);
 
The following required event IDs should all be among those listed; if not, this is a finding:
 
46 -- Object:Created
47 -- Object:Deleted
162 -- User error message
164 -- Object:Altered
 
 
If SQL Server Audit is in use, proceed as follows.
 
The basic SQL Server Audit configuration provided in the supplemental file Audit.sql uses the broad, server-level audit action group SCHEMA_OBJECT_CHANGE_GROUP for this purpose. SQL Server Audit's flexibility makes other techniques possible. If an alternative technique is in use and demonstrated effective, this is not a finding.
 
Determine the name(s) of the server audit specification(s) in use.
 
To look at audits and audit specifications, in Management Studio's object explorer, expand
&lt;server name&gt; &gt;&gt; Security &gt;&gt; Audits
and
&lt;server name&gt; &gt;&gt; Security &gt;&gt; Server Audit Specifications.
Also,
&lt;server name&gt; &gt;&gt; Databases &gt;&gt; &lt;database name&gt; &gt;&gt; Security &gt;&gt; Database Audit Specifications.
 
Alternatively, review the contents of the system views with "audit" in their names.
 
Run the following to verify that all CREATE, ALTER, and DROP actions on any locally-defined permissions tables, procedures and functions are being audited:
USE [master];
GO
SELECT * FROM sys.server_audit_specification_details WHERE server_specification_id =
(SELECT server_specification_id FROM sys.server_audit_specifications WHERE [name] = '&lt;server_audit_specification_name&gt;')
AND audit_action_name = 'SCHEMA_OBJECT_CHANGE_GROUP';
 
If no row is returned, this is a finding.
 
If the audited_result column is not "SUCCESS" or "SUCCESS AND FAILURE", this is a finding.</check-content></check></Rule></Group><Group id="V-67423"><title>SRG-APP-000507-DB-000357</title><description>&lt;GroupDescription&gt;&lt;/GroupDescription&gt;</description><Rule id="SV-81913r3_rule" severity="medium" weight="10.0"><version>SQL4-00-038200</version><title>SQL Server must generate Trace or Audit records when unsuccessful accesses to designated objects occur.</title><description>&lt;VulnDiscussion&gt;Without tracking all or selected types of access to all or selected objects (tables, views, procedures, functions, etc.), it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
 
Types of access include, but are not necessarily limited to:
SELECT
INSERT
UPDATE
DELETE
EXECUTE
 
To aid in diagnosis, it is necessary to keep track of failed attempts in addition to the successful ones.
 
Use of SQL Server Audit is recommended. All features of SQL Server Audit are available in the Enterprise and Developer editions of SQL Server 2014. It is not available at the database level in other editions. For this or legacy reasons, the instance may be using SQL Server Trace for auditing, which remains an acceptable solution for the time being. Note, however, that Microsoft intends to remove most aspects of Trace at some point after SQL Server 2016.&lt;/VulnDiscussion&gt;&lt;FalsePositives&gt;&lt;/FalsePositives&gt;&lt;FalseNegatives&gt;&lt;/FalseNegatives&gt;&lt;Documentable&gt;false&lt;/Documentable&gt;&lt;Mitigations&gt;&lt;/Mitigations&gt;&lt;SeverityOverrideGuidance&gt;&lt;/SeverityOverrideGuidance&gt;&lt;PotentialImpacts&gt;&lt;/PotentialImpacts&gt;&lt;ThirdPartyTools&gt;&lt;/ThirdPartyTools&gt;&lt;MitigationControl&gt;&lt;/MitigationControl&gt;&lt;Responsibility&gt;&lt;/Responsibility&gt;&lt;IAControls&gt;&lt;/IAControls&gt;</description><reference><dc:title>DPMS Target SQL Server Database 2014</dc:title><dc:publisher>DISA</dc:publisher><dc:type>DPMS Target</dc:type><dc:subject>SQL Server Database 2014</dc:subject><dc:identifier>2637</dc:identifier></reference><ident system="http://iase.disa.mil/cci">CCI-000172</ident><fixtext fixref="F-73537r3_fix">Where SQL Server Trace is in use, define and enable a trace that captures all auditable events. The script provided in the supplemental file Trace.sql can be used to do this.
 
If SQL Server Audit is in use, design and deploy an Audit that captures all auditable events and data items. The script provided in the supplemental file Audit.sql can be used as the basis for this. Supplement the standard audit data as necessary, using Extended Events and/or triggers.
 
Alternatively, to add the necessary data capture to an existing server audit specification, run the script:
USE [master];
GO
ALTER SERVER AUDIT SPECIFICATION &lt;server_audit_specification_name&gt; WITH (STATE = OFF);
GO
ALTER SERVER AUDIT SPECIFICATION &lt;server_audit_specification_name&gt; ADD (SCHEMA_OBJECT_ACCESS_GROUP);
GO
ALTER SERVER AUDIT SPECIFICATION &lt;server_audit_specification_name&gt; WITH (STATE = ON);
GO</fixtext><fix id="F-73537r3_fix" /><check system="C-68003r5_chk"><check-content-ref name="M" href="DPMS_XCCDF_Benchmark_MS_SQL_Server_2014_Database_STIG.xml" /><check-content>If neither SQL Server Audit nor SQL Server Trace is in use for audit purposes, this is a finding.
 
Obtain the list of objects (tables and stored procedures) where tracking of SELECT, INSERT, UPDATE, DELETE, or EXECUTE actions is required. If there are none, this is not a finding.
 
If SQL Server Trace is in use for audit purposes, verify that all required event classes are being audited. From the query prompt:
SELECT * FROM sys.traces;
 
All currently defined traces for the SQL server instance will be listed. If no traces are returned, this is a finding.
 
Determine the trace(s) being used for the auditing requirement.
In the following, replace # with a trace ID being used for the auditing requirements.
From the query prompt:
SELECT DISTINCT(eventid) FROM sys.fn_trace_geteventinfo(#);
 
The following required event ID should be among those listed; if not, this is a finding:
 
162 -- User error message
 
If SQL Server Audit is in use, proceed as follows.
 
The basic SQL Server Audit configuration provided in the supplemental file Audit.sql uses the server-level audit action group SCHEMA_OBJECT_ACCESS_GROUP for this purpose. SQL Server Audit's flexibility makes other techniques possible. If an alternative technique is in use and demonstrated effective, this is not a finding.
 
Determine the name(s) of the server audit specification(s) in use.
 
To look at audits and audit specifications, in Management Studio's object explorer, expand
&lt;server name&gt; &gt;&gt; Security &gt;&gt; Audits
and
&lt;server name&gt; &gt;&gt; Security &gt;&gt; Server Audit Specifications.
Also,
&lt;server name&gt; &gt;&gt; Databases &gt;&gt; &lt;database name&gt; &gt;&gt; Security &gt;&gt; Database Audit Specifications.
 
Alternatively, review the contents of the system views with "audit" in their names.
 
Run the following to verify that all logons and connections are being audited:
USE [master];
GO
SELECT * FROM sys.server_audit_specification_details WHERE server_specification_id =
(SELECT server_specification_id FROM sys.server_audit_specifications WHERE [name] = '&lt;server_audit_specification_name&gt;')
AND audit_action_name = 'SCHEMA_OBJECT_ACCESS_GROUP';
GO
 
If no row is returned, this is a finding.
 
If the audited_result column is not "FAILURE" or "SUCCESS AND FAILURE", this is a finding.</check-content></check></Rule></Group><Group id="V-67425"><title>SRG-APP-000507-DB-000356</title><description>&lt;GroupDescription&gt;&lt;/GroupDescription&gt;</description><Rule id="SV-81915r3_rule" severity="medium" weight="10.0"><version>SQL4-00-038100</version><title>SQL Server must generate Trace or Audit records when successful accesses to designated objects occur.</title><description>&lt;VulnDiscussion&gt;Without tracking all or selected types of access to all or selected objects (tables, views, procedures, functions, etc.), it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one.
 
Types of access include, but are not necessarily limited to:
SELECT
INSERT
UPDATE
DELETE
EXECUTE
 
Use of SQL Server Audit is recommended. All features of SQL Server Audit are available in the Enterprise and Developer editions of SQL Server 2014. It is not available at the database level in other editions. For this or legacy reasons, the instance may be using SQL Server Trace for auditing, which remains an acceptable solution for the time being. Note, however, that Microsoft intends to remove most aspects of Trace at some point after SQL Server 2016.
 
Trace does not offer tracking of SELECT operations, so where this is required it must be implemented at the application level.&lt;/VulnDiscussion&gt;&lt;FalsePositives&gt;&lt;/FalsePositives&gt;&lt;FalseNegatives&gt;&lt;/FalseNegatives&gt;&lt;Documentable&gt;false&lt;/Documentable&gt;&lt;Mitigations&gt;&lt;/Mitigations&gt;&lt;SeverityOverrideGuidance&gt;&lt;/SeverityOverrideGuidance&gt;&lt;PotentialImpacts&gt;&lt;/PotentialImpacts&gt;&lt;ThirdPartyTools&gt;&lt;/ThirdPartyTools&gt;&lt;MitigationControl&gt;&lt;/MitigationControl&gt;&lt;Responsibility&gt;&lt;/Responsibility&gt;&lt;IAControls&gt;&lt;/IAControls&gt;</description><reference><dc:title>DPMS Target SQL Server Database 2014</dc:title><dc:publisher>DISA</dc:publisher><dc:type>DPMS Target</dc:type><dc:subject>SQL Server Database 2014</dc:subject><dc:identifier>2637</dc:identifier></reference><ident system="http://iase.disa.mil/cci">CCI-000172</ident><fixtext fixref="F-73539r1_fix">Where SQL Server Trace is in use, implement tracking of SELECTs on designated tables at the application level, using the system stored procedure sp_trace_generateevent to write the tracking records to the Trace used for audit purposes.
 
Create triggers to raise a custom event on each table that requires tracking of Insert-Update-Delete operations. The examples provided in the supplemental file CustomTraceEvents.sql can serve as the basis for these.
 
Add a block of code to the supplemental file Trace.sql for each custom event class (integers in the range 82-91; the same event class may be used for all such triggers) used in these triggers.
 
Ensure that Trace.sql includes blocks of code for event classes 42, 43, and 162.
 
Execute Trace.sql.
 
If SQL Server Audit is in use, design and deploy an Audit that captures all auditable events and data items. The script provided in the supplemental file Audit.sql can be used as the basis for this. Supplement the standard audit data as necessary, using Extended Events and/or triggers.
 
Alternatively, to add the necessary data capture to an existing server audit specification, run the script:
USE [master];
GO
ALTER SERVER AUDIT SPECIFICATION &lt;server_audit_specification_name&gt; WITH (STATE = OFF);
GO
ALTER SERVER AUDIT SPECIFICATION &lt;server_audit_specification_name&gt; ADD (SCHEMA_OBJECT_ACCESS_GROUP);
GO
ALTER SERVER AUDIT SPECIFICATION &lt;server_audit_specification_name&gt; WITH (STATE = ON);
GO</fixtext><fix id="F-73539r1_fix" /><check system="C-68005r5_chk"><check-content-ref name="M" href="DPMS_XCCDF_Benchmark_MS_SQL_Server_2014_Database_STIG.xml" /><check-content>If neither SQL Server Audit nor SQL Server Trace is in use for audit purposes, this is a finding.
 
Obtain the list of objects (tables and stored procedures) where tracking of SELECT, INSERT, UPDATE, DELETE, or EXECUTE actions is required. If there are none, this is not a finding.
 
If SQL Server Trace is in use for audit purposes, review the application(s) using the database to verify that all SELECT actions on categorized data are being audited, and that the tracking records are written to the SQL Server Trace used for audit purposes. If not, this is a finding.
 
Review the designated tables for the existence of triggers to raise a custom event on each Insert-Update-Delete operation.
 
If such triggers are not present, this is a finding.
 
Check to see that all required event classes are being audited. From the query prompt:
SELECT * FROM sys.traces;
 
All currently defined traces for the SQL server instance will be listed. If no traces are returned, this is a finding.
 
Determine the trace(s) being used for the auditing requirement.
In the following, replace # with a trace ID being used for the auditing requirements.
From the query prompt:
SELECT DISTINCT(eventid) FROM sys.fn_trace_geteventinfo(#);
 
The following required event IDs should be among those listed; if not, this is a finding:
 
42 -- SP:Starting
43 -- SP:Completed
82-91 -- User-defined Event (at least one of these; 90 is used in the supplied script)
162 -- User error message
 
If SQL Server Audit is in use, verify that execution of all SELECT, INSERT, UPDATE, DELETE, or EXECUTE actions on the designated objects, is audited,.
 
If any such actions are not audited, this is a finding.
 
If SQL Server Audit is in use, proceed as follows.
 
The basic SQL Server Audit configuration provided in the supplemental file Audit.sql uses the server-level audit action group SCHEMA_OBJECT_ACCESS_GROUP for this purpose. SQL Server Audit's flexibility makes other techniques possible. If an alternative technique is in use and demonstrated effective, this is not a finding.
 
Determine the name(s) of the server audit specification(s) in use.
 
To look at audits and audit specifications, in Management Studio's object explorer, expand
&lt;server name&gt; &gt;&gt; Security &gt;&gt; Audits
and
&lt;server name&gt; &gt;&gt; Security &gt;&gt; Server Audit Specifications.
Also,
&lt;server name&gt; &gt;&gt; Databases &gt;&gt; &lt;database name&gt; &gt;&gt; Security &gt;&gt; Database Audit Specifications.
 
Alternatively, review the contents of the system views with "audit" in their names.
 
Run the following to verify that all logons and connections are being audited:
USE [master];
GO
SELECT * FROM sys.server_audit_specification_details WHERE server_specification_id =
(SELECT server_specification_id FROM sys.server_audit_specifications WHERE [name] = '&lt;server_audit_specification_name&gt;')
AND audit_action_name = 'SCHEMA_OBJECT_ACCESS_GROUP';
GO
 
If no row is returned, this is a finding.
 
If the audited_result column is not "SUCCESS" or "SUCCESS AND FAILURE", this is a finding.</check-content></check></Rule></Group><Group id="V-67427"><title>SRG-APP-000502-DB-000349</title><description>&lt;GroupDescription&gt;&lt;/GroupDescription&gt;</description><Rule id="SV-81917r2_rule" severity="medium" weight="10.0"><version>SQL4-00-037400</version><title>Trace or Audit records must be generated when unsuccessful attempts to delete categorized information (e.g., classification levels/security levels) occur.</title><description>&lt;VulnDiscussion&gt;Changes in categorized information must be tracked. Without an audit trail, unauthorized access to protected data could go undetected.
 
To aid in diagnosis, it is necessary to keep track of failed attempts in addition to the successful ones.
 
For detailed information on categorizing information, refer to FIPS Publication 199, Standards for Security Categorization of Federal Information and Information Systems, and FIPS Publication 200, Minimum Security Requirements for Federal Information and Information Systems.
 
Use of SQL Server Audit is recommended. All features of SQL Server Audit are available in the Enterprise and Developer editions of SQL Server 2014. It is not available at the database level in other editions. For this or legacy reasons, the instance may be using SQL Server Trace for auditing, which remains an acceptable solution for the time being. Note, however, that Microsoft intends to remove most aspects of Trace at some point after SQL Server 2016.
 
Since Trace does not provide for tracking SELECT statements, it is necessary to provide that part of the tracking at the application level. Because of this, it may also be appropriate to audit DELETE actions at the application level. However, to capture all DELETEs, whether they come from the application or bypass it, the Trace must be configured to cover them.
 
Use of SQL Server Audit's SCHEMA_OBJECT_ACCESS_GROUP causes capture of all accesses, successful and otherwise, to all schema-scoped objects. The [Succeeded] column in the audit output indicates the success or failure of the attempted action. Be aware, however, that it may report True in some cases where one would intuitively expect False. For example, SELECT 1/0 FROM SYS.ALL_OBJECTS will appear in the audit trail as successful, if the user has permission to perform that action, even though it contains an invalid expression. Some other actions that one would consider failures (such as selecting from a table that does not exist) may not appear at all.&lt;/VulnDiscussion&gt;&lt;FalsePositives&gt;&lt;/FalsePositives&gt;&lt;FalseNegatives&gt;&lt;/FalseNegatives&gt;&lt;Documentable&gt;false&lt;/Documentable&gt;&lt;Mitigations&gt;&lt;/Mitigations&gt;&lt;SeverityOverrideGuidance&gt;&lt;/SeverityOverrideGuidance&gt;&lt;PotentialImpacts&gt;&lt;/PotentialImpacts&gt;&lt;ThirdPartyTools&gt;&lt;/ThirdPartyTools&gt;&lt;MitigationControl&gt;&lt;/MitigationControl&gt;&lt;Responsibility&gt;&lt;/Responsibility&gt;&lt;IAControls&gt;&lt;/IAControls&gt;</description><reference><dc:title>DPMS Target SQL Server Database 2014</dc:title><dc:publisher>DISA</dc:publisher><dc:type>DPMS Target</dc:type><dc:subject>SQL Server Database 2014</dc:subject><dc:identifier>2637</dc:identifier></reference><ident system="http://iase.disa.mil/cci">CCI-000172</ident><fixtext fixref="F-73541r1_fix">Where SQL Server Trace is in use, create triggers to raise a custom event for DELETEs on each table holding categorized information. The examples provided in the supplemental file CustomTraceEvents.sql can serve as the basis for these.
 
Add a block of code to the supplemental file Trace.sql for each custom event class (integers in the range 82-91; the same event class may be used for all such triggers) used in these triggers. Execute Trace.sql.
 
If SQL Server Audit is in use, design and deploy an Audit that captures all auditable events and data items. The script provided in the supplemental file Audit.sql can be used as the basis for this. Supplement the standard audit data as necessary, using Extended Events and/or triggers.
 
Alternatively, to add the necessary data capture to an existing server audit specification, run the script:
USE [master];
GO
ALTER SERVER AUDIT SPECIFICATION &lt;server_audit_specification_name&gt; WITH (STATE = OFF);
GO
ALTER SERVER AUDIT SPECIFICATION &lt;server_audit_specification_name&gt; ADD (SCHEMA_OBJECT_ACCESS_GROUP);
GO
ALTER SERVER AUDIT SPECIFICATION &lt;server_audit_specification_name&gt; WITH (STATE = ON);
GO</fixtext><fix id="F-73541r1_fix" /><check system="C-68007r3_chk"><check-content-ref name="M" href="DPMS_XCCDF_Benchmark_MS_SQL_Server_2014_Database_STIG.xml" /><check-content>Review the system documentation to determine whether it is required to track categories of information, such as classification or sensitivity level. If it is not, this is not applicable (NA).
 
If neither SQL Server Audit nor SQL Server Trace is in use for audit purposes, this is a finding.
 
If SQL Server Trace is in use for audit purposes, review the Trace settings, and the triggers on the tables holding categorized information, to determine whether all DELETE actions on these tables are traced, including failed attempts. If not, this is a finding.
 
Check to see that all required event classes are being audited. From the query prompt:
SELECT * FROM sys.traces;
 
All currently defined traces for the SQL server instance will be listed. If no traces are returned, this is a finding.
 
Determine the trace(s) being used for the auditing requirement.
In the following, replace # with a trace ID being used for the auditing requirements.
From the query prompt:
SELECT DISTINCT(eventid) FROM sys.fn_trace_geteventinfo(#);
 
The following required event IDs should be among those listed; if not, this is a finding:
 
82-91 -- User-defined Event (at least one of these, matching the triggers; 90 is used in the supplied script)
162 -- User error message
 
 
If SQL Server Audit is in use, proceed as follows.
 
The basic SQL Server Audit configuration provided in the supplemental file Audit.sql uses the broad, server-level audit action group SCHEMA_OBJECT_ACCESS_GROUP for this purpose. SQL Server Audit's flexibility makes other techniques possible. If an alternative technique is in use and demonstrated effective, this is not a finding.
 
Determine the name(s) of the server audit specification(s) in use.
 
To look at audits and audit specifications, in Management Studio's object explorer, expand
&lt;server name&gt; &gt;&gt; Security &gt;&gt; Audits
and
&lt;server name&gt; &gt;&gt; Security &gt;&gt; Server Audit Specifications.
Also,
&lt;server name&gt; &gt;&gt; Databases &gt;&gt; &lt;database name&gt; &gt;&gt; Security &gt;&gt; Database Audit Specifications.
 
Alternatively, review the contents of the system views with "audit" in their names.
 
Run the following to verify that all SELECT, INSERT, UPDATE, and DELETE actions on tables and views are being audited:
USE [master];
GO
SELECT * FROM sys.server_audit_specification_details WHERE server_specification_id =
(SELECT server_specification_id FROM sys.server_audit_specifications WHERE [name] = '&lt;server_audit_specification_name&gt;')
AND audit_action_name = 'SCHEMA_OBJECT_ACCESS_GROUP';
 
If no row is returned, this is a finding.
 
If the audited_result column is not "FAILURE" or "SUCCESS AND FAILURE", this is a finding.</check-content></check></Rule></Group><Group id="V-67429"><title>SRG-APP-000502-DB-000348</title><description>&lt;GroupDescription&gt;&lt;/GroupDescription&gt;</description><Rule id="SV-81919r2_rule" severity="medium" weight="10.0"><version>SQL4-00-037300</version><title>Trace or Audit records must be generated when categorized information (e.g., classification levels/security levels) is deleted.</title><description>&lt;VulnDiscussion&gt;Changes in categorized information must be tracked. Without an audit trail, unauthorized access to protected data could go undetected.
 
For detailed information on categorizing information, refer to FIPS Publication 199, Standards for Security Categorization of Federal Information and Information Systems, and FIPS Publication 200, Minimum Security Requirements for Federal Information and Information Systems.
 
Use of SQL Server Audit is recommended. All features of SQL Server Audit are available in the Enterprise and Developer editions of SQL Server 2014. It is not available at the database level in other editions. For this or legacy reasons, the instance may be using SQL Server Trace for auditing, which remains an acceptable solution for the time being. Note, however, that Microsoft intends to remove most aspects of Trace at some point after SQL Server 2016.
 
Since Trace does not provide for tracking SELECT statements, it is necessary to provide that part of the tracking at the application level. Because of this, it may also be appropriate to audit DELETE actions at the application level. However, to capture all DELETEs, whether they come from the application or bypass it, the Trace must be configured to cover them.&lt;/VulnDiscussion&gt;&lt;FalsePositives&gt;&lt;/FalsePositives&gt;&lt;FalseNegatives&gt;&lt;/FalseNegatives&gt;&lt;Documentable&gt;false&lt;/Documentable&gt;&lt;Mitigations&gt;&lt;/Mitigations&gt;&lt;SeverityOverrideGuidance&gt;&lt;/SeverityOverrideGuidance&gt;&lt;PotentialImpacts&gt;&lt;/PotentialImpacts&gt;&lt;ThirdPartyTools&gt;&lt;/ThirdPartyTools&gt;&lt;MitigationControl&gt;&lt;/MitigationControl&gt;&lt;Responsibility&gt;&lt;/Responsibility&gt;&lt;IAControls&gt;&lt;/IAControls&gt;</description><reference><dc:title>DPMS Target SQL Server Database 2014</dc:title><dc:publisher>DISA</dc:publisher><dc:type>DPMS Target</dc:type><dc:subject>SQL Server Database 2014</dc:subject><dc:identifier>2637</dc:identifier></reference><ident system="http://iase.disa.mil/cci">CCI-000172</ident><fixtext fixref="F-73543r1_fix">Where SQL Server Trace is in use, create triggers to raise a custom event for DELETEs on each table holding categorized information. The examples provided in the supplemental file CustomTraceEvents.sql can serve as the basis for these.
 
Add a block of code to the supplemental file Trace.sql for each custom event class (integers in the range 82-91; the same event class may be used for all such triggers) used in these triggers. Execute Trace.sql.
 
If SQL Server Audit is in use, design and deploy an Audit that captures all auditable events and data items. The script provided in the supplemental file Audit.sql can be used as the basis for this. Supplement the standard audit data as necessary, using Extended Events and/or triggers.
 
Alternatively, to add the necessary data capture to an existing server audit specification, run the script:
USE [master];
GO
ALTER SERVER AUDIT SPECIFICATION &lt;server_audit_specification_name&gt; WITH (STATE = OFF);
GO
ALTER SERVER AUDIT SPECIFICATION &lt;server_audit_specification_name&gt; ADD (SCHEMA_OBJECT_ACCESS_GROUP);
GO
ALTER SERVER AUDIT SPECIFICATION &lt;server_audit_specification_name&gt; WITH (STATE = ON);
GO</fixtext><fix id="F-73543r1_fix" /><check system="C-68009r4_chk"><check-content-ref name="M" href="DPMS_XCCDF_Benchmark_MS_SQL_Server_2014_Database_STIG.xml" /><check-content>Review the system documentation to determine whether it is required to track categories of information, such as classification or sensitivity level. If it is not, this is not applicable (NA).
 
If neither SQL Server Audit nor SQL Server Trace is in use for audit purposes, this is a finding.
 
If SQL Server Trace is in use for audit purposes, review the triggers on all tables holding categorized information, to determine whether trace events are generated for all DELETE actions on these tables. If not, this is a finding.
 
Check to see that all required event classes are being audited. From the query prompt:
SELECT * FROM sys.traces;
 
All currently defined traces for the SQL server instance will be listed. If no traces are returned, this is a finding.
 
Determine the trace(s) being used for the auditing requirement.
 
In the following, replace # with a trace ID being used for the auditing requirements.
 
From the query prompt:
SELECT DISTINCT(eventid) FROM sys.fn_trace_geteventinfo(#);
 
The following required event IDs should be among those listed; if not, this is a finding:
 
82-91 -- User-defined Event (at least one of these, matching the triggers; 90 is used in the supplied script)
162 -- User error message
 
 
If SQL Server Audit is in use, proceed as follows.
 
The basic SQL Server Audit configuration provided in the supplemental file Audit.sql uses the broad, server-level audit action group SCHEMA_OBJECT_ACCESS_GROUP for this purpose. SQL Server Audit's flexibility makes other techniques possible. If an alternative technique is in use and demonstrated effective, this is not a finding.
 
Determine the name(s) of the server audit specification(s) in use.
 
To look at audits and audit specifications, in Management Studio's object explorer, expand
&lt;server name&gt; &gt;&gt; Security &gt;&gt; Audits
and
&lt;server name&gt; &gt;&gt; Security &gt;&gt; Server Audit Specifications.
Also,
&lt;server name&gt; &gt;&gt; Databases &gt;&gt; &lt;database name&gt; &gt;&gt; Security &gt;&gt; Database Audit Specifications.
 
Alternatively, review the contents of the system views with "audit" in their names.
 
Run the following to verify that all SELECT, INSERT, UPDATE, and DELETE actions on tables and views are being audited:
USE [master];
GO
SELECT * FROM sys.server_audit_specification_details WHERE server_specification_id =
(SELECT server_specification_id FROM sys.server_audit_specifications WHERE [name] = '&lt;server_audit_specification_name&gt;')
AND audit_action_name = 'SCHEMA_OBJECT_ACCESS_GROUP';
 
If no row is returned, this is a finding.
 
If the audited_result column is not "SUCCESS" or "SUCCESS AND FAILURE", this is a finding.</check-content></check></Rule></Group><Group id="V-67431"><title>SRG-APP-000501-DB-000337</title><description>&lt;GroupDescription&gt;&lt;/GroupDescription&gt;</description><Rule id="SV-81921r3_rule" severity="medium" weight="10.0"><version>SQL4-00-037200</version><title>SQL Server must generate Trace or Audit records when unsuccessful attempts to drop locally-defined security objects occur.</title><description>&lt;VulnDiscussion&gt;SQL Server protects its built-in security objects (tables, views, functions, procedures, etc.) from alteration by database users and administrators. However, applications sometimes have additional, security-related objects defined in the database. DROP operations on these objects must be monitored.
 
To aid in diagnosis, it is necessary to keep track of failed attempts in addition to the successful ones.
 
Use of SQL Server Audit is recommended. All features of SQL Server Audit are available in the Enterprise and Developer editions of SQL Server 2014. It is not available at the database level in other editions. For this or legacy reasons, the instance may be using SQL Server Trace for auditing, which remains an acceptable solution for the time being. Note, however, that Microsoft intends to remove most aspects of Trace at some point after SQL Server 2016.
 
Use of SQL Server Audit's SCHEMA_OBJECT_CHANGE_GROUP causes capture of all attempts, successful and otherwise, to CREATE, ALTER, or DROP any schema-scoped objects. The [Succeeded] column in the audit output indicates the success or failure of the attempted action. Be aware, however, that it may report True in some cases where one would intuitively expect False.&lt;/VulnDiscussion&gt;&lt;FalsePositives&gt;&lt;/FalsePositives&gt;&lt;FalseNegatives&gt;&lt;/FalseNegatives&gt;&lt;Documentable&gt;false&lt;/Documentable&gt;&lt;Mitigations&gt;&lt;/Mitigations&gt;&lt;SeverityOverrideGuidance&gt;&lt;/SeverityOverrideGuidance&gt;&lt;PotentialImpacts&gt;&lt;/PotentialImpacts&gt;&lt;ThirdPartyTools&gt;&lt;/ThirdPartyTools&gt;&lt;MitigationControl&gt;&lt;/MitigationControl&gt;&lt;Responsibility&gt;&lt;/Responsibility&gt;&lt;IAControls&gt;&lt;/IAControls&gt;</description><reference><dc:title>DPMS Target SQL Server Database 2014</dc:title><dc:publisher>DISA</dc:publisher><dc:type>DPMS Target</dc:type><dc:subject>SQL Server Database 2014</dc:subject><dc:identifier>2637</dc:identifier></reference><ident system="http://iase.disa.mil/cci">CCI-000172</ident><fixtext fixref="F-73545r2_fix">Where SQL Server Trace is in use, define and enable a trace that captures all auditable events. The script provided in the supplemental file Trace.sql can be used to do this.
 
Add blocks of code to Trace.sql for each custom event class (integers in the range 82-91; the same event class may be used for all such triggers) used in these triggers.
 
Create triggers to raise a custom event on each locally-defined security table that requires tracking of Insert-Update-Delete operations. The examples provided in the supplemental file CustomTraceEvents.sql can serve as the basis for these.
 
Execute Trace.sql.
 
Where SQL Server Audit is in use, design and deploy a SQL Server Audit that captures all auditable events. The script provided in the supplemental file Audit.sql can be used for this.
 
Alternatively, to add the necessary data capture to an existing server audit specification, run the script:
USE [master];
GO
ALTER SERVER AUDIT SPECIFICATION &lt;server_audit_specification_name&gt; WITH (STATE = OFF);
GO
ALTER SERVER AUDIT SPECIFICATION &lt;server_audit_specification_name&gt; ADD (SCHEMA_OBJECT_CHANGE_GROUP);
GO
ALTER SERVER AUDIT SPECIFICATION &lt;server_audit_specification_name&gt; WITH (STATE = ON);
GO</fixtext><fix id="F-73545r2_fix" /><check system="C-68011r4_chk"><check-content-ref name="M" href="DPMS_XCCDF_Benchmark_MS_SQL_Server_2014_Database_STIG.xml" /><check-content>If neither SQL Server Audit nor SQL Server Trace is in use for audit purposes, this is a finding.
 
If there are no locally-defined security tables or procedures, this is not a finding.
 
If SQL Server Trace is in use for audit purposes, verify that all required events are being audited. From the query prompt:
SELECT * FROM sys.traces;
 
All currently defined traces for the SQL server instance will be listed. If no traces are returned, this is a finding.
 
Determine the trace(s) being used for the auditing requirement.
In the following, replace # with a trace ID being used for the auditing requirements.
From the query prompt:
SELECT DISTINCT(eventid) FROM sys.fn_trace_geteventinfo(#);
 
The following required event IDs should all be among those listed; if not, this is a finding:
 
46 -- Object:Created
47 -- Object:Deleted
162 -- User error message
164 -- Object:Altered
 
If SQL Server Audit is in use, proceed as follows.
 
The basic SQL Server Audit configuration provided in the supplemental file Audit.sql uses the broad, server-level audit action group SCHEMA_OBJECT_CHANGE_GROUP for this purpose. SQL Server Audit's flexibility makes other techniques possible. If an alternative technique is in use and demonstrated effective, this is not a finding.
 
Determine the name(s) of the server audit specification(s) in use.
 
To look at audits and audit specifications, in Management Studio's object explorer, expand
&lt;server name&gt; &gt;&gt; Security &gt;&gt; Audits
and
&lt;server name&gt; &gt;&gt; Security &gt;&gt; Server Audit Specifications.
Also,
&lt;server name&gt; &gt;&gt; Databases &gt;&gt; &lt;database name&gt; &gt;&gt; Security &gt;&gt; Database Audit Specifications.
 
Alternatively, review the contents of the system views with "audit" in their names.
 
Run the following to verify that all CREATE, ALTER, and DROP actions on any locally-defined permissions tables, procedures and functions are being audited:
USE [master];
GO
SELECT * FROM sys.server_audit_specification_details WHERE server_specification_id =
(SELECT server_specification_id FROM sys.server_audit_specifications WHERE [name] = '&lt;server_audit_specification_name&gt;')
AND audit_action_name = 'SCHEMA_OBJECT_CHANGE_GROUP';
 
If no row is returned, this is a finding.
 
If the audited_result column is not "FAILURE" or "SUCCESS AND FAILURE", this is a finding.</check-content></check></Rule></Group><Group id="V-67433"><title>SRG-APP-000501-DB-000336</title><description>&lt;GroupDescription&gt;&lt;/GroupDescription&gt;</description><Rule id="SV-81923r3_rule" severity="medium" weight="10.0"><version>SQL4-00-037100</version><title>SQL Server must generate Trace or Audit records when locally-defined security objects are dropped.</title><description>&lt;VulnDiscussion&gt;SQL Server protects its built-in security objects (tables, views, functions, procedures, etc.) from alteration by database users and administrators. However, applications sometimes have additional, security-related objects defined in the database. DROP operations on these objects must be monitored.
 
Use of SQL Server Audit is recommended. All features of SQL Server Audit are available in the Enterprise and Developer editions of SQL Server 2014. It is not available at the database level in other editions. For this or legacy reasons, the instance may be using SQL Server Trace for auditing, which remains an acceptable solution for the time being. Note, however, that Microsoft intends to remove most aspects of Trace at some point after SQL Server 2016.&lt;/VulnDiscussion&gt;&lt;FalsePositives&gt;&lt;/FalsePositives&gt;&lt;FalseNegatives&gt;&lt;/FalseNegatives&gt;&lt;Documentable&gt;false&lt;/Documentable&gt;&lt;Mitigations&gt;&lt;/Mitigations&gt;&lt;SeverityOverrideGuidance&gt;&lt;/SeverityOverrideGuidance&gt;&lt;PotentialImpacts&gt;&lt;/PotentialImpacts&gt;&lt;ThirdPartyTools&gt;&lt;/ThirdPartyTools&gt;&lt;MitigationControl&gt;&lt;/MitigationControl&gt;&lt;Responsibility&gt;&lt;/Responsibility&gt;&lt;IAControls&gt;&lt;/IAControls&gt;</description><reference><dc:title>DPMS Target SQL Server Database 2014</dc:title><dc:publisher>DISA</dc:publisher><dc:type>DPMS Target</dc:type><dc:subject>SQL Server Database 2014</dc:subject><dc:identifier>2637</dc:identifier></reference><ident system="http://iase.disa.mil/cci">CCI-000172</ident><fixtext fixref="F-73547r2_fix">Where SQL Server Trace is in use, define and enable a trace that captures all auditable events. The script provided in the supplemental file Trace.sql can be used to do this.
 
Add blocks of code to Trace.sql for each custom event class (integers in the range 82-91; the same event class may be used for all such triggers) used in these triggers.
 
Create triggers to raise a custom event on each locally-defined security table that requires tracking of Insert-Update-Delete operations. The examples provided in the supplemental file CustomTraceEvents.sql can serve as the basis for these.
 
Execute Trace.sql.
 
Where SQL Server Audit is in use, design and deploy a SQL Server Audit that captures all auditable events. The script provided in the supplemental file Audit.sql can be used for this.
 
Alternatively, to add the necessary data capture to an existing server audit specification, run the script:
USE [master];
GO
ALTER SERVER AUDIT SPECIFICATION &lt;server_audit_specification_name&gt; WITH (STATE = OFF);
GO
ALTER SERVER AUDIT SPECIFICATION &lt;server_audit_specification_name&gt; ADD (SCHEMA_OBJECT_CHANGE_GROUP);
GO
ALTER SERVER AUDIT SPECIFICATION &lt;server_audit_specification_name&gt; WITH (STATE = ON);
GO</fixtext><fix id="F-73547r2_fix" /><check system="C-68013r4_chk"><check-content-ref name="M" href="DPMS_XCCDF_Benchmark_MS_SQL_Server_2014_Database_STIG.xml" /><check-content>If neither SQL Server Audit nor SQL Server Trace is in use for audit purposes, this is a finding.
 
If there are no locally-defined security tables or procedures, this is not a finding.
 
If SQL Server Trace is in use for audit purposes, verify that all required events are being audited. From the query prompt:
SELECT * FROM sys.traces;
All currently defined traces for the SQL server instance will be listed.
 
If no traces are returned, this is a finding.
 
Determine the trace(s) being used for the auditing requirement.
In the following, replace # with a trace ID being used for the auditing requirements.
From the query prompt:
SELECT DISTINCT(eventid) FROM sys.fn_trace_geteventinfo(#);
 
The following required event IDs should all be among those listed; if not, this is a finding:
 
46 -- Object:Created
47 -- Object:Deleted
162 -- User error message
164 -- Object:Altered
 
If SQL Server Audit is in use, proceed as follows.
 
The basic SQL Server Audit configuration provided in the supplemental file Audit.sql uses the broad, server-level audit action group SCHEMA_OBJECT_CHANGE_GROUP for this purpose. SQL Server Audit's flexibility makes other techniques possible. If an alternative technique is in use and demonstrated effective, this is not a finding.
 
Determine the name(s) of the server audit specification(s) in use.
 
To look at audits and audit specifications, in Management Studio's object explorer, expand
&lt;server name&gt; &gt;&gt; Security &gt;&gt; Audits
and
&lt;server name&gt; &gt;&gt; Security &gt;&gt; Server Audit Specifications.
Also,
&lt;server name&gt; &gt;&gt; Databases &gt;&gt; &lt;database name&gt; &gt;&gt; Security &gt;&gt; Database Audit Specifications.
 
Alternatively, review the contents of the system views with "audit" in their names.
 
Run the following to verify that all CREATE, ALTER, and DROP actions on any locally-defined permissions tables, procedures and functions are being audited:
USE [master];
GO
SELECT * FROM sys.server_audit_specification_details WHERE server_specification_id =
(SELECT server_specification_id FROM sys.server_audit_specifications WHERE [name] = '&lt;server_audit_specification_name&gt;')
AND audit_action_name = 'SCHEMA_OBJECT_CHANGE_GROUP';
 
If no row is returned, this is a finding.
 
If the audited_result column is not "SUCCESS" or "SUCCESS AND FAILURE", this is a finding.</check-content></check></Rule></Group><Group id="V-67435"><title>SRG-APP-000496-DB-000335</title><description>&lt;GroupDescription&gt;&lt;/GroupDescription&gt;</description><Rule id="SV-81925r2_rule" severity="medium" weight="10.0"><version>SQL4-00-036500</version><title>SQL Server must generate Trace or Audit records when unsuccessful attempts to modify locally-defined security objects occur.</title><description>&lt;VulnDiscussion&gt;SQL Server protects its built-in security objects (tables, views, functions, procedures, etc.) from alteration by database users and administrators. However, applications sometimes have additional, security-related objects defined in the database. ALTER operations on these objects must be monitored.
 
To aid in diagnosis, it is necessary to keep track of failed attempts in addition to the successful ones.
 
Use of SQL Server Audit is recommended. All features of SQL Server Audit are available in the Enterprise and Developer editions of SQL Server 2014. It is not available at the database level in other editions. For this or legacy reasons, the instance may be using SQL Server Trace for auditing, which remains an acceptable solution for the time being. Note, however, that Microsoft intends to remove most aspects of Trace at some point after SQL Server 2016.
 
Use of SQL Server Audit's SCHEMA_OBJECT_CHANGE_GROUP causes capture of all attempts, successful and otherwise, to CREATE, ALTER, or DROP any schema-scoped objects. The [Succeeded] column in the audit output indicates the success or failure of the attempted action. Be aware, however, that it may report True in some cases where one would intuitively expect False.&lt;/VulnDiscussion&gt;&lt;FalsePositives&gt;&lt;/FalsePositives&gt;&lt;FalseNegatives&gt;&lt;/FalseNegatives&gt;&lt;Documentable&gt;false&lt;/Documentable&gt;&lt;Mitigations&gt;&lt;/Mitigations&gt;&lt;SeverityOverrideGuidance&gt;&lt;/SeverityOverrideGuidance&gt;&lt;PotentialImpacts&gt;&lt;/PotentialImpacts&gt;&lt;ThirdPartyTools&gt;&lt;/ThirdPartyTools&gt;&lt;MitigationControl&gt;&lt;/MitigationControl&gt;&lt;Responsibility&gt;&lt;/Responsibility&gt;&lt;IAControls&gt;&lt;/IAControls&gt;</description><reference><dc:title>DPMS Target SQL Server Database 2014</dc:title><dc:publisher>DISA</dc:publisher><dc:type>DPMS Target</dc:type><dc:subject>SQL Server Database 2014</dc:subject><dc:identifier>2637</dc:identifier></reference><ident system="http://iase.disa.mil/cci">CCI-000172</ident><fixtext fixref="F-73549r1_fix">Where SQL Server Trace is in use, define and enable a trace that captures all auditable events. The script provided in the supplemental file Trace.sql can be used to do this.
 
Where SQL Server Audit is in use, design and deploy a SQL Server Audit that captures all auditable events. The script provided in the supplemental file Audit.sql can be used for this.
 
Alternatively, to add the necessary data capture to an existing server audit specification, run the script:
USE [master];
GO
ALTER SERVER AUDIT SPECIFICATION &lt;server_audit_specification_name&gt; WITH (STATE = OFF);
GO
ALTER SERVER AUDIT SPECIFICATION &lt;server_audit_specification_name&gt; ADD (SCHEMA_OBJECT_CHANGE_GROUP);
GO
ALTER SERVER AUDIT SPECIFICATION &lt;server_audit_specification_name&gt; WITH (STATE = ON);
GO</fixtext><fix id="F-73549r1_fix" /><check system="C-68015r3_chk"><check-content-ref name="M" href="DPMS_XCCDF_Benchmark_MS_SQL_Server_2014_Database_STIG.xml" /><check-content>If there are no locally-defined security tables or procedures, this is not a finding.
 
If neither SQL Server Audit nor SQL Server Trace is in use for audit purposes, this is a finding.
 
If SQL Server Trace is in use for audit purposes, verify that all required events are being audited. From the query prompt:
SELECT * FROM sys.traces;
 
All currently defined traces for the SQL server instance will be listed. If no traces are returned, this is a finding.
 
Determine the trace(s) being used for the auditing requirement.
In the following, replace # with a trace ID being used for the auditing requirements.
From the query prompt:
SELECT DISTINCT(eventid) FROM sys.fn_trace_geteventinfo(#);
 
The following required event IDs should all be among those listed; if not, this is a finding:
 
46 -- Object:Created
47 -- Object:Deleted
162 -- User error message
164 -- Object:Altered
 
 
If SQL Server Audit is in use, proceed as follows.
 
The basic SQL Server Audit configuration provided in the supplemental file Audit.sql uses the broad, server-level audit action group SCHEMA_OBJECT_CHANGE_GROUP for this purpose. SQL Server Audit's flexibility makes other techniques possible. If an alternative technique is in use and demonstrated effective, this is not a finding.
 
Determine the name(s) of the server audit specification(s) in use.
 
To look at audits and audit specifications, in Management Studio's object explorer, expand
&lt;server name&gt; &gt;&gt; Security &gt;&gt; Audits
and
&lt;server name&gt; &gt;&gt; Security &gt;&gt; Server Audit Specifications.
Also,
&lt;server name&gt; &gt;&gt; Databases &gt;&gt; &lt;database name&gt; &gt;&gt; Security &gt;&gt; Database Audit Specifications.
 
Alternatively, review the contents of the system views with "audit" in their names.
 
Run the following to verify that all CREATE, ALTER, and DROP actions on any locally-defined permissions tables, procedures and functions are being audited:
USE [master];
GO
SELECT * FROM sys.server_audit_specification_details WHERE server_specification_id =
(SELECT server_specification_id FROM sys.server_audit_specifications WHERE [name] = '&lt;server_audit_specification_name&gt;')
AND audit_action_name = 'SCHEMA_OBJECT_CHANGE_GROUP';
 
If no row is returned, this is a finding.
 
If the audited_result column is not "FAILURE" or "SUCCESS AND FAILURE", this is a finding.</check-content></check></Rule></Group><Group id="V-67437"><title>SRG-APP-000498-DB-000346</title><description>&lt;GroupDescription&gt;&lt;/GroupDescription&gt;</description><Rule id="SV-81927r2_rule" severity="medium" weight="10.0"><version>SQL4-00-036600</version><title>Trace or Audit records must be generated when categorized information (e.g., classification levels/security levels) is created.</title><description>&lt;VulnDiscussion&gt;Changes in categorized information must be tracked. Without an audit trail, unauthorized access to protected data could go undetected.
 
For detailed information on categorizing information, refer to FIPS Publication 199, Standards for Security Categorization of Federal Information and Information Systems, and FIPS Publication 200, Minimum Security Requirements for Federal Information and Information Systems.
 
Use of SQL Server Audit is recommended. All features of SQL Server Audit are available in the Enterprise and Developer editions of SQL Server 2014. It is not available at the database level in other editions. For this or legacy reasons, the instance may be using SQL Server Trace for auditing, which remains an acceptable solution for the time being. Note, however, that Microsoft intends to remove most aspects of Trace at some point after SQL Server 2016.
 
Since Trace does not provide for tracking SELECT statements, it is necessary to provide that part of the tracking at the application level. Because of this, it may also be appropriate to audit INSERT actions at the application level. However, to capture all INSERTs, whether they come from the application or bypass it, the Trace must be configured to cover them.&lt;/VulnDiscussion&gt;&lt;FalsePositives&gt;&lt;/FalsePositives&gt;&lt;FalseNegatives&gt;&lt;/FalseNegatives&gt;&lt;Documentable&gt;false&lt;/Documentable&gt;&lt;Mitigations&gt;&lt;/Mitigations&gt;&lt;SeverityOverrideGuidance&gt;&lt;/SeverityOverrideGuidance&gt;&lt;PotentialImpacts&gt;&lt;/PotentialImpacts&gt;&lt;ThirdPartyTools&gt;&lt;/ThirdPartyTools&gt;&lt;MitigationControl&gt;&lt;/MitigationControl&gt;&lt;Responsibility&gt;&lt;/Responsibility&gt;&lt;IAControls&gt;&lt;/IAControls&gt;</description><reference><dc:title>DPMS Target SQL Server Database 2014</dc:title><dc:publisher>DISA</dc:publisher><dc:type>DPMS Target</dc:type><dc:subject>SQL Server Database 2014</dc:subject><dc:identifier>2637</dc:identifier></reference><ident system="http://iase.disa.mil/cci">CCI-000172</ident><fixtext fixref="F-73551r1_fix">Where SQL Server Trace is in use, create triggers to raise a custom event for INSERTs on each table holding categorized information. The examples provided in the supplemental file CustomTraceEvents.sql can serve as the basis for these.
 
Add a block of code to the supplemental file Trace.sql for each custom event class (integers in the range 82-91; the same event class may be used for all such triggers) used in these triggers. Execute Trace.sql.
 
If SQL Server Audit is in use, design and deploy an Audit that captures all auditable events and data items. The script provided in the supplemental file Audit.sql can be used as the basis for this. Supplement the standard audit data as necessary, using Extended Events and/or triggers.
 
Alternatively, to add the necessary data capture to an existing server audit specification, run the script:
USE [master];
GO
ALTER SERVER AUDIT SPECIFICATION &lt;server_audit_specification_name&gt; WITH (STATE = OFF);
GO
ALTER SERVER AUDIT SPECIFICATION &lt;server_audit_specification_name&gt; ADD (SCHEMA_OBJECT_ACCESS_GROUP);
GO
ALTER SERVER AUDIT SPECIFICATION &lt;server_audit_specification_name&gt; WITH (STATE = ON);
GO</fixtext><fix id="F-73551r1_fix" /><check system="C-68017r3_chk"><check-content-ref name="M" href="DPMS_XCCDF_Benchmark_MS_SQL_Server_2014_Database_STIG.xml" /><check-content>Review the system documentation to determine whether it is required to track categories of information, such as classification or sensitivity level. If it is not, this is not applicable (NA).
 
If neither SQL Server Audit nor SQL Server Trace is in use for audit purposes, this is a finding.
 
If SQL Server Trace is in use for audit purposes, review the Trace settings, and the triggers on the tables holding categorized information, to determine whether all INSERT actions on these tables are traced, including failed attempts. If not, this is a finding.
 
Check to see that all required event classes are being audited. From the query prompt:
SELECT * FROM sys.traces;
 
All currently defined traces for the SQL server instance will be listed. If no traces are returned, this is a finding.
 
Determine the trace(s) being used for the auditing requirement.
In the following, replace # with a trace ID being used for the auditing requirements.
From the query prompt:
SELECT DISTINCT(eventid) FROM sys.fn_trace_geteventinfo(#);
 
The following required event IDs should be among those listed; if not, this is a finding:
 
82-91 -- User-defined Event (at least one of these, matching the triggers; 90 is used in the supplied script)
162 -- User error message
 
 
If SQL Server Audit is in use, proceed as follows.
 
The basic SQL Server Audit configuration provided in the supplemental file Audit.sql uses the broad, server-level audit action group SCHEMA_OBJECT_ACCESS_GROUP for this purpose. SQL Server Audit's flexibility makes other techniques possible. If an alternative technique is in use and demonstrated effective, this is not a finding.
 
Determine the name(s) of the server audit specification(s) in use.
 
To look at audits and audit specifications, in Management Studio's object explorer, expand
&lt;server name&gt; &gt;&gt; Security &gt;&gt; Audits
and
&lt;server name&gt; &gt;&gt; Security &gt;&gt; Server Audit Specifications.
Also,
&lt;server name&gt; &gt;&gt; Databases &gt;&gt; &lt;database name&gt; &gt;&gt; Security &gt;&gt; Database Audit Specifications.
 
Alternatively, review the contents of the system views with "audit" in their names.
 
Run the following to verify that all SELECT, INSERT, UPDATE, and DELETE actions on tables and views are being audited:
USE [master];
GO
SELECT * FROM sys.server_audit_specification_details WHERE server_specification_id =
(SELECT server_specification_id FROM sys.server_audit_specifications WHERE [name] = '&lt;server_audit_specification_name&gt;')
AND audit_action_name = 'SCHEMA_OBJECT_ACCESS_GROUP';
 
If no row is returned, this is a finding.
 
If the audited_result column is not "SUCCESS" or "SUCCESS AND FAILURE", this is a finding.</check-content></check></Rule></Group><Group id="V-67439"><title>SRG-APP-000498-DB-000347</title><description>&lt;GroupDescription&gt;&lt;/GroupDescription&gt;</description><Rule id="SV-81929r2_rule" severity="medium" weight="10.0"><version>SQL4-00-036800</version><title>Trace or Audit records must be generated when unsuccessful attempts to create categorized information (e.g., classification levels/security levels) occur.</title><description>&lt;VulnDiscussion&gt;Changes in categorized information must be tracked. Without an audit trail, unauthorized access to protected data could go undetected.
 
To aid in diagnosis, it is necessary to keep track of failed attempts in addition to the successful ones.
 
For detailed information on categorizing information, refer to FIPS Publication 199, Standards for Security Categorization of Federal Information and Information Systems, and FIPS Publication 200, Minimum Security Requirements for Federal Information and Information Systems.
 
Use of SQL Server Audit is recommended. All features of SQL Server Audit are available in the Enterprise and Developer editions of SQL Server 2014. It is not available at the database level in other editions. For this or legacy reasons, the instance may be using SQL Server Trace for auditing, which remains an acceptable solution for the time being. Note, however, that Microsoft intends to remove most aspects of Trace at some point after SQL Server 2016.
 
Since Trace does not provide for tracking SELECT statements, it is necessary to provide that part of the tracking at the application level. Because of this, it may also be appropriate to audit INSERT actions at the application level. However, to capture all INSERTs, whether they come from the application or bypass it, the Trace must be configured to cover them.
 
Use of SQL Server Audit's SCHEMA_OBJECT_ACCESS_GROUP causes capture of all accesses, successful and otherwise, to all schema-scoped objects. The [Succeeded] column in the audit output indicates the success or failure of the attempted action. Be aware, however, that it may report True in some cases where one would intuitively expect False; and some other actions that one would consider failures (such as selecting from a table that does not exist) may not appear at all.&lt;/VulnDiscussion&gt;&lt;FalsePositives&gt;&lt;/FalsePositives&gt;&lt;FalseNegatives&gt;&lt;/FalseNegatives&gt;&lt;Documentable&gt;false&lt;/Documentable&gt;&lt;Mitigations&gt;&lt;/Mitigations&gt;&lt;SeverityOverrideGuidance&gt;&lt;/SeverityOverrideGuidance&gt;&lt;PotentialImpacts&gt;&lt;/PotentialImpacts&gt;&lt;ThirdPartyTools&gt;&lt;/ThirdPartyTools&gt;&lt;MitigationControl&gt;&lt;/MitigationControl&gt;&lt;Responsibility&gt;&lt;/Responsibility&gt;&lt;IAControls&gt;&lt;/IAControls&gt;</description><reference><dc:title>DPMS Target SQL Server Database 2014</dc:title><dc:publisher>DISA</dc:publisher><dc:type>DPMS Target</dc:type><dc:subject>SQL Server Database 2014</dc:subject><dc:identifier>2637</dc:identifier></reference><ident system="http://iase.disa.mil/cci">CCI-000172</ident><fixtext fixref="F-73553r1_fix">Where SQL Server Trace is in use, create triggers to raise a custom event for INSERTs on each table holding categorized information. The examples provided in the supplemental file CustomTraceEvents.sql can serve as the basis for these.
 
Add a block of code to the supplemental file Trace.sql for each custom event class (integers in the range 82-91; the same event class may be used for all such triggers) used in these triggers. Execute Trace.sql.
 
If SQL Server Audit is in use, design and deploy an Audit that captures all auditable events and data items. The script provided in the supplemental file Audit.sql can be used as the basis for this. Supplement the standard audit data as necessary, using Extended Events and/or triggers.
 
Alternatively, to add the necessary data capture to an existing server audit specification, run the script:
USE [master];
GO
ALTER SERVER AUDIT SPECIFICATION &lt;server_audit_specification_name&gt; WITH (STATE = OFF);
GO
ALTER SERVER AUDIT SPECIFICATION &lt;server_audit_specification_name&gt; ADD (SCHEMA_OBJECT_ACCESS_GROUP);
GO
ALTER SERVER AUDIT SPECIFICATION &lt;server_audit_specification_name&gt; WITH (STATE = ON);
GO</fixtext><fix id="F-73553r1_fix" /><check system="C-68019r3_chk"><check-content-ref name="M" href="DPMS_XCCDF_Benchmark_MS_SQL_Server_2014_Database_STIG.xml" /><check-content>Review the system documentation to determine whether it is required to track categories of information, such as classification or sensitivity level. If it is not, this is not applicable (NA).
 
If neither SQL Server Audit nor SQL Server Trace is in use for audit purposes, this is a finding.
 
If SQL Server Trace is in use for audit purposes, review the Trace settings, and the triggers on the tables holding categorized information, to determine whether all INSERT actions on these tables are traced, including failed attempts. If not, this is a finding.
 
Check to see that all required event classes are being audited. From the query prompt:
SELECT * FROM sys.traces;
 
All currently defined traces for the SQL server instance will be listed. If no traces are returned, this is a finding.
 
Determine the trace(s) being used for the auditing requirement.
In the following, replace # with a trace ID being used for the auditing requirements.
From the query prompt:
SELECT DISTINCT(eventid) FROM sys.fn_trace_geteventinfo(#);
 
The following required event IDs should be among those listed; if not, this is a finding:
 
82-91 -- User-defined Event (at least one of these, matching the triggers; 90 is used in the supplied script)
162 -- User error message
 
 
If SQL Server Audit is in use, proceed as follows.
 
The basic SQL Server Audit configuration provided in the supplemental file Audit.sql uses the broad, server-level audit action group SCHEMA_OBJECT_ACCESS_GROUP for this purpose. SQL Server Audit's flexibility makes other techniques possible. If an alternative technique is in use and demonstrated effective, this is not a finding.
 
Determine the name(s) of the server audit specification(s) in use.
 
To look at audits and audit specifications, in Management Studio's object explorer, expand
&lt;server name&gt; &gt;&gt; Security &gt;&gt; Audits
and
&lt;server name&gt; &gt;&gt; Security &gt;&gt; Server Audit Specifications.
Also,
&lt;server name&gt; &gt;&gt; Databases &gt;&gt; &lt;database name&gt; &gt;&gt; Security &gt;&gt; Database Audit Specifications.
 
Alternatively, review the contents of the system views with "audit" in their names.
 
Run the following to verify that all SELECT, INSERT, UPDATE, and DELETE actions on tables and views are being audited:
USE [master];
GO
SELECT * FROM sys.server_audit_specification_details WHERE server_specification_id =
(SELECT server_specification_id FROM sys.server_audit_specifications WHERE [name] = '&lt;server_audit_specification_name&gt;')
AND audit_action_name = 'SCHEMA_OBJECT_ACCESS_GROUP';
 
If no row is returned, this is a finding.
 
If the audited_result column is not "FAILURE" or "SUCCESS AND FAILURE", this is a finding.</check-content></check></Rule></Group><Group id="V-67441"><title>SRG-APP-000498-DB-000346</title><description>&lt;GroupDescription&gt;&lt;/GroupDescription&gt;</description><Rule id="SV-81931r2_rule" severity="medium" weight="10.0"><version>SQL4-00-036650</version><title>Trace or Audit records must be generated when categorized information (e.g., classification levels/security levels) is modified.</title><description>&lt;VulnDiscussion&gt;Changes in categorized information must be tracked. Without an audit trail, unauthorized access to protected data could go undetected.
 
For detailed information on categorizing information, refer to FIPS Publication 199, Standards for Security Categorization of Federal Information and Information Systems, and FIPS Publication 200, Minimum Security Requirements for Federal Information and Information Systems.
 
Use of SQL Server Audit is recommended. All features of SQL Server Audit are available in the Enterprise and Developer editions of SQL Server 2014. It is not available at the database level in other editions. For this or legacy reasons, the instance may be using SQL Server Trace for auditing, which remains an acceptable solution for the time being. Note, however, that Microsoft intends to remove most aspects of Trace at some point after SQL Server 2016.
 
Since Trace does not provide for tracking SELECT statements, it is necessary to provide that part of the tracking at the application level. Because of this, it may also be appropriate to audit UPDATE actions at the application level. However, to capture all UPDATEs, whether they come from the application or bypass it, the Trace must be configured to cover them.&lt;/VulnDiscussion&gt;&lt;FalsePositives&gt;&lt;/FalsePositives&gt;&lt;FalseNegatives&gt;&lt;/FalseNegatives&gt;&lt;Documentable&gt;false&lt;/Documentable&gt;&lt;Mitigations&gt;&lt;/Mitigations&gt;&lt;SeverityOverrideGuidance&gt;&lt;/SeverityOverrideGuidance&gt;&lt;PotentialImpacts&gt;&lt;/PotentialImpacts&gt;&lt;ThirdPartyTools&gt;&lt;/ThirdPartyTools&gt;&lt;MitigationControl&gt;&lt;/MitigationControl&gt;&lt;Responsibility&gt;&lt;/Responsibility&gt;&lt;IAControls&gt;&lt;/IAControls&gt;</description><reference><dc:title>DPMS Target SQL Server Database 2014</dc:title><dc:publisher>DISA</dc:publisher><dc:type>DPMS Target</dc:type><dc:subject>SQL Server Database 2014</dc:subject><dc:identifier>2637</dc:identifier></reference><ident system="http://iase.disa.mil/cci">CCI-000172</ident><fixtext fixref="F-73555r1_fix">Where SQL Server Trace is in use, create triggers to raise a custom event for UPDATEs on each table holding categorized information. The examples provided in the supplemental file CustomTraceEvents.sql can serve as the basis for these.
 
Add a block of code to the supplemental file Trace.sql for each custom event class (integers in the range 82-91; the same event class may be used for all such triggers) used in these triggers. Execute Trace.sql.
 
If SQL Server Audit is in use, design and deploy an Audit that captures all auditable events and data items. The script provided in the supplemental file Audit.sql can be used as the basis for this. Supplement the standard audit data as necessary, using Extended Events and/or triggers.
 
Alternatively, to add the necessary data capture to an existing server audit specification, run the script:
USE [master];
GO
ALTER SERVER AUDIT SPECIFICATION &lt;server_audit_specification_name&gt; WITH (STATE = OFF);
GO
ALTER SERVER AUDIT SPECIFICATION &lt;server_audit_specification_name&gt; ADD (SCHEMA_OBJECT_ACCESS_GROUP);
GO
ALTER SERVER AUDIT SPECIFICATION &lt;server_audit_specification_name&gt; WITH (STATE = ON);
GO</fixtext><fix id="F-73555r1_fix" /><check system="C-68021r3_chk"><check-content-ref name="M" href="DPMS_XCCDF_Benchmark_MS_SQL_Server_2014_Database_STIG.xml" /><check-content>Review the system documentation to determine whether it is required to track categories of information, such as classification or sensitivity level. If it is not, this is not applicable (NA).
 
If neither SQL Server Audit nor SQL Server Trace is in use for audit purposes, this is a finding.
 
If SQL Server Trace is in use for audit purposes, review the triggers on all tables holding categorized information, to determine whether trace events are generated for all UPDATE actions on these tables. If not, this is a finding.
 
Check to see that all required event classes are being audited. From the query prompt:
SELECT * FROM sys.traces;
 
All currently defined traces for the SQL server instance will be listed. If no traces are returned, this is a finding.
 
Determine the trace(s) being used for the auditing requirement.
In the following, replace # with a trace ID being used for the auditing requirements.
From the query prompt:
SELECT DISTINCT(eventid) FROM sys.fn_trace_geteventinfo(#);
 
The following required event IDs should be among those listed; if not, this is a finding:
 
82-91 -- User-defined Event (at least one of these, matching the triggers; 90 is used in the supplied script)
162 -- User error message
 
 
If SQL Server Audit is in use, proceed as follows.
 
The basic SQL Server Audit configuration provided in the supplemental file Audit.sql uses the broad, server-level audit action group SCHEMA_OBJECT_ACCESS_GROUP for this purpose. SQL Server Audit's flexibility makes other techniques possible. If an alternative technique is in use and demonstrated effective, this is not a finding.
 
Determine the name(s) of the server audit specification(s) in use.
 
To look at audits and audit specifications, in Management Studio's object explorer, expand
&lt;server name&gt; &gt;&gt; Security &gt;&gt; Audits
and
&lt;server name&gt; &gt;&gt; Security &gt;&gt; Server Audit Specifications.
Also,
&lt;server name&gt; &gt;&gt; Databases &gt;&gt; &lt;database name&gt; &gt;&gt; Security &gt;&gt; Database Audit Specifications.
 
Alternatively, review the contents of the system views with "audit" in their names.
 
Run the following to verify that all SELECT, INSERT, UPDATE, and DELETE actions on tables and views are being audited:
USE [master];
GO
SELECT * FROM sys.server_audit_specification_details WHERE server_specification_id =
(SELECT server_specification_id FROM sys.server_audit_specifications WHERE [name] = '&lt;server_audit_specification_name&gt;')
AND audit_action_name = 'SCHEMA_OBJECT_ACCESS_GROUP';
 
If no row is returned, this is a finding.
 
If the audited_result column is not "SUCCESS" or "SUCCESS AND FAILURE", this is a finding.</check-content></check></Rule></Group><Group id="V-67443"><title>SRG-APP-000498-DB-000347</title><description>&lt;GroupDescription&gt;&lt;/GroupDescription&gt;</description><Rule id="SV-81933r2_rule" severity="medium" weight="10.0"><version>SQL4-00-036850</version><title>Trace or Audit records must be generated when unsuccessful attempts to modify categorized information (e.g., classification levels/security levels) occur.</title><description>&lt;VulnDiscussion&gt;Changes in categorized information must be tracked. Without an audit trail, unauthorized access to protected data could go undetected.
 
For detailed information on categorizing information, refer to FIPS Publication 199, Standards for Security Categorization of Federal Information and Information Systems, and FIPS Publication 200, Minimum Security Requirements for Federal Information and Information Systems.
 
Use of SQL Server Audit is recommended. All features of SQL Server Audit are available in the Enterprise and Developer editions of SQL Server 2014. It is not available at the database level in other editions. For this or legacy reasons, the instance may be using SQL Server Trace for auditing, which remains an acceptable solution for the time being. Note, however, that Microsoft intends to remove most aspects of Trace at some point after SQL Server 2016.
 
Since Trace does not provide for tracking SELECT statements, it is necessary to provide that part of the tracking at the application level. Because of this, it may also be appropriate to audit UPDATE actions at the application level. However, to capture all UPDATEs, whether they come from the application or bypass it, the Trace must be configured to cover them.
 
Use of SQL Server Audit's SCHEMA_OBJECT_ACCESS_GROUP causes capture of all accesses, successful and otherwise, to all schema-scoped objects. The [Succeeded] column in the audit output indicates the success or failure of the attempted action. Be aware, however, that it may report True in some cases where one would intuitively expect False. For example, SELECT 1/0 FROM SYS.ALL_OBJECTS will appear in the audit trail as successful, if the user has permission to perform that action, even though it contains an invalid expression. Some other actions that one would consider failures (such as selecting from a table that does not exist) may not appear at all.&lt;/VulnDiscussion&gt;&lt;FalsePositives&gt;&lt;/FalsePositives&gt;&lt;FalseNegatives&gt;&lt;/FalseNegatives&gt;&lt;Documentable&gt;false&lt;/Documentable&gt;&lt;Mitigations&gt;&lt;/Mitigations&gt;&lt;SeverityOverrideGuidance&gt;&lt;/SeverityOverrideGuidance&gt;&lt;PotentialImpacts&gt;&lt;/PotentialImpacts&gt;&lt;ThirdPartyTools&gt;&lt;/ThirdPartyTools&gt;&lt;MitigationControl&gt;&lt;/MitigationControl&gt;&lt;Responsibility&gt;&lt;/Responsibility&gt;&lt;IAControls&gt;&lt;/IAControls&gt;</description><reference><dc:title>DPMS Target SQL Server Database 2014</dc:title><dc:publisher>DISA</dc:publisher><dc:type>DPMS Target</dc:type><dc:subject>SQL Server Database 2014</dc:subject><dc:identifier>2637</dc:identifier></reference><ident system="http://iase.disa.mil/cci">CCI-000172</ident><fixtext fixref="F-73557r1_fix">Where SQL Server Trace is in use, create triggers to raise a custom event for UPDATEs on each table holding categorized information. The examples provided in the supplemental file CustomTraceEvents.sql can serve as the basis for these.
 
Add a block of code to the supplemental file Trace.sql for each custom event class (integers in the range 82-91; the same event class may be used for all such triggers) used in these triggers. Execute Trace.sql.
 
If SQL Server Audit is in use, design and deploy an Audit that captures all auditable events and data items. The script provided in the supplemental file Audit.sql can be used as the basis for this. Supplement the standard audit data as necessary, using Extended Events and/or triggers.
 
Alternatively, to add the necessary data capture to an existing server audit specification, run the script:
USE [master];
GO
ALTER SERVER AUDIT SPECIFICATION &lt;server_audit_specification_name&gt; WITH (STATE = OFF);
GO
ALTER SERVER AUDIT SPECIFICATION &lt;server_audit_specification_name&gt; ADD (SCHEMA_OBJECT_ACCESS_GROUP);
GO
ALTER SERVER AUDIT SPECIFICATION &lt;server_audit_specification_name&gt; WITH (STATE = ON);
GO</fixtext><fix id="F-73557r1_fix" /><check system="C-68023r2_chk"><check-content-ref name="M" href="DPMS_XCCDF_Benchmark_MS_SQL_Server_2014_Database_STIG.xml" /><check-content>Review the system documentation to determine whether it is required to track categories of information, such as classification or sensitivity level. If it is not, this is not applicable (NA).
 
If neither SQL Server Audit nor SQL Server Trace is in use for audit purposes, this is a finding.
 
If SQL Server Trace is in use for audit purposes, review the Trace settings, and the triggers on the tables holding categorized information, to determine whether all UPDATE actions on these tables are traced, including failed attempts. If not, this is a finding.
 
Check to see that all required event classes are being audited. From the query prompt:
SELECT * FROM sys.traces;
 
All currently defined traces for the SQL server instance will be listed. If no traces are returned, this is a finding.
 
Determine the trace(s) being used for the auditing requirement.
In the following, replace # with a trace ID being used for the auditing requirements.
From the query prompt:
SELECT DISTINCT(eventid) FROM sys.fn_trace_geteventinfo(#);
 
The following required event IDs should be among those listed; if not, this is a finding:
 
82-91 -- User-defined Event (at least one of these, matching the triggers; 90 is used in the supplied script)
162 -- User error message
 
 
If SQL Server Audit is in use, proceed as follows.
 
The basic SQL Server Audit configuration provided in the supplemental file Audit.sql uses the broad, server-level audit action group SCHEMA_OBJECT_ACCESS_GROUP for this purpose. SQL Server Audit's flexibility makes other techniques possible. If an alternative technique is in use and demonstrated effective, this is not a finding.
 
Determine the name(s) of the server audit specification(s) in use.
To look at audits and audit specifications, in Management Studio's object explorer, expand
&lt;server name&gt; &gt;&gt; Security &gt;&gt; Audits
and
&lt;server name&gt; &gt;&gt; Security &gt;&gt; Server Audit Specifications.
Also,
&lt;server name&gt; &gt;&gt; Databases &gt;&gt; &lt;database name&gt; &gt;&gt; Security &gt;&gt; Database Audit Specifications.
Alternatively, review the contents of the system views with "audit" in their names.
 
Run the following to verify that all SELECT, INSERT, UPDATE, and DELETE actions on tables and views are being audited:
USE [master];
GO
SELECT * FROM sys.server_audit_specification_details WHERE server_specification_id =
(SELECT server_specification_id FROM sys.server_audit_specifications WHERE [name] = '&lt;server_audit_specification_name&gt;')
AND audit_action_name = 'SCHEMA_OBJECT_ACCESS_GROUP';
 
If no row is returned, this is a finding.
 
If the audited_result column is not "SUCCESS" or "SUCCESS AND FAILURE", this is a finding.</check-content></check></Rule></Group><Group id="V-67877"><title>SRG-APP-000231-DB-000154</title><description>&lt;GroupDescription&gt;&lt;/GroupDescription&gt;</description><Rule id="SV-82367r3_rule" severity="medium" weight="10.0"><version>SQL4-00-021300</version><title>SQL Server must protect data at rest and ensure confidentiality and integrity of data.</title><description>&lt;VulnDiscussion&gt;This control is intended to address the confidentiality and integrity of information at rest in non-mobile devices and covers user information and system information. Information at rest refers to the state of information when it is located on a secondary storage device (e.g., disk drive, tape drive) within an organizational information system. Applications and application users generate information throughout the course of their application use.
 
User-generated data, as well as, application-specific configuration data, needs to be protected. Configurations and/or rule sets for firewalls, gateways, intrusion detection/prevention systems, filtering routers, and authenticator content are examples of system information likely requiring protection. Organizations may choose to employ different mechanisms to achieve confidentiality and integrity protections, as appropriate.
 
If the confidentiality and integrity of SQL Server data is not protected, the data will be open to compromise and unauthorized modification.
 
Protective measures include encryption, physical security of the facility where the storage devices reside, operating system file permissions, and organizational controls. Each of these should be applied as necessary and appropriate.&lt;/VulnDiscussion&gt;&lt;FalsePositives&gt;&lt;/FalsePositives&gt;&lt;FalseNegatives&gt;&lt;/FalseNegatives&gt;&lt;Documentable&gt;false&lt;/Documentable&gt;&lt;Mitigations&gt;&lt;/Mitigations&gt;&lt;SeverityOverrideGuidance&gt;&lt;/SeverityOverrideGuidance&gt;&lt;PotentialImpacts&gt;&lt;/PotentialImpacts&gt;&lt;ThirdPartyTools&gt;&lt;/ThirdPartyTools&gt;&lt;MitigationControl&gt;&lt;/MitigationControl&gt;&lt;Responsibility&gt;&lt;/Responsibility&gt;&lt;IAControls&gt;&lt;/IAControls&gt;</description><reference><dc:title>DPMS Target SQL Server Database 2014</dc:title><dc:publisher>DISA</dc:publisher><dc:type>DPMS Target</dc:type><dc:subject>SQL Server Database 2014</dc:subject><dc:identifier>2637</dc:identifier></reference><ident system="http://iase.disa.mil/cci">CCI-001199</ident><fixtext fixref="F-73993r1_fix">Apply appropriate controls to protect the confidentiality and integrity of data on a secondary device.
 
Where encryption is required, this can be done by full-disk encryption or by database encryption. To enable database encryption, create a master key, create a database encryption key, and protect it by using mechanisms tied to the master key, and then set encryption on.
 
Implement physical security measures, operating system access control lists and organizational controls appropriate to the sensitivity level of the data in the database(s).</fixtext><fix id="F-73993r1_fix" /><check system="C-68445r3_chk"><check-content-ref name="M" href="DPMS_XCCDF_Benchmark_MS_SQL_Server_2014_Database_STIG.xml" /><check-content>If the application owner and Authorizing Official have determined that encryption of data at rest is NOT required, this is not a finding.
 
If the application owner and Authorizing Official have determined that encryption of data at rest is required, ensure the data on secondary devices is encrypted.
 
If full-disk encryption is being used, this is not a finding.
 
If DBMS data encryption is required, ensure the data is encrypted before being put on the secondary device by executing:
 
SELECT
      d.name AS [Database Name],
      CASE e.encryption_state
            WHEN 0 THEN 'No database encryption key present, no encryption'
            WHEN 1 THEN 'Unencrypted'
            WHEN 2 THEN 'Encryption in progress'
            WHEN 3 THEN 'Encrypted'
            WHEN 4 THEN 'Key change in progress'
            WHEN 5 THEN 'Decryption in progress'
            WHEN 6 THEN 'Protection change in progress'
      END AS [Encryption State]
FROM sys.dm_database_encryption_keys e
RIGHT JOIN sys.databases d ON DB_NAME(e.database_id) = d.name
WHERE d.name NOT IN ('master','model','msdb')
ORDER BY 1
;
 
For each user database where encryption is required, verify that encryption is in effect. If not, this is a finding.
 
Verify that there are physical security measures, operating system access control lists and organizational controls appropriate to the sensitivity level of the data in the database(s). If not, this is a finding.</check-content></check></Rule></Group></Benchmark>