Best Security Practices for the iNetwork Application@ www.ramittal.com

Introduction

This document provides the in-depth security measures taken to secure the workloads for iEvent Application.

Stakeholders include Internal Audit Leaders, Security Architects, Engineers, Chief Information Security officers, and Chief Customer officers.

SOP Revision table

SOP Description	Version	Last Updated Date	Last Updated By
Initial Draft	1.0	16 Jan 2023	Rahul Mittal
Added Backup and Disaster Recovery	1.1	14-Aug-2023	Rahul Mittal

---

This document will cover the following topics

1. Security measures for iEvent Application.

2. FAQs for customers sharing data with iEvent Application.

3. Security Perspective: Compliance and Assurance

The security perspective helps us achieve confidentiality, integrity, and availability of iEvent Application data and cloud workloads.

---

It comprises the capabilities given below. (REF: CAF Framework.)

Security Governance
Threat Detection
Data Protection
Security Assurance
Vulnerability Management
Application Security
Identity and Access Management
Infrastructure Protection
Incidence Response

• Implement a segregated account environment
• Identity and Access Management
• Infrastructure Security
• Data Security
• Application Security
• Logging, Monitoring and Auditing
• Incident Response

4. Implement a Landing Zone using AWS Control Tower

• Data Protection
  • Encryption at Rest
  • Encryption in Transit
  • Restrict Access to Content
• Identity and Access Management
  • Authentication – AWS SSO
  • Access Control – Identity Access Management Federation
  • Managing Access Permissions to AWS Control Tower resources
  • Prevent Cross Service impersonation
  • Using IAM policies for AWS Control Tower
• Compliance Validation
  • Architecting for HIPAA, SOC and PCI security.
• Resiliency
• Infrastructure Security
  • Accessing multiple accounts in the AWS Control Tower environment
  • Creating the Auditor user in AWS SSO to provide read-only access to all AWS accounts
  • Manage Control Tower Tasks
  • Dashboard – Manage summary of Control Tower Environment
  • Organization Units – Add/Delete/Register/Re-Register OU
  • Accounts – Manage account details and state
  • Account Factory – Edit Network configuration for new accounts and enroll/invite accounts
  • Guardrails – Manage guardrails for each OU.
  • User and Access – Manage details for AWS SSO integration
  • Shared Accounts – Management, Log Archive and Audit
  • Landing Zone – Manage starting point for each Account on OU
  • Logging and Monitoring of Control Tower resources

---

SECTION 1: iEvent Application – Security measures

Physical access controls.

Physical access to the iEvent application’s infrastructure is restricted to only myself, as I am the sole individual involved and responsible for its operation. My home office, where the application is hosted, is secured using basic security measures such as locked doors and windows. Only authorized personnel (myself) are allowed entry into the premises. This ensures that no unauthorized individuals can physically access the infrastructure hosting the iEvent application.

Furthermore, the physical security of the equipment hosting the iEvent application is enhanced by maintaining the confidentiality of access information and not sharing it with anyone. This minimizes the risk of unauthorized access to the infrastructure.

System access controls.

The iEvent Application employs a comprehensive and layered security strategy for managing access to its information systems. This approach involves the implementation of robust security practices, including the utilization of strong and secure passwords, Role-Based Access Control (RBAC) mechanisms, Multi-Factor Authentication (MFA), and Single Sign-On (SSO) solutions to facilitate secure system access.

Data access controls.

User management within the iEvent Application is facilitated through Microsoft Active Directory, ensuring effective control over user identities. Access to resources is then governed by group access policies, bolstered by Multi-Factor Authentication (MFA) within the iEvent Application for an added layer of security.

Data access is channeled through AWS Workspaces, providing a secure environment for users to interact with the data. The data itself resides within AWS S3 buckets, connected through Storage Gateway File shares. Importantly, none of the received data is directly reachable over the Internet without undergoing stringent authentication and authorization processes. This approach safeguards the data from unauthorized access and reinforces its security posture.

Furthermore, customer data is securely stored within a MySQL database. This database employs encryption at rest, ensuring that sensitive information remains protected even when stored. To enhance security, the MySQL database is situated within a private Virtual Private Cloud (VPC), further isolating it from external access and potential threats.

This multi-layered approach to data storage and access control ensures that customer data is comprehensively protected throughout its lifecycle, from storage to user interaction.

