How can you ensure information security in a distributed environment?

One way to asses your phishing risks is to perform a company wide phishing test campaign. Some vendors provide free or trial based services that can deliver the phishing test to users and provide campaign results reports to view the user click rate. Although sending periodic training emails to users on how to avoid phishing is best in my opinion, a phishing test campaign is a great way to gain insight on what percentage of users are vulnerable.

One key ingredient often not emphasized is the need to explain and communicate the policies and standards with empathy and in plain speak.

Creating policies & standards is a fundamental task. It's how executive management can clearly articulate what they expect. It helps set the culture of the organization. Yet they also need to be maintained. And when the organization changes, they need to be changed / updated as well. The policy lifecycle isn't always done well, which is bad for all parties involved. I cannot expect a person to follow a policy / standard that they are not aware of. And I cannot expect non-native English speakers to be able to read a policy that's not been translated to their native language, which is why I try to make sure policies & standards are written as clearly and concisely as possible as that makes translations easier.

Technical controls are the foundation of your security program. Using the right technologies or tools will further enhance the policies and enable your people. The products don't solve the products, people do, yet products help. Your products need to align to the processes and truly enable them. Products also need to be configured and maintained. Simply purchasing them isn't enough!

One thing I have found helpful is that there are many ‘ready to go’ solutions to educate, test and monitor your organization. Most can be tailored to specific policies of your organization. A helpful approach is also to include that these trainings help for awareness at work AND at home.

A security program is like a living organism. It will change and evolve over time. As such, one has to consciously maintain it. When it's deemed to no longer be adequate, update it. If the use case or purpose no longer fits, retire that aspect. Don't be afraid to change and adapt. After a near-miss or incident, that's a good time to devote to lessons learned or analysis and make appropriate changes to prevent future occurrences.

It’s probably just me, but I’m not sure if the starting point of the question was correct in the first place. The “exam question” is not about how to secure a distributed environment but rather, whether or not the distributed environment was intentional. If it was, then the security architecture should have been in place from the onset. If it still isn’t, identify the gaps and get on with it. If the state of things was not an intended consequence but a result of lack of proper planning and architecting, then the way to go is to first determine the desired to-be architecture, and then plan to progressively move towards that architecture as we modernize our current systems and infrastructure over time. You’re welcome.