Customer Data Storage and Security/Privacy Attributes ¶
Purpose
- Document where customer data is stored across the system.
- Define security and privacy attributes and their allowed values.
- Describe how attributes are associated with data in storage, in process, and in transmission.
- Support STIG compliance with AC-16-00 (Security and Privacy Attributes).
1. Scope ¶
This document applies to all systems and components within the MCT platform that store, process, or transmit customer-related data.
2. Attribute Model ¶
2.1 Security Attributes ¶
The following security attributes are defined at the organizational level and should be used by all in-scope systems.
| Attribute Name | Description | Allowed Values |
|---|---|---|
confidentiality_level | Information confidentiality level | Public, Internal, Restricted, Confidential |
integrity_impact | Impact of loss of integrity | Low, Moderate, High |
availability_impact | Impact of loss of availability | Low, Moderate, High |
data_criticality | Business criticality of the data | Low, Medium, High |
2.2 Privacy Attributes ¶
| Attribute Name | Description | Allowed Values |
|---|---|---|
pii_flag | Whether data contains PII | None, PII, SensitivePII |
pii_type | Type of PII present | ContactInfo, Identifier, Financial, Health, Other |
data_subject_type | Type of data subject | Customer, Employee, Vendor, Partner, Other |
retention_category | Retention category for data | ShortTerm, Standard, LongTerm, Regulatory |
PII = Personally Identifiable Information
3. Customer Data Inventory ¶
This section identifies major customer data categories, their business purpose, and their security/privacy attributes.
| Data Category | Description | Primary System(s) | Typical Use | Confidentiality Level | PII Flag | PII Type |
|---|---|---|---|---|---|---|
UserAccounts | MCT portal user accounts | MCT Web Portal – table mct_member | Portal login, authorization, personalization | Confidential | SensitivePII when username is an email or other identifiable ID | Identifier, possibly ContactInfo |
CIAccountsAndSecrets | CI/machine/service account identifiers and secrets used by MCT | MCT Central API – table mct_ci_info | Integrations, automation, calling external APIs | Confidential or higher (per secrets policy) | High-sensitivity credentials; usually pii_flag=None unless values map to individuals | Other (credentials/secrets) |
AlertSubscriptionContact | Alert subscription emails | MCT Web Portal – tables mct_subscribe, mct_member | Notify customers or service owners about incidents | Confidential | SensitivePII | ContactInfo |
TestAccountsForCustomerSites | Test accounts and site URLs used to monitor customer-facing services | MCT Central API, MCT Resource Management – tables MCTTestAccount, mct_resource_accounts | Synthetic monitoring and automation tests | Confidential | SensitivePII | Identifier, ContactInfo |
CustomerFacingMonitoringConfig | Monitoring configuration that references customer environments or services (e.g., site URLs, VIPs, service names, server hostnames) | MCT Central API, MCT Web Portal, MAS Central | Define and manage checks, templates, attributes | Internal or Confidential (field-dependent) | PII or None | Identifier or None |
MonitoringResultsAndErrorCodes | Synthetic test results, error codes, metadata (may contain site URLs, meeting IDs, pseudonymous identifiers, server hostnames) | MCT Status API, PostgreSQL, Pinot, ELK, Prometheus | Troubleshooting, SLO/SLA, reporting | Internal | PII or None (implementation dependent) | Identifier or None |
4. Data Storage Mapping ¶
This section documents where each category of customer data is stored (databases, object storage, logs, caches, search indexes, etc.) and how attributes are applied.
| Data Category | Storage Type | Storage Location | Schema Example | Security & Privacy Attributes |
|---|---|---|---|---|
UserAccounts | Relational DB | MCTDB.MCT.mct_member (PostgreSQL, replicated SJ/DFW) | id, username, privilege, timezone, preference, ownedservice, ... | confidentiality_level=Confidential; pii_flag=SensitivePII when username is an email or identifiable ID; pii_type=Identifier/ContactInfo; data_subject_type=Customer or InternalUser |
CIAccountsAndSecrets | Relational DB | MCTDB.MCT.mct_ci_info | env, broker_host, identity_host, scopes, item_type, item_name, item_password, item_id, item_org_id, ... | High-sensitivity credential data;confidentiality_level=Confidential or higher per key management standard; usually pii_flag=None, unless item_name/item_org_id map to individuals; pii_type=Other (Credentials) |
AlertSubscriptionContact | Relational DB | MCTDB.MCT.mct_subscribe, MCTDB.MCT.mct_member (PostgreSQL in SJ/DFW, replicated via SharePlex) | USER_ID, CUSTOMER_EMAILS, SUBSCRIBE_TIME, EMAIL_TYPE, USERNAME, TIMEZONE, ... | confidentiality_level=Confidential; pii_flag=SensitivePII; pii_type=ContactInfo; data_subject_type=Customer |
TestAccountsForCustomerSites | Relational DB | MCTDB.MCT.mct_test_account (classic MCT, if present); MCTDB.MCT.mct_resource_accounts (resource management) | id, test_app, app_urls, app_name, username, password, bound_machine_ip, status, ... | confidentiality_level=Confidential; pii_flag=SensitivePII; pii_type=Identifier,ContactInfo; data_subject_type=Customer or InternalTester |
CustomerFacingMonitoringConfig | Relational DB | Multiple configuration tables (for example, checks, templates, attributes) under MCTDB.MCT; some data cached in Redis; server endpoint/host data mainly from MCTDB.MCT.mct_server and related tables | Includes site URLs, VIPs, service names, server IP/hostname, template YAML, monitor attributes, and related fields | confidentiality_level=Internal or Confidential depending on whether customer identifiers or customer-specific environment data are present; pii_flag set based on presence of identifiers |
5. Attribute Association and Propagation ¶
Design principles and target state
5.1 In Storage ¶
- Security and privacy attributes are stored as explicit fields or metadata in the underlying storage (for example, columns such as
confidentiality_level,pii_flag,pii_type, or storage-level labels/tags). - For derived or replicated datasets, attributes are inherited from the source system and should NOT be downgraded without an approved change.
5.2 In Process ¶
- Internal services that process customer data SHOULD carry attribute information as part of the data model or message schema.
- Where a processing step transforms or aggregates data, the resulting attributes should be derived according to predefined rules (for example, the most restrictive
confidentiality_levelamong inputs).
5.3 In Transmission ¶
- APIs, message queues, and ETL jobs that transmit customer data should preserve or reapply the relevant security and privacy attributes from the source.
- Where attributes are not explicitly transmitted, the receiving system should re-derive attributes based on data classification policy and source system definitions.
6. Attribute Governance: Permitted Values, Changes, and Review ¶
Current design principles and target state
6.1 Permitted Values Management ¶
- Application teams should NOT introduce ad-hoc attribute values outside the approved list.
6.2 Attribute Change and Audit ¶
- Changes to attribute definitions (for example, adding a new
pii_type) require formal change management approval. - Changes to attribute values for existing datasets (for example, reclassifying a table from
InternaltoConfidential) should be:- Approved by the data owner and Security/Privacy representative.
- Logged in the change management system with rationale.
6.3 Periodic Review ¶
- Attribute definitions and data storage mappings in this document shoulb be reviewed at least annually.
- The review ensures that:
- New systems or data stores with customer data are added.
- Deprecated systems or data categories are removed or updated.
- Attributes remain accurate and reflect current business and regulatory requirements.