Management of Network Security Applications

Philip C. HylandPh.D. Candidate, George Mason University

TASC, Inc.4801 Stonecroft Blvd.Chantilly, VA 20151

Phone: (703) 633-8300 (W)Fax: (703) 449-1080

E-Mail: pchyland@tasc.comhttp://mason.gmu.edu/~phyland

Ravi SandhuProfessor, Department of Information and Software Engineering

George Mason UniversityFairfax, VA 22030-4444

Phone: (703) 993-1659 (W)Fax: (703) 993-1638

E-Mail: sandhu@gmu.eduhttp://www.list.gmu.edu/~sandhu

ABSTRACT:Security policy and security techniques have been major research topics for a long

time, but relatively little work has been reported on management of distributed securityapplications. This paper reviews several security management projects and related secu-rity research to date. We present a core set of security managed objects for use with theSimple Network Management Protocol (SNMP). Security applications are assessed forvalue of management via SNMP. A scenario of corporate firewalls illustrates concepts ofsecurity management correctness, sufficiency, and completeness. Ongoing investigations,case studies, and implementation issues are discussed. Introduction of a Packet-Filter In-formation Protocol (PFIP) suggests propagation of security information in a manner usedby routing protocols. We conclude with recommendations for further work to advanceSNMP-based management of security applications.

KEYWORDS:Firewalls, Management Information Base (MIB), Network Management, Packet-Filter

Information Protocol (PFIP), Security Application Management, Security Management,SNMP

I. IntroductionGeneral security solutions try to establish

perimeters or layers of protection to filterwhat data passes in or out. Multiple layersand access points make robust network secu-rity systems a natural example of distributedoperations in both implementation and man-agement aspects. The level of threat to theresources and data within a system makes ac-tive management of security capabilities an im-portant distributed operations mission.

Computer security has been of interestsince the first multi-user systems. Only re-cently, since vital data and critical businessfunctions moved onto networked systems,have network security mechanisms prolifer-ated. User expectations of system quality,privacy, performance, and reliability aregrowing. The rapid deployment of new secu-rity technology needs flexible, efficient man-agement to help system operators from beingoverwhelmed by configuration and monitor-ing overhead. The complexity and interde-pendent nature of network security demandsan up-to-date system view and the capabilityto gather and correlate underlying event details.

A security program depends on the cor-rectness, completeness, and reliability ofthree related components – security policy,implementation mechanisms, and assurancemeasures. Figure 1 shows the relationshipsbetween these components and end users.Security policies set the guidelines for opera-

tional procedures and security techniques thatcounter security risks with controls and pro-tective measures. Security policy has a directimpact on the rules and policing actions thatensure proper operation of the implementa-tion mechanisms. Policy has an indirect in-fluence on users; they see securityapplications and access services, not policies.The security policies of the organization de-termine the balance between users’ ease ofuse and level of responsibility versus theamount of controls and countermeasures.

The goal of the security manager is to ap-ply and enforce consistent security policiesacross system boundaries and throughout theorganization. The challenges in achieving afunctional security system are twofold. First,a consistent and complete specification of thedesired security policy must be defined, in-dependent of the implementation. The sec-ond need is a unified scheme to enforce theapplicable security policies using availabletools, procedures, and mechanisms. The dif-ficult task in achieving a “state of security” isnot obtaining the necessary tools, but choosingand integrating the right ones to provide a com-prehensive and trustworthy chain of security.

Security policy and security techniqueshave been major research topics for manyyears. However, study and experience withoperational network security management arelacking. We believe that the need for secu-rity management will multiply, much as the

growth of LANs created a demandfor better network managementsolutions. As the active part of theassurance component, operationalsecurity management deserves andrequires additional research to har-ness the full potential of manyevolving security systems.

The quantity, variety, andcomplexity of security applica-tions represent so many differentfunctions and security states thatintegrated management would be

SecurityPolicy

ImplementationMechanisms

Status from Sensors

Indirect InfluenceUsers

Rules Control

ControlEntities

Figure 1. Security Components

impossible without mapping attributes to acommon management model. In this paper,we present a structure for a common securityManagement Information Base (MIB) anddiscuss its application to representative secu-rity mechanisms. A new Packet-Filter Infor-mation Protocol (PFIP) is introduced forpropagation of security information.

Our goal is to promote a better under-standing of the issues and approaches to inte-grated, consistent security management.Section 2 provides background in the relatedtopics of network management and a reviewof security and system management work todate. Section 3 develops the foundation for asecurity management concept using commonsecurity attributes, extension of the networkmanagement infrastructure to encompass se-curity management, and core challenges to amore robust security management environ-ment. It also identifies ongoing work beingdone at GMU’s Laboratory for InformationSecurity Technology to implement securitymanagement prototypes. Section 4 drawsconclusions on the state of development of se-curity management and needs for further work.

II. Background and Related WorkSecurity management has long been con-

