CYBER SECURITY SERVICES

9 Steps for all organisations

Risk Management Regime

 

Why defining and communicating your Board’s Information Risk Management Regime is central to your organisation’s overall cyber security strategy.

Summary

Organisations rely on technology, systems and Information to support their business goals. It is important that organisations apply a similar level of rigour to assessing the risks to its technology, systems and information assets as it would to other risks that might have a material business impact, such as regulatory, financial or operational risks. This can be achieved by embedding an appropriate risk management regime across the organisation, which is actively supported by the board, senior managers and an empowered governance structure.

Defining and communicating the organisation’s attitude and approach to risk management is crucial. Boards may wish to consider communicating their risk management approach and policies across the organisation to ensure that employees, contractors and suppliers are aware of the organisation’s risk management boundaries.

What is the risk?

Taking risk is a necessary part of doing business in order to create opportunities and help deliver business objectives. For any organisation to operate successfully it needs to address risk and respond proportionately and appropriately to a level which is consistent with what risks an organisation is willing, or not, to tolerate. If an organisation does not identify and manage risk it can lead to business failure.

The lack of an effective risk management and governance structure may lead to the following:

·         Exposure to risk: Without effective governance processes the Board will be unlikely to understand and manage the overall risk exposure of the organisation.

·         Missed business opportunities: Risk decisions taken within a dedicated security function, rather than organisationally, will be motivated by achieving high levels of security. This may promote an overly cautious approach to risk leading to missed business opportunities or additional cost.

·         Ineffective policy implementation: The board has overall ownership of the corporate security policy. Without effective risk management and governance processes the Board won't have confidence that its stated policies are being consistently applied across the business as a whole.

 

How can the risk be managed?

Establish a governance framework:  A governance framework needs to be established that enables and supports a consistent and empowered approach to risk management across the organisation, with ultimate responsibility residing at board level;

Determine what risks an organisation is willing to tolerate and what is unacceptable: Agree what risks you are prepared to tolerate in pursuit of your business objectives. Produce guidance and statements that helps individuals throughout the organisation make appropriate risk based decisions.

Maintain board engagement: The board should regularly review risks that may arise from an attack on technology or systems used. To ensure senior ownership and oversight, the risks resulting from attack should be documented in the corporate risk register and regularly reviewed. Entering into knowledge sharing partnerships with other companies and law enforcement, can help you understand new and emerging threats as well as share approaches and mitigations that might work.

Produce supporting policies: An overarching technology and security risk policy should be created and owned by the board to help communicate and support risk management objectives, setting out the risk management strategy for the organisation as a whole.

Adopt a lifecycle approach to risk management: Technology changes, as does the threat and therefore risks change over time. A continuous through-life process needs to be adopted to ensure security controls remain effective and appropriate.

Apply recognised standards: Consider the application of recognised sources of security management good practice, such as the ISO/IEC 27000 series of standards.

Make use of endorsed assurance schemes: Consider adopting the Cyber Essentials Scheme. It provides guidance on the basic controls that should be put in place to manage risk of online cyber attack to enterprise technology and offers a certification process that demonstrates your commitment to cyber security.

Educate users and maintain awareness: All users have a responsibility to help manage security risks. Provide appropriate training and user education that is relevant to their role and refresh it regularly. Encourage staff to participate in knowledge sharing exchanges with peers across your organisation and beyond.

Promote a risk management culture: Risk management needs to be organisation-wide, driven by corporate governance from the top down, with user participation demonstrated at every level of the business.

 

Step 1: - Setup your Risk Management Regime

Assess the risks to your organisation’s information and systems with the same vigour you would for legal, regulatory, financial or operational risks. To achieve this, we embed a Risk Management Regime across your organisation with support from directors and senior managers.

Would you like to talk about Cyber Security?

Training all users is the first step to combating cybercrime.  Users have to consider what they include in publicly available documents and web content. They should also be aware of the risks from discussing work-related topics on social media,
and the potential of being targeted by phishing attacks.

With our targeted ethical training we can ensure that everyone is up to date with the latest attack profiles.

Ready to find out more about User Education?

PROTECTION

Services

Traditional perimeter-based network defence is obsolete—transform to a Zero Trust model

 

Zero Trust overview

Instead of believing everything behind the corporate firewall is safe, the Zero Trust model assumes breach and verifies each request as though it originates from an uncontrolled network. Regardless of where the request originates or what resource it accesses, Zero Trust teaches us to “never trust, always verify.”

In a Zero Trust model, every access request is strongly authenticated, authorized within policy constraints and inspected for anomalies before granting access. Everything from the user’s identity to the application’s hosting environment is used to prevent a breach. We apply micro-segmentation and least privileged access principles to minimize lateral movement. Finally, rich intelligence and analytics help us identify what happened, what was compromised, and how to prevent it from happening again.

