# General Security

## End-to-End Security Management

- Cloud Adoption is supported by a risk & security framework.
**Infra is so far Ok, but not good enough for operation**
- Skills development plan for existing employees includes ongoing training on how to manage risk during both normal and abnormal delivery, and recruitment plan is based on a gap analysis to support cloud adoption.
**Not Yet**
- Technical standards are defined and documented for network, system, application, encryption, cloud services, and that includes guidance for implementation and reference architectures.
**We host the doucments on gitlab, including runbook and FAQ**
## Operational Risk

- Operating model to support cloud strategy is in place.
**Not yet**
- IT architecture requirements include network and security requirements that are aligned with business, contractual, regulatory requirements.
**Yes**
- Change and configuration management is defined, automated, configuration drift tracked, compared, reviewed and remediated.
**We use gitlab, clickup, and aws ecr to manage the version**
- Problem and Incident Management run-books are readily available for use by business functions, and cover all significant types of incident including security incidents with clear escalation points, and a clear segue to the Business Continuity and Disaster Recovery plans.
**We host the doucments on gitlab, including runbook and FAQ**

## Strategy

- Internal/External IT audits are performed and reported on annual or semi-annual basis.
**No. We review the infra monthly, yet not inclyding security**
- An organizational strategy that supports delivery in the cloud exists and is approved by the board or senior management.
**Yes, we review the infra monthly.**
- Roles and responsibilities for executing cloud security strategy have been clearly defined.
**No. Own by the pipeline developer, what you make it we fix itNo, the service is owned by the developers, and they fix it themselves.**
- Business cases for cloud adoption require adequate documentation of the associated risks.
**No**

# Data Protection

## Data Classification and Strategy

- There is a data classification standard defined and documented. The standard covers protections that are required, retention periods, and security mechanisms that are required.
- Is the data security owned by business team? Security team? Infrastructure team?
**Infrastructure team**
- Is there a data classification defined?
**Yes**
- Is the standard documented and reviewed periodically?
**No**
- There is a cloud encryption standard and process defined based on the data classification standard. (e.g., KMS, HSM, specific ciphers, ELB cipher suites).
- Is there a data security strategy or baseline defined?
**Yes**
- Is there a standard operation procedure (SOP) defined to standardize and audit the protection of data?
**No, but on going.**
- What encryption method is used?
**No**
- Data access policies and entitlements are defined relative to the data classification. Tags or other indicators connect access policies to the data they regulate.
- Is there a mapping of access pattern between human and data?
**No**
- How is it aligned with data classification?
**No**
## Retention

- Data classification policy or some other customer policy dictates clear retention and deletion policies for data.
- How is data retention determined for different kinds of data?
**We do not define it.**
- Data is automatically deleted when it is no longer required to be retained.
- Does the customer define retention rules for cloud-native storage?
**Yes**
- Restore time objective (RTO) and restore point objective (RPO) are defined and implemented.
- Is there a RTO defined?
**No**
- Is there a RPO defined by application?
**No**
- How is disaster recovery plan (DRP) designed, tested, and validated to ensure the required RTO/RPO can be achieved?
**No**
- There is a documented backup management process to handle information system and data backups, and backup tools have been implemented.
- How are application backups made?
**S3: No, Dynambodb: multi az**
- How often are applications backed up?
**Dynambodb: realtime**
- Are backups tested?
**No**
- How often?
**No**

## Data at Rest