Transmission controls.

Once data is securely stored within iEvent Application Managed AWS S3 buckets, its access is orchestrated through HTTPS/TLS-based protocols, ensuring robust encryption both at rest and during transmission.

1. Data traversing the network is achieved through AWS Storage Gateway, employing S3-Managed Keys (SSE-S3) – a 256-bit Advanced Encryption Standard (AES-256) encryption mechanism for file shares. The Storage Gateway system employs SSL/TLS (Secure Socket Layers/Transport Layer Security) protocols to encrypt data while in transit between the gateway appliance and AWS storage. By default, Storage Gateway integrates Amazon S3-Managed encryption keys (SSE-S3) to enact server-side encryption for all data held within Amazon S3.
2. Additionally, AWS CLI v2 is utilized for data transfers between buckets, whether internally or across different accounts. This process employs a minimum of TLS 1.2, further enhancing the security of data transmission.

These measures collectively ensure that data is not only safeguarded during storage but also remains protected as it moves through various network pathways, maintaining its confidentiality and integrity throughout its journey.

Should you require further clarification or assistance with other sections of the security assessment form, please feel free to let me know.

Input controls.

The iEvent Application is constructed using the latest Angular framework for the front-end, Spring Boot for backend services, and AWS Lambdas for middleware functions. The architecture incorporates various input controls to fortify the security of the application against potential vulnerabilities.

1. Front-end Input Validation (Angular Framework): Within the Angular front-end, input validation is implemented to ensure that data entered by users adheres to expected formats and limits. This prevents unauthorized data injection, cross-site scripting (XSS), and other common input-related attacks. Validation rules are enforced both on the client side to provide a seamless user experience and on the server side to prevent tampering with data before it reaches backend services.
2. Backend Input Validation (Spring Boot): The Spring Boot backend applies thorough input validation to incoming requests. This includes sanitizing and validating data received from clients to prevent SQL injection, parameter manipulation, and other forms of data tampering. By implementing strict validation routines, the application mitigates risks associated with malformed or malicious input.
3. AWS Lambda Middleware Validation: Middleware services, powered by AWS Lambdas, also enforce input validation before processing requests. This validation layer helps maintain the integrity of data flowing between the frontend and backend, reducing the potential for attacks that exploit unvalidated input.
4. Data Storage and Retrieval (MySQL and AWS S3): As data is stored in the MySQL database and images are stored in AWS S3 buckets, input controls extend to the data stored and retrieved. All interactions with the database and S3 buckets involve input validation checks to thwart potential attacks like SQL injection or unauthorized data access.
5. File Upload Handling (Angular and AWS S3): If the application allows users to upload images to AWS S3, comprehensive input validation is enforced on both the front-end and the backend. This prevents malicious file uploads and ensures that only authorized file types and sizes are accepted.

By implementing stringent input controls throughout the application’s architecture, from front-end interfaces to backend services, middleware, and data storage interactions, the iEvent Application ensures that user input is thoroughly validated and sanitized. These measures significantly reduce the risk of input-based security vulnerabilities and bolster the overall security posture of the application.

Data backups.

The iEvent Application employs a robust data backup strategy to ensure the integrity, availability, and recoverability of critical data. This strategy encompasses various layers of backup mechanisms to safeguard against data loss and unforeseen incidents.

Documentation and Incident Response: The data backup strategy is thoroughly documented, including backup schedules, retention policies, restoration procedures, and contact information for key personnel involved in data recovery. In the event of a data loss incident, a well-defined incident response plan is enacted to swiftly restore data from backups and minimize downtime.

Regular Database Backups (MySQL): The application’s MySQL database, housing essential data, is subject to routine backups. Regular automated backups are scheduled at defined intervals to capture changes and updates to the database. These backups are securely stored in a designated location, ensuring that historical data can be recovered in case of database corruption, accidental deletions, or other unforeseen events.

Image Data Backups (AWS S3): Images stored in AWS S3 buckets are also included in the backup strategy. Incremental backups of image data are taken regularly to capture changes and additions. These backups are stored within the AWS environment, leveraging the built-in redundancy and durability features of AWS S3 to safeguard against data loss.

Backup Retention and Lifecycle Management: Backup retention policies are established to manage the lifecycle of backups efficiently. This ensures that a reasonable history of backups is maintained, allowing for point-in-time recovery if necessary. Older backups are pruned according to a predetermined schedule to optimize storage usage while retaining adequate coverage.

