Check Point Enterprise Security Framework Version 2

Published by the Check Point Strategic Consulting Group

March 2023

©2023 Check Point Software Technologies Ltd. All rights reserved | P. 1

Synopsis
This document details how the Check Point Enterprise Security Framework Version 2 can be used and includes
scope, audience, and methodology. The paper is public and intended for cyber security leaders, architects,
engineers, and stakeholders. No prior knowledge is required other than familiarization with the related
documentation.

Author(s) JP Edwards, Enterprise Security Architect

Contributors Check Point Enterprise Security Architecture Team

Status: Published
Date Status Author Comments
30/01/2023 Release JP Edwards Version 7.1

Related Documentation
Section Title
CESF https://www.checkpoint.com/support-services/security-workshop/

©2023 Check Point Software Technologies Ltd. All rights reserved | P. 2

Contents
Synopsis .........................................................................................................................................................................2
Status: Published ...........................................................................................................................................................2
Related Documentation.................................................................................................................................................2
Executive Brief ...............................................................................................................................................................4
What's New ...................................................................................................................................................................4
Introducing CESF Version 2 ............................................................................................................................................6
Key Drivers .....................................................................................................................................................................6
Operational Model ........................................................................................................................................................9
Advisory, Assessments, and Architecture ....................................................................................................................11
CESFv2 Layers ..............................................................................................................................................................14
Introduction to Layers .................................................................................................................................................14
The Core CESFv2 Layer ................................................................................................................................................15
Contextual Layers ........................................................................................................................................................16
The Governance Contextual Layer...............................................................................................................................17
The Architect and Operational Contextual Layer ........................................................................................................17
The Assessment Contextual Layer ...............................................................................................................................18
The Assessment Layer: Deep Dive ...............................................................................................................................20
Running Assessments Using CESFv2 ............................................................................................................................20
Cyber Security RISK Assessment ..................................................................................................................................21
NIST & CIS Assessments ...............................................................................................................................................22
CESF Assessments ........................................................................................................................................................23
Zero Trust Maturity Assessments (CISA) .....................................................................................................................24
Zero Trust Architecture Using CISv8 ............................................................................................................................25
Data Visualization for Zero Trust Assessments ............................................................................................................26
The Architect and Operational Layer: Deep Dive ........................................................................................................27
Network Diagrams .......................................................................................................................................................28
Framework Design .......................................................................................................................................................29
Framework Section Explained .....................................................................................................................................30
Finished Framework Example ......................................................................................................................................32
Conclusion ...................................................................................................................................................................33
Appendix: CESFv2 and Other Frameworks ..................................................................................................................34

©2023 Check Point Software Technologies Ltd. All rights reserved | P. 3

Executive Brief
Following the release of our first Check Point Enterprise Security Framework in 2019 and its widespread adoption
throughout our architectural and engineering communities, constructive feedback has enabled us to compile a
new and improved version. This version addresses the changing architectural landscape and aligns with a risk-
based consultative approach to cyber security. Please note that the following paper supplements the Check Point
Enterprise Architecture whitepaper.1
Our first CESF version was based on a process-led concept for security architecture development. In our latest
version (CESFv2), we have introduced a governance and risk-led approach, which reflects the requirement to align
architecture with impact, threat, and vulnerability analysis.

"As a framework, CESFv2 uses

qualitative analysis and a cross-
functional approach to improve the
efficiency and effectiveness of cyber
security recommendations
and advice."

CESFv2 focuses on updates in the following

core areas:
Leadership: CESFv2 includes features designed
to support the C-suite in making more effective
and efficient cyber security decisions and
managing cyber security risks.
Risk-focus: CESFv2 supports using multiple
assessment frameworks, such as NIST CSF, for
control-based compliance and risk assessments.
Governance: CESFv2 has a built-in method to build governance and policy frameworks.
Strategic advisory and consulting: CESFv2 is cross-functional and supports the development of cyber security
strategies delivered through the advisory and consulting approach.
Operations: CESFv2 defines operational roles, responsibilities, and the development of target operating models.
Delivery: The core delivery vehicle for CESFv2 is the security workshop, explicitly designed to focus on strategic
cyber security discussions and cyber security risks.

What's New
Academic work, including cyber security frameworks, evolve the more they are tested in the real world. The CESF
process is no different. Since its conception, the original framework has been continuously tested in live

1
https://www.checkpoint.com/downloads/products/checkpoint-enterprise-security-framework-whitepaper.pdf1.

©2023 Check Point Software Technologies Ltd. All rights reserved | P. 4

environments. Based on data collected from real world use of our framework, we’ve been able to make
improvements designed to provide enhanced support to our customers' leadership, architects, engineers, and
operational teams.
We hope the enhancements have resulted in a more efficient and effective enterprise security framework. One
that is agnostic at the point of use, more adaptable in its applications, more effective in delivering enterprise
security architecture, and has a broader appeal and audience.

Below is a high-level list of the significant new components and their focus. We’ve worked hard to ensure that
CESFv2 reflects the need within organizations to work in a cross-functional manner whereby multiple teams are
stakeholders in the overall security posture, which is why each feature maps to a relevant audience.

Audience New Features

Strategic Consulting and Advisory / CISO Services
Leadership Zero Trust Advisory
Enhanced Cloud Transformation

Cyber Security Risk Management and Consulting

SABSA-Based Enterprise and Solutions Architecture

NIST 1800-35 Zero Trust Architecture
Architecture
Check Point & CISA Zero Trust Architecture
Automation and DevOps Code-Level Consultancy
NIST CSF Assessment
CISv8 IG1,2,3 Assessments
NIST 800-53 and RISK Management Frameworks
Governance,
Risk, and NIST 800-82R2 - Industrial Control Systems (ICS) Security
Compliance
CISA Zero Trust Maturity Assessment
MITRE Attack Modelling and Reverse Attack Mapping Using CIS-to-MITRE
CCM Assessment (or cloud security assessments)
Operations Target Operating Models (TOM) and Operational Architecture

©2023 Check Point Software Technologies Ltd. All rights reserved | P. 5