sidered a sub-function of network manage-ment. It is one of the five functional areasdefined in the OSI management framework[5]. International standards for securityfunctions like audit trails, security alarms andnotifications, key management, authentica-tion, and access control have generally pro-gressed much farther that similar work in theIETF community. Between 1992 and 1994, aEuropean security management prototypecalled Project SAMSON [7] identified anintegration architecture that included bothCMIP and SNMP interfaces for managementof security mechanisms. Another project calledWILMA [13] produced some SNMP devel-opment tools in 1995 for security management.

A. TerminologyWe define security management as the

“real-time monitoring and control of activesecurity applications that implement one ormore security services.” The purpose of se-curity management is to ensure that the secu-rity measures are operational, in balance withcurrent conditions, and compliant with thesecurity policy. Not only must the servicesfunction correctly and in a timely fashion,they must counteract existing threats to gen-erate justifiable confidence in the systemtrustworthiness. One of the largest securitypitfalls is to focus on certain security prod-ucts or technologies without defining a bal-anced security policy and thereby gaining afalse sense of security. Protection is only asstrong as the weakest link.

Assurance is the conventional term formethods that are applied to assess and ensurea security system enforces and complies withintended security policies. One may use as-surance tools before, during, or after securitymechanism operations. Post-processing ofsecurity events typically includes audit trailanalysis and related off-line intrusion detec-tion and trend analysis methods. Many Intru-sion Detection System (IDS) applicationsbegan as post-processing functions due tolimited processing and software capabilities,but most are migrating toward interactive,real-time operations [12].

Pre-operational analysis of security mayinvolve extensive testing and the use of rig-orous logical analysis referred to as formalmethods. This approach is widely applied incritical aviation, nuclear power and medicalsystems, as well as security kernels, to en-hance reliability [9]. The need for highly re-liable security systems cannot be satisfiedonly through design and testing, especiallysince protection from malicious parties is afundamental need1. Developers for critical

1 Critical systems depend somewhat on the low likeli-hood of random conditions to cause error states, but

systems have found that reliable systemsmust address:

• Fault prevention during design anddevelopment,

• Fault detection during operations and

• Fault recovery during abnormal or er-ror states.

Network security management applica-tions concentrate on the latter two areas asthey relate to networks. Like security ker-nels, security mechanisms must properly im-plement security, but the assurance roletypically occurs in a separate applicationrather than internally. Security managementtools are active assurance methods that func-tion to monitor operational security services,allowing observation and reaction to keyfault, configuration, and performance status.While security kernels and security mecha-nisms are like automobile drivers who areultimately responsible for safe operations,security management is like the traffic cop whoreinforces the rules and assists in trouble spots.

Security management has two roles–monitoring and control. The first involvesdata collection that provides insight forsystem stakeholders2 on whether securityoperations achieve the security policiesintended by the system design. Statuspresentation may be in the form of real-timegraphical displays or periodic printed reportsof data trends or exceptions. The frequencyand granularity of data gathering arenecessarily tradeoffs with the network trafficvolume and processing load of monitoringcomponents. The second role of securitymanagement is to provide a means to adjustthe level of security monitoring andoperational safeguards if the current level computer hackers purposely search for the weak pointsthat exist in any complex system.2 Stakeholders is a term meant to imply all responsiblepersons, beyond just the system operators and users. Itmay include data or business application owners orequivalent security accreditors in government organi-zations.

rent level does not match security policy orthe desired level of risk.

Traditionally, security management hasbeen viewed as a special case of networkmanagement. Security and management areinterdependent by their nature, so each needsthe services of the other. Thus, managementof security and security of management aredifferent facets of the same issue. Security ofmanagement is a prerequisite of many highreliability and secure applications, particu-larly management of security. This is the so-called security of management before man-agement of security requirement. To date,much more work has been done to define se-curity mechanisms than to extend manage-ment capabilities to security applications.

B. Network SecurityNetwork security management is by na-

ture a distributed function. Applications thatmay utilize security management includefirewalls, databases, Email, teleconferencing,electronic commerce, intrusion detection, andaccess control applications. Security man-agement faces the same security threats asother distributed applications. Coordinatedmanagement of security is not feasible with-out a secure management infrastructure thatprotects in transit messages from modifica-tion, spoofing, and replay. Although endsystem security is beyond the scope of thisdiscussion, it is clear that key management,access control, and reliable implementationof management software are critical also.

In its crudest form, security managementcould require human presence at every secu-rity device and manual evaluation of all sig-nificant events. On the other hand, webelieve that remote monitoring with com-puter assisted correlation and management ofsystem events is just as viable for securitymanagement as it is for network manage-ment. In fact, it may be argued that detectionof sophisticated attacks need the help ofcomputer-assisted correlation tools evenmore than network management systems.

Some network management systems use re-mote trend analysis and pattern recognitionof management data to initiate automated orrecommended operator responses. Similarpossibilities for security are more a matter ofmarket demand and investment than technol-ogy limitation. We also believe the lack ofstandard definitions for managed securityobjects have limited more widespread, inter-operable implementations.

