A Shift Left Approach for Enterprise Security Architecture

[kmithilesh]

Are you planning for a Shift Left approach for your security architecture?

This document provides practical guidance on “Shift Left”, its approach and applicability  towards enterprise wide security architecture and governance, covering both the corporate and product lifecycle. In this document we will talk about the Common Architecture Criteria (CAC) as a framework to apply at the architecture, design, and implementation layers such that Shift Left helps drive a concise and consistent approach across onboarding third-party applications or developing and deploying internal applications early on throughout the lifecycle that provides multiple benefits such as architecture optimization, operational efficiency,  faster delivery, and more.

Shift Left principle:

The Shift Left principle advocates identifying and shifting tasks as early as possible into the lifecycle, which in turn helps for better planning and execution translating into better quality and workflow optimizations. The workflow types can vary, including business workflow, security workflow, product development workflow, and many more. While the Shift Left approach was initially used for testing in product development, over time it's also been used to improve enterprise level security architecture and governance for the corporation, along with development and deployments.

A Shift Left approach for enterprise security architecture:

A Shift Left approach for enterprise security architecture focuses on creating a security architecture framework by identifying, planning, implementing, and governing enterprise-wide security, covering corporate security, supply chain security, and product and service security throughout development, deployment, and lifecycle management. 

A fast-growing technology company like Netskope is solving security challenges faced by customers across different cloud and hybrid services, as well as safeguarding its own multi-vendor technology stack to run the Netskope organization. Shift Left has been a constant approach used here for planning, evaluation and execution of our enterprise level security architecture tasks. 

At Netskope, due to ever growing demands of features and capabilities across product portfolio, there will always be a need to quickly deliver solutions to a customer. This brings many quick fix solutions to the table and when the customer needs to scale with their growth, the sustainability gets tough, which in turn requires additional resources and time. This is when a standard Shift Left approach at the architecture layer helps us streamline and improve quality and consistency with scale at enterprise level.

A practical Shift Left approach at the architecture layer is defined in the form of Common Architecture Criteria (CAC), which helps improve enterprise-wide architecture, including security for developing, deploying and maintaining company-wide processes, standards, products, or services.

The CAC (Common Architecture Criteria) framework, is a collection of architecture controls logically segmented across multiple domains and blueprint for better governance. Each domain has multiple blueprints and each blueprint has multiple CAC requirements. The CAC framework helps assess architecture including security across the board that help design, develop, implement and maintain security architecture across the company, resulting in optimized and consistent security across the company.  

A CAC architecture framework enables both Netskope Corporation and Products / Services towards a common reference architecture to seamlessly integrate native as well as 3rd party applications. It is,

1. a documented standards, process, guideline and governance for both corp and product
2. a documented validate and artifact based Secure SDLC governance process.
3. a documented policy for onboarding 3rd party applications or vendors.

A CAC framework divides architecture into multiple relevant domains such as,

1. Security and Privacy Domain
2. Management Domain  
3. Traffic Domain
4. Infrastructure Domain  
5. Vendor Integration Domain
6. Deployment and Operation Domain  

A CAC framework further divides each domain into multiple relevant blueprints such as, 

A security and Privacy domain contains the following blueprints.

1. Encryption Security Blueprint
2. Authentication, Authorization and Access control Security Security Blueprint
3. Certificate and Key Management Security Blueprint
4. Web and API Security Blueprint
5. Firewall and Hardening Security Blueprint
6. Security Log Management Security Blueprint
7. Privacy and Data Protection Security Blueprint

 A CAC framework further divides each blueprint into multiple relevant controls such as, Encryption Security Blueprint contains the following controls,

1. CAC-SECURITY-ENCRYPT-110.00: In transit Encryption must use TLS v1.2 or higher
2. CAC-SECURITY-ENCRYPT-120.00: In transit Encryption must only use recommended Cipher Suites with TLS
3. CAC-SECURITY-ENCRYPT-130.00: In transit Encryption should use Mutual TLS for identity certificate validation
4. CAC-SECURITY-ENCRYPT-140.00: At rest Encryption must use FIPS-approved cryptographic algorithm to protect electronic data
5. CAC-SECURITY-ENCRYPT-150.00: At rest one way encryption (aka Hashing) must use SHA 2 or higher
6. CAC-SECURITY-ENCRYPT-160.00: At-rest encryption must store encryption key securely
7. CAC-SECURITY-ENCRYPT-170.00: At-rest encryption must use Anonymisation or Pseudo Anonymisation for data masking
8. CAC-SECURITY-ENCRYPT-180.00: At-rest encryption must NOT store any sensitive information in plain text
9. CAC-SECURITY-ENCRYPT-190.00: At-rest encryption must NOT display any sensitive information in plain text

An Encryption Security CAC Control for "In transit Encryption must use TLS v1.2 or higher" may look like,

Have you already implemented the Shift Left approach or planning about the same? Let us know about your journey or thoughts on applying a shift left approach towards security?