Introducing CESF Version 2
The original CESF fulfilled the role of supporting architects engaged in cyber security architecture. In CESFv2, we
broadened the scope by including support for GRC and cyber security leaders with services and features, such as
cyber risk and control-based assessments.
The goal is to increase the effectiveness of the overall CESF process through a better understanding of the people,
processes, and technology that make up our clients' security capability. In addition, we hope to deliver more
informed advice and recommendations by increasing our knowledge of these components.
"The core new attributes for CESFv2
are the use of focused information
gathering through RISK and CONTROL-
BASED ASSESSMENTS, and the
introduction of layered contextual
information designed to support a
cross-functional CYBER SECURITY
STRATEGY."

This framework aims to empower the

enterprise’s cyber security
conversation by applying the lens of
governance frameworks, such as NIST
CIS, combined with industry-standard
risk assessments the output of which
will support decision-makers looking to
deliver real world solutions for real
Fig: The
world risks. complete
CESFv2
We maintain that a solid understanding process
of cyber security risk is a powerful
vehicle to affect change, ultimately leading to a more robust cyber security posture.

We hope that through this paper, the audience will understand how and why to apply the CESFv2 process and how
the framework can support improvements and change.

Key Drivers
We’re proud to present the following new feature benefits:

• Improved communication: The language of risk is universally understood inside and outside of cyber
security; using this commonality enhances our communication with C-suite and governance teams. In our
experience, risk-based conversations reach a wider audience than those focused only on technology.

• Business-focused approach: Building a successful cyber security strategy today starts with a firm
understanding of the business impact and cyber security risk before technology. CESFv2 focuses on
understanding these core business concerns better so that decision-makers can make more informed and
effective technology/product choices.

©2023 Check Point Software Technologies Ltd. All rights reserved | P. 6

 • Top-down process: All architecture, including enterprise security architecture, must follow a process,
which is why CESFv2 has, at its core, a clearly defined top-down approach. The process starts with senior
stakeholders but will capture the goals and requirements at multiple levels – each of which has an
essential voice in the cyber security conversation. A significant influence on CESFv2 is the SABSA
framework2 , which we have heavily adapted to reflect our intended use. The table below shows the
various layers of the cyber security conversation and there relevant discissions

The Cyber Security Conversation

Business View Contextual Discussion
Architect View Conceptual Discussion
Engineer View Logical Discussion
Builder View Physical Discussion
Operations View Security Services Management Discussion

• Strategic engagement plan: Good planning improves outcomes, which is why we’ve integrated the
concept of SABSA layers into our CESFv2 process and aligned these with different stakeholders. We’ll
explore this alignment in detail through this paper; however, for now, we invite the reader to
acknowledge the alignment and recognize its influence on our cross-functional methodology in which
each organizational role is represented.

Why
View SABSA Layer What (assets) How (process) Who (roles)
(motivation)

Business Goals, CIO, CISO,

Business Risks Risk
Business Contextual Processes, and Security
and Impact Assessment
Objectives Officers
Business Gaps, Current Security
Security
Architect Conceptual Knowledge and State, Maturity, Framework and
Architects
Risk Strategy and Architecture Modelling

Informational Security
Engineer Logical Security Policies Security Design
Assets Experts

Security Design Security Security

Builder Physical Security Policies
and Architecture Technologies Engineering

Security Operations
Operations Management Security Assets Security Posture
Operations and Analysts

• Assessment and RISK focus: CESFv2 makes significant use of public control libraries such as NIST and CIS
alongside industry-established cyber risk assessment practices. When combined with a solid

2
https://sabsa.org/sabsa-executive-summary/

©2023 Check Point Software Technologies Ltd. All rights reserved | P. 7

 understanding of cyber security architecture and practical knowledge of implementation, the result is
often a powerful tool to reduce overall risk and support the overall cyber security strategy.

• Cross-functional capability: Cyber security is a shared responsibility in any organization. The lines
between those who are accountable, responsible, consulted and informed on cyber security decisions is
often complex, which is why CESFv2 is designed so that different teams can interact with the overarching
process in the most appropriate format. The example below shows how roles and responsibilities are
aligned to various stages in the CESFv2 process.

Audience
Assessors and
GRC and C-suite Architects Operational
Auditors
GRC teams and those Enterprise, solution, Ops and incident Teams looking to
leadership functions and technical teams developing perform control-
that are looking to architecture teams workflow and based assessments
use the CESFv2 to looking to follow a processes for based on known
help develop SABSA-based process changes and libraries such as NIST
Governance models. for security incident handling. or CISv8.
architecture.

©2023 Check Point Software Technologies Ltd. All rights reserved | P. 8

Operational Model
In the previous section, we highlighted the influence of the SABSA framework on the development of both CESF
and CESFv2. In this section, we introduce the mapping of these layers to the CESFv2 layers of assess, architect,
design, deliver, and manage. The design decision behind the layered approach is to make the CESFv2 framework
cross-functional in its application, meaning, the framework must allow different teams, both customer and Check
Point, to complete different activities at different layers of an overall top-down process.
In order for the framework to be followed correctly it must start with some type of assessment and analysis.
This ensures a solid dataset that acts as a foundation from which the correct architecture and cyber security
decisions are drawn. The top-down approach doesn’t work if the first layer is omitted.
The table below shows how the various CESF core layers are mapped to a defined process and the relevant
stakeholders.

CESFv2 SMB / Delivery

View Activity Customer Enterprise
Layer SME Vehicle
Business Goals,
Security
CISO / CIO /
Business Assess Assessment, Zero
Directors Regional Global
Trust Maturity,
Cyber Risk Analysis Architect Enterprise
/ Security Architects /
Gap Analysis, Engineers Field CISO Security
Security
Architect Architect Architecture and Workshop
Architects
CIS Review

High-Level Design, Lead

Target Architecture, Engineers Security Security
Engineer Design
Technology / and Design Engineers Engineers
Products Mapping Team

Low-Level Design
Builder Deliver Implementati
and Configuration
on Engineers Professional Services
Security
Incident Response and Services
Operations Account Management
Operations Manage Security Services and SOC
Teams

©2023 Check Point Software Technologies Ltd. All rights reserved | P. 9

