This reading built on the information included in the Firewalls chapter of the textbook. It identified two categories of conflicts that could exist – intrapolicy or interpolicy. It also introduced three subcategories of conflicts – contradictory, redundant, and irrelevant. I found the examples of security policies in the textbook to be a bit easier to digest than some of the material in this reading. My key takeaway was that there needs to be a high-level and complete representation of all security policies to evaluate for conflicts, that it’s particularly important to evaluate for conflicts in network security policies, and that there are different approaches for policy verification and/or testing, some of which are very complex and involved.
Megan,
I agree with your comments. I think that your key takeaway is a very important point that should be considered. Evaluation for conflicts and there are different approaches for verification and testing. A one size fits all approach does not work in security
This article talks about how implementing security policies on an information system can be difficult in large organizations and how conflicts can arise in the security policies. The process a policy usually goes through: 1. Security requirements, 2. Abstract policies, 3. Executable policies (configuration), and 4. Policy enforcement mechanisms. Conflicts can be in a single security policy called intrapolicy or exist between two or more policies. The result of a policy conflict could make it contradict one another, be redundant, or irrelevant. Any three of these categories ultimately may lead to the policy not being enforced and either allowing a user perform an action they were not allowed to or prevent an action a user should have permission to do. These conflicts can happen in access control management, network policies or policy execution.
An interesting takeaway from this reading is the conflicts arising in the context of abstract security policies, particularly segregation of duties (SoD). There are two main categories of SoD, static SoD and dynamic SoD. Static SoD or strong exclusion is built on the concept that given two roles, a user cannot activate both – simply put the “creator” cannot be the “approver”. Dynamic SoD or weak exclusion allows users to perform exclusive roles, just not at the same time. SoD conflict resolution includes revising the policy, restricting user’s access to various roles, etc. While SoD is not a new concept, it certainly presents a challenge for SMEs with various overlapping roles, versus larger organizations with static SoD.
There are multiple approaches to policy enforcement mechanisms, and the authors pointed out that, “A crucial advantage of using a formal policy representation, particularly at the abstract level, is the possibility of the early identification of anomalies.”. Redundancies and contradictions are common in real systems. This drives up the cost of the systems and lowers the usability for the end-users. However, the standards, such as what the XACML has take into account the redundancies and contradictions to perform “deny-overrides”, which allow denials to take precedence in an event of a conflict.
The management of security not only ensures the protection of service and adapts to the increasing complexity of system architectures. It also has to follow many regulations promulgated by governments in order to do the business practices. The conflict can be separated into two categories, one is intrapolicy conflicts which exist within a single policy. One is interpolicy conflicts with at least two or more policies. In each policy, there are three subcategories: contradictory, redundant, and irrelevant. The National Institute of Standards and Technology role-based access control model shows the users guide to ensure the separation of duty (SoD) is not violated. SoD constraints are enforced both at the role hierarchy level and user hierarchy level.
One thing I found interesting about the conflicts is that I’ve put them in place myself while messing around with my own computer or network. Usually it happens because I don’t remember what rules/policies I’ve already put in place and I didn’t document them. I usually find the conflicts with manual testing and because something I thought would work did not work. Then I go back and keep trying scenarios. Slightly applicable to this topic, most recently, I assigned two access points on my network the same static IP address, which created a conflict.
I thought the section on the Internet Protocol Security Intrapolicy Conflict Detection was interesting. In particular the point that applying more that one transformation could result in a reduction in the level of protection. The author makes a point to state that “In fact, it is not always true that the combination of more transformations results in a stronger protection.” This can lead to a multitransform anomaly, which occurs when a weaker protection is applied after a strong one. This is an important concept as much of information security involves layering preventative measures on top of each other, such as the different types of firewalls we learned about in Boyle Chapter 6 and in this case, more is not always better.
I agree that this is very interesting. I’d imagine it is something similar to having a maximum security server room and then not having a password on the computer.
When I’m doing security reviews at work we always ask about how often security policy (like firewall policies and rules) reviews are done. We also ask for evidence of the results. This reading brings up exactly why we do that: because conflicts are likely to occur. There can be intrapolicy conflicts (within a single policy) or interpolicy conflicts (between at least two). And those conflicts can be contradictory, redundant, or irrelevant. Without proper reviews, these conflicts are inevitable and will grow over time until a problem is detected. You might not think redundant conflicts are a big deal, but they cause overhead and increased security management costs.
Hi Jonathan – I agree that in large organizations with a variety of security policies, over time policy conflicts are virtually inevitable. Regular reviews are the best way to identify those conflicts in a timely fashion and resolve them to reduce the cost of managing those conflicting policies. In a critical business area like information security, clarity in policies should be a priority, because it allows faster decision-making, and reduces confusion over what is or is not permitted in a given security situation.
Separation of Duty (SoD) is an important concept from this reading. SoD constraints refer to the prevention of one user from holding multiple roles within the organization that might allow them to easily commit malicious behaviors undetected. Typically, the enterprise will identify a set of important roles in certain business process and will designate them as mutually exclusive, so that no single employee can hold more than one of that list of roles. SoD can be implemented statically or dynamically. Static SoD means an employee is limited to performing the duties of one exclusive role and can never perform the duties of another role. Dynamic SoD means an employee might hold multiple exclusive roles, but can only perform the duties of one role at any given time. The implementation of dynamic SoD requires systems in place to verify that SoD constraints are being met, and to detect when those constraints are broken. It is important to implement SoD constraints within an organization to prevent fraud and to increase the likelihood of malicious activity being detected, by increasing the number of employees who must be involved to perpetrate the activity.
One of key points that I took from this reading is the complexity of configuring network security policies due to rule dependency semantics and the interaction between policies in the network. With the global connectivity provided by the Internet, network security has gained significant attention in research and industrial communities. Due to the increasing threat of network attacks, network security devices like firewalls and IPSec gateways have become important integrated elements not only in enterprise networks but also in small and home networks. Network security polices are essential elements in Internet security devices that provide traffic filtering, integrity, confidentiality, and authentication.
An interesting takeaway I have from this reading is the distinction between irrelevant and redundant conflicts. One could argue that they are one and the same, but that could just turn into a semantics debate. Is any conflict truly irrelevant? This is why I always pull myself back to the business student in me when talking about cybersecurity. Although a conflict might be irrelevant or redundant, it’s only as irrelevant or redundant as the business case for it allows. Depending on your risk appetite, you might actually prefer redundant controls because they ensure maximum protection.
This chapter talks about how conflicts develop in security policies and what to do in order to resolve those issues. There are 3 conflicts mentioned which are contradictory (authorization that make policy inconsistent), redundant (being dominated by another authorization), and irrelevant (not being able to activate due to elements having conflicts in the authorization). One way of resolving these issues would be to come up with numerous solutions and apply them one by one if the previous solution didn’t work properly.
In this week’s reading of Chapter 55, Detection of Conflicts in Security Policies, what I thought was interesting was that there are several types of conflicts and methods in identifying security conflicts. The conflict that was interesting to me was the separation of duty conflict. Important and sensitive permissions should not be held by the same employee within the organization. Separation of duties helps prevent fraud. For example, someone in the internal audit should not also work in IT security with the organization. This chapter mentions role-based access control which restricts network access based on a person’s role with the company. Individuals are only allowed to access the data necessary to perform their tasks. Role-based access control is helpful if the organization has many employees and use third-party contractors or vendor as it will help in securing the organization’s confidential data.
My key takeaway from this reading was that policy conflicts can be divided into 2 main categories, intra-policy and inter-policy conflicts. Intrapolicy is a conflict that exists within a single policy, while interpolicy happens between two policies. For both of these categories, there are 3 sub-categories called contradictory, redundant, and irrelvant. Contradictory conflicts happens when 2 policies exists that work against each other, for example, employee 1 is given permission to access to a file but is not given access to that same file in another principal. This is contradictory because they are incompatible authorizations. Redundant conflicts occurs when one is overpowered by the other authorization and does not affect the system if removed. For example, if employee 1 has access to writing on an entire folder, it is redundant to have a policy allowing that employee to have writing access on a specific file in that folder. Irrelevant conflicts occur when the conflict can not make any moves in a system, for example, when all the authorizations working together cannot lead to activation of all the authorizations involved in the conflict.
Hi Quynh, that is a great point that you mention here about the three types of policy conflicts. I think that redundant conflict is the most common in many organizations since most access is configured in terms of folders and not file access. The reason why might be because it takes more effort and time by the IT department to individually restrict files. Restricting folders seems to be the easier but perhaps not the most efficient method.
From this reading, I found Query-Based conflict detection to be interesting. This allows users to figure out actual firewall behavior by evaluating the action it would enforce instead of trying it manually. This method is much easier than manual. There have been a few different technologies that have made this possible, including Fang and Firewall Analyzer. I like this method. For one, it makes testing components of your firewall much easier. It is also based on SQL, which is a programming language that most in the IT world are either familiar with or use regularly. This method does have some downfalls, and they are similar downfalls to traditional SQL. The queries can be extremely complex, and if one small mistake is made, the query can be useless. Firewall Analyzer, which is one of the mainstream tools that use this technology, has standard queries in its guide, which allows for less error.
I liked how figure 55.11 was similar to the Figure 6.20 from our textbook. Figure 55.11 represented going through a couple of different Firewalls before accessing the system. Although this was not presented in the reading it looks like they are attempting to represent the defense in depth concept that was discussed in the textbook. I liked how both readings related to each other with different examples.
Hi Michael , I missed this when I read the reading, but now that you point it out, I agree. It is interesting to see the defense in depth portrayed like that. With many of these concepts we have encountered in class, seeing it visualized helps reinforce the information.
The explanation of conflicts and the different type of conflicts stood out to me in this reading. The reading discussed how you start with business requirements and the you map those to system requirements, and in doing so conflicts arise. There two main categories of conflicts intrapolicy (single policy) and interpolicy ( at least two policies). Within these two categories one could have a contradictory, irrelevant, or redundant policy. This reading laid the foundation; however, I’m looking forward to the class discussion to clarify my understanding.
Megan Hall says
This reading built on the information included in the Firewalls chapter of the textbook. It identified two categories of conflicts that could exist – intrapolicy or interpolicy. It also introduced three subcategories of conflicts – contradictory, redundant, and irrelevant. I found the examples of security policies in the textbook to be a bit easier to digest than some of the material in this reading. My key takeaway was that there needs to be a high-level and complete representation of all security policies to evaluate for conflicts, that it’s particularly important to evaluate for conflicts in network security policies, and that there are different approaches for policy verification and/or testing, some of which are very complex and involved.
Michael Doherty says
Megan,
I agree with your comments. I think that your key takeaway is a very important point that should be considered. Evaluation for conflicts and there are different approaches for verification and testing. A one size fits all approach does not work in security
Nicholas Fabrizio says
This article talks about how implementing security policies on an information system can be difficult in large organizations and how conflicts can arise in the security policies. The process a policy usually goes through: 1. Security requirements, 2. Abstract policies, 3. Executable policies (configuration), and 4. Policy enforcement mechanisms. Conflicts can be in a single security policy called intrapolicy or exist between two or more policies. The result of a policy conflict could make it contradict one another, be redundant, or irrelevant. Any three of these categories ultimately may lead to the policy not being enforced and either allowing a user perform an action they were not allowed to or prevent an action a user should have permission to do. These conflicts can happen in access control management, network policies or policy execution.
Lakshmi Surujnauth says
An interesting takeaway from this reading is the conflicts arising in the context of abstract security policies, particularly segregation of duties (SoD). There are two main categories of SoD, static SoD and dynamic SoD. Static SoD or strong exclusion is built on the concept that given two roles, a user cannot activate both – simply put the “creator” cannot be the “approver”. Dynamic SoD or weak exclusion allows users to perform exclusive roles, just not at the same time. SoD conflict resolution includes revising the policy, restricting user’s access to various roles, etc. While SoD is not a new concept, it certainly presents a challenge for SMEs with various overlapping roles, versus larger organizations with static SoD.
Xiduo Liu says
There are multiple approaches to policy enforcement mechanisms, and the authors pointed out that, “A crucial advantage of using a formal policy representation, particularly at the abstract level, is the possibility of the early identification of anomalies.”. Redundancies and contradictions are common in real systems. This drives up the cost of the systems and lowers the usability for the end-users. However, the standards, such as what the XACML has take into account the redundancies and contradictions to perform “deny-overrides”, which allow denials to take precedence in an event of a conflict.
To-Yin Cheng says
The management of security not only ensures the protection of service and adapts to the increasing complexity of system architectures. It also has to follow many regulations promulgated by governments in order to do the business practices. The conflict can be separated into two categories, one is intrapolicy conflicts which exist within a single policy. One is interpolicy conflicts with at least two or more policies. In each policy, there are three subcategories: contradictory, redundant, and irrelevant. The National Institute of Standards and Technology role-based access control model shows the users guide to ensure the separation of duty (SoD) is not violated. SoD constraints are enforced both at the role hierarchy level and user hierarchy level.
Jonathan Mettus says
One thing I found interesting about the conflicts is that I’ve put them in place myself while messing around with my own computer or network. Usually it happens because I don’t remember what rules/policies I’ve already put in place and I didn’t document them. I usually find the conflicts with manual testing and because something I thought would work did not work. Then I go back and keep trying scenarios. Slightly applicable to this topic, most recently, I assigned two access points on my network the same static IP address, which created a conflict.
Christa Giordano says
I thought the section on the Internet Protocol Security Intrapolicy Conflict Detection was interesting. In particular the point that applying more that one transformation could result in a reduction in the level of protection. The author makes a point to state that “In fact, it is not always true that the combination of more transformations results in a stronger protection.” This can lead to a multitransform anomaly, which occurs when a weaker protection is applied after a strong one. This is an important concept as much of information security involves layering preventative measures on top of each other, such as the different types of firewalls we learned about in Boyle Chapter 6 and in this case, more is not always better.
Panayiotis Laskaridis says
Hi Christa,
I agree that this is very interesting. I’d imagine it is something similar to having a maximum security server room and then not having a password on the computer.
Jonathan Mettus says
When I’m doing security reviews at work we always ask about how often security policy (like firewall policies and rules) reviews are done. We also ask for evidence of the results. This reading brings up exactly why we do that: because conflicts are likely to occur. There can be intrapolicy conflicts (within a single policy) or interpolicy conflicts (between at least two). And those conflicts can be contradictory, redundant, or irrelevant. Without proper reviews, these conflicts are inevitable and will grow over time until a problem is detected. You might not think redundant conflicts are a big deal, but they cause overhead and increased security management costs.
Mitchell Dulaney says
Hi Jonathan – I agree that in large organizations with a variety of security policies, over time policy conflicts are virtually inevitable. Regular reviews are the best way to identify those conflicts in a timely fashion and resolve them to reduce the cost of managing those conflicting policies. In a critical business area like information security, clarity in policies should be a priority, because it allows faster decision-making, and reduces confusion over what is or is not permitted in a given security situation.
Mitchell Dulaney says
Separation of Duty (SoD) is an important concept from this reading. SoD constraints refer to the prevention of one user from holding multiple roles within the organization that might allow them to easily commit malicious behaviors undetected. Typically, the enterprise will identify a set of important roles in certain business process and will designate them as mutually exclusive, so that no single employee can hold more than one of that list of roles. SoD can be implemented statically or dynamically. Static SoD means an employee is limited to performing the duties of one exclusive role and can never perform the duties of another role. Dynamic SoD means an employee might hold multiple exclusive roles, but can only perform the duties of one role at any given time. The implementation of dynamic SoD requires systems in place to verify that SoD constraints are being met, and to detect when those constraints are broken. It is important to implement SoD constraints within an organization to prevent fraud and to increase the likelihood of malicious activity being detected, by increasing the number of employees who must be involved to perpetrate the activity.
Wei Liu says
One of key points that I took from this reading is the complexity of configuring network security policies due to rule dependency semantics and the interaction between policies in the network. With the global connectivity provided by the Internet, network security has gained significant attention in research and industrial communities. Due to the increasing threat of network attacks, network security devices like firewalls and IPSec gateways have become important integrated elements not only in enterprise networks but also in small and home networks. Network security polices are essential elements in Internet security devices that provide traffic filtering, integrity, confidentiality, and authentication.
Panayiotis Laskaridis says
An interesting takeaway I have from this reading is the distinction between irrelevant and redundant conflicts. One could argue that they are one and the same, but that could just turn into a semantics debate. Is any conflict truly irrelevant? This is why I always pull myself back to the business student in me when talking about cybersecurity. Although a conflict might be irrelevant or redundant, it’s only as irrelevant or redundant as the business case for it allows. Depending on your risk appetite, you might actually prefer redundant controls because they ensure maximum protection.
Christopher Clayton says
This chapter talks about how conflicts develop in security policies and what to do in order to resolve those issues. There are 3 conflicts mentioned which are contradictory (authorization that make policy inconsistent), redundant (being dominated by another authorization), and irrelevant (not being able to activate due to elements having conflicts in the authorization). One way of resolving these issues would be to come up with numerous solutions and apply them one by one if the previous solution didn’t work properly.
Elias Harake says
In this week’s reading of Chapter 55, Detection of Conflicts in Security Policies, what I thought was interesting was that there are several types of conflicts and methods in identifying security conflicts. The conflict that was interesting to me was the separation of duty conflict. Important and sensitive permissions should not be held by the same employee within the organization. Separation of duties helps prevent fraud. For example, someone in the internal audit should not also work in IT security with the organization. This chapter mentions role-based access control which restricts network access based on a person’s role with the company. Individuals are only allowed to access the data necessary to perform their tasks. Role-based access control is helpful if the organization has many employees and use third-party contractors or vendor as it will help in securing the organization’s confidential data.
Quynh Nguyen says
My key takeaway from this reading was that policy conflicts can be divided into 2 main categories, intra-policy and inter-policy conflicts. Intrapolicy is a conflict that exists within a single policy, while interpolicy happens between two policies. For both of these categories, there are 3 sub-categories called contradictory, redundant, and irrelvant. Contradictory conflicts happens when 2 policies exists that work against each other, for example, employee 1 is given permission to access to a file but is not given access to that same file in another principal. This is contradictory because they are incompatible authorizations. Redundant conflicts occurs when one is overpowered by the other authorization and does not affect the system if removed. For example, if employee 1 has access to writing on an entire folder, it is redundant to have a policy allowing that employee to have writing access on a specific file in that folder. Irrelevant conflicts occur when the conflict can not make any moves in a system, for example, when all the authorizations working together cannot lead to activation of all the authorizations involved in the conflict.
Elias Harake says
Hi Quynh, that is a great point that you mention here about the three types of policy conflicts. I think that redundant conflict is the most common in many organizations since most access is configured in terms of folders and not file access. The reason why might be because it takes more effort and time by the IT department to individually restrict files. Restricting folders seems to be the easier but perhaps not the most efficient method.
Charlie Corrao says
From this reading, I found Query-Based conflict detection to be interesting. This allows users to figure out actual firewall behavior by evaluating the action it would enforce instead of trying it manually. This method is much easier than manual. There have been a few different technologies that have made this possible, including Fang and Firewall Analyzer. I like this method. For one, it makes testing components of your firewall much easier. It is also based on SQL, which is a programming language that most in the IT world are either familiar with or use regularly. This method does have some downfalls, and they are similar downfalls to traditional SQL. The queries can be extremely complex, and if one small mistake is made, the query can be useless. Firewall Analyzer, which is one of the mainstream tools that use this technology, has standard queries in its guide, which allows for less error.
Michael Doherty says
I liked how figure 55.11 was similar to the Figure 6.20 from our textbook. Figure 55.11 represented going through a couple of different Firewalls before accessing the system. Although this was not presented in the reading it looks like they are attempting to represent the defense in depth concept that was discussed in the textbook. I liked how both readings related to each other with different examples.
Charlie Corrao says
Hi Michael , I missed this when I read the reading, but now that you point it out, I agree. It is interesting to see the defense in depth portrayed like that. With many of these concepts we have encountered in class, seeing it visualized helps reinforce the information.
Ashleigh Williams says
The explanation of conflicts and the different type of conflicts stood out to me in this reading. The reading discussed how you start with business requirements and the you map those to system requirements, and in doing so conflicts arise. There two main categories of conflicts intrapolicy (single policy) and interpolicy ( at least two policies). Within these two categories one could have a contradictory, irrelevant, or redundant policy. This reading laid the foundation; however, I’m looking forward to the class discussion to clarify my understanding.