Creating a Security Program is one of the best ways an organization can lower the risk and impact of a cybersecurity incident.
Unfortunately, many companies resist doing this despite the advice from various authorities, accreditation boards, and security certification organizations, often because they think making a program is costly, time-consuming, and limiting. However, this is not always true.
Most organizations already have some informal security programs, and formalizing this may simply be a matter of documentation and comparison with best practices and standards.
The process for creating a program should include a few ingredients to ensure the program meets the company's needs. These include:
This establishes the framework upon which the program is built. Add a few dashes of differences in size, familiarity, and capability, and you have a completed program.
Some industries, countries, states, and even municipalities have specific requirements for security for applicable organizations. Understanding these requirements at the beginning of the selection process can help narrow the list of options.
For example, an organization that falls under HIPAA may elect to use NIST 800-53 as a starting point for a security program, while an organization associated with the DoD may elect to use CMMC (NIST 800-171).
Additionally, locations like the European Union, California, and New York also have specific regulations that should be part of a security program but may not be comprehensive enough to cover every aspect of security within an environment.
Specific and niche requirements should be documented and understood so any decisions about a program can be measured against these requirements to ensure they are addressed.
Organizations should also regularly check for security requirement updates and new legislation that would affect their security program.
Corporate culture also plays a large role in determining a program.
Does your organization prefer complete risk avoidance, a prescriptive approach with detailed instruction, or a risk identification process allowing more flexibility in deploying compensating controls?
Guides like NIST 800-53 are more prescriptive and indicate very specific settings, protections, and configurations to deploy within an environment.
Alternatively, NIST CSF helps an organization identify potential risks within an environment and allows an organization the ability to determine the best way to address risks.
Some organizations are more comfortable using more well-known guidelines like NIST to help explain to customers some of the security practices that are followed. In contrast, others may find that lesser-known guides like CIS CSC and COBIT provide additional flexibility for the specific needs of their environment.
Another factor to be used to help create an overall program is the size of the organization.
For example, smaller organizations may prefer the Implementation Group flexibility built into the CIS v8 controls, highlighting items within reach for smaller organizations while also providing flexibility as companies grow.
Organization size may also dictate the number of resources (time, financial) available to implement the framework recommendations. Finding a guiding framework with fewer overall items may be more manageable to start.
Furthermore, breaking a set of standards into more manageable segments appropriate for a specific organization may help reduce the risk of being overwhelmed with requirements and change. Taking smaller steps over a longer period can build resilience and maturity in a security program.
Most security guides and assessments have been available for several years, suggesting members of an organization may have some level of familiarity with a specific framework.
Perhaps they have gone through a project to implement the recommendations from CIS CSC previously and understand the foundational approach this provides, or they may be familiar with the specific requirements from 800-53 and can be immediately effective. This often makes adoption easier as interactions and interdependencies can be anticipated ahead of time, allowing for a smoother and more rapid adoption of the framework details.
Sometimes, this familiarity may result from interaction with a third-party vendor specializing in a specific regulatory framework, business model, or compliance process.
Determining the desired outcome is one of the last areas of consideration in selecting a framework.
Ask yourself:
The answer may be a combination of the above items, choosing a more appropriate risk-based approach over a more prescriptive one.
As the organization finalizes plans for a program, the contents should be reviewed and compared with published controls and guidelines.
These might come from NIST, CIS, ISACA, or other organizations and help identify all the aspects that should be included in a security program. Assessing the program against these controls and recommendations reveals items that were missed, overlooked, or not completely implemented.
Identifying these controls will help provide additional coverage and risk reduction for the organization.
A mature security program should include:
This is a process that PacketWatch has been successfully coordinating for many clients, helping them gauge their progress against established guidelines and creating a prioritized approach for risk reduction and compliance management. For guidance and customized advice, contact our Advisory Services team today.
Todd Welfelt has an Information Technology career spanning more than 25 years. He has turned his extensive experience with hands-on management and maintenance of computer systems into practical assessment and implementation of security tools to meet the needs of compliance frameworks, as well as provide real-world risk reduction.