Skip to main content
A few spelling fixes and words choice.
Source Link
athena
  • 3.1k
  • 17
  • 35

Risk is an increasing function of access

There is a simple rule of risk computation which explains the fear of your colleagues of the IT team. The more access you have on any operating system the higher are the impacts of any error or attack.
For example, if one userof your colleague, lets say Bob, is attacked through a standard phishing attack, then Bob account is available to cyber-criminal and sold on the Internet within minutes. If Bob account has admin privilegespriviledges then this account will be used to send SPAM at a large scale on the Internet, then to steal other accounts with phishing attacks at a large scale, and very quickly (within minutes) will open a back door to your network (this is possible because the Bob account is an admin one) permettingpermitting a total remote control of Bob's PC (through tools as `ssh`, `VNC`, `VPN`...). This attack initiated from an internal PC, from a priviledgedprivileged account is able to break any firewall, stop any anti-virus, anti-spam protection. 
The> **The evil is insideinside**. Even your best network admins, system admins or security admins may keep this corrupted PC undected for months (cf. `Stuxnet`).

Even your best network admins, system admins or security admins may leave this corrupted PC undected for months (cf. Stuxnet).

False risk reduction

If your developper colleagues are good at managing the OS on which they works, and have a physical access to the computer, then this difference in risk is null.
**Any > **Any engineer on any OS
can grant himself admin access
if > if he has a physical access to the computer.**

Blocking the admin access on any OS is a valid risk reduction approach for users who are unable to make a difference between admin privileges and normal user privileges. Here is the key question I would ask to your developper team colleagues and act upon their awareness of risk:
"What will you take care of if you are granted
admin privilege on your OS?"

"What will you take care of if you are granted
admin privilege on your OS?"

If they are good enough to be risk aware, then they are good enough to get the access they want. Then there is no risk reduction in refusing them this admin access. Beware: there is a collateral risk for your company as a whole if you refuse them an access they can easily get: they will do it the dirty way, they will behave as outlaw, they won't be able to ask any help, they'll have to cover any mishap.

Risk is an increasing function of access

There is a simple rule of risk computation which explains the fear of your colleagues of the IT team. The more access you have on any operating system the higher are the impacts of any error or attack.
For example, if one user, lets say Bob, is attacked through a standard phishing attack, then Bob account is available to cyber-criminal and sold on the Internet within minutes. If Bob account has admin privileges then this account will be used to send SPAM at a large scale on the Internet, then to steal other accounts with phishing attacks at a large scale, and very quickly (within minutes) will open a back door to your network (this is possible because the Bob account is an admin one) permetting a total remote control of Bob's PC (through tools as `ssh`, `VNC`, `VPN`...). This attack initiated from an internal PC, from a priviledged account is able to break any firewall, stop any anti-virus, anti-spam protection. The evil is inside. Even your best network admins, system admins or security admins may keep this corrupted PC undected for months (cf. `Stuxnet`).

False risk reduction

If your developper colleagues are good at managing the OS on which they works, and have a physical access to the computer, then this difference in risk is null.
**Any engineer on any OS
can grant himself admin access
if he has a physical access to the computer.**

Blocking the admin access on any OS is a valid risk reduction approach for users who are unable to make a difference between admin privileges and normal user privileges. Here is the key question I would ask to your developper team colleagues and act upon their awareness of risk:
"What will you take care of if you are granted
admin privilege on your OS?"

If they are good enough to be risk aware, then they are good enough to get the access they want. Then there is no risk reduction in refusing them this admin access. Beware: there is a collateral risk for your company as a whole: they will do it the dirty way, they will behave as outlaw, they won't be able to ask any help, they'll have to cover any mishap.

Risk is an increasing function of access

There is a simple rule of risk computation which explains the fear of your colleagues of the IT team. The more access you have on any operating system the higher are the impacts of any error or attack.
For example, if one of your colleague, lets say Bob, is attacked through a standard phishing attack, then Bob account is available to cyber-criminal and sold on the Internet within minutes. If Bob account has admin priviledges then this account will be used to send SPAM at a large scale on the Internet, then to steal other accounts with phishing attacks at a large scale, and very quickly (within minutes) will open a back door to your network (this is possible because the Bob account is an admin one) permitting a total remote control of Bob's PC (through tools as `ssh`, `VNC`, `VPN`...). This attack initiated from an internal PC, from a privileged account is able to break any firewall, stop any anti-virus, anti-spam protection. 
> **The evil is inside**.

Even your best network admins, system admins or security admins may leave this corrupted PC undected for months (cf. Stuxnet).

False risk reduction

If your developper colleagues are good at managing the OS on which they works, and have a physical access to the computer, then this difference in risk is null.
> **Any engineer on any OS
can grant himself admin access
> if he has a physical access to the computer.**

Blocking the admin access on any OS is a valid risk reduction approach for users who are unable to make a difference between admin privileges and normal user privileges. Here is the key question I would ask to your developper team colleagues and act upon their awareness of risk:

"What will you take care of if you are granted
admin privilege on your OS?"

If they are good enough to be risk aware, then they are good enough to get the access they want. Then there is no risk reduction in refusing them this admin access. Beware: there is a collateral risk for your company as a whole if you refuse them an access they can easily get: they will do it the dirty way, they will behave as outlaw, they won't be able to ask any help, they'll have to cover any mishap.

Source Link
athena
  • 3.1k
  • 17
  • 35

Risk is an increasing function of access

There is a simple rule of risk computation which explains the fear of your colleagues of the IT team. The more access you have on any operating system the higher are the impacts of any error or attack.
For example, if one user, lets say Bob, is attacked through a standard phishing attack, then Bob account is available to cyber-criminal and sold on the Internet within minutes. If Bob account has admin privileges then this account will be used to send SPAM at a large scale on the Internet, then to steal other accounts with phishing attacks at a large scale, and very quickly (within minutes) will open a back door to your network (this is possible because the Bob account is an admin one) permetting a total remote control of Bob's PC (through tools as `ssh`, `VNC`, `VPN`...). This attack initiated from an internal PC, from a priviledged account is able to break any firewall, stop any anti-virus, anti-spam protection. The evil is inside. Even your best network admins, system admins or security admins may keep this corrupted PC undected for months (cf. `Stuxnet`).

False risk reduction

If your developper colleagues are good at managing the OS on which they works, and have a physical access to the computer, then this difference in risk is null.
**Any engineer on any OS
can grant himself admin access
if he has a physical access to the computer.**

Blocking the admin access on any OS is a valid risk reduction approach for users who are unable to make a difference between admin privileges and normal user privileges. Here is the key question I would ask to your developper team colleagues and act upon their awareness of risk:
"What will you take care of if you are granted
admin privilege on your OS?"

If they are good enough to be risk aware, then they are good enough to get the access they want. Then there is no risk reduction in refusing them this admin access. Beware: there is a collateral risk for your company as a whole: they will do it the dirty way, they will behave as outlaw, they won't be able to ask any help, they'll have to cover any mishap.