it security

I.T. SecurityAbegail T. SoñasBS IT 4

Contents

IT Security Overview Overview 3 Main Objectives

Firewalls Introduction to Firewalls Organizational Guidelines Functionality Guidelines

Intrusion Detection Introduction Limitations to NIDS Things to Consider When

Choosing NIDS

Vulnerability Assessment Introduction to

Vulnerability Assessment Vulnerability Assessment

Preparation (SLA) Penetration Assessment

IT Security OverviewOverview | 3 Main Objectives

Overview

Information technology security is controlling access to sensitive electronic information so only those with a legitimate need to access it are allowed to do so.

This seemingly simple task has become a very complex process with systems that need to be continually updated and processes that need to constantly be reviewed.

IT Security Overview

3 Main Objectives

There are three main objectives for information technology security: confidentiality, integrity, and availability of data.


3 Main Objectives

Confidentiality protecting access to sensitive data from those

who don't have a legitimate need to use it.

Integrity ensuring that information is accurate and

reliable and cannot be modified in unexpected ways.

Availability of Data ensures that is readily available to those who

need to use it (Feinman et. al., 1999).


FirewallIntroduction to Firewalls | Organizational Guidelines |Functionality Guidelines

Contents

Introduction to Firewalls Organizational Guidelines Functionality Guidelines

Firewall

Introduction to Firewall

Institutions and businesses need to protect themselves from threats created by the use of new technologies. Firewall technology is useful in offering this

protection.

Firewalls control all inbound and outbound traffic.

Firewall


The most common types of technology used in firewalls are packet filtering, application level firewalls, and stateful inspection firewalls.

Firewall


MOST COMMON TYPES OF TECHNOLOGY Packet filtering software

works at the network layer where all packets are inspected as they pass through a router.

Packets that match access control rules are allowed through, while those that do not match are dropped.

Firewall


MOST COMMON TYPES OF TECHNOLOGY Application-level firewalls

work at the application layer. Most use proxy servers that act as an interface

between internal users and the Internet. The proxy checks for permissions and enforces

access control rules. Services that do not comply with these rules

are blocked.

Firewall


MOST COMMON TYPES OF TECHNOLOGY Stateful inspection

works at the network layer. IP header information is reviewed to determine

which services to allow through and which to block.

Firewall


MOST COMMON TYPES OF TECHNOLOGY Adaptive proxy, a new firewall technology,

combines packet filtering with secure proxy technology.

Firewall


Firewall appliances, as opposed to software applications, are becoming more popular.

These devices are stand-alone and typically combine hardware and software set

into an operating system.

Firewall

Organizational Guidelines The following selection guidelines are

recommended by Gartner, and can be found at http://enterprise.cnet.com/enterprise/0-9567-7-2481743.html

1) Establish application/business needs: Internet, intranet, extranet.

2) Assess security risks: high, medium, or low.3) Establish security requirements.4) Establish operational capabilities.5) Check security budget allocation.

Firewall

http://enterprise.cnet.com/enterprise/0-9567-7-2481743.html

http://enterprise.cnet.com/enterprise/0-9567-7-2481743.html

Organizational Guidelines6) Establishing business requirements includes

asking questions about:7) What type of access to the Internet is required

and by whom (internal employees, remote access, access from outside to company Web site)?

8) Does the company intranet need a firewall to protect from internal attacks?

9) Does the enterprise want to conduct business with other business partners and suppliers via an extranet?

Firewall

Organizational Guidelines10) Assessing the type of firewall to install requires

an organization to review its network design and business objectives. By conducting a risk analysis, exposures and levels of risk may be determined. Then, based on the results of the risk analysis, an organization has the starting blocks from which its requirements will arise.

Firewall

Organizational Guidelines10) (Continuation…) A sampling of what may be

uncovered during the risk analysis includes these:

The threats, impact, and vulnerabilities of connecting to the Internet.

