[RPA]PC自動化技術総合スレ[効率化] Part.7

■ このスレッドは過去ログ倉庫に格納されています
2019/11/19(火) 20:35:47.34ID:K8abzL+c
語りましょう
次スレは>>950がたててね
2020/01/12(日) 13:57:39.24ID:/os/mmOS
>>785
ずれてんのはお前な
セキュリティを意識してないから要件漏れだらけだ
773は今は別の問題で誰も議論してない
2020/01/12(日) 14:00:43.14ID:bSfOvwvy
>>786
俺の言ってること、理解できないんでしょ？
もう君出てこなくていいよｗ

それより >>773 を深めたほうがスレ的に面白い。
突発的に出てきそうなお知らせって、みんなどうやって拾おうとしてる？
2020/01/12(日) 14:23:22.55ID:BrY9V3ck
>>787
そっくり返すわ
お前も出てくんな
2020/01/12(日) 14:36:27.29ID:bSfOvwvy
>>788
だって君、質問も理解できてないし、リスク分析もできないし、勝手に条件追加するし、勝手に要件も追加しようとする。
邪魔なだけじゃん。
プロジェクト炎上屋さんでしょ。いらんわｗ
2020/01/12(日) 14:39:42.55ID:wzOQ6goX
>>789
だって君、質問も理解できてないし、リスク分析もできないし、隠れた条件見逃すし、要件お漏らしするし
邪魔なだけじゃん
プロジェクト炎上屋さんでしょ。要らんわ
2020/01/12(日) 14:54:13.91ID:bSfOvwvy
>>790
ナンだよ隠れた条件って。勝手に付け加えるなｗ
質問者からそんな追加条件ヒアリングできてないぞ。

お前、ずーと一人でスコープがずれてんのよ。
だから会話にならんし、人の言うことが理解できない。

そろそろ学習しろ。何回同じこと繰り返してるの？
2020/01/12(日) 15:06:00.25ID:khQ0wJGz
>>791
んなこと言ってるから本来必要な要件をお漏らししてあとで大事故に繋がるんだよ
相手が言ったことだけを鵜呑みにするな
それは何も考えないバカのやりかただ
2020/01/12(日) 15:18:55.74ID:bSfOvwvy
>>792
> 相手が言ったことだけを鵜呑みにするな

ちがうぞ。必要なら相手に提案して「ヒアリング」するんだよ。
で、エビデンスを残す。
勝手に追加するのはプロジェクトとして最悪の結果を残すし、そんなやつはプロジェクトにいらない。

だれも必要としていない提案すらまともでない内容を勝手に追加するな。

今回だと、

> 銀行振込の帳票なんかを毎日銀行のオンラインサービスサイトからダウンロードしたいんだけど勉強するのはseleniumってやつでいいの？

> 「今日の(昨日のではなくて)、銀行のオンラインサービスサイトからダウンロードに成功した(失敗していない)」
という判定をどうすればいいか、思いつかない

に対して、なぜ、

> ステータスコードなんてのは、通信中に明らかなエラーはなかったね、程度の認識でいい
ステータスOKならそこから更に、中間者攻撃がなかったか、データ破損がなかったか、等のより精度の高いチェックをするのが当たり前だ

みたいな話が出る？
そもそもお前の言ってるステータスコードが「HTTPステータスコード」なら、このコメントすら間違ってるんだけど？
2020/01/12(日) 15:40:20.21ID:BtWuREj/
>>793
つうか前から思ってたがここはプロジェクトじゃねえぞ間抜け

ヒアリングしてないのはお前も同じ
質問者の発言は「ダウンロード成功したかどうか判断方法がわからない」だけだ
ダウンロード成功の定義が定まってない以上は過不足を論じることはできない
お前は余計な要件を追加するなというがそれが余計かどうかもわからん
俺が言うようにお前が必要な要件を勝手に無視してるかもしれん

リアルなプロジェクトでない掲示板ではよくあるシチュエーションだが質問者が議論に参加する気がない場合は平均的なシチュエーションを想定して論じるしかない
となると答えは信頼できるハッシュ値との比較が妥当なところだろとなるわけだ

HTTPステータスコードと誰かが言ったか？
2020/01/12(日) 15:45:24.57ID:BtWuREj/
つうかステータスコードをHTTPステータスコードと読み替えても特に問題ないだろそこ
2020/01/12(日) 15:55:29.27ID:bSfOvwvy
>>792
> ヒアリングしてないのはお前も同じ