Geographic Redundancy: To enhance data durability and availability, backup copies are often stored in geographically separate regions or availability zones. This approach guard against regional outages or disasters, providing an additional layer of resilience.

Backup Testing and Restoration: Periodic testing of backup restoration processes is conducted to validate the integrity of backups and the ability to restore data effectively. These tests help ensure that backups are reliable and can be used for recovery purposes when needed.

Encryption and Access Controls: Backups are encrypted to maintain data confidentiality during storage. Access controls and permissions are meticulously managed to prevent unauthorized access to backup copies.

By implementing this comprehensive data backup strategy, the iEvent Application ensures that critical data is shielded from loss and can be restored efficiently in the face of unexpected disruptions or emergencies.

Data segregation.

The iEvent Application meticulously adheres to a robust data segregation policy, ensuring the separation of various types of data to prevent unauthorized access, maintain data integrity, and comply with data protection regulations.

1. Logical Segregation: a. User Data Isolation: Data associated with different users is kept separate at both the application and database levels. Each user’s information is uniquely identified and isolated from other users’ data, preventing data leakage and unauthorized access. b. Functional Separation: Data associated with different functions of the application is segregated to prevent unintended access. This ensures that user-generated content, system configurations, and application logs are isolated from one another.
2. Database Segregation: a. MySQL Database Schemas: Different categories of data, such as user profiles, event information, and application logs, are stored within separate database schemas. This segregation ensures that data remains organized and distinct, minimizing the risk of data leakage or unintended cross-interaction.
3. Storage Isolation: a. AWS S3 Buckets: Images and various application-related files are stored within dedicated AWS S3 buckets, with access controls configured to limit exposure. This segregation prevents unauthorized parties from accessing sensitive images or documents.
4. Access Controls: a. Role-Based Access Control (RBAC): Users are assigned specific roles based on their responsibilities within the application. RBAC restricts access to only the data and functionality necessary for their tasks, preventing unnecessary exposure. b. Least Privilege Principle: Access permissions are granted at the minimum level required for users to perform their functions. This principle ensures that users only have access to the data they need and nothing more, reducing the potential for accidental or intentional misuse.
5. Data Classification: a. Sensitive Data Identification: Data is classified based on its sensitivity and regulatory requirements. Confidential data, personal information, and other sensitive information are identified and treated with additional security measures.
6. Data Retention and Purging: a. Retention Policy: A defined data retention policy outlines the duration for which specific types of data are stored. This policy helps manage storage costs and ensures that data is not retained longer than necessary. b. Data Purging: Once data reaches the end of its useful life, it is systematically purged from the system in accordance with legal and regulatory requirements. This prevents unnecessary storage of outdated or obsolete information.

By adhering to this comprehensive data segregation policy, the iEvent Application ensures that data remains isolated, secure, and properly managed throughout its lifecycle, supporting data privacy, regulatory compliance, and overall security objectives.

---

SECTION 2: FAQs for customers sharing data with iEvent Application

