13. helmikuuta 2018

EU:n tietosuoja-asetus ja Linux


Kuten kaikki IT-ammattilaiset varmasti jo tietävät, tietosuoja-asetuksen (EU 2016/679) siirtymäaika päättyy 25.5.2018 ja projektit vaatimustenmukaisuuden täyttämiseksi ovat kuumimmillaan. Vaikka tietosuoja-asetuksen vaatimukset ovat suurelta osin dokumentoituja prosesseja, tietosuojaperiaatteiden noudattamista ja riskilähtöistä henkilötietojen suojaamista, tulee huomiota kiinnittää myös tekniseen tietoturvaan.

Tietosuoja-asetuksen tekniset vaatimukset?

Tietosuoja-asetus ei määrittele millaiset tekniset kontrollit tarvitaan suojaamaan henkilötietojen käsittelyä ja tallentamista, vaan organisaation pitää noudattaa alan yleisiä hyvä käytäntöjä ja riskiperustaista harkintaa. Tekniselle tasolle mentäessä ei yleensä kannata takertua liikaa yksittäiseen vaatimukseen, vaan huolehtia teknisestä tietoturvasta laajemmin. Käytännössä organisaatiolla voisi olla vaikka 2-3 eri tietoturvaluokkaa, joihin palvelut sijoitetaan ja näille luokille toteutetaan halutut tietoturvakontrollit.

Käyn tässä läpi muutamia vaatimustenhallinnan osa-alueita nimenomaan Linux-järjestelmien työkaluihin perustuen, mutta periaatteet ovat toki samat muissakin käyttöjärjestelmissä.

Valvonta ja hälytykset

Yksi merkittävimmistä tietosuoja-asetuksen vaatimuksista on tietomurroista ilmoittaminen. Jotta organisaatio voi kertoa tietomurron tapahtuneen ja mitä palveluita tai tietoja tietomurto koskee tai ei koske, tarvitaan välineet valvomaan sitä, mitä palveluissa tapahtuu sekä tallentamaan tämä lokitieto huolellisesti. 

Linux-käyttöjärjestelmässä on erinomaiset valmiit työkalut audit trailin ja lokienhallinnan hoitamiseksi:
  • Linuxin Audit:n määrittelyä, jotta epäilyttävistä toimenpiteistä saadaan ilmoitukset.
  • Sovellusten lokitusmääritysten läpikäyntiä, jotta sovellukset kirjoittavat tarpeelliset lokit tapahtumistaan.
  • Keskitetyn lokienhallinnan käyttöönotto, jotta lokit tallennetaan luotettavaan paikkaan säilytettäväksi.
  • Keskitetyn lokihallinnan lokidataa on analysoitava mahdollisten poikkeamien löytämiseksi, ja poikkeamat on käsiteltävä. 

Päivitysten hallinta

Tietomurrot tapahtuvat usein sovellusvirheiden avulla. Koska kaikissa sovelluksissa on virheitä, on ensiarvoisen tärkeää pitää sovellukset päivitettyinä. Linux-jakeluissa on omat tapansa hoitaa päivitystenhallintaa, mutta isommassa ympäristössä tarvitaan usein jokin keskitetty sovellusinventaario ja päivitystenhallinta tietoturvapäivitysten hallintaan. Tähän on valmiita ohjelmistoja, kuten Red Hat Satellite, mutta yhtä hyvin tämän voi automatisoida omilla skripteillä.

Palvelinten koventaminen

Data on yhtä hyvin suojattu kuin sovellus, jossa sitä käsitellään. Jos sovelluksen käyttövaltuushallinta on leväperäistä tai sessionhallinta ei toimi, ei hyvälläkään tietokannan salauksella ole merkitystä. Jos taas palvelimella, jossa sovellusta ajetaan ei tietoturva ole kunnossa, ei sovellustason hienotkaan tietoturvakontrollit hyödytä. 

Linux-ylläpitäjän näkökulmasta meidän pitää pystyä tuottamaan turvallinen, vakaa ja ylläpidettävä alusta sovelluksille ja datalle. Tätä alustan turvalliseksi tekemistä kutsutaan koventamiseksi. Käytännössä varmistetaan käyttövaltuushallinnan toimintaa, minimoidaan palveluita, salataan tietoa, tietoliikenneyhteyksiä jne.

Yksi tärkeä osa palvelinten koventamista on myös tunnistaa ja rajoittaa hyökkäyksen eteneminen palvelimen sisällä. Hyvät työkalut tähän tarjoaa mm. SELinux ja Audit-palvelu.

Verkon segmentointi ja valvonta

Organisaatioiden verkot ovat usein segmentoitu, mutta valitettavan usein eri verkkosegmenttien väliset palomuuriavaukset ovat varsin laajat. Näin esimerkiksi toimistoverkkoon pääsyn jälkeen on vihamielisellä taholla mahdollisuus edetä kohti päämääräänsä - henkilötietoa.

