Security Manager's Journal: A little housecleaning
- 22 April, 2013 10:04
I am never wanting for risks and vulnerabilities to address. These are things that can get pushed aside by the emergency of the day, budget constraints or the internal politics of the organization. But when the time is right, I push for change. Here are three things that I'm currently tackling.
Some problems can't be addressed until the time is right.Action plan: This could be a good time to tackle three of them.
VPN configuration has always been a point of contention between the security, desktop and network teams. Our current VPN client is deployed in a split tunneling mode. When someone is using the VPN client, only resources on our network are forced to go through the encrypted VPN tunnel. Everything else, such as webmail, social media and personal file storage like Dropbox, is routed through the user's local Internet connection.
That leaves a lot of a remote user's Internet traffic unprotected and uninspected. The traffic that stays out of the tunnel doesn't come up against our state-of-the-art firewalls for URL content filtering and is invisible to our intrusion-prevention tools, our advanced malware analysis system, our application layer inspection technology and our data loss prevention (DLP) software for identifying when sensitive information is leaked.
My objections to split tunneling have always been met with counterarguments from the network and desktop teams who worry that users will suffer performance slowdowns if all client VPN traffic is forced through our company's infrastructure. That stalemate might soon be broken, though, since the network team plans to upgrade circuits and add functionality this year, so performance won't be hit if we disable split tunneling.
The next risk I might be able to mitigate is Web-based corporate email. We deployed Microsoft Outlook Anywhere a few years ago so users could launch the Outlook client without having to be connected to the VPN. What I don't like is that it can be configured to pull mail from our servers to any PC. That would include shared, public PCs, like the ones in hotel lobbies. Once a user is done checking his mail on such a PC, he walks off, leaving the mail and calendar and contact info on the machine. Any subsequent user of that public computer could open the Outlook client and see all that information, some of which could be highly sensitive in nature. They might not be able to connect back to the Exchange server to send or receive mail, but the email, attachments, contacts and calendar items will be visible.
My preference is to use the browser-based Microsoft Outlook Web Access (OWA). With OWA, when the browser is properly closed and all Web history, cookies and cache have been cleaned, virtually no mail is left on the client PC. And that is the route we are taking, by migrating all of our employees to Microsoft 365 for cloud-based email. We will restrict Outlook Anywhere access to corporate PCs.
The third item on my list is a problem that involves permissions. It was discovered during the investigation of a recent DLP incident. The DLP analyst discovered that the permissions for a departmental file share that contained sensitive business documents were set so that all domain users could list the file contents of any folder. Although the users couldn't download or view the contents of files, just displaying folder or document names can be risky. For example, say that the human resources department had a folder named "Layoffs," and inside that was a spreadsheet called "2013 Reduction in Force." Anyone who saw those names would likely make assumptions, and layoff rumors would soon be flying.
Having found that several folders were configured in this way, we will mandate a review of all departmental file shares to ensure that permissions are set properly. We are also planning some new technical controls and processes to prevent improper permissions from being set.
This week's journal is written by a real security manager, "Mathias Thurman," whose name and employer have been disguised for obvious reasons. Contact him at email@example.com.
Join in the discussions about security! computerworld.com/blogs/security
Read more about security in Computerworld's Security Topic Center.