Should Someone Be an Admin If They Don’t Care About Security?

Here is a bar bet you can win and probably make a decent amount of money on.  Bet an exec or even a technician that there are strangers with network administrator rights to their network.

Should that be the case? Clearly not!  Who in the world would do such a thing! Most executives confronted with this possibility would probably recoil.  Nobody wants to believe there is even one member of their tech team with a blatant disregard for security, let alone an administrator.   But the fact of the matter is, most organizations surrender administrative privileges to large numbers of people they don’t even employ.

Does that seem far-fetched? Allow me to introduce your programming team.  Chances are, you have software running on your network right now that was written by people you don’t know.   And it has administrative rights which if exploited could cripple the entire organization.   Read through to the end to understand how the non-technical executive can help control this issue.

A little bit of background for the non-technical executive, this circumstance occurs in a couple of different ways:

·         First, (on a windows network) many software packages have a component that can run “as a Service” on a pc or a server.  By default, anything that runs as a service has “Local System” rights.  In many ways system level rights are more powerful than standard administrator rights, bypassing existing rights and allowing for everything from the creation of accounts to downloading and installing software or running configuration scripts.

·         Second, applications that do not run with local system rights tend to operate with the network rights of the logged in user.   In such a case if the application tries to do something the user does not have rights to do, the software will error out.  The user then applies political pressure on IT Staff to “fix” the issue.   Without a clear-cut organizational software policy, strong technicians are left to their own judgment.  But as often as not, rights are gradually increased until the user (and consequently the software) is at least a local administrator.   If the user running the software is a “local administrator”, so is the software.   Meaning, once again, unknown programmers can install software and run configuration packages inside your organization.

·         Finally, users running as “local admins” generally have the capability to install whatever software they choose.  This creates a multiplier affect of vulnerabilities of both the previous two categories.

Put more succinctly, any software installed within your organization has the potential to run with administrative rights. Such software may inadvertently cripple critical services (think CrowdStrike).  Its source code may be infected with malware or ransomware and cause a “supply chain attack” within your network (think SolarWinds a few years back).  Or it may simply have vulnerabilities that can be exploited directly, giving bad actors direct access to organizational resources (think nearly every piece of software at one point or another).

For years the programmers one job has been to make software.  The pressure they encountered, tended to be along the lines of added functionality, more simple features and unrealistic deadlines.  They did not communicate with or know anything about the networks where their software is installed.  Rather than creating software that can run in secure environments, software vendors were more likely to create “white papers” explaining to technical staff how to loosen security configurations for optimal software performance.

this may sound like an overwhelming, or even insurmountable problem; there are actions the non-technical executive can take to increase organizational cyber-security.   By understanding the problem and removing political barriers, the non-technical executive can arguably make a more immediate difference than nearly anyone.  

The first thing to understand is that once in a hole, one should stop digging.   To that end, basic network users and even department heads should not have the capacity to install software.   This means they should not be local administrators of their machines.  Functionally, this means that software should be requested, approved by management, and installed only by an authorized technician.   Any user who can install software on their machine can install malware or worse as well.

Operationally, this may also mean that all applications will need to be installed, and certain applications will need to be updated by the it department. This, by definition, will cause more upfront work for the technicians and wait time for the employees.  Once such a policy is implemented though, backend troubleshooting of conflicts and security issues should be reduced to the benefit of all.

The next thing the non-technical executive should do is to develop an inventory of all the software deemed necessary by the organization.   This list should include all the standard software you might not think of immediately, like Microsoft Office; as well as the line of business applications that provide mission critical workflows. This list should be ranked by importance and identify who should have access.  It may be helpful to imagine a system wide crash where individual applications and services could only be restored one at a time.

In such a case, what are the five or ten most critical applications the organization would prefer to be restored first?   Who are they critical too?  One might be critical to a department head; another might be critical to the entire organization.  And a third could be essential client facing services and be something the customers and world at large would notice immediately if they weren’t available.  Inevitably, there will be applications that aren’t critical at all.  These are priorities best set by the executive team and acted upon by the technical team. 

Such a software inventory focuses everyone on what leadership deems important to the organization.  It informs IT, especially third-party IT providers, of the relative necessity of a vulnerable application.   Standing orders can be given to restrict or uninstall unauthorized applications.  Less critical applications and services can be shut down in a crisis, whereas more critical services may necessitate a discussion.  

In summary, one of the most potentially dangerous security holes in most networks is also the least reviewed.   Here are a few things the non-technical executive can do to mitigate risk.

·         Have the IT team inventory all the software on company devices

·         Have the executive team identify which pieces of software are critical to business operations, which are nice to have, and which are not critical at all.

·         Remove users’ rights to install software on their machines.

·         Establish a policy that software must be authorized prior to installation.

·         Establish a policy to vet software vendors for security and secure coding practices.

·         Move to SaaS/Cloud applications.  This generally removes requirements for rights on your network and tends to limit the collateral damage that can be caused. 

Just because these aren’t things that are currently being controlled, doesn’t mean that they can’t be.  An executive team that takes in interest in security, can go a long way towards helping the security team do their job.  Supply chain attacks are an increasing threat to your organization, it is important to understand who has admin access to your network.