そうそう。。だから提示された内容に対してのみコメントするようにしている。
だから余計な追加はしてない。

> ダウンロード成功の定義が定まってない以上は過不足を論じることはできない

そうそう。過不足を論じるな。

> リアルなプロジェクトでない掲示板ではよくあるシチュエーションだが質問者が議論に参加する気がない場合は平均的なシチュエーションを想定して論じるしかない

そうそう。分かってんじゃん。
ただ、平均が何かはシュチュエーションによる。
わからない場合は、「提示された内容で」進めるのがズレないコツ。
この場合は、「銀行振込の帳票なんかを毎日銀行のオンラインサービスサイトからダウンロードしたい」っていうよくあるダウンロード案件。

> HTTPステータスコードと誰かが言ったか？

ナンのステータスコードを指したんだ？(これがヒアリング)

> 信頼できるハッシュ値との比較が妥当なところだろとなるわけだ
ならねーよばかｗ
なんでそこで飛ぶｗ

ところで、

> 今は署名もハッシュもない状況を議論してんだよ

そんな条件は、だ・れ・が・決めた？
2020/01/12(日) 16:06:16.36ID:gAizTjEJ
すげえ長々とやり合ってる所申し訳ない
>753、>>758の話だけ見ると
>「今日の(昨日のではなくて)、銀行のオンラインサービスサイトからダウンロードに成功した(失敗していない)」
単純にファイルダウンロードに成功したかどうかだけなら
とりあえず日付でファイル名作って存在チェックだけやればええんやないの？
セキュリティ面の話はその次のステップじゃ？
2020/01/12(日) 16:11:41.42ID:gAizTjEJ
ぶっちゃけ要件なんて後出しでコロコロ変わるんだから
・ツールでやりたい事（現行業務のヒアリング、自動化のフロー/処理の流れの策定）
・その上で必要なエラーチェック処理（ファイル存在チェック、アクセス可否チェック、整合性チェック等など）
正直、やりたい事も分からずに互いの妄想だけで殴り合ってるのは不毛すぎるわ
2020/01/12(日) 16:14:25.30ID:bSfOvwvy
>>797
これ、今日ダウンロードしたファイルはホントに今日の作成のモノなの？って疑問だから、ダウンロード日の比較だとちょっとまずい。(ダウンロードファイル名に作成日付が入っていればいいけど。)

で、前日ファイルと当日ファイルの内容比較なら、ハッシュの比較でいいんでは？ってのがコメントとしてついてる。

意識高い君がズレたこと言ってるから、ミスリードになってるけど、元の文脈はそんな感じ。
2020/01/12(日) 16:21:20.58ID:gAizTjEJ
>>799
ああ、そういう流れでハッシュ値比較が出たのか
個人的にはファイルのタイムスタンプで見たいかな
あれなら作成日時とれるし
2020/01/12(日) 16:22:25.75ID:BtWuREj/
>>796
提示された内容に対してのみコメントとかよく言えたもんだ
お前の論調は余計な要件を増やすなだろ
先程も言ったが要件が定まってないのに要件を増やすなとは言うことはできない
つまりお前も脳内で勝手に定めた要件を基にして発言しているんだよ
それは提示された内容ではない

提示された内容は「銀行サイトからダウンロードする際にダウンロード成功を判定する方法」だ
何を持ってダウンロード成功とみなすかは未定義な

HTTPモジュールの返すステータスあるいは投げる例外だよ
バカでもわかると思うがHTTPリクエストの失敗要因はネットワークやサーバーサイドだけじゃねえぞ？

妥当だぞ
セキュリティが絡むファイルのダウンロードを必要とする場面ではハッシュ値の比較はポピュラーな解決策だ
コストと安定性と精度の観点から見てバランスがいいんだよ
もちろんサービス側がハッシュ値を公開してる前提だが
デジタル署名もないハッシュ値も無い場合に比較的有効な確認方法は形式チェックと複数回ダウンロードだが
形式チェックはエラーが小さいと意外とチェックに引っかからない場合がある
複数回ダウンロードはファイルダウンロードの通信経路が保護されてる前提だがエラー検出の精度はかなり高い
2020/01/12(日) 16:26:38.27ID:BtWuREj/
>>797
ファイルが存在するかだけじゃ駄目だ
ダウンロードに失敗してもファイルが残る場合はある
ブラウザが成功と認識しても実は失敗してたなんてことは普通にある話だ
ダウンロードしたファイルが開けなかった
でも取り直したら開けたなんてこと経験したことないか？
最近はブラウザの品質が良いからそう頻繁に起こることでもないがそういうことは原理的にありえるんだ
2020/01/12(日) 16:35:47.13ID:BtWuREj/
>>799
質問者は「今日のダウンロードが成功したかどうかを判定する方法」を知りたがってる
ファイルが昨日ダウンロードしたものかどうかは聞いてない
今日のダウンロードが成功したことがわかればそのファイルが昨日のものではないことは明らかなのだからそれを聞く意味がない
2020/01/12(日) 16:36:13.49ID:bSfOvwvy
> お前の論調は余計な要件を増やすなだろ

