米国 2023年国土安全保障シンポジウム・エキスポにおけるレイFBI長官の発言

こんにちは、丸山満彦です。

2023.02.16にバージニア州のクリストファー・ニューポート大学で開催された「国土安全保障シンポジウム・エキスポ」でクリストファー・レイFBI長官が講演をしていますが、サイバー関連のテーマで話をしていますね。。。


● FBI

・2023.02.16 Director Wray's Remarks at the 2023 Homeland Security Symposium and Expo

Director Wray's Remarks at the 2023 Homeland Security Symposium and Expo	2023年国土安全保障シンポジウム・エキスポにおけるレイ長官の発言について
Introduction	序文
Thank you.	ありがとうございます。
If you take a look at the topics for the conference today, each panel discusses something the FBI is heavily involved in right now—cyber intrusions and ransomware attacks, risks posed by unmanned systems, domestic and international terrorism, and vulnerable supply chains that run through China and everywhere else. So, I appreciate the opportunity to kick off these discussions and share a little bit about how the FBI is working with critical partners like many of you in this room to combat these threats.	今日の会議のトピックをご覧いただくと、サイバー侵入やランサムウェア攻撃、無人システムがもたらすリスク、国内および国際テロ、中国やその他の地域を経由する脆弱なサプライチェーンなど、各パネルでFBIが現在深く関わっている事柄が取り上げられています。そこで、このような議論を始める機会をいただき、ここにお集まりの多くの皆様のような重要なパートナーとともに、FBI がどのようにこれらの脅威と闘っているかについて、少しお話しさせていただきます。
Cyberattacks and ransomware. Unmanned systems. Domestic and international terrorism. Supply chain vulnerabilities.	サイバー攻撃とランサムウェア。無人システム。国内および国際的なテロリズム サプライチェーンの脆弱性。
It’s hard not to get overwhelmed by the enormity of those topics and these threats. And, frankly, that’s a lot for one day.	これらのテーマと脅威の大きさに圧倒されるのは無理もありません。正直なところ、1日では足りないくらいです。
And, of course, I should add, those are just some of the threats we’re focused on at the FBI, where we’re also tackling the trafficking and exploitation of children, alarming levels of violent crime and hate crimes, the epidemic of deadly narcotics, and malign foreign influence aimed at undermining our government, just to name a few others.	もちろん、これらは私たちがFBIで重点的に取り組んでいる脅威の一部に過ぎません。他にも、子どもの人身売買や搾取、憂慮すべきレベルの暴力犯罪や憎悪犯罪、劇薬の蔓延、政府の弱体化を狙った外国の悪意ある影響など、いくつかの例を挙げればきりがありません。
As I like to say: A lot of people seem to have ideas about things they think the FBI should be doing more of, but I haven’t heard any responsible suggestions for things we could be doing less of.	私はこう言いたいのです。多くの人が、FBIはもっとやるべきことがある、と考えているようですが、私は、FBIはもっとやるべきことがあるのではないか、という責任ある提案を聞いたことがありません。
So, in order for the FBI to be at the forefront and stay ahead of all these threats, we rely on the partnerships we’ve developed with folks in the private sector—including many of you represented here today—and across all levels of government, both here at home and abroad.	FBIがこうした脅威の最前線に立ち、先手を打つためには、今日ここにお集まりの多くの方々を含む民間部門の人々、そして国内外のあらゆるレベルの政府機関との協力関係が欠かせません。
And the importance of those partnerships is really the core of the message I hope you’ll take away from my time with you here today.	このようなパートナーシップの重要性こそが、本日私が皆さんにお伝えしたいメッセージの核心です。
Cyber Threats	サイバーの脅威
So, what are we dealing with?	では、私たちは何に対処しているのでしょうか。
In cyberspace, the threats only seem to evolve, and the stakes have never been higher.	サイバースペースでは、脅威は進化する一方であり、そのリスクはかつてないほど高まっています。
One bad actor targeting a single supply chain can cause cascading effects across multiple sectors and communities.	1つのサプライチェーンを狙った悪質な行為によって、複数のセクターやコミュニティに連鎖的な影響が及ぶ可能性があります。
One unpatched vulnerability can mean the difference between business as usual and a scramble to get scores of systems back online.	パッチを適用していない脆弱性が1つでもあれば、通常通りのビジネスができるか、多数のシステムをオンラインに戻すために奔走しなければならないかの分かれ目になります。
And over the past few years, we’ve increasingly seen cybercriminals using ransomware against U.S. critical infrastructure sectors. In 2021, we saw ransomware incidents against 14 of the 16 U.S. critical infrastructure sectors.	また、ここ数年、サイバー犯罪者が米国の重要インフラ部門に対してランサムウェアを使用する事例が増加しています。2021年には、米国の重要インフラ16分野のうち14分野に対してランサムウェアのインシデントが発生しました。
In a perverse way, that makes sense, right?	裏を返せば、これは理にかなっていると言えますよね。
If you want someone to quickly pay a ransom, you threaten the very basic things they rely on for their day-to-day lives—something like an oil pipeline, an elementary school, or an electrical grid. Malicious actors assume—and, perhaps, rightly so—that if they attack these things we depend on every day, they can inflict more pain, and people will pay more quickly.	身代金をすぐに支払わせたいのであれば、石油パイプライン、小学校、電力網など、日常生活で頼りにしている基礎的なものを脅かすのです。悪意のある行為者は、私たちが日々依存しているこれらのものを攻撃すれば、より多くの苦痛を与えることができ、人々はより早く代金を支払うだろうと考えています。
And these actors have demonstrated there’s really no bar too low. They have no problem, for instance, threatening to shut down a children’s hospital to make a quick buck.	そして、悪意ある行為者たちは、ハードルが低すぎるということがないことを実証しています。 たとえば、手っ取り早く金を稼ぐために子どもの病院を閉鎖すると脅しても、何の問題もないのです。
Let me be clear: That’s not a hypothetical example.	これは仮定の話ではないので、誤解のないようにお願いします。
And while you would expect that cybercriminals are focused on operations for their own financial gain, really, any malicious cyber actor could also be trying to steal information or conduct influence operations, or laying the groundwork to disrupt our critical infrastructure. And those threats are not only proliferating, but becoming more complex.	サイバー犯罪者は金銭的な利益を得るための作戦に集中していると思われますが、実際には、悪意のあるサイバー行為者は、情報を盗んだり、影響力を行使したり、重要なインフラを破壊するための土台を築いたりすることも可能なのです。このような脅威は、急増するだけでなく、より複雑化しています。
There is no bright line where cybercriminal activity ends and hostile government activity begins, which both compounds and complicates the threat landscape.	サイバー犯罪者の活動がどこで終わり、政府の敵対的な活動がどこで始まるかという明確な線はなく、それが脅威の状況を複雑にしているのです。
We’re seeing blended threats where—for instance—the Iranian government has sponsored cybercriminals to perpetuate attacks to gather intelligence or gain access.	例えば、イラン政府がサイバー犯罪者のスポンサーとなり、情報収集やアクセス権を得るために攻撃を継続させているような脅威が混在しています。
In other instances, hostile governments have attempted to make their cyberattacks look like criminal activity, which caused whole operations to go sideways.	また、敵対する政府がサイバー攻撃を犯罪行為に見せかけようとし、その結果、作戦全体がうまくいかなくなるケースもあります。
That’s what we saw in 2017, when the Russian military used the NotPetya malware to hit Ukrainian critical infrastructure. The attack was supposed to look like a criminal heist, but was actually designed to destroy any systems it infected. They targeted Ukraine, but ended up also hitting systems throughout Europe, plus the U.S. and Australia, and even some systems within their own borders. They shut down a big chunk of global logistics, and, ultimately, their recklessness ended up causing more than $10 billion in damages—maybe the most damaging cyberattack in history.	2017年にロシア軍がマルウェア「NotPetya」を使ってウクライナの重要インフラを攻撃したのがそうでした。この攻撃は、犯罪的な強盗のように見えるはずでしたが、実際には、感染したシステムを破壊するように設計されていました。ウクライナをターゲットにした攻撃でしたが、最終的にはヨーロッパ全域、さらに米国とオーストラリアのシステム、そして自国内のシステムにも被害が及びました。世界の物流の大部分を停止させ、最終的に100億ドル以上の損害を与えました。これは、おそらく史上最も大きなサイバー攻撃です。
Add to that, cyber adversaries have also obtained an increasing capacity for stealth in recent years, facilitating more comprehensive access to U.S. networks. They’ve demonstrated the ability to maintain persistent access across various networks and environments by using seemingly legitimate credentials, accessing administrator accounts, and laterally traversing networks. They will park on a system quietly and then just wait for the right opportunity.	さらに、近年、サイバー敵対者はステルス能力を高め、米国のネットワークへのアクセスをより包括的なものにしました。彼らは、一見正当な認証情報を使用し、管理者アカウントにアクセスし、ネットワークを横断することで、様々なネットワークや環境に持続的にアクセスする能力を実証しています。彼らは、ひっそりとシステムに潜伏し、適切な機会を待つだけなのです。
So, to sum up the cyber threat picture: There’s a persistent, multi-vector, blended threat that’s constantly evolving and a continual challenge to assess, so we’re battling back against a constant barrage of attacks.	つまり、サイバー脅威の全体像をまとめると、次のようになります。このような脅威は常に進化しており、その評価も難しいため、私たちは常に攻撃の嵐に対抗しています。
China	中国
In this cyber threat landscape, China is the most dangerous actor to industry.	このようなサイバー脅威の状況において、産業界にとって最も危険な存在なのが中国です。
The Chinese government sees cyber as the pathway to cheat and steal on a massive scale, and more broadly, there’s simply no country that presents a broader or more severe threat to our ideas, innovation, and economic security than the Chinese government because they’ve shown themselves willing to lie, cheat, and steal to dominate major technology and economic sectors, crushing and putting companies from other nations out of business.	中国政府は、サイバーは大規模な不正行為や窃盗を行うための手段だと考えています。もっと広く言えば、中国政府ほど、私たちのアイデア、イノベーション、経済の安全保障に対して広範かつ深刻な脅威を与えている国はありません。なぜなら、彼らは主要技術や経済分野を支配し、他の国の企業を潰して廃業させるために嘘や不正行為、窃盗も辞さないことを示しているのです。
The Chinese government’s hacking program is bigger than that of every other major nation combined, and Chinese government hackers have stolen more of our personal and corporate data than all other countries—big and small—combined.	中国政府のハッキングプログラムは、他のすべての主要国のハッキングプログラムを合わせたよりも大規模であり、中国政府のハッカーは、大小の国を合わせたよりも多くの個人および企業データを盗んでいます。
But the threat from the PRC [People's Republic of China] government is particularly dangerous because they use that massive cyber effort in concert with every other tool in their government’s toolbox. What makes the Chinese government’s strategy so insidious is the way it exploits multiple avenues at once, and often in seemingly innocuous ways.	しかし、PRC（中華人民共和国）政府の脅威は特に危険です。なぜなら、彼らは大規模なサイバー活動を、政府の道具箱にある他のあらゆるツールと協調して使っているからです。中国政府の戦略が非常に陰湿なのは、複数の手段を同時に、しかも多くの場合、一見無害に見える方法で利用するからです。
They identify key technologies to target. Their “Made in China 2025” plan, for example, lists ten broad areas—spanning industries like robotics, green energy production and vehicles, aerospace, and biopharma.	中国政府は、ターゲットとなる重要な技術を特定します。例えば、「Made in China 2025」計画では、ロボット工学、グリーンエネルギー生産と自動車、航空宇宙、バイオ医薬品など、10の大分野を挙げています。
Then, they throw every tool in their arsenal at stealing the technology in those areas. And they are fine with causing indiscriminate damage to get to what they want, like in the Microsoft Exchange hack—the Hafnium attack—from 2021, which compromised the networks of more than 10,000 companies in just a single campaign.	そして、その分野の技術を盗むために、あらゆる手段を講じるのです。例えば、2021年に起きたMicrosoft Exchangeのハッキング（Hafnium攻撃）では、たった1回のキャンペーンで1万社以上のネットワークが危険にさらされましたが、彼らは欲しいものを手に入れるために無差別に損害を与えることも平気で行います。
At the same time, the Chinese government uses intelligence officers to target the same information.	同時に、中国政府は諜報部員を使って、同じ情報を狙っています。
And to knock down a few misconceptions about what it’s like to be targeted by Chinese intelligence, first of all, most Chinese spies aren’t just targeting people with government secrets. They’re after people with accesses to innovation, trade secrets, and intellectual property they feel would give them an advantage—economically or militarily.	そして、中国の情報機関に狙われるとはどういうことなのか、いくつかの誤解を打ち砕くために、まず第一に、ほとんどの中国のスパイは、政府の秘密を持つ人だけを狙っているわけではありません。経済的、軍事的に有利になると思われる技術革新、企業秘密、知的財産へのアクセス権を持つ人物を狙っているのです。
Second, many U.S. citizens who are compromised don’t realize they are working for the Chinese government. Chinese intelligence officers often use co-opted staff from Chinese universities or national businesses—effectively contract intelligence officers—to contact targets and develop what seems like a “collaborative” relationship, and the Chinese intelligence officer actually running the operation might never personally be in contact with the target.	第二に、情報漏洩した米国人の多くは、自分たちが中国政府のために働いていることに気づいていない。中国の諜報員はしばしば、中国の大学や国営企業の共同スタッフ（事実上の諜報員契約）を使ってターゲットと接触し、「協力」関係のようなものを構築しているのですが、実際に作戦を実行している中国の諜報員はターゲットと個人的に接触することはないかもしれません。
Third, and finally: With Chinese intelligence, the spy may not ever ask for information, but may, instead, just be looking for access to people and to networks, and that access may, in turn, be just enough to create a vulnerability for a cyber intrusion. So, their intelligence and cyber efforts are working hand-in-hand.	第三に、最後に。中国の諜報機関では、スパイは情報を求めず、単に人やネットワークへのアクセスを求め、そのアクセスがサイバー侵入のための脆弱性を作り出すのに十分な場合もあります。つまり、彼らの諜報活動とサイバー活動は密接に関係しているのです。
They also use elaborate shell games to disguise their efforts—both from our companies, and from our government investment screening program CFIUS, the Committee on Foreign Investment in the United States.	また、彼らは手の込んだ偽装工作を行い、私たちの企業からも、政府の投資審査プログラムであるCFIUS（Committee on Foreign Investment in the United States）からも、その努力を隠蔽しています。
And for non-Chinese companies operating in China, the Chinese government takes advantage of its laws and regulations to enable its stealing.	また、中国で活動する非中国企業に対しては、中国政府はその法律や規制を利用して窃盗を可能にします。
For example, in 2022, we learned that a number of U.S. companies operating in China had malware delivered into their networks through tax software the Chinese government required them to use. To put it plainly: By complying with Chinese laws, these companies unwittingly installed backdoors for Chinese state hackers. The overall result of PRC efforts like these is deep, job-destroying damage across a wide range of industries—and it’s damage that hits across the country, too, which is why we’re running 2,000 or so PRC-related counterintelligence investigations, out of every one of our 56 field offices.	例えば、2022年、中国で活動する多くの米国企業が、中国政府が使用を義務付けた税務ソフトウェアを通じて、マルウェアをネットワークに配信されていたことが分かりました。分かりやすく言えば 中国の法律に従うことで、これらの企業は知らず知らずのうちに、中国国家のハッカーのためのバックドアを設置していたのです。このようなPRCの取り組みの結果、幅広い産業分野で雇用を奪う深刻な被害が発生しており、その被害は国内にも及んでいます。そのため、私たちは56の支局すべてから、PRC関連の防諜調査を約2,000件実施しています。
Disrupting the Threat	脅威を断ち切る
In the cyber and espionage realm, just as in our other programs, our goal is disruption: getting ahead of and thwarting cyberattacks as early as possible, seizing infrastructure, and denying hackers the benefit of their crimes.	サイバーとスパイの分野でも、他のプログラムと同様、私たちの目標は破壊です。サイバー攻撃をできるだけ早く先回りして阻止し、インフラを押収し、ハッカーが犯罪の利益を得るのを阻止することです。
Just a few weeks ago, we announced the success we’ve had with the year-and-a-half-long disruption campaign against the Hive ransomware group, dismantling their infrastructure and taking it offline.	つい数週間前、私たちはランサムウェアグループ「Hive」に対する1年半に及ぶ破壊活動で、彼らのインフラを解体し、オフラインにすることに成功したことを発表したばかりです。
Since 2021, they’ve been one of the larger and more active ransomware groups we know of, targeting businesses and other victims in over 80 countries, and demanding hundreds of millions of dollars in ransom.	2021年以降、彼らは私たちが知る限り、より大規模で活発なランサムウェアグループの1つで、80カ国以上の企業やその他の被害者を標的にし、数億ドルの身代金を要求しています。
Last July, the FBI gained clandestine, persistent access to Hive’s control panel—essentially, hacking the hackers.	昨年7月、FBIはHiveのコントロールパネルに秘密裏に持続的にアクセスし、ハッカーをハッキングすることに成功しました。
From last July to this January, we repeatedly exploited that access to get Hive’s decryption keys and identify victims, and we offered those keys to more than 1,300 victims around the world so they could decrypt their infected networks—preventing at least $130 million in ransom payments—all without Hive catching on.	昨年7月から今年1月にかけて、このアクセス権を悪用してHiveの復号化キーを入手し、被害者を特定しました。そして、世界中の1300人以上の被害者にこのキーを提供し、感染したネットワークを復号化することで、少なくとも1億3000万ドルの身代金の支払いを防ぎましたが、すべてHiveに気づかれずにすんだのです。
The victims targeted by the Hive group reinforced what we know—that ransomware groups don’t discriminate. They went after big and small businesses.	Hiveが標的とした被害者たちは、ランサムウェアグループが差別をしないことを改めて認識させられました。彼らは大企業も中小企業もターゲットにしています。
We rushed an FBI case agent and computer scientist to one specialty medical clinic that was so small, the doctor there also managed the clinic’s IT security. We helped larger companies, and we also shared keys with victims overseas through our foreign-based legal attaché offices—like when we gave a foreign hospital a decryptor, which they used to get their systems back up before ransom negotiations even began, possibly saving lives.	私たちはFBIの捜査官とコンピュータサイエンティストを、ある専門医院に急行させました。その医院は非常に小規模で、医師が医院のITセキュリティも管理していました。例えば、海外の病院に暗号解読機を提供したところ、身代金交渉が始まる前にシステムを復旧させ、人命を救うことができたのです。
As we consider how best to focus our efforts at disrupting the hackers, we’re not only providing intelligence to current victims to help them quickly recover from an attack, but also on preventing attacks before they happen.	ハッカーを阻止するためにどのような取り組みを行うのが最善かを検討する中で、私たちは攻撃から迅速に回復するための情報を現在の被害者に提供するだけでなく、攻撃を未然に防ぐための取り組みも行っています。
So, for example, while on Hive’s systems, when we saw the initial stages of one attack against a university, we notified the school and gave their IT staff the technical information they needed to kick Hive off of their network before ransomware was deployed.	例えば、ハイブのシステムで、ある大学に対する攻撃の初期段階を確認したとき、学校に通知し、ITスタッフに必要な技術情報を提供し、ランサムウェアが展開される前にハイブをネットワークから追い出しました。
But our ability to help often hinges on victims—both private and public—reaching out to us when they are attacked.	しかし、私たちの支援は、民間企業や公的機関の被害者が攻撃を受けた際に、私たちに連絡をくれるかどうかにかかっていることが多いのです。
Unfortunately, during these past seven months, we found that only about 20% of Hive’s victims reported to law enforcement they had been attacked, which means we wouldn’t have been able to help 80% of their victims if we hadn’t managed to get into Hive’s infrastructure, seeing what was happening from the bad guys’ side. So, while an important success, the Hive disruption was somewhat unusual.	残念ながら、この7ヵ月間、Hiveの被害者のうち、警察当局に攻撃を受けたと報告したのはわずか20%でした。つまり、Hiveのインフラに侵入し、悪者側から何が起こっているかを確認できなければ、80%の被害者を助けることはできなかったのです。つまり、重要な成功ではありましたが、Hiveの妨害はやや異例だったのです。
We can’t count on that level of visibility into adversaries’ systems, so we’re counting on our relationships with the private sector to let us know about a problem in time to fix or mitigate it.	私たちは、敵のシステムをそこまで見通すことはできないので、問題を修正・緩和するのに間に合うように問題を知らせてくれる民間企業との関係を頼りにしています。
As part of those relationships, we share threat intelligence to help companies fortify their defenses, and we rely on organizations in the private and public sector to let us know when they’ve been attacked, because once we learn about an attack, we work with our partners to broadly share what we can with public and private industry partners and international security agencies to improve overall network defense and prevent attacks.	このような関係の一環として、私たちは企業の防御を強化するために脅威情報を共有しています。また、攻撃を受けた際には、民間および公共部門の組織から私たちに知らせてもらうようにしています。攻撃について知った後は、ネットワーク防御全体の改善と攻撃防止のために、パートナーと協力して、公共および民間業界のパートナーや国際セキュリティ機関とできることを幅広く共有しています。
Dissemination of attack information helps overcome typical silos that thwart recovery efforts, and in many instances, public and private sector partners provide us information in return that we can take back and use to help you with your recovery efforts.	攻撃情報の発信は、復旧作業を妨げる典型的なサイロを克服するのに役立ち、多くの場合、官民のパートナーは、私たちが持ち帰って復旧作業に役立てることができる情報を見返りに提供してくれます。
For example, in 2021, the Port of Houston was attacked by cybercriminals.  Because the Port reached out to us quickly, we were able to get technically trained agents out to the scene. There, they discovered a brand-new, zero-day exploit used to commit the attack—that is, a vulnerability and means of exploiting it that no one knew about yet. We immediately deployed our investigative tools to search for other victims where the same exploit was being deployed, and by the time the software provider developed a patch, we’d already enlisted our partners at CISA [the Cybersecurity and Infrastructure Security Agency] to work with us to help victims already being targeted, for whom that fix would otherwise have been too late. And, of course, the Port—and Houston—benefited greatly, too.	例えば、2021年、ヒューストン港がサイバー犯罪者の攻撃を受けました。  このとき、ヒューストン港はすぐに私たちに連絡し、技術的な訓練を受けたエージェントを現場に派遣することができました。そこで、攻撃に使われた全く新しいゼロデイ脆弱性、つまり、まだ誰も知らない脆弱性とその悪用方法を発見したのです。そして、ソフトウェア・プロバイダーがパッチを開発する頃には、すでにCISA（サイバーセキュリティ・インフラストラクチャ・セキュリティ局）のパートナーに協力を要請し、すでに標的とされていた被害者のために、手遅れになる前にパッチを提供するよう働きかけていました。そしてもちろん、港やヒューストンも大きな恩恵を受けました。
The FBI is determined to use all of our tools and resources to help victims, whether we’re talking about single individuals or whether they number in the thousands.	FBIは、被害者が一人であろうと数千人であろうと、あらゆる手段や資源を駆使して被害者を救済することを決意しています。
When the FBI determined the Chinese had executed the Hafnium attack to install backdoors into at least 10,000 U.S. and international partner networks and computers, we worked with a private sector partner to conduct the arduous task of identifying those victims using only IP addresses, including developing a custom tool for the task. We then employed advanced analytics to geolocate victims to specific field offices and legal attaché offices, and triaged over 1,700 victim notifications. And when some system owners weren’t able to remove the Chinese government’s backdoors themselves, we executed a first-of-its-kind, surgical, court-authorized operation, copying and removing the harmful code from hundreds of vulnerable computers—slamming those backdoors shut.	FBI は、中国が少なくとも 1 万台の米国および海外のパートナーのネットワークとコンピュータにバックドアをインストールするために Hafnium 攻撃を実行したと判断したとき、民間部門のパートナーと協力して、IP アドレスのみを使用してこれらの被害者を特定する困難な作業を行いました。そして、高度な分析を用いて被害者を特定の現地事務所や法務局に地理的に特定し、1,700件を超える被害者通知のトリアージにあたりました。さらに、中国政府のバックドアを自分で削除できないシステム所有者がいたため、裁判所が承認した初の外科手術を実施し、数百台の脆弱なコンピュータから有害なコードをコピーして削除し、バックドアを閉鎖しました。
That example illustrates how today’s FBI views success: disruption of our adversaries by leveraging our capabilities, tools, and resources to get ahead of and thwart cyber attacks as early as possible.	この例は、今日の FBI が成功をどのように捉えているかを示しています。つまり、私たちの能力、ツール、リソースを活用してサイバー攻撃に先手を打ち、できるだけ早く阻止することにより、敵対者を混乱させるということです。
As these examples demonstrate, a lot of good can come from mutual trust and working together—from strong partnership. And strong public and private sector partners not only help us at the FBI get ahead of the threat and aid in recovery, but they also help us leverage our traditional law enforcement authorities to further our disruption goals—not just arresting and extraditing more hackers, but dismantling their infrastructure and seizing their funds. Through seizures, we can also help a company recover funds that would otherwise be lost.	これらの例が示すように、相互の信頼と協力、つまり強力なパートナーシップから、多くの良いことが生まれます。官民の強力なパートナーは、私たち FBI が脅威を先取りして復旧を支援するだけでなく、従来の法執行機関の権限を活用して、より多くのハッカーを逮捕して送還するだけでなく、彼らのインフラを解体して資金を押収するなど、破壊工作の目標を達成するのにも役立っています。ハッカーの逮捕や引き渡しだけでなく、インフラを破壊し、資金を押収することができます。押収によって、企業が失われるはずの資金を回収することもできます。
For instance, from January through November 2022, our Internet Crime Complaint Center’s Recovery Asset Team used the Financial Fraud Kill Chain over two thousand times, successfully freezing more than $328 million—a 74% success rate—that could then be returned to individuals and businesses who had been defrauded.	例えば、2022年1月から11月にかけて、インターネット犯罪相談センターのリカバリー・アセット・チームは、金融詐欺のキル・チェーンを2000回以上使用し、3億2800万ドル以上の凍結に成功しました（成功率74％）。
Greed is a primary motivator of the cyber threat, and by hitting cyber actors where it hurts—their wallets—we can disincentivize more attacks before they occur.	サイバー脅威の主な動機は貪欲さですが、サイバー犯罪者の財布という痛いところを突くことで、攻撃が起こる前にその意欲をそぐことができるのです。
A few weeks ago, we announced the arrest of a Russian national who administered the Bitzlato Limited cryptocurrency exchange, which laundered over $15 million in ransomware proceeds and over $700 million in darknet illicit transactions. At the same time, we worked with our international law enforcement partners to seize Bitzlato’s servers and execute additional arrests. Cryptocurrency exchanges like Bitzlato are a vital part of the infrastructure cybercriminals use to launder the funds extorted from their victims. In thinking about how we, at the FBI, can have the most durable disruptive impact, our goal is not only to take away the motivation for ransomware attacks, but also to deprive ransomware groups of the resources they need to successfully conduct these attacks.	数週間前、私たちはBitzlato Limitedという暗号通貨取引所を管理していたロシア人を逮捕したと発表しました。この取引所では、1500万ドル以上のランサムウェアの収益と7億ドル以上のダークネット不正取引が洗浄されていました。同時に、当社は国際的な法執行機関のパートナーと協力して、Bitzlatoのサーバーを押収し、追加の逮捕を実行しました。Bitzlatoのような暗号通貨取引所は、サイバー犯罪者が被害者から強奪した資金を洗浄するために使用するインフラの重要な部分です。私たちFBIが最も持続的な破壊的インパクトを与える方法を考える上で、私たちの目標は、ランサムウェア攻撃の動機を奪うだけでなく、ランサムウェアグループがこれらの攻撃を成功させるために必要なリソースを奪うことでもあります。
Conclusion and Partnerships	まとめとパートナーシップ
Bottom line: We believe in using every tool we’ve got to protect American innovation and critical infrastructure, but, as I said before, that’s not something the FBI can do alone.	結論です。私たちは、アメリカのイノベーションと重要なインフラを守るために、あらゆる手段を講じることを信条としています。
That’s a big reason conferences like this—focused on building a dialogue between the public and private sector on current and emerging threats—are so important to the Bureau. They build the partnerships necessary for us to understand and stay ahead of the threat.	このような会議が FBI にとって非常に重要なのは、現在および将来の脅威について官民の対話を促進することに重点を置いているためです。このような会議は、私たちが脅威を理解し、その先を行くために必要なパートナーシップを構築するものです。
So, again, thank you for inviting me to kickstart the discussions today. Now, let’s turn this into a conversation.	本日のディスカッションを始めるにあたり、お招きいただきありがとうございました。 では、この議論を会話に発展させていきましょう。

欧州 ENISA 協調的な脆弱性情報開示：EU共通のアプローチ

こんにちは、丸山満彦です。

2023年1月16日に採択された「EU全域で共通レベルの高いサイバーセキュリティのための措置に関する新指令（NIS2）」により、加盟国は2024年10月17日までに協調的脆弱性開示政策を採択・公表する必要があります。。。さらに、現在審議中のサイバーレジリエンス法（CRA）案において脆弱性の取り扱い要件が含まれていますね。。。

と言うことで、ENISAは協調的な脆弱性情報開示についてのガイドを公表しています。。。

日本はそう言う意味では早く（2004.07.08）から、脆弱性情報を開示するためのプロセスである「情報セキュリティ早期警戒パートナーシップ」を運営しているわけで先進的な取り組みをしていましたね。。。今回のEUでの取り組みにも、この実績は参考にされたようです。。。

● ENISA

・2023.02.16 Coordinated Vulnerability Disclosure: Towards a Common EU Approach

Coordinated Vulnerability Disclosure: Towards a Common EU Approach	協調的な脆弱性情報開示：EU共通のアプローチに向けて
The new report of the European Union Agency for Cybersecurity (ENISA) explores how to develop harmonised national vulnerability programmes and initiatives in the EU.	欧州連合サイバーセキュリティ機関（ENISA）の新しい報告書は、EUにおいて調和された各国の脆弱性プログラムおよびイニシアチブを開発する方法を探っている。
With the new Directive on measures for a high common level of cybersecurity across the Union (NIS2) adopted on 16 January 2023, Member States will need to have a coordinated vulnerability disclosure policy adopted and published by 17 October 2024. In addition, other ongoing legislative developments will also address vulnerability disclosure, with vulnerability handling requirements already foreseen in the proposed Cyber Resilience Act (CRA).	2023年1月16日に採択された「EU全域で共通レベルの高いサイバーセキュリティのための措置に関する新指令（NIS2）」により、加盟国は2024年10月17日までに協調的脆弱性開示政策を採択・公表する必要がある。さらに、現在進行中の他の法整備も脆弱性開示に対応するものであり、提案されているサイバー・レジリエンス法（CRA）において脆弱性の取り扱い要件がすでに予見されている。
The new report published today looks into the expectations of both industry and the Member States in relation to the NIS2’s objective. It also analyses the related legal, collaborative, technical challenges arising from such initiatives.	本日発表された新しい報告書では、NIS2の目的に関連して、産業界と加盟国の両方がどのような期待を抱いているかを調べている。また、このような取り組みから生じる、関連する法的、協調的、技術的な課題についても分析している。
Apart from insights on industry expectations, the findings feed into the guidelines ENISA and the NIS Cooperation Group intend to prepare to help EU Member States establish their national Coordinated Vulnerability Disclosure (CVD) policies. These guidelines would be focused on vulnerability management, dedicated processes and related responsibilities.	産業界の期待に関する洞察とは別に、この調査結果は、ENISAとNIS協力グループが、EU加盟国が国別の協調的脆弱性開示（CVD）政策を確立するのを支援するために作成しようとしているガイドラインに反映される。このガイドラインは、脆弱性管理、専用プロセス、および関連する責任に焦点を当てたものとなるだろう。
With this research, ENISA seeks to find out how a harmonised approach across the EU can be achieved. The different options envisaged to do so will be discussed within the task force driving the project and consisting of ENISA together with the NIS cooperation group.	この研究により、ENISAは、EU全域で調和されたアプローチをどのように実現できるかを見出そうとしている。そのために想定されるさまざまな選択肢は、ENISAとNISの協力グループからなる、このプロジェクトを推進するタスクフォースで議論される予定である。
Peeking into the report:	報告書を覗く：
Examples of what industry expects:	産業界が期待例：
a national or European CVD policy may encourage organisations to set vulnerability management and security practices as a priority;	国または欧州のCVD政策は、組織が脆弱性管理とセキュリティの実践を優先するよう促すかもしれない。
policy makers should consider the existing initiatives and standards around CVD;	政策立案者は、CVDに関する既存の取り組みや標準を考慮する必要がある。
global cooperation across different legislations as well as cooperation between industry players and the public sector needs to be strengthened to avoid silos.	異なる法律間のグローバルな協力、および業界関係者と公共部門の協力関係を強化し、サイロ化を回避する必要がある。
Challenges for Security Researchers	セキュリティ研究者の課題
The report also highlights the incentives and obstacles addressed to security researchers to legally report vulnerabilities. Reputational interests are a key driver for researchers whose public proof of vulnerability discovery and disclosure adds to their professional credibility and thus ensures the legitimacy and reliability of their work. On the other hand, a vague or absent CVD framework may lead to legal uncertainty, and this hinder or even prevent the reporting of vulnerabilities.	この報告書では、セキュリティ研究者が脆弱性を合法的に報告するための誘因や障害も取り上げている。研究者にとって、脆弱性の発見と公開を公に証明することは、専門家としての信頼性を高め、その研究の正当性と信頼性を保証する重要な推進力となっている。一方、CVDの枠組みが曖昧であったり、存在しなかったりすると、法的な不確実性が生じ、脆弱性の報告が妨げられたり、阻止されたりする可能性がある。
Background	背景
The report builds upon previous work performed by ENISA in the field of vulnerabilities. ENISA issued a report on good practices on vulnerability disclosure in the EU in April 2022. In addition, the limitations and opportunities of the vulnerability ecosystem were analysed in the ENISA 2019 State of Vulnerabilities report.	本報告書は、脆弱性の分野でENISAが実施した過去の作業を基に作成されている。ENISAは、2022年4月にEUにおける脆弱性開示に関するグッドプラクティスに関する報告書を発行した。さらに、脆弱性エコシステムの限界と機会については、ENISA 2019 State of Vulnerabilitiesレポートで分析した。
Further information	さらに詳しい情報
Developing National Vulnerability Programmes and Initiatives – ENISA report 2023	国家脆弱性プログラムおよびイニシアチブの開発 - ENISAレポート2023
Vulnerability Disclosure in the EU – An overview of National Vulnerability Disclosure Policies in the EU – ENISA report 2022	EUにおける脆弱性開示 - EUにおける各国の脆弱性開示政策の概要 - ENISAレポート2022年版
State of Vulnerabilities 2018/2019 - Analysis of Events in the life of Vulnerabilities	脆弱性の状態 2018/2019 - 脆弱性の生涯における事象の分析
Economics of Vulnerability Disclosure	脆弱性開示の経済学
Good Practice Guide on Vulnerability Disclosure. From challenges to recommendations	脆弱性開示に関するグッドプラクティスガイド。課題から提言へ
Directive on measures for a high common level of cybersecurity across the Union (NIS2)	欧州連合全体におけるサイバーセキュリティの高い共通レベルのための措置に関する指令（NIS2)
Cyber Resilience Act (CRA)	サイバーレジリエンス法(CRA)

