In the chapter “Detection of Conflicts in Security Policies”, the main content is the detection and management of security policy conflicts. The protection of information systems is divided into five layers: Security Requirements, Abstract Policies, Executable Policies (configuration), Policy Enforcement Mechanisms, and Enforced Policies. These strategies will deal with different conflicts. And conflicts can be divided into two categories: 1. intrapolicy conflicts and interpolicy conflicts, and follow subcategories in each category: contradictory, redundant, and irrelevant. Also mentioned in this chapter is Separation of Duties (SoD) as an important constraint. By decentralizing power and responsibility to reduce the occurrence of non-compliance business and reduce fraud.
This is a great summary. My take away from the points you raise is that firms must have sound business policies that inform information security. It’s difficult to define a technology policy unless the business agrees on the value and risk profile of the asset. This is especially important when identifying conflicts. Technology should reflect and enforce business policy/process. Firms with poor business processes will likely have more security conflicts .
In this reading the authors discuss the detection and resolution of security conflicts. Some conflicts may arise from the presence of positive and negative authorizations, e.g. Jane is assigned to a group that can access a file and another that cannot. Other conflicts may be derived from security policy constraints that the authorizations must satisfy. An example of this type of constraint is separation of duty. This type of conflict requires that sensitive permissions should not be held by the same person as defined by business rules. The reading cites the example of an individual assigned to create and approve purchase orders. In this case, there is no check on the person to ensure they aren’t creating and approving fraudulent orders.
An auditor could look for these types of conflicts by reviewing access control lists and business policies. They could also review logs from the system to identify situations where the same user carried out conflicting tasks.
In this week’s reading, the several types of methods in identifying security conflicts caught my attention. More specifically, the separation of duty (SoD) conflict was an important concept covered given that the implementation of constraints to address SoD help with preventing fraud and increase the likelihood of malicious activity being detected. For example, by preventing one user from holding multiple roles within the organization, SoD constraints can prevent malicious behaviors from occurring and going undetected; in other words, said constraints are enforced at the role hierarchy level. This is a familiar concept to us since we learned about role-based access control which restricts network access based on a person’s role with the company. From what I can recall, role-based access is also helpful in securing an organization’s confidential data.
I certainly agree that role-based access controls can provide assurance around segregation of duties, assuming the roles are designed appropriately. Provisioning user accounts at the role level is easier to manage for an organizations access management team and it ensures that user accounts aren’t provisioned excessive/rogue access.
The key point that caught my attention, is the differentiation between stateless and stateful firewall as I have been implanting the firewalls in cloud in my previous job. Stateful firewalls are capable of monitoring and detecting states of all traffic on a network to track and defend based on traffic patterns and flows. Stateless firewalls, however, only focus on individual packets, using preset rules to filter traffic.
Stateless firewalls make use of a data packet’s source, destination, and other parameters to figure out whether the data presents a threat. These parameters have to be entered by either an administrator or the manufacturer via rules they set beforehand.
A stateful firewall inspects everything inside data packets, the characteristics of the data, and its channels of communication. Stateful firewalls examine the behavior of data packets, and if anything seems off, they can filter out the suspicious data. Also, a stateful firewall can track how the data behaves, cataloging patterns of behavior.
I also found the discussion on stateless and stageful firewalls interesting. The goal of a stateless firewall is to protect networks based on static information such as source and destination, and the goal of stateful firewall is to monitor the state of active network connections while analyzing incoming traffic and looking for potential traffic and data risks. I find it interesting that stateless firewalls are only able to focus on individual packets.
In this reading I found section 6 to be interesting
6. Semantic Web Technology for Conflict Detection
The term Semantic Web refers to both a vision and a set of technologies. The vision is articulated, in particular by the World Wide Web Consortium (W3C), as an extension to the current idea of the
Web in which knowledge and data could be published in a form easy for computers to understand and reason with. Doing so would support more sophisticated software systems that share
knowledge, information, and data on the Web just as people do by publishing text and multimedia. Under the stewardship of the W3C, a set of languages, protocols, and technologies has been
developed to realize this vision partially, to enable exploration and experimentation, and to support the evolution of the concepts and technology.
This really opens some doors in terms of discovering conflicts
The role of segregation of duties (SoD) in security policy’s precedes the digital age and it’s one of the first concepts I was introduced to within the access management area. What I found interesting is the article identifies to variations of SoD including static and dynamic, which are two terms I was unfamiliar with. Static SoD (i.e. role based) is the concept I associated with all SoD’s, for example, a developer should not have the ability to develop and subsequently deploy their source code updates into the production environment. Dynamic SoD is a more systematic way of avoiding access conflicts where, if we use the previous example, the action of a developer who modified code would be captured in the system and their ability to actually deploy that code is blocked./revoked.
I like your summary of SoD. Static SoD is to let an employee perform the responsibilities of only one role, while dynamic SoD is to let one employee have the responsibilities of multiple roles and supervise each other. SoD is an important security strategy, and the primary goal of both static and dynamic SoDs is to prevent fraud within an organization and increase the likelihood of detecting human malicious activity by insiders.
In this reading, I enjoyed the section discussing Interfirewall Analysis. I learned about upstream firewall (firewall that protects servers from data sent from a computer or network) and downstream firewall (firewall that protects servers from data received from a computer or network). Upstream traffic consists of sending e-mails or uploading files. Downstream traffic consists of receiving emails or downloading files. The section also discusses four anomalies: shadowing (occurs when traffic is blocked), spuriousness (occurs when traffic is permitted), redundancy (occurs when previously blocked traffic that is denied), and correlation (occurs when rules are correlated)
The key point that I took away from the Vacca reading was from the section on the Java Enterprise Edition (Java EE) example. I thought this example was helpful in showing examples of security configuration language. The section focuses on declarative security mechanisms, but it was helpful to understand that there are two categories, programmatic and declarative. While these sort of security controls can be hard to parse through due to the technical language, I thought the section of the third chapter did a good job of showing the overlapping security constraints and how it can lead to unintended consequences, such as allowing requests that were previously denied.
I also took interest in that section, and I found it interesting how the security constraints can be overwritten if hierarchies aren’t given close attention. This makes you think how other applications handle different methods surrounding their applications outside of java. Project Zero is a google funded project which targets applications for vulnerabilities in code in zero-day attacks – I bet there are a lot of applications that are littered and exploited with these issues.
The simple takeaway here in this reading points to policy enforcement mechanism, separation of duty and how enforced policies and tools are put together to support the analysis of the security policies implementation needed by organizations to determine the corresponding security categorization (low-level function impact to High impact . How these tools when implemented support and common approach to identifying security conflicts and the tools required to supports security policies. It emphasizes the role access control plays and the essential need for it to be regulated with stringent security control and need for human intervention to help complete the task of consistently managing the access control.
The analysis and availability of high-level security policies in real systems often exhibit conflict resolution and redundancies by identifying these anomalies and possibly suggest corrections known as modality conflict.
I found the separation of duties section to be very interesting, it makes a lot of sense to have a policy in place to keep one party from having absolute power, putting in a SOD policy certainly helps to keep things more secure
Hi Jason,
I agree with you on the separation of duty policy (SoD) that limits the privileges given to a user that could be to misuse the system on their own or discourage the possibility of fraud and to avoid violating the business rules. SoD is a role-based access control that manages privileges and constraints mapped for business rules and control model.
Some key points that I took away from the chapter are that firewalls are like guards at the gates to site networks. They don’t provide total protect of incoming attacks or potential outbound attacks from infected computers. There are four types of firewalls companies can use, main border firewalls, screen border routers, internal firewalls, and host firewalls. I also found it interesting that firewalls don’t directly filter with antivirus filtering but there is a strong connection between firewalls and antivirus servers.
Good post. Firewalls and network are such a vast topic that we will not be able to know everything but understanding them will always be beneficial for us in the future. Firewalls are needed to protect and monitor what is coming in and out of the network. There is also different filters that companies used to monitor packets and the main firewall filter that most organizations use today is Stateful Packet Infection.
This chapter provides important tools for security administrators to deal with the detection of conflicts in security policies. It also provides the right approach on how to manage the conflict. Today, various hardware-software tools are used to manage a network, as well implement them with many security requirements to manage correct rules all the while allowing access to be controlled and regulated. Furthermore, policies are created based on business requirements, however many of the policies have conflicts with each other. Various hardware-software devices are used to manage and control network security that has conflicts. For example, iptable, firewall, and SELinux are all always in conflict with each other. It is the responsibility of the system/security engineer to resolve the conflicts by managing each process or service that can work based on the expectation of the requirement.
When managing the least privilege in security control, time can enhance the chances of conflict in security policies due to the need to manage access on each level. Rather than have a need to set up various network security policies that are applicable, it is important to detect the conflict in security policies when enforcing least privilege access. Then examine it when they are trying to push any request for access then can examine detection of conflict in security policies.
Separation of duties in security policies also generates conflict in security policies. For example, semantic web technology tools offer strategies that can be particularly useful for development in real-time systems. Conflict detection becomes a common component of the tool for designing and configuring security policies in the real environment, this chapter thoroughly talks about all security policy conflict concepts to all security experts.
In this chapter, authors introduced the detection and management of the conflicts in security policies that is an important topic for researchers and experts in information system discipline. The authors found out 5 conflict areas: security policies, executable security policies, network security policies, query-based conflict detention, and semantic web technology. There are 5 layers to protect information system: security requirements, abstract policies, executable policies (configuration). policy enforcement mechanisms, and enforced policies. Moreover, each conflict can be in one of two categories: intra-policy and inter-policy. In the part “conflicts in security policies”, SoD/SSoD conflicts are the important because to address SoD/SSoD can help preventing fraud.
The key takeaway in this article is centered on security policy and conflict detection on network and considering abstract and executive policies. It focuses on detection and management of conflicts in security policies which is important for organizations and industrial communities to be equipped with this knowledge areas.
I found Access Control at the Java Enterprise Edition level fascinating. That is because of how hierarchies work within the code, and how easy it is for an administrator to by accidently grant access to permissions if the hierarchies are not tailored properly. For example, adding security constraints to the URL/acme/wholesale users would deny them certain constraints for what methods the users can use. However, it becomes a problem if an administrator adds a constraint to the URL/acme group which overrides the previous constrains listed. Which is bizarre to me, because even though the new constraint was added – you would think that URL/acme/wholesale users would be the most specific constraint and therefore the methods wouldn’t be overwritten, This would cause many problems for administrators if not thoroughly checked, as it could grant permissions that were not necessary or potentially unwanted for the user types and lead to potential threats.
There are different types of firewalls including packet filtering/stateless firewalls, stateful firewalls, and application firewalls. Stateless firewalls work at the network and transport layer and focus on IP address, ports, and IP protocol type. Stateful firewalls consider everything involved in a stateless firewall but additionally track the TCP state and other stateless protocols. Application firewalls function at the application layer and are often tailored to consider specific application protocols. The reading further explains different types of testing that can be used for each type of firewall.
The key point I took from this reading is the different type policies that exist for information systems. There is abstract and executive policy. Abstract policy is a policy that provides a formal representation of access control and its behavior. Executive policy is a policy that describe the access control in a way that can immediately be processed by an access control component. There is also two categories of conflicts such as interpolicy conflict and an intrapolicy conflict. The interesting part is when you are authorized to do an action on resource A by a positive authorization and are forbidden to do the same thing on a resource a by a negative authorization.
While reading “Detection of Conflicts in Security Policies”, a something I found to be interesting was the paragraph on “Channel Protection Conflicts” under section 5. It states that the configuration of secure channels is an error-prone activity and so assistance/conflict detection mechanisms are needed by administrators. There are several technologies that can be used to protect channels, such as IPsec (Internet Protocol Security) and TLS (Transport layer security) protocol. IPsec allows the creation of secure communication channels between two endpoints by using the authentication header (AH) or the encapsulating security payload (ESP) to establish a VPN. TLS is used to create VPNS.
In today’s world, separation of duty has become very popular where the principle believes no user should be given enough privileges to misuse the system. Vacca believes that serration of duty has a high impact on preventing fraud. The recommended implementation is role-based access, where hierarchy allows easy mapping. We see companies separating employees from creating and approving orders to avoid conflict of interest in the real world. If several roles overlap, they should be assigned to different users in the system to have a separation of duties in place.
This reading proclaims in the very beginning that it “seeks to identify common approaches to identifying security conflicts, considering three relevant scenarios: access control policies, policy execution, and network protection.” Of the three, I am most interested in network protection. It is my goal to become an expert in Network security. I want to be able to protect networks, so I am planning on taking my CCNA certification to reassure myself that I know how networks function, and how to get them back up and running when they’re not functioning properly. I also set the goal of becoming a network security engineer in the near future. As of now, I only have experience as an end user support technician. But I know that I will achieve every goal I set for myself, I always do!
In the chapter “Detection of Conflicts in Security Policies”, the main content is the detection and management of security policy conflicts. The protection of information systems is divided into five layers: Security Requirements, Abstract Policies, Executable Policies (configuration), Policy Enforcement Mechanisms, and Enforced Policies. These strategies will deal with different conflicts. And conflicts can be divided into two categories: 1. intrapolicy conflicts and interpolicy conflicts, and follow subcategories in each category: contradictory, redundant, and irrelevant. Also mentioned in this chapter is Separation of Duties (SoD) as an important constraint. By decentralizing power and responsibility to reduce the occurrence of non-compliance business and reduce fraud.
This is a great summary. My take away from the points you raise is that firms must have sound business policies that inform information security. It’s difficult to define a technology policy unless the business agrees on the value and risk profile of the asset. This is especially important when identifying conflicts. Technology should reflect and enforce business policy/process. Firms with poor business processes will likely have more security conflicts .
In this reading the authors discuss the detection and resolution of security conflicts. Some conflicts may arise from the presence of positive and negative authorizations, e.g. Jane is assigned to a group that can access a file and another that cannot. Other conflicts may be derived from security policy constraints that the authorizations must satisfy. An example of this type of constraint is separation of duty. This type of conflict requires that sensitive permissions should not be held by the same person as defined by business rules. The reading cites the example of an individual assigned to create and approve purchase orders. In this case, there is no check on the person to ensure they aren’t creating and approving fraudulent orders.
An auditor could look for these types of conflicts by reviewing access control lists and business policies. They could also review logs from the system to identify situations where the same user carried out conflicting tasks.
In this week’s reading, the several types of methods in identifying security conflicts caught my attention. More specifically, the separation of duty (SoD) conflict was an important concept covered given that the implementation of constraints to address SoD help with preventing fraud and increase the likelihood of malicious activity being detected. For example, by preventing one user from holding multiple roles within the organization, SoD constraints can prevent malicious behaviors from occurring and going undetected; in other words, said constraints are enforced at the role hierarchy level. This is a familiar concept to us since we learned about role-based access control which restricts network access based on a person’s role with the company. From what I can recall, role-based access is also helpful in securing an organization’s confidential data.
I certainly agree that role-based access controls can provide assurance around segregation of duties, assuming the roles are designed appropriately. Provisioning user accounts at the role level is easier to manage for an organizations access management team and it ensures that user accounts aren’t provisioned excessive/rogue access.
The key point that caught my attention, is the differentiation between stateless and stateful firewall as I have been implanting the firewalls in cloud in my previous job. Stateful firewalls are capable of monitoring and detecting states of all traffic on a network to track and defend based on traffic patterns and flows. Stateless firewalls, however, only focus on individual packets, using preset rules to filter traffic.
Stateless firewalls make use of a data packet’s source, destination, and other parameters to figure out whether the data presents a threat. These parameters have to be entered by either an administrator or the manufacturer via rules they set beforehand.
A stateful firewall inspects everything inside data packets, the characteristics of the data, and its channels of communication. Stateful firewalls examine the behavior of data packets, and if anything seems off, they can filter out the suspicious data. Also, a stateful firewall can track how the data behaves, cataloging patterns of behavior.
Hello Shubham,
I also found the discussion on stateless and stageful firewalls interesting. The goal of a stateless firewall is to protect networks based on static information such as source and destination, and the goal of stateful firewall is to monitor the state of active network connections while analyzing incoming traffic and looking for potential traffic and data risks. I find it interesting that stateless firewalls are only able to focus on individual packets.
In this reading I found section 6 to be interesting
6. Semantic Web Technology for Conflict Detection
The term Semantic Web refers to both a vision and a set of technologies. The vision is articulated, in particular by the World Wide Web Consortium (W3C), as an extension to the current idea of the
Web in which knowledge and data could be published in a form easy for computers to understand and reason with. Doing so would support more sophisticated software systems that share
knowledge, information, and data on the Web just as people do by publishing text and multimedia. Under the stewardship of the W3C, a set of languages, protocols, and technologies has been
developed to realize this vision partially, to enable exploration and experimentation, and to support the evolution of the concepts and technology.
This really opens some doors in terms of discovering conflicts
The role of segregation of duties (SoD) in security policy’s precedes the digital age and it’s one of the first concepts I was introduced to within the access management area. What I found interesting is the article identifies to variations of SoD including static and dynamic, which are two terms I was unfamiliar with. Static SoD (i.e. role based) is the concept I associated with all SoD’s, for example, a developer should not have the ability to develop and subsequently deploy their source code updates into the production environment. Dynamic SoD is a more systematic way of avoiding access conflicts where, if we use the previous example, the action of a developer who modified code would be captured in the system and their ability to actually deploy that code is blocked./revoked.
Hi Bryan,
I like your summary of SoD. Static SoD is to let an employee perform the responsibilities of only one role, while dynamic SoD is to let one employee have the responsibilities of multiple roles and supervise each other. SoD is an important security strategy, and the primary goal of both static and dynamic SoDs is to prevent fraud within an organization and increase the likelihood of detecting human malicious activity by insiders.
In this reading, I enjoyed the section discussing Interfirewall Analysis. I learned about upstream firewall (firewall that protects servers from data sent from a computer or network) and downstream firewall (firewall that protects servers from data received from a computer or network). Upstream traffic consists of sending e-mails or uploading files. Downstream traffic consists of receiving emails or downloading files. The section also discusses four anomalies: shadowing (occurs when traffic is blocked), spuriousness (occurs when traffic is permitted), redundancy (occurs when previously blocked traffic that is denied), and correlation (occurs when rules are correlated)
The key point that I took away from the Vacca reading was from the section on the Java Enterprise Edition (Java EE) example. I thought this example was helpful in showing examples of security configuration language. The section focuses on declarative security mechanisms, but it was helpful to understand that there are two categories, programmatic and declarative. While these sort of security controls can be hard to parse through due to the technical language, I thought the section of the third chapter did a good job of showing the overlapping security constraints and how it can lead to unintended consequences, such as allowing requests that were previously denied.
Hi Ryan,
I also took interest in that section, and I found it interesting how the security constraints can be overwritten if hierarchies aren’t given close attention. This makes you think how other applications handle different methods surrounding their applications outside of java. Project Zero is a google funded project which targets applications for vulnerabilities in code in zero-day attacks – I bet there are a lot of applications that are littered and exploited with these issues.
The simple takeaway here in this reading points to policy enforcement mechanism, separation of duty and how enforced policies and tools are put together to support the analysis of the security policies implementation needed by organizations to determine the corresponding security categorization (low-level function impact to High impact . How these tools when implemented support and common approach to identifying security conflicts and the tools required to supports security policies. It emphasizes the role access control plays and the essential need for it to be regulated with stringent security control and need for human intervention to help complete the task of consistently managing the access control.
The analysis and availability of high-level security policies in real systems often exhibit conflict resolution and redundancies by identifying these anomalies and possibly suggest corrections known as modality conflict.
Hello Oluwaseun,
I found the separation of duties section to be very interesting, it makes a lot of sense to have a policy in place to keep one party from having absolute power, putting in a SOD policy certainly helps to keep things more secure
Hi Jason,
I agree with you on the separation of duty policy (SoD) that limits the privileges given to a user that could be to misuse the system on their own or discourage the possibility of fraud and to avoid violating the business rules. SoD is a role-based access control that manages privileges and constraints mapped for business rules and control model.
Some key points that I took away from the chapter are that firewalls are like guards at the gates to site networks. They don’t provide total protect of incoming attacks or potential outbound attacks from infected computers. There are four types of firewalls companies can use, main border firewalls, screen border routers, internal firewalls, and host firewalls. I also found it interesting that firewalls don’t directly filter with antivirus filtering but there is a strong connection between firewalls and antivirus servers.
Hi Corey,
Good post. Firewalls and network are such a vast topic that we will not be able to know everything but understanding them will always be beneficial for us in the future. Firewalls are needed to protect and monitor what is coming in and out of the network. There is also different filters that companies used to monitor packets and the main firewall filter that most organizations use today is Stateful Packet Infection.
This chapter provides important tools for security administrators to deal with the detection of conflicts in security policies. It also provides the right approach on how to manage the conflict. Today, various hardware-software tools are used to manage a network, as well implement them with many security requirements to manage correct rules all the while allowing access to be controlled and regulated. Furthermore, policies are created based on business requirements, however many of the policies have conflicts with each other. Various hardware-software devices are used to manage and control network security that has conflicts. For example, iptable, firewall, and SELinux are all always in conflict with each other. It is the responsibility of the system/security engineer to resolve the conflicts by managing each process or service that can work based on the expectation of the requirement.
When managing the least privilege in security control, time can enhance the chances of conflict in security policies due to the need to manage access on each level. Rather than have a need to set up various network security policies that are applicable, it is important to detect the conflict in security policies when enforcing least privilege access. Then examine it when they are trying to push any request for access then can examine detection of conflict in security policies.
Separation of duties in security policies also generates conflict in security policies. For example, semantic web technology tools offer strategies that can be particularly useful for development in real-time systems. Conflict detection becomes a common component of the tool for designing and configuring security policies in the real environment, this chapter thoroughly talks about all security policy conflict concepts to all security experts.
In this chapter, authors introduced the detection and management of the conflicts in security policies that is an important topic for researchers and experts in information system discipline. The authors found out 5 conflict areas: security policies, executable security policies, network security policies, query-based conflict detention, and semantic web technology. There are 5 layers to protect information system: security requirements, abstract policies, executable policies (configuration). policy enforcement mechanisms, and enforced policies. Moreover, each conflict can be in one of two categories: intra-policy and inter-policy. In the part “conflicts in security policies”, SoD/SSoD conflicts are the important because to address SoD/SSoD can help preventing fraud.
The key takeaway in this article is centered on security policy and conflict detection on network and considering abstract and executive policies. It focuses on detection and management of conflicts in security policies which is important for organizations and industrial communities to be equipped with this knowledge areas.
I found Access Control at the Java Enterprise Edition level fascinating. That is because of how hierarchies work within the code, and how easy it is for an administrator to by accidently grant access to permissions if the hierarchies are not tailored properly. For example, adding security constraints to the URL/acme/wholesale users would deny them certain constraints for what methods the users can use. However, it becomes a problem if an administrator adds a constraint to the URL/acme group which overrides the previous constrains listed. Which is bizarre to me, because even though the new constraint was added – you would think that URL/acme/wholesale users would be the most specific constraint and therefore the methods wouldn’t be overwritten, This would cause many problems for administrators if not thoroughly checked, as it could grant permissions that were not necessary or potentially unwanted for the user types and lead to potential threats.
There are different types of firewalls including packet filtering/stateless firewalls, stateful firewalls, and application firewalls. Stateless firewalls work at the network and transport layer and focus on IP address, ports, and IP protocol type. Stateful firewalls consider everything involved in a stateless firewall but additionally track the TCP state and other stateless protocols. Application firewalls function at the application layer and are often tailored to consider specific application protocols. The reading further explains different types of testing that can be used for each type of firewall.
The key point I took from this reading is the different type policies that exist for information systems. There is abstract and executive policy. Abstract policy is a policy that provides a formal representation of access control and its behavior. Executive policy is a policy that describe the access control in a way that can immediately be processed by an access control component. There is also two categories of conflicts such as interpolicy conflict and an intrapolicy conflict. The interesting part is when you are authorized to do an action on resource A by a positive authorization and are forbidden to do the same thing on a resource a by a negative authorization.
While reading “Detection of Conflicts in Security Policies”, a something I found to be interesting was the paragraph on “Channel Protection Conflicts” under section 5. It states that the configuration of secure channels is an error-prone activity and so assistance/conflict detection mechanisms are needed by administrators. There are several technologies that can be used to protect channels, such as IPsec (Internet Protocol Security) and TLS (Transport layer security) protocol. IPsec allows the creation of secure communication channels between two endpoints by using the authentication header (AH) or the encapsulating security payload (ESP) to establish a VPN. TLS is used to create VPNS.
In today’s world, separation of duty has become very popular where the principle believes no user should be given enough privileges to misuse the system. Vacca believes that serration of duty has a high impact on preventing fraud. The recommended implementation is role-based access, where hierarchy allows easy mapping. We see companies separating employees from creating and approving orders to avoid conflict of interest in the real world. If several roles overlap, they should be assigned to different users in the system to have a separation of duties in place.
This reading proclaims in the very beginning that it “seeks to identify common approaches to identifying security conflicts, considering three relevant scenarios: access control policies, policy execution, and network protection.” Of the three, I am most interested in network protection. It is my goal to become an expert in Network security. I want to be able to protect networks, so I am planning on taking my CCNA certification to reassure myself that I know how networks function, and how to get them back up and running when they’re not functioning properly. I also set the goal of becoming a network security engineer in the near future. As of now, I only have experience as an end user support technician. But I know that I will achieve every goal I set for myself, I always do!