Security Workshops
The quality of the data collected through the CESFv2 process is essential, which is why, where possible, we always
try and make sure the program includes some face-to-face workshop elements. These encourage an open-forum
debate and collaboration. While each engagement is different and designed around clients' requirements, there
are some general workshop focuses depending on where we are in the overall process.
The workshop will take a different form depending on the CESFv2 phase, as described in the table below.

CESFv2 Phase Workshop Focus

Business risk-based discussion with CIO/CISO, interview and evidence gathering, business
Assess impact, vulnerabilities, likelihood of a significant cyber event, threats, attack profiles,
compliance, governance, risk.
Whiteboard, conceptual discussion, controls gap analysis, design review, target and desired
Architect
state, Zero Trust design principles, enterprise security architecture, mitigation.
Product and component presentations and design focus, Zero Trust components, solutions
Design
architecture, HLD.
Deliver Configuration and implementation discussions, technical architecture, LLD.
Manage Incident response, operational management, operating models, MDR, PS.

We would also like to draw attention to the general chronology of engagements to highlight that the workshops’
primarily focus on data gathering instead of presenting solutions. Doing so allows for the correct level of detail to
be collected and for analysis to be done post-workshop.

©2023 Check Point Software Technologies Ltd. All rights reserved | P. 10

Advisory, Assessments, and Architecture
Context helps, which is why we have included a section explaining who, where, and how the framework was
developed and some of the supporting components derived from its use. Currently, the CESFv2 framework is used
throughout the Check Point community, where a process is required to design, deliver, and support cyber security
solutions and leadership. It is owned and maintained by the Check Point Enterprise Security group, for whom it
represents the foundational guidance for all our work.
The Check Point Strategic Consulting group has made conscious improvements to the framework since its initial
conception. We remain committed to ensuring the framework remains a high-level conceptual framework that
can be interpreted and applied in multiple different scenarios depending on need, and that it acts as a
foundation for other more technical or lower-level models.
Our consulting approach is driven by three CESF pillars: Assessment, Architecture, and Advisory. Each can be used
in the CESFv2 process to help communicate concepts to customers, explain processes and methodologies, and
ensure traceability and accountability. More information about these services can be found at
https://www.checkpoint.com/support-services/security-consulting/.

The 3 “A” of “The goal of strategic consulting is to perform

Check Point
strategic advisory, assessment, and architectural work for,
consulting
and on behalf, of our customers. We advise on all
matters relating to cyber security, making
assessments of the current security state and
architecture to address gaps and improve overall
posture.”

While CESFv2 defines the methodology and principles used to help achieve certain cyber security goals, we also
maintain that the process can effectively link leadership, architectural, and engineering teams in a common
understanding of the “as-is” and “to-be.” cyber security architecture In other words, using the features contained
in the CESFv2 framework, architects, consultants, and advisors are better able to "glue" customer and business
requirements to technology choices and thereby improve the efficiency and effectiveness of the cyber security
program.

©2023 Check Point Software Technologies Ltd. All rights reserved | P. 11

 Fig: CESFv2 providing the linkage between business objectives and technology choices

In creating CESFv2, we wanted to increase the overall value that could be derived from following our process and
therefore explored how different presentations and visualizations could complement the outcome. Since we’re
confident the new process will deliver better data inputs and outputs, we wanted to explore new ways to present
the data.
Some of these new visualizations are described here:
Cyber Security SWOT
analysis: We borrowed the
SWOT (strengths,
weaknesses, opportunities,
and threats) analysis
format and applied it to
our work in cyber security.
This visualization presents
the internal and external
issues identified as part of
the assessment alongside
our recommendations in a
single view. It’s a powerful
single-page view we often
use as part of an executive
summary.

©2023 Check Point Software Technologies Ltd. All rights reserved | P. 12

 Radar and priority
graphs: The standard
radar graph is a familiar
tool used to show gaps
identified as part of an
assessment. We’ve
compiled these graphs
with other elements to
add a priory rating linked
to the complexity and
return-on-investment
analysis done as part of
our engagement.

Fig: Example radar graph showing GAP analysis and priority weighting

Risk heat maps: A risk heat map is a powerful visualization

tool used with Enterprise Risk Management. Also known as
a risk heat chart or risk matrix, it shows risk likelihood on
the horizontal axis (X) and risk impact on the vertical axis
(Y). We incorporate this view into our risk assessment work
and show how various data points will move once the
recommended treatment is actioned.

CISO dashboards: How data is presented is very important when communicating across various teams within a
specific organization. We’ve therefore defined several presentations explicitly designed for different audiences.
The table below shows how we construct these views. It’s an example of a C-level Zero Trust dashboard showing
the overall maturity score and various data representations.

©2023 Check Point Software Technologies Ltd. All rights reserved | P. 13

 Fig: Zero Trust executive dashboard example

Security roadmaps: Planning

technology adoption can be complex
and, based on our work in the field, is
a much-needed and requested
component of any cyber security
advice. To this end, we now ensure
that GANTT-style charts are included in
our reports when requested.
Plans, such as the one shown here, can
be extremely useful when planning
transformation exercises or adopting
complex architectural changes such as
Zero Trust adoption, whereby
activities must be scheduled correctly.
Now that we’ve established the context and how CESFv2 is centrally positioned within our community, we can
explore how it’s used to articulate architectural, operational, and leadership aspects of cyber security. In the next
section, we’ll unpack the new components of the framework and explore how these additional features are used
by us and our customers.

CESFv2 Layers
Even though our new framework evolved from the previous versions, the basic premise has not changed. There is
still a need for a defined and repeatable process that is easy to follow and guides us to deliver accountable and
traceable security architecture.

Introduction to Layers
The most significant change has been to append our previous version of CESF with new layers, which we did in
order to increase the effectiveness of the process by allowing the sub-process to be included. We call this sub-

©2023 Check Point Software Technologies Ltd. All rights reserved | P. 14

process a "contextual layer". Its primary function is to provide context to different teams and stakeholders, all of
whom play a role in the overarching enterprise security architecture.
The new layers are now described as follows:

Description Detail
Outer Ring, Refers to the core architectural process for which CESF was originally intended. The
Primary process starts with the ASSESS phase.
Function, Core
Inner Ring, This ring refers to a contextual process, or function, that exists in support of the
Contextual primary, or outer, process. The aim is for the addition of the context to support the
Layer, Support overall process by allowing various sub-processes to be included.
Function For example, "Plan" (as seen in the inner ring of the complete CESFv2 graphic) provides
context when dealing with assessment planning i.e. it is the first phase in the process of
starting an assessment.

