Pasi Ahonen,

Transkriptio

1 Käyttöönotettavan järjestelmän tietoturvallisuuden evaluointi (& TITAN Data Security for Industrial Automation - A project funded within TEKES Safety and security Program) Pasi Ahonen,

2 Esityksen sisältö TITAN projektin tavoitteita ja tuloksia TITAN projektin motiivit Tietoturvatestaustyökalujen evaluaatio Automaatiojärjestelmän tietoturvatestaus Parhaiden Käytäntöjen kuvauksesta Automaatiojärjestelmän tietoturvan evaluointi Yleistä automaatiojärjestelmän evaluaatiosta Evaluaation tavoitteet ja vaiheet Evaluaatiokohteen ja tutkittavien ominaisuuksien määrittely Evaluaatiokriteeristön määrittely Evaluaatiometodien ja -työkalujen määrääminen Evaluaatiotulosten raportointi 2

3 TITAN projektin motiivit

4 Tietoturvatestaustyökalujen evaluaatio 4

5 Criteria Criteria Description Possible Grades/Values TITAN työkaluevaluaation kriteeristö Purpose Phase Commercial Maturity Platforms Test Domain Extension/ Future proof Mitigation Automation Reporting ICS applicability Basic description of tool purpose and usage Phase of use in system lifecycle Costs and availability Readiness and completeness of the tool for full industrial use Systems supported & Optionally: System reqs Target & Scope of security analysis or test Possibilities to extend testing or connect to other functions or data Support for vulnerability fixing and mitigation Analysis or test automation level Reporting facilities and formats Listing of properties of the tool that may help the usage in various Industrial Control Systems (ICS) Free text about tool s purpose plus the type of test, e.g. (Port scanner/ Static analyser/ Dynamic analyser/ Protocol fuzzer/ Load tester/ Port scanner/ Vuln. scanner/ Protocol analyser/ Debugger etc.). Relevant phase(s): (Feasibility/ Design/ Implementation/ Testing/ Deployment/ Maintenance) (Price/ Free/ Open source). (Possible Availability estimates) List of reference usage (Maintained by/ Beta release only/ Uncertain) (MS/ Linux/ Mac). Optionally: Reqs for: Disk, CPU, Memory Analysis Target: (Sourcecode/Bytecode/Executable). Runtime Target: (No support/ Systems/ Interfaces). Analysis Scope: (Line/ Command/ Function/ Module/ Program/ System) Free text about Customizable test cases, Import & Export of models, data and vulnerabilities, Rule updates, Plug-ins Free text about Mitigation functions & properties, Hardening, IDE support Free text about automated functions & properties List of supported reporting facilities, formats and standards Embodiment of critical properties (such as: Reliability, Dependability, Interdependencies, Real-time properties, Protocol support, Language & OS support, Fast deployment, Vulnerability types) Ease of use Ease of use & deployment of the tool Free text about ease of use & deployment issues Notes Important other issues to notify List of Strengths and Weaknesses. (E.g. Accuracy, % of false positives, etc.) 5

6 TITAN Työkaluevaluaatio (results snapshot) 6

7 Best tools in TITAN Tool Purpose Phase Commercial Maturity Platforms Test Domain Extensions Mitigation Automation Reporting ICS Applicability Ease of Use Notes Achilles Satellite Specifically for ICS. Protocol testing. Network attack simulation Implementation, testing, deployment, maintenance Commercial. The Achilles Satellite Hardware Platform 1 year fee is $ Used by several companies Comes with hardware. Client is for Windows Industrial automation systems Additional protocol testers No Highly automated Generates PDF reports Designed especially for ICSs. Support for many industrial automation protocols Easy Independent industrial PC (Ubuntu) with special hardware, test applications and data. Operated remotely with a Windows-only client software. Satellite includes tests for following protocols: ARP, BOOTP, CIP, DCOM, DHCP, DNP3, Ethernet/IP, FTP, HTTP, ICCP, ICMP IGMP, IPv4, LLDP/LLDP-MED, MODBUS/RTU, MODBUS/TCP, MMS, NTP, RPC, SNMPv1, SNMPv2c, SNMPv3, TACACS+, TCP, Telnet, UDP and Vnet/IP. Testing with Achilles is usually sold as a service to customer. Passing the tests with Satellite is required for Achilles Cyber Security Certification. 7

