The term “security program” means a lot of different things to a log of different people. To some, it’s just an acceptable use policy or password policy. To others, it’s the operationalization of security controls (e.g. firewalls, endpoint security, 2FA, etc.). To others still, it’s the measurement of how many alerts were triaged by the security team, how many vulnerabilities were discovered, or how long it took to apply patches for a particular month.
In reality, it’s a combination of all of these things. A true security program provides the rules, guidance, and validation (or efficacy) with regards to security within the organization.
In an effort to help clarify some things we have created the following list of program documentation components to explain each building block of a world-class security program.
Policies
Security policies exist to explain how a particular aspect of securing the organization supports the overall objectives and strategy of the business. They are the why of the security program.
Policies should be clear, concise, and to the point. There is no need for flowery or poetic language as these documents exist to convey instruction and direction.
Policies should also use deontic modal verbs such as “must”, “can’t”, “won’t”, “shall”, and “will” that convey instruction or direction versus permissive or subjective modal verbs such as “could”, “may”, or “might”.
Examples include password policy, acceptable use policy (AUP), or software development lifecycle (SDLC) policy.
Procedures
If the policy explains why a particular aspect of security exists, the procedures explain how they exist.
Security procedures explain how to do something. You can consider the documents as implementation and operation instructions for a particular control.
These documents should be very detailed and tactically written so that anyone could review and duplicate the instructions provided.
For example, procedures related to user account lifecycle might include new user account creation procedures, account change procedures, account deletion procedures, and account audit procedures.
As technology changes frequently, so too will these documents require updates.
Standards
Standards documents exist to communicate baseline requirements for specific aspects of the security program.
For example, with regards to user passwords, your standards document would likely contain the organizational requirements for password length, complexity, and reuse in addition to required security mechanisms to protect passwords, such as approved encryption, hashing, and salts. You should have a completely separate section within your password standards document if the aforementioned requirements differ for administrative and service accounts.
We also like to think of standards as a backstop for anything a specific procedure doesn’t explicitly mention. Your respective standards document should aim to address any issues or questions that might arise from the associated policy documents.
We hope that this post has clarified the main building blocks of a successful security program. If you still have questions, however, please do not hesitate to reach out to one of our CISOs to learn how to build, enhance, or assess your security program.
You can also chat live with one of our CISOs to help address any questions you might have. Just click the “Chat with a CISO” button.
Andrew Hay is the COO at Lares and is a veteran cybersecurity executive, strategist, industry analyst, data scientist, threat and vulnerability researcher, and international public speaker with close to 25 years of cybersecurity experience across multiple domains. He prides himself on his ability to execute the security strategy of the company with which he works without neglecting business objectives and the needs of its customers. Andrew is the author of multiple books on advanced security topics and is frequently approached to provide expert commentary on industry developments. He has been featured in publications such as Forbes, Bloomberg, Wired, USA Today, and CSO Magazine.
