Cybersecurity is a pressing concern for everyone, but small and mid-size enterprises (SMEs) are even more susceptible to cyberattacks than many might think. In a late 2021 survey, 42% of small business respondents reported having been hit by a cyberattack within the last year. And the average number of attacks per company is rising significantly for SMEs, clocking in at nearly the same rate as larger organizations.
Not every SME has the budget for an expansive security team, but that doesn’t mean they can’t build a successful security program. This post covers the frameworks and practices that can guide teams and their decision making when building (or rebuilding) a program from the ground up.
A Note on GRC and Frameworks
Governance, risk management, and compliance (GRC) forms the foundation of any successful security program. Typically, these components are wrapped up into what people usually just refer to as “compliance.”
As most IT professionals aren’t compliance experts, compliance can feel daunting for an IT team to navigate. But compliance isn’t as different from security as many believe. When boiled down to the basics, compliance is simply a matter of defining controls, and a control is simply a policy, a process, or a technology.
Frameworks can help you determine which controls your organization needs. NIST, for example, is a common framework that can help you understand the standard operating controls required for a holistic corporate security program. While NIST is more focused on government standards, it is a great guide for budding programs, especially for those who aren’t familiar with writing controls.
Compliance tip: When it comes to cloud security, research frameworks that align with the specific provider. For example, AWS has the Well-Architected Framework to guide users on the controls necessary to secure cloud infrastructure.
Steps to Building a Security Program
Security requires visibility into the inner workings of an organization. When approaching a new program, establish insight and documentation around the following:
- Logs. Areas without adequate logging and monitoring create potential risks. Use the following process to identify these gaps.
- First, investigate:
- What log sources exist in what applications.
- How these logs are retrieved.
- Then, create a matrix and document log details like:
- Technology and service source.
- Input and output methods.
- Finally, establish and execute on plans to automate log monitoring for effective security operations.
- First, investigate:
- Data flows. For both security and privacy, it is important to know what data is stored and processed through what systems. Investigate your data flows by interviewing data owners and developing data flow diagrams. These diagrams should document what data travels through the company’s environment and where it travels. This process will identify any areas where data has been mishandled and enable scoping for different compliance needs.
- Access. Knowing who has what access to which systems is crucial to protecting the data stored in them. Access and permissions should always align with the following two principles:
- Separation of duties: The principle that no one person should have enough access to misuse a system on their own.
- Principle of least privilege: The principle that users should be given the least amount of access they need to do their job.
To document access, start by creating an access control matrix. This will provide a powerful tool for:
- Onboarding and offboarding by helping IT personnel keep track of access and permissions for all the roles in the organization.
- Identifying and correcting gaps, especially areas where the principles of separation of duties and least privilege are violated.
- Providing evidence of controls around authorizing access. This can be helpful for tracking compliance.
Tracking vendors. Consider using this access document to aid in creating a vendor list.
Throughout the process of building out visibility documentation, take note of any risks you identify by starting a risk register.
Managing risks requires an element of project management: risks should be documented, and plans to address them should be tracked and managed. Your risk register should include everything you need to know about each risk, including ownership, plans for mitigation, deadlines, and more. For example, your risk register might include:
- An ID and description of the risk.
- The risk’s likelihood, impact, and severity. Use a standardized scale (i.e., 1-5) to quantify each.
- Treatment plan. Usually, treatment plans specify the approach the company plans to take to address this risk. For example, “mitigate,” “transfer,” and “accept” are common treatment plans for risks.
- Mitigating action. Specify the steps the organization plans to take to reduce the risk.
- Corrective action plan. Specify the steps the organization plans to take to implement the mitigating action.
- Corrective action plan results. Specify the results of the corrective action plan.
- An owner and approver for the risk’s remediation steps.
- Progress, due date, and completion date for the specified remediation steps.
Note that these categories are not exhaustive; your risk register may include additional data specific to your organization.
Risk assessment shouldn’t be a one-and-done activity, but rather an ongoing analysis. Continue to document and assess risks in the risk register with the process above when they are identified. This will keep the register up to date and functional, allowing it to inform decisions on which projects to prioritize based on their ability to reduce risk.
Define and Implement Controls
Here’s the fun part — making the magic happen! Each risk that is mitigated results in new controls or improved existing controls (again, a control is a policy, process, or technology). Each control must be defined and implemented.
For example, a risk such as “terminated employees retaining access to work accounts” will result in creating or improving employee offboarding processes, which may require a piece of technology — like an identity management platform. Then, those new controls should be added to policy, which authorizes and communicates the requirements throughout the organization.
The processes listed above, along with the regulations and frameworks that your company adheres to, should act as guidance for defining your controls.
Sometimes, making controls a reality is easier said than done. Implementing controls can be difficult — especially when working with a sprawled IT environment, which is fairly common in SMEs. Controls often span multiple areas and functionalities; in the previous example regarding terminated employees, for instance, mitigations result in both HR and IT controls. Similarly, a control like keeping policy up to date requires leadership from many departments. And controls like access requests, security training, and policy acknowledgements require every person in the organization to be successful.
In a sprawled environment with many point solutions rather than a few centralized and robust ones, data sometimes gets lost in translation. Information and processes may not transfer seamlessly from department to department, and tools may not successfully carry data from one point to the next. The result is gaps in visibility and communication, which create new risks and inefficiencies.
Having a central platform where you can implement and manage controls that span the entire organization is critical for effective, long-term security. For example, JumpCloud and CrowdStrike are designed to integrate seamlessly together to unify everything from identity and device management to endpoint detection and response (EDR) into one platform. This makes it easier to apply and monitor controls in one place while avoiding the risk of gaps in execution and visibility. Learn more about unifying your environment with JumpCloud and CrowdStrike.
Polices communicate controls with the entire organization. Ensuring user understanding and adoption of controls is critical to maintaining a secure environment; after all, users are security’s first line of defense. Having users review and agree to policies on at least an annual basis will provide awareness and accountability to all users in the organization.
Don’t forget to train and harden users on the different processes they need to comply with to protect against potential threats. These processes can range from reporting social engineering, to securing their home networks, to establishing strong authentication practices and requesting access via the right channels.
Security should be a holistic and iterative process: programs should be continuously improved upon. Fortunately, it doesn’t take a full third-party audit to check up on your security. For the SMEs that can’t afford a third-party audit when they start off, internal audits can be highly effective in gaining visibility into control consistency. Findings from these audits can be used to inform risk assessments and planning mitigations.
Start with a Unified Foundation
Sometimes, building a security program can feel like a series of expensive purchases — but it shouldn’t. In fact, unified IT and security environments with only a few robust tools are usually more secure and more cost-effective than an environment with all the “latest and greatest” point solutions. What’s more, unified environments streamline IT and security processes while providing a better experience for your teams.
Before you get started with building (or rebuilding) your security program, check out the benefits of unification so you can approach your program with the right mindset. Learn more about IT and security unification in JumpCloud and CrowdStrike’s whitepaper, Combining Business Priorities and Security: Choose Your Own Adventure.