The introduction of these additional layers has been driven by our knowledge that cyber security is an increasingly
cross-functional activity. Therefore, by engaging with multiple different teams throughout the process, the quality
of advice and recommendations significantly increases.

In the following section, we explore the components of each layer and describe how they were designed to work
and how they could be further adapted to suit bespoke requirements.

The Core CESFv2 Layer

The outer ring of the CESFv2 communicates to stakeholders each of the various phases or steps that must be
completed and the order in which they must be followed within an overall process. We draw the reader’s
attention to the fact that each step must be completed but in some cases some steps are imbued with greater
significance. For example, one engagement may require protracted control-based assessment before the
architectural work is completed, while other engagements may only require very lightweight data gathering.
• Assess: The first phase, in which business and
security drivers are captured, and audits and
assessments are completed. Depending on the
nature of the engagement, this can be a high-level
boardroom conversation or part of a workshop.
The outcome should be a clear understanding of
the target state. This core function maps directly
to the assessment layer (more on this later).

• Review: The review focuses on the current and

planned network and security architecture.
Typically, this phase is done using interactive
whiteboarding and a detailed design conversation.
The outcome is a clearly documented "as is" and
"to be" design.

©2023 Check Point Software Technologies Ltd. All rights reserved | P. 15

 • Design: The data captured is now used to inform a design that is aligned to Check Point's best practices.
The architecture team will draw on experience, product specialists, and industry best practices to mitigate
or remove the gaps which have been identified.

• Delivery: In this step, the system is physically built or deployed. It includes all operational testing,
documentation, and acceptance into the final environment.

• Manage: A vital component of any design is to have the lifecycle of the service understood and managed.
This is critical when defining the budget, and, also for making sure the solution performs its role as
required.

Contextual Layers
CESFv2 introduces the concept of "contextual layers" into the framework. This concept allows the framework to
appeal to various user groups and increases its scope and effectiveness. Depending on what you are looking to
achieve, you can use the framework in a different manner.

In some cases, the contextual layers are used independently from the core layers, such as in the table below:

Contextual Layer (adding additional information for specific audiences)

Audience (view) Governance Architect Operational Assessment

Major Influence Gartner CAPTA SABSA SABSA NIST/ CIS

Anticipate Enterprise Enterprise Plan

Prevent Solution Solution Interview

Contextual
Layer Protect Technical Technical Analyse

Respond Operations Operations Treatment

Now that we’ve established how the various layers are used, we will explore their function in more detail.

©2023 Check Point Software Technologies Ltd. All rights reserved | P. 16

The Governance Contextual Layer
This view is designed for architects looking to build
governance frameworks into the overall process. The rationale
here is to reflect on how organizations are looking to develop
frameworks that capture how a security function will be Respond Anticipate
performed and the rules by which it will be delivered. The
ethos is to describe the security function before it's
implemented in a way that is understood by all stakeholders.
For example, if there was a need to build a governance model
for cloud security, then the user would follow this layer and
start with defining what the security attributes for cloud
security are in the “anticipate” phase.
The phases are defined as:
Protect Prevent
• Anticipate: Anticipate needs and objectives, define
business goals, and align them to technology
deliverables. This part of the process is where we
capture what the business expects from the security
architecture and the security strategy.
• Prevent: Prevention through planning, architecture, threat profiling, cyber-risk analysis, best practices,
and the selection of correct cyber security products and services. In cloud-like environments, we predict a
reduction in the day-to-day operational management of systems and more focus on prevention through
architecture. This means that a properly designed system can use a policy crafted at the design phase
throughout its lifecycle with minimal production changes required.
• Protect: Delivery and management, or protection, through automation.
• Respond: Responding to breaches, security failures, and the evolving threat landscape.

The Architect and Operational Contextual Layer

This layer is used to describe the different architectural responsibilities that are typical design process, and
highlights the cross-functional nature of the CESFv2 process:

• Enterprise Security Architecture (ESA): This team bridges business and technology. They function as a
liaison between the C-suite and technology teams and are responsible for delivering justified solutions
and services.

©2023 Check Point Software Technologies Ltd. All rights reserved | P. 17

 • The ESA: Responsible for defining which problem needs
a solution and gathering the requirements from both
business and security stakeholders. Their key objective is Ops Enterprise
to ensure that all solutions meet clearly defined business
goals.

• Solution Architecture: This team's function is concerned

with converting requirements to design patterns that
can be passed to the technical design team. The solution
architect only deals with defined requirements and
would engage in feasibility design and lab testing.
Technical Solution
• The SA3: Responsible for translating the problem into a
solution and describing the building blocks that should
be used. This team deals with a known set of
requirements. They must work closely with the ESA to ensure the response matches the organization's
maturity, risk appetite, budget, and operational capabilities.

• Technical Architecture (TA): The TA delivers implementable design documents with a clearly defined
technology specification, including sizing and configuration. They have a strong understanding of
products, their roles, and their limitations.

• Ops: The role of this team is critical to the continued success of the architecture throughout its life cycle,
as all systems require an operational element. In this phase, the expectation is that processes are defined
and implemented alongside a collection of metrics and data to demonstrate the system's effectiveness.

The Assessment Contextual Layer

A core component of our new framework is a focus on using assessments to improve the overall 18 effectiveness
and architectural output of an engagement. This section looks at how we have integrated control libraries such as
NIST and CIS intergrade into the overall process.

• Plan: Our consultants plan assessments with GRC and other cyber risk professionals with support from
the client’s leadership. The assessments are designed to address cyber security gaps, map these to a risk
score and present the findings in risk language understood by a C-level and executive audience. Our
most common assessments are based on NIST CSF or CISv8.

3
https://www.gartner.com/en/information-technology/glossary/solution-architecture

©2023 Check Point Software Technologies Ltd. All rights reserved | P. 18

 • Collect: Cyber risk assessments are conducted through
