Difference between revisions of "IoTSec:Security Challenges"
From its-wiki.no
Josef.Noll (Talk | contribs) (Created page with "= Security Challenges in Smart Grids = == General (seen for users aspects) == Error/Warning logging and handling * diagnostic tools and error reporting and handling * general...") |
Josef.Noll (Talk | contribs) (→Security Challenges in Smart Grids) |
||
Line 1: | Line 1: | ||
= Security Challenges in Smart Grids = | = Security Challenges in Smart Grids = | ||
+ | {{TOCright}} | ||
== General (seen for users aspects) == | == General (seen for users aspects) == | ||
Error/Warning logging and handling | Error/Warning logging and handling |
Revision as of 08:09, 14 October 2016
Security in IoT for Smart Grids | |||||||
---|---|---|---|---|---|---|---|
|
Security Challenges in Smart Grids
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