CHECK POINT ENTERPRISE SECURIT Y FRAMEWORK

(CESF)

A Process-Driven Approach to Building Enterprise Security Architecture

CHECK POINT ENTERPRISE SECURITY FRAMEWORK (CESF) | 2

Abstract

This Check Point paper outlines a new process-oriented approach to developing enterprise security architecture. It draws from both well-known open frameworks as well as Check Point’s rich experience in architectural design and development.

In this paper, we provide you with an overview that includes an architectural process, framework, and methodology. This is not,

however, a “how-to” guide. By the time you reach the paper’s

conclusion, you should have a firm grasp of the various components of the Check Point Enterprise Security Framework

(CESF), and how they form the foundation for your next enterprise architecture.

Audience

Architects, engineers, and designers engaged in security architecture will benefit from this paper. As a prerequisite, you should be well versed in network and security design concepts and generic security architectural concepts and frameworks.

CHECK POINT ENTERPRISE SECURITY FRAMEWORK (CESF) | 3

TABLE OF CONTENTS

1 Introduction ... 4

2 Open Frameworks ... 7..

33 Zero To Trusrustt ... ... 99

4 The Enterpise Security Framework ... 11

5 Using the CESF Process ... 14

6 Review and Architecture Phase ... 15

7 The Workshop ... 16

8 The Review Layer ... 19

9 The Architecture Layer ... 23.

10 Design and Build Phase ... 26.

11 The Design Layer ... 27.

12 The Build Layer ... 32

13 The Implementation Layer ... 39.

14 Service Management ... 43.

15 The Service Management Layer ... 43.

16 Summary and Conclusion ... 44

CHECK POINT ENTERPRISE SECURITY FRAMEWORK (CESF) | 4

1 Introduction

Check Point has always believed in extending proper, correct, and impartial security advice to our customers, and the value in being trusted as security architectural advisors.

Our commitment to security architecture has resulted in Check Point supporting dedicated teams of security architects focused on advancing our clients’ security posture. We designed this consultancy approach to deliver security based on real business requirements, and not just commercial motives.

Check Point has developed this approach into a complete architectural methodology and process framework. With great pride, we’re excited to introduce this to a wider audience as the Check Point Enterprise Security Framework-CESF .

We know that organizations see value in a structured approach to security architecture, which is why Check Point developed the CESF process. This framework allows any enterprise security team to develop a secure architecture using a formulated, accountable, and comprehensive process.

WHY IS SECURIT Y ARCHITECTURE NECESSARY?

Before we explain how and why Check Point developed an enterprise security framework, let’s discuss brieflyA'y it’s important to understand the role of security architecture within an enterprise. Here are several reasons why you need security architecture:

• Building security without a carefully considered plan is at best complicated, and at worst can lead to a compromised security posture and increase your costs.
• CISOs need a way to communicate cyber risk to an organization’s management team: — Does the current security posture align with common security standards? — Do the existing security controls complement the business needs? — Does the existing security infrastructure address all the business risks? — How to reduce TCO and operational efforts while enhancing the level of security? — How to implement new security innovations to support the wider business?
• Measuring the success of security spend is vital. Good security architecture adds structure to spending decisions and improves accountability.
• Check Point believes that security architecture should have a clear and concise methodology.

CHECK POINT ENTERPRISE SECURIT Y FRAMEWORK (CESF)

Check Point developed CESF as a customer-centric security framework to help our customers explain, develop, mature their security posture and align with security best practices. Through our process, architects are able to accurately capture and record business requirements and convert these into tangible Check Point solutions and advanced security solutions.

The CESF mission statement is to:

• Meet our customers’ requirements for a structured and systematic approach to design, architecture, and digital transformation that results in a tangible implementable solutions.

CHECK POINT ENTERPRISE SECURITY FRAMEWORK (CESF) | 5

• Respond to the challenges of transformation by reducing costs through careful design.
• Be a methodology that delivers digital transformation; from concept to the completion of real-world security solutions The info-graphic below show the end-to-end process.

WHAT CESF MEANS FOR OUR CUSTOMERS

Some key benefits include:

• Accountability: Using CESF ensures security spend is accountable and can be traced back to a business requirement.
• Strategic: The CESF helps define near, medium, and long-term goals, reducing technology overlap and unnecessary spend. Having a view of a long-term strategy reduces the need for point solutions and helps build a strong, complete, security ecosystem.
• Complete: The outcome of using the CESF is a security architecture roadmap and reference architecture, one designed to support the client’s business while maturing the overall security posture.
• Justified: The CESF delivers a bespoke detailed design blueprint that enables clients to build a complete security ecosystem. Solutions and spend can be justified against measurable requirements. Solutions and spend can also be justified to the board.
• Independent: Because it is built and based on open standards, clients have full visibility of the decision making process and how the architectural solution was developed.
• Professional: A collaborative approach to developing security architecture brings Check Point and client architects into a closer working relationship.

CESF AS A PROCESS

We can explain the CESF process as a logical methodology that consists of a collection of phases. Each phase has a specific function and output. The combination of these phases allows us to deliver security architecture in a manner that is accountable, and fully documented. Expressing the CESF as series of linked phases helps simplify the process and means we can use different resources at different points of engagement.

CHECK POINT ENTERPRISE SECURITY FRAMEWORK (CESF) | 6

The phases are:

• Review and Architecture: This phase of the process is for business and architecture reviews as part of a CESF workshop. This phase is for data-capture, business modelling and risk assessments.
• Design and Build: This phase is for CESF architects to develop a response to the requirements and to build customized logical design blueprints and recommendations.
• Implementation: This phase is for professional services, partners, etc. to add low-level design details and deliver statement-of-works for real-world solutions.
• Service Management: This phase is for continuous development and improvement of the security posture.

CESF FUNDAMENTALS

Before we look into the CESF process, it is important to understand the key components and drivers that have influenced its development; namely SABSA (Sherwood Applied Business Security Architecture) and Zero Trust. SABSA is widely used outside of network or cyber security requirements to develop business-driven solutions and Zero Trust has become a mainstay of enterprise architecture. Both of these open frameworks are widely used and respected by the security industry for their approach and relevance. They are by their nature, both broad and, relevant to all disciplines of security. Check Point's deep understanding these subjects has influenced and shaped the development of the CESF process:

• The CESF process has re-interpreted and reformatted these two key influences so that the CESF process is focused on delivering a holistic network and cyber security architecture relevant to our clients.
• The Check Point CESF process combines the best parts of these existing open frameworks with our world-class understanding of security, its design, implementation, development, and support.
• The CESF process is designed to deliver realistic, real-word security architecture and must result in blueprints and recommendations that are actionable and achievable.

