A One-Pager of Security Questions to Think About When Designing, Building, Deploying, or Changing... Anything

A. BUSINESS REASON: Why are you changing/implementing/deploying this? What is the business purpose? What does this do? What is the business process it supports, or supporting it? Is this needed?

B. DATA SENSITIVITY: Does this change/system/application use, redirect, or expose any data flows? If so, what sort of data is involved? Is it sensitive data (customer data [including personally identifiable information or intellectual property], customer or organization financial data [bank accounts, credit cards, financial results, or components thereof - including order records], organization trade secrets, contracts, or other confidential emails or communications, etc.)?

C. DEVELOPMENT SECURITY: If this change/build/deployment involves deploying code, has this code been peer-reviewed and/or tested through automated (SAST) security tooling to check for security issues? Is there evidence of such review or testing? Can you provide evidence of approval to move the code to production, upon future request? Have you verified all your software components are secure? Do you have an SBOM for your application? Have your component vendors provided you with SBOMs? Have you vetted OSS components for security?

D. DATA TRUST BOUNDARIES: Does this change/build/deployment cause data to cross trust boundaries (e.g. between different-tiered environments [dev/test/prod], from the internal network to the Internet, or to a 3rd party vendor)? If so, is that crossing required? Is the data flow secured (see E below)? Are you protecting data if it flows from a higher-trust to a lower-trust environment?

E. DATA FLOW SECURITY: If this change/build/deployment alters an existing data flow or creates a new data flow, or connects data sources and destinations across systems, applications, or networks, then how is the data protected in transit? How are data flow connections authenticated when being established? What encryption protocols and/or cipher suites are used? How is data protected at rest at the source and at the destination? What encryption is used at rest?

F. ENCRYPTION BEST PRACTICES: If encryption is being deployed to protect data as part of this change/build/deployment (whether at rest or in transit – see E), how are shared secrets or PKI keys stored? Are they stored securely (e.g. in Amazon Secrets Manager or Azure Key Vault)? Are they rotated regularly?

G. SERVICE ACCOUNT BEST PRACTICES: If a new service account or principal is created as part of this change/build/deployment, does it follow security best practices? (20-character randomly generated password, securely stored in a organization-approved password manager or cloud secrets vault, with an incorrect password lockout threshold of 1, without remote access, file share or VPN access rights, systems access for account restricted to only those systems where needed, account properly labelled as a service account, temporary access rights for service accounts/principals where possible)?

H. INTERACTIVE LOGON BEST PRACTICES: If interactive logon account(s) is/are created/used as part of that change/build/deployment, how is least privilege enforced? Are there designated user(s) for the system/application/components? Is access control role-based or discretionary? Who assigns access? Who reviews access? Is there separation of duties? Is there only one user per interactive account? How are they authenticated (with MFA, FIDO/U2F, WebAuthN)? What is used to authorize their access (Azure AD, AWS Single Sign-On, other IdP services)? What protocols are used for authorization (e.g. LDAPS, OAuth2, SAML 2.0, etc.)? How are users’ logon credentials stored? Are they rotated regularly? Is user access reviewed at least quarterly? If admin-level access is needed, is admin rights-delegation used, avoiding permanent admin rights on the account? How are privileged accounts monitored? Is user access or activity logging enabled?

I. SYSTEMS SECURITY: If this change/build/deployment involves deploying a new cloud instance, VM, or container, has this system been scanned for vulnerabilities? Has it been patched (at hypervisor, host OS, container image, and application levels) to remediate risky vulnerabilities? Has it been properly configured (defaults changed) and hardened to remove security misconfigurations? Has it had standard security tooling (e.g. EDR, SIEM logging, inventory management, RMM) installed on it?

J. NETWORK SECURITY: If there is a network connectivity change involved in this change/build/deployment, are you deploying ONLY the minimum connectivity required for purpose (with proper network segmentation, denying connectivity by default, allowing only ports/protocols/endpoints necessary for the business purpose)? Is your perimeter firewall or NSG (if applicable) configured to deny all inbound and outbound connectivity by default?

K. DATA ACCESS CONTROL: If this change/build/deployment/process requires storing data somewhere, especially sensitive data [see item B], is that location adequately protected in terms of access control (see also item E for encryption at rest). This applies to file shares, cloud buckets, and databases storing data, as well as to SaaS data lake applications.