だから違うって。日本語理解しろよ。
スコープとズレた箇所でいきなり「セキュリティ意識が低い」とか頭湧いてるって言ってんだよ。

あと、「HTTPリクエストの失敗要因はネットワークやサーバーサイドだけじゃねえぞ？ 」って違うからな。
なんとなくは理解してるみたいだけど、HTTPステータスコードって基本的には「Webサーバ」が返すインフォメーションだから。

ほかもひどいな。自爆もほどほどに＾＾；
2020/01/12(日) 16:47:38.45ID:yD0L96jY
>>758
こんなんじゃねと考えた

ファイル名に今日の日付が含まれる仕様である場合
→ファイル名チェックをする

ファイル内部の特定のセルなどに今日の日付が含まれる仕様である場合
→特定のセルなどをチェックする

そうでない場合
→どっかに今日の日付を探してそれをチェックする 例えばダウンロードページ（に遷移する前とか）に「○月○日のデータはこちら」みたいな箇所があればそこのhtmlをチェックする
→あるいは目視チェックする 手作業でダウンロードするよりは数倍楽でしょ データの形式とかHPの仕様が変わることもあるから無難でもある
2020/01/12(日) 16:48:25.04ID:BtWuREj/
>>804
ダウンロード失敗の要因にセキュリティ攻撃の可能性もあるのだからそこは当然考慮すべき

サーバーがどんなHTTPステータスコードを返そうがそれ以外にもHTTPリクエストが失敗する要因があるんだよ
だからHTTPステータスコードだけじゃなくHTTPモジュールの返すステータスコード（あるいは例外）を見る必要があるんだよ
あえてステータスコードと一段抽象化して書いたのはそういう理由だ
無知な人はHTTPリクエストの失敗要因はサーバーだけにあると勘違いしてHTTPステータスコードだけ見ればいいやなどと思っちゃうのかもしれんがな
お前さ管理ばっかりでプログラム書いたことないだろう？
2020/01/12(日) 21:13:09.66ID:04cjRg0b
ここRPAのスレだよね?
セキュリティとか関係無いだろ。

そもそもセキュリティ考えなきゃいけないようなもんはRPAで組んじゃいかん。
ブラウザからダウンロードする時のセキュリティと同レベルでOK。
つまり、特別なもんは必要無い。
逆にそれでOKじゃないならRPAじゃ無くて専用のアプリ組んで、それをRPAから呼び出すようにすべきだろ。
2020/01/12(日) 21:18:41.88ID:04cjRg0b
ダウンロード失敗の判定も特別なもんは必要無さそうだ。
帳票というのが何のファイルか分からんけどOffice文書なら、zipだから化けたら開けんだろ。

どっちにしろ、判定なんて状況によりいろんな方法が有るんだから、どうにも特別な方法が必要という状況になってから考えるべきだろ。
2020/01/12(日) 22:23:36.41ID:zPbjC6MN
>>807
それじゃあ何もできないぞ
セキュリティ無視できるタスクなんてめったにない
つうか自動化する以上は事故ったときのリスクも増大するからセキュリティは手作業のときより神経質にならなきゃいかん
2020/01/13(月) 02:27:18.98ID:CdKMm6na
>>809
そんなにセキュリティが大事ならWindows使うのがもうダメ。
というかメジャーOS全てダメだな。
独自OSを開発する必要がある。

それくらいナンセンスだよ。
鉄壁のセキュリティのすぐ横でユ―ザーがメール添付のウィルスファイルダブルクリックしてアホだろう。
2020/01/13(月) 03:26:38.47ID:DzRETjKI
被害妄想レベルのセキュリティ意識ｗ
ローカル端末使っとけよｗｗｗ
2020/01/13(月) 09:21:35.75ID:II7jjoOs
お前らまじでセキュリティ意識低いな
当たり前のようにやるべきことを普通にやれって言ってるだけだぞ？
2020/01/13(月) 10:02:16.92ID:XrlS1QE+
自宅警備しかしてないからそんなセキュリティ意識になるんだよ。
お一人様CSIRTでも作っとけｗ
2020/01/13(月) 10:12:57.47ID:CdKMm6na
>>812
RPAというのは手作業を自動化するようなもの。
手作業で必要なセキュリティ対策で十分。
2020/01/13(月) 10:14:48.22ID:CdKMm6na
セキュリティ意識が低いとかバカ丸出しだ。
そっちの方が低い。

