Security Program Components 101

Security Program Components 101

Security Program Components 101 1090 727 Andrew Hay

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.

Where There is Unity, There is Victory

[Ubi concordia, ibi victoria]

– Publius Syrus

Contact Lares Consulting logo (image)

Continuous defensive improvement through adversarial simulation and collaboration.

©2019 Lares, LLC | All rights reserved.
    Privacy Preferences

    When you visit our website, it may store information through your browser from specific services, usually in the form of cookies. Some types of cookies may impact your experience on our website and the services we are able to offer. It may disable certain pages or features entirely. If you do not agree to the storage or tracking of your data and activities, you should leave the site now.

    Our website uses cookies, many to support third-party services, such as Google Analytics. Click now to agree to our use of cookies or you may leave the site now.