Zero Trust Across the Digital Estate

 


 

Zero Trust readiness across your user identities, devices, application, data, infrastructure, and networks

Step 3 - Network Permiter Defences

Lanmark will audit and block insecure or unnecessary services and only allow permitted websites to be accessed.

We can then start to protect your networks from attack by defending the network perimeter, filtering out unauthorised access and malicious content.  To make sure your vulnerability exposure is minimised we constantly monitor and test security controls 24 x 7 x 365.

Would you like to discuss our Zero Trust Model?

Step 4 - Malware Protection

Malware protection can block malicious emails and prevent malware from being downloaded from websites or emails.

Lanmark produces relevant policies and establishes anti-malware defences across your organisation using a series of tools and applications that can self heal and stop malware and ransomware in its tracks.

Ready to chat about Malware Protection?

Step 5 - User Privileges and Passwords

80% of breaches are brute force attacks using easy to guess or stolen user credentials.  A security policy can prevent users from selecting easily guessed passwords and locks accounts after a low number of failed attempts.

Lanmark can implement single sign-on solutions using Multi-Factor Authentication utilising tokens and biometric system.  We also implement password management solutions to relieve the burden from users.

Do you want to discuss Access  Control?

Step 6 - BYOD and Remote Working

By using Mobile Device Management technical controls we can limit access to business data without altering or interfering with personally-owned devices.

We will also help develop a mobile working policy and train staff to adhere to it. We can apply a secure baseline and build all devices to that specification.

Find out more about MDM and Access Control?

CYBER SECURITY MANAGEMENT

Services

Epicbackup – UK’s best backup and Disater Recover Solution

 

Summary

The Epicbackup service provides onsite backup appliances which utilise snapshot technology to continually backup all data drives on all physical and virtual Windows and Linux servers including SAN data.

All data is automatically encrypted and sent via VPN Internet links to our secure remote storage facility located within 2 x n+1 geographically distinct UK based datacentres.

Epicbackup is operational 24 x7 and managed by a team of backup, recovery and virtualisation experts, who can perform simple file restores, server virtualisation or if requested invoke your full Business Continuity recovery.

eCloud

Epicbackup's eCloud® provides you with the safety and security of knowing your data is safely held offsite and you can have access to business-critical applications in case of unplanned downtime.

RECOVERY TIME OBJECTIVES

Epicbackup Recovery Times

The Recovery Time Objective (RTO) is the duration of time and a service level within which a business process must be restored after a disaster (or disruption) in order to avoid unacceptable consequences associated with a break in business continuity.

Note: Estimated times are subject to data set sizes and Clients LAN and Internet bandwidth.

Problem

RTO

COMMENTS

Files

30 minutes

The backup technicians will start a file restore within 30 minutes of notification. Time to complete dependent on file recovery size

Single email recovery

2 hours

The backup technicians will start a mailbox restore and email content search within 30 minutes of notification. Time to complete is dependent on mailbox size.

Entire single mailbox recovery

2 hours

The backup technicians will start a mailbox restore within 30 minutes of notification. Time to complete is dependent on mailbox size.

Multiple mailboxes

4 hours

The backup technicians will start the mailbox restores within 60 minutes of notification. Time to complete is dependent on mailbox size.

Entire Exchange database

estimated

6 hours

The backup technicians will call your registered Exchange support contact within 30 minutes to discuss where to restore the database to and if log files are required to be restored. Your Exchange support contact will be responsible for getting your Exchange server back online and operational

Microsoft SQL or Oracle database

estimate

6 hours

The backup technicians will call your registered database dba to discuss where to restore the database to and if log files are required to be restored. Your DBA will be responsible for getting your database back online and operational

Server Failure

60 minutes

The backup technicians will start the server virtualisation within 30 minutes of notification. Time to complete the virtualisation of the server is dependent on the amount of snapshot files that need to be concatenated

Archive File/Folder/Database Recovery

24 hours

The backup technicians will start a restore from our datacentre repository within 8 hours of notification. Time to complete is dependent on file sizes and Clients internet connection speed.

Business Continuity / Premises Failure

estimated 8 hours

The backup technicians will call your registered Business Continuity contact within 30 minutes to discuss the nature of the emergency and possible recovery solutions. If full BCP is required, the backup technicians will start to virtualise server onto our datacentre fabric within 30 minutes of the call. The backup technicians will require the client’s IT support contact to initiate Internet DNS changes. Time to complete the virtualisation of all servers and test connections is dependent on the total number of servers to be virtualised

Restoration from BCP if in operation less than 24 hours

estimated 8 hours

The backup technicians will call your registered Business Continuity contact within 60 minutes to discuss the restoration process. As the BCP service has only been operational for a short amount of time it may be considered that restoration is not required and changed files are subsequently restored by backup technicians on an as needed basis. This approach can result in data loss. The clients on premises servers must be available and have Internet access. The backup technicians will require the client’s IT support contact to initiate Internet DNS changes back to their original state. Time to restore data from the datacentre to the recovered client servers is dependent on the total amount of changed data.

