Skip to main content

This page has been translated using TexTra by NICT. Please note that the translation may not be completely accurate.
If you find any mistranslations, we appreciate your feedback on the "Request form for improving the automatic translation ".

2nd Next-Generation security Architecture Study Meeting

Overview

  • Date and Time: Tuesday, March 15, 2022 (2022) from 13:00 to 15:00
  • Location: Online
  • Agenda:
    1. Opening
    2. Proceedings
      1. Zero Trust Architecture Application Policies
      2. Technical Report on Introduction of Continuous Risk Diagnosis and Response (CRSA)
      3. Free discussion
    3. Adjournment

Materials

Reference Information

Summary of proceedings

Date

Tuesday, March 15, 2022 (2022) from 1:00 p.m. to 3:00 p.m.

Location

Held online

Attendees

Member

  • UEHARA Tetsutaro (Professor, Faculty of Information Science and Engineering, Ritsumeikan University)
  • Seiji Kono (Chief security Officer, Technology Management Office, Microsoft Corporation)
  • Shigeru Kimura (Evangelist / Architect in charge of security Operations, Cisco Systems LLC * 1)
  • GOTO Atsuhiro (President, security Graduate University of Information)
  • Natsuhiko Sakimura, President of OpenID Foundation
  • Yusuke Tahara (General Manager of Integration Service & Planning Department, Integration Promotion Division, LAC Co.,Ltd.)
  • Morifumi Narahara (Chief IT Architect, Tanium LLC)
  • Toshio Nawa (Managing Director / Senior Analyst, Cyber Defense Research Institute Co., Ltd.)
  • Norihiko Maeda (Director of the Office of the President of FFRI,Inc. security)
  • Mitsuhiko Maruyama (Partner, PwC Consulting LLC)

* 1 Received comments by email on Thursday, March 17, 2022

Observer

  • Cyber security Center (NISC)

Digital Agency (Secretariat)

  • Strategy & Organization Group security Risk Management Team

Information-Technology Promotion Agency

  • Digital Architecture and Design Center

