IoTSec:Security Challenges
From its-wiki.no
Security in IoT for Smart Grids | |||||||
---|---|---|---|---|---|---|---|
|
Security Challenges in Smart Grids
read also: Protection profile for Smart Meters - BSI - Germany: 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)
- 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