Updated 1/23/2023
This document outlines, at a high level, security in place for our BlkBag Infrastructure. The core of BlkBag is the BlkBag Patient Platform, which enables us to security deliver data to you, globally.
BlkBag has chosen Amazon Web Services ("AWS") to host all services for our cloud computing needs. For most customers, we leverage AWS GovCloud and depending on customer need will launch BlkBag in specific regions to protect data sovereignty.
Within AWS, we perform the entire life cycle of application development, testing, and production deployment. As this document will describe, we leverage a collection of Platform as a Service ("PaaS") services that enable us to rapidly build, test, and deploy our solutions.
This strategy enables BlkBag to build and deliver new capabilities leveraging agile methodologies, ensuring that customer feedback is integrated and a vital part of our business operations.
Additionally, these methodologies, as are described within this document enable us to leverage the most cutting edge technologies, in a repeatable, auditable, and scalable manner that sets BlkBag apart as a company providing medical IT solutions.
For our customers, BlkBag has carefully selected services provided by AWS GovCloud that are authorized by the United States Government’s FedRAMP process as well as the Department of Defense’s Cloud Computing Security Requirements Guide ("DoD SRG") at a FedRAMP HIGH or DoD SRG IL-5 (In some instances IL-6) accreditation level. These accreditations are in addition to AWS’s HIPAA compliance for the services in use and BlkBag’s adherence to best practices to secure the Cloud infrastructure.
By leveraging accredited services for HIPAA as well as FedRAMP and DoD SRG, BlkBag hosts its solutions in cloud services that meet and exceed the requirements for HIPAA data and security. This architecture also enables BlkBag apps to be used for government use cases.
To provide secure authentication, BlkBag uses a combination of hardware authenticators and software authenticators to provide a second factor of authentication. All services which BlkBag uses have MFA enabled for all users.
In countries with multiple regions, deploying this solution will be comprised of leveraging a multi-region failover. Typical development and deployment of AWS infrastructures have aimed to be "Multi-Availability Zone," meaning a single region in AWS has multiple distinct zones within a region. BlkBag has taken the approach of aiming for further redundancy, aiming to run not only in multiple Availability Zones but also multiple regions within a country. While this does incur some additional cost overhead, the costs are a worthwhile investment to achieve high availability and redundancy, enabling a less expansive disaster recovery plan. This means that if one data center becomes inoperable in any means, the other data center will provide services to users.
For instance, if the power or network connectivity is disrupted in AWS GovCloud West, the traffic would flow to AWS GovCloud East. More important, data is replicated in both environments enabling real time failover. In the event of a catastrophic loss of a data center, the replication would ensure that data is stored within the other region.
This high availability engineering flows down into compute, storage, and logging. There may be some degradation in capabilities, such as US Gov East does not have the Simple Notification Service, meaning Push Notifications maybe down for a period of time—but the core processing and storing of data, the critical part of the solutions, will remain active.
Deploying this infrastructure will rely on leveraging AWS CodeCommit for Git storage of code. AWS CodePipeline that will build, test, and deploy the applications.
In delivery, this application will be hosted as a "Serverless" web app leveraging two possible methodologies within AWS, AWS Lambda and AWS Fargate.
Lambda is a "Function as a Service" solution that is a consumption-based execution environment. This means that BlkBag will be "paying for what it uses" instead of consistently having servers running. With traditional computing, one would have 2-3 servers load balanced to handle the traffic. This would employ costs of 24/7/365 running non-stop. Serverless, a "function" handles the request the second it is made, scaling up to handle the requests as necessary automatically. After the requests have completed, the Serverless infrastructure scales down the instances. In this example, one would pay for the 500 milliseconds that the server executes the request.
Fargate works a bit differently, but is also PaaS, entirely managed by AWS itself. Fargate takes Docker Containers and runs them automatically in infrastructure hosted by AWS. While you pay 24/7/365 "running" costs for servers, they are instantly responsive to requests and require no "cold boot" times like Lambda. But these costs can be negligible. Additionally, Fargate "scales" as more requests come in. For instance, if you have 2 servers running by default and a slew of traffic hits them, Fargate will add on additional servers as necessary, then remove them when the surge scales down.
All services provided by BlkBag are web accessible. This enables anyone with a modern web browser or mobile device to securely access the services.
For cloud based storage, we will leverage Amazon DynamoDB to perform long term database storage of data. This data structure is a "NoSQL" object database.
BlkBag’s DynamoDB is configured to have multi-region replication via Global Tables. When an entry is added, updated, or deleted from one region, it is replicated to the other region automatically. This enables us to achieve high availability and automatically failover. Additionally, to protect against malicious activity, BlkBag enables Point in Time recovery for all data stored within DynamoDB, meaning at any point data can be restored in the previous 35 day period.
For file storage, such as pictures or other binary data, we leverage Amazon Simple Storage Service ("S3"). This service provides extremely high global redundancy and access for files stored within the service. All files are stored encrypted. When a user retrieves a file, we return a usable Presigned URL link that enables downloading for 10 minutes.
Access to the data and encryption keys is delegated by roles to services within AWS. To this end, access by BlkBag administration is limited, ensuring that deletion of data or keys cannot be performed. While BlkBag’s AWS account administrators could have access to the root KMS keys, these accounts are role limited to limited individuals, with strong password and multi-factor authentication enabled to access the accounts.
BlkBag customer data is, unless a dedicated tenant, shared within a single AWS account. Access to data is enforced at the application level through several security checks to ensure a user is modifying data that exists within their organization. At additional costs, BlkBag can provide segregated AWS tenants to customers, these tenants are managed in the same manner as our shared customer AWS tenant.
To protect data at rest, all data—from data stored within Amazon DynamoDB, Amazon S3, AWS Lambda, Fargate, etc are all protected at rest and in transit with AWS KMS. KMS is Amazon’s key management service that protects encryption keys. These keys are generated, stored, and cycled within AWS automatically.
For auditing within applications, to comply with DoD SRG IL-4 and HIPAA requirements, we will leverage Amazon Kinesis Data Firehose and S3. Each region will be configured to have S3 buckets for object storage, where the application will write log data to the Kinesis stream. Kinesis buffers the data and will write it to S3 automatically, reducing read costs to S3 itself for object storage.
These logs will be configured to be in "Standard" storage within S3 for 30 days. After that, they will be migrated to the cheaper "Infrequent Access" object storage for 150 days, then migrated to Amazon Glacier Deep Archive for a period of 10 years.
For BlkBag staff managing BlkBag cloud infrastructure, our configurations and security management within AWS ensures that all modifications or access to environments and data within BlkBag are logged, audited, and monitored 24/7.
BlkBag leverages a variety of additional auditing methodologies using AWS GuardDuty, AWS Security Hub, AWS Config, and additional security tooling. This enables administrators to monitor security of the infrastructure and mitigate malicious activities.
Within any healthcare application, auditing and logging are the key to accountability. With our strategy for customer auditing, we capture virtually every action a user performs. This enables BlkBag to capture granular user actions, such as authenticating with BlkBag ID, updating a patient name within BlkBag Rounds, marking an item as billed. This enables administrators of entities unique insight into user behavior and action.
Specific auditing actions that may be of interest to BlkBag Customers:
Failed Authentication Attempts
Successful Login, including user email notifications
Locked Accounts, including user email notifications
View of Patients
Addition or Modification of patients
Addition or Modification of hospitalizations
Addition or Modification of encounters
All billing actions
Movement of users within an organization
Removal of users within an organization
Modification of organization settings
All auditing can be at the entity level, user level, or individual user level.
Not sure exactly what we’re looking for or just want clarification? We’d be happy to chat with you and clear things up for you.