Reflections on state certification of antiviruses

    Every year our valiant regulators (FSB and FSTEC in the first place) require more and more various kinds of licenses, permits, certificates, and the like from IT specialists. The FSB imposes the use of its “proprietary” encryption algorithms, instead of the obscure global ones. FSTEC strives to stick its nose deeper into the code of software products, in its search for undeclared features, “caring” for the security of our information.
    But is there any sense in such studies in relation to modern antiviruses?

    You can use any antiviruses for your home, but for government agencies or to protect personal data in personal data information systems (ISPDn) you will have to choose a product that has passed the appropriate certification.

    Legislation


    So, according to the Decree of the Government of the Russian Federation No. 781 of 11/17/2007, the information protection means used in ISPDn are required to undergo the conformity assessment procedure (established requirements, which are prescribed in the FSTEC guidelines) in the prescribed manner. In particular, the use of only certified solutions for state institutions is spelled out in documents such as Presidential Decrees of March 17, 2008. No. 351 “On measures to ensure the information security of the Russian Federation when using information and telecommunication networks of international information exchange” and dated May 12, 2004 No. 611 "On measures to ensure the information security of the Russian Federation in the field of international information exchange."

    The software is checked for compliance with the requirements of the guidance document."Protection against unauthorized access to information. Part 1. Software for information security. Classification by the level of control of the absence of undeclared opportunities .

    The key point of this RD is this plate:

    Requirements for the level of control. The list of requirements.

    No.Name of requirement
    Control level
    4321
    Documentation Requirements
    1Monitoring the composition and content of documentation
    1.1.Specification (GOST 19.202-78)+===
    1.2.Description of the program (GOST 19.402-78)+===
    1.3.Description of application (GOST 19.502-78)+===
    1.4.Explanatory Note (GOST 19.404-79)-+==
    1.5.Texts of programs included in the software (GOST 19.401-78)+===
    Test Content Requirements
    2.Monitoring the initial state of software+===
    3.Static analysis of program sources
    3.1.Controlling the completeness and lack of redundancy of source texts+++=
    3.2.Compliance control of software source code to its object (boot) code+==+
    3.3.Control communications functional objects management-+==
    3.4.Monitoring the relationships of functional objects by information-+==
    3.5.Control of information objects-+==
    3.6.Monitoring the presence of specified structures in the source code--++
    3.7.Formation of the list of functional objects execution routes-++=
    3.8.Analysis of critical execution paths of functional objects--+=
    3.9.Analysis of the algorithm of the operation of functional objects based on flowcharts, diagrams, etc., constructed from the sources of controlled software--+=
    4.Dynamic analysis of program sources
    4.1.Monitoring the execution of functional objects-++=
    4.2.Comparison of actual execution routes of functional objects and routes constructed in the process of conducting static analysis-++=
    5.Reporting++++
    Designations
    "-" - there are no requirements for this level;
    "+" - new or additional requirements;
    "=" - the requirements coincide with the requirements of the previous level.

    According to paragraph 3 "Monitoring the initial state of the software" list of requirements
    • Control consists in fixing the initial state of the software and comparing the results with those given in the documentation.
    • The results of monitoring the initial state of the software should be calculated unique values ​​of the checksums of the boot modules and source codes of the programs included in the software.
    • Checksums should be calculated for each file included in the software.
    Yeah, fine, the checksums of all the program files should be fixed in the documentation. This would be a ride for the firmware of the crypto router (in general, this is done there), but certainly not for the antivirus! Even if we do not take into account the software modules directly, the signature databases (by the way, “included in the software”) are updated almost hourly. What kind of monitoring the status of the software can be discussed?

    Currently, FSTEC certified products of several anti-virus companies:
    • ESET (4th level of lack of NDV);
    • Dr.Web (level 2 and 3);
    • Kaspersky Lab (Level 3);
    • VBA32 (Level 4).

    for instance


    For example, take Kaspersky Anti-Virus (just an example), they are very proud of their FSTEC certificates, not missing the chance to trump them with clients.

    Certificate of Conformity (No. 1384) for the “Kaspersky Anti-Virus 6.0 for Windows Workstations” software product was issued back in 2007, then extended to 2013, during which time LK released 4 (!) Major updates (MP) for it, and the certificate is the same ! This means that no one has tested the product, just because the number of the major version has not changed ... And this is not to mention the daily update of the signature databases.



    There are no checksums in the certificate. Logically, why are they? At the first update, most of the files will simply change. Of course, this paperwork perfectly covers the fifth points of the heads of IT departments, but do those who issue such things really do not understand the whole nonsense of the situation ..?



    And here, in the certificate of conformity from the FSB, they are, but what is the point in them? Just check the distribution before installing.

    And what is the result?


    You have a bunch of pieces of paper on a protection tool, but :

     1. Nobody guarantees you no random (supposedly) errors in the code, including critical ones, which can be used to completely compromise the system. From the experience of using the same Kaspersky Anti-Virus 6.0, I can say that there are simply a huge number of errors remaining after all certifications (well, other products have less :). But is it possible to prove, for example, the intentionality of an abandoned “Buffer Overflow” hole? Hardly ...

     2.Thanks to advanced systems for updating and treating new threats, almost any modern anti-virus can perform arbitrary actions (so-called treatment scripts) by command from the update center. What prevents you from giving the command to find certain files on the computer, guarantee them, and then, in full accordance with all user agreements, transfer them “for analysis to virus analysts”? So what? Well, it happens, we considered these files to be malicious and, taking care of your safety, we analyzed them. For your own good! Sleep calmly, no malicious macros have been detected in your secret documents, and to that analyst we gouged out our eyes and cut off our tongue;)

    conclusions


    Existing methods for controlling the absence of undeclared capabilities in such software products as means of protecting information from dynamic threats are hopelessly outdated and cannot guarantee anything at all . And indeed, the ability to reliably keep in check this kind of system seems doubtful.
    The certificate will save you only from checking regulators, but not from any threats. Well, this is quite logical for our country, unfortunately ... p class =

    Also popular now: