Why System Administrators should not be given scanning privileges

Its an accountability and validation issue.   Start with the original concept that the primary motivation of System administrators is to keep hosts ‘up and running’ as opposed to a Security officer, whose primary objective is to keep systems secure.   These two objectives can come into conflict.Now, lets take an example, a system administrator has a server with Java on it.   The version of Java is outdated, and has a vulnerability.   They discover that if they apply the patch, it “breaks” an application on the server.  Thus they have no particular desire to fix the vulnerability.   (It generates additional work).   The Security Officer, on the other hand, does a risk assessment to determine whether the risk should be accepted, or whether the service should be disabled (through updating Java) while waiting for a patch. Now, lets talk about what could happen.   The system administrator updates Java, and runs a scan of the host.   Now that vulnerability appears as mitigated, and its off their plate.   The application is temporarily broken.  Then they roll back the patch.   Until the Security Officer runs a rescan, that vulnerability appears as mitigated.  If the system administrator is saavy, they repeat this process immediately after every scan by the Security Officer. This sounds like something that wouldn’t happen, but I’ve seen it before.  Its more common than you think. Other options exist as well, including shutting off a machine, scanning the IP, making the host “disappear” in your security data. I’m a firm believer that System Admins should not be accepting risk.  Acceptance of risk needs to be done at a management level where the decision maker realizes the impact of what they are doing (and honestly, system administrators have a biased view of whether or not to accept risk)

Leave a Reply

Your email address will not be published.