1. Where will Customer data be hosted by iEvent Application? Is it a cloud-based hosting solution or is it within the data center of the iEvent Application? The customer data for the iEvent Application is hosted within a cloud-based environment. Specifically, the application is hosted on Amazon Web Services (AWS). The AWS cloud infrastructure provides the necessary resources to host the application’s frontend (Angular), backend (Spring Boot), middleware services (AWS Lambdas), as well as the storage solutions (MySQL database and AWS S3 buckets) for data and images. Additionally, the application’s hosting is configured within a Virtual Private Cloud (VPC) on AWS, which enables a private and isolated network environment for enhanced security and control.AWS offers a comprehensive set of services and features that align with the iEvent Application’s hosting requirements, ensuring scalability, flexibility, and security for customer data. This cloud-based hosting solution allows the iEvent Application to efficiently manage its infrastructure, data storage, and application components while leveraging the benefits of AWS’s extensive global network and resources.
2. Provide a summary/description of their data hosting solution? The iEvent Application’s data hosting solution is built upon a cloud-based infrastructure, specifically leveraging Amazon Web Services (AWS), to ensure a robust, scalable, and secure environment for hosting its various components. This cloud-based setup provides the foundation for the application’s frontend, backend, middleware, and storage needs.Frontend Hosting (Angular): The frontend of the iEvent Application, developed using Angular’s latest framework, is hosted on Amazon S3. This allows for efficient distribution of static web content to users, enhancing the application’s performance and availability.Backend Hosting (Spring Boot and Node.js Lambda): The backend services are divided between Elastic Compute Cloud (EC2) instances for Spring Boot-based services and AWS Lambda for Node.js-based services. EC2 instances offer scalable compute capacity for hosting the Spring Boot backend components, while AWS Lambda provides a serverless environment for executing Node.js functions in response to events.Database Hosting (MySQL): Customer data is securely stored within a MySQL database, ensuring data integrity and persistence. The database is managed within the AWS ecosystem, benefiting from AWS’s infrastructure and security features.Image and Content Hosting (AWS S3): Images, videos, and other files shared by users are hosted on Amazon S3 buckets. This content storage solution ensures easy access, efficient delivery, and scalability as the application’s user base grows.Messaging and Notification Services (SES, SNS, SQS): AWS Simple Email Service (SES) facilitates secure and reliable email communication with users. Simple Notification Service (SNS) enables effective push notifications to various endpoints, while Simple Queue Service (SQS) manages message queues for decoupled communication between components.Domain Management (Route 53): Amazon Route 53 is utilized for domain management, providing scalable and reliable DNS services to direct users to the application’s resources with high availability.The integration of these AWS services, including SES for email communication, SNS for notifications, SQS for message queuing, Route 53 for domain management, and the strategic use of EC2 instances and AWS Lambda functions, ensures a comprehensive data hosting solution. This solution guarantees a high level of security, scalability, and flexibility for the iEvent Application, supporting its frontend, backend, middleware, and storage requirements within a cloud-based environment.
3. Who are the users of the iEvent Application that will have access to Customer data? The users of the iEvent Application who will have access to customer data include the following roles:
   1. Registered Users (Event Organizers and Attendees): These are individuals who have registered on the iEvent Application to either organize events or participate as attendees. Event organizers may have access to customer data to manage event details, communicate with attendees, and analyze event metrics. Attendees may access their own personal event information and interact with event-related content.Administrators: Administrators are individuals responsible for managing and overseeing the application’s functionality, security, and user accounts. They may have access to customer data for troubleshooting, user support, and ensuring the application’s proper operation.Support and Customer Service: Support and customer service personnel may access customer data to assist users with inquiries, troubleshooting, and resolving issues related to the application. This access helps provide timely and effective assistance to users.Technical Team: Technical personnel, including developers and system administrators, may require access to customer data for maintenance, updates, and troubleshooting purposes. This access ensures the application’s continuous operation and technical health.
   It’s crucial to implement role-based access controls (RBAC) to ensure that each user role only has access to the data necessary for their specific tasks and responsibilities. By enforcing RBAC, the iEvent Application can mitigate the risk of unauthorized data access and maintain data privacy for customers.
4. Will any third-party users of the iEvent Application also have access to Customer data? The hosting and data storage components are mainly managed within the AWS environment, with data segregation and access controls in place. The application’s functionality seems to primarily revolve around event management and attendee interaction.
5. Does the external party perform periodic user access verification to ensure only authorized users have access to Customer data? The architecture mainly consists of AWS services and components, and user access controls are primarily governed by the application’s design and implemented security measures. Furthermore, AWS has implemented various tools and services to enhance the security and monitoring of the iEvent Application’s environment:
   • AWS Trusted Advisor: AWS Trusted Advisor analyzes the application’s AWS environment for best practices and provides a comprehensive report that covers areas such as cost optimization, security, performance, and fault tolerance. This service helps ensure that the architecture aligns with AWS’s recommended security configurations and practices.
   • AWS Inspector: AWS Inspector is a security assessment service that automatically assesses the application’s resources for vulnerabilities, potential security issues, and deviations from security standards. It provides detailed findings and recommendations to help address security risks proactively.
   • Amazon Macie: Amazon Macie is a security service that uses machine learning to automatically discover, classify, and protect sensitive data stored in AWS. It helps identify security risks by analyzing data access patterns and generating alerts for potential unauthorized access or data exposure.

These tools contribute to maintaining a secure environment by proactively identifying and addressing vulnerabilities and security gaps. If implemented and configured effectively, they can help mitigate risks and ensure that only authorized users have access to customer data.

