CompTIA Security_ Deluxe Study Guide_ SY0-201 - Emmett Dulaney [257]
Further proof: Have you ever downloaded an update from a well-known vendor who proved their identity with a digital certificate only to have that update crash your system? Enough said.
To gain the most from certificate security troubleshooting, follow these guidelines:
■ Stop assuming certificates prove trustworthiness.
■ Consider why you would want to trust each specific entity whose identity is proven by a CA.
■ Consider why you trust the CAs that you do (review the trusted roots list in your web browser to see which CAs you are trusting already).
■ Only choose to make the same selection for this certificate in the future when you are denying acceptance or trust of an entity.
■ When asked to retrust an entity, reconsider.
■ If any utility questions any aspect of a certificate, such as the common name (CN) on the certificate not matching the claimed name of a site, deny acceptance of the certificate.
■ Obtain your own certificate from a reputable CA, such as VeriSign. But don’t settle for a free or e-mail-only certificate; obtain a certificate that validates more than just a working e-mail inbox.
■ Require mutual certificate-based authentication from all Internet sites whenever available.
■ Make sure your client tools update their Certificate Revocation Lists (CRLs) before each check of a received certificate.
Certificates themselves cannot currently be spoofed or stolen after use. However, this security does not mean that fake certificates don’t exist or that abuse doesn’t occur. You need to be vigilant at inspecting certificates and assume the worst even when accepting the identity from a trusted CA.
Communications Security
Communications security is an ever-expanding branch of IT security and one that is often not given the respect and attention it truly deserves. Communications security encompasses all the means by which data can enter or leave your otherwise private LAN. Even with a strongly secured LAN, weak communications security can bring it all crashing down. Each pathway by which data can move is yet another route through which malware can gain entry and intrusions can take place. In the realm of remote access, several areas fall in this category and demand specific attention: dial-up, remote control/remote shell, and VPN.
Remote access is the broad collection of mechanisms that allow external entities to interact with an internal closed environment. These can vary greatly in regard to speed and breadth of access. But even a trickle of data can be used to infiltrate an apparent fortress. Consider how the Grand Canyon was carved through solid rock by just running water. You need to be aware of every flow of data that penetrates the boundaries of your private LAN and fully control each and every bit of data moving across such a gateway.
One of the most important steps in securing your LAN against malicious events performed over remote access links is to erect a first-stage defense. A first-stage remote access defense is a separate authentication system for remote access that preauthenticates all connections before they are allowed to interact with the LAN itself. These preauthentication systems serve as domain controllers for remote access connections. Thus, if the remote access user fails to properly authenticate to the first-stage defense barrier, they cannot even approach the internal domain controllers or servers on the LAN.
These preauthentication systems make full network attacks from remote links much more difficult. Without them, a remote access attack can directly affect any aspect of the internal LAN. Thus, a successful remote-access-based attack can affect all users. However, with a preauthentication system, most attacks, even initially successful ones, are prevented