Chapter 23
Troubleshoot Security Issues
This chapter covers the following official CompTIA Cloud+ exam objective:
5.2 Given a scenario, troubleshoot security issues.
(For more information on the official CompTIA Cloud+ exam topics, see the Introduction.)
The focus of this chapter is the troubleshooting of security issues. It is a broad topic and builds on many topics that were covered in previous chapters. You will learn about privileged accounts, troubleshooting authentication, and authorization, and you’ll gain an understanding of security groups.
This chapter will also explore keys and certificates, including how to handle expired, revoked, or compromised keys and certificates.
CramSaver
If you can correctly answer these questions before going through this section, save time by skimming the ExamAlerts in this section and then completing the CramQuiz at the end of the section.
1. _____ is the process in which a regular user account gains privileged access.
2. What is the range of server-side REST error codes?
3. A(n) _____ security group is a set of rules that allows or blocks access to resources for specific users or other cloud-based resources.
4. True or false: FTP is a secure protocol.
Privilege
Recall from Chapter 5, “Identity and Access Management,” that with privileged access a user is granted rights that allow for escalated access to a resource. This access is not something granted to a regular user account in most cases but is reserved for individuals who need to have more administrative control over a resource.
Managing privileged access poses several challenges. Most organizations follow a Least Privilege policy in which user accounts are given only the access that users need. The goal is to prevent users from having access to privileged operations that they are not required to have, but this can result in problems in which a user ends up with not enough access.
A user may end up having problems with privileged access for many reasons, which are covered next.
Missing
An account or role may be missing the privileged credentials altogether. To determine if this is the case, review access logs, group memberships, and account permissions using the Identity and Access Management (IAM) or the logging dashboard.
Incomplete
There may be several steps or components to providing privileged access to a resource. In this situation, each case is different, and there isn’t a single troubleshooting method to resolve the problem. As with missing privileged credentials, review access logs, group memberships, and account permissions. Also consult the documentation regarding how to set up the privileged access to determine if a step was skipped.
Escalation
Privilege escalation is the process in which a regular user account gains privileged access. The method used to perform the escalation can vary quite a bit. For example, a user working on a Linux virtual machine might use the su or sudo command to escalate his or her account to gain privileged access. Or, if the user is working with cloud-based accounts, security or IAM policies could be used to escalate the user account. Because there are so many methods to escalate user account privileges, there isn’t any single troubleshooting technique to determine the cause of errors. Consult log files and review the documentation for the escalation process to start the troubleshooting process.
Keys
Access to cloud resources may be granted via keys rather than the traditional username/password combination. Note that this topic will be covered in more detail in the “Keys and Certificates” section later.
Authentication
Recall from Chapter 5 that identification occurs when a user provides some sort of value, such as a username, to indicate who he or she is. By itself, identification isn’t enough to grant access to the system; the process of authentication must also be used. Authentication occurs when the user proves his or her identity by using another piece of information, such as a password or an access token.
In terms of troubleshooting authentication problems, consider the following:
Review security and access log files because often entries in the log files indicate the reason authentication fails.- Attempt to replicate the failure, where possible, in a nonproduction setup. In some cases, the cause of the failure is with the user making a mistake during the authentication process. This can include providing the wrong username/password combination or “fat fingering” the username or password. Users also might be trying to log in to the wrong resources. You might spend hours trying to troubleshoot an authentication problem only to discover it is a simple user error.
- Leverage cloud-native and third-party troubleshooting tools.
- Consider resetting the password or issuing new access keys.
- If the user is logging in via a web browser, consider having the user clear the browser cookies. Cookies can contain old, outdated information that can impact the authentication process.
- If using multifactor authentication (MFA), verify that all authentication components are working correctly.
Authorization
Recall from Chapter 5 that after a user has been identified and authenticated, that user is granted access to resources within the system. This is the process of authorization when an authenticated user is either allowed or denied access to resources based on predetermined rules.
In terms of troubleshooting authorization problems, consider the following:
- Verify that the resource that the user is being authorized to access is functioning properly and is accessible via the network. Note that the resource that provides the authorization may be different from the resource that the authorization is being provided to access.
- For token-based authorization, verify that the token hasn’t expired.
- Verify that the account has been correctly configured for access to the resource.
- Verify that the user is currently authenticated. Many authentication methods have a timeout value. If the user isn’t currently authenticated, the authorization method will fail.
- Many authorization methods use application programming interface (API) calls via a protocol like representational state transfer (REST). Standard error codes can indicate the source of an error. Error codes 100–199 are for informational purposes and are not normally used for troubleshooting problems. Error codes 200–299 are successful responses. Error codes 300–399 are for times when an API call is redirected to another resource. Normally, error codes 400–499 (client-side errors) and 500–599 (server-side errors) are used to troubleshoot API problems. See Table 23.1 for some of the most common REST error codes.
TABLE 23.1 REST Error Codes
Code |
Meaning |
|---|---|
400 |
Bad request |
401 |
Unauthorized |
403 |
Forbidden |
404 |
Not found |
405 |
Method not allowed |
500 |
Internal server error |
501 |
Not implemented |
502 |
Bad gateway |
503 |
Service unavailable |
Security Groups
In a cloud environment, a security group is used to control who can access a resource. Two types of security groups are covered here: network security groups and directory security groups.
Network Security Groups
A network security group is designed to provide protection to a network (VPC). These groups act like virtual firewalls for your cloud-based network. To troubleshoot a network security group, you follow many of the same steps as you would use with a standard firewall:
- Verify the problem applies to network access to your cloud-based network, not a problem with the resource itself that you are attempting to access.
- Verify that access is available within your cloud-based network.
- Determine whether there have been any recent changes to your network security group rules.
- Review the log file(s) for the network security group.
- Review the rule(s) for the network security group.
- Monitor network traffic while testing new configurations.
Note that errors related to network security groups could be either that access is blocked when it should be allowed or access is allowed when it should be blocked.
Directory Security Groups
A directory security group is a set of rules that allows or blocks access to resources for specific users or other cloud-based resources. The basic troubleshooting operations are similar to network security groups, but you are testing access based on users rather than connections from outside your network coming into your network.
Keys and Certificates
In cloud computing, keys provide an alternative method of authentication. Instead of providing a traditional username and password, an authentication key is provided instead. Keys are not normally used when users manually log in to a cloud environment but are leveraged when placing API calls to perform an action on a resource.
One of the problems with IT security revolves around the concept of trust. For example, suppose you want to connect to your bank online, and you type the bank’s URL in a browser. Your browser gets a response from a remote server, but how can you ensure that remote server is actually your bank and not a server that hijacked your connection attempt?
The solution to this issue is a digital certificate. When the browser connects to the server, the server issues a signature that is tied to a digital certificate. The web browser then consults a third-party organization called a certificate authority (CA) to verify the signature. The trust is built between the client system and the server by using the CA for verification. Public CAs are available for certificate signing.
You may encounter several issues when troubleshooting keys and certificates, including the ones described next.
Expired
Both keys and certificates can be set to expire after a specific period of time. This issue is much more common with certificates because setting an expiration date for a certificate is a default option. An expired key or certificate is no longer valid and will require issuing a new key or certificate.
Revoked
An administrator may decide to revoke a key or certificate either because he or she believes the access is no longer needed or because the key or certificate may have been compromised. A revoked key or certificate is no longer valid and will require issuing a new key or certificate.
Trust
Trust is more of a certificate issue than a key issue. For a certificate to be used, the client system must trust the CA. Typically, this is a configuration option on the client system. For example, in a web browser you can go to your settings and specify which CA servers the web browser will trust.
Compromised
A compromised key or certificate can pose a serious security risk. For example, if a key is compromised, the result can be unauthorized access to resources. If a certificate is compromised, the result can be a server hijacking and stealing sensitive information. Troubleshooting compromised keys or certificates can be challenging unless reported by the individual who allowed the compromise. For compromised keys, running audits that look for specious user activity can help. For compromised certificates, user complaints or the lack of traffic to a server can indicate a problem.
Misconfigured
Any misconfigured resource is likely to cause problems. Resources that rely on keys or certificates will not work correctly if the keys or certificates are not configured correctly. To troubleshoot this issue, review log files, double-check the configuration documentation to ensure all steps were followed correctly, and always remember to test a configuration after you have completed the setup process.
Misconfigured or Misapplied Policies
For more information on misconfigured or misapplied policies, see “Policies” in Chapter 7, “OS and Application Security Controls.”
Data Security Issues
This section will focus on data security issues that you will face within a cloud environment.
Unencrypted Data
See “Encryption” in Chapter 8, “Data Security and Compliance Controls in Cloud Environments.”
Data Breaches
If you pay attention to the news, you are probably aware of the rise in data breaches that have been reported by major organizations. Hackers are becoming more sophisticated and finding more ways to access organizations’ classified information.
To limit having to troubleshoot data breach issues, first focus on keeping the data as secure as possible. Securing the data includes following many of the policies and procedures that were covered in Chapter 8, including segmenting data, limiting access to data, and developing a good records management policy.
You should also consider the following steps to help troubleshoot when a data breach occurs:
- Use tools to determine whether a data breach has occurred.
- Have a plan in place in the event of a data breach.
- Do not hesitate to engage a third-party organization to help you mitigate the data breach.
- Contact law enforcement immediately because the sooner the crime is reported, the better law enforcement officers can provide aid.
Misclassification
See the “Classification” section in Chapter 8.
Lack of Encryption in Protocols
Protocols that lack encryption create the risk of data being stolen during transport. This issue can be mitigated if data is encrypted before transport using a separate utility, but it is normally better to avoid using protocols that lack encryption. As a result, you should avoid using the following protocols in your cloud environment:
- File Transfer Protocol (FTP)
- Telnet
- Network File System (NFS)
- Simple Network Management Protocol (SNMP)
- HTTP
There may be some exceptions to the “don’t use these protocols” rule. For example, modern organizations widely use FTP to share files as read-only to anonymous users. And within the confines of a protected network, some organizations use SNMP and NFS in specific situations, but they should never be used outside the company network.
Insecure Ciphers
Some ciphers are no longer considered to be secure because the algorithm used to perform the encryption is vulnerable to hacking attempts. Be aware of ciphers that the encryption industry now considers to be insecure and avoid using these ciphers:
- DES encryption cipher
- 3DES encryption cipher
- RC4 encryption cipher
- AES with CBC encryption cipher
Exposed Endpoints
An endpoint is any device or resource that is designed to be the destination in a network communication. Many endpoints are designed to be exposed to entities outside your network. For example, your web server and email server are endpoints that you want to be connected to the Internet. These endpoints should have a security plan in place to allow only the intended access to the endpoint.
However, many endpoints are not supposed to be exposed outside your network. For example, consider a database resource that stores sensitive company data. As a result, it is important to make sure these endpoints are secured behind a firewall or a similar security appliance.
Misconfigured or Failed Security Appliances
Note that the topics of this Cloud+ exam objective are covered in Chapter 6, “Secure a Network in a Cloud Environment,” and Chapter 7, “OS and Application Security Controls,” as follows:
- IPS: In the “Host-Based IDS (HIDS)/Host-Based IPS (HIPS)” section in Chapter 7
- IDS: In the “Host-Based IDS (HIDS)/Host-Based IPS (HIPS)” section in Chapter 7
- NAC: In the “Network Access Control (NAC)” section in Chapter 6
- WAF: In the “Web Application Firewall (WAF)” section in Chapter 6
Unsupported Protocols
An unsupported protocol is one that your organization has decided will not be permitted to be used. The reason for not using it could be security related or because the protocol does not support the organization’s business requirements.
Some tools, like port scanners, can be used to determine which protocols are being used on a cloud resource within your cloud infrastructure. For more details, see “Packet Capture” and “Packet Analyzer” in Chapter 25, “Troubleshoot Connectivity Issues and Common Performance Issues.”
External/Internal Attacks
A lot of security experts spend a great deal of time and effort trying to ward off external attacks. Tools and procedures covered in previous chapters, specifically Chapters 6–10, address many of these external attacks and how security experts attempt to prevent these attacks as well as troubleshoot issues that arise from these attacks.
However, internal attacks, which are attacks launched by valid users within the organization, must also be considered. A level of trust must be given to internal users, but this level of trust often makes it easier for an internal user to launch an attack.
Following are some procedures and tools that you can utilize to troubleshoot and limit internal attacks:
- Clearly document what actions are permitted and which actions are not permitted.
- Make users aware of their security responsibilities. For example, users should not walk away from their workstations unless they first lock their computer.
- Impose strict security requirements, including strong passwords.
- Secure internal resources, including the network.
- Use auditing tools to provide greater insight to user activity.
What Next?
If you want more practice on this chapter’s exam objectives before you move on, remember that you can access all of the CramQuiz questions on the companion website. You can also create a custom exam by objectives with the practice exam software. Note any objectives you struggle with and go to that objective’s material in this chapter.