Even a small network with modest secu-rity needs will soon face significant adminis-trative overhead to configure and monitorfirewalls, authentication servers, secureEmail servers, etc. Organizations are nowcoming to expect both privacy mechanismsand firewall protection, but competitive pres-sures are driving administrators to reduce la-bor costs of network and system managementthrough automation and consolidation ofmanagement activities. The rapid deploy-ment of security services in corporate andpublic networks reinforces the need for secu-rity management.

Like other distributed applications, secu-rity management modules must speak acommon language. Two standards-basedmanagement protocols have addressed secu-rity management somewhat. SNMPv2 pro-posed many security enhancements over theexisting SNMPv1, however the standardsprocess collapsed under its own weight.SNMPv3 is emerging to combine the bestaspects of SNMPv2 (RFC 1445-1452) withSNMPv2c (RFC1901-1907). Since SNMP ismore pervasive than the ISO’s Com-mon Management Information Protocol(CMIP) standard, SNMPv3 is expectedto be a important security managementprotocol. Some research efforts suchas the SAMSON project have looked atintegration aspects of the security man-agement problem, but more sustainedresearch needs to establish a real visionand plan so as to bring order and syn-ergy to the topic. With that thought in

mind, we seek to offer some common secu-rity management rules, views and tools, and aroadmap for additional research needs.

C. Security Management ResearchThe literature and available products re-

lated to management of security applicationsis quite sparse. Despite vendor hype, man-agement tools for secure applications arelimited in capabilities and generality. Al-though a few firewall vendors have usedSNMP Traps to identify security alarms to anetwork management station, most securityresearch has focused on techniques and dataanalysis. Intrusion detection, multicastconferencing, and web (HTTP) security havereceived some attention, but no securityMIBs exist nor are integrated security man-agement functions in wide use.

Most readers will be familiar with the ba-sic concepts of common SNMP and theCMIP network management protocols ascovered by authors such as Rose [8] andStallings [11]. Distributed Management En-vironment (DME), an important alternative,began as a part of the Open Software Foun-dation’s (OSF) broader Distributed Comput-ing Environment (DCE) initiative. DMEaimed to address management of large, het-erogeneous networks by defining a commonhigh-level interface for network devices andapplications using a single API to accesscommon functions of the SNMP and CMIPprotocols (see Figure 2). As a first step, theOSF announced the Network ManagementOption (NMO) 1.0 specification in May

ManagementEngine

XMP

ManagedApplication

AdaptationLayer

SNMP CMIPS-HTTP

ManagementApplication

SNMP CMIPS-HTTP

Management Agents

Figure 2. XMP Management Infrastructure

1994. The independent SAMSON projectstudied and developed a working prototypeusing XMP with SNMP and CMIP stacks.Figure 2 also shows another managementinterface alternative using Secure HTTP (S-HTTP). Although use of S-HTTP is not pro-posed by existing working groups, the use ofHTTP for GUI front-ends for non-securemanagement has been gaining momentum.

The Network Management Forum hasalso attempted to reconcile the SNMP andCMIP environments. Its OMNIPoint 1document was a roadmap for compatiblespecifications. As part of this effort, theISO/CCITT Internet Management Coexis-tence (IIMC) working group defined MIBtranslation rules and proxy definitions towardthis end. Its review of management securityissues is in [6].

Much of the security management workpublished to date relates to IDS applications.Early IDS work related to off-line analysismethods for detecting anomalies or attackpatterns in audit data from standalone sys-tems. As analysis techniques and distributedprocessing capabilities have improved, recentIDS work is becoming more real-time andcooperative, similar to other event-drivennetwork management functions. Recently,Crosbie [3] proposed using “autonomousagents” for redundancy and simplicity.White, Fisch and Pooch are working on “co-operative, peer-based” IDS [12]. Both effortsare intent on the functionality of the IDS ap-plication, but intercommunication and man-agement functions are clearly needed andidentified. This suggests that the future ofIDS may consist of independent, but commu-nicating detection tools. Coordination andmanagement of distributed IDS agents aredistributed management functions specializedfor IDS. If the IDS protocol and manage-ment capabilities were to be aligned withSNMP, then linkage to other managementapplications may be the next logical progres-sion.

Multicast management issues have beenan active research topic due to the growinginterest in Internet conferencing. As businessuse of multicast becomes common, the de-mand for multicast privacy solutions willgrow. Authentication, encryption key man-agement and access control are big concernsas participation increases. Late joins andearly departures from secure sessions com-plicate key management due to the need todynamically refresh the keys of active par-ticipants. Gong [4] has raised many of theseissues specific to group-oriented multicastsecurity, but many are also general securitymanagement issues. Some issues from mul-ticast security also relate to network man-agement scenarios in which a central siteneeds to communicate with many distributeddevices. Key management is usually handledoutside the network management standardsarena, but using secure management tomonitor and control a key management ap-plication is very conceivable.