6. After receiving Customer data, is this data always encrypted when at rest?

Absolutely, customer data is safeguarded through secure storage mechanisms across a range of platforms. This includes employing AES encryption on Elastic Block Store (EBS) volumes, MySQL databases, and AWS S3 buckets when the data is at rest. Notably, both MySQL databases and S3 buckets, alongside their corresponding EBS volumes, are fortified with the utilization of the industry-standard AES-256 encryption algorithm. This rigorous approach not only amplifies data protection but also guarantees the confidentiality of sensitive information, irrespective of its dormant state.

7. After receiving Customer data, is this data always encrypted when sent over the network to other systems and applications that will be processing this data?

Certainly. Upon storing the data within the iEvent Application Managed AWS S3 buckets, its retrieval employs HTTPS/TLS-based protocols, ensuring encryption both at rest and during transit.

1. For network-based data access, AWS Storage Gateway serves as an intermediary, utilizing S3-Managed Keys (SSE-S3) – a robust 256-bit Advanced Encryption Standard (AES-256) encryption scheme for file shares. The Storage Gateway system deploys SSL/TLS (Secure Socket Layers/Transport Layer Security) protocols to encrypt data during its journey between the gateway appliance and AWS storage. By default, Storage Gateway incorporates Amazon S3-Managed encryption keys (SSE-S3) to enforce server-side encryption for all data stored within Amazon S3.
2. The utilization of AWS CLI v2 for inter-bucket data transfers, whether within the same account or across different accounts, is another measure to maintain encryption. AWS CLI version 2 employs an internal Python script that is compiled to ensure a minimum TLS 1.2 connection for secure transmission.

This layered approach guarantees that customer data remains encrypted throughout its transit, bolstering its security and confidentiality.

Additionally, access to both S3 data and API data is strictly limited to authenticated and authorized users. AWS Security Token Service (STS) plays a role in this, generating short-lived credentials that are valid for a duration of 60 minutes. These credentials are used for accessing S3 data and APIs, enhancing security by limiting the lifespan of access tokens.

Furthermore, on the API front, security is upheld through Identity and Access Management (IAM) based mechanisms. API calls are only permitted for users possessing appropriate IAM permissions, ensuring that only authorized actions are executed.

This comprehensive approach, involving encryption, time-bound access tokens, and IAM-based security, reinforces the protection of customer data at various stages of transit and interaction.

8. Will users of iEvent Application have access to Customer data directly over the Internet?

No customer data can be directly accessed over the internet without undergoing the necessary authentication and authorization procedures. User access to the data will primarily occur through workspaces, where data is made accessible via Storage Gateway File shares. Additionally, users with the required permissions can also access the data within the AWS Console through bucket access to Amazon S3.

9. Do the users of iEvent Application have multifactor authentication when accessing Customer data directly over the Internet?

Certainly, MFA is enforced.

10. Will users of iEvent Application with administrative privileges have access to the infrastructure hosting Customer data over the Internet?

Users of the iEvent Application with administrative privileges won’t have direct access to the infrastructure hosting Customer data over the Internet. Access to such infrastructure is meticulously controlled and managed to maintain security and confidentiality.

11. Do users of iEvent Application with administrative privileges have multifactor authentication when accessing the infrastructure hosting Customer data over the Internet?

Indeed, users possessing administrative privileges within the iEvent Application are mandated to undergo multifactor authentication (MFA) when seeking access to the infrastructure that hosts Customer data over the Internet. This additional layer of security enhances the protection of sensitive information and reinforces the integrity of the system.

12. Does iEvent Application perform a periodic vulnerability assessment of all systems present within their data hosting environment?

Absolutely, the iEvent Application employs a comprehensive approach to vulnerability assessments by utilizing automated tools such as AWS Trusted Advisor and Amazon Macie. These tools work in tandem with regular assessments to ensure the robustness of all systems within the data hosting environment.

By integrating AWS Trusted Advisor, the application benefits from automated checks that analyze various aspects of its infrastructure, including security, cost optimization, and performance. This contributes to the identification of vulnerabilities and potential issues, allowing the iEvent Application to proactively rectify any security gaps.

Furthermore, the inclusion of Amazon Macie enhances the vulnerability assessment process by automatically detecting and classifying sensitive data stored within AWS, thereby aiding in the identification of potential vulnerabilities related to data exposure.

