Security policy document

Contents
‍

1. Parties Involved

2. Security Policy

3. Security Awareness

4. Classification of Data

5. Security Assessments and Compliance (Customer Infrastructure)

5.1. Data Center and Customer Infrastructure

5.1.1. Network Security (Firewalls)

5.1.2. DDoS Mitigation

5.1.3. Port Scanning

5.1.4. Anti-virus and Anti-Malware

5.1.5. Authority, Access and Data Security

5.2. Encryption and KMS

5.3. Event Logs

5.4. Data Backup and Retention

5.5. Disaster Recovery

5.6. Responsibilities and Rights

6. Security Assessments and Compliance (Builder.ai Infrastructure)

6.1. Firewall

6.2. Anti-Virus

6.3. Encryption

6.4. Password Management

6.5. Access Logs

6.6. Data Access and Security

6.7. Data Backup and Retention

6.8. Disaster Recovery

6.9. Responsibilities, Rights and Duties of Personnel

7. Audits and Compliance Inventory Configuration Audit

7.1. Security Audit

7.2. Continuous Compliance Audit

8.0 File Integrity Monitoring & Logging

9.0 Conduct Vulnerability Assessment

10. Perform Penetration Testing

11. Security Awareness
‍

1. Parties Involved

This policy applies to all Builder.ai employees and any other parties’ vendors, existing or potential customers or trainees.

2. Security Policy

We are responsible for the security of workloads running on AWS. This includes protecting instances, applications running on them, and protecting AWS credentials amongst other things. Amazon provides tools such as AWS IAM (Identity & Access Management) service, Multi Factor authentication (MFA), SecurityHub for monitoring CIS compliance, GuardDuty for continuous threat detection, AWS Config for ensuring configuration rule compliance, security groups, and AWS KMS to help with security responsibilities. The use of these tools is detailed below and in specific documentation that can be found in our company wiki.

In addition, we need to be mindful of general best practices around security and augment Amazon’s offerings with the best in class third-party solutions where appropriate. 

These practices will help build a secure computing environment.

• Maintain the confidentiality, integrity and availability of customer data and our business assets.
• Managing customer assets in a mutually agreed manner.
• Ensuring the information assets are protected against unauthorized access.
• Develop and maintain a robust risk assessment, management and treatment method.
• Applying appropriate risk controls at all times.
• Develop and maintain a business continuity plan to ensure agreed services to customers at all times.
• Investigate all security incidents in-line with the security management process.
• Regular security related information is shared with all stakeholders.
• Encourage deployment of security best practices.
  

We will adhere to the AWS Well-Architected design principles:

• Implementing a strong identity foundation around the principle of least privilege.
• Enabling traceability with real time monitoring and alerting.
• Applying security at all layers.
• Automating security best practices with controls defined in code.
• Protecting data in transit and at rest.
• Keeping people away from data by minimising the need for direct access.
• Preparing for security incidents by having a comprehensive incident management process.

2.1 Policy updates

This document will be reviewed monthly by a nominated set of Builder.ai’s technical leadership. This group will be referred to as the security review board.

As part of this review process, any gaps discovered as per ongoing security trends, customer feedback or security incidents may lead to updates of this policy.

All changes to the document should be supplied to the security review board before the monthly meeting where they will be reviewed and approved. 

2.1.1 Revision History

We will maintain named versions of this document for each change using the format major.minor:‍

Drafts will increment the minor version number: 0.1 , 0.2

Final document will increment the major number: 1.0, 2.0 

This will be implemented by creating a “named version” in the version history of the document.

3. Security Awareness

We perform security awareness at two levels:

• Awareness within the organization
• Induction programs, training etc.
• Fire drills etc.
• Awareness to the customers
• Client onboarding package that details our security best practices.
• Education and awareness is spread through blogs, whitepapers, quarterly recommendations shared with customers to enhance their infrastructure performance and security
• We share AWS best practices with our managed service customers on a time-to-time basis.
• We conduct workshops for customers to make them aware of security risks and best practices.
• Secret shopper testing must be conducted once every year with the MSP team members with the purpose of verifying that appropriate validations are performed to verify the user. As detailed in the on call procedures document link

We update our clients (and ourselves) regarding security awareness related to all security fields including the steps needed to maintain better security for their AWS infrastructure.

Our recommendations to customers:

• Firewall ports such as SSH and DB ports should be restricted for public access, SSH should only be allowed from specific IP’s DB ports should only be opened from private IP address of the EC2 servers.
• Use “Bastion” host and keep our Instance in private mode so that there is no chance to access those Instances directly.
• Keep their password protected and don't share the password with anyone else.
• Use NACL rules which restrict the in and out of one or more subnet, network access control list (ACL) is an optional layer of security for your VPC that acts as a firewall for controlling traffic, by default it allows all inbound and outbound Ipv4 traffic and, if applicable, Ipv6 traffic.
• Use VPC endpoint to transfer data to one AWS resource to another e.g. To transfer data from EC2 to S3 using VPC endpoint so that the data should travel on AWS private network, which makes the data more secure and also increases the transfer speed.
• Use IPsec VPN to transfer data from on premise DCs to AWS so the data transfers securely.

4. Classification of Data

At Builder.ai we follow a consistent method of classification of data to ensure consistency in handling when the information is shared within the organization and external bodies. The documents and data that need to be protected are classified under the following categories:

• Confidential: we have kept our data confidential on cloud‍
• Restricted: data of particular user should or related to particular department should be kept restricted like for e.g.: if HR is uploading Salary Slip or any personal information to S3 so that bucket should only be accessed by the HR not by any other group. For this we have given particular bucket information to the particular department so that data should only be accessed by them only.
• We also recommend that they don’t share their password of access and secret key to anyone, we’ve implemented a strong password policy and also kept that bucket private.‍
• Public: data represents the least-sensitive data with the lowest security requirements.‍
• Private: restricted data is in the highest security classification and represents the most sensitive data.
  

5. Security Assessments and Compliance (Customer Infrastructure)

Builder.ai hosts and manages customer infrastructure within Amazon secure data centers, and utilizes components and technologies within these data centers for security protections at multiple layers and against multiple threats. Amazon continually manages risk and undergo recurring assessments to ensure compliance with industry standards. Refer to https://aws.amazon.com/security/ for details of Security and Compliance at AWS.

5.1 Data Center and Customer Infrastructure

5.1.1 Network Security (Firewalls)

Amazon provides tools such as AWS (EC2) firewall for securing cloud-based servers. 

Each Amazon EC2 Instance is protected by either one or more security groups, which contains sets of firewall rules that specify which type of network traffic should be delivered to that particular instance.

At a higher level, we can also apply network access controls on the load balancers and at the VPC level.

By default, the firewall operates in a deny-all mode and customers must explicitly open the ports needed to allow inbound traffic. Often enough the firewall policy contains an overly permissive set of rules, which create security holes. We recommended that customer’s lockdown their firewall policy and only allow communication that is absolutely required.

Creating a restrictive traffic management and security design on a per-instance basis is their job. For example, customers should not open remote access (RDP or SSH) to all of their production instances instead they should use “Bastion Hosts” to get remote access to production instances and lock down administrative access to only the “Bastion Host” from the external network.

5.1.2 DDoS Mitigation: 

AWS provides flexible infrastructure and tools that enable customers to implement strong DDoS mitigations. For more details, refer to: Denial of Service Attack Mitigation on AWS – AWS Answers. We work closely with AWs support teams to quickly respond to events and enable advanced DDoS mitigation controls when needed.

5.1.3 Port Scanning

Port scanning is prohibited and our infrastructure providers investigate every reported instance. When port scans are detected, they are stopped and access is blocked.

5.1.4 Anti-virus and Anti-Malware

We recommend our customers to deploy anti-virus solutions to protect their system from virus and malware threats. Customers can either extend their existing on-premise anti-virus solution to AWS cloud, or Builder.ai deploys and manages the Antivirus / Anti-Malware solution for its customers.

5.1.5 Authority, Access and Data Security

