How to Formalize a Security Program

Written by David Worthington on October 20, 2021

Share This Article

It’s Cybersecurity Awareness Month! In honor of the theme — Do Your Part. #BeCyberSmart — we’re doing our part by educating IT teams and organizations on protecting themselves. Throughout October, the JumpCloud blog will focus on top cybersecurity issues, from IT admin best practices to CISO responsibilities. Tune back in throughout the month for new cybersecurity content or check out our archive of existing security articles for cybersecurity insights written specifically for the IT professional.


Star Trek’s Doctor Leonard McCoy was legendary for lines such as, “I’m a doctor, not a bricklayer.” An IT professional may not be an auditor or process expert, but today’s environment necessitates learning more about those aspects of organizational management. The challenge, as outlined by Dr. McCoy, is that IT administrators have traditionally never served as security officers within their organizations, nor are they experts in risk management. Small to medium-sized enterprises (SMEs) also contend with greater scarcity of applicable experience than larger enterprises, and it’s not uncommon for a single person to perform multiple roles.

Fortunately, the path to getting there is accessible, even if it’s challenging. It begins by creating a strategy, which can be focused around a few core concepts. However, formalizing a strategy into a program requires structure, documentation, and (depending upon the industry you work within) an auditor’s buy-in. This is important to do because risks could otherwise be uncontrolled, making a breach or disaster recovery incident exponentially worse. There could be other externalities such as harmful monetary, compliance, or legal consequences as well.

That was the case when I became IT Director at a manufacturing company and transformed nascent security practices into a formalized security program. It was serendipitous timing that we’d just done that, not only due to the threat environment, but because a significant ISO audit was coming down the pike. ISO non-conformance is a big deal for manufacturers and has extended into IT in a major way. The order came down from the top to be prepared, and having that level of accountability was important to get things done.

We’ll be referring to the Enterprise Information Security Program (EISP) framework throughout this article. It outlines how an organization minimizes its security risks to help plan for continued operations should incidents occur while adhering to legal and regulatory regimes that are trending toward greater internal accountability. The process is bigger than this article and can be lengthy: plans are built over the course of months or quarters and need to be cross-functional. Therefore, our focus here is to extract the areas of focus most helpful to the SME, so that your program can meet or exceed those of large enterprises with dedicated teams focused on this kind of work without having to invest an exorbitant amount of time determining what could or should apply.


Assemble Your Documents and Policies

These are the select components found within an EISP that aren’t overkill for an SME to incorporate into its program. You can find a sample EISP policy here. The heavy lifting comes in as you memorialize those activities into a structured document that doesn’t just live on a shelf collecting dust.

Very structured programs will have a hub and spoke approach, where additional policies arise from those outlined in this document in support of its objectives. Compliance will generally determine which documents you’ll be including, but every topic listed below is important.

This index will help you to collect and create the policies that you’ll be needing:


Outline Your Plan


You’ll begin by stating the commitment your organization has made to data confidentiality, integrity, and availability in support of operations as well as to comply with any applicable rules and regulations. Below is an example that makes a concise statement:

“The Commonwealth of Massachusetts. (“the Commonwealth”) collects, manages, and stores information on a regular basis in order to support business operations. The Commonwealth is committed to preserving the confidentiality, integrity, and availability of its information assets*. The Commonwealth must protect its information assets, provide for the integrity of business processes and records, and comply with applicable laws and regulations. This document, the Enterprise Information Security Policy (hereafter, the “Policy”), reinforces Leadership’s commitment, establishes high-level functions of an information security program, and outlines information security requirements to safeguard information assets and assist the Commonwealth to achieve its strategic objectives.”

The purpose here is to create a clear statement of the Authority, Scope, and Responsibilities that are enshrined in the program you’ve created. That answers the questions of who has ordered this program be created, what systems and departments it applies to, and who will carry out the work involved. This will have requisite C-level buy-in or mandates from a board of directors.

As you flesh out your initial outline further, consider additional facets of the program like:

  • Compliance: You may consider outlining penalties for non-compliance
    • Write ups, disciplinary action, etc.
  • Information Security Objectives: The guiding principle going forward should be how are you going to support Confidentially, Integrity, and Availability (CIA). You may find that banks and insurers are beginning to survey clients about these objectives, so it’s an added benefit to have them present in document form. This may include:
    • Managing risks to an acceptable level
    • Supporting governance structures to manage those risks
    • Having a strategy in place to protect your assets
    • Creating security awareness and accountability to adhere to best practices
    • Maintaining compliance with contractual obligations, laws, and regulations
  • Communications and Reporting: You’ll be responsible for making certain that your organization is aware of and can access all policies and documents related to information security and any modifications that might be made to them. I kept those documents in a shared folder on a file server that anyone has access to. Information security shouldn’t be a siloed activity.
    • You may want to consider having employees sign that they’ve read Acceptable Use and other policies during onboarding and are aware of where to find security policy documents. We incorporated it into our employee handbook and linked to them through an internal HR website.

