ささみさんのメモ

ささみさんのメモです。首都圏近郊でSEをしています。

R1.NW午後問題

 まだ家時間があるので、今回は「ネスぺR1」です。昨年のうちに「ネスぺの基礎力」に目を通しておけたので、不明点を確認しながら進んでいます。

 

昨年は午後Ⅱの社内LAN再構築で、VoIPの設定がババンっと出ていますね。実務で電話線まで含めた設計構築に関わることが全く無いのでなかなか入って来ないのですが「もし私がこの会社のシステム部だったら…」と頑張って考えて覚えることにします。(ちなみに現在の知識だけで挑んだところ、11/100点でした…--;)NWまで取得できていれば、社内のテクニカルな業務は一通りOKなはず…!将来はどんな会社で働こうかな♪ 夢は膨らみますね♪

 

…ということで、まずは午後Ⅰからです。

 

午後Ⅰ

問1 3/50 (⁉)

2個のONUはBGPで、コアルータ→L3SWはLAGPで、S3LW同士はVRRP冗長化しているデータセンターのシステムです。こっそり回線負荷の計算問題も出題されていました。基本的事項も多かったです。復習につとめます。

 

問2 12/50 (⁉)

WebサーバをLBを使用して複数台で冗長化する内容で、ライトで分かりやすい出題でした。実際にWebシステムを扱っている方は普段の知識で解けるのではないでしょうか。私はインフラ屋さん(サーバ運用構築とかしています)なのでHTTPリクエスト??ヘッダ??と来ると硬直します…。何をどこまで覚えればよいのか、過去問をやって様子を見たいと思います。

 

問3 12/50 (⁉)

中規模企業内システムで、セキュリティチェックOK端末のみ持込可にするための高セキュリティ設定に関する出題です。想像しやすい出題方式で助かります。

 

ということで1回解いてみたんですが、実際にやってみると2割しか取れませんでした。本には過去問対策として「4年分×3回」と書かれています。実務で明らかに経験が足りない場合、直近の出題傾向を掴むには過去問をやりこむしかないですね。

 