• Access to information shall be restricted to authorized users who have a required business need to access the information.
• Authorization to access the customer accounts must be granted by the designated business owner. An email from a customer and/or designated owner will be considered as approval.
• We will provide required access on a least privilege basis to all services.
• AWS Console and API Access
• MFA shall be enabled for Root users of Builder.ai and all customer accounts.
• Root users shall not be used for any operational activity.
• Builder.ai resources shall use their Builder.ai IAM or SSO user with MFA enabled to access customer resources accounts.
• Builder.ai Admin shall delegate client access to resources as per requirement.
• All programmatic access shall be via IAM roles.
• All users will only have access to the privileges they need and no more.
• An IAM user shall have either password or the keys. Passwords shall be used to access AWS console and keys for programmatic access only. One IAM user shall never be used for both purposes.
• We check MFA activation every 3 month for all AWS accounts.  
• Remote Access to client servers by Builder.ai resources
• Builder.ai has its own Private Cloud Infrastructure in AWS.
• All Builder.ai Windows laptop devices shall be secured by Windows defender Antivirus. 
• Direct Access
• Builder.ai resources shall use their Builder.ai user with MFA to access customer resources accounts. 
• Records of all the users having access to specific internal and customer information are maintained.

Data at Rest: Data at rest is data that is not actively moving from device to device or network to network, such as data stored on a hard drive, laptop, flash drive, or archived/stored in some other way. Data protection at rest aims to secure inactive data stored on any device or network. While data at rest is sometimes considered to be less vulnerable than data in transit, attackers often find data at rest a more valuable target than data in motion. We recommend encrypting sensitive data at rest.

Data in Transit: Data in transit, or data in motion, is data actively moving from one location to another such as across the internet or through a private network. Data protection in transit is the protection of this data while it’s traveling from network to network or being transferred from a local storage device to a cloud storage device. Wherever data is moving, effective data protection measures for in-transit data are critical, as data is often considered less secure while in transit. We recommend all data in transit be encrypted over a protocol such as SSL.

5.1.6 Federated Roles Access.

• Federated role used for centrally managed access to multiple AWS accounts using credentials from your corporate directory. Federation is the practice of establishing trust between a system acting as an identity provider and other systems, often called service providers that accept authentication tokens from that identity provider. Amazon Web Services (AWS) supports open federation standards, including Security Assertion Markup Language (SAML) 2.0, to make it easier for the systems and service providers to interact.
• Federated Roles enabled for Builder.ai internal test accounts.
  

5.2 Encryption and KMS

• If a customer is using encryption for data at rest and wants keys to be managed by AWS KMS, MSP Team ensures that best practices are followed in KMS configuration.
• All Builder.ai resources use encrypted channels to access customer resources.
• S3 bucket that stores logs and customer keys are also encrypted and keys are managed through KMS.

5.3 Event Logs

• Cloud Trail and AWS Config will be enabled and properly configured for internal and all customer AWS accounts.
• Logs of all servers are stored in S3 and a periodic review and analysis of these logs is done.
• All logs of the AWS account are retained for 90 days in S3 and then moved into Glacier.
• Logs of customer accounts are retained for 90 days in S3 and then moved to Glacier. Logs in Glacier are retained for another 455 days before permanently removing them. In case a customer needs to change this log retention policy due to compliance or its enterprise policy, appropriate changes are made in the retention configuration for the customer. The retention policy is captured either in MSA or a separate document duly approved by the customer.
• The maximum retention that we support will be 455 days.
• In the event that a customer requires less than 455 days this will be adjusted in the Expiration Lifecycle to be the desired period.
• We will offer log hosting and aggregation.
• In the event that a customer chooses to store their logs on their infrastructure :
• We will provide access to the logs in a Bucket.
• For real time shipping, we will use a log shipper such as filebeat.
  

5.4 Data Backup and Retention

We have enabled EC2 server backup through AWS Lifecycle Manager and set a cloud watch event for that function, which runs at every midnight taking backup of EC2 server by making an AMI of that EC2 server.

And the second option is that we have scripts for taking backup of EC2 server, for this we have launched a minimum configuration server and have that script on that server, which runs every midnight and makes AMI of that particular server.

We have set the retention period to delete the AMI after 7 days of creation and for that we have configured lambda function and cloud watch event for that and second option is the script for deleting 7 days old AMI. And for our RDS we have enabled Automatic backup of RDS DB servers.

5.5 Disaster Recovery

Internal systems

We have detailed recovery plans for our internal services. Each service has a plan tailored to its design. Detailed runbook can be found here : Disaster recovery plan - Internal Only (contact us for more information)

Customer environments

We are able to provide consultancy to customers on setting up comprehensive DR plans. We also offer a variety of backup solutions. These will be tailored to meet specific customer requirements by our Solution Architects.

Business continuity test drills 

We ensure business continuity test drills are conducted once every year. Below tests must be performed to ensure business continuity :