Figure 2: The key influences

2 Frameworks

OVERVIEW

Let us look in more details at the SABSA open framework Check Point has used to develop CESF. SABSA is one of the most widely recognized security architectural methodologies. Its framework allows security architects to develop a business requirement into a security design, and then to manage implementation in a controlled manner while maintaining a business-driven focus. Every security solution is based on, and linked to, a business requirement. The key tools in delivering security architecture through SABSA are the use of the SABSA framework and SABSA views.

The SABSA methodology is to analyze the business requirements at the outset, and create a chain of traceability through to logical design and implementation. The main features of SABSA are the “views” and “layers” components of the SABSA framework. In the next section we will look at how these are used and their importance.

VIEWS

The first component of the SABSA process that we will look at is the SABSA “view” concept, which describes how the framework engages with different stakeholders as we move through the process of security architecture. The end-to-end process of building security needs to account for all

end-to-end process of building security needs to account for all

points’ of view. Each layer of the process is relevant to someone’s point of view.

The table to the right shows the various layers of the SABSA design methodology and the “views” that are attributed to each layer.

In the table to the right, we have listed the various layers and their function in the overall process.

The SABSA framework is a top-down process that moves through a number of "layers". Each layer has a specific purpose and has a specific “view” as seen above. When combined, they make up the entire SABSA process. Each “layer” has a specific job in the overall process and is a pre-requisite for the subsequent layers. Each “layer” represents a specific set of processes designed to elicit the data needed to complete the layer’s objective. Each layer plays a fundamental part in the overall design process.

LAYERS

Figure 3. SABSA views1

1 Source: https://sabsa.org/sabsa-executive-summary/

CHECK POINT ENTERPRISE SECURITY FRAMEWORK (CESF) | 8

THE SABSA FRAMEWORK

The cornerstone of SABSA is the SABSA framework. The framework gives the SABSA architect a structure by which to formulate the security architecture. It also structures how data is collected and the questions asked. In its simplest form the SABSA framework is a roadmap to deliver business-driven accountable security by collecting answers and asking questions at each layer. Key Point: The framework starts at the ‘contextual’ layer and moves across and down.

Figure 5. SABSA framework2

SABSA AND CESF

Check Point has drawn inspiration from the SABSA framework and credits its influence in the creation of the CESF process. CESF borrowed, and adapted, the concepts of "views" and "layers" in its approach to develop a process specifically designed around network and cyber security. Because SABSA has been designed to help in all fields of security architecture, Check Point chose to adopt some of its guiding principles but to tailor these specially for our own audience and customer-base. The result is a more targeted process designed to deliver on the requirements of Check Point customers. Check Point’s adoption of SABSA into the CESF process also means that we are able to borrow common terminology and act as an open framework.

2 Source: The SABA framework-https://sabsa.org/sabsaoverview.pdf

CHECK POINT ENTERPRISE SECURITY FRAMEWORK (CESF) | 9

3 Zero Trust

Zero Trust was introduced to the world as a model for security architecture in 2010 by John Kindervag of Forrester Research,3 and it’s another key influence on the CESF process. In this section, we will explore Zero Trust as a wider concept and architectural methodology, before exploring how CESF uses Zero Trust. A core premise of Zero Trust is that to think about cyber-risk correctly, we should first assume the internal network is compromised; we just do not know it yet. If we follow this assumption, we can conclude that internal connections must be authenticated before they are trusted.

Figure 6. Forrester: The seven pillars of Zero Trust architecture

Zero Trust is now an industry standard design methodology. Its approach is a move towards a label-based architecture, which uses identity and connection-context to make access decisions for users, data, and networks irrespective of location. In a true Zero Trust network, designers would approach the internal and external networks as essentially the same in terms of trust, risk, i.e., the internal and external networks are ‘toxic'.

3 Webinar: No More Chewy Centers: The Zero-Trust Model of Information Security,” by John Kindervag, Forrester, August 9, 2010

CHECK POINT ENTERPRISE SECURITY FRAMEWORK (CESF) | 10

DRIVERS FOR THE ZERO TRUST MODEL

As security professionals Zero Trust invites us to accept that a hard perimeter is ineffective against many attack vectors.

The following drivers are commonly quoted as reasons for adopting Zero Trust:

• f3A'eb access, and all encrypted traffic (VPN, SSL, SMTP-TLS, etc.) cannot be filtered efficiently or effectively at the corporate perimeter.
• Once inside the perimeter, those traffic items may carry hostile payloads that can work their way transversely to attack resources they were never intended to contact.
• A hard perimeter is at odds with modern business models; organizations are often disparate with users working from multiple locations.
• Cloud transformation is a key strategic goal for many organizations. This often means an organization’s intellectual property and core workloads are now located in shared-ownership platforms. Traditional models of security aren’t equipped to secure these business models.

PROCESS-CENTRIC SECURIT Y ARCHITECTURE

Zero Trust proposes that perimeters don’t exist anymore and network is essentially borderless. Security professionals need to find alternatives to securing data, corporate assets and users. Modern thinking is to move away from a focus on networks, borders, and systems and address process and data-centric security requirements.

This paradigm shift is by no means complete but it means that security architecture needs to encompass a view of how data is secured irrespective of its location. How this manifests in real- world security architecture is a topic for the ”build” and “design” CESF process; for now we will only acknowledge a

Figure 7. Evolution of Information Security Technology 4

move away from the network-centric to data-centric network design to a more process and data-centric view.

ZERO TRUST AND CESF

We have established that the principles of Zero Trust are mainstream and that Check Point has adopted these principles as a key design principle for CESF. The table on the right shows how the Zero Trust methodology is a critical component of the CESF process.

We consider Zero Trust a key component of CESF because:

• Zero Trust is used as a design principle integral to most modern secure networks. All security architectural papers and all Check Point design templates are built around Zero Trust, except in circumstances where this architecture doesn’t apply or is counter-intuitive. 4 Source: Dan Hitchcock, The SABSA Institute C.I.C. 2019

CHECK POINT ENTERPRISE SECURITY FRAMEWORK (CESF) | 11

4 Check Point Enterprise Security Framework

THE CESF

This section introduces Check Point ENTERPRISE Security Architecture as a design process and the vehicle for building security architecture.

As previously discussed, CESF is the Check Point interpretation of the SABSA process combined with best practice and Zero Trust architecture. In this section, we will convert SABSA “views” and SABSA “layers” to CESF “views” and “layers”, and incorporate Zero Trust into the CESF process.

