効果的なSOC管理とインシデント対応 (Effective SOC Management and Incident Response)

字幕表動画を再生する

AI 自動生成字幕

Did you know that you can be part of the lucrative cyber security industry?

儲かるサイバーセキュリティ業界の一員になれることをご存知ですか？
Even top companies like Google, Microsoft, Amazon, IBM, Facebook, and Dell all hire cyber security professionals.

グーグル、マイクロソフト、アマゾン、IBM、フェイスブック、デルといった一流企業でさえ、サイバーセキュリティの専門家を雇っている。
The cyber security industry has a 0% unemployment rate.

サイバーセキュリティ業界の失業率は0％である。
The average salary for an entry level cyber security job is about $100,000 per year in the United States.

サイバーセキュリティの初級職の平均給与は、米国で年間約10万ドルである。
Furthermore, you don't need to know coding and learn from your home, and you get a scholarship to kick start your career.

さらに、コーディングの知識がなくても自宅で学ぶことができ、キャリアをスタートさせるための奨学金ももらえる。
Apply now.

今すぐ申し込む
EC Council is pledging a $3.5 million CCT scholarship for cyber security career starters.

EC評議会は、サイバーセキュリティのキャリアをスタートさせる人に350万ドルのCCT奨学金を提供することを約束した。
Scan the QR code on the screen to apply for the scholarship.

画面に表示されるQRコードを読み取り、奨学金に応募してください。
Fill out the form.

フォームに記入してください。
Hello everyone, and welcome to today's session, Effective Soft Management and Incident Response.

皆さんこんにちは、本日のセッション「効果的なソフト管理とインシデント・レスポンス」にようこそ。
I'm Shilpa Goswami, and I'll be your host for the day.

私はシルパ・ゴスワミ、今日のホストを務めます。
Before we get started, we would like to go over a few house rules.

始める前に、いくつかのハウスルールを確認しておきたい。
For our attendees, the session will be in listen-only mode and will last for an hour, out of which the last 10 minutes will be dedicated to Q&A.

このセッションは聴講のみで、1時間、最後の10分間は質疑応答に充てられる。
If you have any questions during the webinar to organizers or our speaker, use the Q&A window.

ウェビナー中に主催者やスピーカーに質問がある場合は、Q&Aウィンドウをご利用ください。
Also, if you face any audio or video challenges, please check your internet connections or you may log out and log in again.

また、音声や映像に問題がある場合は、インターネット接続を確認するか、一度ログアウトして再度ログインしてください。
An important announcement for our audience.

視聴者の皆様に重要なお知らせです。
As a commitment to closing the cyber security workforce gap by creating multi-domain cyber technicians, EC Council pledges $3.5 million towards CCT education and certification scholarship to certify approximately 10,000 cyber professionals ready to contribute to the industry.

ECカウンシルは、マルチドメインのサイバー技術者を育成することによりサイバーセキュリティの労働力格差を解消することを約束し、業界に貢献できる約1万人のサイバー専門家を認定するためのCCT教育と認定奨学金に350万ドルを拠出することを約束する。
If you want to know more, kindly visit our website given in the chat section.

もっと詳しくお知りになりたい場合は、チャットセクションにある当社のウェブサイトをご覧ください。
Also, we would like to announce to audiences about the special handouts.

また、特別配布物についてもお知らせします。
Take the screenshot of the running webinar and post in your social media LinkedIn, Twitter tagging, EC Council, and hashtag CyberTalks.

ウェビナーのスクリーンショットを撮影し、LinkedIn、Twitter、EC協議会、ハッシュタグ「CyberTalks」を付けてソーシャルメディアに投稿してください。
We will share free handouts to first 15 audience.

先着15名様に無料配布資料をお配りします。
Our speaker for today's session, Randy Thomas.

本日のスピーカー、ランディ・トーマス。
He is responsible for the SOC security product development, which includes detection as code,

コードとしての検出を含むSOCセキュリティ製品開発の責任者、
DIFI, incident command, vulnerability management, threat intelligence, driven security operations, threat hunting, and offensive security at Syntex, a leading managed cloud provider.

DIFI、インシデントコマンド、脆弱性管理、脅威インテリジェンス、ドリブンセキュリティオペレーション、脅威ハンティング、大手マネージドクラウドプロバイダーであるSyntex社の攻撃型セキュリティ。
He has over 21 years of experience in enterprise cyber security in a wide range of environments, including the US military and intelligence, commercial e-com, detail, and MSSP, MSSSP markets.

米軍や諜報機関、商用のeコマース、ディテール、MSSP、MSSP市場など、幅広い環境における企業サイバーセキュリティの分野で21年以上の経験を持つ。
He leverages his combined 28 plus years of enterprise IT experience and 18 years of experience in DevOps, DevSecOps, SOC, security engineering, and software development to deliver high quality security products and solutions.

28年以上の企業IT経験と、DevOps、DevSecOps、SOC、セキュリティ・エンジニアリング、ソフトウェア開発における18年の経験を活かし、高品質のセキュリティ製品とソリューションを提供している。
Without any further delay, I will hand over the session to you, Randy.

これ以上お待たせすることなく、ランディ、あなたにセッションを引き継ぎます。
Thank you, Shilpa.

ありがとう、シルパ。
Good day, everyone.

皆さん、こんにちは。
Thank you for taking this time to join the webinar, either live or later recorded.

ウェビナーにご参加いただきありがとうございます。
Today, we're going to talk about management and leadership in security operations.

今日は、セキュリティ・オペレーションにおけるマネジメントとリーダーシップについて話そう。
As with all things cyber security, it is iterative and you're always learning, regardless of your role and position inside of a SOC.

サイバーセキュリティのすべてに言えることですが、SOC内での役割や立場に関係なく、反復的であり、常に学び続ける必要があります。
Overview of what we're going to discuss, we're going to talk about what is a SOC, that varies.

これからお話しすることの概要ですが、SOCとは何か、それは様々です。
What are the business cases that you're using to defend your organization?

組織を守るために、どのようなビジネスケースを使っているのか？
What's the role of a leader?

リーダーの役割とは？
How do you plan and organize your team?

チームをどのように計画し、組織していますか？
Give an example and talk through a threat intelligence driven SOC lifecycle, something that can be done regardless of your maturity.

脅威インテリジェンス主導のSOCライフサイクルについて、例を挙げて説明する。
Go into some measures of effectiveness so you can know where you're at and know where you're going.

効果測定に入ることで、現在地と今後の方向性を知ることができる。
And give an example of iterative growth of a SOC.

また、SOCの反復成長の例を挙げてください。
And this is from a personnel progression, personnel growth standpoint.

そしてこれは、人材の進歩、人材の成長という観点からのものだ。
And then have some further research for you that are interested, either are in a leadership position or interested in it, or just want to know how leaders in operations think.

そして、興味のある人、指導的立場にある人、あるいはそれに関心のある人、あるいは単にオペレーション部門のリーダーがどのように考えているかを知りたい人のために、さらに詳しいリサーチを用意している。
So I've seen SOCs that have been everything from a SIM tool in an IT shop of one person to actually being responsible for not only the security operations, but the digital forensics, incident response, the threat intelligence work, the hunt work, building cyber threat intelligence products, offensive security, vulnerability management, SIM operation, and maybe engineering.

SOCは、1人のITショップのSIMツールから、セキュリティオペレーションだけでなく、デジタルフォレンジック、インシデントレスポンス、脅威インテリジェンス業務、ハント業務、サイバー脅威インテリジェンス製品の構築、攻撃的セキュリティ、脆弱性管理、SIMの運用、そしてエンジニアリングまで、すべてを担っている。
And likewise for EDR and other platforms.

EDRや他のプラットフォームも同様だ。
In my background, I've had to do the extremes there.

私の経歴では、そこで極端なことをしなければならなかった。
So it comes across.

だから伝わるんだ。
So understanding what your responsibilities are, very important.

だから、自分の責任を理解することは非常に重要だ。
So another area that you want to look at as a security operations leader is at some point to create a charter and write down your roles, your responsibilities, and really the limits of what the SOC can do.

セキュリティ・オペレーション・リーダーとして見ておきたいもう1つの分野は、ある時点で憲章を作成し、役割と責任、そしてSOCができることの限界を書き出しておくことです。
And that can cover a lot of things, and you want that to be an iterative and a learning or a living document, and not just let it sit on a shelf.

そして、それをただ棚に眠らせておくのではなく、反復的で学習的な、あるいは生きた文書にしたいものだ。
It should be something you come back and look at, whether it be during exercises or during actual incidents.

練習中であれ、実際の事故であれ、戻って見てみるものであるべきだ。
And it should be communicated across your organization with IT, with legal, with corporate communications, what have you.

そしてそれは、IT部門、法務部門、コーポレート・コミュニケーション部門など、組織全体で共有されなければならない。
These are important.

これらは重要だ。
They help reduce ambiguity where it exists, because as a security operations professional, you will deal with lots of ambiguity, lots of events that you cannot plan for.