セキュリティが必要ならRPAをやめるべき。
2020/01/13(月) 10:47:53.03ID:8EXCq9RG
>>814
ほんこれ
2020/01/13(月) 10:54:41.70ID:pulMCdUh
>>814
駄目だぞ
人間だと、あっやっちまった、って気付いてすぐに対処に入ることができることでも、プログラム化したらそうはいかない
ループで100回処理するとこにバグやセキュリティ障害があったら、手作業のときより100倍の被害が出てもおかしくない
手作業のときと同じセキュリティレベルじゃ全く足りないんだよ
手作業のときと同じってのは宣伝文句でしかなく、実際にはプログラムと手作業は全くの別物なんだ
作業者の責任能力の違いも大きい
2020/01/13(月) 11:05:53.86ID:nlvLw0Pz
>>817
それはエラー処理の話
セキュリティの話じゃない
2020/01/13(月) 11:10:36.60ID:II7jjoOs
手作業ってのは暗黙知の塊だ
手作業と同じって感覚でやってたら、なにかしら見落としが生じる
手作業とプログラムは違うものだという当たり前の前提に立って、プログラムが処理しやすい、プログラマが間違えにくい方法でロジックを再編しろ
2020/01/13(月) 11:11:11.93ID:II7jjoOs
>>818
セキュリティも同じ
2020/01/13(月) 11:12:30.09ID:CdKMm6na
マウスで2ヵ所クリックするだけのアプリはリスクが低い。
ループとか高度なことをするからリスクが上がる。
RPAでリスクを考えるべきほど高度なことするからおかしくなる。

本当にリスクを考えるべきならRPAを辞めれば良い。
2020/01/13(月) 11:16:07.47ID:CdKMm6na
というか、普通のプログラムでもセキュリティなんて大して考えないけどな。

考えるべき所なら最初からそれ用で揃える筈。
俺ん所にゃそんな発注はそもそも来ない。
2020/01/13(月) 11:24:35.36ID:II7jjoOs
RPAの性質上セキュリティ対策は必要不可欠
外部サービスを含め様々なアプリやサービスにアクセスするから、一般的な手法で開発されるプログラムよりセキュリティ事故を起こしうるポイントが多くなる

またRPAプログラムに与える権限が強すぎる点も問題だ
例えば外部サイトから特定のデータを定期的にダウンロードしたい、という目的のために、その外部サイトのアカウントをプログラムに持たせなければならない
特定のデータダウンロードしたいだけなのに、そのアカウントの全操作権限を渡さなければならないということだ
これはやりたいことに対してリスクが大きすぎる

