Secure Automation and Continuous Monitoring (SACM) Requirements

As the group continues to define an architecture and use cases, some requirements can already be formed and be used to evolve the architecture as well. This section describes the requirements used by the SACM WG to assess and compare candidate information models and protocols to suit the architecture. These requirements express characteristics or features that a candidate protocol or data model must be capable of offering so as to ensure security and interoperability.

Until a richer architecture is agreed upon, the requiremens are predicated on the following model:

| Evaluator | <....B....> | Assessment Consumer | +--------+ +-----------+ +---------------------+ +-------| ^ ^ +--------+ | | C | | Asset | <-----+ v | +--------+ +-------------+ | | Repository | | +-------------+ | | +--------------------+ | | Posture Assessment |<---------------------+ | Repository | +--------------------+ ]]> The Architectural Model shown above demonstrates: Asset: is the endpoint of interest that is posture validated. Evaluator: is the service that affects the posture assessment and stores the posture result into a repository. Repository: is the storage component bound to the Evaluator that contains the posture assessment information. Posture Assessment Repository: is another type of repository that holds posture assessment information. While not bound to the Evaluator, it is another source of posture assessment information (e.g. a data aggregation point aggregating posture assessment with other attributes) that can provide information to serve SACM use cases. Assessment Consumer: is the service that requires the posture assessments information of one or more assets. Using this architectural reference model, the interfaces, data models and transports used to affect the posture assessment, e.g. A in the figure above have already been defined by different mechanisms, for example, an IETF defined one through NEA. As the focus of SACM is the information exchange to obtain the posture assessment information, it can be achieved through the interfaces shown as B. That is, it is not clear that there is a requirement for the Assessment Consumer to tap directly into the Repository. Similarly, it is not clear that SACM is chartered to define the interfaces and data model for how an Evaluator stores and transports the assessment results to the Repository. Thus, the focus of the requirements will revolve around the data models, protocols and transports for B, the communication of posture assessment from an Evaluator to an Assessment Consumer.

With the use cases spanning the need to collect, verify and update information about posture assessment, the set of high level requirements for the data model include: Posture Assessment includes the posture attributes relating to the asset configuration but its observed status as well. The use cases already articulate the many different means in which such configuration may be queried and will evolve over time. With the explosion of different assets evolving and means in which the assets are used and configured, the data model must be extensible to allow for the support of these new upcoming attributes. Considerations for the lightweight representation for these attributes and the tools used to consume the information will be required. Use cases, especially in the vulnerability assessment and threat defense applications require time criticality in both obtaining the information as well as consuming (e.g. parsing). The agility requirement is to ensure that the data model and its implementations are suitable to fit in different deployment models and scenarios. While it is presumed that we can leverage from standards, the data model must also adhere to Internationalization especially of display strings where applicable. To ensure a globalized and interoperable standard, it is understood that a minimum set of terms and attributes are defined to address the use cases defined, the expected set of posture assessments (including the expected posture configuration) and potential state or assertions.

The protocol requirements must account for different network topology scenarios to ensure that the information can be (securely) routed. With the focus of enabling the communication of posture assessment information, different scenarios must also be accounted for to address the use cases. The architectural model design tenets or requirements incude: To address the availability of posture assessment from different Evaluators that may support different interface (or data model) versions, a discovery mechanism may be introduced by which Posture assement Evaluators and Consumers can be registered with their capabilities (e.g. version support) clearly defined. The architectural model for designing the security and transport must account for a many-to-many connections. It is expected that an Assessment Consumer may probe, request and consume Posture assessment information from various Evaluators. Similarly, Evaluators will be providing their Posture assessment information to many Assessment Consumers. Assessment Consumers such as Firewalls or Intrusion Prevention Systems will require realtime notifications especially of posture assessment updates."> Just as there is a need to recieve timely updates of Posture Assessment information, there are applications where Assessment Consumers will require full state information of an Evaluator's Posture Assessment repository. As such, the repository may be very large based on both the number of assets and historical information stored by that Evaluator's Posture Assessment Repository; e.g. bulk synchronization or updates will be required."> As applications defined in the use cases may be deployed in different enterprise scenarios, an enterprise's network deployment may vary and must be taken into account. In a simple enterprise scenario, an application may be expected to sit in the same internet domain; however, in today's enterprise, the application, while still part of the enterprise, may be in a different internet domain or hosted on a private cloud. As such, the transport must account that there data delivery may be feasible in different OSI transport layers and in some cases, may be over a limited bandwidth connection.