なぜなら、セキュリティ・オペレーションの専門家として、あなたは多くの曖昧さや、計画できないような多くの出来事に対処することになるからだ。
So when you can plan and can organize, do yourself a favor in your team and do that.

だから、計画を立て、組織化できるようになったら、チームのためにそうしてほしい。
And that always is something you iterate on.

そしてそれは常に反復するものだ。
It's never stagnant, never stale.

決して停滞することなく、陳腐化することもない。
So again, wherever we can, being proactive, being responsive is very important.

だから、できる限り積極的に、そして迅速に対応することがとても重要なんだ。
Be intentional where you can.

できるところでは意図的に。
As a leader, it's important when you give directions and intent that you are not changing that constantly.

リーダーとして重要なのは、指示や意図を与えるときに、それを絶えず変えないことだ。
You have a good path.

あなたは良い道を歩んでいる。
You have a good plan.

あなたには良い計画がある。
Obviously, you have to be able to adapt.

もちろん、適応できなければならない。
We'll talk more about the OODA loop later, you know, observe, orient, decide, and act.

OODAループについては後で詳しく話すが、観察し、方向づけ、決定し、行動する。
That is a helpful tool in the process.

その過程で役に立つツールだ。
It's also important to either, one, establish, or two, take what is there and curate it so you look at your responsibilities, your roles.

また、自分の責任や役割に目を向けるために、1つには確立すること、2つにはそこにあるものを取り入れ、キュレーションすることも重要だ。
A RACI matrix is a very good way to do that.

RACIマトリックスはそのための非常に良い方法だ。
It would go across your organization.

それは組織全体に及ぶだろう。
If you're in the MSP, Managed Service Provider, Managed Security Service Provider space, such as

もしあなたがMSP、マネージド・サービス・プロバイダー、マネージド・セキュリティ・サービス・プロバイダーなどの分野に携わっているのであれば、次のようになるだろう。
Syntax is, we have to have those with each of our customers.

シンタックスは、それぞれの顧客と共有しなければならない。
That way, it's understood.

そうすれば理解される。
You also should build workflows that are accurate and reflect not only the RACI, but how that actually works in practice.

また、RACIだけでなく、それが実際にどのように機能するかを反映した正確なワークフローを構築する必要がある。
It's very important that you take these things in mind and you always have the iterative life cycle development process.

これらのことを念頭に置き、常に反復的なライフサイクルの開発プロセスを持つことが非常に重要だ。
Everything you do affects other aspects of the organization.

あなたがすることはすべて、組織の他の側面に影響を与える。
You know, think of it as throwing a boulder in a pond and the ripples in the water.

池に玉石を投げ入れると、水面に波紋が広がるようなものだと思ってくれればいい。
So, you have to be intentional about what you do.

だから、意図的に行動しなければならない。
Train how we fight.

戦い方を訓練する。
Use exercises.

エクササイズを使う。
Definitely do tabletop exercises, TTXs.

卓上練習、TTXは絶対にやる。
Also, highly recommend operational exercises in the environment.

また、環境での作戦演習を強く勧める。
Do OPEXs and do them often.

OPEXは頻繁に行うこと。
Internal to start with, internal to SOC, you know, expand it to security engineering if there is a security engineering organization.

まずは内部で、SOCの内部で、セキュリティ・エンジニアリングの組織があれば、セキュリティ・エンジニアリングにも広げていく。
Expand it from there.

そこから広げていく。
Include aspects of your enterprise IT.

企業ITの側面を含む。
That could be different departments, different divisions, and then look at doing it with customers as well, especially if you have customer environments, particularly in MSSPs, where there is split roles and responsibilities across not only the customer, but inside the SOC as an MSSP as well.

特にMSSPでは、顧客だけでなくMSSPとしてのSOC内部でも役割と責任が分かれている。
Okay.

オーケー。
A SOC is going to be in an organization that already exists.

SOCはすでに存在する組織の中に入ることになる。
The organization does what the organization does.

組織は組織の仕事をする。
Perhaps it's an e-commerce company and they sell retail products online.

おそらくeコマース企業で、小売商品をオンラインで販売しているのだろう。
Perhaps there's a mix with brick and mortar as well.

おそらく、レンガとモルタルも混在しているのだろう。
Perhaps you're a governmental organization, what have you.

おそらく、あなたは政府機関でしょう。
That exists.

それは存在する。
So, you need to understand things such as what are the business cases for the SOC.

そのため、SOCのビジネスケースは何かなどを理解する必要がある。
You have to focus in and understand where the SOC fits in the larger organization.

SOCがより大きな組織の中でどのような位置づけにあるかを理解し、集中しなければならない。
It's also important to build and, again, curate an understanding of crown jewels.

また、クラウン・ジュエリーの理解を深め、またそれをキュレーションすることも重要だ。
It's often called a crown jewels analysis.

よくクラウンジュエル分析と呼ばれるものだ。
It's exactly what it sounds like.

まさにその通りだ。
These are the top 10, the top 100 important things to the organization.

これらは、組織にとって重要なことのトップ10、トップ100である。
Again, to go back to what's why, this is what the organization is doing.

もう一度、なぜなのかに戻ると、これが組織がやっていることだ。
That typically would include not just technical, but personnel aspects as well.

技術的な面だけでなく、人事的な面も含まれるのが一般的だ。
If you've been in the industry for long, most breaches tend to occur via email, business email compromise, or BEC, huge, huge vector.

この業界に長くいると、ほとんどの情報漏えいは電子メール（BEC）を介して発生する傾向がある。
What are some of the aspects of that?

それはどのような点ですか？
Not only do you get the supply chain side attacks that are becoming more common, you also have the old but good attacks on invoice and wire fraud.

一般的になりつつあるサプライチェーンサイドの攻撃だけでなく、請求書詐欺や振り込め詐欺といった古くからある攻撃もある。
So, your finance department could be a CFO.

つまり、財務部門がCFOになる可能性もある。
So, all of these people, your C-suite, your board, you have your HR department.

つまり、C-suite、取締役会、人事部、これらすべての人々だ。
We're out of, in the U.S., income tax season.

アメリカでは所得税の季節が終わった。
That's also an issue as well with W-2 fraud, for instance, things like that.

例えば、W-2の不正なども問題だ。
You want to identify those, not just the identity and access management IAM pieces, which, of course, you want to include, you know, endpoint, detect and respond, EDR, things such as that.

IDおよびアクセス管理IAMの部分だけでなく、もちろんエンドポイント、検出と応答、EDRなども含めて識別したい。
Boundary protection is fine.

バウンダリー・プロテクションは問題ない。
That's not a panacea, of course.

もちろん、それは万能ではない。
Hence, other technologies such as zero trust, network access, CTNA coming about.

それゆえ、ゼロ・トラスト、ネットワーク・アクセス、CTNAといった技術が生まれた。
So, you leverage this work you do as a leader putting this together to prioritize what you work on, whether it's adding new capabilities to the SOC, such as detection engineering, or how you respond.

つまり、リーダーとしてこれをまとめる作業を活用し、検知エンジニアリングなどSOCに新しい機能を追加するのか、あるいはどのように対応するのか、何を優先して取り組むかを決めるのです。
And this deserves mentioning because, unfortunately, I've been in environments that have done this.

残念ながら、私はこのような環境にいたからだ。
You can only actually have one number one priority.

最優先事項は1つしかない。
You cannot have A through Z.

AからZまで揃えることはできない。
You cannot have 26 number one priorities.

26もの優先順位を持つことはできない。
You need to make choices.

選択をする必要がある。
The resources are always limited.

リソースは常に限られている。
Doesn't matter if you have a budget of $20,000 U.S. or $20 million.

予算が2万ドルであろうと2000万ドルであろうと関係ない。
You have severe limitations on what is achievable.

達成可能なことに厳しい制限がある。
Also, some aspects to consider in a more holistic manner are words have meanings.

また、言葉には意味がある。
So, anything the SOC gets in from systems that are instrumenting, such as a SEM or other tools, is an event.

つまり、SOCがSEMやその他のツールなど、計測しているシステムから得たものはすべてイベントとなる。
The event came in potentially based upon an alert or as an informational feed.

イベントは、アラートに基づいて、あるいは情報フィードとして入ってくる可能性がある。
So, the SOC has to determine whether it's manual or with automation, hopefully the latter.

だからSOCは、手作業か自動化か、できれば後者かを判断しなければならない。
That's a growth area, right?

それは成長分野だろう？
You have to build contextual reference and relevance to the event.

文脈を参照し、イベントとの関連性を構築しなければならない。
What does that mean?

どういう意味ですか？
If you're in the retail space, for instance, or hospitality, your enemy number one is threat actors such as FinCET.

例えば小売業や接客業であれば、一番の敵はFinCETのような脅威行為者だ。
This is how they act.

これが彼らの行動だ。
This is their tools, techniques, procedures, their TTPs.

これは彼らの道具であり、技術であり、手順であり、TTPである。
So, you look for things like that.

だから、そういうものを探すんだ。
So, once something comes in as an event, the SOC, whether manually or automatically, either clears the event, the alert, or it's elevated to be a probable incident.