8 Best tools in TITAN Tool Purpose Phase Commercial Maturity Platforms Test Domain Extensions Mitigation Automation Reporting ICS Applicability Ease of Use Notes Codenomicon Defensics Model-based fuzz testing Implementation, testing, deployment, maintenance Yes Tools have been developed for ca. 10 years Linux, Windows Protocol interfaces No Test cases are ran automatically Tool generates test log and summaries Highly applicable. Test sets for some industrial automation protocols The tool is easy to use and run. Both command line and GUI are available Detects faults from protocol implementation. May crash or slow down the target application during tests. Very effective test method. Includes ca.130 different protocol test suites. 8

9 Best tools in TITAN Tool Purpose Phase Commercial Maturity Platforms Test Domain Extensions Mitigation Automation Reporting ICS Applicability Ease of Use Notes Nmap Port scanning, network mapping Implementation, testing, deployment, maintenance Free, GPL Years of development Linux, Windows, BSD Running, networked systems No No Partial Text files Depends on devices used in ICS network. Often very applicable Basic scanning is easy, especially with a graphical front-end. Advanced use requires studying. 9

10 Best tools in TITAN Tool Purpose Phase Commercial Maturity Platforms Test Domain Extensions Mitigation Automation Reporting ICS Applicability Ease of Use Notes Tenable Nessus Vulnerability scanner Implementation, testing Commercial, free for home users Widely used, developed for years Linux, Windows, OS X Various targets, mainly running networked systems Plugins for various purposes Warnings of dangerous services or software versions Running the test is automated Generates a.html report SCADA Plugins Easy to use GUI Finds only vulnerabilities from database. Vulnerabilities are written to database with NASL language. Tests include port scans, and if e.g. ftp port is open tool attempts anonymous login. 10

11 A Potential exploit tool Tool Purpose Phase Commercial Maturity Platforms Test Domain Extensions Mitigation Automation Reporting ICS Applicability Ease of Use Notes Metasploit Framework 3.2 Exploit development and excecution. Penetration testing Implementation, testing, deployment, maintenance Free, BSD De facto vulnerability development framework Linux, Windows Various targets Yes No Automates vulnerability exploitation No Very applicable, especially if ICS contains older IT systems Easy to use GUI, but building exploit modules and shellcodes requires experience Framework includes over 300 different exploits for Windows, Unix/Linux and Mac OS X systems 11

12 A Potential web tool Tool Purpose Phase Commercial Maturity Platforms Test Domain Extensions Mitigation Automation Reporting ICS Applicability Ease of Use Notes Nikto Web server vulnerability scanner Implementation, testing, deployment, maintenance Free, GPL Yes, active development Linux Web servers No Warns from vulnerabilities Scanning is automated Text file Many ICS devices (e.g. switches, process controllers) include web servers Simple command line use Performs comprehensive tests against web servers for multiple items, including over 3500 potentially dangerous files/cgis, versions on over 900 servers, and version specific problems on over 250 servers. Most vulnerabilities which are found are not dangerous in ICS environment. 12

13 A Potential monitoring tool Tool Purpose Phase Commercial Maturity Platforms Test Domain Extensions Mitigation Automation Reporting ICS Applicability Ease of Use Notes Nethawk ipro & Flow Analyser Network traffic high-performance capturing, monitoring and analysis Implementation, testing, maintenance Yes Quite new product. Active development Comes with specific hardware. Flow analyser client for Windows only Network traffic Flow Analysis, QoS and Snort IDS No Visualisations and network captures Good for monitoring purposes Requires some training. Web based GUI or remote SSH connection Database based network traffic visualisation capabilities. Tool includes many advanced features for different kind of uses 13

14 TITAN Automaatiojärjestelmän tietoturvatestaus 14

15 Pääasiallinen tietoturvatestauksen kohde: MetsoDNA CR (+Test setup) Achilles Satellite 15