• Ensure that Anti-virus solution is deployed on all the systems of Managed Services team and also updated with latest version
• Engineers should have access to internet using secondary Internet link
• USB Internet dongles / Smartphone hotspots
• All the customer support data available on cloud
• Secondary engineer should be able to support the customer
• Backup of all the servers every 24 hours
  

5.6 Responsibilities and Rights

• Responsibility for the information security rests with the KMS Keys.
• It is expected that all the employees of our organization shall comply with the information security procedure including maintenance of data confidentiality and data integrity. Failure to do so may result in disciplinary action.
• All resources are under a strict Non-Disclosure Agreement.
• We have given specific IAM rights to our users to access the resources with strict password policy.
  

6. Security Assessments and Compliance (Builder.ai infrastructure)

6.1 Firewall

Firewall is deployed in on-premise to restrict access to systems from external networks and between systems internally.

6.2 Anti-Virus

Systems used by all the employees of the organization are protected with the latest version of the Antivirus system.

6.3 Encryption

Local systems used by the managed services team of our organization to access customer environments are protected with full disk encryption to ensure that customer information is protected in the event of any theft / unauthorised access.

Server side encryption at rest will be defined in a separate design document.

6.4 Password Management

• Users shall be required to follow good security practices in the selection and use of passwords.f This policy applies to all PCs or workstations used to connect to the Company network and also to the Cloud Infrastructure.
• Passwords should be rotated every 90 days
• Passwords should not be reused
• Passwords should be at least 10 characters in length
• They must contain upper and lower case letters, with a symbol or number
• Multi-factor authentication
• For some key applications multifactor authentication will be required

6.5 Access Logs

• Logs for all the systems that are supported will be maintained for at least 90 days.
• Logs for the systems that are used for supporting will also be maintained for at least 90 days.
• The logs for systems used for providing support to customers will be audited at least once a month for any violations.
• Logs will also be audited for detecting and reacting to systematic attacks on the customer servers as per scope of work and agreement with the customer.

6.6 Data Access and Security

Once data is in the cloud, whether in a public cloud or in PVC environment, customers should consider:

• Encrypting it for both “in-flight” and “at-rest” states. For example, if customers need to send sensitive data between their web application and their users’ browser, then they should always encrypt the channel and use SSL.
• If customers need to protect server-to-server communication, such as between their application web Server and database, it is recommended that they consider IPSec or SSL.
• When choosing an encryption solution to protect sensitive data “at-rest” whether an open source solution or built-in OS solution, (e.g. Microsoft Encrypting File System (EFS), encrypts or a commercial solution), customers Must evaluate each solution and see what fits best with their security practice.
  

6.7 Data Backup and Retention

We have enabled EC2 server backup through lambda function and set a cloud watch event for that function, which runs at every midnight taking backup of EC2 server by making an AMI of that EC2 server. And the second option is that we have scripts for taking backup of EC2 server, for this we have launched a minimum configuration server and have that script on that server, which runs every midnight and makes AMI of that particular server. We have set the retention period to delete the AMI after 7 days of creation and for that we have configured lambda function and cloud watch event for that and second option is the script for deleting 7 days old AMI. And for our RDS we have enabled Automatic backup of RDS DB servers.

6.8 Disaster Recovery and Business Continuity

