DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment / Arguments
Regarding claims rejected under 35 USC 112(b):
The currently amended claims are considered to have overcome the applied rejections. As such, the rejections have been withdrawn.
Regarding claims rejected under 35 USC 103:
The currently amended claims are considered to have overcome the applied rejection. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Goodridge (US 2019/0325133 A1).
In response to Applicant’s arguments against the Singh reference concerning “during analysis” (“Singh's restoration is a remediation step it fixes the security breach to prevent further damage by the malicious process. The claimed restoration is an investigative step… Singh resets the token to stop the attack, not to allow the malicious behavior to occur again (repetition) as a means of forensic identification and to trap the attacker by observing the repetition of the illegal change”), it is first noted that Col. 4, Ll. 20-25 of Singh states that “the event analysis logic within the token analysis system may access the access token data store maintained within the kernel space to reset one or more privileges associated with the compromised access token to its intended value.” It is additionally noted that “during analysis” does not exclude remediation, which may be performed by an analysis system as in Singh. Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Further in response to Applicant’s arguments against the motivation (“A person of ordinary skill, seeking to secure a system (as in Singh), would reset the token to prevent the attack from continuing. They would not be motivated to restore the token and continue monitoring for the specific purpose of watching the attack repeat, as this arguably leaves the system vulnerable during the analysis window”), it is first noted that Col. 5, Ll. 42-52 of Singh states that “the first component may generate an alert to the user or an administrator, reset the access token to its original privilege levels, and quarantine the object that caused the execution of the malicious process by placement of the object in an isolated segment of memory for subsequent analysis and deletion.” Thus, Singh already considers resetting the token together with a quarantine and subsequent analysis. Additionally, allowing potentially dangerous execution is a known aspect of quarantine and analysis. Execution in an isolated segment allows one of ordinary skill in the art to observe malicious behavior for proper identification, analysis, and cataloging.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1, 3-6, 8, 10-13, 15, and 17-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. Independent claims 1, 8, and 15 recite “identif[y/ing] a file that initiates a procedure for illegally changing privileges if the procedure is repeated,” which renders the respective claims indefinite because it is not clear how to interpret this limitation. For one, it is not clear what is meant to be identified. Specifically, whether the limitation is drawn to (1) identifying a file as being a file that initiates “a procedure for illegally changing privileges, or to (2) merely identifying a file that already has the property of initiating “a procedure for illegally changing privileges.” The scope of the identifying step is not clear such that a person of ordinary skill in the art could interpret the metes and bounds of the claim so as to understand how to avoid infringement. It is likewise not clear how to interpret “if the procedure is repeated” because the claim limitation merely refers to initiating the procedure and not its actual execution. The actual execution may not be part of the claim scope, and it is therefore not clear what “repeated” refers to in that case.
The independent claims also recite “whether the list of privileges in the modified access token has been changed,” which renders the respective claims indefinite in view of the previous limitation of “intercepting an OS event that indicates a launch of a new thread or a launch of a new process, wherein each thread inherits an access token of the associated process, wherein each access token includes a list of privileges that describe access rights and permissions of the process and associated threads.” The latter limitation does not specify the manner of “intercepting,” and it is not clear whether the intercepted launch actually takes place within the scope of the claim such that there is antecedent for “the list of privileges in the modified access token [having] been changed.” The language stating “wherein each thread inherits an access token of the associated process, wherein each access token includes a list of privileges that describe access rights and permissions of the process and associated threads” does not actually specify the access token being generated or obtained.
For the purpose of applying prior art, this limitation has been interpreted to mean that a history of suspicious operations is considered before determining that the file is malicious
The dependent claims do not rectify this deficiency, and are also rejected with their respective parent claims.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1, 3-4, 6, 8, 10-13, 15, 17-18, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Vincent (US 10,565,378 B1) in view of Singh (US 11,314,859 B1) and Goodridge (US 2019/0325133 A1).
Regarding claim 1, Vincent discloses: A method for detecting a vulnerability (e.g., Col. 1, Ll. 30-33, Col. 7, Ll. 18-44, and Col. 8, Ll. 1-3 of Vincent with respect to vulnerabilities which may be exploited maliciously) in an operating system based on process and thread data, comprising:
detecting one or more launches of one or more threads associated with one or more processes in an operating system (OS) by intercepting an OS event that indicates a launch of a new thread or a launch of a new process,
Refer to at least FIG. 2, FIG. 5-6, Col. 5, Ll. 23-27, Col. 8, Ll. 16-20, Col. 12, Ll. 23-27, and Col. 16, Ll. 7-12 of Vincent with respect to detecting threads scheduled for execution via hooks. A process consists of one or more threads.
wherein each thread inherits an access token of the associated process,
Refer to at least Col. 8, Ll. 21-31 of Vincent, which states that a token “may be interpreted as an object (e.g., information formatted in a specified structure) that describes the security context of a process or thread associated with the token, wherein one or more thread(s) of the process perform various actions on the behalf of the user that the token represents. The token may be thought of as a badge or identification (ID) of the user account to which the process, and thus any threads associated therewith, belongs.”
wherein each access token includes a list of privileges that describe access rights of the process and associated threads;
Refer to at least Col. 8, Ll. 45-59 of Vincent, stating that “the information comprising the security context in a token may include, inter alia, the identity of the user account associated with the process or thread, identifiers of the groups to which the user is a member, session information, and the privilege(s) of the user and/or groups to which the user is a member. Herein, a privilege is an access right of a process or thread that allows the process or thread to perform various operations on behalf of the user represented by the token. A privilege may relate to the access-control and/or auditing mechanism utilized by operating systems to provide security and isolation. As used herein, the term “privilege” may represent a privilege level.”
generating a set of privileges based on the detected one or more launches for the one or more processes and one or more associated threads (e.g., “the learned privilege list (herein the learned privilege list may also include information associated with one or more threads and the privilege(s) of each thread, if applicable)” in Col. 5, Ll. 30-33 in Vincent; “the use of ‘privilege list’ should be interpreted as including the ‘privilege list’ and the ‘learned privilege list’ in Col. 19, Ll. 19-21 of Vincent);
Refer to at least FIG. 3, Col. 2, Ll. 62-Col. 3, Ll. 4, Col. 3, Ll. 32-39, Col. 9, Ll. 57-61, Col. 10, Ll. 36-41, and Col. 13, Ll. 26-30 of Vincent with respect to a privilege list which is generated.
analyzing the generated set of privileges to identify illegitimate changes in privileges by identifying at least one access token that has been changed (e.g., TOKEN_N changed to TOKEN_N’ in FIG. 7 of Vincent);
Refer to at least Col. 5, Ll. 25-46, Col. 9, Ll. 65-Col. 10, Ll. 5, Col. 13, Ll. 26-54, and Col. 16, Ll. 40-56 of Vincent with respect to determining whether current process privileges are stolen and/or maliciously modified.
detecting a vulnerability in the OS using one or more rules; and
Refer to at least Col. 17, Ll. 45-Col. 18, Ll. 36 of Vincent with respect to a determination of malicious exploitation (i.e., a vulnerability is being exploited as in Col. 1, Ll. 30-33, Col. 7, Ll. 18-44, and Col. 8, Ll. 1-3 of Vincent above).
wherein each of the one or more rules includes at least the following conditions: whether the modified access token is unique; and
Refer to at least Col. 1, Ll. 23-30, stating that “each token structure is “unique” to a process within the run-time environment in that there is a one-to-one mapping between the process and its associated token (and its included privileges set).” Further, Col. 4, Ll. 27-36 of Vincent states that “[a] stolen token may represent a token that is no longer associated with a process in a one-to-one mapping, but is instead associated with a plurality of processes in a one-to-many mapping.”
Refer to at least 1302 in FIG. 13 of Vincent with respect to determining whether the token is mapped one-to-one with a process.
whether [privileges have been changed];
Refer to at least 1304-1305 in FIG. 13 of Vincent with respect to detecting changes between current privileges and those in the privilege list.
Vincent discloses remediation such as alerting (e.g., Col. 4, Ll. 58-61), but does not specify remediation comprising: isolating a file that exploited the detected vulnerability, in response to detecting the vulnerability. Vincent also does not specify: the access token list of privileges further comprising permissions of the process and associated threads; whether privileges have been changed for the modified token further comprising and whether the list of privileges in the modified access token has been changed; restoring the access token and the list of privileges of the processes and/or threads of the isolated file during analysis of the behavior of the isolated file; and identifying a file that initiates a procedure for illegally changing privileges if the procedure is repeated. However, Vincent in view of Singh discloses remediation comprising: isolating a file that exploited the detected vulnerability, in response to detecting the vulnerability;
Refer to at least Col. 5, Ll. 37-52 and Col. 14, Ll. 39-47 of Singh with respect to remediation including an alert and quarantining a file that caused execution of a malicious process.
the access token list of privileges further comprising permissions of the process and associated threads;
Refer to at least Col. 2, Ll. 17-21 and Col. 8, Ll. 55-Col. 9, Ll. 6 of Singh with respect to privileges including permissions such as CREATE, READ, and DELETE file.
restoring the access token and the list of privileges of the processes and/or threads of the isolated file during analysis of the behavior of the isolated file.
Refer to at least Col. 5, Ll. 37-48 of Singh stating that “the first component may generate an alert to the user or an administrator, reset the access token to its original privilege levels” as part of remedial action which includes the quarantining. Further see at least Col. 4, Ll. 20-25 of Singh stating that “the event analysis logic within the token analysis system may access the access token data store maintained within the kernel space to reset one or more privileges associated with the compromised access token to its intended value.”
The teachings of Vincent and Singh both relate to detecting malicious privilege escalation and are considered to be within the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Vincent to further implement remediation comprising quarantine functionality for at least the purpose of preventing continued exploitation from a malicious file while allowing analysis and subsequent deletion (e.g., Col. 5, Ll. 45-47 of Singh). It further would have been obvious to include permissions as part of the privilege list because the substitution of one known element for another would have yielded predictable results to one of ordinary skill in the art at the time (i.e., the cited portions of Singh); to include resetting the access token for at least the purpose of validating escalation of privilege during analysis.
Vincent-Singh considers quarantine and subsequent analysis as in Col. 5, Ll. 44-48 of Singh, but does not specify: identifying a file that initiates a procedure for illegally changing privileges if the procedure is repeated. Vincent-Singh further does not specify: and whether privileges have been changed for the modified token further comprising whether the list of privileges in the modified access token has been changed.
However, Vincent-Singh in view of Goodridge discloses: identifying a file that initiates a procedure for illegally changing privileges if the procedure is repeated;
Refer to at least [0062] of Goodridge stating that “a suspect process may be allowed to continue for the time being while an outcome may be determined in relation to each specific requested operation (e.g. to block the requested operation, allow the operation, or perform the operation in a modified form). That is, the evaluation may in some examples link together a history of suspicious operations before determining that the process is malicious.”
and whether privileges have been changed for the modified token further comprising whether the list of privileges in the modified access token has been changed.
Refer to at least [0039]-[0040] and [0061] of Goodridge with respect to an access token comprising several fields of information including “a list of privileges” and “TokenPrivileges;” and with respect to comparison between a presented access token and a recorded version of the access token. As per the cited portions, “evaluation may then involve probing the given access tokens and comparing particular fields therein… TokenGroups and TokenPrivileges may include additional groups and/or include higher privilege groups.” According to at least [0061] of Goodridge, a unique identifier is also checked.
The teachings of Goodridge likewise concern detecting escalation of privilege attacks and access tokens, and are considered to be within the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Vincent-Singh to further implement evaluating a history of suspicious operations for at least the purpose of improving detection accuracy (i.e., reducing false positives and better identifying persistent threats). It further would have been obvious to compare privilege lists and unique identifiers within the token because the substitution of one known element for another would have yielded predictable results to one of ordinary skill in the art at the time (i.e., the substitution of which token fields are compared during evaluation).
Regarding claim 3, Vincent-Singh-Goodridge discloses: The method of claim 1, wherein the generated set of privileges is analyzed by identifying at least one privilege usage event in the OS.
Refer to at least FIG. 4A-C, FIG. 8, and 1002 in FIG. 10 of Vincent with respect to analyzing triggering events.
Regarding claim 4, it is rejected for substantially the same reasons as claims 1 and 3 above (i.e., the citations concerning hooks and analyzing triggering events).
Regarding claim 6, Vincent-Singh-Goodridge discloses: The method of claim 1 further comprising, analyzing the behavior of the one or more processes and/or threads of the isolated file.
Refer to at least Col. 5, Ll. 2-14 of Vincent with respect to the EoP detection system analyzing behavior.
Refer to at least Col. 5, Ll. 37-52 of Singh with respect to quarantining the object for subsequent analysis.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify Vincent-Singh for the EoP to perform behavior analysis as part of subsequent analysis on the quarantined object for substantially the same reasons as claim 1 above, and further to identify collect additional threat information for vulnerability reporting (e.g., data about APTs and attack chains; data about associated servers and payloads—e.g., Col. 1, Ll. 42-53 of Vincent).
Regarding independent claim 8, it is substantially similar to independent claim 1 above, and is therefore likewise rejected (i.e., the citations and obviousness rationale).
Regarding claims 10-13, they are substantially similar to claims 3-6 above, and are therefore likewise rejected.
Regarding independent claim 15, it is substantially similar to independent claim 1 above, and is therefore likewise rejected (i.e., the citations and obviousness rationale).
Regarding claims 17-18 and 20, they are substantially similar to claims 3-6 above, and are therefore likewise rejected.
Claim(s) 5 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Vincent-Singh-Goodridge as applied to claims 1, 3-4, 6, 8, 10-13, 15, 17-18, and 20 above, and further in view of Strogov (US 2023/0315848 A1).
Regarding claim 5, Vincent-Singh-Goodridge does not specify: further comprising intercepting the OS events from a log of all recorded events in the OS. However, Vincent-Singh-Goodridge in view of Strogov discloses: further comprising intercepting the OS events from a log of all recorded events in the OS.
Refer to at least FIG. 3, [0070]-[0071], and [0050] of Strogov with respect to a security system receiving event information from event logs for analysis.
The teachings of Vincent-Singh-Goodridge and Strogov both concern identifying malicious threads based on associated events, and are considered to be within the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Vincent-Singh-Goodridge to further obtain information from event logs because event logs because the substitution of one known element for another (e.g., obtaining information directly from hooks, or from records including those of hooks) would have yielded predictable results to one of ordinary skill in the art at the time (e.g., an intermediate data logging step); further because having additional input information from all recorded events would improve detection accuracy.
Regarding claim 19, it is substantially similar to claim 5 above, and is therefore likewise rejected.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VADIM SAVENKOV whose telephone number is (571)270-5751. The examiner can normally be reached 12PM-8PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jeffrey L Nickerson can be reached at (469) 295-9235. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Jeffrey Nickerson/Supervisory Patent Examiner, Art Unit 2432
/V.S/Examiner, Art Unit 2432
Prosecution Insights