In combination with regular assessments, AWS Trusted Advisor and Amazon Macie contribute significantly to maintaining the integrity and security of the iEvent Application’s hosted systems, safeguarding customer data and bolstering its protection against potential threats.

13. Does the iEvent Application perform monitoring of security-related events (such as failed login attempts, data transfer to unknown IP addresses, etc.) for all the systems present within their data hosting environment?

Absolutely, we’ve established a robust security monitoring approach. To achieve this, CloudTrail logs have been enabled to meticulously track activities associated with system access. The management of system access is meticulously handled through security groups, ensuring controlled and authorized entry. It’s important to note that data is exclusively accessible to workspaces and systems within a private Virtual Private Cloud (VPC), further augmenting security measures.

Moreover, to bolster authentication, multifactor authentication (MFA) is implemented for logins. Only authorized users are granted access to the AWS console, and this access is intricately tied to AWS security mechanisms. These measures collectively contribute to a proactive security stance, enhancing the iEvent Application’s ability to identify and respond to security events swiftly and effectively.

Additionally, AWS Shield is leveraged to bolster security through IP filtering. This service works to safeguard against Distributed Denial of Service (DDoS) attacks, enhancing the application’s resilience against external threats.

14. What is the data backup solution that will be used by iEvent Application? Is Customer backup data encrypted?

The iEvent Application employs a comprehensive data backup strategy that encompasses multiple layers of protection. MySQL databases and application instances are subjected to scheduled backups, ensuring data resilience.

In specific terms, the data is transferred to the AWS S3 standard Storage tier. Renowned for its exceptional durability, this tier boasts an impressive 11 nines of durability and is replicated across three Availability Zones (AZs), guaranteeing data availability.

To optimize storage efficiency and meet long-term retention requirements, the implementation of an archival policy is pivotal. This policy involves the systematic migration of data to the AWS S3 Glacier tier, known for secure and cost-effective cold storage over extended periods.

Importantly, the commitment to security remains unwavering. Both within AWS S3 and the Glacier storage tiers, the data is fortified with encryption mechanisms to thwart unauthorized access. This rigorous practice ensures that customer backup data remains confidential and unaltered throughout its storage lifecycle.

15. How is patch management managed by iEvent Application for all the systems that are present within their data hosting environment? Currently, patch management for all the systems within the iEvent Application’s data hosting environment is conducted manually. This process involves identifying the relevant security patches and updates for the various components and systems in use. Subsequently, the iEvent Application’s team performs the necessary installations and configurations to ensure that the systems are up to date and fortified against potential vulnerabilities.
16. Can you please specify the geographical jurisdiction of the data?

The data will be situated in the US East (N. Virginia) region, specifically us-east-1 within North America. Additionally, there are plans to implement data replication in a different region, such as ap-south-1, for the purpose of Disaster Recovery.

---

SECTION 3: Security by Design Principles

The following principles are followed to strengthen the workload security in AWS.

1. Implement a segregated account environment
2. Identity and Access Management
3. Infrastructure Security
4. Data Security – in transit and at rest
5. Application Security
6. Logging, Monitoring and Auditing
7. Incident Response – prepare for security events

1. Implement a segregated account environment: Currently, we have 3 accounts segregated based on workloads.

1. iEvent Application Production account – Production-WorkLoads
2. iEvent Application UAT Account – UAT-WorkLoads
3. iEvent Application Dev Account – DEV-WorkLoads

The Structure of a new landing zone for the current AWS management account is as follows.

• Root – The parent that contains all other OUs in the iEvent Application Landing zone.
  • Infrastructure: Used for shared infrastructure services such as networking and IT services. Create accounts for each type of infrastructure service you require.
  • Security: Used for security services. Create accounts for log archives, security read-only access, security tooling, and break-glass.
  • Sandbox: Holds AWS accounts that individual developers can use to experiment with AWS Services. Ensure that these accounts can be detached from internal networks and set up a process to cap spending to prevent overuse.
  • Workloads: Contains AWS accounts that host your external-facing application services. You should structure OU’s under SDLC and Prod environments (like the foundational OU’s) to isolate and tightly control production workloads.

