OSCAL(Open Security Controls Assessment Language)とは、次世代の情報セキュリティの管理方法だ
OSCALとは主に、セキュリティ・コンプライアンスの自動化・コード化を目的に、規格をコード化し、組織やシステムのProfileに沿って、組み込むComponent(hardware, software, services, policies, procedures, plans)の評価(Assessment)及び監査(Compliance)まで自動で行えるようにすることが目的のオープンソースの言語仕様だそうです。
現状のOSCAL 1.0ではNISTやISMSなどの規格や組織やシステムのセキュリティ方針をXML、JSON、およびYAMLで表現し、マシンが読み取れるようにしています。
OSCAL2.0では、セキュリティ監査の自動化の仕様を組み込み、各対応策に関する仕様を各サービスプロバイダーが実装することで、そのサービスプロバイダーをマネジメントシステムに組み込んだ際のセキュリティ監査を自動化することを視野に入れているようです。
2021/6/7に1.0.0のリリース,2022/1/30に1.0.1のリリースがされています。
非常によくできていてここまでシンプル化できてすごい！という感じです。
https://pages.nist.gov/OSCAL/concepts/layer/
# 言語仕様は大きく分けて3層に分かれている(Controls Layer, Implementation Layer, Assessment Layer)
## Control Layer
Controlsは組織(会社)やシステム(SaaS, IaaS)のポリシーを決める際に指針とするもので主に規格の集合であるCatalogとそれを元に作成したProfileからなります。
## Implementation Layer
ImplementationはControlsを元に、組織やシステムが使うツール=Component(hardware, software, services, policies, procedures, plans)とその組織やシステムのProfileを元にしたセキュリティ対策を実行する際のプランである System Security Plan(うちの組織やシステムではこのControlsを採用するといった方針)からなります。
## Assessment Layer
Assessment LayerはImplementationに対応した評価方法や評価結果で、評価方法・計画はAssessment Plan、実際の評価をした証跡(Citations and External Links Attachments and Embedded Images Evidence, Screen Shots, Photos, Interview Notes)はAssessment Results(定期的に実施するAssessment Planの場合、Assesmennt Planに対して複数作成される)、Assessment Resultに問題ありだった場合に是正策として作成されるのがPlan of Action and Milestones(是正されるまでcloseしない)のようです。Assesment Layerに関してはOSCAL2.0へ自動化に向けて改修が予定されているため、仕様が変わる可能性もあります。
# 各層の構成
# Controls Layer
## Catalog Model
CatalogはNIST 800-53, ISO27001, COBIT 5のことです。改訂などに対応できる想定のようで、Control(対応策: 「パスワードは8桁以上にする」)の集合(Controls)からできています。厳密には、NISTはhigh/middle/lowがあるので、パスワード管理の対応策の一つがパスワード管理の桁数であり、そのlowが8桁以上、等と内部で細分化されており、これをSystem Security Planで指定すると思われます。
## Profile Model
Profileは組織(会社)やシステム(SaaS, IaaS)にあうように一つか複数のCatalogから選んだControlの集合(Controls)です。これがImplementationやAssessmentの土台になります。
# Implementation Layer
## System Security Plan Model
System Security Plan は組織(会社)やシステム(SaaS, IaaS)の実際の設定で、そのシステムが使っているComponentとその実際の設定から出来ています。例えば「このSaaSのインフラはAWSをdockerで, プライベートネットワーク制限をかけた状態で使用している。このSaaSの顧客情報は紙でN社のアクセス権が保たれた場所で管理されている。」といったことが記述できると思われます。(control parameter values, responsible roles, implementation status, control origination, and a description of control satisfaction)
## Component Definition model
Componentは、System Security Planの構成要素となるものでハードウェア、ソフトウェア、サービス、ポリシー、プロセス、手順等のことです。(hardware, software, service, policy, process, procedure, or compliance artifact)
具体的にはMySQL 7.XやJava X.Xといったものから、AWS EC2、クリアデスクポリシー、等まで何でもComponentにあたるようです。
# Assessment Layer
## Assessment Plan model
一回か継続的なモニタリングのプランを記述するもの(an assessment or continuous monitoring activities)で、対象(Objectives: 多分Component)、評価者(Assessment Subject: locations, components, inventory items, and users)、評価に使用するもの(Assets: teams, tools, and rules of engagement)、人力・自動のアクション(Assessment Activities: manual and automated activities)を設定するものです。
## Assessment Results model
Assessment Planの証跡を含む結果を記述するモデル。
## Plan of Action and Milestones (POA&M) model,
Assessment Resultからわかる残留リスクを記述するためのモデル。
# 従来のISO27001的な階層の分け方はどこに対応するのか
- リスク
- 情報資産
- 委託先(供給者)
- 文書(ポリシー)
はどこに紐づくのか。
ここからは仕様に書いてあるわけではないのでかなり推察が含まれています。
## リスク
リスクは、Assessment ResultsやPOA&Mの中のelementとして存在します。
Controlが実施されていればRiskは除去されるはずなので、Controlを中心に据えて各レイヤーから参照できるようにしているOSCALではRiskの存在感は小さいのかもしれません。
## 情報資産・委託先(供給者)・文書(ポリシー)
情報資産・委託先(供給者)・文書(ポリシー)はComponent Definitionに含まれているようです。
Control対象は情報資産だけでなく、ポリシーや委託先等も含まれるためComponentとしてまとめられていると思われます。
規格としては人間を主体にして人間の操作対象である
情報資産 <=> リスク
という考え方で捉えると理解しやすいと思いますが、機械を主体にして、継続的なモニタリング(継続的なアセスメント)を前提にして考えると
対応策(Control) <=> 情報セキュリティの構成要素(Component)
という考え方は利にかなっているように思えます。
# 評価(Assessment)及び監査(Compliance)
英語のニュアンスがわからないので悩んでいますが、継続的なAssessmentは監査(Compliance)になっていくのでしょうか。最初のコンセプトの記事にはComplianceという言葉が頻繁に登場するのですが、現在の言語仕様にはAssessmentという言葉しか登場しません。
# OSCALの今後
NISTやGovReadyを中心に、オープンソースとして、Docker, IBM, ,,,等のメンバーが参加しているので近い将来情報セキュリティのメインストリームになっていくかもしれない一方で、SAML, OIDC, OAuth等、結局仕様が複雑で普及に長い時間がかかったことを考えるとゆっくりと時間をかけて成熟していくのかもしれません。
CatalogはNIST 800-53のみしか作成されておらず、ISO27001のCatalogはまだ作成されていませんが、NISTの整備がある程度進むかオープンソースへの参加者が増えれば一気に進む可能性がありそうな一方、むしろOSCALの仕様に合わせて文書構造を調整したほうがリンク構成等が洗練されそうなのでそういった形で、ISO27001自体を修正していく方向性は中長期的に有り得そうです。
個人的にはSAML等のIDの規格しか知らないため、OSCALはパット見複雑ですし、実際に各apiの結果も複雑であるため、各開発言語のラッパーができても受け入れられるのに時間がかかる気もします。
# 参考文献
日本語
https://www.jipdec.or.jp/archives/publications/J0005163_6
英語
https://www.youtube.com/watch?v=mo3J0tFxixg
https://www.youtube.com/watch?v=eP8K7piU5UQ
https://pages.nist.gov/OSCAL/presentations/oscal-ap-ar-poam-v3.pdf
https://pages.nist.gov/OSCAL/presentations/oscal-leveraged-authorizations-v6a.pdf
https://pages.nist.gov/OSCAL/learn/presentations/oscal-workshop-2021-02/
https://www.nist.gov/blogs/cybersecurity-insights/foundation-interoperable-and-portable-security-automation-revealed
https://blogs.easydynamics.com/2021/07/07/innovating-security-compliance-through-open-standards/
https://github.com/usnistgov/OSCAL
この記事が気に入ったらサポートをしてみませんか？