Building From The Ground Up

The idea of creating a security program from scratch crossed my mind many times before I had the chance to do it. When I landed into security, moving over from IT, I had already had many years of experience - going level 1 (as a contractor tasked with unboxing monitors and sitting them on desk as the only chore of one of my earlier contract gigs) eventually through to becoming a Networking Engineer, Enterprise Engineering & IT Manager.

When I transitioned to security, I had seen a fair share on the IT side. Not everything, but a lot.

However, I was a novice with the idea of what was an “organized” Security Program.

I had landed as a Senior Lead over a security operations team that was also tasked with some cross-functional engagement to get some visibility into new systems and services being rolled out by the enterprise IT group.

A foundation had not been established that would allow InfoSec to become a key member that was consulted on such activities. We were lucky to have any awareness that something was getting deployed half the time.

As I moved on to more mature and integrated opportunities and gained insight via mentors, more hands-on experience and certifications (Security+, CRISC, CISSP) I got a better sense of what a program should look like, in an idealized world of course.

I started getting more comfortable at noticing what would have been better to have emphasize, program wise, that would have helped InfoSec from a governance standpoint. There was even evidence that some programs had bypassed these items to dive into the shiny tools, and the latest Gartner chart fads of the time. Their security tool’s positioning on those charts serving as their primary justification of what made a better security program at one place versus the other.

During a thought experiment about building a program from scratch, I discovered "Enterprise Cybersecurity: How to Build a Successful Cyberdefense Program Against Advanced Threats."by Scott Donaldson (Author), Stanley Siegel (Author), Chris K. Williams (Author), Abdul Aslam (Author) in around 2017.

I do not profess that this is the method to build the best, or the greatest security program in the world, your country, or that your state has ever seen. But it is an honest start in the direction I believe. I look forward to if the community can share and comment on the materials here to help us define and optimize this for future disciples. Maybe with enough iterations and feedback, we can structure an outline for such things that help eliminate a headache or two.

Evaluating Business Mission, Leadership & Assets

Too often I’ve seen security activities in organizations start off with the technical aspects of a system or service and not the true meat and bones.

The Why…

What purpose does this system or service serve? How does this system or service help the organization achieve its mission, its objectives?

How does this system aid in creating value for the organization?

I learned that these items, which are core tenants when undergoing and learning practices associated with SASBA (which develops methodologies that help develop risk-driven information security architectures,) is a fundamental and core input to understanding and starting the abstraction process when developing security governance model.

Colleagues in the field often mention that the first step in securing an organization is to account for all assets, which is not necessarily incorrect. “You can’t protect what you don’t know exists”.

I feel you. But, in my opinion, I like to pull back a little further… Why does it need to exist in the first place?

You can learn that an organization has 12,000 assets of 50 classifications categories in 5 flavors, etc. But that doesn’t really answer the why? The why can be just as important as the what, or in this case, the how many?

My opinions about the first steps you should take can lead to some critical discoveries and produce some helpful artifacts. These knowledge bases can generate valuable data well into the organization’s future. Remaining an excellent source to drive the why.

Stakeholder Engagement: First Priority

This first priority comes in the shape of Stakeholder Engagement and can take the form of a risk assessment and interviews of all key Executives, Leaders, Managers, & SMEs from various business areas.

Understanding business objectives, priorities and incentives can help you secure executive buy-in, especially when you cook up those lovely programs, controls, policies, and constraints to prevent the business from careening off the cliff us security folks love to believe will inevitably happen if we are not around or involved.

During this phase, we can understand the risk preferences and thresholds of the people involved in vital activities and link the inherent risks of those activities to the established objectives and goals.

Additionally, knowing what these individuals understand about compliance and client requirements can impact the establishment, execution, and future expansion of controls.

Activities:

• Interview C-Suites leaders, department heads, technical leads, regulatory officers
• Gather insights on the business goals, risk concerns (things that keep them up at night) and operational dependencies (including things related to third-parties or vendors).
• Formulate a governance structure that accounts and produces items such as your
  • A start to your Information Security Program Policy
  • A Compliance Steering Committee that can help direct activities and actions against potential risks or compliance requirements.
  • A cadence for reporting on potential information (KPIs, KRIs, Metrics, and Incident Review Summarization).
  • Consensus on what frameworks your organization will adopt and align too as per business requirements/ client requirements.

Although not everything here may be in its final form, this stakeholder engagement is essential for establishing the baseline and foundation for the seeds you will plant later.