• We have setup network & application level for DR solution. And we have our company website on AWS with high availability. 
• Connectivity to Cloud Resources
• We use keybox & bastion host for our connect cloud resources. 
• Availability of Customer Information 
• We use Slack channel & Google Drive for storing customer information within the Team.
• Availability of Team
• We work in 24*7 shifts.
• Cloud Tools
• We use ELB, Auto-scaling, Code deploy, git etc. for high availability and automation.
• Internal Services DR plan‍
• Disaster recovery plan - Internal Only (contact us for more information.
  

6.9 Responsibilities, Rights and Duties of Personnel

• Responsibility for the information security rests with the Builder.ai Managed services team.
• It is expected that all the employees of Builder.ai shall comply with the information security procedure including maintenance of data confidentiality and data integrity. Failure to do so may result in disciplinary action.
• All Builder.ai resources are under strict Non-Disclosure Agreement.

7.0 Audits and Compliance Inventory Configuration Audit

• AWS Security Hub
• AWS Guard Duty
• Using AWS Config
• Cloud Trails
  

7.1 Security Audit

• Audit to ensure that MFA is enabled appropriately on all accounts.
  

7.2 Continuous Compliance Audit

At Builder.ai we ensure appropriate configuration is maintained for all clients by setting up AWS Config rules. This is configured for each customer account as described in the AWS Config guide here: Internal document, contact us for more information. Each customer account feeds into an internal master account which is set up to trigger alerts whenever an account config changes and/or becomes non-compliant. All cases of this happening will cause a ticket to be created in our MSP teams ticketing system, and will be investigated and actioned within 24 hours or less depending on the severity.

We also set up SecurityHub on customer accounts to ensure infrastructure is, and remains, CIS compliant. Violations also trigger alerts and freshdesk tickets that will be actioned within 24 hours or less.

This is additional service Builder.ai offers to its customers as per their compliance requirements. Builder.ai conducts tool based audits to find non-compliances and take corrective actions.

8.0 Integrity Monitoring & Logging

The next step is to ensure the continuous integrity of critical system files, application configuration files, and application logs.

We recommend that customers implement integrity monitoring and log analysis solutions to detect any unauthorized modifications to their system components – files, registry, services, processes and critical system files.

Logging is another important component of information security. If logs are not taken, security incidents cannot be captured and if log and security events are not monitored, incidents cannot be detected.

It is important to enable logging for all components that provide visibility into our computing environments including:

• Operating systems, firewalls, antivirus software, intrusion prevention and application logs. We have already enabled “Cloud Trail” logs to monitor our AWS infrastructure that saves in particular S3 buckets.
• Cloud Trail and AWS Config will be enabled and properly configured for Builder.ai and all customer AWS accounts.
• Logs of Builder.ai servers are stored in S3 and a periodic review and analysis of these logs is done.
• All logs of Builder.ai AWS account are retained for 90 days in S3 and then moved into Glacier.
• Logs of customer accounts are retained for 90 days in S3 and then moved to Glacier.
  

Logs in Glacier are retained for another 455 days before permanently removing them. In case a customer needs to change this log retention policy due to compliance or its enterprise policy, appropriate changes are made in the retention configuration for the customer. The retention policy is captured either in MSA or a separate document duly approved by the customer.

If a customer has already established a monitoring solution and is collecting logs to a central server, then Instances running in the cloud are just another resource that must be monitored.

Firewall configuration changes may be required to allow logs from the cloud environment to reach the central log-collection server on-premises in addition to securing the data transmission path.

9.0   Conduct Vulnerability Assessment

We conduct vulnerability tests on our internal AWS account by using Amazon Inspector. Amazon Inspector is a security vulnerability assessment service that helps improve the security and compliance of applications deployed on Amazon EC2. It automatically assesses applications for vulnerabilities or deviations from best practices, and then produces a detailed list of security findings prioritized by level of severity. Amazon Inspector includes a knowledge base of hundreds of rules mapped to common security standards and vulnerability definitions that are regularly updated by AWS security researchers. After fetching the reports from Amazon Inspector, we evaluate them and perform all the security measures that are mentioned in that report.

10.  Perform Penetration Testing

Once customers have created their desired security posture around their running instances, we recommend that they evaluate the security of their systems by conducting penetration testing to safely exploit system vulnerabilities, including OS service and application weaknesses.

By conducting the vulnerability assessment, customers identify the vulnerabilities but not the potential consequences if these vulnerabilities are exploited. For example, the vulnerability scan may show a SQL injection vulnerability, but when they attempt to exploit it in the penetration testing, it could reveal personally identifiable information (PII) or data that is within the risk tolerance of the organization.

Penetration testing is a very useful approach to validating the effectiveness of the defensive mechanisms. This exercise will help customers determine if their security controls implementation can withstand real world attacks. Amazon understands the critical importance of penetration testing in any secure application deployment, hence it has established a policy for its customers to request permission to conduct penetration tests. The PCI Data Security Standard, FISMA, NIST, and other legislative and industry regulations also mandate for the penetration testing. First we take permission from the AWS form, via the link below:

Penetration Testing

Then, we fill-up this form with all required information by AWS support team. After confirmation and approval by AWS, we start penetration testing.

11. Security Awareness

• Customer Education on Cloud Security
• Builder.ai shares AWS best practices with its managed service customer on time to time basis.
• Builder.ai conducts workshops for customers to make them aware of security risks and best practices.
• White Paper & Blogs.