Structuring a Security Policy - Part 2

Following on from last week's post on security policy writing, below is a proposed XML template for IT security policies. It is designed to standardise policy production ensuring that no information is missed and that policies are easily located. A policy written in this framework would be stored on an intranet with different users given different levels of access. A simple set of rules applied by an XSLT parser would create automated numbering, links between policy, procedure and implementation, and the production of formatted documentation ready to print at the level of detail required, for the period required.

The XML is designed to be used for the bulk of the actual policies, but for documentation purposes these need to be bookended with administrative information at the front (such as scope descriptions and change control information) and appendicies at the back (containing forms, training documentation and other related documents). Full versions of the XML without comments are available at the end of the post.

Policy XML
<policy_xml> - The opening tag for a section of policy XML.

<title></title> - The policy title.
<parent></parent> - This would be another policy, when sub-policies are used, or could be blank.
<draft_date></draft_date> - Date of writing.
<live_date></live_date> - Date that the policy is active from. This allows those affected to be briefed and trained to cope with any changes.
<retired></retired> - Whether the policy is still in use or has been retired. Retired policies must still be stored.
<standards></standards> - A reference to any external standards that this policy is designed to meet, such as PCI-DSS or ISO:27001.
<exceptions_to_scope></exceptions_to_scope> - A record of exclusions to the policy.
<policy></policy> - The actual policy. This and the title would be the only parts actually displayed to someone reading the policy.
<notes></notes> - Any notes for other members of the infosec team who might be updating the policy at a later date, or who want more information about why a particular decision was made. The notes would be the equivalent of comments in code.
<tags></tags> - Tagging policies in the same manner as blog posts allows for the quick location of other related policies that may not be in the same policy section.

</policy_xml> - The closing tag for a section of policy XML.

Procedure XML
<procedure_xml> - The opening tag for a section of procedure XML.

<title></title> - The procedure title.
<parent></parent> - The parent policy of the procedure. This cannot be blank and must refer to an existing policy.
<procedure_scope></procedure_scope> - The scope of the individual procedure, i.e. which systems or users it will apply to.
<draft_date></draft_date> - Date of writing.
<live_date></live_date> - Date that the procedure is active from. This allows those affected to be briefed and trained to cope with any changes.
<retired></retired> - Whether the producedure is still in use or has been retired. Retired procedures must still be stored.
<standards></standards> - A reference to any external standards that this procedure is designed to meet, such as PCI-DSS or ISO:27001.
<exceptions_to_scope></exceptions_to_scope> - A record of exclusions to the procedure.
<procedure></procedure> - The actual procedure. This and the title would be the only parts actually displayed to someone reading the procedures.
<compliant></compliant> - Whether the procedure meets or exceeds the minimum standards of the policy it relates to.
<notes></notes> - Any notes for other members of the infosec team who might be updating the procedures at a later date, or who want more information about why a particular decision was made. The notes would be the equivalent of comments in code.
<tags></tags> - Tagging procedures in the same manner as blog posts allows for the quick location of other related procedures that may not be in the same policy section.

</procedure_xml> - The closing tag for a section of procedure XML.

Implementation XML
<implementation_xml> - The opening tag for a section of implementation XML.

<parent_procedure></parent_procedure> - The parent procedure of the implementation. This cannot be blank and must refer to an existing procedure.
<test_date></test_date> - The date that the implementation verification was made.
<exceptions_to_scope></exceptions_to_scope> - Any areas of the implementation which were not verified.
<implementation_results></implementation_results> - The results of the implementation verification.
<compliant></compliant> - Whether the implementation of a procedure meets or exceeds the minimum standards of the procedure.
<identified_problems></identified_problems> - Any problems identified during the verification.
<notes></notes> - Any notes for other members of the infosec team who might be reviewing the verification at a later date, or who want more information about why a particular decision was made. The notes would be the equivalent of comments in code.

</implementation_xml> - The closing tag for a section of implementation XML.

Full XML without Comments

<policy_xml>

<title></title>
<parent></parent>
<draft_date></draft_date>
<live_date></live_date>
<retired></retired>
<standards></standards>
<exceptions_to_scope></exceptions_to_scope>
<policy></policy>
<notes></notes>
<tags></tags>

</policy_xml>

<procedure_xml>

<title></title>
<parent></parent>
<procedure_scope></procedure_scope>
<draft_date></draft_date>
<live_date></live_date>
<retired></retired>
<standards></standards>
<exceptions_to_scope></exceptions_to_scope>
<procedure></procedure>
<compliant></compliant>
<notes></notes>
<tags></tags>

</procedure_xml>

<implementation_xml>

<parent_procedure></parent_procedure>
<test_date></test_date>
<exceptions_to_scope></exceptions_to_scope>
<implementation_results></implementation_results>
<compliant></compliant>
<identified_problems></identified_problems>
<notes></notes>

</implementation_xml>

The code in this post was converted into html using Centricle's encode / decode html entities tool.