人間が手作業でやる場合は人間直感と柔軟な対応力、そして責任能力を持ってしてカバーしうる問題だがプログラムではそうはいかない
プログラムには直感も柔軟性も責任能力もない
なのでプログラムは手作業のときよりもより厳重にセキュリティ対策を施さなければならない
2020/01/13(月) 11:44:58.82ID:nlvLw0Pz
>>820
アホなのか？
人手の作業で気付いてなんとかできるなら既にセキュリティズタボロってことだぞw
2020/01/13(月) 11:47:33.01ID:nlvLw0Pz
>>823
だから柔軟性でなんとかなるなんてセキュリティボロボロやん
性善説でなんとかできるならセキュリティなんて要らんよw
2020/01/13(月) 12:01:22.27ID:XrlS1QE+
対策するかしないかはリスク判定してからだぞ。
システム全体のリスク判定できない病は新人が陥るやつだから、さっさと抜け出せｗ
2020/01/13(月) 12:03:13.22ID:IOw3xBOo
>>824>>825
セキュリティに完全はねえよ
可能な限り無いように務めるが起こるときは起こる
そして起きてしまったときの対応力は業務プログラムより人間のほうが遥かに高い
事前に想定しきれなかったことにも対処できるのが手作業の強みだ
2020/01/13(月) 12:20:00.30ID:nlvLw0Pz
>>827
だから起きてからの対応はセキュリティの話じゃねーだろ
起きないようにするのがセキュリティなの
あと起こってからの対応とか言ってるけど余計なことして傷口広げる例なんていくらでもある
2020/01/13(月) 12:34:01.16ID:XrlS1QE+
>>828
おぃおぃ。起きてからの対応決めとくのはセキュリティの重要項目だぞ。
これだから底辺しか見てないヤツは困る。全体を知れ。
2020/01/13(月) 12:47:22.58ID:nlvLw0Pz
>>829
JIS Q 27002（ISO/IEC 27002）にはそんなもんは定義されてないけどなw
お前が言ってるのはインシデント対応
しかも、検出・分析と封じ込め・根絶・復旧の区別もついてない
そもそも手作業だからなんとかなるとか言ってる時点でセキュリティを語るレベルじゃない
2020/01/13(月) 12:54:45.07ID:XrlS1QE+
>>830
ほんと底辺ｗ
2020/01/13(月) 12:58:37.89ID:nlvLw0Pz
JISも知らなくてクヤシーまで読んだw
2020/01/13(月) 13:02:45.72ID:XrlS1QE+
>>831
JIS Q 27002 で組織と責任範囲を設定をして、インシデントに対してのしきい値を設定するまでが、一般的なセキュリティ対応な。
覚えとけｗ
2020/01/13(月) 13:14:42.49ID:nlvLw0Pz
インシデントのしきい値？
ちょっと説明してみ、ソース付きでなw
2020/01/13(月) 13:19:07.91ID:SIUc1M0X
>>828
アホすぎ
てめえは想定しきれなかったセキュリティ事故は起きたら放置すんのかよ
ろくに事後対応に備えず原発推進して被害拡大させた連中と同じだな
2020/01/13(月) 13:22:12.09ID:V4HNq25L
なんちゃら規格って持ち出して偉そうに語る老害って資格コレクターで実際の現場では全然役に立たない無駄な仕事量産マシーンになるのが定番パターンだから困る
2020/01/13(月) 13:24:58.90ID:XrlS1QE+
>>834
CSIRTを知らんやつとこれ以上話すことねぇよｗ
2020/01/13(月) 13:27:04.60ID:nlvLw0Pz
>>835-836
セキュリティ要件とインシデント対応の区別をつけろ
って話な
まあ言い返せなくてクヤシーってことなんだろうけどw
で、君らはインシデントのしきい値と言う謎用語はわかるわけ？
わかるなら説明してよw
2020/01/13(月) 13:27:11.09ID:DzRETjKI
セキュリティくんは細かいこと気にし過ぎて
仕事進められないタイプだね
老害リストラ予備軍＾＾
2020/01/13(月) 13:30:27.31ID:nlvLw0Pz
>>837
セキュリティの話に組織ガーとか
必死にググったんだろうなw
2020/01/13(月) 13:31:23.21ID:oxUV3TeC
事故後の対応を事前に決めれるなら原因もわかってるはずだからそもそも事故が発生しないようにすればいい
事前に予測できなかったものだけが事故として起こる
だから事故が発生した後の柔軟な対応が大事なんだよ
事前に決めれることだけでは全くもって不十分
狡猾で研究熱心なハッカーがどんな攻撃手段を考えてくるか事前になんでも予測できるかって話だよ
2020/01/13(月) 13:32:57.83ID:nlvLw0Pz
>>839
技術者がセキュリティ語るならこの程度の用語を使い分けるのは常識だと思うけどね
まあグダグダのままなんとなくでセキュリティ確保できたーとか思ってる企業もいっぱいあるみたいだけどw
2020/01/13(月) 13:36:28.36ID:nlvLw0Pz
>>841
> 事故後の対応を事前に決めれるなら原因もわかってるはずだからそもそも事故が発生しないようにすればいい
アホなの？
原因はともかくバックアップからリストアする
なんて対応は普通にあるだろ

> だから事故が発生した後の柔軟な対応が大事なんだよ
事前の準備もしてなきゃアタフタするだけだろw
マジでセキュリティ要件とかインシデント対応の区別がついてないんだな
2020/01/13(月) 13:36:38.09ID:DzRETjKI
誰も読まない規格書作りまくって
セキュリティ対策した気になるやついるよねｗ
2020/01/13(月) 13:38:22.90ID:XrlS1QE+
>>842
そｒｙ使い分けるのが常識だわ。
なんでセキュリティの話にインシデント対応が含まれないと思ったんだ？
ISMSなんて、半分組織の話だぞ。

