Hi, welcome to This is My Architecture.
I am Herman, Solution Architect for AWS.
We are glad to have Gabriel from Bowtie, to share with us AWS‘s architecture.
Gabriel, what's up? Hello, Herman.
Gabriel, could you first tell us about Bowtie?
Bowtie is Bao Tai Ren Shou in Chinese.
We are Hong Kong's first virtual insurance company
under a set of strict approvals and authorizations.
With innovative technology and our medical know-how,
we aim to provide a fully digital insurance experience for Hong Kong people.
Therefore, our customers can get their quotes, underwriting and claim services online anytime, anywhere.
Bowtie employs technology to reduce our costs,
offering citizens with security at lower costs and more convenient means.
Among that, we chose AWS to set up our insurance platform.
As you mentioned, Bowtie is the first virtual insurance company in Hong Kong,
so security must be a priority.
So how can AWS help you achieve your security automation goals?
We apply a lot of AWS cloud architecture and tools
to ensure our insurance platform is safe and stable.
Plus, we can continue to launch new services to our customers.
AWS has many services that have saved us tons of efforts and time.
For instance, at a conventional firm, they may need to hire someone
to monitor the server or system logs around the clock.
In contrast, Bowtie has made its own alert system,
making sure we can get some warnings quickly or even immediately
in case some security incidents happen.
Our engineers can then make some modifications and investigations.
So how does this notification system actually work?
Different Bowtie workflows have employed several AWS services.
For example, our domain name is managed on Route 53.
It has a few domain name query logs. Our workflows can conduct some AWS API calls.
Every log will be recorded by Cloudtrail.
This way, our core system is placed in a VPC at the end.
And all network traffic will be recorded by VPC Flow Log.
After saving these logs, how can you use them later?
We will use GuardDuty, which will flash a few losses as I mentioned.
Thus, it will have different rules, like it will look at the IP addresses of those API calls,
as well as other different parameters.
It checks for issues in these events, like if an account has been compromised,
or if there are any strange domain queries.
If any issue is detected, it will send these events that need to be notified to CloudWatch Event.
After that, we set CloudWatch Event again, and send those events to Lambda.
Next, Bowtie make different customizations in Lambda.
For example, each of the events can have an IP address.
Via third-party services, such as checking the origin countries of IP address,
we can add some different customizations and decorations.
After the event is completed, we send the events to our security engineers
by means of some third-party platforms, such as Slack.
We chose Slack, because we realized it was easy to miss some security notifications
with traditional emails.
As a result, the whole event is virtually gone.
Plus, these third-party chat services can customize many messages.
For example, buttons or links can be added for our security engineers
to look up the entire issue.
Therefore, GuardDuty can save you time and easily integrate different data sources.
Can you give us a practical example or explain how AWS helps your business?
Like on my way home, I received a GuardDuty notification from Slack,
telling me there was an unauthorized AWS console login.
Then I checked with our tool. It turned out my colleague was rushing with debugging at home,
and forgot to use the company's VPN.
This triggered an unauthorized AWS console login from a new IP address.
I see. So what are you going to do if you really receive an event?
As mentioned, we have different losses. With Cloudtrail, we stream those to CloudWatch,
and then Lambda for some decorations and some filtering.
Finally, they are sent to the ElasticSearch cluster.
In the previous example, after I received that notification, I used parameters like the IP address
or user names to access Kibana in Elasticsearch.
This way, I can check if colleagues made some API calls during that time,
or if there were different API calls to that IP address before,
making it easier for us to see what happened to that security notification.
We have a rule at Bowtie if a colleague accidentally triggers a security warning in GuardDuty,
he or she must leave a message explaining what they did
on the chat platform,
as well as how the warning was triggered.
After they leave a message, we are able to explain to the team how we can avoid
triggering those security warnings in the future.
After that, the whole event is closed.
Gabriel, thank you for sharing how Bowtie securely automates on AWS.
Thank you all for watching This is My Architecture.