10/7/19

Hey peeps,

So wanted to talk about an elephant in the room that seems to scary so many people and that is the administrative side of the technical side: Policies.

After many months now of living, breathing, and studying for the CompTIA CASP+ (which I just passed on 10/2/19) its been a truly interesting enlightenment when your able to understand how and why these Policies, Procedures, and Processes are defined. Also tied into this is Standards, Baselines, and Guidelines which in many ways can go much deeper than just policies. But for the simpleton I’ll just stick with policies.

What is a Policy?

A policy is a document that dictates the intentions of management towards the use, operation, and security of information systems. A policy defines the details that are specifically expected from management and/or employees and yes maybe the stakeholders (whinny little Ferangi those people are) on how their needs are going to be met.

Policy Example:

Encryption Policy

HIIPA is a widely known regulation used by medical offices and hospitals and it’s recommended that all data (at-rest and in-motion) be encrypted. Based on this information, all [insert company name] data will be encrypted.

A policy is very high-level and doesn’t go into much detail, it’s just sets the tempo for what follows. Ferangi don’t need details after all, they just want to be pacified. 😛

What is a Procedure?

A procedure falls under a policy and is considered slightly more detailed than the policy and gives context to the administrative, logical, or physical controls to be used.

Procedure Example:

Encryption Procedure

(Copied from SAN but updated to NIST Standards 800-131A – March 2019)

4. 1. Algorithm Requirements
      1. Ciphers in use must meet or exceed the set defined as “AES-compatible” or “partially AES-compatible” according to the IETF/IRTF Cipher Catalog, or the set defined for use in the United States National Institute of Standards and Technology (NIST) publication FIPS 186, or any superseding documents according to the date of implementation. The use of the Advanced Encryption Standard (AES) is strongly recommended for symmetric encryption.
      2. Algorithms in use must meet the standards defined for use in NIST publication FIPS 186 or any superseding document, according to date of implementation. The use of the RSA and Elliptic Curve Cryptography (ECC) algorithms is strongly recommended for asymmetric encryption.
      3. 4. 1. 1. Signature Algorithms

         Algorithm	Key Length (min)	Additional Comment
         ECDSA	P-256	Consider RFC6090 to avoid patent infringement.
         RSA	2048	Must use a secure padding scheme. PKCS#7 padding scheme is recommended. Message hashing required.
         LDWM	SHA256	Refer to LDWM Hash-based Signatures Draft
         AES-CBC	128	NIST recommends minimum encryption key length of 128 (IPSEC) – Note: Kerberos uses AES-128 encryption with Active Directory (since Server 2008)
         HMAC	SHA256	NIST recommends SHA-2 or SHA-3 family, SHA-1 disallowed (Switch/Routers)

4. 2. HASH FUNCTION REQUIREMENTS

In general, <Company Name> adheres to the NIST Policy on Hash Functions.

4. 3. KEY AGREEMENT AND AUTHENTICATION

      1. KEY EXCHANGES MUST USE ONE OF THE FOLLOWING CRYPTOGRAPHIC PROTOCOLS: DIFFIE-HELLMAN, IKE, OR ELLIPTIC CURVE DIFFIE-HELLMAN (ECDH).

      2. END POINTS MUST BE AUTHENTICATED PRIOR TO THE EXCHANGE OR DERIVATION OF SESSION KEYS.

      3. PUBLIC KEYS USED TO ESTABLISH TRUST MUST BE AUTHENTICATED PRIOR TO USE. EXAMPLES OF AUTHENTICATION INCLUDE TRANSMISSION VIA CRYPTOGRAPHICALLY SIGNED MESSAGE OR MANUAL VERIFICATION OF THE PUBLIC KEY HASH.

      4. ALL SERVERS USED FOR AUTHENTICATION (FOR EXAMPLE, RADIUS OR TACACS) MUST HAVE INSTALLED A VALID CERTIFICATE SIGNED BY A KNOWN TRUSTED PROVIDER.

      5. ALL SERVERS AND APPLICATIONS USING SSL OR TLS MUST HAVE THE CERTIFICATES SIGNED BY A KNOWN, TRUSTED PROVIDER.

   4. KEY GENERATION

      1. CRYPTOGRAPHIC KEYS MUST BE GENERATED AND STORED IN A SECURE MANNER THAT PREVENTS LOSS, THEFT, OR COMPROMISE.

      2. KEY GENERATION MUST BE SEEDED FROM AN INDUSTRY STANDARD RANDOM NUMBER GENERATOR (RNG). FOR EXAMPLES, SEE NIST ANNEX C: APPROVED RANDOM NUMBER GENERATORS FOR FIPS PUB 140-2.

 Policy Link: https://www.sans.org/security-resources/policies/general/doc/acceptable-encryption-policy (Last Updated June 2014 – not current with NIST 800-131A)

A procedure is very much in a way a bit more technical but still pretty much an overview.

What is a Process?

A process usually falls under a procedure and is the step-by-step process to deploying the procedures of the policy.

Process Example:

Encryption Process:

Here is a link to my blog, techs are inherently lazy, plus my ADD has kicked in and I just lost focus. 😛 But this would be a process, a step-by-step instruction on how to setup a DNSSEC process that provides SHA-256 integrity to DNS records. On a side note, if you have a local Windows-based CA-based PKI you can enable IPSEC on DNSSEC too. 😉

https://www.g15it.com/windows-cyber-security-enabling-dns-sockets-for-greater-dns-cache-protection/

I hope this helps demystify policies, procedures, and processes. 🙂

Here is a recent article on the basics of cyber security controls based on Preventative, Detective, Corrective, Corresponding, and Recovery. They aren’t all-inclusive but hey it’s a baseline for understanding. 😀

In closing, I HIGHLY recommend everyone reads NIST 800-131A as it set a new standard for algorithms to be used as it was updated in March 2019, it was last updated in early 2015.

Cheers!