プロメテウスは神ではない。
これは多くの人が忘れているか、理解していないことだ。彼は神でも人でもなく、より古いものからできていた。彼はタイタンだ。
ガイアとウラノスが結ばれたとき、彼らは多くの子をなした。ヘカントケイル族、キュクロプス、そして大地を放浪する十二の怪物。それぞれをウラノスはガイアの内に封じ込め、彼らすべてを退屈なるタイタンへの見世物とした。
気をつけて欲しいのだが、彼の息子サターンは後にウラノスを去勢し、ガイアの説得によりその権力を奪ったが、これはギリシア人のためのやり方だった。
後にゼウスがタイタンと彼らの冷酷な支配に対し立ち上がり、一握りのタイタンが神々とともに戦った。それがテミスとプロメテウス。そして最後に神々は争いに勝利した。
プロメテウスが栄光の唯一の貢献者であったと主張するのは馬鹿げているし、私もそうするつもりはないが、古代の多くの著述家はそうしている。プロメテウスは戦ったのだ、結局は、個人的な理由のために。
人間。
プロメテウスは文筆、科学、農業、医学、数学を彼の子達である人間に与えた。神は苦しみを与え、犠牲を要求した。プロメテウスが焼けた骸を彼の名誉のために要求したことがあっただろうか？
人間は彼の創造物の1つだ。彼は人間たちが安全で強靱で発展し続けるようにあることを望んだ。彼は人間たちが神々によって祝福され保護されることを望んだ。ゼウスは彼が火を盗んだときに怒り、プロメテウスを岩に縛り付けて毎日肝臓をワシについばまれるようにした。
プロメテウスが神々から火を盗んだように、我々も日々宇宙から秘密を獲得する。かつて火はとてつもなく神秘的で魔術的だった。ひどく危険で信じがたいものだった。君が物語ることの出来る唯一の根源が、星だというのを想像できるか？
古代ギリシャで、それはどんなに信じがたかったことだろう。そして今は？ありふれたものだ。ありふれたものがかつて奉られていた。
これがあらゆる偉大な魔術の手法だ。これがあらゆる偉大な業の手法だ。これがあらゆる未知なる物事の手法だ。
研究と洞察により、神秘はありふれたものとなる。犠牲は必要とされず、血を捧げることも無い。宇宙の扉は我々に向けて開かれているのだ。
我々と共に踏み出そう。
— プロメテウス研究所の雇用書類から、おそらく1982年、[編集済]によるもの
株式会社プロメテウス研究所は科学的な研究開発を基盤とした営利目的の複合企業でした。1892年に設立されたこの会社は、商業用および民間用の異常な技術の研究と開発に専念していました。1998年の[データ削除済]の事件まで、プロメテウス研究所は財団の最も手強い競合相手だとみなされていました。研究所は異常な研究から製造された高品質の電子工学、医療および医薬品、自動車、光学、および産業用品の提供者として広く知られていました。またプロメテウス研究所は世界中の多様な軍隊、主としてアメリカ合衆国と機密契約を結んでいました。研究所は[編集済]のように軍事的能力を高めることに向いている無数の特殊化した科学技術をそれらの集団に供給しました。
プロメテウス研究所は多くの主要な要注意団体と関わりあっていました。ワンダーテインメント・インダストリーと訴訟を、マーシャル・カーター＆ダークからオブジェクトの購入を、マクスウェリズム教会の使者とブレイン-マシーンインターフェースを開発するために働き、マナの慈善財団のために低コストの代用食物を計画し、道具と必需品をAre We Cool Yet?、世界オカルト連合、カオス・インサージェンシーに販売し、GRU"P"部局に産業スパイ活動を行っていました。プロメテウス研究所は財団に対し公然と敵対したのでも、助力をしたのでもありません。財団はプロメテウス研究所の特に不安定なオブジェクト群のために設計した収容プロトコルを提供しましたが、断られました。
[データ削除済]の発生と隠蔽の結果として開発中のプロジェクトの多くが財団に押収され、生き残った職員は財団に雇用されました。他の要注意団体も他の施設群からプロジェクトと研究を盗んだと考えられています。プロメテウス研究所は世界中に多くのネットワークと、支社と、系列会社とオフィスを保有していました。それらの場所はすべて一般的な職場であったにも関わらず、主に個々の専門分野に専念していました。たとえば、コルカタのプロメテウス研究所の支社はレーザーの工学研究に焦点をあて、ニューメキシコの施設はコンピューター・サイエンスに専念していました。プロメテウス研究所には、惑星工学を研究していたマリアナ海溝の研究室のような多数の秘密施設もありました。ある文書は、原子物理学と量子力学を研究する火星の完全に自立した施設と、ジュラ紀に建設された遺伝子工学を研究する施設の存在を示唆しています(これらの施設はまだ特定されていません)。
プロメテウス研究所は、第一に研究開発企業です。私たちが解決しようとしている問題は数多くありますが、利益追求の会社としてそれらを解決するのに利用できる資金は限られています。従って、プロメテウス研究所は投資対象に優先順位をつけ、解決に値すると考えられるプロジェクトか調査しなければなりません。
しかしながら、私たちは自分たちの世界的な科学者による独自研究に誇りを持っています。精神ネットワークやテレポーテーションのような製品は長期休暇中の科学者たちによって開発されました。このため、プロメテウス研究所は週8時間の独自研究という方針を設けています。私たちはこのための計画請求フォームも提供しています。あなたが自由な手法で終日研究に従事したいと考えているなら、このフォームに記入し人事部に提出してください。作業には2日から4日ほどかかります。
[ここに計画名を入力]のための認可計画
プロジェクトに特別な名前を付けないでください。計画名はそれが何であるか、すなわち科学的な疑問に対する許可要求に基づいて命名してください。
問題
何を達成しようとしていますか？どのような問題を解決しようとしていますか？
問題を詳細に説明してください。なぜプロメテウス研究所が取り組むべき問題であるのかを明確にしてください。
解決策
提案される科学的解決法を説明しましょう。どうやってそれは正確に機能するのでしょうか？問題を解決するためにすることは何ですか？その実行可能性を支える提案の背後にある科学技術もしくは研究は何でしょうか？それら科学技術や研究のメリットは何ですか？参考文献をおすすめします。
事業例
この製品または知識を購入もしくは使用するのは誰ですか？販売対象層(年齢層、民族、社会階級など)を提示してください。潜在的な市場をリストアップしましょう。製品であれば、すでに市場に出回っている類似製品とはどのような違いがありますか？なにが製品をより魅力的な選択肢にするのでしょうか？この研究あるいは科学技術の使用もしくは販売はプロメテウス研究所や科学的知識にどれほどの利益をもたらすのでしょう？
資金の使用
あなたはこの発想の開発と研究の援助のために資金を要求しています。資金はどこにいくのでしょう？それらは何の為に使われるのでしょう？資金で何を買うのでしょう？誰を雇うのでしょう？予想された工程と完成の日付の予定表、計画に使われる資材と道具のリスト、必要な契約者のリスト、それらすべての価格幅を提示してください。
既知の問題
普及、もしくは研究や科学技術の収益性に関する主要な問題は何でしょうか？既知のバグ、市場投入の難しさ、プロジェクトの失敗などの問題をどのようにすれば解決することができますか？
これは私が加わったことのある実際の認可済計画や多様な設計コンペのフォーマットをとても簡略化したものです。プロメテウス研究所は資金の限られた会社です。従って、会社は投資のために最良の、そして最も熟考された計画を選ばなければなりません。問題と解決策は自明です。事業例は基本的に、オブジェクトの創造とそれが作動する計画があるということを証明します。資金の使用は、プロジェクトに投入した資金が実際に有効に利用されていることを確実にします。既知の問題は、この製品に実際に未来があること、そして作成者がその先に考えていることを確認する実用的な方法です。
参考文献は必要ではありませんが、それは記事を明らかに良くするでしょう。
このフォーマットは基本的にプロメテウス研究所の作ったSCPオブジェクトに対する別の観点です。それらは商業目的を念頭において設計されています。その目的は？その意図は？一体誰の為に？
このフォーマットは基本的に"そもそもなぜこのオブジェクトは作られたのだろう？"と問いかけてきます。
物語を作るためにこのフォーマットを使うのはこれまであなたがやってきた方法よりも難しいかもしれません。が、これはSCPオブジェクトに対し独特な観点、つまり創造者の視点を与えてくれます。
このフォーマットを使うときに覚えていなければならないことは1つだけ。「地獄への道は善意で舗装されている」。
(プロメテウス研究所は彼らが有用だと考えたオブジェクトを作りますが、恐ろしい結果をもたらします)
全体の構成
レッドゾーン・セキュリティ報告の基本的なテンプレートは以下のようになります。それぞれのセクションについては後に適切なセクションで説明します。
[ヘッダーブロック]
----
++ 大要
++ 影響を受けた製品
++ 異常痕跡指標
++ ワークアラウンド
++ 修正されたソフトウェア
++ 私的利用と公表
++ ソース
ヘッダーブロック
レッドゾーン・セキュリティ報告のヘッダーブロックを作る際は、以下のパラメーターと
redzone-advisoryのコンポーネントを含みます。
- タイトル (任意)
- 参照しやすいよう、脆弱性に与えたタイトルです。これはページのタイトルと一致させるべきでしょう。
- id (必要)
- 脆弱性のIDナンバーです。これはたいてい以下のような形をとります。redzone-sa-12345678-2-to-3-word-summary. これは通常このように、ページのURLと一致させるべきです。: www.scp-wiki.net/redzone-sa-12345678.
- 更新日 (任意)
- この報告が最後に更新された日付です、もしこれが発表の日付と一緒ならこのパラメーターは削除してください。
- 発表日 (任意)
- この報告の最初のバージョンが発表された日付です。
- バージョン (任意)
- この更新が何回更新されたのかを示すバージョンナンバーです。第二版を表すには1.2と書くように、2桁のナンバーを使ってください、もしこれが最初のバージョンなら、このパラメーターは削除してください。
- 最終バージョン (任意)
- これが文書の'最終'バージョンかどうかを示します。デフォルトではtrueです。もし脆弱性の修正がまだ終わっていなかったり、他の理由で'最終'でないのならば、ここにはfalseと書いてください。
- 影響力 (必要)
- 脆弱性のベーシックCVSSスコアです。脆弱性が全くない場合は0.0であり、最大値は10.0です。このCVSS算出ツールを使って算出するか、自分で想定するかしてください。
- worknd (任意)
- 修正されたバージョンに更新する以外で、この脆弱性への応急措置があるかどうかを書いてください。デフォルトではfalseです。もし応急措置があるなら、このパラメーターをtrueと書いてください。
- バグ (必要)
- この脆弱性を引き起こしたバグの内部バグIDナンバーです。IDナンバーはRZux12345の形にしてください。複合的なナンバーは新しい行に分けてください。
- cve (任意)
- この脆弱性に触れるCommon Vulnerabilities and Exposures(CVE)ナンバーです。CVEナンバーはCVE-year-digitsの形を取り、数字は4桁か5桁になります。(技術的にはそれより長くできますが、一般的ではありません。)CVEデータベースを探して、あなたが使いたいナンバーが使われていないことを確認してください。それから、今年のナンバーを割り当ててください。複合的なナンバーは新しい行に分けてください。
- cwe (任意)
- 脆弱性を含むCommon Weakness Enumerationナンバーです。CWEナンバーはCWE-123の形を取ります。適切な欠陥と一致するCWEナンバーか確認してください。 このサイトで正しいCWEナンバーを探すことが出来ますが、CWEシステムはSCP財団のタグシステムよりも難解です。もし正しいCWEナンバーを探す手伝いがほしいときは、PMを
AJMansfieldに送ってください。彼が手伝ってくれるでしょう。複合的なナンバーは新しい行に分けてください。
ここに完全にパラメーターの埋まったレッドゾーン-報告コンポーネントの実例を置いておきます。
[[include component:redzone-advisory
|タイトル=Redzone Thingamajig Server Cromulator Vulnerability
|id=redzone-sa-12345678-thingamajig-cromulator
|更新日=2005-01-01
|発表日=2004-01-01
|バージョン=1.9
|最終バージョン=false
|影響力=7.0
|worknd=false
|バグ=RZux12345
RZux23456
|cve=CVE-1234-5678
CVE-1234-6789
|cwe=CWE-123
CWE-234
]]
もしあなたが
他の会社のセキュリティ報告を作りたいなら
レッドゾーン-報告-ベースコンポーネントの代わりに
レッドゾーン-報告コンポーネントを使うことが可能です。ここには2つの追加パラメーターを具体的に描写出来ます。
- ロゴ (必要)
- レッドゾーン・セキュリティのロゴの代わりに、ページのトップで使用する別の画像を挙げてください。
- カラー (必要)
- すべてのカラーコードを使うことが出来ます。ほとんどの場合ここにはロゴの主要なカラーを据えるべきですが、最初のページの背景と対照的なものにするのもいいでしょう。WCAG Contrast Checker tool - このツールが使えます。「fg」ボックスに色を入力して6つの円が緑色に変わるのが理想的ですが、6つのうち5つであれば通常は十分です。
加えて、レッドゾーン-報告-ベースを使うときは、すべての以前のオプションパラメーターを具体的に描写する必要があります。要素をfalseに除外するためにです。
概要
このセクションは、この脆弱性の技術概要を提供することを目的としています。これには、次のようなさまざまなものが含まれます。
- 脆弱性がどのように作用するのか。
- なにが脆弱性を引き起こしたのか。
- その脆弱性がどのように利用される可能性があるか。
- どこならそれが当てはまらないか。
この部分はSCP記事の説明部分の類似品だと考えてください。違いはそれが持つ異常な影響を直接は書かないということです-これについては、異常痕跡指標で描写します。
影響を受けた製品(任意)
この部分はレッドゾーンの製品のどれがこの脆弱性に影響を受けているかを正確に描写します。多くの例で、ここは以下のように表を使うのが簡単でしょう。
| 脆弱性のある製品 |
修復済: |
| レッドゾーン・クロミュレーター3000シリーズ |
1.2.3 |
| レッドゾーン・シンガマジグ・サーバー |
2.3.4 |
これには以下のコードを使ってください:
||~ 脆弱性のある製品 ||~ 修復済: ||
|| レッドゾーン・クロミュレーター3000シリーズ || 1.2.3 ||
|| レッドゾーン・シンガマジグ・サーバー || 2.3.4 ||
ですがこの部分は短くしてください-ここには客観的事実だけを書きましょう、何行もどの製品が影響を受けたかについて書くことは読者に読む気を失わせるでしょう。場合によってはこの部分を全く取り除くのが適切かもしれません。
異常痕跡指標
これはこの記事の中で最も重要な部分です。ここではどのような種類の異常が脆弱性の発生の原因かを説明します。SCP記事の説明部分のように、異常についてたくさんの情報を明らかにすると考えてください。
ワークアラウンド(任意)
レッドゾーンの顧客が危険性を軽減する、もしくは脆弱性を解決する手段について書いてください。SCP記事の収容手順のようなものと考えてください。
もし応急措置が存在しないのなら、この部分は除外してください。
修復されたソフトウェア(任意)
財団が新しいバージョンにアップグレードすることによってこの問題を修復できない理由があるなら、ここにその理由を書いてください。
この部分は必要に応じて、除外するか定形文に置き換えます。例えば、"ソフトウェアのアップグレードを検討する際には、レッドゾーンセキュリティ報告反応アーカイブを参照して、その後の勧告を確認した上で露出させるか完全な上位の解決法を判断することをお勧めします"。
私的利用と公表(任意)
この部分ではこのバグが財団レッドゾーンの顧客に与えた影響について説明できます。もしそれが全てを駄目にするなら、そう書いてください。この文書が発行されるまでに、脆弱性がどの程度知られていたのかも説明してください。
この部分は必要に応じて、除外するか模範例に置き換えます。例えば、"レッドゾーンセキュリティインシデントチーム(RSIT)はこの報告内の脆弱性のいかなる公表または故意の利用を発見していません"。
ソース(任意)
この脆弱性がどうやって発見されたのかについての背景または年表を載せることが出来ます。この部分は必要に応じて除外または定形文に置き換えられます。例えば、"脆弱性はレッドゾーンが内部セキュリティ試験を行っている間に発見されました"。
