IoTSec:Security Challenges

= Security Challenges in Smart Grids =

read also: BSI Protection Profile BSI (the German Authority for Information Security) developed a so-called protection profile standardising security requirements. This protection profile exists, so far, in an abstract form and is only specified, in essence, for Smart Meter Gateways.

https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Zertifizierung/Reporte/ReportePP/pp0077V2b_pdf.pdf?__blob=publicationFile&v=1

General (seen for users aspects)
Error/Warning logging and handling
 * diagnostic tools and error reporting and handling
 * general logging: successful and failed login attempts

Authentication and Authorization of users
 * Authentication Servers single and multiple.
 * authentication server failure condition
 * user management

General System Aspects

 * security against modifying startup code
 * Firewalls (rules, whitelisting - “everything is forbidden”)
 * Tamper identification for assets
 * Time synchronization
 * Software updates

System Administration
% here I would suggest to establish an onion concept
 * Established onion configuration (most security-aware systems in the centre), layers around
 * Routines for identification of onion-machines (what kind of security for which kind of machines)
 * Configuration % of what??
 * security updates //software updates

RTU configuration %why are you concentrating on the RTU? as pointed out, I think the right approach is to have a security “shell” with specific requirements for each layer of the shell… (this includes both machines, access to control room, remote access) SCADA % split into physical and IT access
 * PC requirements & protection
 * programming and updating RTU programs
 * protection against Intrusion
 * How the traffic is secured? Authentication, protocols, certificates... ?
 * logging & troubleshooting
 * encryption
 * secured configuration

Private PCs and Mobile Phones
 * VPN requirement
 * mobile phone requirements

Other security measures
 * plugins like flash, ActiveX...
 * Secure headers % what do you mean here
 * external devices like USB

Smart Meter Systems
AMS (?) & Concentrators AMS is the “system”, right? Thus, where do we limit it? I suggest we split it up, into
 * AMR/Smart Meter (we had that topic already)
 * Mesh and communication (e.g. 2G or 3G/4G only?)
 * cloud management of AMR

Smart Meters

 * communication protocol and encryption in radio mesh % requirements to suppliers
 * how do they identify each other, - identity handling
 * encryption and key exchange
 * software update
 * meter (??) % what to you mean


 * authentication and authorization
 * key management

Smart Meter Mesh

 * communication protocol in radio mesh
 * frequency
 * encryption
 * mobile communication (modem capabilities), end-to-end encryption


 * robustness (e.g., duty cycles, tamper protection…)

Backend AMS/Cloud
Other Physical Security requirements % can you sort in somewhere else
 * communication with headendsystems

= to be sorted = Communication Security Requirements % I suggest we take these communication req. together with the specific protocols Monitoring and Logging of events % see suggestion earlier Is it (would it be) protected against Attacks? %don’t think you get an answer, ask for severity of the attacks (estimated) in the different shells
 * protocols, algorithms, encryption algorithms, key length, tampering functions
 * IPSec, TLS, SSH...
 * DDoS
 * Man in the middle
 * malware
 * any other threats and vulnerabilities