We built CESF around number of layers, each with a specific goal and conducted sequentially. Each layer plays a role in collating and processing the client’s business and security requirements in such a way as to arrive at the required output. The combination of these layers is a complete security architecture that is fully accountable to business requirement and fully documented.

SABSA TO CESF

Check Point’s interpretation of the SABSA “layers” has SABSA Layer Check Point CESF Layer resulted in the same amount of layers, but now described to

Contextual REVIEW

be more relevant to our goal of building network and cyber

Concept ARCHITECTURE

security solutions. We will look at each layer in more detail in a later section of this paper. For now, it is important toLogical DESIGN understand the conversion that Check Point has made, as

Physical BUILD

illustrated in the table on the right.

Component IMPLEMENT Management MANAGE

Figure 9. Translating SABSA to CESF layers

CESF VIEWS

CESF uses the principle of views in the same way as SABSA: a view describes the ownership for a layer. In the CESF framework, we can find the owner of the layer in the "owner" column, as shown in the table below. We will refer to CESF views throughout this paper, as they are a key part of the SABSA framework and CESF.

Key Point: A difference between SABSA and CESF is that the CESF architect assumes responsibility for multiple views.

CESF Layer View / Owner REVIEW Client's View

ARCHITECTURE DESIGN Check Point Architect's View

BUILD IMPLEMENT Check Point SME, Professional Services

MANAGE Check Point Account Management, Customer Success Team

Figure 10. The CESF layers, views and owners

CESF L AYERS

Like SABSA, CESF is comprised of a number of layers, each with a specific goal and conducted sequentially. Each layer plays a role in collating and processing the client’s business and security requirements in such a way as to arrive at the required output.

The layers are as follows:

Figure 11. The CESF layers and their descriptions

CHECK POINT ENTERPRISE FRAMEWORK

As the name suggests the CESF is a framework, one that defines the structure by which we should conduct security architecture. The CESF provides a set of rules and principles that apply to the process of developing enterprise security solutions.

Figure 12. The complete CESF showing the core and extended sections

NAVIGATION

Before we discuss the various components of CESF it is important to understand how we navigate the table. We have divided the framework into a number of layers, with specific tools and deliverables at each phase. Each layer is addressed sequentially and from left to right, as shown below:

Figure 13. The complete CESF showing how to navigate the layers and rows

PROCESS AND TIMELINE

The final piece of information that we can gain from the framework is the order that we progress through the process. In the CESF we complete each layer at a specific time within the overall engagement.

Figure 14. The CESF showing when the various layers are completed

5 Using the CESF Process

• Implementation: Professional services, partners and engineers are able to add low-level design details to the recommendations delivering on the business-driven solutions built through the CESF process. Engagement of specialist teams such as incident response and strategic alliance, and.vendor specific design patterns, such as the Check Point Infinity architecture, can be applied.

• Service Management: Continuous development and improvement of the security posture by Check Point. Account management and technical post-implementation support.

6 Review and Architecture Phase

OVERVIEW

This is the first stage of the CESF process and sets up the entire engagement. It contains two critical layers that are both of which are delivered as part of the CESF workshop. This phase consists of the following:

• The Workshop is the core, and only, vehicle for data-capture and discussion with the client. There is no way to complete the CESF process without a CESF workshop.

• Review Layer is used to capture the business requirements, risks, goals and strategy. The “review” layer is business-centric.

• Architecture Layer is used to capture security objectives and perform the required technology-centric analysis.

In terms of the CESF table, we are looking at the following layers:

Figure 15. The CESF layers required for the workshop phase

CHECK POINT ENTERPRISE SECURITY FRAMEWORK (CESF) | 16

7 The Workshop

OVERVIEW

The CSF workshop is a core component of the CESF process. We consider it critical to the success of the process. Without the workshop, we are not able to collect the information required. The value of the workshop cannot be under- represented; consequently, they are always conducted face-to-face, in a forum format, designed to allow our clients a platform in which to articulate their organization’s business and security requirements. In this section, we will look at how the workshop is conducted, the people required to be present, and show some of the workshop components. We can describe a Check Point workshop as follows: The Enterprise Architecture Workshop is an exclusive and focused single day meeting between the client and Check Point professionals to openly discuss, review and advise on all aspects of the existing, and future, security ecosystem. As with any client-facing process, there is a specific engagement timeline as shown below. The key point is that the workshop is an open-forum, face-to-face exercise containing a significant whiteboard session that’s followed by a report.

Figure 16. The Check Point workshop timeline

WORKSHOP PRINCIPLES

Onsite workshops are hosted by dedicated architects and are designed to systematically and methodically capture all the information required by the framework process. The guiding principles of the workshop are:

• An open, honest, and interactive one day session

• A vendor-neutral security best-practice discussion

• Business processes and context focused

• Security requirement and security concept focused

• Not a technical deep-dive

WORKSHOP GOALS

The workshop is the single most important point of contact between Check Point and the client. The main goals are:

• To better understand the client’s business objectives and how this relates to their security technology choices

• Help clients achieve their architectural goals

• Challenge ideas and explore what is possible

• Help clients align with security best practices

• Write, record, report and present recommendations

OUTPUT

At the conclusion of the review we will have:

• A corporate strategy as it pertains to security

• The client’s business and security drivers

The workshop agenda is written and agreed upon by the architect and client before they meet. Check Point CESF process can be used to assist customers who have a more focused agenda. In these cases the agenda can be changed. The most important consideration is that enough quality information is gathered to process to the “design” and “build” layers.

• A collection of business processes and attributes

• The client’s risk appetite

• An analysis of existing security controls and high-level security architecture

• Future or target architecture as the client sees it

A complete business impact assessment

WORKSHOP STRUCTURE AND AGENDAS

Business Review

Architectural Review

Risk Appetite Assessment Business Impact Assessment (BIA)

Threat Environment Analysis Network Design Review

Network Design Review Whiteboard Sessions

Whiteboard Sessions Security Controls Review

CHECK POINT ENTERPRISE SECURITY FRAMEWORK (CESF) | 18

The most important components of the workshop are:

Stakeholder Interviews

We always start by collaborating with senior security stakeholders to discuss the business drivers. The main vehicle for collecting requirements is through stakeholder interviews, conducted with senior managers, program managers, and C-level representatives. The interviews allows the architect to hear first-hand the client’s business objectives and security challenges. These interviews are critical for establishing what really matters to the organization. In this opening section of the workshop, the client’s senior managers, program managers, etc. will articulate:

• What the business does and how it achieves its goals
• The key business process that the client is engaged in
• The impact of security on business functions
• The perception of security requirements to the business units
• Future business objectives
• The impact of change on the business

Complete Network Design Review

A significant part of the workshop process concerns the network design and security design review. This is where Check Point architects and the client map out the existing security environment, normally though a whiteboard session. The main components are:

• Security architectural review: Identify and cover immediate, mid- and long-term security challenges.
• Security network and threat prevention design: Provide a secured and flexible network and security design aligning with the security best practices.
• Understand existing security controls: The security infrastructure review session must capture the current state of the architecture to a sufficient technical depth, without unpacking the entire configuration. The architect will use a security control matrix to make sure all significant areas are covered. Figure 17. Whiteboarding plays a large part in the workshop

and is often the focus of discussion when reviewing the client’s architecture

Participation

The success of this phase is very much dependent on gaining the correct level of commitment and "buy-in" from the client.

The value of the designs developed though the CESF process is conditional on us collecting the correct level of information during the workshop. For example, in many organizations top-level managers can articulate the business strategy and future business aspirations, fundamental information for the CESF process. The most effective workshops are those that have the correct C-level sponsorship.

While every organization has its own internal structure, a good example of the various participants is in the table below.

Figure 18. The recommended participants for a standard CESF workshop

8 The Review Layer

The review layer is primarily concerned with capturing information that pertains to the client’s business, both in terms of their general overall strategy, and the role security plays within the organization. We often refer to this as business modeling.

In the previous section, we discussed the workshop and the workshop process. We complete this layer during the workshop. This layer describes the process of capturing business objectives, requirements, aspirations, and near-, medium- and long-term goals. It is the only layer dedicated to the client’s business and its objectives.

The layer is made up of the following steps:

CHECK POINT ENTERPRISE SECURITY FRAMEWORK (CESF) | 20

REVIEW LAYER PROCESS

The following section explains how the steps shown in Figure 19 are accomplished. This layer is a combination of three distinct processes. First, the architect will learn the client’s business and identify requirements. Afterwards, they will be able to articulate the influence of security on these requirements. The final step is to express these requirements as attributes, i.e., labels that describe what is required of the security architecture.

1. Identifying Business Requirements (BRs)

We have already discussed the stakeholder interviews as a part of the workshop process. The outcome of these interviews should be a collection of business requirements.

Definition: A business requirement is a resource, process, or condition that is vital for the continued success and growth of a business. Below is an example of a business requirement captured in a data-capture template:

Figure 20. Example of a business requirement

2. Identifying Business Drivers for Security (BDS)

During the stakeholder interviews, we will also gather the business drivers for security. These statements describe the requirements in the context of security. All requirements are relatable to security and this is what the BDS captures. In other words, the interview process will result in the CESF architect knowing exactly how to relate security to business requirements.

Business drivers for security are very specific to each client and it is only through the workshop interviews that we are able to capture these in detail. Often business requirements are too general in definition. The BDS gives them more focus and relevance to security architecture.

Key Point: Business drivers for security are aways inked to the business requirements and processes. BDS’s provide the security context to the BRs.

Below is an example of a business requirement and its corresponding BDS.

Figure 21. Example of a business requirement

CHECK POINT ENTERPRISE SECURITY FRAMEWORK (CESF) | 21

3. Attributes

The next and final stage is “business attribute mapping.” This is the process of assigning a number of attributes to each requirement identified during the workshop.

We will discuss what an attribute is in the following section and they feature prominently in this pape weve r. Ho r, for now it is important to note that “attributes” play the role of providing a link between the requirement and the recommendation.

An attribute is a conceptual abstraction of a business requirement. The attributed terms are abstract in nature but are an excellent mechanism to map out security controls. There are no fixed rules on how attributes are used and their use is often subjective. It is the CESF architect's responsibility to use attributes correctly.

De inition: SABSA defines an attribute as a conceptual abstraction of a real business requirement (the objectives, drivers and targets) which are modeled into a normalized language that articulates requirements and measures performance in a way that is instinctive to all stakeholders.

Key Point: Defining attributes also helps us to prioritize the business requirements and security drivers. Attributes can be given different weightings. Later in the CESF we will use the attributes to define the security controls that are required.

For the sake of simplicity we have borrowed the SABSA attribute table. However, it is possible for the architect to express their own attributes. The example below shows how we collect the attributes into our business process table.

Figure 22. A security attribute map used to link business requirements to business drivers for security

CHECK POINT ENTERPRISE SECURITY FRAMEWORK (CESF) | 22

ATTRIBUTE MAPPING

In complex cases it is common to find multiple attributes linking to multiple requirements. Another way to present these complexities is using an attribute map. The example below shows an enterprise’s goals and security objectives connected to security attributes.

Figure 23. A security attribute map used to link business requirements to business drivers for security

Maps like the one shown above will be expanded on during the next phase of the CESF process, for now it is important to appreciate that a single attribute might decribe multiple requirements.

In the following example, we have added the attributes to the data-collection table.

Figure 24. Example showing a business requirement and the attributes

CHECK POINT ENTERPRISE SECURITY FRAMEWORK (CESF) | 23

9 The Architecture Layer

OVERVIEW

The architecture layer is primarily concerned with capturing information that pertains to the client’s security design, architecture, operations, and infrastructure. Key Point: This layer represents the workshop’s architectural review process, and it should be considered one of the most important layers in the CESF process. Combined with the review layer, the architecture layer will produce a complete business and technical data set on which the following phases will depend. In the following section, we will outline some of the key processes that define this layer.

RISK ASSESSMENT

A key component of this layer is performing a risk assessment that captures, in a systematic fashion, the various security components currently in the network. We use the risk assessment to measure and record the organization's security posture, in its current state. The assessment is designed to probe the customer's security architecture. Through the assessment, the CESF architect can record how effective an attack might be and record the potential impact of a successful attack. This process analyses the risk and impact of various breach types, and the damage that would be caused. The following table is an example of a risk assessment template.

Figure 25. Extract from a typical Risk Assessment Matrix

A risk matrix gives us a structured method to work through various pre-defined controls and score them depending on the risk that a failure of this control would mean to the organization.

ZERO TRUST REVIEW

By taking a Zero Trust approach to the analysis of an existing network, architects and designers are able to probe the internal security functions and ask how capable the network is in defending itself from a breach. The Zero Trust approach takes the position that the internal network is already “toxic” or compromised, and invites us to assume the mindset of the attacker.

“A way to think about cyber threats is to assume you have already been compromised; you simply don’t know it yet.” Forrester5

Adopting this position allows for a higher degree of speculation about existing security postures, which results in a complete and thorough appraisal of the network. We will cover this topic in depth during the workshop stage of the CESF process.

RISK APPETITE ASSESSMENT

The risk appetite assessment is the process of quantifying a cyber risk. Making informed decisions about the cyber risk appetite could often be the difference between the success and failure for security projects, and if the organization will fulfill its strategic goals.

Risk appetite is the level of tolerance that an organization has for risk. One aspect of the definition is to understand how much risk an organization is willing to tolerate, and the other is thinking about how much an organization is willing to invest or spend to manage the risk. Risk appetite sets the boundaries for prioritizing which risks need to be treated.

Figure 26. The risk appetite scale

5 "Zero Trust," Forrester

CHECK POINT ENTERPRISE SECURITY FRAMEWORK (CESF) | 25

THREAT ANALYSIS

A useful tool for analyzing a client’s current architecture and security posture is through a managed Check Point CheckUp. We can use CheckUp results to understand network traffic and Internet usage. Often this level of insight can draw attention to operational issues, such as a lack of security visibility.

Figure 27. Exampe of a CheckUp Report

CONCLUSION: REVIEW AND ANALYSIS

We have completed the review and analysis of the client’s business and security estate. This information will form the foundation of the entire engagement, which is why it is important that the work is thorough and professionally collected. The CESF architect will have a solid understanding of the business, its strategy and requirements, and how security is designed and managed. They will also have a good understanding of the client’s appetite for change, their motivation, and capability.

At the conclusion of this phase, we will have:

A complete review layer

• All the required input from the client has been gathered
• Business drivers have been identified, captured, and recorded
• Business processes that influence the cyber security posture have been recorded
• Business attributes that reflect the business drivers have been identified

A complete architecture layer

• A detailed analysis of the existing network security posture has been performed
• A complete risk assessment
• A complete business impact assessment
• A record of the existing security controls In the following phase, we will use this information to formulate a security architectural blueprint, roadmap and report.

10 Design and Build Phase

OVERVIEW

We will tackle the two layers "design" and "build" in a single phase. In this phase, the CESF architect will move from the business requirements (BRs) to the logical design and explain the security components used and why. This phase centers on designing and building a solution and a set of recommendations. At the completion of this phase, the CESF architect will have documented the whole process for delivery back to the client.

This phase consists of the:

• Design Layer, which uses Zero Trust, network segmentations, attribute mapping and security best-practices to define the security components required to meet the BRs.

• Build Layer, which pulls all the design components together into a logical security architecture blueprint and completes the reporting element of the process.

From the CESF table below, we see these phases complete post-workshop. They are the last layers under the CESF architect's complete ownership. Once the “design” and “build” layers are done, the design is passed to other teams for implementation.

Figure 28. The CESF table showing the design and build phase

CHECK POINT ENTERPRISE SECURITY FRAMEWORK (CESF) | 27

THE DESIGN AND BUILD GOALS

The key goals of the phase are:

• To align business requirements with technology choices. All business requirements translate to security infrastructure or process improvements. All technology recommendations are justified and traceable back to the business requirements.
• If recommendations can be made to improve business processes, they will be delivered at this phase. Recommendations could include operational improvements or changes to the workflow. These recommendations are mapped to business requirements as are the technology choices.
• Convert the “attributes” into real-world security components.
• Complete the security architecture report, the overarching document that presents the CESF architects vision back to the client.

11 The Design Layer

OVERVIEW

This layer is the most complex to complete and requires knowledge of various security best practices and components. The outcome of this layer will depend on how the data from the previous layer was processed and the quality of the information collected during the “review” and “architecture” layers. The “design” layer covers all aspects of design, including the logical design of the security ecosystem as well as any relevant operational process designs. The main technology deliverables from this layer are:

• Mapping business attributes to security controls and services
• Mapping security controls to physical components
• Applying Zero Trust design methods
• Applying Infinity architecture methods
• Maintaining the chain-of-responsibility between concept and logical design
• Adhering to the single platform of the Infinity architecture methodology The main operational/process deliverables from this layer are:
• Operational efficiencies including organizational structures and separation of duties
• Operational efficiencies in the management of security events
• Efficiencies in the management of security policies
• Shared responsibility of security risk between business units and internal teams The following techniques, processes and tools are used as part of this layer.

LOGICAL DESIGN

This section explains the technology design process. As explained in previous sections, the CESF architect will use information in the preceding layers, combine this with Zero Trust, reference architecture and best practices, and produce a design template and solution.

Before we can start building the logical design, we need to know what security components are required. For this, the architect will use the “attribute-to-service” mapping. This process is similar to the “business-to-attribute” mapping that we discussed in the review section. HoweverA this time we are using the attribute to help define security services.

USING ATTRIBUTES

We first discussed attributes in the “review” layer and explained that each business requirement needs to have a number of them; a requirement would have between 2 and 20 attributes.

In this phase, we will map those attributes to specific security components and services. These components are key to the solution as they meet the needs of the various business requirements. This process does not let the CESF architect know where to put the component in the design, only that the component is required for the design to be complete.

Definition: A component is a vendor agnostic description of a thing that has a specific security function. For example, an IPS is a component.

It is the job of the CESF architect to consider each attribute and define the service, or controls, that are appropriate to meet the expectation of the attribute. As we have stated before, the attribute is the single most important link between the review and architecture layer and the design and build layers.

As with all design processes the language that is used is important. At the “design” layer, the "things" used in the design should be described as “controls” and not specific vendor competencies. This is because we can implement services in any number of different ways. It is only at the “implementation” layer that we define a specific vendor device and its configuration.

SECURITY CONTROLS AND SERVICES

Definition: A security control is defined as a process, object or action that results in a specific security action or event.

In the context of the CESF framework, the design layer is only concerned with defining these controls and security services. Some examples are shown below:

Figure 30. The language used to describe security things is different at each layer

MAPPING ATTRIBUTES TO COLS ONTR

With a complete list of business attributes, we are now able to do an attribute-to-security mapping. This process takes the attributes defined in the “review” phase and converts them to real-world technology that can be used in a logical design.

This step is critical for a completed architecture as it maps the attributes to real-world security technology and, where appropriate, to Check Point technology.

Key Point: Mapping controls to business attributes means that we never loose focus on what is important to the business. Every control is there for a reason.

Key Point: CESF architects will use a list of known mappings. However, the main point to this process is being able to justify why a specific component, technology or service is being used.

