Warning — possible high-risk issue
It's important to follow a strict set of guidelines for maintaining, configuring, and using network devices. Common topics to address:
Warning — possible critical-risk issue
Even small networks should be protected by firewalls that are configured to filter both incoming and outgoing traffic, and to allow only those services that have been explicitly whitelisted. Firewalls provide a great basic defense layer, and they are rather easy to configure and maintain.
A DMZ (demilitarized zone) is a subnetwork for systems that are exposed to an untrusted network (i.e., the Internet). The purpose of a DMZ is to ensure that even if an externally exposed system is compromised, the attacker only has access to systems within the DMZ — not the internal network. Without a DMZ in place, a single missing security patch or a 0-day vulnerability in one of the exposed services can lead to a full compromise of the internal network.
A network zoning concept that groups and separates systems can help tremendously in the event of a system compromise. Confining an attacker to a zone ensures that even if that zone is lost, other systems that may be more valuable are still protected. Unless your network is very small, zoning is essential and is difficult to replace with other security controls. Without zoning, a compromise in a completely unrelated system might expose our confidential information.
Traffic sniffing is usually easily done, both within and outside of the internal network. Even on switched networks, an attacker can use ARP spoofing to route other systems' network packets through their computer and read the contents on the way through. The only effective protection is cryptography. All sensitive traffic should be both encrypted and signed: encrypted to protect against eavesdropping, and signed to make sure an attacker cannot simply modify the content of the transmitted messages.
Encrypted protocols are readily available for most purposes. In addition, many protocols — even those originally conceived as plain-text protocols — can be tunneled through SSL/TLS to add an encrypted and signed layer.
Encryption must be in place to protect confidential information that is transmitted over the network.
You should never use plain-text protocols for remote device administration and management. These protocols should use encryption to protect credentials passing over the network, and they should also protect the integrity of the transmitted commands in order to guard against manipulation.
Warning — possible medium-risk issue
In monitoring contexts, encryption requirements depend on the sensitivity of the information made accessible by the protocol. If sensitive information can be fetched, the protocol should be encrypted. Information gathered through monitoring interfaces can be highly valuable to an attacker; it often contains network and server details that can be used in subsequent attacks.
Protocols that allow access to files on the network should generally be encrypted, unless all of the information on the associated network shares is public. Unencrypted protocols for file access put both the confidentiality and the integrity of data at risk because an attacker can not only steal the information, but also modify it.
ARP spoofing was conceived to allow sniffing even on switched networks that don't send all traffic to a subnet. Because the ARP protocol does not have integrity protection, the attack is trivial.
Luckily, ARP spoofing is relatively easy to prevent, and even easier to identify. Switches that are capable of working on the IP layer have built-in defenses against this attack (they register when systems on two different ports claim the same IP address). Additionally, open source tools such as arpwatch can be used to identify an active attack and send out alerts.
It's very important to have controls in place to protect against this kind of attack.
A separate network for device management can help mitigate the risk associated with devices that do not support encrypted protocols. The dedicated management zone should generally not be routable from the regular internal network, and access to the zone should be restricted. Restriction methods include access control (such as 802.1x) and physical port protection.
For sensitive projects, it's best if networking devices are either administered exclusively through encrypted and integrity-protected protocols, or are managed through a separate and protected management network.
It's essential to monitor your network for events that may affect the availability, integrity, and confidentiality of data. Network events are numerous and varied, so it's important to find the right signals for your company's infrastructure, architecture, and services.
It's extremely important to understand what's happening on your network, and to identify security events. Not only should you monitor your network and its events, but you also need to identify people to alert when important signals occur.
It's important to monitor your network for events that may affect the availability of your (and our) data. Monitoring helps ensure that outages are swiftly identified and addressed.
Monitoring and alerting is strongly recommended, to ensure that unauthorized access and other security incidents are swiftly identified and addressed.
Note that this does not necessarily mean you need an intrusion detection/prevention system (IDS/IPS) on your network. In many cases, it can be just as effective to identify specific and custom signals that indicate a potential incident.
Log files from devices like firewalls, DNS servers, DHCP servers, and routers are indispensable in the event of a security incident. They're also a great source of signals to help identify security-impacting events in the first place. Network devices should produce adequate log files that are retained for at least six months, so that historic events can also be appropriately investigated.
With a central log collection location for all relevant networking systems, you can more easily correlate security-impacting events across multiple sources. Centralizing also simplifies log review. For sensitive projects, a central logging system is strongly recommended.
Because your Wi-Fi can be used to access a private/internal network, no encryption or WEP encryption is not sufficient. WEP was broken years ago and does not offer any real protection. Enterprise environments require WPA2-Enterprise.
WPA-PSK is not suitable for a corporate environment: on the one hand, one user on the network can sniff all other users' traffic, and on the other hand, the management of the preshared key is usually very challenging because it must be changed when an employee leaves the company. For companies that would need to share the key with 20 or more employees, the use of WPA/WPA2-Enterprise is strongly recommended instead.
Because your project seems to handle sensitive data, remote access to your internal network via VPN should be protected by strong authentication, such as a second factor or machine certificates stored on the system's TPM.
VPN authentication with a username and password alone is considered insufficient. It is very easy to phish users, and password reuse across services is extremely common (even when policies are in place to explicitly disallow password reuse). Remote access to the internal network should require strong authentication, such as a second factor and/or machine certificates (ideally stored in a TPM). The latter have an additional advantage: certificates are not easily transferred to non-corporate machines.
Warning
Using this authentication method without at least a username and password is highly unusual. Did you forget to check the "Username and password" box?
Because non-corporate machines cannot be centrally updated, managed, and malware-checked, allowing these machines access to the local network via VPN is extremely dangerous. Please ensure that technical controls are in place to prevent unmanaged machines from connecting via VPN.
Because non-corporate machines cannot be centrally updated, managed, and malware-checked, allowing these machines access to the local network via VPN is extremely dangerous. You've indicated that technical controls exist but you don't use a certificate. Describe the controls that are in place.
To ensure that outsourcing providers adhere to your policies and employ adequate security practices, it's important to regularly audit them. These security audits should be done at least annually so the providers can adapt to changing security requirements and identify possible issues quickly.
A set of hardening and/or build standards for servers helps to ensure that all systems are appropriately hardened. These standards should be applied to internally and externally exposed systems, and should include requirements such as:
You probably won't have to create these standards from scratch. Publicly available hardening guides can help you set requirements for your company's systems.
Do your hardening and build standards cover the following topics?
The topics listed in this question should be part of any set of hardening and build standards. You probably won't have to create these standards from scratch. Publicly available hardening guides can help you set requirements for your company's systems.
Even though internal servers (and the services they provide) might not be directly exposed to the Internet, it is important to harden them as a second layer of defense. If an attacker manages to compromise a single system, it should still be difficult for them to expand their access. Also, internal servers might be exposed indirectly as backends.
Because your project seems to handle sensitive data, it's important to document your hardening and build standards. Documentation helps ensure that standards are consistently applied, no matter which employee actually performs the hardening.
Server and service configuration tends to become more complex over time. Without established processes, configuration can become inconsistent among similar systems within the fleet. This is a common source of security issues: some systems are overlooked and continue to have issues that are caused by the configuration. Because your project has stricter requirements for confidentiality, integrity, and/or availability, it's important to establish configuration management processes.
Your project seems to handle sensitive data. Processes should be in place for regularly reviewing configuration files and settings, to ensure that they are appropriate and safe.
Unfortunately, security bugs and vulnerabilities cannot always be caught during the development process, particularly if the software is complex. Software vendors often issue patches and security fixes to address vulnerabilities that were identified after rollout. It is essential to have processes in place to monitor vulnerabilities in software and apply patches as soon as possible. Note that once a patch has been released, the vulnerability is public, so attackers can easily exploit it.
Not all patches are equally important; some must be installed very quickly to protect against likely compromise. Your patching process should include carefully considering the risk caused by each vulnerability, and triggering emergency procedures when appropriate so that affected systems are patched as soon as possible.
Relying on the update mechanism built into the operating system is generally not sufficient; typically, many applications are not covered. You should maintain an inventory of all software that is not covered by built-in updates, and your administrators should subscribe to the key sources of information on updates for that software.
Patches that are deployed without prior testing may have an adverse affect on the availability and integrity of the data hosted on your servers. Unfortunately, there is a long history of faulty security patches. It is generally impossible to test security updates exhaustively in all possible scenarios, so to be safe, you should first deploy patches on test systems that closely mimic your production environment.
Comprehensive logging of security events is absolutely essential for both the identification and the investigation of security incidents. Comprehensive logging is strongly recommended for systems with direct access to confidential information, as well as for surrounding systems.
Unfortunately, not all security incidents can be identified right away. Log files should be retained for at least six months so incidents can be appropriately investigated, even when they're discovered later on.
With a central log collection location for all relevant networking systems, you can more easily correlate significant events across multiple sources. Centralizing also simplifies log review.
Using domain administrator accounts all the time is fairly dangerous. When a system is compromised, the attacker inherits the privileges of the compromised user, so it's especially problematic when the user is a domain administrator. Administrators should use separate, regular accounts for most tasks, and that they authenticate as domain admins only when necessary. Readily available Windows tools (such as runas.exe) make this fairly simple.
When the root account is used for privileged actions, it's impossible to later trace the action to a specific person. The root password for *nix systems should be a highly guarded secret that is kept in a secure physical location (e.g., in an envelope in a safe), retrieved only when absolutely necessary, and changed after each use.
When you have separate individual accounts on each system, you can't centrally disable accounts or change a password for all machines. Individual accounts can be overlooked when an employee leaves the company, or you might forget to change a password on a specific machine. Having a central directly for authentication makes account management much easier and safer.
It appears that your project has strict requirements for confidentiality, integrity, and/or availability. To meet these requirements, you should regularly review administrative actions in order to catch and revert unauthorized changes.
If availability and integrity are important to your project, you should synchronize data between your primary site and a data center. Having a backup site helps ensure that an incident at one site does not result in data loss or inconsistencies.
Even if you synchronize data in near real time with an alternate site, you may also need to maintain a backup on tape or other removable media. Synchronization issues sometimes cause inconsistencies and mistakes that are propagated through multiple data centers, resulting in permanent data loss. Only regular backups that are stored offline can ensure recovery (for example, if something is accidentally deleted). Note that backups on removable media should be encrypted and stored off-site at a safe location.
Data on backup media is generally exposed to certain elevated risks, such as during transport to an off-site storage facility. Confidential data should be encrypted on backups. Encryption also makes it easier to destroy data — if the backup key is destroyed, the data can no longer be recovered and therefore can also be considered destroyed.
When backup media is stored near the main systems, there is a chance that in a disaster, both might be destroyed at the same time and significant data loss will occur.
Backups can only help if they work as expected, of course, and to make sure that is the case, recovery should be tested regularly. Testing should include both the common case of recovering small amounts of very specific data from backup media (e.g., files that have been accidentally deleted), as well as the (with luck, much rarer) case of restoring an entire system from backup.
A set of hardening and/or build standards should be applied to all client systems that are provided to users, and should include requirements such as:
>You probably won't have to create these standards from scratch. Publicly available hardening guides can help you set requirements for your company's systems.
Techniques such as the ones listed above should be part of any set of hardening and build standards for client systems. You probably won't have to create these standards from scratch. Publicly available hardening guides can help you set requirements for your company's systems.
Security requirements and other client system settings can be very difficult to manage, particularly with a large fleet of client systems. Mobile devices make this even more difficult, as they are often not in the same place and are easily overlooked. This is a common source of security issues; you should have a central way to manage client devices.
Availability, integrity, and/or confidentiality seem to be critically important for the data, systems, or services you provide. Processes should be in place for regularly reviewing standard client builds, to ensure that they are appropriate and safe.
Not all patches are equally important. Patches that fix remotely exploitable issues in client systems must be installed very quickly to protect against compromise. Your patching process should include carefully considering the risk caused by each vulnerability, and triggering emergency procedures when appropriate so that affected systems are patched as soon as possible.
Malware has become one of the most pervasive problems in computer security. Many computers on the Internet are infected with malware. It's important to have effective controls in place that detect, and ideally avert, malware infections.
Unfortunately, correctly identifying malware has become extremely difficult; it's very easy for malware authors to slightly modify their creations and evade detection. For best results, limit client systems to a whitelist of identified known good software. Products that facilitate a whitelist approach include Google Santa, Microsoft AppLocker and Bit9 Parity.
Comprehensive logging of security events is absolutely essential for both the identification and the investigation of security incidents. Client systems are often the first target a serious attacker will attempt to compromise, so it's important to have logging in place to catch such events.
Unfortunately, security incidents can't always be identified right away. Log files should be retained for at least six months so incidents can be appropriately investigated, even when they're discovered later on.
With a central log collection location for all relevant client systems, you can more easily correlate significant events across multiple sources. Centralizing also simplifies log review.
Allowing users to have administrator access is generally considered dangerous. In a malware attack or vulnerability exploit, the attacker inherits the user's privileges. It's fine to grant local administrative access on a need-to-have basis, but administrator privileges should be considered a risk, particularly for users who are not very well-versed in IT.
On both Windows and Linux machines, it is relatively easy to steal the hashes of the local administrator/root account. Using modern brute-force methods (such as rainbow tables, GPU cracking, etc.), literally billions of passwords can be tried each second. At that rate, even strong passwords can be found out in a very short amount of time. For best results, disable local administrative accounts or set different passwords for each machine. Otherwise an attacker who cracks the local administrator/root password will be able to expand their access to your entire fleet of client machines. Microsoft has released the Local Administrator Password Solution (LAPS) tool to help address this issue in Windows environments.
As of April 8, 2014, Windows XP is no longer supported and does not receive security updates or patches for critical vulnerabilities. Windows XP was originally released more than a decade ago, and it lacks many of the security controls that are common in more modern operating systems. Many exploits do not work on newer operating systems, thanks to mitigations that make buffer overflows and other memory corruption issues hard to exploit. Using up-to-date software and operating systems is an absolute necessity.
Trusting users to encrypt sensitive information on laptops is almost never an effective strategy. Full-disk encryption is strongly recommended. If a laptop contains information that might directly or indirectly compromise our confidential data (including data that indirectly gives access to our information, such as SSH keys, password hashes that may be reused on production systems, etc.), the hard disk must be fully encrypted. It's vital to ensure that the loss or theft of a laptop will not result in a data leak.
Mobile devices are extremely easy to lose or steal. If your users can access confidential information (or other information that might be used to indirectly gain access to confidential data) from mobile devices, adequate encryption is essential. Ideally, a device policy should be rolled out to all corporate phones to enforce encryption and password requirements, and to provide remote wipe functions.
Your project seems to deal with confidential information. On devices that contain information that might directly or indirectly compromise confidential data (including data that indirectly gives access to information, such as SSH keys, password hashes that may be reused on production systems, etc.), full-disk encryption must be enabled.
Because this project seems to deal with sensitive data, you should ensure that all confidential information is encrypted anytime it is stored on media that may be taken outside of a physically secure facility.
Technical testing by security specialists is absolutely necessary to ensure the security and proper configuration of all software that's used to handle confidential and sensitive information.
Unfortunately, automated security testing is insufficient. Many security issues can only be discovered by manual tests. Automated security scans can (and should) be performed internally as well. It's not necessary to hire outside consultants for internal scans.
Information systems are usually subject to frequent changes, and security threats also evolve rapidly. For these reasons, it's important to repeat security testing frequently (at least annually) to make sure security issues were not introduced by recent changes.
Automated security scans are a low-cost, low-effort way to make sure that known vulnerabilities and insecure misconfiguration in standard software are quickly identified and can be addressed. For best results, perform automated security scans at least quarterly. Ideally, scans should apply to both externally exposed and internal-only systems.
Information systems are usually subject to frequent changes, and security threats also evolve rapidly. For these reasons, it's important to repeat security scans frequently (at least quarterly) to make sure security issues have not been introduced by recent changes or recently discovered in off-the-shelf software.
Tip
It's important to scan both externally exposed and internal systems. The results of these scans are extremely valuable for vulnerability and patch management. They can — with very low effort — quickly identify components that have not received necessary patches.
Not every company can have the necessary know-how to do technical security/penetration tests on their own. But because your project has very high confidentiality and/or integrity requirements, it's important to have sufficient know-how and resources to do in-house technical testing of the services you provide.
Not every company can have the necessary know-how to do technical security/penetration tests on their own. To compensate, in-depth and frequent third-party penetration tests should be performed on both externally exposed services and internal-only systems.
Thank you for your diligence!
Status: No changes Download Answers Reset Questionnaire