今さら聞けないセキュリティ　2020年03月30日

NXP SE050検証(テストWEBサーバーへの接続)(NXP SE050 WEB server connection test)

#はじめに#
2019/12/14に開かれた　IoTSecJPにてお時間をいただき
[セキュアエレメントとIoTデバイスセキュリティ](https://www.slideshare.net/KentaroMitsuyasu1/secure-element-for-iot-device)
と題してお話させていただきました。
その内容をベースにまとめていきたいと思います。

#テストWEBサーバーの準備#
SE050に書き込んだ証明書を使って、テスト接続するWEBサーバーを構築する。

[自分用ngrokをauthtoken対応にする(self hosted ngrok)](https://qiita.com/kmitsu76/items/36a4ba952ccb88e2a2ad)で作った自分用ngrokを使い、独自ドメインで証明書を作成、適当なポート番号で手元のラズパイゼロにTCP通信をあける。今回は50020とした。

ラズパイゼロにnginxでテストサーバーを構築していく。
以下を参考にさせていただいた。
https://emc-craft.xyz/raspberrypi/nginx

NXP SE050検証(証明書プロビジョニング)(NXP SE050 certificate provisioning)

#はじめに#
2019/12/14に開かれた　IoTSecJPにてお時間をいただき
[セキュアエレメントとIoTデバイスセキュリティ](https://www.slideshare.net/KentaroMitsuyasu1/secure-element-for-iot-device)
と題してお話させていただきました。
その内容をベースにまとめていきたいと思います。

#証明書の書き込み#
SE050を使ってWEBサーバーへつなぐテストを行いたいが、SE050で生成したパブリックキーへ署名して、証明書を作成し、書き戻してTLSセッションで利用できるようにしなくてはならない。

前回、[NXP SE050検証(証明書読み出し)(NXP SE050 cerificate extraction by using ESP32)]( https://qiita.com/kmitsu76/items/91829a15025ee2afa925)でプリセットされていた証明書を読み込んだが、今回は同様に証明書を作成し書き戻してみる。

ユーザーが使えるObjectIDはex_sss_objid.hに定

NXP SE050検証(I2C経路暗号化)(NXP SE050 encrypting I2C transmission)

#はじめに#
2019/12/14に開かれた　IoTSecJPにてお時間をいただき
[セキュアエレメントとIoTデバイスセキュリティ](https://www.slideshare.net/KentaroMitsuyasu1/secure-element-for-iot-device)
と題してお話させていただきました。
その内容をベースにまとめていきたいと思います。

#I2C通信の暗号化#
ホストマイコンからI2Cで鍵情報を送る際、ロジアナで読み取られないようにI2C経路を暗号化したい。
ATECC608Aでは、IOProtectionKeyというもので暗号化、復号を行いI2C経路を守る仕組みを備えていた。

同じようなことがSE050 でできないか。

現状のNXP SE050を動作させるテストコード[NXP SE050検証(ESP32への

【SC試験対策】鍵を利用した暗号化とディジタル署名の図解と具体例

# 目的
SC試験でも頻出の鍵を利用した技術に関して整理したので記録を残しておきます。
技術的に深いところを理解するというより技術の概要理解を目的としています。
お気付きの点（技術的な点や本記事の構成などなんでも）ありましたら、コメントいただけると幸いです。

# 鍵を利用した暗号化とディジタル署名の目的
まず、それぞれの技術について目的を確認しましょう。
鍵を利用した暗号化の目的の目的は、【盗聴対策】です。
送信側で、平文を***暗号化***し、受信側で***復号***することで盗聴の心配なく、ネットワーク上にデータを流すことができます。

一方、ディジタル署名の目的は【改ざん対策】と【なりすまし対策】です。
インターネットという荒波を超える途中で攻撃者による改ざんが行われていないことを保

CEHのECEクレジット取得方法

# 1. この記事の要約（3行まとめ）
– **ECEクレジットはCEHの維持に必要なポイント。**
– **資格の維持には3年間でECEクレジットが120ポイントと、年会費が80ドル必要。**
– **ポイントの取得が比較的容易なのは「CNDに合格」、情報セキュリティ関連の「資格試験に合格、書籍等のレビュー、トレーニングの受講、イベント等への出席、イベント等でのプレゼン」の6種類。**

# 2. この記事の対象読者
– CEHの合格を目指している人。
– CEHに合格した人。
– CEHの維持・更新にECEクレジットが必要なことは知っているが、何をすれば取得できるのか分からない人。

# 3. ECEクレジットとは
– 正式名称：EC-Council Continuing Education Credits
– 略称（日本語表記）：ECEクレジット
– 説明：ホワイトハッカーの認定資格であるCEH（Certified Ethical Hacker）の維持・更新に必要なポイント。情報セキュリティに関する活動や学習を継続的に行っていることを証明するためのポイントであり、合格から3年毎に

強秘匿性と識別不可能性(暗号理論)

# はじめに
暗号には大きく、二人が同じ鍵を持つ**共通鍵暗号**と暗号化鍵を公開し復号化鍵を秘密にする**公開鍵暗号**があります。この公開鍵暗号は暗号化鍵を公開しているため、共通鍵暗号にはなかったセキュリティを考える必要があります。なぜなら、攻撃者になりうる第三者もこの公開された暗号化鍵が取得可能になるため、攻撃者は自分の持っている平文を自由に暗号化でき、**平文と暗号文のペアをいくらでも取得することが可能になる**からです。この攻撃手法は**選択平文攻撃**(Chosen Plaintext Attack, CPA)と呼ばれており、公開鍵暗号はこの攻撃に対して安全であることが必須となっています。(復号オラクルが利用できると仮定して、暗号文から平文が取得できる選択暗号文攻撃(Chosen Ciphertext Attack, CCA)に対しても安全であることが望ましい。)
ここでは、公開鍵暗号が安全であることが言える暗号の性質である、**強秘匿性**(semantic security)と**識別不可能性**(indistinguishability)について説明します。また、この

[月次配信] PowerShellの難読化分析及び解読

#概要
PowerShellはシステムの関係者のために特別に設計されたWindowsのコマンドシェルである。Windows 10 Redstone 1703 Bild 2のアップデート後、コマンドプロンプト(cmd)がWindows PowerShellに変更された。
OSとプロセスを管理する機能の全般を制御できるAPIと単一関数コマンドツール(cmdlet, Command-Let)を持っているため、比較的に短いソースコードで効果的な性能を出せるPowerShellは攻撃者によってよく使用された。

PowerShellの代表的な脅威はコマンド制御(C2)サーバから追加不正コードをReflective DLL Injectionなどの様々な攻撃方法を使用して、システムメモリに直接アップロードさせるFileless Attackがある。PowerShellは2014年発見されたPoweliks不正コードが急増し、2017年の統計によると、PowerShellスクリプトの中で不正コードが95.4%[report from Symantec]に達する程、多くの不正コードが存在する。最近発生

インシデント初期対応に使えるCDIR Collecterについて

サイバーディフェンス研究所が開発しているインシデント初期対応でつかえる情報収集ツールです。
本記事ではツールの説明にとどまり、それぞれのログの見方などについては別途記事を書きたいと思います。

#CIDRツールとは
インシデントの初期対応で使える情報収集に有用なツールです。

下記のような情報が得られます。
**実行すると得られる情報**
– メモリ
– MFT
– Change Journal
– イベントログ
– プリフェッチ
– レジストリ

**↑の情報をもとにわかること例**
– 現状不審な動作が継続しているかどうか 　→メモリ情報などから調査
– 今回検知されたファイルの侵入時期 　→MFTから
– 検体の実行可否と実行時刻 　　→プリフェッチから
などなど。。。

#使い方
ダウンロードしたフォルダ内のexeを実行するだけ。
具体的な手順は下記の外部サイトを参照のこと。
>初動対応用データ保全ツール「CDIR Collector」解説
>https://www.atmarkit.co.jp/ait/series/3945/

**※実行場所について**
端末上で直接実行す

TCP SACK PANIC(CVE-2019-11477)を読み解くための英文法

# CVE-2019-11477
[https://access.redhat.com/security/cve/CVE-2019-11477](https://access.redhat.com/security/cve/CVE-2019-11477)

An integer overflow flaw was found in the way the Linux kernel’s networking subsystem processed TCP Selective Acknowledgment (SACK) segments. While processing SACK segments, the Linux kernel’s socket buffer (SKB) data structure becomes fragmented. Each fragment is about TCP maximum segment size (MSS) bytes. To efficiently process SACK blocks, the Linux kernel merges mu

脆弱性を直した後のセキュリティテスト（SQLインジェクションの場合）

脆弱性が報告されてから修正が完了するまでに、Webアプリケーション開発者(またはテスター)ができることをセキュリティテストを中心に書く。

1. 再現手順の確立
2. 原因究明
3. 対策の実行
4. 修正の確認
5. セキュリティテスト

セキュリティテストってどうやればいいの？というエンジニアの参考になればいいなあ。

※本記事のサンプルコードは C# + Entity Framework だが、プロセスは他の言語やフレームワークでも通用する。

## 1.再現手順の確立

※注意：再現行為を本番環境でやるのは危険すぎるので、検証環境でやるのがよい

脆弱性が報告されたら、通常のバグ修正と同じように、まず脆弱性を再現させる。（TDD風に言うなら、レッドになるテストを作る）

SQLインジェクションの場合、主にHTTPリクエスト（HTTP の URL、ヘッダ、本文など）が再現手順になる。あらかじめ Web サイトへのログインが必要な場合は、それも再現手順に含めておく。

再現手順を確立しておくことで、修正後に再現しなくなる（テストがグリーンになる）＝修正できたことを確認できるようにな

WEBアプリのログイン機構のセキュリティチェック観点

ログイン関連の機能開発するときに、私が確認している項目

**[重要!!]金融、行政システムなど、業界独自の法規・基準は意識していません**

## 結論

もろもろいろいろ面倒なので、ログインロジックの自作は極力避けましょう。
SNSとかのソーシャルログインがいいです。
作るの大変ですけど、運用が相対的に楽になります。

あと、不必要に個人情報持つのもやめましょう。
持っちゃうと後が大変です。。。

## リスク評価観点

* ログインユーザに紐づけて以下の情報を保持するか？
* 個人情報
* 個人を特定可能な情報
* メールアドレスだけでも個人情報
* cf. https://www.soumu.go.jp/main_sosiki/gyoukan/kanri/question03.html
* 総務省では、「メールアドレスだけでも個人情報になる場合がある」としているので、
そういったアドレスを排除できない以上、メアドだけでも個人情報を持っていることになる
*

【Sign in with Apple】「xxxxx@privaterelay.appleid.com」へメールを送った際バウンスする

# はじめに
Sign In with Apple（Appleログインと後述）が2019年に発表され、2020年4月には必須化になるなか導入の際にハマったインフラ系のことについてメモ書きしておきます。
私はiOSエンジニアではないですがPMやっていたときに遭遇しました。
ユーザ登録時にAppleログインで会員登録する際にメールアドレスをサービス提供側に公開するか非公開にするか選択があります。
非公開を選択した場合、サービス側が取得できるメールアドレスは「xxxx@privaterelay.appleid.com」になります。
本家サイトには「xxxx@privaterelay.appleid.com」に返信すれば登録ユーザに届くというようなことを書いているけどもGmailで送信した場合に下記の様にバウンスしてきました。これの解決方法です。

![apple_bounse.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/397770/7be4cf0d-d06b-67df-59e2-edc3420929f0.

セキュリティマネジメントの勉強-リスク分析と評価

#リスク分析と評価
リスクマネジメントを行うためには、情報資産を調査し分類する必要がある。
それを情報資産台帳にまとめる。

##情報資産の調査
ISMSの適用範囲で用いられている情報資産の調査を行う。
部門ごとに漏れの内容にリスクを洗いだす。
過去の事件や事故、損害額なども考慮し、脅威と脆弱性を認識する。

##情報資産の重要性による分類と管理
単独で管理すると分析がつらい。
そのためグループ化して管理する。

##情報資産台帳
機密性や重要性、分類グループなどをまとめたのを情報資産台帳という。
情報資産をもれなく記載するだけでなく、変化に応じて適切に更新していくことも必要。

#リスクの種類
##リスク
リスクとはまだ起きてはないが、起こると情報資産に影響を与える事象や状態のこと。
すでに起こったことはリスクではなく問題として処理する。
また起こっていない、起こるかどうかが不確実なことを、リスクとして洗い出す。

##リスク源
リスク発生源（リスクソース）を除去することが有効なリスク対策となる。

##リスク所有者
リスクを洗い出し、リスクとして特定したら、リスク所有者を決定する

セキュリティマネジメントの勉強-情報セキュリティ継続

#情報セキュリティ継続
##緊急事態の区分
緊急事態の区分を明らかにしておく必要がある。

| レベル |事象 |
|—————–:|:——————:|
| 1 | 影響を及ぼすおそれのない事象 |
| 2 | 影響を及ぼすおそれの低い事象 |
| 3 | 影響を及ぼすおそれの高い事象 |

##緊急時対応計画
Contingency Plan
サービスの中断や災害発生時に、システムを迅速かつ効率的に復旧させる計画。

初期の対応計画では、初動で何をするかなどを中心に組む。
完全復旧よりも暫定対応を優先することもある。

##復旧計画
緊急対応後、完全復旧させるための計画です。
暫定的ではなく、恒久的な復旧を目指す。

##障害復旧
日頃からバックアップを取っておくこと。
バックアップデータはシステムのそばに置いてるほうが復旧が早いが
地震とかの大災害時を想定すると、遠隔地に保存しておくことも必要。

##ディザスタリカバリ
事業継続マネジメントのおける概

情報共有ツールで意図しない情報漏洩を防ぐための設定

## はじめに
開発に限らず様々なプロジェクトで、Google DriveやTrello等のチーム内情報共有を円滑にするためのツールを使う機会は多いと思います。
ただ、うっかり設定を誤ってしまうと思わぬところで情報漏洩をしてしまうことなどがあります。
本記事ではそのような誤りがないように設定する手順をまとめます。

## Google Drive
#### リンク共有による意図しない情報漏洩を防ぐ
チーム内でファイルを共有するためにリンクURLを共有することがあると思います。
この共有可能リンクはデフォルトで「リンクを知っている人は**誰でも**アクセス可能」となるため注意が必要です。

##### リンク共有手順

（ファイルを開いた状態の場合）
「共有」をクリックします。
Spring SecurityでDB認証&BCryptでハッシュ化

# 概要
* Spring Securityで必要最低限のログイン機能を実装する。（権限周りは触れません。）
* ログインフォームなどはSpring Securityで用意されているものを使う。
* 仕組みはあまり理解できていないので、また別でまとめます。
* この投稿はとりあえず、動くようになったというところまで！

# 開発環境
* OS：Windows10
* IDE：eclipse 2019-12
* Java：13
* Spring boot：2.2.5(Gradle)
* DB：Oracle 12c

# Spring Securityの導入
## 依存関係で下記の4つを選択
* Spring Security
* Spring Web
* Spring Data JPA
* Oracle Driver ←使用するDBのDriverを選択してください
![2020-03-15-14-06-34.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/364697/5974c5b7-

[月次配信] 月次攻撃サービスの統計及び分析 – 2020年2月

#はじめに
株式会社サイバーフォートレスでは攻撃サービス(ポート)情報を収集し、分析しています。
分析内容から、月次攻撃サービス（ポート）、月次攻撃サービスパターンのTOP10を確認し、過去データと比較し、攻撃トレンドへの対策を考えます。
セキュリティ担当者または、システム管理者はこのようなデータ分析を活用してサイバー脅威の予測に役立てていただければと思います。

#月次攻撃サービス(ポート)TOP 10
2020年2月の一か月間収取されたイベントの分析結果、先月とほぼ同じ推移でみられている。月次攻撃サービスTOP 10は、全体の件数と比べて減少した。全体的な特異事項はない。

| 順位 | サービス(ポート) | 比率(%) |
|:—-:|:———————:|:——-:|
| 1 | HTTP(TCP/80) | 45.75% |
| 2 | DNS(UDP/53) | 18.17% |
| 3 | Microsoft-DS(TCP/445) | 15.12% |
|

自動車の電源・電池と計算機・通信

自動運転系の安全分析をするにあたり、電気自動車の電源・電池と計算機・通信について網羅的な調査を始めるために、

「自動車　複数電池」で検索した。

主な検索結果と、その記事中で参照している一次情報、参考文献などを列記する。

これは、自動車の安全を確保するためには、通信・サーバ、ECU(CPU)などが乗っ取られないことが重要であるが、これまでの安全対策で漏れているところがないかを探す作業の一つである。

#1.
自動車用リチウムイオン電池を活用した 電源システム, 境野 真道, 九州工業大学/日産, 2015
https://kyutech.repo.nii.ac.jp/?action=repository_action_common_download&item_id=4509&item_no=1&attribute_id=16&file_no=1

参考文献
[1] (社)次世代自動車振興センター, “電気自動車等保有台数統計(推定値)” [オンライン]. Available: http://www.cev­pc.or.jp/tokei/hanbai.html [アクセス日:

「3分で理解するWEBプログラミングセキュリティ 02」クロスサイトスクリプティングとは?

# 3分で理解するWEBプログラミングセキュリティ 0２
**3分で理解するWEBプログラミングセキュリティ**
↓↓記事が出来次第Link貼って行きます↓↓
**No.01 SQLインジェクションとは?**
**No.02 クロスサイトスクリプティングとは?**
**No.03 クロスサイトリクエストフォージェリとは?**
**No.04 ディレクトリトラバーサルとは?**

1.クロスサイトスクリプティングとは?
・概要
2.クロスサイトスクリプティング対策(PHPでの実装例)
・対策方法
・実装例

##1.クロスサイトスクリプティングとは
**概要**
攻撃者は、まずターゲットとなる企業を見つけ、その企業に興味を持ちそうなユーザーが訪れる掲示板サイト上で罠(スクリプト付リンクを貼るなど)を仕掛けます。ターゲットの企業に興味を持ったユーザーが、掲示板サイト上で仕掛けられた罠にかかると、攻撃者が掲示板サイト内でスクリプトを実行します。
ユーザーはスクリプト情報を持ったままターゲット企業のページに移動することになるのですが、実は、ジャンプ先はターゲット企業を装った偽サイトで

Linuxでファイル入出力のログを取りたい

#やりたいこと
ユーザがＰＣとＵＳＢメモリやＳＤカードをつないでデータを出し入れした時の
ログをとりたい。また、勝手にユーザが監視プロセスを落とせないようにしたい。
#インストール
inotify-toolsをインストール

“`
sudo apt-get install inotify-tools
“`
#試してみる
“`
qiita@ubuntu:~$ inotifywait -m .&

“`
mオプションをつけないと、１回出力するとコマンドが終了するとのこと。

“`
qiita@ubuntu:~$ ls
Desktop Documents Downloads Music
./ OPEN,ISDIR
./ ACCESS,ISDIR
./ CLOSE_NOWRITE,CLOSE,ISDIR
qiita@ubuntu:~$
qiita@ubuntu:~$

“`
lsで監視しているディレクトリにアクセスすると何か表示されている。

サブディレクトリはどうだろう

“`
qiita@ubuntu:~$ mkdir hoge
./ CREATE,ISDIR