WO2004104793A2 - Systeme et methode pour une surveillance securisee d'entreprise et pour une gestion de configuration - Google Patents

Systeme et methode pour une surveillance securisee d'entreprise et pour une gestion de configuration Download PDF

Info

Publication number
WO2004104793A2
WO2004104793A2 PCT/US2004/016084 US2004016084W WO2004104793A2 WO 2004104793 A2 WO2004104793 A2 WO 2004104793A2 US 2004016084 W US2004016084 W US 2004016084W WO 2004104793 A2 WO2004104793 A2 WO 2004104793A2
Authority
WO
WIPO (PCT)
Prior art keywords
policy
implementer
security
component
framework
Prior art date
Application number
PCT/US2004/016084
Other languages
English (en)
Other versions
WO2004104793A3 (fr
Inventor
Silvio Renzi
Mauricio Renzi
Adrian Prezioso
Jeff Caro
Dennis Van Dusen
Original Assignee
Allegent Technology Group, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Allegent Technology Group, Inc. filed Critical Allegent Technology Group, Inc.
Priority to US10/882,153 priority Critical patent/US20070180490A1/en
Publication of WO2004104793A2 publication Critical patent/WO2004104793A2/fr
Publication of WO2004104793A3 publication Critical patent/WO2004104793A3/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227—Filtering policies
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227—Filtering policies
    • H04L63/0263—Rule management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic

Definitions

  • the invention relates generally to the field of network-based computing. More specifically, the invention relates to a system and metliod for providing network-based security services.
  • Enterprises are not simple hierarchies. Many functional elements comprise the infrastructure for any given organizational component, so security policies which affect any functional element type may not be appropriate for all of the various elements in the organizational. The security policies are relevant across organizational components with minor parametric changes.
  • a missing element from traditional security point product solutions is the equivalent of a universal command and control system with a consistent management system and database.
  • the command and control system would connect the point solution results to appropriate people and policy oriented standard and custom procedures to implement the enterprise's security and privacy policies with consistency and traceability.
  • the invention provides a system and method for providing network-based security services.
  • embodiments of the invention enable a customer to select policies for automatic distribution, installation, and configuration management onto the customer's network.
  • embodiments of the invention improve the way that security events are collected, analyzed, and responded to.
  • one or more protection techniques are considered for protecting the asset, the organization assigns responsibilities to carry out or protect the asset, and a policy is constructed. After the policy is developed a plan is put into action to protect the asset, and a policy implementer is developed and/or purchased, distributed, configured, and managed. Finally, the policy, its enforcement, and its effectiveness, are reviewed to determine any changes needed, and new requirements are discovered, closing the lifecycle.
  • An embodiment of the invention provides a method for implementing policy objectives in a network, including: developing a policy implementer; registering at least one system component; and selling the policy implementer, the policy implementer enabling the policy objectives to be instantiated in the network.
  • An embodiment of the invention provides a method for rapid development, including: planning an implementation of a policy; describing the implementation; coding the implementation into a policy inplementer; and certifying the policy implementer.
  • An embodiment of the invention provides a method for coding a policy implementer, including: registering as a user on a developer Web site; coding the policy implementer; and accessing a code submission tool from the developer Web site, the code submission tool enabling the user to submit the code to a repository.
  • An embodiment of the invention provides a system configured to instantiate policy objectives in a network, the system including a framework, the framework configured to distribute a policy implementer and to collect data from the network.
  • An embodiment of the invention provides a method for managing information security lifecycle, including: storing information content; implementing a policy associated with the content; and distributing the content.
  • An embodiment of the invention provides a method for providing services, including: offering a enterprise infrastructure model; offering a service provider model; offering a subscription model; offering a ala carte model; offering a services sale; and offering protection services.
  • An embodiment of the invention provides a system for providing network services, the system including a framework, wherein the framework is configured to perform at least one of analysis of data, collection of data, distribution, administration, and display of data.
  • An embodiment of the invention provides a method for providing information security services, including: describing a virtual network component with a named abstraction; developing a policy implementer using the named abstraction; associating a portion of a real network with the named abstraction; naming the associated portion of the real network; and protecting the named portion of the real network using the policy implementer.
  • Fig. 1 is a block diagram of a functional architecture, according to an embodiment of the invention.
  • Fig. 2 is a block diagram of the client system components and the external IT sources shown in Fig. 1, according to an embodiment of the invention
  • Fig. 3 is a block diagram of the distribution components shown in Fig. 1, according to an embodiment of the invention.
  • Fig. 4 is a block diagram of the event management components shown in Fig. 1, according to an embodiment of the invention.
  • Fig. 5 is a block diagram of the management console servers shown in Fig. 1, according to an embodiment of the invention;
  • Fig. 6 is a block diagram of the primary administrative console shown in Fig. 1, according to an embodiment of the invention.
  • Fig. 7 is a block diagram of the subordinate administrative console shown in Fig. 1, according to an embodiment of the invention.
  • Fig. 8 is a block diagram of controllers, which are distributed throughout the functional arcliitecture shown in Fig. 1, according to an embodiment of the invention.
  • Fig. 9 is a block diagram of the policy implementer development kit shown in Fig. 1, according to an embodiment of the invention.
  • Fig. 10 is a block diagram of the agent developer kit shown in Fig. 1, according to an embodiment of the invention.
  • Fig. 11 is a block diagram of the plug-in developer kit shown in Fig. 1, according to an embodiment of the invention.
  • Fig. 12 is a process flow chart for an e-commerce transaction from the perspective of a customer, according to an embodiment of the invention.
  • Fig. 13 is a process flow chart for supplying enterprise services from the perspective of a service provider, according to an embodiment of the invention.
  • Fig. 14 is a process flow chart for the product development process shown in Fig. 13, according to an embodiment of the invention.
  • Fig. 15 is a process flow chart for the warehousing process shown in Fig. 13, according to an embodiment of the invention.
  • Fig. 16A is a process flow chart for the user registration process according to an embodiment of the invention.
  • Fig. 16B is a process flow chart for the device registration process according to an embodiment of the invention.
  • Fig. 17 is a process flow chart for the e-commerce transaction shown in Fig. 13, according to an embodiment of the invention
  • Fig. 18 is a process flow chart for the framework component distribution process shown in Fig. 17, according to an embodiment of the invention.
  • Fig. 19 is a process flow chart for the e-commerce transaction shown in Fig. 13, according to an embodiment of the invention.
  • Figs. 20A-H are illustrations of a table mapping policy choices to policy implementers, according to an embodiment of the invention.
  • Fig. 21 is a process flow chart for the distribution process shown in Fig. 19, according to an embodiment of the invention.
  • Fig. 22 is a block diagram of the distribution process shown in Fig. 19, according to an embodiment of the invention.
  • Fig. 23 is a messaging diagram for agent start-up, according to an embodiment of the invention.
  • Fig. 24 is a process flow chart showing a distribution hierarchy, according to an embodiment of the invention.
  • Fig. 25 is a process flow chart for the operations process shown in Fig. 13, according to an embodiment of the invention.
  • Fig. 26 is a block diagram showing functional components of event management, according to an embodiment of the invention.
  • Fig. 27 is a block diagram showing functional components of event management according to an embodiment of the invention.
  • Fig. 28 is a block diagram showing functional components of event management according to an embodiment of the invention.
  • Fig. 29 is a process flow chart showing an event management hierarchy, according to an embodiment of the invention.
  • Fig. 30 is a process flow chart showing command propagation, according to an embodiment of the invention.
  • Figs. 31-34 are process flow charts for the operations process shown in Fig. 13, according to an embodiment of the invention
  • Figs. 34-36 are flow diagrams of a security management lifecycle process, according to an embodiment of the inventions
  • Fig. 37 is a block diagram of the data structure associated with policy implementation, according to an embodiment of the invention.
  • Fig. 38 is a block diagram of the data structure associated with the E-Commerce component, according to an embodiment of the invention.
  • Fig. 39 is a block diagram of the data structure associated with the Deployment component, according to an embodiment of the invention.
  • Fig. 40 is a block diagram of the data structure associated with the Breaches and Methods component, according to an embodiment of the invention.
  • Fig. 41 is a block diagram of the data stracture associated with the Event infrastructure, according to an embodiment of the invention.
  • Fig. 42 is a block diagram of the data structure associated with the METRICS, according to an embodiment of the invention.
  • Fig. 43 is a block diagram of the data stracture associated with the Inventory infrastructure, according to an embodiment of the invention.
  • Fig. 44 is a block diagram of the data stracture associated with the Security Oriented infrastructure, according to an embodiment of the invention.
  • the invention is directed to an improved infonnation security lifecycle, a functional arcliitecture (also described hereinafter as a framework), and improved methods for providing network-based security.
  • Embodiments of the invention provide an electronic connection among an organization's policy objectives, procedures, people, and technical security controls.
  • the term “distributed” refers to a computational task or function that is broken into sub-functions or processes to execute on more than one distinct computing device so that all of the devices act harmoniously to deliver the desired result or overall function.
  • deployment refers to the process of determining the specific device to send a component or configuration manifests to, to inform that device that it needs the component, to manage the process of sending the component, to receive confirmation that the component is received, and to persist the status of the delivery.
  • the term “distribution” refers to the overall process of determining what components or configuration manifests should be sent to 'child' or 'client' systems, to deploy the components to those systems, and to then set the component into execution by invoking it.
  • the protection lifecycle must include a facility to discover a need, to establish a policy doctrine, implement automated protections that are enforceable, and assure the policy with oversight and an improvement program.
  • Figs. 34-36 are flow diagrams of a security management lifecycle process, according to an embodiment of the invention. As shown in Figs. 34-36, the process includes: Security Requirement Discovery; Protection Paradigm Hypothesis; Organizing for Protection & Duty of Care Assignment; Policy Development; Policy Implementation Plan and Description; Policy Implementer Development; Policy Implementer Certification; Policy Implementer Sales; Policy Implementer Distribution; Customization and Configuration; Enforcement, Audit and Policy Accreditation; and Policy Improvement Review. Not all steps are required in other embodiments.
  • the steps in this lifecycle can provide, for example:
  • the Infrastructure makes it easier for non-specialized security personnel to manage the enterprise's security procedures. It also provides a facility for enlisting a cadre of developers to rapidly solve security issues and to rapidly deploy those solutions.
  • the Infrastructure adds higher level management controls to local devices by deploying the basic Controller, turning these into distributed agents that then carry out the instructions imposed by higher level policy applications which are packaged as Policy Implementer.
  • the lifecycle step of Requirement Discovery occurs when an organization becomes aware that a threat or vulnerability exists in their environment, that an asset is at risk, that use of assets is at risk or is impaired, or when legislation forces action on their part.
  • This step includes the understanding of the security, asset management, or network problem. The step is used to clarify and to narrow the scope of the problem defined as a threat or vulnerability to loss.
  • Security-related requirements may be categorized by integrity, availability, and confidentiality. These concepts can form the basis of the security goals established for an organization. Integrity is the metric for the process of assuring that information is kept intact, and not lost, damaged, or modified in an authorized manner, or that the network is not compromised.
  • Availability is the metric for the process of assuring that assets or information is accessible to authorized users when needed and that, to the extent possible, the systems are safe from accidental or intentional disablement.
  • Confidentiality is the metric for the process of assuring that information is accessible only as authorized and that it cannot be acquired by unauthorized personnel and/or via unauthorized avenue.
  • the Threat/Vulnerability Assessment includes, for example, the sub-processes of: identifying assumptions, constraints, and dependencies involved; determining assessment methodology; gathering and reviewing information; identifying and prioritizing threats; identifying and prioritizing risks; matching threats with vulnerabilities; determining likelihood of occurrence; identifying existing or planned countermeasures; and completing a threat/vulnerability assessment report. Requirements will provide a degree and a characterization (type) for each threat or breach.
  • This lifecycle step includes the construction of a conceptual approach to a defense to the threat, a limiting of the vulnerability, or a reaction and remedy for the breach or potential loss.
  • Various tools and analysis techniques can be used to frame a protection paradigm concept. This concept will be used to further understand and categorize the detailed scope of protections needed to protect against or respond to the problem and their relationship to other protections the organization uses. The protections for one threat may differ greatly based upon the value of the assets protected, for instance.
  • This step identifies potential control areas for protection and its implementation, such as, for example: security policy or management practice changes; organizational security; asset classification; personnel security; physical and environmental security; communications and operations management; access control; asset management; network management; security management infrastructure; systems development and maintenance; business continuity planning; service level agreements; and/or compliance with laws establishing duties of care.
  • security policy or management practice changes such as, for example: security policy or management practice changes; organizational security; asset classification; personnel security; physical and environmental security; communications and operations management; access control; asset management; network management; security management infrastructure; systems development and maintenance; business continuity planning; service level agreements; and/or compliance with laws establishing duties of care.
  • the next step is to construct a taxonomy of the logical entities (a logical framework) and a taxonomy of the physical (real) entities for the detection of threat and the defense against the threat.
  • An organizational map for the management of the defense team and a management structure for retaining the discipline of the defense are also needed.
  • the next step is to construct a taxonomy of the logical entities taxonomy for naming has to be, itself, enforced by a security management system infrastructure.
  • the management structure for the process must make use of the naming and the assignments of roles to actual individuals.
  • the Who and Where must be generally stated.
  • the 'What' to search for is the threat / policy element being addressed by the development.
  • the Who is generalized to a role, and the Where is generalized to a context. This step provides the naming stracture for the objects above and the team roles and security responsibilities for all stakeholders.
  • Security policy helps establish standards for resource protection by assigning program management responsibilities and providing basic rales, guidelines, and definitions for everyone in the organization. Policy thus helps prevent inconsistencies that can introduce risks, and policy serves as a basis for the enforcement of more detailed rules and procedures.
  • Policy formulation is an important step toward standardization of security activities.
  • Security policy is generally formulated from the input of many members of an organization, including security officials, line managers, and resource specialists. However, policy is ultimately approved and issued by the organization's senior management.
  • the term 'Security policies' has many meanings. The meanings are differentiated by the type of object for which the policy is to be enforced.
  • a network routing security policy has a scope appropriate to a network router and is usually explained in a short 'rule' in the router's configuration stating that messages from a certain input interface should be output on another interface.
  • a health care provider's information security policy requires much more explanation and a management stracture for maintaining the discipline needed to effect it.
  • a low-level or implementation-level policy is a policy which can be stated effectively with a short rule
  • a high-level or organizational security policy is a policy where more information must be provided to make the policy understandable.
  • An organizational systems security policy provides a consolidated statement of the security requirements for the systems of an organization.
  • the policy documents the basic information regarding system security from the requirements, paradigm, and organization steps above, and it identifies the relevant organizational mandate and legal doctrine containing security directions and context. It provides an indication of the level of security assurance required and assigns organizational roles and responsibilities for managing the defenses.
  • a system security policy discusses topics such as: basic facts, security domains, security functionality, security assurance, and configuration management.
  • Assurance defines how strong and how correct security functions need to be, and is directly related to the level of threat under which the system will operate. As the requirement for strength and correctness in a security function increases, so does the effort required to evaluate that function and therefore the cost of products at that level of assurance. Selecting the assurance level therefore involves balancing cost against security needs.
  • accreditation provides a statement of the status of computer system security relative to the stated security policy at the time of the accreditation
  • configuration management provides the control process for maintaining the required level of security throughout the life of the operational system.
  • Configuration Management defines change approval procedures, sets the management structure, and provides a reference to baseline configuration documentation.
  • the missing element from traditional security point product solutions is provided by the Infrastructure described here — the equivalent of a universal command and control system.
  • the Policy Implementers link the point products across a standard network connection to a consistent management system and database.
  • the Infrastructure connects security's point solution results to appropriate people and policy oriented standard and custom procedures to implement the enterprise's security and privacy policies with consistency and traceability.
  • the business process provides for a developer community and for evolving standards, but it also is based on the best of breed open source and several vendor solutions to allow for other's standard setting roles.
  • the Infrastructure makes it easier for non-specialized security personnel to manage the enterprise's security procedures.
  • Program-level policy is typically issued by the head of the organization or another senior official, such as the top management officer to establish the security program, assign program management responsibilities, state organization-wide computer security goals, purpose and objectives, and provide a basis for compliance and enforcement.
  • Program-framework policies provide organization-wide direction on broad areas of program implementation. For example, they may be issued to assure that all components of an organization address contingency planning or risk analysis. Program-level policy is usually broad enough that it does not require much modification over time.
  • the program-level policy firmly establishes individual employee accountability.
  • Program-level policy serves as the basis for enforcement by describing penalties and disciplinary actions that can result from failure to comply with the organization's security requirements. Discipline is set commensurate with levels and types of security infractions. Without the proper level, visibility, and education of these policies, nonconformance to policy can be claimed as unintentional on the part of employees.
  • Issue-specific policies identify and define specific areas of concern and state the organization's position. Issue-specific policies are likely to require revision and updating from time to time, as changes in technology and related activities take place. This is largely because as new technologies develop, some issues diminish in importance while new ones continually appear. These policies do not often disappear, since technologies or functions do not often die but are instead transformed.
  • the broad categories for issue-specific policies are, for example: Physical Security; Personnel Security; Network Configuration and Security; Communications Security; Administrative Security; Asset Management, Maintenance and Protection; Risk Management; Contingency Planning.
  • System-specific policies state the security objectives of a specific system, define how the system should be operated to achieve the security objectives, and specify how the protections and features of the technology will be used to support or enforce the security objectives.
  • a system refers to the entire collection of processes, both automated and manual.
  • System-specific policy is normally issued by the manager or owner of the system (which could be a network or application), but may originate from a high official, particularly if all impacted organizational elements do not agree with the new policy.
  • Low-level security policies are detailed rales for the operation of specific devices or network connections. These rales are automatic in their impact and are implementations of the higher level policies above. Without them, automation of policy enforcement would be impossible, yet the higher level policies are rarely made traceable to the lower level rules, especially when a proper security automation mfrastracture as is described in this application is unavailable.
  • Policy implementation is a process and must be planned. Policy cannot merely be pronounced by upper management in a one-time statement or directive with high expectations of its being readily accepted and acted upon. Rather, just as formulating and drafting policy involves a process, implementation similarly involves a process, which begins with the formal issuance of policy that should be digested and addressed.
  • This step determines the role technology will play in enforcing or supporting the policy. Security is normally enforced through a combination of technical and traditional management procedures. Those aspects that can be assisted by technology are considered for development, and the functionality that must be developed is divided into Policy Implementers in this plan.
  • Communications Security provides details of how to meet the link encryption and routing or other networking related requirements of the system.
  • Computer Security gives details of the approaches selected to meet the security requirements such as virus protection, intrusion detection, service configuration, physical security, communication encryption facilities, etc.
  • policies are often not specific to single sites. Policy Implementation must be accomplished in stages, and the starting point for the development is a context rather than a site.
  • a context is a described environment (collections of business locations, networks, organizational elements, etc.) devoid of any real geographic or identifying information. The use of the context creates a generality for the implementation and focuses the implementation to the generalized threat. It also focuses the later deployment phases on the localization of the implementation rather than on the functionality.
  • Security rales cannot often be applied universally, even at the goal level. Security must often be integrated into many existing activities and practices throughout many levels of the organization, and different functional elements may have widely differing systems and needs to accommodate. Organizational elements tailor their implementations of policy to meet their unique needs. Also, news of the degree to which implementation has occurred and enforcement of compliance is a reality in any sub-organization should be available, along with detailed implementation information. Appropriate visibility should be afforded the security policy through all applicable documentation, but with the complexity existing, and the need for enforcement, only a dynamic, automated system has any hope of providing the visibility of the specifically applicable detail needed or implemented in any specific organizational element or on any specific device.
  • intrusion detection software can alert system administrators to suspicious activity or take action to stop the activity.
  • Portable computers can be configured to report in from wherever they are located when not on the corporate network. Databases can report when they need backup or archiving. Traditional management procedures are used for disciplining employees or for process assurance and improvement.
  • Not all of an Implementation Plan may be executed in one short period or in all divisions of an organization or on all equipment or networks at once. The staged roll-out across the organization and the phased development and deployment of the function should be controlled by a Plan.
  • An implementation of a policy should be sufficient to meet duty of care requirements for each specific policy detection, reporting, analysis, or enforcement element.
  • An organization's insurance may be ineffective or their director's legal or contractual liability may be increased if duty of care is not met.
  • Templates for the Plan will be available in the Developer and Assurance Component of the Infrastructure and will be integrated to allow for entry of Plan and rapid viewing of the Plan's effect on Assurance. Completion level and status metrics will be calculated automatically in the Assurance component of the Infrastructure. A degree of flexibility will be provided by the Infrastructure templates, different templates will be available for each major category of security policy and type of mechanism, and templates will be organized to allow for rapid, but high quality development of Plans in that they will generally allow for a structured question/answer process with the planner.
  • the sections of the Policy Implementation Plan are, for example: • General Description: describes the specific elements of a policy that are being implemented, and a general description of the way that the Policy Implementer is constructed to enforce the policy. This provides a summary Statement of Applicability.
  • Target Context Describe a fictitious example organization and generalize a description of the environment that the organization could have. State a presumed characterization of the fictitious organization's ability to understand its risks and manage them without and with the Policy Implementer. Characterize the fictitious organization's preparedness for receiving and managing the Policy Implementation.
  • Policy Traceability describes specific elements of the relevant policies that are enforced by the Implementer. Boundaries are explained where limits to the implementation relative to the requirements of the policy have been established.
  • Assurance and Compliance Description states the assurance level of the approach, and sets 'efficacy evidence' criteria needed to substantiate the assurance claim and to meet the traceability above. Describes the intentions of the Compliance Directives, Programs, and Procedures stemming from the specific element of the policies being addressed by the implementation approach, and provides forms for reporting compliance and requesting Audit, Accreditation, and Certification for the specific element of the policies addressed.
  • Communication Description describes the specific information and application protocols relating to the implementation of the Policy to fully inform the user and the review/audit/accreditation bodies regarding the nature of information transferred from and to the various elements of the implementation and how it is used.
  • Configuration Management provides a baseline for configuration management of the developed function (bill of materials of internal elements and how they fit together). It also permits the specification of deployment and applicability (usability within other Implementers or for specific environments) of the Implementer, stating where its components will be placed within the infrastructure framework. Provide a plan for staged roll-out across the organization. It also provides a description of any configuration needed for any subcomponents of the Policy Implementer.
  • Processing Description provides descriptions of all algorithms, rules, code, measurements, workflow, and processing schedules used to implement the Policies addressed. Failure Action descriptions will be included to show how the security approach will behave under failure conditions.
  • Management Specification describes and specifies the issues raised by the Implementer and how they are directed (workflow) to those responsible, and how they may be cancelled based upon new events.
  • Operating Procedures States relevant procedures used in the management, administration, and operation of the system under the approach.
  • the Operating Procedures may consist of a number of independent procedures and include specific procedures designed to protect against known vulnerabilities in the approach which are not otherwise protected. Procedures maybe security-relevant. Examples of relevant procedures include: a. storage management procedures; b. startup, recovery, and closedown procedures; c. user training and usage procedures; d. physical security; e. userid and password procedures; f. control of access and permissions; g. monitoring of privileged actions; h. procedures for development and Distribution; i. controls on connectivity and foreign software; j. review, audit, and accreditation procedures.
  • Policy Implementer Merchandising Objectives describes who needs the Implementer, provides an FAQ for developers, and proposes packaging, pricing, sales policies, and subscription direction. Includes links to information on insurance plans and adjunct services such as Compliance Assistance and Process Improvement Services. This section describes the function for those involved in the Distribution or use of it.
  • This Plan is a requirements document when completed in this methodology.
  • the choice of which of the words 'optional', 'preferred,' and 'should' may change depending upon the process of negotiation and scoping with the Implementer developers.
  • the documentation should reflect a choice usable during the code review.
  • Policy Implementation Plans are used to stir Policy Implementers development and to provide a basis for Policy Implementer certification.
  • Policy Implementation Plans and Policy Implementers will often be developed by different 3rd parties or internally, and the development of them may be accomplished by large or small teams, at times being formed ad hoc. These teams may be acting for financial gain or may be 'open source' developers.
  • the described business process provides for improvement by updating of the plans and extension of the Implementers.
  • the described business process also provides for the development of improved Policy Implementers by other 3rd parties and/or internal developers as requirements change.
  • each automated approach named and referred to as a Policy Implementer will be implemented within a structured process, within a framework and on an infrastructure to generally meet established criteria.
  • the Implementation Plan will provide the staged roll-out and the phased development objectives for the implementation.
  • the context for use of each policy implementer will be stated in the plan and used for configuration management and deployment as well as for sales catalog categorization.
  • the structured process will provide for make/buy decisions, incorporation of multiple developer's works, and the reuse of prior developments.
  • the framework and infrastructure provide an inventory facility for categorizing of function, configuration management for use and version control, and tracking of deployments.
  • the infrastructure maintains records of ownership and/or licensing status of the policy implementer function for each unit sold and/or deployed either in a bundle, subscription, or otherwise.
  • the results of the Policy Implementation Plan - Description process are used as an input to the Audit Step in the methodology.
  • the results are also used for Accreditation. They form an explanation for the Policy Implementer and are included as the basis of all online documentation.
  • Online documentation for the functionality of the installed protection facilities on any system deployed will be available in an integrated document.
  • the utility of this approach is that any user or reviewer will be able to see the specific protections for a specifically protected device at a specific time and the limitations, security approaches taken, and those protections that ARE NOT installed or licensed to them.
  • the documentation is linked to the installation, and conversely, only the relevant documentation is available for the specific installed protections for a device.
  • policies are implemented, and policy implementer function is developed, often one policy implementer will contain protection function that applies to more than one policy.
  • the Infrastructure provides the ability to trace the function provided by the policy implementer back to multiple policies, regardless of the domain or organizational purpose to which the policies apply.
  • This methodology also provides for the integration of computer security policy into and consistently with other organizational policies, such as personnel policies.
  • Policy Implementers are not specific to single sites in most cases. They are specific to contexts that are specified in the above steps.
  • the plan for the Implementation is a statement of requirements and a presumptive statement of direction.
  • This step in the methodology provides detailed descriptive entries for the context, purpose, approach, and sales scenarios for the Policy Implementation.
  • This Description is a requirements document when completed in this methodology. The choice of which of the words 'optional', p ' referred, ' and 'should' may change depending upon the process of negotiation and scoping with the Implementer developers. When the certification process below begins, the documentation should reflect a choice usable during the code review.
  • the methodology By breaking apart the Implementation Plan from the Policy Implementation Description step, and the Implementation Description from the Policy Implementer Development step, the methodology further enhances the utility of separation of effort and inclusion of differentiated talents into the methodology of Policy Implementation. It also provides an improved tool for clearly conveying to developers, customers, users, and reviewers the protections that are being offered and the plan for rollout of improvements to that protection function.
  • This step occurs before, during, and after the Policy Implementer Development Step, and overlaps the Certification step.
  • the utility of this schedule is that improved quality will result in the description, and because of the longer involvement and negotiation, a better description regarding the end functionality developed in the Policy Implementer will result.
  • Templates for the Description will be available in the Developer Component of the Infrastructure. Completion level and status metrics will be calculated automatically in the Assurance component of the Infrastructure. A degree of flexibility will be provided by the Infrastructure templates, different templates will be available for each major category of security policy and type of mechanism. Each section of the description will have a fill-in the blanks form for starting the description and a diagramming tool. The templates will be organized to allow for rapid, but high quality development of Descriptions. [00103] In summary, the following actions are accomplished in the Policy Implementation Step:
  • the Utility of the Policy Implementation Plan and Description is the visibility of the Policy and the specificity of the protections that the Policy Implementation provides. Effective policies must usually be visible, but in this methodology, much of the protection, threat, vulnerabilities, and enforcement are unseen by humans until after the incident occurs. Nisibility aids implementation of policy by helping to ensure that the correct protections are utilized and that the scope of the protection is well understood before purchase of the protection. Implemented Policies should also be integrated into and consistent with other organizational policies, such as personnel policies. The availability of a quality mfrastracture and a quality presentation of protective measures will yield the understanding needed to integrate the protective mechanisms.
  • This step sees the detailed design and programming of a Policy Implementer which includes a number of items that collectively provide the requisite functionality to deliver an implementation of an automated breach detection, data collection, and/or enforcement mechanism required for some sliver of an issue-specific or system-specific policy and provides traceability sufficient to meet appropriate program-level policies.
  • the policy implementer consists of a series of:
  • programmed components such as agents and plug-ins, build scripts, deployment and provision rales, templates, descriptions, analysis, workflow, response and reaction rales, reports, naming and definitions of components, device types, device / network asset-groups, etc., low-level policy directives, schedules, plans, analysis queries and metrics, workflow process definitions, configuration rales for various connections or installations, information and analysis displays, data structures, audit criteria, evaluation criteria, accreditation criteria, and • other programmed obj ects that together are sufficient to perform some automation of the automated configuration management, breach detection, data collection, data reporting, and/or enforcement actions within a planned context within a customer system.
  • programmed components such as agents and plug-ins, build scripts, deployment and provision rales, templates, descriptions, analysis, workflow, response and reaction rales, reports, naming and definitions of components, device types, device / network asset-groups, etc., low-level policy directives, schedules, plans, analysis queries and metrics, workflow process definitions, configuration
  • Response and reaction rales define what actions to take when a policy is breached or when actual activity falls outside acceptable limits according to some metric.
  • a policy implementer could also combine the functionality of previously developed policy implementers.
  • An Intrusion Detection Agent, Vulnerability Monitoring Agent, Vulnerability Management Agent, Network Discovery Agent and Network Asset Management Plug-in could all be combined by building a comprehensive set of analysis and reaction rales that integrate the operations of each component into a single policy implementer. This application would be responsible for insuring that an organization's network assets comply with a defined level of vulnerability protection and it would perform continuous audits of those assets.
  • Policy Implementers are developed for contexts, and the Infrastructure provides for the deployment to and configuration for each specific location and realized context.
  • Fig. 14 is a process flow chart for the Policy Implementer product development process 1302 shown in Fig. 13, according to one embodiment of the invention. As shown therein, the process allows a registered developer (registered in step 1402) to submit developed Policy Implementer software for certification. It also provides tools required to develop, test, and submit software.
  • the Developer Component provides a developer exchange Website to provide the tools necessary for software developers to make contributions to the software repository and to administer their software and their financial and user account.
  • Primary functions provided by this web site include, for example, a developer code submission tool (which accepts new and updated Policy Implementers software components and inserts them into the code certification process) and code certification tools for third party certification and code review management. It would also provide forms and a question/answer facility for explaining what the Policy Implementer contains and how it is to be deployed.
  • Configuration information, and configuration management information will be entered through this portion of the Developer Component of the Infrastructure. Completion level and status metrics will be calculated automatically in the Assurance component of the mfrastracture. These forms and question/answer facilities will be integrated into the Policy Implementer Software Development Kits.
  • Fig. 14 the developer uses the developer website and / or downloads a set of tools required to develop, test, and submit software in step 1404.
  • Software is then developed in step 1406 and submitted in step 1408 for certification, together with test results. If the developer is updating existing software, then this is indicated, along with an identification of the component being updated.
  • the certification step 1410 software is subjected to a standardized Policy Implementer Certification (below) process where it is determined in step 1412 whether the software meets predetermined compatibility, security and performance criteria. Where certification fails, the developer is given an opportunity to return to the development & testing step 1406. If the software passes certification, then the software is transferred to the warehouse and made available for distribution.
  • Every Policy Implementer should be safe, secure, and sufficient in function to meet a stated requirement for duty of care for a specifically described policy detection, reporting, analysis, or enforcement element of a policy.
  • the certification step 1410 software is subjected to a standardized certification process where it is determined whether the Policy Implementer or Framework software meets predetermined compatibility, security and performance criteria. If the software passes certification, then the software status is changed and the code is transferred to the CODE REPOSITORY and made available for distribution (step 1414). [00126] This step describes the review methodology for certifying a policy implementer. Certification is the process of verifying the functionality produced during implementation and formally authorizing the policy implementer for deployment. Certification involves an independent review of each of the policy implementer components to ensure that the security measures implemented in the components are appropriate for the required level of security and the information being processed.
  • the certification methodology described is designed to be a collaborative process with the use of external resources coupled with internal resources forming a certifier community.
  • the external resources include individuals and teams that are vetted and are unrelated to the developers of the Policy Implementers.
  • the utility of this design is the ability to enlist outside, independent resources and to overlap the execution of certification of Plan, Implementation Description, and Implementer by parallel and integrated certification by several certifiers from a wide set of knowledgeable, competing candidates that often are working on a volunteer basis.
  • This approach establishes a negotiation process between the QA management for the Policy Implementer process and the Planners, Describers, and Implementers wherein documentation regarding issues with the submitted Plan, Description, or Implementer code is provided, in part, from the certifier community, and the direct negotiation regarding the repair of the Plan, Description, or Implementer is only between the author and the QA management team - - the certifier is not exposed to the author unless they establish contact outside of the process.
  • the certification process formally analyzes the protection provided in terms of security assumptions and security assertions.
  • a security assumption is some protective measure assumed to be provided within the electronic security domain or context whereas a security assertion is a protective measure included as part of the policy implementer and operating procedures being certified.
  • a security requirement is therefore typically met by one or more security assertions which are reliant upon some subset of the security assumptions.
  • Certification involves several steps. These steps are provided for example only. Certification can include more or fewer steps as necessary.
  • Certifier is vetted for conflicts of interest and quality, and assigned to role if vetting is positive. Certifier is provided access to see Plan, Description, and/or Implementer code.
  • the Certifier studies the policy requirement and understands the context to be addressed by the policy. (This context is a generalization of the environment a fictitious example organization would have and the presumed nature of the organization). 4) The Certifier studies the Organizational Security policy, policy requirements, and organizational naming plans and understands the context to be addressed by the Security policy and supporting procedures.
  • Performance A number of qualitative factors related to security must be considered during the evaluation, including availability, survivability, accuracy, response time, throughput, code quality, and fit with frastracture. Performance is normally evaluated by stress testing and monitoring system parameters while increasing system load.
  • Penetration testing is used to assess the ease of circumventing or breaking the system's security mechanisms, and is the most technically complex of the evaluation activities. While penetration testing is specific to each category of security mechanism, the following are common areas where flaws may be exploited:
  • the process may result in a list of discrepancies and insufficiencies in the Policy Implementation.
  • a certification report is written by filling out online review forms through the user interface of the Assurance Component of the Infrastructure, and several recommendations are requested / made regarding quality and purpose of the Plan, Description, and Implementer.
  • Presentations for certification reviews can be online and assisted by diagrams presented that are stored with the documentation.
  • the reviews will include, for example, the Plan, then Description, then Implementer being presented in order. Each portion should be presented by a group member who is qualified and able to answer technical questions about the Plan, Description, or Implementer.
  • the presentations will be recorded by the Infrastracture for later review.
  • This overview will include a diagram of the approach being implemented, and the place of the Implementer under review in the system.
  • the Architectural description of the system will also provide a data flow and a functional overview.
  • the functional overview should include information about what threats the code is expected to deal with, and how it will deal with them.
  • the Infrastracture will store all of this information as part of the Policy Implementer development.
  • Certifiers will assess a degree and a characterization (type) for each Implementation issue.
  • the Infrastracture will automatically determine the adequacy of a certification based upon Certifier self-assessments and workflow a completed certification back to the Assurance Management team.
  • Certifications add to the documentation of the Implementation.
  • the utility of the Certification Step is that it provides a tool to clarify Implementer compliance using gap analysis between the "ideal model" as specified in the plan, and the current implementation. It also assists in polishing the Policy Implementation Plan and Description, and the Policy Implementer by stating a list of necessary remedial actions.
  • Certifiers can perform the following tasks, for example:
  • the extended certification record will be open to additions by certifiers for an Implementer. Comments added into this extended record may include, for example:
  • Certifiers will be notified automatically by the Assurance Component of the Infrastructure when changes are made to the Policy addressed by an Implementation in this methodology. Certifiers may also identify a need for recertification and report that need based upon, for example, any of the following indicators:
  • the Assurance Management team is responsible for continual process improvement of the methodology, and for continuous enhancement of the facility. They are also responsible for the specific reviews and specific certifications and their results, and for the assurance overall of the operation of the Infrastracture. The Assurance Management team is also responsible for the vetting of Certifiers. The certification process should itself vet the products of the Policy Implementation process steps in this methodology.
  • the Developer Component of the Infrastructure provides an information website for those wishing to participate in the planning and development of Implementers.
  • the site also provides tools for development, including Configurators, Software Development Kits, quality testing tools for Implementers, and sample code.
  • the Configurators also provide the facilities to provide the Implementers for sale through the Infrastracture.
  • the Developer Component of the Infrastracture provides a developer community member the opportunity to contact and connect with others who wish to volunteer or to offer an Implementer for sale.
  • the Developer Component has a search mechanism for concepts needing work, and for concepts being worked on by others where participation is needed. Those eager to get started may also post a message to the 'board' asking what people would like to see done to stir interest. Developers may post anonymous resumes on the 'board' to offer their services in the development process. Certifiers are often recruited off of the board.
  • Fig. 15 is a process flow chart for the code warehousing process 1304 shown in Fig. 13, according to one embodiment of the invention.
  • Warehoused software is placed into a CODE REPOSITORY and can be propagated from parent systems (in a tiered CODE REPOSITORY stracture), or can be imported directly as a result of the product development process in step 1504. If the software is imported through product development, the current CODE REPOSITORY is the top level (i.e., the source) for that software.
  • the controller can receive a notification that there is a software update available in step 1502.
  • this notification triggers an update request in step 1503.
  • an update request can be generated on a scheduled basis.
  • the local controller requests the CODE REPOSITORY updates, and updates can be downloaded from the parent CODE REPOSITORY system.
  • new software can be added to the CODE REPOSITORY as a result of the standardized product development process.
  • step 1510 Once software is updated in step 1510, the administrative information distribution engine is notified of the updates in the CODE REPOSITORY in step 1512. Where the update is merely a revision change, approval may not be required. In other cases, for example where the update is a new software component, approval (step 1514) from the administrative info ⁇ nation distribution engine is required in step 1518 prior to authorization for distribution in step 1516.
  • the first step in the operation of the system is the Customer Relationship establishment process. This process involves the recording of the Customer and the initial security information for the customer.
  • Framework Sale Enterprise hifrastructure Model where the infrastracture framework is licensed to an enterprise or organization for use on one or more computer processors, with unlimited use of one or more specified Policy Implementers;
  • Non-Framework Sale - Service Provider Model Application Server Provider where the infrastracture is used by multiple customers and where either Protection Services, Protection Insurance Services, or Policy Implementers are provided at a fee;
  • Non-Framework Sale - Subscription Model Subscription sales where one or more Protection Services and/or one or more Policy Implementers are provided at a fee;
  • Non-Framework Sale - ala Carte Model ala Carte purchases of additional function where one or more Protection Services and/or one or more Policy Implementers, selected without being a part of a subscription, are provided at a fee;
  • Services Sale Providing services for customization and or custom development of protections.
  • the sale of a Protection Service is a transaction where a fee is paid in exchange for the tools needed to protect against a specific threat.
  • the sale of Protection Assurance is the sale of an insurance policy stating that specific threats will not have an impact on the devices or network protected by the facility utilized to effect protection.
  • the Business Process presented in this application includes, for example, the processes of:
  • Fig. 16A is a process flow chart for the user registration process 1306 shown in Fig. 13, according to one embodiment of the invention. The process begins by collecting registration information in step 1601 from the customer after they begin using the customer website. Their personal and organizational information is persisted to the Data Structures as shown in Fig. 3.
  • Fig. 16B is a process flow chart for the device registration and sanctioning process shown in Fig. 13, according to one embodiment of the invention.
  • the process begins by collecting registration information about the device either from prior discovery and inventory information, from the customer, or from the device itself in step 1602.
  • the approval of this information may be processed through the workflow process or may be granted automatically, depending upon global settings, through the Sanctioning section of the Distribution website.
  • step 1604 based upon the user's approval, a generic controller installer is packaged and deployed to the client system which the user has decided to protect.
  • the user initiates the installation request from that device after customer log-in at that device to the Sanctioning section of the Distribution website, according to one embodiment of the invention.
  • Automatic controller installation may also be accomplished, according to one embodiment of the invention, by scheduling one or more 'Sanctions' through the Sanctioning section of the Distribution website and using an automatic 'logon script' or other automatic scripting tool for installing the controller in an automatic fashion to multiple devices simultaneously. In this case, there is no operator at the device being deployed to.
  • the controller Upon completion of download, the controller is automatically extracted and installed from the downloaded package. Upon start-up, the controller gathers system configuration information, logs into the distribution engine and provides the information to the distribution engine in a secondary device oriented registration step 1608.
  • the distribution engine prepares a controller manifest (see configuration, below) based on the configuration information, which is then received by the controller in step 1610, and the controller reports in to its management component in the final step. This completes the process of registration in preparation for e-commerce purchases.
  • Fig. 12 is a process flow chart for an e-commerce transaction from the perspective of a customer, according to one embodiment of the invention.
  • the process continues when the customer logs onto an E-Commerce Component of the hifrastructure, for example via a Web portal in step 1202.
  • the customer reviews a catalog menu or other list of policy options, and selects the policy(ies) in step 1204 that they desire to implement on their network or devices. They then search the list of Policy Implementers associated with the selected policies for purchase and to have installed on their network-based system.
  • the customer receives one or more deliverables from the e-commerce transaction 1205.
  • the customer may receive: an implemented policy 1206; an implemented security framework 1208; certification documents 1210; and/or an insurance policy (according to predetermined terms) 1220.
  • Such a transaction is enabled by the processes broadly depicted in Fig. 13.
  • Fig. 17 is a process flow chart for the e-commerce transaction 1308 shown in Fig. 13, according to one embodiment of the invention.
  • this embodiment involves a framework sale.
  • a framework (or enterprise) sale can be initiated in step 1704 after customer login 1702.
  • a menu of framework components are from a catalog 1702, which is based on products available in the warehouse.
  • a framework implementer is customized in step 1708 according to the configuration of the target host system, and the implementer distributes the purchased framework components in step 1710.
  • the framework implementer likewise may trigger the distribution of warehouse 1712 and administrative data 1714, as shown.
  • Fig. 19 is a process flow chart for the e-commerce transaction 1308 shown in Fig. 13, according to another embodiment of the invention.
  • the result of the transaction is that one or more Policy Implementers become active on the user device or network.
  • a user is prompted to login in step 1902.
  • a user is presented with a menu of choices, here, policy choices in step 1904, based on products available in the warehouse catalog 1906.
  • a policy implementer is customized in step 1908 based on user selections and the configuration of the target host system. Controllers retrieve agents, plug-ins, or other components of the selected policy from the warehouse, via the distribution service 1910, as described above with reference to framework components.
  • Figs. 20A-H are illustrations of a table mapping policy choices to policy implementers, according to one embodiment of the invention.
  • the left column provides examples of policy selections available to a customer.
  • the right column indicates the policy implementer components associated with each of the example policy choices. Other policy/implementer combinations are possible.
  • Fig. 13 is a process flow chart for supplying Policy Implementers from the perspective of a 3rd party service provider, according to one embodiment of the invention.
  • the 3rd Party Policy Implementer To be available to a customer, the 3rd Party Policy Implementer must be completed and certified prior to a related e- commerce transaction 1308 (whether for framework or policy), as described above from the customer's perspective. Accordingly, a service provider first develops products in step 1302, then warehouses the developed products in step 1304. As shown in figure 13, a registration step 1306 is also a prerequisite to the e-commerce transaction 1308. Licensing and Security for Infrastructure
  • Policy Implementer Distribution is implemented by the Distribution Component of the Infrastracture. Distribution of Framework components may be carried out in a similar manner. The distribution is begun when a new sanction, license, or update occurs.
  • Licenses and sanction information are established in the database of the Parent Administration Component, and are then deployed to all databases toward the user devices which they affect.
  • the device becomes a member of an asset-group of sanctioned devices. Licenses for the asset-group may then be applied to the operation of Policy Implementers on the device.
  • Authorization for distribution also allows for a child distribution engine to receive new versions of code as it is released, so long as the number of licenses for that code in 'asset-groups' below that distribution engine is greater than one and so long as the distribution engine remains in contact with the parent administration system.
  • Authorization to operate and authorization to submit data to management nodes are controlled in a similar license based control facility.
  • Base data and the database objects (stored procedures, data stracture definitions, etc.) for the Infrastructure are deployed automatically by the Tiered Database Deployment facility of the Infrastructure.
  • This facility consists of the elements shown on Fig 3.
  • the process involved in Tiered Database Deployment is shown in the process diagram in Fig 24.
  • License and Sanction data is distributed by the same facility as Base Data. Security over the distribution is strict, and is aimed at automatic distribution and 100% correctness of result in all cases. An incremental distribution based upon a differential calculation is used to shorten the timeframe for distribution and to reduce bandwidth. The distribution is carried out between databases directly where possible so that the differential may be computed quickly.
  • the SOFTWARE DISTRIBUTION ENGINE (see Fig. 3) is responsible for managing all software deployments in an implementation of the SYSTEM. It maintains knowledge of currently deployed components as well as associated version and configuration information with the Component Management facility. Utilizing the DISTRIBUTION SERVICE, it also processes update requests from child systems, and serves updates when requested by those child systems.
  • the resulting package includes Software and possibly other files which could variably contain Configuration data and Manifest information.
  • the software is encrypted with a key that is used to authenticate and unpack the software component when the component is installed.
  • Fig. 21 is a process flow chart for the distribution process 1910 shown in Fig. 19, according to one embodiment of the invention.
  • the process begins when the controller receives a policy update notice in step 2102.
  • the controller will request pending updates from the distribution service in step 2104, and receive the updated policy components from the distribution service in step 2106.
  • the controller then installs (step 2108) and invokes (step 2110) the policy implementer components.
  • Fig. 22 is a block diagram of the distribution process shown in Fig. 19, according to one embodiment of the invention.
  • Infrastracture At the core of the Infrastracture is an enterprise-caliber software distribution platform capable of maintaining all Infrastracture components. It handles the automatic deployments of software and configuration releases for all Components — including agents, processing plug-ins, rale sets, templates, and output plug-ins - that are distributed throughout the network.
  • the platform is naturally suited for scalability and network growth.
  • This extensible architecture can easily incorporate configuration management of non-Infrastructure components as well. Support for release archival and rollback allow for robust failure recovery. Integration with the management console and wizard-based GUIs provide administrators with powerful remote management capabilities.
  • the Infrastracture provides a fully featured, robust software distribution platform designed with the Infrastracture components in mind, but extensible to embrace traditional software as well.
  • Distribution Engine 2200 The heart of the distribution mechanism lies in the Distribution Engine 2200, as shown in Figure 22.
  • Each Distribution engine consists of components that work together to provide scalable and reliable software distribution: Distribution Service 2240; Distribution Client 2210 (in the controller); Code Repository 2250; Component Deployment Data 2220; and Manifest Generator 2230 web services.
  • Distribution Engine 2200 The main component that coordinates the process is the Distribution Engine 2200. Its main task is to handle incoming requests from Distribution Clients 2270 within Controllers. Controllers know how to communicate with the Distribution Engine 2200 and abstract that complexity from the component where it is embedded. Controllers can send different types of requests, but the most common are requests for software or configuration release updates.
  • Each Distribution Engine Component Management Database provides the configuration and deployment data regarding what needs to be delivered to the -Client 2260.
  • the engine maintains a directory of all the devices and plug-ins that it manages, along with configuration and deployment data for each.
  • This plug-in deployment data contains information about the plug- ins' type, location, software release, and configuration release, among others. Using this data, the distribution service applies business logic to determine what updates need to be delivered to the client 2260.
  • CODE Repository Software releases are all managed by another component called the CODE Repository.
  • This repository is a version control system that is specially tailored to manage all versions of component code. It not only manages various software releases of a component, but also configuration releases as well, allowing administrators to rollback to previous releases if necessary.
  • the Distribution Service returns a message to the CONTROLLER telling it what components and which releases are available.
  • the CONTROLLER then communicates directly with the CODE Repository, downloads all changes, and initiates its update process.
  • Fig. 24 is a process flow chart showing a distribution hierarchy, according to an embodiment of the invention. For larger networks, distribution engines 2402, 2404, 2406, 2408, 2410 can be scaled and tiered to provide a manageable framework for software distribution.
  • Distribution is performed top-down in a hierarchical manner, where the engines are logically arranged essentially as a hierarchical tree (as shown in Fig. 24), with redundancy.
  • Distribution engines regularly communicate via the distribution client with their parent engine asking it for any software updates that are available. Updates are pulled down from the parent and persisted in the engine's local CODE REPOSITORY. Base Data and License is pulled down and stored in the DATA REPOSITORY. At leaf nodes, Controllers retrieve these updates the next time they query the distribution service.
  • Fig. 23 is a messaging diagram for agent start-up, according to one embodiment of the invention.
  • the controller is responsible for the lifecycle of the Policy Implementer element's (an agent here) execution.
  • the lifecycle begins with downloading 2302 the agent to the client system and installing 2304 it in the controller.
  • the framework provides an automatic installation and update mechanism to simplify this process for the administrator in step 2306.
  • the controller loads it and initiates the registration process in step 2308.
  • Each agent must register itself with the system in order to receive the permission and credentials to operate.
  • the agent provides the controller with some identifying information, and the controller determines if this agent has the rights to operate.
  • Rights could be revoked for many reasons, including expired subscription, invalid credentials, or insufficient resources.
  • the controller makes this decision after consulting with the system's runtime configuration database. After the agent is given the approval to ran, it is assigned an encrypted key by the controller 2310. This key is then used for subsequent interaction with the controller to ensure that requests coming from the agent are authentic.
  • the controller's update receiver uses an automated pull-down mechanism for agent updates. It automatically checks the system's distribution server regularly or on demand for new updates and downloads any that exist. It then performs the upgrade by installing the patch or reconfiguring the manifest files, and then restarting the affected code. No manual intervention is required, although the user can change preferences if they want to be notified prior to any updates.
  • This same mechanism is used for installing new software on a host. An authorized user can remotely instruct the update receiver to download a new component from the distribution server and start it. The only prerequisite for installing a new component is that the controller must have already been installed and configured on the host and the host must be sanctioned and licensed to run the component, and these conditions are relaxed under development scenarios.
  • Customization refers to actions taken prior to distribution of code to target devices, and may include the final forming of a package of code to distribute based upon the type of machine(s) to which the code is to be sent, version of framework at that device, other installed components at that device, and / or upon other criteria. It may also include the alteration of the code being distributed for security purposes to make it impossible to execute the code on a device/network other than the device/network it is to reside on. Further, it may include the combined effects of using more than one policy implementer at a customer device, where one policy implementer adjusts its package definition based upon the presence of another policy implementer.
  • Configuration information includes providing an identity and basic operating parameters to an executable using a manifest; dynamic changes to operating parameters using new manifests and commands; specific tasks to accomplish using task assignments; or specific targets or watch items for 'scans' using discovery plans, and other information.
  • This variety of Configuration requires a wide variety of different data, including, for example:
  • the assignment of tasks and plans for Policy Implementer elements extends the requested operations of the Infrastructure from a concept into an action.
  • the deployed software is the real interface point for the real world of the network and device under control.
  • the continuous protection, detection and response capabilities against threats, remotely exploitable vulnerabilities and real-time incidents on the protected networks are provided by the deployed software as configured. Examples of the software functions being configured are:
  • the last step in the distribution process is configuration of the component.
  • Manifest information includes identifying system information and the license keys necessary for proper execution of the component code.
  • Configuration and tasking information (see above) is also needed but is loaded at various times including but not limited to the installation timeframe.
  • the Manifest Generator answers the manifest request and produces a new custom manifests based on the component deployment data stored locally in the Distribution Engine Database. Since only the Manifest Generator can generate these encrypted manifests, integrity of the system is ensured.
  • the Manifest Generator contains another key that is used to authenticate and authorize the software component when the component is started up.
  • the Assigned Task and Plan data are produced by other web services connected to the distribution database and are encrypted with a key. These other Web Services answer requests for configuration and tasking data in a similar manner.
  • the configuration data is used to control the software component during execution as well as at started up.
  • the startup schedule may also be controlled by the Tasks and Plans data.
  • the basic purpose of the Infrastracture is intrusion prevention and risk reduction. More specifically, the purpose of the Infrastracture is to provide a framework for the effective deployment and operation of Policy Implementer solutions to aid in:
  • a decision to launch the incident response process into action should be made based upon the threat, so the management process can be viewed as a continuous decision-making process: "What threat is present?", "How to we defend against it to prevent harm?". These decisions are based on the information provided by the hifrastructure and the Policy Implementer components. Paradoxically, without proper design, the more security devices deployed, the more difficult it is to make the right decisions about defensive strategies because of the analysis burden caused by the additional information.
  • automation tools such as scripts and utilities aimed at processing the information flow.
  • the Utility of the Policy Implementers elements is that they collectively provide an integrated facility for processing the information flow. When properly constructed and used effectively in the Infrastracture, they are additive, allowing an assembly of information and the integrated analysis needed to understand it.
  • the Utility of the Infrastracture is that it provides rapid detection of attacks by using solid analysis techniques that pre-correlate and correlate data effectively. By coalescing data to remove redundancy, and archiving old data or worthless data, analysis is possible for long term threat trending and risk analysis.
  • the Policy Implementers often read data streams from a single sensor, or a security or application platform — the 'point solutions' which are highly effective in their own right but are often unable to provide full cycle security in a complex environment. More advanced Policy Implementers combine data from multiple security and application platforms, correlate that data and provide relevant and accurate data for threat response. Policy Implementers also provide the response, reconfiguration, and enforcement mechanism for threats.
  • Operations step 1312 refers to the execution of the services on the customer network. No services will be loaded prior to the e-commerce transaction step 1308. In addition, where the customer has purchased framework components to be loaded onto the customer-controlled network, the customer machine(s) must first be sanctioned in step 1310.
  • Task initialization in this methodology includes the process of deployment and configuration of Policy Implementer components toward a defined purpose with a set schedule for specific actions on a defined target scope such as a network segment or a defined set of assets to be protected.
  • Schedules and targets are set by Plans.
  • An example would be a Plan stating that a specific Controller component should schedule a SNORT agent to execute at 9PM for a specific target address range.
  • a Controller starts Policy Implementer components which either have a predefined schedule or have been given a scan Plan or Task, the component will begin its work. If no predefined Task is assigned, the component will start up but wait for direction from a senior Framework Part such as a Management Console or the Discovery Engine.
  • a senior Framework Part such as a Management Console or the Discovery Engine.
  • the Utility of this facility is the significant reduction in system load resulting from the key-hole narrowing of the threat field-of-view. By providing focus to the monitoring and data collection efforts on a highly dynamic basis, the system overall is more effective.
  • a number of facilities are used for monitoring.
  • the Infrastracture is constructed to provide for use of 3rd party tools for monitoring, and the business process and facility provides for the deployment and control of the 3rd party tools.
  • Policy Implementer Agent components manage and receive data from the 3rd party tools or perform the monitoring function directly.
  • the Agents interface directly with the 3rd party or internally developed tool, or read and interpret log files created by the tool.
  • the Agents are programmed to initiate and / or reconfigure the 3rd party tool.
  • Fig. 25 is a process flow chart for the operations 1312 process shown in Fig. 13, according to one embodiment of the invention. As shown therein, interesting activities are first detected in step 2502, then persisted and or queued in step 2504. Event types are checked to determine whether the detected event has a subscriber in step 2506. If not, an error report is generated in step 2508. If so, then the event is reported in accordance with the subscription in step 2510.
  • step 2512 Certain events will be analyzed against predefined rales in step 2512, sent to an event subscriber in step 2522, and checked against automatic response logic in step 2524. If an automatic response to the event is to be made, then a reaction command is prepared in step 2526, and the command is sent in step 2528.
  • the response command could be or include, for example, a command to collect additional info ⁇ nation, or a command to disable portions of the network- based system.
  • Other events are merely aggregated in step 2514 and analyzed in step 2516, and, if they meet predefined criteria (step 2518), may be used to generate a new event in step 2520.
  • Detection data is specifically the information that most cogently characterizes an anomaly, status (or state - a well-defined logical or operational mode that the network object is in), intrusion or attack, a presence or absence, etc. This data is either interpreted by an Agent or is used to form an Event by the Agent which the Agent communicates by publishing it.
  • Agents do not simply pull sensor log files into the event reporting structure for posting to a database. Agents are developed to effectively report events, often performing some degree of analysis, no ⁇ nalization and aggregation on the data before creating a traditional event message.
  • the Utility of the Agent concept within the Policy Implementer is that the various elements of the Policy Implementer collectively reach an optimal pattern of distributed collection and analysis, balancing the amount of initial analysis on the device itself against processor load, bandwidth consumption, and correlation processing.
  • Fig. 26 is a block diagram showing functional components of event management, according to one embodiment of the invention.
  • Events may be received by event manager from child event managers 2640 in a hierarchy of event managers. Events are routed to subscribers based on the routing tables with the event manager. Subscribers may be parent event managers 2610, management consoles 2620, or other plug-ins 2630. Although subscribers are shown as being on separate hosts, they may be threads that are local to the event manager which perform aggregation, analysis, correlation, or other functions.
  • Subscriber processes may return control messages that describe response actions. These control messages are received by the event manager's command and response component. Control messages are queued and sent to the intended recipient the next time the recipient checks in with the event manager.
  • Fig. 27 is a block diagram showing functional components of event management according to one embodiment of the invention.
  • events may be received by event manager from child event managers. Events are persisted and queued using the calling thread.
  • a routing engine thread dequeues the event, matches its type against one of the entries in its routing table, and sends it to all registered subscribers for that event.
  • Subscribers are invoked with an event manager thread. Generally, a subscriber will spawn a separate thread to perform blocking I/O operations. It also maintains a queue where events are stored until they are serviced by the subscriber.
  • Fig. 28 is a block diagram showing functional components of event management according to one embodiment of the invention.
  • the event manager 2800 has a proxy at the child event manager.
  • the proxy knows what events the parent event manager 2500 currently recognizes.
  • the proxy (on the child event manager) subscribes to the events that the parent wants to see.
  • Events are immediately persisted in step 2810 prior to enqueuing in step 2820.
  • Events are dequeued and compared against a routing table in step 2830 that matches event types to subscribers.
  • the table is populated when subscribers notify the event manager with a new subscription request for a certain event type.
  • Fig. 29 is a process flow chart showing an event management hierarchy, according to one embodiment of the invention.
  • Fig. 30 is a process flow chart showing command propagation, according to one embodiment of the invention.
  • the event manager receives commands from an upper level in step 3002. They can originate, for example, from the management console, administration server, or an event subscriber. Commands are queued in the event manager by the command and response component in step 3004.
  • Analysis tools located near the Agent that generates an event, or that are in the child-parent reporting chain and can 'subscribe' to an event can perform Local Analysis. Analysis consists of:
  • Normalization for Correlation Re-characterizing a set of events as a single event of a 'higher' importance by (in the case of local analysis) relatively simple comparisons and calculations. Normalization takes multiple event data streams and ensures that they are presented to the next layer in a standard fo ⁇ nat for correlation. It is easier to compare data from disparate data sources and multi-vendor security solutions by pre-filtering and regrouping them in a distributed processing pattern.
  • Local Reporting consists of immediate notification of a user local to the generation of the event, or local to a device in the reporting chain 'near' to the generation of the event. This relatively low level but relatively high priority or importance presentation is accomplished by the included function of the Dashboard facility of the Controller or the Management Console, or by Dashboard or Management Console Policy Implementer Plug-In components.
  • the Infrastracture provides analysis facilities such as event co ⁇ elation which may be utilized to improve threat identification and assessment by looking not only at individual events, but at their sets, bound by some common parameter.
  • analysis facilities such as event co ⁇ elation which may be utilized to improve threat identification and assessment by looking not only at individual events, but at their sets, bound by some common parameter.
  • Pre-correlation is a new methodology available now because older mechanisms never reached a level of function where the methodology could be implemented effectively. [00253] In the Infrastracture, according to one embodiment of the invention, Pre-correlation can be performed by:
  • Collecting pre-categorized data allows rapid partitioning of an analysis.
  • the use of the naming for groups of assets and the characterization of them by standard typing allows for specificity and tuning in terms of analysis techniques, scan planning, and scheduling.
  • streamlined, indexed queries can be used.
  • the analysis is much easier.
  • the use of background database processes for coalescing (culling) the database data and the use of filters and roll-ups within the event reporting data collection stream allows data volumes to be reduced significantly.
  • Tracking protection status with an inventory of the health of devices being protected is necessary for any closed loop assurance methodology, or the process would be inefficient.
  • the use of an Inventory system allows knowledge to be retained by device, network segment, etc. regarding update status for the devices, route blocks for connections, device and interface statuses (well-defined logical or operational mode that the network object is in), port settings, etc.
  • the threat field of views can be based upon the known protection level of devices such that the known devices will not be scanned for all threats but rather only for threats for which protection is not yet established, and scans will be done not against an IP range but rather against devices specifically. It is insufficient to perform these without a rapid procedure for adjusting the scans when a new threat appears or when the reliability of the assurance or the information in the inventory decreases. At these times, the rapidity of scamiing and the breadth and depth of information collected must increase in a hurry. Only a system that is capable of both modes and capable of the rapid adjustment is sufficient.
  • Incremental scans based upon groups of assets by specifying device names, device types, etc. rather than IP number ranges can also greatly improve results.
  • the number of scans may increase overall, but their length is decreased, their penetration is deeper (larger numbers of signatures, for instance) and the information produced from them is better both in focus and usability.
  • the Utility of this type of focused, incremental scan allows for the collection of discovery infonnation, routing information, and vulnerability information at the same time and in ways not previously possible until after considerable traditional co ⁇ elation was 'data mined'.
  • the Utility provides an organization point for new knowledge, and the Infrastracture makes use of this by opening up the collection of knowledge to a community of experts. With the ability to hold data very effectively with the Discovery and Inventory Data Structures, the Infrastracture is used as an asset management and network management database where new information can be persisted that may be beyond the current structures of the Infrastructure.
  • the Utility of the Pre-co ⁇ elation methodology and the Infrastracture is the significant reduction in system load resulting fi-om the key-hole narrowing of the threat field-of-view and coincidental efficiency gained by disciplined and continuous learning.
  • the cumulative effect of all of the facets of pre-co ⁇ elation is that the actual resulting information from the tuned collection, categorization and organized storage is that the information is not in need of nearly as much real correlation BEFORE analysis even begins.
  • Pre-correlation is performed prior to Persistance with Categorization.
  • the results of initial analysis are characterized by Breaches if they are Vulnerabilities, Attacks, or Violations, or other Discovery information.
  • Other incoming data includes raw Events and Discovery data (descriptive information about the network and its components).
  • the Infrastracture supplies a standardized and integrated Data Stracture for Events, Discovery, Vulnerabilities, and Intrasion Detection analysis.
  • the Infrastracture also utilizes Data Structures for Inventory management with automatic extraction from the Discovery data stracture.
  • the Infrastracture provides a Data Stracture for Alert workflow management, which also is automatically populated from the Events, Discovery, Vulnerability, and Intrasion Detection data structures.
  • Policy Implementers can more readily focus efforts on specific, targeted fields of threats. Also, analysis elements of Policy Implementers can run at the Repository Database and perform and can also populate more data into them.
  • Discovery data is stored into multiple tables in the database as efficiently as possible during discovery. Where possible, all of the rows inserted into the various discovery tables use the same identity number as the primary key when a specific new discovery item is entered. Utility: This eliminates the need to generate new identity numbers for each table, and provides efficiency since the enforcement of primary keys need not occur at this timeframe.
  • Data entered into the Discovery data structures is usually 'point in time' observation information. In the case where the Policy Implementer provides observation timeframe ranges, that information is also persisted.
  • Discovery data can also be created by Co ⁇ elation, so it is important to continue the process of coalescence to include Correlation result data over time.
  • the Infrastracture is established to track breaches of policies and to start workflows to alert responsible parties that the breaches have occurred.
  • the Infrastracture provides status and evaluation reporting facilities for breaches by policy and by context. It also provides a facility for simplifying the process of auditing and accreditation — it provides for both reporting information by policy, but also provides a questionnaire system for collecting the manually entered information (completing the forms) required for audits or accreditation reviews.
  • the events are interpreted by a subscriber that is a part of the Policy Implementer or that is provided by the Infrastructure for reuse by policy implementers.
  • the interpreted events are converted to breaches of various types in this interpretation processing.
  • Statuses include presence and condition information for assets and configuration information.
  • Actions in response to breaches and status changes may be invoked by the infrastracture or by components of a policy implementer based upon rales included in the policy implementer.
  • the actions are called alerts when the user should be informed, or action items when only workflow is initiated.
  • Workflow processing may also create alerts for instigating action such as manual intervention by a user.
  • Specific Responses chosen are based on automatic rales which are linked to Breach Types and are provided by programmed elements of the Policy Implementer.
  • the reactions may trigger rales for deploying new software or updating existing software, new provisioning of the network, alteration or blocking of the network configuration, or a large number of other Defensive Reactions or Enforcement Actions.
  • the workflow associated with the breach's initiation of an Alert or an Action is performed by the Workflow facility utilizing the AutoFunctions function.
  • Breaches and Statuses cause an awareness by the infrastracture of discovered network devices and connectivity as well as the configuration and 'signatures' of those devices. This information is tracked in the Infrastracture in both a discovery data stracture (all discovered information) as well as an inventory giving all 'last known' information about the devices and their connectivity.
  • the Coalescence facility stores inventory data into the Inventory Data Structures.
  • the Coalescence facility reduces the number of rows in the database. It accomplishes this by successively removing rows from each table in turn, addressing the information in that table on the basis of the information of all of the other tables as needed. [00289] Though this process is akin to co ⁇ elation, it is different because it is based upon comparisons of retrieved results based upon Plan scans primarily, to reduce the amount of data actually stored. It is also different because the purpose of it is to create timeframe range records from point in time records in the Discovery data.
  • Coalescence finds all Discovery observations in a timeframe where there is no substantive difference between the observations, and there is also no other observation in that timeframe for the same discovered object.
  • the Coalescence facility searches for timeframes where the observations regarding a discovered object are substantially (described below) the same, then it reduces those timeframes by finding any observation regarding that discovered object which shows a difference in some characteristic that is considered important (this is described below).
  • the first observed and last observed times for the timeframe are then set on one of the observation records in the timeframe (the representative) and all the other observations are eliminated from the database, adjusting other database records to point to the representative record (by resetting foreign keys).
  • Coalescence is not Consolidation. Coalescence does not include normalization in general, and it does not traditional aggregation. Consolidation can filter out irrelevant data, focusing on the important threat-related data using rales. Consolidation is perfonned before Coalescence by the Local Analysis facility and eliminates many false positives before persistence.
  • the Coalescence facility has two basic components: the fixed query structure and the extendable query stracture.
  • the fixed query stracture is entirely programmed into the Infrastructure, while the extended queries are provided as Policy Implementer.
  • the Coalescence facility changes the list of discovery record characteristics (columns) that are used in its various queries. These queries are used to determine which records in the discovery tables are 'substantially the same'.
  • the list of characteristics are different for each type of discoveiy object, but are usually related to the 'status' (or state - a well-defined logical or operational mode that the network object is in) of the observed object. For instance, initially, the Plan that was the source of the observation is considered a differentiator. If two or more Plans generated observations within a timeframe, then the timeframe will be broken into two or more smaller timeframes. After a while, the Plan holds little meaning and it is much more important to combine the Discovery data based upon real characteristics. At this point, the queries in coalescence exclude consideration of plan differences.
  • the extendable queries may change the nature of the standards set by the Irifrastracture by providing a different list of the observations in a given timeframe that will be combined.
  • Coalescence is also applied to Events in the Infrastracture, but is often less important because of the pre-processing performed by Policy Implementer Agents.
  • Co ⁇ elation is the process of establishing or finding relationships between entities. This definition is very general, but in security work, correlation may be defined as improving threat identification and assessment processes by looking not only at individual events or observations, but at sets of events and observations, based on some common parameter. Various types of co ⁇ elation can be used to glean attack intelligence. Micro and Macro Co ⁇ elation are both included in the hifrastructure. Co ⁇ elation in the Infrastracture includes multi-variate threat analysis.
  • Conelation in the Infrastracture is based upon both Event data and Discovery data, as well as Inventory data. Conelation generates new Discovery data and new Alerts or Actions for workflow. Coalescence includes Co ⁇ elation result data over time.
  • the Conelation facility has two basic components: the fixed query structure and the extendable query stracture. The fixed Co ⁇ elation facility is entirely programmed into the Infrastracture, while the extended Co ⁇ elation facility is provided by various Policy Implementer.
  • the Pattern-Recognition scenario rules data stracture contains and names scenarios which are sequences of events (first event x, then event y, etc.) which might indicate or describe some attack or user / machine action which should cause concern.
  • the rules also include the necessary characteristics of status (state), conditions, timeouts and actions.
  • Pattern-Recognition data structures also provide a list of rales which each Inventory Object is CURRENTLY being watched for, including the rale step which was last observed.
  • Conelation rules may be applied to incoming events data in real-time (as they arrive) or to the historical events stored in the database.
  • the elements of Policy Implementer within the Local Analysis stage applies Co ⁇ elation rales to incoming events data in real-time.
  • the elements of Policy Implementer residing near the Discovery database applies Co ⁇ elation rales to the historical Events and Discovery data stored in the database, providing data mining analytics to uncover concealed activity and threats from low level, long cycle activity.
  • the rales engine is schedule granularly for execution either by defaults or Policy Implementer settings, and may be reset by users.
  • Statistical co ⁇ elation does not employ any pre-existing knowledge of a specific attack but rather studies activities and events for their normalcy.
  • Infrastracture statistical conelation is provided by Policy Implementer which are written to use the base understanding from the Inventory system and the Infrastracture Metrics facility data structures.
  • Statistical co ⁇ elation may occur before data is persisted by the Persistance with Categorization step or after it.
  • Subscribers may be parent event managers 2610, management consoles 2620, or other plug-ins 2630. Although subscribers are shown as being on separate hosts, they may be threads that are local to the event manager which perfonn aggregation, analysis, conelation, or other functions.
  • Subscriber processes may return control messages that describe response actions. These control messages are received by the event manager's command and response component. Control messages are queued and sent to the intended recipient the next time the recipient checks in with the event manager.
  • Fig. 27 is a block diagram showing functional components of event management according to one embodiment of the invention.
  • events may be received by event manager from child event managers. Events are persisted and queued using the calling thread.
  • a routing engine thread dequeues the event, matches its type against one of the entries in its routing table, and sends it to all registered subscribers for that event.
  • Subscribers are invoked with an event manager thread. Generally, a subscriber will spawn a separate thread to perfonn blocking I/O operations. It also maintains a queue where events are stored until they are serviced by the subscriber.
  • Fig. 28 is a block diagram showing functional components of event management according to one embodiment of the invention.
  • the event manager 2800 has a proxy at the child event manager.
  • the proxy knows what events the parent event manager currently recognizes.
  • the proxy (on the child event manager) subscribes to the events that the parent wants to see.
  • Events are immediately persisted in step 2810 prior to enqueuing in step 2820.
  • Events are dequeued and compared against a routing table 2830 that matches event types to subscribers. The table is populated when subscribers notify the event manager with a new subscription request for a certain event type.
  • Any number of subscribers can subscribe to an event. If the event is found in the routing table, then it is sent to all of its subscribers. If the event type is not found, or it has no subscribers, then the event manager treats this as an enor condition and generates an error event.
  • Fig. 29 is a process flow chart showing an event management hierarchy, according to one embodiment of the invention.
  • This implementation is more suitable than the aforementioned distributed models since it reduces event duplication and isolates filter and co ⁇ elation processing to only those nodes that should perform it.
  • this manner of distributing collection work across many nodes drastically improves the performance and reliability of the monitoring system and does not overburden one particular resource.
  • Infrastructure delivers a high performance, dynamic, flexible and non-intrusive monitoring architecture that scales well to large, distributed systems.
  • Fig. 30 is a process flow chart showing command propagation, according to one embodiment of the invention.
  • the event manager receives commands from an upper level in step 3002. They can originate, for example, from the management console, administration server, or an event subscriber. Commands are queued in the event manager by the command and response component in step 3004.
  • Messages are also received from lower level controllers in step 3012.
  • the command and response component of the event manager removes commands destined for the controller off the queue and packages them into the messages response which is returned to the controller in step 3014.
  • the Metrics facility statistics data structure contains and names metrics used for differentiation between normal and abnormal activity.
  • Each Metrics statistics row contains a query and a reference to a breach type that associates a risk to the metric.
  • the metrics queries are run automatically based upon the frequency specified in the row.
  • the metrics generated are retained and reported in real time and historically as trends.
  • the trends are stored in the metrics buckets stracture of the Infrastracture.
  • Algorithmic co ⁇ elation is used in addition to the categorization of Events, Vulnerabilities and Discovery, as well as with the Inventory information to compute the threat levels specific to various attack types, such as the threat of a denial of service or worm/virus attack, and provide trends based upon the results, by device, asset-group, and policy.
  • Detecting threats using statistical co ⁇ elation does not require any pre-existing knowledge of the attack for it to be detected.
  • the queries in the metrics system provide thresholds and actions which may be set to find threats based upon pre-defined activity thresholds.
  • the thresholds are defaulted but may be reconfigured based on the customer's experiences.
  • the use of rules by type of asset-group is defaulted, and may be overridden for different customer asset- groups.
  • the Conelation Metrics provides various parameters in the Metrics Data Structures for asset-groups to set the algorithm for faster querying and higher accuracy detection. For instance, if a certain normal level of specific reconnaissance activity (e.g., port scans) is exceeded for a prolonged period of time, a specific Breach would be generated by the system. A different threshold applied on a different set of devices would imply a different level of activity to cause a Breach. These parameters may be adjusted over time by Policy Implementer so that the metrics computed from other available event context data (such as vulnerability scanning results or metrics settings for normal user activity on the asset-group) can take effect.
  • a certain normal level of specific reconnaissance activity e.g., port scans
  • a specific Breach would be generated by the system.
  • a different threshold applied on a different set of devices would imply a different level of activity to cause a Breach.
  • These parameters may be adjusted over time by Policy Implementer so that the metrics computed from other available event context data (such as vulnerability scanning results or metrics settings for normal
  • the AutoFunctions function provides a relatively open facility to run predefined stored procedures and SQL queries.
  • the AutoFunctions function is configured based upon frequency of execution of each stored procedure or query, and provides a result storage mechanism.
  • the AutoFunctions function is also used for managing workflow for the Infrastracture.
  • the Metrics facility extends well beyond the Statistical Conelation methodology.
  • the Metrics facility provide for detecting problems with storage space and other database issues, track user interaction rates for trending, and provides Metrics for other risk levels based upon alerts being generated.
  • the Inventory data structures contain information about network objects which are similar (inclusive of) the discovery objects.
  • the inventory information only contains the most recent 'status' information for each identified network object.
  • the characteristics that form the 'status' are different for each network object and a standard, set by the Infrastructure, defines those characteristics. This standard is revised over time.
  • the Inventory data structures are used to persist information beyond what is generated by Discovery. Status requirements are set in the Inventory, so that when a status of a device is detected that is different from the status requirement, a Breach is generated internally.
  • Utility The Inventory system provides the ability to check the statuses of various network objects, including services, open ports, open and blocked routes, etc. It also provides a simple lookup mechanism for finding all known devices by asset-group. It provides a consistent basis for the Discovery process and for Pre-Co ⁇ elation.
  • the discovery process will find devices in a network under protection that are not actually covered for protection themselves. These unregistered devices should usually be licensed for protection, or they will be reported for auditing as insufficiently protected to the 'duty of care' level prescribed by policies and implemented by policy implementer rales. In these cases, licensing actions, installation and/or deployment of new Infrastracture (controller only in this case) and Policy Implementer will be triggered automatically or under a workflow approval process.
  • Utility is shown by the automatic licensing operations and deployment of infrastracture and policy protections to newly discovered devices.
  • the inventory stracture yielded by the Discovery facility is used in reporting. New discovery is linked to this inventory information, and new infonnation collected from the users about the network and its devices is tied to the inventory so that the collected information is all integrated and protected from loss more substantially than raw event or discovery data can be.
  • Specialized reporting is provided by the Report Generation facility of the Infrastracture. These include data mining, dynamic reports, and custom reports.
  • An "audit” is conducted by an outside organization and results in a formal written examination of the enforcement discipline and appropriateness of the policies of the organization. Security audits test how the confidentiality, availability and integrity of an organization's information is assured.
  • a computer security audit is a systematic, measurable technical assessment of how the organization's security policy is employed at a specific site.
  • Computer security auditors work with the full knowledge of the organization, at times with considerable inside information, in order to understand the resources to be audited.
  • the Infrastracture assist the auditor by supplying, for example, the:
  • Utility The Infrastracture tells an auditor how the security policies - the foundation of any effective organizational security strategy - are actually used and an assessment of how effectively the organization's security policy is being implemented.
  • the audit is a continuous operation that is broken into visits for ease. As organizations evolve, their security structures will change as well. The security audit is not a one-time task, but a continual effort to improve data protection. The audit builds on previous audit efforts to help refine the policy and correct deficiencies that are discovered through the audit process.
  • Accreditation is performed by an authority above the development team called the accreditor.
  • the result of Accreditation is the formal authorization to set a system into production or operation.
  • Accreditation is the process of independently verifying that a system operates properly in performing an appropriate organizational need based upon all available information and inspections of the implementation.
  • the system requirements statement and documentation produced during certification, and perhaps the procedures documentation for procedures sunounding the system are examined, and the system and its context are inspected.
  • Accreditation for security also ensures that the security measures implemented in the system are appropriate for the required level of security and the information being processed and that discipline for maintaining the specific security protection can and will be continued.
  • the Assurance components provide for Accreditation much in the same way as for Audits.
  • the Assurance facility provide a central repository for the policy documentation, and direct traceability to all Policy Implementer and the plans and documentation for all aspects of the implementation of those Policy Implementers. It also provides templates and checklists that can form a basis for the accreditation.
  • the templates and checklists will also include interview questionnaires and fact finding questionnaires that allow for a step by step completion process for the accreditation based upon their standards.
  • the standards are usually stated in terms of security 'assumptions' and security 'assertions'.
  • a security assumption is some protective measure (a protection) assumed to be provided within the security domain by an external (from the Policy Implementer) facility whereas a security assertion is a protection being declared as being provided by the Policy Implementer.
  • a security requirement is met by one or more security assertions which are dependent upon some limited set of the security assumptions.
  • the normal (initial or default) questionnaire for an Accreditation includes, for example, checklist items for each Policy Implementer and for each protection offered:
  • a. The security protections are confinned by reviewing the Implementation Plan against the referenced and other relevant organizational policies.
  • the Policy Implementation Plan is validated as providing appropriate and consistent mechanisms to implement the functionality required by the Policy.
  • the Operating Procedures are reviewed to ensure that sufficient procedural security in the context being addressed by the Policy Implementer to ensure the effectiveness of the security protections implemented and to provide adequate security where security requirements are not otherwise addressed.
  • the Policy Implementation Description is reviewed to ensure that it adequately describes the system and that the security overview co ⁇ ectly reflects the posture identified in the Policy and Implementation Plan.
  • the Policy Implementer security assumptions and assertions are extracted from the Policy, the Implementation Plan, and the Operating Procedures and security checklists created. f.
  • Each context is inspected (if real) or context (if example) to confirm adequate implementation of physical and personnel security, and to ensure communications and computer security protections (measures) have been conectly installed (for real only).
  • Equipment real or presumed
  • An evaluation of the computer system will be carried out to confirm that the computer system adequately protects the information being processed and stored, and that the computer security protections implemented cooperate as required to provide a well integrated security environment.
  • the Customer uses the Infrastracture Security component to authorize users and set up new business units as needed.
  • the User Administration function allows an administrator to manage organizations, users, memberships of users in organizations, and their associated roles and privileges. Registered users may also update their own details.
  • Infrastructure Management All access, read only, electronic feedback capability for the areas and asset-groups they manage.
  • Indirect (web-based) access to the Infrastracture database is established via an application-level login from the Infrastracture application as described above. Direct access requires knowledge of the Schema's credentials within the database.
  • Passwords are stored in the database in an encrypted format for security and privacy reasons.
  • Each Policy Implementer component (and controller) is counted by the licensing mechanism before it is allowed to operate.
  • the Authentication and Authorization processed are defined above.
  • Event data is collected in great volume. Discovery data and some alerts are entered in lower volumes. Each of these forms of data may be expunged after action is taken on them. Inventory, on the other hand, should be retained for further use. This differentiation allows for the controlled expunging paradigms implemented in the infrastructure. Background processes remove unneeded event, discovery, and alert information to off-line files.
  • the archiving process is controlled by Archiving Rules stored in the Infrastructure database. These rales specify which data may be archived based upon queries. These Arcliiving Rules may be provided by Policy Implementer or by the customer. Enforcement, Audit and Policy Accreditation
  • the results of the Policy Statement, Policy Implementation Plan and Description, and Certification process are used as an input to the Enforcement, Audit and Policy Accreditation Step in the methodology.
  • the Assurance Component of the Infrastracture provides an inventory and report description data stracture, an online documentation facility, a report generation facility, and a data entry facility (for additional report information entry) for use by reviewers, auditors, and accreditation. Online documentation for the functionality of the installed protection facilities on any system deployed will be available in an integrated document.
  • the network and equipment installed is detected automatically and cataloged by the Infrastucture.
  • the inventory is downloadable for off-line study, and automatically formatted into report segments for specific accreditation agencies and audit types.
  • the basic purpose of the Infrastracture is intrasion prevention and risk reduction. More specifically, the purpose of the Infrastracture is to provide a framework for the effective deployment and operation of Policy Implementer solutions to aid in:
  • the distributed framework provides, for example:
  • the frastracture includes the components as shown in Fig. 1: including the Management Framework and the Installed System Framework.
  • the Management Framework and Installed System Framework closely model each other, but the descriptions provided here differentiate for emphasis.
  • the Management Framework provides strong Developer and Assurance Components which provide complete facilities for internal and external developers, whereas the Installed System Framework provides less emphasis on the complete functionality in those components.
  • Only the Management Framework includes the complete E-commerce Component. Policy Implementers submitted through the Policy Implementation submission Infrastructure Component in an Installed System Framework are not subject to sale from the Management Framework on an automatic basis.
  • the Management Framework includes client system(s) 102, distribution component(s) 106, Policy Implementation submission component(s) 110, developer component(s) 118, assurance component(s), E-commerce component(s), inventory component(s), analysis and discovery component(s), license and security component(s), event manager(s), management console(s), primary Administration console 112, subordinate administration console(s) 114, and software development kits (SDK's).
  • client system(s) 102 distribution component(s) 106
  • Policy Implementation submission component(s) 110 includes assurance component(s), E-commerce component(s), inventory component(s), analysis and discovery component(s), license and security component(s), event manager(s), management console(s), primary Administration console 112, subordinate administration console(s) 114, and software development kits (SDK's).
  • SDK's software development kits
  • the Installed System Framework includes client system(s), distribution component(s), Policy Implementation submission component(s), developer component(s), assurance component(s), E-commerce component(s), inventory component(s), analysis and discovery component(s), license and security component(s), event manager(s), management console(s), subordinate administration console(s), and software development kits (SDK's).
  • the Policy Implementation submission component(s), developer component(s), assurance component(s), E- commerce component(s), and SDK's are optional.
  • the Infrastructure describe here provides a distributed framework and process for computer and network security and configuration management in any collection of computing or networking devices.
  • This framework encompasses the apparatus and process for implementing security, network, and configuration policies, called 'Policy Implementers'.
  • a Policy Implementer is a body of computer program code stating some set of the following:
  • Policy Implementers specify and control the deployment and activation of the code and proper parameters throughout an instance of the distributed framework to maintain an improved level of operation of the network in a managed process.
  • a Policy Implementer names a configuration. Policy Implementers provide a facility to coordinate the detection, analysis, and response to network inefficiencies, e ⁇ ors, outages, security events, software aging, and other factors, using some set of coding, rales, and the tools available in the Infrastracture across one or more devices within the Infrastracture Framework.
  • a Policy Implementer consists of one or multiple application service elements (ASE). Each element provides one part necessary for the successful enforcement of the Policy being implemented.
  • the elements of the Policy Implementer ASE rely upon the infrastracture provided by the Framework to provide program to program associations and connections, remote operations management, and reliable data transfer, among other facilities.
  • Policy Implementers can also provide a manageable tool greatly simplifying the burden on systems administrators, packaging most or all tools and parameters needed to detect and respond where needed to manage the network of devices. Policy Implementers provide a simplified mechanism for ensuring effective and auditable deployment of the proper stracture for network protection. Policy Implementers provide a packaging facility to allow for the sale of those elements and knowledge to end users and organizations which are needed to address a specific type of vulnerability or issue.
  • Policy Implementers can provide a management tool for compliance. With Policy Implementers, an organization may more easily demonstrate due diligence in meeting specifications of legislation (Sarbanes-Oxley, HIPAA, GLBA) or other industry or government standards (e.g. NIST). When a Policy Implementer is deployed throughout an organization's network, it installs some collection of agents, plug-ins, and rales that address the measurement/detection, analysis, and reaction requirements of the policy, transparently adjusting to the actual structure of the network and the devices in it.
  • Policy Implementers can provide a management tool for accreditation.
  • an accrediting organization need only specify the minimum set of Policy Implementers that need be deployed into an organization, and be satisfied that those Policy Implementers are up to the task of breach detection and enforcement of the Policies which they implement.
  • An organization being audited for accreditation need only show that they have deployed the proper Policy Implementers and that they have kept them up to date.
  • Policy Implementers can provide a management tool for systems administration. Policy Implementers consist of components and rules that are each specific to an application or platform in the environment.
  • a sign-on policy enforcer would include an Agent that detects poor rales on an ERP system on a mainframe running SAP, as well as one for a mainframe running PeopleSoft, one for a Solaris system running SAP, etc. It would also include an application detector Agent. It would include a Management Console plug-in for displaying detected installations of ERP systems in the network, non-confonnant installations and installations that are properly protected.
  • the Policy Implementer would also include the event descriptions for the messages coming from these agents, conelation rales for assisting the analysis, the alert descriptions needed for analysis, decision rules that allow a user interaction where needed to respond to breaches, the report descriptions for the accreditation proceedings, auditor reporting tools, and administrative information. With one instruction to deploy the Policy Implementer, all of the needed rules and prograniming would be sent to the proper devices and activated according to proper schedules. [00372] Policy Implementers can also be specified as a part of another Policy Implementer. This encasement technique allows for easier deployment of the Policy.
  • Policy Implementers can provide a management tool for development. Rather than attempt the difficult and complex task of developing an entire implementation of a policy in one step, the Policy Implementer provides a task structuring and phasing device to limit the scope of development to a smaller requirement at the beginning and retain discipline as the scope of implementation grows on subsequent versions.
  • Data and database objects are included in the Data Repository.
  • the data stored in the Repository is generally classified into categories for distribution. These categories are set in the Infrastracture Management Framework Repository.
  • Licensing and Security Components control the use of the system. Only sanctioned devices may receive the Infrastructure software and only registered devices and users may submit new data to the repository or obtain information from it. Licensing and security should be distributed. Licenses control the number of client systems or networks that may be sanctioned or from which information may be collected. These licenses are established in the E-Commerce component, and are controlled centrally to ensure the collection of revenues. For that reason, the licenses should be distributed and the system repositories should be protected so that licenses may not be compromised. Thus the system is tiered for security purposes, and the repositories distribute licenses and security information downward as needed to provide for the operation of customer systems under the licensing and security. Since multiple levels of parent-child relationships can exist, licenses and accompanying security information should be propagated from parent to child so long as the child is properly authorized to receive those updates, until no child needs access to the license. The Distribution components, in concert with the Controllers, enforce software licensing.
  • Fig. 2 is a block diagram of the client system 102 components and the external information technology (IT) sources 104 shown in Fig. 1, according to one embodiment of the invention.
  • the client system represents a computer system upon which, at a minimum, a controller is installed. Typically, this is a system to which agents from a Policy Implementer are deployed rather than other framework components.
  • the client system may or may not represent the target of the agent's operations, since the agents installed on it may detect and control external devices.
  • protections over Infrastracture Components other than the client system may also be established by the installation of a controller on those components and the distribution of policy implementer agents to that controller. Controller
  • the controller on the client system represents a mediation point between an agent and the rest of the functional architecture.
  • the controller provides critical agent management and monitoring functions, insuring that its agents do not operate outside specified bounds. It also provides secure communication with other framework components, and provides a unique identity for the device it is resident on.
  • the agent If the agent is not targeting the client system upon which it is installed, it performs its operations on one or more external IT sources.
  • these agents utilize network management, such as simple network management protocol (SNMP), or other control protocols to communicate with their targets.
  • SNMP simple network management protocol
  • the distribution arcliitecture may include various subcomponents, detailed below.
  • the distribution architecture includes an E-Commerce Component (See Fig. 38) providing a user Web site providing a graphical user interface for software selection, purchase and deployment. Only authorized, registered users are granted the necessary pennissions to perform these functions.
  • Framework software When Framework software is purchased, the sanctioning process provides for establishing the framework component on a customer device and the retrieving of the framework software to that device from a distribution component.
  • Policy Implementer software is purchased, the licenses for it are deployed to a proper administration and distribution components, allowing for the distribution of the software to a local client system, or to be added to the customer's software distribution engine for enterprise distribution.
  • FIG. 44 A Data Stracture is shown in Fig. 44 which provides the persistence needed for enforcing security in the Infrastracture.
  • All Infrastructure components should be sanctioned to serve as a component of the system framework.
  • the sanctioning process is distinct from the licensing process as it applies to the operation of a certain framework component on a certain device.
  • All Policy Implementer components should be installed on devices that are covered under a proper license for the Policy implementer to operate or to be deployed.
  • Authorization for distribution typically comes in the way of valid per-device' and 'per-network' software subscriptions, which entitle a registered device in the network to obtain new versions of Policy Implementer or Framework software code and configuration information from a distribution engine so long as the number of devices registered for the code in the device or network 'asset- group' does not exceed the number allowed by the license (or subscription) for that 'asset-group'.
  • Authorization for distribution also allows for a child distribution engine to receive new versions of code as it is released, so long as the number of licenses for that code in 'asset-groups' below that distiibution engine is greater than one and so long as the distribution engine remains in contact with the parent administration system.
  • Authorization to operate and authorization to submit data to management nodes are controlled in a similar license based control facility.
  • Fig. 3 is a block diagram of the distribution components 106 shown in Fig. 1, according to one embodiment of the invention. Distribution delivers software, configuration data, and updates to target systems, including client systems as well as other core components. The precise process of performing distribution varies depending upon whether the update is for programming, data, or data structure.
  • Fig. 24 is a process flow chart showing a distribution hierarchy, according to an embodiment of the invention.
  • distribution engines 2402, 2404, 2406, 2408, 2410 can be scaled and tiered to provide a manageable framework for software distribution. Distribution is performed top-down in a hierarchical manner, where the engines are logically arranged essentially as a hierarchical tree (as shown in Fig. 24), with redundancy. Each engine, or node, in the distribution tree only knows about those distribution nodes directly beneath it, but the children are under multiple parents in a priority scheme to provide the redundancy.
  • Non-leaf nodes with Data Repositories higher in the tree contain summary meta-data about all the engines, devices, Infrastracture Framework and the Policy Implementer components managed beneath it. License information, but not configuration information is stored at these nodes for non- immediate children.
  • leaf nodes with Data Repositories contain detailed information about Infrastructure Framework and the Policy Implementer software and configuration releases and device data that is necessary for managing component instances.
  • Distribution engines regularly communicate via the distribution client with their parent engine asking it for any software updates that are available. Updates are pulled down from the parent and persisted in the engine's local CODE REPOSITORY. Base Data and License is pulled down and stored in the DATA REPOSITORY. At leaf nodes, Controllers retrieve these updates the next time they queiy the distribution service.
  • a "master" distribution engine 2402 where copies of all the software, base data, and licenses for all the Controllers beneath it are stored.
  • Each Infrastracture implementation may have one or more master engines at a customer site that serve this purpose, and additional masters may reside elsewhere.
  • a master is provided for Application Service Provider customers as well.
  • a service provider provides a separate master distribution engine that customer implementations can use as their root engine in order to receive live updates to their existing repositories.
  • Customers can elect to either be connected to a service provider master engine, or they can maintain their own (disconnected) master distribution engine internally. In this case, software and data updates are perfonned manually at the master and then propagate down to the Controllers.
  • Licenses and sanction infonnation are established in the database of the Parent Administration Component, and are then deployed to all databases toward the user devices which they affect.
  • the device becomes a member of an asset-group of sanctioned devices. Licenses for the asset-group may then be applied to the operation of Policy Implementers on the device.
  • a machine may be 'sanctioned' and licensed for the hosting and operation of zero or more of the Policy Implementer components, and is counted by the licensing mechanism before it is allowed to operate for each of those components.
  • the SOFTWARE DISTRIBUTION ENGINE is responsible for managing all software deployments in an implementation of the SYSTEM.
  • Distribution delivers software, configuration data, and updates to target systems, including client systems as well as other core components.
  • Administration and Distribution components can be tiered, so that multiple levels of parent-child relationships can exist, whereby deployments and updates propagate from parent to child so long as the child is properly authorized to receive those updates.
  • Deployment involves programming, data, and data stracture updates to child systems. The precise facility and methodology of performing deployment varies among these three types of updates.
  • the terai Component is used to refer to specific software configuration items as used in the Infrastracture.
  • a Configuration Item in this description is limited to be a software element that is under control of the Component Management configuration management system. It refers to the deployable format of software in the mfrastracture rather than the source code from which the deployable format stems unless they are the same. It includes all elements that contribute to the deployable baseline.
  • the code deployed in the Infrastructure includes:
  • Policy Implementer Distribution is implemented by the Distribution Component of the Infrastracture. Distribution of Framework components may be carried out in a similar manner. The distribution is begun when a new sanction, license, or update occurs.
  • Base data is information persisted in the databases of the Infrastracture that is generally common to all installations. It includes control information for the Management Framework and for the Installed Frameworks. It is differentiated from other data in that it is not specific to any customer. It includes template info ⁇ nation form many objects and sample data. Without this data, the Infrastructure could not properly function.
  • Fig. 1 provides the data structure components comprising this base data.
  • Base data is deployed with each Installed Framework. Updates to the base data must be copied to all Installed Frameworks from the Management Framework.
  • Base data and the database objects (stored procedures, data structure definitions, etc.) for the Infrastracture are deployed automatically by the Tiered Database Deployment facility of the Infrastracture.
  • This facility consists of the elements shown on Fig. 3.
  • the process involved in Tiered Database Deployment is shown in the process diagram in Fig. 24.
  • License and Sanction data is distributed by the same facility as Base Data. Security over the distribution is strict, and is aimed at automatic distribution and 100% conectness of result in all cases. An incremental distribution based upon a differential calculation is used to shorten the timeframe for distribution and to reduce bandwidth. The distribution is carried out between databases directly where possible so that the differential may be computed quickly.
  • the database serving as the source of the base data and the licensing data need not be the same.
  • the database serving as the source of the base data and objects is one of the Quality Assurance databases so that all objects in the system are appropriately tested before deployment. Special views and mechanisms are set up in this database so that only that data and those objects appropriate for deployment to the target or child database may be seen during the deployment.
  • source database for licensing and security information is a database which has a window into the Main Administration database where E-commerce business rales are controlling the alteration of information. This window limits the information visible to the child and guarantees that the child cannot alter the data.
  • the methodology for determining differences is based upon a table (called DB_OBJECT_VERSIONS) that contains a series of metrics which form a signature for all objects and data in the database.
  • DB_OBJECT_VERSIONS a table that contains a series of metrics which form a signature for all objects and data in the database.
  • a trigger in the database recalculates the signatures based upon the present state of the objects in the database. This recalculation is done efficiently relative to the speed of the transmission of the contents of the difference.
  • Any objects that do not exist in the child are created in this process. Any objects that exist in the child database but do not exist in the parent are retained. The process is carried out on a schedule and as the child is commanded to attempt the synchronization.
  • a special number called a security token is passed to the child database in this process. This token allows security procedures in the child to detect breaches of security or lapsing of licenses and to take appropriate action.
  • control data for the system is distributed and checked for accuracy on an automatic basis. Changes to the database stracture are controlled and distributed as well.
  • Fig provides the data stracture used for managing components of the
  • Deliverable Components are under configuration management, and their readiness for deployment is tracked.
  • the components are defined initially to be immutable — without a version.
  • Those components with versions which are ready for deployment are added to a third component list. All of these lists are a part of the base data, and are thus deployed in the process above.
  • Each child database that has a list of licensed and sanctioned devices automatically obtains these lists as they are updated.
  • Each Distribution Engine Database maintains a directory of all the licensed and sanctioned devices and components that it manages, along with configuration and deployment data for each.
  • This deployment data contains infonnation about the components' type, location, software release, and configuration release, among others. Using this data, the Distribution Service applies business logic to determine what updates need to be delivered to the Client.
  • Each child database that has a list of licensed and sanctioned devices will automatically generate a list of components that should be deployed and the device where they should be deployed to whenever new data is received from the parent regarding the components newly available. This last list is updated as components are deployed by the SOFTWARE DISTRIBUTION ENGINE, and the updates may be provided back to the parent for licensing controls.
  • Fig. 4 is a block diagram of the event management components shown in Fig. 1, according to one embodiment of the invention.
  • EVENT MANAGERS are responsible for performing two primary functions: Event analysis and Command propagation.
  • EVENT MANAGERS subscribe to events from other EVENT MANAGERS or directly from CLIENT SYSTEMS. As a result of these subscriptions, EVENT MANAGERS are configured to receive, log, analyze and distribute events to other subscribers. This publish and subscribe architecture enables events to be analyzed, aggregated and combined through multiple processing layers. Subscribers to an EVENT MANAGER can include other EVENT MANAGERS, MANAGEMENT CONSOLE SERVERS or registered 3rd party Policy Implementer elements called plug-ins.
  • Fig. 5 is a block diagram of the management console server shown in Fig. 1, according to one embodiment of the invention.
  • the MANAGEMENT CONSOLE SERVER provides the end users with a presentation mechanism to expose data and functions of the SYSTEM, customized by the elements of a Policy Implementer.
  • a CONTROLLER is installed on the MANAGEMENT CONSOLE SERVER and is used to perfonn general management tasks including receiving and installing Framework and Policy Implementer software updates, and receiving configuration changes and administrative commands from the Administration Console Server for execution.
  • the MANAGEMENT CONSOLE SERVER 110 provides a basic user interface and is capable of dynamically incorporating new console modules in the form of Policy Implementer plug-ins.
  • PLUG-INS are loaded into the MANAGEMENT CONSOLE SERVER by the PLUG-IN MANAGER.
  • MANAGEMENT CONSOLE ENGINE Utilizing the MANAGEMENT CONSOLE ENGINE, these plug- ins subscribe to events from known EVENT MANAGERS and provide custom display, analysis and management capabilities for those events. Additionally, plug-ins can persist data for future access and reporting and manage communications.
  • Fig. 6 is a block diagram of the primary administrative console 112 shown in Fig. 1, according to one embodiment of the invention.
  • the PRIMARY ADMINISTRATION CONSOLE SERVER is a central warehouse of administration data used to track customers, sales and globally aggregated operational data. It is used as the ultimate arbiter of data validity in the SYSTEM. It also provides a senior level of management system tools for supervision of the SYSTEM.
  • Fig. 7 is a block diagram of the subordinate administrative console 114 shown in Fig. 1, according to one embodiment of the invention.
  • the SUBORDINATE ADMINISTRATION CONSOLES provide a facility for constrained administration of the Framework by administrative personnel at the service provider, or, if deployed at a customer's site, by the customer's Framework administrator. It allows for user authorization and password control, software release control (within proper bounds), system status evaluation, and system overrides.
  • Fig. 8 is a block diagram of controllers, which are distributed throughout the functional architecture shown in Fig. 1, according to one embodiment of the invention.
  • Each of the functional components depicted in Fig. 1 preferably include a software controller (hereinafter, just “controller”) used to control agents, plug-ins, or other software.
  • controller a software controller
  • Developer Components include:
  • SDK's Software development kits
  • the USER WEB SITE provides a graphical user interface for software selection, purchase and deployment. Only authorized, registered users are granted the necessary permissions to perform these functions.
  • the Developer Community first enters into involvement with Infrastracture by contacting the User Web Site. They receive an initial system for trial and learn about the system on the User Web Site.
  • the DEVELOPER EXCHANGE WEBSITE provides the tools necessary for software developers to make contributions to the software repository and to administer their software and their account with a service provider.
  • Primary functions provided by this web site include:
  • Developer code submission tool which accepts new and updated software components and inserts them into the code certification process.
  • the EXECUTIVE, AUDITOR, AND ACCREDITOR WEBSITE provides the tools necessary for customer executives, the auditing and the accreditation community to ensure a proper discipline, process improvement, and duty of care over the security system they purchase from a service provider. They may use the Management Framework and/or their Installed Framework to manage the audit engagements and accreditation efforts needed and to administer their account with a service provider. Primary functions provided by this web site include: • Executive, Auditor, and Accreditor registration.
  • Engagement Information Management (primarily contact information, security privileges, and checklists only).
  • a customer executive is a CXO level manager of an organization that has become a purchaser of Infrastracture. Executives are provided access to the Audit and Accreditation Community on a confidential basis and are provided with evaluations of their system beyond what is normally provided in the Installed Infrastructure.
  • Certifiers are vetted individuals who review Policy Implementer software. They have specialized access to the system resources.
  • Auditors are organizational users who provide Security Audits to clients who are Infrastracture customers. They are provided specialized access to Infrastructure, and their permissions for use are propagated on a very restricted basis to the Customer repositories for a specific engagement period. Customers MUST request the distribution of security access to their repositories, and the control over the access is managed at the Customer repository on a confinnation basis.
  • the Auditors create their reports utilizing the facilities of the Infrastracture Management Framework system, and their reports are, in part, made available to customer executives on the Management Framework and other approved users on the Installed Framework.
  • Accreditors are organizations which certify the operation of entire systems for security at Infrastructure customers. Their representatives are provided specialized access to Infrastracture, and their permissions for use are propagated on a very restricted basis to the Customer repositories in the same way as the permissions of auditors, but for a specific and shorter duration.
  • the Accreditors create their reports utilizing the facilities of the Infrastructure Management Framework system. Their accreditation certification report may be provided on the Management and Installed Framework systems at their discretion.
  • Fig. 9 is a block diagram of the policy implementer development kit 116 shown in Fig. 1, according to one embodiment of the invention.
  • a POLICY IMPLEMENTER DEVELOPER KIT in conjunction with the Developer Component of the Infrastracture provides the tools to combine the functionality of certified system components, including Agents and Plug-ins, to provide the requisite functionality to deliver an implementation of a Policy.
  • PoDK POLICY IMPLEMENTER DEVELOPER KIT
  • the Developer Component of the Infrastracture provides the tools to combine the functionality of certified system components, including Agents and Plug-ins, to provide the requisite functionality to deliver an implementation of a Policy.
  • Provided as part of the PoDK is a facility to define and manage analysis and reaction rules, which form the foundation for workflow between the constituent components.
  • This kit along with other Developer Components provide a context for defining the relationships between agents, plug-ins, and rales. It also enables users (acting in the role of policy builders) to define accreditation criteria - ranges of acceptable behavior from elements of the policy system, and to define what actions to take when the policy is breached - when actual activity falls outside those limits.
  • a policy builder could combine the functionality of an Intrusion Detection Agent, Vulnerability Monitoring Agent, Vulnerability Management Agent, Network Discovery Agent and Network Asset Management Plug-in by building a comprehensive set of analysis and reaction rales that integrate the operations of each component into a single policy application. This application would be responsible for insuring that an organization's network assets comply with a defined level of vulnerability protection and it would perform continuous audits of those assets.
  • the Policy and Policy Implementer Description section describes the Policy being implemented, and the way that the Policy Implementer is constructed to enforce the policy.
  • the Compliance Description section describes the intentions of the Compliance Directives, Programs, and Procedures related to the Policy being Implemented, and provide forms for reporting compliance and requesting Accreditation and Certification. It also states the 'efficacy' of the Implementer.
  • the Communication Description section describes the specific information and application protocols relating to the implementation of the Policy to fully inform the user and the Accreditation bodies regarding the nature of information transfened from and to the Client System and how it is used.
  • the Policy Implementer Configuration section provides a configuration tool to specify by selection any subcomponents of the Policy Implementer that have already been developed or to create a 'stub' for those subcomponents not yet begun. It also permits the specification of deployment and applicability (usability within other Implementers or for specific environments) of the Implementer, stating where its components will be placed within the Framework.
  • the Policy Implementer Merchandising section describes who needs the Implementer, provides FAQ and packaging information, and states pricing, sales policies, and subscription information. Includes info ⁇ nation on insurance plans and adjunct services such as Compliance Assistance and Process Improvement Services.
  • the Processing Description section provides descriptions of all algorithms, rales, code, measurements, workflow, and processing schedules used to implement the Policy.
  • the Code Review section describes and specifies the process involved in and history of the review of the coding and methodology of the Implementer.
  • the User Interface Description section describes and specifies the dashboard facilities for the Implementer. Sets roles and privileges for the use of the User Interface, and allows tailoring of existing interface components.
  • the Management Specification section describes and specifies the issues raised by the Implementer and how they are directed (workflow) and how they may be cancelled based upon new events.
  • Agent Developer Kit
  • Fig. 10 is a block diagram of the agent developer kit 118 shown in Fig. 1, according to one embodiment of the invention.
  • the Agent Developer Kit in conjunction with the Developer Component provides the facilities for a software developer to implement new agents.
  • the ADK is comprised of a number of tools, including:
  • Sample software (which provides a number of reference agent implementations); Integrated Development Environment (IDE); core agent software libraries; developer documentation; software debugger used to provide a facility to test and debug software; and a submission mechanism, which enables a developer to submit agent software to the Developer Exchange that the programmer is registered with.
  • IDE Integrated Development Environment
  • core agent software libraries software libraries
  • developer documentation software debugger used to provide a facility to test and debug software
  • submission mechanism which enables a developer to submit agent software to the Developer Exchange that the programmer is registered with.
  • a CONTROLLER is installed on the ADK both for use as a test mechanism for agent development, but also to receive and install software updates. This CONTROLLER has special facilities to enable debugging.
  • Fig. 11 is a block diagram of the plug-in developer kit 120 shown in Fig. 1, according to one embodiment of the invention.
  • the PLUG-IN DEVELOPER KIT (PDK) in conjunction with the Developer Component provides developers with the facilities required to design, implement, test, and submit Plug-ins for certification.
  • sample code including data, filter, actions and events
  • IDE to enable rapid development of plug-ins
  • core software libraries developer documentation
  • software debugger used to provide a facility to test and debug software
  • a submission mechanism which enables the developer to submit software to the Developer Exchange that the programmer is registered with
  • manifest designer which allows the developer to customize the contents and format of the manifest file used to authorize the operation of plug-ins
  • a local website which provides the facility to view those plug-ins which are management console oriented
  • conelator designer which provides the tools necessary to build complex conelation rules for the plug-in
  • queue plug-in designer and a UI plug-in designer (which provides the developer the tools needed to build a GUI plug-in which conforms to the management console specs).
  • a CONTROLLER is installed on the PDK both for use as a test mechanism for plug-in development, but also to receive and install software updates. This CONTROLLER has special facilities to enable debugging.
  • the organizations within the Infrastracture system community are reporting information about themselves to others, and this information, if released without review, if released to the wrong organizations, or if not released to the proper organizations at the proper time, will likely cause detriment to the organization. For this reason, organizations are structured into administrative (managerial), structural (control, response, or reporting), or review groupings within Infrastracture. This provides organizations with rights of access based upon the relationships which they have with other organizations.
  • Users in Infrastracture should be members of organizations. They may possibly be general members of the public (considered so when not otherwise authorized access), reporting users, reviewing users, administrators or analysis group members, depending upon the roles they have been assigned within their organization(s).
  • Machines or Devices are also roles in Infrastracture. These roles are not usually the same as the roles provided for users, but the roles operate in a similar manner.
  • the Infrastructure User Administration function allows an administrator to manage organizations, users, memberships of users in organizations, and other administrators and all of their associated roles and privileges. It also manages user registration, and allows secure access by registered users who may also update their own details.
  • the Infrastracture Device Administration function allows an administrator to manage licenses, subscriptions, device sanctioning, device functionality and description of devices in organizations and all of their associated roles and privileges. It also manages initial device registration, and allows secure access by registered devices.
  • the Security Component of the Infrastracture provides:
  • Manage user accounts can manage registration function including organizational role assignment.
  • ⁇ 'Common Interest' group - users are grouped together by a shared common user attribute, e.g. preferences and/or categories.
  • the invention described above thus overcomes the disadvantages of known systems by enabling a customer to select policies for automatic distribution, installation, and configuration management onto the customer's network, and by improving the way that security events are collected, analyzed, and responded to.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computing Systems (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne un système et une méthode permettant de fournir des services sécurisés fondés sur un réseau. Dans un aspect de l'invention, des modes de réalisation permettent à un client de sélectionner des politiques, pour une installation, pour une gestion de configuration et pour une distribution automatique sur le réseau du client. Dans un autre aspect de l'invention, des modes de réalisation permettent d'améliorer la manière dont les événements sécurisés sont recueillis, analysés et traités.
PCT/US2004/016084 2003-05-20 2004-05-20 Systeme et methode pour une surveillance securisee d'entreprise et pour une gestion de configuration WO2004104793A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US10/882,153 US20070180490A1 (en) 2004-05-20 2004-07-01 System and method for policy management

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US47176303P 2003-05-20 2003-05-20
US60/471,763 2003-05-20

Publications (2)

Publication Number Publication Date
WO2004104793A2 true WO2004104793A2 (fr) 2004-12-02
WO2004104793A3 WO2004104793A3 (fr) 2005-01-06

Family

ID=33476885

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2004/016084 WO2004104793A2 (fr) 2003-05-20 2004-05-20 Systeme et methode pour une surveillance securisee d'entreprise et pour une gestion de configuration

Country Status (1)

Country Link
WO (1) WO2004104793A2 (fr)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007045150A1 (fr) 2005-10-15 2007-04-26 Huawei Technologies Co., Ltd. Procede et systeme de controle de la securite d'un reseau
WO2007060664A3 (fr) * 2005-11-25 2009-04-09 Continuity Software Ltd Systeme et procede de gestion de ressources de protection des donnees
US8346614B2 (en) * 2007-09-06 2013-01-01 Metabyte, Inc. Promoting a web technology through a virtual service marketplace
US20160127394A1 (en) * 2014-10-30 2016-05-05 Resilient Systems, Inc. Action Response Framework for Data Security Incidents
CN114490302A (zh) * 2022-03-04 2022-05-13 大庆火兔网络科技有限公司 一种基于大数据分析的威胁行为分析方法及服务器

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6014697A (en) * 1994-10-25 2000-01-11 Cabletron Systems, Inc. Method and apparatus for automatically populating a network simulator tool
US6058383A (en) * 1996-06-27 2000-05-02 Kent Ridge Digital Labs Computationally efficient method for trusted and dynamic digital objects dissemination
US20010029603A1 (en) * 2000-04-05 2001-10-11 Nec Corporation System development method, functional unit development method, development-support system and storage medium storing program of same
US20020016920A1 (en) * 2000-08-02 2002-02-07 Masahiro Komura Method and apparatus for mediation of security information, and a computer product
US6530024B1 (en) * 1998-11-20 2003-03-04 Centrax Corporation Adaptive feedback security system and method

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6014697A (en) * 1994-10-25 2000-01-11 Cabletron Systems, Inc. Method and apparatus for automatically populating a network simulator tool
US6058383A (en) * 1996-06-27 2000-05-02 Kent Ridge Digital Labs Computationally efficient method for trusted and dynamic digital objects dissemination
US6530024B1 (en) * 1998-11-20 2003-03-04 Centrax Corporation Adaptive feedback security system and method
US20010029603A1 (en) * 2000-04-05 2001-10-11 Nec Corporation System development method, functional unit development method, development-support system and storage medium storing program of same
US20020016920A1 (en) * 2000-08-02 2002-02-07 Masahiro Komura Method and apparatus for mediation of security information, and a computer product

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007045150A1 (fr) 2005-10-15 2007-04-26 Huawei Technologies Co., Ltd. Procede et systeme de controle de la securite d'un reseau
EP1936892A1 (fr) * 2005-10-15 2008-06-25 Huawei Technologies Co., Ltd. Procede et systeme de controle de la securite d'un reseau
EP1936892A4 (fr) * 2005-10-15 2009-02-11 Huawei Tech Co Ltd Procede et systeme de controle de la securite d'un reseau
WO2007060664A3 (fr) * 2005-11-25 2009-04-09 Continuity Software Ltd Systeme et procede de gestion de ressources de protection des donnees
US8863224B2 (en) 2005-11-25 2014-10-14 Continuity Software Ltd. System and method of managing data protection resources
US8346614B2 (en) * 2007-09-06 2013-01-01 Metabyte, Inc. Promoting a web technology through a virtual service marketplace
US20160127394A1 (en) * 2014-10-30 2016-05-05 Resilient Systems, Inc. Action Response Framework for Data Security Incidents
WO2016069111A1 (fr) * 2014-10-30 2016-05-06 Resilient Systems, Inc. Cadre de réponse active pour incidents de sécurité de données
US10367828B2 (en) 2014-10-30 2019-07-30 International Business Machines Corporation Action response framework for data security incidents
US20190356682A1 (en) * 2014-10-30 2019-11-21 International Business Machines Corporation Action response framework for data security incidents
US11463456B2 (en) * 2014-10-30 2022-10-04 Green Market Square Limited Action response framework for data security incidents
CN114490302A (zh) * 2022-03-04 2022-05-13 大庆火兔网络科技有限公司 一种基于大数据分析的威胁行为分析方法及服务器

Also Published As

Publication number Publication date
WO2004104793A3 (fr) 2005-01-06

Similar Documents

Publication Publication Date Title
US20070180490A1 (en) System and method for policy management
Lins et al. Trust is good, control is better: Creating secure clouds by continuous auditing
US20210334821A1 (en) Platform for facilitating an automated it audit
CN107835982B (zh) 用于在计算机网络中管理安全性的方法和设备
Force et al. Security and privacy controls for federal information systems and organizations
Aagedal et al. Model-based risk assessment to improve enterprise security
US20060080656A1 (en) Methods and instructions for patch management
Ellison et al. Evaluating and mitigating software supply chain security risks
US20070157311A1 (en) Security modeling and the application life cycle
Khan et al. Systematic literature review on security risks and its practices in secure software development
US20070233538A1 (en) Systems, methods, and apparatus to manage offshore software development
Jacobs Engineering information security: The application of systems engineering concepts to achieve information assurance
Baca et al. Countermeasure graphs for software security risk assessment: An action research
Ismail et al. A unified framework for cloud security transparency and audit
US20070240223A1 (en) Systems, methods, and apparatus to manage offshore software development
Khan et al. Security assurance model of software development for global software development vendors
Empl et al. SOAR4IoT: securing IoT assets with digital twins
Buecker et al. IT Security Compliance Management Design Guide with IBM Tivoli Security Information and Event Manager
Splaine Testing Web Security: Assessing the Security of Web Sites and Applications
WO2004104793A2 (fr) Systeme et methode pour une surveillance securisee d'entreprise et pour une gestion de configuration
Hansch Automating security risk and requirements management for cyber-physical systems
Koopman A framework for detecting and preventing security vulnerabilities in continuous integration/continuous delivery pipelines
Espedalen Attack trees describing security in distributed internet-enabled metrology
Copeland et al. Azure Security Center and Azure Sentinel
Caracciolo Policy as Code, how to automate cloud compliance verification with open-source tools

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase