Discussion for EA874 Topic 5 > Enterprise Security
Architecture
Post # 1
Post # 1
I think enterprise architects can all find great value and use for the template provided by the Network Applications Consortium for Enterprise Security Architecture. The document truly provides useful guidance for developing a policy-driven security program -- easily applicable in many organizations.
The three pillars of security -- comprised of Availability, Confidentiality and Integrity, also gives us guidance on the fundamental goals of security programs. Our security programs should keep these goals in mind as we identify and prioritize assets (what we need to protect), those that put these assets at risk (the threats we need to protecting our assets from), and how we plan to protect it (our security architecture). Policies and its supporting processes are developed based on findings and recommendations to reduce the risks posed by the threats.
Among our reading selections, the Gartner article of McMillan and Sholtz (2013) warns us that in developing security architecture, one significant problem is the confusion that organizations sometimes create regarding three key functions: 1.) IT security governance, 2.) security management and 3.) security operations. Such confusion can easily create the kind of inefficiencies that result in the organization's overall security performance failure, conflict of interest, and organizational dysfunction. The research article helps clarify the functional distinctions and argues the importance of establishing a security governance forum that stays out of operational issues, but rather gives direction and oversight for the organization in order to maintain the organization's focus on business outcomes. The clear definitions of the three functions will ensure the necessary separation of roles within the security architecture and processes, such that conflicts of interest which can create vulnerabilities can be avoided.
The NAC expands these discussions with its framework for developing the security programs and architecture, and provides a template which describes and delineates the various elements that work together in the framework. The diagram below, included in the white paper, shows the relationships of these elements with demarcations placed for Security Governance, Security Program Management, and Security Operations.
The NAC framework is policy-centric and walks us through a discussion of clearly defined steps to develop a security program, starting from the development of policies, standards, procedures, and guidelines; all of which are in line with the organization's risk management practice, and their definition of security requirements. I think the diagram provides a complete depiction of all key elements that needs to be considered for security program development.
By the way, I think the Trust Model from the Gartner toolkit selection also provides a good starting point for identifying security requirements that can be used to drive policy development. It has the trust level classifications of Low, Medium, and High trust, for each identified control area within each of the 13 control categories: 1.) Access Controls; 2.) Awareness and Training; 3.) Configuration Management; 4.) Maintenance; 5.) Media Protection; 6.) Physical Access Controls; 7.) Personnel Security; 8.) Risk Assessment; 9.) System Host Security; 10.) Systems and Information Interity; 11.) Workstation Protection; 12.) Wireless and Mobile; 13.) Audit and Accountability.
References:
Network Applications Consortium. (2004). Enterprise Security Architecture: A framework and template for a policy-driven security program. White paper. Prepared from NAC’s Strategic Interest Group (SIG) process.
Rob McMillan and Tom Scholtz. (2013 Jan 23) Security Governance, Management and Operations Are Not the Same. Gartner research article.
/
The three pillars of security -- comprised of Availability, Confidentiality and Integrity, also gives us guidance on the fundamental goals of security programs. Our security programs should keep these goals in mind as we identify and prioritize assets (what we need to protect), those that put these assets at risk (the threats we need to protecting our assets from), and how we plan to protect it (our security architecture). Policies and its supporting processes are developed based on findings and recommendations to reduce the risks posed by the threats.
Among our reading selections, the Gartner article of McMillan and Sholtz (2013) warns us that in developing security architecture, one significant problem is the confusion that organizations sometimes create regarding three key functions: 1.) IT security governance, 2.) security management and 3.) security operations. Such confusion can easily create the kind of inefficiencies that result in the organization's overall security performance failure, conflict of interest, and organizational dysfunction. The research article helps clarify the functional distinctions and argues the importance of establishing a security governance forum that stays out of operational issues, but rather gives direction and oversight for the organization in order to maintain the organization's focus on business outcomes. The clear definitions of the three functions will ensure the necessary separation of roles within the security architecture and processes, such that conflicts of interest which can create vulnerabilities can be avoided.
The NAC expands these discussions with its framework for developing the security programs and architecture, and provides a template which describes and delineates the various elements that work together in the framework. The diagram below, included in the white paper, shows the relationships of these elements with demarcations placed for Security Governance, Security Program Management, and Security Operations.
The NAC framework is policy-centric and walks us through a discussion of clearly defined steps to develop a security program, starting from the development of policies, standards, procedures, and guidelines; all of which are in line with the organization's risk management practice, and their definition of security requirements. I think the diagram provides a complete depiction of all key elements that needs to be considered for security program development.
By the way, I think the Trust Model from the Gartner toolkit selection also provides a good starting point for identifying security requirements that can be used to drive policy development. It has the trust level classifications of Low, Medium, and High trust, for each identified control area within each of the 13 control categories: 1.) Access Controls; 2.) Awareness and Training; 3.) Configuration Management; 4.) Maintenance; 5.) Media Protection; 6.) Physical Access Controls; 7.) Personnel Security; 8.) Risk Assessment; 9.) System Host Security; 10.) Systems and Information Interity; 11.) Workstation Protection; 12.) Wireless and Mobile; 13.) Audit and Accountability.
References:
Network Applications Consortium. (2004). Enterprise Security Architecture: A framework and template for a policy-driven security program. White paper. Prepared from NAC’s Strategic Interest Group (SIG) process.
Rob McMillan and Tom Scholtz. (2013 Jan 23) Security Governance, Management and Operations Are Not the Same. Gartner research article.
/
No comments:
Post a Comment