Access controls for question delegation environments

Techniques are provided for access controls for question delegation environments. One method comprises obtaining a security policy for a question obtained from a user; monitoring responses to the question; and enforcing, by a third-party portal processing system, access controls within the security policy for data associated with the question and/or the responses to the question, wherein the access controls comprise one or more restrictions with respect to a time duration to access the data and/or a number of people that may access the data. The third-party portal processing system evaluates whether the time duration to access the data has expired before providing access to the data and/or whether the number of people that may access the data has been exceeded before providing access to the data. A client-side encryption of the data is optionally performed by a provider of the data.

FIELD

The field relates generally to information processing.

BACKGROUND

Questionnaires are often used by companies to assess the risk posed by third-party vendors and partners. In some cases, responses from third parties may contain highly sensitive information, particularly as the responses pertain to questions about sensitive topics, such as information security practices and/or financial information. In such cases, companies and third parties often enter into non-disclosure agreements (NDAs) to ensure that the third-party data is handled in prescribed ways by the company receiving the data. There is not a clear way, however, to translate the requirements of an NDA, including access control requirements, into requirements that are technically enforceable, verifiable, and auditable. NDAs may also be vague and leave certain requirements open to interpretation.

A need exists for a mechanism for specifying access control requirements for questionnaires and/or associated responses in such a way that an intermediate platform can interpret and enforce those requirements.

SUMMARY

In one embodiment, a method comprises obtaining a security policy for at least one question obtained from a user; monitoring one or more responses to the at least one question; and enforcing, by a third-party portal processing system, one or more access controls within the security policy for data associated with one or more of the at least one question and the one or more responses to the at least one question, wherein the one or more access controls comprise one or more restrictions with respect to one or more of a time duration to access the data and a number of people that may access the data.

In some embodiment, the exemplary method further comprises evaluating whether the time duration to access the data has expired before providing access to the data and/or whether the number of people that may access the data has been exceeded before providing access to the data.

In at least one embodiment, a client-side encryption of the data is performed by a provider of the data using a symmetric key pair to generate an encrypted version of the data. The third-party portal processing system stores the encrypted version of the data comprising an encrypted payload and an encrypted symmetric key.

DETAILED DESCRIPTION

Illustrative embodiments of the present disclosure will be described herein with reference to exemplary communication, storage and processing devices. It is to be appreciated, however, that the disclosure is not restricted to use with the particular illustrative configurations shown. One or more embodiments of the disclosure provide methods, apparatus and computer program products for access controls for question delegation environments.

In one or more embodiments, techniques are provided for companies and third parties to describe their security requirements, including access control requirements, for questionnaires in such a way that an intermediate platform shared by the companies and third parties can interpret and enforce those requirements. The disclosed intermediate platform allows companies to publish questionnaires to be responded to by the third parties and allows third parties to answer questionnaires and submit responses back to companies. Among other benefits, the disclosed access control framework makes access control requirements between companies and third parties explicit, and the access control requirements can be technically enforced, simultaneously protecting third parties and companies from the mishandling of third-party data.

In some embodiments, when a company publishes a questionnaire to a third party, the company also sends a machine-readable security policy document describing expectations for how data related to the questionnaire and/or responses is handled. The disclosed access control framework provides a mechanism for parties to enforce the access control aspects of a security policy.

FIG. 1illustrates a questionnaire submission and response platform100, according to at least one embodiment of the disclosure. As shown inFIG. 1, a customer110submits one or more questionnaires, optionally by means of an intermediate portal120, discussed further below, to a third-party portal200, as discussed further below in conjunction withFIG. 2. Questions in the questionnaire are to be responded to (and/or otherwise processed) by a designated third party130. The third party130responds to the questionnaire and may optionally delegate one or more responses to another party, referred to as a fourth party140. The fourth party140is delegated the responsibility for responding to one or more questions by the third party130. The fourth party140can optionally delegate to fifth parties (not shown) and so on. While only one instance is shown inFIG. 1for each of the customer110, the third party130and the fourth party140, multiple or zero instances of the customer110, the third party130and/or the fourth party140can be present in various embodiments, as would be apparent to a person of ordinary skill in the art. It is noted that the customer110may have multiple people with distinct roles working on a given questionnaire, such as a submitter and a reviewer, as discussed further below in conjunction with the example ofFIG. 3, for example.

In the exemplary embodiment ofFIG. 1, the customer110, third party130and the fourth party140share the same third-party portal200.

As noted above, customers110optionally submit the questionnaires to the third-party portal200by means of the intermediate portal120, such as the RSA Archer® platform, commercially available from RSA Security LLC, of Dell EMC, Hopkinton, Mass. The intermediate portal120and the third-party portal200communicate, for example, over a secure link using an optional administrative service account. It is noted that the third party130and fourth party140continue to use the third-party portal200to respond to questionnaires and/or to delegate questionnaires.

In one or more embodiments, a question submitted by the customer110typically comprises the following exemplary attributes:UUID: a unique identifier for the question;Text: the actual question; andTags: a set of key-value pairs describing the question, such as category.

A questionnaire comprises a list of one or more questions.