要件のはなししてるときにリスク判定しないとか、セキュリティの話ししてるときに組織な話が出るとにげるとか底辺すぎｗ

何度も言うけど、新人病だからさっさと抜け出さえよ。
2020/01/13(月) 13:40:23.42ID:XrlS1QE+
>>843
> 原因はともかくバックアップからリストアする

そんな対応はセキュアな組織ではしない。
セキュリティ意識低すぎｗｗｗ
2020/01/13(月) 13:41:58.50ID:Dv2NHD6v
>>843
事故を検出した時にバックアップからリストアすることが正しい対応と「事前にわかってる」ならそういうシステムを組めばいい
今は「事前に正解がわからないこと」を論じてる
お前は世界中のハッカーがどんな脆弱性を付いてどんな攻撃をしてどんな被害がでてどんな対処をすればいいか予め全て理解してるのか？そんなことは不可能だ
だから事後対応の柔軟性が求められるんだよ
そんなことは業務プログラムには不可能で必ず人間が手を動かさなければならない
2020/01/13(月) 13:45:48.41ID:Dv2NHD6v
事後対応の柔軟性が重要とは言ったが事前の対応や計画が不要という意味ではないぞ
事前にも力を尽くした上での事後対応の柔軟性が重要ということだ
規格マニアのバカは下手すると今回の事故は規格や計画にないから対応はやらなくていいですとか言い出しかねない
2020/01/13(月) 14:13:41.42ID:CdKMm6na
お前らはRPAを使うな。
ゲラゲラw
2020/01/13(月) 14:19:40.66ID:nlvLw0Pz
>>845
最初の話は>>664辺りな
追い込まれてCSIRTとか言っちゃって引っ込みつかなくなったんだろうけどセキュリティの基本は何を誰からどうやって守るか
2020/01/13(月) 14:21:49.85ID:nlvLw0Pz
>>846
バカにもわかるように例示しただけだぞ
もしかして「原因はともかく」を原因なんて調べないって読んじゃったか？
底辺にはよくある勘違いだがw
2020/01/13(月) 14:24:21.39ID:nlvLw0Pz
>>847-848
だれも事故対応までRPAでやるなんて言ってないけどw
上にも書いたけど「検出・分析と封じ込め・根絶・復旧」の区別ぐらいつくようになってから出直せよ
2020/01/13(月) 14:31:18.65ID:XrlS1QE+
>>851
セキュアな組織では、インシデントに応じて、エスカレーションがなされる。
で、一般的には、原因が不明な状態でとりあえず「バックアップからリストアする 」なんてぬるい判断は責任ある立場のやつほどしない。

「インシデントに対してのしきい値」が理解できないことが原因だから、「CSIRT インシデント 判定」ぐらいでググって、にわか知識でもつけてこいｗ
2020/01/13(月) 14:33:47.38ID:XrlS1QE+
>>850
「何を」の部分の発想がお前は底辺なんだよｗ
2020/01/13(月) 14:42:46.11ID:nlvLw0Pz
>>853
それは状況による
サービス継続が至上命題のシステムもある
で、インシデントしきい値の説明早くしろよ
2020/01/13(月) 14:43:40.12ID:nlvLw0Pz
>>854
バカには理解できないのかw
2020/01/13(月) 14:49:49.99ID:XrlS1QE+
>>855
> サービス継続が至上命題のシステムもある

原因不明だぞ？SQLインジェクションの攻撃余波でデータが吹っ飛んでたりしたら復旧次第、データ抜き放題じゃねぇかｗ

> インシデントしきい値の説明早くしろよ

なんで、ここまでヒント出して理解できないんだ？
https://www.jpcert.or.jp/csirt_material/files/manual_ver1.0_20151126.pdf
インシデント発生時のフローとして、トリアージや事象の分析における影響範囲のしきい値を予め設定しておくのがCSIRTの基本なんだよ。
2020/01/13(月) 15:04:03.32ID:nlvLw0Pz
>>857
原因わかるまでサービス停止が許されないこともあるし、インシデントの内容にもよるだろ
やばいIPからのアクセスを禁止して運用再開とかいろいろなケースがある
そう言うのを「柔軟な対応力」って言うんだろw