…これは…試験前はお祭り騒ぎをしているかもしれません(頭の中が( ´∀` ))

 

登録セキスペ オンライン講習A 3・4 追記2 - セキュリティに関する各種機関

セキュリティに関する各種機関についての学習メモ。

※各項目は講習教材より抜粋し、編集しています。

 
<セキュリティ対策方針を立てる機関>
日本国内のセキュリティ対策方針について確認したい場合、下記のような情報を参照することになります。

IPA: https://www.ipa.go.jp/

 重要なセキュリティ情報、脆弱性情報、その他のコンテンツ

経済産業省https://www.meti.go.jp/policy/netsecurity/ 

 情報セキュリティ対策

総務省https://www./soumu.go.jp/main_sosiki/joho_tsusin/security/

 国民のための情報セキュリティサイト

普段見慣れませんが、上記のほかに、下記のような組織もあります。
まるでドラマやアニメの世界のようですが、知っておいて損はなさそうです。

警察庁: https://www.npa.go.jp/cybersecurity/

 サイバーポリスエージェンシー

     https://www.npa.go.jp/cyber/

 サイバー犯罪対策プロジェクト

NISC: https://www.nisc.go.jp/materials/index.html

 内閣サイバーセキュリティセンター。
 国の情報システムへのサイバー攻撃の監視や対処を行う。国のサイバー攻撃対策の司令塔。2000年に設置、センター長は内閣官房副長官補が兼務する。
★ここを見ると、日本のセキュリティ対策の変遷や現在の方針などが分かります。

 

<セキュリティ情報を周知する機関の一般的な略称>
★言葉が混同するので、使用方法に注意。

CSIRT(シーサート):Computer Security Incident Response Team
「コンピュータセキュリティインシデント」に関する報告を受け取り、調査し、対応活動を行う組織体の名称です。(一般名詞)

https://www.nic.ad.jp/ja/basics/terms/csirt.html

イメージは、有事の際の町内会の「火消し役」「セキュリティインシデントの消防署」のような感じ…だそうです。

https://www.sbbit.jp/article/cont1/24965


CERT(サート):Computer Emergency Response Teamなど
コンピューターへの不正アクセス脆弱性などのコンピュータセキュリティインシデントに対応する活動を行う組織です。具体的には、コンピュータセキュリティインシデントについて、情報収集・分析を行い、結果の公表や関係組織との調整により、問題の解決・再発の防止を図っています。

https://jprs.jp/glossary/index.php?ID=0127

 ちなみに、CSIRT=CERTの意味で使用されることもあるようです。また、現在様々な「CERT」がありますが、組織によって何の略称かが異なるようです。一筋縄ではいきません。

https://www.jpcert.or.jp/tips/2004/wr044201.html

重要な組織については、「これはどのように発足して、どんなことをしている機関なのか?」を理解しておく必要がありますね。

 

<セキュリティや脆弱性に関する情報を周知・発信する機関について>

(国内)
JPCERT/CC: https://www.jpcert.or.jp/

1992年頃よりボランティアベースで発足(現在は一般社団法人)。日本国内の情報セキュリティ対策組織。日本国内の脆弱性情報の受付窓口。また、日本国内で重要なインシデントが発生した場合はCSIRTとなり問題の解決につとめる。IPAと共同で、日本国内の脆弱性情報に関するポータルサイトJVNを運営している。

(海外)
US-CERT: https://www.us-cert.gov/ncas/alerts

米国国土安全保障省(DHS)配下の情報セキュリティ対策組織(参考:https://www.jpcert.or.jp/magazine/security/field-us.html

CERT/CC: https://www.kb.cert.org/vuls/

米国カーネギーメロン大ソフトウェア工学研究所(Carnegie Melon University, Software Engineering Institute)に置かれているセキュリティ対策組織。
ネットワークに関する不正アクセス、不正プログラム、システムの脆弱性問題などに関して、情報を収集し、非常に素早い分析を行い、その結果の発表を行う組織。
(参考:https://www.atmarkit.co.jp/ait/articles/0401/01/news131.html

NIST: https://www.nist.gov/

NISTとは、アメリカ合衆国連邦政府機関の一つで、科学技術に関連する標準についての研究などを行う機関。
ITの分野では、連邦政府の利用する暗号技術などの情報セキュリティ関連規格が有名で、DESやAES、FIPS-140/140-2など、NISTに標準として採用された技術が世界的な標準として広く普及することが多い。(参考:http://e-words.jp/w/NIST.html
近年では、よりITに特化したフレームワークとして、NISTの定めたサイバーセキュリティフレームワークが世界的に有名なようです。(参考:https://www.cybereason.co.jp/blog/edr/2786/

 

脆弱性ポータルサイトやデータベース>
JVN: https://jvn.jp/
JVNJPCERT/CCIPAが共同で運営する脆弱性情報ポータルサイト
日本で検挙された情報以外に、海外の調整機関(US-CertやCERT/CC)と連携した脆弱性情報を載せている。

JVN iPedia: https://jvndb.jvn.jp/

日本国内外を問わず、日々公開される脆弱性対策情報を収集、蓄積することを目的とする。内容はJVNで提供されているもののほか、国内製品や国内流通製品の脆弱性情報が掲載される。

Vulnerability Notes Database:  https://www.kb.cert.org/vuls/ ←CERT/CCと同じ
CERT/CCのデータベースの名称。
JVN脆弱性情報の中で「VU#」で始まるコードはこのデータベース上のもの。

CVE: https://cve.mitre.org/
サイバーセキュリティの脆弱性に関する共通名の辞書。
非営利団体MITRE社が番号付けする「CVE識別番号」(共通脆弱性識別子)で有名。
(参考:https://www.ipa.go.jp/security/vuln/CVE.html)

NVD: https://nvd.nist.gov/vuln

NISTの脆弱性データベースの名称。CVEとリンクしている。

 

情報収集の際は上記サイトを中心に調査していくことになるんですね。例えばJVNJVN iPediaで公開時期が同時ではない場合もあるとのことで、注意が必要です。

 

講習ではほかに、CVSS(Common Vulnerability Scoring Syste)の評価項目詳細や
CWE(共通脆弱性タイプ一覧)などについて学習しました。

全部覚えて使いこなせたら一流サイバーエンジニア!? 道のりは長そうです…!

 

にほんブログ村 IT技術ブログ IT技術メモへ
にほんブログ村

登録セキスペ オンライン講習A 3・4 追記1 - 各種脆弱性調査ツール

下記の4つが脆弱性の調査に有用なツールが紹介されていました。

少しだけ触ってみたり調べてみたのでメモです。

 

Fiddler

ネットワークキャプチャツールです。クライアントPCへインストールし、通信先に対するHTTPリクエスト/レスポンスなどがチェックできます。https://www.ipa.go.jp/files/000077215.pdf

ツール名で検索したら2019年度のIPAの集合講習用教材が出てきました。とりいそぎ試してみる分にはとても分かりやすかったです。どうも集合講習だと実際に手を動かしての学習があるようですね。

 

OWASP ZAP

オワスプ社のウェブアプリケーション脆弱性ツールです。Fiddler同様クライアントPCへインストールして使用します。※使用するには先にJREのインストールが必要です。

講習教材に、注意点として破壊検査を行うと書かれていますので気を付けてください。下記サイトでも使い方が紹介されています。宛先サイトを指定するだけで脆弱性チェックができます。

https://www.shadan-kun.com/blog/vulnerability/2961/

ちなみに、試しにこのサイトのチェックをしてみたらアラートが7件も…

 

f:id:ano_sasami:20200429220528j:plain

owsp zapでのこのブログのスキャン結果です。

 

OpenVAS

オープンソース脆弱性診断ツールです。英語のみ対応らしいです。

下記サイトで使用例が紹介されています。Apacheを動作させているサーバへインストールし、自サーバの各種脆弱性や、他のサーバへ向けた攻撃に利用される危険性などについて調査することができるようです。

https://knowledge.sakura.ad.jp/342/

 

Nmap

ポートスキャンツールです。ネットで検索すると、「コマンド」として使用方法が書かれたサイトが数多くヒットします。ポート状態の調査で使用できるものとしてはOS標準でnetstatやssコマンドがありますが、nmapは宛先IPアドレスを指定・実行するだけで「XX番開いてた!」「YY番閉じてた!」と報告してくれる、何かと使い勝手が良いやつ…らしいです。OSやサービス名、そのバージョン名の取得もできるとか。

https://beginners-network.com/nmap.html

ちなみにこちらの方のサイトで、バージョン名やOS名を検知した際のApacheアクセスログの動きが紹介されています。

http://bttb.s1.valueserver.jp/wordpress/blog/2019/01/06/nmap/

 

 

Fiddlerの参照先サイトに記載されているAppGoatは、IPAが開発した脆弱性体験学習ツールです。脆弱性の概要や対策方法など、脆弱性に関する基礎的な知識を実習形式で体系的に学べるらしいです。(今回の講習教材にこのツールの紹介が10数ページほど載っています。)

システム管理者/運用者/開発者は、この学習を通して安全なウェブサイトの作り方を学ぶことができます。12テーマの脆弱性(例:SQLインジェクションCSRF、…etc.)について学習することができ、脆弱性ごとの習熟度テストで理解度が確認でき、全脆弱性に関する総合テストによって評価されます。…とのことです。実践的な手法で正しいスキルが身に着けられるツールのようです。どんな脆弱性も検出できるようになりますね!

個人でもIPAへ利用申請すれば使用できるようですが、集合研修で講義を聞きながら進められると理解も早くて助かります。集合研修は2年後なんですが、果たしてどうでしょうか…?

脆弱性体験学習ツール AppGoat:IPA 独立行政法人 情報処理推進機構

 

追記: 上記IPAに問い合わせたところ、Fiddlerの参照先サイトはセキスペの集合研修で使用しているものではないのだそうです。また、IPAのセキスペ集合研修でAppGoatを扱う予定も特に無いとのことです。個人使用を考えている旨伝えたところお勧めしてもらえたので、時間があるときにチャレンジしてみたいと思います。

 

にほんブログ村 IT技術ブログ IT技術メモへ
にほんブログ村

登録セキスペ 法改正について

 最近法改正されて現在は不要となっているようですが、私が申請したH30年度は登録時にIPAへ提出する書類に法務局発行の「登記されていないことの証明書」、本籍地発行の「身分証明書」がありました。(取り寄せが大変でした)

「登記されていないことの証明書」は青年被後見人、被保佐人ではないこと、また「身分証明書」は禁治産宣告・後見人登録通知・破産宣告を受けていないことを証明する書類です。せいぜいこの書類で証明できるのは「知的障害・精神障害がないこと」「痴呆でないこと」「判断力が低いために自己破産を起こしていないこと」くらいですが、要は「自分の財産を守るための判断力が無い」と法的に判定されている人はセキスペに登録できない仕組みでした。

後見人制度とは→https://isansouzoku-guide.jp/seinenkoukennin

会社や個人の利益を守るための職種であるということを象徴しているようですね。

 

ほかにも法改正によって変更した点がありそうですが、詳細は後日フォローアップしておきます。

登録セキスペ オンライン講習A 5・6

 倫理性に関する話です。この章では、技術者の意思決定は社会に多大な影響を与える故に、倫理を徹底することの重要さが強調されていました。企業や個人の不正に直面したとき、私たちは適切な行動を起こし問題の解決を試みないといけません。

 

内部告発のための公益通報の要件に関する項目が興味深かったので載せてみます。※下記講習教材より抜粋

De George R.T. " Business Ethics" (1989)による定義:

1.一般大衆に被害が及ぶか

2.上司へ報告したか

3.内部的に可能な手段を試みたか

<社会人として通報→1~3を満たすとき、公益通報は道義的に許されるといえる>

4.自分が正しいことを示す明らかな証拠があるか

5.リスクを十分考慮し、公益通報によって問題を解決できるか

<技術者として通報→4,5を満たすとき、公益通報を行うべき>

出典はITではなくビジネスに関する本でしょうか。エンジニアとしての行動としてあてはめて考えると…ということですね。影響力の大きな脆弱性情報が隠蔽されそうなときは、まずは慌てず内部的に可能な手段を試みること、もしそれだめなら外部へ相談することが求められています。

公益通報とは →https://www.toben.or.jp/know/iinkai/koueki/kouekitsuho/

 

また、国際的なエンジニアの倫理規定としてIEA(国際エンジニア登録機関)が「IEA倫理規定」を定めています。

普段現場で技術系の業務をしている人には当たり前のものとして身についている価値観かと思いますが、これから業務に入る人は一読して胸に留めておくと参考になると思います。

 

登録セキスペ オンライン講習A 3・4

Japan Vulnerablility Notes(JVN)概説【全編】【後編】を受講しました。

 

主なトピックはこんな感じです。

脆弱性周知のための各種サイトとその特性

・CVSS値の決定方法

・各脆弱性チェックのためのツールとその使い方

 

各セクション受講後に確認テストがあるのですが、なかなか合格できず何回も再チャレンジすることになりました。ソフトウェア製品開発をしている会社さんなんかで就労しようと思うとフル活用しそうな知識です。

脆弱性チェックのためのツールは個人でも使用して良いそうなので自分でやってみたいです。

 

「受講目安は6Hだから1~2日で済むかなー」と思っていたのですが、ことのほか時間がかかりました。続きは来週実施します。

登録セキスペ オンライン講習A 1・2

 

「情報セキュリティ早期警戒パートナーシップ」

 

という長い名前の協定があります。

日本国内の脆弱性関連情報の対策の普及を図るため、2004年からIPAにより運用されているものです。

 

今回の講習では、この協定における登録の流れについてひととおり学習しました。

 

 

びっくりしたのは、ソフトウェア製品については、脆弱性の発見があっても公表タイミングがずいぶん遅くなるケースが想定されていることです。

安全性を考慮すると発見者がIPAに連絡したら即時で「調査中だが危険性が高い」等のステータスで公表してしまって良いように思えます。

が、実際のビジネスシーンではそのようにはいかないものなのでしょうか。そのあたりは競合との競争など、込み入った事情があるのかもしれませんが…。

 

<想定される通常のケース>

連絡フロー:発見者→IPAJPCERT/CC→製品開発者

JPCERT/CCから製品開発者へ最初の連絡を試みた日を起算日とし、

JPCERT/CCは、起算日から45日後を目安として公表日を決定する。

 

<公表が遅れるケース>

・開発者と連絡が6ヶ月以上とれない場合

IPA内の公表判定委員会で公表可否を判定。

公表する場合は、製品開発者名や脆弱性情報等をJVNで公表する。

 

これは…万が一後者にあたるシステムを使用していた場合は災難ですね…。

ちなみに、通常運用でも45日かかり、発見者は公表日までみだりに脆弱性情報を他人に漏らしてはいけない規定になっています。

ということは、製品脆弱性についての世間公表の第一報は、連絡をもらった製品開発者が自発的に公表するケースのみ。製品開発者の高い倫理観を信用するシステムになっているようです。

 

しかし比較的自由に誰でもプログラミングもアプリ・システム開発もできてしまう時代、懸念があるならもう少し高い統制力で危険を管理しても良いような気がしますが…

 

スライド冒頭には、脆弱性を指摘された際の開発者の立場としては「発表に対してネガティブな印象を与えてしまう」「責任問題やプライド等が気になりインシデント報告を行いたくない」等の問題が…などと書かれています。

想定できるリスクがあるなら回避すべきだと思うのですが、どうなんでしょう。

 

私は普段ユーザーの立場にいるので、「危険があるかもしれない」ソフトの情報が公表されないケースが想定されるのは、とても不安なことです。

 

 

ちなみにこの協定の適用範囲は

・国内で利用されているソフトウェア製品(ただしプロトコルや暗号アルゴリズムなど仕様自体の脆弱性は含まない)

・日本国内からのアクセスが想定されるサイトで稼働するウェブアプリケーション

です。

脆弱性を発見したら迷わずIPAへ相談したら良いですね。

 

 

https://www.ipa.go.jp/files/000059694.pdf

(情報セキュリティ早期警戒パートナーシップガイドライン