- Sensitive data in block storage (e.g., EBS, instance storage) is encrypted where required.
- Describe the current EBS volume strategy.
**No applicable**
- Is there a standard to encrypt some or all volumes?
**No**
- Is encryption of instance local storage required by any policies or regulations?
**No**
- Sensitive data in object storage (e.g., S3) is encrypted where required.
- Describe the current S3 bucket policy model.
**All bucket and objects are not public **
- Is there an encryption policy that should apply to all buckets?
**NO**
- What is the encryption method used? (`SSE-S3`, `SSE-KMS`, `SSE-C`)
**NO**
- Sensitive data in relational databases (e.g., DB on EC2, RDS) is encrypted where required.
- Does the customer use RDS databases or databases on EC2?
**Yet, but not in data pipeline**
- Does the database data need to be encrypted at rest?
**I don't know**
- Which encryption scheme will be used? EBS volume-level encryption, TDE, or something else?
**I don't know**
- Sensitive data in document databases (e.g., DynamoDB, MongoDB, ElasticSearch) is encrypted where required.
- DynamoDB encrypts by default, does the customer use KMS?
**No**
- What about ElasticSearch instances?
**We don't use it**
- Access to Object Storage (e.g., S3) is limited via appropriate access policies, such as bucket policies.
- How are bucket policies applied?
**All bucket and objects are not public**
- How are they managed?
**We defined the permision between each service in CDK**
- Is there is a global standard policy or mechanism?
**All bucket and objects are not public and partial authorized via CDK**
- How are policies configured for public-facing buckets? (principal/resource/action)
**No public facing buckets**
- Encryption keys are managed using Amazon Key Management Service (KMS) or a well-managed HSM.
- Do they use KMS?
**No**
- How do they manage master keys (Managed/Customer Import)?
**No**
- AMIs are protected if they contain sensitive information.
- Is there any user/business data stored in AMIs?
**We do not use AMI**
- Where is sensitive data stored?
**We do not use AMI**
- Is there any de-identification method in place?
**We do not use AMI**
- Source code for infrastructure code is protected.
- How is infrastructure code (e.g., cloudformation, terraform, Puppet, Ansible) protected from unauthorised modification?
**We have to review the commit by DevOps (Hsi-wen, Ting-An) before publish it**
- Who can commit code?
**All develpoer**
- How would the customer know if code was modified?
**We adopt rolling update, so they don't know.**
- How is it protected from mass deletion?
**We only set the remove policy for storage, i.e., S3 and dynamodb, and only the access key of devops can access the production**
- How is it protected from being made public?
**We only set the remove policy for storage, i.e., S3 and dynamodb, and only the access key of devops can access the production**
- Cloud native storage services are not made public: S3, ElasticSearch clusters, EBS volumes, RDS snapshots, AMIs, etc.
- How does the customer prevent public sharing of cloud-native storage?
**In the data pipeline, services are not publicly accessible.**

## Data in Transit

- Sensitive data is encrypted between end users and API endpoints (not AWS API endpoints. Between end users and customer endpoints and customer applications)
- How is data secured between end users and applicaitons?
**The data pipeline is an internal service that is not publicly available.**
- Is TLS terminated at the edge with load balancers or all the way to EC2?
**Not applicable**
- Sensitive data is encrypted between applications and data stores (e.g., web apps talking to database servers, app servers talking to file servers)
- What protocols are used between systems? (e.g., SQL, NFS, MQ, SQS)
**Not applicable**
- How is data secured across the network?
**Not applicable**
- Are these connections encrypted?
**Not applicable**
- TLS certificates are managed, trusted, and renewed regularly. (Either through Amazon Certificate Manager or a well-understood customer process)
- Are there any tools in place to manage the keys of the encryption algorithms?
**Not applicable**
- Do they use AWS Certificate Manager?
**Not applicable**
- Connectivity between customer premises and AWS is protected.
- How do customer data centres and/or offices connect to the VPC and/or AWS resources?
**Not applicable**
- How is data encrypted over that connection?
**Not applicable**
- HTTPS endpoints for AWS services are used, rather than HTTP endpoints. HTTPS is enforced for S3 bucket policies, where appropriate per data classifications and access requirements.
- Do you use HTTPS on S3-hosted assets?
**S3 is not publicly available**
- Is there a HTTPS enforcement statement in S3 bucket policies?
**S3 is not publicly available**
# Infrastructure Security

## Instance Level Security

- Hardened images or hardening methods (i.e., bootstrapping scripts) are used.
- What is the mechanism for deploying EC2 instances?
**We do not use EC2 in data pipeline.**
- How are instances hardened/patched? (e.g., patch-in-place, patch base AMI and replace, redeploy)
**Not applicable**
- On-instance security is managed and maintained.
- How are application and OS logs extracted from instances?
**Not applicable**
- What endpoint security (anti-virus, host intrusion detection, instance-level firewall) is applied?
**Not applicable**
- How is that enforced/monitored?
**Not applicable**
- Patching is planned and organised for long-lived instances.
- How do operating systems get patched?
**Not applicable**
- How do applications (e.g., web servers, programming language runtimes) get patched?
**Not applicable**
- Can security get a sense of the state of patching across the estate?
**Not applicable**
- Database (e.g., DB on EC2, RDS) patching activities are planned and scheduled, based on business risk and impact analysis.
- What is the process to patch databases?
**Not applicable**
- Is the window for RDS patching changed from default?
**Not applicable**