16 Käytetyt työkalut Source code analysis: CPPcheck Security testing related: Codenomicon Defensics (SNMPv2, HTTP Server, Telnet, WLAN, Modbus ) Achilles Satellite Nmap Netwox Yersinia Aircrack Tenable Nessus 3 Nikto SNMPWalk Metasploit Framework Backtrack 4 beta Monitoring: Nethawk ipro Clarified Analyzer Wireshark 16

17 Tietoturvatestauksen johtopäätökset Carry out testing during R&D or at least before deployment Testing of proprietary protocols is challenging, a proprietary tool or at least heavy tailoring of a common tool is often required Commercial tools are often easy to use and well documented. Open source tools are more difficult to use and less integrated Security testing in industrial automation requires a lot of manual work and supervision to get it done well Defense in depth: Also the automation network devices require security/robustness testing (but not online) Web services etc allow easier testing using standard SA tools 17

18 TITAN Parhaiden käytäntöjen kuvauksesta 18

19 De facto -standardien evaluointi Evaluation criteria Quality Usability, purpose ja scope Merits Regulation Maintenance and availability Specials Explanation Subjective quality level How general purpose is the standard? Too broad or too constricted References. How often the standard is in use in relevant organisations? Mandatory usage? Is a state authority or other organisation mandating the use? How well is the standard updated and is it generally available? (Open / $ / Closed) How well the specifics of industrial automation are taken into account? Rational Good quality and substance are required Practicability and usability taken into account Earlier adapters add trust Regulation directs the activities Openness improves quality and availability Sector specific requirements such as dependability

20 Parhaiden käytäntöjen kehittämisen prosessi TITANissa 1. First, we initially identify the best standards and practices available 2. Next, we describe such standards in general level 3. Then, we evaluate such standards with Finnish companies and organisations 4. Then, we assemble the best practices for the use of Finnish parties 5. Finally, we inform the industry about the assembled best practices within seminars and material

21 TITAN Parhaiden käytäntöjen kuvausten muoto Threats Why protection is needed? Some typical threats and vulnerabilities Practice description 1. Requirements Reqs for correct operation Fundamental reqs Additional reqs Non-reqs what should not be done 2. Actions required to protect Simple description of what actions to do in practice The list of desired results of the actions 3. Typical roles for each action (optional) Client / Vendor / Integrator 4. Relevant phases of SDLC (optional) Order / Deployment / Maintenance Example practice (optional) If possible, give e.g. one A4 guideline or other example practice, e.g. a check list

22 Automaatiojärjestelmän tietoturvan (tt) evaluointi 22

23 Yleistä automaatiojärjestelmän tt-evaluaatiosta Erilaiset automaatiojärjestelmät ja niiden yksittäiset komponentit vaativat erityiskäsittelyä kun ajatellaan operatiiviseen ICS toimintaan otettavan tieto- tai kommunikointijärjestelmien tietoturvan arvioimista. ICS alueen järjestelmien tietoturva-arvioinnissa on otettava huomioon useita erityispiirteitä jotka voivat olla jopa ristiriidassa toistensa kanssa, jolloin on löydettävä tasapaino eri asioiden välillä. Usein täytyy ensisijaisesti varmistaa tuotantoa ohjaavien ja seuraavien järjestelmien käyttövarmuus ja oikea toiminta, kun taas tietoturvaominaisuudet täytyy olla kyllä kunnossa mutta ne eivät saa aiheuttaa häiriöitä jotka voisivat heikentää käyttövarmuutta. Toinen ulottuvuus on erilaiset arviointimenetelmät ja niiden käyttö. Suomalaistenkin toimijoiden käyttöön on yleisesti saatavilla esimerkiksi avoimia ja kaupallisia tietoturvahaavoittuvuuksien sekä käyttöjärjestelmien ja erilaisten sovellusten konfiguraatioiden turvallisuutta määrittäviä ohjelmistotyökaluja, mutta niiden soveltuvuutta ICS alueella toimivan organisaation tai yrityksen voi olla vaikea arvioida. Tietty menetelmä tai työkalu voi esimerkiksi listata käyttäjälle 600 erilaista varoitusta järjestelmän tietoturvaan liittyen, mutta käyttäjän voi olla hankala soveltaa tulosta järjestelmän kehittämiseksi tai sen arvioimiseksi onko järjestelmän turvallisuus riittävällä tasolla. 23

