Thursday, March 29, 2018
Thursday, March 15, 2018
Monday, February 19, 2018
Tuesday, February 6, 2018
Monday, December 18, 2017
Threat Modeling
What is a Threat?
In information security, a threat is any actor or event that can cause potential harm to an
information system asset.
In information security, a threat is any actor or event that can cause potential harm to an
information system asset.
information system asset.
Overview of Threat Modeling
Developing a threat model is the process of mapping the specific, unique threats to your
organization and the methods used to attack any information technology asset or collection of assets.
The two primary goals of threat modeling are:
- Provide a clear perspective of assets, threats, and possible attacks to facilitate discussions regarding risk management decisions and practices
- Discover and evaluate gaps in security controls at the application, system, infrastructure, and enterprise levels
The concept of conducting threat modeling exercises has been around for as long as distributed
information systems have been used to process data. Since the inception of the idea there
have been various methodologies that solve a specific problem, but may not scale to an enterprise level,
are not applicable outside of the Software Development Lifecycle (SDLC), or are not repeatable.
An effective threat modeling process that addresses these issues and can be applied to both
information technology operations and software development. The Threat Model reflects the fact
that different technology teams face different threats. Our model can be tailored to individual
stakeholders throughout an organization to reflect their areas of responsibility. This capability allows for
the entire organization to work in concert to evaluate the threats to the enterprise and develop strategies
to address those risks.
Developing a threat model is the process of mapping the specific, unique threats to your
organization and the methods used to attack any information technology asset or collection of assets.
organization and the methods used to attack any information technology asset or collection of assets.
The two primary goals of threat modeling are:
- Provide a clear perspective of assets, threats, and possible attacks to facilitate discussions regarding risk management decisions and practices
- Discover and evaluate gaps in security controls at the application, system, infrastructure, and enterprise levels
The concept of conducting threat modeling exercises has been around for as long as distributed
information systems have been used to process data. Since the inception of the idea there
have been various methodologies that solve a specific problem, but may not scale to an enterprise level,
are not applicable outside of the Software Development Lifecycle (SDLC), or are not repeatable.
information systems have been used to process data. Since the inception of the idea there
have been various methodologies that solve a specific problem, but may not scale to an enterprise level,
are not applicable outside of the Software Development Lifecycle (SDLC), or are not repeatable.
An effective threat modeling process that addresses these issues and can be applied to both
information technology operations and software development. The Threat Model reflects the fact
that different technology teams face different threats. Our model can be tailored to individual
stakeholders throughout an organization to reflect their areas of responsibility. This capability allows for
the entire organization to work in concert to evaluate the threats to the enterprise and develop strategies
to address those risks.
information technology operations and software development. The Threat Model reflects the fact
that different technology teams face different threats. Our model can be tailored to individual
stakeholders throughout an organization to reflect their areas of responsibility. This capability allows for
the entire organization to work in concert to evaluate the threats to the enterprise and develop strategies
to address those risks.
Asset Analysis
Threat models must begin with the identification of the most critical assets. This is known as the
Crown Jewel Analysis. Your organization's mission is dependent on the confidentiality, integrity,
and availability of these assets. These assets must be protected and have their risk exposure limited.
By understanding what is critical to your organization, we can identify the dependencies and the threats
you face.
Assets include two major elements:
1. Business Assets, which are data, components, or functionality that are essential for the business
mission of the system.
2. Security Assets, or data, components, or functionality that are of special interest to an attacker.
They may not always be the same.
Threat models must begin with the identification of the most critical assets. This is known as the
Crown Jewel Analysis. Your organization's mission is dependent on the confidentiality, integrity,
and availability of these assets. These assets must be protected and have their risk exposure limited.
By understanding what is critical to your organization, we can identify the dependencies and the threats
you face.
Crown Jewel Analysis. Your organization's mission is dependent on the confidentiality, integrity,
and availability of these assets. These assets must be protected and have their risk exposure limited.
By understanding what is critical to your organization, we can identify the dependencies and the threats
you face.
Assets include two major elements:
1. Business Assets, which are data, components, or functionality that are essential for the business
mission of the system.
mission of the system.
2. Security Assets, or data, components, or functionality that are of special interest to an attacker.
They may not always be the same.
They may not always be the same.
Define the Attack Surface
The next step is to create a comprehensive map of the components of the application, system, or
environment that contain, communicate with, or otherwise provide some form of access to the assets.
The communication flows between the assets and the components are integral to determining the
attack surface. The attack surface will help define the boundaries, scope, roles and responsibilities
in the threat model.
Information including devices, interfaces, libraries, protocols, functions, and APIs is collected and
used to complete the picture of the attack surface. Existing security controls and services are captured
to outline their effectiveness.
The next step is to create a comprehensive map of the components of the application, system, or
environment that contain, communicate with, or otherwise provide some form of access to the assets.
The communication flows between the assets and the components are integral to determining the
attack surface. The attack surface will help define the boundaries, scope, roles and responsibilities
in the threat model.
environment that contain, communicate with, or otherwise provide some form of access to the assets.
The communication flows between the assets and the components are integral to determining the
attack surface. The attack surface will help define the boundaries, scope, roles and responsibilities
in the threat model.
Information including devices, interfaces, libraries, protocols, functions, and APIs is collected and
used to complete the picture of the attack surface. Existing security controls and services are captured
to outline their effectiveness.
used to complete the picture of the attack surface. Existing security controls and services are captured
to outline their effectiveness.
Mapping Threats and Attacks
Threat mapping begins with determining the sources of attack and their motivation. Disgruntled
employees, state actors, and random script kiddies are all examples of potential threats to your system.
Each threat actor can have different skillsets, resources, and objectives and must be accounted for when
developing the model.
Documentation of the attack surface provides the source material of the next phase: mapping the paths
of attack. Through our understanding of the system components and functionality, we are able to
envision attacker tools and techniques applied to abuse the system. The attack surface depicts the
pathways of an attacker and allows visualization of multiple attack methods.
Threat and attack mapping is a sophisticated skill. It requires an understanding of an attacker’s
mindset and deep knowledge of attack methodologies.
Threat mapping begins with determining the sources of attack and their motivation. Disgruntled
employees, state actors, and random script kiddies are all examples of potential threats to your system.
Each threat actor can have different skillsets, resources, and objectives and must be accounted for when
developing the model.
employees, state actors, and random script kiddies are all examples of potential threats to your system.
Each threat actor can have different skillsets, resources, and objectives and must be accounted for when
developing the model.
Documentation of the attack surface provides the source material of the next phase: mapping the paths
of attack. Through our understanding of the system components and functionality, we are able to
envision attacker tools and techniques applied to abuse the system. The attack surface depicts the
pathways of an attacker and allows visualization of multiple attack methods.
of attack. Through our understanding of the system components and functionality, we are able to
envision attacker tools and techniques applied to abuse the system. The attack surface depicts the
pathways of an attacker and allows visualization of multiple attack methods.
Threat and attack mapping is a sophisticated skill. It requires an understanding of an attacker’s
mindset and deep knowledge of attack methodologies.
mindset and deep knowledge of attack methodologies.
Threat Analysis
After completing discovery of the system and detailing threat actors, comes the analysis phase, in
which the risk of each attack vector is quantified in a manner that allows stakeholders to understand
the potential for real damage to your organization.
The results of the analysis phase allow your organization to make decisions that maximize the
effectiveness of the security devices (such as firewalls, intrusion detection systems, and spam filters)
and procedures that mitigate threats and attacks. The DREAD Method is a simple, extensible model
that allows for comparing and ranking risks in an easy-to-understand manner.
Damage - How bad would an attack be?
Reproducibility - How easy is it to reproduce the attack?
Exploitability - How much work is it to launch the attack?
Affected Users - How many people will be impacted?
Discoverability - How easy is it to discover the threat?
Each category is assigned a value between 0 and 10, 0 reflecting no risk/damage, while 10 is
maximum risk/damage. The DREAD formula is:
Risk = (D + R + E + A + D) / 5
The values that are derived by DREAD allow your organization to focus its energy on the
most vulnerable portion of your information systems and prioritize your efforts on implementing
controls to reduce risk.
After completing discovery of the system and detailing threat actors, comes the analysis phase, in
which the risk of each attack vector is quantified in a manner that allows stakeholders to understand
the potential for real damage to your organization.
which the risk of each attack vector is quantified in a manner that allows stakeholders to understand
the potential for real damage to your organization.
The results of the analysis phase allow your organization to make decisions that maximize the
effectiveness of the security devices (such as firewalls, intrusion detection systems, and spam filters)
and procedures that mitigate threats and attacks. The DREAD Method is a simple, extensible model
that allows for comparing and ranking risks in an easy-to-understand manner.
effectiveness of the security devices (such as firewalls, intrusion detection systems, and spam filters)
and procedures that mitigate threats and attacks. The DREAD Method is a simple, extensible model
that allows for comparing and ranking risks in an easy-to-understand manner.
Damage - How bad would an attack be?
Reproducibility - How easy is it to reproduce the attack?
Exploitability - How much work is it to launch the attack?
Affected Users - How many people will be impacted?
Discoverability - How easy is it to discover the threat?
Each category is assigned a value between 0 and 10, 0 reflecting no risk/damage, while 10 is
maximum risk/damage. The DREAD formula is:
maximum risk/damage. The DREAD formula is:
Risk = (D + R + E + A + D) / 5
The values that are derived by DREAD allow your organization to focus its energy on the
most vulnerable portion of your information systems and prioritize your efforts on implementing
controls to reduce risk.
most vulnerable portion of your information systems and prioritize your efforts on implementing
controls to reduce risk.
Risk = Probabilty x Impact
Effective Defense
The goal of threat modeling is to select the proper controls to address identified threats.
System and software designers often choose security controls from a well-known best practice list,
such as antivirus software, firewalls, input validation, etc. However, the implementation of controls
without a threat model can lead to security holes since not all threats have been directly addressed.
Even the best practice controls, if configured generically, do not address the unique threats faced by
each organization's unique environment.
Without appropriate threat modeling, security controls and procedures can be ineffective because they
do not address the unique threats facing the organization. This approach to threat modeling uncovers
any technological, process, or organizational gaps in security controls and allows for enhanced risk
management practices that align to the mission of your organization.
The goal of threat modeling is to select the proper controls to address identified threats.
System and software designers often choose security controls from a well-known best practice list,
such as antivirus software, firewalls, input validation, etc. However, the implementation of controls
without a threat model can lead to security holes since not all threats have been directly addressed.
Even the best practice controls, if configured generically, do not address the unique threats faced by
each organization's unique environment.
System and software designers often choose security controls from a well-known best practice list,
such as antivirus software, firewalls, input validation, etc. However, the implementation of controls
without a threat model can lead to security holes since not all threats have been directly addressed.
Even the best practice controls, if configured generically, do not address the unique threats faced by
each organization's unique environment.
Without appropriate threat modeling, security controls and procedures can be ineffective because they
do not address the unique threats facing the organization. This approach to threat modeling uncovers
any technological, process, or organizational gaps in security controls and allows for enhanced risk
management practices that align to the mission of your organization.
do not address the unique threats facing the organization. This approach to threat modeling uncovers
any technological, process, or organizational gaps in security controls and allows for enhanced risk
management practices that align to the mission of your organization.
Sunday, November 26, 2017
Effective Tabletop Exercise Design
I used to hold the position that when an organization decides to execute a table top exercise it was because they were mature to the point of having an incident response plan. The organization utilizes the table top to test the execution IRP and identify any gaps. I mostly thought the exercise was to affirm that the controls and processes in place were adequate.
I was mistaken.
Often the exercise is meant to shine a spotlight on how unprepared a company is if an incident were to occur. A tabletop exercise could be to demonstrate to management that in the event of a breach they don't know who is responsible for what, what the proper response should be, when to involve legal council, when to involve law enforcement, etc.
Table top exercises are an effective tool for measuring an organization's capability of responding to an incident throughout all maturity levels.
This point highlights the importance of having a clearly defined objective before heading into a tabletop exercise. Objectives should align with past, current, and future capabilities. The objectives enable tabletop planners to design the scenario to be inclusive of all stakeholders and test the cohesiveness of supports systems in response to potential cyber attacks.
The next step should be to develop the team who will design the exercise. This could be an outsourced resource who can objectively review policies and procedures and design an exercise based on provided documentation. The design team could also be internal resources familiar with the processes in-house. The objectives should drive defining the personnel required to design scenarios. The designers should not be a part of the exercise itself. The designers should also be unencumbered from pressures of the results of the exercise (political or otherwise). The design team should be allocated anywhere between 1 to 3 months to adequately plan the exercise.
The design team will flush out all the participants in the exercise. It is key for a table top team to understand the audience of the exercise. It has to tailor its language to be inclusive. The exercise must also speak to the environment of the organization. Specific tools they use, understanding of security concepts, native acronyms, are among the things that may need to be accounted for when designing the exercise. The participants should all be able to understand and track the scenario as it is executed during the exercise.
In order to build an effective table top exercise the design team must account for these common issues with table top execution:
Now that your team is built, the objectives defined, and the audience identified, the designers will be able to begin building the scenario. Designers must build realistic events that could occur that impacts the organization, partners, and stakeholders. The scenario will be closely tied to the objectives of the exercise. The scenario is comprised of scripted events that are meant to facilitate discussions between the different groups involved in the exercise. The scripts should allow for improvisation so simple modifications and injects (new data for participants to consider) are available.
Now all that's left is the execution and after action reports. It is necessary to have someone whose only function is to take a copious amount of notes to build the report. Candor is a necessity of any table top exercise. It is meant to identify any gaps in the organization and help develop plans to rectify any findings. It must be communicated that the outcome of the exercise is meant to make all parties involved better. The event is not meant to shame but to uplift by informing and building.
I was mistaken.
Often the exercise is meant to shine a spotlight on how unprepared a company is if an incident were to occur. A tabletop exercise could be to demonstrate to management that in the event of a breach they don't know who is responsible for what, what the proper response should be, when to involve legal council, when to involve law enforcement, etc.
Table top exercises are an effective tool for measuring an organization's capability of responding to an incident throughout all maturity levels.
This point highlights the importance of having a clearly defined objective before heading into a tabletop exercise. Objectives should align with past, current, and future capabilities. The objectives enable tabletop planners to design the scenario to be inclusive of all stakeholders and test the cohesiveness of supports systems in response to potential cyber attacks.
The next step should be to develop the team who will design the exercise. This could be an outsourced resource who can objectively review policies and procedures and design an exercise based on provided documentation. The design team could also be internal resources familiar with the processes in-house. The objectives should drive defining the personnel required to design scenarios. The designers should not be a part of the exercise itself. The designers should also be unencumbered from pressures of the results of the exercise (political or otherwise). The design team should be allocated anywhere between 1 to 3 months to adequately plan the exercise.
The design team will flush out all the participants in the exercise. It is key for a table top team to understand the audience of the exercise. It has to tailor its language to be inclusive. The exercise must also speak to the environment of the organization. Specific tools they use, understanding of security concepts, native acronyms, are among the things that may need to be accounted for when designing the exercise. The participants should all be able to understand and track the scenario as it is executed during the exercise.
In order to build an effective table top exercise the design team must account for these common issues with table top execution:
- Cyber scenario objectives not clearly defined.
- Rules of engagement not clearly defined.
- Reduced awareness due to Senior leaders not involved in planning.
- Cyber injects are not executed as planned.
- Training audience fights against scenario
- Account for logistical/technical issues during execution
Now that your team is built, the objectives defined, and the audience identified, the designers will be able to begin building the scenario. Designers must build realistic events that could occur that impacts the organization, partners, and stakeholders. The scenario will be closely tied to the objectives of the exercise. The scenario is comprised of scripted events that are meant to facilitate discussions between the different groups involved in the exercise. The scripts should allow for improvisation so simple modifications and injects (new data for participants to consider) are available.
Now all that's left is the execution and after action reports. It is necessary to have someone whose only function is to take a copious amount of notes to build the report. Candor is a necessity of any table top exercise. It is meant to identify any gaps in the organization and help develop plans to rectify any findings. It must be communicated that the outcome of the exercise is meant to make all parties involved better. The event is not meant to shame but to uplift by informing and building.
Saturday, February 4, 2017
Defending the top 5 ways attackers own your network
Recently the Cyber security firm Praetorian published a report that details the top 5 attack methods used by the firm over 100 separate penetration test engagements. The report was based on what are the tools and techniques used by attackers once they already have a foothold within the network. This premise is based on the fact that it is near impossible to insure that all employees will not click on a bad link emailed to them that may run code or steal their credentials. The report show the most common ways they went from getting that user to click a bad link to owning the entire network.
The top 5 methods in order were:
So the bad news is that these security holes have been around for years. The good news is that these security holes have been around for years. This is good news because the ways to mitigate these issues are readily available and do not require the acquisition of some additional software or security appliance.
Weak Domain User Passwords
A lot of organizations feel safe because they have followed what has become common place in thinking what a secure password is. "Well my domain is set to require 8 characters, 1 special character, 1 capital letter, and 1 number as a password." Sadly, this does not make for a secure complex password. In order to satisfy these requirements users will commonly use passwords like P@ssword123 and Winter!2016. I don't believe that anyone would consider either of these examples of secure passwords. Organizations need move away from passwords towards passphrases. Where Winter!2016 is considered weak !LoveTheWinter!0f2016 is orders of magnitude more difficult to crack simply because of the increased number of characters used. Passphrases are easy to remember and provide enough security to thwart most attempts to crack.
Additional guidance is that when possible two factor authentication should be implemented especially for administrative and remote access. An organization with less strict password rules has a dramatic net positive impact when complimented with a second factor of authentication.
Broadcast Name Resolution Poisoning
Broadcast Name Resolution Poisoning attacks leverage how systems attempt to find other systems on the network to steal credentials. If a system looks for a system that is neither set in the local hosts file or in DNS looks to NetBIOS/LLMNR for answers. NetBIOS/LLMNR broadcasts traffic across the network to search for a system. Because this is broadcast traffic all systems see it and all systems can respond. An attacker can leverage this function to gather credentials that can either be cracked offline or replayed to other systems to increase network access.
Most organizations have no business need for NetBIOS/LLMNR. The guidance is to disable this and populate the DNS servers with entries for the enterprise systems. Web proxy auto discovery (WPAD) operates similarly to NetBIOS/LLMNR. This function should also be disabled within web browsers. An organization can also choose to forward WPAD traffic to an internal proxy that is controlled.
Pass the Hash
A lot of organizations do not know how to properly manage the local administrator password on the many client systems across a network. Often they have the same username and password across each of the systems because that makes for ease of administration. Unfortunately, if an attacker gains access to one system and is able to compromise the password hash they are then able to have administrative access to all systems that use that account without the need for cracking the hash.
To mitigate the exposure to pass the hash attacks, organizations should look to apply a defense in depth type approach. First is to restrict the ability Domain and Enterprise administrators to login workstations. This way the credentials will never be on the system to be stolen. Another technique is to remove the ability of workstations to initiate inbound connections to other workstations. In general there should be no reason for client to client communications to occur. Only trusted administrative network segments should be allowed to login remotely. Later versions of windows allow you to remove the ability of storing credentials in local databases.
Microsoft also has released the Local Administrator Password Solution (LAPS) that generates a random password for each local administrator account. That password is then stored in Active Directory with the computer object. Domain administrators can then grant permissions to certain users to read the password to perform administrative functions.
Clear text passwords stored in memory
Mimikatz is a popular attack tool used to steal cleartext passwords from the LSASS process in windows. If an attacker is able to obtain administrative or system level privileges, usernames and passwords can be pulled directly from memory.
Later versions of windows have resolved this issue by default but older versions must have been patched with KB 2871997 and have modified the registry to set HKLM\SYSTEM\CurrentControlSet\Control SecuityProviders\Wdigest UseLogonCredential REG_DWORD to 0. This should be considered a high value registry key so it should be monitored to make sure it hasn't been changed.
Insufficient Network Access Controls
This attack vector was touched on in the pass the hash mitigation strategy. Attackers often have free reign on a network once they get a foothold. They are able to touch other client systems as well as all of the critical systems due to a lack of network access controls that segregate systems. The network should be restricted in such a way that systems should only be able to talk to each other if there is a business need to do so.
Organizations often grasp the concept of having a DMZ and segmenting their network into trusted zones in regards to untrusted traffic coming in from the outside. The same logic should be applied internally. Client systems should be barely trusted because while administrators do have some control of the system, the end user may have engaged in some bad behavior that lead to the compromise of the system that has yet to be detected. The defender must think in terms of limiting the damage that system can do as much as possible while not significantly impeding the end user from completing daily tasks.
To accomplish this network administrators must work with business units to identify what are critical systems and understand what personnel should and should not have access to.
The top 5 methods in order were:
- Weak Domain User Passwords
- Broadcast Name Resolution Poisoning (aka WPAD)
- Local Administrator Attacks (aka Pass the Hash)
- Cleartext Passwords Stored in Memory (aka Mimikatz)
- Insufficient Network Access Controls
So the bad news is that these security holes have been around for years. The good news is that these security holes have been around for years. This is good news because the ways to mitigate these issues are readily available and do not require the acquisition of some additional software or security appliance.
Weak Domain User Passwords
A lot of organizations feel safe because they have followed what has become common place in thinking what a secure password is. "Well my domain is set to require 8 characters, 1 special character, 1 capital letter, and 1 number as a password." Sadly, this does not make for a secure complex password. In order to satisfy these requirements users will commonly use passwords like P@ssword123 and Winter!2016. I don't believe that anyone would consider either of these examples of secure passwords. Organizations need move away from passwords towards passphrases. Where Winter!2016 is considered weak !LoveTheWinter!0f2016 is orders of magnitude more difficult to crack simply because of the increased number of characters used. Passphrases are easy to remember and provide enough security to thwart most attempts to crack.
Additional guidance is that when possible two factor authentication should be implemented especially for administrative and remote access. An organization with less strict password rules has a dramatic net positive impact when complimented with a second factor of authentication.
Broadcast Name Resolution Poisoning
Broadcast Name Resolution Poisoning attacks leverage how systems attempt to find other systems on the network to steal credentials. If a system looks for a system that is neither set in the local hosts file or in DNS looks to NetBIOS/LLMNR for answers. NetBIOS/LLMNR broadcasts traffic across the network to search for a system. Because this is broadcast traffic all systems see it and all systems can respond. An attacker can leverage this function to gather credentials that can either be cracked offline or replayed to other systems to increase network access.
Most organizations have no business need for NetBIOS/LLMNR. The guidance is to disable this and populate the DNS servers with entries for the enterprise systems. Web proxy auto discovery (WPAD) operates similarly to NetBIOS/LLMNR. This function should also be disabled within web browsers. An organization can also choose to forward WPAD traffic to an internal proxy that is controlled.
Pass the Hash
A lot of organizations do not know how to properly manage the local administrator password on the many client systems across a network. Often they have the same username and password across each of the systems because that makes for ease of administration. Unfortunately, if an attacker gains access to one system and is able to compromise the password hash they are then able to have administrative access to all systems that use that account without the need for cracking the hash.
To mitigate the exposure to pass the hash attacks, organizations should look to apply a defense in depth type approach. First is to restrict the ability Domain and Enterprise administrators to login workstations. This way the credentials will never be on the system to be stolen. Another technique is to remove the ability of workstations to initiate inbound connections to other workstations. In general there should be no reason for client to client communications to occur. Only trusted administrative network segments should be allowed to login remotely. Later versions of windows allow you to remove the ability of storing credentials in local databases.
Microsoft also has released the Local Administrator Password Solution (LAPS) that generates a random password for each local administrator account. That password is then stored in Active Directory with the computer object. Domain administrators can then grant permissions to certain users to read the password to perform administrative functions.
Clear text passwords stored in memory
Mimikatz is a popular attack tool used to steal cleartext passwords from the LSASS process in windows. If an attacker is able to obtain administrative or system level privileges, usernames and passwords can be pulled directly from memory.
Later versions of windows have resolved this issue by default but older versions must have been patched with KB 2871997 and have modified the registry to set HKLM\SYSTEM\CurrentControlSet\Control SecuityProviders\Wdigest UseLogonCredential REG_DWORD to 0. This should be considered a high value registry key so it should be monitored to make sure it hasn't been changed.
Insufficient Network Access Controls
This attack vector was touched on in the pass the hash mitigation strategy. Attackers often have free reign on a network once they get a foothold. They are able to touch other client systems as well as all of the critical systems due to a lack of network access controls that segregate systems. The network should be restricted in such a way that systems should only be able to talk to each other if there is a business need to do so.
Organizations often grasp the concept of having a DMZ and segmenting their network into trusted zones in regards to untrusted traffic coming in from the outside. The same logic should be applied internally. Client systems should be barely trusted because while administrators do have some control of the system, the end user may have engaged in some bad behavior that lead to the compromise of the system that has yet to be detected. The defender must think in terms of limiting the damage that system can do as much as possible while not significantly impeding the end user from completing daily tasks.
To accomplish this network administrators must work with business units to identify what are critical systems and understand what personnel should and should not have access to.
Reference:
Subscribe to:
Posts (Atom)