## On-premises Connectivity

- Data is appropriately protected in transit between on-prem data centres or offices and AWS.
- How do AWS resources cloud connect with on-premises or hosted infrastructure?
**We only get data from s3 via boto3**
- What is the type of VPN (AWS VGW or via self-managed EC2 instance)?
**No**
- How is HA of VPN achieved (manual or automatic)?
**No**
- Backup connectivity between on-premises and AWS is established and tested.
- What is the secondary / backup connection to AWS?
**No**
- How often is it tested to ensure it works?
**No**
- Access to hosts should be limited to the Designated Source, i.e., Systems Manager or bastion hosts.
- What is the current standard for remote access to instances?
**No**
- How do they implement bastion/jump hosts (Open source/Marketplace)?
**No**
- Who manages the bastion host (Security Team, Infrastructure Team)?
**No**
- How are users authenticated (Username/password or Key pairs)?
**No**
- What ports are allowed to remote access (SSH, Remote Desktop)?
**No**

## VPC Model

- VPC design is guided by a strategy that is aligned with the business and workloads.
- How many VPCs are in an account?
**No applicable for data pipeline. It's serverless**
- What is the VPC model?
- Single VPC for all applications?
**No applicable**
- Or is it one VPC for each application?
**No applicable**
- Are VPC endpoints used?
**No applicable**
- Inter-VPC connectivity is limited and regulated carefully.
- Is there a shared services VPC or AWS account?
**No applicable**
- What kinds of services are operated there?
**No applicable**
- Is PrivateLink or TransitGateway used?
**No applicable**
- How much VPC Peering is used?
**No applicable**
- Appropriate separation of subnets is based on routing and network isolation (e.g., Internet-accessible public subnet, private subnet).
- How many subnets in each VPC (e.g. public, private, both)?
**No applicable**
- What are the controls that ensure that a private subnet remain private?
**No applicable**
- When a service is open to internal users only, how are source IPs are restricted? (Single IP? Subnet?)
**No applicable**
- Network ACL is used on subnet to provide isolation capability where appropriate.
- Are NACLs used?
**No applicable**
- What is the rationale / strategy for using NACLs?
**No applicable**
- VPC Security Groups' rules appropriately restrict network access.
- What services can have internet access?
**No applicable**
- What ports can be opened to internet?
**No applicable**
- How are SGs regulated?
**No applicable**
- Who can create them?
**No applicable**
- How are they checked to be sure they are not overly permissive?
**No applicable**
- Network logging is used strategically to detect and respond to incidents.
- Are any VPC Flow Logs enabled (perhaps on strategic ENIs, like load balancers, customer gateways, etc.)?
**No applicable**
- Network-based incidents can be detected and responded to.
- Is Amazon GuardDuty enabled?
**No applicable**
- Trusted Advisor for open security groups?
**No applicable**
- Config Rules for unexpected modifications to networking stuff?
**No applicable**
- If someone makes unauthorised changes to routing tables, NACLs, security groups, etc., how would you know?
**No applicable**
- Endpoints are used in subnets that do not have Internet access.
- Are VPC endpoints used for AWS services in private subnets?
**No applicable**

## Web Application Security

