27.10.2016 09:57:23

Den här artikeln diskuterar det tekniska projektstadiet, som relaterar till ett av stegen i informationssäkerhetssystemets (ISS) livscykel - "designstadiet", som, i enlighet med den inhemska standarden GOST 34.601-90, omedelbart följer utvecklingen av villkoren för informationssäkerhetssystemet.

1. Utveckling av teknisk designdokumentation för NIB

Livscykeln för ett informationssäkerhetssystem (nedan kallat ISS) består i allmänhet av följande steg:

• analys av krav på informationssäkerhetssystem;
• design;
• genomförande;
• genomförande;
• utnyttjande.

Den här artikeln diskuterar skedet av det tekniska projektet, som hör till "design" -stadiet och, i enlighet med den inhemska standarden GOST 34.601-90, följer omedelbart utvecklingen av villkoren för informationssäkerhetssystemet.

1.1. Varför utveckla dokumentation för NIB överhuvudtaget?

Svaret på denna fråga bör övervägas i två plan: i planet för ägaren av informationsresurser (för vars skydd ett informationssäkerhetssystem skapas) och i planet för den direkta utvecklaren av informationssäkerhetssystemet.

För ägaren av informationsresurser är det viktigt att få resultatet i form av ett fungerande informationssäkerhetssystem som minskar riskerna för att äventyra begränsad åtkomstinformation i organisationen. Det tekniska projektet i detta fall tjänar till att utveckla de grundläggande principerna för det framtida systemet, nämligen, det inkluderar en beskrivning av hur ISS kommer att byggas och fungera, vilka åtgärder och medel som säkerställer informationsskydd, vilka möjligheter finns att utveckla och förbättra systemet. Efter avslutad utveckling av ett tekniskt projekt för ett informationssäkerhetssystem får kunden en omfattande uppsättning dokumentation för informationssäkerhetssystemet, som beskriver alla tekniska nyanser av det framtida systemet.

För den direkta utföraren, i det tekniska projektets skede, är det nödvändigt att fastställa den mest lämpliga ISS-arkitekturen, samt göra rätt val av åtgärder och medel för att skydda information i organisationen. Det är också viktigt att säkerställa att systemets egenskaper och egenskaper överensstämmer med de tekniska specifikationerna, eller att motivera, med kundens medverkan och samtycke, justeringen av de krav som anges i de tekniska specifikationerna för att öka effektiviteten av det skapade systemet.

Således, som ett resultat av utvecklingen av teknisk designdokumentation, kommer kunden att ha svar på följande frågor:

• vad är den allmänna arkitekturen för NIB;
• vilka åtgärder och medel kommer att användas för att genomföra krav på informationsskydd;
• hur NIB kommer att fungera;
• vilka förändringar i organisationen som är nödvändiga för att öka informationssäkerhetsnivån kommer att följa som ett resultat av implementeringen av ISS;
• kommer Kundens krav (affärskrav) och kraven i regulatoriska rättsakter på informationssäkerhetsområdet att beaktas vid utveckling och implementering av informationssäkerhetssystemet och i så fall hur.

I processen med att utveckla teknisk projektdokumentation kommer entreprenören att få följande resultat:

• en grund för övergången till nästa steg för att bygga en ISS, nämligen stadierna för arbetsdokumentation och implementering;
• förståelse för arkitekturen, teknologierna och verktygen som används, ordningen för att bygga systemet;
• hur Kundens krav (affärskrav) och regulatoriska dokument inom området informationssäkerhet implementeras för systemet.

1.2. Genomgång av tillvägagångssätt för att utveckla teknisk projektdokumentation

Utvecklingen av ett tekniskt projekt för ett informationssäkerhetssystem sker oftast utifrån relevanta standarder och vägledande dokument. Dessutom är deras användning obligatorisk för statliga institutioner, men rekommenderas för kommersiella. I praktiken använder kommersiella organisationer också statliga standarder när de utvecklar teknisk projektdokumentation av följande skäl:

• ett upprepat testat tillvägagångssätt för att skapa informationssystem;
• genomtänkt struktur och innehåll i dokument;
• en uppsättning dokument tillräckliga för utveckling och beskrivning av nästan alla system.

För att utveckla dokumentation för den tekniska projektfasen (TP) av NIB, används statliga standarder och vägledningsdokument för 34-serien:

• GOST 34.201-89 "Typer, fullständighet och beteckning av dokument när du skapar automatiserade system." Denna standard specificerar:
  • typer och namn på dokument på TP-stadiet;
  • fullständighet av dokumentation;
  • accepterade dokumentbeteckningar;
  • regler för att utse informationssystem och deras delar.
• GOST 34.003-90 "Villkor och definitioner";
• GOST 34.601-90 "Automatiska system. Stadier av skapandet." Standarden specificerar:
  • förteckning över stadier av arbete som utförts på det tekniska stadiet;
  • detaljerad beskrivning av det arbete som utförts på det tekniska stadiet;
  • förteckning över organisationer som deltar i skapandet av ISS;
• RD 50-34.698-90 "Automatiska system. Krav på innehållet i dokument." Detta vägledningsdokument anger kraven på innehållet i dokument på TP-stadiet.

Det är viktigt att förstå att enligt 34-serien av standarder är teknisk design ett steg för att skapa ett system, och inte bara en uppsättning dokument. I praktiken kombineras detta steg ofta med det preliminära designskedet, vilket tjänar till att utveckla flera preliminära lösningar och motivera den mest lämpliga. En sådan kombination tillåts av standarden, men det måste beaktas att detta inte förnekar behovet av att uppnå målen för det preliminära konstruktionsstadiet.

Oftast utvecklas det preliminära konstruktionsstadiet i det fall då kraven i de tekniska specifikationerna för systemet kan implementeras på flera fundamentalt olika sätt, och även när det bland dessa metoder inte finns några klart föredragna.

Det är dock värt att notera att ovanstående standarder är för generella och implementerar huvudsakligen design och allmänna strukturella funktioner. För att utveckla den materiella delen av de tekniska projektstadiets dokument använder designers information från följande källor:

Aktuella regulatoriska dokument (RLA) som reglerar kraven på skydd av viss information med begränsad åtkomst. Dessa föreskrifter ställer krav på åtgärder för att skydda information i informationssystem, beskriver nyanserna av att genomföra dessa åtgärder och ytterligare förstärkningsåtgärder. Bland de nuvarande rättsakterna finns följande:

• Beslut från FSTEC i Ryssland av den 18 februari 2013 nr 21 "Om godkännande av sammansättningen och innehållet av organisatoriska och tekniska åtgärder för att säkerställa säkerheten för personuppgifter under deras behandling i informationssystem för personuppgifter";
• Order från Rysslands FSTEC av den 11 februari 2013 nr 17 "Om godkännande av krav för skydd av information som inte utgör en statshemlighet som finns i statliga informationssystem"
• Order från Rysslands FSTEC av den 14 mars 2014 nr 31 ”Om godkännande av krav för att säkerställa informationssäkerhet i automatiserade styrsystem för produktion och tekniska processer vid kritiska anläggningar, potentiellt farliga anläggningar, samt anläggningar som utgör en ökad fara för människors liv och hälsa och för den naturliga miljön;
• metodologiskt dokument "Åtgärder för att skydda information i statliga informationssystem", godkänd av Rysslands FSTEC den 11 februari 2014.

Kraven på skydd av begränsad åtkomstinformation och listor över skyddsåtgärder varierar för informationssystem av olika säkerhetsnivåer/klasser. Om informationen i en organisation inte är skyddad i enlighet med Ryska federationens federala lagar (till exempel officiella hemligheter), kan ägaren av denna information använda de metoder som föreslås i dessa lagar för att bygga ett företagsinformationssäkerhetssystem .

Ryska och utländska standarder som beskriver olika tillvägagångssätt för sätt att implementera stadierna i livscykeln för att bygga en ISS, inklusive det tekniska designstadiet:

• en serie statliga standarder GOST R ISO/IEC 2700X, identiska med internationella standarder ISO/IEC 2700X. Dessa standarder beskriver PDCA-processen (Plan, Do, Check, Act) för implementeringen av livscykeln för ett ledningssystem för informationssäkerhet, som är en integrerad del av informationssäkerhetssystemet;
• NIST SP 800-64 är en US National Institute of Standards and Technology-standard som beskriver livscykeln för informationssystemutveckling;
• NIST SP 800-37 är en US National Institute of Standards and Technology-standard som ger vägledning för att integrera riskhantering i informationssystemens utvecklingslivscykel.

