FlowTrack standardizes and automates configuration management through the use of automation scripts as well as documentation of all changes to production systems and networks. Automation tools automatically configure all FlowTrack systems according to established and tested policies, and are used as part of our Disaster Recovery plan and process.
FlowTrack policy requires that:
(a) All production changes, including but not limited to software deployment, feature toggle enablement, network infrastructure changes, and access control authorization updates, must be invoked through approved change management process.
(b) Each production change must maintain complete traceability to fully document the request, including requestor, date/time of change, actions taken and results.
(c) Each production change must be fully tested prior to implementation.
(d) Each production change must include a rollback plan to back out the change in the event of failure.
(e) Each production change must include proper approval.
Configuration management is automated using industry-recognized tools like Docker, AWS Config, and AWS CloudFormation to enforce secure configuration standards.
All changes to production systems, network devices, and firewalls are reviewed and approved by Security team before they are implemented to assure they comply with business and security requirements.
All changes to production systems are tested before they are implemented in production.
Implementation of approved changes are only performed by authorized personnel.
Tooling is used to generate an up to date system inventory.
FlowTrack uses the Center for Internet Security (CISs) as a baseline for hardening systems.
All IT assets in FlowTrack have time synchronized to a single authoritative source.
All frontend functionality (e.g. user dashboards and portals) are separated from backend (e.g. database) systems by being deployed on separate servers or containers.
All software and systems are required to complete full-scale testing before being promoted to production.
All code changes are reviewed to assure software code quality, while in development, to proactively detect potential security issues using git commits and static code analysis tools. More details can be found in the Software Release / Code Promotion section.
All infrastructure and system configurations, including all software-defined sources, are centrally aggregated to a configuration management database (CMDB) -- AWS Config.
Configuration auditing rules are created according to established baseline, approved configuration standards and control policies. Deviations, misconfigurations, or configuration drifts are detected by these rules and alerted to the security team.
Before provisioning any systems, a request must be created and approved in the Jira Production Change Management (PRODCM) project.
The security team must approve the provisioning request before any new system can be provisioned, unless a pre-approved automation process is followed.
Once provisioning has been approved, the implementer must configure the new system according to the standard baseline chosen for the system's role.
If the system will be used to store sensitive information, the implementer must ensure the volume containing this sensitive data is encrypted.
Sensitive data in motion must always be encrypted.
A security analysis is conducted once the system has been provisioned. This can be achieved either via automated configuration/vulnerability scans or manual inspection by the security team. Verifications include, but is not limited to:
The new system is fully promoted into production upon successful verification against corresponding FlowTrack standards and change request approvals.
Employee laptops, including Windows, Mac, and Linux systems, are configured either
The following security controls are applied at the minimum:
The security configurations on all end-user systems are inspected by Security through either a manual periodic review or an automated compliance auditing tool.
Linux System Hardening: Linux systems have their baseline security configuration applied via automation tools. These tools cover:
Windows System Hardening: Windows systems are not used however if they are in the future they will have their baseline security configuration applied via the combination of Group Policy settings and/or automation scripts. These baseline settings cover:
Any additional configuration changes applied to hardened Windows systems must be clearly documented by the implementer and reviewed by the Security team.
Provisioning management systems such as configuration management servers, remote access infrastructure, directory services, or monitoring systems follows the same procedure as provisioning a production system.
Critical infrastructure roles applied to new systems must be clearly documented by the implementer in the change request.
All network devices and controls on a sensitive network are configured such that:
Vendor provided default configurations are modified securely, including
Encryption keys and passwords are changed anytime anyone with knowledge of the keys or passwords leaves the company or changes positions and the new position does not require knowledge of the keys or passwords.
Traffic filtering (e.g. Security Group traffic rules) and inspection (AWS WAF logs) are enabled.
An up-to-date network diagram is maintained.
In AWS, network controls are implemented using Virtual Private Clouds (VPCs) and Security Groups. The configurations are managed as code and stored in approved repos. All changes to the configuration except resizing of Instances follow the defined code review, change management and production deployment approval process.
FlowTrack maintains multiple AWS accounts, atleast one per environment.
prod account itself handles the Production environment for example.
Access to each account is funneled through our designated SSO provider, which establishes a trust relationship to a set of predefined roles in the master account. Once authenticated, a user then leverages AWS IAM Assume Role capability to switch to a sub-account to access services and resources.
The account and network structure looks like the following:
SSO/IdP ── FlowTrack-prod │ └── VPC │ └── Subnets │ └── Security-Groups │ └── EC2 instances │ └── Docker containers │ ├── FlowTrack-test │ └── VPC │ └── Subnets │ └── Security-Groups │ └── EC2 instances │ └── Docker containers │ ...
FlowTrack AWS environments and infrastructure are managed as code. Provisioning is accomplished using a set of automation scripts and AWS code. Each new environment is created as an AWS account connected to the master IdP. The creation and provisioning of a new account follows the instructions documented in the ReadMe and Init scripts and/or internal documentation.
The FlowTrack Continuous Delivery Pipeline automates creation and validation of change requests. This is done in a 3-step process:
Create/Validate Change Request Ticket
CodePipeline is used for continuous delivery (build and deploy), and we employ CodePipeline-Jira automation such that:
Detect Change Details and Obtain Approval
A separate process is implemented to provide additional details to assist/automate the ticket approval process:
Whenever a PRODCM ticket is created an integration with the ticket system and deployment process is triggered to;:
The following practices will fail this validation and result in manual processing, therefore should be avoided:
After analysis an approval is posted to the PRODCM Jira ticket or deployment.
If human approvals are needed, the required approvers will review the details and approve/decline accordingly.
Detect Risky Changes, Deploy and Close
CodePipeline workflow proceeds only with an approved and validated PRODCM ticket and human intervention.
Part of the code review process is to detect risky changes.
Examples of security-related or risky changes include:
Once a deploy is completed, the PRODCM ticket should be marked resolved and closed.
FlowTrack uses automated tooling to ensure systems are up-to-date with the latest security patches.
On local Linux and Windows systems, the unattended-upgrades tool is used to apply security patches in phases.
FlowTrack follows a "cattle-vs-pets" methodology to keep the resources in the cloud environments immutable and up-to-date with security patches.
AWS Elastic Container Service (ECS) is used to dynamically manage container resources based on demand.
Engineering team builds or uses a security-approved Amazon Machine Image (AMI) , server build scripts, and/or DockerFiles to include required security agent. DockerFiles are built as images and stored in Elastic Container Registry (ECR)
The security agents installed on the security-approved AMIs and/or DockerFiles continuously scan for and report new vulnerabilities.
The ECRs are automatically rebuilt from the latest weekly during a code deployment to include the latest security patches.
FlowTrack requires auto-update for security patches to be enabled for all user endpoints, including laptops and workstations.
In order to promote changes into Production, a valid and approved Change Request (CR) is required. It can be created in the Change Management System/Portal which implements the FlowTrack Change Management workflow, using the Production Change Management (PRODCM) Jira project to manage changes and approvals.
At least two approvals, or one CEO approval, are required for each PRODCM ticket. By default, the approvers are
Additional approver(s) may be added depending on the impacted component(s). For example,
Each PRODCM ticket requires the following information at a minimum:
Additional details are required for a code deploy, including:
In the event of an emergency, the person or team on call is notified. This may include a combination or Development, IT, and Security.
If an emergency change must be made, such as patching of a zero-day security vulnerability or recovering from a system downtime, and that the standard change management process cannot be followed due to time constraint or personnel availability or other unforeseen issues, the change can be made by:
Notification: The Engineering Lead, Security Lead, and/or IT Lead must be notified by email, chat, or phone call prior to the change . Depending on the nature of the emergency, the leads may choose to inform members of the executive team.
Access and Execution: Manually access of the production system or manual deploy of software, using one of the following access mechanisms as defined in Access Control policy and procedures:
Post-emergency Documentation: A PRODCM ticket should be created within 24 hours following the emergency change. The ticket should contains all details related to the change, including:
Prevention and Improvement: The change must be fully reviewed by Security and Engineering together with the person/team responsible for the change. Any process improvement and/or preventative measures should be documented and an implementation plan should be developed.
Fincosa LLC, 220 Calle Manuel Domenech #2012, San Juan, PR, 00918, USA