As noted above, the customer110is an entity (e.g., an organization or individual) that submits a questionnaire to be filled out by a designated third party130. The customer110may be characterized in some embodiments, as follows:Id (Identifier); andTags: an arbitrary set of key-value pairs describing the customer110, such as a customer name and/or primary office location.

As noted above, the third party130is an entity that responds to a questionnaire and may optionally delegate certain responses to a fourth party140. The third party130may be characterized in one or more embodiments, as follows:Id; andTags: an arbitrary set of key-value pairs describing the third party130.

As noted above, the fourth party140is an entity that is delegated responsibility for responding to one or more questions by a third party130. The fourth party140can optionally delegate one or more questions to one or more fifth parties and so on. The fourth party140may be characterized in some embodiments, as follows:Id; andTags: an arbitrary set of key-value pairs describing the fourth party140.

A user of the questionnaire submission and response platform100is an entity and/or person representing an organization using the third-party portal200. It is noted that a user can take the role(s) of, for example, a customer110, a third party130and/or a fourth party140. Further, the term “user” herein is intended to be broadly construed so as to encompass numerous arrangements of human, hardware, software or firmware entities, as well as combinations of such entities.

FIG. 2illustrates an exemplary implementation of the third-party portal200ofFIG. 1in further detail, according to some embodiments. As shown inFIG. 2, the exemplary third-party portal200comprises an access control manager240that implements the disclosed access control techniques, as discussed further below in conjunction with, for example,FIGS. 3 through 10. The exemplary third-party portal200maintains one or more database(s)270comprising, for example, a question library275, security policies280, a usage rule list285, a sharing rule list290, and policy agreements295.

In some embodiments, the question library275comprises a list of substantially all possible questions across all questionnaires submitted to the third-party portal200, and maintained by the third-party portal200.

The security policies280comprise, for example, a map that describes directives to be enforced for questions. The security policy map can be expressed, for example, in a key-value format, such as question⇒list of directives, where the key is the question and the value is the list of directives to be enforced for that question.

Requirements covered by the security policies280can include (but are not limited to):Data access expiration: how long a company has access to a response of a third party;Data access maximum viewers: maximum number of unique individuals at a company that can view a response of a third party;Data retention: how long the platform retains the questionnaire response;Data location: geographic location where the questionnaire response is stored geographically; andData encryption: whether the third-party response needs to be protected using client-side encryption (e.g., private keys only held by customers or third parties and not the third-party portal200) or if it is sufficient to encrypt data using platform-managed keys.

A security policy280can be altered after the security policy280has been accepted by both the customer110and a third party130. In this case, the customer110or third party130can use the third-party portal200to propose an update to the security policy280, and then follow a similar workflow as described herein to accept, reject, or update the policy. In some cases, it may not be possible for the third-party portal200to retroactively apply a new policy after the assessment has already been started. In those cases, the third-party portal200would raise an alert and ask if the current in-progress questionnaire should be abandoned and restarted with a new policy.

Directives comprise instructions describing a security or compliance control to be enforced by the third-party portal200. Exemplary directives include:dataAccessExpiration=12 and dataAccessExpirationUnits=months: access to question response granted for 12 months to recipient of question response;dataAccessMaxViewers=5: at most five people at the recipient organization are allowed to view a question's response; anddataLocation=EU: question response data must be stored in a data center in the European Union.

The usage rule list285comprises one or more usage rules, represented, for example, as an ordered list (in a similar manner as network firewall rules). The last rule is a default rule in some embodiments that matches all questions and sources and purposes (question.id=*, source.id=*, purpose=*). The default rule could be completely open with no directives, meaning the security policy is applied.

A usage rule, in some embodiments, is a rule describing a set of directives to be applied to questions that match conditions in the rule. In some embodiments, three conditions in a usage rule are a question matcher pattern, a source matcher pattern, and a purpose. Usage rules are used for questionnaire responses coming back to a user (e.g., the user is playing the role of a customer110or a third party130delegating to a fourth party140). If the user is playing the role of a customer110, the purpose should be VIEW. If the user is playing the role of third party130delegating to a fourth party140, the purpose should be SHARE. An exemplary usage rule comprises:Question matcher pattern: A pattern that can be matched against a question and produces a Boolean result (true or false). The pattern uses a syntax like regular expressions and can apply to any part of a Question: the UUID, Text, and Tags;Source matcher pattern: A pattern that can be matched against a third party and produces a Boolean result (true or false). The pattern uses a syntax like regular expressions and can apply to the third-party ID and Tags;Purpose: Must be either VIEW or SHARE or both; andList of Directives.

The sharing rule list290comprises one or more sharing rules, represented as an ordered list (in a similar manner as network firewall rules). The last rule is a default rule in some embodiments that matches all questions, destinations, and purposes (question.id=*, destination.id=*, purpose=*). The default rule could be completely open with no directives, meaning the security policy is applied.