そのため、何かがイベントとして入ってくると、SOCは手動であれ自動であれ、イベントやアラートを消去するか、あるいはインシデントの可能性が高いと判断します。
So thus, thus comes into play your incident handling process, which is a process if you don't have, definitely should make.

このように、インシデント処理プロセスが重要な役割を果たす。
There's plenty of references.

参考文献はたくさんある。
I have some at the end we can go over.

最後にいくつかあるので、それを見てみよう。
And one other point of note, particularly in more mature organizations, they will have an information technology information library, ITIL, based IT service management process.

そしてもうひとつ、特に成熟した組織では、IT技術情報ライブラリ（ITIL）に基づくITサービス管理プロセスがある。
Those define incidents at the ITSM level.

これらはITSMレベルでインシデントを定義する。
That is not necessarily a security incident that comes in as an event and or an alert to the SOC.

それは、必ずしもセキュリティ・インシデントがイベントとして、あるいはSOCへのアラートとして入ってくるわけではない。
In the SOC, we then, therefore, have to process that.

SOCでは、それを処理しなければならない。
Okay, being a SOC leader, we can manage our processes, manage our metrics, we can manage our timesheets and expense reports.

SOCリーダーであれば、プロセスを管理し、指標を管理し、タイムシートや経費報告書を管理できる。
When you're managing people, in my view, you've got some challenges to work through.

私が思うに、人を管理するときには、いくつかの課題がある。
So, leadership is important.

だから、リーダーシップは重要だ。
Again, as I mentioned earlier, from a resource standpoint, it's always limited.

繰り返しになるが、先ほども言ったように、リソースの観点からは常に限られている。
You must be pragmatic.

現実的でなければならない。
You cannot, nor should you really want to solve 100% of anything because when you start that process and when you finish it, it takes some period of time.

100％解決することはできないし、また、100％解決したいとも思わないはずだ。
There's periodicity in there.

そこには周期性がある。
And the threat landscape typically evolves.

そして、脅威の状況は通常進化する。
So, whether it's cyber hygiene or full coverage, that can always be a challenge.

だから、サイバー衛生であれ、フルカバレッジであれ、それは常に課題となりうる。
Now, obviously, full coverage of something like EDR, of other advanced authentication mechanisms such as MFA or other tools such as CyberArk, most certainly, those should be employed.

もちろん、EDRやMFAなどの高度な認証メカニズム、あるいはCyberArkのようなツールをフルに活用することも必要だ。
But you want close to 100% coverage.

しかし、100％に近いカバレッジが欲しい。
That's not the, of course, the intent of the discussion point there.

もちろん、そこが論点の趣旨ではない。
But understand that it's always evolving.

しかし、それは常に進化していることを理解してほしい。
We always have to iterate.

私たちは常に反復しなければならない。
So, as a leader in SOC, when everything else is on fire and there's chaos abounds because that's what a SOC has to deal with, right?

だから、SOCのリーダーとして、他のすべてが炎上し、カオスがあふれているとき、それがSOCが対処しなければならないことなんだ。
We deal with challenges from our customers, whether they're internal or external or both.

社内、社外、あるいはその両方にかかわらず、私たちは顧客からの課題に対処する。
So, be calm, be consistent, do your best, learn, you know, have the sixth step in your six phases of incident response is your lessons learned, your after-action report, as many of us like to call it.

だから、冷静に、一貫性を持って、ベストを尽くし、学び、インシデント対応の6つの段階における6つ目のステップは、教訓を得ることである。
So, get better afterwards.

だから、その後に良くなってくれ。
And again, everything we do has consequences, ripples in the pond, as I said.

そして、繰り返しになるが、私たちの行動にはすべて結果が伴う。
As a leader, it's particularly important for you to either learn or continue to hone soft skills.

リーダーとして特に重要なのは、ソフトスキルを身につけるか、磨き続けることだ。
So, interpersonal communication is huge.

だから、対人コミュニケーションは非常に重要なんだ。
Body language is a huge part of that, even in video.

ビデオであっても、ボディランゲージはその大きな部分を占める。
You know, you need to have empathy for what the affected victim or victims are having to deal with and what the ramifications they will have to deal with with countermeasures.

被害に遭われた方、あるいは被害に遭われた方がどんなことに対処しなければならないのか、また、対策を講じることでどんな影響があるのか、共感する必要があるのです。
You know, if you have an environment with 80,000 associates and there's no MFA, you can't just turn MFA on instantly because that goes back to crown jewels.

8万人のアソシエイトがいる環境でMFAがない場合、即座にMFAをオンにすることはできない。
If they're an e-com environment and nobody can get in to do the work, you can't sell anything.

e-comの環境で、誰も仕事をする人が入ってこなければ、何も売ることができない。
So, it takes balance.

だから、バランスが必要なんだ。
Crucial conversations happen.

重要な会話が交わされる。
Those are difficult conversations.

それは難しい会話だ。
There is a course on that, which I took years ago.

何年も前に受講したコースがある。
It's very good.

とてもおいしいよ。
And human psychology.

そして人間の心理。
It's a great hobby to have, not just for self-growth, but in general, and particularly as a leader in cybersecurity.

自己成長だけでなく、一般的に、特にサイバーセキュリティのリーダーとして、持つべき素晴らしい趣味だ。
So, even as a director or as a C-suite, if you are responsible for operations and or engineering in the space, it is very important that you maintain some technical acumen.

そのため、たとえ取締役であっても、あるいはC-suiteであっても、この分野でオペレーションやエンジニアリングを担当するのであれば、ある程度の技術的な見識を維持することが非常に重要です。
So, have a lab.

だから、研究室がある。
Spin up VMs in AWS, Azure, DigitalOcean, what have you.

AWS、Azure、DigitalOceanなどでVMをスピンアップする。
You know, and I like the example of can you do packet analysis?

パケット分析ができるかどうかという例が好きなんだ。
I can.

私はできる。
You know, it's something that is good to have as a basic fundamental skill, and doing protocol analyzer work, too, with Wireshark is also good.

Wiresharkでプロトコルアナライザーを使うのもいい。
Lastly, on this point, one of the important things we need to know is how we learn as an individual.

最後に、この点について、私たちが知るべき重要なことのひとつは、個人としてどのように学ぶかということだ。
Only we can do that for ourselves.

それができるのは自分たちだけだ。
You know, as an instructor for university courses, I can't force you to learn anything.

私は大学の講師として、あなたに何かを学ぶことを強制することはできません。
You have to go, and you have to have enough drive to be able to figure it out.

行かねばならないし、それを理解できるだけの意欲がなければならない。
So that's important, because you go on vacation, you're behind.

休暇に入れば、遅れを取ることになる。
The point is not to feel like you have to catch up, because you can never catch up.

重要なのは、追いつかなければならないと思わないことだ。
That's, again, going back to being pragmatic.

それはまた現実的な話に戻る。
Understand the environment of what you need to focus on.

何を重視すべきかという環境を理解する。
And that skill takes time, and it's a constant skill to work on.

そして、そのスキルには時間がかかり、常に努力し続ける必要がある。
Okay, some basics on organization.

さて、編成の基本をいくつか。
So I'm a strong believer in honing individual strengths of your members.

だから私は、メンバーの個々の強みを磨くことを強く信じている。
Obviously, you have diversity of background and thought in the team.

もちろん、チームには多様な経歴や考え方がある。
That is very important.

それはとても重要なことだ。
As a team grows, it's good to have people that have a non-cyber IT background.

チームが成長するにつれ、サイバーIT以外のバックグラウンドを持つ人材がいることは良いことだ。
They have a different perspective, somebody with a finance background.

彼らは異なる視点を持っている。
I've worked with those.

私はそういう人たちと仕事をしてきた。
They've worked on my team.

彼らは私のチームで働いてきた。
It's great.

素晴らしいよ。
You get different perspectives.

異なる視点を得ることができる。
And you mitigate weaknesses as best you can.

そして、できる限り弱点を緩和する。
Going back to part one, what is your SOC?

前編に戻って、あなたのSOCは何ですか？
If you don't have that answered, it's really hard to organize your team.

その答えがなければ、チームをまとめるのは本当に難しい。
And how do you organize your team?

また、どのようにチームを編成するのですか？
Into sub-teams.

サブチームに分かれる。
Do you do squads if you're an MSSP?

MSSPならスクワッドもやるのか？
Do you separate out and have a six-person cell for 15 customers, and you just multiply that out?

15人の顧客に対して6人のセルを作り、それを掛け算するのか？
Or do you break it up into current operations and future operations?

それとも、現在の事業と将来の事業に分けるのか？
Current operations is what's happening right now and in the next two weeks.

現在のオペレーションとは、現在と今後2週間のことだ。
Future operations is things that are further out and take more resources, such as detection engineering, detection as code, things like that.

将来のオペレーションとは、検知エンジニアリングやコードとしての検知など、もっと先のことであり、より多くのリソースを必要とするものだ。
Or do you just have a big pool of personnel, and you just look at the queue?

それとも、大きな人材プールを持っていて、ただ列を見ているだけなのか？
There's reasons to do all of those, and they don't have to be a static point or place in time.

