Every organization has a certain amount of acceptable and unacceptable security risk. Nearly every company accepts the level of risk entailed by granting their employees access to company data needed to perform their job. For example, running reports on your customer base might require access to a database of all your customers.
A competent IT department tracks these requirements and communicates potential risks to leadership. The biggest problem is not the presence of these security risks, but the existence of unknown threats. We’ll go over some of the more common, simpler vulnerabilities that exist within the endpoint security space and provide suggestions for documenting and rectifying them. A recurring theme is not that IT professionals are somehow negligent, but that they don’t have easy access to the information to let them build and enforce sensible policies.
Tracking User Permissions
One of the easiest, but most prevalent vulnerabilities to fix, is the risk involved by providing access to information over and above what’s necessary for employees to fulfill their duties. There are all kinds of ways to chop up permissions and many different standards one can adopt, but the real issue is that it can be tough to track permissions across multiple systems.
The best way to resolve this problem is to automate in a way that allows an organization to predict who has access to what without having to search explicitly.
There should be no surprise that a particular person has access to some resource or information. For illustrative purposes, let’s take file share permissions. If someone needs access to a set of documents, the ideal method is to have a dedicated folder for the documents that are only accessible for members of the security group who were assigned permission.
Administrators often create a single role, call it sales, and then tack on all necessary file permissions to that group. The problem with this method is that you get permission creep, and suddenly your sales group has access to all the resources that any particular individual requires, even if the rest of the team doesn’t. This story shouldn’t be a surprise to any systems administrator. And it becomes extremely challenging for auditors to retrieve the rhyme or reason for anyone in sales to have access to the entire customer database. Breaking permissions out in a modular fashion has big payoffs in the long run.
Reviewing Local Administration Rights
Users are made administrators of their laptops or desktops for a variety of reasons, and almost none of them are insurmountable. Suppose some end user is using a piece of corporate software that needs weekly updates, but those updates require administrator access. So instead of having that (perhaps high-profile user) contact the helpdesk every week to remote in and update the software, a request goes to the endpoint management team, and they grant the user administrator access allowing them to update the software as needed. From a security perspective, this user’s laptop now represents a significant attack surface whereby a simple vulnerability on this machine could allow them to move laterally into accessing anything on that computer. Uh-oh. Even worse is that most companies don’t have a great way of knowing which of their users are logged in as an administrator.
There are always preferable methods of solving these kinds of issues. A small investment into an endpoint management tool that auto-updates the software suite, grants temporary administrator access for short periods of time and then automatically revokes it and provides software white-listing for self-service are all simple, low-footprint methods of completing the necessary task without opening a massive vulnerability into your corporate resources. Adopting a policy of “no local administrators” requires company buy-in, and it’s up to the company’s leadership to advertise and enforce the policy.
Establishing a Consistent Endpoint Patching Timeline
How many missing patches per endpoint does your company have? Can you even get those numbers quickly and accurately? Patching is old-hat, but even though it’s a solved problem, many organizations don’t have reasonable patch processes or a sufficient way of enforcing those policies. A typical patch timeline is as follows:
- Week 1: Microsoft publishes a set of patches for their Windows Operating Systems
- Week 2: Waiting for any day one bugs to get sorted out, the first patches are applied to non-production test systems.
- Week 3: After half-heartedly testing patches on these non-prod systems, patches are rolled out to low-impact user machines.
- Week 4: Finally, patches are rolled out high-impact machines (sensitive users, servers)
This is a generous timeline (much more accelerated than what orgs are actually doing), but even in this scenario, it can be a full month before a system receives a critical security patch. By the time the patches go live, the next month’s patches are already out. We suggest that you condense this timeline to just a week which should be trivial given an efficient patch management system and sensible policies. Here’s our plan:
- Day 1 (Patch Tuesday): Patches are received from Microsoft and immediately/automatically deployed to a representative mix of machines – users from all groups, and servers from all service/application groups.
- Day 2 (Wednesday): If there are any issues, use your patch management’s rollback utility to remove those patches and suspend further deployment. Patches automatically deployed to rest of end-user machines and low-impact servers.
- Day 3 (Thursday): If there are no issues, patches are automatically implemented to the rest of your servers.
- Day 4 (Read-only Fridays): All patches are deployed, and all problems are followed up on before the weekend.
By using this method and utilizing a competent patch management system that confers total control and complete visibility, you can accelerate your patch timelines while minimizing your missing patch downtime. Considering that many of the highest profile ransomware breaches—including WannaCry and its variants—were simple exploits of vulnerabilities fixed in patches released by Microsoft months before the weaknesses were manipulated, it’s easy to see how implementing speedy patching practices has a high return.
Moral of the Story
There are a lot of easy ways to decrease your endpoint security attack surface through sensible, inexpensive methods. The above are just a few ways you can quickly implement these suggestions into your security practices and potentially save your company real dollars and man hours.
To learn more about Endpoint Solutions, download the datasheet, take the training and watch The Power of Cyber Security Solutions webinar! Contact a Tech Data security expert today for more information at email@example.com.
About the author
Josh Hickok, Senior Consultant, Security Solutions, Tech Data