Tillverkarens driftdokumentation för informationssäkerhetsutrustning och hjälputrustning. Dessa dokument innehåller omfattande teknisk information om de verktyg som används vid konstruktionen av informationssäkerhetssystem, inklusive de som är direkt relaterade till implementeringen av informationssäkerhetsåtgärder som inte är relaterade till till exempel servrar, datalagringssystem, virtualiseringsverktyg och andra. Den allmänna uppsättningen av sådana dokument varierar från tillverkare till tillverkare och beror bland annat på implementeringen av ett visst verktyg (hårdvara/mjukvara). Nedan finns en standarduppsättning operativ dokumentation för informationssäkerhetsverktyg som används för att utveckla dokument i det tekniska projektstadiet:

• allmän beskrivning (datablad);
• administratörsguide (kan inkludera lokal och centraliserad hanteringsguide);
• Användarguide;
• Snabbinstallations- och distributionsguide (för skyddssystem för hårdvaruinformation);
• bruksanvisning;
• Vägledning för distribution i virtuell infrastruktur (för mjukvaruinformationssäkerhetssystem);

Allmän information om tillgängliga ISS-arkitekturer, bästa praxis när det gäller att bygga ISS, riktlinjer för säkerhet och integration av informationssäkerhetssystem med varandra, information om problem i samspelet mellan vissa informationssäkerhetssystem. Exempel på sådan information kan inkludera följande dokument:

• guider om arkitekturer för informationssäkerhetssystem, till exempel: Defence-in-Deepth, Cisco SAFE, Check Point SDP och andra;
• bästa praxis inom området informationssäkerhet, till exempel, tillgängliga på dessa länkar (https://www.sans.org/reading-room/whitepapers/bestprac/, http://csrc.nist.gov/publications/nistpubs/ 800-14 /800-14.pdf). Dessa dokument presenteras oftast på engelska, men alla ryska tillverkare av skyddsutrustning har sina egna bästa praxis för att implementera säkerhetsåtgärder och kan tillhandahålla dem på begäran;
• säkerhetsriktlinjer för informationssäkerhet och driftmiljöer. Ett exempel är avsnittet "Säkerhet" på den officiella Microsoft-portalen (https://technet.microsoft.com/ru-ru/library/dd637672.aspx).

1.3. Utveckling av ett tekniskt projekt för NIB i enlighet med GOST 34

Utvecklingen av dokument på det tekniska projektstadiet för ISS utförs oftast av integratörer av dessa tjänster och implementeras huvudsakligen i enlighet med följande plan:

Fastställande av listan över dokument som ska utvecklas - denna information anges i de tekniska specifikationerna för ISS. I vissa fall kan dokumentutvecklaren, i samförstånd med kunden, utöka eller minska denna lista, om denna möjlighet finns med i de tekniska specifikationerna;

Utveckling av dokumentmallar för TP-stadiet - strukturen används i enlighet med RD 50-34.698-90 och GOST 2.106 (för vissa dokument), formaterad i enlighet med GOST 2.105-95;

Utveckling av den materiella delen av dokument. Krav på systemet fastställs i tekniska specifikationer för NIB. I enlighet med dessa krav fastställs en lista över tekniska och organisatoriska skyddsåtgärder som krävs för implementering i systemet. Skyddsåtgärder kan fastställas i relevanta regelverk (beroende på vilken typ av information som skyddas), företagsstandarder och informationssäkerhetspolicyer, samt baserat på förekomsten av aktuella säkerhetshot som identifierats under utvecklingen av organisationens hotmodell. Baserat på listan över skyddsåtgärder väljer IS-utvecklaren lämpliga informationssäkerhetsverktyg och utvecklar informationssäkerhetssystemets funktionella struktur (undersystem, komponenter). Vidare beskriver de tekniska designdokumenten det praktiska genomförandet av skyddsåtgärder utifrån valt säkerhetsskydd eller organisatoriska åtgärder i organisationens infrastruktur.

Samordning av den utvecklade dokumentationen och de lösningar som presenteras i den med kunden av systemet.

När man utvecklar teknisk projektdokumentation är det oftast inte nödvändigt att utveckla en komplett lista över dokument som specificeras i GOST 34.201-89, eftersom denna standard är föråldrad och vissa av dokumenten inte tar hänsyn till utvecklingstrender och teknologier för moderna informationssystem . Den minsta uppsättningen dokument som krävs för att beskriva informationssäkerhetssystemet är följande:

• teknisk designförklaring;
• förklarande anmärkning till det tekniska projektet;
• funktionell strukturdiagram;
• strukturdiagram av ett komplex av tekniska medel;
• organisationsstrukturdiagram;
• lista över köpta varor.

På kundens begäran eller i det fall att ISS är ett komplext flerkomponentsystem, kan följande dokument också utvecklas ytterligare:

• automatiseringsschema;
• beskrivning av automatiserade funktioner;
• beskrivning av systemets informationsstöd;
• beskrivning av komplexet av tekniska medel;
• mjukvarubeskrivning;
• beskrivning av organisationsstrukturen.

Det bör noteras att GOST 34.201-89 möjliggör en utökning av dokumentutbudet på TP-stadiet, men i praktiken finns det mer än tillräckligt med dessa dokument.

Tekniskt designblad

Beteckning: TP.

Detta dokument är avsett att beskriva listan över dokument som utvecklats i det tekniska projektstadiet. Antalet sidor i vart och ett av de utvecklade dokumenten anges också.

Förklarande notering till det tekniska projektet

Beteckning: P2.

Detta dokument är det viktigaste för TP-stadiet och innehåller en beskrivning av ISS-arkitekturen, tekniska och organisatoriska åtgärder, ISS-funktioner, mjuk- och hårdvarusystem och annat. Enligt standarden består den av fyra huvudsektioner:

• allmänna bestämmelser;
• beskrivning av aktivitetsprocessen;
• grundläggande tekniska lösningar;
• åtgärder för att förbereda automationsobjektet för att sätta systemet i drift.

Funktionell strukturdiagram

Beteckning: C2.

Detta dokument beskriver den logiska strukturen hos ISS, nämligen:

• logiska delsystem och komponenter som ingår i ISS;
• funktioner implementerade med hjälp av delsystem och komponenter;
• informationskopplingar mellan logiska delar av SIS och typer av meddelanden under utbyte.

Strukturdiagram av ett komplex av tekniska medel

Beteckning: C1.

Detta dokument innehåller en beskrivning av följande delar av ISS:

• tekniska medel som en del av logiska delsystem och komponenter i informationssäkerhetssystem;
• kommunikationskanaler och utbyte mellan tekniska medel som indikerar transportprotokoll.

Organisationsschema

Beteckning: C0.

Detta dokument beskriver organisationens organisationsstruktur i termer av ISS-ledning, nämligen:

• avdelningar och ansvariga personer i organisationen som är involverade i driften av ISS;
• utförda funktioner och kopplingar mellan avdelningar och ansvariga personer.

Lista över köpta föremål

Benämning: VP.

Detta dokument innehåller en lista över all mjukvara och hårdvara, samt licenser som används för att skapa ett informationssäkerhetssystem. Utvecklad i enlighet med GOST 2.106.

Notera. Det är också värt att notera här att vägledningsdokumentet RD 50-34.698-90 tillåter tillägg av vilket dokument som helst på TP-stadiet (inkludering av avsnitt och information som skiljer sig från de föreslagna), sammanslagning av avsnitt, såväl som uteslutning av vissa enskilda avsnitt. Beslut om detta fattas av utvecklaren av dokument på TP-stadiet och baseras på funktionerna i den skapade NIB.

1.4. Regler för utveckling av dokumentation

• strukturell överensstämmelse med statliga standarder;
• strikt överensstämmelse med kraven i de tekniska specifikationerna för systemet;
• tillämpning av dokumentmallar (användning av enhetliga stilar, uppmärkning, fält, etc.);
• ett individuellt förhållningssätt och samtidig användning av befintliga utvecklingar när du fyller i delar av dokument.

Förklarande notering till det tekniska projektet:

• dokumentutveckling utförs i Microsoft Word; efter att utvecklingen är klar rekommenderas det att konvertera dokumentet till PDF-format för enkelhetens skull;
• termer och förkortningar måste vara konsekventa i alla delar av dokumentet;
• Det rekommenderas att undvika uppenbara upprepningar och onödig ökning av dokumentets längd;
• tekniska lösningar måste beskrivas så detaljerat som möjligt med angivande av:
  • arkitektur och teknik som används;
  • plats för mjukvara och hårdvara i organisationens infrastruktur;
  • informationssäkerhetsverktyg som används med en beskrivning av deras egenskaper, implementerade funktioner, information om certifiering;
  • grundläggande inställningar för informationssäkerhetsverktyg i form av skyddsmekanismer, adressering, routing, interaktion med relaterade system och verktyg, etc.;
  • kontroller, metoder för åtkomst till dem och platser för deras installation;
  • diagram (strukturella, funktionella, organisatoriska):
    • utveckla diagram i Microsoft Visio;
    • efter utveckling, infoga diagram i dokumentet med hjälp av dialogrutan "Klistra in special" i EMF-format (Windows-metafil);
    • utveckla separata diagram för systemet, delsystemen och komponenterna i delsystemen;
    • göra utformningen av diagrammen enhetlig, med samma element, förkortningar, ikoner, textstilar etc.

1.5. Resurser som hjälper dig att utveckla dokumentation

Internet innehåller en enorm mängd information som i en eller annan grad kan hjälpa till vid utvecklingen av teknisk projektdokumentation. Nyckelresurser presenteras i tabellen nedan.

Tabell. SIS tekniska designresurser

Resurstyp	Information	Exempel på resurser
Internetportaler för federala verkställande myndigheter	Regleringsdokument, metodologiska rekommendationer, register (inklusive certifierade informationssäkerhetssystem), databaser (inklusive databaser över sårbarheter och hot)	fstec.ru clsz.fsb.ru minsvyaz.ru/ru/
Internetportaler för tillverkare av informationssäkerhet, distributörer av lösningar för informationssäkerhet	Beskrivning av informationssäkerhetslösningar, driftdokumentation för informationssäkerhet, analysmaterial och artiklar	securitycode.ru kaspersky.ru/ drweb.ru/ ptsecurity.ru/ infowatch.ru/ infotecs.ru/ cisco.com/c/ru_ru/index.html checkpoint.com altx-soft.ru
Specialiserade informationssäkerhetsresurser	Jämförelse av informationssäkerhetslösningar, recensionsartiklar om informationssäkerhetslösningar, tester av informationssäkerhetslösningar, djupgående teknisk information om informationssäkerhetsteknologier	anti-malware.ru bis-expert.ru safe.cnews.ru securitylab.ru/ vulners.com/ csrc.nist.gov itsecurity.com owasp.org sans.org

1.6. Exempel på tekniska projektstadsdokument

För att förstå kraven på innehållet i dokumentationen på TP-stadiet finns nedan exempel på att fylla i huvuddokumenten (dokumentavsnitt).

1.6.1. Förklarande notering till det tekniska projektet

Den förklarande anteckningen är ett ganska omfattande dokument, så här är ett exempel på innehållet i avsnittet "Grundläggande tekniska lösningar" i en del av ett av SIS-delsystemen - säkerhetsanalysundersystemet.

ISS delsystem för säkerhetsanalys

Delsystemets struktur och sammansättning

Undersystemet för säkerhetsanalys (SAS) är utformat för att systematiskt övervaka säkerhetsstatusen för automatiserade arbetsstationer (AWS) för personal och organisationsservrar. Grunden för ESD är mjukvaruverktyget "Test" som produceras av Information Security LLC. SZI Test är certifierat av FSTEC i Ryssland för överensstämmelse med tekniska specifikationer (TU) för informationssäkerhet och för den fjärde nivån av kontroll över frånvaron av odeklarerade förmågor.

ESD innehåller följande komponenter:

• Testserverhanteringsserver;
• Testa konsolens hanteringskonsol.

En beskrivning av delsystemets komponenter presenteras i tabellen nedan.

Tabell. ESD-komponenter

Komponent	Beskrivning
Testa Server Management Server	Tillhandahåller hantering av skanningsuppgifter, utför funktioner för att övervaka säkerhetsstatusen för arbetsstationen och organisationens servrar. Skanningsparametrar ställs in av informationssäkerhetsadministratören på testserverns hanteringsserver. All insamlad information om skanningsresultat lagras i testserverns serverlagring baserat på Microsoft SQL Server 2008 databashanteringssystem
Testa konsolen	Tillåter informationssäkerhetsadministratören att ansluta till testservern, visa och ändra dess konfiguration, skapa och ändra skanningsuppgifter, se information om uppgifternas framsteg och resultaten av deras exekvering. Hanteringskonsolen är installerad på informationssäkerhetsadministratörens arbetsstation

Tillhandahålla funktioner

ESD tillhandahåller följande funktioner:

• implementering av proaktivt skydd av organisationens arbetsstationer och servrar genom att övervaka informationssäkerhetens status;
• automatisering av processer för att övervaka efterlevnaden av interna policyer och vissa säkerhetsstandarder;
• minskning av kostnader för revision och säkerhetskontroll, utarbetande av statusrapporter;
• automatisering av resursinventeringsprocesser, sårbarhetshantering, övervakning av efterlevnad av säkerhetspolicyer och förändringskontroll.

Lösning för ett komplex av hård- och mjukvaruverktyg

Listan över använd ESD-mjukvara och hårdvara finns i tabellen nedan.

Tabell. ESD mjukvara och hårdvara

ESD-kontrollserver

Tekniska medel

Den fysiska servern som används som ESD-hanteringsserver måste uppfylla de tekniska kraven för programvaran och operativsystemet som är installerat på den, som anges i tabellen nedan.

Tabell. OS- och mjukvarukrav för ESD-kontrollservern

programvara	Tekniska krav
	CPU	RAM, MB
Microsoft Windows Server 2008 R2	3000 MHz, 4 kärnor	8192
Microsoft SQL Server 2008 R2
Testa serverprogramvara

programvara

Hanteringsserver OS

Windows 2008 R2 OS installeras på hanteringsservern på normalt sätt från en startdistribution.

Hanteringsserverns OS hanteras både lokalt från konsolen och via RDP-protokollet.

Management server DBMS

Microsoft SQL Server 2008 R2-databasen installeras under ett konto med lokala administratörsrättigheter med hjälp av standardinstallationsguiden från distributionspaketet som tillhandahålls av produktutvecklaren.

Testa serverprogramvara

Testservermjukvaran installeras på hanteringsservern med hjälp av standardinstallationsguiden.

Den första installationen och efterföljande hanteringen av Test Server-programvaran i normalt läge utförs med hjälp av testkonsolens hanteringskonsol som är installerad på IS-administratörens arbetsstation.

IS-administratörens arbetsstation

Tekniska medel

Den befintliga arbetsstationen för en anställd på organisationens avdelning som ansvarar för att tillhandahålla informationssäkerhet, som kör Microsoft Windows-familjen av operativsystem, används som en plattform.

De tekniska medlen för informationssäkerhetsadministratörens arbetsstation måste ha följande hårdvarukonfigurationsegenskaper (åtminstone rekommenderas):

• CPU 2 GHz;
• RAM 4 GB;
• Hårddisk 80 GB.

programvara

Testa konsolprogramvara

Informationssäkerhetsadministratörens arbetsstation där programvaran Test Console är installerad måste fungera under något av följande operativsystem:

• Microsoft Windows 7, 32- och 64-bitars;
• Microsoft Windows 8/8.1, 32- och 64-bitars.

Dessutom måste Microsoft .NET Framework version 3.5 SP1 eller högre installeras på informationssäkerhetsadministratörens arbetsstation för att programvaran för hanteringskonsolen för Test Console ska fungera korrekt, och säkerhetsinställningarna för det använda operativsystemet måste tillåta åtkomst till testservern.

Installation av Test Console-programvara på ESD-administratörens arbetsstation utförs med hjälp av standardinstallationsguiden för Test Server-programvaran med det valda alternativet för att installera Test Console-hanteringskonsolen och andra standardinställningar.

Interaktion med angränsande system

För ESD, angränsande är:

• brandväggsundersystemverktyg;
• Active Directory-katalogtjänster;
• Arbetsstation och servrar i organisationen.

För att säkerställa nätverksinteraktion med angränsande system och direkt mellan ESD-komponenterna själva måste passagen av nödvändig nätverkstrafik organiseras.

För att säkerställa möjligheten att ta emot uppdateringar av kunskapsbasen och testprogramvarumoduler för testserverskannern, är det nödvändigt att ge åtkomst till update.com-webbservern för företaget Information Security LLC via port 443/tcp.

Vid skanning i PenTest-läge sker interaktionen mellan testserverns scanner och arbetsstationen och organisationens servrar via IP-protokollet. Vid skanning i revisions- och efterlevnadslägen används fjärrhanteringsprotokoll WMI, RPC etc. För att skanna värdar på enheter med brandväggsfunktioner måste du tillåta anslutningar från testservern till de skannade värdarna via IP. Följaktligen måste testservern förses med åtkomst till nätverksportarna för de skannade värdarna med hjälp av lämpliga fjärrkontrollprotokoll.

Eftersom ESD, vid skanning i revisions- och efterlevnadslägen, använder fjärrkontrollprotokoll för analys, måste skanningsverktyg för testprogram genomgå autentisering och auktorisering på den skannade noden. I ESD, för att skanna noder i revisions- och efterlevnadslägena, används konton med administrativa privilegier i varje typ av nod (arbetsstation, server, applikationssystem, DBMS, etc.).

Alla registrerade informationssäkerhetshändelser lagras i Microsoft SQL DBMS. Dessa händelser kan skickas till undersystemet för övervakning av informationssäkerhetshändelser med hjälp av speciella kontakter.

Drift och underhåll av ESD

Subsystemanvändare

Drift och underhåll av ESD-verktyg utförs av anställda i organisationen med den funktionella rollen som "IS-administratör".

En informationssäkerhetsadministratör definieras som en specialist vars uppgifter inkluderar:

• bestämma skanningsparametrarna för organisationens noder;
• ställa in och starta skanningsuppgifter;
• analys av skanningsresultat för närvaron av sårbarheter i informationssystem, konfigurationsfel eller bristande överensstämmelse med tekniska standarder;
• kontroll över eliminering av sårbarheter;
• bildande av standarder och krav som gäller för att säkerställa säkerheten för organisationens arbetsstationer och servrar.

Systemdriftlägen

Normalt driftläge

I normal drift fungerar ESD 24 timmar om dygnet, 7 dagar i veckan.

Vid normal drift utför informationssäkerhetsadministratören:

• schemalagd och oplanerad skanning av noder;
• generera rapporter;
• uppdatering av kunskapsbaser och testprogramvarumoduler.

Nödoperation

Om säkerhetsutrustningens funktion störs störs delsystemets funktion. Underlåtenhet att använda ESD-utrustning påverkar inte funktionen hos organisationens automatiserade arbetsstationer och servrar.

1.6.2. Funktionell strukturdiagram

Funktionsdiagram kan utvecklas för hela informationssäkerhetssystemet eller för en del av det, till exempel ett delsystem eller en komponent.

Ett exempel på ett allmänt funktionsdiagram för en ISS visas i figuren nedan.

1.6.3. Strukturdiagram av ett komplex av tekniska medel

Blockschemat för ett komplex av tekniska medel kan utvecklas både för hela ISS och för dess delar - delsystem och komponenter. Möjligheten att utveckla diagram för delar av informationssäkerhetssystemet bestäms av systemets skala och den nödvändiga detaljen.

Ett exempel på ett blockschema över ett komplex av tekniska informations- och säkerhetssystem presenteras i figuren nedan.

Idag kommer vi att prata om inhemska standarder för designdokumentation. Hur dessa standarder fungerar i praktiken, varför de är dåliga och varför de är bra. Vid utveckling av dokumentation för statliga och seriösa privatkunder har vi oftast inget val – efterlevnad av standarder ingår i kraven för att dokumentera tekniska specifikationer. I praktiken har jag stött på olika exempel på missuppfattningar om uppbyggnaden av standarder, vad som ska stå i dokumenten och varför dessa dokument behövs. Som ett resultat producerar pennorna från tekniska författare, analytiker och specialister ibland sådana pärlor att det är oklart i vilket medvetandetillstånd de skrevs. Men i själva verket är allt ganska enkelt. En sökning på Habr gav inga länkar till mer eller mindre komplett material om detta ämne, så jag föreslår att fylla i denna irriterande lucka.

Vad är dokumentationsstandarder?

I den aktuella 34-serien finns det bara tre huvuddokumentationsstandarder:

Den mest älskade och populära standarden för utveckling av tekniska specifikationer. Det enda du inte bör glömma är att det är tätt kopplat till andra standarder i serien, och om du har fått tekniska specifikationer gjorda enligt denna standard är det starkt tillrådligt att följa andra standarder, även om det inte finns några direkta krav för detta. Åtminstone när det gäller allmän ideologi (om vilken nedan)

Detta är ett grundläggande dokument som ger en komplett lista över GOST 34-dokumentation, rekommendationer för kodning av dokument, vilka stadier av projektet dokumenten tillhör (stadierna beskrivs i GOST 34.601-90), samt hur de kan kombineras med varandra.

Faktum är att denna standard är ett stort bord med kommentarer. Det kan läggas in i Excel för enkel användning.

En voluminös standard som beskriver innehållet i projektdokument med varierande detaljeringsgrad. Ovannämnda GOST 34.201-89 används som ett index.

Det finns många frågor och tolkningar av dess bestämmelser angående standarden RD 50-34.698-90, som på grund av sin vaghet ofta förstås olika av kunden och entreprenören, eller till och med medlemmar i projektgruppen. Men tyvärr har vi inget mer konkret.

Låt oss nu överväga för- och nackdelarna med standarderna, traditionellt börja med nackdelarna.

Nackdelar med standarder

Den största nackdelen är uppenbar för alla - standarderna är gamla. De innehåller en föråldrad idé om arkitekturen för ett automatiserat system. Till exempel:

• tvåstegsapplikationer, bestående av ett klientprogram och en DBMS-server (inga tre eller fler "tier" applikationer, inga Weblogic eller JBoss)
• strukturen på databastabellerna, som beskrivs, kommer att ge en uppfattning om den logiska datamodellen (det faktum att det kan finnas någon form av viloläge mellan applikationen och databasen verkade som ett dåligt överskott då)
• användargränssnittet är ett fönster (finns det något annat? Vad är en "webbläsare"?)
• Det finns få rapporter i systemet, alla är papper och skrivs ut på en matrisskrivare.
• Programmet som utvecklas är inriktat på att lösa "informationsbehandlingsproblemet", som har en tydlig input och output och är mycket specialiserad. Informationsbehandlingen är baserad på en "algoritm". Ibland finns det flera "algoritmer". (Objektorienterad programmering tog då bara sina första steg och övervägdes inte på allvar).
• databasadministratören förstår vilken information som finns i tabellerna och deltar aktivt i att redigera systemkataloger (finns det verkligen en DBMS-server för 50 olika applikationer?)

Följaktligen har standarden artefakter som följande:

5.8. Ritning av dokumentformuläret (videoram)
Dokumentet måste innehålla en bild av dokumentets eller videoramens form i enlighet med kraven i statliga standarder för det enhetliga dokumentationssystemet R 50-77 och nödvändiga förklaringar.

Poängen med dokumentet är att sovjetiska företag använde så kallade "Printing Areas", där det fanns höghastighetsmatrisskrivare, vars drivrutiner ofta skrevs av ingenjörerna själva. Därför var de tvungna att föra ett register över alla dokument som behövde skrivas ut för att säkerställa att dokumenten såg ut som de skulle när de skrevs ut.

"Videoram" är också ett dokument som visades på en textskärm. Skärmarna stödde inte alltid de obligatoriska tecknen och det erforderliga antalet horisontella tecken och vertikala linjer (och stödde inte grafik alls). Därför var det även här nödvändigt att ytterligare samordna formerna för alla skärmdokument.

Nu säger orden "maskinogram", "videoram", "ADC" oss ingenting längre. Jag hittade dem inte heller i användning, även om jag tog examen från ett specialiserat institut på 90-talet. Detta var tiden för uppkomsten av Windows 3.1, VGA-skärmar, tre-tums disketter och de första inhemska webbplatserna. Men dessa ord finns i standarden, och kunden kräver ibland nyckfullt att vi förser honom med en komplett uppsättning dokumentation i enlighet med GOST 34.201-89. Dessutom migrerar sådana formuleringar i ToR från ett departement till ett annat och har redan blivit en sorts outtalad mall där innehållet hamras in.

Så dokumentet med det dumma namnet "Ritning av dokumentformuläret (videoram)" i projektet ska och ska inte vara tomt.

Vad är bra i standarden

Varje standard är bra genom att den tillåter kunden och entreprenören att tala samma språk och ger en garanti för att kunden åtminstone inte kommer att ha några klagomål "i form" på de överförda resultaten.

Och GOST 34-standarderna är också bra eftersom de sammanställdes av smarta människor, testade genom åren, och de har ett tydligt mål - att på papper så fullständigt som möjligt beskriva den komplexa abstrakta essensen som alla automatiserade kontrollsystem representerar.

När du på ett kompetent sätt behöver ställa en uppgift för västerländska entreprenörer som aldrig har hört talas om våra GOST-standarder, kan du också lita på dessa standarder, eller snarare på deras innehåll och semantiska komponent. För, jag upprepar, garantin för fullständig information är värd mycket. Oavsett hur mycket vi smickrar oss själva med den höga nivån på vår professionalism, kan vi glömma att inkludera elementära saker i våra krav, medan samma GOST 34.602-89 "kommer ihåg" allt. Om det inte är klart för dig hur resultatet av västerländska entreprenörers arbete ska se ut, titta på dokumentationskraven och rekommenderade avsnitt. Jag försäkrar dig, det är bättre att inte tänka på det! Troligtvis finns det västerländska analoger av våra standarder, där allt kan vara mer komplett, modernare och bättre. Tyvärr är jag inte bekant med dem, eftersom det ännu inte har funnits ett enda fall där våra GOST-standarder inte räckte till.

Du kan skratta åt det faktum att standardskaparna inte visste något om java eller .NET, om HD-skärmar och internet, men jag skulle inte råda dig att underskatta omfattningen av det arbete de gjorde och dess värde för vår professionella gemenskap.

Hur man läser och förstår dokumentationsstandarder enligt GOST-serien 34

Standarden delar upp alla dokument längs två axlar - tid och ämnesområde. Om du tittar på tabell 2 i GOST 34.201-89 kan du tydligt se denna uppdelning (kolumnerna "Skapelsestadiet" och "Del av projektet"

Stadier för att skapa ett automatiserat kontrollsystem

Stadierna av skapandet definieras i GOST 34.601-90. Tre av dem är relevanta för dokumentation:

• Utkast till design (ED)
• Teknisk design (TP)
• Utveckling av arbetsdokumentation (DD)

Preliminär design följer efter steget med tekniska specifikationer och tjänar till att utveckla preliminära designlösningar.

Tekniskt projekt beskriver det framtida systemet från alla vinklar. Dokument på TP-stadiet bör efter läsning lämna efter sig fullständig klarhet i föreslagna tillvägagångssätt, metoder, arkitektoniska och tekniska lösningar. I nästa fas kommer det att vara för sent att beskriva tillvägagångssätt och motivera tekniska lösningar, så fas P är nyckeln till framgångsrikt slutförande av arbetet, eftersom alla de olika kraven i de tekniska specifikationerna måste återspeglas i dokumenten för fas P Vid fas P kanske systemet inte existerar alls.

Arbetsdokumentation designad för framgångsrik driftsättning, driftsättning och vidare drift av det nya systemet. Detta är dokument som innehåller mycket specifik information som beskriver fysiskt existerande entiteter, till skillnad från P-fasen, som beskriver framtida prakt.

Delar (sektioner) av projektdokumentation för skapandet av ett automatiserat styrsystem

Ämnesområdet är uppdelat i ”Bestämmelser”. Till en början verkar det som att en sådan uppdelning är överflödig och onödig. Men när man börjar arbeta med denna verktygslåda i praktiken blir ideologin som är inbäddad i den gradvis tydlig.

Ett automatiserat system, enligt definitionen av kompilatorerna av GOST, är en kombination av hårdvara, mjukvara och kommunikationskanaler som behandlar information som kommer från olika källor i enlighet med vissa algoritmer och producerar bearbetningsresultat i form av dokument, datastrukturer eller kontrollåtgärder. En primitiv modell av det enklaste maskingeväret.

För att fullständigt beskriva denna "maskin" görs följande avsnitt (som i ritningen):

Programvara (MS), besvara frågorna: vilken logik är fast inuti den "svarta lådan"? Varför valdes just dessa algoritmer, dessa speciella formler och dessa specifika koefficienter?

Matematisk programvara vet ingenting om processorer eller databaser. Detta är ett separat abstrakt område, bostaden för "sfäriska hästar i ett vakuum." Men matematisk programvara kan vara mycket nära relaterad till ämnesområdet, aka Real Life. Till exempel ska styralgoritmer för trafikledningssystem godkännas av Statens trafiksäkerhetsinspektion innan de godkänns av kunden. Och då förstår man varför de finns med i en separat bok. För ingen inom trafikpolisen är intresserad av vilket OS som applikationsservern kommer att köras på, men vilken skylt och hastighetsgräns som dyker upp på tavlan i regn eller snö är väldigt intressant. De är ansvariga för sin del och tänker inte skriva på något annat. Å andra sidan, när de skrev under, kommer det inte att finnas några frågor om den tekniska sidan av frågan - varför de valde de tavlor eller trafikljus och inte andra. "Fädernas" visdom manifesteras exakt i sådana praktiska fall.

Informationsstöd (IS). Ännu en del av systemet. Den här gången görs den svarta lådan i vårt system transparent och vi tittar på informationen som cirkulerar i den. Föreställ dig en modell av det mänskliga cirkulationssystemet när alla andra organ är osynliga. Något sådant här är Information Support. Den beskriver informationsflödets sammansättning och vägar inom och utanför, den logiska organisationen av information i systemet, en beskrivning av referensböcker och kodningssystem (de som gjort program för produktion vet hur viktiga de är). Den huvudsakliga beskrivande delen faller på TP-stadiet, men vissa "rudiment" flödar in i RD-steget, som dokumentet "Databaskatalog". Det är tydligt att det tidigare innehöll exakt vad som står i rubriken. Men idag, försök att skapa ett sådant dokument för ett komplext komplext system, när systemet väldigt ofta använder köpta delsystem med sina egna mystiska informationslagringar. Jag säger inte ens att det här dokumentet inte behövs särskilt nu.

Eller här är "Status för datorlagringsmedia". Det är tydligt att den tidigare innehöll ett antal magnetiska trummor eller filmrullar. Vad ska jag lägga in där nu?

Kort sagt, i RD-fasen representerar informationsstöddokument en ganska skadlig rudiment, eftersom de formellt borde finnas, men det finns inget speciellt att fylla dem med.

programvara. Allas favoritdel av projektdokumentation. Ja, om så bara för att det bara är ett dokument! Och då förstår alla vad som måste skrivas ner där. Men jag upprepar det ändå.

I det här dokumentet måste vi berätta för dig med hjälp av vilken programvara algoritmerna som beskrivs i ML exekveras och bearbetar informationen som beskrivs i IR. Det vill säga att det inte finns något behov av att duplicera information från andra avsnitt här. Här ges systemets arkitektur, motiveringen för de valda mjukvaruteknologierna, deras beskrivning (alla möjliga systemsaker: programmeringsspråk, ramverk, operativsystem, etc.). Även i detta dokument beskriver vi hur informationsbehandlingsverktyg är organiserade (meddelandeköer, lagring, säkerhetskopieringsverktyg, tillgänglighetslösningar, alla typer av applikationspooler, etc.). Standarden innehåller en detaljerad beskrivning av innehållet i detta dokument, som alla specialister förstår.

Teknisk support (TO). Inte mindre älskad del av projektdokumentationen. Den rosa bilden grumlas bara av det överflöd av dokument som behöver utvecklas. Totalt kräver standarden utveckling av 22 dokument, varav 9 är på TC-stadiet.

Faktum är att standarden ger en beskrivning av all teknisk support, inklusive datorhårdvara och nätverk, tekniska system och till och med konstruktionsdelen (om så krävs). Och denna ekonomi regleras av ett stort antal standarder och förordningar, samordnade i olika organisationer, och därför är det bekvämare att dela upp allt i delar och koordinera (redigera) i delar. Samtidigt låter standarden dig kombinera vissa dokument med varandra, vilket är vettigt om hela gänget godkänns av en person.

Glöm inte heller att en uppsättning kvalitetsstandarder innebär inspelning och lagring av tekniska dokument, och våra "böcker" från kunden kan distribueras mellan olika arkiv, beroende på ämnet för beskrivningen. Detta är ytterligare ett argument för att fragmentera dokumentation.

Organisationsstöd (OO). Efter att ha undertryckt önskan, som är normal för en tekniker, att hoppa igenom detta avsnitt så snabbt som möjligt, tvärtom, kommer jag att överväga det mer i detalj. Sedan, kollegor, har det nyligen funnits några dåliga trender i projekt som kräver förtydliganden i detta avsnitt.

På TP-stadiet innehåller avsnittet endast ett dokument " Beskrivning av organisationsstrukturen", där vi måste tala om för kunden vad han bör förbereda sig för när det gäller att ändra organisationsstrukturen. Plötsligt behöver du organisera en ny avdelning för att driva ditt system, införa nya tjänster osv.

På RD-stadiet dyker det upp andra, mer intressanta dokument, som jag skulle vilja överväga separat.

Användarguide. Kommentarer är onödiga tycker jag.

Metodik (teknik) för datorstödd design. Vid behov kan du inkludera en beskrivning av processen för mjukvarubyggande, versionskontroll, testning etc. i detta dokument. Men detta är om kunden i den tekniska specifikationen önskar att personligen montera programvaran. Om han inte kräver detta (och inte betalar för det), är hela ditt interna kök inte hans sak, och det här dokumentet behöver inte göras.

Tekniska instruktioner. På grund av modet för att formalisera affärsprocesser försöker en listig kund ibland stoppa in driftsbestämmelser i detta dokument. Så, under inga omständigheter bör du göra detta.

Beskrivning av affärsprocesser, roll- och arbetsbeskrivningar, arbetsföreskrifter – allt detta är ORD, det vill säga organisatorisk och administrativ dokumentation. Vilket är produkten av ett konsultprojekt, som så vitt jag förstår inte köpts av dig. Och vi köpte ett tekniskt projekt av dig och även teknisk dokumentation för det.

Den tekniska instruktionen är ett lager mellan bruksanvisningen och bruksanvisningen. RP beskriver i detalj Hur du måste göra vissa åtgärder i systemet. Den tekniska instruktionen säger det somåtgärder måste utföras i vissa fall relaterade till driften av systemet. Grovt sett är en teknisk instruktion en kort sammanfattning av RP för en specifik position eller roll. Om kunden inte har roller bildade eller han vill att du själv skapar roller och jobbkrav, ta med de mest grundläggande rollerna i dokumentet, till exempel: operatör, senior operatör, administratör. Kundens kommentarer om ämnet "men det är inte så med oss" eller "vi gillar det inte" bör åtföljas av en lista över roller och en beskrivning av arbetsansvar. Eftersom affärsprocesser vi vi sätter det inte. Vi är dessa affärsprocesser automatisera.

Jag kommer att skriva om de beskrivna rakes separat, med färgglada exempel, eftersom detta inte är första gången som detta har upprepats i olika sektorer av den "nationella ekonomin."

Beskrivning av den tekniska processen för databehandling (inklusive telebehandling). En patetisk kvarleva från grottåldern, då det fanns speciellt utsedda "datoroperatörer" som matade hålkort till maskinen och packade en utskrift av resultatet i ett kuvert. Denna instruktion är till för dem. Jag kan inte säga exakt vad du ska skriva i den på 2000-talet. Gå ut själv. Det bästa är att bara glömma detta dokument.

Systemomfattande lösningar (WSO). Standarden tillhandahåller 17 dokument i OP-delen. För det första är dessa nästan alla dokument från den preliminära fasen av Schematic Design. För det andra är det alla typer av uppskattningar, beräkningar och korta beskrivningar av automatiserade funktioner. Det vill säga information för personer som inte kommer från den huvudsakliga IT-produktionen, utan för supportpersonal - chefer, estimerare, inköpsspecialister, ekonomer, etc.

Och för det tredje innehåller OP ett megadokument som heter "Förklarande anmärkning för det tekniska projektet", som är tänkt att vara ett slags sammanfattning, men i själva verket lägger många designers in allt användbart innehåll från TP-stadiet. Ett sådant radikalt tillvägagångssätt kan vara motiverat och till och med ömsesidigt fördelaktigt för både beställaren och entreprenören, men i vissa fall.

Alternativ för att använda GOST 34

1. Fullständig och exakt efterlevnad av standarden. Naturligtvis kommer ingen att skriva ett sådant moln av dokument frivilligt. Därför förbereds en komplett uppsättning dokument endast på brådskande begäran från kunden, som han säkrade i de tekniska specifikationerna och även fastställd med ett avtal ovanpå. I det här fallet måste du ta allt bokstavligt och ge kunden fysiska "böcker", där det kommer att finnas namnen på dokumenten från tabell 2 i GOST 34.201-89, med undantag för helt onödiga, vars lista du måste diskutera och säkra skriftligt. Innehållet i dokumenten ska också, utan någon fantasi, överensstämma med RD 50-34.698-90, ända ner till sektionernas namn. För att få kundens hjärna att explodera delas ibland ett stort system in i delsystem och separat designdokumentation utfärdas för varje delsystem. Det ser skrämmande ut och är inte föremål för normal kontroll med hjälp av det jordiska sinnet. Speciellt när det gäller integrationen av delsystem. Vilket avsevärt förenklar acceptansen. Huvudsaken är att du själv inte blir förvirrad och att ditt system fortfarande fungerar som det ska.
2. Vi älskar bara GOST-standarder. Seriösa stora företag älskar standarder. Eftersom de hjälper människor att förstå varandra bättre. Om din kund är känd för sin kärlek till ordning och standardisering, försök att följa standard GOST-ideologin när du utvecklar dokument, även om detta inte krävs av de tekniska specifikationerna. Du kommer att bli bättre förstådd och godkänd av de godkännande specialisterna, och du kommer själv inte att glömma att inkludera viktig information i dokumentationen, du kommer bättre att se målstrukturen för dokumenten, planera arbetet med att skriva dem mer exakt och spara dig själv och dina kollegor mycket nerver och pengar.
3. Vi bryr oss inte om dokumentation, så länge allt fungerar. Den oansvariga kundens försvinnande utseende. En liknande syn på dokumentation kan fortfarande hittas bland små och fattiga kunder, såväl som i auktoritära "idiotokratier" som blivit över från perestrojkans tid, där chefen är omgiven av lojala vänner - direktörer, och alla frågor löses i personliga samtal . Under sådana förhållanden är det fritt fram att helt försumma dokumentation, men det är trots allt bättre att inte slå ner sikten och åtminstone schematiskt fylla i dokumentationen med innehåll. Om inte till den här kunden, skicka den sedan vidare (sälj den) till nästa.

Slutsats

Den här artikeln handlade om våra GOST-standarder för att dokumentera automatiserade styrsystem. GOSTs är gamla, men som det visar sig är de fortfarande mycket användbara i hushållet. Bortsett från några uppenbara rudiment har strukturen i dokumentationen egenskaperna fullständighet och konsistens, och efterlevnad av standarden eliminerar många projektrisker, som vi kanske inte var medvetna om till en början.

Jag hoppas att materialet som presenterades var användbart för dig, eller åtminstone intressant. Trots den uppenbara tröttheten är dokumentation ett viktigt och ansvarsfullt jobb, där noggrannhet är lika viktigt som att skriva bra kod. Skriv bra dokument, kollegor! Och nästa vecka åker jag på två affärsresor i rad, så jag kan inte garantera publicering av nytt material (jag har ingen cache, jag skriver från mitt huvud).

Dokumentets namn:
Dokumentnummer:	1.16-78
Dokumenttyp:	GOST
Mottagande myndighet:	Sovjetunionens statliga standard
Status:	Inaktiv
Publicerad:
Acceptansdatum:	30 november 1978
Start datum:	1 juli 1979
Utgångsdatum:	1 januari 1987
Revisionsdatum:	1 januari 1983

GOST 1,16-78

Grupp T50

STATENS STANDARD FÖR USSR UNION

STATLIGT STANDARDISERINGSSYSTEM

Förklarande anmärkning till utkastet till standard. Konstruktion, innehåll, presentation och design

Statligt standardiseringssystem. Förklarande anmärkning till utkast till standard. Lay-out, innehåll, formulering och formell presentation

Införandedatum 1979-07-01

Genom dekret från USSR State Committee on Standards daterat den 30 november 1978 N 3205 fastställdes introduktionsdatumet från 07/01/79

ÅTERUTGIFT med ändring nr 1, godkänd i november 1981 (IUS 3-82)


Denna standard fastställer krav för konstruktion, innehåll, presentation och utförande av förklarande anteckningar till utkast till statliga, industri, republikanska standarder och standarder för företag av alla slag.

1. ALLMÄNNA BESTÄMMELSER

1. ALLMÄNNA BESTÄMMELSER

1.1. En förklarande notering till utkastet till standard upprättas för varje revidering av utkastet som skickas för granskning, skickas för godkännande och lämnas för godkännande.

1.2. En förklarande notering till utkastet till standard ska upprättas av den organisation (företaget) som utvecklat standarden.

Om det finns flera utvecklare, upprättas en förklarande notering till standardutkastet av den ledande organisationen (företags)-utvecklaren.

1.3. En oberoende förklarande not upprättas för varje standard som utvecklas.

Det är tillåtet att upprätta en förklarande not under samtidig utveckling, förberedelse för samordning och godkännande av sammanhängande standarder av samma kategori för homogena standardiseringsobjekt.

2. KRAV FÖR KONSTRUKTION, INNEHÅLL OCH PRESENTATION AV EN FÖRKLARANDE ANMÄRKNING

2.1. Titeln på den förklarande anmärkningen anger standardens kategori och fullständiga namn, serienumret på utkastet till standardrevision och (eller) information om standardens utvecklingsstadium.

Till exempel:

Förklarande anteckning

till utkastet till statlig standard "Sytrådar av natursilke. Tekniska förhållanden" (första upplagan skickas ut för granskning).

Förklarande anteckning

till utkastet till statlig standard "Kartografiska enheter. Termer och definitioner" (slutlig utgåva lämnas in för godkännande)

2.2. Den förklarande anmärkningen till utkastet till standard bör bestå av avsnitt som är numrerade i följd genom hela den förklarande anmärkningen och betecknas med arabiska siffror med en punkt i slutet av numret. Avsnittsrubriker ska vara med versaler.

Vid behov kan den förklarande anteckningen delas in i underavsnitt, stycken och stycken enligt kraven som fastställs i GOST 1.5-68 * för standarder.
________________
* Dokumentet är inte giltigt på Ryska federationens territorium. Ersatt av GOST 1.5-85 (inställd utan ersättning), nedan i texten

2.3. Den förklarande anmärkningen bör bestå av avsnitt ordnade i följande ordning:

grund för att utveckla standarden;

mål och mål för standardutveckling;

data om standardiseringen av objektet i början av utvecklingen av utkastet till standard;

egenskaper hos standardiseringsobjektet;

vetenskaplig och teknisk nivå för standardiseringsobjektet;

teknisk och ekonomisk effektivitet från implementeringen av standarden;

det förväntade datumet för implementeringen av standarden och den förväntade perioden för dess giltighet;

förhållande till andra standarder;

information om distribution för feedback (för alla utgåvor av standardutkastet, utom den första);

information om godkännande (endast för den slutliga versionen av utkastet till standard som lämnats in för godkännande);

informationskällor;

ytterligare information.

Vid sammanställning av förklarande anteckningar för den andra och efterföljande (förutom den slutliga) utgåvan av standardutkastet är det tillåtet att inte inkludera avsnitt i dessa förklarande anteckningar vars innehåll inte har ändrats.

2.4. En förklarande notering för varje utgåva av utkastet till standard upprättas utifrån de indikatorer, normer, egenskaper, krav som ingår i denna utgåva, med motivering för deras ändringar.

2.5. I avsnittet "Bas för utveckling av standarden" bör du ange ämnesnumret enligt den godkända planen, datum och namn på organisationen som godkände referensvillkoren.

Vid framtagande av ett utkast till standard som inte ingår i standardiseringsplanen (ett oplanerat ämne) bör de högre myndigheternas direktivhandlingar som standarden utvecklas utifrån anges.

Det bör också anges i enlighet med vilket omfattande standardiseringsprogram, om något, standarden utvecklas.

2.6. I avsnittet "Mål och mål med att ta fram en standard" ska du ange de slutliga resultaten som kommer att uppnås genom att använda standarden, och de uppgifter som kommer att lösas under utvecklingen av standarden.

2.7. I avsnittet "Data om standardiseringen av ett objekt vid början av utvecklingen av ett utkast till standard", ange information om att standarden utvecklas för första gången, eller information om aktuella standarder, tekniska specifikationer, instruktioner och andra dokument som gällde i början av utvecklingen av ett utkast till standard för detta standardiseringsobjekt.

2.8. I avsnittet "Kännetecken för standardiseringsobjektet", beroende på objektet som standardiseras (produkter, indikatorer, normer, egenskaper, krav av organisatorisk, metodologisk och allmän teknisk karaktär), kategori och typ av standard, ange huvudindikatorerna, normer, egenskaper, krav i utkastet till standard som definierar den vetenskapliga och tekniska nivån för standardiseringsobjektet och deras genomförbarhetsstudie.

De viktigaste indikatorerna, normerna, egenskaperna, kraven i utkastet till standard kan vara kraven i huvudriktningarna för utvecklingen av den nationella ekonomin i Sovjetunionen, indikatorer för standardiseringsplaner och tekniska specifikationer för utveckling av standarder och indikatorer för användning av material Resurser.

Detta avsnitt ger information från rapporter om resultaten av utfört forsknings- och utvecklingsarbete eller länkar till rapporter som anger var rapporterna finns, samt information om resultaten av patentforskning om föremålet för standardisering, om bevisade inhemska och utländska upptäckter och uppfinningar publicerade under de senaste tio åren före godkännandet av standarden, och slutsatsen om testning av prototyper eller pilotpartier av de produkter som standardiseras.

2.9. I avsnittet "Vetenskaplig och teknisk nivå för standardiseringsobjektet" tillhandahålls en jämförande analys av indikatorer, normer, egenskaper, krav enligt utkastet till standard;

med indikatorer, normer, egenskaper, krav på standarder (rekommendationer) från CMEA, ISO, IEC och andra internationella organisationer;

med indikatorer, normer, egenskaper, krav från inhemska och utländska standarder;

med de bästa exemplen på utrustning och varor av inhemsk produktion och utländska företag;

med de högsta moderna prestationerna inom vetenskap, teknik, avancerad inhemsk och utländsk erfarenhet inom detta område.

Detta avsnitt bör återspegla överensstämmelsen med indikatorer, normer, egenskaper och krav i utkastet till standard:

uppgifter definierade i huvudriktningarna för utvecklingen av den nationella ekonomin i Sovjetunionen;

komplexa vetenskapliga och tekniska program, inklusive föremålet för standardisering;

omfattande standardiseringsprogram.

I detta avsnitt, baserat på ovanstående data, ges en generell slutsats om den vetenskapliga och tekniska nivån på indikatorer, normer, egenskaper och krav för standardiseringsobjektet.

Om, med den slutliga utgåvan av standardutkastet som lämnats in för godkännande, jämförelsetabeller av indikatorer eller en karta över den tekniska nivån och kvaliteten på produkter i enlighet med GOST 2.116-71* skickas separat, anger den förklarande anmärkningen till denna utgåva endast resultaten av den jämförande analysen och ger en allmän slutsats om den vetenskapliga och tekniska nivån på indikatorer, normer, egenskaper, krav för standardiseringsobjektet.
________________
GOST 2.116-84. - Databastillverkarens anteckning.

2.10. I avsnittet "Teknisk och ekonomisk effektivitet från implementeringen av standarden" bör du ange den förväntade ekonomiska effektiviteten, de ekonomiska fördelarna med standardiseringsobjektet och de huvudsakliga källorna för att få den ekonomiska effekten.

Om det är omöjligt att beräkna den ekonomiska effektiviteten av att implementera en standard bör nödvändig motivering tillhandahållas. Detta avsnitt anger sociala effektivitetsindikatorer från implementeringen av standarden (om några).

2.11. I avsnittet "Beräknat datum för standardens ikraftträdande och förväntad giltighetstid" ska följande anges:

motivering av den förväntade tidsramen för införandet av standarden, med hänsyn till den tid som krävs för att utföra aktiviteter för att implementera standarden;

motivering av huvudaktiviteterna för implementering av standarden, inklusive motivering av möjligheten att organisera centraliserad (specialiserad) produktion av produkter;

motivering för godkännande av ett utkast till standard utan begränsning av giltighetstid eller motivering för standardens förväntade giltighetstid.

2.12. I avsnittet "Släktskap med andra standarder" bör du ange:

att utkastet till standard hör till en uppsättning standarder som ingår i systemet;

uppgifter om förhållandet mellan utkastet till standard och andra standarder, såväl som standarder och rekommendationer från CMEA och andra internationella organisationer;

rimliga förslag om behovet av att revidera, utveckla förändringar eller upphäva befintliga sammanhängande standarder.

Vid en revidering av en produktstandard lämnas information om utbytbarhet av produkter enligt utvecklade och gällande standarder samt åtgärder för att säkerställa drift och reparation av produkter tillverkade enligt gällande standard.

2.13. I avsnittet "Information om utskick av recensioner" bör du ange:

antalet organisationer (företag) till vilka utkastet till standard skickades;

antal organisationer (företag) som skickade recensioner;

en kort generaliserad beskrivning av recensionerna;

resultat av granskning av recensioner.

2.14. I avsnittet "Information om godkännande" ska du ge information om godkännandet av utkastet till standard med intresserade organisationer (företag); om att hålla förlikningsmöten; ge en kort beskrivning av de diskuterade frågorna; indikera oenighet som kvarstod under utvecklingen av utkastet till standard.

Om utkastet till standard inte kräver godkännande bör det i den förklarande anmärkningen anges att standarden inte är föremål för godkännande.

2.15. I avsnittet "Informationskällor" bör du ange de informationskällor som används vid utvecklingen av utkastet till standard, inklusive:

normativa handlingar i gällande lagstiftning;

föreskrifter för ministerier, departement, föreningar och företag;

inhemska standarder och tekniska specifikationer (deras beteckningar);

utländska och internationella standarder och andra dokument från internationella organisationer (deras beteckningar och namn);

patentforskningsrapporter;

rapporter om genomfört forsknings- och utvecklingsarbete m.fl.

2.16. I avsnittet "Ytterligare information" kan du vid behov inkludera:

alternativ för att lösa vissa frågor och (eller) individuella frågor angående utkastet till standard med en begäran till organisationer (företag) till vilka utkastet till standard skickas för granskning för att uttrycka sin åsikt;

och andra frågor.

2.17. Den förklarande anmärkningen bör presenteras i enlighet med kraven i GOST 1.5-68, avsnitt 1, för standarder.

3. KRAV FÖR ATT FYLJA EN FÖRKLARANDE ANMÄRKNING

3.1. Den förklarande anmärkningen till utkastet till standard bör skrivas ut i enlighet med kraven i GOST 6.38-72*.
________________
* Dokumentet är inte giltigt på Ryska federationens territorium. GOST R 6.30-2003 är giltig. - Databastillverkarens anteckning.

3.2. Den förklarande noten till utkastet till statlig, industri, republikansk standard måste undertecknas av chefen (ställföreträdande chefen) för den ledande organisationen (företags)-utvecklaren, chefen för standardiseringstjänsten, chefen för utveckling (ämne) och utförare.

Den förklarande anmärkningen till utkastet till företagsstandard ska undertecknas av chefen för utvecklingsavdelningen (avdelningen), utvecklingschefen (ämne) och artisterna.

Signaturerna finns på sista sidan i den förklarande anmärkningen till utkastet till standard.

3.3. Den förklarande anmärkningen till utkastet till standard ska ha separata sidnummer och inte innehålla ett omslag.

Elektronisk dokumenttext
utarbetad av Kodeks JSC och verifierad mot:
officiell publikation
Statligt system
standardisering: Samling av GOST. -
M.: Standards Publishing House, 1983

GOST 1.16-78 GSS. Förklarande anmärkning till utkastet till standard. Konstruktion, innehåll, presentation och design (med ändring nr 1)

Dokumentets namn:	GOST 1.16-78 GSS. Förklarande anmärkning till utkastet till standard. Konstruktion, innehåll, presentation och design (med ändring nr 1)
Dokumentnummer:	1.16-78
Dokumenttyp:	GOST
Mottagande myndighet:	Sovjetunionens statliga standard
Status:	Inaktiv
Publicerad:	Officiell publikation. Statligt standardiseringssystem: Samling av GOST. - M.: Standards Publishing House, 1983
Acceptansdatum:	30 november 1978
Start datum:	1 juli 1979
Utgångsdatum:	1 januari 1987
Revisionsdatum:	1 januari 1983

Som regel är den förklarande anmärkningen det mest komplexa dokumentet om programvara, vilket ibland orsakar mycket kontrovers och diskussion kring dess innehåll. Varför händer detta?

Syftet med den förklarande anmärkningen

Vi har redan sagt att i mjukvaruutveckling är detta ett av de viktiga stegen. Den bör innehålla en beskrivning av ditt system med hänsyn till de utvalda teknikerna, som GOST 34 kräver av oss. Och dokumentet förklarande anmärkning till det tekniska projektet, eller kort sagt PZ, är ett av huvuddokumenten i detta skede. Och, jag måste säga, oftast är det den förklarande anmärkningen som är det mest komplexa dokumentet om programvara, vilket ibland orsakar mycket kontrovers och diskussion kring dess innehåll.

Sammansättning av en vanlig förklarande not

Den förklarande anmärkningen till det tekniska projektet innehåller avsnitt som:

– Introduktion. Detta avsnitt ger systemets fullständiga namn och utvecklingsämnet, samt en lista över dokument som låg till grund för arbetet med projektet.

– Syfte och omfattning. Den beskriver de mål och mål som kommer att lösas med hjälp av systemet, samt omfattningen av dess användning.

– Specifikationer. Detta avsnitt är vanligtvis uppdelat i underavsnitt som beskriver: ställa in uppgiften för att skapa ett program; den matematiska apparatur som används; programvara operationsalgoritm; struktur för in- och utdata; sammansättning av hårdvara och mjukvara. Det är också nödvändigt att tillhandahålla beräkningar och analysresultat för att motivera valet av exakt de lösningar som nämns i dokumentet.

– Förväntade tekniska och ekonomiska indikatorer. Avsnittet innebär en ekonomisk motivering för utvecklingen med hänsyn till dess tekniska indikatorer.

– Källor som används i utvecklingen. Avsnittet är en lista över dokument, artiklar och publikationer som refererades till i texten.

Standarder för förklarande anteckningar

Sammansättningen av sektionerna bestäms av GOST 19.404, men standarden tillåter att dessa sektioner kombineras vid behov och även att lägga till nya. Vid användning av GOST-serien 34 bör ett dokument utvecklas i enlighet med RD 50-34.698. Dokumentet måste dock hålla sig inom kraven i allmänna standarder, såsom GOST 19.105.

Kostnad för att utveckla en förklarande anteckning

Hur kan du skapa ett programdokument till lägsta kostnad som är mest användbar för ditt projekt, som:

– Å ena sidan, tydligt och begripligt presenterar all nödvändig (och ibland tråkig) information, inklusive komplexa tekniska detaljer;

GOST 19.404-79

Grupp T55

INTERSTATE STANDARD

Enhetligt system för programdokumentation

FÖRKLARANDE ANTECKNING

Krav på innehåll och design

Enhetligt system för programdokumentation. Förklarande anteckning. Krav på innehåll och presentationsform

Införandedatum 1981-01-01

Genom dekret från USSR State Committee on Standards daterat den 11 december 1979 N 4753, sattes genomförandedatumet till 01/01/81

NYUTGÅVA. januari 2010


Denna standard fastställer krav på innehållet och utformningen av programdokumentet "Förklarande anmärkning", definierat av GOST 19.101-77, som är en del av dokumenten vid utvecklingsstadierna för programmets preliminära och tekniska design.

1. ALLMÄNNA BESTÄMMELSER

1. ALLMÄNNA BESTÄMMELSER

1.1. Strukturen och utförandet av dokumentet fastställs i enlighet med GOST 19.105-78.

Sammanställning av informationsdelen (kommentarer och innehåll) är valfritt.

1.2. Den förklarande anmärkningen måste innehålla följande avsnitt:

introduktion;

Syfte och omfattning;

specifikationer;

förväntade tekniska och ekonomiska indikatorer;

källor som används i utvecklingen.

Beroende på dokumentets egenskaper kan enskilda avsnitt (underavsnitt) kombineras, liksom nya avsnitt (underavsnitt) kan införas.

2.1. I avsnittet "Introduktion" anger du programmets namn och (eller) symbolen för utvecklingsämnet, såväl som de dokument på grundval av vilka utvecklingen genomförs, som anger organisationen och datumet för godkännande.

2.2. I avsnittet "Syfte och omfattning" ange syftet med programmet och en kort beskrivning av programmets omfattning.

2.3. Avsnittet "Tekniska specifikationer" bör innehålla följande underavsnitt:

ställa in problemet för att utveckla ett program, beskriva de matematiska metoderna som används och, om nödvändigt, beskriva antagandena och begränsningarna förknippade med den valda matematiska apparaten;

beskrivning av algoritmen och (eller) programmets funktion med motiveringen för att välja algoritmen för att lösa problemet, möjliga interaktioner mellan programmet och andra program;

beskrivning och motivering för val av metod för att organisera in- och utdata;

beskrivning och motivering för val av hård- och mjukvara utifrån gjorda beräkningar och (eller) analyser, distribution av lagringsmedia som används av programmet.

2.4. I avsnittet "Förväntade tekniska och ekonomiska indikatorer" anges tekniska och ekonomiska indikatorer som motiverar fördelen med det valda tekniska lösningsalternativet, såväl som, om nödvändigt, förväntade operativa indikatorer.

2.5. I avsnittet "Källor som används i utvecklingen" anges en lista över vetenskapliga och tekniska publikationer, reglerande och tekniska dokument och annat vetenskapligt och tekniskt material som refereras i huvudtexten.

2.6. Bilagan till dokumentet kan innehålla tabeller, motiveringar, metoder, beräkningar och andra dokument som används i utvecklingen.



Elektronisk dokumenttext
utarbetad av Kodeks JSC och verifierad mot:
officiell publikation
Enat system för programdokumentation:
lö. GOST. -
M.: Standardinform, 2010