System and method for multi-source vulnerability management

Abstract

A method for multi-source cloud infrastructure vulnerability management includes receiving cloud element information related to a cloud-based element in a cloud environment. The method also includes receiving first vulnerability information from a first vulnerability source and receiving second vulnerability information from a second vulnerability source. Cloud element context information is also received from the cloud environment regarding the cloud-based element. A multi-source vulnerability database is then generated from both the first vulnerability information and from the second vulnerability information. The cloud element information and the cloud element context information are then evaluated using the multi-source vulnerability database to generate a vulnerability assessment.

Description

[0001] The chapter headings used herein are for organizational purposes only and should not be construed as limiting the subject matter described in this application in any way.

[0002] introduction

[0003] The move of data and software applications to the cloud has fundamentally changed how computer systems deliver software applications and services to users. For example, the network edge of traditional enterprise networks has been replaced by virtual perimeters, thus changing how computers process information and access data. This eliminates the entry and exit points traditionally used for deploying hardware security and network visibility devices.

[0004] Not only does the underlying processing architecture differ in the cloud, but the scale and growth models of processes, applications, and services also differ. For example, cloud-based computing system resources can grow and shrink on very rapid timescales. Furthermore, cloud-based computing systems can be highly distributed, making the tracking and proper sequencing of events far more challenging. In addition, the security and vulnerability threat models in cloud-based computing systems are inherently different compared to fixed-infrastructure enterprise networks. Therefore, traditional methods and systems for monitoring and protecting network information and systems in the cloud are no longer sufficient to protect users. Attached Figure Description

[0005] The present teachings and other advantages thereof, according to preferred and exemplary embodiments, are described in more detail below with reference to the accompanying drawings. Those skilled in the art will understand that the drawings described below are for illustrative purposes only. The drawings are not necessarily drawn to scale; rather, the emphasis is generally placed on illustrating the principles of the teachings. The drawings are not intended to limit the scope of the applicant's teachings in any way.

[0006] Figure 1 The steps of an embodiment of a multi-source cloud infrastructure vulnerability management method according to this teaching are shown.

[0007] Figure 2 A block diagram of an embodiment of a multi-source cloud infrastructure vulnerability management system according to this teaching is shown.

[0008] Figure 3 An example of a workflow for managing a multi-source cloud infrastructure vulnerability management system for virtual private clouds, in accordance with this teaching, is shown.

[0009] Figure 4 A block diagram illustrating an embodiment of the method and system for collecting multi-source vulnerability information according to this teaching is shown.

[0010] Figure 5 An embodiment of the workflow for a server management method and system for the present invention is shown.

[0011] Figure 6 Detailed steps in an embodiment of the vulnerability management method of this teaching are shown. Detailed Implementation

[0012] The teachings will now be described in more detail with reference to exemplary embodiments illustrated in the accompanying drawings. Although the teachings have been described in conjunction with various embodiments and examples, they are not intended to be limited to these embodiments. Rather, as those skilled in the art will understand, the teachings include various alternatives, modifications, and equivalents. Those skilled in the art who receive the teachings herein will recognize additional implementations, modifications, and embodiments, as well as other areas of use, within the scope of the disclosure described herein.

[0013] References to "an embodiment" or "an embodiment" in the specification mean that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the teachings. The phrase "in an embodiment" appearing in different places in the specification does not necessarily refer to the same embodiment.

[0014] It should be understood that the steps of the method described herein can be performed in any order and / or simultaneously, provided that the teachings remain operational. Furthermore, it should be understood that the apparatus and method described herein may include any number or all of the described embodiments, provided that the teachings remain operational.

[0015] Systems and methods are needed to manage vulnerabilities in cloud-based software and / or infrastructure by identifying and / or remediating vulnerable elements as quickly and efficiently as possible. Vulnerability management is the process of identifying, classifying, categorizing, and / or remediating and mitigating vulnerabilities in computer software and / or firmware. In a cloud environment, vulnerabilities exist at multiple layers of the cloud stack. Vulnerabilities in elements within cloud infrastructure are diverse, numerous, and can change rapidly. For example, vulnerabilities differ based on the characteristics of the elements within the cloud infrastructure, such as the version of software running on the element, the different operating systems used by the element, the different applications running on the element, and the different infrastructure providers. Therefore, vulnerability information can be noisy and / or diluted. In a cloud environment, information about a specific known vulnerability is less useful if it is generalized. Furthermore, in a cloud environment, information is less useful if it is not provided in a context that helps locate vulnerabilities within the cloud infrastructure.

[0016] A characteristic of the methods and apparatus taught in this course is that it generates vulnerability information with less noise and / or dilution than existing vulnerability management techniques. For example, instead of being told that a bash version is generally vulnerable to all operating systems, users of the systems or methods taught in this course are instead told that a specific version of their bash is vulnerable to the version of software they are currently using (such as their Ubuntu version).