This process provides us with the list of security controls we will use in our design. In the map below, we can see how the security attributes that were collected as part of the previous phase are now mapped to security services and controls.

Figure 31. The language used to describe security is different at each layer

ZERO TRUST DESIGN

The following Zero Trust concepts are guiding principles for architects at the “design” layer. We consider Zero Trust as a gold standard in how to design secure networks, and how they should be segmented. CESF architects regard Zero Trust as a security best practice. Clearly, Zero Trust is not and cannot be applied to every solution. However, where applicable, CESF architects will use this as a core design principle.

In the following section, we will look at the building blocks of Zero Trust designA as defined by Forrester, and how we applied them to the CESF process.

Toxic networks – In Zero Trust architecture workloads should be available and accessible regardless of location. Zero Trust demands that security professionals protect internal data from insider abuse in the same manner as they protect external data on the public Internet. This has an impact on the security controls that we would use in the design.

Identity – Designing to Zero Trust standard means adopting the “Principle of Least Privilege” as the access control strategy. Zero Trust means strictly enforcing access control using identity. As a core principle of CESF we would expect the Zero Trust design to incorporate an identity source.

Key Point: A Zero Trust design principle would be to restrict a user’s access to only the resources they need to perform their job, and, instead of trusting everyone, we verify that they are the intended user for the resource.

Audit and logging – Also aligned to Zero Trust principles is to perform logging on all traffic. This allows connections to be properly audited. It is therefore necessary for the CESF architecture to design a platform that is able to properly audit and log traffic, and to use this valuable data to enrich the overall security visibility.

Figure 32. Control interactions between users, resources, data and applications

MORE ZERO TRUST CONSIDERATIONS

• Micro-segmentation and visibility: In order to keep threats isolated and any infection blast-radius contained, highly segmented or micro-segmented networks are needed. Increasing the amount of segments gives us more opportunity to monitor and record traffic. This should result in a high-degree of network visualization.

The CESF architect will consider the following points, amongst others, when developing the recommended security architecture:

CHECK POINT ENTERPRISE SECURITY FRAMEWORK (CESF) | 31

DESIGNING OPERATIONAL PROCESSES

The “design” layer of the CESF is primarily concerned with making recommendations that advance the client’s security posture through technology recommendations. However, there is also scope to assist clients outside of purely technological solutions. Changes to operational and business processes can often lead to more secure and manageable security solutions. The CESF process acknowledges the value of such changes to the overall security architecture.

Workflow Process

How customers manage, their environment has a significant impact on the technology used. In some instances, the client may not have the capacity to manage a complex security ecosystem, so the architect might propose changes to the workflow process in order to enable a simpler, more manageable security. Recommendations that address changes to workflow processes can often include use of new technology, such as automation, and:

• Simplification of the security policy
• Simplification of the change control process
• Sharing responsibility for the security policy with other teams, such as application owners

Operational Efficiency

How the client’s operational team conducts the management of their security estate has an impact on security effectiveness. Often when security infrastructure becomes more complex, the size of a security team remains static. The CESF process recognizes this potential issue and is cognitive of the impact changes to security controls, services and processes can be. We must consider the people and process component of security architecture as the part of the design process. Recommendations should be cognitive of the impact on the operational team’s workload and responsibilities. When relevant, the CESF architect will make recommendations to operational practices for the betterment of the overall security architecture. Often the CESF architect will be able to draw on first-hand experience of security operations (SOC) and share their relevant knowledge. Examples of recommendations that might be included in the report include:

• Adoption of design templates from a pre-built service catalogue in order to reduce the design cycles.
• Changes to the change-control process so that pre-approved changes are allowed, resulting in security changes that can be implemented quicker.
• DevOps teams take control of intra-zone access control policies in order to reduce the change to implementation times.
• Assistance to help define the network as a cloud platform in order to help simplify cloud transition.

CHECK POINT ENTERPRISE SECURITY FRAMEWORK (CESF) | 32

12 The Build Layer

OVERVIEW

We define the “build” layer as the layer at which the CESF architect will build a logical representation of the recommended architecture, including any changes to business processes and operations. The previous “design” layer gave us the principles and components that we can use. It is now time to pull these together into a working security architecture. The design blueprints produced at this layer are a key deliverable handed back to the client, and define the CESF architect’s vision for the client’s architecture.

The main technology deliverables from this layer are the document;

• The placement of security controls into the security architecture
• The completed desgin blueprints and referance architecture
• The placement of components and services required to complete a Zero Trust design
• The use of the Check Point Infinity architecture The main operational/process deliverables from this layer are:
• Document any recommendations to improve business processes that support the recommended architecture. The following section will describe the techniques, processes, and tools used as part of this layer.

NETWORK SEGMENTATION AND TRUST ZONES

The process of network segmentation is a topic in its own right and we will not attempt to discuss it in full here. What is important to note is that at the completion of the design layer, a fully segmented architecture is defined. This logical design is aligned to Zero Trust architecture and our best practices. The CESF process relies heavily on Zero Trust to inform how we approach segmentation. A key tenet of Zero Trust is to design a network that enables micro-segmentation for the purposes of increasing security visibility and reducing risk. Practitioners of cyber security will know the security benefits of moving to a properly segmented network and CESF architects will use segmentation best practice as a core design principle.

Key Point: In some cases networks are suited

to a more traditional segmentation approach. The approach is a product of the pervious layers of the CESF process. The graphic on the right shows some of the CESF design process:

Figure 33. Network segmentation practice in action

CHECK POINT ENTERPRISE SECURITY FRAMEWORK (CESF) | 33

ALIGNMENT WITH ZERO TRUST

In the previous section we looked at the various Zero Trust principles that make up a Zero Trust architecture, and we looked at the various design methodologies and the core features that need to exist in the Zero Trust design. We can now use these to influence where components are required, where they will be located, and how they will interact.

Key Point: It’s norma to find that organizations are not abe to immediatey convert to a compete Zero Trust architecture. However, because the architect knows the key attributes required in the design, they are abe to seect what components of Zero Trust are the most appropriate.

Depending on the outcome of the workshop phase, the CESF architect would define one, or all, of the Zero Trust building blocks to be included in the final design. According to the principles of CESF, which we have discussed in previous sections, the design must be based on clear business requirements. Consequently, how Zero Trust is implemented is conditional on the outcome of the workshop. Below are the various Zero Trust designs that could be used.

• Zero Trust Networks: Reduce the risk of lateral movement with micro-perimeters and identity-based policies.

• Zero Trust People: Use multi-layer authentication to identify and verify all corporate access to any internal asset. Figure 34. The components required for Zero Trust people design