そのすべてに理由があるし、固定された時点や場所である必要はない。
And again, going back to crown jewels, that should be your priorities.

そしてまた、クラウンジュエルに戻るが、それが優先事項であるべきだ。
That should go into how you divide your team up, how you handle on-call, how you handle nights and weekends.

それは、チームをどう分けるか、オンコールをどう扱うか、夜間や週末をどう扱うか、といったことにまで及ぶはずだ。
Do you have follow the sun?

太陽についていけるか？
Do you have a Panama-type schedule?

パナマのようなスケジュールはありますか？
Or do you have something else?

それとも他に何かお持ちですか？
Or are you eight to five?

それとも8時から5時まで？
So do you have an incident response plan for the organization?

では、組織のインシデント対応計画はあるのだろうか？
Do you have an incident commander?

インシデントコマンダーはいますか？
And it really doesn't matter the size.

サイズも関係ない。
It's not an excuse.

言い訳ではない。
It can be a one-pager if you're a five-person company.

5人規模の会社なら1ページで済む。
It should be more than that if you're 500,000.

50万人ならそれ以上になるはずだ。
And as I tell my mentees and students, the R in incident response is not react.

そして、私の部下や生徒たちにも言っていることだが、インシデントレスポンスのRは "react "ではない。
We have to do enough of that.

我々はそれを十分にやらなければならない。
So plan and develop accordingly.

だから、それに従って計画し、開発する。
And always remember, we are attacked at machine speed.

そして常に覚えておいてほしいのは、我々はマシンスピードで攻撃されているということだ。
It's not just a guy sitting in his basement like I am at the unofficial Rocky Mountain

ロッキー山脈の非公式大会に参加している私のように、地下室で座っているだけの男ではない。
Syntax Cyber Operations Command Bunker doing things.

シンタックス・サイバー・オペレーションズ・コマンド・バンカーは物事を行う。
So pivot your team and grow at a more machine-responsive rate.

だから、チームをピボットし、より機械的な反応速度で成長させるのだ。
Okay.

オーケー。
This is an eye chart, and it's best to talk through it.

これはアイチャートであり、話し合うのが一番だ。
So this isn't a course on OODA loops, but the idea is you quickly iterate, you look, you figure out where you are contextually, you make choices, and you act.

だから、これはOODAループのコースではないが、素早く反復し、見て、文脈的にどこにいるかを把握し、選択し、行動するということだ。
It should not be 42 steps that take three days.

3日かかる42ステップではないはずだ。
It should be, again, minutes, hours, because we are under attack at machine speed.

我々はマシンスピードで攻撃を受けているのだから。
So and in a more mature organization, not saying a larger organization, again, this could just be a few people, you need to start incorporating threat intelligence to focus the limited resources that we have on the largest threat profiles.

そのため、より成熟した組織（大規模な組織とは言わないが、やはり数人で構成される場合もある）では、限られたリソースを最大の脅威プロファイルに集中させるために、脅威インテリジェンスを取り入れ始める必要がある。
And you can put this together using open source intelligence work, OSINT.

そして、オープンソースのインテリジェンスワーク、OSINTを使ってこれをまとめることができる。
So you have some process in place, and there is incident handling that escalates, and you now have an incident to respond to.

つまり、何らかのプロセスがあり、インシデント処理がエスカレートし、対応すべきインシデントが発生する。
So as we mentioned earlier, it didn't clear out, so it got considered a potential incident.

だから、先ほども言ったように、クリアにならなかったので、潜在的なインシデントと見なされるようになった。
Okay.

オーケー。
Well, what work have you done to contextualize this with threat data against the organization's threat profile?

では、組織の脅威プロフィールに照らし合わせて、脅威データとの関連付けを行うためにどのような作業を行ったのですか？
Build a threat profile.

脅威プロファイルを構築する。
Start out with what market verticals you're in.

まず、あなたがどのような市場垂直方向にいるのかから始めましょう。
Go through your board of directors, your C-suite, your other important parts of the organization, and critical infrastructure.

取締役会、C-suite、組織のその他の重要な部分、そして重要なインフラを調べ上げる。
It could be your credit card data environment.

クレジットカードのデータ環境かもしれない。
If you have to do PCI DSS type of work with credit card information that's not encrypted or hashed, and it could be anything else along those lines.

暗号化もハッシュ化もされていないクレジットカード情報を使ってPCI DSSのような作業をする必要がある場合、その線上にあるものなら何でもあり得る。
So you should have a process of doing threat hunting against that threat intelligence data to better understand and build a threat product so you know what your environment is and or your customers.

そのため、脅威インテリジェンス・データに対して脅威ハンティングを行い、脅威製品をよりよく理解し、構築するプロセスを持つべきです。
So you can, again, rapidly focus in on what are the latest indicators of compromise, IOCs, the latest known campaigns, and the previous campaigns.

そのため、繰り返しになるが、妥協の最新指標、IOC、既知の最新キャンペーン、過去のキャンペーンに迅速に焦点を絞ることができる。
Just because it's an old campaign doesn't mean it's not a good campaign and won't get used again or reused by other actors.

古いキャンペーンだからといって、それが良いキャンペーンではなく、再び使われたり、他のアクターによって再利用されたりすることがないとは限らない。
Call them copycats.

彼らは模倣犯と呼ばれている。
That's also common.

それもよくあることだ。
Do some pen testing, whether it's third party or internal red teaming or purple teaming.

サードパーティであれ、社内のレッド・チーミングであれ、パープル・チーミングであれ、ペン・テストを実施する。
Use real threat-based work that's been observed or researched.

観察または研究された、実際の脅威に基づいた作品を使用すること。
And the idea is you already have some detections in place.

そして、あなたはすでにいくつかのディテクションを持っているということだ。
And if not, this is a process where you identify those.

そうでない場合は、それを特定するプロセスだ。
You do threat analysis work based on that to help understand how to process that information and have the analysts work it.

その情報をどのように処理するかを理解し、アナリストに作業させるために、それに基づいて脅威分析作業を行う。
And then you follow that up by doing detection engineering to create a new detection or you tune existing detections based upon changes in the threat landscape as it does change.

その後、検知エンジニアリングを行って新しい検知を作成したり、脅威の状況の変化に応じて既存の検知を調整したりする。
And for this example, for each of those phases, you need to rapidly go through effectively the OODA loop process.

そしてこの例では、それぞれの段階において、効果的にOODAループのプロセスを迅速に進める必要がある。
One caveat that a lot of people fall into, it's a trap, is they'll go straight from observe to act.

多くの人が罠にはまる注意点として、観察から行動に直行することだ。
Spend a few minutes, a few hours, orienting and deciding.

数分でも数時間でも、方向づけと決断に費やす。
Again, everything has impacts to the target organization for any kind of countermeasures or detections.

繰り返しになるが、あらゆる対策や検知は、対象となる組織に影響を与える。
So all part of being organized and responsive and not reactive.

組織的で、反応的でなく、対応的であることの一部なんだ。
So if you do not measure it, you cannot manage it, do not know who wrote that, it was not

だから、それを測定しなければ、管理することはできない。
Peter Drucker, although he gets attributed with it often.

ピーター・ドラッカーはよくそう言われるが。
So what are some things as a leader you can do?

では、リーダーとしてできることは何だろうか？
At the highest level, I would call them OKRs, your objectives and key results.

最も高いレベルでは、私はOKRと呼んでいる。
I like to have them as quarterly goals, generally speaking.

私は四半期ごとの目標を持つのが好きなんだ。
We're going to work on initial detection as code, pipeline deployment using SGMA rules in a quarter.

四半期後にはSGMAのルールを使って、コードとしての初期検出、パイプライン展開に取り組むつもりだ。
And it may be nascent, it may be a 0.5 version of it, that's okay.

そして、それは初期段階かもしれないし、0.5バージョンかもしれない。
What's the next quarter going to do to that, right?

次の四半期はどうなるんだ？
Have these as goals.

これらを目標として持つ。
If you work in a large environment that is doing Agile safe, scaled Agile framework, that can very easily feed into your program increment, your PI planning as well.

アジャイル・セーフ、スケーラブル・アジャイル・フレームワークを採用している大規模な環境で働いている場合、それはプログラム・インクリメントやPIプランニングにも容易に反映される。
Have the process work for you as much as possible, as challenging as that can be at times.

それは時に困難なことかもしれないが、可能な限りプロセスを自分のものにしてほしい。
So service level agreements, SLAs, that term gets abused.

だからサービス・レベル・アグリーメント（SLA）という言葉が乱用される。
So SLAs are high level, relatively speaking, objectives that we agree to meet whether internally or in the case of an MSP, MSSP environment, it's going to be tied to contract documents or it should be anyway.

SLAとは、比較的高いレベルの目標であり、社内であれ、MSPやMSSPの環境であれ、満たすことに合意するものです。
An easy example building off that is after the SOC identifies an incident from the EDR within five minutes of that escalation, an alert goes out to the customer or to the SOC to work it depending on what the construct is of the SOC and the contractual requirements.

