Cybersecurity Interview Questions Part-4

In continuation of our interview series, here we are presenting the 4th part in our interview series.

Let’s begin:

Q1. How firewall can aid in malware mitigation?

An enterprise firewall between your internal network and the Internet provides one layer of protection for the internal computers. However, not all threats come through the “front door” of your organization’s network and through that firewall. Employee and consultant laptops that have been connected to public or home networks can become infected with malware. Once these users connect their computers, physically or through VPN connections, to your organization’s internal network they have effectively circumvented the Internet-facing firewall. Other possible “backdoors” that may allow worms to infect computers inside an Internet-facing firewall include users reading and downloading attachments from personal, external web-based email, employees using Instant Messaging (IM) or Internet Relay Chat (IRC) and users visiting web sites with malicious code. Phishing schemes (a combination of social engineering and HTML hyperlink trickery), spyware/adware, and DNS (Domain Name Service) cache poisoning can be used to trick users into visiting malicious web sites unintentionally. Upon visiting one of these web sites, the user’s web browser could automatically download or run malicious code, infecting the host computer and possibly other systems on the internal network.

Q2. What is the significance of IDS/IPS ?

Yes. An IDS (OR Intrusion Prevention System (IPS)) should be deployed on the network in an effort to find network attacks, to analyze and correlate these anomalies, and to react as needed.

The use of IDS/IPS devices can help to answer the following questions:

• Is the organization under attack?
• What IP/network is the source?
• What IP/network is the target?
• Which attack, if known, is being executed?

In a sense, an Intrusion Detection/Prevention System provides an ability to see the traffic coming and going across the network wires. Although an IDS/IPS is only as effective as the signatures it uses to detect intrusions, the network placement of the IDS/IPS sensors, and the analyst examining the IDS/IPS alerts, it is still a necessary and corroborative network device to add to an organization’s defense in depth strategy.

Q3. What are the difficulties in identifying the outbound traffic from the malicious programs?

Infected computers may attempt to join a botnet using IRC or web-based protocols to get instructions from the controlling server(s) of that network. These directions can include installing hidden key-logging software, performing covert network scans, performing a DoS (denial of service) attack, or participating in a DDoS (distributed denial of service) attack, and installing other malicious code onto that computer that may act as a “middle-man” hiding evidence of the compromise from AV scanners, firewalls and even experienced administrators. Worms may hide outgoing communications to its controlling computer by using random or nonstandard outbound ports for service protocols such as: IRC, FTP (File Transfer Protocol) and TFTP (Trivial File Transfer Protocol). It is not sufficient for an organization to block IRC traffic by only blocking ports 6666/TCP and 6667/TCP (the well-known ports for IRC). In fact, some recent variants have begun using port 80/TCP, which is the same port used for browsing web sites. Selecting a port used for normal business, combined with the trend for worms to encrypt their communications, makes it even more difficult for administrators to identify network traffic as malicious.

Q4. What are the main areas to be considered while attempting the mitigation ?

Defense in depth for most organizations should at

least consider the following two areas:

(1) protecting the enclave boundaries

(2) protecting the computing environment.

Q5. Explain about enclave boundaries in network.

The enclave boundary is the point at which the organization’s network interacts with the Internet. For the purpose of this article, the focus will center on firewall and intrusion detection/prevention systems usage.

1. Firewalls

The main purpose of a firewall is access control. By limiting inbound (from the Internet to the internal network) and outbound communications (from the internal network to the Internet), various attack vectors can be reduced. Acceptable inbound communication types for the organization need to be explicitly defined in the firewall policies. As the firewall is usually one of the first lines of defense, access to the firewall device itself needs to be strictly controlled. Conversely, the firewall also needs to be configured for authorized outbound network traffic. In the case of a compromised host inside the network, outbound or egress filtering can contain that system and prevent it from communicating outbound to their controller as in the case with bot-nets. Often times, firewalls default to allowing any outbound traffic, therefore, organizations may need to explicitly define the acceptable outbound communication policies for their networks.

In most cases the acceptable outbound connections would include:

• SMTP to any address from only your SMTP mail gateway(s);
• DNS to any address from an internal DNS server to resolve external host

names;

• HTTP and HTTPS from an internal proxy server for users to browse web

sites;

• NTP to specific time server addresses from an internal time server(s);
• Any ports required by AV, spam filtering, web filtering or patch