・2023.02.16 Developing National Vulnerabilities Programmes

Developing National Vulnerabilities Programmes

国家脆弱性プログラムの開発

Based on the experiences and perspectives gathered from industry players and national governments, as well as on the documentation developed by multiple actors involved with national vulnerability initiatives and programmes, the EU Coordinated Vulnerability Disclosure (CVD) ecosystem remains fragmented. Although interesting approaches and initiatives are taking place in some EU Member States, yet further steps can be done towards an integrated EU vision and action.

業界関係者や各国政府から集められた経験や見解、また各国の脆弱性イニシアティブやプログラムに関わる複数の関係者によって作成された文書によると、EUの協調的脆弱性開示（CVD）エコシステムは依然として断片的なままであることがわかります。いくつかのEU加盟国では、興味深いアプローチや取り組みが行われているが、EUの統合的なビジョンと行動に向けて、さらなるステップを踏むことが可能である。

・[PDF]

・[DOCX] 仮訳

目次...

1 INTRODUCTION	1 序論
1.1 CONTEXT AND OBJECTIVES	1.1 背景と目的
1.2 TARGET AUDIENCE	1.2 対象読者
1.3 REPORT STRUCTURE	1.3 報告書の構成
1.4 METHODOLOGICAL APPROACH	1.4 方法論的アプローチ
2 NATIONAL CVD POLICY IMPLEMENTATION – THE INDUSTRY  PERSPECTIVE	2 国家のCVD政策の実施 - 産業界の視点
2.1 CONTEXT	2.1 前提条件
2.2 ASSESSMENT OF NATIONAL POLICIES	2.2 国家政策の評価
2.3 GOOD PRACTICES WHEN DEVELOPING AND IMPLEMENTING A NATIONAL COORDINATED  VULNERABILITY DISCLOSURE POLICY	2.3 国家的な協調による脆弱性開示政策を策定し、実施する際のグッドプラクティス
2.4 CHALLENGES FACED WHEN DEVELOPING AND IMPLEMENTING A NATIONAL COORDINATED  VULNERABILITY DISCLOSURE POLICY	2.4 国家レベルで調整された脆弱性開示政策を策定し、実施する際に直面する課題
3 ADDRESSING LEGAL CHALLENGES FOR SECURITY  RESEARCHERS	3 セキュリティ研究者のための法的課題への対応
3.1 CONTEXT	3.1 文脈
3.2 INCENTIVES FOR SECURITY RESEARCHERS TO LEGALLY REPORT VULNERABILITIES	3.2 セキュリティ研究者が合法的に脆弱性を報告するための誘因
3.3 DISINCENTIVES PREVENTING LEGAL REPORTING OF VULNERABILITIES	3.3 脆弱性の合法的な報告を妨げている阻害要因
3.4 INITIATIVES ADDRESSING THE LACK OF LEGAL PROTECTIONS	3.4 法的保護の欠如に対処するための取り組み
4 ADDRESSING COLLABORATIVE CHALLENGES: THE USE OF  OPEN-SOURCE SOFTWARE AND BUG-BOUNTY PROGRAMS	4 共同の課題への取り組み。オープンソースソフトウェアとバグバウンティプログラムの利用
4.1 OPEN-SOURCE SOFTWARE – OSS	4.1 オープンソースソフトウェア - OSS
4.1.1 Context	4.1.1 コンテクスト
4.1.2 Vulnerabilities’ impact, management and treatment within OSS	4.1.2 OSS における脆弱性の影響、管理、処置
4.1.3 Usage of ‘software bill of materials’ within the context of OSS	4.1.3 OSS の文脈における「ソフトウェア部品表」の使用法
4.1.4 Governance under the perspective of OSS	4.1.4 OSS の観点からのガバナンス
4.1.5 Instances of OSS vulnerabilities within public and private organisations	4.1.5 公共・民間組織における OSS 脆弱性の事例
4.2 CONSIDERATIONS ON OUTSOURCING SECURITY VIA BUG BOUNTY PROGRAMMES	4.2 バグバウンティプログラムによるセキュリティのアウトソーシングに関する考察
4.2.1 Context	4.2.1 コンテクスト
4.2.2 Structure of bug bounty programmes	4.2.2 バグバウンティプログラムの構造
4.2.3 Security-by-design	4.2.3 デザインによるセキュリティ
4.2.4 Bug bounty programmes in public administrations	4.2.4 行政機関におけるバグバウンティプログラム
4.2.5 Bug bounty programmes challenges	4.2.5 バグバウンティプログラムの課題
4.2.6 Evolution of bug bounty programmes	4.2.6 バグ報奨金制度の進化
5 ADDRESSING TECHNICAL CHALLENGES: AUTOMATION INITIATIVES SUPPORTING PRIORITISATION AND TREATMENT OF VULNERABILITIES	5 技術的課題への対応 脆弱性の優先順位付けと対処を支援する自動化の取り組み
5.1 CONTEXT	5.1 背景
5.2 AUTOMATED PROCESSES WITHIN VULNERABILITY MANAGEMENT	5.2 脆弱性管理におけるプロセスの自動化
5.3 COORDINATED VULNERABILITY DISCLOSURE TOOLS FOSTERING THE USAGE OF  AUTOMATED WORKFLOWS WITHIN VULNERABILITY PRIORITISATION AND TREATMENT	5.3 脆弱性の優先順位付けと治療における自動化ワークフローの使用を促進する協調的な脆弱性開示ツール
6 CONCLUSIONS	6 結論
7 REFERENCES	7 参考文献

・エグゼクティブサマリー

EXECUTIVE SUMMARY	エグゼクティブサマリー
Based on the experiences and perspectives gathered from industry players and national governments, as well as on the documentation developed by multiple actors involved with national vulnerability initiatives and programmes, the EU Coordinated Vulnerability Disclosure (CVD) ecosystem remains fragmented. Although interesting approaches and initiatives are taking place in some EU Member States, yet further steps can be done towards an integrated EU vision and action.	業界関係者や各国政府から集めた経験や見解、また、各国の脆弱性イニシアティブやプログラムに関わる複数の関係者が作成した文書によると、EUの協調的脆弱性開示（CVD）エコシステムは、依然として断片的なままであることがわかります。いくつかのEU加盟国では、興味深いアプローチや取り組みが行われているが、EUの統合的なビジョンと行動に向けて、さらなるステップを踏むことが可能である。
This report shows that, despite recent efforts by national governments in developing CVD policies, some industry players have taken the lead and developed vulnerability policies and programmes at organisation level. Nevertheless, among the top industry expectations is that the development of a national or European level CVD policy could help organisations and public administrations to set vulnerability management as a priority and further encourage security practices. In addition, the alignment of such policies with existing international standards, can greatly help in promoting harmonization.	本報告書では、CVD政策の策定における各国政府の最近の努力にもかかわらず、一部の業界プレーヤーが率先して脆弱性政策や組織レベルのプログラムを策定していることが示されている。とはいえ、業界が最も期待しているのは、国または欧州レベルのCVD政策を策定することで、組織や行政が脆弱性管理を優先課題に設定し、セキュリティ対策をさらに奨励できるようになることである。さらに、このようなポリシーを既存の国際標準と整合させることは、ハーモナイゼーションの推進に大いに役立ちます。
As far as vulnerability initiatives are concerned, Bug Bounties Programmes (BBP) is an area that grew remarkably over the past few years. BBPs have considerably adapted their business models in offering different type of services, hence different coverages of IT systems and levels of involvement in vulnerability management processes. Today, BBPs platform providers are now cooperating with key public institutions to run customised programmes adapted to their needs and IT infrastructures. Further expansion is expected as long as the community can continue relying on BBPs (i.e., confidentiality of internal information and data protection) and ensuring trust between the stakeholders involved.	脆弱性対策に関する限り、バグバウンティプログラム（BBP）は、過去数年間に著しく成長した分野である。BBPは、さまざまなタイプのサービスを提供することで、そのビジネスモデルを大幅に適応させ、その結果、ITシステムの対象範囲や脆弱性管理プロセスへの関与の度合いも異なっている。現在、BBPのプラットフォームプロバイダーは、主要な公共機関と協力し、そのニーズとITインフラに適合したカスタマイズされたプログラムを運営している。コミュニティがBBPへの信頼（内部情報の機密性、データ保護）を継続でき、関係者間の信頼が確保できる限り、さらなる拡大が期待される。
In terms of human capital, researchers play a fundamental role in the disclosure of vulnerabilities. Accordingly, it is interesting to understand motivations, incentives and challenges influencing researchers’ contribution. From their perspective, reputation remains as a one of the key incentives to legally report vulnerabilities, as it leads to fame and recognition. However, legal protection is also highly considered, especially because the absence, uncertainty or non-clarity of legal conditions can push to illegal channels.	人的資本の面では、研究者が脆弱性公開の根幹を担っている。したがって、研究者の貢献に影響を与える動機、インセンティブ、課題を理解することは興味深い。研究者の観点からは、名声や認知につながるため、評判は脆弱性を合法的に報告する重要なインセンティブの一つであることに変わりはありません。しかし、特に法的条件の不在、不確実性、非明確性が違法な手段を後押しする可能性があるため、法的保護も非常に重要視されている。
Collaborative challenges arise in the use of tools to improve vulnerability disclosure processes. For example, when looking into vulnerabilities related to open-source software (OSS) and considering how intertwined commercial and OSS are today, a need to further improve coordination between OSS developers and private vendors was identified. Aspects such as OSS vulnerability handling, responsibility and accountability are not yet clearly defined and among actors involved across the IT product supply chains, which may hinder coordination efforts.	脆弱性の開示プロセスを改善するためのツールの使用において、共同的な課題が発生します。例えば、オープンソースソフトウェア（OSS）に関する脆弱性を調査し、今日、商用とOSSがいかに絡み合っているかを考慮すると、OSS開発者と民間ベンダーとの間の連携をさらに改善する必要性があることが明らかになりました。OSSの脆弱性対応、責任、アカウンタビリティなどの側面は、IT製品のサプライチェーンを超えて関係者間でまだ明確に定義されておらず、調整の努力を阻害する可能性がある。
Challenges related to technical and technological issues also constitute a key area of discussion and analysis. A forward-looking perspective on the use of automation as an enabler to efficiently manage vulnerability identification, sourcing and classification is also provided by this report. It is observed that, as vulnerability analysis and treatment still require human expertise, the risk of deskilling experts due to automated processes may be minimised.	また、技術的・技能的な課題も重要な議論・分析対象である。本報告書では、脆弱性の特定、調達、分類を効率的に管理するための実現手段としての自動化の利用について、将来を見据えた視点も提供されている。脆弱性の分析と治療には依然として人間の専門知識が必要であるため、自動化されたプロセスによって専門家が不足するリスクは最小化される可能性があることが確認されている。
Finally, alignment across different legislation as well as cooperation between industry players and governments are needed to avoid silos. Harmonisation of CVD practices, coordination and international cooperation among players are essential priorities both from a legal and technical perspectives. In this regard, ENISA will continue offering advice, publishing guidelines, promoting information sharing, raising awareness, and coordinating CVD-related activities at national and EU level.	最後に、縦割り行政を避けるためには、異なる法律間の調整と、業界関係者と政府間の協力が必要である。CVD実務の調和、関係者間の調整と国際協力は、法律と技術の両面から不可欠な優先事項である。この点に関して、ENISAは引き続き助言を提供し、ガイドラインを発行し、情報共有を促進し、意識を高め、国およびEUレベルでのCVD関連活動の調整を図っていく予定である。