A sharing rule, in some embodiments, is a rule describing a set of directives to be applied to questions that match conditions in the rule. The three conditions are the question matcher pattern, a destination matcher pattern, and a purpose. Sharing rules are used for questionnaire responses that a user is sending out, i.e., the user is playing the role of a third party130responding to a questionnaire, or a fourth party140sharing data with a third party130who is responding back to a customer110. If the user is directly responding to a customer110, the purpose should be VIEW. If the user is responding to a third party130who is then sharing his/her data with a customer110, the purpose should be SHARE. An exemplary sharing rule comprises:Question matcher pattern: A pattern that can be matched against a question and produces a Boolean result (true or false). The pattern uses a syntax like regular expressions and can apply to any part of a Question: the UUID, Text, and Tags;Destination matcher pattern: A pattern that can be matched against an organization and produces a Boolean result (true or false). The pattern uses a syntax like regular expressions and can apply to the organization's ID and Tags, and also the degree of delegation, where the degree represents how many hops the data can be shared in case of delegation. For instance, a degree of 2 means a fourth party allows a third party to share its data with a customer that has reached out to the third party;Purpose: Must be either VIEW or SHARE or both; andList of Directives.

The policy agreements295comprise agreements between a third party130and a customer110that comprise:Third-party id;Customer id;Security Policy;Purpose: one of VIEW or SHARE;Agreement expiration date;Third-party digital signature;Customer digital signature;Linked agreement(s): one or more linked policy agreements. This applies in the case of delegation when a third party130has delegated responses to a fourth party140, in which case the third party130and the fourth party140enter into an agreement which is linked to the original agreement between the third party130and the customer110; andAmendment(s): zero or more signed modifications to the original agreement.

In some embodiments, the digital signature from the fourth party140in a policy agreement295is wrapped with a digital signature from the third party130.

In one or more embodiments, a usage policy matcher is a component of the third-party portal200that takes as inputs a questionnaire and a usage rule list and returns a security policy. For each question in the questionnaire, the usage policy matcher goes, typically in order, through the usage rule list and evaluates the question matcher pattern against the question and the source matcher pattern against the third party130that the questionnaire is intended for. For each question, the list of directives for the first matching usage rule is returned. If none of the usage rules match, the default (last) usage rule in the list is applied.

In one or more embodiments, an exemplary sharing policy matcher processes a questionnaire and a sharing rule list290and returns a security policy280. For each question in the questionnaire, the sharing policy matcher goes, typically in order, through the sharing rule list290and evaluates the question matcher pattern against the question and the destination matcher pattern against the organization the questionnaire response is intended for. For each question, the list of directives for the first matching sharing rule is returned. If none of the sharing rules match, the default (last) sharing rule in the list is applied.

In an embodiment, an exemplary enforcement engine evaluates and enforces directives. A trigger is an event in the third-party portal200that triggers the enforcement engine to check one or more directives. Each directive is associated with one or more triggers. Triggers can be based on events related to a questionnaire, such as “Questionnaire submitted”, or timer-based, such as “New day started.”

A question matcher optionally processes questions from the questionnaire and matches them against existing questions known to the third-party portal200in the question library275.

In one or more embodiments, an agreement checker processes the list of questions and checks for the most recent existing unexpired data usage agreement with Purpose=VIEW in the account of the customer110that cover all the questions in the questionnaire. As part of this, the agreement checker optionally also needs to validate any linked agreements in cases where third parties are sharing data on behalf of fourth parties.

A conflict checker attempts to construct an expected security policy for the third party130.

For a more detailed discussion of various aspects of the third-party portal200, see, for example, U.S. patent application Ser. No. 16/456,302, filed Jun. 28, 2019, entitled “Security Policy Exchange and Enforcement for Question Delegation Environments,” incorporated by reference herein in its entirety.

In some embodiments, exemplary access control requirements include one or more of:

1) limiting access to sensitive data for a certain period of time;

2) auditing accesses of sensitive data;

3) limiting the number of people with access to the sensitive data; and

FIG. 3is a communication diagram300illustrating an exemplary implementation of a question delegation process according to an embodiment of the disclosure, where customers110submit questionnaires directly to the third-party portal200, without an intermediate portal120. As shown in the example ofFIG. 3, a submitter at the customer310, such as customer ACME, submits a questionnaire to a person at third-party vendor330, such as vendor FOO. The recipient person at the third-party vendor330is notified of the questionnaire and responds to the questionnaire. In the embodiment ofFIG. 3, the third-party vendor330does not employ client-side encryption functionality.

Certain questions in the questionnaire may have responses that the third-party vendor330considers sensitive. These sensitive responses can be associated, for example, with two parameters: 1) an expiration date beyond which customer310should no longer have access to those sensitive responses, and 2) a maximum number of people at customer310that are allowed access to the sensitive data. These parameters can be set by the third-party vendor330based on prior negotiations with the customer310(for instance, using the techniques disclosed in U.S. patent application Ser. No. 16/456,302, referenced above) or at the time that the third-party vendor330sends the questionnaire back to the customer310.

The third-party portal200keeps track of the expiration date for each question and the limit for the number of people allowed to access the sensitive data. The third-party portal200also maintains a list of people at the customer310who are allowed to view the questionnaire. In some embodiments, the submitter is automatically added to this list.

The submitter at the customer310receives the questionnaire and requests to view the questionnaire. Non-sensitive responses in the questionnaire can be shown immediately to the submitter, when the submitter requests to view and/or access a non-sensitive response. For sensitive responses, the third-party portal200first verifies that the expiration date has not passed. Any sensitive responses for which the expiration date has passed are not rendered to the submitter.