- Web application threats have been identified and appropriate controls have been applied. (e.g., WAF, Shield Advanced, proxies)
- What web application threats are important (e.g., SQL injection, malicious requests, web scraping)?
**Not applicable to data team**
- What kinds of mitigations are in place to deal with them?
**Not applicable**
- The application architecture is resilient against volumetric DDoS attacks.
- What does your ALB, CloudFront, API Gateway, DDoS protection architecture look like?
**Not applicable**
- Do you have preventive controls in place against http flood, scanners and probes and known reputation lists?
**Not applicable**
- Do you have preventive controls in place to prevent unauthorized application scanners and crawlers?
**Not applicable**
- The AppSec architecture incorporates standards such as OWASP Top 10 for application risks.
- WAF logs are ingested similarly to other security logs, and alerts can be triggered from them.
- Have WAF logs from all the accounts sent to a central bucket in your security account
**Not applicable**
- If AWS WAF is used, it is configured to handle rate limiting, geographic-based restrictions, and malicious user agents.
- Do you have rate based rules set up for identified paths and tested each path exceeding the threshold limit
**Not applicable**
- Do you have rate limiting for sensitive Application Paths to reduce the risk of DDoS attacks and scraping?
**Not applicable**
- Do you have geo-location or IP based whitelisting configured in your WAF?
**Not applicable**

# IAM

## Account Strategy

- AWS Account model is well designed and structured based on multi-account governance best practices. It might use Control Tower, it might be a DIY version of Control Tower, or it might be a custom approach.
- What is current AWS account model?
**We have two independent accounts, i.e., production and development (only for model training)**
- How are accounts used? (e.g., per business unit, per environment, per workload, per team)
**per team**
- How are new AWS accounts added when necessary?
**We only add an new account once to remove algorithm developer from production environment**
- What is the major rationale for account separation (security, billing, org structure)?
**security**
- Are there any accounts that don't make sense (e.g., too many unrelated services running in that account)?
**No**
- Is AWS Organizations used for multi-account governance?
**No, but we will do**
- Is AWS Control Tower or one of the Landing Zone solutions in use for consistent deployment of guardrails across all accounts owned by the customer?
**No**
- How do they detect and/or deal with AWS accounts that are created outside the official hierarchy?
**No**
- Core Accounts have been defined and secured for governance of all other accounts. These accounts are used for Shared Services, Networking, Security/Audit, Centralized Logging, etc. and are accessible only by privileged cloud architects and admins.
- Are the following Core Accounts provisioned?
- Logging account: Centralized location for central storage of Cloudtrail logs, VPC Flowlogs, Guardduty findings, Config logs, ALB logs, S3 access logs, etc.
**No**
- Security account: AWS Config aggregator, Amazon GuardDuty, and alerts.
**No**
- Shared Services account: Shared virtual private cloud (VPC) for remote connectivity to other accounts.
**No**
- Network account: Primary AWS Direct Connect setup with an AWS Transit Gateway setup to communicate with VPCs from other accounts.
**No**
- Business Unit accounts
**No**
- Sandbox/POC account for isolation testing and different security rules and policies.
**No**
- AWS Accounts are deployed through a well understood process. Consistent security controls are applied across all accounts. Guardrails are deployed across all accounts.
- Can you explain what your account request process is like?
**No**
- How are guardrails implemented for new accounts that are provisioned?
**No**
- What attributes are assigned to these accounts?
**No**
- What are the guardrails you have defined that are mandatory for all accounts?
**No**
- What guardrails do you have for specific account types (e.g., based on environment type or regulatory requirements for a workload)?
**No**
- Walk me through any automation in the implementation of these guardrails and validation that they are in place? How does one get to define and change these guardrails?
**No**
- Can you walk me through how one would get notified of any change?
**No**

## Root Account

- AWS account contacts (billing, operations, and security contacts) have been configured for account(s).
- Who are the additional account contacts (security contact) and how are they managed?
**Jerry Chen**
- Who is the current contact for new and existing accounts (an email list alias to include backup members)?
**Jerry Chen**
- Who is the current contact for the billing alerts (account-based or global-based)?
**Hsi-Wen Chen**
- Is the process to deal with the alerts an automated or manual process (e-mail alerts with escalation)?
**Email**
- AWS Billing is monitored. Alerts are set. Cost analysis via tags or other business-relevant mechanisms is performed.
- Is the detailed billing report enabled?
**Yes**
- Can you walk me through how access to Billing information is determined across your AWS account fleet?
**Yes**
- What is the mechanism by which different stakeholders get access to billing information based on their 'need to know'?
**Only CEO and RD Lead can check it**
- The AWS root user has a secure password with MFA, no access keys, and its use is limited.
- Is MFA supported/activated on accounts? Who holds the hardware/software token?
**No**
- Where is the seed/QR code stored (i.e., in a vault, safe, or external location)?
**No**
- The root account does not have access keys issued. An automated alert would fire if access keys were created for root.
- Is there a root access key?
**I don't know**
- Is the existence of root access key monitored?
**I don't know**
- Root account access (in case of emergency) is governed well. Authorized users can gain access to root if needed.
- How is the root password created and stored?
**I don't know**
- Who might need access?
**I don't know**
- How would they get access?
**I don't know**
- How would you know?
**I don't know**

