Antwoord.

Achtergrond van de vraag:

Vereisten voor informatiebeveiliging zijn een cruciaal onderdeel van grote IT-projecten sinds de vroege dagen van de eerste normen voor veiligheidsaudits (bijvoorbeeld ISO 27001 of de vereisten van de federale wet 152 in Rusland). Zonder duidelijke analyse en formalisering van de vereisten loopt de beveiliging van het systeem het risico declaratief en niet toepasbaar in de praktijk te zijn.

Probleem:

Beveiligingsvereisten worden vaak abstract geformuleerd ("alles moet beschermd zijn"), houden geen rekening met echte bedrijfsprocessen en architectuur, en zijn niet uitgewerkt op verschillende niveaus: organisatorisch, technologisch en gebruikersondersteuning. Bovendien kunnen klanten en ontwikkelaars dezelfde vereisten verschillend interpreteren, wat leidt tot een discrepantie tussen uitvoerbaarheid en normativiteit.

Oplossing:

Een systeemanalist begint met het bestuderen van bedrijfs-, staats- en sectorale normen (bijvoorbeeld: GOSTs, GDPR, PCI DSS, ISO 27001). Vervolgens identificeert hij samen met de architect en beveiligingsprofessionals de bedrijfskritische processen, gegevensopslag- en overdrachtspunten, mogelijke bedreigingen en bepaalt de lijst van relevante risico's. Op basis daarvan bereidt de analist een gedetailleerde matrix van vereisten voor toegang, opslag, logging en codering voor, evenals incidentscenario's. Na goedkeuring formaliseert hij deze in documenten, zodat elke vereiste kan worden gecontroleerd door middel van testen of tijdens een audit.

Belangrijke kenmerken:

Beveiligingsvereisten worden geformaliseerd met inachtneming van architectuur, bedrijfsprocessen en RegTech-normen.
Het is noodzakelijk om organisatorische, technologische en gebruikersondersteuningsbeleid te onderscheiden.
Nauw samenwerken met beveiligingsprofessionals, architecten, juristen en QA-engineers is verplicht.

Vragen met een addertje onder het gras.

Waarom kan men niet alleen vertrouwen op technische middelen voor informatiebeveiliging (antivirussoftware, firewalls, SIEM)?

Omdat informatiebeveiliging een proces is en niet gewoon een set systemen. Organisatorische procedures, menselijke factor, reguliere controles en training van gebruikers spelen een cruciale rol.

Kun je vereisten als vervuld beschouwen als het systeem alleen intern is getest?

Nee — vaak is een externe audit, certificering en soms stresstests onder toezicht van een toezichthouder vereist voor naleving van normen.

Is het genoeg om in de GPS het vereiste "het systeem moet beveiligd zijn volgens 152-FZ" op te nemen?

Niet genoeg — specifieke maatregelen moeten worden aangegeven (toegangscontrole, opslag van logboeken, gegevenscodering), de locaties van implementatie en verificatiecriteria.

Typische fouten en anti-patronen

Formulering van vage of declaratieve vereisten ("het moet veilig zijn")
Scheiding van het beveiligingsproces van architectonische en bedrijfsanalyse (werken "parallel", interageren niet)
Overschatting van de rol van technische middelen zonder rekening te houden met menselijke en procesfactoren
Gebrek aan reguliere controles van de actualiteit van informatiebeveiligingseisen

Voorbeeld uit de praktijk

Negatieve case: In een internetbankproject heeft de analist alleen de algemene zin "vereisten van 152-FZ moeten worden gevolgd" in de GPS opgenomen. Aannemers hebben standaardautorisatie en een SSL-certificaat geïmplementeerd, en tijdens de externe audit bleek dat er geen controle was over de opslag van gegevens en dat de authenticatielog niet beschermd was.

Voordelen:

Snelle ontwikkeling

Nadelen:

Ontevredenheid van de toezichthouder
Risico op blokkering van de lancering

Positieve case:

Aan het begin van het project heeft de systeemanalist samen met de beveiligingsprofessionals en de klant een lijst van bedreigingen goedgekeurd, gedetailleerde vereisten voor codering en audit per scenario ontwikkeld, en verantwoordelijkheden bepaald. Het resultaat was dat het systeem de audit zonder opmerkingen doorstond.