Security

Security measures can and should be customized on a case by case basis, and may vary depending on exactly what needs to be secured.  However, there are some basic guidelines that apply generally:

Follow the principle of least privilege.

  • That is, give access only to users or machines that need it, and provide the least amount of access necessary to accomplish a desired function. For example, give read only access where edit access is not needed, provide standard user access where administrative access is not necessary, allow unsolicited network connections only from systems you trust.

Use multiple layers of protection.

  • Don't rely entirely on a single tool or mechanism to protect your system or data.  For example, limit creation of accounts on a given system to only those with authorization to access it, but also set up rules, group memberships, or other mechanisms within the system to appropriately restrict access. 
  • Set up firewall rules to limit access to a system, but also employ other measures such as TCP wrappers on Linux (/etc/hosts.deny |hosts.allow) or share-level permissions in Windows to enhance or further shape access. 
  • In addition to using Windows Defender as basic protection against malware on Windows, use another anti-malware package such as Symantec Endpoint Protection or Malware Bytes that operates in a complementary fashion.

Disable or uninstall unnecessary services or programs. 

  • For instance, if you have no reason to allow remote console access to a machine, turn off the SSH or Remote Desktop service.  If such access is necessary, restrict the address space that can access it.

Review settings and test the configuration to be sure it behaves as you expect.

  • For instance, if you've set up firewall rules to allow only select traffic, scan the system from both a machine that *should* have access and one that should *not* and verify that the behavior is correct – e.g., on either a Linux or Windows system you might install a tool called Nmap and issue 'nmap [hostname | IP address]'.

Use third party tools to scan systems for weaknesses or vulnerabilities. 

  • For example, use Nexpose, Metasploit, ssllabs.com (for web servers), or other tools to scan a given operating system or website for known issues and implement the recommended remediation actions if problems are discovered. 
  • Be on the lookout for no-longer-secure cipher suites or SSL / TLS versions.

Before implementing any third-party product (especially "free" products), evaluate it for security holes and trustworthiness. 

  • Avoid installing software from questionable sources. 
  • Prefer programs that provide source code that is open to community review. 
  • Verify authenticity and integrity through evaluation of MD5 hashes or digital signatures.

Apply patches on a regular basis.

  • Automatic updates are preferable if appropriate for a given system:  e.g., set Windows Update to automatically update or use your Linux distribution's automatic options. 
  • If automatic updates are not possible because of the role a given system plays, run regular checks for patches, evaluate their importance, and plan backup / rollback strategies and downtime as necessary to patch the system.

Security measures can and should be customized on a case by case basis, and may vary depending on exactly what needs to be secured.  However, there are some basic guidelines that apply generally:

When building your own applications or websites, engage in secure coding practices. 

  • Be mindful of pitfalls such as accepting user input "as-is," without "cleaning" or escaping it. 
  • Never trust raw input from the web, as it may be used to attempt to "inject" extra SQL or OS commands that do things that may compromise the system or site.

Disallow the sending of sensitive information such as usernames and passwords over un-encrypted connections.

  • For example, enable SSL on websites as appropriate (for all sites, if possible, regardless of content).
  • Use only secure protocols like SSH or SFTP to connect to systems or transfer data or information.

Avoid storing sensitive information in "public" or unsecured areas. 

  • Appropriately restrict access to data and, if possible or where required, keep "at rest" data in an encrypted form.

Be aware of any requirements for system / application implementation for the kind of data you are storing or transferring. 

  • For instance, personal health information is subject to HIPAA requirements, financial operations may be subject to PCI requirements, services financed with federal grants may require adherence to FIPS guidelines, etc.