Consider what Internet or external services are required, what features are required, and what level of assurance is required.

Firewall



This will help towards specifying a firewall according to the user's needs as opposed to selecting a firewall based on the number of features it comes with. The firewall must reflect the company's existing security policy, not impose a new one. In the absence of a security policy, or where a security policy exists but does not cover the Internet, an acceptable use agreement should be implemented.

Firewall



Operational capabilities should be established, i.e., what processes are involved in the day-to-day running of the system, check logistics, IT responsibilities, etc. Another important factor to bear in mind is to check where the security spending will come from: Does the enterprise have a dedicated security department with a dedicated security budget, or will budget have to be requested from the corporate IT director.

Firewall

Functionality Guidelines

Questions to ask include these:1) What authentication techniques does the

firewall support?2) Which antivirus software is supported?3) Can it filter Java/ActiveX applets?4) Are there logging facilities for

inbound/outbound traffic?5) Are there auditing and reporting tools?

Firewall


6) Does it carry out intrusion detection?7) Does it have alerting facilities?8) Is there a standby device in case of failure?9) Does the firewall support VPN?10) What types of encryption settings does it

have?11) Can it centrally manage multiple firewalls?

Firewall


12) Does it offer secure remote management?13) Does it have ITSEC or ICSA certification?14) Does it have load balancing/traffic

prioritization/bandwidth management?15) Does it support LDAP?16) Performance?17) Does it offer PKI support?

Firewall

Intrusion Detection SystemIntroduction | Limitations to NIDS | Things to Consider When Choosing NIDS

Contents

Introduction Platform Components Signature Detection or

Anomaly Detection Placement on the Network Network-based and Host-

based Functionality

Limitations to NIDS False Positives TCP Stream Reassembly/IP

Defragmentation Switched Networks

Things to Consider When Choosing a NIDS Operation Systems NICS Supported Reactive Versus Passive

Systems Alerting Logging and Reporting Maintenance Console Scalability Redundancy

Intrusion Detection System

Contents

Introduction

Platform Components Signature Detection or Anomaly Detection Placement on the Network Network-based and Host-based Functionality


Introduction

"An intrusion detection system (IDS) inspects all inbound and outbound network

activity and identifies suspicious patterns that may indicate

a network or system attack from someone attempting to break into or compromise a system."


Introduction: Platform

Some IDSs function from a dedicated (black box) appliance, meaning that there is no need for the customer

to ▪ load the operating system, install the application

software, and harden the operating system separately.

Others are software based and have to be installed on top of a supported platform and operating system.


Introduction: Components IDSs generally can be broken into two

components: the sensor and the console.

The sensor sits upon the network and acts as a sniffer, listening to network traffic in promiscuous mode.

The console is the point of central management for an IDS system. By using the console, an administrator may take notice

of any current attack alerts. In many cases, the console may be used to customize

certain preferences for the IDS.


Introduction: Signature Detection or Anomaly Detection

SIGNATURE DETECTION Most IDSs function by means of a built-in

attack signatures database.

If the IDS detects a match between current network activity and an attack in the signatures database, the IDS will document the attempted attack in a log. In many cases the IDS sensor will also send an

alert to the console regarding the attack.


Introduction: Signature Detection or Anomaly Detection

ANOMALY DETECTION Other IDSs function based upon anomaly

detection. This approach is more statistical, because the IDS

compares all network traffic to whatever is considered a "normal" load for a particular network. The IDS analyzes packet sizes, protocols, and traffic load

in this comparison process.

Therefore, if a particular transaction is atypical to a certain predefined extent, it is designated an attack by the IDS system.


Introduction: Placement on the Network

IDS can be set up either inside or outside of a firewall, depending on the needs of an organization.

An external IDS monitors attacks that occur on a firewall that are not

allowed into a network; therefore potential attacks are discovered, but internal threats go undetected.

Internal IDS configurations do not see attacks that are repelled by the