Control of access to network transmissionresources has been a research concern be-cause multicast can consume a large amountof bandwidth when broadcasting to a largepopulation of receivers. Ballardie in [2] hasidentified problems of limiting access tomulticast trees and suggested a method forcontrolling abuses by users who may inad-vertently or maliciously consume majorchunks of network resources. Later, we ap-ply some similar concepts in our proposedPacket-Filter Information Protocol (PFIP) tomonitor and control restrictive firewall filters.

A direct application of security manage-ment was discussed by Banning in [1]. Ban-ning built a distributed audit system to collectdata from heterogeneous systems using net-work management protocols. Although onlya simple prototype, it demonstrated the stepsto integrate other security applications usingsimilar MIB definition, agent development,and value-added processing of collected data.Not every security management application

should have to apply this process. We be-lieve a core set of attributes and procedureswould greatly promote extension of man-agement functions to other security applica-tions and support synergy between thoseapplications.

III. Integrated Security ManagementDeployment of effective security man-

agement requires three basic managementcomponents – applications, infrastructure,and agents. We focus on the issues ofadapting the predominant management statusand control mechanisms (management infra-structure and agents) to accommodate secu-rity management needs. Processing anddisplay applications are beyond the scope ofthis discussion.

The basic management infrastructuremust provide suitable mechanisms for thefollowing factors to maintain secure man-agement of applications:

• confidentiality and integrity

• data transport

• common data encoding

• liveness3

These capabilities may or may not beavailable from existing network managementsystems. The use of standard protocols suchas SNMPv3 along with proven securitymechanisms for authentication,access control, integrity andconfidentiality ensures no weaksecurity links4. In addition, themanagement platform itselfneeds protection through goodsystem and physical security.

3 Liveness, a term from securityresearch, may also be called freshnessto indicate that the value of the data isnot merely in its quantity, but also inits quality (timeliness).4 In a chain, each link is important, while some othermodels represent security as being layered like an on-ion whereby one layer covers the weakness of another.

A. Management of Security Applica-tions

It is widely agreed that consolidation andintegration of management functions is nec-essary to keep costs down and allow smallnetwork operations staffs to extend theirscope of control. It is also clear that movestoward centralized management can lead tosingle points of failure and performanceproblems. A recent trend within the networkmanagement industry is the deployment ofdistributed management systems that can co-operatively share information and implementcontrol functions. Many security applica-tions may benefit from consolidated, coop-erative management, especially those that aredynamic and widely duplicated across multi-ple sites.

Several security applications are potentialcandidates for integrated management usingstandard protocols. Table 1 below showsour assessment of the relative suitability ofsome possible applications. We used threesubjective factors to assess each applicationfor integration with a security managementsystem. Proliferation rates how widespreadthe application is, research value assesses theimportance of the application technology,and real-time management indicates the use-fulness of interactive management in the ap-plication domain. For example, due to the

Application Prolif-eration

ResearchValue

Real-TimeManagement

Total

Security Firewalls* H H H 9*

S- HTTP L H H 7Secure DNS L M M 5Secure Email M H M 7

Kerberos M M M 6Intrusion Detection System* M H H 8*

Secure Audit Trail M M L 5Secure Multicast L M M 7System Security H H L 7

* Candidate for Case StudyL = Low (1), M = Medium (2), H = High (3)

Table 1. Security Applications

rapid deployment and variety of vendor of-ferings, network security firewalls show greatpromise for management by standard proto-cols. Likewise, the substantial research in-terest in IDS applications makes it anothergood subject for study.

B. MIB SecurityOf the three core security principles (con-

fidentiality, integrity and availability), integ-rity is the most critical to managementoperations. The authentication of users andthe reliable delivery of the correct data areconstant imperatives. While confidentialityof some data may be desired (such as transferof new keys or passwords during login), it isnot a constant driver. Availability of securitymanagement applications is also a lesser con-cern since many applications can continue tooperate and maintain status information dur-ing gaps in communications.

It may seem that a security managementsystem that manages a trusted applicationshould go through the same rigorous testingand analysis as the primary security applica-tion. Rushby [10] indicates a security kernelmust have access to and control over the vitalsecurity features of a system and must main-tain secure attributes in spite of any possiblesequence of operations. If thesecurity management appli-cation enforces security, itand all related infrastructurewould have to meet all secu-rity requirements of the coreapplication (e.g., securitykernel). We conclude that thepurpose of security manage-ment is not to enforce security, but to managesecurity risk by sensing and displaying statusof important parameters. It is a means togather status information and tune perform-ance parameters to meet current data safetyneeds.

C. Security MIB TemplateA basic security MIB should include

common attributes from all applications withsecurity roles. A sound security model iscrucial in extending the network managementparadigm to encompass security. The majorchallenge is to define a common set of man-aged objects that are useful to security man-agers in detecting and reacting to securityevents. After the core set of MIB attributeshas been defined, each security applicationmay extend the security MIB to specify itemsthat support unique features in their domain.Also important to effective, active manage-ment is definition of trap events. Traps gener-ate real-time alerts for critical events at a nodesuch as exceeding absolute or rate thresholds