Policies

The following are the specific elements required for IT and network security (your risk management controls go here). These could become secondary documents that flow from the primary program, and your auditor may determine which ones are mandatory. This is a general listing of what you’ll include, as well as supporting activities to produce a system to run your program.

Data classification

  • Outline data owners, custodians, and a privacy officer
    • Controls for each type of data
    • Responsibilities for each persona
  • Classify data by restricted, private, and public
  • This inventory will drive your compliance activities and determine the types of controls that are implemented below.

Technical Controls 

Technical controls will protect your data and help to ensure that the objectives of CIA are met. These aren’t all necessarily policies, but they’re the elements that back them up.

  • Application security
    • Supply chain management policies; we’d recommend checking out a new ISO standard called SPDX that’s making rounds.
    • Patching: Patching is a fundamental technical control to mitigate vulnerabilities from the operating system and down its stack
      • We recommend policies to ensure that critical OS updates aren’t ignored and installed in a timely manner.
      • Vulnerabilities are becoming more of a concern to IT administrators now that MFA has strengthened logins
    • Hardening Operating systems with policies that limit vulnerabilities
    • Application Lifecycle Management: This entails vendor management and ensuring software meets organizational standards
    • Penetration testing (if you’ve developed custom code in-house)
    • Only use applications that you need, especially on servers
    • Limit the ability of your staff to use unauthorized cloud services (via a broker) or to install applications independently. An SSO portal of approved applications can streamline their ‘asks’.
  • Identity and Access Management: EISP typically desires information to be ‘need to know’ for access rights and controls
    • Use MFA to protect user accounts; this is mandatory
      • Don’t use SMS tokens if possible; those are insecure
      • Push alerts are the most user-friendly (and highly secure) method
    • Consider single sign on with smart group attributes to maintain least privilege access to information
      • Nested group membership is a legacy Active Directory method of management, which can easily lead to users becoming overprivileged. 
    • Consider SSO to rein in bad passwords and not risk exploits that expose credentials on third party servers
    • Consider a cloud-based file storage services that has integrated security such as strong encryption and auditing
  • Network Management: These are example of technical controls to protect your network
    • Endpoint EDR protection: Modern EDR solutions combine AI with heuristics to sniff out irregular behaviors
    • A network map should exist and be maintained; access to network devices, even switches, should be limited.
    • Use device level certificates and UEFI security features to secure PCs.
    • Data Loss Prevention policies can prevent undesired data exfiltration
    • Encrypt your drives and dispose of old hardware appropriately 
    • Monitoring
      • SMEs don’t necessarily have the resources to adequately operate a Security Operations Center (SOC), but new managed solutions are emerging to do this at scale.
      • I found a SIEM to be useful in hunting down a desktop that had a Man-in-the-Browser attack that EDR failed to notice, passing EDI data from our ERP system to an external IP. However, most alarms were false and alert fatigue can quickly set it. I’ll admit that I didn’t conduct threat hunting on the alerts once we closed them.
      • I’d argue against having too many security systems as opposed to mastering the ones that you have.
    • Harden devices by enabling features such as flood guards and checking for /controlling any rogue devices that are involved in hardware based attacks
    • Zero Trust Security: Consider adopting a posture of zero trust access via conditional access
    • Work with certified partners and sponsor your network techs to obtain certifications from vendors
    • Change Management Procedures: This is something that should be outlined in policies as problems can affect availability. I once had an IT manager configure SMTP services on Windows Server, only for a misconfiguration to lead to our IPs to be blacklisted and a mission critical fax server to no longer operate for order processing.
    • Configuration management: Your organization should outline the checklist of tasks involved in setting up new servers, etc. These are forms that auditors will look for and they, like your master document, are subject to change management rules.

Mobile Security: Use MDM or other solutions to secure mobile devices, especially if your organization has a BYOD policy; read here for a better understanding of mobile security considerations. There are also cultural and privacy considerations that can make some BYOD technical controls controversial. This is a decision that your team will determine. The general rule of thumb is not to do anything that would impact the trust that your staff has in the IT department.

Physical Security

Not all controls are technical: physical access to your infrastructure or incidents such as uncontrolled fires can be just as damaging as a remote attack and rogue devices that are brought onsite are emerging as an alarming new threat vector in cybersecurity.

  • Deploy CCTV systems and other deterrents
  • Use appropriate door locks or a mantrap
  • Consider hiring security guards
  • Have a policy for asset management
  • Use the appropriate HVAC systems and fire suppression
  • Use proximity badges


Administrative controls 