The third-party portal200optionally audits the viewing of sensitive data by the submitter. Suppose later that the submitter wants to allow access to another person on his team, such as a reviewer that reviews responses. The submitter sends an “Access Request” on behalf of the “reviewer.”

The third-party portal200checks that the limit for the maximum number of people allowed access to the sensitive data is not already met. If the limit is not yet met, the third-party portal200adds the reviewer to a list of people at the customer310who are allowed to view the questionnaire. Otherwise, the access request is rejected.

If the access request is approved, the reviewer can later try to view the responses to the questionnaire. The third-party portal200again checks the expiration dates for any sensitive responses, and also audits who viewed the sensitive data.

Revoking Access

There are two cases for revoking access. In one case, the submitter person at the customer310may want to remove access for a specific reviewer, for example. In another case, the third-party vendor330may want to revoke access to the customer310. Note that the latter case may not be allowed by the platform if an agreement was reached beforehand between the third-party vendor330and the customer310for the duration of time that the customer310was allowed access.

For the first case, the submitter simply asks the third-party portal200to remove access to the questionnaire to the reviewer, and the third-party portal200removes the reviewer from the list of people allowed access to the sensitive data. The third-party portal200would update the count of current viewers accordingly by decrementing the count by one.

For the second case, the third-party vendor330asks the third-party portal200to remove access to the customer310, and the third-party portal200clears the list of everyone at customer310allowed access and moves the expiration data to the current time or before.

It is noted that revocation optionally only applies to sensitive responses. Non-sensitive responses can continue to be viewed. All revocations are audited by the third-party portal200in some embodiments.

Delegation to a Fourth or Fifth Party

As shown inFIG. 3, in some cases, a third-party vendor330may delegate responses to certain questions to fourth-party vendors (not shown inFIG. 3), who may in turn delegate responses to fifth parties (not shown), and so on. Following a similar process as described above, a fourth or fifth party can designate certain responses as sensitive and attach expirations and counts for the maximum number of people allowed to view the response. In this case, expirations and counts can optionally be set for each degree of indirection. For instance, a fourth-party vendor340could stipulate an expiration and count for the third-party vendor330that the fourth-party vendor340is providing the response to, and a separate expiration and count for customers viewing the response.

FIG. 4illustrates an exemplary implementation of a question delegation environment400with access control and client-side encryption functionality according to one embodiment, where customers110again submit questionnaires directly to the third-party portal200, without an intermediate portal120.

One or more aspects of the disclosure recognize that client-side encryption is useful when third-party vendors330and fourth-party vendors340(or fifth parties) do not trust the third-party portal200with the sensitive data they are sharing with customers. To implement client-side encryption, a public key server450is employed in some embodiments. In some embodiments, each user identity (across the customer310, third-party vendor330and/or fourth-party vendor340, for example,) has a public and private key pair, and the public key for a user is stored and publicly available from the public key server450. Optionally, the functionality of the public key server450could be included as part of the third-party portal200.

The client-side encryption functionality is optionally layered on top of the flows described above in conjunction withFIG. 3, allowing client-side encryption to be selectively enabled, as needed.

As shown in the example ofFIG. 4, a submitter at the customer310, such as customer ACME, submits a questionnaire to a person at third-party vendor330, such as vendor FOO, and reviews responses. The recipient person at the third-party vendor330responds to the questionnaire and/or delegates the questionnaire to a fourth-party vendor340or fifth party (not shown), for example. The fourth-party vendor340can then respond to the delegated questionnaire and/or delegate the delegated questionnaire to a fifth party (not shown)

FIG. 5is a communication diagram500illustrating an exemplary implementation of a question delegation process according to an embodiment of the disclosure, where customers110submit questionnaires directly to the third-party portal200, without an intermediate portal120. As shown in the example ofFIG. 5, a submitter at the customer310, such as customer ACME, submits a questionnaire to a person at third-party vendor330, such as vendor FOO. The recipient person at the third-party vendor330is notified of the questionnaire and responds to the questionnaire. In the embodiment ofFIG. 5, the third-party vendor330employs client-side encryption functionality.

The embodiment ofFIG. 5assumes that client-side encryption is implemented by, for example, a mobile device, web client, and/or browser plug-in and not done by the user, using keys obtained from the public key server450. It is noted that whatever party310,330,340is sharing the data fully controls the generation of all the keys used to encrypt the data and the creation of encrypted data in the example ofFIG. 5.

The third-party vendor330generates responses on the client side and identifies responses, R, that the third-party vendor330considers to be sensitive.

In some embodiments, the third-party vendor330generates a symmetric key Kvand encrypts the sensitive responses, R, with Kvto generate E(Kv, R). The third party then encrypts the symmetric key Kvwith its own public key, PV, obtained from the public key server450to generate E(PV, Kv). The third-party vendor330then saves an encrypted draft of the response in the third-party portal200. This encrypted draft is represented, for example, as a CMS (Cryptographic Message Syntax) message with the following enveloped data:

i. encryptedContentInfo: E(Kv, R) from step a (this is the encrypted payload)

ii. recipientInfo: E(PV, Kv) from step b (this is the encrypted key).

Optionally, a signed data section could also be added to the CMS message to provide guarantees about the integrity of the data.

Eventually, the third-party vendor330will be ready to share the response with the submitter at the customer310. The third-party vendor330creates a new CMS message specifying the submitter as a recipient, specifying the public key, PS, of the submitter obtained from the public key server450and using a new generated symmetric key, KS. This follows the same process outlined above. The third-party vendor330then submits the encrypted message to the third-party portal200. The third-party portal200stores the CMS message, and notifies the submitted at the customer310. Note that the third-party portal200has no access to the underlying sensitive responses.

FIG. 6is a communication diagram600illustrating an exemplary implementation of a question delegation process according to an embodiment of the disclosure, where a submitter associated with the customer310views the response to his or her questionnaire, and, optionally, provides access to a reviewer of the customer310to view the sensitive answers to the questionnaire. As shown inFIG. 6, the third-party vendor330initially shares the encrypted response (described above) with the third-party portal200, and the third-party portal200notifies submitter of the customer310of the encrypted response.

To decrypt the encrypted answers, the submitter gets the private key KSfor his or her own public key PSfrom the public key server450. The submitter will then decrypt E(PS, KS) using his or her private key to recover KSand decrypt the encrypted payload E(KS, R). It is noted that this functionality is performed client-side in the embodiment ofFIG. 6. The third-party portal200provides the encrypted data to the submitter.

As noted above the, submitter can optionally send an access request to provide access to another person, a reviewer, from the customer310(e.g., a member of his or her team) to view the sensitive answers to the questionnaire. As shown inFIG. 6, the submitter gets the public key of the reviewer PR, and encrypts KSwith PRto produce E(PR, KS). The submitter creates an access request on behalf of the reviewer. The access request contains E(PR, KS).

If allowed, the third-party portal200adds the reviewer to the list of allowed viewers of the questionnaire and saves E(PR, KS) with the rest of the questionnaire data by creating a new CMS message with the new recipient. Note that the existing encrypted questionnaire data is used as part of the new CMS message. When the reviewer retrieves the questionnaire with a view request, the third-party portal200returns the encrypted CMS message. It follows the same process as the submitter to then decrypt and view the sensitive responses in the questionnaire.

There are two cases for revocation: 1) the third-party vendor330wants to remove access to the customer310entirely, including the submitter and all reviewers, and 2) the submitter wants to remove access for one or more reviewers.

Case 1) is accomplished in some embodiments by the third-party vendor330sending a revocation request to the third-party portal200. The third-party portal200deletes all of the saved CMS messages and all access privileges for the customer in question.

Case 2) is accomplished, for example, by the submitter sending a revocation request to the third-party portal200. The third-party portal200would then update its list of allowed viewers by removing the specified reviewer(s) and recreating a new CMS message for the remaining recipients. The underlying encrypted questionnaire data is reused as part of the new CMS message.

In one or more embodiments, key rotation can be performed by the third-party vendor330on demand or based on a schedule. The third-party vendor330makes a request to the Portal to retrieve all CMS recipient information stored for itself or for customers. For each existing CMS message in the third-party portal200, the third-party vendor330generates a new CMS message with the payload encrypted with a new symmetric key and the new symmetric key encrypted with the public keys of each recipient (submitter, reviewer, or itself). The third-party vendor330then sends the new CMS messages to the third-party portal200to save and replace the existing CMS messages. This whole process can be done transparently so that customers are not aware of the key rotation.

Suppose that a third-party vendor330delegates the response to a set of questions to a fourth party, and the fourth party considers those responses to be sensitive. In this case, the fourth-party vendor340may not know ahead of time which customers the third-party vendor330will be sharing responses to, and it is possible that the third party may want to share responses with new customers down the road.

To address this situation, instead of sending a single CMS message addressed to the third-party vendor330, the fourth-party vendor340sends c CMS messages addressed to the third party330. c is a parameter that controls how many customers the third party330can share the data of the fourth-party vendor340with. Each of the c CMS messages has a payload encrypted with a different symmetric key. Each time a third party330shares data of a fourth-party vendor340with a customer310, the third-party vendor330uses up one of the CMS messages. When the third party330runs out of shares, the third party330must go back to the fourth-party vendor340to get a new set of CMS messages.

This model allows the fourth-party vendor340to fully control encryption and key management for the data it controls.

Signatures can be added during delegation as well. A fourth-party vendor340can send a signed CMS message to a third-party vendor330. The third-party vendor330can re-sign that message (including the signature of the fourth party) again with its own signing key.

The overall model can be extended to fifth, sixth parties, and so on, as would be apparent to a person of ordinary skill in the art based on the present disclosure.

Any significant actions related to client-side encryption are audited by the third-party portal200, including, for example: a submitter adding a reviewer, key rotation and revocation.

Client-Side Encryption: An Alternate Stronger Revocation Model

In the above scheme, when a submitter revokes access to a reviewer, the encrypted data remains encrypted with a symmetric key that was previously known to the reviewer. The third-party portal200still enforces access control to the encrypted data, but for stronger security it may be desirable to discard the existing encrypted data and encryption key entirely.

The above model can be adapted to support revocation with rekeying. When a third party330shares a questionnaire response to a customer, instead of sending one CMS message, the third-party vendor330sends r CMS messages. Each CMS message has its content encrypted with a different encryption key.

The third-party portal200keeps track of an index i that points to the current CMS message for the customer310. When a submitter adds access to a reviewer, index i stays the same. When a submitter revokes access to a reviewer, the third-party portal200discards the CMS message at index i and increments index i by 1. It is as if the third party330has reshared the questionnaire response with the customer310, except that the sharing has been done in advance by the third party330.

When r is exceeded, the customer310needs to go back to the third party330through the third-party portal200to get a new set of CMS messages.

This alternate revocation model also works with delegation in the mix. When a fourth party340sends a response to a third party, instead of sending c CMS messages (as described above), the fourth party340sends c x r CMS messages. The fourth party340then passes on r copies to each customer310it is sharing fourth-party data with.

Separated Identities Model

In the “separated identities” model, an intermediate portal120(FIG. 1), such as RSA Archer, is used by the customer310(the submitter and reviewer personas) to submit assessments and receive questionnaire responses. The submitter and reviewer personas do not have accounts with the third-party portal200. All communication between the intermediate portal120and the third-party portal200is mediated using an administrative service account provisioned to the customer310by the third-party portal200.

FIG. 7is a communication diagram700illustrating an exemplary implementation of a question delegation process according to an embodiment of the disclosure, where customers110submit questionnaires to the third-party portal200, using the intermediate portal120ofFIG. 1with email verification. As shown in the example ofFIG. 7, a submitter at the customer310, such as customer ACME, submits a questionnaire via an intermediate portal720of the customer310with a third-party risk solution, to the third-party portal200. The third-party portal200notifies the third-party vendor330, such as vendor FOO. The recipient person at the third-party vendor330is notified of the questionnaire and responds to the questionnaire. In the embodiment ofFIG. 7, the third-party vendor330does not employ client-side encryption functionality.

Consider the requirements for time-limited access of sensitive data and limiting the number of unique people with access. Generally, when the intermediate portal720pulls down the questionnaire data from the third-party portal200, the intermediate portal720only syncs non-sensitive responses, and sensitive responses remain stored in the storage of the third-party portal200. Sensitive response data is replaced by a link in the intermediate portal720. When a submitter or reviewer wants to a view the sensitive responses to the questionnaire, the intermediate portal720automatically follows the link on behalf of the user. The user must then verify his or her identity to access the sensitive data. This can be accomplished in two possible ways: email verification with an email server750, shown inFIG. 7, or automatic verification, as discussed further below in conjunction withFIG. 8. These flows can be used together for extra identity assurance, as would be apparent to a person of ordinary skill in the art.

As in the “Federated Identities” models discussed above, where there is no intermediate portal120, the third-party vendor330responds back to the questionnaire with an expiration and limit for the number of people allowed to access the sensitive data set as parameters. The submitter is notified. Only non-sensitive data is synchronized back to the intermediate portal720. Sensitive data remains in the storage of the third-party portal200. In lieu of getting the sensitive data, the intermediate portal720gets a link to the third-party portal200which serves as a pointer to the sensitive data.

The submitter chooses to view the questionnaire responses. All non-sensitive responses are viewable immediately from the intermediate portal720. The intermediate portal720then prompts the submitter to view the sensitive responses. If the submitter wants to proceed, the intermediate portal720automatically follows the link to the third-party portal200. (This can be implemented, for example, through Application Programming Interface (API) calls or by embedding a browser frame within the intermediate portal720itself.)

The third-party portal200sends a challenge code in an email to the email address of the submitter, which is assumed to be available from the original questionnaire submitted by the submitter. The submitter checks his or her email and enters the challenge code into the intermediate portal720/third-party portal200interface.

The third-party portal200verifies the challenge code and checks that the expiration date on the sensitive data has not passed. If the expiration date on the sensitive data has not passed, the third-party portal200issues an access token back to the intermediate portal720, which the intermediate portal720stores securely. The token is similar in intent to a JWT (JSON Web Token). The token is signed by the third-party portal200, contains an access token expiration time (which should not be past the expiration set by the third party), and claims in the form of questionnaire responses that the submitter has access to.

The intermediate portal720resubmits this token back to the third-party portal200to retrieve the sensitive data and render it in the interface of the intermediate portal720. It is important to note that the intermediate portal720should not persist this data. It should remain in memory on the side of the intermediate portal720.

While the token is not expired, the submitter can continue to view the sensitive questionnaire response data without reverifying himself After the token has expired, the submitter needs to reverify himself Optionally, the third-party portal200can issue a refresh and access token together, and the intermediate portal720can automatically use the refresh token to retrieve a new access token without requiring the submitter to re-authenticate himself. The third-party portal200continues to check that the questionnaire expiration date has not passed with each access and refresh.

Suppose the submitter later wants to grant access to a reviewer to view the questionnaire. The submitter sends an access request to the third-party portal200through the intermediate portal720to grant access to a reviewer, with the email address of the reviewer included in the request.

The third-party portal200checks if the limit for the number of people allowed access is already met. If the limit has not been met, the third-party portal200adds the email of the reviewer to the list of people allowed access to the sensitive data.

When the reviewer later seeks to access sensitive data in the questionnaire, he or she follows the same flow as the submitter (as described above).

FIG. 8is a communication diagram800illustrating an exemplary implementation of a question delegation process according to an embodiment of the disclosure, where customers110submit questionnaires to the third-party portal200, using the intermediate portal120ofFIG. 1with automated verification. As noted above, the automated verification flow ofFIG. 8is an alternative way to verify the identity of the submitter or reviewer. Compared to the email verification flow, the automated verification provides a better user experience, as the user does not need to check his email and enter a challenge code. However, automated verification places a greater burden on the secondary system (intermediate portal720) to securely maintain secrets.

As in the email verification flow ofFIG. 7, after a third party responds to a questionnaire, only non-sensitive data is synchronized back to the intermediate portal720. Sensitive data remains stored in the third-party portal200, and a pointer to the sensitive data in the form of a link is synchronized back to the intermediate portal720. In contrast to the email verification flow ofFIG. 7, in addition to the link, secret data tied to the submitter identity, in the form of an email address, is generated by the third-party portal200and sent back to the intermediate portal720. The third-party portal200also keeps this secret data. The nature of the secret data depends on the method of authentication to be used when the submitter views the sensitive data in the questionnaire (to be described below).

The submitter chooses to view the questionnaire responses. All non-sensitive responses are viewable immediately from the intermediate portal720. The intermediate portal720then prompts the submitter to view the sensitive responses. If the submitter wants to proceed, the intermediate portal720automatically follows the link to the third-party portal200. (This can be implemented through API calls or by embedding a browser frame within the intermediate portal720itself.)

The intermediate portal720automatically uses the secret data stored locally to authenticate to the third-party portal200using the email address of the submitter as his identity. Authentication can be accomplished in any number of ways. For instance, the secret data can be interpreted as a password, and the third-party portal200can simply verify the password against a salted hash kept at the third-party portal200. Alternatively, the SRP (Secure Remote Password) protocol can be used to verify the password. Alternatively, the secret data can be a certificate private/public key pair, and the intermediate portal720can authenticate on behalf of the submitter using client-side certificate authentication.

Similar to the email verification flow, a JWT-like access token is returned back to the intermediate portal720, and this can be resubmitted by the intermediate portal720to gain access to the sensitive data.

If a submitter later wants to grant access to the questionnaire to a reviewer on his team, for example, he or she sends an access request through the intermediate portal720. Similar to the email verification flow ofFIG. 7, the third-party portal200checks the limit for maximum people allowed access and returns an access response accordingly. In contrast to the email verification flow ofFIG. 7, this access response also includes secret data that the reviewer can use to authenticate to the third-party portal200later on. This secret data is stored securely in the intermediate portal720and associated with the reviewer. The third-party portal200also keeps this secret data and associates it with the email address of the reviewer.

When the reviewer later seeks to access sensitive data in the questionnaire, he or she follows the same flow as the submitter (described above).

In various embodiments, all authentications to the third-party portal200and all accesses to sensitive data in the third-party portal200are audited, as well as requests by submitters to grant or revoke rights to reviewers.

Delegation, revocation, and client-side encryption all follow the same logic as described above for the “federated identities” model, where there is no intermediate portal720, with the exception that the intermediate portal720simply acts as an intermediary to communicate between the submitter and reviewer of the customer310and the third-party portal200.

FIG. 9is a flow chart illustrating an exemplary implementation of a question delegation access control enforcement process900, according to one embodiment of the disclosure. As shown inFIG. 9, the question delegation access control enforcement process900obtains a security policy for at least one question obtained from a user during step910. Thereafter, the question delegation access control enforcement process900monitors one or more responses to the at least one question during step920.

The third-party portal200, for example, enforces one or more access controls within the security policy for data associated with the at least one question and/or the one or more responses to the at least one question during step930. The one or more access controls comprise, for example, restrictions with respect to one or more of a time duration to access the data and a maximum number of people that may access the data, as described herein.

One or more embodiments of the disclosure provide a third-party portal200for access control enforcement for question delegation systems. In some embodiments, an access control framework and workflow are provided as part of the third-party portal200for companies and third parties to describe their access control requirements for questionnaires and/or related responses in such a way that an intermediate platform shared by the companies and third parties can interpret and enforce those access control requirements. The disclosed intermediate platform allows companies to publish questionnaires to be processed by the third parties and allows third parties to answer questionnaires and submit responses back to companies. Among other benefits, the disclosed access control framework makes access control requirements between companies and third parties explicit, and these access control requirements can be technically enforced, simultaneously protecting third parties and companies from the mishandling of third-party data.

In some embodiments, the disclosed techniques for access control enforcement for question delegation provide a systematic way for delegating questions to third parties, and for ensuring the enforcement of access controls associated with the delegated questions and/or related responses.

One or more embodiments of the disclosure provide improved methods, apparatus and computer program products for access controls for question delegation environments. The foregoing applications and associated embodiments should be considered as illustrative only, and numerous other embodiments can be configured using the techniques disclosed herein, in a wide variety of different applications.