Minutes

  • The secretariat explained Material 1 "Policies for Applying the Zero Trust Architecture," Material 3 "Technical Report on Introduction of Continuous Risk Assessment and Response (CRSA)," and Material 5 "Future Response Policies of CRSA in Anticipation of implementation."
  • In the open discussion on "Zero Trust Architecture Application Policies," the following remarks were mainly made.
  • In addition to the assets to be accessed, the evaluation of subjects seeking access to resources in the organization is also important in the description of the guideline, but it is necessary to establish it because it did not describe the subject.
  • The term "identification" in "asset identification" is not used in the guidelines and other documents. It is considered appropriate to change the term to "identification" or "identification" that leads to the next work process.
  • There are unclear parts and fluctuations in the definition of words. For example, the word "properly" is a qualitative expression, so it is better to avoid using it in the guidelines. The word "resource" is used in multiple meanings. The word needs to be revised. In addition, the word "journey" may not be understood. It is better to avoid using it because the way to read it varies from reader to reader.
  • Asset management and identification, identification and valuation lead to shadow IT problems in local public office. In the first place, local public office is in a state of stumbling before the application of the zero Trust architecture, but this measure will make it possible to clarify the problem of shadow IT.
  • There was no mention of BYOD. It is better to consider including BYOD because some data shows that ministries and agencies use BYOD more than public devices.
  • It is better to describe what changes will occur as a result of moving toward a zero Trust architecture. It is necessary to have an image of the current system and an image of the world after the zero Trust architecture is applied.
  • "Figure 1: The Core Logic Components of Zero Trust" does not describe the world of a strict zero Trust architecture. It can be misunderstood that it is only for teleworking and remote access. In fact, there are various interactions with access requests. For example, risk-based authentication does not describe the interactions of additional elements.
  • Understanding the world of zero Trust architecture requires an explanation of various terms. The current terms are few and need to be expanded.
  • Subjects and objects change from time to time. It is necessary to arrange resources based on this whole.
  • In Figure 1: The Core Logical Components of Zero Trust, identity management goes directly to the PEP, but it should be preceded by entity authentication. As a result of authentication, control is exerted at the policy execution point. This mechanism has not been expressed.
  • Apply the Zero Trust Architecture If there are circumstances in which it is necessary to continue to use conventional systems that are difficult to use, it is necessary to request efforts to ensure interoperability, such as by upgrading functions.
  • Since there is a possibility that users will be confused in the application (transition) process, it is necessary to consider setting a transition period in which the new and old systems can coexist temporarily.
  • It is necessary to link the zero Trust architecture with systems around the zero procurement architecture, such as human resource management systems, identity management, asset management, and Trust management.
  • By managing users and assets based on the principles of the Zero Trust Architecture, the content is understood to be relevant to those who actually manage it.
  • The use of words, including terms, is rough and needs to be reviewed. It is requested that the definition be clarified in the writer.
  • Zero Trust is a collection of concepts and ideas, and is also a cyber security plan, so it is not a system design or architecture reference, but design people and introduction reviewers always consider implementation methods consciously. I think that the zero Trust adaptation technology area of "Forrester'sZeroTrusteXtended (ZTX)", 1) Networksecurity, 2) Datasecurity, 3) Workloadsecurity, 4) People / workerforcesecurity, 5) Devicesecurity, 6) Visibilityandanalytics, and 7) Automationandorchestration, can be used as a reference.
  • An example of zero Trust application is presented.
  • Examples of the purposes of DX adoption expected by Trust companies related to Zero private sector are "opening of systems," "application of overall teleworking," "cloud use of Proxy," "security enhancement of teleworking terminals," and "change of network environments suitable for cloud use."
  • The terms "Boundary security" and "Zero Trust Architecture (hereinafter referred to as ZTA)" have been defined, but we believe that the definitions in the reference should be referred to here.
  • Regarding the solutions described in NISTSP800-207, it is requested to consider descriptions in accordance with "intelligent switch," "router," "firewall," "gateway for special applications," "software agent," "endpoint firewall," "SDP," "low-layer network stack," "SDN," and "IBN."
  • In the open discussion on "Technical Report on the Implementation of Continuous Risk Diagnosis and Response (CRSA)", the following remarks were mainly made.
  • Continue to create the normal state as a benchmark, raise the alert, save it to ASO, and rotate the modeling by ASO. In addition, I felt that it would be better to describe the viewpoints of the ASO repository and dashboard in the summary part.
  • The category of network security that is not defined in the US CDM is not defined at present. This needs to be examined.
  • It is also necessary to consider the deepening of actual events such as threat intelligence.
  • In overseas efforts, when CVSS cannot determine, management is attempted based on five total scores: "system compliance (use of public CIS benchmarks, etc.)," "privileged ID (monitoring of least privilege models, etc.)," "passwords (storage in plain text, etc.)," "expired certificates (revocation status of certificates, etc.)," and "insecure TLS and SSL (other than TLS1.3 and SSL3.0)."
  • Regarding Exhibit 3, it is considered that an item should be added to reorganize the positioning of existing systems such as GSOC and Government Information System Management Database (ODB).
  • Regarding "2.1. Positioning of Continuous Risk Assessment and Response (CRSA)," CRSA is considered to be only one of the elements to realize a zero Trust architecture in the current way of writing. Therefore, it is necessary to explain the mechanism of CRSA itself in the first sentence.
  • "(3) What is happening in the network? Understand what kind of intersystem traffic patterns and messages are occurring" is difficult to convey the intention, so it is necessary to revise the description.
  • Regarding "2.1. Positioning of Continuous Risk Assessment and Response (CRSA)," "Although there is a conceptual diagram showing the relationship between the logical components constituting the Zero Trust Architecture, it is considered that the relationship is such that Zero Trust can refer to CDM in the first place, and CDM is not specified to be used for Zero Trust, or the significance of CDM does not depend on Zero Trust."
  • "Figure 2-2 Zero Trust Architecture Deployment Cycle" is inappropriate here because it is a zero Trust realization method. How about replacing the figure in "Outline of the Japanese ToBe Model that Realizes Continuous Diagnosis" on page 10 of "Examination of Next-Generation Type security Architecture in DADC" in the Second Examination Materials with others?
  • "Continuous risk assessment and response (CRSA) aims to promote the understanding of assets by utilizing asset management tools, etc. (2.4. Relationship with the application policies of the Zero Trust Architecture (1) Understanding of assets)", since the purpose of CRSA seems to be only asset management, it is suggested to change the description to "Continuous risk assessment and response (CRSA) aims to understand assets by utilizing asset management tools, etc. and realize (1) - (4) described in 3.2.1".
  • Regarding "(2) Confirmation of the status of assets," it is difficult to convey what CRSA should realize with the current description. It is considered that CRSA will be positioned to provide attribute information to zero Trust by realizing attribute-based authentication and authorization to zero Trust. Therefore, why don't you revise it so that it can be conveyed?
  • Regarding "3.1. Overall Architecture", it is not clear where the primary information (IT asset information, certification log, network log, alert information, data audit log, cloud information) to be captured in the dashboard, which is equivalent to "ToolsandSensors" of the CDM, is. If "reference database system within the government" alone or "reference database system within the government", "reference database system outside the government", and "government information system in ministries and agencies" are applicable, it should be clearly described and expressed so that they can be identified.
  • Regarding "3.2 Governance Layer," we believe that there is generally no problem with the description of the governance layer. Regarding "3.2.2 Target Area (1) Management of Terminals, Server Equipment, etc.," it is necessary to expand the scope of monitoring to Communication Line Devices, other devices (multi-purpose machines, IoT devices, etc.), and clouds in the future, so we believe that this should be clearly stated.
  • With regard to the understanding of asset management, it is requested that vulnerability management be added, and that consideration be given to mentioning not only functional requirements but also operational requirements that do not cause operation failure in view of actual operation.
  • If it is determined that asset management and vulnerability management are necessary, we would like to ask you to consider the keyword "cyber hygiene" again in light of the trend of CISA in the United States.

End