Best Practices for Information Technology Operational Security
Best practices are technical procedures and configuration standards which, over time, have shown to be effective in reducing IT security breaches while having minimal impact on business operations. By definition, therefore, except in highly unusual circumstances, failing to implement all the best practices listed here means your company is taking unreasonable risks with its IT security.
Applying best practices, while valuable, does not necessarily fully secure your systems, however. For optimal security, your company should develop and maintain an information security program through a robust enterprise risk management process with full support of your top-level management. This will enable your company to know what additional procedures and controls should be implemented to fully protect your critical information and technology assets. Until this is complete, at a minimum, you should implement the best practices listed here.
The items in the list below are categorized by implementation complexity, as explained further in each section.
The J.D. Fox Micro List of 39 Best Practices for IT Operational Security
Baseline best practices are items that a non-technical manager can implement.
- Prohibit sharing of passwords. Each user will keep his account passwords secret, and not share it with others. Users sometimes give their passwords to co-workers to easily share a resource such as a file, folder, calendar, contacts list, software subscription license, etc. Instead, appropriate access should be configured by the system administrator for each user account.
- Do not send sensitive information, such as passwords, via e-mail. Unless you use encrypted e-mail, you should consider e-mail communications to be easily accessible by others, now or in the future. If you do not know whether you use encrypted e-mail, you most probably do not.
- Use separate login accounts for IT administration and ordinary production work. Often, in a small business, the owners and managers all have full system administrator privileges through the accounts they use to do their normal work. To minimize vulnerabilities, everyone up to the owner should use a standard user login account (with no administrator privileges) for daily work, and log in with a separate account to perform system administrator tasks. In addition, only those who perform or supervise administrative tasks should have administrator accounts.
- Deploy quality, paid endpoint protection software. This is commonly called "anti-virus" software.
- Ensure the keys to the kingdom are secure. Administrator passwords for your domain name registration, DNS hosting provider, website, and e-mail hosting provider should be known only to very few, highly trusted individuals within your company. Failure to protect this information could lead to a complete hijacking of your Internet identity, which would put most modern companies out of business.
- Physically secure your servers and data storage equipment. Use cables and locks, a locked rack, or a locked closet, or otherwise place your equipment so that it cannot be easily removed or tampered with.
- Hire professional IT support to assist with implementing the items below.
Technical Support Required
In a small business with no employees who are trained in information technology, the following best practices may be difficult to implement properly without professional support.
- Do not create shared login accounts. For anything that requires a user to log in with a password, every user should have his own named account. To share e-mail addresses, you should create distribution lists, configure delegation, or use other mailbox-sharing functions your mail system supports.
- Require complex passwords for all login accounts. If your systems can be configured to enforce this, do so. Pay particular attention to your voicemail system, as users commonly use a very simple PIN to access their voicemails.
- Require computers and mobile devices to lock when idle. This also may be enforcable through configuration, and it should include requiring a PIN or password to unlock (not just a swipe, for example).
- Create user account management checklists, and use them every time you on-board or terminate an employee, or when someone moves to a different role in the company.
- Configure SPF, DKIM, and DMARC in reporting mode for your domain e-mail. This is to minimize the ability for malicious actors to send e-mail purportedly from your domain.
- Ensure your IT service providers don't install backdoors. While it sounds really bad, the term "backdoor" in this context isn't necessarily nefarious, but it can be problematic. Many IT service providers set up connections between your equipment and theirs for convenience, without considering that it reduces your security posture or creates confusion. For example, they might set up login accounts where the purpose of the account isn't immediately clear or documented, set up remote access to your on-premises servers through a cloud-based account you do not control, or set up your scanner to relay e-mailed scans through their mail server. All of this presents a security risk, especially if you decide to discontinue the provider's services. Even if your relationship is good, if your IT provider does these things without advising you, it may indicate your provider is not respectful of your autonomy over your IT security.
- Change default passwords on all equipment: routers, firewalls, Wi-Fi access points, network switches, shared printers and scanners, etc. This will prevent users or visitors from easily changing configurations. Even if you trust your users not to do this, if you detect a breach, intrusion, or some other kind of intrigue in the future, you don't want to wonder whether it all started with someone being able to log in and change your systems' configuration to grant himself access he wasn't supposed to have.
- Disable unsused applications and services. Modern servers, storage devices, and cloud applications come with many file sharing protocols or network-accessible applications enabled. Anything that isn't in use should be disabled to prevent curious users from finding and using them when this isn't desired, or, worse, enabling unauthorized access through vulnerabilities in these applications.
- Limit user permissions to the least privilege required. For user login accounts, assign permissions only for files and folders the user positively needs; do not have a routine where users are assigned access to everything and then decisions made as to what to block. This applies as well to administrative privileges for administrators, not just company data for regular users. Also, do not provide regular users with administrator privileges on workstations unless there is an operational necessity and its impact is understood; otherwise the user will be able to install software you may not approve or bypass security controls. Finally, for cloud accounts, enable access only to the applications or services the user needs, and disable access to all others.
- Maintain server, storage, and network and communications hardware inventory. You cannot properly implement good change management procedures (see below) without an accurate and up-to-date inventory.
- Maintain configuration and performance documentation. This complements the above, and includes operating system and application software, database schemas, shared folders, Wi-Fi and VLANs, etc. It must include baseline configuration standards and performance metrics, as well as a log of all changes made.
- Back up data. Where to back up your company data, how often to back up, how long to keep backups, and how to categorize data to apply the most appropriate backup policy are all beyond the scope of a best practices list. That said, if there is any data that is of any value and you do not have another copy of it somewhere, then you must implement a backup system. This absolutely includes data stored in a cloud system.
- Ensure backups are stored offline. "Offline" here means the backed up data is not stored on the same equipment as the live data, and is not accessible by the users or systems that use the live copy of the data. This is important to protect against malware that may encrypt data for ransom (ransomware). A recent backup is the only way to recover from ransomware. But if such malware executes on your file or database server, and it can encrypt your files and database and then encrypt the backup storage connected directly to that server, then you will not be able to recover.
- Ensure backup storage is as secure as the primary storage. For example, do not have a user copy sensitive business data from your secured network storage to an unencrypted portable hard drive as your backup. As another example, do not copy files from a server that has been configured for highly restricted access onto a network storage device that doesn't have the same or more restrictive permissions for users to access it.
- Monitor and validate data backups regularly. Many companies set up an automatic backup system and then forget about it. The backup stops due to some sort of glitch, and nobody notices, sometimes for years, until there is a major data loss event. Don't let this happen.
- Implement an e-mail security system. At the very least, this includes scanning inbound messages for malware and unsolicited junk mail. Ideally, it will include intelligent scanning to block scam e-mails that attempt to trick users into revealing passwords or financial information, as well as outbound scanning to protect your company's reputation; however, as these functions require planning and introduce risks, they cannot be included in a list of best practices, as they may not be appropriate for your company. In addition, specific configurations within your e-mail security service, such as whether to implement controls to block directory harvesting, reject SPF failures, etc., should be determined depending on many factors specific to your operational requirements relating to e-mail, as well as the capabilities of your e-mail system itself.
- Implement a regular software update procedure. This applies primarily to security patches issued to address discovered vulnerabilities, some of which are very serious.
- Implement platform-specific hardening best practices of on-premises servers, networking equipment, storage devices, communications, remote access, and cloud services systems. This requires expertise on the given platform, and includes configuration items such as limiting permissions on login accounts used by services, disabling unneeded services, protecting security group membership, and configuring firewalls on a server. Or, for remote access (as another example), properly implementing features to protect the network from malware on the remote user's workstation or network, such as tunneling policy.
- Use uninterruptible power supplies (UPS) on equipment that doesn't have a built-in battery, to prevent unexpected shutdowns from brief power outages, which can cause corruption of data.
- Configure systems to temporarily lock out accounts after too many incorrect password attempts. This will foil brute force attempts to guess account passwords.
- Configure SSL encryption and valid digital certificates on all equipment that supports it. SSL is required to ensure communications with your equipment, including login passwords and configuration commands, are encrypted. Valid certificates prevent someone from impersonating a device and thereby stealing passwords even when encrypted. Not encrypting communications, or having administrators routinely bypass security warnings (such as for invalid certificates), fosters an unhealthy approach to security.
- Configure logging and alerts on equipment to track the status of free storage space, system performance, errors, failures, and pending failures.
- Assign individuals to receive and monitor alerts, and regularly check to confirm that alerts will be received. This last part can be accomplished either by having the alerting facility automatically send routine messages (such as a daily status log showing everything is okay) that the responsible individual will check for, or by having the responsible individual manually send test alerts on a schedule.
- Store IT equipment in a clean, dry, and cool room, away from hazards. Do not put your server or network equipment on a table in the open, or in a closet right next to office supplies where people come in and out, even if it's in a locked rack. You want to prevent outages or damage from people accidentally spilling liquids or dropping items on your equipment, or accidentally knocking out power or network cables.
- Employ a change management process. This means there is one person or group that is responsible for approving configuration changes prior to implementation, if multiple administrators have the capability to reconfigure your equipment, applications, databases, or user directories.
Technical and Management Support
These items require not only a technician to implement, but management buy-in, so that appropriate directives can be given to employees or other users to cooperate with the policy to be established. Cooperation will require minimal effort, of course, in keeping with the definition of best practices.
- Implement secure protocols only. This means disabling communications protocols that do not properly protect confidentiality or integrity. It may require upgrading hardware or software that does not support secure protocols.
- Establish a mobile storage policy, to limit or prohibit storing company data on thumb drives, or on local storage of mobile devices and laptops, in order to maintain proper control.
- Establish a cloud storage policy, to limit or prohibit storing company data on cloud services, especially by users logging in with accounts outside the control of your company.
- Establish equipment disposal procedures, to ensure data is properly wiped from disused equipment before it leaves company control.
- Assign data owners and a permissions management process for all files, folders, and databases. Many cloud services have very permissive data sharing capabilities unless you disable them. You must plan and configure sharing settings based on job roles, data types, the nature of the data, and other considerations you might identify. This might require reorganizing data, and can become very involved.
- Separate employee-owned devices from company-owned. This may include setting up separate networks at your facility (one for company equipment and one for employee-owned). Even if users do not bring their devices to your office, you should consider whether to configure remote access differently for employee-owned devices and company-owned, including access methods, applications and data to make available, and procedures for wiping company data off employee-owned mobile devices used to access company e-mail or files.
- Implement job separation and/or rotation. Except for the principals of the company or highly trusted individuals, nobody should have the authority to complete a sensitive transaction by himself from start to finish. This applies to operations such as generating and paying invoices, placing orders, reconciling bank and credit accounts, etc. It can also apply to those who handle data, such as technical personnel who make backups. This control is mostly operational and policy-based, but it can be enforced with technical configuration of permissions. By requiring more than one person to complete a transaction or handle data (separation), the assigned employees would have to collude to engage in malfeasance, which is much riskier than doing it alone. If separation is not feasible, you can rotate jobs, so that one employee can't have free reign to steal from your company without knowing that someone else will eventually take over the assets he used, leading to discovery of the misconduct. Rotation is particularly important in technology because auditing by supervisors may not reveal wrongdoing if the perpetrator is skilled enough at hiding the evidence from supervisors who do not have a high level of technical knowledge.
Not Best Practices
The following controls may be valuable, but are likely to impact operations and thus should not be implemented unless there is a reason, and only with careful and thorough planning. In addition, after deployment, they must be monitored and tuned to prevent negative impact to operations and ensure continuing value. These are listed here because you may see reference to them in administration consoles of your on-premises systems or cloud services, or in sales pitches from security solutions providers. Each has a brief description and explanation as to why they may or may not apply to your business.
- Denial-of-service prevention. These are controls that can protect your website or other publicly-accessible service nodes from being taken offline if malicious actors bombard them with network packets designed for that purpose. However, in many cases, implementing these controls can lead to legitimate visitors being blocked unintentionally, and most small businesses are unlikely to be the target of such attacks.
- Password expiration policy. Changing a password regularly protects a login account from continuing use by unauthorized individuals in the event the password was exposed, such as from a breach into the server that stores password information, or because the user wrote it on a sticky note attached to his screen. This can be enforced by configuring systems to expire passwords on certain routine time intervals (typically from 30 days to six months). The first time a user logs in after expiration, he will be prompted to create a new password. However, changing passwords regularly encourages users to write down passwords where they otherwise might not, making them more prone to exposure. In addition, depending on how the user is accessing a given resource, he may not be prompted to change the password when connecting or logging in after expiration, and thereby is unable to gain access, which generates calls to the help desk and impacts productivity.
- Multi-factor authentication involves requiring users to confirm their identity using an additional method beyond providing the correct password. This includes demonstrating possession of the user's mobile phone by typing a code sent via text message, scanning a thumbprint, or inserting a smart card. These require significant user training and complication leading to help desk calls, and may or may not be appropriate for a given company.
- Data loss prevention (DLP) and cloud security brokerage require significant re-engineering to implement. These are systems that employ sophisticated techniques to control egress of data via e-mail or cloud-based applications or storage systems, and may or may not represent a worthwhile investment for your company.
- Data file and e-mail encryption might seem highly useful for protecting confidential information, but it is not necessarily a good idea. Virtually all communications are encrypted when modern protocols are used, protecting the transmissions (the data in transit) from eavesdropping. Encrypting data in transit is trivial—it merely requires the two communicating nodes to establish temporary encryption keys, and then it's over. Encrypting the contents of an e-mail message where it may be stored on the mail server or your device (and the servers and devices of recipients), or data files on a local or cloud server, is more challenging due to the persistent nature of information in this form (referred to as data at rest). For data at rest, encryption keys must be shared and stored for a period of time, without being exposed, with every user that might need to open the file, and only with those users, as well as any automated systems (such a file indexer) that might need access. This process can become quite complicated. There is a risk of corruption (meaning data loss) during the encryption process of data at rest, something that can't happen to data in transit (the communicating nodes can re-send the information if it gets corrupted in transit). High performance applications can suffer from the additional overhead of encrypting data at rest. And finally, if physical and logical access controls in place already adequately protect the confidentiality of your data, encryption provides no benefit. Thus, while an information security policy or applicable laws may call for encryption of certain data at rest, it is by no means reasonable to state that encrypting data at rest merely for the sake of encrypting it is a best practice.
- Compliance. In IT, this term applies to legislation, government rules, or trade standards that establish requirements for IT system architecture, data management, notification requirements in case of a breach, etc. Whether and how to comply with a given set of standards is a management decision that is carried out by IT, and thus does not impact best practices you should implement for your company.
- Intrusion detection systems (IDS) or intrustion prevention systems (IPS) are technological solutions that monitor many aspects of your IT system's operation, such as the nature and rate of communications; functions executed on an application, infrastructure, or directory server; changes made to data files or database tables; login patterns, etc., to determine whether a malicious actor has gained access to the system. An IPS is a more capable but more complex type of IDS, in that it is positioned to block suspected unauthorized actions. Because this product area is so varied, it would not be correct to state that deploying IDS or IPS is a best practice. Rather, these systems might fall under the best practice, described above, of deploying solutions designed to achieve a baseline hardening or security posture of a given application or platform.
- Redundancy and replication both involve some sort of duplicate of hardware, applications, or data that is available to take over in case of a failure. Again, these are best implemented as part of a well-planned platform-specific design based on the platform's capabilities and your company's risk assessments and uptime/recovery requirements. Overlapping or excessive redundancy can actually reduce the readiness of your systems, or at least will represent unnecessary costs. As a result, redundancy and replication, in and of themselves, should not be included in our list of best practices.
This article applies to business and IT operations, and not to software development. Integrating security into the software development lifecycle is critical for creating secure applications, but the process, and its list of best practices, is quite different from IT operations.
For support implementing best practices for your information technology operations, contact J.D. Fox Micro.
To determine whether to implement security controls into your operations beyond best practices, and/or integrate security into your software development lifecycle, visit the J.D. Fox Exec website to get started developing an Information Security Program.