IAM Identity Center directory – AWS IAM Identity Center (successor to AWS SSO) is used to manage the initial relatively limited number of human users across your builder and cloud foundation teams who need to access the AWS Management Console and AWS APIs to get things done in either team development AWS accounts or in support of managing and operating the overall use of AWS.

Within iEvent Application we have implemented Federated Access with Azure AD to sync users and roles.

2. Identity and Access Management: Ensure only authenticated and authorized users can access resources:

1. Define users, groups, services and roles
2. Protect AWS credentials
3. Use Fine-grained authorization/access control

1. Define users, groups, services and roles

Users: SAML 2.0-based SSO implemented with Azure AD

Groups: Within iEvent Application we have the following foundation roles for AWS in Azure-AD.

1. Cloud Administration: Write access to cloud foundation resources.
   1. AWSAccountFactory – Users that can provision new accounts in AWS Service Catalog.
   2. AWSControlTowerAdmins – Administrator rights to all AWS Control Tower accounts.
   3. iEvent ApplicationCloudAdmin – Administrator access to all other AWS accounts.
2. Security Administration: Write access to cloud foundation security resources.
   1. AWSAuditAccountAdmins – Full access administrator rights to the audit account.
   2. AWSLogArchiveAdmins – Full access administrator rights to the log archive account.
   3. AWSSecurityAndComplainceGroup – Full access to administrator rights to both Audit and Log Archive accounts.
3. Cost Management: Write access to cost budgets and reporting.
   1. AWSFinanceGroup – Billing and cost management access in the management account.
4. Audit: Read Only access to all AWS resources.
   1. AWSSecurityAuditPowerUsers – Power user access to all accounts for security audits.
   2. AWSSecurityAuditors – Read-only access to all accounts for security audits.
5. Other Roles
   1. AWSLogArchiveViewers – Read-only access to the log archive account.
   2. AWSServiceCatalogAdmins – Users that manage access to the account factory product in AWS Service Catalog.
   3. AWSBuilderGroup – Users who will be setting up infrastructure on AWS accounts.
6. Workload-based roles – Roles created for users running workloads in AWS.
   1. AWSSagemakerUserGroup
   2. AWSAIDeveloperGroup
   3. AWSAIAdminGroup
   4. AWSADMINSSO

Services: Least Privilege access at a granular level.

Roles: Defined in Azure AD and synced via SCIM in AWS.

2. Protect AWS credentials

Within iEvent Application we have the:

1. Enabled MFA on the root account and all IAM users
2. Implemented Federated access with Azure Ad.
3. A strict password policy was implemented.
4. Established the least user access by providing access to resources and performing role-based actions.

3. Use Fine-grained authorization/access control

1. Users have no permissions or privileges.
2. Groups have permission to assume a role
3. Roles have permission to do necessary stuff, according to the least privileges
4. Using AWS Control Tower to create OU’s and Landing Zones to centrally manage access.

4. Infrastructure Security

Within AWS, we use Amazon VPC to create a private, secured and scalable environment. We have defined our topology – including gateways, routing tables and private and public subnets.

1. VPC-based network isolation: Manage CIDR block from IPAM pools to create private clouds in AWS
2. Network Segmentation: Segmentation and security zoning to apply similar kinds of security controls to diminish the blast radius of an attack.
3. IAC tools like CloudFormation Templates and Terraform to bake security elements
4. Regular patching of VM instances
5. Use of Sessions Manager for ssh or AD-based RDP Federated access to VMs using workspaces.
6. AWS Shield Advanced for layer 3 and 4 DDOS attacks: currently Shield Basic is available.
7. Create ingress and egress VPC in the network account for traffic management to the workloads account. Will be using RAM to share the transit gateway from the network account with other accounts created for workloads.

5. Data Security

Within iEvent Application, we classify data into sensitivity levels and use mechanisms, such as encryption, tokenization, and access control wherever appropriate.

Following are some of the best practices that are considered for securing sensitive data on the AWS cloud.

Encrypt data always

• AWS Key Management Service (KMS): for the confidentiality of data, encryption, and description using symmetric(AES) and asymmetric algorithms(RSA, ECDSA).
• Digital signature and message security for authentication, integrity, and non-repudiation.

1. Rotate keys regularly
2. Data Classification
3. Secure data at rest and in transit

• Data stored in Amazon S3, Amazon EBS, Amazon RDS, etc. are protected at rest using AWS KMS
• For securing data in flight, all service APIs are called over HTTPS, including data retrieval ones

