Cybersecurity Architecture for Golden Chopsticks Kimchi (GCK)
Background
The Golden Chopsticks Kimchi (GCK) project is a small startup business where the owner ambitions to become The Kimchi King! Long story short, the owner is stranded in a place where kimchi is not common, and the frustration to find fresh kimchi became overwhelming. So, the owner having fond childhood memories of his grandmother’s Golden Chopsticks Korean restaurant decided to figure out how to make kimchi. While he made kimchi there was always extra, and so he decided to share or sell the excess. Although the product is low tech requiring very little ingredients, the consumer demographic is mostly made up of tech users of Facebook Marketplace. One fall season, the Kimchi King decided to post his kimchi for sale locally and there were many who came to pick up jars during a global pandemic. Then the king decided to broaden the post to all states and found people were willing to buy from everywhere. In one night, there were over 10,000 views for the posted kimchi! The king was stuffing kimchi in durable little pouches and sending it across the country during the wintertime. The ambition of the Kimchi King is to make a web application to enable others in various other local markets to create other Kimchi fiefdoms and sell kimchi to all those near them.
Application Architecture
The thought was to create a simple web application that would have a large button in the middle saying “Kimchi me now!” Although a simple act to get kimchi, users would have to register and provide a delivery address as well as credit card information. The other aspect of the application is storing the secret recipes. For example, after making simple kimchi, the Kimchi King decided to spice up the kimchi with various hot peppers. He started with habaneros, then moved to ghost, and finally reapers which is one of the hottest peppers in the world. Other franchise Kimchi Kings may use this information after making agreements to not disclose the secret, and can then access this information from the secure portion of the website. There would also be opportunities to buy other products such as a pair of metal golden chopsticks and bumper stickers that say, “Kimchi me now!” with a Cat saying, “Kimchi meow?”
Kimchi King would like to make some web services for his most dedicated customers. The idea is to make it so that they can go to https://gimmekimchi.com and demand fresh kimchi, and not only go to https://kimchi.load.run to get the basic recipe and spend laborious hours making kimchi. The application architecture for the kimchi serverless application is depicted in Figure 1. The URL would be routed by Amazon Route 53 and through an AWS WAF. The application would follow an AWS serverless architecture leveraging Amplify at the front end, Lambda functions in the middle, and a DynamoDB for the database. AWS Identity and Access Management (IAM), AWS Simple Storage Service (S3), and AWS Cognito are common services that would be leveraged as part of the architecture. From a startup security perspective there is a prescriptive AWS Startup Security Baseline (AWS SSB). This would be a good place to start to secure this application.
AWS Startup Security Baseline (AWS SSB)
The AWS SSB is a set of controls that are broken up into account and workload categories of tasks a startup business would perform to create a minimum-security foundation. This foundation can be expanded upon as the organization grows. The focus is to form a base security posture for a startup using AWS technologies. The controls are focused on securing credentials, enabling logging to increase visibility, managing contact information or logins, creating data boundaries, and recommendations for encryption and reducing scope of access. The Kimchi King is alone with minimal staff and operations, but he is tech savvy working in many companies with enterprise IT scale.
AWS SSB Account Security
AWS SSB Account Security contains the following topics listed below (ACCT.01 to ACCT.12). It makes sense to restrict use of the root user, one of the first things done was to create another user to use when creating a brand-new account. Assigning permission by using IAM user groups also makes sense. Three groups would be initially created, those who administer the system, a group for franchise Kimchi Kings, and the regular users who are a fan of kimchi buying it through the app. Enabling MFA may help to deter adversaries who have malicious intent to harm the kimchi kingdom (app) or pilfer the secret super spicy recipes. Enforcing a password policy may be good for everyone, including customers so that their personal accounts are protected and kimchi ordering is not hijacked by some other user looking for free kimchi. I think deleting unused VPCs, subnets, and security groups make sense. There will be a lot of trial and error, and the sense is over time VPCs, subnets, and security groups created for proving out concepts may just linger in the environment. GuardDuty is a threat-detection service that monitors to see if there are any threat actors misusing AWS resources. It can provide detailed reports for remediation when someone has compromised the system. AWS Trusted Advisor is a passive scan of AWS infrastructure for high-risk/impact issues. The focus is on security, performance, cost, and reliability. Extra functionality for reports can be subscribed to with support plans.
- ACCT.01 – Set account-level contacts to valid email distribution lists
- ACCT.02 – Restrict use of the root user
- ACCT.03 – Configure console access for each user
- ACCT.04 – Assign permissions by using IAM user groups
- ACCT.05 – Require multi-factor authentication (MFA) to log in
- ACCT.06 – Enforce a password policy
- ACCT.07 – Deliver CloudTrail logs to a protected S3 bucket
- ACCT.08 – Prevent public access to private S3 buckets
- ACCT.09 – Delete unused VPCs, subnets, and security groups
- ACCT.10 – Configure AWS Budgets to monitor your spending
- ACCT.11 – Enable and respond to GuardDuty notifications
- ACCT.12 – Monitor for and resolve high-risk issues by using Trusted Advisor
AWS SSB Workload Security
AWS SSB Workload Security contains the following topics listed below (WKLD.01 to WKLD.15). Since our architecture is leveraging Lambda which leverages AWS compute resources, it makes sense to create a role, so we do not need to store or manage long-term credentials while running Lambda functions. Instead of having passwords set within the application in files or in the database it makes sense to leverage the AWS Secrets Management service. There are topics to encrypt EBS and RDS, but DynamoDB the database we will be using can be encrypted so that data at rest is not seen plainly. The edge protection service or endpoint prevention platforms (EPP) we will use is AWS WAF to protect web application traffic and use AWS API Gateway to protect Lambda functions. The AWS WAF combined with AWS Shield can be used to protect against DDoS attacks. For true IDS and IPS other third-party services can be investigated and incorporated. CI/CD can be leveraged to deploy everything from a GitHub repository. There we can use templates to apply security controls instead of manually creating them.
- WKLD.01 – Use IAM roles for compute environment permissions
- WKLD.02 – Restrict credential usage scope with resource-based policies permissions
- WKLD.03 – Use ephemeral secrets or a secrets-management service
- WKLD.04 – Prevent application secrets from being exposed
- WKLD.05 – Detect and remediate exposed secrets
- WKLD.06 – Use Systems Manager instead of SSH or RDP
- WKLD.07 – Log data events for S3 buckets with sensitive data
- WKLD.08 – Encrypt Amazon EBS volumes
- WKLD.09 – Encrypt Amazon RDS databases
- WKLD.10 – Deploy private resources into private subnets
- WKLD.11 – Restrict network access by using security groups
- WKLD.12 – Use VPC endpoints to access supported services
- WKLD.13 – Require HTTPS for all public web endpoints
- WKLD.14 – Use edge-protection services for public endpoints
- WKLD.15 – Define security controls in templates and deploy them by using CI/CD practices
Conclusion
For a startup business it is hard to start a new venture worrying about the business model as well as creating a new application. To create a new application on its own takes a lot of effort. To secure it takes even more effort. Thankfully AWS has thought about the small business and created a prescriptive AWS SSB that acts as a checklist to secure the system. This is a starting place and as the business grows this base can be expanded upon to add extra monitoring and security controls.