Main Menu

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.

Source: Microsoft

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 ComponentPolicy LanguageProcedure 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.  

Endpoints

  1. Users can only access email from devices that are approved by the org. 
  2. Users without a compliant device will be provided instructions to enroll, or use a corporate issued device.
  3. Devices will be hardened from their OEM configurations.
  4. BYODs can access business apps and data after enrolling in MDM app, or having data protection policies applied over the air.
  1. Using MDM system+conditional Access, device status must = compliant in order to login.
  2. Enrollment instructions can be found in documentation repository.
  3. Surface Area Reduction technologies will be employed, with xy+z services disabled by default.
  4. Include specifics about certificates, business profiles, and encryption.

Data

  1. Data stored in cloud must be encrypted in transit and at rest
  2. When possible, DLP rules will apply to data to / from cloud
  3. Data – data stored in the cloud will be treated in a similar manner as sites in premises.
  4. Users will not store personal data in approved cloud storage. No data will be stored on hard drive or USB drives. 
  1. Minimum encryption standards must be AES-256 or TLS 1.2+
  2. Existing data classification policy will govern cloud data as well.
  3. Reference appropriate use of data rights policy/procedures.
  4. Approved storage locations are: OneDrive for Business & Box. Folder redirect will be enabled on all PCs to force anything saved locally to also be saved online.

Apps

  1. Usage of 3rd party SaaS app will be monitored.
  2. Where possible, usage will be authenticated and authorized via company-standard SSO.
  3. When possible, DLP controls will apply to traffic to / from cloud apps.
  4. IT has the right to ‘unsanction’ and block apps that do not meet acceptable security criteria.
  5. Public facing apps will be secured and audited.
  1. A CASB will be used. Appropriate use rights can be found in doc repo.
  2. Company IdP (i.e. Azure AD Okta, Ping, etc.) will be source of SSO passthrough. 
  3. Existing data classification policy will govern cloud app as well.
  4. CASB will block/permit traffic to/from apps from network and/or devices. Minimally accepted security criteria can be found in docs.
  5. Pen tests will be conducted annually. Apps will be scanned for vulns daily. Dormant accts to be checked monthly.

Infrastructure

  1. Admins will be limited to least privileged access.
  2. Only approved, known, and secure container images or code can be deployed. 
  3. Systems will be monitored for suspicious behavior.
  1. Refer to RBAC matrix. Exceptions to be approved by two managers.
  2. Container images will be stored in sanctioned registry, to be scanned for vulns daily & upon change. SOC alerted.
  3. Domain Controllers shall be monitored for SMB reconnaissance and lateral logins Containers will be monitored for suspicious network connections. All will trigger SIEM and investigation by SOC.

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. 

  1. Start with the crown jewels (i.e. privileged administrative accts, container registries, and apps containing crown jewels (i.e. ERP and CRM systems)  
  2. Don’t reinvent the wheel. For instance, if your data classification policy is up to speed, use the same taxonomy to govern data stored in the cloud, and similar DLP controls when emailing or sharing from SaaS. 
  3. But don’t apply dated (on-premises) policies. Passwordless is (nearly) here, and your on-premises password policies could use a refresh. For instance, Windows Hello is mapped to NIST Authentication Assurance Level 2 & 3, and Authenticator on iOS and Android to AAL2.
  4. Since cloud capabilities and controls change frequently, cloud policies and procedures should start with and continually tune these categories, yearly if not more frequently.
  5. Similarly, in the yearly audit, determine if the procedures have been followed or not. If the procedures are too difficult to follow, simplify or skill up to execute them.
  6. Ensure Managed Security Service Partners (MSSP) are following your processes, or agree to follow theirs.
  7. If you’re hoping for a single tool for ongoing monitoring and auditing, check out Cloud Security Posture Management services. If you’re familiar with Secure Score for Microsoft 365, did you know that Microsoft has a similar score for Azure, and that other SaaS providers, like Salesforce, have similar secure baselines? Leveraging APIs, Microsoft and other services are creating overlay CSPM services to track security settings across multiple cloud services in one place.  


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! 

Chris Stegh

Chris Stegh

CTO & VP of Strategy - Enabling Technologies

WHAT WE DO

Data Center Services

Cloud Services

Managed Services

Privacy Policy

WHY WE DO IT

Customer Success

Lookbook

Nutanix Award

THE LATEST

Events Calendar 

Events OnDemand

News

Facebook Twitter Instagram Linkedin
CONTACT US

Read The Exciting Announcement About Our Team Expanding!