Policies also help to regulate employee behavior and instill workers with knowledge about cybersecurity practices. You’ll recognize many of these from accounting internal controls.

  • Password policy: Use passphrases with a minimum password age; all passwords should be unique; consider using password management applications
  • Job rotation to avoid collision and internal threats
  • Mandatory vacations
  • Have an Acceptable Use Policy
  • Practice Least Privilege
  • Have a BYOD policy outlined
  • Training, onboarding and simulation
    • Employees should understand to say something when they see something, such as communicating through a different medium when they receive a suspicious email request from a colleague or business partner.
    • Consider using services that test your employees’ security awareness skills and reinforce their education(s).
  • Onboarding and offboarding policies
    • ISO wanted to see these policies and be certain that they were followed when I was an IT director.
    • This is vital to protect the confidentiality of information and safeguard against potentially seditious persons


Incident Response 

This would easily encompass a document onto itself, but it’s important to at least have a workflow to respond to security incidents. It’s not practical for an SME to have all of the requisite teams that an enterprise would throw at this problem, but that doesn’t mean you shouldn’t sketch out what your response will be, what the discrete steps are, and who’s involved.

  • Have a plan to identify, analyze, and respond; the NIST framework provides a simple overview of the activities involved. This may be via a third party such as an MSP, but you shouldn’t be without one.
  • Communications are as important as the response itself
  • Have an SLA with any partner to investigate incidents
  • Ensure that evidence is preserved from the most volatile to stable storage.

Disaster Recovery Plan

Storage is cheap; use it. You should have a plan and consider performing tabletop exercises to practice it. Recovering can be everything from a data back-up to a hot site that mirrors operations entirely, depending on your needs.

  • Note that ISO focuses heavily on this topic
  • Options include network disconnected offline backups, online cloud back-ups
  • Your recovery is only as good as your last back-up
  • Back-ups should be adequately secured, i.e. encryption 
  • Be mindful that your internet connection can become a factor in incomplete online backups; ensure that your pipeline can handle the volume of data you’re sending over the wire. The initial upload will be larger if you’re only sending the differential changes subsequently. Pay attention to your error logs.
  • Even the Volume Shadow Copy Service on Windows Server can be helpful if availability is lost for a single file. There were a few instances where my team was able to recover lost work this way.
  • Banks and insurers are increasingly asking for this to be done

Risk Management

Some, but not all, risks are acceptable; however, all risks can be managed. For instance, a few lost laptops annually may not justify paying for advanced tracking systems. The controls that were outlined above are some of the remedies to lower your risks. There are qualitative and quantitative ways to measure the organization impact of risks. These resources will help you:

  • An excellent overall overview of risk management formulas and a matrix to help make decisions about whether to accept or address risks.
    • It helps to be able to show management a dollar amount that’s associated with a particular risk.
  • Assessing risks begins with knowing your assets and ensuing activities such as data classification. 

Change Control (ISO, et al.)

Auditing regimes such as ISO specify distinct processes to govern your documents and record any changes that may be made to them. This often involves:

  • The requirement for internal roles outside of your department to approve your department’s changes (to avoid any conflicts).
  • A diagram that outlines policy framework coverage, which specifies which of your policies satisfies which auditing standard/policy.
  • Employees may resist documenting every change, but compliance is important for the system to function properly. Be mindful that individuals who are designated to approve changes can become bottlenecks. It’s important to have streamlined workflows and appropriate alerting to track tasks and ensure nothing is left on the table. This was a point of contention at my company when the volume of changes overwhelmed the people who were supposed to be reviewing them. It’s a marathon, not a race.

This was by no means an exhaustive list, but it will get you started.

Don’t Risk Being Unprepared

You could, like me, be tasked with an audit, which comes from a variety of sources with a variety of intentions depending on your industry. Audits are no longer superficial, where a few promises to do better will make the problem go away until next time. Either way, there are many common elements that will be listed as policies (or evidence) in an audit, and it’s my experience that auditors will always find something to justify their visits. 

By formalizing your security program, you can dramatically reduce the incidents of non-compliance. It will give you the ability to practice an internal audit prior to the official one: this is something that ISO looks favorably on, and practice avoids eleventh-hour panic and long days at the office (or your home office) that could otherwise be avoided. And, since your managers have skin in the game (whether they know it or not), a formalized security program ensures everyone is protected. A friend who’s an experienced security engineer recently told me: 

…There is no way that the baseline tasks that you outline [about forming a security strategy] can be done without some investment in time/resources/training …and when responsibilities are delegated without commensurate reasonable resources – then regulators and civil attorneys will place the “responsibility/blame” squarely on management.”

That’s a message IT admins should be equipped with when obtaining buy-in from management, because you’re going to have to do this someday, even if regulations don’t apply to you now. IT is becoming more heavily governed and process oriented; stay ahead of the curve and create a program before the absence of one becomes a torrent of (avoidable) trouble for your team. It’s a slow roll to establish a comprehensive security program, and procrastination isn’t your friend.

Many of the controls listed above are made possible using the JumpCloud Directory Platform. The platform is fully functional and free for your first ten users and devices with complimentary premium support available as you ramp up.

David Worthington

I'm the technical blogger for JumpCloud. JumpCloud certified, security analyst, a one-time tech journalist, and former IT director.

Continue Learning with our Newsletter