> https://www.jpcert.or.jp/csirt_material/files/manual_ver1.0_20151126.pdf
しきい値なんて言葉は書かれてないけど？
判断基準はあるけどしきい値なんて簡単な話じゃないだろうし
2020/01/13(月) 15:07:03.15ID:2q6XWWMq
セキュリティでケチつけて荒らしたいだけでしょ 無視が一番
2020/01/13(月) 15:08:37.91ID:XrlS1QE+
>>858
もうぼろぼろだな。ねとけｗ
2020/01/13(月) 15:14:01.09ID:nlvLw0Pz
ぼろぼろでそれしか言えなくなったのかw
可哀想だな
2020/01/13(月) 15:44:11.42ID:XrlS1QE+
>>861
そりゃ掛ける言葉もなくなるわ。
「やばいIPからのアクセスを禁止して運用再開」なんていい出すやつだぜ。会話が成立せんわ。
セキュリティ意識低すぎｗｗｗ

> 判断基準はあるけどしきい値なんて簡単な話じゃないだろうし

しきい値として記述できるレベルの簡単な判断基準に落とし込むんだよ。
特にエスカレーションは、あまり判断しなくて良いように基準を決める。
簡単じゃない部分はエスカレーション先の責任者が判断するような仕組みを作るのがセキュアな組織作りな。
底辺には理解できない範囲なのよ。
2020/01/13(月) 16:09:06.99ID:CdKMm6na
>>862
バ―カw
セキュアな組織作りは既にされている前提だろ。
RPAのレベルなんてそれより下位か同等までだ。
2020/01/13(月) 16:10:06.62ID:CdKMm6na
RPAなんて底辺なんだから無理するな。
2020/01/13(月) 17:19:33.65ID:nlvLw0Pz
>>862
> 「やばいIPからのアクセスを禁止して運用再開」なんていい出すやつだぜ。
そういう対応もあるって話な
てか、もうそういう所にしか突っ込めなくなったのかよ

> セキュリティ意識低すぎｗｗｗ
だからセキュリティじゃなくてインシデント対応な

> しきい値として記述できるレベルの簡単な判断基準に落とし込むんだよ。
値にできる項目もあるだろうけどすべてじゃないよな？
セキュリティ分野でインシデントに対してのしきい値なんて言うアホな用語使う奴見たことないわ

> 底辺には理解できない範囲なのよ。
無理して自爆してるお前が言うなよw
2020/01/13(月) 17:34:07.36ID:XrlS1QE+
>>865
もうぼろぼろだな。ねとけｗ
2020/01/13(月) 17:53:54.19ID:1q8+/eQn
>>866
>>861
バカループ乙w
2020/01/13(月) 18:25:02.13ID:XrlS1QE+
うちの1年生でも分かる言葉で説明してやっても追いつけないし、「インシデント対応はセキュリティじゃない」とか、「原因はともかくバックアップからリストアする」とか、認識がズレまくってるやつとこれ以上続けてもしょうがないからなぁ。

知らない言葉がいっぱいあるって正直に言うところは好感持てたぞ。
ググっとけ。

あと、がんばってイキロｗ
2020/01/13(月) 19:41:57.50ID:nlvLw0Pz
インシデントに対してのしきい値なんて言う謎の言葉で価値誇られてもなぁw
判断基準を作ったことあればしきい値なんて言う単純なもので済むはずがないことぐらいわかりそうなもんだけどググることしかできない彼にはわからないんだろうな
2020/01/13(月) 19:51:01.01ID:N+zCCrTG
しきい値は草はえるｗ
2020/01/13(月) 21:52:16.56ID:XrlS1QE+
>>869
スレチなんだけどなぁ。。。ｗ

インシデント対応の初動は、多くの場合運用チームに任せられて、インシデントの監視は「異常値の発生」がトリガーになる。
オペレータが切り分けを実施するので、運用手順には「しきい値」を明確にした上で、インシデントを定義する。
例えばDDoSを定義するのであれば「回線の80%以上を占める通信が10分間続いた」みたいに客観的に観測できる内容にできるだけ落とし込んで置くことが必要。
実務では、この時点で、インシデントに重要度と影響範囲の判定がなされ、エスカレーション先が決定する。

しきい値って言葉が使われるのは、主に運用チームを相手に定義書を作成するから。
ごく普通の運用定義の風景なんだけど、理解できた？
2020/01/13(月) 22:15:09.23ID:BvowWoiX
めちゃめちゃスレ進んでて草
2020/01/13(月) 22:24:55.71ID:nlvLw0Pz
判定基準はしきい値「だけじゃない」って前にも書いたんだけどねぇ…
そもそも>>871に書いてあるのは検出基準であってインシデント対応じゃないし
DDoSで通信量とかDDoSがなにものかもわかってないみたいだし
スレチという以前にぼろぼろすぎるだろw
2020/01/13(月) 22:27:41.03ID:Zf0H2zIq
結局事前に定めた基準を満たさないならなんの対策もしないんだろ
でハッカーはそこを付いてくる
意味ねー
2020/01/13(月) 22:38:25.54ID:XrlS1QE+
>>873
> 判定基準はしきい値「だけじゃない」って前にも書いたんだけどねぇ…
> そもそも>>871に書いてあるのは検出基準であってインシデント対応じゃないし