interviews and observations with specific client teams. At
the clients' request, we can also leverage Check Point's
Treat Plan
considerable expertise in data capture to produce
detailed packet-level analysis.
• Analyse: Based on the dataset and controls from NIST and
CIS, we use a qualitative risk-based score process to grade
the controls and arrive at a cumulative risk and readiness
score. When requested, these scores can be presented in
classic '5x5' risk matrices or as part of a threat model.
• Treat: Once gaps and risks are identified, a risk register Collect
Analyse
and treatment plan are built detailing what actions (if any)
we recommend. Recommendations are aligned with the
CESF values of EFFECTIVENESS and EFFICIENCY, i.e. there
should be a clear and actionable treatment plan provided.
practical

Now that we have completed an overview of the various layers and the reader has an appreciation of their
function, we can explore the contextual layers in more detail. These layers represent the most significate new
component of CESFv2, which are the use of a formalized assessment process and the use of cross-functional teams
within architecture.

©2023 Check Point Software Technologies Ltd. All rights reserved | P. 19

The Assessment Layer: Deep Dive
The following section is a deeper dive into how assessments are run within the overall CESFv2 process. The table
below is a brief recap on how the CESFv2 core layers map to the contextual layer. The assessment layer is primary
connected to the “assess” component showing that any assessment work is always completed at the beginning of
an engagement and the output of the assessment is collected before we progress to the “architecture” layer of the
core framework.

CESFv2 Core Contextual Layer Description of Contextual

Description of Core Layer
Layer Mapping Layer
Assessment selection and planning,
Plan
In CESFv2, everything starts with understanding of threat groups.
some level of assessment. This can
The collection of data through an
be a total compliance/risk
Collect interview, questionnaire or technology
assessment or a more general
such as CSPM.
Assess conversation-led capture of current-
state architecture. The decision as to When dealing with control data, the
what approach to take is often analysis will build the GAP analysis.
guided by factors such as Analyse When dealing with risk assessment, the
compliance, effort and time. analysis will be based on the risk
calculations
The phase whereby gathered data is
Architect transformed into a meaningful
conceptual recommendations.
The concept is transformed into
Design & solutions that deliver on
Build recommendations and are
considered fit-for-purpose.
The practical step required to Treat The action taken based on the risk
develop a solution. Scale and register or the GAP analysis.
Deliver
complexity must be considered at
this phase.
Production management and
Manage
improvement of the solution.

Running Assessments Using CESFv2

Using common frameworks is extremely useful for multiple reasons, not least that they act as a standard
benchmark and that when completed there is a consistent report which can be generated on a yearly basis.
The main assessment frameworks are:
• Check Point Enterprise Security Framework security controls. The CESF frameworks
Assessment (CESF): This is a proprietary allow us to translate NIST CSF controls into
assessment used to evaluate the security real-world security solutions.
posture and understand the network
• NIST CSF v1.1: NIST provides security

©2023 Check Point Software Technologies Ltd. All rights reserved | P. 20

 architects with an audit program designed • NIST 800-53 rev5: This document defines
to help technical and non-technical security the standards and guidelines for federal
stakeholders to visualize gaps in the agencies to design and manage their
organization's existing security posture. information security systems.
• CIS Controls v7.1 & v8: The CIS • NIST SP 800-82r2: This document guides
Controls have internationally recognized how to secure Industrial Control Systems
cyber security best practices for defence (ICS).
against common threats. They are
• CISA Zero Trust Maturity Model: We assess
consensus-developed resources that bring
each pillar of the CISA model and rank the
together expert insight about cyber threats,
maturity, which, once combined with a
business technology, and security.
weighting score, allows us to calculate a
• Cyber Risk Assessment: Based on the Zero Trust maturity score.
industry accepted risk equation: risk =
• CIS Benchmarks: CIS Benchmarks are best
likelihood x vulnerability. Typically, the
practices for the secure configuration of a
assessment team will draw on information
target system.
from MITRE ATT&CK and in-house sources
to map the threat landscape to business • SOC-CMM: This framework is designed to
impact. deliver a continuous approach to measuring
technical capability across the technology
• SABSA: SABSA is a framework and
and services domains that are relevant to
methodology for enterprise security
SOC capability.
architecture and service management.

Each framework brings a different value depending on the domain under assessment. For example, SOC-CMM is
typically used to assess Secure Operations Centre capability. In contrast, NIST CSF will highlight gaps in overall
cyber security capability.

Cyber Security RISK Assessment

Our Cyber Risk Assessment aims to address the challenges of implementing aspects of an effective cyber risk
management strategy and propose recommendations that increase its efficiency. In addition, the program is
geared towards supporting C-level decision-makers using industry-standard RISK calculations and tools.
The identification and management of cyber risk are what cyber security leaders deal with daily. It’s the natural
evolution of any compliance-based assessment such as NIST of CIS. While we distinguish between the two
activities, there is a cross-over. For the sake of clarity, we define the activities that relate to Cyber Risk assessments
as those that include the following components which is different from a control-based assessment that is based
purely on measuring compliance with a known control library, such as NIST.

Cyber Security Risk Assessment

Assessment
Identity vulnerabilities Model threats Rank business impacts
Component
Measure readiness Assess countermeasures,
Define control outcome, perform
Activity (controls), test simulate attack groups and
qualitative and quantitative BIA
defences techniques
Outcome Reduce risk

Protected Financial Reputational / Operational

©2023 Check Point Software Technologies Ltd. All rights reserved | P. 21

Reducing risk using quantitative analysis is sometimes a challenge. However, for those responsible for minimizing
the financial impact of cyber security events, it’s a necessary calculation and a valuable tool in communicating risk.
The standard risk calculation we use is based on the following formula:
RISK (R) = LIKELIHOOD (L) x IMPACT (V)
• LIKELIHOOD: How likely is the attack to take place? What is the frequency we would expect to see this type of
attack?
• IMPACT: If the attack was to succeed, how much damage could it do? Most importantly, could it cause the
business to be impacted financially?

The example below is a 5x5 risk matrix produced as part of our RISK assessments. Based on the likelihood and
impact calculation above, it acts as an effective tool to communicate those risks that we consider to be outside of
acceptable thresholds and, therefore, pose a real risk to the business, both operationally and financially.

As cyber risk assessment is a core