24 Evaluaation tavoitteet Tietoturvaevaluaation suorittamiseksi tarvitaan taustatiedoiksi käyttöönotettavan järjestelmän tai tuotteen tietoturvatavoitteet, vaatimukset, asennuspisteessä vallitseva tietoturvapolitiikka, ym. relevanttia pohjatietoa. Näiden määrittelemisessä on voitu käyttää apuna valmiita skelettejä (esim. API Std 1164, Annex B: SCADA-järjestelmän tietoturvasuunnitelma). On välttämätöntä tuoda esiin ja kiinnittää nämä olemassa olevat taustavaatimukset tietoturvalle, tai jos niiden määrittely on kesken, viimeistään nyt tarkemmin määritellä ne ennen tietoturvaevaluaation aloittamista. Alue on laaja ja monimutkainen. Kunkin operatiivisen toiminnan tietoturvatavoitteisiin ja vaatimuksiin vaikuttavat mm. ko. teolliselle toiminnalle asetettu lainsäädäntö, sääntely, asiakassopimukset, yleisen turvallisuuden ylläpitäminen, jne, kaikki yhdessä. Evaluaatio perustuu ennen kaikkea vertailuun, mahdollisimman varman tiedon keräämiseen siitä ovatko evaluaatiokohteen ominaisuudet tavoitteiden mukaiset. Jos kohde ei täytä ennakkovaatimuksia, yleensä on järkevää selvittää ja kirjata lisäksi: Millaisia löydetyt poikkemat ovat?, Miten paljon poikkeamia on?, jne 24

25 Evaluaation tavoitteet Tietoturvaevaluaation tavoitteita voi olla mm. seuraavanlaisia: Vastaako järjestelmän (käyttöjärjestelmä, sovellukset, tietoliikenne, jne) asetukset tiettyä esimääriteltyä mallia, ns. sallittua konfiguraatiota? Kestääkö järjestelmä toiminnassa vaikka sitä vastaan suunnataan tietyn tyyppisiä tietoturvahyökkäyksiä (esim. palvelunestohyökkäykset, robustness-testaus, jne) Onko järjestelmän toteutukseen jäänyt tietoturvahaavoittuvuuksia (kuten puskuriylivuodot, puutteellinen input/output käsittely, tms.)? Onko järjestelmästä poistettu kaikki sellainen toiminnallisuus joka ei ole käytössä (esim. web-palvelin ohjelmistot, toimisto-ohjelmistot, jne.) Onko huolehdittu ohjelmistojen päivitysominaisuuksien turvallisuudesta? Entä vikojen korjaamisesta? Onko järjestelmässä huomioitu haittaohjelmien torjunta? Miten? 25

26 Evaluaation päävaiheet Huolimatta kaikesta edellämainitusta lähtökohtien moninaisuudesta, järjestelmän tietoturvaevaluaatiokokonaisuuden voidaan määritellä koostuvan seuraavista päävaiheista: 1. Evaluaatiokohteen määrittely, sis. evaluaation alaisten kohteiden rajaus 2. Evaluaatiokriteeristön määrittely (sis. vaatimukset tietylle sec zone, sec level, sec policy) 3. Evaluaatiometodien ja työkalujen määrääminen, sekä toimintaohjeen tarkempi määrittely (assessment työkalun profiili, skeletit, tarkistuslistat, jne) Esim Evaluointiaktiviteettien suorittaminen (tt-työkalujen käyttö realistiseen testijärjestelmään, ei tuotantokäytön aikaiseen laitokseen) ja raportointi 5. Evaluaation tulosten validointi 26

