IoTSec:Security Challenges
From its-wiki.no
| Security in IoT for Smart Grids | |||||||
|---|---|---|---|---|---|---|---|
|
|
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.
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)
- PC requirements & protection
- programming and updating RTU programs
- protection against Intrusion
SCADA % split into physical and IT access
- 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
- communication with headendsystems
Other Physical Security requirements % can you sort in somewhere else
to be sorted
Communication Security Requirements % I suggest we take these communication req. together with the specific protocols
- protocols, algorithms, encryption algorithms, key length, tampering functions
- IPSec, TLS, SSH...
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
- DDoS
- Man in the middle
- malware
- any other threats and vulnerabilities