1 / 20

“ Real time M onitoring and Control of Hydroelectric Dam”

“ Real time M onitoring and Control of Hydroelectric Dam”. Partecipanti: UNIPARTHENOPE POLITO CNR. Overview. Goal of the paper Proposed architecture Correlator GET Decision Support System Policy Conflict Resolution Reachability Analysis Resilient event storage Misuse case

shanta
Download Presentation

“ Real time M onitoring and Control of Hydroelectric Dam”

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. “Real time Monitoring and Control of Hydroelectric Dam” Partecipanti: UNIPARTHENOPE POLITO CNR

  2. Overview • Goal of the paper • Proposedarchitecture • Correlator • GET • DecisionSupportSystem • Policy ConflictResolution • ReachabilityAnalysis • Resilienteventstorage • Misuse case • Conclusion and Future Work

  3. Obiettivo del lavoro rispetto a TENACE • Description of an enhanced SIEM (Security Information and Event Management) systemwith the introduction of novelcomponents. • The proposed SIEM will be validated on a criticalinfrastructure scenario, namelya Hydroelectric Dam. • In particular, wedescribeda misuse case thatmimicsan attack to a DAM.

  4. Architettura Proposta • GET Component: an advanced security information and eventcollectorenabling multiple layer data analysis on SIEM frameworks; • a DecisionSupport System thatallowsboth to: • Resolvepolicy conflicts; • analyzeand control IT networks by allowing to discoverunauthorized data paths and performautomatic re-configuration of network devices; • a ResilientEvent Storage to ensureintegrity and unforgeability of alarmseven in the case of attackagainstitscomponents.

  5. GET • generate security events by observing multiple layer data from the sources in the monitoredinfrastructure. • The mostrelevantsources are physicalsensors, logicalaccessevents, physicalaccessevents, network systems and logs from networkedapplications. • Tranlstatesucheventsinto a common format whichissuitable for the central Correlator engine of the SIEM and for the DecisionSupport System. • preprocessdata in the collectionpoints and detectsanomalies in the cyber-physicalsystems (e.g. anomalies in the measuredparameters).

  6. Correlator • The Correlator analyzes the GET events in order to discoverknownattacksequences, i.e. sequencesencodedthroughschematicrules and stored in the rule database of the SIEM. • Correlator engineis a software component thatallows to detectspecificattackssignatures (security eventsequences) within the event flow received. • Whenan attacksignatureismatched, the Correlator generates an alarm. • The alarmgeneratedcontainsalso information about the eventsthatgeneratedit. • Alarmgeneration through Correlator isperformed in order to improve the accuracy of incidentdiagnosis and allowbetterresponseprocedures. • The Correlator shows fewsemanticallyricheralarms in the face of the hugenumber of eventscoming from single sensors.

  7. How the correlator works(brute force attackexample) The well-knownattackssignatures are definedthrough the {\emcorrelationrules}. In particular, a correlationruledescribes a relation between some information contained in the fields of eventsgathered in order to identify an attack. An example of correlationrulethat can be used, for example, to discover a brute-force attack.

  8. DecisionSupport System (DSS) • DSS hastwofunctionalities: • Policy Conflictresolution • Reachabilityanalysis

  9. DSS for Policy conflictresolution • Once the Correlator reveals an attack, some countermeasureshave to be taken in order to preserve the systemagainst a suchattack. • Countermeaseuresactaccording to specific policy describing the reaction to an event. • It can be the case thatdifferntpolicies are activeat the same time. • This can lead to the occurence of conflict.

  10. AnalitichHierarchyProcess • The AnalyticHierarchyProcess (AHP) is a multi-criteriadecisionmakingtechnique, whichhasbeenlargelyused in severalfields of study. • Givena decisionproblem, whereseveraldifferentalternatives can be chosen to reach a goal (solve the conflict), AHP returns the mostrelevantalternative (which policy wins the conflict)with respect to a set of previouslyestablishedcriteriaand subcriteria. • Practically, the AHP approachis to subdivide a complexprobleminto a set of sub-problems, criteria(element of a policy) and subcriteria (attribute), and then to compute thesolution by properlymerging the variouslocalsolutions for eachsub-problem.

  11. DSS for reachability • Goal: discover unauthorized traffic • caused by misconfigurationsor attacks • network reachability approach • which hosts reach a set of services • high level policies to define network behavior • runtime comparison between • generated rules: provided by refinement process • deployed rules: installed on firewalls • event-based reaction, e.g., • security issue: modify firewall rules to enforce a policy • non-enforceability: install a filtering control to enforce a policy • inference rules to manage: • workflow (refinement + reachability analysis) • events and reaction/remediation

  12. DSS architecture

  13. Network Policies <subject> reach <object> <subject>: e.g., IT Admins <object>: e.g., h1.service1

  14. System description hosts, IP addresses, services (ports, protocols), network topology

  15. Events anomaly (i.e., firewall ruleis more restrictivethan policy) security issue (i.e., unauthorizedtraffic)

  16. Decisions and Remediation e.g., modify firewall rules, add a new firewall (with correspondingrules) to enforce the policy

  17. Resielienceevent Storage • ResilientEvent Storage (RES) systemis an infrastructuredesigned: • to be tolerant to faults and intrusions; • to generate signedrecordscontainingalarms/eventsrelated to security breaches; • to ensure the integrity and unforgeability of alarms/eventsstored. • The RES fault and intrusiontolerantcapabilitymakesitable to correctly create securesignedrecordsevenwhen some components of the architecture are compromised. • Presentedyesterdayby Cesario Di Sarno (Uniparthenope)

  18. Case study • A wrongconfiguration: a data pathexiststhatallows an user in the 'visualization station' to re-write the sensorfirmware. • An unsatisfiedemployee: he/shediscoversthisvulnerability and he/shewant to exploit it to perform a seriousattack to the hydroelectric dam. • Thus, he/sheobtains the administratorcredentialsand logs in to the control machine in the 'control station' and manage the gate of the penstock. • The attackisperformed in twosteps: • 1) from 'visualization station', an unsatisfiedemployeeperforms a reprogramming of the sensorthatmeasures the water flow rate in the penstock. In particular a constant water flow rate valueissent to the control center in order to deceive the operator/a threshold control system; • 2) the unsatisfiedemployeeenters in the 'control station' usingitsown badge (RFID), performs a login with administratorprivileges, sends a command to open the gate and runsaway. • The operator or the classic control systemcannotdetect the attackbecause the sensoralwaystransmits a normal water flow rate value. Instead the turbine spins asfasterashigher the water flow rate is. Also, the electricpowergenerated and injected in the powergridincreases. • Thisattackfinisheswhen the electricpowergeneratedovercomes a security threshold. In that case the transmission line connected to the generator isoverloaded and a blackout islikely to occur.

  19. Conclusion and Future Work • Starting from different expertise, wehaveproposed a frameworkable to manageemergency in a powergrid scenario. • Wehavepresented the componentsweadd for enhancing a SIEM system. • We show the application of the proposedframework in a real scenario • Future Works • Setup of the system • Validation of the wholesystem on the presented case study.

  20. Thanksyou!

More Related