March
20, 2016 / Dennis Holinka
Topic 5 – Security Architecture Layer
This week's posts go over the Security Architecture Layer, the various perspectives, and related reflections in the blog.
Post 3 – Software Defined Security - Global Security Compliance Rules Consolidation
The future of software defined security will be difficult unless there is a metadata driven architecture to provide a central approach to the way security architecture rules and controls are implemented. Most global enterprise are constantly chasing the deluge of controls across multiple privacy, security, legal, regulatory, and compliance taxonomies. Among the taxonomies that abound are the following frameworks that contribute to creation or redundant mapping of a control: AICPA 2014 Trust Services Criteria, Canada PIPEDA (Personal Information Protection Electronic Documents Act), COBIT 5.0, COPPA (Children’s Online Privacy Protection Act), CSA Enterprise Architecture, ENISA (European Network Information and Security Agency) Information Assurance Framework, European Union Data Protection Directive 95/36/EC, FERPA (Family Education and Rights Privacy Act), HIPAA/HITECH act and the Omnibus Rule, ISO/IEC 27001:2013, ITAR (International Traffic in Arms Regulation), Mexico - Federal Law on Protection of Personal Data Held by Private Parties, NIST SP800-53 Rev 3 Appendix J, NZISM (New Zealand Information Security Manual), ODCA (Open Data Center Alliance) Usage Model PAAS Interoperability Rev. 2.0, and PCI DSS v3.
In order for software defined security to inter-operate globally and meet programmatic objective and provide adaptability, a central information repository, similar to the one described in the Security Information Requirement for the Security Vision Requirements document described by Gartner. This central repository should steward the cross mappings of the various global frameworks to simplify the number of controls and implied security architecture designs so that may be programatically applied to IT solutions for the business enterprise. An example of an organization that provides such cross mappings is the Cloud Security Alliance whose mission it is to standardize on the security controls across domains and frameworks. The controls matrix provided by the organization (CCM) assist customers in assessing the overall security risk of a provider with its intention of standardizing cloud providers. According to the Alliance organization, CCM "provides a controls framework in 16 domains that are cross-walked to other industry-accepted security standards, regulations, and controls frameworks to reduce audit complexity, normalize security expectations, cloud taxonomy and terminology, and security measures implemented in the cloud":
According to Gartner, Phase 3 is "longer term, expect further transformation of information security to become software-defined itself. The shift to SDx has the potential to generate organizational disruption" by requiring teams from server, network, storage, and information security integrate into a platform team. The software defined anything SDx including security will require the standardization of controls and an API based approach similar to Open Stack for Security to emerge to provide the facade for provider specific implementations of security. For example there are emerging SDN security controllers that can control the flow of open flow traffic defined by SDN. This is achieved by separating the management, control, and data planes for security as well as network so that each can be controlled. There are scripting languages such as FRESCO and controllers/kernels such as FORT/NOX that provide the ability to provide dynamic security to the network flows. Similarly, SOA Gateways can be used to provide similar security features when combined with a programmatic management, control, and data plane provider.
As you can see from the figure that the SDN Controller can manage the security of the software defined network that was topologically assembled. A similar approach can be used if SDx is used at the process and application component layers as it is used here in the technology layer for network, server, storage, and information repositories (e.g. Data-stores). The approach of using APIs that can reconfigure configurations/objects and manage intercepts for entry or exit functions for the application and technology layers will be required to provide the SDx Phase 3 integration for security across the IT stack.
Topic 5 – Security Architecture Layer
This week's posts go over the Security Architecture Layer, the various perspectives, and related reflections in the blog.
Post 3 – Software Defined Security - Global Security Compliance Rules Consolidation
The future of software defined security will be difficult unless there is a metadata driven architecture to provide a central approach to the way security architecture rules and controls are implemented. Most global enterprise are constantly chasing the deluge of controls across multiple privacy, security, legal, regulatory, and compliance taxonomies. Among the taxonomies that abound are the following frameworks that contribute to creation or redundant mapping of a control: AICPA 2014 Trust Services Criteria, Canada PIPEDA (Personal Information Protection Electronic Documents Act), COBIT 5.0, COPPA (Children’s Online Privacy Protection Act), CSA Enterprise Architecture, ENISA (European Network Information and Security Agency) Information Assurance Framework, European Union Data Protection Directive 95/36/EC, FERPA (Family Education and Rights Privacy Act), HIPAA/HITECH act and the Omnibus Rule, ISO/IEC 27001:2013, ITAR (International Traffic in Arms Regulation), Mexico - Federal Law on Protection of Personal Data Held by Private Parties, NIST SP800-53 Rev 3 Appendix J, NZISM (New Zealand Information Security Manual), ODCA (Open Data Center Alliance) Usage Model PAAS Interoperability Rev. 2.0, and PCI DSS v3.
In order for software defined security to inter-operate globally and meet programmatic objective and provide adaptability, a central information repository, similar to the one described in the Security Information Requirement for the Security Vision Requirements document described by Gartner. This central repository should steward the cross mappings of the various global frameworks to simplify the number of controls and implied security architecture designs so that may be programatically applied to IT solutions for the business enterprise. An example of an organization that provides such cross mappings is the Cloud Security Alliance whose mission it is to standardize on the security controls across domains and frameworks. The controls matrix provided by the organization (CCM) assist customers in assessing the overall security risk of a provider with its intention of standardizing cloud providers. According to the Alliance organization, CCM "provides a controls framework in 16 domains that are cross-walked to other industry-accepted security standards, regulations, and controls frameworks to reduce audit complexity, normalize security expectations, cloud taxonomy and terminology, and security measures implemented in the cloud":
Figure: CSA - CCM version 3.0.1
Figure: Software Defined Network Security Application - Example
As you can see from the figure that the SDN Controller can manage the security of the software defined network that was topologically assembled. A similar approach can be used if SDx is used at the process and application component layers as it is used here in the technology layer for network, server, storage, and information repositories (e.g. Data-stores). The approach of using APIs that can reconfigure configurations/objects and manage intercepts for entry or exit functions for the application and technology layers will be required to provide the SDx Phase 3 integration for security across the IT stack.