Restoration from BCP service

estimated 8 hours

The backup technicians will call your registered Business Continuity contact within 60 minutes to discuss the restoration process. The clients on premises servers must be available and have Internet access but should not be accessible by staff. Following data restoration, the backup technicians will require the client’s IT support contact to initiate Internet DNS changes back to their original state. Time to restore data from the datacentre to the recovered client servers is dependent on the total amount of changed data.

 

 

Step 7 - Protect Data

All businesses, regardless of size, should take regular backups of their important data, and make sure that these backups are recent and can be restored. By doing this, you're ensuring your business can still function following the impact of flood, fire, physical damage or theft.

Furthermore, if you have backups of your data that you can quickly recover, you can't be blackmailed by ransomware attacks.

Chat about Epicbackup, AWS or Azure backup?

Step 8 - Security Controls & Patch Management

Lanmark's Managed Service will apply security patches and ensure the secure configuration of all systems is maintained. We create a system inventory and define a baseline build for all devices giving a platform on which build automated monitoring and control of your environment.

We apply patches at the earliest possibility to limit exposure to known software vulnerabilities but we also have rigorous testing procedures to ensure manufacturers patches & hotfixes do not crash stable systems.

Patch Management

Best Practices

 

What is Patch Management?

Patch management is the practice of reviewing, understanding, testing, deploying, and reconciling the deployment state for software product updates. The goal of the updates is to correct problems, close vulnerabilities, and improve product functionality, which is essential to the stability of an IT infrastructure in most environments. By understanding the different kinds of patches and following best practices, an IT service provider can keep clients’ critical systems free from known vulnerabilities.

 

Is Patch management a significant concern?

With new vulnerabilities being discovered almost daily, keeping systems up-to-date with patches is often a full-time job, especially in larger environments. In addition, the lag time between when a vulnerability is discovered and when a virus or worm appears is now measured in days or weeks rather than months. This puts tremendous pressure on vendors to release patches before they’ve been fully regression-tested. The result is that oftentimes patches fix the problem they’re designed to address, but unintentionally break something else in the process. Patch management is often seen as a trivial task. Simply click on ‘update’, and that’s it. But in reality, there is a lot more to it, and a proper policy is certainly not overkill. But what should a patch management policy include apart from deploying patches?

 

Types of Patches

Hotfixes

Hotfixes are small patches designed to fix a single problem and are developed either in response to a security advisory or by customer request. Hotfixes are typically issued to either plug security holes, such as buffer overflows, or to fix features that don’t behave as intended.

 

Roll-Ups

Occasionally, Microsoft combines several hotfixes together into a single package called a roll-up. This is typically done when several security issues have been identified within a short time period, and its purpose is to simplify the job of installing hotfixes for administrators. Unfortunately, this is not always a good idea. There have been instances in which installing multiple patches broke applications, and the headache then arises – figuring out which patch in the roll-up actually caused the problem.

 

Service Packs

At fairly regular intervals, Microsoft combines all hotfixes issued for a platform into a single package called a service pack. These service packs are cumulative. For instance, Service Pack 3 includes all hotfixes issued both before and since Service Pack 2 appeared. While service packs undergo more thorough testing than individual hotfixes, there have nevertheless been a few instances in which a service pack caused new problems while solving others.

 

MSRC Ratings System

Hotfixes that address security vulnerabilities are also called security fixes, and the Microsoft Security Resource Center (MSRC) rates these according to a four-point scale from high to low. This is useful for administrators because it allows them to decide which fixes should be applied as soon as possible and which can be deferred until later or even ignored. The ratings also refer to the types of vulnerabilities they guard against. An example of a critical issue might be a self-propagating Internet worm that can bring servers to their knees and wreak other kinds of havoc, which means that your clients’ confidential business information might be at risk of being lost, stolen or corrupted. Moderate means you have a properly configured firewall and are following good security practices, so you aren’t likely to be affected by the problem, although it’s still possible. Finally, low means it would take a combination of a genius hacker and a negligent system administrator for the exploit to occur, but it’s still remotely possible.

 

Policy, Process, and Persistence

 

Policy

The first step in developing a patch management strategy is to develop a policy that outlines the who, what, how, when and why of patching your clients’ systems. This advance planning enables you to be proactive instead of reactive. Proactive management anticipates problems in advance and develops policies to deal with them; reactive management adds layer upon layer of hastily thought-up solutions patched together using bits of string and glue. It’s easy to see which approach will unravel in the event of a crisis.

 