## Application Access

- Secrets that grant access between systems (e.g., app to database, app to app) are governed through an automated and well understood process.
- What secrets have you identified that are subject to your lifecycle management policies?
- Database credentials, SSH key pairs, AWS Access Key Pairs, 3rd party auth tokens?
**No**
- Secrets are stored securely, protected, and encrypted.
- Is your secrets store on-premise?
**No**
- Is it in a shared services account?
**No**
- Do you have an instance of AWS Secrets Manager or SSM Parameter Store in each account?
**No**
- Access to app-level secrets is limited to just the applications and/or users who need it.
- Do you have separation of duties in place for Create, GetSecretValue, Rotate, Delete actions?
**Yes**
- Are you using identity-based IAM policies?
**Yes**
- For cross-account access to secrets, describe your resource policies on secrets. Do you have a hierarchical naming structure to further limit access to secrets?
**No**
- If you are using AWS Secrets Manager are you tagging your secrets and the IAM Roles that are permitted to actions on these secrets to implement an Attribute-based Access Control model?
**Not applicable**
- Unauthorised actions and unauthorised attempts to use secrets are detectable and can be responded to.
- What actions on secrets are you logging?
**Not applicable**
- Describe the alerting in place related to metrics around those actions and the response procedures to those alerts?
**Not applicable**
- Do you have compliance requirements for which you have audit reporting mechanisms in place?
**Not applicable**
- How do you respond to a security incident related to unauthorized access to and use of a secret?
**Not applicable**

## Human Access

- Standard identity lifecycle processes are documented/updated to add/remove human access to AWS when an employee status changes. Joiner/Mover/Leaver processes are defined.
- How is a new user added to a group (or federated role via a directory group)?
**base one their function, including admin, evops, frontend, backend, algorithm, qa
- What permissions do users have by default?
**Not any**
- What is the process to add a user to the highly privileged admin group (or federated role via a directory group)?
**No process**
- Who can recover/retrieve the stored credentials?
**Admin**
- What do you have Documented in your user access methods (console vs CLI; federation vs IAM-user) playbook?
**Yes, on gitalb**
- IAM policies are used to grant a restricted set of permissions (e.g., least privilege, deny billing changes). That is, customer-managed or AWS managed policies are used. Inline policies are not used.
- How are IAM policies created?
**Only for devops, we create a cdk-deploy-policy because it have a really great power**
- How are they used?
**Only for devops**
- Who creates them (e.g., centrally or by team or by app)?
**Centrally**
- Developers have the ability to create IAM Roles and Policies or pass IAM Roles to AWS Services, and that ability is limited carefully.
- Are there restrictions on Developer capabilities with IAM?
**Yes**
- Are these at an Account level?
**Only admin**
- Are you aware of and using IAM Permissions Boundaries?
**Yes**
- How do you test to validate over permissiveness of service roles?
**Not yet**
- How do you become aware of creation, modification, or deletion of permissions within IAM polices?
**No**
- IAM roles and policies are periodically evaluated to ensure they are reasonable, compliant, not overly broad, and necessary.
- For different Roles in an RBAC model, what are the conditions defined in your IAM policies to determine access?
- This can be by IP address, datetime, region, etc.
**No policy**
- If you are moving towards ABAC, walk me through your mechanisms for defining attributes on your Principals and Resources/Objects
**We just use RBAC**
- Access and scope permissions are reviewed periodically by people who know what is required.
- Are IAM policies and IAM tools (e.g., Last Service Accessed, IAM Credential Report) periodically reviewed (e.g., bi-annually) to ensure best practices and the principle of least privilege?
**No**
- Do you have a periodic IAM Policy recertification process in place?
**No**
- Humans use roles to access privileges.
- Are IAM role(s) used for cross-account access?
**No**
- Can you walk me through how Cross-Account Roles are defined, developed, monitored and managed?
**No**
- Strong password policy is set for AWS IAM users and humans use MFA devices to login.
- What is the IAM password policy complexity (i.e., how many letters, numbers, special characters, minimum size)?
**We employ aws default password policy**
- How are passwords created? How is the password rotated?
**Every 3 month**
- Identity federation (using corporate identity directory) is used for identity and account management to cloud service provider.
- Is identity federation used for unified user management?
**No**
- Is SAML used for user management?
**No**
- Is AWS Organizations used?
**No**
- Humans who access internal applications use a centralised and well managed identity service.
- How is access provisioned for internal business applications, operating systems, databases?
**No**
- Can you walk me through your Single Sign-On process?
**No**
- System (OS, DB and other infrastructure-level) administrator credentials are strong or managed by a directory, and not shared.
- How are administrator credentials used for instance administration?
**No**
- Are they federated? Are they individually assigned or shared?
**No**