27 Tietoturvaevaluaation kokonaisuus ja päävaiheet Operatiivisen toiminnan -Tietoturvavaatimukset -Tietoturvapolitiikat Arkkitehtuurimäärittely 2. Evaluaatiokriteeristön määrittely Kunkin evaluaation tavoitteet Automaatiojärjestelmä (tai sen osa) 1. Evaluaatiokohteiden määrittely (sis. rajaus evaluoitavista ominaisuuksista) 3. Evaluaatiometodien ja työkalujen määrääminen, tarkempi evaluointiohje 4.. Evaluaatioaktiviteettien suorittaminen ja raportointi 5.. Evaluaatiotulosten validointi 27

28 1. Evaluaatiokohteiden määrittely Evaluaatiokohteen määrittely sisältää pääsääntöisesti seuraavia vaiheita: 1. Edellytys: Organisaatio on suorittanut tai tilannut (ja dokumentoinut) järjestelmän kokonaisriskiarvioinnin, jossa järjestelmän riskialtteimmat osat on alustavasti tunnistettu. (Huom! Tämän suorituksessa saa toki olla käytetty hyväksi myös järjestelmän teknistä skannausta (ei online!) tai profilointia tiettyjen ominaisuuksien suhteen, jotka osoittavat järjestelmästä riskialttiita kohtia.) 2. Organisaatio päättää mm. edellisen kohdan ja muiden suunnitelmien ja evaluaatiotavoitteiden perusteella mitä evaluaatiokohteita kussakin tietoturvaevaluaatiossa tutkitaan. 3. Kutakin yksittäistä evaluaatiota koskien, organisaatio rajaa evaluaatiokohteen tutkittavat ominaisuudet. Esimerkki: Tietyssä evaluaatiossa kohteesta määritellään evaluoitavaksi ainoastaan ulkoinen (black box) käyttäytyminen järjestelmän ollessa tietoturvaan liittyvän kokeellisen evaluaatiomenetelmän alaisena. Käyttäytyminen oltava todettavissa standardimenetelmin (ja liittyy kokonaisjärjestelmän toimintakyvyn kannalta olennaiseksi todettuun toiminteeseen.) 28

29 1. Esimerkki evaluoitavaksi valituista evaluaatiokohteista Optionaalinen evaluaatiokohde Julkiset verkot Toimistoverkko DMZ & FWs Evaluoitavan automaatiojärjestelmän rajaus Päivityspalvelin Pääsyoikeus-päivitykset Prosessiasema-1 PLC-1 C A B PLC-2 Varmuuskopiointi ja palautusjärjestelmät D Evaluoitavien ominaisuuksien rajaus: Prosessiasemasta ja PLC:stä vain ulkoinen (black box) käyttäytyminen DMZ:sta ja toimistoverkosta vain prosessiasema-1:n tukitoiminnot Vain rajapintojen A, B, C ja D evaluointi Tehtävä yksityiskohtainen dokumentaatio rajauksesta 29

30 2. Evaluaatiokriteeristön määrittely Tämä vaihe on ehkä evaluaatioon liittyvistä määrittelyistä vaikein. Kysymyksenasettelu: Mitä kriteeristöä vasten kulloistakin evaluaatiokohdetta tutkitaan? Mikäli kriteeristö ei ole tarpeeksi tarkkaan määritelty, tai se ei kohdistu tietoturvan kannalta oleellisiin seikkoihin järjestelmässä, eivät tuloksetkaan vastaa tarkoitustaan eli konformanttisuuden todentamista tiettyihin tietoturvavaatimuksiin nähden. Käytettävä kriteeristö riippuu voimakkaasti evaluaatiokohteesta sekä tavoitteista joita järjestelmän toiminnalle on asetettu. Mitään kaikenkattavaa kriteeristöä ei tietenkään ole olemassa joka sopisi kaikkiin käyttötarkoituksiin, sillä kyse on voimakkaasti CASE riippuvaisesta, yrityksen itsensä määrittelemästä asiasta. 30

