Author:
First drafted: ~2019
Published: 2025-04-10 This example doesn't pretend to be all-inclusive and complete, but it should provide some inspiration and a source for comparison and discussion.
The policy is derived from working and operating in highly regulated and compliant environments.
💡 I am not suggesting to anyone that this sample policy should be implemented and enforced to the letter. It is published as an example so that people can pick and mix what suits their set-up and situation, and discuss "Should we be doing/considering point x?"
Critique and feedback very welcome, ping me on reddit.
Derived from various security frameworks and PCI DSS.
Credentials and security configuration shall be configured by the (PoLP). Multi-factor authentication () shall be required for public subnet facing interactive sessions, this includes any and all interfaces/devices/hosts. As required implement MFA proxies for components that do not natively support MFA. Consider MFA as a standard everywhere, at least creating MFA authenticated short lived sessions so MFA doesn’t become a burden to the caretakers. Consider implementation of Zero trust architecture () aka perimeterless security Consider implementation of Zero Trust Network Access () Firewall policy shall be governed by the principle of least access (PoLA). I.e. only open ingress and/or egress ports as required All subnet firewalling shall define explicit DENY ALL policy for ingress and egress traffic. For example, denying egress traffic explicitly by default is a great defence against many exploits that must phone-home to download their exploit payload, and mitigates reverse access exploits. This stance also reduces a threat actors options for data exfiltration. OPTIONAL Connections to untrusted networks shall require a proxy and explicit authentication. This is a very strict policy but provides significant benefits. A singular point of authenticated egress centralises many topics and reduces OpSec/SoC toil. All data storage and processing shall be performed on private networks. All data transmission shall be protected with strong encryption using strong cryptographic standards and methods. Implement software such as spiped to secure components that do not natively support encrytped network communications Consider using a service mesh with mTLS support for container/compute networks Data at-rest: Data classified as sensitive shall be protected with strong encryption before being written to persistent storage "at rest". I.e. This class of data shall never be written to persistent storage without encryption. Data online on-record: Data classified as sensitive that is online and/or in-flight shall be protected with strong on-record encryption, and never written to persistent storage without encryption. This refers to highly sensitive data such as personally identifiable data (PII) or credentials, such as payment credentials or system access credentials. These kinds of data records should be protected by on-record encryption. These kinds of records are candidates for the use of one-way hashing, salting and peppering. Data classified as sensitive is permitted to be written to memory for processing without protection, so long as the max lifetime of the data is limited/short and measured to the usage of the data in real-time or near-time. e.g. sensitive memory/cache data is considered stale if not used within 60 minutes and should be evicted from cache and/or the cache should self-expire such records. Consider techniques for securely wiping memory addresses and free memory if this aspect is not natively implemented by the relevant component(s). Data classified as ultra sensitive must implement on-record and in-memory encryption and obfuscation techniques. Centralised logging shall be used and shall be configured in a way to make stored log entries immutable to prevent tampering of audit trails. Emission of logs shall be configured in a security hardened manor, to mitigate the chances of log emissions being blocked. Access to systems shall require authentication and be centrally logged. Access to data classified as sensitive shall require authentication and be centrally logged. Interactive shell sessions must traverse a security hardened bastion/perimeter. Interactive shell sessions should be recorded and sent to centralised logging. Auditing shall be enabled where it is supported and audit logs shall be centrally logged. Systems and software shall be not be left in default configuration, this includes default credentials. Systems and software shall be configured and hardened against attacks and exploits. Centralised logs shall be monitored by an intrusion detection system (IDS) and/or a security information and event management (SIEM) system, with notifications sent to relevant caretakers e.g. SoC. Systems and software versions will be evaluated for updates and patches on a regular basis, following PCI DSS methodology. The public subnet network perimeter shall be scanned for security issues monthly, with notifications sent to the relevant caretakers. The private subnet networks shall be scanned for security issues on a quarterly basis, with notifications sent to caretakers. The regular network scans should include checks for the correct network segmentation. Systems and software shall be monitored by a file integrity monitor (FIM) and events shall be centrally logged, with infraction notifications sent to the relevant caretakers. Network proxy usage shall be centrally logged. Failed authentication attempts breaching a configured threshold shall emit notifications to the relevant caretakers. Caretakers will have recurring calendar reminders configured to ensure their duties are carried out in accordance to policy. Encryption keys and passphrases shall be kept secret and protected from unauthorised parties, caretakers have the custodial duty to monitor and enforce this. Authentication keys and passphrases shall be kept secret and protected from unauthorised parties. Detection of suspicious activities, and/or suspected breaches of policy, and/or unexpected exfiltration or infiltration of data (data breaches) shall be forthrightly reported to caretakers without delay. An annual review of credentials and security configuration and firewall policy shall be conducted, and out of line and/or outdated situations shall be corrected. For interactive sessions shared credentials shall not be permitted. (No shared interactive accounts) For system accounts and services which under normal operations are primarily non-interactive sessions, shared service credentials shall be permitted. The caretakers will setup and maintain an observation and notification methodology of: Proactive monitoring of OpSec/NetSec/SoC related information sources and databases The central log system(s) System load, capacity and headroom That the defined availability metrics of the system(s) and service(s) and within expected thresholds Other relevant system events and signals Secret sharing and management: For a given secret, such as an encryption key, no one person should know all the secret material. Secrets shall be cut into shares and distributed among caretakers/custodians. [] [] Ceremonies/events where secret shares need to be combined to recreate a secret, e.g. to install or configure a given secret, should follow a well-documented process, including a ticket/record to document the event, the procedure followed, the justification, the parties and shares involved, etc. During ceremonies/events where secret shares are combined to recreate a secret, techniques and procedures shall be used to mitigate the risk of any one person becoming aware of all the secret material for a given secret. Secret shares should be stored in a secure manor, and never unencrypted at rest. For security, continuity and recovery the caretakers shall implement a comprehensive and robust backup strategy and consider the benefits of the 3-2-1 backup principle [] which provides: The caretakers have time machine for the relevant systems and data Helps with cyberattack investigations and retrospectives Enables the caretakers to recover from a topic such as data loss Enables the caretakers to perform disaster recovery
Sample InfoSec policy