CSV (Comma-Separated Values) is used by almost every technology platform that we encounter. Manipulating this data can be cumbersome if you’re NOT an Excel wizard, but PowerShell can simplify this job. For example,
Group Policy is nothing but flexible and extremely powerful when it comes to both configuration management and installation of software. In addition, Group Policy is one of your best tools for securing your endpoints. You can manage anything and everything from Firewall rules, account privileges, application white-listing, etc. You can also manage user rights as well.
Computers and Users in your environment have a lot of rights, by default, that they don’t need. Using Group Policy, we can manage these privileges and start to lock-down our environments without making it burdensome for our end users. One such privilege is the ability to Log on Locally.
By default, anyone that has the correct username and password can log on locally to a system, but do you really need to log on to a server in your datacenter using a local account? Some of you might, in this case you should explicitly allow certain accounts to have this privilege. Instead of using the default setting of “if you have a local account you can log in to this system”, but instead restrict this at a global level. This ensures that your systems are properly managed and no one was being lazy or malicious by creating a one-time account they forgot about.
Let’s take the opposite approach. Do you have systems on your network(s) that should only be logged on by specific individuals, accounts, services, etc? Instead of relying on plainly on the security of your username and password, we should restrict this right to the specific accounts, computers, users, etc. that should have access. Only then, if they have the correct credentials are they allowed to login over the network.
By restricting this access to only the certain machines or users within a specific group, someone who has either found a set of credentials or has somehow infiltrated your network will only be able authorize a set of systems because others have been restricted.
Another example is to manage who has access to Log on Remote Desktop Services permissions. Does everyone need to access a set of systems (this goes for both workstations and servers)? I bet not, so why just enable RDP (Remote Desktop Protocol) for anyone who has valid credentials? We should tightly restrict who has access to our systems, especially when using RDP.
For all situations regarding user rights and access to systems, we should always restrict access as much as possible. The key is to create these restrictions without being burdensome for your end-users. There is a fine line, but we should always attempt to be reasonable with this approach. Some systems just shouldn’t be accessed over RDP or locally, this will be up to the discretion of your organizations risk. Providing clear guidance and allowing your management to either enable these restrictions or to accept the risk is all that we as IT professionals can do.
When organizations begin to think of users as cattle instead of unicorns we begin to remove their pride for, and their responsibility to, an organization. When responsibility for their actions are only out of necessity or self-preservation then you have lost the battle, but not necessarily the war. You can change people’s mindset but it just may take a little more effort.
I believe that people are the answer to most security problems. Empowering people by making them part of your security team enhances their awareness and fosters a sense of shared responsibility. Organizations that encourage (and consistently preach) a shared responsibility will have continual communication and awareness of their responsibilities in order to protect themselves and their fellow employees. Those organizations that treat employee’s as another expense (or cattle) will push their employees away which allows them to disassociate themselves from their responsibility. You have now created more resistance, and ultimately your security team has another force fighting against them – and not with them.
Cattle organizations encourage people to use their creativity in an unproductive way. The results include employees who attempt to bypass your security measures, instead of identifying and reporting potential incidents. Most organizations have warmed up to the idea of phishing simulations (I hope your organization has) to provide an immersive and lifelike training experience. Some cattle organizations have gone as far as to let go of employees that fail these tests. By taking this approach, you have now forced your employees to either report everything, report nothing, or use creative ways to fight against the security team instead of for it. Employees in a cattle organization will begin to use their creativity to bypass their training by creating Outlook rules to detect these simulations, or completely ignoring (caring) about a new face walking through the halls. The first question that should come to your mind is, why are my employees doing this. The second is identifying and preventing these (negative) creative ideas within your environment.
Unicorns are majestic and beautiful creatures. Organizations and security teams that believe, and routinely encourage, their employees have equal (shared) responsibility for the protection of their organization, their data, and ultimately their job, will obtain an army of security agents to constantly watch for suspicious activity both digitally and physically. Our security teams now have more actionable intelligence to do their jobs successfully.
Just imagine, if everyone (Finance, HR, System Administrators, Shipping, etc.) in your organization is encouraged to protect themselves, their fellow employees, and their organization from suspicious email, people, system configurations, and so on. If you have worked in security for any amount of time you know that the best information about problems or incidents comes from employees. Unicorn organizations create a culture of responsibility – a stake-hold of sorts – which enables a form of peer pressure to report and communicate any suspicious activity. I don’t know about you, but I would rather believe in unicorns than step in cow shit.
To run a PowerShell script on multiple computers via Group Policy, you can work with an Immediate Scheduled Task. The main advantage over logon scripts is that you can execute your script with admin rights.