management software to only the appropriate vendor address(es) to pull

down updates; and

• Anything else where the business case is documented and signed off by

appropriate management.

2. Intrusion Detection Systems

The goal of an IDS (intrusion detection system) is to identify network traffic in near real time. Most IDSs use signatures to detect port scans, malware, and other abnormal network communications. The ideal placement of an IDS is external to the organization as well as internally, just behind the firewall. This way, an organization will have visibility to the traffic approaching the organization as well as the traffic that successfully passed through the firewall. Conversely, there will be visibility on internal traffic trying to communicate external to the network – particularly useful for situations where malicious activity originates from inside the firewall.

Q6. Brief about the Computing Environment in network.

Defending computing hardware and software from attack may be the first line of defense against the malicious insider — or it may be the last line of defense against the outsider who penetrates the enclave boundary defenses. In either case, defending the computing environment is necessary to establish an adequate information assurance posture.

1. Authorized Local Network Devices

Ensure that the only devices connected to the organization’s network are those items provided by the organization. USB thumb-drives, MP3 players, personal or consultant laptops may be a threat to your environment, therefore if an exception is required by business case, the owner should ensure the device is free of malware before being allowed to connect to the network.

2. Operating System Patching/Updating

Organizations should have a documented patching policy as well as a systematic,

accountable, and documented set of processes and procedures for handling patches.

The patching policy should specify what techniques an organization will use to monitor vendor sites for new patches and vulnerabilities and which personnel will be responsible for monitoring, retrieving and implementing those patches. It should also include a methodology for testing and safely installing patches. Pay particular attention to vendor reboot requirements as part of the patch process. Failure to execute this requirement can leave your systems vulnerable.

3. Operating System Hardening

Operating systems should be hardened to improve the ability to withstand attacks.

Various hardening scripts and checklists are available from NIST (National Institute of Standards and Technology), NSA (National Security Agency), and CIS (Center for Information Security).

4. Anti-Virus Updating

New viruses are discovered everyday. It is therefore recommended to set anti-virus

applications to automatically update signature files and scan engines whenever the

vendor publishes updates. Mobile and remote users should be required to connect at least weekly and if possible daily to obtain updated signatures. The organization should monitor anti-virus console logs to correct any systems that failed to be updated.

5. Change Control Process

Implement a change control process to document and review firewall and other network changes before they are implemented.

6. Host-based Firewall

Consider implementing host-based firewalls running on each internal computer and

especially laptops assigned to mobile users. Aside from the primary firewall functionality, many host-based firewalls have application hashing capabilities. This is helpful to identify applications that may have been trojanized after initial installation. It is also useful to validate whether an application has been legitimately updated or modified.

7. Vulnerability Scanning

Routine vulnerability scanning is a valuable practice for every organization. Host

scanning mimics the malicious network activity that networked hosts may encounter. Consequently, scan results can indicate which hosts are vulnerable to various types of attacks. These devices should be targeted by system administrators for immediate patching and remediation.

8. Use Of Proxy Servers and Web Content Filters

Implement outbound application layer proxy servers and web content filters to prevent users from inadvertently being directed to malicious web sites. This includes an outbound web proxy server that is the only computer allowed by the firewall to connect outbound using HTTP and HTTPS. If any of your systems become infected, the combination of proxy servers and firewall egress filtering will help contain the infection and hinder it from connecting to a host outside of your organization.

9. Email Attachment Filtering

Filter the following attachment types at your email gateway unless required for business use: .ade .cmd .eml .ins .mdb .mst .reg .url .wsf .adp .com .exe .isp .mde .pcd .scr .vb .wsh .bas .cpl .hlp .js .msc .pif .sct .vbe .bat .crt .hta .jse .msi .pl .scx .vbs .chm .dll .inf .lnk .msp .pot .shs .wsc. This list continues to grow. Organizations should consider only allowing file extensions with a documented business case and filtering all others.

10. Monitor Logs

Administrators should not rely solely on AV software and email filtering to detect worm infections. Logs from firewalls, intrusion detection and prevention sensors, DNS servers and proxy server logs should be monitored on a daily basis for signs of worm infections including but not limited to:

• Outbound SMTP connection attempts from anything other than your SMTP mail gateways
• Excessive or unusual scanning on TCP and UDP ports 135-139 and 445 Outbound connection attempts on IRC or any other ports that are unusual for your environment
• Excessive attempts from internal systems to access non-business web sites
• Excessive traffic from individual or a group of internal systems
• Excessive DNS queries from internal systems to the same host name and for known “non-existent” host names using a centralized means such as a syslog host to collect logs from various devices and systems can help in the analysis of the information.

Q7. What are the three broad strategies discussed and deployed while securing the network?

On a network level, it is a fact that eventually, some attacks will get through. To minimize the risks, your defenses should take a layered approach. These layers should:

1. Prevent malware from getting to your organization’s devices
2. Prevent malware from executing its malicious code
3. Prepare a rapid incident response plan to cyber attacks

Q8. What should be the response to any successful infiltration in network?

The manner in which an organization handles an incident will be highly tailored to that organization. Procedures should be based on the incident response policy inside the SOPs (Standard Operating Procedures) of that organization. An SOP delineates the specific technical processes, techniques, checklists, and forms used by the incident response team and the organization as a whole. SOPs should be comprehensive and detailed to ensure that the priorities of the organization are reflected in response operations. In addition, following these standardized responses should minimize errors, particularly those that might be caused by the increased tempo and stress occurring while responding to an incident. Finally, SOPs should be tested to validate their accuracy and usefulness, and then distributed to all team members.

If you don’t have an SOP below are some recommended, although not exclusive, steps you may

want to consider incorporating into an SOP to minimize sensitive information from being exposed.

Note that taking appropriate action quickly is essential.

1. If only a few systems are infected, physically disconnect them from your internal network immediately to contain the infection and prevent infected systems from connecting to the Internet.
2. If step #1 can not be accomplished in a timely manner or more than a few systems are infected and you have not implemented strong firewall egress filtering and proxy servers, immediately block ALL outbound traffic to external networks.
3. Implement filters on internal routers, firewalls and other networking equipment as appropriate to isolate infected segments and to monitor network traffic to ensure internal containment or identify how this infection is spreading and which hosts are infected. Monitor all network traffic in order to address possible multifaceted attacks.
4. Review appropriate log files to attempt to identify the first system infected and what the attack vector was if possible.
5. It is vital to determine if any of the infected systems successfully connected to any site on the Internet and what information, if any, was exposed.
6. Conduct a forensic examination of the system identified in step 4 to determine the extent of the compromise and remediation steps. Note that it is important not to trust any software and utilities that already exist on this system since they may also have been compromised or subverted. The examination should be conducted by loading fresh copies of the utilities, running them from good copies on write-protected, removable media or booting from good, write-protected media containing the utilities.
7. If the results of the forensic exam indicate a rootkit was installed, we then recommend for each infected system:
8. a) Ensure any needed data is backed up.
9. b) Reformat the hard drive.
10. c) Rebuild the system.
11. d) Ensure all security patches are applied.
12. e) Ensure the most current AV signatures are applied.
13. f) Restore the system to the network.
14. g) Change local administration passwords and the passwords for any user of the

infected system.

1. h) Change any network share passwords for users of the infected system.
2. i) Notify your information security team.
3. If the results of the forensic exam indicate a worm infection, we then recommend for each infected system:
4. a) Apply the appropriate security patches to the system.
5. b) Clean the infected machine using AV signatures that are verified to detect this

variant.

1. c) Change local administration passwords and the passwords for any user of the

infected system.

1. d) Change any network share passwords for users of the infected system.
2. e) Restore the system to the network.
3. f) Notify your information security team.
4. Once all the systems are cleaned, closely monitor for re-infection for the next

week.

10. If identifying personal information has been compromised, the individual(s)

should be notified.

Q9. What are the processes of Incident Lifecycle response?

These are the processes of the Incident Lifecycle Response:

1. Preparation
2. Detection and Analysis
3. Containment, Eradication & recovery
4. Post Incident Activity

Q10. Explain briefly about the various processes of Incident Lifecycle Response?

Organizations should perform preparatory measures to ensure that they are capable of responding effectively to malware incidents. Sections 4.1.1 through 4.1.3 describe several recommended preparatory measures, including building and maintaining malware-related skills within the incident response team, facilitating communication and coordination throughout the organization, and acquiring necessary tools and resources.

Building and Maintaining Malware-Related Skills