[0017] Another feature of the methods and apparatus taught in this course is that it generates vulnerability information rich in cloud-specific context. For example, instead of notifying the user that the “server” is vulnerable, it informs the user, for example, “Your Django application server is vulnerable, and it is on a load balancer.” Therefore, the methods and systems taught in this course provide users with vulnerability assessments that are particularly relevant to the cloud-based system at hand. For example, it provides users with vulnerabilities in processes installed on a specific Linux distribution, rather than vulnerability information that typically affects all Unix systems. The latter type of general assessment is difficult for users to manage and / or remediate because it lacks specificity and context.

[0018] As used herein, the term "cloud-based element" can refer to hardware, software, or a combination of hardware and software deployed in the cloud. For example, a cloud-based element can refer to software running on cloud-based hardware. A cloud-based element can also refer to a hardware device located in the cloud. A cloud-based element can also refer to a virtual machine or other virtual computing operation. A cloud-based element can also refer to software and the hardware-based computing device running said software. Software, as used herein, refers to a collection of executable code that provides processes, applications, and / or services. Additionally, cloud-based elements as used herein can refer to various services and / or platforms running in the cloud.

[0019] One aspect of this teaching is a cloud-native vulnerability management application suite that can run on any computing platform, including, for example, virtual machines, servers, desktops, laptops, and handheld devices. Some or all of the computing platforms on which the systems and methods of this teaching are implemented can be dedicated or shared.

[0020] Many service providers offer cloud-based elements, including a range of compute, storage, database, networking, and cloud migration services. Additionally, various cloud-based elements are available, such as tools and applications like search, load balancing, and software development tools. Amazon Web Services (AWS) offers a variety of services, including Elastic Compute Cloud (EC2), Relational Database Service (RDS), and Simple Storage Service (S3). Amazon also provides services such as Identity and Access Management (IAM). Similarly, Google offers cloud services, sometimes referred to as Google Cloud. Microsoft offers Azure cloud services. These and other service providers offer a variety of cloud storage services, including managed databases, object, block, and file storage. The commercial cloud service offerings are expected to grow rapidly in the coming years.

[0021] A feature of some embodiments of the multi-source cloud infrastructure vulnerability management system of this teaching is that they unify different sources of vulnerability information into a common view, which is used to generate outputs related to applicable vulnerabilities that are particularly useful to users. This includes generating alert outputs and providing remediation pathways. In other words, various embodiments of the multi-source cloud infrastructure vulnerability management system of this teaching unify cloud-based vulnerability information collected from different sources associated with different cloud service providers and / or vulnerability information providers, making it possible to process it to generate effective and actionable vulnerability assessments.

[0022] Some existing technology systems rely solely on the National Vulnerability Database (NVD) as a source of vulnerability data. Other existing technology systems rely on other vulnerability data sources. In these existing technology systems, multiple sources of vulnerability data are not processed together. Therefore, these existing technology systems do not establish a common, richer view of specific vulnerabilities. In contrast, embodiments of the methods and systems taught in this paper combine NVD information with other sources, including operating system-specific vulnerability data such as CentOS Errata and Security Advisories (CESA) and Amazon's Linux Advisories (ALAS). Information from these sources is collected and ingested into a format that supports consistent processing of the collected data on cloud-based elements to provide a unified vulnerability picture of those elements.

[0023] Another feature of this teaching is the ability to gather information from the user's cloud-based elements and the various cloud providers offering those elements. Additional information from cloud providers provides contextual data, which leads to more targeted and / or accurate vulnerability assessments. By understanding details about, for example, the location, type, version, and other contextual information of a particular cloud-based element, vulnerabilities and associated remediation paths for that specific cloud-based element become more specific, accurate, and prioritized.

[0024] Therefore, various embodiments of the vulnerability management methods and systems described in this teaching provide users with vulnerability information relevant to their systems. For example, vulnerabilities may be provided for processes installed on a specific Linux distribution, contrary to the common practice of affecting all Unix systems. The methods and systems described in this teaching offer advantages over existing vulnerability management techniques because they reduce false positives and because the cloud provider-specific context makes it clearer which cloud-based elements need patching.

[0025] Figure 1The steps of an embodiment of a multi-source cloud infrastructure vulnerability management method 100 according to the present teachings are illustrated. In a first step 102, information is collected. This collection step 102 may involve various other methods of passively receiving and receiving and / or retrieving information. This collection step 102 may involve retrieving information from, for example, websites, databases, or other repositories. A wide variety of information may be collected in collection step 102 of various embodiments of the method. For example, in some embodiments, information about the cloud-based infrastructure being managed is collected. Information about various cloud-based elements is collected, including details about cloud-based elements such as operating systems, workloads, packages, servers, machine images, hosts, disks, and other types of storage. Additionally, information about other monitored cloud-based elements related to vulnerability assessment may be collected in collection step 102.

