# Developing a Security Program
Cybersecurity isn’t purely focused on technology and chasing down active attacks in an environment to keep the organization safe. Cybersecurity is business dependency that allows an organization to securely perform their business objectives. Security Programs are developed to ensure that appropriate technologies, controls, peoples and processes are in place to allow these business objectives to be met securely and with as little friction as possible. Often, and historically, security programs have been seen in a negative view. Security technology and people are not cheap, processes can impede or disrupt business operations, and worth mentioning is the stigma around a business unit or employee being contacted because they’ve done something wrong. Developing a security program that is focuses on business objectives from the outset is a great way for security to move from being seen in this negative light, to becoming an open, transparent and business enabling unit.
## Security Organizational Structure
Before moving into the specifics of developing a security program, it's important to cover how a security organization should be structured. Dependent of a myriad of factors such as industry, compliance, budget, and organization size, the organizational structure and terminology attributed to roles and business units will differ. A research paper written by Conrad Shayo and Frank Lin, titled '[An Exploration of the Evolving Reporting Organizational Structure for the Chief Information Security Officer (CISO) Function](https://www.semanticscholar.org/paper/An-Exploration-of-the-Evolving-Reporting-Structure-Shayo-Lin/ebebf8df24c646c0b51731c95b0e2f4d0153a4e1#extracted)’ provides a ‘Recommended CISO Organizational Structure’ as displayed in the below image.
The paper states that an ideal reporting structure for the CISO is not yet settled, and this is evidence through many studies where the CISO position reporting to multiple difference areas. Who the CISO reports to is a question that cannot easily be determined, however there are factors to consider when making that decision:
* **Security Maturity:** Understanding and adoption of security at the senior executive level.
* [**Governance, Risk, and Compliance (GRC)**](/darkcybe/security-operations/threat-mangement/identify/governance-risk-and-compliance-grc.md)**:** Pre-existing implementations of GRC in the organization, if the organization is risk aware reporting from the CISO can be directly to the Chief Risk Officer (CRO).
* **Conflict of Interest:** In some occurrences, CISO reporting may fall to the Chief Information Officer (CIO) or Chief Technology Officer (CTO). Considerations should be made as to whether this constitutes a conflict of interest as the security activities may impede on the performance of the CIO/CTO objectives.
Again, there is no defined way to organize this reporting structure, in fact in an article by [IT News](https://www.itnews.com.au/news/nsw-transport-cluster-gets-raft-of-new-it-execs-517840), NSW Transport in Australia have implemented a CISO and dual CIO structure. Regardless of the structure, it's clear that the CISO has a lot on their plate, the image below taken from the [CISO Tradecraft](https://www.cisotradecraft.com/home) podcast website sums it up quite well.
## Security Frameworks
Frameworks are implemented to assist in managing the complexity of and building of a core strategy for how cybersecurity can assist the business. There are various security frameworks that can be adopted and modified to suit your organization. There is no ‘best practice’ for adopting a framework, in fact multiple frameworks can be implemented to form your security program.
It is useful to separate and understand the difference between the types of security frameworks available. [Frank Kim](https://www.frankkim.net/) presented a talk titled ‘[How to Make Sense of Cybersecurity Frameworks](https://www.rsaconference.com/Library/presentation/USA/2019/how-to-make-sense-of-cybersecurity-frameworks-4)' at RSA 2019 where he simplifies the different types of frameworks into three buckets which are expanded upon in the below examples. When developing a security program, the end goal should be to incorporate a framework across each of the categories. This may and often will not be achievable right away but does provide a great roadmap for maturing your security program over time.
### Control Frameworks
Succinct actions that can be taken to address weaknesses or risk. Control frameworks are heavily focused on technical controls that can be implemented in order to protect the IT environment across multiple control families. Control frameworks are great to establish baseline configurations for IT systems and can assist in developing a roadmap of control adoption across an environment.
#### Mapping Control Frameworks
With so many different frameworks and even an additional category not listed below which covers compliance and regulatory controls such as the [HIPAA](https://www.hhs.gov/hipaa/index.html) and [PCI-DSS](https://www.pcisecuritystandards.org/) for example, it becomes difficult to understand linkage between controls when requirement exists, or programs are developed to incorporate multiple control frameworks. Luckily, there are mappings between many of the different frameworks to assist in simplifying this process.
### Program Frameworks
Policies, procedures, processes, and activities as they relate to security programs. Program frameworks are particularly important in defining business-oriented processes and decisions into a security program and allows an organizations senior leadership to understand the importance and current security posture of the organization. Program frameworks are a stepping stone from the implementation of a control framework.
### Risk Frameworks
Considerations to prioritize and categorize security program capabilities specific to your program or organization. Risk frameworks expand on the control and program frameworks and allow a security program to apply risk aware decision making and analysis to areas of cybersecurity risk in an organization. Employing a risk framework is the most mature framework that can be employed and is often reserved to larger enterprise organization as it requires a lot of capabilities in terms of personnel, business unit and senior leadership buy-in in order for it to be effectively used.
### Framework References
| Framework Category | Usage | Frameworks |
| ------------------ | ----------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Control | Baseline Technical Capabilities Control Prioritization Roadmap |
|
## Steps for Developing a Security Program
Developing a security framework isn’t an easy task and will depend on a lot of variables from within the business. There is a great blog post by [Karen Scarfone](https://www.scarfonecybersecurity.com/) titled ‘[How to develop a cybersecurity strategy: Step-by-step](https://www.techtarget.com/searchsecurity/tip/How-to-develop-a-cybersecurity-strategy-Step-by-step-guide)’ that defines 4 key steps to undertake when developing an effective security program.
### Understanding the Threat Landscape
Threat Landscape is a term coined to describe the entirety of identified cybersecurity events that are impacting businesses across the world. Commonly, threat landscapes are separated into business sectors, regions, timeframes, vulnerabilities, etc. By evaluating the context of the threat landscape relevant to your organization, you can apply prioritization and risk aware decision making into the development of your security program.
Security vendors and researchers regularly post annual threat landscape reports which can assist greatly in gaining context to the threats and exploits observed. Some examples of the more recently (as of writing) released can be found in the below table.
| Vendor | Link |
| ----------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Fortinet | [Threat Predictions for 2023: New Attack Surfaces and Threats Emerge as Cybercrime Expands \| FortiGuard Labs (fortinet.com)](https://www.fortinet.com/blog/threat-research/2023-threat-predictions-new-attack-surfaces-threats-emerge-cybercrime-expands) |
| CrowdStrike | [2023 Global Threat Report \| CrowdStrike](https://www.crowdstrike.com/global-threat-report/) |
| Trend Micro | [Future/Tense: Trend Micro Security Predictions 2023 - Security Predictions](https://www.trendmicro.com/vinfo/us/security/research-and-analysis/predictions/2023) |
### Assessing Program Maturity
Before developing a program, its important to understand where the organization current sits in terms of cybersecurity maturity. As previously discussed in the Security Frameworks section, Program Frameworks can assist in measuring an organizations existing security program or overall maturity. Both the NIST CSF and CIS Control frameworks employ a methodology referred to ‘Implementation Tiers/Groups’. These Implementation groups allow maturity to represented in terms of framework adoption. The maturity referenced in the NIST CSF is a lot more robust, where-as the CIS Controls focus heavily on technical control implementation.
| Framework | Implementation Tier 1 | Implementation Tier 2 | Implementation Tier 3 | Implementation Tier 3 |
| ------------------------------------------------------------------------- | --------------------- | ----------------------------------- | ------------------------------------- | --------------------- |
| [NIST CSF](https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.04162018.pdf) | Partial Adoption | Risk Informed | Repeatable | Adaptative |
| [CIS Controls](https://www.cisecurity.org/controls/implementation-groups) | Basic Cyber Hygiene | Basic Cyber Hygiene + 74 Safeguards | Implementation Tier 2 + 23 Safeguards | |
#### Cyber Defense Matrix
A handy resource in achieving measurement of technologies aligned to the NIST CSF is the [Cyber Defense Matrix](https://cyberdefensematrix.com/), conceptualized by [Sounil Yu](https://twitter.com/sounilyu) who is the CISO at [JupiterOne](https://www.jupiterone.com/). The Cyber Defense Matrix identifies the core technologies applied across the NIST CSF functions and separates each into asset classes. Importantly, at the bottom of the grid the importance of People, Technology, and Process is displayed to ensure that maturation is not only tied to technology implementation. As stated on the Cyber Defense Matrix website, “TECHNOLOGY plays a much greater role in IDENTIFY and PROTECT. As we move to DETECT, RESPOND, and RECOVER, our dependency on TECHNOLOGY diminishes and our dependency on PEOPLE grows. Throughout all five operational functions, there’s a consistent level of dependency on PROCESS. This continuum helps us understand where we might have imbalances in our reliance on PEOPLE, PROCESS, and TECHNOLOGY when trying to tackle our cybersecurity challenges.”
### Security Program Improvement
Having established a baseline of where your organizations security maturity sites, a roadmap for security program improvement can be created with key markers for success identified. Mapping short-comings against possible improvements can assist in quantifying the business needs for deploying new tools, processes and procedures in order to increase the level of maturity. Having an understanding of what needs to be improved, how to improve it, and who needs to be involved in order to effect the improvement is critical during this stage of security program development. The aforementioned Program Frameworks are great starting points to align your current security program implementation against.
### Documenting the Security Program
The last phase of developing a security program is to document the policies, processes, and procedures required for implementation. This will require executive or business buy-in to effectively deploy the program. Active participation from other Business Units (BU) is a core, this allows for frictionless implementation due to the BU’s ability to openly work to consult in various areas of the security program, additionally when BU and senior leadership are involved in the security program it goes a long way in build a risk aware security culture within the organization.
## Resources
{% embed url="" %}
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://darkcybe.gitbook.io/darkcybe/security-operations/threat-mangement/identify/developing-a-security-program.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.