Verkon segmentointi on usein tehokkainta tehdä erillisissä palomuureissa, mutta useissa tapauksissa on perusteltua tehdä tarkempaa verkkoyhteyksien suojausta tai lokitusta myös itse palvelimella. Myös tähän Unix-pohjaiset ratkaisut antavat hyviä työkaluja. Oikein tehtyinä nämä eivät käyttöönoton jälkeen tuo juurikaan lisää työtä ylläpitäjille.  

Varmistukset

Varmistusten ottaminen konesalissa on usein hyvin hallussa, mutta entäs se yksittäinen palvelin Azuressa?  Kuuluuko varmistusprosessiin myös säännölliset testipalautukset? Sillä kuten Shrödinger's Backup -laki kuuluu "Varmistuksen tila on tuntematon ellei palautusta ole yritetty". 

Tarkemmin näitä ja monia muita Linuxin tietoturvaan liittyviä asioita läpikäydään Linuxin tietoturva -koulutuksessa. 


Timo Vehviläinen 
Information Security Manager
Kesko

5. helmikuuta 2018

The Futurology of Software testing, part 2/2

3. One super-discipline: UX plus RE plus QA plus QC

Sometimes, while explaining the intricacies of 2-switch coverage in state transition testing to some poor victims of HR departments’ ISTQB obsession, I get a very good question: “how does the choice between 1-switch and 2-switch coverage translate into customer satisfaction?”.

Needless to say, my answer is “it depends”, and depend it does, on what is important for customers, and for which customers, and to what extent, and how much this “what” would be enhanced by a higher N-switch coverage, and how much achieving this coverage would cost… Teaching people technicalities makes no sense unless they (people, not technicalities) have access to the information necessary to be able to make informed decisions regarding which technicalities to use. Otherwise, it is like teaching Latin to people who want to learn Dutch, which means totally useless unless you want to engage in scientific research.

Yes, what I am saying here is to some extent the same that context-driven school (11) has preached for years now – that the choice of test cases and test techniques and test methods depends on business context, and that you must “explore” the reality in order to discover this context, and that actually executing tests is a good way to explore and discover what has not been properly established during business analysis, nor during requirements analysis, nor during architectural design. Right, except that a far better solution is to put these disciplines together instead of delaying them into last resort “exploratory testing”.

4. When everything changes, nothing changes

I jumped the band-wagon of conscious testing in 1994. Before that, I had tested a lot as well: either my own software, or other people’s software, or hardware and software together, but I had not treated this controlling activity as a separate mental discipline, worth paying special attention to.

One of the first things I learned as a budding tester was, that testing was often not considered important enough and therefore neglected. Ten - twelve years later, surfing the giant wave of agile movement, I experienced the same again: testing not considered necessary by some sophomore agile teams.

Now, twenty-two years later, as you know very well, this attitude is gone – everybody understands, that… oh no, I was going to tell a lie. This is still the same – the happy-go-lucky attitude “it shall be all right” is still here with us, and I believe always will.

In 1996, I read about keyword-driven testing and thought “wow!”. Much, much later I met people explaining to me how unique and novel FitNesse and Cucumber approaches were; people who had not even heard the term “keyword-driven testing” and were not aware that FitNesse and Cucumber were fine implementations of it.

In 1980:s I met Simula programming language (12) and thought “wow!” again, only to learn C some time later and then again C++ as a “new” approach. I survived the OO-hysteria in late nineties, when God Himself was thought to be OO, and now listen to 20-years old guys telling me how great C# is. Not much has changed.

When I discovered Boris Beizer, Bill Hetzel and Glenford Myers and felt like a million dollars, it was a kind of anti-climax to find some seemingly obsolete books on informatics from 1970 and reading there about the very same principles of testing applied on some stone-age programming languages running on completely Jurassic machines. Tempora mutantur, but do really nos et mutamur in illis? (13).

And reading – with burning cheeks – “Agile Manifesto” in 2002, I couldn’t help the feeling of déjà vu… because of my knowledge of Tom Gilb’s EVO (“Evolutionary Project Management”) approach, first published some 25 years earlier.

So, in spite of Moore’s law, which obviously applies to electronics but not to development methods, not much has changed in testing during the last 20 years, so you need not expect any radical changes in the coming 20 years, either. Actually, not much has changed since 1628!

In the summer of 1628, the captain responsible for supervising construction of the ship, Söfring Hansson, arranged for the ship's stability to be demonstrated […]. Thirty men ran back and forth across the upper deck to start the ship rolling, but the admiral stopped the test after they had made only three trips, as he feared the ship would capsize. […] Fleming remarked that he wished the king – who had been sending a steady stream of letters insisting that the ship put to sea as soon as possible - were at home. (14)

-----------------
Sources:
11. Or exploratory, or rapid, or SBTM, or jamesbachis, or cenkanerish…
12. Simula was created much earlier than that, in 1960:s
13. Tempora mutantur, nos et mutamur in illis means “times change, and we change with them”
14. https://en.wikipedia.org/wiki/Vasa_(ship)#Construction



Author Bogdan Bereza is an international multitalent. He speaks six languages and is a true expert of e.g. Requirements Engineering and Testing.

You can find his IREB CPRE certification courses here: IREB CPRE Courses >>

You find also large selection of testing training courses at Tieturi 

Suositut tekstit