[0026] In some embodiments of collecting step 102, information is collected from various sources of vulnerability data. For example, various known sources of public vulnerability data can be collected. For example, collecting vulnerability information from any specific vulnerability information source can take the form of downloading from a webpage, utilizing an API, reading one or more files, and / or monitoring RSS feeds. For example, vulnerability information can take the form of a CVE list, vulnerability classification tracking, and / or vulnerability remediation details. As a specific example, information can be collected from the National Vulnerability Database (NVD) operated by the National Institute of Standards and Technology (NIST), which provides an updated list of common vulnerabilities and exposures (CVEs). In various embodiments, one or more operating system-specific vulnerability data (such as CESA for CentOS, Amazon's ALAS Linux security recommendations, vulnerabilities in Ubuntu, and others) can also be collected. Other example sources of vulnerability information may include Red Hat, Microsoft, various operating system vendors, and various computer and network system providers, service providers, and open-source and proprietary vulnerability databases and websites.

[0027] Information can be collected in various ways in collection step 102. For example, information can be read from a file. The information can also be received from a network. Furthermore, the information can be downloaded from a webpage. The processor implementing collection step 102 of method 100 can also request information from a cloud provider, and / or the cloud provider can send information to the processor performing collection step 102 of method 100. Information can be provided or retrieved at a specific time, and / or can be provided or retrieved on a near real-time basis. In some embodiments, collection step 102 receives information from a software agent. Furthermore, in some embodiments, collection step 102 receives information from an operating system. Furthermore, in some embodiments, collection step 102 receives information from a database.

[0028] In the second step 104, the collected information is ingested to form a general information set based on information from multiple sources. The ingested information is provided in a uniform form for further processing in subsequent steps. This uniform form may take the form of one or more lists with a specific set of attributes. In some embodiments of ingestion step 104, the collector receives a file in collection step 102, and then in ingestion step 104, the file is read into the processor and combined with other collected information to produce a file that includes information from multiple sources.

[0029] In some embodiments, the ingestion step generates two types of ingestion information. In these embodiments, the first type of ingestion information is cloud element information. Cloud element information is based on collected information about the cloud-based infrastructure being managed. The cloud-based element information may also include contextual information derived from the cloud provider. The second type of ingestion information is multi-source vulnerability information. Multi-source vulnerability information is based on information collected from various vulnerability information sources.

[0030] In step 3, 106, cloud-based element information and multi-source vulnerability information are assessed. This assessment includes, for example, matching specific vulnerabilities with applicable cloud elements in the cloud-based managed infrastructure, prioritizing vulnerabilities, determining vulnerability severity, identifying appropriate remediation measures, and / or identifying related vulnerabilities. Other vulnerability assessments and / or cloud infrastructure context may also be part of step 106.

[0031] In step four, 108, the assessed information is processed in downstream processing that performs multiple tasks. For example, step four, 108 may generate a vulnerability assessment. Step four, 108 may determine whether a particular vulnerability should be excluded from a particular vulnerability assessment if, for example, a user has chosen to suppress reporting of that particular vulnerability. Therefore, step four, 108 may filter the assessed information to exclude specific predetermined vulnerabilities. Step four, 108 may also generate alerts, identify policy violations, issue reports, remediate threats, and / or modify non-compliant infrastructure to a compliant configuration. The processing of the assessed information in step four, 108 may result in alert and / or remediation steps that enable the user to make decisions or take actions. The processing of the assessed information in step four, 108 may be used to perform automated changes to the processes and / or configurations or reconfigurations of cloud-based elements to remediate various issues associated with the identified vulnerabilities. The processing in step four, 108 may generate output related to the generated vulnerability assessment to the user's I / O device for the user to consume. Step four, 108 may process the assessed information based on user-supplied rules to produce the various results and actions described herein. In some embodiments, the result of step 108 generates a computer process capable of alerting, reporting, and analyzing for end users. For example, the result may lead to changes in infrastructure configuration, compliance assurance, and the establishment of vulnerabilities and threats.

[0032] Evaluation step 3 106 or processing step 4 108, or both, may include a series of processing steps, each producing specific processing data and synthetic information derived from the collected information. Some embodiments of step 3 106 and / or step 4 108 utilize a pipelined processor architecture, which has the advantage that processing can be applied in any order because the output of each pipeline stage fed to the next stage is generic event data. For example, the pipelined processor may be the pipelined processor disclosed in U.S. Patent Application No. 15 / 846,780, filed December 17, 2017, entitled “System and Method For Cloud-Based Operating System Event and Data Access Monitoring,” which has been assigned to the assignee. The entire contents of U.S. Patent Application No. 15 / 846,780 are incorporated herein by reference. Each stage may also generate refined evaluation information associated with evaluation step 3 106. The different stages of processing step four 108 can generate, for example, raw event logs, alerts and notifications based on events that meet customizable rule sets, vulnerability and exploitation analysis, identification of security threats and vulnerabilities, and archives of time-series raw event logs.

[0033] Figure 2A block diagram of an embodiment of a multi-source cloud infrastructure vulnerability management system 200 according to the present teachings is shown. One or more cloud environments, clouds 1202 to N204, are connected to collector 206. As used herein, the term "cloud environment" is a set of cloud-based elements that can be provided to users. In some embodiments, the cloud environment is provided by a service provider such as Amazon, Google, Microsoft, and numerous other cloud service providers. In some embodiments, the cloud environment is a provisioned or on-premises cloud environment, such as one hosted in the offices, data centers, networks, and / or other processing and / or input / output system facilities of one or more organizations. As used herein, the term "cloud system" is a set of cloud elements residing in one or more cloud environments used by a large number of users, including, for example, companies providing various network services and software-as-a-service platforms. Collection systems 208, 210 receive cloud element information from cloud environments 202, 204. Multiple vulnerability information sources 208, 210 are connected to collector 212. Collectors 206, 212 use various methods to collect information from cloud environments 202, 204 and vulnerability information sources 208, 210. Multiple collectors 206 and 212 do not necessarily use the same method. In various embodiments, the number of cloud environments, the number of vulnerability information sources, and the number of collectors are different.

[0034] Collectors 206 and 212 are connected to processor 214. The processor can take the form of various processor systems. For example, processor 214 can be a single processor or multiple processors. Processor 214 can be hardware-based, or it can be a virtual machine processor. Processor 214 can also be a cloud-based processor. Additionally, processor 214 can be a service executing on cloud infrastructure. Processor 214 is connected to database 216. Database 216 can be a single database, or it can include multiple databases. Furthermore, database 216 can be a private database or a public database.

[0035] Processor 214 is connected to one or more user input / output devices 218. User input / output devices 218 may include, for example, websites, computers, applications, management systems, or devices for managing, monitoring, modifying, and / or operating cloud infrastructure. For simplicity, Figure 2 Only a subset of the possible components of the monitoring system described in this teaching are shown. Some embodiments of the multi-source cloud infrastructure vulnerability management system 200 include large-scale systems with many other cloud environments, collectors, databases, processors, and user I / O.

[0036] refer to Figure 1 and Figure 2Both, processor 214 executes some or all of the steps of method 100. Cloud environments 202, 204 generate cloud element information received and / or retrieved by collector 206 in step one 102. Vulnerability information sources 208, 210 generate vulnerability information received and / or retrieved by collector 212 in step one 102. Processor 214 executes all or part of ingestion step two 104 and / or evaluation step three 106. Processor 214 may also execute step four 108 downstream to generate alerts and other outputs. Processor 214 also provides information to database 216. Additionally, processor 214 may use information retrieved from database 216 and / or information retrieved from ingestion step two 104, evaluation step three 106, and any results of downstream processing step 108. Processor 214 then sends the results of downstream processing of general event data to user I / O 218. In some embodiments, user I / O executes some or all of processing step four 108.

[0037] In some embodiments, one or more of collectors 206, 212 are collection processors that are part of processor 214. In some embodiments, processor 214 includes an ingestion processor that performs ingestion step two 104, an evaluation processor that performs evaluation step three 106, and a downstream processor that performs at least some of the processes in step four 108. These different processors may be the same or different physical and / or virtual processors.

[0038] Figure 3 An embodiment of a workflow for managing a multi-source cloud infrastructure vulnerability management system 300 according to this teaching is shown. The virtual private cloud 302 includes one or more software agents 304, 304', and 304''. A virtual private cloud is a cloud-based service typically provided by a cloud service provider. A virtual private cloud is also a set of shared computing resources that includes various cloud-based elements allocated to users within a public cloud environment. A virtual private cloud provides a degree of isolation between different users sharing computing resources in a cloud environment.

[0039] One or more of software agents 304, 304', and 304" collect information about various cloud-based elements in the virtual private cloud 302. Software agents 304, 304', and 304" can collect this information from the management platform within the virtual private cloud 302. For example, software agents 304, 304', and 304" can collect information from a package manager. Software agents 304, 304', and 304" can also collect information directly from cloud-based elements or related cloud-based elements of the virtual private cloud 302. A system element list 306 is generated. For example, a list of all packages running on the virtual private cloud 302, their operating system (OS) types, and their OS versions can be generated as part of the system element list 306.

[0040] Examine multiple vulnerability databases (308) to identify any potential vulnerabilities applicable to elements in the system's element list. For example, vulnerabilities specific to a particular package and OS type, as well as OS version, can be identified.

[0041] A potential vulnerability list 310 is generated for all applicable cloud-based elements. Potential vulnerability information 310 may include, for example, the severity of a specific vulnerability, its entry vector, and other details. Further processing 312 is performed to study, analyze, and filter the potential vulnerability list 312. In some embodiments, this processing 312 generates vulnerabilities specific to the managed cloud-based elements. In some practice examples, processing 312 applies computer security industry best practices and other security experiences to determine the severity of the vulnerabilities. Based on the severity determined from processing 312, a decision step 314 determines whether the system is vulnerable. If not, no action is taken 316. If so, a vulnerability assessment 318 is performed.

[0042] The results of vulnerability assessment 318 provide various information about vulnerabilities in cloud-based elements within Virtual Private Cloud 302. For example, in some embodiments, a list of vulnerable packets and associated CVEs is provided. In some embodiments, servers affected by the vulnerability are provided. In some embodiments, aggregated vulnerability key performance indicators (KPIs) are provided. As a result of the vulnerability assessment, users of Virtual Private Cloud 302 can therefore take remedial actions, such as patching software, modifying configurations, etc.

[0043] In various embodiments, the process cycle of the multi-source cloud infrastructure vulnerability management system 300 is repeated as software agents 304, 304', 304" collect information about various cloud-based elements in the virtual private cloud 302 during their established time periods. In some embodiments, the multi-source cloud infrastructure vulnerability management system 300 workflow is user-initiated. In some embodiments, after remediation actions are taken, all or some of the workflows are repeated, and the resulting vulnerability assessments are reflected as vulnerabilities that are no longer those successfully remediated items on list 318.

[0044] Some embodiments of this teaching install one or more of software agents 304, 304', and 304" at the host level of the virtual private cloud 302, thus enabling deep-level scanning of the server to find vulnerable installed packages. Software agents 304, 304', and 304" examine package information about the workload. The systems and methods of this teaching use process 312 to notify the user of the presence of vulnerable packages in the examined package information. Process 312 can organize the workflow around what is important based on common vulnerabilities and exposures (CVEs). This supports direct display of prioritized detected vulnerabilities on the user's control panel (not shown).

[0045] Figure 4 An embodiment of the method and system for collecting multi-source vulnerability information 400 according to this teaching is illustrated. Vulnerability data is input into a vulnerability tracking database 402. As described herein, one public source of vulnerability information is the National Vulnerability Database (NVD) source 404. NVD source 404 maintains the NVD website 406 and the NVD Common Vulnerability and Exposure (CVE) file 408, both of which contribute to combined data 410 of known vulnerabilities. Combined data 410 is used to generate an NVD CVE list 412. In some embodiments, information from the NVD CVE list 412 is collected and stored in the vulnerability tracking database 402.

[0046] Data stored in the vulnerability tracking database 402 may include, for example, a list of vulnerability packages represented in a Common Platform Enumeration (CPE) format. That is, information about vulnerabilities associated with a predetermined platform within a cloud-based system, software, and / or package. For example, vulnerabilities may include security-related software flaws and misconfigurations. For example, software vulnerabilities may be associated with code, package design, and / or system architecture. For example, the collected data may also include details of the vulnerability impact, such as attack vectors and scores. For example, the scores may be based on the Common Vulnerability Scoring System (CVSS), which is provided as part of NIST NVD.

[0047] The second vulnerability information source is Red Hat 414. Red Hat source 414 includes the Red Hat Security Data API (Application Programming Interface) 416, which provides Red Hat vulnerability classification tracking 420. Source 414 also includes a Red Hat security notification webpage 418, which provides Red Hat package vulnerability remediation details 422. Red Hat vulnerability classification tracking 420 information is collected and stored in a vulnerability tracking database 402. Red Hat package vulnerability remediation details 422 information is collected and stored in the vulnerability tracking database 402.

[0048] The third vulnerability information source is Ubuntu 424. Ubuntu source 424 includes the Ubuntu Security Tracker webpage 428, which provides Ubuntu vulnerability classification tracking 426. Source 424 also includes the Ubuntu Security Notification webpage 436, which provides Ubuntu package vulnerability remediation details 432. The Ubuntu vulnerability classification tracking 426 information is collected and stored in the vulnerability tracking database 402. The Ubuntu package vulnerability remediation details 432 information is collected and stored in the vulnerability tracking database 402.

[0049] The fourth vulnerability information source is Amazon 434. Amazon source 434 includes the Amazon ALA SRSS feed 436, which provides details 438 of remediation for vulnerabilities in Amazon Linux packages. ALAS is a Linux security advisory service. RSS is a well-known, truly simple, federated standard for content distribution. The Amazon Linux package vulnerability remediation details 438 information is collected and stored in the vulnerability tracking database 402.

[0050] The fifth vulnerability information source is CentOS 440. CentOS source 440 includes CentOS security notification webpage 444, which provides CentOS package vulnerability remediation details 442. CentOS package vulnerability remediation details 442 are collected and stored in vulnerability tracking database 402.

[0051] In various embodiments, information from sources 404, 414, 424, 434, and 440 is collected and stored as in combination. Figure 1 The multi-source cloud infrastructure vulnerability management method describes the collection 102 and ingestion steps 104. For example, the vulnerability tracking database 402 can be combined with... Figure 2 Database 216 is described.

[0052] Figure 5 An embodiment of a workflow for a method and system for managing multi-source vulnerability information 500 for server 502 used in this teaching is shown. At the start of workflow 500, the server is in an unknown vulnerable state. The system determines at decision point 504 whether a scan is needed. This determination is triggered, for example, on a newly registered server (scan needed = yes). In some embodiments, the determination is triggered at a user-configurable time point. In some embodiments, the determination is triggered at an automatically triggered point determined by the system, such as when a vulnerability information source publishes a new vulnerability or is otherwise determined by some other threshold. If a scan is determined to be needed at decision point 504, a collector acquires packet information 506 about server 502. In some embodiments, a software agent acquires packet information 506 about server 502.

[0053] The packet information acquired in step 508 is processed. This processing step 508 contextualizes the acquired packet information and places the data into a format that can be compared with vulnerabilities in vulnerability tracking database 510. In various embodiments, this vulnerability tracking database 510 is combined with... Figure 4The vulnerability tracking database 402 is described. Processing 508 allows the extraction of specific information from the vulnerability tracking database 510. For example, a specific version of bash on server 502 has a specific Ubuntu vulnerability. Therefore, vulnerabilities specific to server type, package type, package version, and / or other details about the package are extracted from vulnerability tracking database 510.

[0054] Additionally, contextual data about server 502 is collected from one or more cloud providers 514, 514', and 514". Information is also collected from server 502 to determine specific data and data context about server 502. As an example, contextual data may be collected to notify a user that a specific server 502 has been identified as a front-end web server on the Azure cloud platform. This contextual data about server 502 is ingested and processed 516 together with information collected from the vulnerability tracking database 510 to generate vulnerability data for the user of server 502. Continuing this example The processing output, in the form of vulnerability data 516, could be, for example, a user's font line web server having a bash vulnerability. Therefore, the specific combination of packet and server information collected during collection and ingestion allows the processor to generate vulnerability data 516, which is a highly specific and actionable vulnerability assessment not available in prior art vulnerability assessments. The specificity of the packet and server information is in a format that can be matched with the vulnerability tracking database 510, and can contain vulnerabilities from multiple sources, provided by context 512 collected from cloud providers 514, 514', and 514".

[0055] Figure 6 Detailed steps of an embodiment of the vulnerability management method 600 of this teaching are illustrated. In step 602 of method 600, vulnerability information is collected from the NVD. In step 604 of method 600, vulnerability information is collected from other sources. For example, vulnerability information may be collected from a specific operating system and the vulnerability data it provides in step 604. For example, CentOS, Ubuntu, Linux. Some of the information may be in the form of data stored via web pages and may be obtained by automatically identifying vulnerability data on these web pages. Some information may also be provided in the form of data obtained by API calls to an OS-specific data source. The use of various methods and from various sources to collect information is an important distinction that provides significant advantages for vulnerability management using the systems and methods of the present invention. Some embodiments use collectors responsible for collecting the necessary specific vulnerability data (e.g., NVD data collectors, CESA data collectors, Ubuntu vulnerability collectors, etc.). In various embodiments, these collectors implement specific collection methods to collect specific vulnerability information.

[0056] Step 3, 606 of method 600 involves collecting information about cloud-based systems of users under management. Step 3, 606 involves collecting cloud element information related to cloud-based elements in the cloud environment. In some embodiments, step 3, 606 is accomplished through a package scan performed by a software agent. In some embodiments, step 3, 606 collects information about the operating system and installed packages. This information may include, for example, type and version.

[0057] Step four, 608 of method 600 processes data collected from different vulnerability sources to present it in an appropriate form for storage and processing as part of a multi-source vulnerability database. Some embodiments of step four, 608 store data from each data source individually without any context from other data sources. Other embodiments of step four, 608 combine all vulnerability information collected from different vulnerability sources in steps one, 602, and two, 604, and store only specific vulnerability information applicable to a user-specific system. For example, embodiments of step four, 608 may generate vulnerability information only for a specific type of Unix operating system rather than general Unix. Some embodiments of step four, 608 process vulnerabilities from multiple vulnerability sources to generate and store in a multi-source vulnerability database generic vulnerabilities with less noise and / or better specificity than those reported in individual sources. For example, a generic vulnerability in a multi-user vulnerability database might replace two separately reported vulnerabilities from two different sources related to the same vulnerability.

[0058] Step 5 of Method 600, 610, processes the specific vulnerability information from the vulnerability database of the managed user system as determined in Step 3, 606.

[0059] Step 6.12 of Method 600 involves collecting additional contextual information about the cloud-based elements in the managed system. This information can be collected from the cloud provider that provides the cloud-based elements to the user's system. Contextual information can be important in determining the severity of a particular vulnerability. For example, a vulnerable package that is only accessible to the development team may pose a lower risk than a vulnerability that is accessible across the entire internet via a webpage.

[0060] Step 7.614 of Method 600 processes cloud-based element information, context information, and vulnerability information from a multi-source vulnerability database for the managed user system to generate a vulnerability assessment. The collected context (e.g., server tags) helps determine the priority of vulnerability remediation and provides users with additional details and context regarding system vulnerabilities provided in the vulnerability assessment. The importance of a vulnerability becomes more relevant based on context. For example, context helps users understand which servers must be patched first to significantly reduce the overall risk to the infrastructure. Examples of context include attributes such as: whether the server serves user network traffic; whether cloud provider firewall rules expose vulnerabilities exploiting specific ports; and whether vulnerabilities exist in database packets.

[0061] Step eight 616 of method 600 provides alerts and / or remediation details that enable the user to make decisions or take actions related to the vulnerabilities identified in step seven 614. Step eight 616 may provide reconfiguration of cloud-based elements based on the vulnerabilities identified in step seven 614. For example, software patches may be applied, ports may be changed, and / or databases may be modified. Furthermore, all unnecessary packages may be removed, OS notifications may be viewed and CVEs identified, recommended best practices may be applied, and packages may be verified to be up-to-date. Vulnerability scoring may be applied. Vulnerability scoring may be based on the Common Vulnerability Scoring System v2 (CVSS v2) used by NVD. In these cases, the severity may be high (H), medium (M), or low (L), determined by NVD. Some embodiments of method 600 allow users to suppress specific vulnerabilities, and these vulnerabilities are not processed and / or reported by the system. Some embodiments of step eight 616 are adapted to situations where the user establishes an acceptance of the risk of a specific vulnerability. For example, the user may determine that the presentation risk of a particular package vulnerability is acceptable. These risk acceptance criteria may be predetermined and / or they may be determined by the user at different points in the execution of the steps of method 600. In some embodiments, in step eight 616, vulnerabilities in the user's risk acceptance are suppressed and / or filtered out.

[0062] One feature of some embodiments of this teaching is that they compare a large number of published CVEs across all installed packages. Cross-checking can be performed against all corresponding vendor recommendations for these packages, and vulnerabilities can be identified, for example, against a specific image ID on an affected server. This approach significantly reduces the false positive rate. Some embodiments of the systems and methods of this teaching support automated inspection of package information about workloads and cross-checking against NVDs. Some embodiments of this teaching also provide users with manual, planned updates, cross-references with operating system vendors, and proactive guidance on which AMIs need updating. Systems based on this teaching are supported across all environments, cloud security providers, and containers, thereby reducing complexity.

[0063] One feature of some embodiments of this teaching is that they can support vulnerability management at the workload layer, which is highly efficient. Typically, vulnerability management involves monitoring configurations on user workloads and infrastructure to detect any increase in the attack surface. However, in practice, unauthorized packages may be installed in the base image, or packages may be manually installed in production environments. This makes tracking patches in cloud environments complex and tedious. For example, new base images (such as Amazon Machine images, or AMIs on Amazon Cloud-based systems) are often created every few weeks, leaving servers vulnerable during the time between a vulnerability becoming available and a patch being added to the AMI. When the attack surface remains vulnerable for too long, widespread vulnerabilities (such as Heartbleed or Shellshock) can cause serious problems. For example, cloud-based infrastructure may include servers outside the immutable infrastructure paradigm. These servers are often the most critical servers in the environment (e.g., OpenVPN servers, jumphosts, etc.), thus requiring continuous monitoring for vulnerable packages.

[0064] Furthermore, due to application dependencies, many packages are pinned and not updated with the underlying code. This makes these packages vulnerable unless regularly monitored and patched. Automated vulnerability scanning examines package information in near real-time to determine the presence and location of vulnerable packages. When implemented at the host level, automated scanning means that vulnerabilities can be identified and remediated at every step of the application lifecycle.

[0065] Another feature of the systems and methods for multi-source vulnerability management taught in this paper is that they provide a set of cloud-native (i.e., cloud-specific), platform-independent, and comprehensive vulnerability management applications. The results of embodiments of the vulnerability management methods and systems can provide users with synthetic and contextualized data related to vulnerabilities occurring in their cloud-based infrastructure. In one example, the results and outputs of the system and methods help remediate vulnerabilities across a wide range of vulnerability types because it can apply a comprehensive set of known vulnerabilities.

[0066] Another characteristic of the methods and systems taught in this paper is that they utilize processing assets distributed across cloud-based computing architectures in a cost-effective manner. Therefore, as the managed information systems grow, systems scalable according to this paper evolve inwards in a cost-effective and modular way. This is at least partly because the system relies on cloud-based processing resources that can scale up as the information system's needs increase and decrease when those needs decrease. Systems according to this paper also readily adapt to the addition of new computer infrastructure management, compliance, threat, vulnerability, and monitoring applications by supporting configurable and software application-based monitoring methods. This contrasts with known systems where single-point solutions for vulnerability management require specialized, expensive hardware and offer smaller suites of cloud-based system management applications.

[0067] Equivalent solution

[0068] Although the applicant's teachings have been described in conjunction with various embodiments, this does not mean that the applicant's teachings are limited to such embodiments. Rather, as those skilled in the art will understand, the applicant's teachings include various alternatives, modifications, and equivalents that may be made therein without departing from the spirit and scope of the teachings.

Claims

1. A method for multi-source cloud infrastructure vulnerability management, the method implemented by a network traffic management system, the network traffic management system comprising one or more network traffic devices, client devices, or server devices, the method comprising: receiving cloud element data related to cloud-based elements in a cloud environment; receiving first vulnerability data from a first vulnerability source; receiving second vulnerability data from a second vulnerability source, the second vulnerability source being a provider of a particular operating system; receiving cloud element context data from the cloud environment, the cloud element context data including the particular operating system with respect to the cloud-based elements; replacing the first vulnerability source and the second vulnerability source with a multi-source vulnerability database generated from both the first vulnerability data and the second vulnerability data, such that reported vulnerabilities from the first vulnerability source and separately reported vulnerabilities from the second vulnerability source are merged into a single generic vulnerability in the multi-source vulnerability database, wherein the single generic vulnerability includes a generic set of information ingested from the first vulnerability source and the second vulnerability source; evaluating the cloud element data and the cloud element context data using the multi-source vulnerability database to generate a vulnerability assessment related to the single generic vulnerability and the particular operating system; and generating a remediation step list in response to the vulnerability assessment.

2. The multi-source cloud infrastructure vulnerability management method of claim 1, wherein the vulnerability assessment includes a prioritized vulnerability list.

3. The multi-source cloud infrastructure vulnerability management method of claim 1, wherein the vulnerability assessment includes a list of vulnerabilities with associated severities.

4. The multi-source cloud infrastructure vulnerability management method of claim 1, wherein the vulnerability assessment includes aggregated vulnerability key performance indicators.

5. The multi-source cloud infrastructure vulnerability management method of claim 1, further comprising prioritizing the remediation step list.

6. The multi-source cloud infrastructure vulnerability management method of claim 5, wherein the prioritized remediation step list includes recommended software patches.

7. The multi-source cloud infrastructure vulnerability management method of claim 5, wherein the prioritized remediation step list includes software removal packages.

8. The multi-source cloud infrastructure vulnerability management method of claim 1, wherein the generating the multi-source vulnerability database from both the first vulnerability data and the second vulnerability data includes processing the first vulnerability data and the second vulnerability data to generate a generic vulnerability.

9. The multi-source cloud infrastructure vulnerability management method of claim 1, wherein the evaluating the cloud element data and the cloud element context data using the multi-source vulnerability database to generate the vulnerability assessment includes listing vulnerabilities specific to the cloud-based elements.

10. The multi-source cloud infrastructure vulnerability management method of claim 1, wherein at least one of the cloud-based elements includes a cloud-based computer.

11. The multi-source cloud infrastructure vulnerability management method of claim 1, wherein at least one of the cloud-based elements includes a cloud-based virtual machine. ​ 12. The multi-source cloud infrastructure vulnerability management method of claim 1, wherein receiving the first vulnerability data and / or the second vulnerability data from at least one of the first vulnerability source and the second vulnerability source comprises receiving vulnerability information from a Common Vulnerabilities and Exposures database.

13. The multi-source cloud infrastructure vulnerability management method of claim 1, wherein receiving the first vulnerability data and / or the second vulnerability data from at least one of the first vulnerability source and the second vulnerability source comprises receiving vulnerability information from a web page.

14. The multi-source cloud infrastructure vulnerability management method of claim 1, wherein receiving the first vulnerability data and / or the second vulnerability data from at least one of the first vulnerability source and the second vulnerability source comprises receiving vulnerability information from a file.

15. The multi-source cloud infrastructure vulnerability management method of claim 1, wherein receiving the first vulnerability data and / or the second vulnerability data from at least one of the first vulnerability source and the second vulnerability source comprises receiving vulnerability information from an OS-specific data source.

16. The multi-source cloud infrastructure vulnerability management method of claim 1, wherein the cloud element data comprises package data.

17. The multi-source cloud infrastructure vulnerability management method of claim 16, wherein the package data comprises a package type.

18. The multi-source cloud infrastructure vulnerability management method of claim 16, wherein the package data comprises a package version.

19. The multi-source cloud infrastructure vulnerability management method of claim 1, wherein the cloud element data comprises server data.

20. The multi-source cloud infrastructure vulnerability management method of claim 19, wherein the server data comprises a server type.

21. The multi-source cloud infrastructure vulnerability management method of claim 19, wherein the server data comprises data regarding server network traffic.

22. The multi-source cloud infrastructure vulnerability management method of claim 1, further comprising providing the vulnerability assessment to a user.

23. A network traffic management device comprising a memory having programming instructions stored therein and one or more processors configured to execute the programming instructions stored in the memory to: receive cloud element data related to a cloud-based element in a cloud environment; receive first vulnerability data from a first vulnerability source; receive second vulnerability data from a second vulnerability source, the second vulnerability source being a provider of a particular operating system; receive cloud element context data from the cloud environment, the cloud element context data comprising the particular operating system with respect to the cloud-based element; replace the first vulnerability source and the second vulnerability source with a multi-source vulnerability database generated from both the first vulnerability data and the second vulnerability data, such that a reported vulnerability from the first vulnerability source and a separately reported vulnerability from the second vulnerability source are merged into a single generic vulnerability in the multi-source vulnerability database, wherein the single generic vulnerability comprises a generic set of information ingested from the first vulnerability source and the second vulnerability source; evaluating the cloud element data and the cloud element context data using the multi-source vulnerability database to generate a vulnerability assessment related to the single generic vulnerability and the particular operating system, and generating a remediation step list in response to the vulnerability assessment.

24. The apparatus of claim 23, wherein, the one or more processors are further configured to execute the programming instructions stored in the memory to receive the first vulnerability data from the first vulnerability source and the second vulnerability data from the second vulnerability source.

25. The apparatus of claim 23, wherein, the one or more processors are further configured to execute the programming instructions stored in the memory to evaluate the cloud element data and the cloud element context data with the same one of the one or more processors.

26. The apparatus of claim 23, further comprising the first vulnerability source and a second vulnerability source.

Images