簡単な例を挙げると、SOCがEDRからインシデントを発見してから5分以内にエスカレーションを行い、SOCの構成や契約要件に応じて、顧客またはSOCにアラートを出して対応する。
But it's not, this is not atomic level indicators.

しかし、これは原子レベルの指標ではない。
That would be a bad place to put them, having done many, many contracts.

何度も何度も契約を結んできた彼らにとって、それは悪い場所だろう。
So next level you take internally, it wouldn't go in the contract normally, would be service level objectives, SLOs.

その次のレベルとして、通常は契約書には記載されないが、サービス・レベル目標（SLO）がある。
Okay.

オーケー。
So the SOC has to meet a five-minute SLA.

つまり、SOCは5分間のSLAを守らなければならない。
How do we do that?

どうすればいいんだ？
Well, we want to get a two-minute alert process to make it an incident in two minutes based upon those atomic indicators.

その原子指標に基づき、2分後にインシデントが発生するような2分間のアラート・プロセスが欲しい。
What are and where do atomic indicators live?

原子指標とは何か？
They should live at the SLI, the service level indicators level.

彼らはSLI（サービス・レベル指標）レベルで生きるべきだ。
That would be things you cannot break down anymore.

それはもう壊せないものだろう。
That could be something such as an IOC, hashes, domain names, IP addresses.

それは、IOC、ハッシュ、ドメイン名、IPアドレスなどである。
The point is to contextualize event data and to feed that back up through the process.

ポイントは、イベントデータを文脈化し、それをプロセスを通じてフィードバックすることだ。
So these are things we can do irrespective of all the chaos that can and will often come with security operations.

つまり、治安維持活動にともなう混乱とは無関係に、私たちができることなのだ。
So this picture I pulled from Twitter from hacking articles, I like it as a baseline.

だから、この写真はTwitterのハッキング記事から引っ張ってきたもので、ベースラインとして気に入っている。
I would say tweak it for your organization.

あなたの組織に合わせて調整すればいいと思う。
But, you know, here's an idea for what we call job qualification requirements, JQRs, for a SOC analyst one.

しかし、SOCアナリストの職務資格要件（JQR）と呼ばれるものを考えてみよう。
You should be able to do these types of things, understand what the diamond model of intrusion analysis is, and be able to give descriptive analysis work.

このようなことができ、侵入分析のダイヤモンドモデルとは何かを理解し、記述的な分析作業ができるようになる必要がある。
And as a leader, one of the things you want to do with areas such as this is you want to establish a baseline, whether it's style guides or something along those lines.

リーダーとして、このような分野でやりたいことのひとつは、スタイルガイドであれ何であれ、ベースラインを確立することだ。
You want it to be consistent and repeatable.

一貫性があり、反復可能であることが求められる。
You don't want to have everything to be special, you know, special snowflake, as we like to say.

すべてを特別なものにしたいとは思わないだろう。
You should understand the basics of threat modeling.

脅威モデリングの基本を理解する必要がある。
Depending on your organization, you should understand the basics of the frameworks, PCI-DSS,

組織によっては、PCI-DSSというフレームワークの基本を理解しておく必要があります、
NIST, HIPAA, sometimes all of those, and their importance.

NIST、HIPAA、時にはそれらすべて、そしてそれらの重要性。
With frameworks, regardless of what the framework is, you should also recognize that they're not straitjackets, they should be adapted to the organization.

フレームワークが何であるかにかかわらず、フレームワークは拘束衣ではないことを認識し、組織に適応させるべきだ。
That is an entirely different talk.

それはまったく別の話だ。
So you should understand the fundamentals of vuln management.

だから、バルーン管理の基本を理解すべきだ。
The difference between vuln management and enterprise patch management, to me, is you have threat overlay for that.

バルーン管理とエンタープライズ・パッチ管理の違いは、脅威のオーバーレイがあることだ。
Just because you're patching the top vulnerabilities does not mean you're doing vuln management.

上位の脆弱性にパッチを当てているからといって、バルーンマネジメントをしているとは言えない。
Because as you get more into threat-related work and you dig into it, you'll realize that the bad guys, the more sophisticated bad guys, tend to use a lower level of vulnerabilities.

というのも、脅威関連の仕事に携わり、それを掘り下げていけばいくほど、悪者たち、より洗練された悪者たちは、より低いレベルの脆弱性を使用する傾向があることに気づくだろう。
They tend to string them together and do their compromises, drop their mal-doc, do the business email compromise, take your session cookie for your ZTNA access, et cetera.

彼らは、それらをつなぎ合わせて妥協し、マルドクを落とし、ビジネスメールを妥協し、ZTNAアクセス用のセッションクッキーを取る、などといったことをする傾向がある。
It sells well to talk about zero days, but the reality is typically not that.

ゼロ・デーの話はよく売れるが、現実はそうではないのが普通だ。
We have to deal with the more mundane.

もっと平凡なことに対処しなければならない。
We'll talk about that on the next slide a bit.

次のスライドで少しお話ししましょう。
So understand the differences between risk and threat and vulnerability.

だから、リスクと脅威と脆弱性の違いを理解すること。
Again, packet analysis.

もう一度言うが、パケット分析だ。
Understand the basics of the SIEM that you should be using.

使用すべきSIEMの基本を理解する。
And understand how you're supposed to respond.

そして、自分がどう対応すべきかを理解する。
And understand as a Tier 1 how you are to support incident handling.

そして、ティア1としてインシデント対応をどのようにサポートすべきかを理解すること。
As a Tier 1, at least from my perspective, it's unfair and unreasonable to have a Tier 1 analyst be conducting, leading the IR process.

ティア1として、少なくとも私の視点からは、ティア1のアナリストがIRプロセスを指揮、主導するのは不公平で理不尽だ。
Supporting it?

サポートする？
Absolutely.

もちろんだ。
Doing aspects of it.

そういう面もある。
But understand where you fit in the picture.

しかし、自分がどの位置にいるのかを理解することだ。
Understand events.

イベントを理解する。
Understand incidents.

事件を理解する。
And the breach word, the B word, is not a SOC term.

違反の言葉、Bの言葉はSOCの用語ではない。
It is a legal term.

法律用語である。
Just for the U.S. at below federal levels of state, territories, and districts, there are at least 54 laws on the books at that level that define what a breach is.

連邦レベル以下の州、準州、郡レベルの米国だけでも、違反とは何かを定義する法律が少なくとも54本ある。
That's not water cooler talk anymore.

それはもう水掛け論ではない。
So when your legal department says it's a breach or your customers, then you call it a breach.

つまり、法務部門が違反だと言えば、あるいは顧客が違反だと言えば、それを違反と呼ぶわけだ。
And again, soft skills are important for everyone.

そしてまた、ソフトスキルは誰にとっても重要だ。
We deal with customers.

私たちは顧客を相手にしている。
And it's important to hone those skills.

そして、そのスキルを磨くことが重要だ。
All right.

分かった。
So as all things are with cyber, it depends on your personal drive and ambition.

つまり、サイバーに関わるすべてのことがそうであるように、個人の意欲と野心次第ということだ。
So here are some areas, some breadcrumbs, if you will, to go after.

そこで、追いかけるべきいくつかのエリア、いわばパンくずを紹介しよう。
Or to, as me and others often do, we knock the dust off of these.

あるいは、私や他の人がよくやるように、これらの埃を叩き落とす。
So if you've ever searched for how to stop ransomware on Google, I'm sorry.

Googleでランサムウェアを止める方法を検索したことがある方、ごめんなさい。
Because most of it is regurgitated information, and it's not useful.

なぜなら、そのほとんどが使い古された情報であり、役に立たないからだ。
So what actually causes it are what would be characterized in the CIS top six.

では実際に何が原因かというと、CISのトップ6に特徴的なものがある。
What are your physical virtual assets, your hosts?

物理的な仮想資産、ホストとは何か？
What applications do you have?

どんなアプリケーションを持っていますか？
What level of access?

アクセスのレベルは？
How do you control it?

どうやってコントロールするのですか？
Do you have your active directory?

アクティブ・ディレクトリはありますか？
Do you have your file share internet exposed either directly or indirectly?

ファイル共有のインターネットが直接、あるいは間接的に公開されていませんか？
That's how those things happen.

そういうことが起こるんだ。
Do you have it really easy for your admins to get to the domain controllers or other domain attached servers?

管理者がドメインコントローラーや他のドメインに接続されたサーバーにアクセスするのは本当に簡単ですか？
Or do you have a process, you know, be it a bastion host type of setup or something along those lines?

それとも、そのようなプロセス、つまり、要塞ホストのようなセットアップとか、そういうものがあるのですか？
Again, defense in depth.

繰り返すが、ディフェンス・イン・デプスだ。
So that affects your business email compromise as well.

そのため、ビジネスメールの危殆化にも影響する。
And by the way, your wire and invoice fraud.

ところで、電信送金詐欺と請求書詐欺についても。
So there's no magic in it.

だから、魔法なんてないんだ。
There's just work.

仕事があるだけだ。
So a recent book is the new version of building a world-class cybersecurity operations center for MITRE.