firewall, but monitor attacks that penetrate the firewall as well as internal attacks.


Introduction: Network-based and Host-based

There are two types of IDS.

Network-Based Systems real-time examine all traffic on a system

Host-Based Systems examines log file data examine traffic only on that specific system


Introduction: Functionality When searching for a NIDS, one of the first

aspects to consider it the type of attacks detected by the IDS. It is not sufficient to merely rely on the number of attack

signatures in the database.

It is better to ensure that the particular IDS has signatures for a wide variety of attack types, such as buffer overflows, stealth port scans, CGI attacks, SMB

probes, NMAP probes, fragment attacks, and OS fingerprinting attempts.


Introduction: Functionality An effective IDS should also perform

protocol analysis, detecting protocols such as TCP/IP, ICMP, UDP, FTP, SMTP, HTTP, DNS, RPC,

NetBIOS, NNTP, SNMP, and Telnet.

More advanced NIDS can actually display these protocol transactions in real time.

One such product is Netprowler.


Introduction: Functionality Some vendors have attempted to integrate

network and host-based intrusion detection into a single product.

ISS's RealSecure is the strongest example of such a product. The combined ability to watch network-based attacks

(including port scans and remote buffer overflow-based attacks) with system-level events (such as failed login attempts and modified registry keys) in one interface is incredibly powerful.

Additionally some IDSs can be integrated with firewalls and scanners in an attempt to increase security.


Contents

Limitations to IDS

False Positives TCP Stream Reassembly/IP Defragmentation Switched Networks


Limitations to NIDS

False Positives One important limitation to NIDSs is the

frequency of false positives.

No current IDS can completely eliminate the possibility of a false positive. However, most NIDS may be reconfigured so that a

particular false positive does not continue to register. This reconfiguration is usually done via the attack

signatures database.


Limitations to NIDS

False Positives Many NIDS products have customizable attack

signatures and also allow for the creation of new signatures. The programming of these signatures varies from

product to product.

For instance, Network Flight Recorder uses a proprietary N-code programming language to create new signatures. Other NIDS, such as ISS's RealSecure, have customizable

functions that allow one to determine how the IDS should respond when it detects suspicious activity.


Limitations to NIDS

False Positives These functions may somewhat alleviate the

occurrence of false positives. However, it may be difficult to get full information on the

hundreds of signatures that are built-in to a particular IDS, making customization more difficult.

In addition, depending upon the product, the use of custom signatures may slow the performance of the IDS.


Limitations to NIDS

TCP Stream Reassembly/IP Defragmentation

Attacks involving TCP and IP packets are the cause for special concern. In order to monitor a TCP/IP connection, the target

network must keep track of all of the individual TCP or IP packets.

Though a set of TCP packets may arrive out of order, the receiving network may reorder the packets by using the packet sequence numbers.


Limitations to NIDS

TCP Stream Reassembly/IP Defragmentation Many attacks exist that attempt to "confuse" the

process of stream reassembly. For example, a teardrop attack causes a buffer overflow

through the use of malformed data packets. The danger lies in the fact that the first packet looks no

different than an ordinary data packet, so the IDS does not immediately detect the attack.

In some cases, depending upon the operating system, it only takes one bad packet to crash the IDS. Once the IDS fails, most NIDS tend to fail open, so that once

an attacker has crashed the IDS, s/he has access to the network.


Limitations to NIDS

TCP Stream Reassembly/IP Defragmentation Although a report was issued in 1998 arguing that

novice attacks using fragmented packets could elude all commercial NIDS, as of 2000 most NIDS were still unable to cope fully with this possibility.

A few companies have added reassembly capabilities into their IDS products, such as Cisco and NFR. Other products can recognize fragmented packets, but are

unable to perform TCP reassembly.


Limitations to NIDS

SWITCHED NETWORKS Special limitation and problems emerge if the