Regular backups

• Scheduled backups are taken for Ec2 instances, EBS volumes, and databases
• More elaborate disaster recovery strategies like multi-site, warm standby, etc. are planned for FY-24-26.

Important data security services implemented for data security in iEvent Application.

Amazon GuardDuty – A security service featuring intelligent threat detection and continuous monitoring service.

Amazon Macie – A machine learning tool to assist discovery and securing of personal data stored in Amazon S3. Rules can be configured for data loss prevention and sensitive data discovery job.

AWS Config Rules – A monitoring service that dynamically checks cloud resources for compliance with security rules.

Amazon Inspector – Planned for FY [24-26] For automated security assessment checks for host and network. For host assessment, an inspector agent is required to be installed in the EC2 instances selected as assessment targets.

6. Application Security

Here are some of the best practices around application security:

1. Application AuthN and AuthZ: We use federated identity-based SSO using Azure AD for authentication and authorization.

2. Store application secrets securely[Planned for FY24-26]: using AWS Secret Manager or AWS SSM Parameter store to retrieve secured information at runtime.

3. AWS Web Application Firewall (WAF) for layer 7 security[Planned for FY24-26]: for attacks like XSS, SQL injection, etc.

4. Communicated over secure protocols like HTTPS, SFTP, etc. while data is in transit.

5. Static and Dynamic Application code testing[Planned for FY24-26]: before code release.

6. Penetration Testing [Planned for FY24-26]: using tools like BURP for applications that operate sensitive data or have strict security requirements.

7. Logging, Monitoring, and Auditing: Monitor, Alert, and change to the iEvent Application environment in real time. Integrate log and metric collection with systems to automatically investigate and act. Identifying a potential security threat is essential for legal compliance assurance and key areas in this are:

• Capture and Analyze logs
• Integrate Auditing Controls with notifications and workflows.

Categories of Logs:

AWS Infrastructure Logs

• AWS Cloud Trail
• VPC Flow Logs

AWS Service Logs

• S3 access logs
• ELB access logs
• CloudFront
• AWS Lambda
• RDS
• EC2 access logs

Application-based Logs [FY24-26]

• iEvent Application Application Logs
• Performance Monitoring Logs
• Messages
• Security

Within iEvent Application, we have implemented security controls as listed below.

Cloud Trail – A service that enables governance, compliance, operational auditing, and risk auditing of AWS accounts. With it, we can continuously monitor and retain account activity related to actions across AWS infrastructure. It provides event history of account activity including actions taken through the AWS Console, SDKs, CLI’s and other AWS services thus simplifying security analysis, resource change tracking and troubleshooting.

Guard Duty – AWS-managed threat detection service that continuously monitors for malicious or unauthorized behavior helping us protect AWS accounts and workloads.

VPC flow logs – For monitoring of traffic coming into our network, guard duty uses this to analyze traffic, per VPC turn-on, per region turn-on.

AWS Config – Provides an inventory of all the resources and the history of configuration changes to the resources.

Security Hub – Per region and per account, checks for compliance and pulls the information from all the AWS resources that we decided to turn on. The config rules currently configured for CIS AWS Foundations Benchmark v1.2.0, AWS Foundation Security best practices, and PCI DSS V3.2.1

Amazon CloudWatch Logs – Stores all the application-level logs.

8. Incident Response – prepare for security events [FY24-26]

For iEvent Application, the following practices facilitate effective incidence response

• Detailed Logging is available that contains important content such as access to tools and files.
• Ensure that quick access to the security team can be granted and impacted systems are isolated as well as capturing of data and state of forensics.

Acronyms:

AWS: Amazon Web Services

RBAC: Role-Based Access Controls

MFA: Multi-Factor Authentication

SSO: Single Sign On

CLI: Command Line Interface

AES: Advanced Encryption Service

RSA: Rivest Shamir Adleman

ECDSA: Elliptic Curve Signature Algorithm

TLS: Transport Layer Security

SSE-S3: Server-Side encryption-S3

EC2: Elastic Compute

RDS: Relation Database Service

S3: Simple Storage Service

PHI: Protected Health Information

HIPAA: Health Insurance Portability and Accountability Act

PCI: Payment Card Industry

DSS: Data Security Standard

GDPR: General Data Protection Regulation

KMS: Key Management Service