A good first step in defining a core secu-rity MIB is to apply the standard Fault, Con-figuration, Accounting, Performance andSecurity (FCAPS) network managementfactors in the security context. Although asingle security MIB definition cannot coverevery need, there are advantages in a com-mon standard that all compliant systems mustsupport and may extend as necessary. Table2 shows some core elements from the generalsystem and packet-filter sections of our draftFirewall MIB.

Although the MIB variables in Table 2require detailed explanations to apply themprecisely, it should be evident that a MIBcould implement the packet-filter access ruletable of a firewall. Management operations(SET/GET) on the packet-filter table entries,for example, would enable configuration of a

Table 2. Potential Firewall MIB Attributes

§ fwSysObjectID§ fwSysSecAdmin§ fwSysServices§ fwSysForwarding§ fwSysNonIPAction§ pfTabUpdate§ pfTable§ pfEntry

§ pfIn/Out_Flag§ pfProtocol§ pfSourceAddress§ pfSource_PortLB§ pfSource_PortUB§ pfDestAddress§ pfDest_PortLB§ pfDest_PortUB

§ pfStart_Time§ pfEnd_Time§ pfPollInterval§ pfDroppedSince

LastPoll§ pfTop10SrCs

SinceLastPoll

specific filter rule. Rules for an applicationlevel "proxy server" firewall are also beingdeveloped as a separate MIB section. Tobuild a complete security MIB, additional MIBmodules can be defined for other securitymechanisms such as security audit trails, se-curity guards, authentication servers, andIDS. In addition, trap events should be de-fined for real-time alerts for key events.

Ongoing research is testing the viabilityand utility of preliminary MIB definitions.Usefulness for both configuration opera-tions and status gathering is important.Validation will consist partly of assessingwhether a particular configuration is effec-tive in detecting one or more attacks de-scribed CERT advisories. Developmentsystems include a simple packet-filteringfirewall using the Texas A&M Univer-sity’s Drawbridge package on a PC plat-form. Instrumentation of the securityapplication with an SNMP agent will allowimplementation and enhancement of thesecurity MIB. The testing against knownscenarios will give implementation andexperimental experience. Our implemen-tations of consolidated security manage-ment will also involve other widelyavailable security tools, such as tcp_wrappersand the TIS firewall toolkit.

D. Management Application ScenarioWhen several similar manageable devices

or applications are in a common managementdomain5, a common management applicationmay be considered. Below we present an ex-ample application with one Network Man-agement Station (NMS) to manage a group ofnetwork security firewalls.

ACME Enterprises has several externallyconnected LANs that require new firewallsand some that need firewalls between de-

5 A single management domain exists when manage-ment entities can be accessed from a single locationand they are the administrative responsibility of oneorganization.

partments. ACME has remote offices thatconnect via the Internet as in Figure 3. Al-though most firewalls would be managedfrom an NMS inside the firewall, externalmanagement of firewalls is necessary for or-ganizations that want central administration.This can be problematic, since SNMP usesthe UDP service and management capabili-ties would be hindered if UDP access thoughthe firewall is restricted.

ACME managers want to use an existingnetwork management platform to monitor thenew firewalls. To do so, an upgrade fromSNMPv1 to SNMPv3 will support data integ-rity and confidentiality. Typically, the eventsof interest for a firewall will be the numberof incoming packets that are dropped due topacket-filter restrictions. If a large number ofdrops occur in rapid sequence, a significantsecurity event may be occurring. Alterna-tively, if a high percentage of packets in aninterval (say 50% in a 30-second interval) arerejected, there may be cause for concern.Both of these events could trigger a trapevent to the NMS to alert an operator forfurther assessment.

The NMS may raise or lower the securitymonitoring posture based on the recent pat-

InternalFirewall

ExternalFirewall

OrganizationalBoundary

NMS

ExternalFirewall

Internal Network

Remote Network

OrganizationalBoundary

Internet

SNMPAgent

SNMPAgent

ExternalFirewall

Internal Network SNMPAgent

SNMPAgent

Figure 3. Management of Internal vs. External Firewalls

tern of alerts, external information, or systemsecurity policy. If a reoccurring security alertis being generated from the same source, themanager may want to set the filtering actionas “log packet” or “log header” for later re-view rather than just dropping it. Such amanagement response may provide neededevidence to trace intruders. Care is needed tokeep flooding attacks from overflowing stor-age areas, however. Recording packet dropsrequires the NMS operator to SET thepacket-filtering rule that is associated withthe alert. This may be done by doing a GETand searching through the packet-filter tablefor the rule, or the original alert may indicatethe associated rule in the trap message. Tochange the configuration of the packet-filtering table, the “action” column must al-low read/write access.

