Improving Cloud Security Policies
Our Strategic Advisors find a consistent gap when reviewing our customers’ security policies: a lack of focus on cloud computing. Even in organizations with many traditional policy documents, there’s a lag in updating them for cloud technologies like Microsoft 365. Additionally, the gap widens when it comes to documenting the standard procedures for securing cloud services. This blog provides suggestions on where to start, or how to bridge those gaps.
A Real-World Example
First, a bit of context to differentiate policy from procedural content. In the physical world, an analogy exists with burglar alarms. A family’s policy would be the decision to pay for and use an alarm or not. It would also say if the PIN is to be shared with anyone except the residents, and if the PIN will be occasionally changed. The procedure would document how and when the unit is to be armed/disarmed, and the PIN length. A mature process might add the names of neighbors or pet sitters who have the PIN, and how soon after sharing the PIN it should be changed.
Overkill? Probably, but in the event of a burglary, it becomes clear how helpful that information would be. Say the family jewels are missing upon returning from vacation, with no forced entry. The family who followed their procedure would have better evidence by knowing that only the dog sitter had the current PIN. Contrast their police report with a family who’d shared the current PIN with the last three pet sitters and a handyman without changing it. Who’s more likely to solve the crime?
The Cyber World is No Different
Now back to our regularly scheduled cyber security programming…. Consider organizations whose Exchange Online service gets compromised. Which would be more likely to know what happened? The org whose policy is to limit the number of global admins and to use MFA, or the organization with no limits and who didn’t change the shared password after the last three contractors finished their work?
Important note: policies are simply hollow lines of text without the procedures that dictate behavior. The family who decides to use an alarm has a policy to improve security, but is still at risk if they don’t follow a procedure to execute the policy. This is quite frequently the case in IT security, where a policy exists but does little to actually improve an organization’s security posture.
Where to start?
In cloud services, it’s well known that there is a shared responsibility for security between the service provider and the service consumer. In this well-traveled chart, the lines and overlaps are drawn.
Source: Shared responsibility in the cloud – Microsoft Azure | Microsoft Learn
The “responsibilities” in the blue center column make for good starting points for a cloud policy. Without coincidence, they align with the Zero Trust reference architecture, shown below.
Parsing Policies into Procedures
Using the Shared Responsibilities and Zero Trust charts as a basis, the chart below describes a few examples in which a cloud policy and corresponding procedures might be constructed.
|Cloud Trust Component||Policy Language||Procedure Language|
Identity & Access
1. All logins from all devices will be assumed to be untrustworthy. Every login will be verified explicitly prior to granting access.
2. User accounts may be proactively blocked in the event of a suspected compromise, before/while the user is consulted.
3. Third party SaaS accounts must be approved and sanctioned by IT. Where possible, authentication and authorization will pass through via company-standard SSO.
4. Guests access
a. will be approved when there is a valid business case two managers in the LOB approve
b. will be periodically reviewed and renewed or revoked
1. Organizational passphrase policy will apply, within system limits. MFA and conditional access will be used on all cloud accounts.
2. Workforce members will be contacted via cell phone to confirm a suspected compromise. If no cell contact can be made, members contact the support desk for resolution.
3. When no SSO option exists, IT will verify and configure SAML or OAuth protocols for all third party SaaS.
4a. Approval process will be through a web form and PowerAutomate approval.
4b. Access reviews will be set on all guest accts every 90 days. Sponsors (not guests themselves) will be asked to approve.
More mature organizations might add details around auditing/confirming controls.
Measuring Success and Other Suggested Practices:
Policies are everchanging living documents, so start yours or refresh them using these simple principles.
Have you refreshed your policies for SaaS, PaaS, and Iaas? eGroup | Enabling Technologies’ vCISO Advisors did prior to leaving their enterprises and joining our team. Reach out for a conversation!