最近出版された本は、MITREの世界クラスのサイバーセキュリティ・オペレーション・センターを構築するための新しいバージョンだ。
It's fantastic.

素晴らしいよ。
I know Carson personally, he's one of the authors of this one.

私は個人的にカーソンを知っている。
He authored the first book solo about nine years ago.

彼は約9年前にソロで最初の本を執筆した。
Fantastic reference, highly recommend it.

素晴らしい参考書だ。
If you're not using for incident response, characterization, contextualization, and sharing

インシデント・レスポンス、特性分析、文脈分析、共有に使用していない場合
Veris, go learn about Veris.

ベリス、ベリスについて学んでこい
You should understand diamond model of intrusion analysis as well and how the cyber kill chain framework works in there.

侵入分析のダイヤモンドモデルや、サイバーキルチェーンフレームワークの仕組みについても理解しておく必要がある。
And last but not least, even though it gets mentioned first a lot, how do you employ the

そして最後に、よく最初に言及されることではあるが、どのように採用するか。
MITRE ATT&CK framework?

MITRE ATT&CKフレームワーク？
My favorite way to start that is at the enterprise level.

私が一番好きなのは、企業レベルから始めることだ。
What are they after?

何を狙っているのか？
Are they after data or are they trying to burn it down, your environment down?

データを狙っているのか、それとも環境を破壊しようとしているのか？
Or both?

それとも両方？
Or can they potentially do both?

それとも両方できる可能性があるのか？
And then you work from there.

そして、そこから仕事をする。
You take the information from doing your intelligence profile, that dossier, and then you go work

諜報活動から得た情報、つまり一件書類を作成し、それから仕事をする。
MITRE ATT&CK framework to see what they're doing.

MITRE ATT&CKのフレームワークで、彼らが何をしているのかを確認する。
Again, no magic, it's just work.

繰り返しますが、魔法ではありません。
And with that being said, Shilpa, back over to you.

ということで、シルパ、話を戻そう。
Thank you so much, Andy.

ありがとう、アンディ。
Thank you very much for an informative session and our attendees share the same sentiments.

有益なセッションをありがとうございました。
Before we begin with the Q&A part, I would like to inform all the attendees that this session is in sync with EC council certification, CSA, maps to the SOC analyst role, and even with the CSA certification is eligible for $13,000 plus job with an average salary of $85,000.

Q&Aパートに入る前に、このセッションはECカウンシルの認定資格であるCSAと同期しており、SOCアナリストの役割にマッピングされ、CSAの認定資格を持っていても、平均給与85,000ドルで、13,000ドルプラスの仕事を得る資格があることを、参加者の皆さんにお知らせしたいと思います。
If you're interested to learn more about our programs, do let us know in the poll that's going to be conducted now.

私たちのプログラムについてもっと知りたいと思われる方は、これから実施される投票でお知らせください。
Let us know your preferred mode of training and we will reach out to you soon.

ご希望のトレーニング方法をお知らせください。
So Randy, shall we start with the Q&A?

ではランディ、Q&Aから始めようか？
Absolutely.

もちろんだ。
Okay.

オーケー。
Our first question is, what is the RACI matrix by Shivaraman?

最初の質問は、シバラマンによるRACIマトリックスとは何かということだ。
So the RACI or the RACI, it's a matrix of who's responsible, who is accountable, who is consulted and who is informed.

つまり、RACIとは、誰が責任を持ち、誰に責任を負わせ、誰に相談し、誰に情報を伝えるかというマトリックスなのだ。
And you basically break down processes that you have to work.

そして、基本的に自分が働かなければならないプロセスを分解するんだ。
Something as basic as incident response, who is responsible for that?

インシデント対応と同じくらい基本的なことだが、誰がその責任を負うのか？
The SOC is.

SOCは
Who is accountable for that?

誰がその責任を負うのか？
The SOC is.

SOCは
Who is consulted?

誰に相談するのか？
Other groups could be IT, could be legal, et cetera.

他のグループは、ITであったり、法律であったり、いろいろだ。
And informed could be the CTO as an example.

CTOの例もある。
There's lots of examples online for that to give you some ideas, but it's important to have that.

ネット上にたくさんの例があるので、アイデアを得ることができる。
If anything taught us that it was the conviction of the former Uber CISO last summer.

それを教えてくれるものがあるとすれば、昨夏のウーバー元CISOの有罪判決だろう。
Thank you, Randy, for answering that question.

ランディ、質問に答えてくれてありがとう。
Next question is, when we say five-minute SLI, is it at first level incident responder or like Tire 1 by Gullen?

次の質問だが、5分間のSLIというのは、第一レベルのインシデント・レスポンダーのことなのか、それともガレンのタイヤ1のようなものなのか？
Well, that was an example.

それは一例だ。
It can be anything.

何でもいいんだ。
Your SLA could be, for the same thing, it could be 15 minutes or an hour.

SLAは15分かもしれないし、1時間かもしれない。
There tend to be various types of SLAs and that really gets into contract discussions and that varies from, or potentially contract discussions, and it varies from customer to customer.

SLAにはさまざまな種類があり、契約に関する議論に発展することもあれば、契約に関する議論に発展する可能性もある。
But the idea is either if it's internal at the organizational level across departments, directorates, and the C-suite, there's an understanding of how we respond and that's communicated or it's with customers and that's communicated as well.

しかし、その考え方は、部門、取締役、C-suiteにまたがる組織レベルでの内部的なものであれば、私たちがどのように対応するかを理解し、それを伝えるか、あるいは顧客との関係であれば、それも同様に伝えるというものだ。
Thank you, Randy.

ありがとう、ランディ。
Our next question is, would love to have some guidance on open source SIEM, EDR, XDR, NDR tools, as well as some affordable options by Gerhard.

次の質問は、オープンソースのSIEM、EDR、XDR、NDRツール、およびゲルハルト氏による手頃な価格のオプションについて、ガイダンスが欲しいというものだ。
Product discussions.

製品に関する議論。
I'm not going to have a great answer for that because I get to focus on operations for the first time ever here at Syntax and not engineering.

というのも、私はシンタックスで初めて、エンジニアリングではなくオペレーションに専念することになったからだ。
I have a fantastic engineering counterpart director and I am not completely up to date on giving that.

私には素晴らしいエンジニアのカウンターパートのディレクターがいる。
There are a few options.

選択肢はいくつかある。
You just got to dig into the, and see where the, some of those have gotchas as far as how potential licensing goes.

ライセンス取得の可能性に関して、どこが問題なのかを調べなければならない。
But if it's on GitHub, chances are, yeah, it takes some research, but you will come away after probably several hours with the basic answers.

でも、GitHubにあるのなら、多少のリサーチは必要かもしれないが、おそらく数時間後には基本的な答えが得られるだろう。
You'll have it narrowed down to a few options for EDR or for SIEM, because there are not a lot of options.

EDRやSIEMは選択肢が少ないので、いくつかの選択肢に絞られるでしょう。
Thank you, Randy, for answering that question.

ランディ、質問に答えてくれてありがとう。
Our next question is, what is your suggestion on creating an incident ticket in ITSM for every alert triggering in SIEM?

次の質問は、SIEMでアラートがトリガーされるたびに、ITSMでインシデントチケットを作成することについての提案です。
Do you think it's the right approach or do we have to log on, log an incident ticket only for those alerts which are investigation worthy?

それとも、調査に値するアラートに対してのみ、ログオンしてインシデントチケットを記録しなければならないのでしょうか？
Secondly, what metrics do you suggest we prepare to showcase SOC performance to CISO?

次に、SOCのパフォーマンスをCISOに示すために、どのような指標を用意すればよいでしょうか。
Okay, so, and I've dealt with and encountered extremes.

それで、私は極端なものを扱ってきたし、出会ってきた。
So sending any alerts as an ITSM incident from SOC is not really beneficial.

そのため、SOCからITSMインシデントとしてアラートを送信することは、あまり有益ではない。
So that's, and that's why I was specific in saying the SOC escalates anything that comes in, whether it's from ITSM or from the instrumented enterprise environment.

SOCは、ITSMからであろうと、計装化された企業環境からであろうと、入ってきたものは何でもエスカレーションするというのが、私が具体的に述べた理由です。
The SOC must characterize it, whether manually or automatically or some combination thereof, as a security incident.

SOCは、手動であれ自動であれ、あるいはそれらの組み合わせであれ、これをセキュリティ・インシデントとして特徴付けなければならない。
That should most certainly be an ITSM incident, preferably automated.

それはITSMのインシデントであるべきで、できれば自動化されていることが望ましい。
So that, because what you end up with is you end up with alert fatigue rapidly, particularly from security devices.

その結果、特にセキュリティー機器からのアラートに対する疲労が急速に蓄積することになる。
If anything, security devices tend to be, shall we say, chatty.

どちらかといえば、セキュリティ・デバイスは、言ってみればおしゃべりな傾向がある。
We don't want to send 100,000 events per day to ITSM as alerts, for instance.

例えば、1日に10万件ものイベントをアラートとしてITSMに送りたくない。
That's very easy to do even in fairly small environments.