network is switched. This depends on the type of switches deployed as well as

the type of NIDS in use. Most Internet-delivery environments are switched. The switches create a bit of a problem, as the NIDS

device needs to see the traffic before inspecting it.


Limitations to NIDS

SWITCHED NETWORKS

The solution here is either to inspect the traffic at certain bottleneck points (such

as perimeter firewalls) or to figure out a method of siphoning traffic off the wire

onto a private inspection network.


Contents

Things to Consider When Choosing a NIDS

i. Operation Systemsii. NICS Supportediii. Reactive Versus Passive Systemsiv. Alertingv. Logging and Reportingvi. Maintenancevii. Consoleviii. Scalabilityix. Redundancy



Operation Systems The types operating systems supported vary

greatly among IDS products. OS support is a big concern when considering a

software-based NIDS.

Some products only support Windows NT, whereas others, such as Snort, can be run on a wide variety of operating systems.

Other NIDS will be designed so that the console runs on a Windows machine, while the sensor runs on OpenBSD.


http://www.gslis.utexas.edu/~netsec/ids.html#oper


Operation Systems

Regardless of which operating system is supported, an organization should choose their NIDS carefully when considering the operating system.

The administrator of the IDS should be aware of all of the vulnerabilities related to the operating system that the IDS sits upon, so that the IDS may not be compromised.


http://www.gslis.utexas.edu/~netsec/ids.html#oper


NICS Supported A very important consideration for NIDS is the

type of Network Interface Cards (NICS) supported.

Most prevailing technologies provide support for a wide variety of types, such as Token ring, FDDI, Ethernet, Fast Ethernet, or Gigabit

Ethernet. Netprowler, by Symantec/Axent, currently only supports Ethernet or Fast Ethernet.

Such details should be taken into account before purchasing and deploying an IDS.


http://www.gslis.utexas.edu/~netsec/ids.html#nics


Reactive Versus Passive Systems One important aspect to consider is the

need for a reactive NIDS versus a passive NIDS.

A passive NIDS will simply log any suspicious network activity. If a serious attack takes place, the IDS will also

send an alert to the console and perhaps by email or pager.


http://www.gslis.utexas.edu/~netsec/ids.html#reac


Reactive Versus Passive Systems A reactive NIDS

will perform those tasks and more. For example, suppose a reactive IDS detects

some type of attack from a particular IP address.

The reactive IDS may be programmed to automatically rewrite the rules of the network's firewall in order to deny future traffic from the attacking IP address-all of this taking place without human intervention.




Reactive Versus Passive Systems Certain reactive NIDS may have the

following features: Setting SNMP traps Disconnecting and capturing sessions Killing processes Disabling user accounts Launching program commands Shunning attacker IP addresses




Reactive Versus Passive Systems There are advantages and disadvantages for

both types of NIDS.

When considering a reactive NIDS, a network administrator may be assured of a timely response in the event of an attack.

However, this response can backfire, depending upon the actual circumstances.




Reactive Versus Passive Systems

For instance, in our example on previous slide, suppose the attacking IP address had been spoofed by a hacker. As a result, the legitimate network, which was spoofed,

would be restricted access to the network by the reactive NIDS.

Therefore a hacker could use the reactive features of an IDS to cause a denial of service attack.




Alerting The alerting features of a NIDS may be in the

form of an email, pager, telephone call, or an alarm.

Most NIDS include many types of alerting features.

Most importantly, alerting should be done via the NIDS console, if no other alerting mechanism is available or enabled.


http://www.gslis.utexas.edu/~netsec/ids.html#aler


Logging and Reporting A competent NIDS should minimally include a

logging feature.

The log enables an administrator to review any suspicious network traffic.

Logs cannot be solely depended upon when deploying a NIDS. A determined hacker may easily flood the network to the

extent that the log reaches its capacity and fails. Depending upon the operating system that the IDS sits on, a