ソフトウェアサプライチェーンリスクの軽減策について...

こんにちは、丸山満彦です。

ソフトウェアサプライチェーンに関連するサイバーインシデントは2021年ごろに、SolarWinds社、Codecov、Kaseya社、Log4j など続いたわけですが、リスク管理的にいうと、発生可能性が低い（全ソフトの中で、問題となるソフトが含まれている可能性が低いと言う意味で）が、発生した場合の影響が非常に大きくなる場合があり、かつ現在の状況で言うと、対策コストがかかりそうと言うことで、悩ましい問題となっていますね。。。また、自然災害と異なり、潜伏していて被害に気づかない状況が長期間続く場合もあると言うことですね。。。そして、この問題が、国家安全保障を含む、国民の生活、生命、経済に大きく影響する場合もあると言うことですね。。。で、DXが進むとさらに、国民への影響が大きくなっていく...

米国では、事件を受けて大統領令 (EO) 14028を出して、ソフトウェア成分表・部品表 (SBOM) と言う解決策を推進しつつあり、日本もSBOMの導入に向けての検討をしているわけですが、なかなかに難しい問題があると言うのは聞いています。。。

かといって、重大な脆弱性が発見されるごとに、すべてのソフトウェアをスキャンすると言うわけにもいかないようにも思いますしね。。。

なんか、重要な脆弱性を見落とさない、かつ、対策が容易な方法があれば良いのですけどね。。。

永遠の2000年問題的な感じがします。。。

最近RANDに掲載されていた(元は、The Hillに掲載)、Sasha Romanoskyさんの記事が簡単にまとまっていてわかりやすかったですかね。。。

● RAND

・2023.01.26 Software Supply Chain Risk Is Growing, but Mitigation Solutions Exist COMMENTARY (The Hill)

どんなことが書いているかというと...

社会全体としてソフトウェアの脆弱性管理が難しい理由

