Introduction to IT infrastructure security

In this Lesson, you will look at an organisation's IT infrastructure security requirements and its associated documentation.

Along the way you'll be dealing with various technical security controls, including:

System, application, and software patching.
Data back-up.
Protective monitoring.
Network intrusion devices.
Penetration testing.

Operational security

One of the key functions in protecting systems is implementing a robust patching policy to protect the organisation from attack. This applies to all systems and application software running on the managed host systems.

Decorative image: Patching systems

Patching

You've previously heard of patching in the lesson but it's good practice to recall what a patch is as you're going to be examining patching in more depth now.

A patch is a piece of software code that can be applied after the software program is installed to correct an issue with that program.

Computer hope

Some applications are more susceptible to attack than others. For example, Adobe Acrobat Reader has had many serious security flaws that have been exploited by hackers. As most computers have this product installed, it's an obvious target. Another hugely popular but now expired software, Flash also had many serious weaknesses and is now at End-of-Life (EOL).

A patching policy should also apply to all embedded devices, like network infrastructure components and SCADA systems.

Many organisations have a team dedicated to analysing emerging threats and patches offered by vendors. They establish the criticality of the patch and whether it impacts their estate.

Severity rating 

While software vendors typically supply a severity rating for their patches, it might be that, for a given IT infrastructure, the potential impact of the vulnerability doesn’t warrant the immediate application of the patch. So, the security team should recommend the timeframe it should take to deploy a patch or set of patches – perhaps stating that a critical patch is deployed within 48 hours while standard non-critical patches are deployed within 4 weeks through a normal system update cycle. 

Patches should be tested before being deployed – they can cause adverse side effects if the vendor hasn’t carried out enough regression testing. 

Back up and archiving 

All data, including transaction logs and audit trails, should be backed up. 

This means making copies of data so that a system can be restored in the event of data loss. 

The organisation’s business requirements should dictate how long it would take to recover from a failure. This is typically documented in the Business Impact Assessment, performed during the risk assessment phase of the Information Security Management System implementation. 

Archiving is the planned movement of old data from online storage onto a less expensive storage tier for long-term retention. Historically, physical tape was used because it was inexpensive. Now, there are many types of storage devices and options for backing up and archiving data, including Storage Area Networks and Virtual Tape Libraries. 

A backup and recovery policy should incorporate the backup strategy. The factors to consider include: 

Whether the backups are full or incremental, or a combination of both. 
The frequency of backup. 
The backup rotation – a typical method is grandfather-father-son where three generations of backup are held to provide maximum protection against a malware infection or corrupt data. 
Storing backups in a secure offsite location.

Recovery testing 

Recovery testing should also be covered in the policy. It’s common for an organisation to discover that their backups haven’t been working and this exposes them to severe risk of data or service loss. Recovery tests should be performed at least once a month and event logs related to backups checked for errors. 

An offsite storage facility should have the same level of physical security regime as the primary data centre – backup tapes could hold an organisation’s trade secrets, private client details and system code. 

Key points

Let’s take a look at some of the key points to take with you as you move through the rest of this Course and lesson:

One of the key functions in protecting systems is implementing a robust patching policy to protect the organisation from attack.
A patching policy should also apply to all embedded devices, like network infrastructure components and SCADA systems.
Patches should be tested before being deployed – they can cause adverse side effects if the vendor hasn’t carried out enough regression testing.
Recovery tests should be performed at least once a month and event logs related to backups checked for errors.

IT infrastructure security [ISME]