• Zero Trust Devices: Secure, control, and isolate every device on your network.

• Zero Trust Workload: Secure data and applications in public clouds and data centers.

• Zero Trust Data: Keep data secure, anywhere, with comprehensive multi-layered protection.

• Visibility and Analytics: Full threat visibility with a single view into security risks, integrating Security Information Management (SIM) and more advanced security analytics platforms like Security User Behaviour Analytics (SUBA). Other analytics systems can also be enabled to know and understand what is taking place in the network.

• Automation and Orchestration: Automate all processes and tasks using flexible APIs and rich 3rd party integrations. Providing the ability to have positive command and control of the many components that are used as part of the Zero Trust strategy is a vital piece of the extended Zero Trust ecosystem.

CHECK POINT ENTERPRISE SECURITY FRAMEWORK (CESF) | 34

DEFINING SECURIT Y CONTROLS

In the previous layer, we identified the various security components required to satisfy the business objectives. Now, we need to place these components into the network. This work is conducted by the CESF architect based on all the factors we have discussed previously, namely Zero Trust, best practice and business requirements. The example below shows security controls and their logical network positions.

Figure 35. Security contro to network segment-mapping matrix

DESIGN BLUEPRINTS

The completion of the build phase is the publishing of the Check Point workshop report, which we will discuss in the next section. A core component of the report is the design blueprints. These present the recommended logical security architecture, the security components, and their placement within the network.

The CESF architecture will draw on a number of resources in this part of the process. Some of these are:

• Security Control Matrix: The controls, components and services that were identified and linked to the business and architectural review will now be transposed to the design blueprints.
• Best Practices: Applying the industry and Check Point security best practice guides, as well as our own industry knowledge means that design blueprints are able to form the basis of any low-level design that might follow. The components are placed in the design relative to the required position and in relation to other security components.
• Segmentation: The segmentation architecture, including alignment with Zero Trust, as well as a proposal for segmentation rules.
• Reference Architectures: CESF architects have been conducting workshops for over five years. As a consequence the architects are able to draw on a design repository in the creation of the design blueprint and report. This allows designs to be referenced across industry verticals.

CHECK POINT ENTERPRISE SECURITY FRAMEWORK (CESF) | 35

Network Security Segmentation Controls

& Zero Trust Matrix

Reference Best Architectures Practice

Figure 36. Combining the various elements into the CESF process in order to define security architecture

ZERO TRUST REFERENCE ARCHITECTURE

A highly segmented Zero Trust network means having security controls between all assets, reducing the ability of compromised assets to propagate malicious code, or for bad actors to pivot onto other machines and launch further attacks. The graphic below shows a client’s network in which multiple enforcement points have been established. As part of the CESF “build” layer, each of these enforcement points should be understood in the context of security and business requirements.

Figure 37. A network segmented using Zero Trust principles

CHECK POINT ENTERPRISE SECURITY FRAMEWORK (CESF) | 36

INFINITY REFERENCE ARCHITECTURE

Check Point has always defined security architecture in a way that addresses all the components of a security ecosystem. Check Point Infinity architecture is a single-platform methodology whereby the entire security ecosystem is built on a common technology platform.

The key benefits of adopting this methodology are:

• Attack Surface: A single-platform approach where security products form each part of the network, including endpoint, cloud, and mobile, work together as a single security ecosystem.
• Complexity: Multiple security platforms normally means multiple management platforms, all of which need to be supported. Multiple point solutions can reduce overall security effectiveness. Building a security ecosystem means the sum of the total is more than that of the individual components.
• Operational and engineering teams are under increased pressure to deliver projects faster. Using the Infinity architecture approach means less complexity because the entire security infrastructure is managed from a centralized security policy.
• Intelligence: At the heart of Infinity architecture is the concept that by combining and sharing threat intelligence, from multiple sources, we are better able to protect the network, users and workloads. Check Point Infinity architecture is described in the graphic below, where the entire security ecosystem is integrated with a cloud-based, threat-intelligence data store, and where management is consolidated. Figure 38. The Check Point Infinity architecture Key Point: Check Point Infinity is a cyber security architecture which future-proofs business and IT infrastructure across all networks, including cloud and mobile. The architecture is designed to resolve the complexities of growing connectivity and more challenging security.

CHECK POINT ENTERPRISE SECURITY FRAMEWORK (CESF) | 37

OTHER REFERENCE ARCHITECTURES

When developing a logical architecture, the CESF process allows for the use of any open and documented architectural reference guides. In some cases, there may be specialized technology or compliance references that can inform the architectural choices. While the logical architecture must reflect business requirements, it should also be aligned with relevant architectural practices. For example, the Purdue model is widely used when developing SCADA security architecture.

THE REPORT

If the CESF process is going to be an effective means of communicating a long-term vision for better security, then it must be properly documented. At the completion of this layer, the architect will have created a bespoke report that outlines the key design and security concepts that Check Point would recommend for meeting the client’s requirements. The report is the only deliverable from the workshop that documents the design process from conception to completion.

Figure 39. Sample report

REPORT CONTENTS

The standard report aims to be a single source of high-level design recommendations based on business requirements and security drivers. At a minimum, a report contains:

• Review and Architecture: What data was captured during the workshop and the existing network topology highlighting the components that should be considered as part of the overall security posture.
• Best Practices: The Check Point architect’s methodology. This section explains how the various attributes have been assigned and why.
• Conceptual Design: A comprehensive, high-level security architecture report (50-80 pages) with findings and a recommended design. Personalized reports are crafted for each client.

CHECK POINT ENTERPRISE SECURITY FRAMEWORK (CESF) | 38

• Solution Overview: An explanation of the components, which are included in the solution. The solution overview adds context to the personalized solutions presented in the recommendations section.
• Operational Processes: The report will often contain recommendations and advice that deals with improvements to the business procesA'orkflow, or operational changes. These business consultancy recommendations are beyond pure technology recommendations. Figure 40. Example taken from a workshop report. Key Point: It’s important to remember that the report is ony designed to give high-eve recommendations, design advice, and conceptua architecture, and not ow-eve design. The transition from high-eve concepts to ow-eve, impementabe, design is discussed in the next section.

CONCLUSION: DESIGN AND BUILD

By applying Zero Trust design methods, leveraging industry recognized security best practices and interpreting the client’s business requirements, the CESF architect is able to provide complete security architecture and solutions design. Blueprints and security services are documented in a bespoke report that, if required, can be moved to an implementation phase.

The architect has now finished the “design” and “build” phase of the client’s security architecture.