hacker may also compromise the IDS and easily delete information in the log.


http://www.gslis.utexas.edu/~netsec/ids.html#logg


Logging and Reporting On the other hand, all false positives will also

be present in the log. If there are an unusually large number of false positives,

this can be quite an annoyance to the person who has to review the log.

However, it is important to use the IDS log to search for any possible threats.

Most network security experts encourage administrators to look at the IDS log at least once a day.


http://www.gslis.utexas.edu/~netsec/ids.html#logg


Maintenance When deploying an IDS, it is important to keep

the signature database up to date.

Depending upon the particular product, there are various ways to ensure that the NIDS has the latest signature files available. The frequency of updates may vary from company to

company. Most commercial vendors offer a download of new

signatures from the vendor Web site.


http://www.gslis.utexas.edu/~netsec/ids.html#main


Maintenance Others have automated updating features,

though in some cases, the process of updating the signature database may mean the upgrade of the entire NIDS. Open source NIDS, such as Snort, are very flexible

concerning signature updates. Often someone in the particular community of open

source users can write a signature that is available to others in a short period of time.


http://www.gslis.utexas.edu/~netsec/ids.html#main


Console Most NIDS include a console that

provides various views and controls of the intrusion detection system.

The interface of the console will vary greatly depending upon the IDS. Most commercial NIDS include a GUI interface with

several possible views of the network. Other NIDS, such as Snort, have a command line

interface.


http://www.gslis.utexas.edu/~netsec/ids.html#cons


Console Additionally, some consoles may be accessed

remotely, depending upon the product.

Many consoles will have a hierarchical tree GUI interface.

Some interfaces have the ability to sort attack by type, attacker, or target host.

These aspects should be considered, as some IDS consoles do not provide as many viewing options as others.




Console An important question to consider is the

communication between the sensors and the central console.

It is important that the communication, such as attack alarms, are delivered to the console and to other recipients in a reliable, quick, and secure manner.




Scalability Some NIDS will scale more efficiently than others. As a network grows, the traffic may be too much

for the IDS to handle.

For certain NIDS, this problem may be solved simply by deploying more sensors (or appliances) on the network, in order to keep up with the network load. But this option is not suitable for a company or

organization with less monetary resources.


http://www.gslis.utexas.edu/~netsec/ids.html#scal


Scalability Other IDS vendors do not sell the console and

sensors separately. Therefore as the network grows, an organization

may have to change their IDS if the current one cannot scale.


http://www.gslis.utexas.edu/~netsec/ids.html#scal


Redundancy Good redundancy for the IDS usually depends upon

the amount of traffic on the network. As the amount of traffic increases, some NIDS will be less

effective in detecting certain threats due to the heavy load.

This largely depends upon how the particular product is designed. Netprowler, by Symantec/Axent, provides a unique

approach to this concern. Netprowler does not attempt to monitor all network traffic.

▪ Instead, it is configured to detect only certain attacks.


http://www.gslis.utexas.edu/~netsec/ids.html#redu


Redundancy The configuration is determined by the types of

machines sitting on a particular network, so that Netprowler listens for the most relevant threats for the network. For other NIDS, redundancy may be very closely related

to scaling concerns-as the network grows, traffic may be too overwhelming for the particular IDS.

Therefore it is vital that an organization be fully aware of the size and constitution of its network, so that an effective IDS may be deployed to fit the unique needs of the particular network.


http://www.gslis.utexas.edu/~netsec/ids.html#redu

Vulnerability AssessmentIntroduction to Vulnerability Assessment |Vulnerability Assessment Preparation (SLA) |Penetration Assessment

Contents

Contents

Introduction to Vulnerability Assessment Vulnerability Assessment Preparation (SLA) Penetration Assessment

Vulnerability Assessment

Introduction

A vulnerability assessment on an enterprise network can be a major undertaking, but it's an important part of securing a network.