かなり小さな環境でも、それはとても簡単なことだ。
So you want to process it.

だから処理したいんだろう。
So one of the things you have to consider during the lifecycle maturity of your SOC and looking at the SLAs, whether contractually or internal agreements, they need to be reasonable.

そのため、SOCのライフサイクルが成熟する過程で考慮しなければならないことのひとつは、契約上であれ内部契約上であれ、SLAが妥当なものでなければならないということだ。
Five minutes may be completely unreasonable if you have a SOC of three people working eight to five.

3人のSOCが8時から5時まで働いているのであれば、5分という時間はまったく理不尽かもしれない。
Maybe it's six hours, maybe it's 12 hours, probably not five minutes.

6時間かもしれないし、12時間かもしれない。
So there has to be a process in there.

だから、そこにはプロセスが必要なんだ。
And again, it's not fair to a tier one analyst to say this is an incident versus it is a probable incident and then escalated internally to a tier two SOC, for instance.

繰り返しますが、ティア1のアナリストが、これはインシデントだと言うのと、インシデントの可能性が高く、ティア2のSOCなどに内部でエスカレーションされるのとでは、フェアではありません。
So that comes with maturity.

それは成熟に伴うものだ。
That's a nightmare, sending all of your alerts as tickets.

すべてのアラートをチケットとして送信するなんて悪夢だ。
And the second part, totally lost my train of thought.

そして後半は、完全に思考回路が狂ってしまった。
What was the second part?

第2部は何だったのですか？
Thank you, Randy, for answering the question.

ランディ、質問に答えてくれてありがとう。
Our next question is, could you please tell us some SIEM tools and techniques used at industry level so that as SOC L1 must be learned before entering into the industry by Pradeep?

次の質問ですが、SOC L1として業界に入る前に学ぶべき、業界レベルで使用されているSIEMツールとテクニックを教えてください。
Okay, I will tell you like I tell my students when I teach different courses.

では、私がいろいろなコースを教えるときに生徒たちに話すように、あなたにも話してあげよう。
Learn one of the following in any order.

以下のいずれかを順不同で学ぶ。
Learn Azure Sentinel, learn Splunk, learn Elastic.

Azure Sentinelを学び、Splunkを学び、Elasticを学ぶ。
Learn one of them well enough to do queries, to build a dashboard, do enough qualitative analysis to build a representative dashboard.

クエリーを行い、ダッシュボードを構築し、代表的なダッシュボードを構築するのに十分な質的分析を行うために、そのうちの1つを十分に学ぶ。
Perfect example I also give is build a dashboard and, you know, it's for your customer, this fictitious customer, and have a VM fire off something that is or looks like PSExec.

ダッシュボードを作り、顧客（架空の顧客）のためにVMからPSExecのようなものを起動させる。
That one always makes the hair on the back of my neck stand up, regardless if it's legitimate or not.

それが正当なものであろうとなかろうと、いつも首の後ろの毛が逆立ってしまう。
So that is a tool that is either actually PSExec, which is basically a remote administration Windows tool, or it is something masquerading as that.

つまり、このツールの正体はPSExecであり、基本的にWindowsのリモート管理ツールであるか、あるいはそれを装ったものである。
That is a common TTP that is used by bad guys.

これは悪者がよく使うTTPだ。
So that's an easy thing to dig into, and you'll learn a bit about a SIEM.

SIEMについて少し学ぶことができます。
You'll learn a bit about doing queries, such as, you know, SPL and Splunk, build a basic dashboard, and contextualize so you understand.

SPLやSplunkなどのクエリについて少し学び、基本的なダッシュボードを作成し、文脈を理解できるようにします。
So as a hiring manager, it's important to me to understand that you know why you did something, and the so what of what was done.

ですから、採用担当者としては、あなたがなぜ何かをしたのか、何をしたのか、その「So What」を理解していることが重要なのです。
You can talk through that, not just make a pretty dashboard.

きれいなダッシュボードを作るだけでなく、それを通して話し合うことができる。
So great question.

素晴らしい質問だね。
Thank you, Randy, for answering that question.

ランディ、質問に答えてくれてありがとう。
Our next question is, what is your opinion on having an incident severity calculator?

次の質問は、インシデントの深刻度計算機を導入することについてどう思われますか？
What would be the right criteria to be considered for developing this calculator by Amir?

アミールがこの電卓を開発するために考慮すべき基準は何だろう？
Well, that is going to be something that needs tuning continually, just because, again, such as PSExec FireResolve doesn't mean it's actually an incident.

PSExecのFireResolveのように、継続的なチューニングが必要だからといって、実際にインシデントが発生するわけではない。
It could just be an alert.

単なる警告かもしれない。
So you have to dig into things such as detection engineering.

だから、検出工学などを掘り下げる必要がある。
Are they obfuscating the fact, are they just saying, oh, it's this process, but it's running from your Chrome browser?

彼らは事実を難解にしているのだろうか？このプロセスはクロームブラウザから実行されている、と言っているだけなのだろうか？
That's not PSExec.

それはPSExecではない。
That's malware, fileless malware.

これはマルウェアで、ファイルレスのマルウェアだ。
So something as simple as that.

そんな単純なことだ。
And again, this goes back to doing a basic OSINT, open-source intelligence-based investigation.

そしてまた、これは基本的なOSINT、オープンソースインテリジェンスに基づいた調査を行うことに戻る。
And it could just be on yourself, your own organization, to say, I'm in these market verticals.

そして、自分自身や自分の組織で、私はこのような市場垂直統合に参加していると言うこともできる。
These are my NAICS codes.

これが私のNAICSコードだ。
I'm in manufacturing, and I'm in healthcare.

私は製造業で、医療にも携わっている。
Okay, well, these are the actors that tend to operate in there.

なるほど、そこで活動しがちな俳優たちだ。
So I want to prioritize alerting and eventing and potential incident processing on these lower-level CVEs.

だから、これらの低レベルのCVEに対するアラート、イベント、潜在的なインシデント処理を優先したい。
Maybe you have Qualys or Rapid7 or any other vulnerability scanner.

もしかしたら、QualysやRapid7などの脆弱性スキャナーを持っているかもしれない。
You enrich that event processing with more contextualized data to say, oh, well, this CVE is lower-level.

そのイベント処理をより文脈に沿ったデータで充実させ、ああ、このCVEは下位レベルなんだ、と言えるようにする。
It's a low, but it's higher for us because, contextually, this is how things tend to look based upon actor campaigns.

これは低い数字だが、私たちにとっては高い数字だ。というのも、文脈上、俳優のキャンペーンに基づくと、このように見える傾向があるからだ。
So you don't have to have an Intel team to do this.

だから、インテルチームがなくてもできるんだ。
As a leader, spend a weekend, do some research, and come up with a basic set.

指導者としては、週末を費やしてリサーチし、基本的なセットを考える。
You don't have to try and solve all your problems and go for 80% Pareto principle at play always.

すべての問題を解決しようとする必要はないし、常に80％のパレート原理を目指す必要もない。
Great question.

いい質問だね。
Thank you, Randy.

ありがとう、ランディ。
Our next question is, what is the best recommendation MSSSP SOC can give to client for brute-force attack on accounts even having MFA applied?

次の質問は、MFAが適用されているアカウントに対するブルートフォース攻撃について、MSSSP SOCがクライアントに与える最善の推奨事項は何かということだ。
Bye, Valit.

さようなら、ヴァリット。
Well, that landscape constantly changes.

まあ、その風景は常に変化している。
You have a lot of different vectors.

いろいろなベクトルがあるね。
Let's say you're using Azure Active Directory.

Azure Active Directoryを使っているとしよう。
There are controls you can put in place, and some of those vary depending on the level of service.

サービスレベルによって異なるが、あなたが導入できるコントロールがある。
Is it a P1, is it a P2, et cetera, to help with that?

P1なのか、P2なのか。
You know, the unrealistic travel is useful.

非現実的な旅は役に立つよ。
Geoblocking, in general, is not very useful.

一般的に、ジオブロッキングはあまり役に立たない。
There are these things called VPNs and zombies and the Tor network.

VPNやゾンビ、Torネットワークと呼ばれるものがある。
So that has limited runway, if you will.

だから滑走路は限られている。
Other things that you can do and should look at are advertisement networks, ad networks.

他にも、広告ネットワーク、広告ネットワークがある。
They're also called malvertisement networks for a good reason.

不正広告ネットワークと呼ばれるのには理由がある。
There is not really much vetting on the provenance and pedigree of the code that is uploaded there.

そこにアップロードされるコードの出所や血統については、あまり吟味されていない。
So it is a common transport for malware.

つまり、マルウェアの一般的な輸送手段なのだ。
Has been for years.

もう何年もそうだ。
That has not changed.

それは今も変わっていない。
So how do you handle that?

では、どう対処する？
Something as simple as blocking ad networks as well.

広告ネットワークもブロックするという単純なものだ。
So there's quite a lot, and you always have to look at different ways to do it.

だから、非常に多くのことがあり、常にいろいろな方法を考えなければならない。
But depending on your environment, there are definitely ways to do it.

