Editor's Notes
- #2: Presented at SecureWorld Expo Seattle
- #4: Policies are a system of authoritative artifacts deployed to protect an organization’s information assets. Specifically, authoritative artifacts are documents against which an organization executes and operates. The intent of this presentation is to provide assurance professionals with methods and techniques to drive an aggregate method of policy design and move away from the more individualistic method that has been approached.
- #5: Taxonomy is the practice and science of classification. A taxonomy, or taxonomic scheme, is a particular classification ("the taxonomy of ..."), arranged in a hierarchical structure. Typically this is organized by supertype-subtype relationships, also called generalization-specialization relationships, or less formally, parent-child relationships. In such an inheritance relationship, the subtype by definition has the same properties, behaviors, and constraints as the supertype plus one or more additional properties, behaviors, or constraints.
- #6: A taxonomy, or taxonomic scheme, is a particular classification ("the taxonomy of ..."), arranged in a hierarchical structure. Typically this is organized by super type-subtype relationships, also called generalization-specialization relationships, or less formally, parent-child relationships. In such an inheritance relationship, the subtype by definition has the same properties, behaviors, and constraints as the super type plus one or more additional properties, behaviors, or constraints. Developing policy artificats requires a blending of taxonomies from science, mathematics and the legal arena.
- #7: Large amounts of information from disparate sources is gathered and organized in a manner to provide an organization with a view of activities, events and behavior when queried and/or analyzed. To render the information in a data warehouse consumable, the information is organized by parent-child relationships in a hierarchal fashion resulting in reports that contain only the information you require to support, make or adjust decisions for the organization
- #8: Taxonomy based policies supports aggregation. Aggregation results in policy artifacts that are consumable, extensible and easily sustainable. The migration to a design-driven architecture will reduce the number of policies to design and maintain. Once developed requires less updates or updates can be made in a modular fashion.
- #9: Architectural Artifact—A specific document, report, analysis, model, or other tangible that contributes to an architectural description. [Roger Sessions]
- #10: Policies are a system of authoritative artifacts deployed to protect an organization’s information assets. Policies are legally binding to those whom they are directed. Authoritative artifacts are documents against which an organization executes and operates. Sets the bar for human behavior and the enforces through technology configuration.
- #11: An internal control that reduces the risk of an existing or potential control weakness resulting in errors and omissions. [ISACA] Controls for security policies prevent unnecessary policies, assure policy alignment to the business, verify that written policies have an intended use and provide extensibility of policy in anticipation of events and/or activities that are required which cannot meet a policy requirement and may impact compliance.
- #12: Point: The artifact and/or solution covers a particular segment. Enterprise: The artifact and/or solution covers a whole which consists of disparate points. Hybrid: The artifact and/or solution must covers both Point and Enterprise. Context: The setting of the artifact and/or solution which covers circumstances relevant to the operations of the organization. Use Scenario: Can the artifact and/or solution address scenarios that are specific to the organization? Exception: When the information in the artifact is dynamic due to the nature of the technology or audience it addresses; requires flexibility to address legacy technology that is in-scope of a regulation but cannot meet compliance requirements; temporary activities and/or events that negatively impact organization compliance and may introduce security vulnerabilities; and special circumstances for users whose role in an organization requires special consideration that may impact compliance requirements and/or introduce security vulnerabilities. Floor: The baseline from which you set policy with the intention that it can be revised to accommodate an exception; is prescriptive rather than explicit.
- #13: Setting and defining context is a method for aligning your policies to the business and a control for eliminating unnecessary policies. Additionally, it defines the conceptual layer that will drive the parent-child relationship of taxonomy-based policies.
- #14: Use-scenarios in policy design are important because policies written without use cases often contain inappropriate information for the audience, or add complexity to a simple policy. If the use-scenario is targeted toward humans, then the language and content will reflect actions that are taken by humans. If the target is technology, the content will reflect what actions the technology solution will be configured against to protect authorized users and deter unauthorized users. If you cannot map your policy to a use in your environment and/or consumed by a person or technology, it should not be written.
- #15: Taxonomy-based policy design begins by using the context control to define the setting of your policies through the identification of your audience, logical boundaries and scope. Defines the conceptual layer that will drive the parent-child relationship of taxonomy-based policies. Parent-child relationships are mapped as follows: (1) Audience is legal professionals, external end-users, internal end-users and technology professionals; (2) Logical boundaries are defined from a network domain perspective of extranet, intranet and departmental; and (3) The scope of the policies is point, enterprise and hybrid.
- #17: Development of a policy schema is essential as it provides the business with the representation of policy concepts. Defined are the policy system and the relationships between those concepts, target audience, and business function. Defining a schema provides assurance that the organization will invest only in the artifacts they require.
- #18: The schema above contains the necessary policies for the organization, defines the scope, and defines audience and boundaries. The schema is overlaid on a legal backplane to indicate overall authority and ownership of the policies.
- #19: Meta data is “data about data [wikipedia]
- #20: Just as a data warehouse is driven by the metadata it contains, so too are policy artifacts. Human resources and legal has invested in building a brand that influences the organization’s policies. Adapting your policies to reflect the same brand supports the organization’s culture and contributes to the cohesion of your policies when consumed by end users. There also may be content and directives in the aforementioned policies which influence the policies you will write. Industry standards/regulations are also metadata sources.
- #22: Depending on the audience, a taxonomy based on a table may convey policy structure and architecture. This scientific component taxonomy table below establishes another crucial element of policies. The business view of policies is rendered through the ‘what’ we must protect through meta policy followed by answering the ‘where’ we protect through micro policy
- #23: The component taxonomy defines the meta (parent) policy and micro (child) policy. The meta policy is the primary policy you want your readers to adhere to. Micro policies are introduced to further define the target areas the meta policy enforces. A network acceptable use policy is an enterprise policy meant to influence the physical human behavior of technology. The policy communicates to the user how they are to use the technology they’ve been entrusted with as well as the scope of support the organization is able to provide for its technology. Write exceptions to address future technologies they are considering, but have yet to implement based on the technology roadmap of the organization. Exceptions should also target policies that may require flexibility.