When you have a patch management policy in place, and a notification arrives of a critical vulnerability in a software product, you immediately know who will deal with it, how you will deploy the patch, whether it needs to be done sooner or later, and so on. For example, a simple element of a patch management policy might be that critical or important patches should be applied immediately, while moderate or low patches should be submitted to a team member for further study. Another example is proactively scheduling a specific day of the week or month for installing patches (usually weekends, in case something breaks), as opposed to the drop-everything, the-sky-is-falling approach common in a reactive environment. Making a decision tree that addresses these issues ahead of time reduces anxiety and speeds response when the time comes to patch something.

 

Process

The detailed procedure you will use to respond to vulnerabilities and deploy patches should be explicit within your security policy. The typical patch management process is illustrated above by the process workflow in general terms, and includes aspects of the Information Technology Infrastructure Library (ITIL) to ensure success.

The following six-step process is defined as best practice by Microsoft and should also be considered as you craft your own tailor-made process for use within your managed services practice.

1.     Notification. Information comes to you about a vulnerability with a patch meant to eliminate it. Notification might be sent via email from the Microsoft Security Notification Service, a pop-up balloon when you’re using Automatic Updates, a message displayed in the Software Update Services (SUS) web console, or some other method. It all depends on which tools you use to keep your systems patched and up-to-date.

2.     Assessment. Based on the patch rating and the configuration of your systems, you need to decide which systems need the patch, and how quickly they need to be patched to prevent an exploit. Having an accurate inventory of systems and applications running on your clients’ networks is essential if you want to keep the networks secure against intrusion.

3.     Obtainment. How you get the patch you need depends on which patch management tools you choose to deploy. In general, such tools range from completely manual (i.e. visiting the Windows Update website) to almost entirely automatic (i.e. via remote monitoring and management software).

4.     Testing. Information Testing should always take place before you apply patches to production systems. Test your patches on a testbed network that simulates your production network. Remember that Microsoft can’t test all possible effects of a patch before releasing it, because there are thousands of applications that can run on servers and millions of combinations of applications. Thus, you must test patches before deploying them, especially if you have custom code running on your machines. If you need a way to justify the cost of purchasing duplicate equipment for a testbed network, tell the boss it’s like insurance. If you deploy patches to a client that has 15 systems, and you wreck all of them at the same time, that client is effectively out of business until you get everything restored. If you can’t afford to lose a client, you need to plan for some level of patch testing.

5.     Deployment. Based Deploy a patch only after you’ve thoroughly tested it. When you are ready to apply it, do so carefully. Don’t apply a patch to all your systems at once, just in case your testing process missed something. A good approach is to apply patches one at a time, testing your production servers after each patch is applied to make sure applications still function properly. A major consideration to deploying should also be based on geographic location. If you have a client with three locations, you should consider applying patches on three separate days to avoid a situation where you potentially take out the entire company if one patch has an issue following deployment. It is certainly better to be safe than sorry in this case, and the little extra care will go a long way with client relations if something negative were to result from the patch cycle.

6.     Validation. How The final step in the process is often forgotten: making sure that the patch has actually been installed on the targeted systems. The validation process must be completed so when it comes time to report on status to your client, you are certain that the data being submitted is an accurate representation of the actual patch status. This reporting and validation process takes some time, but it is a necessary procedure to ensure that service levels are met.

 

Persistence

Policies are useless, and processes are futile unless you persist in applying them consistently. Network security requires constant vigilance, not only because new vulnerabilities and patches appear almost daily, but because new processes and tools are constantly being developed to handle the growing problem of keeping systems patched.

Effective patch management has become a necessity in today’s information technology environments. Reasons for this necessity are:

·        The ongoing discovery of vulnerabilities in existing operating systems and applications

·        The continuing threat of attackers developing applications that exploit those vulnerabilities

·        Vendor requirements to patch vulnerabilities via the release of patches and updates

 

These points illustrate the need to constantly apply patches to your clients’ IT environments.

Such a large task is best accomplished following a series of repeatable, automated best practices. Therefore, it’s important to look at patch management as a closed-loop process. It is a series of best practices that have to be repeated regularly on your clients’ networks to ensure protection from exposed vulnerabilities. Patch management requires the regular rediscovery of systems that may potentially be affected, scanning those systems for vulnerabilities, downloading patches and patch definition databases, and deploying patches to systems that need them.

 

In Conclusion

Patch Management requires:

1.     Regular rediscovery of systems that may potentially be affected

2.     Scanning those systems for vulnerabilities

3.     Downloading patches and patch definition databases

4.     Deploying patches to systems that need them

Ready to discuss Managed Services?

Step 9 - Incident Management

Lanmark establishes an incident response and disaster recovery capability. We then test your incident management plans and provide specialist training.

By having a plan ready to mobilise we have the tools to deal with an attack and initiate a recovery of the situation without resorting to paying ransomware.

Would you like more information about our Incident Management Service?

COVID-19 : Lanmark is fully operational during this time.