FSI Service Spotlight: HAQM Lex

Editor’s note: This is the fifth in a monthly series for Financial Services Industry Service Spotlight.

—

Welcome to another edition of the Service Spotlight blog series. In this series, we plan to highlight five key considerations of a particular service that financial institutions should focus on to help streamline service approval, including:

Achieving compliance
Data protection
Isolation of compute environments
Automating audits with APIs
Operational access and security

Each of these five areas will include specific guidance that can help you streamline service approval for the particular service, which may need to be adapted to your specific use case and environment.

In this edition, we are covering HAQM Lex, a service for building conversational interfaces for applications using voice and text. It is powered by the same technology as HAQM Alexa and enables any developer to build conversational bots quickly with no deep learning expertise necessary. By using an HAQM Lex bot, you can provide customers 24/7 availability to get questions answered and tasks performed without needing to speak to an agent. HAQM Lex bots use automatic speech recognition and natural language understanding to determine user’s intent and dynamically adjusts the responses in the conversation.

HAQM Lex provides automatic speech recognition and natural language understanding technologies to create a speech language understanding system. This system helps HAQM Lex understand the intent behind the natural language speech and text inputs. You can use HAQM Lex to build context-aware chatbots that can handle multi-turn conversations, complete tasks and answer frequently asked questions. HAQM Lex integrates with many other services on the AWS platform, including HAQM Kendra, HAQM Polly, HAQM Connect, and HAQM Comprehend. Integration with AWS Lambda provides your bots access to pre-built serverless enterprise connectors that can seamlessly integrate with SaaS applications such as Salesforce.

HAQM Lex provides automatic speech recognition and natural language

Financial institutions have been increasingly using machine learning services to create simple yet effective customer support, virtual support agents, and digital assistant experiences such as intelligent IVR routing, information capture to reduce time agents need to spend on collecting customer information, and chatbots for their internal and external websites and mobile applications to perform tasks such as checking account balances and stock portfolios. TransUnion used HAQM Lex to automate their HAQM Connect based Interactive Voice Response (IVR). It reduced the time their customers spent in the IVR from 2 minutes to just 18 seconds and helped them save over 40% in annual costs. Liberty Mutual Insurance has created a digital assistant using HAQM Lex to redefine their employee experience for 50,000 employees in 800 offices across the world. It enables their employees to ask questions in natural language and get the right information fast so that they can spend more time helping their customers.

We will now dive deep into the five key considerations outlined previously.

Achieving Compliance with HAQM Lex

HAQM Lex is an AWS managed service and third-party auditors regularly assess the security and compliance of it as part of multiple AWS compliance programs. As part of the AWS shared responsibility model, the HAQM Lex service is in the scope of the following compliance programs and customers can obtain corresponding compliance reports under an AWS non-disclosure agreement (NDA) through AWS Artifact.

SOC 1,2,3
PCI
ISO/IEC 27001:2013, 27017:2015, 27018:2019,ISO/IEC 9001:2015 and CSA STAR CCM v3.0
MTCS (few regions only)
HITRUST CSF
FINMA

The customer’s scope of the shared responsibility model when using HAQM Lex is determined by the sensitivity of their data, their organization’s compliance objectives, and applicable laws and regulations. AWS provides resources to customers for compliance validations.

Data Protection with HAQM Lex

At AWS, we recommend our customers secure their data in transit and at rest by encrypting it. HAQM Lex uses the HTTPS protocol to communicate with a customer’s client application. It uses HTTPS and AWS signatures to communicate with other services, such as HAQM Polly and AWS Lambda on the customer application’s behalf. Customers use published AWS API calls to access HAQM Lex through the network. Clients must support Transoport Layer Security (TLS) 1.0 and we recommend TLS 1.2 or later. Clients must also support cipher suites with perfect forward secrecy (PFS), such as Ephemeral Diffie-Hellman (DHE) or Elliptic Curve Ephemeral Diffie-Hellman (ECDHE). All HAQM Lex model-building and runtime API operations use signature V4 for authenticating requests.

HAQM Lex stores four types of content and AWS offers different options for encryption at rest:

Sample Utterances – When a customer develops a bot, they can provide sample utterances for each intent and slot. This information is used only to build the bot and to create the user experience and this data is encrypted at rest.
Customer Utterances – These are the utterances from users interacting with the bot. HAQM Lex encrypts utterances that users send to customer bot and stores for 15 days in its internal data store. HAQM Lex does not store or retain voice or text utterance information from applications that are subject to Children’s Online Privacy Protection Act (COPPA).
Session attributes – These contain application-specific information that is passed between HAQM Lex and client applications. HAQM Lex passes session attributes to all AWS Lambda functions configured for a bot. If a Lambda function adds or updates session attributes, HAQM Lex passes the new information back to the client application. Session attributes persist in an encrypted store for the duration of the session. Customers can configure the session to remain active for a minimum of 1 minute and up to 24 hours after the last user utterance. The default session duration is 5 minutes.
Request attributes – These contain request-specific information and apply only to the current request. A client application uses request attributes to send information to HAQM Lex at runtime. Customers use request attributes to pass information that doesn’t need to persist for the entire session. Because request attributes don’t persist across requests, they aren’t stored.
Conversation logs – By enabling conversation logs, customers get a detailed view of conversations that users have with their bot. Customers can configure logging text input to HAQM CloudWatch Logs and audio input to HAQM S3.
- Text logs store text input, transcripts of audio input, and associated metadata in CloudWatch Logs. Customers can enable encryption using an AWS KMS key on the CloudWatch Logs log group that HAQM Lex uses for text logs. For more information, see Encrypt Log Data in CloudWatch Logs Using AWS KMS in the HAQM CloudWatch Logs User Guide.
- For audio logs customer can use default encryption on their S3 bucket or specify an AWS KMS key to encrypt audio objects. Customer can choose to use default S3 bucket encryption, or customer can choose to use their own AWS KMS keys to encrypt their audio objects by leveraging options for encryption at rest offered by S3.

HAQM Lex also provides a few different ways to manage the data stored by it. You can use the DeleteUtterances operation to delete stored utterances for a specific user. In context of conversation logs to protect sensitive data captured as slot values, you can enable slot obfuscation to mask those values for logging.

Using IAM policies, Permission boundaries, Service Control Policies or Resource policies customers can limit access to sensitive information stored.

IAM Policy to grant Lex read-only access:

{
"Version": "2012-10-17",
"Statement": [
{
“sid”: “HAQM-Lex-Read-Only-grant”
"Action": [
"lex:GetBot",
"lex:GetBotAlias",
"lex:GetBotAliases",
"lex:GetBots",
"lex:GetBotChannelAssociation",
"lex:GetBotChannelAssociations",
"lex:GetBotVersions",
"lex:GetBuiltinIntent",
"lex:GetBuiltinIntents",
"lex:GetBuiltinSlotTypes",
"lex:GetIntent",
"lex:GetIntents",
"lex:GetIntentVersions",
"lex:GetSlotType",
"lex:GetSlotTypes",
"lex:GetSlotTypeVersions",
"lex:GetUtterancesView"
],
"Effect": "Allow",
"Resource": "*"
}
]
}

SCP to deny access to create and update bot API operations:

{
   {
    "Version": "2012-10-17",
    "Statement": [
        {
            "sid": "scp-deny-HAQM-Lex-create-update-bot"
            "Action": [
                "lex:CreateBot",
                "lex:UpdateBot"
            ],
            "Effect": "Deny",
            "Resource": ["arn:aws:lex:us-east-1:123412341234:bot/*]
        }
    ]
}

Isolation of compute environments with HAQM Lex

HAQM Lex is a managed service that doesn’t have any compute resources on the customer’s side of the shared responsibility model. As a managed service, AWS is responsible for infrastructure security and it is protected by the AWS global network security procedures that are described in the HAQM Web Services: Overview of Security Processes whitepaper.

HAQM Lex supports resource-based access policies and customers can add conditions like restricting access based on the source IP address or establish private connection between their Virtual Private Cloud (VPC) and HAQM Lex by creating HAQM Virtual Private Cloud (HAQM VPC) endpoints. Effectively, this policy isolates network access to a given HAQM Lex resource from specific a VPC within the AWS:

{
    "Version": "2012-10-17",
    "Statement": [
       {
           "Effect": "Allow",
           "Action": "lex:",
            "Resource": [
                "arn:aws:lex:us-east-2::bot:ContactcenterBot:",
                "arn:aws:lex:us-east-2::intent:EmployeeBot:",
                "arn:aws:lex:us-east-2::slottype:CustomerBot:*"
            ],
            "Condition": {
                "IpAddress:": {
                    "aws:SourceIp": [
                        "192.0.2.0/24",
                        "203.0.113.0/24"
                    ]
                }
            }
        }
}

Automating audits with APIs with HAQM Lex

HAQM Lex is integrated with AWS CloudTrail. CloudTrail captures a subset of API calls for HAQM Lex as events, including calls from the HAQM Lex console and from code calls to the HAQM Lex APIs. Using the information collected by CloudTrail, you can determine the request that was made to HAQM Lex, the IP address from which the request was made, who made the request, when it was made, and additional details.

The API calls logged by CloudTrail differ based on the version of HAQM Lex API you are using. You can learn more about the specific API calls in the HAQM Lex V1 or HAQM Lex V2 documentation. HAQM Lex has a few important APIs that you should monitor to make sure only approved bots are created, updated, or deleted.

Following are the key APIs for HAQM Lex V1:

PutBot – creates a new bot or replaces an existing bot
PutBotAlias – creates an alias for the specified version of the bot or replaces an alias for the specified bot
PutIntent – creates an intent or replaces an existing intent
PutSlotType – creates a custom slot type or replaces an existing custom slot type

HAQM Lex V2 APIs simplify versioning and information architecture. It provides separate APIs to create, update, and delete actions on bots.

For bot creation:

CreateBot – creates a new HAQM Lex conversational bot
CreateBotAlias – creates an alias for the specified version of a bot
CreateBotLocale – creates a locale in the bot
CreateBotVersion – creates a new version of the bot
CreateIntent – creates a new intent
CreateSlot – creates a slot in an intent
CreateSlotType – creates a custom slot type

Once the bot has been created, there are a few key APIs to monitor to ensure they don’t deviate from defined standards or get deleted.

For bot update:

UpdateBot– updates the configuration of an existing bot
UpdateBotAlias– updates the configuration of an existing bot alias
UpdateBotLocale– updates the settings that a bot has for a specific locale
UpdateIntent– updates the settings for an intent
UpdateSlot– updates the settings for a slot
UpdateSlotType– updates the configuration of an existing slot type

For deleting a bot:

DeleteBot– deletes all versions of a bot. It also deletes all of the resources contained in the bot such as locales, intents, slot, and slot types defined for the bot
DeleteBotAlias– deletes the specified bot alias
DeleteBotLocale– removes a locale from a bot
DeleteBotVersion– deletes a specific version of a bot
DeleteIntent– removes the specified intent
DeleteSlot– deletes the specified slot from an intent
DeleteSlotType– deletes a slot type from a bot locale

HAQM Lex V1 (PutBotAlias) and HAQM Lex V2 (CreateBotAlias, and UpdateBotAlias) APIs allow you to enable conversation logs to store bot interactions. It is important to make sure the destination of the logs has encryption at rest enabled as described in the Data Protection with HAQM Lex section above.

The following example shows a CloudTrail log entry that demonstrates the CreateBotAlias action:

{
    "eventVersion": "1.05",
    "userIdentity": {
        "type": "AssumedRole",
        "principalId": "ID of caller:temporary credentials",
        "arn": "arn:aws:sts::XXXX:assumed-role/role name/role ARN",
        "accountId": "XXXX",
        "accessKeyId": "AKIAIOSFODNN7EXAMPLE",
        "sessionContext": {
            "sessionIssuer": {
                "type": "Role",
                "principalId": "ID of caller",
                "arn": "arn:aws:iam::XXXX:role/role name",
                "accountId": "XXXX",
                "userName": "role name"
            },
            "webIdFederationData": {},
            "attributes": {
                "mfaAuthenticated": "false",
                "creationDate": "creation date"
            }
        }
    },
    "eventTime": "event timestamp",
    "eventSource": "lex.amazonaws.com",
    "eventName": "CreateBotAlias",
    "awsRegion": "Region",
    "sourceIPAddress": "192.0.2.0",
    "userAgent": "user agent",
    "requestParameters": {
        "botAliasLocaleSettingsMap": {
            "en_US": {
                "enabled": true
            }
        },
        "botId": "bot ID",
        "botAliasName": "bot aliase name",
        "botVersion": "1"
    },
    "responseElements": {
        "botAliasLocaleSettingsMap": {
            "en_US": {
                "enabled": true
            }
        },
        "botAliasId": "bot alias ID",
        "botAliasName": "bot alias name",
        "botId": "bot ID",
        "botVersion": "1",
        "creationDateTime": creation timestamp
    },
    "requestID": "unique request ID",
    "eventID": "unique event ID",
    "readOnly": false,
    "eventType": "AwsApiCall",
    "recipientAccountId": "XXXX"
}

You can also use AWS Config custom rules to capture and monitor your Bot configuration. Here is a blog post that describes how to create a generic custom AWS config rule using the Rule Development Kit. AWS Config also enables you to take remediation actions when an undesired configuration is detected. You can learn more about AWS Config custom rules in the documentation.

Operational access and security with HAQM Lex

AWS customers in the financial services industry require detailed logging and assurance of access of critical data. Customers can review third-party auditor reports such as the AWS SOC 2 Type II report, ISO 27001, and others in AWS Artifact.

Access to HAQM Lex is governed by AWS Identity and Access Management (IAM) service. IAM is an AWS service that helps you control who can be authenticated and authorized to use HAQM Lex resources. HAQM Lex supports identity-based policies and resource-based policies for actions supported by both HAQM Lex Model Building Service as well as HAQM Lex Runtime Service. Identity-based policies allow you define which actions are allowed or defined for an IAM identity whereas resource-based policies allow you to specify what actions a specified principal can perform on the HAQM Lex resource and under what conditions.

Below is an example of how this policy grants an IAM user or role in your AWS account permission to use the PostText operation with any HAQM Lex bot in a particular account tagged with the key “Department” and the value “Support”.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": "lex:PostText",
            "Effect": "Allow",
            "Resource": "arn:aws:lex:us-east-2:XXX:bot:*"
            "Condition": {
                "StringEquals": {
                    "lex:ResourceTag/Department": "Support"
                }
            }
        }
    ]
}