しかし、あなたの環境次第では、絶対に方法はある。
You know, obviously, you have to look at your supply chain.

サプライチェーンに目を向ける必要があるのは明らかだ。
I mean, I showed you the Okta breach from last summer, the LastPass breach.

つまり、昨年夏のOktaの情報漏洩やLastPassの情報漏洩をお見せしました。
The list goes on and on.

リストはまだまだ続く。
It's not a question of if but when for compromises and breaches.

妥協や違反は、「もし」ではなく「いつ」の問題なのだ。
Again, pragmatic, how do you do the best you can?

もう一度言うが、現実的な話として、どうすればベストを尽くせるのか？
So great question.

素晴らしい質問だね。
Thank you.

ありがとう。
Thank you, Randy.

ありがとう、ランディ。
Next question is, would you say that diamond model of intrusion analysis may probably be suitable in the establishment of SOC?

次の質問は、ダイヤモンド・モデルの侵入分析がSOCの設立に適しているということでしょうか？
At least in a basic form, you don't have to devote a whole lot of time to it.

少なくとも基本的な形であれば、それに多くの時間を割く必要はない。
It helps you characterize what's going on at the initial stages.

初期段階で何が起こっているのかを特徴づけるのに役立つ。
Before you dive into something such as the kill chain and or going directly into MITRE ATT&CK.

キルチェーンやMITRE ATT&CKに直接飛び込む前に。
There's reasons to do any of those, but from an organization standpoint and building processes on how you do things, yeah.

でも、組織という観点や、物事の進め方のプロセスを構築するという観点からは、そうだね。
Just do the basics and just characterize those few key points as best you can.

基本的なことをやり、いくつかの重要なポイントをできる限り特徴づけるだけでいい。
Thank you, Randy.

ありがとう、ランディ。
We'll take last two questions for the day.

最後に2つの質問を受け付けます。
Our next question is, any best open source threat intelligence for SOC?

次の質問は、SOCに最適なオープンソースの脅威インテリジェンスはあるか？
Yeah, I'm trying to remember any of them off the top of my head.

ああ、頭の中でどれかを思い出そうとしているんだ。
As far as threat feeds go, data feeds, they exist.

脅威のフィードに関しては、データフィードは存在する。
I know Alienware got bought out.

エイリアンウェアが買収されたのは知っている。
That's the only one I can think of, not Alienware, but AlienVault, I think it is.

Alienwareではなく、AlienVaultだと思います。
They got bought out, I think, by Dell, but that's an available source.

デルに買収されたと思うが、それは入手可能な情報だ。
The important thing about threat intelligence is it's not information, it's data.

脅威インテリジェンスについて重要なことは、それは情報ではなくデータだということだ。
The SOC is responsible for building threat products, just as it's responsible for building any other security operations-related products.

SOCは、他のセキュリティ運用関連製品の構築と同様に、脅威製品の構築にも責任を負う。
We have to process it.

それを処理しなければならない。
We have to contextualize it, and frankly, we have to filter it because we get a lot of not necessarily useful information.

私たちはそれを文脈化しなければならないし、率直に言って、必ずしも有益とは言えない情報がたくさん入ってくるので、フィルタリングしなければならない。
I wouldn't say it's bad information, but contextually irrelevant.

悪い情報とは言わないが、文脈的には関係ない。
That happens more often than not.

そういうことはよくあることだ。
So sifting through that is something that you have to do on an iterative basis.

だから、それをふるいにかけていくのは、繰り返しやっていかなければならないことなんだ。
Everything I've talked about today, I didn't use the A word, agile.

今日話したことはすべて、アジャイルというAワードは使っていない。
This is all DevSecOps.

これはすべてDevSecOpsだ。
That's what all of this conversation has been today, so good question.

それが今日の会話のすべてだ。
Thank you, Randy, so much for answering that question.

ランディ、質問に答えてくれてありがとう。
We'll take the last question for the day.

今日の最後の質問を受けます。
Can you explain more on SOC playbook and SOC runbook?

SOCプレイブックとSOCランブックについて詳しく教えてください。
Can I see a sample SOC playbook and a sample of SOC runbook?

SOCプレイブックのサンプルとSOCランブックのサンプルを見ることはできますか？
I unfortunately do not have the time to show examples.

残念ながら、例をお見せする時間がない。
So the basic difference between a play and a runbook and how you would want to construct them is the playbook you want to build out as the overarching response to how you handle, let's say, just a campaign.

つまり、プレイとランブックの基本的な違いと、それらをどのように構築したいかということです。プレイブックは、例えばキャンペーンをどのように扱うかという包括的な対応として構築したいものです。
You know, this APT group is doing this particular campaign.

このAPTグループは、この特別なキャンペーンをやっているんだ。
We're bucketizing all of the intelligence and detections and automations in this, and the associated runbooks are go pull this information in, enrich from this source.

インテリジェンス、検出、自動化などすべてをバケツ化し、関連するランブックはこの情報を取り込み、このソースからリッチにする。
It's the discrete tasks that you want to go do.

それは、あなたが行ってやりたいと思う個別の仕事だ。
Go shell into this console and scrape this information back and bring it in.

このコンソールのシェルに入り、この情報をスクレイピングして取り込んでくれ。
Pull this data feed, that kind of thing.

このデータフィードを引き出すとか、そういうことだ。
That way, the idea is you have consistency in your runbooks, and as you build out the playbooks, you can pick and choose.

そうすることで、ランブックに一貫性を持たせることができ、プレイブックを作り上げるにつれて、選択することができるようになる。
You know, I'm going to the automation and organization store.

オートメーションと整理整頓の店に行くんだ。
I'm going to put these things in my playbook, you know, basket, and I'm going to build this product.

これらのことをプレーブックに入れて、バスケットに入れて、この製品を作るんだ。
That way, you can scale.

そうすれば、規模を拡大できる。
Everything we do has to have an idea and thought to scaling, whether it's scaling up or scaling down.

私たちがやることはすべて、スケールアップであれスケールダウンであれ、スケーリングに対するアイデアと考えを持っていなければならない。
Typically, it's not down, so it lets us be more agile and try to be more proactive in defending at machine speed.

通常、ダウンすることはないので、より機敏に、より積極的にマシンスピードで守備にあたることができる。
But hopefully, that gives you at least a basic breakdown of how to go and approach that.

しかし、これで少なくとも、どのようにアプローチして行けばいいのか、基本的な内訳はわかったと思う。
Thank you so much, Randy.

ありがとう、ランディ。
Thank you again to our wonderful speaker for answering those questions and for the great presentation and knowledge shared with our global audiences.

これらの質問に答え、素晴らしいプレゼンテーションと知識を世界中の聴衆と共有してくれた素晴らしいスピーカーに改めて感謝する。
It was a pleasure to have you with us, and we are looking for more and more sessions with you.

あなたとのセッションをもっともっと増やしたいと思っています。
Before we conclude the webinar, would you like to give a small message to our audiences?

ウェビナーを締めくくる前に、視聴者の皆さんに一言メッセージをお願いします。
Yes, and thank you, Shilpa.

ありがとう、シルパ。
I've enjoyed it.

楽しかったよ。
So, again, it's important to be pragmatic, plan where you can, understand you have to react often, and from vectors that we often don't know, sometimes we do.

だから、繰り返しになるが、現実的であること、可能な限り計画を立てること、頻繁に反応しなければならないことを理解することが重要だ。
So, and as a leader, it's very important that we work with our team, we regulate, and don't, as far as not burning our folks out, you know, we're trying to solve problems, and it's very important as a leader to work with your team and really set them up for success, empower them, and part of that comes from defining what they do and what they don't do.

だから、リーダーとして、チームと協力し、規制し、従業員をやきもきさせないようにすることがとても重要なんだ。
Thank you so much, Randy, for the message to our audiences.

ランディ、観客へのメッセージをありがとう。
Before we end the session, I would like to announce our next CyberTalk session, Incident Response Planning, Preparing for Network Security Bridges, which is scheduled for July 5, 2023.

セッションを終える前に、次回のCyberTalkセッション「インシデント・レスポンス・プランニング、ネットワーク・セキュリティ・ブリッジへの備え」を2023年7月5日に予定していることをお知らせします。
This session is an expert presentation by Mez D. Guzman, cybersecurity leader.

このセッションは、サイバーセキュリティのリーダーであるメズ・D・グスマン氏による専門的なプレゼンテーションである。
To register for the session, please do go visit our website, www.eccu.edu, CyberTalks.

セッションへのお申し込みは、ウェブサイトwww.eccu.edu、CyberTalksをご覧ください。
The link is given in the chat section.

リンクはチャットセクションに記載されている。
Hope to see you all on July 5th.

7月5日に皆さんにお会いできることを楽しみにしています。
With this, we end the session.

これでセッションを終える。
You may now disconnect your lines.

これで回線を切断することができる。
Thank you.

ありがとう。
Thank you so much, Randy.

ありがとう、ランディ。
Thank you.

ありがとう。
Pleasure having you.

君がいてくれて嬉しいよ。
Thank you.

ありがとう。