Shared Responsibility or Shared Fate? Decentralized IT Means We Are All Cyber Defenders
With the IT universe expanding, collaboration, thoughtfulness, and discipline can ensure a more secure future.
Does your organization truly understand the shared responsibility model? Shared responsibility emerged from the early days of cloud computing as a way to delineate responsibilities between cloud providers and their customers, but often there's a gap between what shared responsibility means and how it is interpreted. With the decentralization of IT, this gap is getting worse.
Decentralization of IT
Our applications, servers, and overall technology used to be under the purview and control of the IT department, yet with the shift to cloud, and specifically software-as-a-service (SaaS), this dynamic has changed. Whether it's the sales team bringing in a customer relationship management (CRM) system like Salesforce, or the HR department operating a human resources information system (HRIS) like Workday, there's a clear "expanding universe" of IT that no longer sits where it used to. Critical business workflows exist in separate business units far from IT and security and are managed as such. Our corporate IT footprints have become decentralized.
This is not some minor, temporary trend. With the ease and speed of adopting new SaaS applications and the desire to "lift and shift" code into cloud-based environments, this is the future. The future is decentralized.
Challenging Security Realities
The shift to business-owned and -operated applications puts security teams in a position where risk management is their responsibility; they are not even able to log in to some of these critical systems. It's like asking your doctor to keep you healthy but not giving her access to your information or having regular check-ups. It doesn't work that way.
Beyond the challenging human skills gap, there's technical entropy and diversity everywhere, with different configuration settings, event logs, threat vectors, and data sensitivities. On the access side, there are different admins, users, integrations, and APIs. If you think managing security on Windows and Mac is a lot, try it across many huge applications.
With this reality, how can the security team be expected to combat a growing amount of decentralized business technology risk?
Shared Responsibility Becomes Shared Fate
We must operate our technology with the understanding that shared responsibility is the vertical view between cloud provider and customer, but that enterprise-owned piece of shared responsibility is the burden of multiple teams horizontally across an organization. Too often the mentality is us versus them, availability versus security, too busy to care about risk, too concerned with risk to understand "the business." This must change.
An incident in security doesn't just impact security. We've heard "united we stand, divided we fall." We need to say that more in cyber — we win or lose together. This is why the horizontal view, across the org for the "customer-owned" piece of shared responsibility, must be viewed as a shared fate.
Fighting Back, Together
Great, we must do more. We all hear that a lot. But what specifically can we do immediately to improve our situation?
Connect the people: Regardless of the technology, we are still in an environment where technology is deployed, managed, and used by people. Bring together the people involved in particular technologies or workflows and make sure they know each other and can communicate well.
Create a shared security-productivity vision: If each group and/or role understands what incentives, responsibilities, and other dynamics exist for their teammates, there will be more empathy and better interactions.
Continue to include security after procurement: Once a new app is rolled out, the security team needs to be informed to determine who has access to the tool, how it will be used, and what data is stored within it. It's critical that the defenders in your organization have this visibility in order to protect against threats.
Create a consistent access method: This can be through your existing IAM tools, like Okta or Ping, but it's imperative to understand how users — both inside and outside of your organization — are going to be using the app and who has admin access and rights. This way, you can limit over-privilege and prevent wide-reaching data exposure and risk.
Set organization-wide policies across apps: For example, create file-sharing rules within tools like Google Drive or Box. This can be done without the security team blocking productivity among teams. When there's a clear partnership between security and the business, simple rules around passwords, expiration dates, or access control for file sharing can be the baseline for which threat detection rules and policy violations are more clearly written and deployed.
Conduct a risk assessment of every app in your environment: Whether it's employee data in Workday or Zoom recordings of board meetings that your apps are storing, it's critical to know the relative importance and risk level of each app. Ask yourself if adversaries would want to access it and, if so, how much they'd gain from the data. This will help you determine the types of apps you allow in your network, as well as policies and controls associated with the rollout.
Roll out an integration policy, and stick to it: With organizations of more than 1,000 employees using more than 150 SaaS applications on average today, it's important to understand integrations between apps like Google and Slack. While at times wildly convenient for a particular employee, this new integration web quickly changes risk profiles of your sanctioned SaaS applications, and it's incredibly difficult to keep up once your culture allows for random third-party integrations to connect to SaaS. Be disciplined here about setting a policy and sticking to it.
While our IT universe is expanding, with some collaboration, thoughtfulness, and discipline, we can have a more productive and a more secure future. It's on us to make sure our shared fate is a positive one.
About the Author
You May Also Like