Endpoint AV Software Security Requirements

  • • Events and data flow from kernel driver to AV Engine only (never from engine to kernel).
  • • Only the AV engine may open the kernel driver, and only on system startup. “Open” is the only control operation allowed from user mode to kernel driver. No other component may communicate with the kernel driver.
  • • The kernel driver startup and initialization code must validate, sanitize, and put into canonical form inputs from AV engine.
  • • Kernel driver initialization and startup must occur during the operating system startup sequence and must complete before users are allowed to log on to the system.
  • • Kernel driver initialization must complete before user logon to the system.
  • • Kernel driver initialization must occur as early as is possible during operating system startup.
  • • Before communications are allowed to proceed between any two or more modules in the system, validation must be performed on the identity and integrity of the calling process/module/binary. The preferred mechanism is validation of a digital signature over the binary. The signature must be signed by the private key of the software manufacturer.
  • • Every other component except the kernel driver must run in user mode.
  • • Installation should confine the reading and writing of the configuration files to the User Interface only.
  • • The system must have the ability to encrypt communications from/to the management console. This must be system administrator configurable.
  • • The management console must contain a user authentication system.
  • • The management console must contain a user authorization system.
  • • The management console must be able to authenticate to an LDAP.
  • • Management console authorization must be able to be performed by LDAP group membership.
  • • The administrator must be able to configure the management console to use any combination of:

° Local authentication ° LDAP authentication ° Local authorization ° LDAP group membership

  • • The user interface must re-authenticate the user before allowing changes.
  • • The management console will be able to run in a hardened state. There will be a customer document describing the hardened configuration. Hardening is configurable at customer discretion.
  • • Input validation coding must be implemented on every system input, with particular care to file parsing and examination path, the reading of the configuration files, and inputs from Communicator.
  • • The file and event handling paths through the code must be rigorously fuzzed.
  • • All components of the system must be built using a rigorous Security Development Lifecycle (SDL), with particular emphasis on secure coding techniques, input validation, and rigorous proof of the effectiveness of the SDL (i.e., security assurance testing for vulnerabilities).*
  • • Vulnerability testing before product release must be thorough and employ multiple, overlapping strategies and tools.

The above list of requirements completes the security analysis upon the endpoint security system. Because the management console is intended to be installed and run by the customer rather than by the vendor, the management console has to have sufficient security features so that the customer’s preferred security posture can be implemented: customer “manageable.” This is as opposed to hosted systems, which will be managed by the same organization. Manageable (by others) as opposed to managed (by the organization that created the software). This is an important distinction that was called out earlier in this book: “the deployment model.”

As was noted, the list of requirements presented here cannot be taken as a complete list, since some of the requirements refer to previous discussions and are not reiterated here. For a real-world system, I would list all requirements, so as to create a complete picture of the security needs of the system. The architectures presented in this book, I’ll reiterate, should be taken as examples, not as recipes.


1. NATO Science Committee (1969). Software Engineering Techniques. Report on a conference sponsored by the NATO Science Committee, p. 16. Quote from Edsger Dijksta, Rome, Italy, 27th to 31st October 1969. Retrieved from http://homepages.cs.ncl. ac.uk/brian.randell/NATO/nato1969.PDF.

Please see Core Software Security: Security at the Source, by James Ransome and Anmol Misra (CRC Press, © 2014), for a complete discussion of the SDL and how it can be implemented successfully.

< Prev   CONTENTS   Source   Next >