You can learn more about actions, resources, and condition keys supported by HAQM Lex in IAM policies in HAQM Lex V1 or HAQM Lex V2 documentation.

Certain AWS artificial intelligence (AI) services, including HAQM Lex may store and use customer content processed by those services for the development and continuous improvement of HAQM AI services and technologies. You can use organization-wide AI services opt-out policies to opt out of having your content stored or used for service improvements. When you opt out of content use by an AWS AI service, that service deletes all of the associated historical content that was stored prior to setting the option

The following example shows a policy that you could attach to your organization’s management account to opt out of AI services for accounts in your organization. Refer to the documentation for more examples of opt-out policies, such as opt-out policy for a single service.

{
    "services": {
        "@@operators_allowed_for_child_policies": ["@@none"],
        "default": {
            "@@operators_allowed_for_child_policies": ["@@none"],
            "opt_out_policy": {
                "@@operators_allowed_for_child_policies": ["@@none"],
                "@@assign": "optOut"
            }
        }
    }
}

Conclusion

In this post we reviewed HAQM Lex and highlighted key information that can help financial services customers accelerate the approval of the service within these five categories: achieving compliance, data protection, isolation of compute environments, automating audits with APIs, and operational access and security. While not a one-size-fits-all approach, the above guidance can be adapted to meet your organization’s security and compliance requirements and provide a consolidated list of key areas for HAQM Lex. In the meantime, be sure to visit our AWS Industries blog channel and stay tuned for more financial services news and best practices.

AWS for Industries