So here we are, eighty six days, four hours,
17 minutes and 32 seconds and counting for the number of days left for the life of Windows
7 and Server 2008 R2. Of course, unless you get extended security updates. If you’re like
many of us, you’re either in the middle of doing a migration or you already have done
a migration from Windows 7 and server 2008 R2. And as part of that process, you’ve probably
changed permissions in order to copy files, move data, migrate servers. Did you ever go
back to check and make sure that those permissions were set properly once you’ve finished the
migration? For example, if you’ve used in place upgrades, permissions may be left behind
from the older operating system, that may not be what you want. So when you’re migrating,
think of these permission or legacy carry overs. When you work with hyper V often you change
permissions during the migration process and you may not change them back. For example,
you might be exporting out hyper v virtual machines over the network and you get a permission
error. That’s because the system account of the hyper V host executes the export and is
not the same permission on the network share. Thus, it’s recommended to change these permissions
to allow each system to access each other. Often tools such as PStools from syinternals
can be used to temporarily change permissions. Do the actions and at the very end of the
project they’ll change them back to what they were. I’ve got more information in the article.
Get Acl is the basic powershell command that gives you information about the security of
a resource. It can be a file. It can be a registry key. And often if you don’t go back
and check to see what you’ve set for permissions, you may come back later on and realize they’re
not set. What you want them to be. There are many scripts out there on the Web that allow
you to do a full NTFS directory effective permissions audit so you can see exactly who
is the owner, who has rights, who has access to the files. Yes, that’s great for on premise
file servers, but what about when you moved to the cloud? We need similar tools, but not
the same for when we moved to cloud security. In office 365, you have to focus on where
the data is located and where it’s shared. For example, on onedrive or SharePoint, you
can do sharing auditing, reporting in the Office 365 console, which allows the administrator
to generate a list of shared resources to enable this report. You go into that protection.office.com
and sign in in the left pane of security compliance center. Then click on search. Click on the
audit log search. And under activities you want to click sharing and access request activities
to search on these sharing related events. So when the Office 365 security and complaints
portal, you want to look for search and under activities, you want to scroll down.
Until you see sharing an access request activities and review all the options you have there.
And what kind of reports you may need. You could also do a quick query with ViewableByExternalUsers=true
and ViewableByAnonymousUsers=true. That gives you a quick and dirty report of who has access
to links and other resources inside your SharePoint. Take the time to audit and confirm that how
you set up the item is what you want it to be. Accidental access permissions can lead
to headlines and security events such as earlier this year when the exposure of eight hundred
eighty five million mortgage records at First American Financial Corporation occurred because
of misconfiguration was done in their web server. It allowed users of their company
to access records that they should not have been able to access. If someone had taken
the time to audit the permissions set on the web server, they may have saved themselves
of these headlines and these issues. Take the time to review permissions and what you’ve
set to ensure what they are, what you intend them to be. Don’t forget to sign up for tech.
Talk from IDG on the new YouTube channel for the tech news of the Day. Until next time.
This is Susan Bradley for CSO Online.