The disclosed techniques for access control enforcement for question delegation may be implemented using one or more processing platforms. One or more of the processing modules or other components may therefore each run on a computer, storage device or other processing platform elements. A given such element may be viewed as an example of what is more generally referred to herein as a “processing device.”

As noted above, illustrative embodiments disclosed herein can provide a number of significant advantages relative to conventional arrangements. It is to be appreciated that the particular advantages described above and elsewhere herein are associated with particular illustrative embodiments and need not be present in other embodiments. Also, the particular types of information processing system features and functionality as illustrated and described herein are exemplary only, and numerous other arrangements may be used in other embodiments.

In these and other embodiments, compute services can be offered to cloud infrastructure tenants or other system users as a Platform-as-a-Service (PaaS) offering, although numerous alternative arrangements are possible.

Cloud infrastructure as disclosed herein can include cloud-based systems such as Amazon Web Services (AWS), Google Cloud Platform (GCP) and Microsoft Azure. Virtual machines provided in such systems can be used to implement at least portions of a cloud-based third-party portal platform in illustrative embodiments. The cloud-based systems can include object stores such as Amazon S3, GCP Cloud Storage, and Microsoft Azure Blob Storage.

Illustrative embodiments of processing platforms will now be described in greater detail with reference toFIGS. 10 and 11. These platforms may also be used to implement at least portions of other information processing systems in other embodiments.

FIG. 10shows an example processing platform comprising cloud infrastructure1000. The cloud infrastructure1000comprises a combination of physical and virtual processing resources that may be utilized to implement at least a portion of the third-party portal200. The cloud infrastructure1000comprises multiple virtual machines (VMs) and/or container sets1002-1,1002-2, . . .1002-L implemented using virtualization infrastructure1004. The virtualization infrastructure1004runs on physical infrastructure1005, and illustratively comprises one or more hypervisors and/or operating system level virtualization infrastructure. The operating system level virtualization infrastructure illustratively comprises kernel control groups of a Linux operating system or other type of operating system.

The cloud infrastructure1000further comprises sets of applications1010-1,1010-2, . . .1010-L running on respective ones of the VMs/container sets1002-1,1002-2, . . .1002-L under the control of the virtualization infrastructure1004. The VMs/container sets1002may comprise respective VMs, respective sets of one or more containers, or respective sets of one or more containers running in VMs.

In some implementations of theFIG. 10embodiment, the VMs/container sets1002comprise respective VMs implemented using virtualization infrastructure1004that comprises at least one hypervisor. Such implementations can provide question delegation and access control enforcement functionality of the type described above for one or more processes running on a given one of the VMs. For example, each of the VMs can implement question delegation and access control enforcement control logic and associated agreements for providing question delegation and access control enforcement functionality for one or more processes running on that particular VM.

In other implementations of theFIG. 10embodiment, the VMs/container sets1002comprise respective containers implemented using virtualization infrastructure1004that provides operating system level virtualization functionality, such as support for Docker containers running on bare metal hosts, or Docker containers running on VMs. The containers are illustratively implemented using respective kernel control groups of the operating system. Such implementations can provide question delegation and access control enforcement functionality of the type described above for one or more processes running on different ones of the containers. For example, a container host device supporting multiple containers of one or more container sets can implement one or more instances of question delegation and access control enforcement control logic and associated agreements for use in question delegation.

As is apparent from the above, one or more of the processing modules or other components of the third-party portal200may each run on a computer, server, storage device or other processing platform element. A given such element may be viewed as an example of what is more generally referred to herein as a “processing device.” The cloud infrastructure1000shown inFIG. 10may represent at least a portion of one processing platform. Another example of such a processing platform is processing platform1100shown inFIG. 11.

The processing platform1100in this embodiment comprises at least a portion of the given system and includes a plurality of processing devices, denoted1102-1,1102-2,1102-3, . . .1102-K, which communicate with one another over a network1104. The network1104may comprise any type of network, such as a wireless area network (WAN), a local area network (LAN), a satellite network, a telephone or cable network, a cellular network, a wireless network such as WiFi or WiMAX, or various portions or combinations of these and other types of networks.

The processing device1102-1in the processing platform1100comprises a processor1110coupled to a memory1112. The processor1110may comprise a microprocessor, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other type of processing circuitry, as well as portions or combinations of such circuitry elements, and the memory1112, which may be viewed as an example of a “processor-readable storage media” storing executable program code of one or more software programs.

Also included in the processing device1102-1is network interface circuitry1114, which is used to interface the processing device with the network1104and other system components, and may comprise conventional transceivers.

The other processing devices1102of the processing platform1100are assumed to be configured in a manner similar to that shown for processing device1102-1in the figure.

Multiple elements of an information processing system may be collectively implemented on a common processing platform of the type shown inFIG. 10 or 11, or each such element may be implemented on a separate processing platform.

As another example, portions of a given processing platform in some embodiments can comprise converged infrastructure such as VxRail™, VxRack™, VxBlock™, or Vblock® converged infrastructure commercially available from Dell EMC.

As indicated previously, components of an information processing system as disclosed herein can be implemented at least in part in the form of one or more software programs stored in memory and executed by a processor of a processing device. For example, at least portions of the functionality shown in one or more of the figures are illustratively implemented in the form of software running on one or more processing devices.