component of a process-driven
architecture a dedicated publication will
be made available on our website
where we will deep dive into the threat
modelling components not detailed in
this paper.

Fig: 5x5 risk matrix example

NIST & CIS Assessments

To ensure our assessment work meets industry-standards or
where the client requests it, we will perform NIST and CISv8
assessments based purely on the published controls library.
Check Point often perform such assessments for organizations
looking for a third-party review of their posture and who
understand the value of using engineering and architectural
teams to add their point of view to the overall compliance
conversation.
This approach allows the Check Point team to engage using a
standard body of work and language that can be compared over
iterations of the same assessment framework.
Typically, our clients will request that we present assessment
findings in alignment with NIST in order for our work to be more
easily understood by Governance, Risk, and Compliance teams.
For example, this data visualization radar graph is a standard deliverable when performing NIST assessments.

©2023 Check Point Software Technologies Ltd. All rights reserved | P. 22

CESF Assessments
In some instances, it’s more appropriate to use a customized set of assessment controls that better reflect the
desired outcome. This flexible approach increases the assessment phase’s EFFICIENCY and EFFECTIVENESS as it
removes the structure prescribed by frameworks such as NIST. We call this style of assessment a “CESF
Assessment”. Some examples include:

Assessment Type Description

CESF ICS Assessment Set of 30 controls selected from NIST 800-82R2 that reflected the requirement to
secure the IT/OT perimeter.
CESF Assessment DC Set of 5 controls selected from CISv8 IG3 that best reflected the requirement to
Perimeter assess the perimeter security.

Once the appropriate assessment frameworks have been selected, there is an assessment design phase that allows
the frameworks (more specifically, the controls within the framework) to be edited to make them more relevant to
the audience. For example, if the scope were to assess and recommend a cloud architecture, then it would be
reasonable to use a section of controls from NIST CSF v1.1 such as:
"Control: PR.DS-5: Protections against data leaks are implemented."
This control could then be re-formatted in a manner that is more relevant to our advance, for example:

"CESF Control: Is the environment designed to restrict each container's access to shared resources so that
information cannot inadvertently be leaked from one container to another?"

The second control would then be placed alongside similar controls and presented as a questionnaire.
Another example would be where the assessment scope includes perimeter security, for which the assessment
designer can select controls such as this one from NIST 800-53:
"SC-7: Boundary Protection: Monitor and control communications at the external managed interfaces to the
system and key internal managed interfaces within the system."
Once the process of building a bespoke and targeted assessment is completed, the controls are published as a
questionnaire or hosted with our Cyber Security Assessment platform.

Control Controls Class Control Description Control Detail

ID
12.2 Boundary Scan for unauthorized Perform regular scans from outside each
Defence connections across trusted network boundary to detect any
trusted network unauthorized connections accessible across
boundaries. the boundary.
12.3 Boundary Deny communications Deny communications with known malicious
Defence with known malicious IP or unused Internet IP addresses and limit
addresses. access only to trusted and necessary IP
address ranges at each of the organization's
network boundaries.

©2023 Check Point Software Technologies Ltd. All rights reserved | P. 23

 12.4 Boundary Deny communication Deny communication over unauthorized TCP
Defence over unauthorized ports. or UDP ports or application traffic to ensure
that only authorized protocols are allowed to
cross the network boundary in or out of the
network at each of the organization’s
network boundaries.

Zero Trust Maturity Assessments (CISA)

Following the explosion of interest around Zero Trust and the work done by institutions such as Forrester, NIST and
CISA, the Check Point consulting team developed a Zero Trust Maturity Assessment. It was designed to measure
the "as-is" and "to-be" state of our customers' Zero Trust architecture and to use this information to help guide the
development of capabilities that will ultimately improve the overall Zero Trust Maturity score.
To arrive at such a value, we selected the CISA Zero Trust model as our baseline. We maintain that it offers the
most well-rounded and agnostic measure of maturity while remaining simple and consumable. The work done by
CISA was formatted into an assessment, an extract of which is shown below:

Fig: Extract taken from Check Point CISA Zero Trust Maturity Assessment

We have chosen not to delve into the assessment workings within this paper other than to highlight the following;
Zero Trust means different things to different audiences. Some organizations will focus on specific Zero Trust
principles above others; for example, a software application organization would most likely see Zero Trust in the
context of application security. This organization-specific focus should be reflected in the "weighting" we give to
the maturity score – it doesn't make sense to downgrade a maturity score if the control is irrelevant. We,
therefore, added a weighting capability to our assessment. While we’ll be able to fully explore the Zero Trust
maturity assessment in another paper, the weighting calculation we use is based on the table below:

Weighting Table for Zero Trust Maturity Assessments

Network-Centric Cloud-Centric Application-Centric
Data 10 30 30
Device 15 5 5
Identity 50 30 20
Network 20 5 5
Workloads 5 30 40
Total 100 100 100

©2023 Check Point Software Technologies Ltd. All rights reserved | P. 24

The concept behind weighting is that depending on the client's business activities, i.e., software development and
manufacturing, etc. the approach to achieving Zero Trust will change slightly. For example, a software
development company will focus on applying Zero Trust to workloads and containers and worry less about
network security. This concept is fully explained in a dedicated whitepaper 4.

Zero Trust Architecture Using CISv8

The requirement to benchmark capability for specific architectural alignments is becoming increasingly important
to organizations. Consequently, we’ve witnessed the CESFv2 framework being used to design and execute
readiness assessments, such as Zero Trust architectural maturity. Therefore, we’ve included an example of how an
organization that uses CIS controls as a standard can use these to align itself with Zero Trust architectural
principles.5
The example below is a bundle of controls selected to gather a dataset of information about a network
architecture which can then be used to generate a GAP analysis and report.
The process of designing such an assessment is as follows: firstly, the below CIS controls were selected because
they are typically more technical. We then chose a set of CISv8 controls aligned with the Zero Trust principles
displayed below. They reflected the client's appetite for change and security. This is also why some controls are
taken from CIS Group 1 and others from CIS Group 3.

Zero Trust Principle CIS v8 Controls CIS Group