In addition to standard incident response team skills as described in NIST SP 800-61, all malware incident handlers should have a solid understanding of how each major category of malware infects hosts and spreads. Also, incident handlers should be familiar with the organization’s implementations and configurations of malware detection tools so that they are better able to analyze supporting data and identify the characteristics of threats. Incident handlers doing in-depth malware analysis should have strong skills in that area and be familiar with the numerous tools for malware analysis.

Facilitating Communication and Coordination

One of the most common problems during malware incident handling is poor communication and coordination. Anyone involved in an incident, including users, can inadvertently cause additional

problems because of a limited view or understanding of the situation. To improve communication and coordination, an organization should designate in advance a few individuals or a small team to be responsible for coordinating the organization’s responses to malware incidents. The coordinator’s primary goal is to maintain situational awareness by gathering all pertinent information, making decisions that are in the best interests of the organization, and communicating pertinent information and decisions to all relevant parties in a timely manner. For malware incidents, the relevant parties often include end users, who might be given instructions on how to avoid infecting their hosts, how to recognize the signs of an infection, and what to do if a host appears to be infected. The coordinator also needs to provide technical guidance and instructions to all staff assisting with containment, eradication, and recovery efforts, as well as giving management regular updates on the status of the response and the current and likely future impact of the incident. Another possible role for the coordinator is interacting with external parties, such as other incident response teams facing similar malware issues.

Acquiring Tools and Resources

Organizations should also ensure that they have the necessary tools (hardware and software) and resources to assist in malware incident handling

Detection and Analysis

Organizations should strive to detect and validate malware incidents rapidly to minimize the number of infected hosts and the amount of damage the organization sustains. Because malware can take many forms and be distributed through many means, there are many possible signs of a malware incident and many locations within an organization where the signs might be recorded or observed. It sometimes takes considerable analysis, requiring extensive technical knowledge and experience, to confirm that an incident has been caused by malware, particularly if the malware threat is new and unknown. After malware incident detection and validation, incident handlers should determine the type, extent, and magnitude of the problem as quickly as possible so that the response to the incident can be given the appropriate priority.

Identifying Malware Incident Characteristics

Because no indicator is completely reliable—even antivirus software might mis categorize benign activity as malicious—incident handlers need to analyze any suspected malware incident and validate that malware is the cause. In some cases, such as a massive, organization-wide infection, validation may be unnecessary because the nature of the incident is obvious. The goal is for incident handlers to be as certain as feasible that an incident is caused by malware and to have a basic understanding of the type of malware threat responsible, such as a worm or a Trojan horse. If the source of the incident cannot easily be confirmed, it is often better to respond as if it were caused by malware and to alter response efforts if it

is later determined that malware is not involved. Waiting for conclusive evidence of malware might have a serious negative impact on response efforts and significantly increase the damage sustained by the organization.

Identifying Infected Hosts

Identifying hosts that are infected by malware is part of every malware incident. Once identified, infected hosts can undergo the appropriate containment, eradication, and recovery actions. Unfortunately, identifying all infected hosts is often complicated by the dynamic nature of computing. For instance, people shut hosts down, disconnect them from networks, or move them from place to place, making it extremely difficult to identify which hosts are currently infected. In addition, some hosts can boot to multiple OSs or use virtual operating system software; an infection in one OS instantiation might not be detectable when a host is currently using another OS. Accurate identification of infected hosts can also be complicated by other factors. For example, hosts with unmitigated vulnerabilities might be disinfected and reinfected multiple times. Some instances of malware actually remove some or all traces of other malware, which could cause the partially or fully removed infections to go undetected. In addition, the data concerning infected hosts might come from several sources—antivirus software, IDSs, SIEMs, user reports, and other methods—and be very difficult to consolidate and keep current.

Forensic Identification

Forensic identification is the practice of identifying infected hosts by looking for evidence of recent infections. The evidence may be very recent (only a few minutes old) or not so recent (hours or days old); the older the information is, the less accurate it is likely to be. The most obvious sources of evidence are those that are designed to identify malware activity, such as antivirus software, content filtering (e.g., anti-spam measures), IPS, and SIEM technologies. The logs of security applications might contain detailed records of suspicious activity, and might also indicate whether a security compromise occurred or was prevented.

With this we conclude our 4th part here, stay tuned for our next part (Part 5), follow cybervie and stay tuned for our next part..