31 2. Evaluaatiokriteeristön määrittely Evaluoitavassa yrityksessä täytyy olla operatiivista toimintaa kuvaavat tietoturvamäärittelyt ja -säännöstöt kunnossa. Mikäli näin ei ole, evaluoijat eivät voi tietää mitkä ovat toimintaympäristön tarkat vaatimukset ja niiden täyttämiseksi tarvittavat tietoturvakontrollit. (Jos yrityksessä ei ole tällaisia tietoturvamäärittelyjä olemassa, voitaisiin tietysti ajatella evaluaatiota kuitenkin tehtävän vaikkapa jonkin yleisesti määritellyn baseline :n mukaisesti, mutta tällöin emme todellisuudessa tiedä miten evaluaation tulokset todella hyödyttäisivät kyseisen yrityksen operatiivisen toiminnan turvaamisessa.) 1. Ensinnäkin, kullakin tieto-, tietoliikenne- ja automaatiojärjestelmän evaluoitavalla osalla tulee olla operoivan organisaation erityisesti määräämä ja käytössä oleva tietoturvatason (security level) määrittely, johon kuuluvat kiinteästi sekä tietyt tietoturvakontrollit suojaustasomäärittelyineen, sekä tietysti yksityiskohtainen tietoturvapolitiikka. 2. Lisäksi kokonaisjärjestelmän arkkitehtuurikuvauksessa on oltava määriteltynä suojattavien kohteiden vyöhykkeet (electronic perimeter) joissa kussakin siis vallitsee, yllä mainittu, määrätty tietoturvataso (security level). 31

32 2. Evaluaatiokriteeristön määrittely Alla on lueteltu teollisuusautomaatiojärjestelmien käyttöön sovellettavissa olevia tietoturvastandardikantoja (sis. myös valmiita kriteeristöjä ja vaatimuksia), joita voidaan käyttää hyväksi käyttöönotettavan automaatiojärjestelmän tietoturvan evaluoimisessa: American Petroleum Institute (API) Standard 1164, Pipeline SCADA Security Mm. Annex A: Tarkistuslista SCADA -järjestelmän tietoturvan evaluointiin, Annex B: SCADA -järjestelmän tietoturvasuunnitelma (esimerkki) IEEE Standard for Substation Intelligent Electronic Devices (IEDs) Cyber Security Capabilities Konkreettisia esimerkkivaatimuksia IED laitteille ISA99 Industrial Automation and Control Systems Security Standards ANSI/ISA 99: Sisältää mm. tietoturvavyöhykkeiden ja -tason konseptit, auditoinnin, mittaamisen ja monitoroinnin, jne MSISAC/SANS: SCADA and Control Systems Procurement Language Mm. järjestelmän kovennus ja paljon muuta North American Electric Reliability Corporation (NERC) - CIP Standards Paljon hyviä toiminnallisia vaatimuksia mm. laitevalmistajille 32

33 2. Esimerkki ylätason evaluaatiokriteeristöstä Julkiset verkot Toimistoverkko DMZ & FWs Evaluoitavan automaatiojärjestelmän rajaus Päivityspalvelin Pääsyoikeus-päivitykset Prosessiasema-1 C PLC-1 A B PLC-2 Varmuuskopiointi ja palautusjärjestelmät D Valitut ylätason evaluaatiokriteeristöt: 1. Rajapinnoissa A, B, C ja D vain policyn mukaiset protokollat käytössä 2. Rajapinnoissa avoimena vain sallitut palvelut ja portit 3. Prosessiasemassa sallitaan vain tietty maksimiviive (per palvelu) tt-testauksen alaisena 4. Päivityspalvelimen oikea toiminta 5. Pääsynvalvonnan turvallinen toteutus, pääsyoikeuksien päivitykset 6. Palautusjärjestelmän oikea toiminta 33