Network Security Segmentation Controls

& Zero Trust Matrix

Reference Best Architectures Practice

Figure 41. Taking the outcome from the review /architecture layers and producing a workshop report

At the conclusion of this phase, we will have:

Completed the design layer:

• Mapped the business attributes to real-world security controls
• Completed the process of network segmentation
• Recommended changes to operational and business processes that would advance the security posture

Completed the build layer:

• Built the recommended security architecture

• Defined the placement of security controls

• Documented recommendations to business processes and operational efficiencies

Completed the workshop report:

• Combined the workshop blueprints and other requirements into a single security architecture package ready for low-level design and implementation

• The workshop report is presented to the client for approval and final sign-off

13 The Implementation Layer

OVERVIEW

We refer to this layer of the framework as the “implementation” layer in the CESF process. At this layer, the architect’s design blueprints become a tangible working security ecosystem, one that respects the client’s requirements.

In the “implementation” layer, the logical design is handed to other teams so that the various components, services, and processes can have real-world meaning and exist in the client’s network or as part of the client’s process.

We would expect that the recommendations are fully costed and that this is presented and agreed with the client.

Figure 42. CESF showing the implementation layer and its owners

THE IMPLEMENTATION L AYER

At this layer, the architect is not the owner. Check Point teams, partners and implementation engineers are now responsible for carrying out the physical implementation of the design.

Key Point: Ownership of the process changes at this layer.

Key Point: When the overa design reaches this ayer, the ogica architecture woud have been shared with the cient and approved.

COMPONENT AND PROCESS DESIGN

We would expect that all CESF designs and blueprints have physical components. The CESF architect would have produced a design blueprint to a level of detail required by the security engineering professional to translate it into a working solution.

Key Point: At this ayer, the ogica architecture is now expected to become a reaity.

As part of the “design” and “build” layer, we have mapped the attributes to technology and operational processes. The “implementation” layer represents the process of further developing these choices into the physical security mechanisms and security services.

The table below shows how the CESF process expects the “implementation” layer to describe the design.

Figure 43. The language used to describe security things is different at each layer

If the design blueprints are to be stood up as a working solution, then professionals with working knowledge of the implementation must to do this. The Check Point teams that the CESF would expect to be engaged in this layer are:

layer are: • Engineering – Check Point’s qualified engineers across all disciplines are able to address the low-level requirements of the design. These teams are critical to realizing the design in real-world terms. Specialist engineering teams will have practical working knowledge of the various components. Check Point engineers are also able discuss how Check Point products work “under-the-hood” and engage with the client on proof-of-concepts and product testing.

CHECK POINT ENTERPRISE SECURITY FRAMEWORK (CESF) | 41

• Incident Response – Check Point security services, such as incident response teams, are included as there is often a business requirement for incident response and handling services.
• Solutions Centre – Where there is complexity in design, these specialist teams are able to craft non-standard services. For example, when a Figure 45. Check Point Incident Response Team specific skill is required, the services of Check Point Solution Centre are available to create custom hot fixes.
• Account Services – Designs that have progressed to this layer are fully costed and this information is shared with the client. Ongoing service management is covered in the subsequent layer. However, professional services, incident response teams, and component costs are considered part of this layer.

SIZING AND SYSTEM INTERACTIONS

Implementation of any solution must address how components interact, their dependencies as well as configuration best practice. Subject matter experts will consult with engineers to make sure that the proposed solutions fit the design, and the logical design will become a physical architecture ready for implementing.

Key Point: As with a engineering work, component sizing is a key consideration. The purpose of this ayer is to compete this process and to factor in elements such as future capacity requirements.

OUTPUT AND DELIVERABLES

The diagram below shows how the implication layer deliverables are linked to the workshop report. It shows how the various layers of the CESF work together so that the output of this layer is low-level design.

Figure 46. The output from the implementation layer should be enough to complete a working design

END-TO-END EXAMPLE

The following data-capture table shows a completed project whereby the business requirement has been translated to a design and set of Check Point components. Using data-capture forms allows the entire process to be viewed on a single page, albeit at a high-level.

CHECK POINT ENTERPRISE SECURITY FRAMEWORK (CESF) | 42

14 Service Management

The final layer in the framework completes the CESF process. The service management layer is important as it sets up the ongoing process of design evaluation, in-flight account management, and the lifecycle management of the overall security architecture.

At this layer, we have completed the design and implementation of the logical architecture. Engineers now need to test and evaluate the solution.

The CESF owners for this layer are Check Point Professional Services, Check Point Incident Response Team, and account management teams.

It is now the responsibility of the other teams to maintain the momentum of the CESF process. The account service teams and technical support teams such as TAC and Diamond Services, who are responsible for the ongoing support of the implemented architecture, own this layer. These teams will work with the client for the duration of the solutions.

15 The Service Management Layer

Figure 48. The service management layer

CHECK POINT ENTERPRISE SECURITY FRAMEWORK (CESF) | 44

Account services and security engineers are in constant contact with the client, so it would be up to these teams to decide when to re-engage the architectural process. As the business requirements change, so too should the security architecture. The CESF process requires a Check Point representative to make sure the process does not stall and that the customer’s solution is always relevant to their requirements. The key features of this layer are:

• Understand and measure the success of the implemented solution
• Manage any support issues that arise
• Lifecycle management
• Quarterly business reviews
• Plan future workshops and subsequent CESF engagements

16 Summary and Conclusion

Check Point is pleased to present this paper as a new, innovative methodology for security architecture. We hope you have gained the insights as to why Check Point developed this framework and you understand how the process works. Making informed architectural decisions based on clearly defined business requirements can help you understand the benefits and the context for why a specific solution is recommended. All designers and architects strive to achieve completeness of vision in their solutions. Working within CESF means that only the requirements recorded are processed into solutions, allowing focus on solutions and justified results. In addition, by developing a security architecture that is accountable and documented, the value of time spent designing and developing a security solution is justified. We hope that by using the CESF process our clients can develop quicker solutions, create solutions that have a longer life cycle, and ensure that solutions are more efficient in terms of cost and security posture.

Worldwide Headquarters

5 Ha’Solelim Street, Tel Aviv 67897, Israel | Tel: 972-3-753-4555 | Fax: 972-3-624-1100 | Email: info@checkpoint.com

U.S. Headquarters 959 Skyway Road, Suite 300, San Carlos, CA 94070 | Tel: 800-429-4391; 650-628-2000 | Fax: 650-654-4233 www.checkpoint.com © 2020 Check Point Software Technologies Ltd. All rights reserved.