The Shared Security Struggle: Navigating the SaaS shared security responsibility model.

The Shared Security Struggle: Navigating the SaaS shared security responsibility model.

In the not-too-distant past, business critical applications were hosted on bare-metal, ran on dedicated network infrastructure, managed by in-house IT staff, and hosted within company owned data centers. Responsibility for securing this compute infrastructure belonged to the organization's security teams. With hyperscalers entering the picture, these dedicated environments are being methodically substituted in favor of shared infrastructures, hosted platforms, and application environments (IaaS, PaaS, and SaaS). From a business perspective this makes economic sense, but this change introduced a nuance, the shared security responsibility model.

On the other hand, Security experts and Industry Threat reports are predicting ever increasing attacks intended on compromising business critical infrastructure and applications. By design, application interfaces are exposed to the public internet and attackers are quickly capitalizing on application development mistakes, vulnerabilities in embedded libraries, logic mistakes and non-standard security practices. It is simple math for adversaries - invest in compromising a SaaS platform and every customer on that SaaS infrastructure is a potential target of opportunity. Today, SaaS spend globally is about $195B and companies, on average, have around 80 SaaS applications. Eventually, SaaS applications are expected to reach 85% of an organization's software collection. In a recent survey, SaaS was voted the most important technology in achieving business success.

Facing reality. Businesses have decided to double-down on SaaS applications. Enterprise security teams are now sharing security responsibilities for their business-critical applications with partner teams that they do not manage, on infrastructures that they do not have visibility or control over. Teams need to address how they can mitigate cyber security related risk to the business in this shared security responsibility model. The shared responsibility model splits security responsibilities for infrastructure, applications, user access and data protection between multiple entities. Specifically, in a SaaS model, the Enterprise Security team is responsible for enforcing Authentication into the application, authorization controls across the data, logging and monitoring using capabilities provided by the SaaS partner. Application development security, testing and maintenance belong to the SaaS Partner while infrastructure security belongs to the IaaS provider. All of this is to say, the enterprise security teams that are responsible for the business-critical applications are not fully in control of mitigating cyber risk to the business.

So, how could we mitigate Cyber security related risk to business-critical application in a shared security responsibility model? Consider these four (4) best practices that can help enterprise security teams reduce the risk to their mission critical applications.

  1. Extend your security policies and standards: Your business SaaS applications are critical for the continued success of your business. Establish your business relationships with partners that prioritizes security and can prove it. Extending your organization's security policies and standards across to your partner's environment can ensure a similar, if not enhanced security posture. For this, Third Party Risk Management (TPRM) is ever becoming a requirement for SaaS engagements. While the TPRM program has a holistic view on partner risk management, an assessment that requires SaaS partners to demonstrate their current Security posture through third party validation/certification of their security practices is a required first step. Certifications like ISO 27001 & SOC2 can provide a glimpse into an organization’s established security practices. Continuous monitoring of the security posture through certification renewals and vendor security health through your Threat Intelligence team can ensure continuous compliance to your established Standards and Policies.
  2. Establish strong Authentication and Authorization for your tenancy: Take ownership of what you can control. Just because a partner provides the service does not mean you have to compromise on your Authentication and Authorization standards. Demand and deploy strong authentication for access to the application. Single-Sign-On (SSO) allows integration with your existing user base, introduces MFA, and allows group-based permissions that limit unwanted user access to the platform. Validating group-access permissions on a consistent cadence will further prevent unapproved attempts and mitigates un-authorized access by users that are no-longer part of the organization. User Authorization to the application is also an important consideration. The ability to deploy role-based privileges for application management and hosted data must be part of the due diligence process.
  3. Require Reliability & Resiliency: Mission critical applications have near-zero downtime expectations, whatever the reason. Assess and take advantage of partner provided capabilities that could mitigate reliability impact to the application. Enabling defensive capabilities that could address Distributed Denial of Service (DDoS) attack or prevent Account Takeover (ATO) are concrete steps towards ensuring application reliability. Requiring high-availability, failover and regional separation of their hosting environment are fundamental in ensuring reliability. Make sure disaster recovery related policies and standards are extended to the cloud and align with the RPO/RTO requirements of your business needs. Keep in mind, SaaS partners can and will recover the infrastructure and their application in the event of a disaster, but data and configurations are your responsibility. Finally, help your business teams understand and sign off on the reliability and resiliency metrics for their application, while encouraging them to develop and test a crisis management plan in the event of a unexpected incident.
  4. Ensure continuous monitoring: Logging, monitoring, and alerting must be part of the overall risk mitigation plan. Applications must be able to log authentication and authorization events, including any API related activities. These events must be logged and continuously monitored for anomalies. While this does not provide comprehensive insights into the infrastructure and application events, it should provide early warning related to any impact on your tenancy. Further, documenting and socializing a response plan with your SOC and integrating it with your enterprise IR plans would allow timely detection and response in the event of an incident. The goal is to detect early, initiate response and in a worst-case scenario, recover fast to minimize impact to your business rhythm.

The industry is coalescing around the SaaS consumption model. It is a $195B space, has grown by 500% over the past seven years and within the next few years, 85% of the software that organizations use will be delivered SaaS. Responsibility for securing the SaaS infrastructure is shared amongst multiple teams with varying security goals, following distinct policies and standards. But it is possible to mitigate business risks in this shared security responsibility by adopting security best practices and requiring your SaaS partners to support your journey.

Are you ready ?

Dylan Owen, CISSP-ISSEP-ISSMP GNFA GCFA

CISO @Nightwing. Opinions are my own.

8 个月

Thanks for sharing!! Great post!

回复

要查看或添加评论,请登录

Alex J. Attumalil的更多文章

社区洞察

其他会员也浏览了