Vulnerability assessment can be done by inside professionals (i.e. network administrators), but is usually outsourced to Managed Security Service Providers (MSSP). Each MSSP provides different solutions, has a different

background, and different areas of expertise.


Introduction

It's crucial to select an MSSP that offers exactly what is needed.

A couple of factors that determine what may be needed. First, how much of the network to assess and which

parts? Second, what constitutes a vulnerability?


Introduction

Determining what needs to be left vulnerable is as important as what needs to be locked-down.

The only hacker-proof network is one that's been turned off, but obviously that's not the best business plan either.

The level of network security decreases with every application that allows the network to be accessible.

A balance must be struck between security and accessibility for customers, partners, and employees.


Vulnerability Assessment Preparation (SLA)

Though each MSSP offers different solutions, most offer some sort of Service Level Agreement (SLA).

The SLA should cover at least these topics: Security Management, Monitoring, Incident Response, Response Time Escalation, and Documentation.



Most agreements will allow for security tests including detailed audits and penetration assessment

and they should also detail their security processes including authentication, access control, and auditing.

Two major parts of the SLA deal with access to systems, and information and behavior during an attack. The first part pertains to how much of a network the MSSP

should assess and what parts are considered too confidential for outsiders.

Also, it is important to make sure partner and customer systems are not inadvertently scanned.



There are a few different ways to handle an attack and it's important to fully understand the implications of each before committing to an MSSP.

MSSPs will usually do one of three things: post attack audit, on-the-spot consultation, or take full responsibility for real-time response.

If the MSSP is monitoring, this is the time to decide whether they should take it upon themselves to deter a hacker or wait for instructions from an administrator or executive.



An important decision to make before a managed attack is deployed is determining from whom the network is being protected.

Attacks can come from two places, inside or outside the company.



INSIDE THREATS have the potential to be most damaging. Because each employee requires access respective to

his/her position, assessments must be done at each level of user.

OUTSIDE ATTACK or Zero Knowledge Attack can be as damaging as well depending on the time and

money the attacker has to spend, especially if the attacker thinks he/she can find something good.



A competitor may find it advantageous to spend many days or even months trying to gain access to compromising information. An attack from an outside hacker, not a competitor, is

usually not as prolonged due to lack of funds and interest.

If a hacker cannot easily gain access with the few tricks he knows, he is more likely to move on to an easier target than continue trying, especially if he doesn't expect much from the site.

Properly identifying potential risks is necessary to those performing the penetration assessment.


Penetration Assessment

The penetration assessment usually consists of four steps, climaxing at the fourth step, exploitation. 1) Discovery2) Enumeration3) Vulnerability4) Exploitation



FOUR STEPS 1) DISCOVERY The first step, Discovery, will determine which

networks and more specifically which IP addresses will be assessed.

This information can be obtained from the Network Administrator or from the internet by accessing websites, whois databases, and usenet groups.



FOUR STEPS 2) ENUMERATION Enumeration, finding detailed information about

a server, IP address, or system, is the second step in the assessment.

The assessor will try to find User names, operating systems/versions as well as sharing permissions of the workstations.



FOUR STEPS 3) VULNERABILITY The third step is Vulnerability Mapping where the

information that has been gathered thus far is compared to known vulnerabilities.

This information is available on product sites, bug tracking sites, and CERT's site.



FOUR STEPS 4) EXPLOITATION The last phase is Exploitation. The 'map' made in the previous step will be a

foundation for attacking the system's vulnerabilities.

A dictionary will be run to try to crack passwords. If a password is cracked an account becomes available

and the attack now comes from the 'inside'. The assessor will also try to gain privileged

access through vulnerabilities in operating systems or applications running on the server.


Reference

http://www.gslis.utexas.edu/~netsec/overview.html



it security

Technology

firewall technology

firewall firewall appliances

firewall introduction

type of firewall

firewall institutions

security requirements

informationtechnology

security risks