うかる!速攻サプリ@支援士
問題一覧
1
コネクター、エージェント、認証基盤(IAM)連携
2
SSOの認証情報さえあれば、あらゆるユーザーやエンティティーがVPNにログオン。ラテラルムーブメントでよってネットワーク内を自由に移動し、データ漏洩
3
①IAPでアプリにアクセスするのはコネクターであり、ユーザーは社内のリソースに直接アクセスできない。 ②IAPはアプリアクセスのたび、認証/認可。 ③IAPコネクターはFWの内側で運用可能 (コネクターは内→社外の通信(ポート 80/443)のみできればよい。FWの穴開け不要!! IAPコネクターからインターネット上のIAPに通信を開始するため
4
ZTNA。ソフトウェア定義の境界(SDP)上で動作
5
HMAC認証 事前に受信者と送信者が双方で「共通鍵」を保有 入力データに「共通鍵」を含めてハッシュ値を計算
6
ログイン時に送られるデータを攻撃者が記録し、それをそのまま再現することで不正にログインする ノンスと呼ばれるランダムな値を用いてメッセージと一緒にMAC値を生成
7
①第三者への証明 ②否認防止 送受信者共にMAC値の生成ができるから。 送信者が「そんなもの送ってない」と言えば否認可能 →ディジタル署名(電子証明書がある)で対応可能
8
知識 所有物 生体認証
9
ハッシュ関数とブロック暗号
10
①URLにセッションIDを埋め込む ②スクリプトを使用し、セッションIDを強制(クロスサイトスクリプティング) ③HTTPヘッダインジェクション 攻撃者がSet-Cookieヘッダを挿入することで利用者にCookieを強制
11
n(n-1)/2
12
2n、複数の人に同じ公開鍵を渡しても問題ない
13
💛Ping監視💛(死活監視) ICMP、装置のアップダウン エコー要求/応答 👕 🩵SNMP監視🩵👕 (状態監視) CPU/メモリ使用率、障害発生 「 コミュニティ」 コミュニティごとにMIBへのアクセス権限を分ける UDPの161(ポーリング)番、162(Trap)番
14
マルウェア配布サイトやフィッシングサイトなど既知の悪意あるFQDNへの接続を阻止するシステム
15
ユニバーサルプラグアンドプレイ(UPnP)
16
TCPコネクションの確認 コマンド
17
実行場所の違い XSS→Webブラウザ(Client) CSRF→Webアプリサーバ(Server)
18
OCSP (online certificate status/CRL(Certificate Revocation List OCSPの方がリアルタイム性が高いが、OCSPレスポンダが必要。仕組みが整っていない場合が多い。
19
CRYPTREC
20
WEBサーバの証明書のCAのデジタル署名がブラウザの持つルート署名と一致しない
21
①DNSSECでリクエストをデジタル署名で確認 ②キャッシュサーバとコンテンツサーバの分離。インターネットから問い合わせできないようにする。
22
ASCIIコード Shift_JIS
23
前方秘匿性
24
X.509
25
電子政府推奨/推奨候補/運用監視...暗号リスト
26
①SMTPにアクセスするユーザー認証 ②サーバはCAのデジタル署名を持ち、クライアントの証明書の妥当性を確認する
27
ポイズニングは、DNSの仕様によって有効期限内のキャッシュが 存在する間は再帰問合せできない!
28
ソースポートランダマイゼーション/DNSSEC
29
検査・隔離・治療 ①DHCP方式→手動IP設定はDHCPスプーで対策 ②認証スイッチ方式
30
ウイルス検出方法 ①パターンマッチング方式 定義ファイル ②ヒューリスティックスキャン方式 プログラムの動き →動的ヒューリスティックスキャン方式 (ビヘイビア法) サンドボックス
31
メッセージ認証では「共通鍵暗号方式」や「ハッシュ関数」を使ってチェック用データを作ります。 デジタル署名では「公開鍵暗号方式」を使ってチェック用データを作ります。 理屈や考え方は似ているけど、実際のやり方が違う
32
最近では、無線LANやSSL/TLS通信などのセキュリティプロトコルにおいて、 ストリーム暗号よりも主流 。 暗号化とデータ認証を同時に →データの機密性と完全性を同時確保
33
・Spoofing Identity なりすまし ・Tampering with data 改ざん ・Repudiation 否認 ・Information disclosure 情報漏洩 ・Denial of service サービス妨害 ・Elevation of privilege
34
=郵便配達(中間サーバ)では復号、解読されない 逆)TLS :ブラウザとウェブページ間の通信を暗号化し、メッセージは中間サーバーで復号化 →サーバーを管理するサービスプロバイダーはメッセージの内容を読むことができる!!
35
サーバ証明書を発行する過程で、発行依頼元のSNSがもつCAAレコードを確認
36
存在証明 日時に確かにデータが存在していた事の証明 完全性証明 日時以降そのデータが改ざんされていない事の証明
37
DoH(DNS over HTTPS)
38
リソースレコードに対するデジタル署名
39
DNSKEY
40
Endpoint Protection Platform エンドポイント保護 エンドポイント監視、脅威の検知、対処 ネットワーク全体を監視、脅威の検知、対処 IT機器から大量ログを収集、相関関係をもとに分析 SIEMの拡張、インシデント対応プロセスの自動対処 /総合分析、自動対処
41
Due care 遵守すべき要件を過失なく満たしている Due diligence 正当な注意義務及び努力
42
Brand Indicators for Message Identification DMARCと呼ばれる認証が成功したメールに対し企業ロゴを付与し信頼性を高める技術
43
無線LANが盗聴されるリスクを低下できる
44
「我々にメールを送るときには必ず有効な証明書とともにTLSで送ってください、そうじゃない場合は受け取りません!」 STARTTLSの弱点である「MTA同士でお互いTLSを使えたら使う(使えない場合は平文でOK)」を強化 SMTPクライアントがサーバの身元を確認 →TLSハンドシェイクでサーバーに証明書要求
45
①中間者(MITM)攻撃で平文ダウングレードさせられる ②送信サーバーの身元を認証する方法がない。 SMTPメールサーバーは証明書を検証しないから。
46
DNS-Based Authentication of Named Entities MTA-STS強化 STARTTLS 必須 TLS1.0以上、できれば1.2以上 DNSSECが検証できなければ配送しない 公開鍵 必須
47
①送りたいファイルを、1回限りの乱数によるセッション鍵で暗号化 ②①で用いたセッション鍵を、送り先相手の公開鍵で暗号化 ③暗号化ファイルとセッション鍵の両方を送信 なお、通信時、通信そのものの暗号化は行わない。 ④ファイルの送り先にて、自身の秘密鍵で、1回限りのセッション鍵を復号 ⑤④で得た1回限りのセッション鍵で、ファイルの中身を復号
48
IAP
49
STRIDEモデル ペネトレーションテスト(実現しうるシナリオをもとにリスクを評価,MITRE ATT&CK) 脆弱性診断(OWASP top10 に関連)
50
iptables
51
P346 プロセスハロウィング
52
バックアップデータを復元する手順を追加する
53
定期的な更新とパッチ適用
54
本社ネットワーク管理者へVPN接続に用いるIDを一時停止するように連絡する
55
CSIRT
56
GDPR General Data Protection Regulation
57
ARPテーブルを確認するコマンド エージェントが夜間に「arpコマンド」の実行を確認したら、当該PCをネットワークから隔離する。 ※マルウェアはarpコマンドで割り出したIPアドレスにpingで起動を確認
58
「number used once」の略で、「一度だけ使われる数」
59
送信者のTXTレコードの「IPアドレス」が, 送信元✉のIPアドレス(「MAIL FROMコマンド」のアドレス(=エンベロープFrom)) と一致するか? ▽SPFレコード 『IN TXT "v=spf1 +ip4:58.13.7.83( IPアドレス ) -all』 💬どうぞ見に来て頂戴~エンベロープFROMと一緒でしょ?
60
GET メソッド→外部に送信するRefererに秘密情報が含まれる CSRF(クロスサイト・リクエスト・フォージェリ) 「hidden パラメータ」に秘密情報を出力
61
ペネトレーションテスト リスク↓ C&Cサーバへの通信可否などのマルウェア感染 ・一般ユーザから管理者権限への権限昇格 ・推測されやすいパスワードやパスワードハッシュ
62
セキュリティチップ Trusted Platform Module(TPM)、 自己暗号化ドライブ Self Encrypting Drive(SED)、 高信頼ネットワークTrusted Network Communications(TNC)
63
「攻撃者が真正なサーバがもつ真正な公開鍵を事前に入手しておき、その値から計算したフィンガプリントを送りつけてしまう」 「ホスト認証」。 真正な公開鍵と対をなす秘密鍵を、このサーバは本当に持つか?をチャレンジレスポンスで検証する方法です。
230908
230908
k m · 13問 · 2年前230908
230908
13問 • 2年前10/11支援士
10/11支援士
k m · 19問 · 1年前10/11支援士
10/11支援士
19問 • 1年前支援士 前半
支援士 前半
k m · 37問 · 1年前支援士 前半
支援士 前半
37問 • 1年前ネスペ&支援 共通
ネスペ&支援 共通
k m · 21問 · 1年前ネスペ&支援 共通
ネスペ&支援 共通
21問 • 1年前9/8 支援士
9/8 支援士
k m · 28問 · 1年前9/8 支援士
9/8 支援士
28問 • 1年前August,2024
August,2024
k m · 8問 · 1年前August,2024
August,2024
8問 • 1年前仏語2024/11
仏語2024/11
k m · 15問 · 1年前仏語2024/11
仏語2024/11
15問 • 1年前仏 動詞
仏 動詞
k m · 9問 · 1年前仏 動詞
仏 動詞
9問 • 1年前問題一覧
1
コネクター、エージェント、認証基盤(IAM)連携
2
SSOの認証情報さえあれば、あらゆるユーザーやエンティティーがVPNにログオン。ラテラルムーブメントでよってネットワーク内を自由に移動し、データ漏洩
3
①IAPでアプリにアクセスするのはコネクターであり、ユーザーは社内のリソースに直接アクセスできない。 ②IAPはアプリアクセスのたび、認証/認可。 ③IAPコネクターはFWの内側で運用可能 (コネクターは内→社外の通信(ポート 80/443)のみできればよい。FWの穴開け不要!! IAPコネクターからインターネット上のIAPに通信を開始するため
4
ZTNA。ソフトウェア定義の境界(SDP)上で動作
5
HMAC認証 事前に受信者と送信者が双方で「共通鍵」を保有 入力データに「共通鍵」を含めてハッシュ値を計算
6
ログイン時に送られるデータを攻撃者が記録し、それをそのまま再現することで不正にログインする ノンスと呼ばれるランダムな値を用いてメッセージと一緒にMAC値を生成
7
①第三者への証明 ②否認防止 送受信者共にMAC値の生成ができるから。 送信者が「そんなもの送ってない」と言えば否認可能 →ディジタル署名(電子証明書がある)で対応可能
8
知識 所有物 生体認証
9
ハッシュ関数とブロック暗号
10
①URLにセッションIDを埋め込む ②スクリプトを使用し、セッションIDを強制(クロスサイトスクリプティング) ③HTTPヘッダインジェクション 攻撃者がSet-Cookieヘッダを挿入することで利用者にCookieを強制
11
n(n-1)/2
12
2n、複数の人に同じ公開鍵を渡しても問題ない
13
💛Ping監視💛(死活監視) ICMP、装置のアップダウン エコー要求/応答 👕 🩵SNMP監視🩵👕 (状態監視) CPU/メモリ使用率、障害発生 「 コミュニティ」 コミュニティごとにMIBへのアクセス権限を分ける UDPの161(ポーリング)番、162(Trap)番
14
マルウェア配布サイトやフィッシングサイトなど既知の悪意あるFQDNへの接続を阻止するシステム
15
ユニバーサルプラグアンドプレイ(UPnP)
16
TCPコネクションの確認 コマンド
17
実行場所の違い XSS→Webブラウザ(Client) CSRF→Webアプリサーバ(Server)
18
OCSP (online certificate status/CRL(Certificate Revocation List OCSPの方がリアルタイム性が高いが、OCSPレスポンダが必要。仕組みが整っていない場合が多い。
19
CRYPTREC
20
WEBサーバの証明書のCAのデジタル署名がブラウザの持つルート署名と一致しない
21
①DNSSECでリクエストをデジタル署名で確認 ②キャッシュサーバとコンテンツサーバの分離。インターネットから問い合わせできないようにする。
22
ASCIIコード Shift_JIS
23
前方秘匿性
24
X.509
25
電子政府推奨/推奨候補/運用監視...暗号リスト
26
①SMTPにアクセスするユーザー認証 ②サーバはCAのデジタル署名を持ち、クライアントの証明書の妥当性を確認する
27
ポイズニングは、DNSの仕様によって有効期限内のキャッシュが 存在する間は再帰問合せできない!
28
ソースポートランダマイゼーション/DNSSEC
29
検査・隔離・治療 ①DHCP方式→手動IP設定はDHCPスプーで対策 ②認証スイッチ方式
30
ウイルス検出方法 ①パターンマッチング方式 定義ファイル ②ヒューリスティックスキャン方式 プログラムの動き →動的ヒューリスティックスキャン方式 (ビヘイビア法) サンドボックス
31
メッセージ認証では「共通鍵暗号方式」や「ハッシュ関数」を使ってチェック用データを作ります。 デジタル署名では「公開鍵暗号方式」を使ってチェック用データを作ります。 理屈や考え方は似ているけど、実際のやり方が違う
32
最近では、無線LANやSSL/TLS通信などのセキュリティプロトコルにおいて、 ストリーム暗号よりも主流 。 暗号化とデータ認証を同時に →データの機密性と完全性を同時確保
33
・Spoofing Identity なりすまし ・Tampering with data 改ざん ・Repudiation 否認 ・Information disclosure 情報漏洩 ・Denial of service サービス妨害 ・Elevation of privilege
34
=郵便配達(中間サーバ)では復号、解読されない 逆)TLS :ブラウザとウェブページ間の通信を暗号化し、メッセージは中間サーバーで復号化 →サーバーを管理するサービスプロバイダーはメッセージの内容を読むことができる!!
35
サーバ証明書を発行する過程で、発行依頼元のSNSがもつCAAレコードを確認
36
存在証明 日時に確かにデータが存在していた事の証明 完全性証明 日時以降そのデータが改ざんされていない事の証明
37
DoH(DNS over HTTPS)
38
リソースレコードに対するデジタル署名
39
DNSKEY
40
Endpoint Protection Platform エンドポイント保護 エンドポイント監視、脅威の検知、対処 ネットワーク全体を監視、脅威の検知、対処 IT機器から大量ログを収集、相関関係をもとに分析 SIEMの拡張、インシデント対応プロセスの自動対処 /総合分析、自動対処
41
Due care 遵守すべき要件を過失なく満たしている Due diligence 正当な注意義務及び努力
42
Brand Indicators for Message Identification DMARCと呼ばれる認証が成功したメールに対し企業ロゴを付与し信頼性を高める技術
43
無線LANが盗聴されるリスクを低下できる
44
「我々にメールを送るときには必ず有効な証明書とともにTLSで送ってください、そうじゃない場合は受け取りません!」 STARTTLSの弱点である「MTA同士でお互いTLSを使えたら使う(使えない場合は平文でOK)」を強化 SMTPクライアントがサーバの身元を確認 →TLSハンドシェイクでサーバーに証明書要求
45
①中間者(MITM)攻撃で平文ダウングレードさせられる ②送信サーバーの身元を認証する方法がない。 SMTPメールサーバーは証明書を検証しないから。
46
DNS-Based Authentication of Named Entities MTA-STS強化 STARTTLS 必須 TLS1.0以上、できれば1.2以上 DNSSECが検証できなければ配送しない 公開鍵 必須
47
①送りたいファイルを、1回限りの乱数によるセッション鍵で暗号化 ②①で用いたセッション鍵を、送り先相手の公開鍵で暗号化 ③暗号化ファイルとセッション鍵の両方を送信 なお、通信時、通信そのものの暗号化は行わない。 ④ファイルの送り先にて、自身の秘密鍵で、1回限りのセッション鍵を復号 ⑤④で得た1回限りのセッション鍵で、ファイルの中身を復号
48
IAP
49
STRIDEモデル ペネトレーションテスト(実現しうるシナリオをもとにリスクを評価,MITRE ATT&CK) 脆弱性診断(OWASP top10 に関連)
50
iptables
51
P346 プロセスハロウィング
52
バックアップデータを復元する手順を追加する
53
定期的な更新とパッチ適用
54
本社ネットワーク管理者へVPN接続に用いるIDを一時停止するように連絡する
55
CSIRT
56
GDPR General Data Protection Regulation
57
ARPテーブルを確認するコマンド エージェントが夜間に「arpコマンド」の実行を確認したら、当該PCをネットワークから隔離する。 ※マルウェアはarpコマンドで割り出したIPアドレスにpingで起動を確認
58
「number used once」の略で、「一度だけ使われる数」
59
送信者のTXTレコードの「IPアドレス」が, 送信元✉のIPアドレス(「MAIL FROMコマンド」のアドレス(=エンベロープFrom)) と一致するか? ▽SPFレコード 『IN TXT "v=spf1 +ip4:58.13.7.83( IPアドレス ) -all』 💬どうぞ見に来て頂戴~エンベロープFROMと一緒でしょ?
60
GET メソッド→外部に送信するRefererに秘密情報が含まれる CSRF(クロスサイト・リクエスト・フォージェリ) 「hidden パラメータ」に秘密情報を出力
61
ペネトレーションテスト リスク↓ C&Cサーバへの通信可否などのマルウェア感染 ・一般ユーザから管理者権限への権限昇格 ・推測されやすいパスワードやパスワードハッシュ
62
セキュリティチップ Trusted Platform Module(TPM)、 自己暗号化ドライブ Self Encrypting Drive(SED)、 高信頼ネットワークTrusted Network Communications(TNC)
63
「攻撃者が真正なサーバがもつ真正な公開鍵を事前に入手しておき、その値から計算したフィンガプリントを送りつけてしまう」 「ホスト認証」。 真正な公開鍵と対をなす秘密鍵を、このサーバは本当に持つか?をチャレンジレスポンスで検証する方法です。