System and method for trustworthiness, reputation, provenance, and measurement of software
In accordance with some embodiments, a method and system for establishing the trustworthiness of software and running systems by analyzing software and its provenance using automated means. In some embodiments, a risk score is produced. In some embodiments, software is analyzed for insecure behavior or structure. In some embodiments, parts of the software are hardened by producing possibly multiple different versions of the software with different hardening techniques applied, and a choice can be made based on user or environmental needs. In some embodiments, the software is verified and constraints are enforced on the endpoint using techniques such as verification injection and secure enclaves. In some embodiments, endpoint injection is managed through container orchestration.
This is a continuation of and claims priority and benefit to patent application Ser. No. 16/858,668, filed Apr. 26, 2020 by the present inventor, which further claims the priority and benefit to provisional patent application Ser. No. 62/839,595, filed Mar. 26, 2019 by the present inventor, the entire content of which is hereby incorporated by reference.
BACKGROUND OF THE INVENTION 1. Field of the InventionThe present invention relates to the field of evaluating software systems and individual software instances for security risk, collecting the provenance of that software, hardening those systems, enforcing strong protections on the endpoints of execution, and ensuring trustworthiness.
2. Description of the Prior ArtEnsuring that the software running on a computer is trustworthy and unmodified is an important goal in our times, where adversaries have shown unprecedented ability to deliver attacks into vulnerable code and vulnerable systems. Attackers can leverage bugs to modify executable memory, thus introducing new code into an existing system. Or they can overflow data areas, allowing modification of the stack—and crucially, the return address on the stack—or heap to construct jump- and return-oriented programming that can usually execute arbitrary instructions without modifying the data. Or they can work in the supply chain itself, modifying code by introducing bugs or vulnerabilities that they know how to exploit, or simply insert bad logic into the program. Open-source projects are particularly vulnerable to this sort of malfeasance.
This has been an area of active research, including by the present inventor: see U.S. Pat. Nos. 8,932,226; 9,747,172; 9,535,855; 9,336,383; 9,229,881, and so on, all of which disclose methods for creating and providing enforcement of the integrity of systems, including the use of hypervisors for security. In general, existing solutions today to integrity are based on primarily static information, and thus do not accommodate a changing threat landscape and greater knowledge about particular vulnerabilities in particular software assets. One such existing solution is that of integrity measurement. The idea is that a particular software image is signed, usually using a precise certificate authority infrastructure instance. Then if anyone tries to modify the signed image, the signature won't pass. This signature is checked on software load. Monolithic load-time signatures like that have some value, but if the software is already vulnerable, as it is in many cases, locking down that software and enforcing that particular version merely ensures that the vulnerabilities must, undoubtedly, be loaded into memory. Specifically, the system has no idea of the trustworthiness of the software to be loaded. The software may already possess malicious behavior, perhaps through supply chain attacks on the trusted code base. Or perhaps the software is vulnerable to modification. The integrity measurement happens at load, not later: instead, the system usually relies on some sort of assumption about who can access the memory once verified, assumptions that are often violated in practice. For example, with secure enclave systems, the software is loaded into encrypted memory, which is then decrypted upon appropriate entry into the enclave. The integrity measurement occurred at the construction of the enclave. This is fine, until the enclave's software vulnerability is hit that forces it to modify its own executable code or code pointer tables. Moreover, if the code was statically linked—as it often has to be to run in that environment—but otherwise has a function pointer dispatch mechanism, the function pointers can be overwritten. Other systems have continuous integrity enforcement that applies to a whole image, but this is again of no help for already malicious or doubtful software, and also now, because those methods are insensitive to the fine-grained programming model, it sets requirements on the language facilities and the loading/linking of programs: continuous integrity may require statically or lightly dynamically linked software only, and thus not operate for larger applications or environments. Furthermore, in the past, the only pragmatic access to hooks for performing runtime verification were in the hypervisor (such as a binary translating hypervisor or using hardware page table hooks). Now, however, modern hardware allows for techniques such as non-executable memory to be controlled by the operating system directly, and to be requested by userspace applications for their own memory.
Moreover, it has been very difficult to produce until now a workable metric of the security of software. The assumption is mostly that some security is layered onto it, and that that amorphous security is somehow additive: much as two piles of sand merge into one bigger pile of sand, the degree or amount of security or protection of a system has been assumed to be an uncountably additive quantity. And yet, there is a precise and real need for the degree of security to be measured and compared. Users want to know what percentage of their runtime code has been verified, how strong the verification is, and what the likelihood of vulnerabilities throughout their deployments.
The solution is to be able to provide integrity, reputation, trustworthiness, coverage, and risk analysis, so that the endpoint enforcement mechanisms have enough information to go on to adapt to the changing landscape. Such an invention is disclosed below.
SUMMARYIn accordance with some embodiments, a method and system for measuring the risk of executing software and systems composed of that software, based in part on the provenance of the software, automatic code analysis, threat information, the practices of the organizations and people behind the software, and the enforcement posture of the software.
This analysis 160 is then connected to execution. An application installer 100 procures software 120 from a software provider 110 and installs it. At some point—such as when the software is installed or when it is executed—a verifier 130 verifies the software 120 by requesting from the stored analyses 160 to find a match and then verify that the match is correct. If the match is correct, the system can proceed to execution 150. If not, the system will be directed through error or remediation proceedings 140 to rectify the problem.
A provenance analyzer 250 analyzes the installation process (dashed lines are to avoid visual conflict with solid lines) and creates records 285 attributing the ultimate installed as-if-deployed files and other modifications to the package and provider. In some embodiments, the provenance analyzer endeavors to gather as much information about the provenance of the files or changes as possible.
For each of the items it is possible to capture contributors and influencers 340 and their attendant organizations. For example, in an open source project, this captures the identity of the person who committed the change, and who that person works for or ever has. The goal in those embodiments is to capture a portrait of the people who have contributed to the changes, projects, or other elements of the provenance: basically, to capture the fingerprints along the supply chain. In some embodiments, the individuals 345 are tagged to their organizations 355 with when they started, how long they were involved, and the quality or degree of relationship during one or more intervals. In some embodiments, the individuals are identified to their past and current “resumes”, such as LinkedIn or other social media profiles, press releases, quotes, speaking listings, or other available information identifying the person to the organization. Organizational relations can be fluid and indistinct at times: a person may be employed with one organization, contributes in their spare time to another, and an advisor to a third group, for example. In some embodiments, the nature (and/or degree of certainty of knowledge) of the relationship is maintained. This multiplicity of relationships is important, and the publisher is likely of the same type as the organizations in the Influences box. This actually allows for a complex web of relationships to be captured: which organization influences which project, and how: be it common or overlapping contributors, employees, etc. Commonalities 350 includes these overlapping relationships, in some embodiments: picture that the same people attend the same conference five times a year; the commonalities in some embodiments is then a database entry representing the conference, joining it to the project, and then joining it to the list of individuals and companies who have attended. Furthermore, among the influences can be the processes 360 that the project or element within used, which may include without limitation: the specification process, the architecture and design processes, the paradigms used in the design and implementation (such as modularity, code boundaries, abstractions, modes of development and operation, execution paradigms such as separation of privileges, shared memory, enforcement techniques, compilation methods, protections for security, and so on), the existence and quality of any formal proof or code verification (especially for cryptograph algorithms or other critical infrastructure), the nature and degree of code review (including process gates, regression testing, and so on), the experts who have qualified the parts of the system and their assessments, bug and exploit reports (including the quality of the processes and statistical analysis of the reports and their tie ins to contributors), the build processes (including the independent and dependent metrics of the steps of the processes), and the quality (such as accessibility and vulnerability) of the storage of the images (including both the technical storage the applications use as they operate, as well as the storage of the builds themselves by the suppliers and the weaknesses or strengths in the image supply chain). Furthermore, the openness or transparency of 370 of organizations or people, and the social and relational qualities 380 can be stored. These influences, like the others, can have their own reputation, risk assessment, quality assessment, and other metrics attached.
In some embodiments, this information is used in manual remediation, in determining how a vulnerability or malicious behavior entered into a project, and thus capturing the forensics of the people who touched the project and how. Databases such as the one just disclosed can capture the entire “blame” analysis of every line of code of an open source project and how it came to be vulnerable. When tied in with an observed vulnerability, this database can make the forensics much cleaner and faster to perform. Therefore, in some embodiments, most elements of the provenance database in
Some embodiments don't use explicit propagation to assign or update the reputations, but use artificial intelligence. In some embodiments, the calculator has an AI engine. Some embodiments do this by using an adaptive machine learning algorithm (such as a neural network), where the input is the previous reputations on its graph and the new information, and the output is the new reputations. One possible value in using machine learning in this way is to allow iterative refinement of the recurrent data set. The data in such a graph can be tremendously large if collected well, and can include lots of older information. It may be difficult, depending on the data set and the environment, for people with deterministic tools to wade through such a graph and learn when certain signals matter and when others don't. The algorithm in use is applied piecemeal, in some embodiments. In some, the algorithm is focused on one domain at a time (such as a project): a preprocessing step may be performed to abstract out relevant information for the training of or decision from the network, such as flattening the list of contributors and assigning preprocessing contribution scores, instead of exposing the algorithm to each contributor list tied directly to each changelist. (Neural networks are not naively good at graph traversal, which is why a more deterministic preprocessing step can help produce better information for the network to absorb.) These one (or some) at a time steps are then be performed by some embodiments per project(s), for example as above, until the network is filled. Afterwards, a subsequent propagation step can be performed to resolve inequities or conflicts in the output data, to make it coherent. This too may be by using a neural network or learning algorithm. By doing it piecemeal, the training can be done multiply on individual domains (the projects in the example) rather than all at once on the domains together. A possible tradeoff depending on the implementation, as anticipated above, is that the outputs can produce disagreement on joint relationships between the domains (which can be resolved as above with a further pass), but the training ability and parallelizability are often superior. One embodiment explicitly uses projects as the domain. Some embodiments train the algorithm on open source projects by processing each one through a training session. Some embodiment uses supervised training, by correlating known forensic or intelligence reputations for entities with such an opinion available.
The second half of
The application 500, (a loadable binary and/or its dependencies, package structure, and container) is “loaded”, in quotes because it may not be used operationally as a program and thus may have its loading state simulated—especially for just in time dynamic linking—by a specific analyzer loader 510 that is capable of producing at least a partial memory image or virtual image 520 for use by analyses. This loaded image 520 is then measured by a measurer 530 to produce a measurement 540. The possibly simplest measurement is, as mentioned at the top, raw static measurement, where the in-memory footprint that is known to not be stack or heap is hashed, and the hash compared with the signed hash of the expected measurement. As mentioned before, though, this only works for completely static, nonrelocatable code. A loader's job is to often modify the code on its way into memory, by processing relocation entries. Relocation entries can result in runtime linkages through a jump table: a dynamically written table, often containing memory indirect jumps where either the code for the jump or the memory indirection is modified when the symbol is resolved. Thankfully, more modern specifications have removed most relocations from the static code itself, and have replaced them with packed data tables that contain the relocations. This means that the relocation data tables are more important than ever to measure.
A code measurer 640 measures the static code 615. Since static code itself never changes, the regions can be individually measured by a cryptographic hash. This is per region in some embodiments; in some embodiments there is only one hash that is produced when the order can be determined in a fixed manner (such as alphabetically by region then image name without regard to how the images are loaded in memory by ASLR or other randomizers), encompassing multiple regions.
A linking measurer 645 measures relocation or linking tables or other portions of linking regions 620. Relocation entries stored in the binary provide for the locations of the linking entries. Most compilers and language/platform specifications now require that the dynamic linking tables are data tables, which are indirectly jumped to. (The indirections are not always the most efficient, and often look like a relative call to a memory indirect jump, depending on the platform.) Therefore, in most systems, it is sufficient to measure the symbolic (or ordinal offset) relocation tables present in the application, and perform out-of-band “relinking” based on the actual runtime segment relocations. In some embodiments, the library being linked to is also connected to the measurement with its own measurements, containing the exports from the library that this or other target binaries use. This allows not only for indirect linking table's layout to be measured, but for the destination location be fully measured to make sure that it is in fact the named function at that location. More on this in the description of the verification. In older systems or systems that do perform runtime code patching, awareness of that fact is needed: sadly, there are some “optimization” modes that allow for these indirections to be overwritten by the dynamic loader for a minor performance improvement. This is seen in some versions of the Linux kernel, for example, which uses more of a “.o” style linking than a “.so” style with PLTs when it can.
A fixed data measurer 650 measures the static fixed data 625: this can also be done in the manner of the fixed code. In some embodiments, the fixed code 640 and data measurer 650 is the same, and all fixed segments are measured without regard to their being code or data.
Debugging data 635 tends to be similar to relocations. It is measured by debug measurer 660, which often performs the measurement similarly to linking measurer 645. In most cases it won't even matter: debugging information is usually marked as not loadable, and so measuring it is static and also not a problem for running programs.
An initialized data measurer 655 measures initialized data regions 630, and is more complex in many embodiments. It is not generally possible to police the modifications of initialized data segments 630 without running the original logic (a variation of the halting problem). However, it is possible to gate the accesses, or to provide further validation logic through extra symbolic or compiler-process analysis of the code. Gating accesses to data is known in the art: in general, it involves ensuring through reachability analysis that only code that can access that data provably at runtime accesses it, or at least that code that is provably unable to access the data be prevented from accessing it. The problem is that pointer-arithmetic languages cannot be generally subject to this analysis, and so this becomes a somewhat more language specific effort. That being said, there is value to deeper compiler or binary analysis, especially on the determination of reputation.
In addition, the individual steps of compilation can lead to additional analysis. The compilation steps usually involve a front end 710, which produces an intermediate representation 715, a back end 725 that reduces the intermediate representation 715 (or post optimization) to assembly 730, and then to an assembler 740 which emits machine code such as in a binary object 745. Each step has certain constraints that can be inspected. The source code 700 can be analyzed by a source code analyzer 705. The intermediate code can be analyzed by an intermediate analyzer 720. The linker's results can be analyzed by a linker analyzer 765. One such analysis is of the production of linking tables. The assembly 730 can be analyzed by an assembly analyzer 735. One such analysis is performed on a normal symbolic call presented to the assembler—a “call symbol” sort of pseudoinstruction. The assembler produces the basic call with static relocations encoding the symbol as mapped to the linking library for the shared object. The linker converts the static relocation for the symbol, which itself is a standard production of the linker when asked to compile a shared object. These are filled with structure that can be measured and validated, even in the blind without knowledge of the particular destination locations. Some embodiments match the pattern of the GOT/PLT or IDATA/RDATA tables, looking for known compiler output formats and valid ranges. Again, the purpose is to assess whether the structure of the code departs from the known and safe structures, not to determine if it has been modified per se, which will already have been determined by measurement. Some embodiments assess how out of the ordinary, or how unsafe, the compiler's output is.
Some embodiments compare the number and type of safe practices, unsafe practices, and/or suspect patterns (among other things) to help develop the partial or total risk score 865. Some measure one or more of indirect table jumps, modifiable code, linker patterns, library or dependency risk, system call patterns or usages, library call patterns or usages, timing requests, novel or specific CPU instruction patterns (such as new or unproven extensions), hand-assembled code, the choice of language or languages used (some are more safe than others), the use of compiler or build procedures or flags (including but not limited to security extensions, bounds protection, heap protection, stack protection, ROP protection, ASLR or randomization flags), library or dependency risk, execution strategy (such as number of threads, concurrency, locality or remoteness), networking or communications strategy (such as shared pages, UNIX sockets, local or remote IP sockets, Bluetooth, Wi-Fi, and their patterns or flags). Some embodiments develop this understanding through source or binary analysis which can be done statically. (For example, determining what sockets a program uses can be determined by inspection: the source makes it obvious, but even with the binary simple static analysis can determine what the flags and preconditions are on the binding and endpoint addresses.) In some embodiments, symbolic analysis is performed. In some embodiments, dynamic analysis is performed: this can be as simple as a coverage measurer hooked to the package publisher's or third-party's or our own generated test/coverage harness, which then partially determines one or more of statistical properties, behaviors, analytic provable properties (such as that the address is always masked to its broadcast address), or an inventory of behaviors. This sort of analysis can generate a powerful understanding of the behaviors and risks that an application may entail. Also, to repeat, some embodiments combine or perform analysis across the multiple binaries that make up an application, such as its dependencies, underlying system state, and package or container. Some embodiments direct further scrutiny to areas of code influenced by reputation, risk, and provenance (such as using a range table specifying the minimum degree of analysis for a given risk level of the contributor or a rollup of the contributor and influencers for a range of code, with degrees being assigned to each analysis method or submethod such as by an expert.)
In some embodiments, a rule rollup 850, such as those specified by a table, defines how the categories weigh in a total score. Some embodiments use a hierarchical longest-match category named patterns, assigned to a per-parent fraction. For example, a category named “linking:known_patterns” might be assigned 20% of the “linking” category; this means that the sum of all “linking:known_patterns:*” except “linking:known_patterns:_” divided by “linking:known_patterns:_” is weighted to 20% of the value of “linking”; furthermore, when a match is made m is added to “linking:known_patterns” and M is added to “linking:known_patterns:_”, and n is added to “linking:known_patterns” and N to “linking:known_patterns:_” when a part of the data fully fails to match. Some embodiments track the amount of coverage achieved, and instead can produce a weighting not based on N or M but by default weighted to the fraction of bytes covered per category versus expected, with n normalized on its own after reporting the bytes covered by the rule. Of course, rollups can be more general, as they can produce the synthesis of the individual risk versus coverage metrics.
Risk scores produced do not themselves need to be a direct output of a rollup: they can be any arbitrary function whose inputs can comprise any one or more of—and are not limited to-one or more rollups, individual rules, weightings of the rules, the type of rules, the degree of match of a rule (especially for when the rules engine is fuzzy matching), the composite of the type of rules, manual or automatically learned triggers of combinations of the rules, comparisons to peer applications by any means (including developing a statistical background of how many of a rule or of what distribution of the rule exists across the peer applications, and then using a threshold, continuous risk function, trigger/high-watermark mechanism, or arbitrary function to assess the program in light of its peer statistics).
One added possible advantage about analyzing the source for the binary build itself is that further security, risk, and behavioral constraints can be extracted from the source code than from the binary. Source code analysis such as in
As you can see, the above anticipates a runtime enforcement mechanism for overlaid constraints and enforcements, which will be discussed later. However, there are some additional methods for protection which use compiles, used by some embodiments.
In the above cases, it is not a requirement that the hardening be performed project wide. Some embodiments map the choice of hardening techniques to different regions, different files, different outputs, different modules, or different logical groupings of code, such as based on the needs of the user, the risk of the different parts of the code being hardened, or the difficulty in processing the parts of code.
The work need not be limited to the source code. As mentioned above in regards to risk and constraint analysis on the binary (such as the contents of
Moreover, there is no requirement that all applications (binaries or installations) are of the exact same codebase. Even though some embodiments access the catalog by keying off of the binary, the package, the package name, or other identifier, the results of the catalog can contain different software behaviors. In some embodiments, catalog entries contain bug fixes or vulnerability patches to the software: this would normally result in a nominally different version of the software, but so long as feature compatibility is reasonably maintained, such a difference may not matter. What patches are applied and how can be chosen by administrative preference, risk tolerance such as by the user (for example, critical patches might be applied to some or all entries but noncritical ones might not be), or automated criteria, among other things. In substitution environments, for example, this allows for patches to be dropped directly into the substituted environment.
So far, it's been made clear that the analyses can apply not just to one binary but to the collection of binaries and attendant dependencies that make up an application, a package, a container, or filesystem or VM. Some embodiments work at the level of the container or package, and create databases indexed on those containers or packages, such as in
Again, the location of the analyzer is dependent on the embodiment. Some embodiments collocate an analyzer with a verifier, allowing local analysis (such as local binary editing, substitution, measurement, and rollup). Some use a remote analyzer. Some use an offline analyzer. Some use a blend of the above.
The disclosure so far has mentioned a number of different metrics for security and how they can be produced. Reputation is a measure of the trustworthiness (or corruption or corruptibility), and can be applied to among other things the software, to the techniques with which it was built (including development and code writing processes as well as the compilation tools), the people who built it, contributed to it, advertised it, helped it, and so on. (See above for more). Risk can be a part of the reputation metric, or it can be represented separately, identifying—depending on the desired risk metric—intrinsic vulnerability potential of the actual code, or its supply chain, for example. Coverage represents how much of the software, or the supply chain, was analyzed and how much may be unknown still. Value or criticality is a measure of how important the software or its data may be, and may take into account local determinations as well as the determination and metric of the data or applications within. All of these metrics can change over time for the exact same instance of software, as more knowledge is gained.
These metrics can all be, and often do start out as, fine grained for individual analysis “atoms” (which can be provenance elements, installation atoms, code elements, risk elements, and so on). There is value in rolling up these items into metrics representing assemblies of these parts. A rollup scheme was already disclosed for some embodiments representing risk within a binary or installation. The same types of procedures can be employed to create rollups or summaries for assemblies of installations, of binaries, of machines, of networks, and of entire deployments. Some embodiments use rules-based or function-based mechanisms—such as what was disclosed for a binary—to produce rollups for these assemblages. Some embodiments—especially those focused on metrics that can be expressed as likelihoods or probabilities—use a Bayesian network to express the total likelihoods, risks, or reputations of an assembly. Risk that an actor is bad, for example, can be expressed as global probability that the actor is bad: this can be a Bayesian probability assessing our knowledge about the badness of the actor, or it can be a frequentist probability that an inconsistent actor (most are) introduces vulnerabilities, or it can be a mixture of both or something else. Some embodiments derive probability or likelihood values from past history—such as making a frequency measure of vulnerabilities associated with contributors or their associations—to produce a frequentist metric. Some embodiments capture the degree of belief, such as based on intelligence reports or expert assessments: for example, a number can be assigned to a country or its political or military arms based on theoretical assessment. These numbers may not be absolute: one possible advantage of embodiments that encode these as likelihoods (or distributions or +/−likelihoods) is that the base rate of incidence may not need to be known to understand the network effects of the conglomeration of the parts in the joint metrics. In base-rate-free metrical analyses and rollups, some embodiments provide the user with a mooted base rate for point of explanation, such as on a slider from 0 to 1 to explore the base rate risks. Some embodiments ask the user an inventory of questions, be they static or dynamic (as in based on available data as well as based on previous answers), such as “How likely do you feel your systems are to being an attractive and high value target of an attack”, to help determine the network of possible base rates. These inference networks are constructed from the available data, in some embodiments using discrete likelihoods/probabilities and in others using discrete or continuous distributions. For example, the entire supply chain can be evaluated from specific items to produce a likelihood or probability impugning each particular application of a system.
Some embodiments create from the assemblage a hierarchical rollup of metrics (be they risk, reputation, coverage, and so on). Some embodiments employ hierarchies such as shown in
In some embodiments, the page manager is the operating system (kernel) page manager, with hooks added to access the verifier. More specifically, in some embodiments the kernel is modified to allow a program or security supervisor to register page management hooks. In some of those and some other embodiments, the page manager maintains a shadow page table for representing the state that the underlying page manager wishes to see, separate from the real pages. In some embodiments, the page manager is a proper overlay page manager, intercepting page management and fully maintaining shadow pages. In some embodiments, the page manager uses a separate hardware page table scheme: some further embodiments activate the hardware hypervisor page tables and allow the OS page manager to not be modified. Some further embodiments do not use virtualization for any other purpose, and merely register the verifiers in a rump hypervisor dropped in for purely this purpose. These sorts of rump hypervisors can be loaded as kernel modules or as a part of the kernel itself, and slip below the kernel in the CPU execution stack by virtue of the creation of the mechanism. (KVM, a full hypervisor on Linux, classically starts as a rump hypervisor declaring the kernel to be the root domain, before losing its rumpness by exposing full virtualization support to the user.) In some embodiments, the rump hypervisor claims the root virtualization domain, and forces the operating system that loaded it into a child domain. In some embodiments, the page manager is integrated into the root hypervisor of a full virtualization system (such as Xen or KVM). One possible advantage of the embodiments which use the rump virtualization, and the ones that use the shadow tables, is that they can retain the modularity and behavior expected of the underlying system while allowing for the extra page interceptions needed for verification in those embodiments. Moreover, virtualization is no longer as popular a strategy for software deployments, as system administrators and developers have moved to containerization as a far lighter-weight same-system technique to separate workloads and avoid workload interference: depending on the environment, this can either free up the hypervisor CPU support for security purposes, or suggest not to use hardware virtualization support and rely on software hooks. Therefore, in some embodiments, the page manager runs underneath or in concert with a container-enabled kernel (such as some of the ones which support Docker implementations). In some embodiments, the container or its metadata contains the references for the verifier to properly identify the material needed to perform the verification; in some embodiments, the material is retrieved from a local or remote repository or service as appropriate for the container in use. In some embodiments, the container itself has a verifier (in addition to that of the underlying kernel infrastructure, or separately depending on the type of verifier in use—some embodiments of page runtime verification require kernel support). In some embodiments, the container verifier and the system verifier communicate: in some embodiments, the system verifier verifies the container verifier; in some embodiments, the system verifier verifies the entire container on behalf of the container verifier, such as when the container verifier asks the system verifier to perform that work and provides the material or references sufficient for the system verifier to access the material; in some embodiments, the container verifier does the bulk of the work but asks the system verifier (or a smaller system driver that does not itself perform verification) to instrument the system as needed. For example, in a container environment where the system kernel possesses container-accessible hooks for page table manipulation, the system itself may not need to have a verifier and the container verifier will perform its verification as if it had direct access by using those hooks.
Some embodiments use mmap/mprotect and the signal handling processes within an application to perform its verification without requiring unique kernel registration procedures, such as in
Some embodiments perform external application verification, such as shown in
Some embodiments perform supervision in a secure enclave, such as shown in
Some embodiments carry the root of trust further and provide for attestation of the verification of the system.
In some embodiments, the hardware itself checks for, expects, or demands that a verifier be in place. The hardware root of trust, before turning execution over to the software at the execution point, measures and ensures that the verifier is present and matches the integrity demands it has for the verifier (or verifiers). In some embodiments, the verifier writes into hardware a list of verification certifications, in some cases containing the coverage, results, and provenance or chain of certifications of the material used for verification (or constraining or substitution); some further embodiments use that for execution decisions, and some embodiments provide additional attestation services assuring the recipient that the system has the verifiers in place. Some embodiments have the hardware enforcing the verifier's operation (such as locking down the verifier's memory, like in an enclave). In some embodiments, the hardware and the verifier or verifiers have handshakes they perform, such as to ensure that the verifier is operating properly and has verified the system as appropriate and that the verifier can determine that it is on the appropriate hardware.
In some embodiments, the verifiers are not pure software but themselves have some of the verification performed in hardware. Some embodiments allow the CPU, MMU, or on-bus security module to be entered with specific integrity demands for certain memory regions. This can allow for greater performance, as for example page verification on first execution can occur much quicker as the memory is transitioned across the bus into the CPU cache, or within the CPU cache by an on-chip verifier, than for software to have to populate the first level cache lines with the memory being verified at once, thus not only robbing the CPU of instruction time for other purposes but also possibly creating cache churn or thrashing. In some embodiments, the integrity demands are registered with physical, logical, or virtual addresses or page addresses and either implicit or explicit bounds (such as a second address or count of bytes, instructions, or pages), along with the expected measurement. Some further embodiments represent the measurement by a cryptographic or secure hash; some include a bitmask (linear or compressed) of bits that are to be masked to a known state (such as 0) and thus disregarded in the calculation of the hash. Some embodiments take permissions for regions of memory, and enforce those permissions: an MMU, for example, can execute explicit permissions for regions in many cases, and this is used in some embodiments to handle memory segmentation. Some perform constraint verification instead, using a hardware constraint database, such as one containing memory locations and the logic to execute. Some embodiments snoop the bus and cancel any transactions that are in violation of the integrity or constraint demands, or roll back the transactions. Some embodiments perform this snooping by using a dedicated CPU core on chip, or a separate CPU on bus or somewhere in the cache hierarchy. In some embodiments, the hardware enforcement is limited to a software verifier, which then verifies memory. In some embodiments, an MMU (such as an IOMMU that has switchable domains tagged to the CPU execution domain) is used to divide off verifier memory.
Furthermore, some embodiments use cyclical verification, such as shown in
Some embodiments are capable of performing substitutions. A substitution is a modification of the runtime environment by changing or replacing part or all of the code or files.
Because many embodiments depend on cryptographic functions, the ability of a system to provide a good source of randomness may be necessary. However, the existing random generation techniques tend to have limitations. Pseudorandom number generators often suffer for a lack of sufficient entropy, or for leaking information. Hardware random number generators are often sensitive to the environment: quantum diodes can depend on externalities such as temperature.
The analyses disclosed above are provided by some embodiments at least in part as a service across a network, interconnect, or IPC; some embodiments have analyzers collocated with one or more verifiers. Some embodiments of the analysis service may be operated in a cloud environment, or on premises, or a mixture of both. As a service, the analysis can operate in a range of execution duties, from as needed to occasional to triggered to continuous, refining the analyses as needed.
Some embodiments integrate into orchestration, such as shown in
In some embodiments, the verifier retains a channel to the orchestrator. Upon an error or remediation, in some of these embodiments, the verifier's remediator asks the orchestrator to refresh/dump and recreate the workload. This may be useful in cases where the workload has been compromised and the compromise has been detected, and now healed. In some embodiments, the workloads' reputation and risk scores are taken into account when determining whether to allow a deployment or to allow a deployment in the specific place: for example, some organizations may request that a highly risky workload not be placed on the same overlay network, or on the same physical network, or in the same microservices domain, or in the same physical node as a more critical workload. In some embodiments, the underlying host is also measured and analyzed. In some embodiments, the host analysis is used in the determination of whether a workload can be placed on that host or not. For example, some embodiments will not allow a high value workload to be placed on a vulnerable or poor reputation host.
This disclosure requires familiarity with the state of the art in software and risk analysis. Terms like “detect” and “infer” are not necessarily absolutes, but may also refer to the increase in a determined value (such as likelihood or probability) or an increase in its confidence.
Throughout this disclosure, multiple specific embodiments are listed that may be extensions of more general embodiments. It is to be understood that the combinations and subprocesses of these embodiments are also taught by this disclosure, as the combinations and subprocesses are able to be anticipated by those skilled in the art upon and only upon reading this disclosure. Furthermore, uses of the plural or the singular do not restrict the number of the item being mentioned: unless explicitly called out as not being so or being logically inconsistent, mentions of singular items are to be construed to also be plural and vice versa.
In the description herein, one or more embodiments of the invention are described, with process steps and functional interactions. Those skilled in the art would realize, after perusal of this application, that embodiments of the invention might be implemented using a variety of other techniques not specifically described, without undue experimentation or further invention, and that such other techniques would be within the scope and spirit of the invention. The use of the words “can” or “may” in regards to the structure and operation of embodiments is to be construed as referring to further embodiments and configuration options, and does not require further experimentation or invention. The scope and spirit of the invention is not limited to specific examples disclosed therein.
Although the invention has been described with reference to several exemplary embodiments, it is understood that such descriptions and illustrations are not limiting. Changes may be made within the purview of the appended claims, as presently stated, without departing from the scope and spirit of the invention in its aspects. Although the invention has been described with reference to particular means, materials, machines, and embodiments, the invention is not intended to be limited to the particulars disclosed; rather, the invention extends to all functionally equivalent structures, methods, machines, and uses such as are within the scope of the invention and claims.
Claims
1. A method for monitoring the security of software comprising:
- a. receiving, from a software provider associated with a first electronic device over a communication network, by a second electronic device in a cloud environment, a database of software to protect wherein the database of the software at least in part comprises at least one of: an application program executable, source code, a script, just-in-time compiled software, a software package, a distribution, an installer, an archive, and a repository;
- b. downloading, by the second electronic device, an instance of software entered in the database;
- c. installing, by the second electronic device, the instance of software;
- d. performing, by the second electronic device in a cloud environment, software analysis on the software instance for its security properties;
- e. producing, by the second electronic device in the cloud environment at least one part of a hardened version of the software instance, wherein the hardened version is produced at least in part using at least one of a binary translator, a compiler, a linker, and a build system;
- f. collecting from a user or an administrator configuration information that determines at least in part a degree or type of security of the hardened version of the software;
- g. transmitting, over the communication network, the hardened version of the software to the user associated with a third electronic device,
- h. using the monitored environment to modify execution of the software instance by at least one of: substituting in memory at least a part of the software instance under execution with at least a part of the hardened binary version of the software instance, and issuing traps or breakpoints for the running software instance wherein execution is intercepted and modified from that of the running software instance according to the hardened version,
- i. executing, in the third electronic device, the software instance in the monitored environment;
- j. verifying aspects of the execution of the software instance within the monitored environment; and
- k. collecting from the monitored environment information regarding the operation and verification of the execution of the software instance.
2. The method of claim 1 wherein the software analysis comprises at least in part at least one of: static code analysis, binary analysis, symbolic analysis, code flow analysis, compiler output pattern matching, linker output pattern matching, type analysis, reachability analysis, value analysis, execution and dynamic analysis, and continuous analysis.
3. The method of claim 1 wherein the monitored environment is produced by at least one of: injecting a verifier into the address space and running context of the running software instance, running the verifier in a secure enclave within the address space of the software instance, running at least part of the verifier within the kernel underneath an application to be verified, using kernel tracing from a separate verifier application, and modifying a container containing the software instance to also produce the constructing of the monitored environment.
4. The method of claim 1 wherein the choice of the hardened version is made at least in part based on at least one of: the desired protection level, the efficiency implications of the hardening, and the environment the software instance is executing in.
5. The method of claim 1 comprising further steps of:
- a. producing constraints on the behavior of the software instance from the software analysis; and
- b. enforcing the constraints on the behavior of the software instance in the monitored environment.
6. The method of claim 1 comprising further step of producing a risk score based at least in part on the software analysis and the information regarding operation and verification of execution of the software instance.
7. The method of claim 6 wherein the risk score is further based at least in part on the software instances's provenance comprising at least in part at least one of—the identities, makeup, reputation, and trustworthiness—of at least one of: the publisher of the software, the project the software belongs to, the version of the software, the files of the software, changes that have been made to the software, people working on the software, organizations involved with the software, organizations to which the people working on the software belong, the relationships between people involved with the project, relationships between organizations involved on the project, relationships between people and organizations involved on the project, processes of the software development, and the openness of the development.
8. The method of claim 6 wherein the risk score is produced at least in part from metrics on at least one of: an install atom of the software instance, a package of the software instance, a local application of the software instance, local system the software instance is on, a container of the software instance, an operating system running the software instance, a virtual machine of the software instance, a hypervisor running the software instance, hardware running the software instance, a network the software instance is connected to, and context of the deployment of the software instance.
9. The method of claim 6 comprising further step of attesting to the trustworthiness of the software instance based at least in part on at least one risk score for the software instance running including any constraints and execution modifications.
10. The method of claim 1 comprising further step of: attesting to the trustworthiness of the software instance based at least in part on verification of the software instance.
11. A system for monitoring the security of software comprising:
- a. a software provider associated with a first electronic device;
- b. a second electronic device in a cloud environment connected over a communication network to the first electronic device;
- c. a database of software from said software provider wherein the database of the software at least in part comprises at least one of: an application program executable, source code, a script, just-in-time compiled software, a software package, a distribution, an installer, an archive, and a repository;
- d. an instance of software downloaded, entered in the database, and installed by the second electronic device;
- e. a software analyzer that performs on the second electronic device in a cloud environment software analysis on a software instance for its security properties;
- f. a hardener that produces on the second electronic device in a cloud environment at least one at least in part hardened version of the software instance, wherein the hardened version is produced at least in part using at least one of a binary translator, a complier, a linker, and a build system;
- g. a third electronic device that receives over a communication network the hardened version of the software for a user;
- h. a collector that collects from the user or an administrator configuration information that determines at least in part a degree or type of security of the hardened version of the software;
- i. a monitored environment on a third electronic device executing the software instance that modifies execution of the software instance by at least one of: substituting in memory at least a part of the software instance under execution with at least a part of the hardened binary version of the software instance, and issuing traps or breakpoints for the running software instance wherein execution is intercepted and modified from that of the running software instance according to the hardened version;
- j. a verifier on the third electronic device that verifies aspects of the execution of the software instance within the monitored environment;
- k. a collection from the monitored environment of information regarding the operation and verification of the execution of the software instance.
12. The system of claim 10 wherein the software analysis comprises at least in part at least one of: static code analysis, binary analysis, symbolic analysis, code flow analysis, compiler output pattern matching, linker output pattern matching, type analysis, reachability analysis, value analysis, execution and dynamic analysis, and continuous analysis.
13. The system of claim 10 wherein the monitored environment is produced by at least one of: injecting a verifier into the address space and running context of the running software instance, running the verifier in a secure enclave within the address space of the software instance, running at least part of the verifier within the kernel underneath an application to be verified, using kernel tracing from a separate verifier application, and modifying a container containing the software instance to also produce the constructing of the monitored environment.
14. The system of claim 10 wherein the choice of the hardened version is made at least in part based on at least one of: the desired protection level, the efficiency implications of the hardening, and the environment the software instance is executing in.
15. The system of claim 10 wherein the software analyzer produces constraints on the behavior of the software instance, and constraints on the behavior of the software instance are enforced in the monitored environment.
16. The system of claim 10 comprising further a risk analyzer that produces a risk score based at least in part on the software analysis and the information regarding operation and verification of execution of the software instance.
17. The system of claim 16 wherein the risk score is further based at least in part on the software instances's provenance comprising at least in part at least one of—the identities, makeup, reputation, and trustworthiness—of at least one of: the publisher of the software, the project the software belongs to, the version of the software, the files of the software, changes that have been made to the software, people working on the software, organizations involved with the software, organizations to which the people working on the software belong, the relationships between people involved with the project, relationships between organizations involved on the project, relationships between people and organizations involved on the project, processes of the software development, and the openness of the development.
18. The system of claim 16 wherein the risk score is produced at least in part from metrics on at least one of: an install atom of the software instance, a package of the software instance, a local application of the software instance, local system the software instance is on, a container of the software instance, an operating system running the software instance, a virtual machine of the software instance, a hypervisor running the software instance, hardware running the software instance, a network the software instance is connected to, and context of the deployment of the software instance.
19. The system of claim 16 comprising further an attestor that attests to the trustworthiness of the software instance based at least in part on at least one risk score for the software instance running including any constraints and execution modifications.
20. The system of claim 10 comprising further an attestor that attests to the trustworthiness of the software instance based at least in part on verification of the software instance.
| 6088779 | July 11, 2000 | Bharadhwaj |
| 7613907 | November 3, 2009 | Kaabouch |
| 9633158 | April 25, 2017 | Jones |
| 10025927 | July 17, 2018 | Khalid |
| 10102380 | October 16, 2018 | McKeen |
| 20090132823 | May 21, 2009 | Grimen |
| 20090307500 | December 10, 2009 | Sato |
| 20100199354 | August 5, 2010 | Eker |
| 20120284792 | November 8, 2012 | Liem |
| 20120317645 | December 13, 2012 | Fortier |
| 20130111587 | May 2, 2013 | Goel |
| 20140006803 | January 2, 2014 | Bodis |
| 20140229669 | August 14, 2014 | Sandstrom |
| 20160132667 | May 12, 2016 | Freitas Fortuna dos Santos |
| 20160259941 | September 8, 2016 | Vasudevan |
| 20170208067 | July 20, 2017 | Sriramakrishnan |
| 20170262892 | September 14, 2017 | Fernando |
| 20170286721 | October 5, 2017 | |
| 20180046823 | February 15, 2018 | Durham |
| 20180114012 | April 26, 2018 | Sood |
| 20180183578 | June 28, 2018 | Chakrabarti |
| 20180183580 | June 28, 2018 | Scarlata |
| 20180247055 | August 30, 2018 | Curtis |
| 20180247082 | August 30, 2018 | Durham |
| 20190042764 | February 7, 2019 | Durham |
| 20190044729 | February 7, 2019 | Chhabra |
| 20190147184 | May 16, 2019 | Zhang |
| 20190229924 | July 25, 2019 | Chhabra |
| 20200311268 | October 1, 2020 | Kostyushko |
| 20200342100 | October 29, 2020 | Goldstein |
| 20210056205 | February 25, 2021 | Gorelik |
| 20210097037 | April 1, 2021 | Babol |
| 20210173622 | June 10, 2021 | Craik |
| 20210234875 | July 29, 2021 | Hecht |
Type: Grant
Filed: Nov 15, 2022
Date of Patent: Aug 22, 2023
Inventor: Joseph Alan Epstein (Pleasanton, CA)
Primary Examiner: Gary S Gracia
Application Number: 17/987,594
International Classification: G06F 21/55 (20130101); G06F 21/53 (20130101); G06F 21/62 (20130101); G06F 21/56 (20130101); G06F 21/57 (20130101);
