In global organizations, it pays to take advantage of local work.
These nexuses of local activity are arranged into branch offices; satellite entities that are run according to the headquarters’ strategies.
While this model allows for the removal of language barriers in sales, an optimal workforce strategy, and cheaper manufacturing, it places intense demands on the entire company’s security processes. Branch office security is difficult to pin down, but vital to ensure the safety of employees and customers alike.
Branches often need access to some of the same proprietary and customer data as its headquarters; manufacturing and development branches may even handle even more.
But, breaking down the reality of branch security makes it clear that these offices are almost always the weakest components of a company’s security strategy. Unlike the central headquarters, offices are often expected to operate on limited security resources.
This means an ongoing reliance on older-style network security tools like firewalls, and older SIEM tools.
The former sit at the perimeter of each branch, checking the ongoing network connections against inbuilt lists. But, the smaller budget leaves branches without a method to analyze connections going to and from other parts of the organization.
Because branch-based employees access corporate data, share files, and change the corporate landscape on a daily basis, they’re particularly attractive targets for profiteering cybercriminals.
After all, they just need a foothold through which they can spread laterally.
There are four key requirements for bringing branch protection up to par.
The old adage of protecting only what you can detect is part of the difficulty within branch security. Identifying data begins by conducting a data inventory: this is the systematic review and cataloging of the types of information stored within the branch.
A practical approach involves categorizing information into specific sensitivity levels, such as:
This classification will eventually help determine the level of security that these different data types need.
Alongside identifying what type of data each branch is handling, this audit also needs to determine exactly where each database is hosted, and the pathways taken by corresponding data.
Automated discovery tools can significantly expedite this process.
These solutions continuously scan and classify data across all systems, minimizing human error and enabling real-time data identification. This gives security teams an organized and far more reliable infrastructure that accurately traces each branch’s handling of sensitive data.
With data identified, it’s time to limit and control exactly how it traverses the networks.
The traditional approaches to this have revolved around a stack of security tools:
When all of these capabilities are applied in the context of monitoring a remote branch, it can quickly become unmanageable.
One answer to this that doesn’t sacrifice the granular data points from each tool is a unified platform.
This essentially takes the core capabilities of frontline security tools and adds an extra layer of alert analysis and categorization. Security analysts are then presented with a normalized view of individual networks and corresponding alerts.
Configuration changes can be made and pushed to all relevant devices at once, while branch-specific settings can be checked and verified by a headquarter-based team. Branch-based security analysts can be issued focused dashboards that only encompass their own systems and peripherals, empowering leaner on-site teams to proactively address gaps.
Not all users require access to every feature within a system. Different roles come with distinct responsibilities, which in turn need access to specific resources.
Role-Based Access Control (RBAC) enforces this principle by mapping users to roles with defined permissions. RBAC divides authorization into six fundamental components:
Users are the individuals or entities (like services, or devices) that individually access resources.
In RBAC each user is granted an explicit role – their job function or duty within an organization, like code owner. Each role has a bunch of permissions bundled in, which specify precisely which operations each role needs to perform day-to-day.
These operations can include any action that is changing the underlying system state, like pull requests.
Plus, RBAC also links each role to the objects being accessed. Objects include assets like files, datasets, and websites. Unlike operations, accessing objects doesn’t alter the system state. RBAC ensures only appropriate roles can access specific objects, maintaining security through access records.
Each of these components is linked through permissions: these specify the access allowed to each entity according to the user’s role, object, and requested operation. These can be as simple as read, write, execute, or modify.
With all of this set up, the RBAC system then continuously monitors the sessions linked to each user: these are the active periods of interaction between roles, operations, and objects.
With RBAC in place, branch-based staff can reliably access and share only the necessary data through consistently verified sessions, drastically cutting the risk of permissions-based attacks.
Finally, it’s worth highlighting the increasingly fuzzy boundaries of today’s organizations. From a security perspective, vendors can look very similar to small branches. They access and handle chunks of corporate data with perhaps even less visibility.
It’s why supply chain attacks account for some of the largest financial damage for their victims.
To combat this, a regular vendor assessment process needs to be executed. This is a systematic process that evaluates each vendor’s capacity to protect sensitive data and minimize the risks within their own architecture. This starts – like previous branch security steps – with the identification of a branch’s relevant vendors.
This must include:
The point of this is to prioritize vendors according to their potential risk level.
This should follow the vendor that accesses the most sensitive information, and how badly a failure would impact business operations. When starting to assess the highest-risk vendor, evidence needs to be taken from the vendor’s documents.
Security policies, indecent response plans, and relevant industry certifications should be included in their documents: if not, it’s possible to ascertain a vendor’s security through open source ratings. Threat intelligence feeds, public reviews, alongside previous security events and responses can add further insight into the risk facing each branch.
Check Point’s SASE platform that provides a universal, zero trust secure web gateway for employees. Branch and remote employees can connect directly to the internet, corporate applications, and SaaS tools through Harmony, allowing for complete connectivity visibility.
The SASE platform then provides granular security controls for the backend security team, mapping the complete geography of an organization’s networks and data paths.
Check Point’s SASE supercharges the security team’s threat detection and response capabilities with automated remediation, optimized routing, and comprehensive protection.
Explore Checkpoint’s SASE capabilities with a demo today.