## System Access

- IAM Roles are used for resources (e.g., EC2 Instances, ECS Tasks, Lambda) that need access to the AWS platform.
- Are roles created for lambda, EC2, and so on?
**Yes**
- How are they managed?
**We defined them in CDK**
- IAM access keys (access key and secret key), if they exist, are rotated regularly and unused keys are removed.
- How are access keys created? What is the access ket rotation process?
**No**
- What non-AWS entities (e.g., backups, on-prem systems) have access to AWS resources (e.g., S3, DynamoDB)?
**Yes, we download data from s3 via the aws access key**
- IAM credentials are not hardcoded into scripts, source code, or instance user data.
- How are IAM user credentials generally stored?
**Own by each user**
- Are IAM credentials hardcoded anywhere?
**No**
- What does customer do to scan source code repositories or app configurations to make sure no credentials are hardcoded?
**Yes, we use pre-commit hook to check it**
- AWS resources and non-AWS resources (e.g., on-prem) that need access to data have that access regulated through AWS IAM policies and AWS IAM roles.
**Yes**

# Detective Controls

## Audit Model

- A global CloudTrail Trail has been enabled on all account(s) and logged in a central aggregation bucket.
- How do you audit your AWS resources and API calls?
**No**
- Is CloudTrail enabled on all regions and all accounts?
**No**
- Security related findings from the AWS environment are ingested in a standard way and reviewed/alerted as a normal business process.
- Do you ingest logs from your central logging account into a SIEM?
**No**
- Are you using any native AWS services such as an ElasticSearch or AWS Security Hub?
**No**
- CloudTrail is actively monitored for critical API events and anomalies (e.g., CloudTrail being disabled, root user activities).
- Are metrics defined for critical API events?
**No**
- Will anomalies monitored via CloudTrail trigger alarms?
**No**
- Billing alerts are set up to alert on unusal spending.
- Are billing alerts turned on? By region? By service?
**Whole account**
- Who would see them?
**DeVops**
- How would they respond?
**Open a ticket and try to figure it out by services**
- Regular assessments of the cloud security are performed. Their results are tracked and addressed as appropriate.
- Do they use Prowler? ScoutSuite? Cloud Custodian?
**No**
- Any kind of systematic check for security misconfigurations or issues?
**No**
## Logging Model

