THE GIVE AND TAKE
There is always a give and take relationship when it comes to security and usability. Ultimately, the end goal is to have as secure of an environment as possible without inconveniencing the users to the point of warranted frustration. Frustrated users, and even administrators, will find a way to circumvent security controls to get their jobs done. Enterprise environments have many moving pieces and can be managed by anywhere from one to hundreds of employees. When the enterprise gets to a certain size roles and responsibilities begin to break out to different groups, and these responsibilities with the various groups will also shift and morph as the environment changes. To assist in a more seamless process, many look to outside software to meet certain niche requirements for management and reporting.
LOOKS GOOD, BUT IS IT REALLY?
An example that I’ve recently come across is a piece of management software for Microsoft Active Directory (AD). This add-on connects to AD with domain administrator security credentials and gives different groups the ability to change passwords in AD without giving them full access to modify objects.
This, in theory, seems like it could solve some pain points right away for many organizations. Instead of relying on domain admins to change passwords or give more permissions than necessary to Helpdesk users this software will do it for you.
While everything looks secure and the vendor uses the right buzzwords (i.e. HIPAA & SOX compliance), there are several security red flags that jump out right away.
THE SECURITY "RED FLAGS" ARE FLYING
Firstly, there isn't much that this software offers that isn’t already available in AD natively. Instead of relying on an additional piece of software, Active Directory delegation of rights can be configured. Delegating permissions will allow you to specify what containers, objects, and groups can be modified or deleted and by whom. The software also offers the ability to perform bulk updates. Alternatively, by using PowerShell (which comes native with windows environments) performing bulk updates can easily be done by administrators.
Secondly (as we discovered the hard way), by default this application was logging the username and password changes made by the users to a plain text file! (In a lab environment with the application patched to a current version they’ve fixed this issue.)
ANSWERS YOU SHOULD HAVE BEFORE INSTALLING
Whenever possible, there are several questions that should be asked before purchasing or installing new software:
- Does it require additional notoriously insecure applications, such as Java or Flash? Many software vendors have specific versions of Java or Flash that they require for the software to work correctly or to be supported. It’s best to steer clear of applications such as this as it increases inherent risk.
- Is there an actual need for this additional software? Many times the software add-on might be the first step when it shouldn’t be. The main software or tool may have the capabilities that are needed without any additional components.
- What are their security standards? If there's authentication happening in either the frontend or backend, what type and strength of encryption is being used? If the answer is “I don’t know” or an insecure standard, such as MD5 or SHA1, you should look elsewhere for a management solution.
- Is security built-in to their SDLC process? If so, do they follow OWASP guidelines when creating and updating their software platform? In the example above, the software has been given the username and password for a domain administrator account. With access to that information an attacker could compromise the entire network.
OTHER QUALITY ASSURANCE PROCESS STEPS
As well as performing due diligence prior to installing software, there are steps that can be performed in a quality assurance process to protect the environment:
- Install a trial of the software in a development or QA setting. This will allow you to track the application’s behavior and communication. Running Wireshark for a packet capture and Process Explorer for application hooks are both good steps to get a more in-depth understanding of the inner workings of the application. Malware analysis tools can also be used to track all system changes during an installation (https://github.com/Rurik/Noriben).
- Run a vulnerability scan looking for common vulnerabilities.(https://www.owasp.org/index.php/Category:Vulnerabibility_Scanning_Tools).
- Make sure everything is appropriately configured. Ensure that any host-based firewall that is installed is enabled and configured with the proper ruleset for the application to communicate.
- Check out the scope of the network. For larger applications consider the overall scope of the network, where it will be used, and any projected growth when designing the implementation. If there is a database component to the software it should be segregated between that and the application or web server. If the application components were separated onto different hosts then a compromise of the web server would be way less impactful without access to raw database files.
Remember that every added piece of technology or software in an enterprise environment changes and shifts the security risk. Not only will meticulous awareness of added technologies assist in mitigating and preventing the risks, it will also help build a better asset management program.