Access to FlowTrack systems and application is limited for all users, including but not limited to workforce members, volunteers, business associates, contracted providers, consultants, and any other entity, is allowable only on a minimum necessary basis. All users are responsible for reporting an incident of unauthorized user or access of the organization's information systems.
These safeguards have been established to address the HIPAA Security regulations and industry best practices.
FlowTrack policy requires that
(a) Access to all computing resources, including servers, end-user computing devices, network equipment, services and applications, must be protected by strong authentication, authorization, and auditing.
(b) Interactive user access must be associated to an account or login unique to each user.
(c) All credentials, including user passwords, service accounts, and access keys, must meet the length, complexity, age, and rotation requirements defined in FlowTrack security standards.
(d) Use strong password and multi-factor authentication (MFA) whenever possible to authenticate to all computing resources (including both devices and applications).
(e) MFA is required to access any critical system or resource, including but not limited to resources in FlowTrack production environments.
(f) Unused accounts, passwords, access keys must be removed within 30 days.
(g) A unique access key or service account must be used for different application or user access.
(h) Authenticated sessions must time out after a defined period of inactivity.
FlowTrack policy requires that
(a) Access authorization shall be implemented using role-based access control (RBAC) or similar mechanism.
(b) Standard access based on a user's job role may be pre-provisioned during employee onboarding. All subsequent access requests to computing resources must be approved by the requestor’s manager, prior to granting and provisioning of access.
(c) Access to critical resources, such as production environments, must be approved by the security team in addition to the requestor’s manager.
(d) Access must be reviewed on a regular basis and revoked if no longer needed.
(e) Upon termination of employment, all system access must be revoked and user accounts terminated within 24 hours or one business day, whichever is shorter.
(f) All system access must be reviewed at least annually and whenever a user's job role changes.
FlowTrack policy requires that
(a) Use of shared credentials/secrets must be minimized and approved on an exception basis.
(b) If required by business operations, secrets/credentials must be shared securely and stored in encrypted vaults that meet the FlowTrack data encryption standards.
(c) Usage of a shared secret to access a critical system or resource must be supported by a complimenting solution to uniquely identify the user.
FlowTrack policy requires that
(a) Users must not log in directly to systems as a privileged user.
(b) Privilege access must only be gained through a proxy, bastion host, or equivalent, that supports strong authentication (such as MFA) using a unique individual account with full auditing of user activities.
(c) Direct administrative access to production systems must be kept to an absolute minimum.
Automated log-on configurations that store user passwords or bypass password entry are not permitted for use with FlowTrack workstations or production systems.
Users are required to make information systems inaccessible by any other individual when unattended by the users (ex. by using a password protected screen saver or logging off the system).
Information systems automatically lock users such as enabling password-protected screensaver after 5 minutes or less of inactivity.
Information systems automatically enter standby or log users off the systems after 30 minutes or less of inactivity.
The Security Officer must pre-approves any exception to automatic log off requirements.
User IDs and passwords are used to control access to FlowTrack systems and may not be disclosed to anyone for any reason.
Users may not allow anyone, for any reason, to have access to any information system using another user's unique user ID and password.
On all production systems and applications in the FlowTrack environment, password configurations are set to require:
Password expiration may be set to a greater interval if an account is always protected by MFA. Currently, DaaS SSO password rotation interval is set to 60 days.
All system and application passwords must be stored and transmitted securely.
Each information system automatically requires users to change passwords at a pre-determined interval as determined by the system owner and/or Security, based on the criticality and sensitivity of the data contained within the network, system, application, and/or database.
Passwords are inactivated immediately upon an employee's termination (refer to the Employee Termination Procedures in HR policy).
All default system, application, and Vendor/Partner-provided passwords are changed before deployment to production.
Upon initial login, users must change any passwords that were automatically generated for them.
Password change methods must use a confirmation method to correct for user input errors.
All passwords used in configuration scripts are secured and encrypted.
If a user believes their user ID has been compromised, they are required to immediately report the incident to the Security team.
In cases where a user has forgotten their password, password reset procedures provided by the IdP shall be followed. The exact process depends on the system or application. If help is needed, users shall contact IT Support or Security
An approved password manager is used for to store or share non-critical business application passwords that are not integrated with our primary IdP through SSO.
An automated process/tool is implemented to ensure compromised passwords or common dictionary words are not used as passwords. This is currently implemented in DaaS.
FlowTrack selected a DaaS as its primary Identity Provider (IdP) to control user access to systems and business applications.
Single sign-on (SSO) should be used whenever possible instead of local authentication. This centralized approach improves user experience and simplifies access management.
SSO is configured via industry standard SAML protocol between the IdP (DaaS) and the target application.
FlowTrack will not configure SSO to target applications unless they score a "B" rating or higher on the Qualys SSL Labs benchmark.
Security team is responsible for the administration of the IdP / SSO system, including user and access provisioning. Security team may delegate administrative privilege to a subset of the system, such as a specific application.
Multi-factor authentication (MFA) is a standard control used by FlowTrack to provide strong access control to critical systems and applications, and should be enabled whenever possible.
FlowTrack implements DaaS and Google Authenticator, and in some cases Yubikey, for MFA.
Approved MFA methods include:
By default, user access is granted based on the user's job function / role. For example:
This is defined as user groups in DaaS.
Access to sensitive data and production customer data is highly restricted and further defined in its own section.
Access to FlowTrack AWS accounts are permissible through temporary credentials / sessions only. No persistent users, passwords or access keys are allowed in AWS IAM configurations for end-user access, either to the AWS console or AWS CLI. This is achieved with the following processes:
AWS Console Access
FlowTrack-prod) in AWS is configured with IAM roles such as Developer and Security.
FlowTrack-prodand an "AWS application" provisioned in DaaS.
FlowTrack-produsing AWS Assume Role capability.
FlowTrack-prodby default has highly restricted access. For example, the
ReadOnlyAdminRolerole does not have access to modify services and resources in the prod account.
FlowTrack-dev, which is the sandboxed development environment in a separate AWS account.
Assume Role access to a production AWS account is highly restricted.
ReadOnlyAdminRolerole in production which only has access to read access to view system status, config of production systems, CloudWatch metrics, resource group inventories, and CloudWatch dashboards. With approvals higher access may be granted
AWS CLI/SDK Access
Developerrole through AWS console.
AWS Security Hub
Troubleshooting / Support Access
In normal operations, troubleshooting is performed with log analysis on the ELK Stack using AWS ES or ElasticSearch. A separate Support role is created for temporary troubleshooting and support access when log access is insufficient to determine the cause. Support access should be minimized and is designed to involve manual approval and provision process.
VPN remote access to non-production and non-privileged environments in AWS are permissible and implemented using OpenVPN.
VPN remote access to master and production accounts are prohibited.
VPN remote access to FlowTrack office network(s), if applicable, is configured via OpenVPN, and should be used whenever connecting from public networks.
FlowTrack does not allow direct system access by customers. Access is only available through the Web UI or API interface, with valid authentication and authorization detailed in the Product Security, Architecture, and Security pages of the internal document store.
Requests for access to FlowTrack Platform systems and applications is made formally using the following process:
An access request is created in Jira through either the new employee onboarding request or a specific access request from FlowTrack Internal Support site.
The Security team will grant standard access to per job role as part of new employee onboarding. A standard set of accounts that are default for all employees are created as part of the onboarding process. This includes
Standard access may be provisioned at any time by account owners/administrators at any time during or after onboarding with approval of account owners and/or manager.
If additional access is needed in addition to the above, a separate access request (through Jira) is required and the requester must include a description and justification as part of the access request.
Once the review is completed, the Security team approves or rejects the Issue. If the Issue is rejected, it goes back for further review and documentation.
If the review is approved, IT or Security team provisions access, then marks the Issue as Done, adding any pertinent notes required.
Special access, including access to production environments, is not granted until receipt, review, and approval by the FlowTrack Security Officer.
The request for access is retained for future reference.
Temporary accounts are not used unless absolutely necessary for business purposes.
In the case of non-personal information, such as generic educational content, identification and authentication may not be required.
IT Manager or Security team receives access termination requests in one of the following conditions and processes it accordingly:
Privileged users must first access systems using standard, unique user accounts before elevating the privilege or switching to privileged users and performing privileged tasks. Examples include:
Run as Administratorin Windows
Assume rolein AWS
All application to application communication using service accounts is restricted and not permitted unless absolutely needed. Automated tools are used to limit account access across applications and systems.
Services that are part of FlowTrack platform leverage AWS IAM policy configurations and/or OAuth for authorization.
Generic accounts are not allowed on FlowTrack systems.
Direct system to system, system to application, and application to application authentication and authorization are limited and controlled to restrict access.
In AWS, service accounts are implemented in the form of IAM Roles, and their access defined by the corresponding IAM policies. The creation of these IAM roles and policies is implemented as code, which follows the secure development, review and production change approval process.
An inventory of all Service accounts is maintained by AWS IAM and reviewed periodically.
All workstations at FlowTrack are company owned or policy managed, using one the following approved hardware vendors and operating systems:
Wireless networks are not currently managed within FlowTrack. Any employee or contractor working from home will be treated as a non-production facilities (offices, etc.) and are secured with the following configurations:
FlowTrack leverages a combination of CloudFormation credential stores, and Amazon EC2 Systems Manager Parameter Store to securely store production secrets. Secrets are always encrypted; access to secrets is always controlled and audited.
Details and usage are documented on the FlowTrack internal document stores.
The following requirements and controls are in place for accessing production data by internal personnel:
There is no pre-provisioned, persisted "internal" access to production data stores. Access such as direct SSH to the production database servers and direct access to data objects in production S3 buckets are prohibited.
Access to customer data is granted on a per-system basis.
Access requests follow the same production access processes. Access must be approved by both the data owner and the security team, or the CEO.
Access to production data is granted only through an approved platform with strong centralized access control, with MFA.
An audit list of who has access to which customer data is maintained and reviewed monthly. Access is revoked when no longer needed.
FlowTrack employees have the ability to obtain self-service support directly from supported business applications, such as password reset via the SSO/IdP tool.
If needed, users may use our internal service desk or send a email request to obtain IT and Security support.
A ticket is opened in Jira for each support request and assigned to the appropriate personnel. The person assigned must verify the identity of the requester and ensure the ticket has appropriate approval before implementing or providing support. The verification step and confirmation of "User identity verified" should be included as a comment in the ticket by the support personnel. Additionally, if a password or security credential has been created or supplied, confirm user has received it via another channel like slack/email/phone/zoom and document receipt in the ticket.
Fincosa LLC, 220 Calle Manuel Domenech #2012, San Juan, PR, 00918, USA