- Centralized security event logging system is used to ingest cloud-native logs like CloudTrail, CloudWatch Logs, CloudWatch Events etc.
- Describe the current auditing/logging model.
**No**
- What is the standard procedure for logging?
**No**
- What level of logging is enabled? (Cloud services, OS, application).
**Application**
- Where are the logs stored? (Centrally or locally?)
**Centrally**
- How long are the logs stored for?
**Debuggung**
- Key cloud service native logs (i.e., ELB logs, S3 logs, CloudFront logs for Lambda) have been enabled where they make sense.
- What services have logging enabled?
**Lambda, Sagemaker**
- What services should be logging?
**We check it via cloudwatch log group**
- How do you verify that services have logging enabled?
**Lambda, Sagemaker**
- What is the minimum logging level?
**Error, Warning, Info**
- Key cloud network logs (i.e., VPC Flow Logs, VPC Traffic Mirroring) are enabled where they make sense.
- What network-level security mechanisms are enabled? (Firewall, VPC Flow Logs, VPC Traffic Mirroring)
**Not Applicable**
- What kinds of network devices/transit points are monitored and why?
**No Applicable**
- What kinds of network misbehaviour can be detected?
**No Applicable**
- Sanitized logs are accessible to appropriate staff (SOC analysts, incident responders, project teams) when needed.
- Is there a security operation center (SOC) service? Do the logs need to be normalized? Anonymized?
**No**
- Does the SOC staff have appropriate training/knowledge to interpret cloud-native service logs or cloud-related security alerts?
**No**
- Log retention policies are in place and automatically delete/retain logs according to policy.
- What log retention policies are in place or required by regulation?
**We do not define the policies**
- What kind of logs are stored and retained?
**No**
- Can you walk me through your log retention process?
**No**

## Monitoring Model

- System monitoring tools (e.g., CloudWatch, CloudWatch Logs and third-party solutions) are enabled and monitored for anomalies.
- How do you implement infrastructure incident/performance monitoring?
**Cloudwatch with SageMaker Autoscaling group**
- What tools are used?
**Cloudwatch, Autoscaling, SES**
- What about monitoring metrics you have used?
**Backlog for the data and process time**
- Application monitoring tools are used to monitor application logs and performance. Security can be notified of unusual application-level activity.
- How do you implement application system incident/performance monitoring?
**We do not monitor the perfromance. We only check whether a data is process correctly.**
- What tools are used?
**Cloudwatch, SES**
- Database activity monitoring is used for databases that contain sensitive data. Security can be notified of unusual database activity.
- How are databases monitored for security issues (e.g., performance, unauthorised access, misuse)?
**Not applicable**
- What tools are used?
**Not applicable**
- Cloud resources are monitored (via AWS Config Rules, AWS Partner tools, etc.) for unexpected changes that violate security policy (e.g. S3 bucket policy changes).
- Are any resource monitoring solutions used (i.e., CloudWatch, Marketplace solutions)?
**No**
- Is AWS Config used to monitor changes?
**No**
- AWS Config has been enabled on all account(s) and recorded to a central bucket, in order to capture and identify changes to common AWS resources.
- How are AWS Config Rules generated and reviewed?
**No**
- How is Config configured for central management?
**No**
- Certificates are being proactively monitored for renewal before expiration, or auto-renewal systems have been implemented.
- How is a TLS certificate reviewed in case of expiration?
**Not applicable**
- What's the process to renew the certificate?
**Not applicable**

# Incident Response

## Availability

- High availability architecture is planned and implemented at infrastructure level.
- How many AWS Availability Zones does the application use?
**Not appicable**
- How is the application architected for high availability?
**Not appicable**
- Is a load balancer used for multi-AZ deployment?
**Not appicable**
- High availability architecture is planned and implemented at application level.
- How is application level high availability achieved? Is a loose-coupling approach designed in the application? Is server-less architecture in use? Is the application designed with API-driven interfaces?
**Not appicable**
- Mechanisms and plans are in place to respond to volumetric attacks (e.g., DDoS, DNS backscatter).
- How are volumetric attacks handled? How is DNS run? Could DNS handle the load? What kind of geographic restrictions can be applied during an attack? What kind of rate limiting can be applied during an attack? Has any of this been tested?
**Not appicable**

## DevSecOps