L. API SECURITY: If this change/build/deployment sets up or exposes an API (internally or externally), are calls to the API authenticated? If the API sends any data into a lower trust-zone, does it encrypt/mask it if it is sensitive? How is API access controlled (API authentication, network-level call source restriction, etc.)? Is the API behind a WAF if externally exposed? Has the WAF been configured? Has the API been tested against the OWASP API Top 10 if externally exposed? Are API keys rotated regularly and stored securely (e.g. in Amazon Secrets Manager or Azure Key Vault) and NOT hard-coded anywhere?

M. WEB APPLICATION SECURITY: If this is a change to a web application, or involves deploying a web application, has this change/application been tested for security (see C)? If it’s publicly facing, has the application been penetration-tested and/or tested (manually or automatically) against the OWASP Top 10?

N. PRIVACY: If collecting personally identifiable or other sensitive information from customers/users/employees/contractors (depending on jurisdiction), are you minimizing what you collect? Are you collecting only what you say you are collecting in your publicly/internally facing privacy notice(s)? Are you minimizing how long you retain the data? Are you only using the data for the purposes you state in your privacy notice(s)? Have you considered the data lifecycle and storage implications of keeping the data? Is there a process which will let data subjects request their data to be deleted/updated/delivered to them? Are you making sure you are not using customer data in development or test environments?

O. DATA GOVERNANCE/LIFECYCLE: Is data involved in this change/build/deployment classified according to a standard classification policy? Is there a scheduled data cleanup/deletion process for any data that is stored as part of this build/deployment, or resulting from this change? Archiving process? Backup process? Are archives and backups encrypted at rest? Is access to them controlled? How long do you retain the data? Are there regulatory requirements mandating keeping certain types of data for a minimum amount of time? Are you tagging sensitive data and monitoring its movement (including to lower trust-zones or outside of the organization)?

P. VENDOR RISK MANAGEMENT: If this change/build/deployment allows a 3rd party to receive your data, connect to your systems or networks, or make changes to your systems, has that vendor passed via a vendor security and privacy assurance process? Have that vendor’s information security and data privacy practices been reviewed by security? Are appropriate agreements with the vendor in place (e.g. MSA, NDA, DPA, SOW, SLA)?

Q. AVAILABILITY PROTECTION: If deploying systems/applications which are business-critical, are you deploying duplicate systems to ensure a high-availability configuration is in place? What is the maximum tolerable service/system outage window? Have you tested backing up and restoring the system/application, or failing over to an HA node? Is appropriate vertical/horizontal scaling required during periods of heavy load? Is that automated? Do systems scale back down when load reduces again?

R. ASSET MANAGEMENT: Are assets involved in this change/build/deployment named and/or tagged according to a standardized naming convention? Is there an asset lifecycle in place for assets involved? Who will ensure cloud assets or on-premises assets are appropriately decommissioned at end of their life? Will the assets be added to the inventory? Will standard security tooling (see item I) be deployed on these assets?

S. PKI: How are asset identities established in your build/deployment? Are certificates issued to prove system identity and to establish connections? Do you have a certificate authority in place? How are certificates updated regularly?

T. LOGGING: Are you maintaining a long-enough lookback period of logs for all systems involved in this change/deployment/build? Are you logging user access, VM/OS/container/ activity, data movements, API activity? Is all this data flowing to a log correlation platform (e.g. SIEM)? Is time synchronized among all components collecting, aggregating, and sending logs?

U. AI: Is any sensitive data being ingested by an internal or 3rd party AI system, either during training or inference? Are there controls to prevent this? Are there security controls around access to the AI system (whether it is internal or 3rd party)? Has the AI system been evaluated by security and data privacy professionals for security, privacy, and safety? Are your users aware that generative AI outputs may not be trusted as authoritative, and may contain data which violates others' intellectual property rights?

Security is an expansive and extensive discipline! Hopefully this list serves you well as a conversation starter when you plan, build, deploy, or change any systems or applications in your organization.

As always, your questions or comments are welcome!

--Igor Barshteyn, August 16th, 2023.