1. オープンソースのパッケージやライブラリの数が非常に多い (GitHubには2億以上のソフトウェアがポストされている。JavascriptとPythonは2019年当時でも合わせて100万以上のパッケージをサポートしている）
   
   
2. 組織はどのようなソフトが使われているかほとんど知らない
   
   
3. リスク分析のツールがない（大統領令の影響もあってSBOMが普及しつつあるが、どの階層まで詳細に記載すべきか。コストがかかりそうな割に、どれほど有益なのか見極めがついていない）

と言うことを挙げているように感じました。。。

で、リスク軽減を支援する手法の一つとして、

• Libraries.ioやdeps.devの活動を紹介しています。。。ソフトウェア開発者であれば知っていると思いますが。。。
  

deps.dev

また、

SBOM の作成と使用が進めば、ユーザは自分でアプリケーション間でSBOM を比較し、

• 最も危険なコンポーネントを特定することに熟達するかもしれない。。。

で、それをサポートしそうな活動として、FIRSTの活動を紹介しています。

● FIRST

・Common Vulnerability Scoring System SIG

・Exploit Prediction Scoring System (EPSS)

二人いる共同チェアの一人がこの記事の著者のSasha Romanoskyさん...

・・What is EPSS?

2021年5月16日のデータを基にした、EPSSとCVSSのスコアの相関関係から対策の優先順位を考える上では有益？

実際のエクスプロイトデータの検証...

ある脆弱性のサンプルについて、実際に観測されたエクスプロイトを示したもの

・各行は個別の脆弱性（CVE）

・青線は観測されたエクスプロイト（エクスプロイトが成功したかどうかは確認していない ）

・赤点は、CVEが公開された時刻

効率的、効果的な対策を考えないとですね。。。

---

● まるちゃんの情報セキュリティ気まぐれ日記

大統領令

・2021.05.13 米国 国家のサイバーセキュリティ向上に関する大統領令

ソフトウェア資産の管理...

・2022.10.06 米国 CISA 拘束的運用指令23-01 - 連邦ネットワークにおける資産の可視化と脆弱性検出の改善

一部SBOMについて言及した報告（サイバーセキュリティ法制度の国際動向等に関する調査 報告書 ）があります...

・2022.07.16 経済産業省 令和３年度委託調査報告書（サイバーセキュリティ関係） 2022.07.14現在

脆弱性の評価

・2022.11.17 CISA ステークホルダー別脆弱性分類 (SSVC) ガイド

・2022.06.11 NIST NISTIR 8409 (ドラフト) 共通脆弱性評点システムの基礎評点の計算式の測定

・2021.04.30 カーネギー大学 ソフトウェア工学研究所が「Stakeholder-Specific Vulnerability Categorization:SSVC 2.0」を発表していますね。。。

昔に遡り。。。

・2010.10.25 IPA 共通脆弱性評価システムCVSS概説

・2007.04.26 JVN は、名称をJP Vendor Status Notes (JVN) から、Japan Vulnerability Notes (JVN) と変更しました

サプライチェーン関係 (SP800-161, DevSecOpsなど）

・2022.11.12 NIST ホワイトペーパー【プロジェクト概要】ソフトウェアサプライチェーンとDevOpsのセキュリティ実践：リスクベースアプローチによるDevSecOpsの実践

・2022.07.26 NIST White Paper (Draft) [プロジェクト概要] ソフトウェアサプライチェーンとDevOpsセキュリティの実践：リスクベースアプローチによるDevSecOpsの実践

・2022.05.08 NIST SP 800-161 Rev. 1 システムと組織のためのサイバーセキュリティ・サプライチェーン・リスクマネジメントの実践

・2022.02.06 NIST ホワイトペーパー： 大統領令14028条第4e項に基づくソフトウェア・サプライチェーン・セキュリティ・ガイダンス

・2021.12.13 Apache Log4j 2 の脆弱性 (CVE-2021-44228)＋ ソフトウェアの管理 + 脆弱性情報の管理

・2021.10.30 NIST SP 800-161 Rev. 1 (Draft) システムと組織のためのサイバーセキュリティ・サプライチェーン・リスクマネジメントの実践（第2次ドラフト）

・2021.06.27 NIST ソフトウェアサプライチェーンにおける「クリティカル・ソフトウェア」の定義：大統領令14028に応えて...

・2021.06.02 米国 国家のサイバーセキュリティ向上に関する大統領令 (EO 14028) に基づくソフトウェアサプライチェーン管理に関係して。。。

・2021.05.01 NIST SP 800-161 Rev. 1 (ドラフト) システムと組織のためのサイバー・サプライチェーン・リスク管理の実践

・2020.03.01 NISTに基づくSupply Chain Risk Managementについてのちょっとしたまとめ

・2020.02.05 NISTがサプライチェーンセキュリティの実践資料のドラフトを公開していますね。。。

SP800-218 セキュアソフトウェア開発関係

・2022.02.06 NIST SP 800-218 セキュアソフトウェア開発フレームワーク (SSDF) Version 1.1: ソフトウェアの脆弱性のリスクを軽減するための推奨事項

・2021.10.02 NIST SP 800-218 （ドラフト）セキュアソフトウェア開発フレームワーク (SSDF) Version 1.1: ソフトウェアの脆弱性のリスクを軽減するための推奨事項

読みました！ 「CISOのための情報セキュリティ戦略 - 危機から逆算して攻略せよ」

こんにちは、丸山満彦です。

プリファードネットワークのCISO, CPOを務める高橋正和さんの著書、「CISOのための情報セキュリティ戦略 - 危機から逆算して攻略せよ」[amazon] を読み終えました。。。

本書がどんな本かは、前書きから、、、

---

セキュリティ事件・事故のシナリオに基づいた机上演習フレームワークをCISO-PRACTSIEと呼称し、経営者がセキュリティの文脈を理解し、CISOを始めとしたセキュリティ担当者が、経営視点や事業視点を身につける機会として事件・事故を想定し、そこから逆算して対策の検証を行う手法を提案します。

---

詳細に、丁寧に書かれていますね。。。

参考になるところが、あちこちにあると思います。是非是非。。。

ところで、この机上演習ですが、、、以下の資料を参考にしていますね。。。

● JPCERT/CC

・2016.03.31 [PDF] 高度サイバー攻撃(APT)への備えと対応ガイド～企業や組織に薦める一連のプロセスについて

図 18：様々な演習と効果

ただ、このJPCERT/CCのガイドの図はどこからきたのですかね。。。

この辺り（国家安全保障省のHomeland Security Exercise and Evaluation Program）からですかね。。。これ自体は2020年のものですが、2013年発行の前のバージョンがあったのです。。。

● Homeland Security Agency

・Homeland Security Exercise and Evaluation Program (HSEEP)

Homeland Security Exercise and Evaluation Program	国土安全保障演習と評価プログラム
Exercises are a key component of national preparedness — they provide the whole community with the opportunity to shape planning, assess and validate capabilities, and address areas for improvement. HSEEP provides a set of guiding principles for exercise and evaluation programs, as well as a common approach to exercise program management, design and development, conduct, evaluation, and improvement planning.	演習は国家的な準備態勢の重要な要素であり、地域社会全体に計画を形成し、能力を評価・検証し、改善すべき分野に対処する機会を提供するものである。 HSEEPは、演習と評価プログラムのための一連の指導原則と、演習プログラムの管理、設計と開発、実施、評価、および改善計画に対する共通のアプローチを提供する。
Through the use of HSEEP, the whole community can develop, execute, and evaluate exercises that address the preparedness priorities. These priorities are informed by risk and capability assessments, findings, corrective actions from previous events, and external requirements.  These priorities guide the overall direction of an exercise program and the design and development of individual exercises.	HSEEPの利用により、地域社会全体が準備の優先順位に対応した演習を開発、実施、評価することができる。 これらの優先事項は、リスクと能力の評価、所見、過去の事象からの是正措置、および外部要件によってもたらされる。  これらの優先順位は、演習プログラムの全体的な方向性と個々の演習の設計と開発の指針となる。
These priorities guide planners as they identify exercise objectives and align them to capabilities for evaluation during the exercise. Exercise evaluation assesses the ability to meet exercise objectives and capabilities by documenting strengths, areas for improvement, capability performance, and corrective actions in an After-Action Report/Improvement Plan (AAR/IP). Through improvement planning, organizations take the corrective actions needed to improve plans, build and sustain capabilities, and maintain readiness.	これらの優先順位は、計画者が演習の目的を特定し、演習中に評価するための能力と整合させる際の指針となる。演習の評価では、演習の目的および能力を満たすために、強み、改善すべき点、能力のパフォーマンス、および是正措置を事後報告/改善計画（AAR/IP）に文書化することによって評価する。改善計画を通じて、組織は計画を改善し、能力を構築・維持し、即応性を維持するために必要な是正措置を講じる。
・[PDF] Homeland Security Exercise and Evaluation Program Doctrine	国土安全保障演習・評価プログラムのドクトリン
・[PDF] El Programa de Evaluación y Ejercicios de Seguridad Nacional	国土安全保障評価演習プログラム
・[PDF] HSEEP Information Sheet	HSEEP情報シート
・[PDF] HSEEP Frequently Asked Questions 2020	HSEEPよくある質問2020

・[PDF] Homeland Security Exercise and Evaluation Program Doctrine

演習は、大きく

1. ディスカッションベース：セミナー、ワークショップ、机上演習（TTX）、ゲーム
2. オペレーションベース：ドリル、機能演習 (FE) 、総合演習（FSE）

の２パターンを示していますね。。。

---

1. ディスカッションベースの演習

ディスカッション形式の演習には、セミナー、ワークショップ、机上演習（TTX）、ゲームなどがある。この種の演習は、計画、方針、手順、および協定に慣れ親しんだり、新しいものを開発したりするものである。ディスカッションベースの演習は、戦略的、政策的な問題に焦点を当て、ファシリテーターやプレゼンターが議論をリードし、参加者が演習の目的を達成するために動き続けるものである。次の表（表2.3, 表2.4、表2.5、表2.6）には、それぞれのタイプのディスカッションベースの演習の重要な情報が記載されている。

表2.3：ディスカッション型演習の種類：セミナー

セミナー
当局、戦略、計画、方針、手順、プロトコル、リソース、概念、およびアイデアについて参加者に説明する、または概要を提供するディスカッションベースの演習。
要素	考察と活動
目的	•        共通の理解の枠組みを提供する
	•        既存の計画、方針、または手順を開発または大きく変更するための良い出発点を提供する。
構造	•        通常、複数のプレゼンテーション、主題専門家（SME）パネル、またはケーススタディ・ディスカッションの形式で行われる。
	•        講義形式
	•        セミナーのファシリテーター/プレゼンターが主導する
	•        参加者からのフィードバックやインタラクションが少ない
参加者の目標	•         省庁間の能力または管轄区域間の業務に対する認識を得る、または評価する。
	•        将来の能力に関する目標を設定する
実施上の特徴	•        最小限の時間的制約
	•        少人数でも大人数でも効果的
成果	•         議論、提起された問題、および（適切な場合）これらの問題に対処するためのアクションアイテムを記録した報告書
	•        アフターアクションレポート（AAR）／改善計画（IP）

表2.4：ディスカッション型演習の種類：ワークショップ

ワークショップ
政策、計画、手順の策定によく用いられる議論ベースの演習。
要素	考察と活動
目的	•        製品の実現や構築にフォーカスした参加者同士の交流の活発化
	•        目的、製品、または目標が明確に定義され、特定の問題に焦点を当てたものであること
構造	•        ディスカッションができる場での個人の集まり
	•        講義、プレゼンテーション、パネルディスカッション、ケーススタディーディディスカッション、または意思決定支援ツール ワーキングブレイクアウトセッションのファシリテーション ワークショップのファシリテーター/プレゼンターがリードする
参加者の目標	•        グループでの製品開発
	•        コンセンサスを得る
	•        情報の収集または共有
実施上の特徴	•        少人数でも大人数でも効果的
	•        関連するステークホルダーが幅広く参加
	•        明確な目的・目標に基づく実施
	•        講義形式ではなく、参加者同士のディスカッション形式
	•        同じようなグループと課題の一部を探索するために、頻繁にブレイクアウトセッションを利用する
成果	•        緊急時対応計画
	•        相互援助協定
	•        標準作業手順書
	•         事業継続計画
	•        ワークショップ概要報告
	•        アフターアクションレポート（AAR）／改善計画（IP）

表2.5：ディスカッション型演習のタイプ：机上演習

机上演習 Tabletop Exdercise (TTX)
概念的な理解を促進し、長所と改善点を明らかにし、計画、政策、または手続きに関する認識の変化を達成するために、さまざまな問題について対話を行うことを目的とした、シナリオに応じたディスカッションベースの演習である。
要素	考察と活動
目的	•        演習シナリオに関する様々な課題についての議論を行う
	•        概念的な理解を促進し、強みと改善点を明らかにする、または認識の変化を達成する
構造	•        シナリオを提示し、模擬的な時間における事象を説明する
	•        プレイヤーは、ファシリテーターから提示された問題のリストに自分の知識とスキルを適用する
	•         問題点をグループで話し合い、解決に至り、後の分析のために文書化することができる
	•        全体会議または分科会（複数可）
	•        ファシリテーター（複数）によるディスカッション
	•        プレゼンテーション
参加者の目標	•        一般的な認知度の向上
	•        役割と責任の理解を深める
	•        計画や手順の妥当性確認
	•        定義されたインシデントにおけるシステムの種類を評価し、コンセプトを議論する
実施上の特徴	•        経験豊富なファシリテーターが必要
	•        徹底討論
	•        問題解決型の環境
	•        参加者全員が議論に貢献するよう奨励し、無過失責任な環境で意思決定していることを再認識させる必要がある
成果	•        現行の計画、方針、手順の改訂を推奨する。
	•        アフターアクションレポート（AAR）／改善計画（IP）

表2.6：ディスカッション型演習の種類：ゲーム

ゲーム
個人またはチーム向けに設計された、競技または非競争環境での構造化されたプレイであり、議論に基づいたエクササイズ。プレーヤーが参加するイベントであり、その実行には明確なルール、データ、手順が指導される。ゲームは、実際の状況または仮想の状況を描写し、参加者がもっともらしい意思決定と行動を確実に行えるように設計されている。ゲームは、トレーニングの強化、チームビルディングの活性化、作戦・戦術能力の向上などに利用することができる。
要素	考察と活動
目的	•        プレイヤーの意思決定や行動の帰結を探る操作シミュレーション
	•        重要な意思決定ポイントの特定は、ゲーム評価の成功に大きく影響する
構造	•        通常、2つ以上のチームが参加できる環境において、実際の状況または仮想の状況を想定したルール、データ、手順を使用する
	•         意思決定は、演習のデザインと目的によって、ゆっくりじっくり行うことも、素早くストレスのかかることを行うこともできます
	•        ゲームのオープンで意思決定に基づく形式は、エクササイズの効果を拡大する「もしも」の質問を取り入れることができる
	•        ゲームのデザインによって、プレイヤーの行動の結果は、事前に記述される場合と動的に決定される場合がある
参加者の目標	•        意思決定のプロセスと結果を探る
	•        既存プランの「what-if」分析の実施
	•        既存および潜在的な戦略を評価する
実施上の特徴	•        実際に使用するリソースはない
	•        多くの場合、2つ以上のチームが参加する
	•        ゲームの進行に応じて複雑化するモデルやシミュレーションが含まれる場合がある
	•        あらかじめ用意されたアクティビティが含まれる場合と含まれない場合がある
成果	•        計画、方針、手順の妥当性確認、またはリソース要件の評価
	•        アフターアクションレポート（AAR）／改善計画（IP）

2. ディスカッションベースの演習

オペレーションベースの演習には、ドリル、機能演習（FE）、および総合演習（FSE）が含まれる。これらの演習は、計画、方針、手順、および合意を検証し、役割と責任を明確にし、リソースのギャップを特定するものである。運用に基づく演習は、通信の開始、人員及び資源の動員などのリアルタイムの応答を含む。次の表（表2.7、表2.8、表2.9）は、それぞれのタイプのオペレーションベースの演習のための重要な情報を提供する。

表2.7：オペレーションベースの演習の種類：ドリル

ドリル
オペレーションに基づく演習で、単一のオペレーションまたは機能を検証するためによく採用される。
要素	考察と活動
目的	•         単一の機関/組織における特定の機能または能力を検証するため調整され、監督された活動で、多くの場合、単一の操作または機能を検証するために使用される
	•        新しい機器のトレーニング、手順の検証、または現在のスキルの練習と維持の提供
構造	•        単体でも、連続したドリルとしても使用可能
	•        明確に定義された計画、手順、プロトコルを実施する必要がある
参加者の目標	•        新しい手順、方針、および/または機器を評価する
	•         スキルの練習と維持
	•        今後の演習に備える
実施上の特徴	•        即時フィードバック
	•        リアルな環境
	•        ナローフォーカス
	•        単体での性能
	•        結果は、確立された基準に照らして測定される
成果	•        計画が設計通りに実行されるかどうかを判断する
	•        さらなるトレーニングが必要かどうかを評価する
	•        ベストプラクティスの強化
	•        アフターアクションレポート（AAR）／改善計画（IP）

表2.8：オペレーションベースの演習の種類。機能演習

機能演習Function Exercise（FE）
オペレーションベースの演習は、現実的なリアルタイムの環境下で、能力や機能をテストし評価するように設計されているが、リソースの移動は通常シミュレートされる。
要素	考察と活動
目的	•        能力、複数の機能及び／又は下位機能、又は相互依存のある活動群を検証し評価する。
	•        管理、指揮、統制の機能に関わる計画、方針、手順、スタッフについて演習する。
	•        危機的状況下で、確立されたプラン、ポリシー、手順を適用する
構造	•        現実的な演習シナリオでイベントが投影され、イベントの更新により、通常、管理者レベルでの活動が促進される
	•        コントローラは通常、マスターシナリオイベントリスト（MSEL）を使用して、参加者の活動が事前に定義された境界線内に収まるようにする
	•        評価者は行動を観察し、確立された計画、方針、手順、標準的な実践（該当する場合）に照らして比較する。
参加者の目標	•        能力の検証・評価
	•        計画、方針、手続きに重点を置く
実施上の特徴	•        現実的な環境で実施
	•        通常、リソースと人員の配置をシミュレートしている
	•        シミュレーションセルとマスターシナリオイベントリスト（MSEL）の活用
	•        シミュレーターはシナリオの要素を注入することができる
	•        コントローラーと評価者を含む
成果	•        緊急時対応センター（EOC）、指揮所、本部、スタッフの管理評価
	•        パフォーマンス分析
	•        協力関係の強化
	•        アフターアクションレポート（AAR）／改善計画（IP）

表2.9:オペレーションベースの演習の種類：総合演習

総合演習 Full-Scale Exercise (FSE)
演習の種類の中で最も複雑で資源を必要とし、多くの場合、複数の機関、管轄区域/組織、および資源のリアルタイムの移動を伴うオペレーションベースの演習である。
要素	考察と活動
目的	•        ICS（インシデント・コマンド・システム）のような協力体制のもとで活動する多くのプレーヤーを含むことが多い
	•        ディスカッション形式の演習で作成され、以前の小規模な演習で磨かれた計画、方針、手順の実施と分析に重点を置いている。
構造	•        イベントは演習シナリオを通して投影され、イベントのアップデートによりオペレーションレベルでの活動が促進される
	•        複数の機関、組織、管轄区域が関与していること
	•        MSELの使用は、プレイヤーの行動を促進する
	•        SimCellコントローラは、シナリオ要素を注入する
	•        他のタイプのエクササイズに比べ、必要なサポートのレベルが高い可能性がある
	•        複雑な問題を提示し、実際の事件を反映させたリアルな環境で実施
参加者の目標	•        計画や手順で示された役割と責任を実証する
	•        複数の機関、組織、管轄区域の間の調整
実施上の特徴	•        迅速な問題解決、クリティカルシンキング
	•        人材とリソースの動員
	•        運動場は通常、多くの活動が同時に行われる大規模なものである
	•        サイトロジスティクスの綿密なモニタリングが必要
	•        特に小道具や特殊効果の使用に関する安全性の問題を監視する必要がある
	•        計画や手順で示された役割と責任を実証する
成果	•        計画、方針、手順の妥当性確認
	•        リソース要求の評価
	•        アフターアクションレポート（AAR）／改善計画（IP）

英国 データ倫理・イノベーションセンター「業界温度チェック：AI保証の障壁と実現要因」

こんにちは、丸山満彦です。

英国政府のデジタル・文化・メディア・スポーツ省にあるデータ倫理・イノベーションセンターが、「業界温度チェック：AI保証の障壁と実現要因」という報告書を公表しています。業界として選ばれたのは、「人事・採用」、「金融」、「コネクテッドカー・自動運転車 (CAV)」です。。。

「知識・スキルの不足」、「需要不足」というのが、共通して大きな障害という感じですかね。。。

● U.K. Government - Department for Digital, Culture, Media & Sport - Centre for Data Ethics and Innovation

・2022.12.08 Industry temperature check: barriers and enablers to AI assurance

目次...

1.Overview	1.概要
2.General findings: Key themes	2.一般的な調査結果 主要テーマ
3.General findings: Barriers to AI assurance	3.一般的な調査結果 AI保証の障壁
4.General findings: Interventions	4.主な調査結果 介入策
5.Sector-specific findings: Overview	5.分野別所見 概要
6.Summary view across sectors	6.部門別のまとめ
7.HR and recruitment: Overview	7.人事・採用：概要
8.HR and recruitment: Barriers to AI assurance	8.人事・採用：AI保証のための障壁
9.HR and recruitment: Interventions	9.人事・採用：介入
10.Finance: Overview	10.財務：概要
11.Finance: Barriers to AI assurance	11.財務：AI保証のための障壁
12.Finance: Interventions	12.財務：介入
13.Connected and automated vehicles (CAV): Overview	13.コネクテッドカー・自動運転車 (CAV)：概要
14.Connected and automated vehicles (CAV): Barriers to AI assurance	14.コネクテッドカー・自動運転車 (CAV)： AI保証のための障壁
15.Connected and Automated Vehicles (CAV): Interventions	15.コネクテッドカー・自動運転車 (CAV)： 介入
16.Looking towards the future	16.将来に向けて
17.Methodology	17.方法論

概要...

1. Overview	1. 概要
AI assurance - mechanisms to assess and communicate reliable evidence about the trustworthiness of AI systems - has an important role to play in helping to achieve the government’s ambitions for a risk based, pro-growth approach to AI governance, as set out in the National AI Strategy. Providing a toolbox of assurance mechanisms for use with AI - such as technical and governance standards, impact assessments, and possibly in the longer-term, certification - will enable greater adoption of AI and data-driven technologies, while supporting organisations to innovate responsibly. The Roadmap to an Effective AI Assurance Ecosystem, developed by the Centre for Data Ethics and Innovation (CDEI), sets out a path to building an effective and mature ecosystem of AI assurance services in the UK.	AI保証（AIシステムの信頼性に関する信頼できる証拠を評価し伝達するメカニズム）は、国家AI戦略で示されたように、AIガバナンスに対するリスクベースの成長促進アプローチという政府の野心の達成を支援する重要な役割を担っている。技術基準やガバナンス基準、影響評価、そして長期的には認証など、AIで使用するための保証メカニズムのツールボックスを提供することは、AIやデータ駆動型技術の採用を拡大し、同時に組織が責任を持ってイノベーションを行うことを支援することになる。 データ倫理・イノベーションセンター（CDEI）が開発した「効果的なAI保証エコシステムへのロードマップ」は、英国におけるAI保証サービスの効果的で成熟したエコシステムを構築するための道筋を示している。
To support delivery of the Roadmap, the CDEI launched its AI Assurance Programme. In its first year, the focus of the programme has been to gain a better understanding of current levels of industry engagement with AI assurance, to best focus our efforts on areas with the highest potential for impact.	このロードマップの実現を支援するため、CDEIはAI保証プログラムを立ち上げた。初年度のプログラムの焦点は、AI保証に対する業界の現在の取り組みレベルをより深く理解し、最も効果が期待できる分野に焦点を当てることにある。
Since the publication of the Roadmap, the CDEI has facilitated a series of events with stakeholders. Our Industry Temperature Check: Barriers and Enablers to AI Assurance summarises key findings from these activities, which included: a series of Ministerial roundtables, the CDEI x techUK AI assurance symposium, semi-structured interviews, and an online survey, reflecting the views of diverse stakeholders across sectors.	ロードマップの発表以来、CDEIはステークホルダーとの一連のイベントを開催してきた。私たちの業界温度チェック。本書は、一連の閣僚級円卓会議、CDEI x techUK AI assuranceシンポジウム、半構造化インタビュー、オンライン調査など、セクターを超えた多様なステークホルダーの意見を反映したこれらの活動から得られた主要な結果を要約している。
In addition to this, we have chosen to examine in more detail three sectors that face distinct challenges from increased AI adoption: HR and recruitment, finance, and connected and automated vehicles (CAV). This is to ensure that we capture a breadth of concerns and incentives for implementing AI assurance across the economy.	これに加えて、AI導入の拡大により明確な課題に直面する3つのセクターをより詳細に検討することにした。「人事・採用」「金融」「コネクテッドカー・自動運転車（CAV）」です。これは、経済全体でAI保証を実施するための懸念とインセンティブを幅広く捉えるためである。
This publication identifies industry barriers and enablers to engaging with AI assurance, to identify potential practical interventions to support increased uptake and adoption of AI assurance techniques and standards. The report is broken into four sections, the first focusing on cross-sectoral findings, with the following sections focusing on sector-specific findings from HR and recruitment, finance, and CAV.	本書は、AI保証に関与する業界の障壁と実現要因を特定し、AI保証の手法と標準の取り込みと採用の増加を支援するための実践的な介入の可能性を明らかにしている。本報告書は4つのセクションに分かれており、最初のセクションではセクター横断的な知見に焦点を当て、次のセクションでは人事・採用、金融、CAVのセクター固有の知見に焦点を当てている。
The findings illustrated in this paper will inform the continued development of the CDEI’s AI assurance Programme and inform our practical interventions to support the development of a thriving AI assurance ecosystem.	本論文で示された知見は、CDEIのAI保証プログラムの継続的な開発に情報を提供し、繁栄するAI保証エコシステムの開発を支援するための実践的な介入に情報を提供する。

一般的な発見事項：主要なテーマ

2. General findings: Key themes	2. 一般的な発見事項：主要なテーマ
Over the past year, the CDEI has engaged with AI developers, AI assurance service providers, and industry executives from startups, SMEs, and multinationals across a variety of sectors, to gauge familiarity and engagement with AI assurance and identify priority areas for supporting the development of a world-leading AI assurance ecosystem in the UK. This exercise has identified a number of key themes, outlined below:	CDEIは、過去1年間にわたり、AI開発者、AI保証サービスプロバイダ、さまざまな分野の新興企業、中小企業、多国籍企業の業界幹部と関わり、AI保証に対する親近感と関与を測定し、英国における世界有数のAI保証エコシステムの開発を支援するための優先領域を特定した。この調査により、以下のような重要なテーマが特定された。
AI assurance as part of wider risk management	より広範なリスクマネジメントの一環としてのAI保証
AI assurance was often contextualised by participants as an important element of a wider organisational risk management framework. Participants reported developing or expanding existing risk management frameworks to include AI-related risks. These include technical risks, which can be mitigated by modifications to model design or input data, and governance risks, which can be mitigated by changes to organisational policies or processes.	AI保証は、参加者によって、より広範な組織のリスクマネジメントの枠組みの重要な要素であるという文脈で語られることが多い。参加者は、AI関連のリスクを含む既存のリスクマネジメントのフレームワークを開発または拡張していると報告している。これには、モデル設計や入力データの修正によって軽減できる技術的リスクや、組織のポリシーやプロセスの変更によって軽減できるガバナンスリスクが含まれる。
Industry support for a proportionate approach to assurance	保証のための比例アプローチに対する業界の支持
Participants emphasised that selecting an assurance technique to evaluate a system is dependent on the context in which the system is deployed. They noted that the appropriate technique may be determined by a range of factors, including lifecycle stage, risk category, risk level, sector, use case, and legal/regulatory requirements. Typically, participants supported a proportionate approach to assurance, in which low-risk sectors/use cases utilise less formal assurance techniques (e.g. impact assessment), while high risk industries/use cases utilise a combination of assurance techniques (e.g. impact assessment, as well as performance testing, conformity assessment and/or validation).	参加者は、システムを評価するための保証手法の選択は、そのシステムが展開される状況に依存することを強調した。適切な手法は、ライフサイクルステージ、リスクカテゴリー、リスクレベル、セクター、ユースケース、法的／規制上の要件など、様々な要因によって決定される可能性があることを指摘した。一般的に、参加者は、低リスクの分野／ユースケースはあまり正式でない保証手法（例：影響評価）を利用し、高リスクの業界／ユースケースは保証手法（例：影響評価に加え、性能試験、適合性評価及び／又はバリデーション）を組み合わせて利用する、保証の比例アプローチを支持した。
Industry desire for third-party certification/accreditation	第三者認証/認定に対する業界の要望
Many participants felt the use of third-party tools and services - including cloud-based and software-as-a-service (SaaS) assurance platforms - was preferable to using internal services, as they provide an impartial perspective. However, there are concerns around the consistency and robustness of third-party assurance services. Participants expressed a desire for certification or accreditation schemes as a means of recognising and demonstrating the credibility and quality of third-party assurance service providers.	多くの参加者は、クラウドベースやSaaS（Software-as-a-Service）保証プラットフォームなど、第三者のツールやサービスの利用は、公平な視点を提供するため、内部サービスの利用よりも望ましいと考えている。しかし、第三者による保証サービスの一貫性や堅牢性については懸念がある。参加者からは、第三者保証サービス提供者の信頼性と品質を認識・実証する手段として、認証や認定の仕組みを望む声が聞かれた。
Standards to support AI assurance techniques	AIの保証技術をサポートする標準
Many participants referenced using standards developed by standards development organisations (SDOs) alongside other assurance techniques. Some adopted standards directly, while others used them as a point of reference for what they should be assuring for (e.g. explainability and robustness) and then developed their own methods for achieving these aims. Organisations which did not use technical standards reported that this is, in part, because the standards landscape is complex and difficult to navigate.	多くの参加者が、標準化団体（SDO）が開発した標準を他の保証手法と併用していることに言及している。標準を直接採用する場合もあれば、何を保証すべきかの基準（説明可能性や堅牢性など）として標準を使用し、その目的を達成するための独自の方法を開発する場合もありました。技術標準を使用しない組織は、標準の状況が複雑で進むのが困難であることが一因であると報告している。
Prevalence of impact assessments	影響評価の普及
The most frequently cited assurance techniques were impact assessments. Impact assessments pose questions to identify potential ethical and societal impacts of an AI system, and may focus on design and development processes, or wider organisational processes. Participants noted that impact assessments are often the initial stage of an assurance engagement, used to identify what additional measures may be required to assure the system.	最も頻繁に引用された保証手法は、影響評価であった。影響評価は、AIシステムの潜在的な倫理的・社会的影響を特定するための質問を投げかけ、設計・開発プロセスやより広範な組織的プロセスに焦点を当てることがある。参加者は、影響評価は保証業務の初期段階であることが多く、システムを保証するためにどのような追加措置が必要かを特定するために使用されると述べている。
Assurance creates competitive advantage	保証は競争優位を生み出す
There was a strongly held view among participants that AI assurance can provide organisations with ‘a competitive edge’, through building customer trust and managing reputational risk. On one hand, using assurance techniques to evaluate AI systems can build trust in consumer-facing AI systems by demonstrating adherence to ethical values (fairness, transparency etc.) and/or relevant regulation/legislation. On the other hand, using assurance techniques can also help identify and mitigate AI-related risks to manage reputational risks and avoid negative publicity. This helps to mitigate greater commercial risks, in which high-profile failures could lead to reduced customer trust and adoption of AI systems.	参加者の間では、AIによる保証は、顧客の信頼構築やレピュテーションリスクのマネジメントを通じて、企業に「競争優位性」をもたらすという意見が強く聞かれた。一方では、AIシステムの評価に保証技術を用いることで、倫理的価値（公平性、透明性など）や関連する規制・法律への準拠を実証し、消費者向けのAIシステムに対する信頼を構築することができる。一方、保証技術を使用することで、AI関連のリスクを特定・軽減し、レピュテーションリスクをマネジメントし、ネガティブな評判を回避することもできる。これは、知名度の高い失敗が顧客の信頼とAIシステムの採用の減少につながる可能性のある、より大きな商業的リスクを軽減するのに役立つ。
Regulatory compliance is a key driver of assurance	規制遵守は保証の重要な推進力
The need to comply with relevant existing and future regulation and legislation to demonstrate best practice and avoid penalties was identified by participants as a key driver of AI assurance, and is likely to drive both the adoption of existing assurance techniques as well as the development of new assurance techniques and standards. Organisations will need to comply with both existing legislation like the UK General Data Protection Regulation (UK GDPR) as well as anticipated future regulatory frameworks like the regime to be outlined in the UK’s forthcoming White Paper on AI Regulation.	ベストプラクティスを実証し、罰則を回避するために、関連する既存および将来の規制や法律に準拠する必要性は、参加者によってAI保証の主要な推進力として認識されており、既存の保証技術の採用と新しい保証技術や標準の開発の両方を推進すると思われる。組織は、英国一般データ保護規則（英国GDPR）のような既存の法律と、英国が近々発表するAI規制白書で概説される体制のような将来予想される規制枠組みの両方に準拠する必要がある。
Participants were eager to understand how different assurance techniques could help organisations to demonstrate implementation and integration of the proposed regulatory principles set out in the UK Government’s July 2022 Establishing a pro-innovation approach to regulating AI paper, highlighting how regulation can also drive requirements for AI assurance. Participants were also mindful of the EU AI Act, which they anticipated is likely to mandate certain assurance activities such as risk management frameworks and conformity assessments, acting as a direct driver of AI assurance.	参加者は、英国政府が2022年7月に発表した「Establishing a pro-innovation approach to regulating AI paper」で示された規制原則案の実施と統合を実証するために、さまざまな保証技術がどのように役立つかを理解しようとしており、規制がAI保証の要件を推進することもできると強調している。また、参加者は、リスクマネジメントの枠組みや適合性評価など、特定の保証活動を義務付ける可能性が高いと予想されるEUのAI法にも留意しており、AI保証の直接的な推進力として作用しているようだ。

障壁とその説明...

Barrier type : Description	障壁の種類 : 説明
Workforce barriers : Lack of knowledge/skills: In many organisations that design and develop AI systems, staff either don't know what unique risks AI poses, or can identify these risks but don't have the skills or knowledge to effectively mitigate them. Alternatively, in organisations that procure AI systems, teams are often unaware that they may be required to monitor, prove or assess the performance of these systems over time.	人材に関する障壁:知識・スキルの不足。 AIシステムを設計・開発する多くの組織では、スタッフがAIがもたらす固有のリスクを知らないか、リスクを特定できてもそれを効果的に軽減するスキルや知識を持ち合わせていないかのどちらかである。また、AIシステムを調達している組織では、これらのシステムのパフォーマンスを長期にわたって監視、証明、評価することが求められる可能性があることを知らない場合が多いようである。 :
Organisational barriers : Lack of buy-in from senior management teams: Many senior decision-makers (e.g. managing directors/partners) are often unaware of the concept of responsible AI, and as a result don't prioritise or fund measures to support the development of responsible systems. Participants noted the importance of making a strong business case for AI assurance, which can help senior leaders demonstrate return on investment (ROI) in responsible AI.	組織的な障壁:経営幹部からの支持の欠如。 多くの上級意思決定者（例：マネージング・ディレクターやパートナー）は、責任あるAIの概念を知らないことが多く、その結果、責任あるシステムの開発をサポートするための施策に優先順位をつけたり、資金を提供したりすることがない。参加者は、シニアリーダーが責任あるAIへの投資収益率（ROI）を実証するのに役立つ、AI保証のための強力なビジネスケースを作ることの重要性を指摘した。 :
Lack of resources: Lack of financial resources is a common barrier to AI assurance, specifically for the adoption of standards developed by standards development organisations (SDOs). Many SDO-developed standards are labour intensive and costly, requiring considerable time and effort to adopt. This is a particularly big barrier for small and medium-sized enterprises (SMEs), who typically have more limited resources to devote to responsible AI development.	リソースの不足：リソースの不足は、AI保証、特に標準開発組織（SDO）が開発した標準の採用に対する共通の障壁である。SDOが開発した標準の多くは、労働集約的でコストが高く、採用にはかなりの時間と労力を必要とします。これは、責任あるAI開発に割くことのできるリソースが通常より限られている中小企業（SME）にとって、特に大きな障壁となる。
Operational/ market barriers : Lack of standardised/unified approach: Due to the newness of the AI assurance market, there is fragmentation and a lack of consistency across AI assurance service providers. For example, each provider may use different metrics and/or measurement techniques for assessing an AI system. This multitude of approaches makes it difficult for organisations to determine which assurance service provider or technique is best suited to assess their AI systems.	運用／市場の障壁：標準化／統一されたアプローチの欠如。 AI保証市場の新しさにより、AI保証サービスプロバイダ間で断片化し、一貫性が欠けている。例えば、各プロバイダーは、AIシステムを評価するために、異なる測定基準や測定技術を使用することがあります。このような多様なアプローチにより、企業はどの保証サービスプロバイダや手法が自社のAIシステムの評価に最も適しているかを判断することが困難になっている。 :
Governance barriers : Regulatory uncertainty: There is considerable hesitancy to invest resources in adopting assurance techniques or standards that may be irrelevant or incompatible with future regulatory requirements. There is a need for more clarity around which standards/assurance techniques may support compliance with future regulatory requirements.	ガバナンスの障壁：規制の不確実性。 将来の規制要件と無関係または互換性がない可能性のある保証技術や標準を採用するためにリソースを投資することには、かなりのためらいがあります。将来の規制要件への準拠をサポートする規格や保証技術について、より明確にする必要がある。 :

セクターごとの優先度...

★★★:高影響度、★★：中影響度、★：低影響度、？：評価なし

障壁	人事・採用	金融	CAV
知識・スキルの不足	★★★	★★★	★★★
ガイダンスの不足	？	★★	★★
利用可能な保証手法の認識不足	★★	★★★	★
利用可能な規格の認識不足	？	★★★	★★
ベストプラクティスへの道しるべがない	？	★★★	★★★
需要（社内外）の不足	★★★	★★	★★★
適切な手法・規格を選択することが難しい	★	★★	★
標準にかかる金銭的コスト	？	？	★
国際的な相互運用性の欠如	★	★	★
規制の不確実性	？	★★★	★
保証のための努力を認める仕組みの欠如	？	★	★★★
標準化状況の複雑さ	？	★	★

・PDFなら。。。

・[PDF] Industry Temperature Check - Barriers and Enablers to AI Assurance

 

NIST NISTIR 8409 共通脆弱性評点システムの基礎評点の計算式の測定 (2022.11.15)

こんにちは、丸山満彦です。

意見募集をしていた、NISTIR 8409 共通脆弱性評点システムの基礎評点の計算式の測定が確定のようですね。。。

● NIST - ITL

・2022.11.15 NISTIR 8409 Measuring the Common Vulnerability Scoring System Base Score Equation

NISTIR 8409 Measuring the Common Vulnerability Scoring System Base Score Equation	NISTIR 8409 共通脆弱性評点システムの基礎評点の計算式の測定
Abstract	概要
This work evaluates the validity of the Common Vulnerability Scoring System (CVSS) Version 3 "base score" equation in capturing the expert opinion of its maintainers. CVSS is a widely used industry standard for rating the severity of information technology vulnerabilities; it is based on human expert opinion across many sectors and industries. This study is important because the equation design has been questioned since it has features that are both unintuitive and unjustified by the CVSS specification. If one can show that the equation reflects CVSS expert opinion, then that study justifies the equation, and the security community can treat the equation as an opaque box that functions as described.	この研究では、共通脆弱性評点システム (CVSS) Version 3の「基礎評点」式が、その保守者の専門的な意見を反映する上で有効であるかどうかを評価する。CVSSは、情報技術の脆弱性の深刻度を評価するための業界標準として広く利用されており、多くの分野や産業における人間の専門的な意見に基づいている。この研究は、CVSSの仕様では直感的でなく、正当化できない特徴を持つ方程式の設計が疑問視されているため、重要である。もし、数式がCVSS専門家の意見を反映していることを示すことができれば、その研究は数式を正当化し、セキュリティコミュニティは数式を説明通りに機能する不透明な箱として扱うことができる。
This work shows that the CVSS base score equation closely -- though not perfectly -- represents the CVSS maintainers' expert opinion. The CVSS specification itself provides a measurement of error called "acceptable deviation" (with a value of 0.5 points). This work measures the distance between the CVSS base scores and the closest consistent scoring systems (ones that completely conform to the recorded expert opinion). The authors calculate that the mean scoring distance is 0.13 points, and the maximum scoring distance is 0.40 points. The acceptable deviation was also measured to be 0.20 points (lower than claimed by the specification). These findings validate that the CVSS base score equation represents the CVSS maintainers' domain knowledge to the extent described by these measurements.	この研究は、CVSSの基礎評点の式が、完全ではないものの、CVSSの保守者の専門家の意見を忠実に表していることを示している。CVSS仕様自体は、「許容偏差」（0.5ポイントの値を持つ）と呼ばれる誤差の測定法を提供している。この研究では、CVSSの基礎評点と、最も近い整合性のある評点システム（記録された専門家の意見に完全に適合するもの）との間の距離を測定している。著者らは、平均評点距離は0.13ポイント、最大評点距離は0.40ポイントと計算している。また、許容偏差は0.20ポイントと測定された（仕様で主張されている値より低い）。これらの結果から、CVSSの基礎評点式がCVSS保守者のドメイン知識をこれらの測定値で記述される程度に表していることが検証された。

・[PDF] NISTIR 8409

目次...

Executive Summary	エグゼクティブサマリー
1.  Introduction	1.  はじめに
2.  Common Vulnerability Scoring System	2.  共通脆弱性評点システ
2.1. CVSS Base Score Metrics	2.1. CVSS 基礎評点の評価基準
2.2. CVSS Base Score Equations	2.2. CVSS 基礎評点の計算式
3.  Rationale for the CVSS Base Score Equations	3.  CVSS基礎評点の算出根拠
3.1. Development of the CVSS Base Score Equation	3.1. CVSS基礎評点評価式の開発
3.2. Acceptable Deviation	3.2. 許容される偏差
4.  Metrology Tools, Metrics, and Algorithms	4.  測定ツール、測定基準、アルゴリズム
4.1. Knowledge Encoder Tool	4.1. ナレッジ・エンコーダ・ツール
4.2. Knowledge Constraint Graphs	4.2. 知識制約グラフ
4.2.1.  Equivalency Sets	4.2.1.  等価集合
4.2.2.  Magnitude Measurements	4.2.2.  マグニチュード測定
4.2.3.  Simplified Graphs	4.2.3.  簡略化されたグラフ
4.3. Inconsistency Metrics for Knowledge Constraint Graphs	4.3. 知識制約グラフの非整合性指標
4.4. Voting Unification Algorithm	4.4. 投票一元化アルゴリズム
4.4.1.  Analysis of Votes	4.4.1.  投票の解析
4.4.2.  Priority Ordering	4.4.2.  優先順位付け
4.4.3.  Unified Graph Construction	4.4.3.  ユニファイドグラフの構築
4.4.4.  Description of Constructed Graph	4.4.4.  構築されたグラフの記述
5.  Data Collection and Processing	5.  データの収集と処理
5.1. Data Set of Analyzied Vectors	5.1. 解析済みベクターのデータセット
5.2. Volunteer Participants	5.2. ボランティア参加者
5.3. Produced Knowledge Constraint Graphs	5.3. 作成された知識制約グラフ
5.4. Knowledge Constraint Graph Inconsistency Measurements	5.4. 知識制約グラフの非整合性測定
5.4.1.  Graph f00	5.4.1.  グラフf00
5.4.2.  Graph 977	5.4.2.  グラフ977
5.5. Unified Knowledge Constraint Graph	5.5. 統合知識制約グラフ
5.6. Optimal Number of Equivalency Sets	5.6. 最適な等価集合の数
6.  Measurement Approach	6.  測定アプローチ
6.1. Consistent Scoring Systems	6.1. 一貫した採点システム
6.1.1.  Scoring System Defnition	6.1.1.  採点システムの定義
6.1.2.  Consistent Scoring System Defnition	6.1.2.  一貫性のある採点システムの定義
6.2. Generation of a Closest Consistent Scoring System	6.2. 最接近型採点システムの生成
6.3. Measurement Methodology	6.3. 測定方法
7.  Measurement Results	7.  測定結果
7.1. Mean Scoring Distance	7.1. 平均得点距離
7.2. Maximum Scoring Distance	7.2. 最大評点距離
7.3. Acceptable Deviation	7.3. 許容偏差
7.4. Increasing Accuracy with More Data	7.4. より多くのデータによる精度の向上
8.  Interpretation of Results and Related Work	8.  結果の解釈と関連する研究
9.  Conclusion	9.  まとめ
References	参考文献
Appendix A. Acronyms	附属書A. 頭字語
Appendix B. Set of Evaluated CVSS vectors	附属書B. 評価済みCVSSベクタの集合
Appendix C. Encoded Knowledge Constraint Graphs	附属書C. 符号化された知識制約グラフ

エグゼクティブサマリー...

Executive Summary	エグゼクティブサマリー
The Common Vulnerability Scoring System (CVSS) Version 3 maintained by the CVSS Special Interest Group (SIG) is a widely used industry standard for characterizing the properties of information technology vulnerabilities and measuring their severity. It is based on human expert opinion. Vulnerability properties are characterized through a multidimensional vector. The severity is primarily defned through a multi-part “base score” equation with 8 input metrics that is not readily amenable to human comprehension.	CVSS Special Interest Group (SIG) によって維持されている 共通脆弱性評点システム (CVSS) Version 3 は、情報技術の脆弱性の特性を特徴付け、その深刻度を測定するために広く使用されている業界標準である。CVSSは、人間の専門家の意見に基づいている。脆弱性の特性は、多次元ベクトルによって特徴づけられます。深刻度は、主に8つの入力指標を持つ多部構成の「基礎評点」式によって定義されるが、これは人間の理解には容易ではない。
To develop the equation, CVSS SIG members frst described a set of real vulnerabilities using CVSS vectors and assigned them one of fve severity levels. This created a partial lookup table mapping vectors to severity levels. They then defned a target score range for each severity level and created an equation to attempt to map each vector to a score within the specifed score range. Finally, they reviewed the equation’s scoring of vectors that were not included in the partial lookup table to evaluate the effectiveness of the equation on the full set of possible vectors. Since the equation could not perfectly map vectors to score ranges, the CVSS Version 3.1 specifcation provides a measurement of error (an ‘acceptable deviation’ of 0.5 points). However, suffcient information is not provided to reproduce the experiment.	この方程式を開発するために、CVSS SIGのメンバーはまず、CVSSベクトルを使用して一連の実際の脆弱性を記述し、5段階の深刻度レベルのうちの1つを割り当てた。これにより、ベクターと重要度レベルを対応させた部分的なルックアップテーブルが作成された。次に、各重要度レベルの目標評点範囲を定義し、各ベクトルを指定された評点範囲内の評点に対応付けることを試みる方程式を作成した。最後に、部分ルックアップテーブルに含まれていないベクトルに対する方程式の評点を確認し、可能性のあるすべてのベクトルに対する方程式の有効性を評価した。この方程式はベクターを評点範囲に完全に対応付けることができないため、CVSSバージョン3.1の仕様では、誤差の測定値（0.5ポイントの「許容偏差」）を提供している。しかし、実験を再現するのに十分な情報は提供されていない。
This work measures the degree to which the CVSS base score equation refects CVSS SIG expert domain knowledge while providing a reproducible justifcation for the measurements. It starts not from a set of real vulnerabilities, as the CVSS SIG did, but from a set of 66 vulnerability types (i.e., CVSS vectors) that represent 90 % of the vulnerabilities published by the U.S. National Vulnerability Database. CVSS SIG experts evaluate these vulnerability types and encode their knowledge as constraint graphs; sets of graphs are then unifed using a voting algorithm. These unifed graphs represent sets of consistent scoring systems (mappings of vectors to scores). The consistent scoring system closest to the CVSS Version 3.1 scores was found, and the distance between the scores and the closest consistent scoring system scores was measured. These measurements represent the degree to which the CVSS v3.1 base score equation represents the CVSS SIG expert domain knowledge.	この研究は、CVSS基礎評点の式がCVSS SIG専門家のドメイン知識をどの程度反映しているかを測定し、測定値の再現可能な正当性を提供するものである。CVSS SIGのように実際の脆弱性の集合からではなく、米国の国家脆弱性データベースによって公開された脆弱性の90%を占める66種類の脆弱性（すなわちCVSSベクトル）の集合から出発している。CVSS SIGの専門家はこれらの脆弱性の種類を評価し、その知識を制約グラフとして符号化する。次に、グラフの集合は投票アルゴリズムを用いて単一化される。これらの統一されたグラフは、一貫した採点システム（ベクトルと評点の対応付け）の集合を表している。CVSS Version 3.1の評点に最も近い一貫した採点システムを見つけ、その評点と最も近い一貫した採点システムの評点との間の距離を測定した。これらの測定値は、CVSS v3.1の基礎評点式がCVSS SIG専門家のドメイン知識をどの程度表しているかを表している。
Using this approach, the mean and maximum distance of the CVSS v3.1 scores compared to the closest consistent scoring system scores were measured, and the acceptable deviation was recalculated. Unlike acceptable deviation, the new distance metrics measure the score values themselves separate from the severity levels. Using all 12 CVSS SIG inputs, the mean scoring distance is 0.13 points, the maximum scoring distance is 0.40 points, and the acceptable deviation is 0.20 points. Sets of 11 out of 12 of the inputs were used to calculate precision measurements (i.e., standard deviation).	この方法を用いて、最も近い一貫性のある採点システムの評点と比較したCVSS v3.1評点の平均距離と最大距離が測定され、許容偏差が再計算された。許容偏差とは異なり、新しい距離メトリックは、深刻度レベルとは別に評点値そのものを測定する。12のCVSS SIGインプットすべてを使用した場合、平均評点距離は0.13ポイント、最大評点距離は0.40ポイント、許容偏差は0.20ポイントとなった。12個の入力のうち11個の入力は、精度の測定（すなわち標準偏差）を計算するために使用された。
These fndings validate that the CVSS base score equation functions as described (to the extent described by these measurements), and it represents the encoded CVSS SIG domain knowledge. The measurements support the equation as defned. The security community may use it as an opaque box without understanding the internal functionality.	これらの結果は、CVSS基礎評点の式が（これらの測定値によって記述された範囲内で）記述されたとおりに機能し、符号化されたCVSS SIGドメイン知識を表していることを検証している。測定結果は、定義された方程式をサポートしている。セキュリティコミュニティは、内部機能を理解することなく、不透明な箱としてそれを使用することができる。

---

● まるちゃんの情報セキュリティ気まぐれ日記

・2022.11.17 CISA ステークホルダー別脆弱性分類 (SSVC) ガイド

・2022.06.11 NIST NISTIR 8409 (ドラフト) 共通脆弱性評点システムの基礎評点の計算式の測定

・2021.04.30 カーネギー大学 ソフトウェア工学研究所が「Stakeholder-Specific Vulnerability Categorization:SSVC 2.0」を発表していますね。。。

昔に遡り。。。

・2010.10.25 IPA 共通脆弱性評価システムCVSS概説

・2007.04.26 JVN は、名称をJP Vendor Status Notes (JVN) から、Japan Vulnerability Notes (JVN) と変更しました

CISA ステークホルダー別脆弱性分類 (SSVC) ガイド

こんにちは、丸山満彦です。

CISAがステークホルダー別脆弱性分類 (Stakeholder-Specific Vulnerability Categorization: SSVC) ガイドを公表していますね。。。

STAKEHOLDER-SPECIFIC VULNERABILITY CATEGORIZATION	ステークホルダー別脆弱性分類
Carnegie Mellon University's Software Engineering Institute (SEI), in collaboration with CISA, created the Stakeholder-Specific Vulnerability Categorization (SSVC) system in 2019 to provide the cyber community a vulnerability analysis methodology that accounts for a vulnerability's exploitation status, impacts to safety, and prevalence of the affected product in a singular system. CISA worked with SEI in 2020 to develop its own customized SSVC decision tree to examine vulnerabilities relevant to the United States government (USG), as well as state, local, tribal, and territorial (SLTT) governments, and critical infrastructure entities. Implementing SSVC has allowed CISA to better prioritize its vulnerability response and vulnerability messaging to the public.	カーネギーメロン大学のソフトウェア工学研究所（SEI）は、CISAと共同で、脆弱性の悪用状況、安全性への影響、単一システムにおける影響製品の普及率を考慮した脆弱性分析手法をサイバーコミュニティに提供するために、2019年に「ステークホルダー固有の脆弱性分類（SSVC）」システムを作成した。CISAは2020年にSEIと協力して、米国政府（USG）、州・地方・部族・準州（SLTT）政府、重要インフラ事業体に関連する脆弱性を調査するために、独自にカスタマイズしたSSVC決定木を開発した。SSVCの導入により、CISAは、脆弱性対応と一般市民への脆弱性メッセージの優先順位をより適切に設定できるようになった。
How CISA Uses SSVC	CISAはどのようにしてSSVCを使うのか？
CISA uses its own SSVC decision tree model to prioritize relevant vulnerabilities into four possible decisions:	CISAは、独自のSSVC決定木モデルを使用して、関連する脆弱性を4つの可能な判断に優先順位付けしている。
・Track: The vulnerability does not require action at this time. The organization would continue to track the vulnerability and reassess it if new information becomes available. CISA recommends remediating Track vulnerabilities within standard update timelines.	・追跡：この脆弱性は、現時点では対処する必要がない。組織は、脆弱性の追跡を継続し、新しい情報が入手できた場合に再評価を行いる。CISAでは、「追跡」の脆弱性を標準的な更新スケジュールで修正することを推奨している。
・Track*: The vulnerability contains specific characteristics that may require closer monitoring for changes. CISA recommends remediating Track* vulnerabilities within standard update timelines.	・追跡*：この脆弱性には特定の特性があり、その変化についてより綿密な監視が必要な場合がある。CISAでは、「追跡*」の脆弱性を標準的な更新スケジュールで修正することを推奨している。
・Attend: The vulnerability requires attention from the organization's internal, supervisory-level individuals. Necessary actions include requesting assistance or information about the vulnerability, and may involve publishing a notification either internally and/or externally. CISA recommends remediating Attend vulnerabilities sooner than standard update timelines.	・注意：この脆弱性は、組織内部の監督者レベルの個人による注意を必要とする。必要なアクションには、支援や脆弱性に関する情報の要求が含まれ、内部および/または外部への通知の公表を伴う場合がある。CISAでは、標準的な更新スケジュールよりも早く「注意」の脆弱性を修正することを推奨している。
・Act: The vulnerability requires attention from the organization's internal, supervisory-level and leadership-level individuals. Necessary actions include requesting assistance or information about the vulnerability, as well as publishing a notification either internally and/or externally. Typically, internal groups would meet to determine the overall response and then execute agreed upon actions. CISA recommends remediating Act vulnerabilities as soon as possible.	・対処：この脆弱性は、組織内部の監督者レベル、および指導者レベルの個人による注意を必要とする。必要なアクションには、脆弱性に関する支援や情報の要求、社内外への通知の公表などがある。通常、社内のグループは、全体的な対応策を決定するために会議を開き、合意した対応策を実行することになります。CISAは、「対処」の脆弱性をできるだけ早く是正することを推奨している。
The CISA SSVC tree determines the decisions of Track, Track*, Attend, and Act based on five values:	CISAのSSVC決定木は、5つの値に基づいて、追跡、追跡*、注意、対処を決定する。
・Exploitation status	・悪用状況
・Technical impact	・技術的影響
・Automatable	・自動化可能性
・Mission prevalence	・任務の普及性
・Public well-being impact	・公共福祉への影響
To learn more, see the CISA SSVC Guide (pdf, 948 kb).	詳細については、CISA SSVC Guide (pdf, 948 kb)を参照のこと。
CISA's SSVC Calculator	CISAのSSVC計算機
The CISA SSVC Calculator allows users to input decision values and navigate through the CISA SSVC tree model to the final overall decision for a vulnerability affecting their organization. The SSVC Calculator allows users to export the data as .PDF or JSON.	CISAのSSVC計算機を使用すると、ユーザーは意思決定値を入力し、CISAのSSVC決定木モデルを通じて、自分の組織に影響を与える脆弱性の最終的な総合意思決定に至るまでナビゲートすることができる。SSVC 計算機では、ユーザーはデータを.PDFまたはJSONとしてエクスポートすることができる。
Additional SSVC Decision Tree Models	追加のSSVC決定木モデル
Organizations whose mission spaces need to evaluate the effect of vulnerabilities in at least one external organization may find the CISA SSVC decision tree model helpful. The CISA SSVC decision tree model closely resembles the standard SSVC “Coordinator” tree. For organizations whose mission spaces do not align with CISA’s decision tree, the SEI whitepaper Prioritizing Vulnerability Response: A Stakeholder-Specific Vulnerability Categorization (Version 2.0) details other decision tree models that may better align to their mission space.	ミッション・スペースが少なくとも1つの外部組織の脆弱性の影響を評価する必要がある組織は、CISAのSSVC決定木モデルが役に立つかもしれません。CISA SSVC決定木モデルは、標準的なSSVCの「コーディネータ」木に酷似している。ミッション空間がCISAの決定木と一致しない組織については、SEIホワイトペーパー「Prioritizing Vulnerability Response: A Stakeholder-Specific Vulnerability Categorization (Version 2.0) は、組織のミッション空間に適した他の決定木モデルを詳細に説明している。

・2022.11 [PDF] CISA Stakeholder-Specific Vulnerability Categorization Guide

目次...

Overview	概要
The Vulnerability Scoring Decision	脆弱性スコアリングの決定
Relevant Decision Points	関連する判断ポイント
(State of) Exploitation	悪用状況
Technical Impact	技術的影響
Automatable	自動化可能性
Automating Reconnaissance and Vulnerability Chaining	偵察と脆弱性の連鎖の自動化
Mission Prevalence	任務の普及性
Public Well-Being Impact	公衆衛生への影響
Mitigation Status	緩和状況
Decision Tree	意思決定木

Exploitation status	悪用状況
Evidence of Active Exploitation of a Vulnerability	脆弱性を積極的に悪用した証拠
・None	・なし
・Public PoC	・公開PoC
・Active	・アクティブ
Technical impact	技術的影響
Technical Impact of Exploiting the Vulnerability	脆弱性を悪用した場合の技術的影響
・Partial	・部分的
・Total	・全体
Automatable	自動化可能性
・No	・No
・Yes	・Yes
Mission prevalence	任務の普及性
Impact on Mission Essential Functions of Relevant Entities	関連事業体のミッション・エッセンシャル機能への影響
・Minimal	・ミニマム
・Support	・サポート
・Essential	・必須
Public well-being impact	公共福祉への影響
Impacts of Affected System Compromise on Humans	被災したシステムの危殆化による人体への影響
・Minimal	・ミニマム
・Material	・重要
・Irreverslble	・不可逆的

ブログ...

・2022.11.10 TRANSFORMING THE VULNERABILITY MANAGEMENT LANDSCAPE

TRANSFORMING THE VULNERABILITY MANAGEMENT LANDSCAPE	脆弱性管理状況を変革する
By Eric Goldstein, Executive Assistant Director for Cybersecurity	エリック・ゴールドスタイン（サイバーセキュリティ担当エグゼクティブ・アシスタント・ディレクター）著
In the current risk environment, organizations of all sizes are challenged to manage the number and complexity of new vulnerabilities. Organizations with mature vulnerability management programs seek more efficient ways to triage and prioritize efforts. Smaller organizations struggle with understanding where to start and how to allocate limited resources. Fortunately, there is a path toward more efficient, automated, prioritized vulnerability management. Working with our partners across government and the private sector, we are excited to outline three critical steps to advance the vulnerability management ecosystem:	現在のリスク環境では、あらゆる規模の組織が、新たな脆弱性の数と複雑さを管理するという課題を抱えている。成熟した脆弱性管理プログラムを持つ組織は、取り組みの優先順位付けとトリアージに、より効率的な方法を求めている。一方、小規模な組織は、どこから手をつければよいのか、限られたリソースをどのように配分すればよいのかを理解するのに苦労している。幸いなことに、より効率的で自動化され、優先順位が付けられた脆弱性管理への道は開かれている。私たちは、政府機関や民間企業のパートナーとともに、脆弱性管理のエコシステムを前進させるための3つの重要なステップの概要を説明することができる。
・First, we must introduce greater automation into vulnerability management, including by expanding use of the Common Security Advisory Framework (CSAF)	・第一に、共通セキュリティ・アドバイザリー・フレームワーク　 (CSAF) の利用を拡大するなどして、脆弱性管理にさらなる自動化を導入する必要がある。
・Second, we must make it easier for organizations to understand whether a given product is impacted by a vulnerability through widespread adoption of Vulnerability Exploitability eXchange (VEX)	・第二に、VEX（Vulnerability Exploitability eXchange）の普及により、ある製品が脆弱性の影響を受けているかどうかを、組織がより簡単に理解できるようにする必要がある。
・Third, we must help organizations more effectively prioritize vulnerability management resources through use of Stakeholder Specific Vulnerability Categorization (SSVC), including prioritizing vulnerabilities on CISA’s Known Exploited Vulnerabilities (KEV) catalog	・第三に、CISAのKEV（Known Exploited Vulnerabilities）カタログにおける脆弱性の優先順位付けなど、ステークホルダー別脆弱性分類 (SSVC) を使用して、組織が脆弱性管理リソースの優先順位をより効果的に決定できるようにする必要がある。
With these advances, described further below, we will make necessary progress in vulnerability management and reduce the window that our adversaries have to exploit American networks.	以下に説明するこれらの進歩により、私たちは脆弱性管理において必要な進歩を遂げ、敵対者が米国のネットワークを悪用するための窓を減らすことができるだろう。
1. Achieving Automation: Publish machine-readable security advisories based on the Common Security Advisory Framework (CSAF).	1. 自動化の実現：共通セキュリティ・アドバイザリー・フレームワーク (CSAF) に基づいて、機械可読のセキュリティ勧告を発行する。
When a new vulnerability is identified, software vendors jump into action: understanding impacts to products, identifying remediations, and communicating to end users. But as we know, the clock is ticking: adversaries are often turning vulnerabilities to exploits within hours of initial public reports.	新しい脆弱性が特定されると、ソフトウェア・ベンダーは、製品への影響の把握、対処法の特定、エンドユーザーへの情報提供などの活動に飛びつく。しかし、ご存知のように、時間は刻々と過ぎていく。敵は、脆弱性を最初に公表してから数時間以内にエクスプロイト（悪用）に変えてしまうことがよくある。
Software vendors work constantly to understand if their products are impacted by a new vulnerability. To meet this timeframe, our community needs a standardized approach for vendors to disclose security vulnerabilities to end users in an accelerated and automated way.	ソフトウェアベンダーは、自社製品が新しい脆弱性の影響を受けているかどうかを把握するために常に努力している。この時間枠を満たすために、私たちのコミュニティは、ベンダーがエンドユーザーに対してセキュリティ脆弱性を迅速かつ自動的に開示するための標準的なアプローチを必要としている。
The CSAF, developed by the OASIS CSAF Technical Committee, is a standard for machine-readable security advisories. CSAF provides a standardized format for ingesting vulnerability advisory information and simplify triage and remediation processes for asset owners.  By publishing security advisories using CSAF, vendors will dramatically reduce the time required for enterprises to understand organizational impact and drive timely remediation.	OASIS CSAF 技術委員会が開発した CSAF は、機械可読なセキュリティアドバイザリの標準である。CSAF は、脆弱性アドバイザリ情報を取り込むための標準化されたフォーマットを提供し、資産所有者のトリアージと修復プロセスを簡素化する。  CSAF を使用してセキュリティアドバイザリを公開することで、ベンダーは、企業が組織の影響を理解し、タイムリーに修正を行うために必要な時間を大幅に短縮することができる。
2. Clarifying Impact: Use Vulnerability Exploitability eXchange (VEX) to communicate whether a product is affected by a vulnerability and enable prioritized vulnerability response	2. 影響の明確化：VEXを使用して、製品が脆弱性の影響を受けるかどうかを伝え、優先的に脆弱性に対応できるようにする。
VEX allows a vendor to assert whether specific vulnerabilities affect a product; a VEX advisory can also indicate that a product is not affected by a vulnerability. Not all vulnerabilities are exploitable and put an organization at risk. To help reduce effort spent by users investigating vulnerabilities, vendors can issue a VEX advisory that states whether a product is or is not affected by a specific vulnerability in a machine readable, automated way. VEX is implemented as a profile in CSAF and is one of its more popular use cases, aligning with the existing work supporting machine-readable advisories.	VEXにより、ベンダーは、特定の脆弱性が製品に影響を及ぼすかどうかを表明できる。VEXアドバイザリでは、製品が脆弱性の影響を受けないことを示すこともできる。すべての脆弱性が悪用され、組織を危険にさらすとは限らない。ユーザーが脆弱性を調査する労力を軽減するために、ベンダーは、製品が特定の脆弱性の影響を受けるかどうかを、機械的に読み取り可能な自動化された方法で表明するVEXアドバイザリを発行することができる。VEXは、CSAFのプロファイルとして実装されており、より一般的なユースケースの1つで、機械可読アドバイザリをサポートする既存の作業と連携している。
The ultimate goal of VEX is to support greater automation across the vulnerability ecosystem, including disclosure, vulnerability tracking, and remediation. VEX data can also support more effective use of software bill of materials (SBOM) data. An SBOM is a machine-readable, comprehensive inventory of software components and dependencies. Machine-readable VEX documents support linking to an SBOM and specific SBOM components. While SBOM gives an organization information on where they are potentially at risk, a VEX document helps an organization find out where they are actually affected by known vulnerabilities, and if actions need to be taken to remediate based on exploitation status.	VEX の最終的な目標は、情報開示、脆弱性追跡、修正など、脆弱性エコシステム全体の自動化を促進することである。VEXデータは、ソフトウェア部品表（SBOM）データのより効果的な利用もサポートすることができる。SBOMは、ソフトウェアコンポーネントと依存関係の機械読み取り可能な包括的インベントリである。機械読み取り可能なVEX文書は、SBOMおよび特定のSBOMコンポーネントへのリンクをサポートする。SBOMは、組織が潜在的なリスクを抱えている場所に関する情報を提供するが、VEX文書は、組織が既知の脆弱性の影響を実際に受けている場所と、悪用状況に基づいて是正するために行動を起こす必要があるかどうかを確認するのに役立つ。
3. Prioritized Based on Organizational Attributes: Use vulnerability management frameworks, such as Stakeholder-Specific Vulnerability Categorization (SSVC), which utilize exploitation status and other vulnerability data to help prioritize remediation efforts.	3. 組織属性に基づく優先順位付け：ステークホルダー別脆弱性分類 (SSVC) などの脆弱性管理のフレームワークを使用し、悪用状況やその他の脆弱性データを活用して、是正措置の優先順位付けを支援する。
Last year, CISA issued Binding Operational Directive (BOD) 22-01, which directs federal civilian agencies to remediate KEVs and encourages all organizations to implement the KEV catalog into their vulnerability management framework. The first publication of KEV vulnerabilities derived from CISA's use of SSVC which occurred on November 3, 2021.	昨年、CISA は拘束的運用指令（BOD）22-01 を発行し、連邦政府文民機関に KEV の是正を指示するとともに、すべての組織に KEV カタログを脆弱性管理の枠組みに導入するよう奨励しました。2021年11月3日に発生したCISAのSSVCの利用に由来するKEV脆弱性の最初の公表は、このようなものであった。
CISA encourages every organization to use a vulnerability management framework that considers a vulnerability’s exploitation status, such as SSVC.	CISAは、すべての組織がSSVCのような脆弱性の悪用状況を考慮した脆弱性管理のフレームワークを使用することを推奨している。
To assist organizations with using SSVC, today, CISA released:	SSVCを利用する組織を支援するため、本日、CISAは以下を公開しました。
・An SSVC webpage introducing CISA's SSVC decision tree;	・CISAのSSVC決定木を紹介するSSVCウェブページ。
・The CISA SSVC Guide instructing how to use the scoring decision tree; and	・スコアリング決定木の使用方法を説明した「CISA SSVCガイド」、および
・The CISA SSVC Calculator for evaluating how to prioritize vulnerability responses in an organization’s respective environment.	・CISA SSVC計算機は、組織の環境における脆弱性対応の優先順位を評価するためのものである。
Organizations now have the option to use CISA’s customized SSVC decision tree guide to prioritize a known vulnerability based on an assessment of five decision points, which are (1) exploitation status, (2) technical impact, (3) automatability, (4) mission prevalence, and (5) public well-being impact. Based on reasonable assumptions for each decision point, a vulnerability will be categorized either as Track, Track*, Attend, or Act. A description of each decision and value can be found on CISA’s new SSVC webpage.	組織は、CISAのカスタマイズされたSSVC決定木ガイドを使用して、5つの決定ポイント（(1) 悪用状況 (2) 技術的影響 (3) 自動化可能性 (4) 任務の普及性 (5) 公共福祉への影響）の評価に基づいて、既知の脆弱性の優先度を決定できるようになった。各決定ポイントの合理的な仮定に基づき、脆弱性は「追跡」「追跡*」「注意」「対処」のいずれかに分類される。各判断と数値の説明は、CISAの新しいSSVCウェブページで見ることができる。
As we collectively work to advance vulnerability management practices, we want to hear from you. Please send any feedback or questions to "Mail"	我々は、脆弱性管理の実践を推進するために、皆様からの意見を待っている。フィードバックや質問は、"Mail" まで。

---

関連...

● まるちゃんの情報セキュリティ気まぐれ日記

・2022.06.11 NIST NISTIR 8409 (ドラフト) 共通脆弱性評点システムの基礎評点の計算式の測定

・2021.04.30 カーネギー大学 ソフトウェア工学研究所が「Stakeholder-Specific Vulnerability Categorization:SSVC 2.0」を発表していますね。。。

昔に遡り。。。

・2010.10.25 IPA 共通脆弱性評価システムCVSS概説

・2007.04.26 JVN は、名称をJP Vendor Status Notes (JVN) から、Japan Vulnerability Notes (JVN) と変更しました

米国 CISA 拘束的運用指令23-01 - 連邦ネットワークにおける資産の可視化と脆弱性検出の改善

こんにちは、丸山満彦です。

CISAが、連邦政府機関にサイバーセキュリティ資産の可視化と脆弱性検出の改善のために、「拘束的運用指令23-01 - 連邦ネットワークにおける資産の可視化と脆弱性検出の改善」を発出していますね。。。

SBOMの前提としての作業という位置づけですかね。。。

対象は例によって、連邦文民行政機関 (Federal Civilian Executive Branch: FCEB) のシステムで米軍のシステムや情報機関のシステムは基本は対象外ですね。。。

● Cybeersecurity & Ingrastructure Security Agency: CISA 

・2022.10.03 CISA DIRECTS FEDERAL AGENCIES TO IMPROVE CYBERSECURITY ASSET VISIBILITY AND VULNERABILITY DETECTION

CISA DIRECTS FEDERAL AGENCIES TO IMPROVE CYBERSECURITY ASSET VISIBILITY AND VULNERABILITY DETECTION	CISA、連邦政府機関にサイバーセキュリティ資産の可視化と脆弱性検出の改善を指示
New Binding Operational Directive Establishes Core Actions to Achieve Operational Visibility Throughout Federal Civilian Executive Branch	新しい拘束的運用指令は、連邦文民行政機関全体で運用の可視性を達成するための中核的な行動を確立する
WASHINGTON – The Cybersecurity and Infrastructure Security Agency (CISA) issued today Binding Operational Directive (BOD) 23-01, Improving Asset Visibility and Vulnerability Detection on Federal Networks, that directs federal civilian agencies to better account for what resides on their networks.	ワシントン - サイバーセキュリティおよびインフラセキュリティ局（CISA）は本日、拘束的運用指令（BOD）23-01「連邦ネットワークにおける資産の可視化と脆弱性検出の改善」を発行し、連邦民間機関に対して、ネットワーク上に存在するものをより適切に説明するように指示した。
Over the past several years, CISA has been working urgently to gain greater visibility into risks facing federal civilian networks, a gap made clear by the intrusion campaign targeting SolarWinds devices. The Biden-Harris Administration and Congress have supported significant progress by providing key authorities and resources. This Directive takes the next step by establishing baseline requirements for all Federal Civilian Executive Branch (FCEB) agencies to identify assets and vulnerabilities on their networks and provide data to CISA on defined intervals.	過去数年間、CISAは連邦政府民間ネットワークが直面するリスクの可視性を高めるために緊急に取り組んできたが、SolarWindsのデバイスを標的とした侵入キャンペーンによってそのギャップが明らかになった。バイデン＝ハリス政権と議会は、重要な権限とリソースを提供することにより、大きな進展を支援してきた。この指令は、次のステップとして、すべての連邦文民行政機関（FCEB）に対して、そのネットワーク上の資産と脆弱性を特定し、定められた間隔でCISAにデータを提供する基本要件を確立するものである。
“Threat actors continue to target our nation’s critical infrastructure and government networks to exploit weaknesses within unknown, unprotected, or under-protected assets,” said CISA Director Jen Easterly. “Knowing what’s on your network is the first step for any organization to reduce risk. While this Directive applies to federal civilian agencies, we urge all organizations to adopt the guidance in this directive to gain a complete understanding of vulnerabilities that may exist on their networks. We all have a role to play in building a more cyber resilient nation.”	CISA長官のJen Easterlyは次のように述べている。「脅威者は、未知の、保護されていない、または保護されていない資産の弱点を突くために、我が国の重要なインフラと政府ネットワークをターゲットにし続けている。ネットワーク上に何があるのかを知ることは、どのような組織にとってもリスクを減らすための最初のステップである。この指令は連邦政府民間機関に適用されるが、すべての組織がこの指令のガイダンスを採用し、ネットワークに存在する可能性のある脆弱性を完全に理解することを強く勧める。私たちは皆、よりサイバーレジリエンスの高い国家を築くために果たすべき役割を担っている。」
CISA is committed to using its cybersecurity authorities to gain greater visibility and drive timely risk reduction across federal civilian agencies. Implementation of this Directive will significantly increase visibility into assets and vulnerabilities across the federal government, in turn improving capabilities by both CISA and each agency to detect, prevent, and respond to cybersecurity incidents and better understand trends in cybersecurity risk.	CISAは、サイバーセキュリティの権限を用いて、連邦文民行政機関全体でより大きな可視性を獲得し、タイムリーなリスク削減を推進することを約束する。この指令の実施により、連邦政府全体の資産と脆弱性に対する可視性が大幅に向上し、その結果、CISAと各機関の両方によるサイバーセキュリティ事件の検出、防止、対応能力が向上し、サイバーセキュリティリスクの傾向がよりよく理解されるようになる。
This Directive is a mandate for federal civilian agencies. However, CISA recommends that private businesses and state, local, tribal and territorial (SLTT) governments review it and prioritize implementation of rigorous asset and vulnerability management programs.	この指令は、連邦文民行政機関に義務付けられている。しかし、CISAは、民間企業や州・地方・部族・準州（SLTT）政府がこれを見直し、厳格な資産および脆弱性管理プログラムの実施を優先させることを推奨している。
The new Directive can be found at Binding Operational Directive (BOD) 23-01.	新指令は、拘束的運用指令（BOD）23-01に掲載されている。

拘束的運用規則...

・2022.10.03 BINDING OPERATIONAL DIRECTIVE 23-01 - IMPROVING ASSET VISIBILITY AND VULNERABILITY DETECTION ON FEDERAL NETWORKS

BINDING OPERATIONAL DIRECTIVE 23-01 - IMPROVING ASSET VISIBILITY AND VULNERABILITY DETECTION ON FEDERAL NETWORKS	拘束的運用指令23-01 - 連邦ネットワークにおける資産の可視化と脆弱性検出の改善
A binding operational directive is a compulsory direction to federal, executive branch, departments and agencies for purposes of safeguarding federal information and information systems. 44 U.S.C. § 3552(b)(1). Section 3553(b)(2) of title 44, U.S. Code, authorizes the Secretary of the Department of Homeland Security (DHS) to develop and oversee the implementation of binding operational directives. Federal agencies are required to comply with these directives. 44 U.S.C. § 3554(a)(1)(B)(ii). These directives do not apply to statutorily defined “national security systems” or to certain systems operated by the Department of Defense or the Intelligence Community. 44 U.S.C. § 3553(b), (d), (e)(2), (e)(3). This directive refers to the systems to which it applies as “Federal Civilian Executive Branch” systems, and to agencies operating those systems as “Federal Civilian Executive Branch” agencies.	拘束的運用指令とは、連邦政府の情報および情報システムを保護する目的で、連邦、行政府、機関に対する強制的な指示である。 44 U.S.C. § 3552(b)(1)。 合衆国法典第 44 編第 3553 条(b)(2)は、国土安全保障省（DHS）の長官に拘束的運用指令 を策定し、その実施を監督する権限を与えるものである。連邦機関は、これらの指令に従うことを要求される。 44 U.S.C. § 3554(a)(1)(B)(ii). これらの指令は、法令で定義された「国家安全保障システム」、または国防総省もしくは情報機関によって運用される特定のシステムには適用されない。 44 U.S.C. § 3553(b), (d), (e)(2), (e)(3)。 この指令は、適用されるシステムを「連邦文民行政機関システム」と呼び、それらのシステムを運用する機関を「連邦文民行政機関」と呼ぶ。
Background	背景
Continuous and comprehensive asset visibility is a basic pre-condition for any organization to effectively manage cybersecurity risk. Accurate and up-to-date accounting of assets residing on federal networks is also critical for CISA to effectively manage cybersecurity for the Federal Civilian Executive Branch (FCEB) enterprise.	継続的かつ包括的な資産の可視化は、あらゆる組織がサイバーセキュリティリスクを効果的に管理するための基本的な前提条件である。また、連邦ネットワーク上に存在する資産の正確かつ最新の会計処理は、CISAが連邦文民行政機関（FCEB）エンタープライズのサイバーセキュリティを効果的に管理するために不可欠である。
The purpose of this Binding Operational Directive is to make measurable progress toward enhancing visibility into agency assets and associated vulnerabilities. While the requirements in this Directive are not sufficient for comprehensive, modern cyber defense operations, they are an important step to address current visibility challenges at the component, agency, and FCEB enterprise level. The requirements of this Directive focus on two core activities essential to improving operational visibility for a successful cybersecurity program: asset discovery and vulnerability enumeration.	この拘束的運用指令の目的は、機関の資産と関連する脆弱性に対する可視性の強化に向けて、測定可能な進歩を遂げることである。本指令の要件は、包括的で近代的なサイバー防衛作戦には不十分であるが、部局、機関、および FCEB エンタープライズレベルにおける可視性の現在の課題に対処するための重要なステップである。本指令の要件は、サイバーセキュリティプログラムを成功させるために運用の可視性を向上させるために不可欠な2つの中核的活動、すなわち資産の発見と脆弱性一覧に焦点を当てている。
・Asset discovery is a building block of operational visibility, and it is defined as an activity through which an organization identifies what network addressable IP-assets reside on their networks and identifies the associated IP addresses (hosts). Asset discovery is non-intrusive and usually does not require special logical access privileges.	・資産の発見とは、運用の可視性の構成要素であり、組織がネットワーク上に存在するネットワークアドレス可能なIP資産を識別し、関連するIPアドレス（ホスト）を識別する活動として定義される。資産発見は非侵入型であり、通常、特別な論理的アクセス権限を必要としない。
・Vulnerability enumeration identifies and reports suspected vulnerabilities on those assets. It detects host attributes (e.g., operating systems, applications, open ports, etc.), and attempts to identify outdated software versions, missing updates, and misconfigurations. It validates compliance with or deviations from security policies by identifying host attributes and matching them with information on known vulnerabilities. Understanding an asset’s vulnerability posture is dependent on having appropriate privileges, which can be achieved through credentialed network-based scans or a client installed on the host endpoint.	・脆弱性一覧は、これらの資産に存在する脆弱性の疑いを特定し、報告する。ホストの属性（OS、アプリケーション、オープンポートなど）を検出し、古いソフトウェアバージョン、アップデートの欠落、設定の誤りなどを特定しようとするものである。ホストの属性を特定し、既知の脆弱性に関する情報と照合することで、セキュリティポリシーへの準拠や逸脱を検証する。資産の脆弱性ポスチャを理解するには、適切な権限が必要である。この権限は、資格のあるネットワークベースのスキャンや、ホストのエンドポイントにインストールされたクライアントによって実現される場合がある。
Discovery of assets and vulnerabilities can be achieved through a variety of means, including active scanning, passive flow monitoring, querying logs, or in the case of software defined infrastructure, API query. Many agencies’ existing Continuous Diagnostics and Mitigation (CDM) implementations leverage such means to make progress toward intended levels of visibility. Asset visibility is not an end in itself, but is necessary for updates, configuration management, and other security and lifecycle management activities that significantly reduce cybersecurity risk, along with exigent activities like vulnerability remediation. The goal of this Directive is for agencies to comprehensively achieve the following outcomes without prescribing how to do so:	資産と脆弱性の発見は、アクティブスキャン、パッシブフローモニタリング、ログへのクエリ、またはソフトウェア定義インフラの場合はAPIクエリなど、さまざまな手段で行うことができる。多くの機関の既存の継続的診断・軽減（CDM）実装では、このような手段を活用して、意図したレベルの可視化に向けて前進している。資産の可視化はそれ自体が目的ではなく、脆弱性修正のような緊急の活動とともに、アップデート、構成管理、その他のセキュリティおよびライフサイクルマネジメントの活動によって、サイバーセキュリティのリスクを大幅に軽減するために必要なものである。本指令の目標は、各機関が以下の成果を包括的に達成することであり、その方法を規定するものではない。
・Maintain an up-to-date inventory of networked assets as defined in the scope of this directive;	・本指令の適用範囲に定義されるネットワーク資産の最新のインベントリを維持する。
・Identify software vulnerabilities, using privileged or client-based means where technically feasible;	・技術的に可能な場合、特権的またはクライアントベースの手段を用いて、ソフトウェアの脆弱性を特定する。
・Track how often the agency enumerates its assets, what coverage of its assets it achieves, and how current its vulnerability signatures are; and	・技術的に可能な場合は、特権的またはクライアントベースの手段を使用して、ソフトウェアの脆弱性を特定する。
・Provide asset and vulnerability information to CISA’s CDM Federal Dashboard.	・CISAのCDM Federal Dashboardに資産と脆弱性の情報を提供する。
Agencies may request CISA’s assistance in conducting an engineering survey to baseline current asset management capabilities. CISA will work with requesting agencies to provide technical and program assistance to resolve gaps, optimize scanning, and support achieving the required actions in this Directive.	各機関は、現在の資産管理能力を基準化するためのエンジニアリング・サーベイの実施においてCISAの支援を要請することができる。CISAは、要請した機関と協力して、ギャップを解決し、スキャニングを最適化し、本指令の要求事項の達成を支援するための技術的及びプログラム的支援を提供する。
This Directive’s requirements advance the priorities set forth in the Executive Order 14028 on Improving the Nation’s Cybersecurity, specifically Sec. 7 (Improving Detection of Cybersecurity Vulnerabilities and Incidents on Federal Government Networks), and provide operational clarity in achieving policy set forth in previous OMB Memoranda, including M-21-02, M-22-05, and M-22-09. Compliance with this Directive also supports BOD 22-01, Managing Unacceptable Risk Vulnerabilities in Federal Enterprise, as it will enable agencies to enhance the management of known exploited vulnerabilities that can be detected using automated tools.	本指令の要件は、国家のサイバーセキュリティの改善に関する大統領令14028、特に第7項（連邦政府ネットワークにおけるサイバーセキュリティの脆弱性とインシデントの検出の改善）で定められた優先事項を促進し、M-21-02、M-22-05、M-22-09などの以前のOMBメモランダムで定められた政策の達成に運用上の明確さを提供するものである。また、本指令を遵守することにより、BOD 22-01「連邦エンタープライズにおける許容できないリスクの脆弱性管理」をサポートし、自動化ツールを使用して検出可能な既知の悪用される脆弱性の管理を強化することが可能になるためである。
Scope	適用範囲
These required actions apply to any FCEB unclassified federal information system, including any federal information system used or operated by another entity on behalf of an agency, that collects, processes, stores, transmits, disseminates, or otherwise maintains agency information.	これらの要求事項は、FCEBの非分類連邦情報システム（機関に代わって他の機関が使用または運用する連邦情報システムを含み、機関情報を収集、処理、保存、伝送、配布、または維持するもの）に適用される。
This Directive applies to all IP-addressable networked assets that can be reached over IPv4 and IPv6 protocols. For the purpose of this directive, an IP-addressable networked asset is defined as any reportable (i.e., non-ephemeral) information technology or operational technology asset that is assigned an IPv4 or IPv6 address and accessible over IPv4 or IPv6 networks, regardless of the environment it operates in. The scope includes, but is not limited to, servers and workstations, virtual machines, routers and switches, firewalls, network appliances, and network printers — whether in on-premises, roaming, and cloud operated deployment models. The scope excludes ephemeral assets, such as containers and third-party-managed software as a service (SaaS) solutions.	この指令は、IPv4及びIPv6プロトコルを介して到達可能な、IPアドレス指定可能な全てのネットワーク資産に適用される。 この指令の目的上、IPアドレス指定可能なネットワーク資産とは、IPv4またはIPv6アドレスが割り当てられ、IPv4またはIPv6ネットワーク上でアクセスできる、報告可能（すなわち、非エフェメラル）な情報技術または運用技術資産と定義し、その運用環境を問わないものとする。この範囲には、オンプレミス、ローミング、クラウドのいずれの展開モデルであっても、サーバー、ワークステーション、仮想マシン、ルーター、スイッチ、ファイアウォール、ネットワーク機器、ネットワークプリンターが含まれるが、これらに限定されるものではない。コンテナやサードパーティが管理するSaaSソリューションなどの一時的な資産は対象外とする。
Required Actions	要求される対応
1. By April 3, 2023, all FCEB agencies are required to take the following actions on all federal information systems in scope of this directive:	1. 2023年4月3日までに、すべてのFCEB機関は、この指令の対象となるすべての連邦情報システムにおいて、以下の措置を講じることが求められる。
a. Perform automated asset discovery every 7 days. While many methods and technologies can be used to accomplish this task, at minimum this discovery must cover the entire IPv4 space used by the agency.	a. 7日ごとに自動資産探索を実施する。このタスクを達成するために多くの方法と技術を使用することができるが、最低限、この発見は、機関が使用するIPv4空間全体をカバーする必要がある。
b. Initiate vulnerability enumeration across all discovered assets, including all discovered nomadic/roaming devices (e.g., laptops), every 14 days.	b. 発見されたすべての資産（発見されたノマディック／ローミングデバイス（例：ラップトップ）を含む）に対して、14日ごとに脆弱性一覧を開始すること。
i. CISA understands that in some instances achieving full vulnerability discovery on the entire enterprise may not complete in 14 days. Enumeration processes should still be initiated at regular intervals to ensure all systems within the enterprise are scanned on a regular cadence within this window.	i. CISAは、エンタープライズ全体の完全な脆弱性の発見が14日間で完了しない場合があることを理解している。エンタープライズ内の全システムがこの期間内に定期的にスキャンされるように、列挙プロセスを定期的に開始する必要がある。
ii. To the maximum extent possible and where available technologies support it, all vulnerability enumeration performed on managed endpoints (e.g., servers, workstations, desktops, laptops) and managed network devices (e.g., routers, switches, firewalls) must be conducted with privileged credentials (for the purpose of this directive, both network-based credentialed scans and client- or agent-based vulnerability detection methods are viewed as meeting this requirement).	ii. 可能な限り最大限、利用可能な技術でサポートする場合、管理対象エンドポイント（例：サーバー、ワークステー ション、デスクトップ、ラップトップ）および管理対象ネットワークデバイス（例：ルーター、スイッチ、 ファイアウォール）に対して実施するすべての脆弱性一覧は、特権的資格情報を使用して実施しなければ ならない（この指令では、ネットワークベースの資格情報スキャンおよびクライアントまたはエージェント ベースの脆弱性検出方法の両方を、この要件を満たすものと見なす）。
iii. All vulnerability detection signatures used must be updated at an interval no greater than 24 hours from the last vendor-released signature update.	iii. 使用するすべての脆弱性検出シグネチャは、ベンダーがリリースした最後のシグネチャ更新から24時間を超えない間隔で更新されなければならない。
iv. Where the capability is available, agencies must perform the same type of vulnerability enumeration on mobile devices (e.g., iOS and Android) and other devices that reside outside of agency on-premises networks.	iv. 機能が利用可能な場合、機関は、モバイルデバイス（iOSおよびAndroidなど）および機関のオンプレミスネットワークの外に存在するその他のデバイスに対して、同じタイプの脆弱性一覧を実行しなければならない。
v. All alternative asset discovery and vulnerability enumeration methods (e.g., for systems with specialized equipment or those unable to utilize privileged credentials) must be approved by CISA.	v. すべての代替的な資産発見及び脆弱性一覧方法（例えば、特殊な機器を有するシステムや特権的な認証情報を利用できないシステムなど）は、CISAによって承認されなければならない。
c. Initiate automated ingestion of vulnerability enumeration results (i.e., detected vulnerabilities) into the CDM Agency Dashboard within 72 hours of discovery completion (or initiation of a new discovery cycle if previous full discovery has not been completed).	c. 発見完了後 72 時間以内に、脆弱性一覧結果（検出された脆弱性）の CDM Agency Dashboard への自動取り込みを開始する（または、以前の完全な発見が完了していない場合は、新しい発見サイクルを開始する）。
d. Develop and maintain the operational capability to initiate on-demand asset discovery and vulnerability enumeration to identify specific assets or subsets of vulnerabilities within 72 hours of receiving a request from CISA and provide the available results to CISA within 7 days of request.	d. CISAからの要請を受けてから72時間以内に、特定の資産または脆弱性のサブセットを特定するためのオンデマンドの資産発見と脆弱性一覧を開始し、要請から7日以内に利用可能な結果をCISAに提供する運用能力を開発し維持する。
i. CISA understands that in some instances agencies may not be able to complete a full vulnerability discovery on the entire enterprise within this period. It is still necessary to initiate the enumeration process within this time period as any available results will provide CISA and agencies situational awareness in response to imminent threats.	i. CISAは、場合によっては、機関がこの期間内にエンタープライズ全体の完全な脆弱性発見を完了できないことがあることを理解している。利用可能な結果があれば、差し迫った脅威に対応するためのCISA及び機関の状況認識が得られるため、この期間内に列挙プロセスを開始することが依然として必要である。
2. Within 6 months of CISA publishing requirements for vulnerability enumeration performance data, all FCEB agencies are required to initiate the collection and reporting of vulnerability enumeration performance data, as relevant to this directive, to the CDM Dashboard. This data will allow for CISA to automate oversight and monitoring of agency scanning performance including the measurement of scanning cadence, rigor, and completeness.	2. CISAが脆弱性一覧パフォーマンスデータの要件を公表してから6カ月以内に、すべてのFCEB機関は、この指令に関連する脆弱性一覧パフォーマンスデータの収集と報告をCDMダッシュボードに開始することが求められる。このデータにより、CISAはスキャニングの定時性、厳密性、完全性の測定を含む機関のスキャニング性能の監督と監視を自動化することができるようになる。
3. By April 3, 2023, agencies and CISA, through the CDM program, will deploy an updated CDM Dashboard configuration that enables access to object-level vulnerability enumeration data for CISA analysts, as authorized in the Executive Order on Improving the Nation’s Cybersecurity.	3. 2023年4月3日までに、各機関とCISAは、CDMプログラムを通じて、「国家のサイバーセキュリティの改善に関する行政命令」で認められた、CISAアナリストがオブジェクトレベルの脆弱性一覧データにアクセスできる最新のCDMダッシュボード構成を配備する予定である。
Reporting Requirements and Metrics	報告要件と測定基準
1. Six, twelve, and eighteen months after the issuance, FCEB agencies will either:	1. 発行から6ヶ月後、12ヶ月後、18ヶ月後、FCEB機関は以下のいずれかを行う。
(1) Provide CISA (through a reporting interface in CyberScope) a progress report to include any obstacles, dependencies, or other issues that may prevent them from meeting the directive requirements and expected completion dates, OR	(1) CISA（CyberScopeの報告インターフェースを通じて）に対し、指令の要件を満たすことを妨げる可能性のある障害、依存関係、その他の問題、および完了予定日を含む進捗報告書を提出する。
(2) Work with CISA through the CDM program review process outlined in OMB M-22-05, or superseding guidance, to identify and resolve gaps or issues that prevent full operationalization of asset management capabilities, including those requirements in this directive.	(2) OMB M-22-05又はそれに代わるガイダンスに概説されているCDMプログラム・レビュープロセスを通じてCISAと協力し、本指令の要件を含む資産管理能力の完全運用を妨げるギャップ又は問題を特定し、解決する。
CISA Actions	CISAの対応
1. Within 6 months of issuance, CISA will publish data requirements for agencies to provide machine-level vulnerability enumeration performance data in a common data schema.	1. CISAは、発行から6カ月以内に、各機関が機械レベルの脆弱性一覧パフォーマンスデータを共通のデータスキーマで提供するためのデータ要件を公開する予定である。
2. Within 18 months of issuance, CISA will review this directive to ensure the requirements remain relevant to the cybersecurity landscape.	2. CISAは、発行から18カ月以内に、本指令を見直し、要件がサイバーセキュリティの状況に引き続き適合していることを確認する。
3. Annually, by the end of each fiscal year, CISA will provide a status report to the Secretary of Homeland Security, the Director of OMB, and the National Cyber Director identifying cross-agency status, agency asset discovery and vulnerability management performance indicators, and outstanding issues in implementation of this Directive (scanning performance monitoring data, including the measurement of scanning cadence, rigor, and completeness). Additionally, CISA will report quarterly progress to OMB.	3. CISAは、毎年、各会計年度末までに、国土安全保障長官、OMB長官、及び国家サイバー長官に対して、機関間の状況、機関の資産発見及び脆弱性管理のパフォーマンス指標、並びに本指令の実施における未解決の問題（スキャンの定時性、厳格性、完全性の測定を含む、スキャンパフォーマンスモニタリングデータ）を特定する状況報告書を提出する。さらに、CISA は、四半期ごとに OMB に進捗状況を報告する。
4. CISA will monitor agency compliance with this Directive and will provide assistance upon request to support agency implementation.	4. CISAは、機関が本指令を遵守していることを監視し、機関の実施を支援するために要求に応じて支援を提供する。
Implementation Guidance	実施ガイダンス
The purpose of the Implementation Guidance document is to help federal agencies interpret and implement CISA’s Binding Operational Directive (BOD) 23-01. While the primary audience for this document is Federal Civilian Executive Branch (FCEB) agencies, other entities may find the content useful. At a minimum, CISA expects FCEB agencies to meet or exceed the guidance in this document. The guidance seeks to answer the most common questions asked by federal agencies. CISA will update this document with commonly asked questions and as new information becomes available.	実施ガイダンスの目的は、連邦政府機関がCISAの拘束的運用指令（BOD）23-01を解釈し実施するのを支援することである。この文書の主な対象者は連邦文民行政機関（FCEB）であるが、他の機関もこの内容を有用と考えるかもしれない。CISAは、少なくとも連邦文民行政機関が本書のガイダンスを満たすか、それを上回ることを期待している。このガイダンスは、連邦政府機関から寄せられる最も一般的な質問に答えようとするものである。CISAは、よくある質問や新しい情報が入手可能になったときに、この文書を更新する予定である。

実施ガイドライン... 用語定義とFAQですね...

・2022.10.03 IMPLEMENTATION GUIDANCE FOR CISA BINDING OPERATIONAL DIRECTIVE 23-01: IMPROVING ASSET VISIBILITY AND VULNERABILITY DETECTION ON FEDERAL NETWORKS

IMPLEMENTATION GUIDANCE FOR CISA BINDING OPERATIONAL DIRECTIVE 23-01: IMPROVING ASSET VISIBILITY AND VULNERABILITY DETECTION ON FEDERAL NETWORKS	CISA拘束的運用指令23-01の実施ガイダンス：連邦政府のネットワークにおける資産の可視化と脆弱性の検出の改善
The purpose of this document is to help federal agencies interpret and implement CISA’s Binding Operational Directive (BOD) 23-01. While the primary audience for this document is Federal Civilian Executive Branch (FCEB) agencies, other entities may find the content useful. At a minimum, CISA expects FCEB agencies to meet or exceed the guidance in this document. The guidance seeks to answer the most common questions asked by federal agencies. CISA will update this document with commonly asked questions and as new information becomes available.	この文書の目的は、連邦政府機関がCISAの拘束的運用指令（BOD）23-01を解釈し、実施するのを支援することである。この文書の主な対象者は連邦政府文民行政機関（FCEB）であるが、他の機関もこの内容を有用と考えるかもしれない。CISAは、少なくとも連邦政府文民行政機関が本書のガイダンスを満たすか、それを上回ることを期待している。このガイダンスは、連邦政府機関から寄せられる最も一般的な質問に答えようとするものである。CISAは、よくある質問や新しい情報が入手可能になったときに、この文書を更新する予定である。
Glossary	用語集
Vulnerability enumeration performance data – Otherwise referred to as scanning logs, vulnerability enumeration performance data describes datapoints or measurements that provide visibility on the level of performance relative to the requirements in this directive, using automation and machine-level data (e.g., logs/events indicating successful credentialed enumeration completion, date/timestamps surrounding enumeration activities, and signature/plug-in update date/timestamps). Data requirements to satisfy this objective will be published in a common data schema and made available to every Federal agency.	脆弱性一覧パフォーマンスデータ - スキャンログとも呼ばれる脆弱性一覧パフォーマンスデータは、自動化およびマシンレベルのデータ（例：認証された列挙の成功を示すログ/イベント、列挙活動に関する日付/タイムスタンプ、署名/プラグイン更新日付/タイムスタンプ）を使用して、この指令の要件に対するパフォーマンスのレベルを可視化するデータポイントまたは測定値について説明する。この目的を満たすためのデータ要件は、共通のデータ・スキーマで公開され、すべての連邦機関が利用できるようにする予定である。
Vulnerability enumeration – A technique to list host attributes (e.g., operating systems, applications, and open ports) and associated vulnerabilities. Vulnerability enumeration typically requires privileged access to gain full visibility at the application and configuration levels.	脆弱性一覧 - ホストの属性（オペレーティングシステム、アプリケーション、オープンポートなど） と関連する脆弱性をリストアップする技術。脆弱性一覧は、通常、アプリケーションおよび構成レベルで完全な可視性を得るために、特権的なアクセス を必要とする。
Privileged credentials – A local or network account or a process with sufficient access to enumerate system configurations and software components across an entire asset. Administrators must apply the principle of least privilege and/or separation of duties on the accounts used for vulnerability enumeration. Poisoning and machine-in-the-middle type attacks commonly target accounts with elevated privileges, including those used for vulnerability enumeration.	特権資格情報 - 資産全体のシステム構成とソフトウェアコンポーネントを列挙するために十分なアクセス権を持つローカルまたはネットワークアカウント、またはプロセス。管理者は、脆弱性一覧に使用するアカウントに最小特権の原則および/または職務分離の原則を適用する必要がある。ポイズニングおよびマシン・イン・ザ・ミドル型の攻撃は、脆弱性一覧に使用されるアカウントを含め、通常、昇格した特権を持つアカウントを標的としている。
Roaming devices – Devices that leave an agency’s on-premises networks, connect to other private networks, and directly access the public internet.	ローミングデバイス - 機関のオンプレミスネットワークを離れ、他のプライベートネットワークに接続し、公衆インターネットに直接アクセスするデバイス。
Nomadic devices – Devices that permanently reside outside of agency networks.	ノマディックデバイス – 機関内ネットワークの外に常時存在するデバイス。
Frequently Asked Questions	よくある質問
Q: What is the scope of this directive? Which devices specifically need to be scanned?	Q: この指令の対象は何であるか？具体的にどのデバイスをスキャンする必要があるか？
A: This directive applies to all IP-addressable networked assets that can be reached over IPv4 and IPv6 protocols. An IP-addressable networked asset is defined as any reportable (i.e., non-ephemeral) information technology or operational technology asset that is assigned an IPv4 or IPv6 address and accessible over IPv4 or IPv6 networks, regardless of the environment in which it operates. The scope includes, but is not limited to, servers and workstations, virtual machines, routers and switches, firewalls, network appliances, and network printers — whether in on-premises, roaming, or cloud-operated deployment models. The scope excludes ephemeral assets such as containers and third-party managed software as a service (SaaS) solutions.	A: この指令は、IPv4およびIPv6プロトコルを介して到達可能な、すべてのIPアドレス指定可能なネットワーク資産に適用される。IPアドレス指定可能なネットワーク資産とは、IPv4またはIPv6アドレスが割り当てられ、IPv4またはIPv6ネットワーク上でアクセスできる、報告可能な（すなわち、非エフェメラルな）情報技術または運用技術資産であり、それが運用されている環境に関係なく、定義されている。この範囲には、オンプレミス、ローミング、クラウド運用のいずれの展開モデルであっても、サーバー、ワークステーション、仮想マシン、ルーター、スイッチ、ファイアウォール、ネットワーク機器、ネットワークプリンターが含まれるが、これらに限定されるものではない。ただし、コンテナやサードパーティ製のSaaSソリューションなど、一時的な資産は対象外とする。
Q: How does the pre-existing requirement to perform endpoint detection and response (EDR) differ from the requirements of this BOD? To what extent does EDR address asset visibility needs?	Q: エンドポイントの検出と対応（EDR）を実行するという既存の要件は、このBODの要件とどのように違うのか？また、EDRは資産の可視化のニーズにどの程度対応しているか？
A: Asset visibility is a prerequisite for determining where to deploy EDR. While most EDR tools do not provide vulnerability information, the directive gives agencies the flexibility to use any tool that provides credential or client-level vulnerability information. If an agency deploys EDR tools that can provide vulnerability information, those tools can be used in place of a client-based scanner.	A: 資産の可視化は、EDRを導入する場所を決定するための前提条件である。ほとんどのEDRツールは脆弱性情報を提供しませんが、この指令は、クレデンシャルまたはクライアントレベルの脆弱性情報を提供するいかなるツールも使用する柔軟性を機関に与えている。もし、機関が脆弱性情報を提供できるEDRツールを配備していれば、それらのツールをクライアントベースのスキャナーの代わりに使用することができる。
Q: This BOD uses the term “networked assets.” Does that imply cloud is out of scope?	Q: このBODでは、"ネットワーク化された資産 "という用語が使われている。これは、クラウドが対象外であることを意味するのか。
A: Any non-ephemeral asset with an IP address is in scope, including applicable cloud assets. Many cloud use cases are unique. Many agencies have SaaS instances where agencies are unable to run their own scans. In the case of traditional data center collocations, infrastructure as a service (IaaS), and in some cases platform as a service (PaaS), all assets with an IP address are in scope. The scope excludes ephemeral assets such as containers and third-party managed SaaS solutions.	A: IPアドレスを持つ非継続的な資産であれば、適用可能なクラウド資産も含めて対象範囲である。多くのクラウドのユースケースは独特である。多くの機関は、機関が独自のスキャンを実行できないSaaSインスタンスを持っている。従来のデータセンターのコロケーション、IaaS（Infrastructure as a Service）、場合によってはPaaS（Platform as a Service）の場合、IPアドレスを持つすべての資産がスコープに含まれる。コンテナやサードパーティ製のマネージドSaaSソリューションのような一時的な資産は対象外である。
Q: Why does the directive say “initiate scans” instead of “execute” or “complete scans”?	Q: なぜ指令では、「実行」や「スキャン完了」ではなく、「スキャンを開始する」となっているのか？
A: Sometimes, especially in large enterprises, vulnerability scans may not be complete within the 14-day timeframe required in the BOD. To overcome this issue, BOD 23-01 requires agencies to initiate a new scan every 14 days regardless of whether the previous scan has completed. Agencies are also required to feed available results for the previous scan three days after the new scan is initiated, even when the previous scan is not fully complete.	A: 特に大企業では、BODで要求されている14日間の期間内に脆弱性スキャンを完了できないことがある。この問題を克服するために、BOD 23-01は、前回のスキャンが完了したかどうかにかかわらず、14日ごとに新しいスキャンを開始するよう機関に要求している。また、前回のスキャンが完全に終了していない場合でも、新しいスキャンが開始されてから3日後に、前回のスキャンの結果を提供することが義務付けられている。
Q: What is the difference between “asset management” and “asset discovery”?	Q: "資産管理 "と "資産発見 "の違いは何であるか？
A: Asset management and asset discovery are two distinct activities that frequently go hand in hand. Asset management is the active monitoring and administration of endpoints using a centralized solution, such as unified endpoint management (UEM), mobile device management (MDM), or enterprise mobility management (EMM). Inventories from asset management solutions may be used to feed the information about agency assets into the results of a comprehensive asset discovery effort.	A: 資産管理と資産発見は、しばしば手を取り合って行われる2つの異なる活動である。資産管理は、統合エンドポイント管理（UEM）、モバイルデバイス管理（MDM）、エンタープライズモビリティ管理（EMM）などの集中型ソリューションを使用して、エンドポイントを積極的に監視および管理することである。資産管理ソリューションのインベントリは、機関の資産に関する情報を、包括的な資産探索の取り組みの結果に反映させるために使用することができる。
Asset discovery is the process of checking an IPv4 or IPv6 network for active and inactive hosts (e.g., networked assets) by using a variety of methods. The most common discovery methods include actively trying to communicate with all IP addresses in a range using a scan tool such as “nmap” (which is only feasible on smaller IPv4 based networks), or by passively monitoring traffic on the wire to detect activity from any new assets.	資産発見とは、さまざまな方法を用いて、IPv4またはIPv6ネットワークにアクティブなホストと非アクティブなホスト（ネットワーク上の資産など）があるかどうかを確認するプロセスである。最も一般的な発見方法は、「nmap」などのスキャンツールを使用して範囲内のすべてのIPアドレスとの通信を積極的に試みる方法（これは小規模なIPv4ベースのネットワークでのみ実行可能）、またはワイヤ上のトラフィックをパッシブに監視して新しい資産からのアクティビティを検出する方法などがある。
Asset discovery helps organizations find unmanaged assets that are present on the network to ensure they are brought under appropriate management. It also helps organizations identify networked devices, such as Internet of Things (IoT), that cannot be centrally managed. It is possible for an asset to fall off the management tool due to inactivity or other reasons, requiring it to be rediscovered.	資産検出は、ネットワーク上に存在する管理されていない資産を発見し、適切な管理下に置くことを可能にする。また、IoT（Internet of Things）など、一元管理できないネットワーク上のデバイスを特定することもできる。不活性化などの理由で管理ツールから外れてしまい、再認識する必要がある場合もあり得る。
Q: Why does the directive reference the software bill of materials (SBOM) in the Background section but not in subsequent sections?	Q: なぜ指令は背景のセクションでソフトウェア部品表（SBOM）に言及し、それ以降のセクションで言及しないのか？
A: SBOM is mentioned in the introduction to convey the Administration’s vision and describe our desired state in the long term. The directive focuses on very specific first steps that can be achieved within the next 6-12 months and are prerequisites for broader adoption of SBOM. Without comprehensive asset management, agencies will be unable to effectively use SBOMs to manage risk posed by asset components or libraries.	A: SBOMは、行政のビジョンを伝え、長期的に望ましい状態を説明するために、序章で言及されている。この指令は、今後6〜12ヶ月以内に達成可能で、SBOMをより広く採用するための前提条件となる、非常に具体的な最初のステップに焦点を合わせている。包括的な資産マネジメントがなければ、機関はSBOMを効果的に使用して、資産の構成要素やライブラリによってもたらされるリスクを管理することはできないだろう。
Q: We offer public wireless access in conference rooms and lobbies. Are guest networks in scope?	Q: 当社は、会議室やロビーで公衆無線アクセスを提供している。ゲストネットワークは対象であるか？
A:  Guest hosts are not in scope, provided the guest networks are physically segmented from agency networks.	A: ゲストネットワークが機関のネットワークから物理的に分離されている場合、ゲストホストは適用範囲外である。
Q: Are bring-your-own-device (BYOD) assets in scope?	Q：BYOD（Bring-Your-Own-Device）資産は範囲内か？
A: Most federal agencies do not allow BYOD on enterprise networks. If they do, then BYOD devices are in scope. This does not apply to personally owned equipment that connects to federal networks via web interface (e.g., website visitors or remote users connecting via SSL remote access solutions).	A：ほとんどの連邦政府機関では、エンタープライズ・ネットワーク上でのBYODを許可していません。BYODが許可されている場合、そのデバイスは対象範囲に含まれる。ただし、Webインタフェース経由で連邦政府のネットワークに接続する個人所有の機器（Webサイトの訪問者やSSLリモートアクセスソリューションで接続するリモートユーザーなど）には適用されない。
Q: Are air-gapped networks in scope? It may not be possible to transfer a signature to air-gapped networks within 24 hours.	Q：エアギャップ・ネットワークは範囲に含まれるか？24時間以内にエアギャップ・ネットワークに署名を転送することは不可能かもしれない。
A: Many logically isolated networks and systems are incorrectly considered air-gapped. Any device, system, or network that is directly connected to the operating environment, or is connected to another system that is connected to the operating environment, is not considered air-gapped and is in scope for BOD 23-01. Only systems that are truly physically air-gapped are out of scope.	A: 論理的に分離されたネットワークやシステムの多くは、誤ってエアギャップされていると考えられている。動作環境に直接接続されている、または動作環境に接続されている他のシステムに接続されているデバイス、システム、またはネットワークは、エアギャップとはみなされず、BOD 23-01の適用範囲に含まれる。本当に物理的にエアギャップされているシステムのみが対象外である。
Q: Does the BOD include requirements for scanning software and configuration enumerations?	Q: BODには、スキャンソフトウェアや構成列挙の要件が含まれているか？
A: No, the BOD requirements address only basic (IP) asset discovery and vulnerability enumeration. The current BOD does not address hardware management, software management, or configuration management and associated controls. Note that some vulnerabilities due to misconfigurations and basic configurations may be captured by standard vulnerability scanners.	A: いいえ。BOD要件は、基本的な（IP）資産の発見と脆弱性一覧のみを扱っている。現在のBODは、ハードウェア管理、ソフトウェア管理、構成管理および関連するコントロールには対応していません。なお、設定ミスや基本的な設定による脆弱性は、標準的な脆弱性スキャナで捕捉できる場合がある。
Q: Which cloud assets are in scope?	Q: どのクラウド資産が対象になるか？
A: Agencies are responsible for the discovery and enumeration of networked assets under agency control, such as assets in authority-to-operate (ATO) inventories. Each cloud instance is unique, but in general, third-party hosting solutions where agencies still control physical or virtual hosts, such as infrastructure as a service, are within the scope of this directive.	A: 機関は、ATO（Authority-to-Operate）インベントリ内の資産など、機関の管理下にあるネットワーク資産の発見と列挙に責任を負う。クラウドのインスタンスはそれぞれ異なるが、一般的に、機関が物理的または仮想的なホストを引き続き管理するサードパーティのホスティングソリューション（サービスとしてのインフラストラクチャなど）は、この指令の対象範囲内である。
Q: Are communications devices, such as IP telephony, VOIP phones, cameras, and unified communications peripherals in scope?	Q: IP電話、VOIP電話、カメラ、ユニファイドコミュニケーション周辺機器などの通信機器も対象となるか？
A: Yes, these devices are in scope. Adversaries have specifically targeted these devices as they are typically more difficult to harden.	A: はい、これらのデバイスは対象である。一般的にハード化が困難なため、攻撃者はこれらのデバイスを特にターゲットにしている。

ドイツ BSI （連邦情報セキュリティ局）：自動車業界状況報告2021/2022

こんにちは、丸山満彦です。

ドイツの連邦情報セキュリティ局が自動車業界の情勢報告2021/2022を公表していますね。。。「サイバーセキュリティが鍵」というメッセージですね。これは、昨年に2021.09.07に発表された報告書に続く、第2版です。

● Bundesamt für Sicherheit in der Informationstechnik: BSI 

・2022.09.19 Cyber-Sicherheit als Schlüssel: BSI stellt Automotive-Lagebild 2021/2022 vor

Cyber-Sicherheit als Schlüssel: BSI stellt Automotive-Lagebild 2021/2022 vor	サイバーセキュリティが鍵：BSIが自動車業界状況報告2021/2022を発表
Die Digitalisierung moderner Autos schreitet weiter schnell voran. Mitunter sind über 100 einzelner digitaler Steuerungsgeräte in heutigen Autos verbaut, die miteinander verbunden sind oder zentral gesteuert werden können. Durch das autonome Fahren und den Einsatz Künstlicher Intelligenz wird die Komplexität der Software-Architektur in Fahrzeugen weiterhin rasant zunehmen. Und auch die Unternehmen selbst sind mehr denn je auf sichere IT-Systeme angewiesen. Dies stellt das Bundesamt für Sicherheit in der Informationstechnik (BSI) in der zweiten Ausgabe seines Branchenlagebilds Automotive fest.	現代のクルマのデジタル化は急速に進み続けている。現在の自動車には、100個以上の個別のデジタル制御装置が搭載され、それらが相互に接続されたり、集中的に制御されたりすることもある。自律走行や人工知能の活用により、自動車に搭載されるソフトウェア・アーキテクチャの複雑さは今後も急速に増していくだろう。そして、企業自体も、安全なITシステムへの依存度がこれまで以上に高まっている。これは、連邦情報セキュリティ局（BSI）が、自動車産業の状況報告書の第2版で述べている。
BSI-Präsident Arne Schönbohm: „Das BSI gestaltet Informationssicherheit in der Digitalisierung für Staat, Gesellschaft und auch Wirtschaft. Die Automobilindustrie nimmt dabei auf Grund ihrer volkswirtschaftlichen Bedeutung und ihrer umfangreichen Lieferketten eine besondere Stellung ein. Mit dem Lagebild Automotive 2021/22 wird einmal mehr deutlich, dass Cyber-Sicherheit in allen Gliedern der Lieferkette mitgedacht werden muss – von Anfang an bis zum fertigen Produkt. Cyber-Sicherheit ist der Schlüssel für eine funktionierende Automobilindustrie.“	BSIのアルネ・シェーンボーム会長：「BSIは、国家、社会、そして経済のために、デジタル化における情報セキュリティを形成している。自動車産業は、その経済的重要性と広範なサプライチェーンから、特別な位置を占めている。「自動車業界状況報告2021/2022」は、サイバーセキュリティはサプライチェーンのすべてのリンク（最初から最終製品まで）で考慮されなければならないことを改めて明確にしている。サイバーセキュリティは、自動車産業が機能するための鍵である。」
Das Branchenlagebild Automotive 2021/2022 ist die zweite Ausgabe eines branchenspezifischen Überblicks aus Sicht des BSI zur Lage der Cyber-Sicherheit im Bereich „Automotive“, sowohl hinsichtlich der Produktion, als auch der Fahrzeuge selbst. Es macht deutlich, dass künftige Automobile noch viel stärker als heute schon von IT-Funktionen abhängig sein werden. Die Steuerung des Fahrzeugs selbst, aber auch die Vernetzung mit der Infrastruktur (car-to-x) wird rasant digitalisiert. So wurde in Deutschland im vergangenen Jahr die weltweit erste Genehmigung für ein automatisiertes KFZ (Spurhaltesystem) erteilt. Daher ist es aus Sicht des BSI von besonderer Bedeutung, dass die dazu notwendigen, neuen Technologien nicht manipulierbar sein dürfen und mögliche Cyber-Angriffe keinen Einfluss auf die Fahrsicherheit haben dürfen. Das BSI begrüßt daher, dass die Hersteller Cyber-Sicherheit frühzeitig im Entwicklungszyklus neuer Fahrzeugmodelle berücksichtigen und die Umsetzung nach EU-Typgenehmigungsrecht auch nachweisen müssen.	「自動車業界状況報告2021/2022」は、「自動車」セクターのサイバーセキュリティ状況について、生産と車両自体の両面からBSIの視点でセクター別にまとめた第2版である。これからの自動車は、今以上にIT機能への依存度が高まることが明らかである。車両自体の制御はもちろん、インフラとのネットワーク化（car-to-x）も急速にデジタル化されている。例えば、昨年はドイツで世界初の自動運転車（車線維持システム）の認可が下りた。そのため、BSIの観点からは、このために必要な新技術が操作可能であること、起こりうるサイバー攻撃が運転の安全性に影響を与えないことが特に重要であるとしている。したがって、BSIは、メーカーが新車種の開発サイクルの早い段階でサイバーセキュリティを考慮し、さらにEU型式認証法に従って実装を証明しなければならないという事実を歓迎する。
Im Berichtszeitraum waren erneut mehrere Automobilzulieferer von Ransomware-Vorfällen betroffen. Dadurch kam es bei den Betroffenen zu massiven Unterbrechungen der Leistungserbringung. Die durch das BSI grundsätzlich festgestellte Tendenz, dass Dritte mittelbar ebenfalls von IT-Sicherheitsvorfällen in Mitleidenschaft gezogen werden, bestätigt sich auch hier. So war auch ein weltweit führender Automobilhersteller von Ransomware-Angriffen bei Zulieferern betroffen und musste seinerseits seine Produktion drosseln. Im Hinblick auf die operative Cyber-Sicherheit in den Betrieben stellen Ransomware-Angriffe aus Sicht des BSI aktuell die größte Bedrohung dar. Neben den bestehenden Auswirkungen der COVID‑19-Pandemie, insbesondere in den Bereichen von Zulieferteilen, -produkten oder –dienstleistungen, wird die Lage maßgeblich durch den Krieg in der Ukraine und den damit verbundenen wirtschaftlichen, aber zunehmend auch cyber-sicherheitsrelevanten Auswirkungen auf die deutsche Automobilindustrie geprägt. Dies sind u. a. Verfügbarkeitsangriffe auf Webseiten durch DDoS-Angriffe sowie intensive Hacktivisten-Aktivitäten.	報告書の期間中、いくつかの自動車部品メーカーが再びランサムウェアの被害を受けた。そのため、被災組織ではサービスの提供に大規模な支障をきたすことになった。BSIが確認した、ITセキュリティ事故の影響を第三者も間接的に受けるという一般的な傾向は、ここでも確認されている。例えば、世界的な大手自動車メーカーも、サプライヤーへのランサムウェア攻撃の影響を受け、生産縮小を余儀なくされました。企業における運用上のサイバーセキュリティについては、BSIの観点では、現在、ランサムウェア攻撃が最大の脅威となっている。COVID 19の大流行による既存の影響、特にサプライヤーの部品、製品、サービスの分野に加え、ウクライナ戦争とそれに伴う経済的な影響、さらにはドイツの自動車産業に対するサイバーセキュリティ関連の影響によって、状況は大きく変化している。DDoS攻撃によるWebサイトへの可用性攻撃や、ハクティビストによる集中的な活動などである。
Um die Cyber-Sicherheit für den Wirtschafts- und Automobilstandort Deutschland zu erhöhen, arbeitet das BSI in Fragen der Cyber-Sicherheit eng mit dem Kraftfahrtbundesamt (KBA), dem Verband der Automobilindustrie (VDA) sowie weiteren Behörden und aus der Wirtschaft betroffenen Unternehmen zusammen.	ビジネスや自動車の拠点としてのドイツのサイバーセキュリティを高めるため、BSIは連邦自動車交通局（KBA）、ドイツ自動車工業会（VDA）、その他の当局やサイバーセキュリティ問題の影響を受ける企業と緊密に連携している。

・2022.09.19 Branchenlagebild Automotive 2021/2022

Branchenlagebild Automotive 2021/2022

自動車業界状況報告 2021/2022

Die zweite Auflage des Branchenlagebild Automotive 2021/2022 gibt einen branchenspezifischen Überblick zur Lage der Cyber-Sicherheit im Bereich „Automotive“. Sie zeigt vielfältige und komplexe Herausforderungen auf - sowohl hinsichtlich der Produktion als auch der Fahrzeuge selbst. Die Publikation verdeutlicht, wie wichtig diese Aufgabe bei Herstellern, Zulieferern, Entwicklern und anderen Dienstleistern der Automobilindustrie ist und stellt das Engagement des BSI in diesem Sektor dar.

「自動車業界状況報告2021/2022」の第2版では、自動車業界のサイバーセキュリティの状況を分野別にまとめている。生産面でも車両面でも、多様で複雑な課題が浮き彫りになっている。本書は、自動車産業のメーカー、サプライヤー、開発者、その他のサービスプロバイダーにとって、このタスクがいかに重要であるかを説明し、この分野に対するBSIのコミットメントを提示している。

・[PDF]

・[DOCX] 仮訳

1 Einleitung	1 はじめに
2 Managementübersicht zur Gesamtlage	2 経営の全体像の把握
3 Cyber-Sicherheit in der Automobilbranche	3 自動車産業におけるサイバーセキュリティ
3.1 Branchenüberblick	3.1 業界の概要
3.2 Auswirkungen durch den Angriffskrieg auf die Ukraine	3.2 ウクライナへの侵略戦争による影響
3.3 Gefahren durch Cybercrime	3.3 サイバー犯罪による脅威
3.4 Bedeutung der Informationssicherheit in der Supply Chain	3.4 サプライチェーンにおける情報セキュリティの重要性
3.5 Qualifizierung von Schlüsselpersonal	3.5 主要な人材の資格
4 Cyber-Sicherheit im Fahrzeug sowie in digitalen Produkten	4 自動車およびデジタル製品におけるサイバーセキュリティ
4.1 Vernetztes Fahren	4.1 コネクテッド・ドライブ
4.2 Automatisierung und Künstliche Intelligenz	4.2 オートメーションと人工知能
5 Cyber-Sicherheit in Produktionsanlagen und -prozessen	5 生産工場・プロセスにおけるサイバーセキュリティ
5.1 Digitalisierung als Herausforderung in der Produktion	5.1 生産現場の課題としてのデジタル化
5.2 Schwachstellenmanagement	5.2 脆弱性管理
5.3 Dienstleister und Fernservices	5.3 サービスプロバイダーとリモートサービス
6 Maßnahmen und Aktivitäten	6 施策と活動
6.1 Informationssicherheit im Unternehmen	6.1 企業における情報セキュリティ
6.2 Regulierung und Standardisierung - Vorgaben zur Cyber-Sicherheit	6.2 規制と標準化 - サイバーセキュリティ要件
6.3 Neuregelungen für Unternehmen im besonderen öffentlichen Interesse (UBI)	6.3 特別公益法人（UBI）に対する新たな規制
6.4 Zusammenarbeit und Aktivitäten des BSI	6.4 BSIの協力と活動
7 Chancen und Risiken: Ein Blick in die nahe Zukunft	7 チャンスとリスク：近未来への展望
Literaturverzeichnis	書誌情報
Impressum	インプリント

---

昨年度

● まるちゃんの情報セキュリティ気まぐれ日記

・2021.09.08 独国 BSI 自動車業界におけるサイバーセキュリティ

● Bundesamt für Sicherheit in der Informationstechnik: BSI

 ・2021.09.07 Crashtest für Cyber-Sicherheit – BSI stellt Automotive-Lagebild vor

 ・2021.09.07 Branchenlagebild Automotive

 ・[PDF] Branchenlagebild Automotive - Cyber-Sicherheit in der Automobilbranche

 

ドイツ BSI 静的アプリケーションセキュリティテストの文脈における機械学習

 こんにちは、丸山満彦です。

ドイツのBSIが静的アプリケーション セキュリティ テストにおける AI の使用に関する研究報告書を公表していますね。。。力作ですが、2023年初頭に最終化するようです。

● Bundesamt für Sicherheit in der Informationstechnik: BSI

・2022.07.27 Machine Learning in the Context of Static Application Security Testing - ML-SAST

Machine Learning in the Context of Static Application Security Testing - ML-SAST	静的アプリケーションセキュリティテストの文脈における機械学習 - ML-SAST
Überblick über den aktuellen Stand in Forschung und Technik	研究・技術の現状を概観する
Im Projekt Machine Learning in the Context of Static Application Security Testing (ML-SAST) untersucht das BSI, wie Verfahren des maschinellen Lernens genutzt werden können, um Methoden der statischen Codeanalyse zu verbessern.	静的アプリケーションセキュリティテストの文脈における機械学習（ML-SAST）プロジェクトにおいて、BSIは機械学習手法を静的コード解析手法の改善にどのように利用できるかを調査している。
In der Softwareentwicklung stellt die statische Programmcodeanalyse neben der dynamischen Programmcodeanalyse eine wichtige Technik dar, um zum Beispiel redundanten Code, Verletzungen von Programmierrichtlinien oder Fehler in Treiberdateien aufzudecken. Sie ermöglicht ein automatisiertes Auffinden von potentiellen Schwachstellen im Programmcode durch statische Analyseverfahren. Ein aktuelles Anliegen ist es, bereits während der Programmierung Sicherheitslücken für verdeckte Angriffsmöglichkeiten, wie Pufferüberläufe, aufzudecken und somit einen Security-by-Design-Ansatz zu verwirklichen.	ソフトウェア開発において、静的プログラムコード解析は、動的プログラムコード解析と並んで、冗長なコード、プログラミングガイドライン違反、ドライバファイルのエラーなどを検出するための重要な技術である。静的解析手続きにより、プログラムコードの潜在的な弱点を自動的に検出することができる。現在、バッファオーバーフローのような隠れた攻撃可能性を持つセキュリティ脆弱性を、プログラミングの段階ですでに検出し、セキュリティバイデザインのアプローチを実現することが課題となっている。
Im Rahmen des Projekts hat das BSI die neusta mobile solutions GmbH mit der Erstellung einer mehrteiligen Studie beauftragt. Im ersten Teil wird der aktuelle Stand der Forschung in den Bereichen des Machine Learning, der statischen Codeanalyse und deren Kombination untersucht. Flankierend wurden im zweiten Teil Experteninterviews geführt, um die Nachteile der aktuellen Ansätze zu erfassen, und geeignete Use-Cases zu definieren. Im letzten Teil werden vorhandene ML-SAST-Ansätze anhand der Use-Cases und einer neu entwickelten Metrik miteinander verglichen und ein Vorschlag für die Entwicklung eines neuartigen ML-SAST-Ansatzes vorgestellt. Dieser befindet sich aktuell in der Umsetzung. Die Veröffentlichung der finalen Studie und der Implementierung erfolgt Anfang des Jahres 2023.	このプロジェクトの一環として、BSIはneusta mobile solutions GmbHに依頼し、いくつかのパートに分かれて調査書を作成した。第1部では、機械学習、静的コード解析、およびそれらの組み合わせの領域における研究の現状について検討する。第2部では、現在のアプローチのデメリットを明らかにし、適切なユースケースを定義するために、専門家へのインタビューを実施した。最後に、ユースケースと新たに開発した指標に基づいて、既存のML-SASTアプローチを相互に比較し、新しいML-SASTアプローチの開発に関する提案を行う。現在、実施中である。最終的な検討と実施は、2023年初頭に発表される予定である。

・[PDF] Machine Learning in the Context of Static Application Security Testing - ML-SAST

目次...

1  Introduction	1 はじめに
1.1  Summary	1.1 概要
1.2  Summary in German	1.2 概要（ドイツ語）
1.3  Motivation	1.3 動機
1.4  Contribution	1.4 貢献度
1.5  Structure	1.5 構成
2  Artificial Intelligence and Machine Learning	2 人工知能と機械学習
2.1  Definition of Artificial Intelligence	2.1 人工知能の定義
2.2  Basic Principles of AI Systems	2.2 人工知能システムの基本原理
2.3  Machine Learning Primer	2.3 機械学習入門
2.3.1  Supervised Learning	2.3.1 教師あり学習
2.3.2  Unsupervised Learning	2.3.2 教師なし学習
2.3.3  Reinforcement Learning	2.3.3 強化学習
2.3.4  Neural Networks	2.3.4 ニューラルネットワーク
2.3.5  Recurrent Neural Networks	2.3.5 リカレントニューラルネットワーク
2.3.6  LSTM Networks	2.3.6 LSTMネットワーク
2.3.7  Bidirectional Sequence Models	2.3.7 双方向配列モデル
2.3.8  Graph Neural Networks	2.3.8 グラフニューラルネットワーク
2.4  Other Concepts and Further Reading	2.4 その他の概念と参考文献
3  Static Application Security Testing	3 静的アプリケーションセキュリティテスト
3.1  SAST Tools	3.1 SASTツール
3.2  Background on Static Program Analysis	3.2 静的プログラム解析の背景
3.2.1  Compiler Construction Techniques	3.2.1 コンパイラの構築技法
3.2.2  Typical Internal Data Structures for Static Program Analysis	3.2.2 静的プログラム解析のための典型的な内部データ構造
3.2.3  Static Analysis Problems	3.2.3 静的解析の問題点
4  ML in the Context of SAST	4 SASTの文脈における機械学習
4.1  Preliminaries	4.1 前提条件
4.2  Refinements	4.2 リファインメント
4.3  Current State of the Art	4.3 現在の技術水準
4.3.1  Datasets	4.3.1 データセット
4.3.2  Architectures	4.3.2 アーキテクチャ
4.3.3  Explainability	4.3.3 説明可能性
4.3.4  Outlook	4.3.4 展望
5  Expert Interviews	5 専門家インタビュー
5.1  Method	5.1 方法
5.2  Interview Partners	5.2 インタビューの相手
5.3  Results of the Expert Interviews	5.3 専門家インタビューの結果
5.3.1  Versions of C and C++ Used	5.3.1 使用したCおよびC++のバージョン
5.3.2  Opinions Towards SAST Tools in General	5.3.2 SASTツール全般に対する意見
5.3.3  Input Format for Rules for SAST tools	5.3.3 SASTツールのルールの入力形式
5.3.4  Expectations Towards ML-based SAST Tools and Ideas to this End	5.3.4 機械学習ベースのSASTツールへの期待とそのためのアイデア
5.3.5  Easily and Not Easily Detectable Errors	5.3.5 検出が容易なエラーとそうでないエラー
5.3.6  Sources for Error Use Cases	5.3.6 エラー・ユースケースのソース
6 Online Questionnaire	6 オンラインアンケート
6.1 Platform	6.1 プラットフォーム
6.2 Participants	6.2 参加者
6.3 Questionnaire	6.3 アンケート質問
6.4 Results	6.4 アンケート結果
6.4.1 C/C++ Versions	6.4.1 C/C++バージョン
6.4.2 SAST Tools	6.4.2 SASTツール
6.4.3 Input Format for Rules for SAST tools	6.4.3 SASTツール用ルールの入力形式
6.4.4 Error Use Cases	6.4.4 エラーの使用例
6.4.5 ML and SAST Tools	6.4.5 MLとSASTツール
7 Elicitation and Explanation of Error Use Cases with Descriptions	7 エラー・ユースケースの抽出と説明
7.1 void* Pointers	7.1 void*ポインタ
7.2 Difficulty in Tracking Tainted Data	7.2 汚染されたデータの追跡の困難さ
7.3 Integer Overflows Related to Tainted Data	7.3 汚染されたデータに関連する整数のオーバーフロー
7.4 Array Boundary Errors	7.4 アレイバウンダリエラー
7.5 Null Pointer Access	7.5 Nullポインタのアクセス
7.6 Format String Errors (With Tainted Data)	7.6 (汚染されたデータを含む)文字列のフォーマットエラー
7.7 String Termination Errors	7.7 文字列の終了エラー
7.8 Missing Security Checks for Critical Operations	7.8 重要な操作のためのセキュリティチェックの欠落
7.9 Unsafe Use of Random Number Generators	7.9 乱数生成器の安全でない使用
7.10 Information Flow Through Uncleared Main Memory Data Structures	7.10 安全でないメインメモリのデータ構造を介した情報の流れ
7.11 Insecure Origin of Cryptographic Keys and Initialization Vectors	7.11 安全ではない暗号鍵の出所と初期化ベクタ
7.12 Reuse of Initialization Vectors for Specific Operating Modes of Block Ciphers	7.12 ブロック暗号の特定の動作モードに対する初期化ベクタの再利用
7.13 Memory Leaks	7.13 メモリリーク
7.14 Dangling Pointers – Use-After-Free	7.14 ぶら下がりポインタ - ユーズ・アフター・フリー
7.15 Race Conditions	7.15 レースコンディション
7.16 Application-Specific Errors	7.16 アプリケーション固有のエラー
7.17 Pointer Casts to Types with Stricter Alignment	7.17 より厳格なアライメントを持つ型へのポインタキャスト
8 Evaluation Criteria for ML-SAST Approaches	8 ML-SASTアプローチの評価基準
8.1 Qualitative Criteria	8.1 定性的評価基準
8.1.1 Transparency	8.1.1 透過性
8.1.2 Other Requirements	8.1.2 その他の要求事項
8.2 Quantitative Criteria	8.2 定量的基準
8.3 Other Criteria	8.3 その他の基準
9 Data in ML-Experiments: Types, Formats and Schemata	9 ML-Experimentsにおけるデータ：データの種類，フォーマット，スキーマ
9.1 Benchmarks	9.1 ベンチマーク
9.2 Type, Format and Metrics	9.2 タイプ，フォーマット，評価基準
9.2.1 Name, Version and Description of Dataset	9.2.1 データセットの名称、バージョン、説明
9.2.2 Dataset Scheme	9.2.2 データセットのスキーム
9.2.3 Experiment Scheme	9.2.3 実験スキーム
9.2.4 Model Persistence and Tracking	9.2.4 モデルの永続性とトラッキング
9.3 Ontologies for Machine Learning	9.3 機械学習のためのオントロジー
10 Approaches to Conducting a Literature Mapping for ML-SAST	10 ML-SASTのための文献マッピングの実施方法
10.1 Research Questions	10.1 リサーチクエスチョン
10.2 Initial Search	10.2 初期検索
10.3 Iteration Steps	10.3 イテレーションステップ
10.4 Data Extraction	10.4 データ抽出
10.5 Summary of the Most Important Results	10.5 最も重要な結果のまとめ
11 Detailed Description of Most Appropriate Methods for ML-SAST	11 ML-SASTに最適な手法の詳細説明
11.1 Training Data	11.1 学習データ
11.2 Models	11.2 モデル
11.3 Explainability	11.3 説明可能性
12 Prioritization of Models for this Approach and Outlook on Further Work	12 本アプローチにおけるモデルの優先順位付けと今後の展望
12.1 Graph Neural Networks	12.1 グラフニューラルネットワーク
12.2 Conventional Neural Networks	12.2 伝統的ニューラルネットワーク
12.3 Clustering Approaches	12.3 クラスタリングアプローチ
12.4 Reinforcement Learning	12.4 強化学習
12.5 Ensembles of Approaches	12.5 アプローチのアンサンブル
12.6 Conclusion of the Prioritization	12.6 優先順位付けの結論
13 Conclusion	13 結論
13.1 Further Research	13.1 更なる研究
13.2 Outlook	13.2 展望
14 Appendix	14 附属書
14.1 Glossary	14.1 用語集
14.2 Results of the Literature Mapping	14.2 文献マッピングの結果
14.2.1 Base Set	14.2.1 基本セット
14.2.2 Round I	14.2.2 ラウンドI
14.2.3 Round II	14.2.3 ラウンドII
14.2.4 Round III	14.2.4 ラウンドIII
14.2.5  Round IV	14.2.5 ラウンドIV
14.3  Guideline for the interviews with the experts	14.3 専門家インタビューのためのガイドライン
Bibliography	書誌情報