Another approach to assess the configu-ration and efficiency of a packet-filteringfirewall is through summary variables suchas the TopTenRuleHits, TopTenSrcIPAddrand TopTenDroppedPktSrcIPAddr similar tothe Remote Monitoring (RMON) MIB(RFC1757/ 2021). In this way, the most im-portant rules and problems can be closely as-sessed and the effect of changes can be seen.Specific rules may be changed and turned onor off as conditions dictate. Possibly, betterperformance can be attained if rules that arefired most are rearranged in the filtering ta-ble.

Packet-filter tables and application prox-ies only allow approved traffic to passthrough. Changes to the firewall configura-tion may result from reaction to status infor-mation or from external needs. Newapplications may be opened for use on aproxy server, or a security trigger could shut-down dangerous applications or locations.Thus, application and packet-filtering tablesmay function like a router that permits trafficto flow onward toward its destination.

Figure 4 shows high-level firewall MIBdefinition groups that might be accessed from

a standard NMS platform. The procedures tomake an update are as follows. If a firewallis operational and a new proxy application isto be added, the management station wouldupdate the application table by initiating aSET operation on the appropriate row values.Certain columns such as source and destina-tion addresses would be mandatory parts ofthe table information. If a need for applica-tion access is temporary (i.e. user needs ac-cess while on travel), the managementapplication could set a timed trigger to re-move the access automatically.

E. Packet-Filter Information Protocol(PFIP)

While defining the packet-filter MIB, wenoted some similarities with the MIB-2 im-plementation of an IP routing table. Wequestioned whether packet-filter informationcould be propagated amongst routers andcompatible hosts in the same manner thatrouting tables are updated by the Routing In-formation Protocol. Instead of establishingroutes, a packet-filter blocks known and po-tential routes to and from particular destina-tions. The PFIP described below is the result.Further investigation to assess extensions forsharing application gateway, audit event, andIDS "tip-off" information is ongoing.

The PFIP is intended to allow propaga-tion of packet-filter information among hostsand routers in an IP-based network. Whereasrouting protocols deal with information aboutavailable paths between networks and hosts,

StatusInfo

ConfigurationInformation

FirewallMIB

StaticInfo

ApplicationTable

FilterTable

PacketStatus

ThresholdViolations

FilterEvents

ThresholdSettings

Figure 4. Firewall MIB

the PFIP is a restrictive mechanism to con-veniently limit the flow of data packets fromsources that are considered bothersome oruntrustworthy. The PFIP can only propagatedeny rules between known entities. If ameans of strong trust is established betweenentities through authentication, encryption,digital signatures, etc., then full packet-filtertable administration may occur. PFIP worksin concert with existing routing protocols tocontrol network access as close as possible totraffic sources.

PFIP is a means to distribute the respon-sibility for screening out data that is undesir-able to the recipient. Its intent is to dropunwanted packets as close as possible to theirsource, rather than leaving the responsibilitystrictly with the recipient. The obvious bene-fit is a reduction in wasted network band-width since packets are discarded nearer thesource rather than at the destination. The ca-pability also offers potential as a means toimplement service blocking for householdsor businesses that want to ensure undesirabledata is blocked from certain sites and/orduring certain hours.

Each packet-filtering host is assumed tohave a packet-filter table. This table has anentry for every filtering rule that has beendefined for its interfaces. Rules may be de-fined locally by the network administrator ormay be the result of requests from remotesites whose own rules call for limitations ontraffic from the local hosts. Each packet-filter table entry will be defined according tothe Firewall MIB.

Lack of trust between organizations cre-ates a major obstacle to implementation,since source squelching requires that thesource implement externally defined filters.Without some form of trust mechanism, thethreat of denial of service by a third party issignificant. If the required trust level is notsatisfied for packet-filter updates or a nodedoes not support PFIP, routing information is

used to attempt a filter update at another nodenext closest to the source.

Figure 5 will illustrate the precedingconcepts. It shows one instance of how thePFIP may work to update packet-filter tablesin a mixed network of compliant and non-compliant hosts.

Step 1: Host A creates new packet-filterrule that denies traffic from Host Z.

Step 2: Host A, after a configurablenumber of hits on the new rule, sends a PFIPpacket to Z requesting suppression of traffic.

Step 3: Host Z accepts or rejects the PFIPupdate according to its authentication and/orvalidation requirements. Either acceptanceor rejection causes a reply from Z to A sothat future updates are not attempted.

Step 4: An acceptance message from Zcauses A to mark the PF rule as remotely ac-tivated. If Host A receives a rejection mes-sage, it immediately sends a PFIP updatemessage to node V, the node next closest tothe source.

Step 5: If no response is received after aPF update attempt, a timer at Host A expiresand A assumes that either the update or re-sponse was lost. If three consecutive updateattempts fail, the distant node is assumed in-capable of PFIP updates. In that case, Host Aacts as if a reject message arrived and triesfurther updates with the next closest node(s).

Step 6: Steps 2-5 are repeated until anacceptance message confirms the new up-date, or there are no more nodes to try.

A

RtrR

RtrU

Y

ZRtrV

Rtr

V

T

Network

Figure 5. PFIP Update Scenario

IV. ConclusionsThe expansion of the Internet and the

