forked from OVALProject/Sandbox
-
Notifications
You must be signed in to change notification settings - Fork 0
/
windows-definitions-schema.xsd
9288 lines (9284 loc) · 861 KB
/
windows-definitions-schema.xsd
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
<?xml version="1.0" encoding="utf-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:oval="http://oval.mitre.org/XMLSchema/oval-common-5" xmlns:oval-def="http://oval.mitre.org/XMLSchema/oval-definitions-5" xmlns:win-def="http://oval.mitre.org/XMLSchema/oval-definitions-5#windows" xmlns:sch="http://purl.oclc.org/dsdl/schematron" targetNamespace="http://oval.mitre.org/XMLSchema/oval-definitions-5#windows" elementFormDefault="qualified" version="5.10.1">
<xsd:import namespace="http://oval.mitre.org/XMLSchema/oval-common-5" schemaLocation="oval-common-schema.xsd"/>
<xsd:import namespace="http://oval.mitre.org/XMLSchema/oval-definitions-5" schemaLocation="oval-definitions-schema.xsd"/>
<xsd:annotation>
<xsd:documentation>The following is a description of the elements, types, and attributes that compose the Windows specific tests found in Open Vulnerability and Assessment Language (OVAL). Each test is an extension of the standard test element defined in the Core Definition Schema. Through extension, each test inherits a set of elements and attributes that are shared amongst all OVAL tests. Each test is described in detail and should provide the information necessary to understand what each element and attribute represents. This document is intended for developers and assumes some familiarity with XML. A high level description of the interaction between the different tests and their relationship to the Core Definition Schema is not outlined here.</xsd:documentation>
<xsd:documentation>The OVAL Schema is maintained by The MITRE Corporation and developed by the public OVAL Community. For more information, including how to get involved in the project and how to submit change requests, please visit the OVAL website at http://oval.mitre.org.</xsd:documentation>
<xsd:appinfo>
<schema>Windows Definition</schema>
<version>5.10.1</version>
<date>1/27/2012 1:22:32 PM</date>
<terms_of_use>Copyright (c) 2002-2012, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the OVAL License located at http://oval.mitre.org/oval/about/termsofuse.html. See the OVAL License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the OVAL Schema, this license header must be included.</terms_of_use>
<sch:ns prefix="oval-def" uri="http://oval.mitre.org/XMLSchema/oval-definitions-5"/>
<sch:ns prefix="win-def" uri="http://oval.mitre.org/XMLSchema/oval-definitions-5#windows"/>
<sch:ns prefix="xsi" uri="http://www.w3.org/2001/XMLSchema-instance"/>
</xsd:appinfo>
</xsd:annotation>
<!-- =============================================================================== -->
<!-- ============================ ACCESS TOKEN TEST ============================= -->
<!-- =============================================================================== -->
<xsd:element name="accesstoken_test" substitutionGroup="oval-def:test">
<xsd:annotation>
<xsd:documentation>The accesstoken_test is used to check the properties of a Windows access token as well as individual privileges and rights associated with it. It extends the standard TestType as defined in the oval-definitions-schema and one should refer to the TestType description for more information. The required object element references an accesstoken_object and the optional state element specifies the data to check.</xsd:documentation>
<xsd:appinfo>
<oval:element_mapping>
<oval:test>accesstoken_test</oval:test>
<oval:object>accesstoken_object</oval:object>
<oval:state>accesstoken_state</oval:state>
<oval:item target_namespace="http://oval.mitre.org/XMLSchema/oval-system-characteristics-5#windows">accesstoken_item</oval:item>
</oval:element_mapping>
</xsd:appinfo>
<xsd:appinfo>
<sch:pattern id="win-def_attst">
<sch:rule context="win-def:accesstoken_test/win-def:object">
<sch:assert test="@object_ref=ancestor::oval-def:oval_definitions/oval-def:objects/win-def:accesstoken_object/@id"><sch:value-of select="../@id"/> - the object child element of an accesstoken_test must reference an accesstoken_object</sch:assert>
</sch:rule>
<sch:rule context="win-def:accesstoken_test/win-def:state">
<sch:assert test="@state_ref=ancestor::oval-def:oval_definitions/oval-def:states/win-def:accesstoken_state/@id"><sch:value-of select="../@id"/> - the state child element of an accesstoken_test must reference an accesstoken_state</sch:assert>
</sch:rule>
</sch:pattern>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="oval-def:TestType">
<xsd:sequence>
<xsd:element name="object" type="oval-def:ObjectRefType"/>
<xsd:element name="state" type="oval-def:StateRefType" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<xsd:element name="accesstoken_object" substitutionGroup="oval-def:object">
<xsd:annotation>
<xsd:documentation>The accesstoken_object element is used by an access token test to define the object to be evaluated. Each object extends the standard ObjectType as defined in the oval-definitions-schema and one should refer to the ObjectType description for more information. The common set element allows complex objects to be created using filters and set logic. Again, please refer to the description of the set element in the oval-definitions-schema.</xsd:documentation>
<xsd:documentation>An accesstoken_object consists of a single security principle that identifies user, group, or computer account that is associated with the token.</xsd:documentation>
<xsd:appinfo>
<sch:pattern id="win-def_accesstoken_object_verify_filter_state">
<sch:rule context="win-def:accesstoken_object//oval-def:filter">
<sch:let name="parent_object" value="ancestor::win-def:accesstoken_object"/>
<sch:let name="parent_object_id" value="$parent_object/@id"/>
<sch:let name="state_ref" value="."/>
<sch:let name="reffed_state" value="ancestor::oval-def:oval_definitions/oval-def:states/*[@id=$state_ref]"/>
<sch:let name="state_name" value="local-name($reffed_state)"/>
<sch:let name="state_namespace" value="namespace-uri($reffed_state)"/>
<sch:assert test="(($state_namespace='http://oval.mitre.org/XMLSchema/oval-definitions-5#windows') and ($state_name='accesstoken_state'))">State referenced in filter for <sch:value-of select="name($parent_object)"/> '<sch:value-of select="$parent_object_id"/>' is of the wrong type. </sch:assert>
</sch:rule>
</sch:pattern>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="oval-def:ObjectType">
<xsd:sequence>
<xsd:choice>
<xsd:element ref="oval-def:set"/>
<xsd:sequence>
<xsd:element name="behaviors" type="win-def:AccesstokenBehaviors" minOccurs="0"/>
<xsd:element name="security_principle" type="oval-def:EntityObjectStringType">
<xsd:annotation>
<xsd:documentation>The security_principle element defines the access token being specified. Security principles include users or groups with either local or domain accounts, and computer accounts created when a computer joins a domain. In Windows, security principles are case-insensitive. As a result, it is recommended that the case-insensitive operations are used for this entity. User rights and permissions to access objects such as Active Directory objects, files, and registry settings are assigned to security principles. In a domain environment, security principles should be identified in the form: "domain\trustee name". For local security principles use: "computer name\trustee name". For built-in accounts on the system, use the trustee name without a domain. If an operation other than equals is used to identify matching trustees (i.e. not equal, or a pattern match) then the resulting matches shall be limited to only the trustees referenced in the Local Security Authority database. The scope is limited here to avoid unnecessarily resource intensive searches for trustees. Note that the larger scope of all known trustees may be obtained through the use of variables.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element ref="oval-def:filter" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:choice>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<xsd:element name="accesstoken_state" substitutionGroup="oval-def:state">
<xsd:annotation>
<xsd:documentation>The accesstoken_state element defines the different information that can be used to evaluate the specified access tokens. This includes the multitude of user rights and permissions that can be granted. Please refer to the individual elements in the schema for more details about what each represents.</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="oval-def:StateType">
<xsd:sequence>
<xsd:element name="security_principle" type="oval-def:EntityStateStringType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>The security_principle element identifies an access token to test for. Security principles include users or groups with either local or domain accounts, and computer accounts created when a computer joins a domain. In Windows, security principles are case-insensitive. As a result, it is recommended that the case-insensitive operations are used for this entity. User rights and permissions to access objects such as Active Directory objects, files, and registry settings are assigned to security principles. In a domain environment, security principles should be identified in the form: "domain\trustee name". For local security principles use: "computer name\trustee name". For built-in accounts on the system, use the trustee name without a domain.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="seassignprimarytokenprivilege" type="oval-def:EntityStateBoolType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>If the seassignprimarytokenprivilege privilege is enabled, it allows a parent process to replace the access token that is associated with a child process.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="seauditprivilege" type="oval-def:EntityStateBoolType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>If the seauditprivilege privilege is enabled, it allows a process to generate audit records in the security log. The security log can be used to trace unauthorized system access.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="sebackupprivilege" type="oval-def:EntityStateBoolType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>If the sebackupprivilege privilege is enabled, it allows the user to circumvent file and directory permissions to back up the system. The privilege is selected only when an application attempts access by using the NTFS backup application programming interface (API). Otherwise, normal file and directory permissions apply.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="sechangenotifyprivilege" type="oval-def:EntityStateBoolType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>If the sechangenotifyprivilege privilege is enabled, it allows the user to pass through folders to which the user otherwise has no access while navigating an object path in the NTFS file system or in the registry. This privilege does not allow the user to list the contents of a folder; it allows the user only to traverse its directories.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="secreateglobalprivilege" type="oval-def:EntityStateBoolType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>If the secreateglobalprivilege privilege is enabled, it allows the user to create named file mapping objects in the global namespace during Terminal Services sessions.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="secreatepagefileprivilege" type="oval-def:EntityStateBoolType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>If the secreatepagefileprivilege privilege is enabled, it allows the user to create and change the size of a pagefile.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="secreatepermanentprivilege" type="oval-def:EntityStateBoolType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>If the secreatepermanentprivilege privilege is enabled, it allows a process to create a directory object in the object manager. It is useful to kernel-mode components that extend the object namespace. Components that are running in kernel mode have this privilege inherently.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="secreatesymboliclinkprivilege" type="oval-def:EntityStateBoolType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>If the secreatesymboliclinkprivilege privilege is enabled, it allows users to create symbolic links.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="secreatetokenprivilege" type="oval-def:EntityStateBoolType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>If the secreatetokenprivilege privilege is enabled, it allows a process to create an access token by calling NtCreateToken() or other token-creating APIs.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="sedebugprivilege" type="oval-def:EntityStateBoolType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>If the sedebugprivilege privilege is enabled, it allows the user to attach a debugger to any process. It provides access to sensitive and critical operating system components.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="seenabledelegationprivilege" type="oval-def:EntityStateBoolType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>If the seenabledelegationprivilege privilege is enabled, it allows the user to change the Trusted for Delegation setting on a user or computer object in Active Directory. The user or computer that is granted this privilege must also have write access to the account control flags on the object.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="seimpersonateprivilege" type="oval-def:EntityStateBoolType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>If the seimpersonateprivilege privilege is enabled, it allows the user to impersonate a client after authentication.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="seincreasebasepriorityprivilege" type="oval-def:EntityStateBoolType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>If the seincreasebasepriorityprivilege privilege is enabled, it allows a user to increase the base priority class of a process.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="seincreasequotaprivilege" type="oval-def:EntityStateBoolType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>If the seincreasequotaprivilege privilege is enabled, it allows a process that has access to a second process to increase the processor quota assigned to the second process.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="seincreaseworkingsetprivilege" type="oval-def:EntityStateBoolType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>If the seincreaseworkingsetprivilege privilege is enabled, it allows a user to increase a process working set.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="seloaddriverprivilege" type="oval-def:EntityStateBoolType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>If the seloaddriverprivilege privilege is enabled, it allows a user to install and remove drivers for Plug and Play devices.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="selockmemoryprivilege" type="oval-def:EntityStateBoolType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>If the selockmemoryprivilege privilege is enabled, it allows a process to keep data in physical memory, which prevents the system from paging the data to virtual memory on disk.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="semachineaccountprivilege" type="oval-def:EntityStateBoolType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>If the semachineaccountprivilege privilege is enabled, it allows the user to add a computer to a specific domain.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="semanagevolumeprivilege" type="oval-def:EntityStateBoolType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>If the semanagevolumeprivilege privilege is enabled, it allows a non-administrative or remote user to manage volumes or disks.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="seprofilesingleprocessprivilege" type="oval-def:EntityStateBoolType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>If the seprofilesingleprocessprivilege privilege is enabled, it allows a user to sample the performance of an application process.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="serelabelprivilege" type="oval-def:EntityStateBoolType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>If the serelabelprivilege privilege is enabled, it allows a user to modify an object label.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="seremoteshutdownprivilege" type="oval-def:EntityStateBoolType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>If the seremoteshutdownprivilege privilege is enabled, it allows a user to shut down a computer from a remote location on the network. </xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="serestoreprivilege" type="oval-def:EntityStateBoolType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>If the serestoreprivilege privilege is enabled, it allows a user to circumvent file and directory permissions when restoring backed-up files and directories and to set any valid security principle as the owner of an object.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="sesecurityprivilege" type="oval-def:EntityStateBoolType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>If the sesecurityprivilege privilege is enabled, it allows a user to specify object access auditing options for individual resources such as files, Active Directory objects, and registry keys. A user who has this privilege can also view and clear the security log from Event Viewer.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="seshutdownprivilege" type="oval-def:EntityStateBoolType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>If the seshutdownprivilege privilege is enabled, it allows a user to shut down the local computer.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="sesyncagentprivilege" type="oval-def:EntityStateBoolType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>If the sesyncagentprivilege privilege is enabled, it allows a process to read all objects and properties in the directory, regardless of the protection on the objects and properties. It is required in order to use Lightweight Directory Access Protocol (LDAP) directory synchronization (Dirsync) services.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="sesystemenvironmentprivilege" type="oval-def:EntityStateBoolType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>If the sesystemenvironmentprivilege privilege is enabled, it allows modification of system environment variables either by a process through an API or by a user through System Properties.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="sesystemprofileprivilege" type="oval-def:EntityStateBoolType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>If the sesystemprofileprivilege privilege is enabled, it allows a user to sample the performance of system processes.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="sesystemtimeprivilege" type="oval-def:EntityStateBoolType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>If the sesystemtimeprivilege privilege is enabled, it allows the user to adjust the time on the computer's internal clock. It is not required to change the time zone or other display characteristics of the system time.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="setakeownershipprivilege" type="oval-def:EntityStateBoolType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>If the setakeownershipprivilege privilege is enabled, it allows a user to take ownership of any securable object in the system, including Active Directory objects, NTFS files and folders, printers, registry keys, services, processes, and threads.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="setcbprivilege" type="oval-def:EntityStateBoolType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>If the setcbprivilege privilege is enabled, it allows a process to assume the identity of any user and thus gain access to the resources that the user is authorized to access.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="setimezoneprivilege" type="oval-def:EntityStateBoolType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>If the setimezoneprivilege privilege is enabled, it allows the user to change the time zone.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="seundockprivilege" type="oval-def:EntityStateBoolType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>If the seundockprivilege privilege is enabled, it allows the user of a portable computer to undock the computer by clicking Eject PC on the Start menu.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="seunsolicitedinputprivilege" type="oval-def:EntityStateBoolType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>If the seunsolicitedinputprivilege privilege is enabled, it allows the user to read unsolicited data from a terminal device.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="sebatchlogonright" type="oval-def:EntityStateBoolType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>If an account is assigned the sebatchlogonright right, it can log on using the batch logon type.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="seinteractivelogonright" type="oval-def:EntityStateBoolType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>If an account is assigned the seinteractivelogonright right, it can log on using the interactive logon type.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="senetworklogonright" type="oval-def:EntityStateBoolType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>If an account is assigned the senetworklogonright right, it can log on using the network logon type.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="seremoteinteractivelogonright" type="oval-def:EntityStateBoolType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>If an account is assigned the seremoteinteractivelogonright right, it can log on to the computer by using a Remote Desktop connection.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="seservicelogonright" type="oval-def:EntityStateBoolType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>If an account is assigned the seservicelogonright right, it can log on using the service logon type.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="sedenybatchLogonright" type="oval-def:EntityStateBoolType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>If an account is assigned the sedenybatchLogonright right, it is explicitly denied the ability to log on using the batch logon type.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="sedenyinteractivelogonright" type="oval-def:EntityStateBoolType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>If an account is assigned the sedenyinteractivelogonright right, it is explicitly denied the ability to log on using the interactive logon type.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="sedenynetworklogonright" type="oval-def:EntityStateBoolType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>If an account is assigned the sedenynetworklogonright right, it is explicitly denied the ability to log on using the network logon type.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="sedenyremoteInteractivelogonright" type="oval-def:EntityStateBoolType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>If an account is assigned the sedenyremoteInteractivelogonright right, it is explicitly denied the ability to log on through Terminal Services.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="sedenyservicelogonright" type="oval-def:EntityStateBoolType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>If an account is assigned the sedenyservicelogonright right, it is explicitly denied the ability to log on using the service logon type.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="setrustedcredmanaccessnameright" type="oval-def:EntityStateBoolType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>If an account is assigned this right, it can access the Credential Manager as a trusted caller.</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<xsd:complexType name="AccesstokenBehaviors">
<xsd:annotation>
<xsd:documentation>The AccesstokenBehaviors complex type defines a number of behaviors that allow a more detailed definition of the accesstoken_object being specified. Note that using these behaviors may result in some unique results. For example, a double negative type condition might be created where an object entity says include everything except a specific item, but a behavior is used that might then add that item back in.</xsd:documentation>
</xsd:annotation>
<xsd:attribute name="include_group" type="xsd:boolean" use="optional" default="true">
<xsd:annotation>
<xsd:documentation>If a group security principle is specified, this behavior specifies whether to include the group or not. For example, maybe you want to check the access tokens associated with every user within a group, but not the group itself. In this case, you would set the include_group behavior to 'false'. If the security_principle is not a group, then this behavior should be ignored.</xsd:documentation>
<xsd:appinfo>
<oval:deprecated_info>
<oval:version>5.10</oval:version>
<oval:reason>The 'include_group' behavior has been deprecated in favor of using variables to reference more efficient objects for expanding groups.</oval:reason>
<oval:comment>Consider using a sid_object or similar to include the members of a group.</oval:comment>
</oval:deprecated_info>
<sch:pattern id="win-def_at_include_group_value_dep">
<sch:rule context="oval-def:oval_definitions/oval-def:objects/win-def:accesstoken_object/win-def:behaviors">
<sch:report test="@include_group">DEPRECATED BEHAVIOR IN: win-def:accesstoken_object</sch:report>
</sch:rule>
</sch:pattern>
</xsd:appinfo>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="resolve_group" type="xsd:boolean" use="optional" default="false">
<xsd:annotation>
<xsd:documentation>The 'resolve_group' behavior defines whether an object set defined by a group SID should be resolved to return a set that contains all the user SIDs that are a member of that group. Note that all child groups should also be resolved and any valid domain users that are members of the group should also be included. The intent of this behavior is to end up with a list of all individual users from that system that make up the group once everything has been resolved.</xsd:documentation>
<xsd:appinfo>
<oval:deprecated_info>
<oval:version>5.6</oval:version>
<oval:reason>The 'resolve_group' behavior has been deprecated in favor of using variables to reference more efficient objects for expanding groups.</oval:reason>
<oval:comment>Consider using a sid_object or similar to resolve the members of a group.</oval:comment>
</oval:deprecated_info>
<sch:pattern id="win-def_at_resolve_group_value_dep">
<sch:rule context="oval-def:oval_definitions/oval-def:objects/win-def:accesstoken_object/win-def:behaviors">
<sch:report test="@resolve_group">DEPRECATED BEHAVIOR IN: win-def:accesstoken_object </sch:report>
</sch:rule>
</sch:pattern>
</xsd:appinfo>
</xsd:annotation>
</xsd:attribute>
</xsd:complexType>
<!-- =============================================================================== -->
<!-- =========================== ACTIVE DIRECTORY TEST =========================== -->
<!-- =============================================================================== -->
<xsd:element name="activedirectory_test" substitutionGroup="oval-def:test">
<xsd:annotation>
<xsd:documentation>The active directory test is used to check information about specific entries in active directory. It extends the standard TestType as defined in the oval-definitions-schema and one should refer to the TestType description for more information. The required object element references an activedirectory_object and the optional state element specifies the metadata to check.</xsd:documentation>
<xsd:documentation>Note that this test supports only simple (string based) value collection. For more complex values see the activedirectory57_test.</xsd:documentation>
<xsd:appinfo>
<oval:element_mapping>
<oval:test>activedirectory_test</oval:test>
<oval:object>activedirectory_object</oval:object>
<oval:state>activedirectory_state</oval:state>
<oval:item target_namespace="http://oval.mitre.org/XMLSchema/oval-system-characteristics-5#windows">activedirectory_item</oval:item>
</oval:element_mapping>
</xsd:appinfo>
<xsd:appinfo>
<sch:pattern id="win-def_adtst">
<sch:rule context="win-def:activedirectory_test/win-def:object">
<sch:assert test="@object_ref=ancestor::oval-def:oval_definitions/oval-def:objects/win-def:activedirectory_object/@id"><sch:value-of select="../@id"/> - the object child element of an activedirectory_test must reference an activedirectory_object</sch:assert>
</sch:rule>
<sch:rule context="win-def:activedirectory_test/win-def:state">
<sch:assert test="@state_ref=ancestor::oval-def:oval_definitions/oval-def:states/win-def:activedirectory_state/@id"><sch:value-of select="../@id"/> - the state child element of an activedirectory_test must reference an activedirectory_state</sch:assert>
</sch:rule>
</sch:pattern>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="oval-def:TestType">
<xsd:sequence>
<xsd:element name="object" type="oval-def:ObjectRefType"/>
<xsd:element name="state" type="oval-def:StateRefType" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<xsd:element name="activedirectory_object" substitutionGroup="oval-def:object">
<xsd:annotation>
<xsd:documentation>The activedirectory_object element is used by an active directory test to define those objects to evaluated based on a specified state. Each object extends the standard ObjectType as defined in the oval-definitions-schema and one should refer to the ObjectType description for more information. The common set element allows complex objects to be created using filters and set logic. Again, please refer to the description of the set element in the oval-definitions-schema.</xsd:documentation>
<xsd:documentation>An active directory object consists of three pieces of information, a naming context, a relative distinguished name, and an attribute. Each piece helps identify a specific active directory entry.</xsd:documentation>
<xsd:documentation>Note that this object is paired with a state that supports only simple (string based) value collection. For more complex values see the activedirectory57_object.</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="oval-def:ObjectType">
<xsd:sequence>
<xsd:choice>
<xsd:element ref="oval-def:set"/>
<xsd:sequence>
<xsd:element name="naming_context" type="win-def:EntityObjectNamingContextType">
<xsd:annotation>
<xsd:documentation>Each object in active directory exists under a certain naming context (also known as a partition). A naming context is defined as a single object in the Directory Information Tree (DIT) along with every object in the tree subordinate to it. There are three default naming contexts in Active Directory: domain, configuration, and schema.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="relative_dn" type="oval-def:EntityObjectStringType" nillable="true">
<xsd:annotation>
<xsd:documentation>The relative_dn field is used to uniquely identify an object inside the specified naming context. It contains all the parts of the object's distinguished name except those outlined by the naming context. If the xsi:nil attribute is set to true, then the object being specified is the higher level naming context. In this case, the relative_dn element should not be collected or used in analysis. Setting xsi:nil equal to true is different than using a .* pattern match, which says to collect every relative dn under a given naming context.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="attribute" type="oval-def:EntityObjectStringType" nillable="true">
<xsd:annotation>
<xsd:documentation>Specifies a named value contained by the object. If the xsi:nil attribute is set to true, the attribute element should not be collected or used in analysis. Setting xsi:nil equal to true is different than using a .* pattern match, which says to collect every attribute under a given relative dn.</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:choice>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<xsd:element name="activedirectory_state" substitutionGroup="oval-def:state">
<xsd:annotation>
<xsd:documentation>The activedirectory_state element defines the different information that can be used to evaluate the specified entries in active directory. An active directory test will reference a specific instance of this state that defines the exact settings that need to be evaluated. Please refer to the individual elements in the schema for more details about what each represents.</xsd:documentation>
<xsd:documentation>Note that this state supports only simple (string based) value collection. For more complex values see the activedirectory57_state.</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="oval-def:StateType">
<xsd:sequence>
<xsd:element name="naming_context" type="win-def:EntityStateNamingContextType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Each object in active directory exists under a certain naming context (also known as a partition). A naming context is defined as a single object in the Directory Information Tree (DIT) along with every object in the tree subordinate to it. There are three default naming contexts in Active Directory: domain, configuration, and schema.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="relative_dn" type="oval-def:EntityStateStringType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>The relative_dn field is used to uniquely identify an object inside the specified naming context. It contains all the parts of the objects distinguished name except those outlined by the naming context.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="attribute" type="oval-def:EntityStateStringType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Specifies a named value contained by the object.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="object_class" type="oval-def:EntityStateStringType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>The name of the class of which the object is an instance.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="adstype" type="win-def:EntityStateAdstypeType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Specifies the type of information that the specified attribute represents.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="value" type="oval-def:EntityStateAnySimpleType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>The actual value of the specified active directory attribute.</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<!-- =============================================================================== -->
<!-- =========================== ACTIVE DIRECTORY TEST (57) ====================== -->
<!-- =============================================================================== -->
<xsd:element name="activedirectory57_test" substitutionGroup="oval-def:test">
<xsd:annotation>
<xsd:documentation>The active directory test is used to check information about specific entries in active directory. It extends the standard TestType as defined in the oval-definitions-schema and one should refer to the TestType description for more information. The required object element references an activedirectory57_object and the optional state element specifies the metadata to check.</xsd:documentation>
<xsd:documentation>Note that this test supports complex values that are in the form of a record. For simple (string based) value collection see the activedirectory_test.</xsd:documentation>
<xsd:appinfo>
<oval:element_mapping>
<oval:test>activedirectory57_test</oval:test>
<oval:object>activedirectory57_object</oval:object>
<oval:state>activedirectory57_state</oval:state>
<oval:item target_namespace="http://oval.mitre.org/XMLSchema/oval-system-characteristics-5#windows">activedirectory57_item</oval:item>
</oval:element_mapping>
</xsd:appinfo>
<xsd:appinfo>
<sch:pattern id="win-def_activedirectory57_test">
<sch:rule context="win-def:activedirectory57_test/win-def:object">
<sch:assert test="@object_ref=ancestor::oval-def:oval_definitions/oval-def:objects/win-def:activedirectory57_object/@id"><sch:value-of select="../@id"/> - the object child element of an activedirectory57_test must reference an activedirectory57_object</sch:assert>
</sch:rule>
<sch:rule context="win-def:activedirectory57_test/win-def:state">
<sch:assert test="@state_ref=ancestor::oval-def:oval_definitions/oval-def:states/win-def:activedirectory57_state/@id"><sch:value-of select="../@id"/> - the state child element of an activedirectory57_test must reference an activedirectory57_state</sch:assert>
</sch:rule>
</sch:pattern>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="oval-def:TestType">
<xsd:sequence>
<xsd:element name="object" type="oval-def:ObjectRefType"/>
<xsd:element name="state" type="oval-def:StateRefType" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<xsd:element name="activedirectory57_object" substitutionGroup="oval-def:object">
<xsd:annotation>
<xsd:documentation>The activedirectory57_object element is used by an active directory test to define those objects to evaluated based on a specified state. Each object extends the standard ObjectType as defined in the oval-definitions-schema and one should refer to the ObjectType description for more information. The common set element allows complex objects to be created using filters and set logic. Again, please refer to the description of the set element in the oval-definitions-schema.</xsd:documentation>
<xsd:documentation>An active directory object consists of three pieces of information, a naming context, a relative distinguished name, and an attribute. Each piece helps identify a specific active directory entry.</xsd:documentation>
<xsd:documentation>Note that this object supports complex values that are in the form of a record. For simple (string based) value collection see the activedirectory_object.</xsd:documentation>
<xsd:appinfo>
<sch:pattern id="win-def_activedirectory57_object_verify_filter_state">
<sch:rule context="win-def:activedirectory57_object//oval-def:filter">
<sch:let name="parent_object" value="ancestor::win-def:activedirectory57_object"/>
<sch:let name="parent_object_id" value="$parent_object/@id"/>
<sch:let name="state_ref" value="."/>
<sch:let name="reffed_state" value="ancestor::oval-def:oval_definitions/oval-def:states/*[@id=$state_ref]"/>
<sch:let name="state_name" value="local-name($reffed_state)"/>
<sch:let name="state_namespace" value="namespace-uri($reffed_state)"/>
<sch:assert test="(($state_namespace='http://oval.mitre.org/XMLSchema/oval-definitions-5#windows') and ($state_name='activedirectory57_state'))">State referenced in filter for <sch:value-of select="name($parent_object)"/> '<sch:value-of select="$parent_object_id"/>' is of the wrong type. </sch:assert>
</sch:rule>
</sch:pattern>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="oval-def:ObjectType">
<xsd:sequence>
<xsd:choice>
<xsd:element ref="oval-def:set"/>
<xsd:sequence>
<xsd:element name="naming_context" type="win-def:EntityObjectNamingContextType">
<xsd:annotation>
<xsd:documentation>Each object in active directory exists under a certain naming context (also known as a partition). A naming context is defined as a single object in the Directory Information Tree (DIT) along with every object in the tree subordinate to it. There are three default naming contexts in Active Directory: domain, configuration, and schema.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="relative_dn" type="oval-def:EntityObjectStringType" nillable="true">
<xsd:annotation>
<xsd:documentation>The relative_dn field is used to uniquely identify an object inside the specified naming context. It contains all the parts of the object's distinguished name except those outlined by the naming context. If the xsi:nil attribute is set to true, then the object being specified is the higher level naming context. In this case, the relative_dn element should not be collected or used in analysis. Setting xsi:nil equal to true is different than using a .* pattern match, which says to collect every relative dn under a given naming context.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="attribute" type="oval-def:EntityObjectStringType" nillable="true">
<xsd:annotation>
<xsd:documentation>Specifies a named value contained by the object. If the xsi:nil attribute is set to true, the attribute element should not be collected or used in analysis. Setting xsi:nil equal to true is different than using a .* pattern match, which says to collect every attribute under a given relative dn.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element ref="oval-def:filter" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:choice>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<xsd:element name="activedirectory57_state" substitutionGroup="oval-def:state">
<xsd:annotation>
<xsd:documentation>The activedirectory57_state element defines the different information that can be used to evaluate the specified entries in active directory. An active directory test will reference a specific instance of this state that defines the exact settings that need to be evaluated. Please refer to the individual elements in the schema for more details about what each represents.</xsd:documentation>
<xsd:documentation>Note that this state supports complex values that are in the form of a record. For simple (string based) value collection see the activedirectory_state.</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="oval-def:StateType">
<xsd:sequence>
<xsd:element name="naming_context" type="win-def:EntityStateNamingContextType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Each object in active directory exists under a certain naming context (also known as a partition). A naming context is defined as a single object in the Directory Information Tree (DIT) along with every object in the tree subordinate to it. There are three default naming contexts in Active Directory: domain, configuration, and schema.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="relative_dn" type="oval-def:EntityStateStringType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>The relative_dn field is used to uniquely identify an object inside the specified naming context. It contains all the parts of the object's distinguished name except those outlined by the naming context.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="attribute" type="oval-def:EntityStateStringType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Specifies a named value contained by the object.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="object_class" type="oval-def:EntityStateStringType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>The name of the class of which the object is an instance.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="adstype" type="win-def:EntityStateAdstypeType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>The type of information that the specified attribute represents.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="value" type="oval-def:EntityStateRecordType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>The actual value of the specified Active Directory attribute. Note that while an Active Directory attribute can contain structured data where it is necessary to collect multiple related fields that can be described by the 'record' datatype, it is not always the case. It also is possible that an Active Directory attribute can contain only a single value or an array of values. In these cases, there is not a name to uniquely identify the corresponding field which is a requirement for fields in the 'record' datatype. As a result, the name of the Active Directory attribute will be used to uniquely identify the field and satisfy this requirement.</xsd:documentation>
<xsd:appinfo>
<sch:pattern id="win-def_ad57stevalue">
<sch:rule context="win-def:activedirectory57_state/win-def:value">
<sch:assert test="@datatype='record'"><sch:value-of select="../@id"/> - datatype attribute for the value entity of a activedirectory57_state must be 'record'</sch:assert>
</sch:rule>
</sch:pattern>
</xsd:appinfo>
</xsd:annotation>
<xsd:unique name="UniqueAdValueFieldName">
<xsd:selector xpath="./oval-def:field"/>
<xsd:field xpath="@name"/>
</xsd:unique>
</xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<!-- =============================================================================== -->
<!-- ========================== AUDIT EVENT POLICY TEST ========================== -->
<!-- =============================================================================== -->
<xsd:element name="auditeventpolicy_test" substitutionGroup="oval-def:test">
<xsd:annotation>
<xsd:documentation>The auditeventpolicy_test is used to check different types of events the system should audit. It extends the standard TestType as defined in the oval-definitions-schema and one should refer to the TestType description for more information. The required object element references a auditeventpolicy_object and the optional state element specifies the metadata to check.</xsd:documentation>
<xsd:appinfo>
<oval:element_mapping>
<oval:test>auditeventpolicy_test</oval:test>
<oval:object>auditeventpolicy_object</oval:object>
<oval:state>auditeventpolicy_state</oval:state>
<oval:item target_namespace="http://oval.mitre.org/XMLSchema/oval-system-characteristics-5#windows">auditeventpolicy_item</oval:item>
</oval:element_mapping>
</xsd:appinfo>
<xsd:appinfo>
<sch:pattern id="win-def_aeptst">
<sch:rule context="win-def:auditeventpolicy_test/win-def:object">
<sch:assert test="@object_ref=ancestor::oval-def:oval_definitions/oval-def:objects/win-def:auditeventpolicy_object/@id"><sch:value-of select="../@id"/> - the object child element of an auditeventpolicy_test must reference an auditeventpolicy_object</sch:assert>
</sch:rule>
<sch:rule context="win-def:auditeventpolicy_test/win-def:state">
<sch:assert test="@state_ref=ancestor::oval-def:oval_definitions/oval-def:states/win-def:auditeventpolicy_state/@id"><sch:value-of select="../@id"/> - the state child element of an auditeventpolicy_test must reference an auditeventpolicy_state</sch:assert>
</sch:rule>
</sch:pattern>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="oval-def:TestType">
<xsd:sequence>
<xsd:element name="object" type="oval-def:ObjectRefType"/>
<xsd:element name="state" type="oval-def:StateRefType" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<xsd:element name="auditeventpolicy_object" substitutionGroup="oval-def:object">
<xsd:annotation>
<xsd:documentation>The auditeventpolicy_object element is used by an audit event policy test to define those objects to evaluate based on a specified state. There is actually only one object relating to audit event policy and this is the system as a whole. Therefore, there are no child entities defined. Any OVAL Test written to check audit event policy will reference the same auditeventpolicy_object which is basically an empty object element.</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="oval-def:ObjectType"/>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<xsd:element name="auditeventpolicy_state" substitutionGroup="oval-def:state">
<xsd:annotation>
<xsd:documentation>The auditeventpolicy_state element specifies the different system activities that can be audited. An audit event policy test will reference a specific instance of this state that defines the exact settings that need to be evaluated. The defined values are found in window's POLICY_AUDIT_EVENT_TYPE enumeration and accessed through the LsaQueryInformationPolicy when the InformationClass parameters are set to PolicyAuditEventsInformation. Please refer to the individual elements in the schema for more details about what each represents.</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="oval-def:StateType">
<xsd:sequence>
<xsd:element name="account_logon" type="win-def:EntityStateAuditType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Audit attempts to log on to or log off of the system. Also, audit attempts to make a network connection.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="account_management" type="win-def:EntityStateAuditType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Audit attempts to create, delete, or change user or group accounts. Also, audit password changes.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="detailed_tracking" type="win-def:EntityStateAuditType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Audit specific events, such as program activation, some forms of handle duplication, indirect access to an object, and process exit. Note that this activitiy is also known as process tracking.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="directory_service_access" type="win-def:EntityStateAuditType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Audit attempts to access the directory service.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="logon" type="win-def:EntityStateAuditType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Audit attempts to log on to or log off of the system. Also, audit attempts to make a network connection.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="object_access" type="win-def:EntityStateAuditType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Audit attempts to access securable objects, such as files.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="policy_change" type="win-def:EntityStateAuditType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Audit attempts to change Policy object rules. </xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="privilege_use" type="win-def:EntityStateAuditType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Audit attempts to use privileges.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="system" type="win-def:EntityStateAuditType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Audit attempts to shut down or restart the computer. Also, audit events that affect system security or the security log.</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<!-- =============================================================================== -->
<!-- =================== AUDIT EVENT POLICY SUBCATEGORIES TEST =================== -->
<!-- =============================================================================== -->
<xsd:element name="auditeventpolicysubcategories_test" substitutionGroup="oval-def:test">
<xsd:annotation>
<xsd:documentation>The auditeventpolicysubcategories_test is used to check the audit event policy settings on a Windows system. These settings are used to specify which system and network events are monitored. For example, if the credential_validation element has a value of AUDIT_FAILURE, it means that the system is configured to log all unsuccessful attempts to validate a user account on a system. It is important to note that these audit event policy settings are specific to certain versions of Windows. As a result, the documentation for that version of Windows should be consulted for more information on each setting. The test extends the standard TestType as defined in the oval-definitions-schema and one should refer to the TestType description for more information. The required object element references a auditeventpolicy_object and the optional state element specifies the metadata to check.</xsd:documentation>
<xsd:appinfo>
<oval:element_mapping>
<oval:test>auditeventpolicysubcategories_test</oval:test>
<oval:object>auditeventpolicysubcategories_object</oval:object>
<oval:state>auditeventpolicysubcategories_state</oval:state>
<oval:item target_namespace="http://oval.mitre.org/XMLSchema/oval-system-characteristics-5#windows">auditeventpolicysubcategories_item</oval:item>
</oval:element_mapping>
</xsd:appinfo>
<xsd:appinfo>
<sch:pattern id="win-def_aepstst">
<sch:rule context="win-def:auditeventpolicysubcategories_test/win-def:object">
<sch:assert test="@object_ref=ancestor::oval-def:oval_definitions/oval-def:objects/win-def:auditeventpolicysubcategories_object/@id"><sch:value-of select="../@id"/> - the object child element of an auditeventpolicysubcategories_test must reference an auditeventpolicysubcategories_object</sch:assert>
</sch:rule>
<sch:rule context="win-def:auditeventpolicysubcategories_test/win-def:state">
<sch:assert test="@state_ref=ancestor::oval-def:oval_definitions/oval-def:states/win-def:auditeventpolicysubcategories_state/@id"><sch:value-of select="../@id"/> - the state child element of an auditeventpolicysubcategories_test must reference an auditeventpolicysubcategories_state</sch:assert>
</sch:rule>
</sch:pattern>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="oval-def:TestType">
<xsd:sequence>
<xsd:element name="object" type="oval-def:ObjectRefType"/>
<xsd:element name="state" type="oval-def:StateRefType" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<xsd:element name="auditeventpolicysubcategories_object" substitutionGroup="oval-def:object">
<xsd:annotation>
<xsd:documentation>The auditeventpolicysubcategories_object element is used by an audit event policy subcategories test to define those objects to evaluate based on a specified state. There is actually only one object relating to audit event policy subcategories and this is the system as a whole. Therefore, there are no child entities defined. Any OVAL Test written to check audit event policy subcategories will reference the same auditeventpolicysubcategories_object which is basically an empty object element.</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="oval-def:ObjectType"/>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<xsd:element name="auditeventpolicysubcategories_state" substitutionGroup="oval-def:state">
<xsd:annotation>
<xsd:documentation>The auditeventpolicysubcategories_state element specifies the different system activities that can be audited. An audit event policy subcategories test will reference a specific instance of this state that defines the exact subcategories that need to be evaluated. Please refer to the individual elements in the schema for more details about what each represents.</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="oval-def:StateType">
<xsd:sequence>
<!-- Account Logon Audit Policy Subcategories -->
<xsd:element name="credential_validation" type="win-def:EntityStateAuditType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Audit the events produced during the validation of a user's logon credentials.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="kerberos_authentication_service" type="win-def:EntityStateAuditType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Audit the events produced by Kerberos authentication ticket-granting requests.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="kerberos_service_ticket_operations" type="win-def:EntityStateAuditType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Audit the events produced by Kerberos service ticket requests.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="kerberos_ticket_events" type="win-def:EntityStateAuditType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Audit the events produced during the validation of Kerberos tickets provided for a user account logon request.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="other_account_logon_events" type="win-def:EntityStateAuditType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Audit the events produced by changes to user accounts that are not covered by other events in the Account Logon category.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<!-- Account Management Audit Policy Subcategories -->
<xsd:element name="application_group_management" type="win-def:EntityStateAuditType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Audit the events produced by changes to application groups.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="computer_account_management" type="win-def:EntityStateAuditType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Audit the events produced by changes to computer accounts.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="distribution_group_management" type="win-def:EntityStateAuditType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Audit the events produced by changes to distribution groups.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="other_account_management_events" type="win-def:EntityStateAuditType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Audit the events produced by other user account changes that are not covered by other events in the Account Management category.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="security_group_management" type="win-def:EntityStateAuditType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Audit the events produced by changes to security groups.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="user_account_management" type="win-def:EntityStateAuditType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Audit the events produced by changes to user accounts.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<!-- Detailed Tracking Audit Policy Subcategories -->
<xsd:element name="dpapi_activity" type="win-def:EntityStateAuditType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Audit the events produced when requests are made to the Data Protection application interface.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="process_creation" type="win-def:EntityStateAuditType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Audit the events produced when a process is created or starts.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="process_termination" type="win-def:EntityStateAuditType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Audit the events produced when a process ends.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="rpc_events" type="win-def:EntityStateAuditType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Audit the events produced by inbound remote procedure call connections.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<!-- DS Access Audit Policy Subcategories -->
<xsd:element name="directory_service_access" type="win-def:EntityStateAuditType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Audit the events produced when a Active Directory Domain Services object is accessed.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="directory_service_changes" type="win-def:EntityStateAuditType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Audit the events produced when changes are made to Active Directory Domain Services objects.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="directory_service_replication" type="win-def:EntityStateAuditType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Audit the events produced when two Active Directory Domain Services domain controllers are replicated.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="detailed_directory_service_replication" type="win-def:EntityStateAuditType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Audit the events produced by detailed Active Directory Domain Services replication between domain controllers.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<!-- Logon/Logoff Audit Policy Subcategories -->
<xsd:element name="account_lockout" type="win-def:EntityStateAuditType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Audit the events produced by a failed attempt to log onto a locked out account.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="ipsec_extended_mode" type="win-def:EntityStateAuditType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Audit the events produced by Internet Key Exchange and Authenticated Internet protocol during Extended Mode negotiations.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="ipsec_main_mode" type="win-def:EntityStateAuditType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Audit the events produced by Internet Key Exchange and Authenticated Internet protocol during Main Mode negotiations.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="ipsec_quick_mode" type="win-def:EntityStateAuditType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Audit the events produced by Internet Key Exchange and Authenticated Internet protocol during Quick Mode negotiations.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="logoff" type="win-def:EntityStateAuditType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Audit the events produced by closing a logon session.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="logon" type="win-def:EntityStateAuditType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Audit the events produced by attempts to log onto a user account.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="network_policy_server" type="win-def:EntityStateAuditType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Audit the events produced by RADIUS and Network Access Protection user access requests.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="other_logon_logoff_events" type="win-def:EntityStateAuditType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Audit the events produced by other logon/logoff based events that are not covered in the Logon/Logoff category.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="special_logon" type="win-def:EntityStateAuditType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Audit the events produced by special logons.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<!-- Object Access Audit Policy Subcategories -->
<xsd:element name="application_generated" type="win-def:EntityStateAuditType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Audit the events produced by applications that use the Windows Auditing API.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="certification_services" type="win-def:EntityStateAuditType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Audit the events produced by operations on Active Directory Certificate Services.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="detailed_file_share" type="win-def:EntityStateAuditType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Audit the events produced by attempts to access files and folders on a shared folder.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="file_share" type="win-def:EntityStateAuditType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Audit the events produced by attempts to access a shared folder.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="file_system" type="win-def:EntityStateAuditType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Audit the events produced user attempts to access file system objects.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="filtering_platform_connection" type="win-def:EntityStateAuditType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Audit the events produced by connections that are allowed or blocked by Windows Filtering Platform.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="filtering_platform_packet_drop" type="win-def:EntityStateAuditType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Audit the events produced by packets that are dropped by Windows Filtering Platform.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="handle_manipulation" type="win-def:EntityStateAuditType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Audit the events produced when a handle is opened or closed.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="kernel_object" type="win-def:EntityStateAuditType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Audit the events produced by attempts to access the system kernel.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="other_object_access_events" type="win-def:EntityStateAuditType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Audit the events produced by the management of Task Scheduler jobs or COM+ objects.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="registry" type="win-def:EntityStateAuditType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Audit the events produced by attempts to access registry objects.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="sam" type="win-def:EntityStateAuditType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Audit the events produced by attempts to access Security Accounts Manager objects.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<!-- Policy Change Audit Policy Subcategories -->
<xsd:element name="audit_policy_change" type="win-def:EntityStateAuditType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Audit the events produced by changes in security audit policy settings.</xsd:documentation>
</xsd:annotation>