QUESTION NUMBER 71-75
71. What are the various functions of log management infrastructure?
72. Write short note on Syslog Security
Syslog was developed at a time when the security of logs was not a major consideration. Accordingly, it did not support the use of basic security controls that would preserve the confidentiality, integrity, and availability of logs. For example, most syslog implementations use the connectionless, unreliable User Datagram Protocol (UDP) to transfer logs between hosts. UDP provides no assurance that log entries are received successfully or in the correct sequence. Also, most syslog implementations do not perform any access control, so any host can send messages to a syslog server unless other security measures have been implemented to prevent this, such as using a physically separate logging network for communications with the syslog server, or implementing access control lists on network devices to restrict which hosts can send messages to the syslog server. Attackers can take advantage of this by flooding syslog servers with bogus log data, which can cause important log entries to go unnoticed or even potentially cause a denial of service. Another shortcoming of most syslog implementations is that they cannot use encryption to protect the integrity or confidentiality of logs in transit. Attackers on the network might monitor syslog messages containing sensitive information regarding system configurations and security weaknesses; attackers might also be able to perform man-in-the-middle attacks such as modifying or destroying syslog messages in transit.
As the security of logs has become a greater concern, several implementations of syslog have been created that place a greater emphasis on security. Most have been based on a proposed standard, RFC 3195, which was designed specifically to improve the security of syslog. Implementations based on RFC 3195 can support log confidentiality, integrity, and availability through several features, including the following:
Reliable Log Delivery.
Several syslog implementations support the use of Transmission Control Protocol (TCP) in addition to UDP. TCP is a connection-oriented protocol that attempts to ensure the reliable delivery of information across networks. Using TCP helps to ensure that log entries reach their destination. Having this reliability requires the use of more network bandwidth; also, it typically takes more time for log entries to reach their destination. Some syslog implementations use log caching servers
Transmission Confidentiality Protection.
RFC 3195 recommends the use of the Transport Layer Security (TLS) protocol to protect the confidentiality of transmitted syslog messages. TLS can protect the messages during their entire transit between hosts. TLS can only protect the payloads of packets, not their IP headers, which means that an observer on the network can identify the source and destination of transmitted syslog messages, possibly revealing the IP addresses of the syslog servers and log sources. Some syslog implementations use other means to encrypt network traffic, such as passing syslog messages through secure shell (SSH) tunnels. Protecting syslog transmissions can require additional network bandwidth and increase the time needed for log entries to reach their destination.
Transmission Integrity Protection and Authentication.
RFC 3195 recommends that if integrity protection and authentication are desired, that a message digest algorithm be used. RFC 3195 recommends the use of MD5; proposed revisions to RFC 3195 mention the use of SHA-1.
Some syslog implementations offer additional features that are not based on RFC 3195. The most common extra features are as follows:
Robust Filtering.
Original syslog implementations allowed messages to be handled differently based on their facility and priority only; no finer-grained filtering was permitted. Some current syslog implementations offer more robust filtering capabilities, such as handling messages differently based on the host or program that generated a message, or a regular expression matching content in the body of a message. Some implementations also allow multiple filters to be applied to a single message, which provides more complex filtering capabilities.
Log Analysis.
Originally, syslog servers did not perform any analysis of log data; they simply provided a framework for log data to be recorded and transmitted. Administrators could use separate add-on programs for analyzing syslog data. Some syslog implementations now have limited log analysis capabilities built in, such as the ability to correlate multiple log entries.
Event Response.
Some syslog implementations can initiate actions when certain events are detected. Examples of actions include sending SNMP traps, alerting administrators through pages or e-mails, and launching a separate program or script. It is also possible to create a new syslog message that indicates a certain event was detected.
Alternative Message Formats.
Some syslog implementations can accept data in non-syslog formats, such as SNMP traps. This can be helpful for getting security event data from hosts that do not support syslog and cannot be modified to do so.
Log File Encryption.
Some syslog implementations can be configured to encrypt rotated log files automatically, protecting their confidentiality. This can also be accomplished through the use of OS or third-party encryption programs.
Database Storage for Logs.
Some implementations can store log entries in both traditional syslog files and a database. Having the log entries in a database format can be very helpful for subsequent log analysis.
Rate Limiting.
Some implementations can limit the number of syslog messages or TCP connections from a particular source during a certain period of time. This is useful in preventing a denial of service for the syslog server and the loss of syslog messages from other sources. Because this technique is designed to cause the loss of messages from a source that is overwhelming the syslog server, it can cause some log data to be lost during an adverse event that generates an unusually large number of messages.
73. Explain the Need for Log Management
Log management can benefit an organization in many ways. It helps to ensure that computer security records are stored in sufficient detail for an appropriate period of time. Routine log reviews and analysis are beneficial for identifying security incidents, policy violations, fraudulent activity, and operational problems shortly after they have occurred, and for providing information useful for resolving such problems. Logs can also be useful for performing auditing and forensic analysis, supporting the organization’s internal investigations, establishing baselines, and identifying operational trends and long-term problems.
Besides the inherent benefits of log management, a number of laws and regulations further compel organizations to store and review certain logs. The following is a listing of key regulations, standards, and guidelines that help define organizations’ needs for log management:
Federal Information Security Management Act of 2002 (FISMA).
FISMA emphasizes the need for each Federal agency to develop, document, and implement an organization-wide program to provide information security for the information systems that support its operations and assets. NIST SP 800-53, Recommended Security Controls for Federal Information Systems, was developed in support of FISMA. NIST SP 800-53 is the primary source of recommended security controls for Federal agencies. It describes several controls related to log management, including the generation, review, protection, and retention of audit records, as well as the actions to be taken because of audit failure.
Gramm-Leach-Bliley Act (GLBA).
GLBA requires financial institutions to protect their customers’ information against security threats. Log management can be helpful in identifying possible security violations and resolving them effectively.
Health Insurance Portability and Accountability Act of 1996 (HIPAA).
HIPAA includes security standards for certain health information. NIST SP 800-66, An Introductory Resource Guide for Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule, lists HIPAA-related log management needs. For example, Section 4.1 of NIST SP 800-66 describes the need to perform regular reviews of audit logs and access reports. Also,
Sarbanes-Oxley Act (SOX) of 2002.
Although SOX applies primarily to financial and accounting practices, it also encompasses the information technology (IT) functions that support these practices. SOX can be supported by reviewing logs regularly to look for signs of security violations, including exploitation, as well as retaining logs and records of log reviews for future review by auditors.
Payment Card Industry Data Security Standard (PCI DSS).
PCI DSS applies to organizations that “store, process or transmit cardholder data” for credit cards. One of the requirements of PCI DSS is to “track…all access to network resources and cardholder data”.
74. List& Explain the classic categories of malware.
The following are the classic categories of malware:
Viruses.
A virus self-replicates by inserting copies of itself into host programs or data files. Viruses are often triggered through user interaction, such as opening a file or running a program. Viruses can be divided into the following two subcategories:
– Compiled Viruses. A compiled virus is executed by an operating system. Types of compiled viruses include file infector viruses, which attach themselves to executable programs; boot sector viruses, which infect the master boot records of hard drives or the boot sectors of removable media; and multipartite viruses, which combine the characteristics of file infector and boot sector viruses.
– Interpreted Viruses. Interpreted viruses are executed by an application. Within this subcategory, macro viruses take advantage of the capabilities of applications’ macro programming language to infect application documents and document templates, while scripting viruses infect scripts that are understood by scripting languages processed by services on the OS.
Worms.
A worm is a self-replicating, self-contained program that usually executes itself without user intervention. Worms are divided into two categories:
– Network Service Worms. A network service worm takes advantage of a vulnerability in a network service to propagate itself and infect other hosts.
– Mass Mailing Worms. A mass mailing worm is similar to an email-borne virus but is self-contained, rather than infecting an existing file.
Trojan Horses.
A Trojan horse is a self-contained, nonreplicating program that, while appearing to be benign, actually has a hidden malicious purpose. Trojan horses either replace existing files with malicious versions or add new malicious files to hosts. They often deliver other attacker tools to hosts
Malicious Mobile Code.
Malicious mobile code is software with malicious intent that is transmitted from a remote host to a local host and then executed on the local host, typically without the user’s explicit instruction. Popular languages for malicious mobile code include Java, ActiveX, JavaScript, and VBScript.
Blended Attacks.
A blended attack uses multiple infection or transmission methods. For example, a blended attack could combine the propagation methods of viruses and worms.
Many, if not most, instances of malware today are blended attacks. Current malware also relies heavily on social engineering, which is a general term for attackers trying to trick people into revealing sensitive information or performing certain actions, such as downloading and executing files that appear to be benign but are actually malicious. Because so many instances of malware have a variety of malware characteristics, the classic malware categories listed above (virus, worm, etc.) are considerably less useful than they used to be for malware incident handling. At one time, there were largely different procedures for handling incidents of each malware category; now there is largely one set of procedures for handling all malware incidents, thus nullifying the primary need for having categories.
Another problem with the classic categories is that newer forms of malware do not neatly fit into them. For example, in the growing trend of web-based malware, also known as drive-by-download, a user’s web browsing is redirected to an infected website, often with little or no use of social engineering techniques. The infected website then attempts to exploit vulnerabilities on the user’s host and ultimately to install rootkits or other attacker tools onto the host, thus compromising the host. Although the website is infected, its malware does not infect the user’s host; rather, it functions as an attacker tool and installs other attacker tools on the host. Web-based malware is a blended attack of sorts, but its components do not map to the other malware categories.
75. List& Explain the popular attacker tools.
Various types of attacker tools might be delivered to a host by malware. These tools allow attackers to have unauthorized access to or use of infected hosts and their data, or to launch additional attacks. Popular types of attacker tools are as follows:
Backdoors.
A backdoor is a malicious program that listens for commands on a certain TCP or UDP port. Most backdoors allow an attacker to perform a certain set of actions on a host, such as acquiring passwords or executing arbitrary commands. Types of backdoors include zombies (better known as bots), which are installed on a host to cause it to attack other hosts, and remote administration tools, which are installed on a host to enable a remote attacker to gain access to the host’s functions and data as needed
Keystroke Loggers.
A keystroke logger monitors and records keyboard use. Some require the attacker to retrieve the data from the host, whereas other loggers actively transfer the data to another host through email, file transfer, or other means.
Rootkits.
A rootkit is a collection of files that is installed on a host to alter its standard functionality in a malicious and stealthy way. A rootkit typically makes many changes to a host to hide the rootkit’s existence, making it very difficult to determine that the rootkit is present and to identify what the rootkit has changed.
Web Browser Plug-Ins.
A web browser plug-in provides a way for certain types of content to be displayed or executed through a web browser. Malicious web browser plug-ins can monitor all use of a browser.
E-Mail Generators.
An email generating program can be used to create and send large quantities of email, such as malware and spam, to other hosts without the user’s permission or knowledge.
Attacker Toolkits.
Many attackers use toolkits containing several different types of utilities and scripts that can be used to probe and attack hosts, such as packet sniffers, port scanners, vulnerability scanners, password crackers, and attack programs and scripts.
Because attacker tools can be detected by antivirus software, some people think of them as forms of malware. However, attacker tools have no infections capability on their own; they rely on malware or other attack mechanisms to install them onto target hosts. Strictly speaking, attacker tools are not malware, but because they are so closely tied to malware and often detected and removed using the same tools, attacker tools will be covered where appropriate throughout this publication
No comments:
Post a Comment