When leadership sees that the security program is designed with their needs in mind—based on insights from interviews and key information—they’re much more likely to support your recommendations. This alignment makes it easier to highlight where risks could create real exposure and impact documented business concerns, prompting faster action. Stakeholder engagement is critical—without leadership buy-in, even the best-designed security frameworks can doink off the uprights. But once executives understand how risks connect directly to business goals, they’re far more likely to provide the resources and support needed to move security efforts forward.

• ISO27001:2022 Clause 5 Leadership
• NIST Cybersecurity Framework (CSF) Governance (GV)

Business Context & Nuanced Understanding: Second Priority

Once stakeholders have defined their expectations and risk appetites, a natural next step is to understand how business processes, supply chain elements, and external dependencies integrate into the developing security framework. This helps establish which processes and systems are most critical to operations and critical business functions.

This exercise is key because it can help establish the protocols and activities involved with keeping business processes available and support the building of redundancy and backup requirements.

Activities:

• Document key business processes and dependencies. This can take the form of items such as core business processes that keep the business operating such as (order processing, customer support, supply chain management).
• Map out external suppliers, partners, and third-party integrations. Understanding where your control boundary ends and a third parties begins can allow for appropriate composition of contracts, SLAs and clauses that protect the organization from unfavorable events.
• Business Impact Analysis | Business Continuity | Disaster Recovery. These items are robust but are outside the scope of the article and will be revisited via their own breakdown.
• Align business continuity requirements with cybersecurity priorities. Determine who will be responsible for key recovery and/or continuity components that ensure the organization can recover in the event of a disaster.

Produced: You should aim to produce:

• Process maps, logical and physical diagrams, service catalogs, dependency matrix, critical process identification reports.
• Identifying your documentation repository (Confluence, SharePoint, etc).
• Any diagraming tools that will support your architects and designers in constructing ongoing documentation in alignment with the organization’s strategy and shared glossary of terms. Visuals help security folks quite a lot!
• Vendor Management Register
• Third Party Risk Assessments Reports
• Repository of SLAs, contracts, & the promises agreed to within!
• RACIs, Escalation Matrix, Organization Charts, Personnel Call List, Backup List
• Incident Management system processes
• RTO, RPO, Disaster Recovery Plans (DRP) Tabletops

And there is more. This stage really helps to set a baseline for why things are important and how they are important. The BIA and Disaster Recovery components should help identify those critical assets that will require more robust recovery and incident response procedures and help give that “I can’t protect what I don’t know exist” even more criticality. It’s not just about visibility, but context too! Context can help shape the program's efficiency across the items of relevant risks and business impact. This can spur more cost-effective budgeting and tool allocation within the security portfolio and give leadership a relevant outline to scale up the security apparatus as the company grows and risk tolerance change during its lifecycle.

• ISO 27001: Annex A.17 (Business Continuity)
• NIST CSF: Risk Assessment (ID.RA)
• CIS Controls: Incident Response and Management (Control 17)

Asset Identification: Third Priority

Okay, now we get to the ‘what’ for me. Don’t get me wrong – knowing what you protecting is essential. So, the idea here isn’t to undermine it in any way, but rather to highlight that asset identification should stand on equal footing with the first two priorities when it comes to building a security program. Without assets to protect you’re really only securing ideas – and those are a lot trickier to wrangle once manifested into the world. Some ideas require assets, elements, and components to produce the tangible value. This is where understanding your assets attack surfaces, vulnerabilities, and consumers become very key to the likelihood of success.

If a server is in the middle of the woods, can it be hacked? Heck, yeah, if it’s plugged in. But how do we even know if it is in the woods, or in our on-premises data center, or in the cloud? What if it turns out not to be a server at all? Perhaps it's just a bunch of ideas that take the form of algorithms or a code base. Suppose it is an API or an ecommerce site. What if it is just a poor excuse of a blog from some middled-aged tech geek trying to help people out... You know what? Let’s move on!

Asset Management is commonly one of the earliest technical tasks and programs initiated within a security program.

Very frequently, only administrators and engineers fully understand and consume this type of information.

How often do discussions come up with business leadership outside of explaining billing reports explaining why a company's IT costs are so high?

No one in leadership really cares how many servers are running in any subnet versus another that isn’t IT focused, and this is where the visibility and communication between the business can begin to break down. Right there at main control #1.

Outside of performing follow up BIA & Risk Assessments, the total amount of any asset just becomes a line item to lots of business side leadership, and as long as it is operating why would they really care about the status of it across its lifecycle?