Asset Management 1,2,11,15 1
Account Management 5,6 1
Device and Endpoint Security 7,9,10 1,2
Logging and Visibility 8,12,17,18 1
Communication Security 3,4 1
Dynamic Policy 16,13 1,2,3
A Zero Trust assessment design example
Once we collect the controls from the table above, we can build our assessment. The example below is part of this:

4
https://pages.checkpoint.com/the-ultimate-guide-to-zero-trust.html
5
https://www.cisecurity.org/insights/blog/prioritizing-a-zero-trust-journey-using-cis-controls-v8

©2023 Check Point Software Technologies Ltd. All rights reserved | P. 25

 Control Subject Control
ID
1 Perform automated Perform monthly (or more frequent) application updates
application patch on enterprise assets through automated patch
management. management.
2 Establish and maintain an Establish and support an audit log management process
audit log management that defines the enterprise's logging requirements. At a
process. minimum, address the collection, review, and retention of
audit logs for enterprise assets. Review and update
documentation annually or when significant enterprise
changes occur, which could impact this safeguard.
3 Collect audit logs. Collect audit logs. Ensure that logging, per the enterprise's
audit log management process, has been enabled across
enterprise assets.
4 Ensure adequate audit log Ensure that logging destinations maintain adequate
storage. storage to comply with the enterprise's audit log
management process.
5 Ensure network Ensure network infrastructure is kept up-to-date. Example
infrastructure is up-to-date. implementations include running the latest stable release
of software or using currently supported Network-as-a-
Service (NaaS) offerings. Review software versions
monthly (or more frequently) to verify software support.
Fig: Zero Trust network questionnaire example

The architect scores each control in the table, and the data is used to complete the GAP analysis of the assessment
type executed. This data visualization is core to effectively communicating where effort and spending is required.

Data Visualization for Zero Trust Assessments

This section's information is relevant to CISA, CIS, and other frameworks used to assess Zero Trust.
Once the assessor has completed their analysis and the dataset has been collected and analysed, it’s typically
presented as a GAP analysis whereby the current and target state is presented. In the case of Zero Trust being able
to benchmark the various pillars of capability against a known standards for compliance allows the customer a
view on where effort and spending are required. The example below is taken from a Zero Trust maturity
assessment:

©2023 Check Point Software Technologies Ltd. All rights reserved | P. 26

 Fig: Data visualization is a core component of all assessment output

The Architect and Operational Layer: Deep Dive

This section looks in more detail at the architects' contextual view that is shown within CESFv2. This layer is
designed to closely support the core layer by describing how different architectural capabilities are leveraged as
we move through a design cycle. Good architecture requires input from multiple teams at various points in the
process.
As discussed in the previous section, CESFv2 defines three different architectural functions. These are:

Title Focus Competencies

Collecting defining requirements and mapping GAP analysis, RISK

Enterprise Security Architect
business requirements to technology choices. assessments.

Mapping requirements to technology and

Solution design in
Security Solutions Architect defining solutions, and ensuring components are
HLD format.
selected correctly.

Low-level configuration design and detailed

Solution design in LLD
Technical Security Architect technical knowledge to confirm the chosen
format.
technology delivers requirements.

When each function is supportive and complimentary of the others, it means there is no architectural hierarchy
but rather a symbiotic interaction of different disciplines. When done correctly, each step in the process will be
represented by the most appropriate stakeholder and their counterpart within the architecture team (assuming all
three architectural functions are represented):

©2023 Check Point Software Technologies Ltd. All rights reserved | P. 27

 CESFv2 Contextual
Architectural
Core Description of Core Layer Layer
Responsibility
Layer Mapping
In CESFv2, everything starts with some level of assessment. This
can be a total compliance/risk assessment or a more general Enterprise
Assess conversation-led capture of current-state architecture. The Enterprise Security
decision as to what approach to take is often guided by factors Architect
such as compliance, effort, and time.
Enterprise
The phase whereby data gathered is transformed into a Enterprise and Solutions
Architect
meaningful convert or recommendation. / Solution Security
Architect
Design & The concept is transformed into solutions that deliver on Solutions
Solution
Build recommendations and are considered fit-for-purpose. Architect
The practical step required to develop a solution, scale and Technical
Deliver Technical
complexity must be considered at this phase. Architect
Manage Production management and improvement of the solution. Ops Operations

By leveraging multiple different architectural disciplines, we can better support the development of quality
architectural patterns and plans. Two critical deliverables from any architectural engagement should be a cyber
security roadmap that defines the logical steps required to achieve the desired goal and a conceptual/HLD diagram
that logically positions the security components into the broader ecosystem.

Network Diagrams
As discussed, a core deliverable of CESFv2 is to arrive at an actionable set of recommendations. More often than
not, this is done through the production of conceptual architecture diagrams such as the example shown below.

Fig: Network topology produced as part of the CESFv2 process and workshop

©2023 Check Point Software Technologies Ltd. All rights reserved | P. 28

Building Governance Frameworks with CESFv2
The importance of a well-defined governance framework cannot be overlooked in an established cyber security
strategy, which is why we have included this section, which describes how CESFv2 can be used practically to deliver
a cyber security governance framework.
Before we start, we should define what a governance framework is and why we believe it to be important. For this,
we reference the UK National Cyber Security Centre.
"A governance framework is vital to coordinate and direct the management of the service. An effective governance
framework will ensure that procedural, personnel, physical and technical controls continue to work through the
lifetime of service. It should also respond to changes in the service, technological developments, and the
appearance of new threats."6
Based on this definition, we can start to adapt CESFv2 appropriately and use the adapted mode to build our
governance framework.

Once completed, our framework will help conceptualize the link between security strategy, architecture, and
functional security controls, and streamline communication from the boardroom to security engineers through a
commonly understood framework.

Framework Design
In order to proceed, we first acknowledge that the original CESFv2 process needs to be re-formatted because a
governance framework is not a process. We call this new format the "framework mode" so that there is a clear
distinction between the CESFv2 process and the CESFv2 framework. It’s important to note that the following
framework is only one interpretation based on our use case. If required, the framework can be mapped to other,
more suitable functions.
Moving into the framework mode requires a restructuring of the CESFv2 layout and a redefinition of the process.
The mapping is shown below:

6
https://www.ncsc.gov.uk/collection/cloud/the-cloud-security-principles/principle-4-governance-framework

