Monday, 11 March 2013

OpSec Basics

This is a simple little list of OpSec ideas that should be followed in most situations. Nothing ground breaking, just a gentle reminder :)

Take regular backups

Regularly backup systems and data using a combination of incremental and full backups.

Encrypt transmitted data whenever possible

Even on local networks. You may have perimeter firewalls and a switched network, but you have to assume someone is listening.

Minimize software to minimize vulnerability

Reduce the attack surface for remote access and local privilege escalation by only having essential software installed and services running.

Run different network services on separate systems

Not only does this simplify diagnosing operational issues, but means a compromise of one service doesn't directly affect other services. It also reduces the possibility of another service being used in the next stage of an attack.

Least privilege

This should apply at all levels, from system accounts to application logins. Don't use shared credentials and use systems that have granular enough permissions. Someone might not want to do something malicious, but if their system has been compromised the attacker might.

Patch your sh!#

Unpatched software is a liability. Every unpatched system is low-hanging fruit for an attacker.

Be informed

You should have a clear insight into the standard operational and opsec behaviour of your environment. This means having good operational monitoring and metrics, security systems such as HIDS and NIDS and a hardened centralized log collector for system logs and SIEM. Once you have that, take the time to review logs, events and set up alerts if possible.

Segment your network

Compromise is inevitable  so the trick is to limit damage once it happens. Network segmentation stops the attack from moving around freely and thus adds complexity and delay to the next stages of their attack.

Use good crypto and don't roll your own

This applies to everything from choosing a password, to storing passwords and encrypting backups. Don't rely on home-made encryption or obfuscation tricks.

Have a response

It is a question of when you get hacked, not if. You should have an incident response plan well in advance of anything happening. Basics should include how to limit damage, how to collect information for forensics or the authorities and details of who to contact.

Default configuration

When you buy a new piece of kit, build a new system or install an application, or should remember to check and adjust any default configuration. Most things try to be easy, not secure, so leaving in default configuration can be dangerous. Default users are a classic example, but other more subtle configuration might give too much information away or might be permissive in terms of access or actions.


No comments:

Post a Comment