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 ".

Second Next-Generation Security Study Meeting in Architecture

Overview

  • Date and time: March 15, 2022 (Tue) from 13:00 to 15:00
  • Location: Online
  • Agenda:
    1. Opening
    2. Agenda
      1. Application of zero trust and Architecture
      2. Technical Report on the Introduction of Continuous Risk Diagnosis and Response (CRSA)
      3. Free discussion
    3. Adjournment

Material

Reference Information

Summary of the Proceedings

Date and

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

US>

  • Held online

Attendees

Member of the

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

* 1 We received comments by email on Thursday, March 17, 2022.

Observer

  • National Center of Incident Readiness and Strategy for Cybersecurity (NISC)

Digital Agency (Secretariat)

  • Group of Strategy and Organization Security Risk Management Team

Information-Technology Promotion Agency, Japan

  • Digital Architecture Design Center

Summary of the proceedings

  • The secretariat explained Document 1 "Policies for Application of zero trust and Architecture," Document 3 "Technical Report on Introduction of Continuous Risk Assessment and Response (CRSA)," and Document 5 "Future Policies in View of Implementation of CRSA."
  • In the free discussion on the Guidelines for the Application of zero trust and Architecture, the following comments were mainly made.
  • In addition to the assets that are accessed, it is also important to evaluate the subjects who seek access to resources within the organization. Since there is no description of such subjects, it is necessary to establish such a guideline.
  • The term "identification" in "asset identification" is not used in guidelines and other documents. It is considered appropriate to change it to a term that leads to the next work process, such as "identification" or "identification".
  • The definition of some words is unclear and there are some fluctuations. For example, it is better to avoid using the word "properly" in the guidelines because it is a qualitative expression. The word "resource" is used in multiple meanings. It is necessary to review the word. In addition, there is a possibility that the word "journey" cannot be understood. It is better to avoid using it because the way of reading varies depending on the reader.
  • Asset management and identification, identification, and valuation lead to shadow IT problems in local government offices, which often fail in the first stage of the application of zero trust and Architecture. This measure can bring out shadow IT problems.
  • There was no description of BYOD. There are data showing that BYOD is used more frequently than official devices in each ministry and agency, so it would be better to include it.
  • It would be better to describe what changes will occur as a result of zero trust / Architecture. It is necessary to give an image of the current system and the world after the application of zero trust / Architecture.
  • "Figure 1: Core Logical Components of zero trust" does not represent the strict world of zero trust and Architecture. It may give the misunderstanding that it only covers teleworking and remote access. In reality, there are various interactions with access requests. For example, in risk-based authentication, additional elements are confirmed. Such interactions are not represented.
  • In order to understand the world of zero trust Architecture, it is necessary to explain various terminologies. The current terminologies are few and need to be expanded.
  • Since subjects and objects change from time to time, it is necessary to organize resources based on the whole.
  • In Figure 1: Core Logical Components of zero trust, Identity Management goes directly to the PEP, where it should be preceded by Entity Authentication, which takes control at the Authenticated Result Policy Enforcement Point. These mechanisms cannot be expressed.
  • In cases where there are circumstances that require the continued use of existing systems for which zero trust and Architecture are difficult to apply, it is considered necessary to require efforts to ensure inter-operability through function upgrades, etc.
  • Since users may be confused during the application (migration) process, it is necessary to consider setting a migration period, such as allowing the old and new systems to coexist temporarily.
  • It may be necessary to link systems around the zero trust Architecture, such as the personnel management system, identity management, asset management, and procurement management, with the zero trust Architecture.
  • By managing users and assets based on the principles of zero trust and Architecture, it is possible to gain an understanding of the content as it relates to the people who actually manage it.
  • The use of words, including terminology, is too coarse and needs to be revised. It is requested that the definition be clarified by the writer.
  • Zero trust is a collection of concepts and ideas, and since it is a cybersecurity plan, it is not a system design or Architecture reference, but designers and prospective implementers always consider how to implement it. I think that the zero trust conformance technology area of "Forrester'sZeroTrusteXtended (ZTX)", 1) Networksecurity, 2) Datasecurity, 3) Workloadsecurity, 4) People/workforcesecurity, 5) Devicesecurity, 6) Visibilityandanalytics, 7) Automationandorchestration, can be used as a reference.
  • An example of zero trust application is presented.
  • As examples of the purposes of DX-related zero trust expected by private companies, there are "opening of systems," "overall application of teleworking," "use of proxy cloud," "strengthening of security of teleworking terminals," and "change of network environments suitable for use of cloud."
  • The terms "Perimeter Security" and "zero trust Architecture" (hereinafter referred to as "ZTA") are defined. The definitions in the references should be referred to here.
  • In NISTSP800-207, it is requested that the described solutions should be considered in accordance with "intelligent switch", "router", "firewall", "gateway for special purpose", "software agent", "endpoint firewall", "SDP", "low-layer network stack", "SDN", and "IBN".
  • In the open discussion on the "Technical Report on the Introduction of Continuous Risk Assessment and Mitigation (CRSA)," the following comments were mainly made.
  • We felt that it would be better to describe the respective viewpoints of the ASO repository and the dashboard in the summary section.
  • Categories of network security that are not defined in the US CDM are not defined at present and need to be considered.
  • It is also necessary to study in depth the events that are actually occurring, such as threat intelligence.
  • In overseas initiatives, when a CVSS fails to make a determination, management is attempted based on a total score of five scores: system compliance (e.g., using a public CIS benchmark), privileged ID (e.g., monitoring a least-privileged model), passwords (e.g., stored in plaintext), expired certificates (e.g., revocation status of certificates), and insecure TLS or SSL (e.g., non-TLS1.3 or non-SSL3.0).
  • Regarding Document 3, we think that an item should be added to sort out the positioning of existing systems such as GSOC and the Government Information System Management Database (ODB).
  • With regard to "2.1. Positioning of Constant Risk Assessment and Response (CRSA)," under the current wording, CRSA is understood as only one of the elements for realizing zero trust and Architecture. Therefore, it is necessary to explain the mechanism of CRSA itself in the first paragraph.
  • It is necessary to change the description of "(3) What is happening on the network? Understand what kind of traffic patterns and messages between systems are occurring" because it is difficult to convey the intention.
  • Regarding "2.1. Positioning of continuous risk assessment and response (CRSA)", "Although there is a conceptual diagram showing the relationship between the logical components that constitute zero trust Architecture, the relationship is such that the zero trust can refer to the CDM in the first place, and it is not that the CDM is stipulated to be used for zero trust or that the raison d'etre of the CDM depends on the zero trust.
  • "Figure 2-2 Development cycle of zero trust and Architecture" is inappropriate here because it is a method of realizing zero trust. How about replacing the figure of "Overview of the Japan ToBe Model that Realizes Continuous Diagnosis" on page 10 of "Consideration of Next-Generation Security Architecture in DADC" in the second examination material with something like that?
  • In "2.4 Relationship with Application Policies of zero trust and Architecture (1) Understanding of assets", the purpose of CRSA seems to be only asset management. Therefore, how about changing it to "The purpose of CRSA is to understand assets using asset management tools and to realize (1) - (4) described in 3.2.1"?
  • With regard to "(2) Confirmation of the state of assets," the current description is difficult to convey what should be realized by the CRSA. By realizing attribute-based authentication and authorization in the zero trust, the CRSA thinks that it will be positioned as providing attribute information to the zero trust. How about revising it so that this is conveyed?
  • Regarding "3.1. Entire Architecture," it is not clear where the primary information (IT asset information, authorization logs, network logs, alert information, data audit logs, cloud information) captured in the dashboard corresponds to the "ToolsandSensors" of the CDM. If "reference database systems within the government" or "reference database systems within the government," "reference database systems outside the government," or "government information systems of ministries and agencies" correspond to these, they should be clearly described and expressed so that they can be understood.
  • With regard to "3.2 Governance Layer," there is basically no problem with the description of the governance layer. With regard to "3.2.2 Target Areas (1) Management of Terminals and Server Equipment, etc.," it is necessary to expand the scope of monitoring to Communication Line Devices, other equipment (multi-purpose machines, IoT equipment, etc.), and clouds in the future, and thus it should be clearly stated.
  • Regarding the understanding of asset management, GOJ requests USG to consider adding the management of vulnerabilities and referring to not only the function requirements but also the requirements for ensuring trouble-free asset management with a focus on actual asset management.
  • If it is determined that asset management and vulnerability management are necessary, we would like you to consider the keyword "cyber hygiene" again, taking into account the trend of the U.S. CISA.

Greater than or