number of sensitive applications that requirestrong security foreshadow a growth in de-mand for security management capabilities.As electronic commerce, secure messaging andfirewall applications proliferate, managementapplications will be needed to limit adminis-trative burdens while also allowing greaterflexibility and control of security operations.

Before an effective security managementcapability can be developed and demon-strated, there are a few prerequisites. First, asecure management infrastructure must be inplace. SNMPv3 is poised as the secure suc-cessor to SNMPv1. Next, a security MIBmust be defined to allow SET/GET opera-tions on essential values for the security ap-plication to be managed. This is acontentious and difficult step because of theneed to map terms and status parametersfrom many different vendor applications andfeatures to a small set of commonly definedvalues. In this paper, we have suggested acore security MIB with some general pa-rameters applicable to all security applica-tions. The core MIB can be extended todefine configuration and status parametersfor security applications and vendor featuresin the same manner as other MIBs.

The foundational work of defining acommon core of security management infra-structure, attributes and MIB definitions willallow progression to the next phase of capa-bility development, that is, better correlationof management events with security prob-lems. The modification of agent modulesand security management applications to ef-fectively access a common set of securityvalues will open new management features.Then, innovative use of security managementviews and synergy with other managementand security information across the network canunleash new power for security management.

References

[1] Debra Lynn Banning, “A Distributed Audit SystemUsing Network Management Protocols”, Master’s The-sis, California State University, Long Beach, 1992.

[2] Anthony J. Ballardie, “A New Approach to Multi-cast Communication in a Datagram Internet”, Ph.D.Dissertation, University of London, May 1995.

[3] Mark Crosbie, “Active Defense of a Computer SystemUsing Autonomous Agents”, Purdue Univ.,http://www.purdue.cs.edu/homes/spaf/tech-reps/9508.ps.

[4] Li Gong and Mencham Shocham, "Elements ofTrusted Multicasting", In Proceedings 1994 Interna-tional Conference on Network Protocols, p. 23-30,IEEE Computer Society, Los Alamitos, CA, 1994.

[5] ISO/IEC 7498-4, ISO Open Systems Interconnection,Basic Ref. Model, Pt. 4: Management Framework, 1989.

[6] Lee LaBarre, ISO/CCITT to Internet ManagementCoexistence (IIMC): ISO/CCITT to Internet ManagementSecurity (IIMCSEC), Internet draft, MITRE, Feb 1994.

[7] S. Lechner, “SAMSON: Management of Security in OpenSystems”, Computer Communications, Sep 1994.

[8] Marshall T. Rose, The Simple Book: An Introduc-tion to Management of TCP/IP-based Internets, Pren-tice Hall Series in Innovative Technology, Prentice-Hall, Englewood Cliffs, New Jersey, 1991.

[9] John Rushby, "Critical System Properties: Surveyand Taxonomy", Reliability Engineering and SystemSafety, 43(2): 189-219, 1994.

[10] John Rushby, "Kernels for Safety?", Safe andSecure Computing Systems, pp. 210-220, BlackwellScientific Publications, 1989.

[11] William Stallings, SNMP, SNMPv2 and CMIP:the Practical Guide to Network Management Stan-dards, Addison-Wesley, 1993.

[12] Gregory B. White, Eric A. Fisch and Udo W.Pooch, “Cooperating Security Managers: A Peer-Based Intrusion Detection System”, IEEE Network,pp. 20-23, January/February 1996.

[13] WILMA: ftp://ftp.ldv.e-technik.tu-muenchen.de/dist/WILMA/WHAT_IS_WILMA.html

Management of NetworkManagement of NetworkSecurity ApplicationsSecurity Applications

Management of NetworkManagement of NetworkManagement of NetworkManagement of NetworkSecurity ApplicationsSecurity ApplicationsSecurity ApplicationsSecurity Applications

Authors: Philip C. Hyland, TASC, Inc.Authors: Philip C. Hyland, TASC, Inc.

Dr. Ravi Sandhu, GMUDr. Ravi Sandhu, GMU

OutlineOutlineOutline

•• IntroductionIntroduction

•• BackgroundBackground–– TerminologyTerminology–– Network SecurityNetwork Security–– SM ResearchSM Research

•• Integrated Security ManagementIntegrated Security Management–– Management of Security ApplicationsManagement of Security Applications–– Security MIBSecurity MIB–– Firewall MIB TemplateFirewall MIB Template–– Packet Filter Information Protocol (PFIP)Packet Filter Information Protocol (PFIP)

•• ConclusionsConclusions

IntroductionIntroductionIntroduction

•• General Security Management ComponentsGeneral Security Management Components–– Security PolicySecurity Policy

–– Security MechanismsSecurity Mechanisms

–– Security AssuranceSecurity Assurance

GoalGoal: : Trust that “state of security” matches currentTrust that “state of security” matches currentpolicypolicy

ProblemProblem: : Secure Management infrastructure needsSecure Management infrastructure needsimprovement to handle complexity, variety andimprovement to handle complexity, variety andquantity of new security applicationsquantity of new security applications

