FSI Service Spotlight: Amazon 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 Amazon Lex, a service for building conversational interfaces for applications using voice and text. It is powered by the same technology as Amazon Alexa and enables any developer to build conversational bots quickly with no deep learning expertise necessary. By using an Amazon Lex bot, you can provide customers 24/7 availability to get questions answered and tasks performed without needing to speak to an agent. Amazon Lex bots use automatic speech recognition and natural language understanding to determine user’s intent and dynamically adjusts the responses in the conversation.

Amazon Lex provides automatic speech recognition and natural language understanding technologies to create a speech language understanding system. This system helps Amazon Lex understand the intent behind the natural language speech and text inputs. You can use Amazon Lex to build context-aware chatbots that can handle multi-turn conversations, complete tasks and answer frequently asked questions. Amazon Lex integrates with many other services on the AWS platform, including Amazon Kendra, Amazon Polly, Amazon Connect, and Amazon 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.

Amazon 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 Amazon Lex to automate their Amazon 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 Amazon 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 Amazon Lex

Amazon 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 Amazon 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 Amazon 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 Amazon Lex

At AWS, we recommend our customers secure their data in transit and at rest by encrypting it. Amazon 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 Amazon Polly and AWS Lambda on the customer application’s behalf. Customers use published AWS API calls to access Amazon 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 Amazon Lex model-building and runtime API operations use signature V4 for authenticating requests.

Amazon 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. Amazon Lex encrypts utterances that users send to customer bot and stores for 15 days in its internal data store. Amazon 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 Amazon Lex and client applications. Amazon Lex passes session attributes to all AWS Lambda functions configured for a bot. If a Lambda function adds or updates session attributes, Amazon 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 Amazon 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 Amazon CloudWatch Logs and audio input to Amazon 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 Amazon Lex uses for text logs. For more information, see Encrypt Log Data in CloudWatch Logs Using AWS KMS in the Amazon 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.

Amazon 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”: “Amazon-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-Amazon-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 Amazon Lex

Amazon 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 Amazon Web Services: Overview of Security Processes whitepaper.

Amazon 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 Amazon Lex by creating Amazon Virtual Private Cloud (Amazon VPC) endpoints. Effectively, this policy isolates network access to a given Amazon 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 Amazon Lex

Amazon Lex is integrated with AWS CloudTrail. CloudTrail captures a subset of API calls for Amazon Lex as events, including calls from the Amazon Lex console and from code calls to the Amazon Lex APIs. Using the information collected by CloudTrail, you can determine the request that was made to Amazon 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 Amazon Lex API you are using. You can learn more about the specific API calls in the Amazon Lex V1 or Amazon Lex V2 documentation. Amazon 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 Amazon 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

Amazon 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 Amazon 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

Amazon Lex V1 (PutBotAlias) and Amazon 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 Amazon 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 Amazon 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 Amazon 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 Amazon Lex resources. Amazon Lex supports identity-based policies and resource-based policies for actions supported by both Amazon Lex Model Building Service as well as Amazon 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 Amazon 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 Amazon 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 Amazon Lex in IAM policies in Amazon Lex V1 or Amazon Lex V2 documentation.

Certain AWS artificial intelligence (AI) services, including Amazon Lex may store and use customer content processed by those services for the development and continuous improvement of Amazon 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 Amazon 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 Amazon 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