©2023 Check Point Software Technologies Ltd. All rights reserved | P. 29

 CESF Layers CESFv2 Framework Mode Description

Assess Anticipate security requirements and

Anticipate
deliverables
Architect

Prevent loss (financial or Operational)

Design Prevent
events through architecture
Detect threats and continuously
Delivery Detect
improve and develop the system
Observe and respond based on threat
Manage Respond
intelligence
Fig: CESF governance mode and CESF layers

Once the concept of roles and layers is translated into the framework mode, we can apply our governance
terminology and language to the new pillars, or, "anticipate, prevent, detect, respond". The critical design point is
to define the roles of each pillar clearly, and they must document the goals of the governance model. In simple
terms, an effective governance model clearly articulates the organization's goals, the key personnel and their
responsibilities, and the tools they will use to achieve the strategic objectives.
A representation is shown below and should be used as a template for the following section, which involves
populating the framework, starting with the "Anticipate" phase.

Fig: Using CESFv2 in framework mode

Framework Section Explained

The table below defines the roles for each position in the framework process. It allows the practitioner to fill in the
gaps in order to build the framework. At this stage, it's important to note that the elements entered into the
framework should be measurable in some form; doing so will increase the effectiveness of the final framework and
allow maturity to be tracked . For example, if we define the adoption of a certain technology in the “Protect”
element then we should also define at what point we expect this technology element to be completely deployed.

©2023 Check Point Software Technologies Ltd. All rights reserved | P. 30

Framework
Description Example Key Stakeholder
Mode
Anticipating what cyber security
posture the organization needs to Remote workforces
adopt in order to meet business require a secure Zero CISO and leadership
Anticipate objectives and define a strategy. Trust-aligned security need to anticipate and
model that is not document the strategy.
Defining business goals and aligning reliant on legacy DCs.
them to technology deliverables.
Prevent security failure by developing a
policy that describes which process and
technology are used and by whom, Hybrid SASE principles
which is documented within a for user traffic.
governance policy that includes a
service catalogue.
Create a single security
policy for all users. Enterprise Architects
Prevent Prevention through planning, and GRC teams.
architecture, threat profiling, cyber-risk
analysis, best practices, and selecting Fully automate the
the correct cyber security products and onboarding of users'
services. API and cloud-native-
only components.
Should detail functional and non-
functional controls.
Protect all assets by deploying and
managing the security policy and
posture and providing a proportional
response following the operational Follow Zero Trust's “log
process. This includes monitoring, everything” principle.
maintenance, and asset lifecycle Engineers,
Detect management. implementation and
Leverage observability. operational teams.
Delivery and management, or
protection, through automation and API-only change policy.
detection of changes in the posture of
the environment, network, and
workload.
Responding to events in a manner that
can be adapted so that continuous
improvement can be made to the
overall security posture.
XDR and threat
Responding to changes in the threat hunting.
landscape, offensive capabilities, and Incident responses and
Respond cyber operation teams.
aggressor motivation to continuously Ingression to dynamic
update the security strategy. threat intelligence.

Responding to breaches, security

failures, and the evolving threat
landscape.

©2023 Check Point Software Technologies Ltd. All rights reserved | P. 31

Finished Framework Example
While the development of frameworks to assist in solution delivery is customized to each organization, we have
included the following example to illustrate how we designed a framework using CESFv2 components.
This example is taken from an organization adopting SASE architectural principles. Each section has been carefully
completed to contain only those components which are of value to the organization. In productivity teams, the
framework acts as a map for their SASE adoption.

Fig: Governance framework for SASE adoption example

©2023 Check Point Software Technologies Ltd. All rights reserved | P. 32

Conclusion
The Check Point enterprise architectural process continues to develop and reflect our experience with customers,
combined with our desire to help organizations manage their cyber risk through architecture.

In summary, this paper has:

• Explained the update to the Check Point Enterprise Framework.

• Introduced the concept of context so that the framework is relevant to a broader audience, namely C-
level and assessors.
• Detailed how the CESFv2 puts assessment as a core component of successful architecture.
• Shown how CESFv2 can be used to develop governance frameworks.
• Given examples of assessment and framework development using CESFv2.

This paper is written for the community, and we hope that it is of use for the betterment of security architecture in
general. For more information, please see https://www.checkpoint.com/support-services/security-consulting/.

©2023 Check Point Software Technologies Ltd. All rights reserved | P. 33

Appendix: CESFv2 and Other Frameworks
As with most architectural artifacts, there is, and should always
be, influence from other bodies of work. In some senses being
able to link multiple influences and sources add to CESFv2s
overall credibility and allows the user to apply context to the
process.
One of the key reference points in the development of the
CESFv2 approach is the work done by Gartner within their
CARTA approach. The original CESF framework design
methodology was heavily influenced by SABSA, while for
CESFv2, this influence is drawn from Gartner's ever-evolving
Continuous Adaptive Risk and Trust Assessment (CARTA) model, as shown here.
In simple terms, Gartner's CARTA framework has influenced our thinking in relation to both the CESFv2 core
architectural principles and the CESF Framework Mode. These include:
• Forward-thinking: The CARTA model acknowledges that automation is a key requirement and that
security should look to automation first and people second when it comes to responding to threats.
• Continuous improvements and development: This is aligned with cloud best practice principles and
enables a feedback loop between architects and operations.
• Chaining: Refers to the use of multiple solutions, technologies and products aligned across different
disciplines while working symbiotically. In such a framework, each part of the system contributes to the
overall security posture.
The following mappings between CESFv2 to other frameworks are offered as examples of the flexibility designed
into the CESFv2 framework:

Framework/ Attribute Attribute Description CESFv2 CESFv2 Ring

Model Mapping
Gartner Continuous Continuous cyber security Anticipate, Contextual
CARTA improvement assessments are key to moving at the protect and
correct speed, and that automation respond
should be considered core to security.

NIST Definitions Roles and responsibilities between Enterprise, Contextual

different architectural functions. solution and
technical
architects
NIST RMF Assessment Phases of planning required for a Plan, interview, Contextual
planning cyber risk assessment. analysis,
treatment

©2023 Check Point Software Technologies Ltd. All rights reserved | P. 34