「Security」カテゴリーアーカイブ

Cybersecurityの研究開発ロードマップ”CyberROAD”

CyberROADとは、EUのFP7にて実施された一つのプロジェクトである。本プロジェクトでは、サイバーセキュリティの研究開発のロードマップを策定すべく、サイバーテロリズムおよびサイバー犯罪に対抗するための課題を特定した。
本プロジェクトの成果報告書によると、下記の18エリアが重点課題として特定されている。

  1. Anti-malware Research
  2. Authentication and Anomyzation (cybercrime attribution)
  3. Behavioural security and NO-PWD systems
  4. Cryptography and Public-Key Infrastructures
  5. Cybercrime and the Economy
  6. Computer Forensics
  7. Healthcare Systems
  8. SCADA & CIP
  9. Information Exchange
  10. Law & Order
  11. Networking
  12. Cyber Threat Awareness
  13. New objects and ‘disappearing computing’
  14. Social Resilience
  15. SDCL & Architectures
  16. Threat intelligence and Attack Detection
  17. Trust chain & identity
  18. Vulnerability Assessment

尚、本プロジェクトでは、11か国に存在する計20組織からなるCyberROADコンソーシアムが設立され、その中で検討を実施してきた。
更なる詳細は、次のURLを参照のこと。

http://www.cyberroad-project.eu/

EU全体でのサイバーセキュリティのあり方を定めるNIS Directive

サイバーセキュリティに関する法律は、各国において定められている。複数の国の集合体であるEUにおいても、その全体を対象とした法律が存在しおり、具体的には、The Directive on security of network and information systems (NIS Direcive)がそれに相当する。これは、EU全域において、サイバーセキュリティに関する発展のレベルを地位格差なしに同等レベルまで引き上げるための法律である。欧州議会は2016年7月に本法律を可決し、同年8月から施行されることとなっている。

NIS Directiveの具体的な中身については、今後追記予定。

予算教書を見れば、USの予算の詳細がわかる

米国には、3大教書と呼ばれるものがある。
1. 一般教書 (State of the Union Address)
2. 予算教書 (Budget Message of the President)
3. 大統領経済報告 (Economic Report of the President)

このうち予算教書とは、毎年2月に米国大統領が議会に提出する予算の編成方針である。

Webにて公開されている。
https://www.whitehouse.gov/sites/default/files/omb/budget/fy2017/assets/message.pdf

日本の外務省は、本文書の概要を日本語で公開している。データのグラフ化などもされており、日本国民がわかりやすく理解できるよう工夫が凝らされている。
http://www.mofa.go.jp/mofaj/na/na2/us/page25_000342.html

ここを見ると、例えば予算に占めるサイバーセキュリティへの投資額の割合などがわかり、各国のその割合を比較することで、サイバーセキュリティに対する国の本気度がわかる。

Telnetの利用は避けるべき

telnetの利用は避けるべきというのは今や常識であるが、その理由は単純。
telnetはログインの際の認証情報も認証成功後の通信内容も平文でやり取りする。そのため、ネットワーク上での盗聴が容易になされてしまうという問題を抱えており、セキュリティの観点から望ましいプロトコルではない。

IETF MILEにて議論されているROLIEの概要

通称ROLIEと言われる本ドラフトの正式名称は、draft draft-ietf-mile-rolie: “Resource-Oriented Lightweight Information Exchange”である。ここでは本ドラフトの概要を説明する。

本draftは、Atom Publishing ProtocolとAtom Syndication Formatを拡張することにより、セキュリティ関連情報を効率的に公開・共有可能にするものである。

 

詳細は後日。

ITU-T CG-IoTsecの議論の状況

ITU-Tでは、SG17とSG20が、IoT Securityに関する検討scopeのっ境界線を引くべく、CG-IoTsecにて議論を実施している。2016年3月のSG17会合でCG-IoTsecから挙げられた報告によると、SG17とSG20のSecurityに対する考え方が大きく異なっており、scopeの境界線に合意するのに難航しているとのことである。

さてこの議論、納得のいく結論が出るのだろうか。どこかのタイミングで上が決定する必要があるようにも思う。TSAGが、ある程度の見解を出しているので、今後まとまっていくのかが注目される。

RFC 5023: The Atom Publishing Protocol

The Atom Publishing Protocolは、Web resourceをpublishおよびeditするアプリケーションレベルのプロトコルである。本プロトコルは、HTTPを利用してAtomフォーマットの文書を交換すものであるが、Atomフォーマット自体は、RFC4287 “The Atom Syndication Format”にて定義されており、本文書の範囲外である。

本文書では、このAtom Publication Protocolで利用する文書を説明するのと同時に、Web Resourceのpublishおよびeditをするためのプロトコルを定義している。

 

文書の構造の定義

2種類のdocumentを定義している。

  1. Category document: カテゴリのリストを定義。
  2. Service document: ひとつ以上のCollectionをグルーピングしたWorkspaceのリストを定義

CollectionとはResourceの集合体で、そのFeedには、自身のIRIと、member resourceのmetadataが記述される。

RFC5023のSection 8.2の例の抜粋を参考として下記に記載

<collection href=”http://example.org/blog/pic”>
<atom:title>Pictures<atom:title>
<accept>image/png</accept>
<accept>image/jpeg</accept>
<accept>image/gif</accept>
</collection>

また、collectionの中には、利用可能なcategoryを指定することもできる。カテゴリのリストを直接collectionの中に記述してもよいし、href attributeを利用して別の場所で定義したcollectionを参照してもよい。そのリストは、fixedでも、open setでもよく、指定できる。

Collectionの中に記載されるResourceのことを、Member Resourceと呼ぶが、このMember Resourceには、Entry ResourceとMedia Resourcerという2種類が存在する。

 

プロトコルの定義

Atom Publishing Protocolは、Member ResourceをHTTPを利用してretrieve、create、edit、removeするプロトコルを定義している。そのそれぞれのケースに応じて、利用するHTTP methodが異なる点には注意が必要。

  • retrieveするにはGETを利用
  • createするにはPOSTを利用
  • editするにはPUTを利用
  • removeするにはDELETEを利用

尚、POSTを用いてCollectionにcreate requestをする際のツールとして、Slug headerというものが存在する。本ヘッダを利用すると、本ヘッダ中の情報を活用してMember URIを作成してくれる。