- Security uses a pipeline: The security team deploys security controls across the account ecosystem using CI/CD, or some other source control oriented deployment method.
- Is customer deploying application with CI/CD? Are any CI/CD tools used by customer? Is security a part of DevOps process? How?
**CI is gitlab, but we deploy manually every week.**
- Security in the pipeline: when application teams deploy applications as code, there is a security check that is part of the pipeline (e.g., cfn_nag, code scanner).
- Is the customer deploying infrastructure via code?
**Yes**
- What tools are used? (e.g., CloudFormation, Terraform, Fugue)
**CDK**
- Security errors can "break the build" or prevent release.
- Are security checks in the code at the same high priority as functional checks?
**No**
- If a security check fails does the build fail?
**Yes**
- How thorough and wide-ranging are the security checks in the pipeline?
**Only package scaning**
- Security of the pipeline: The security team is involved in securing the pipelines themselves (e.g., Jenkins, CodeBuild). The permissions associated with committers, approvers, releases, etc. are appropriate.
- Who has privileges to approve releases?
**CEO (Jerry Chen) and DevOps Lead (Yao-Hua Yang, Hsi-Wen Chen)**
- Who can commit code?
**All DevOps memebers**
- Who can approve a package to be stored in the production repository?
**We do it in our CI (maybe devops lead?)**
- How much of this is the security team involved in?
**No**
- How much is left to the discretion of the dev teams?
**They can only develop the algorithm; the DevOps will ensure the rest of the stuff**
## Incident Response

- Incident response runbooks that handle cloud incidents exist.
- Is there a plan to respond to anomalies on the EC2 operating system or application?
**No**
- Is there a process to deal with compromised account credentials, etc.?
**No**
- Incidents are investigated using cloud-native and app-appropriate methods. Enough information is available to the right people to determine scope, time, and impact of security incidents.
- What log sources and data sources are available for security investigations?
**Cloudwatch log**
- How long are they available?
**by default (I thinks it wiil be retained forever??)**
- Have security people done investigations before?
**No**
- Were they successful?
**Not applicable**
- Emerging and novel threats are periodically incorporated into the incident response strategy / playbook
- Do you do threat models for important applications?
**No**
- Do you subscribe to an external threat intel feed?
**No**
- Do you engage in threat hunting?
**No**
- Do you keep up with new security services and new AWS security features?
**No**
- Incident response leverages cloud-native automation and can be triggered automatically by events.
- Does security have software development skills?
**Not applicable**
- What tools do the security/IR team use to automate responses?
**Not applicable**
- Who writes lambda functions or other AWS-specific incident response functions?
**Not applicable**
- Metrics are tracked and analyzed to evaluate the effectiveness of the IR process (e.g., time to response from detection/notification, time to quarantine, number of incidents per workload per time period, percent of incidents where root cause was not determined, percent of incidents attributed to common root causes).
- Is there any tool to monitor/notifications?
**No**
- Is there any SLA defined to evaluate the effectiveness of IR process?
**No**
- The appropriate level of AWS Support has been purchased to support the business objectives and security requirements (e.g., Developer, Business, Enterprise) for responding to security events.
- What level of AWS support is in place?
**Business**
- What's the process to get AWS support involved when incident happens?
**Help us to debug**
- Incident response capabilities and runbooks are tested periodically, through tabletop exercises or gamedays/simulations. Post-mortem mechanisms and improvement processes are implemented after the exercise or simulation.
- How often is the incident response (IR) plan reviewed and tested?
**Monthl (in infra meeting)**
- Is there any simulation to test the IR plan and capability?
**No**

# AWS Services

## Infrastructure Services

- [ ] Amazon CloudFront
- [ ] Amazon CloudTrail
- [ ] Amazon Config
- [ ] Amazon Config Rules
- [ ] Amazon EC2
- [ ] Amazon Route53
- [x] Amazon S3
- [ ] Amazon VPC
- [ ] AWS API Gateway
- [x] AWS CloudFormation
- [x] AWS Lambda

## Security Services

- [x] Amazon CloudWatch Events
- [x] Amazon CloudWatch Logs
- [ ] Amazon Detective
- [ ] Amazon GuardDuty
- [ ] Amazon Inspector
- [ ] Amazon Macie
- [ ] Amazon Security Hub
- [ ] AWS Certificate Manager
- [ ] AWS CloudHSM
- [ ] AWS Control Tower
- [ ] AWS Firewall Manager
- [ ] AWS Key Management Service
- [X] AWS Organizations
- [ ] AWS Resource Access Manager
- [ ] AWS Secrets Manager
- [ ] AWS Systems Manager
- [ ] IAM Access Analyzer
- [ ] AWS Service Catalog
- [ ] AWS IoT Device Defender
- [ ] AWS Lake Formation
- [ ] AWS Fraud Detector