インシデント対応の初動が検出なのは当たり前だろ。
スグ話ずらすなぁ。
お前はインシデントのしきい値の意味が知りたかったんだろ？
理解できたの？

それともまだ理解できない？

> DDoSで通信量とかDDoSがなにものかもわかってないみたいだし

DDoS調べてみ。食い尽くされるリソースの一つに回線帯域があるからｗ
2020/01/13(月) 22:41:32.65ID:N9RUr4Lo
3人くらいあぼーんしたら読みやすくなった
2020/01/13(月) 22:53:05.76ID:nlvLw0Pz
>>875
だいぶ前に書いたけど検出と対応の区別がついてないんだな…
もう少しまともに教育してもらった方がいいよ
まあ実務はやってないと思うけどこういう所で恥かくからねw
あとDDoSの検出で帯域なんてまず使わないよ
ファイル転送ガンガンされたら誤検出とか笑い話にもならんから
DDoSが何者かを知ってたら最低でもセッション数/sなどが出てくるはずなんだけどね
2020/01/13(月) 23:07:43.88ID:XrlS1QE+
>>877
スグ話ずらすなぁ。
お前はインシデントのしきい値の意味が知りたかったんだろ？
理解できたの？

> DDoSの検出で帯域なんてまず使わないよ

セッション数/sで監視できない攻撃もあるからな。
もっと言うと、ISPからしたら普通に監視対象だよ。
一定値/一定時間を超えるとユーザに通知するサービスも普通にある。
2020/01/13(月) 23:09:17.92ID:0UmJXvwE
スキルないからRPAなんてやらされてるんだろ
2020/01/13(月) 23:09:43.25ID:XrlS1QE+
> ファイル転送ガンガンされたら誤検出とか笑い話にもならんから

セキュリティ意識高いとこは、ご検出より、見逃しを嫌がるぞ。
全然笑い話じゃない。
ごく普通に検出させた後、検証する。
2020/01/13(月) 23:12:06.25ID:QDc5Ff4l
>>880
お前んとこは見逃しまくりじゃん
事前に定めた基準を満たさないとどんな攻撃されてもスルーするんだろ？
2020/01/13(月) 23:28:37.03ID:nlvLw0Pz
>>878
> お前はインシデントのしきい値の意味が知りたかったんだろ？
だからそんな一部の項目のことを言ってるアホはお前だけ
特にセキュリティ関連のインシデントでしきい値なんてかなり限定されるし

> 理解できたの？
お前が「だけじゃない」ことを理解できてないだけだろ
まあもう引っ込みつかなくなってるだけだろうけど

> セッション数/sで監視できない攻撃もあるからな。
DDoSでセッション数/sで監視できない攻撃って何？
ちょっと詳しく説明してみw

> もっと言うと、ISPからしたら普通に監視対象だよ。
> 一定値/一定時間を超えるとユーザに通知するサービスも普通にある。
どこのISPがDDoS攻撃のために帯域監視してるって？
具体的に書いてみ

>>880
アホか、誤検出だらけだと処置しきれなくなるわ
運用監視舐めんな
そもそもその手のしきい値は状況によって適宜見直すもんだし
セキュリティリスクの見逃しとDDoSのしきい値じゃ全然レベルが違うことも理解してないだろ
2020/01/13(月) 23:28:48.66ID:XrlS1QE+
>>881
> 事前に定めた基準を満たさないとどんな攻撃されてもスルーするんだろ？

言ってないことを根拠にされても困るなぁ。
日本語読めるようになって絡めよｗ
2020/01/13(月) 23:32:52.02ID:XrlS1QE+
>>882
> だからそんな一部の項目のことを言ってるアホはお前だけ

いや、お前がこだわってたんだぞ。すぐに話しそらすのは忘れちゃうからか？
結局わかったのか？まだ理解できないのか？

まず答えろよｗ
2020/01/13(月) 23:33:59.00ID://FLY2oG
>>883
いやお前はずっとそう言ってるよ
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況