Security ComponentsSecurity ComponentsSecurity Components

SecurityPolicy

ImplementationMechanisms

Status from Sensors

Indirect InfluenceUsers

Rules Control

ControlEntities

BackgroundBackgroundBackground

•• OSI Management Framework has several SM-orientedOSI Management Framework has several SM-orientedstandards, IETF has nonestandards, IETF has none

•• At least two European projects have developed SM toolsAt least two European projects have developed SM tools–– SAMSON (CMIP/SNMPv2)SAMSON (CMIP/SNMPv2)

–– WILMA (SNMP)WILMA (SNMP)

ProblemProblem: : Few, if any, public SM research efforts ongoingFew, if any, public SM research efforts ongoing

Lesson from Network Management experienceLesson from Network Management experience::

Standards generally benefit all players, even if relativelyStandards generally benefit all players, even if relativelysimplesimple

TERMINOLOGYTERMINOLOGYTERMINOLOGY

•• Security ManagementSecurity Management–– Real-time monitoring and control of active securityReal-time monitoring and control of active security

applications implementing one or more securityapplications implementing one or more securityservicesservices

•• AssuranceAssurance–– PreventionPrevention

–– DetectionDetection

–– RecoveryRecovery

•• Security of Management versus Management ofSecurity of Management versus Management ofSecuritySecurity

Network SecurityNetwork SecurityNetwork Security

•• Benefits from a layered approachBenefits from a layered approach

•• Requires a secure infrastructureRequires a secure infrastructure

•• System view permits coordinated managementSystem view permits coordinated management

•• Efficient administration is key factorEfficient administration is key factor

•• Emergence of SNMPv3 is importantEmergence of SNMPv3 is important

•• DCE SecurityDCE Security

•• Intrusion Detection SystemsIntrusion Detection Systems

•• Key Management for MulticastKey Management for Multicast

•• Distributed Audit SystemDistributed Audit System

•• SNMPv2/v3, etc.SNMPv2/v3, etc.

SM Research: ExampleComponent Efforts

SM Research: ExampleSM Research: ExampleComponent EffortsComponent Efforts

Integrated SMFramework

Integrated SMIntegrated SMFrameworkFramework

•• ConfidentialityConfidentiality

•• Data IntegrityData Integrity

•• LivenessLiveness

•• EncodingEncoding •• Core Security MIBCore Security MIB

•• Security Application MIBsSecurity Application MIBs

Extensible Concepts - CoreSecurity MIB with Plug-ins

Extensible Concepts - Extensible Concepts - CoreCoreSecurity MIB with Plug-insSecurity MIB with Plug-ins

Core Security MIBCore Security MIBCore Security MIB Authentication ServerAuthentication ServerAuthentication Server

Security GuardSecurity GuardSecurity Guard

Access ControlAccess ControlAccess Control

Certificate ServerCertificate ServerCertificate Server

Virus CheckerVirus CheckerVirus Checker

Key GeneratorKey GeneratorKey Generator

Audit TrailAudit TrailAudit Trail

FirewallFirewallFirewall

Administrative PolicyAdministrative PolicyAdministrative Policy

Security PolicySecurity PolicySecurity Policy

SMONSMONSMON

Example Objective: Firewall ManagementExample Objective: Firewall ManagementExample Objective: Firewall Management

InternalFirewall

ExternalFirewall

OrganizationalBoundary

NMS

ExternalFirewall

SNMP

Agent

Internal Network

Remote Network

OrganizationalBoundary

Internet

SNMPAgent

SNMPAgent

ExternalFirewall

Internal Network SNMPAgent

Firewall MIBFirewall MIBFirewall MIB

StatusInfo

ConfigurationInformation

FirewallMIB

StaticInfo

ApplicationTable

FilterTable

PacketStatus

ThresholdViolations

FilterEvents

ThresholdSettings

PFIP Update ScenarioPFIP Update ScenarioPFIP Update Scenario

A

RtrR

RtrU

Y

ZRtrV

RtrT

Network

DataSource

Data Sink1

2

34

5

6

1

2

3

4

5

6

New PF Rule

PFIP Request toward data source

Response to PFIP request

Process Response

Timeout causes retry

PFIP update at next closest node

ConclusionsConclusionsConclusions

•• Need for security management solutions is growingNeed for security management solutions is growing–– More complexity and varietyMore complexity and variety

–– Tighter budgetsTighter budgets

–– More pervasive applicationsMore pervasive applications

•• Secure management infrastructure is evolving, but needSecure management infrastructure is evolving, but needis for more emphasis on common security managementis for more emphasis on common security managementobjectsobjects

•• Time to develop consensus on core Security MIB is nowTime to develop consensus on core Security MIB is now–– Promotes interoperabilityPromotes interoperability

–– Large potential for synergies from “big picture”Large potential for synergies from “big picture”

–– Common foundation while permitting extensionsCommon foundation while permitting extensions