Well, see, there are these things called vulnerabilities, and they pop into existence like virtual particles blanketing every inch of cyberspace. The issue with vulnerabilities, however, is that they don’t blink out of existence virtually instantly. They linger for a long time (for the rest of the life of that asset) unless that asset is patched or decommissioned. Assets can come in many forms, but we will concentrate on the hardware software forms today. People are also considered assets, as well as other things, but considering this is a primer, we don’t need to get into it any deeper than that right now.

Data and Information Assets

• Customer data (PII)
• Financial data
• Intellectual Property (IP)
• Employee data
• Operational data

IT Infrastructure and Systems

• Servers and data centers
• Networking devices (firewalls, routers)
• Endpoints (laptops, mobile devices)
• Enterprise applications (ERP, CRM)
• Virtual machines and containers

Physical Assets

• Facilities (offices, data centers)
• Access devices (security badges, biometric systems)
• Backup media (drives, tapes)

Software and Applications

• Custom software
• Third-party software
• Open-source components

Cloud and Virtual Assets

• Cloud services (IaaS, SaaS, PaaS)
• Virtual machines in cloud environments
• Containers and orchestration platforms (e.g., Kubernetes)

Human Assets

• Employees (full-time, part-time, contractors)
• Third-party partners and vendors

Documentation and Intellectual Property

• Policies and procedures (security, incident response)
• Legal documents (contracts, SLAs)
• Compliance reports and audit logs

Okay, we got into it just a little. So yeah, there is a lot here and potentially more. Tracking these assets becomes a critical function for the Security Program. Any of these items can be a potential entry point into your environment and the subsequent foothold in a potential breach or other disaster. This is partially why security folks age like wine… mixed with milk.

Not only are there implications for where and how these assets can be deployed, there are implications for firmware, bios, operating systems, software versions, configurations, runtimes, authorization, authentication, logging, and monitoring of these items in various combinations.

With human assets, there are background checks, education checks, work history verifications, interviews, onboarding, enrollments, training, security awareness, phishing them in their first week so they get the message about looking for clues in those carefully crafted emails of doom.

Once you discover your assets, map them to critical and core business functions and operations. In an ideal world, assign assets owners responsible for making sure they stay in alignment and compliant with organizations policies to maintain the asset throughout its lifecycle.

Threat modeling against your assets and create attack trees to carefully understand your areas of defense, trust boundaries, weaknesses, and where you need complementary control. This can both empower your monitoring teams and give you a leg up when whispering "sweet nothings" into eventual auditor’s ears (that'll want to know why you don’t execute every control in NIST SP800-53 at the highest level).

“Because our risk management process identified that this will be managed this way… mmmkay”.

Results may vary with that one. But documentation always helps. And we have yet to establish the Risk Management governance we will use to guide our Risk Mitigation strategies, so let’s wrap up, as those items we tackle within our next article.

• ISO 27001: Annex A.8 (Asset Management)
• NIST CSF: Identify (ID.AM)
• CIS Controls: Inventory of Hardware and Software (Controls 1 and 2)

So, What Have We Established?

The start of something.

Completing or organizing these items will not be easy. As I provide more insights into my philosophy and methodology, it will become very apparent that I believe that human nature and insiders are generally the biggest threats to the security of an organization.

We often glamorize the notion of external adversaries constantly attempting to breach our network and access sensitive data and executive emails. But you know what’s even more alarming? Your people have access to your data repositories and executives email every day!

External threats are a major symbolic(and real) entity that can be pointed to and focus attention.

In the absence of a company culture and security standards established by top management, the threat of internal leaks by your own workforce could outweigh the risk of external breaches.

However, not having the baselines, business context, requirements, objectives, and understanding of your organization’s risk appetite can leave security organizations running in place, trying to figure out why their communication and persuasion is falling on death ears.

With this strategy for creating security programs, the program is immediately connected to the business.

This enhances communication between stakeholders and enables the implementation of customized targeted controls and policies.

Once we understand what process are critical to our business mission, we can protect them without getting in the way and causing unnecessary disruption because of layering in security processes that doesn’t account for (or even know why) we do things the way we do them.

Challenging the way things are done and improving them always holds value. But the key to that exercise usually starts with engaging in communication and doing a lot of listening up front.

Incoming & Thanks

Up next in the Building a Security Program Series we will cover in Article #2

1. Governance Frameworks – Developing policies and frame works and determining what they will align to.
2. Risk Assessments and Prioritization – Quantitative and Qualitative Risks leveraging methodologies
3. Roles & Accountability – Defining responsibilities across the teams and ensuring there is accountability and visibility

Please like, share, comment, and all that good stuff.  Trying to build this community and I'll take all the help I can get - Blessings.