英國商業、能源和產業策略部(Business, Energy and Industrial Strategy, BEIS)於2018年4月17日發布公眾諮詢,議題為「最大化第一代(SMETS1)智慧電表的相容性(interoperability)」,該諮詢將截止於2018年5月24日。 英國對於SMETS1的推廣分為兩階段進行,基礎建設階段始於2011年,主要安裝階段則於2016年11月開始,國家數據及通訊供應商-資料通訊公司(Data Communications Company, DCC)自此階段開始營運,直至2020年智慧電表建置完成。 因現今由各能源供應商使用自身資料及通訊設備裝設第一代智慧型電表,造成消費者無法任意更換能源供應商之情況。對此,英國政府之長期政策目標雖為SMETS1最終可全數透過DCC進行運作,然由於現階段尚未強制能源供應商使用DCC所提供之服務,使用SMETS1的消費者仍無法自由的轉換能源供應商。 本文件提出了兩個方案向公眾諮詢: 要求能源供應商於六個月時限內至DCC註冊其所提供且合於規範的SMETS1,或將SMETS1更換為SMETS2(第二代智慧電表)。而於2020年12月31日前,所有未註冊之SMETS1將強制更換為SMETS2。 若能源供應商已嘗試所有合適的解決方法,仍無法於2019年底前使SMETS1在智慧模式下運作,就必須在2020年6月底前將SMETS1更換為SMETS2。 若供應商係於2019年後才取得SMETS1,於獲得SMETS1之後的六個月內採取所有相關措施後仍無法令SMETS1以智慧模式運作,亦應更換為SMETS2。最終,所有不能運行智慧模式之SMETS1將於2020年12月31日前被完全汰換。 英國政府期透過更完善的政策規劃改善現階段SMETS1透過個別能源供應商之數據及通訊系統運作之情況,以確保SMETS1之智慧模式於消費者更換供應商時能維持正常運作,使消費者可確實獲取改用智慧電表之利益。我國於2015年已開始推動低壓智慧電表建置,英國面臨之問題值得借鏡,政府於推廣低壓智慧電表之同時應注意智慧電表基礎設施之相容性,以增進低壓智慧電表建置效率及降低建置成本。
美國聯邦商務部修訂出口管制規則,對可用於惡意網路活動之項目出口、再出口與移轉進行管制美國聯邦商務部(Department of Commerce, DOC)下之工業及安全局(Bureau of Industry and Security, BIS)於2021年10月20日公布一暫行最終規則(interim final rule),對出口管制規則(Export Administration Regulation, EAR)進行修訂,其於商品管制清單(Commerce Control List)中增訂「可用於監視、間諜活動或其他破壞、拒絕、降低網路及其設備性能之工具」相關之出口管制分類編碼(Export Control Classification Number, ECCN)項目及說明文字,並增訂「授權網路安全出口(Authorized Cybersecurity Exports, ACE)」的例外許可規定(15 CFR §740.22),該暫行最終規則將於2022年1月19日生效。 被列入商品管制清單內的項目,原則上即不允許出口(或再出口、於國內移轉,以下同),惟透過ACE之例外許可,使前述項目可出口至大多數國家,僅在下列「再例外」情況需申請出口許可: 出口地為反恐目的地:出口目的地為15 CFR §740補充文件一所列類別E:1和E:2之國家時,須申請出口許可。 出口對象為國家類別D之政府終端使用者(Government end user):政府終端使用者係指能提供政府功能或服務之國家、區域或地方之部門、機關或實體,當政府終端使用者歸屬於國家類別D時,須申請出口許可。惟若類別D之國家同時被歸類於類別A:6(如賽普勒斯、以色列及台灣),在特定情況下,如為弱點揭露、犯罪調查等目的,出口予該國之電腦安全事件回應小組;為犯罪調查、訴訟等目的,出口可展現資訊系統上與使用者相關、對系統造成危害或其他影響活動之數位製品(digital artifacts)予警察或司法機關;或出口數位製品予前述政府,而該數位製品涉及由美國公司之子公司、金融服務者、民間健康和醫療機構等優惠待遇網路安全終端使用者(favorable treatment cybersecurity end user)擁有或操作資訊系統相關之網路安全事件時,不適用ACE之再例外規定,而不須申請出口許可。 終端使用者為國家類別D:1、D:5之非政府單位:結合上述第二點之說明,不論出口至國家類別D:1、D:5之政府或非政府單位,皆受ACE之「再例外」拘束,而須申請出口許可。僅當出口特定之ECCN網路安全項目予優惠待遇網路安全終端使用者、基於弱點揭露或網路事件回應之目的出口予非政府單位,或對非政府單位的視同出口(deemed export)行為,方不適用再例外規定,而不須申請出口許可。 終端使用者限制:已知或可得而知該物品將在未獲授權之情況下,被用於影響資訊系統或資訊之機密性、完整性或可用性時,須申請出口許可。
歐盟執委會關切奈米科技對於食品安全之影響近年來,奈米科技已多方使用於食品製造業中,舉凡食品的殺菌、保存或食材的包裝等,皆為適例。然而,隨著奈米科技的影響層面逐漸擴大,無論係其功用的研發或風險的防範,仍有進一步研究之必要。 歐盟執委會(European Commission)根據2007年3月其新興健康風險科學委員會(SCENIHR)所提出之報告,認為應加強認識奈米科技對於食品安全之影響,遂邀請歐洲食品安全局(EFSA)就該領域提出科學看法。至2008年10月14日,歐洲食品安全局科學委員會即公布「奈米科技對於食品和飼料所引起之潛在風險(Potential Risks Arising from Nanoscience and Nanotechnology on Food and Feed Safety)」草擬意見,其內容係說明奈米科技應用於食品製造業之多種樣態、人為奈米材料(engineered nano materials,ENM)於食品或飼料製造過程中所產生之作用,以及判斷現有之風險評估方式能否合於需要。 該草擬意見歸結數項結論如下: (1) 因人為奈米材料之體積微小且具有高表面積,於人體吸收時較一般物質更容易產生反應。 (2) 關於化學物質於奈米尺寸下將產生何種變化,迄今無法做出令人滿意之科學論斷,因此就安全性與相關數據的累積,仍需要個別檢視。 (3) 建議應針對風險評估一事設置國際基準,且該基準可同時適用於人為奈米材料及一般化學物質。 (4) 食品與飼料中含有人為奈米材料者,於風險評估時應包括該材料特性之敘述,並進行毒理研究分析,使資訊蒐集更為完備。 由於人為奈米材料不確定之事項甚多,因此需要更豐富的資料加以釐清;而該草擬意見除提供歐盟執委會評估現行法制、研究可行措施外,亦向公眾廣徵回應;民眾可於2008年12月1日前,提供歐洲食品安全局相關科學證據或意見,待該局進行彙整後,將與歐盟會員國商討後續事宜。
歐盟執委會公布「數位金融包裹」法案為鼓勵金融產業之創新,同時使其遵循應有之責任,並讓歐盟金融消費者與商業機構享有更多之利益,歐盟執委會於2020年10月24日提出數位金融包裹法案(Digital Finance Package),並提出以下2項數位金融立法提案: 一、加密資產立法提案(Proposal for Markets in Crypto-assets) 為促進金融創新並同時保有金融穩定性與保護投資人,歐盟執委會提出加密資產管制框架立法提案,並將加密資產分為已受監管與未受監管兩類,前者將持續依據既有規範進行管理。而針對尚未管制之加密資產,該提案針對加密資產發行人與加密資產服務供應商建立嚴格限制,要求取得核准後始可提供服務。具體而言之,立法提案包含以下項目: (一)針對加密資產、加密資產發行人等金融商品名詞進行定義。並建立加密資產服務供應商與發行人營運上、組織架構與資產發行程序之透明度與揭露制度。 (二)針對向公開市場提供加密資產進行管制,例如,依據提案第4條,供應商應為法人,第5條則要求供應商應製作加密資產白皮書,並將其提供給主管機關後始可於公開市場提供相關服務。 (三)針對代幣資產發行人以及其加密資產之審核程序,依據提案第15條,代幣發行者必須為歐盟境內之法律實體。另外,該法要求加密資產發行人應誠實、公平且專業,並完成加密資產白皮書之出版與制定市場溝通規則。 (四)針對加密資產之收購,該法第4章亦設有相關規範,於第37條及38條規定收購之評估機制。 (五)針對加密資產服務供應商之授權與營運條件,該法第5章規定歐盟證券及市場管理局應建立加密資產服務供應商之登記制度。 (六)針對市場秩序維護之部分,該法於第6章規範相關預防市場濫用之禁止事項與要求,並於第7章賦予歐盟成員國各主管機關相關權力,例如第94條之監督與懲處權限。 二、歐盟數位營運韌性管制框架立法提案(Proposal for Digital Operational Resilience) 數位化總伴隨資安風險,歐盟執委會於包裹法案內亦提出歐盟數位營運韌性管制框架立法提案,以確保相關企業可應對所有與通訊技術有關之干擾與威脅,另外,銀行、證券交易所、票據交換所以及金融科技公司將需遵循嚴格之標準以預防並降低ICT資安事件所產生之衝擊,另外亦將針對金融機構雲端運算服務供應商進行監管。具體規範包含: (一)ICT風險管理要求:該立法提案參照相關國際標準,於第5至第14條制訂相關ICT風險管理要求,惟未要求應遵循具體國際標準。 (二)ICT相關事件報告:該提案於第15至20條規範相關報告義務,將整合歐盟金融機構之ICT相關事件報告與監測程序。 (三)數位運作韌性測試:該提案於第21至第24條要求ICT風險管理框架應定期進行測試,惟具體方法可依據組織之規模、風險側寫與商務模式進行調整。 (四)第三方單位風險:該提案於第25至39條規範組織應對ICT第三方供應商風險進行監測,例如,第25條要求金融機構委外執行業務仍應隨時遵循所有金融服務規範,另外,ICT風險管理框架之內容亦應包含第三方ICT風險之監督策略。