34 3. Evaluaatiometodien ja työkalujen määrääminen Ennen teknisten evaluaatioaktiviteettien aloittamista, täytyy siihen liittyvien tarkistus- ja tietoteknisten evaluointiaktiviteettien yksityiskohdat määritellä tarkasti, selkeästi ja selkein perustein. Täytyy olla selkeä perusta (esim. yrityksen aiempien evaluaatioiden baseline tulokset tai asetettu tavoitetila) joille kaikki evaluaatioaktiviteetit pohjautuu, jolloin tiedetään tarkasti mihin referenssiin evaluaatiokohdetta halutaan verrata. Pitää esim. kiinnittää yksityiskohtaiset tarkistuslistat (jos niiden käyttö kuuluu evaluaatioon), järjestelmän ominaisuuksia tutkivien työkalujen kuten penetraatiotestereiden, haavoittuvuusskannereiden, jne, yksityiskohtainen määrääminen ja työkalujen käyttämät konfiguraatiot, laajennukset, haavoittuvuusprofiilit, plug-in moduulit, jne. Tähän tarvitaan usein syvällistä tietoa tietoturvan teknisen evaluaation nykyaikaisista välineistä ja niihin kehitetyistä ominaisuuksista, joten esim. ulkoisen asiantuntemuksen käyttö on usein paikallaan. 34

35 3. Evaluaatiometodien ja työkalujen määrääminen Tärkeitä menetelmiä järjestelmien evaluointiin ovat ainakin: Toimihenkilöiden haastattelu (tarkistuslistat, tietoturvakontrollien prosessit) Haavoittuvuusanalyysi (lähdekoodianalysaattorit, haavoittuvuusskannerit, koodikatselmoinnit) Hyökkäysten sietoa testaavat menetelmät (teollisuusympäristöihin soveltuvat tietoturvatesterit,e.g. Achilles Satellite, penetraatiotesterit, robustness-testerit, testaus palvelunestohyökkäyksiä vastaan) Järjestelmien konfiguraation selvittäminen (sis. erilaisia menetelmiä, esim. verkkoskannerit, porttiskannerit, konfiguraatiotiedostojen tarkistus, palomuurisäännöstöjen ja eri järjestelmien pääsynvalvontasäännöstöjen läpikäynti) ja vertaaminen määriteltyyn 35

36 3. Esimerkki käytettävistä evaluaatiomenetelmistä / -työkaluista Julkiset verkot Toimistoverkko DMZ & FWs Evaluoitavan automaatiojärjestelmän rajaus Päivityspalvelin Pääsyoikeus-päivitykset Prosessiasema-1 A B Varmuuskopiointi ja palautusjärjestelmät Valitut evaluaatiomenetelmät & työkalut: 1. Tietyn liikenneanalysaattorin käyttö 2. Tietyn porttiskannerin käyttö 3. TT-testeri + viiveiden monitorointi 4. Pros.aseman päivitystoiminnon testi 5. Monitori: kirjautumistiedot kryptattu? 6. Edellisen konfigur. palautuskoe PLC-1 C PLC-2 D 36

37 4. Evaluaatiotulosten raportointi Evaluaatioaktiviteettien tuloksena tulisi syntyä: Tiedostoja joihin evaluaatiomenetelmien ja työkalujen tulokset on tallennettu. Nämä tiedostot on usein luokiteltava erittäin luottamuksellisiksi ja suojattava, sillä jos tieto esim. tietoturvapoikkeamista joutuu vääriin käsiin, saattaa järjestelmiin olla helppo tunkeutua sitä havaitsematta. Tulokset tulee olla vertailukelpoisessa muodossa vähintään siten, että vertailu mahdollistuu määriteltyyn tavoitetasoon, sekä mielellään myös aikaisempaan tilanteeseen (baseline). Raportteja joissa evaluoidun kokonaisuuden tunnistetiedot (esim. pvm, kohde, suorittaja, jne.), ennakkovaatimuksia (esim. käytetty kriteeristö, metodit ja työkalut), yhteenvetoja eri osuuksien tuloksista, tärkeimmät löydökset, ja mahdolliset kehityskohteet ja parannusehdotukset, jne. on kirjattu. 37

38 PASI AHONEN Team Leader, SW Technologies, Security Assurance Tel.: GSM: Fax: VTT TECHNICAL RESEARCH CENTRE OF FINLAND Kaitoväylä 1, Oulu, FINLAND PL 1100, Oulu, FINLAND 38

39 VTT luo teknologiasta liiketoimintaa 39