insecure mag 5

8/14/2019 Insecure Mag 5

1/57


2/57


3/57

With 2006 just starting off many are happy to have left a myriad of security problems behind in 2005. Ihope you see more security awareness and experience a cleaner network environment this year.

This issue brings more technical articles and reections on the past year. Many of you e-mailed us askingus to review software titles and hardware, so you ll be glad to know that we have a review in this issue.

Keep those comments coming and thanks for the support!

Mirko ZorzChief Editor

Visit the magazine website at www.insecuremag.com

(IN)SECURE Magazine contacts

Feedback and contributions: Mirko Zorz, Chief Editor - [email protected]

Marketing: Berislav Kucan, Director of Marketing - [email protected]

Distribution

(IN)SECURE Magazine can be freely distributed in the form of the original, non modied PDF document.Distribution of substantively modied versions of (IN)SECURE Magazine content is prohibited without theexplicit permission from the editor. For reprinting information please send an email [email protected] or send a fax to 1-866-420-2598.

Copyright HNS Consulting Ltd. 2006.

www.insecuremag.com


4/57

The popularity of web application rewalls is on the rise. These tools used tobe reserved for a very small percentage of high prole deployments, but, withthe number of less costly products appearing on the market and an opensource option available for anyone to try out (ModSecurity - modsecurity.org),they are nally available to the majority.

In this article I will describe what web applicationrewalls do and give you a quick overview of theirmost useful features. After reading the article youshould leave fairly familiar with the subject matter.You should also have enough information to de-termine whether or not web application rewallshave a place in your life.

What is a web application rewall?

The interesting thing about web application re-walls is that no one really knows exactly what theyare. Or, to say that correctly, it is difcult to get dif-ferent people to agree to a common denition. Invery broad terms, web application rewalls arespecialized tools whose purpose is to increasesecurity in web applications. But try pressing a fewpeople to give you a more specic denition andthey'll give you more questions than answers.Some web application rewalls work are hardwaredevices, some are software applications. Wheresome are network-based, the others work embed-ded in web servers. You can try to compile a list ofweb application rewall vendors and visit their websites in order to learn more, but chances are youwill only get more confused reading what you ndthere.

Jeremiah Grossman, spokesman for the Web Ap- plication Security Consortium (webappsec.org),approached me in late 2004 with an idea of start-ing a project to gure out the web application re-walls. Having been involved with WAFs for some

time I thought it was a beautiful idea. Other peoplemust have liked the idea too because by mid 2005we have had formed a team consisting of some ofthe very knowledgeable people in the web applica-tion rewall market. The Web Application Firewall Evaluation Criteria project was born. (It's homepage is at webappsec.org/projects/wafec) Thename of the project is a mouthful so we are usu-ally referring to it by the abbreviation WAFEC. Tosave me some typing I will also refer to web appli-cation rewalls as WAFs from now on.

This text is not about the work we've done for theproject, although my opinions have, without anydoubt, been heavily inuenced by it. I mention thisproject now (although it was bound to be men-tioned sooner or later instead of later) is because I

remembered one of the emails sent to the projectlist, which illustrates my point about market confu-sion beautifully. Achim Hoffmann, one of the fellowteam members, had sent a list of names variouspeople and organizations used to refer to web ap-plication rewalls over time. With Achim's permis-sion, I am providing the full list here (with a coupleof additions I thought were appropriate):

Adaptive Firewall Adaptive Proxy

Adaptive Gateway Application Firewall Application-level Firewall Application-layer Firewall Application Level Gateway

www.insecuremag.com 4


5/57

Application-level Security Gateway Application Security Gateway Application Security Device Stateful Multilayer Inspection Firewall Web Adaptive Firewall Web Application Firewall Web Application Security Device Web Application Proxy

Web Application Shield

Web Shield Web Security Firewall Web Security Gateway Web Security Proxy Web Intrusion Detection System Web Intrusion Prevention System

There are 22 names on the list and none of themare entirely adequate, for the reasons I will soondiscuss. Adequate or not, of all the names onlyone survived (guess which one). I veried my sus-

picions by using Google to search for each of theterms. Only the term "web application rewall" hadany adverts associated with it.

Enough talk; what is a web applicationrewall?

The main reason it is often difcult for people to

agree on a single denition for a web applicationrewall is simply because the name is used to re-fer to too many things. If you look at the lowernetwork layers (web application rewalls are situ-ated at layer 7) you will nd that they are occupiedby many devices, each specialized for a specicpurpose. We have routers, switches, rewalls, in-trusion detection systems, intrusion preventionssystems, and so on. In the HTTP world, however,we are seeing roughly the equivalent functionalitycrammed into a single device type (and thus onlyone name): the web application rewall.

THE MAIN REASON IT IS OFTEN DIFFICULT FOR PEOPLE TO AGREE ON A SINGLE DEFINI-TION FOR A WEB APPLICATION FIREWALL IS SIMPLY BECAUSE THE NAME IS USED TO RE-FER TO TOO MANY THINGS.

Roughly speaking, it is possible to identify four dis-tinct functionality types within what is today calleda web application rewall (the names in thebracket refer to the equivalent devices on thelower network layers):

1. Audit device. Used to capture full content data(Network Security Monitoring) or only transactionsthat match some criteria (Intrusion Detection Sys-tems).2. Access control device. Used to control accessto web applications, either in positive securitymode (Network Firewalls) or negative securitymode (Intrusion Prevention Systems).3. Architectural/Network design tool. When operat-ing in reverse proxy mode, used to distribute func-

tionality, centralize access, virtualize infrastructureand so on.4. Web application hardening tool. Features thatincrease web application security either by resolv-ing the weaknesses inherent to web applications,or by targeting the programming errors in the ap-plications they are protecting.

Because of the multi-faceted nature of WAFs peo-ple with different backgrounds tend to view them indifferent light. For example, people with back-

ground in network intrusion detection are likely toview WAFs as an IDS devices that just happen tooperate on the HTTP level. Of course, to be en-tirely honest, the lower network layers are notwithout their problems either. For example, the

distinction between intrusion detection and intru-sion prevention if often not quite clear. But RichardBejtlich summed it up well: ... an "IPS" is a layer 7rewall that inverts the access control best prac-tice of "allow some, deny everything else." (Inother words, an IPS performs a "deny some, alloweverything else" function.) I absolutely detest theIPS label and wish access control devices weresimply identied as such, and not confused withaudit devices (e.g., IDSs).

Additional confusion is often introduced when theterm deep-inspection rewalls is involved. Deep-inspection rewalls are devices which, someclaim, have features equivalent to those of webapplication rewalls. But, although there is some

similarity, the difference is profound. Deep-inspection rewalls generally make some effort tolook beyond level 3 and into higher levels. Webapplication rewalls, on the other hand, are toolsthat are built from the ground up to handle HTTPand they understand it very well. A very good (andentertaining) overview of this subject has beenprovided by Marcus J. Ranum in his 'What is"Deep Inspection?' text, available atranum.com/security/computer_security/editorials/deepinspect/.

It is important to accept one fact though: it is notnecessary for a device to implement all four typesof functionality in order for it to be called a webapplication rewall. As long as there is a clear



6/57

understanding of the possible variations, anythingthat increases web application security can becalled a WAF as far as I am concerned. What endusers need to do is rst determine what theirneeds are and then nd a tool that fulls them.

Evolution of Web Intrusion Detection

Intrusion detection, as a concept, has been withus for many years. Its purpose is to detect attacksby looking at the network trafc or by looking atoperating system events. The term intrusion pre-vention is used to refer to systems that are alsocapable of preventing attacks.

Today, when people mention intrusion detection, inmost cases they will be referring to a network in-trusion detection system (NIDS). An NIDS workson the TCP/IP level and is used to detect attacksagainst any network service, including the webserver. The job of such systems, the most popularand most widely deployed of all IDSs, is to monitorraw network packets to spot malicious payload.Host-based intrusion detection systems (HIDSs),on the other hand, work on the host level. Thoughthey can analyse network trafc (only the trafcthat arrives to that single host), this task is usuallyleft to NIDSs.

Host-based intrusion is mostly concerned with theevents that take place on the host (such as users

logging in and out and executing commands) andthe system error messages that are generated. AnHIDS can be as simple as a script watching a logle for error messages. Integrity validation pro-grams (such as Tripwire) are also a form of HIDS.Some systems can be complex: one form of HIDSuses system call monitoring on a kernel level todetect processes that behave suspiciously.

Using a single approach for intrusion detection isinsufcient. Security information management(SIM) systems are designed to manage varioussecurity-relevant events they receive from agents,where an agent can listen to the network trafc oroperating system events or can work to obtain anyother security-relevant information.

Because many NIDSs are in place, a large effortwas made to make the most of them and to usethem for web intrusion detection, too. ThoughNIDSs work well for the problems they were de-signed to address and they can provide some helpwith web intrusion detection, they do not and can-

not live up to the full web intrusion detection po-tential for the following reasons:

NIDSs were designed to work with TCP/IP. TheWeb is based around the HTTP protocol, which is

a completely new vocabulary. It comes with itsown set of problems and challenges, which aredifferent from the ones of TCP/IP. The real problem is that web applications are notsimple users of the HTTP protocol. Instead, HTTPis only used to carry the application-specic data.It is as though each application builds its own pro-tocol on top of HTTP.

Many new protocols are deployed on top of

HTTP (think of Web Services, XML-RPC, andSOAP), pushing the level of complexity further up. Other problems, such as the inability of an NIDSto see through encrypted SSL channels (whichmost web applications that are meant to be secureuse) and the inability to cope with a large amountof web trafc, make NIDSs insufcient tools forweb intrusion detection.

Vendors of NIDSs have responded to the chal-lenges by adding extensions to better understand

HTTP. The term deep-inspection rewalls refers tosystems that make an additional effort to under-stand the network trafc on a higher level. Ulti-mately, a new breed of IDSs was born. Web application rewalls (WAFs) are designed specicallyto guard web applications. Designed from theground up to support HTTP web application re-walls often work as reverse proxies. Instead of go-ing directly to the web application, a request is re-routed to go to a WAF rst and only allowed toproceed if deemed safe. Web application rewalls

were designed from the ground up to deal withweb attacks and are better suited for that purpose.NIDSs are better suited for monitoring on the net-work level and cannot be replaced for that pur-pose.

Though most vendors are focusing on supportingHTTP, the concept of application rewalls can beapplied to any application and protocol. Commer-cial products have become available that act asproxies for other popular network protocols and forpopular databases. (Zorp, atbalabit.com/products/zorp/, available under acommercial and open source license at the sametime, is one such product.)

Isn't it better to just x the code?

Of course it is. But it is not that simple. Sometimesthere is a controversy as to whether we are correctto pursue this approach to increasing security. Acommon counter-argument is that web intrusiondetection does not solve the real problem, and

that it is better to go directly to the problem and xweak the vulnerable web applications. I tend toagree with this opinion. However the reality is pre-venting us from letting go from web applicationrewalls:



7/57

It is not possible to make anything 100% secure- humans have limited capabilities and make mis-takes. Attempting to approach 100% security is noteven done in most cases. Today, in real life, thosewho direct application development usually de-mand features, not security. Attitudes are chang-ing, but slowly.

A complex system always contains third-party

products (components, libraries) whose quality(security-wise) is not known. If the source code forthe products is unavailable, then you are at themercy of the vendor to supply the xes. Even inthe cases when the source code is available youare unlikely to have the resources to review it. We must work with existing vulnerable systems.Some of these legacy systems can not betouched.

It is, therefore, necessary to adopt a dual-approach strategy to achieve best results. Youshould work hard to raise awareness among man-agement and developers. In the meantime dowhat you can to increase security straight away.

Life becomes much easier once you accept youwill fail. To deal with the problem (in this casedeal means minimize the chance of total failure)people invented an approach called defense in depth . By now, defense in depth is a well-knownand a widely accepted security principle. The ba-sic idea is that you don t want to put all your eggsinto the same basket. Instead, assuming any partof the system can fail, you look for ways to cong-ure other parts, or introduce new parts to limit theeffect of the failure. Web application rewalls are

just another piece in the security puzzle. Treatthem as such.

Web Application Firewall Features

The following sections describe some of the moreinteresting features frequently found in web appli-cation rewalls.

Protocol anomaly detection

If you read through various RFCs, you may detecta recurring theme. Most RFCs recommend thatimplementations be conservative about how theyuse protocols, but liberal with respect to what theyaccept from others. Web servers behave this way

too, but such behavior opens the door wide openfor all sorts of attacks. Almost all WAFs performsome sort of sanity check on incoming requestsand refuse to accept anything that is not in accor-dance with the HTTP standard. Furthermore, theycan narrow down the features to those that areacceptable to the application and thus reduce theattack surface area. Some will even go furtherthan that, restricting certain aspects of the HTTPprotocol that were left too loose or completely un-specied.

Enforcing input validation

A frequent web security problem occurs where theweb programming model is misunderstood andprogrammers think the browser can be trusted. If

that happens, the programmers may implementinput validation in the browser using JavaScript.

Since the browser is just a simple tool under con-trol of the user, an attacker can bypass such inputvalidation easily and send malformed input directlyto the application.

A correct approach to handling this problem is toadd server-side validation to the application. If thatis impossible, another way is to add an intermedi-ary between the client and the application and tohave the intermediary reinterpret the JavaScriptembedded in the web page.

Negative versus positive security models

If you have ever worked to develop a rewall pol-icy, you may have been given advice to start witha conguration that denies access to everything,and only then proceed to allow the trafc youknow is safe. That is a very good example of apositive security model. Negative security modeldoes the opposite - access is allowed by defaultand some dangerous trafc patterns are denied.

The two approaches each ask a question:

Positive security model: What is safe? Negative security model: What is dangerous?



8/57

A negative security model is used more often. Youidentify a dangerous pattern and congure yoursystem to reject it. It is simple, easy, and fun. But itis not foolproof. The concept relies on you know-ing what is dangerous. If there are aspects of theproblem you are not aware of (which happensfrom time to time) then you have left a hole for theattacker to exploit.

A positive security model (also known as a white-list model) appears to be a better approach tobuilding policies and works well for rewall policybuilding. In the realm of web application security, apositive security model approach boils down toenumerating every script in the application. Foreach script in the list, you need to create a listsuch as this one:

Allowed request methods (e.g., GET/POST orPOST only)

Allowed Content-Type Allowed Content-Length Allowed parameters Which parameters are mandatory and which areoptional The type of every parameter (e.g., text or inte-ger) Additional parameter constraints (where applica-ble)

This list is just an example. A real-life positive se-

curity model typically includes more elements.Positive security model actually attempts to do ex-ternally what programmers are actually supposedto internally: verify every bit of information thatgoes into a web application. Using the positive se-curity model is better if you can afford to spend thetime to develop it. One difcult aspect of this ap-proach is that the application model changes asthe application evolves. You will need to updatethe model every time a new script is added to theapplication or if an existing one changes. But itworks well to protect stable, legacy applicationsthat no one maintains anymore.

Automating policy development can ease prob-lems:

Some WAFs can observe the trafc and use it tobuild the policy automatically. Some can do it inreal time. With white-list protection in place, you may beable to mark certain IP addresses as trusted, andcongure the WAF to update the policy according

to the observed trafc. If an application is built with a comprehensiveset of regression tests (to simulate correct behav-ior), playing the tests while the WAF is watchingwill result in a policy being created automatically.

So it turns out neither approach is entirely satis-factory on its own. Negative security model workswell to deal with known problems. Positive securitymodel works well for stable web applications. Acombination of both approaches is ideal to use inreal life.

Just-in-time Patching

The positive security model has the potential towork well because the communication between abrowser and the application is well dened in theHTML specication. Scripts that make web appli-cations are essentially designed to process re-quests that consist of a number of parameters.This is true for almost any application out there.Since these parameters are visible to the web ap-plication rewall it is possible to make decisionsbased on its observations. This leads to a interest-ing WAF capability I like to call just-in-time patch-ing. Is it very simple, really.

When a vulnerability in an application is discov-ered in most cases forces are put in motion toclose the hole in the code. Depending on the cir-cumstances (the size of the application, availabilityof developers, legal arrangements and such) theprocess can last anywhere from a couple of min-utes to, well, innity. This is the window of oppor-tunity for the attacker to exploit.

If you can close a vulnerability in code quickly thenyou don't have anything to worry about. But what ifthe length of the window of opportunity is meas-ured in days or weeks? Web application rewallsare ideal tools to help with this: give a decent WAFto a security professional together with enoughinformation about the security problem and he willlikely be able to close the security hole in underone hour. Naturally, this type of protection is notfoolproof and there is always a danger the x isnot complete but in case when you have no otherchoice any protection is better than no protection.Still, the advantages are worth restating:

1. Just-in-time patching is applied as a separatesecurity layer.2. It can be implemented straight away. (Someweb application rewalls require changes to thenetwork layout but some are happy to work em-bedded in the existing web server.)3. It is work executed by a different user prole.Your typical developer may not be very skilled inapplication security, but chances are the security

professional that discovered the problem is.

The principle of just-in-time patching is even eas-ier to apply to the XML-based applications be-cause the application communication is much



9/57

better documented. On the other end of the rangeare various AJAX applications, which tend to usetheir own unique protocols to exchange informa-tion between browsers and the application code.This is where just-in-time patching without customprogramming becomes much difcult.

Rule-based versus anomaly-based protec-

tionRule-based WAFs comprise the majority of what isavailable on the market today. They subject everytransaction to a series of tests. Each test can con-sists of one or more inspection rules. If the testfails, the request is treated as invalid and possiblyrejected.

Rule-based WAFs are easy to build and use andare efcient when used to defend against knownproblems. They are also easy to use when thetask is to build a custom defence policy. But sincethey must know about the specics of every threatto protect from it, these tools must rely on usingextensive rule databases. Vendors maintain ruledatabases and distribute their tools with programsto update WAF installations automatically.

This approach is unlikely to be able to protect cus-tom applications or to protect from zero-day ex-ploits (exploits that attack vulnerabilities that arenot yet publicly known). This is where anomaly-

based IDSs work better.

The idea behind anomaly-based protection is tobuild a protection layer that will observe legal ap-plication trafc and then build a statistical model to

judge the future trafc against. In theory, oncetrained, an anomaly-based system should detectanything out of the ordinary. With anomaly-basedprotection, rule databases are not needed andzero-day exploits are not a problem. Anomaly-based protection systems are difcult to build andare thus rare. Because users do not understandhow they work, many refuse to trust such systems,making them less popular than their rule-basedcounterparts.

State management

The stateless nature of the HTTP protocol hasmany negative impacts on web application secu-rity. Sessions can and should be implemented onthe application level, but for many applications theadded functionality is limited to fullling business

requirements other than security. Web applicationrewalls, on the other hand, can throw their fullweight into adding various session-related protec-tion features. Some of the features include:

Enforcement of entry points. At most web sites,you can start browsing from any site URL that isknown to you. This is often convenient for attack-ers and inconvenient for defenders. An IDS thatunderstands sessions will realise the user is mak-ing his rst request and redirect him back to thedefault entry point (possibly logging the event).

Observation of each user session individually.

Being able to distinguish one session from anotheropens interesting possibilities, e.g., it becomespossible to watch the rate at which requests aremade and the way users navigate through the ap-plication going from one page to another. Lookingat the behavior of just one user it becomes mucheasier to detect intrusion attempts.

Detecting and responding to brute-force attacks.Brute-force attacks normally go undetected inmost web applications. With state management in

place, an IDS tracks unusual events (such as loginfailures), and it can be congured to take actionwhen a threshold is reached. It is often convenientto slow down future authentication attemptsslightly, not enough for real users to notice butenough to practically stop automated scripts. If anauthentication script takes 50 milliseconds tomake a decision, a script can make around 20 at-tempts per second. If you introduce a delay of,say, one second, that will bring the speed to underone attempt per second. That, combined with an

alert to someone to investigate further, would pro-vide a decent defense.

Implementation of session timeouts. Sessionscan be expired after the default timeout expires,and users would be required to re-authenticate.Users can be logged out after a time of inactivity.

Detection and prevention of session hijacking. Inmost cases, session hijacking results in a changeof IP address and some other request data (thatis, request headers are likely to be different). Astateful monitoring tool can detect the anomaliesand prevent exploitation from taking place. Therecommended action to take is to terminate thesession, ask the user to re-authenticate, and log awarning.

Allowing only links provided to the client in the previous request. Some tools can be strict andonly allow users to follow the links that have beengiven in the previous response. This seems like aninteresting feature but can be difcult to imple-

ment. One problem with it is that it prevents theuser from using more than one browser windowwith the application. Another problem is that it cancause incompatibilities with applications usingJavaScript to construct links dynamically.



10/57

Other protection techniques

Other security-hardening features specic to webapplication rewalls aim to remedy the problemsthat arise when the developers place trust in theinput data. For example:

Hidden form elds protection. Internal applica-tion data is sometimes exposed via hidden formvariables, which are not hidden at all. Program-mers often use hidden form elds to preserveprocess state, send data to the user and expectsuch data back with no modications. Such data isvery easy to change. This is a tough problem tosolve, but WAFs usually employ selective crypto-graphic signing to deal with it.

Cookies protection. Similar to the problems withthe hidden form elds, cookies are sometimesused to transport private application data. Unlikehidden form elds, some cookies may contain verysensitive data so WAFs usually encrypt their con-tents altogether. Another approach is to com-pletely virtualise the cookie mechanism. In such asetup the end users only see cookie tokens (simi-

lar to session tokens), while the cookies are keptsafely in the web application rewall itself.

Anti-evasion techniques

One area where network-based IDSs have hadtrouble with web trafc is with respect to evasiontechniques. The problem is there are so manyways to alter incoming (attack) data, so that itkeeps the original meaning as far as the applica-tion is concerned, but to still have it modied suf-ciently to sneak under the IDS radar. This is anarea where being able to understand HTTP com-pletely results in signicant improvement.

For example, just by looking at whole HTTP re-quests at a time, an entire class of attacks basedon request and packet fragmentation is avoided.And because they understand HTTP well and canseparate dynamic requests from requests for staticresources (and so choose not to waste time pro-tecting static requests that cannot be compro-mised), they can afford to apply many differentanti-evasion techniques that would prove too timeconsuming for NIDSs.

NO MATTER HOW YOU CALL THEM, WEB APPLICATION FIREWALLS ARE VERY USEFUL SE-CURITY TOOLS WITH A SECURE POSITION (NO PUN INTENDED) IN EVERY SECURITY PRAC-TITIONER'S TOOLBOX. THEY ARE HERE TO STAY.

Response monitoring and information leakprevention

Information leak prevention is a fancy name formonitoring of the outgoing HTTP trafc. In princi-ple it is identical to request monitoring, and its goalis to watch the output for suspicious patterns andprevent the response from reaching the clientwhen such a pattern is detected. The most likelycandidates for patterns in output are credit cardnumbers and social security numbers. Anotheruse for this technique is to watch for signs of suc-cessful intrusions.It is not really possible to prevent a determinedand skillful attacker from retrieving a piece of in-formation, since she will always be able to encodethe information in some a way as to prevent detec-tion. Still, this technique can protect in the caseswhen the attacker does not have full control overthe server but instead tries to exploit a weaknessin the application.

Conclusion

No matter how you call them, web applicationrewalls are very useful security tools with a se-cure position (no pun intended) in every securitypractitioner's toolbox. They are here to stay.Whether the name itself will remain is a matter fordebate. Many believe the name is not entirelyadequate and that the major vendors will force aname change in order to get a bigger slice of theapplication market. This article only scratches the

surface of this subject. If you care to learn moreabout it I suggest you visit the Web ApplicationFirewall Evaluation Criteria project, which has re-cently had its rst ofcial release. It's a concise adocument of twenty pages which lists various as-pects of web application rewalls. Reading itprobably won't be as entertaining as reading thisarticle was but it can at least claim to be a seriousattempt to provide a comprehensive analysisframework.

Ivan Ristic is a web security specialist and the author of ModSecurity (modsecurity.org), an open source webapplication rewall. He is the founder of Thinking Stone (thinkingstone.com), a web application security com-pany. Ivan wrote "Apache Security" for O'Reilly (apachesecurity.net), a concise yet comprehensive web secu-rity guide for administrators, system architects, and programmers. Ivan is an active participant in the web ap-plication security community, and a member of the Web Application Security Consortium.



11/57


12/57

Over the years we have seen a number of different concepts that were trying

to help the state of security of an average Windows PC user. Earlier, the onlymajor problems were viruses, than we saw Trojans, worms, spyware, mali-cious scripting, etc. Antivirus software nowadays incorporates scanning forall the mentioned types of pests, but the approach that is based on signatureupdating and therefore on human intervention is not a perfect way to secure aPC user.

Security company Trustware (www.trustware.com)has a product that takes a new approach on pro-

tecting the end users. BufferZone is centered on aconcept of virtualization technology, that creates awhole new secluded environment on your com-puter.

After installing the software, you are guidedthrough a mini presentation that introduces you tothe process of setting up your BufferZone. Al-though usage of terms like "virtualization" and"buffer" might be a bit complicated for the averagePC user, the concept is very easy to comprehendand to setup.

Fighting the malware

Your connection to the Internet has probably thebiggest potential of damaging your computer inany way. Using a non patched browser and visitinga site with malicious code can very fast compro-mise your computer. Downloading and starting ale without any proper checking by a 24/7 updatedantivirus product could generate a massive infes-tation that will soon hurt your computer in many

ways. These are just some of the constant threatsPC users are susceptible to.

BufferZone comes to the rescue with only a fewof clicks you could create a defensive shield

around all the pieces of software that interact withremote computers over the Internet. For instance,

if you are still using Microsoft Internet Explorer,you are probably well aware of the problems un-patched versions of this software could generate.Never mind, just add Internet Explorer into theBufferZone and every potential malicious script willexecute in this simulated environment and there-fore won t have any impact on your real computerles.

From my perspective, the real power of Buffer-Zone is not just real-time protection from the prob-lems that can occur while browsing, but the possi-bility of reassuring that downloaded les are se-cure for running.

In the test case scenario, I tried to download aTrojan that gets a list of all my les and sends it toan online web page. I downloaded the le andstarted it while it was placed outside the Buffer-Zone. The Trojan did its payload and very soon Icould see my details online. I then sent the le tothe BufferZone and started it once again.

This time the test Trojan encountered an internalerror as he couldn t list my les, and it reportedthat my computer was secure. I usually downloada lot of different les from the Internet, especiallyfrom sites like Sourceforge and Freshmeat.



13/57

Although they have different methods of takingcare of le integrity and security, you never know

when you will come across an evil developer thatwill create some kind of a unsafe le.

Test Trojan output when application is run outside the BufferZone

BufferZone main screen

During my tests, I ran different programs in theBufferZone, from simple SCP clients and InstantMessengers to an mpeg4 modier program that Iused for editing a couple of gigabytes of digitalvideo les. All programs worked like a charm, Ididn t come across any potential problem. There isa very nice visual touch all programs that are in

the BufferZone have a red border around theiricons and windows (see an example on the follow-ing page). This way you always know if you areworking within an insecure or secure environment.If the border annoys you, you can disable it fromthe conguration menu.



14/57

The red border indicates that this le is in the buffer zone

The program hosts a couple of customizing fea-tures. You can group specic les under severalcategories including Web, Mail and P2P. Thishelps a bit as the most popular software is prede-ned. When you start BufferZone out of the box, it

will immediately add the popular Internet relatedtools into its environment. You can also add yourown software into these categories, making it easyto enable or disable a specic set of programs.

If you want, any le can be sent for execution outside of the protected zone

From the enterprise point of view, BufferZone 1.6incorporates advanced management tools formonitoring, controlling and enforcing user activitythroughout the LAN. These include an enterprise-wide, automated, scheduled BufferZone technol-ogy re-set that removes BufferZone values fromWindows registries without data loss. Also, there isa tool that controls and prevents installation any-where on the LAN of software not originating from

designated servers and lets managers dene ac-ceptable lename extensions. Managers couldalso monitor all BufferZone activity in real time.

Overall, BufferZone is a must have software forWindows users. Its powerful virtualization enginecreates a trusted environment that you will verysoon fall in love with. The software is very easy tosetup, manage and use.

Mark Woodstone is a security consultant that works for a large Internet Presence Provider (IPP) that servesabout 4000 clients from about 30 countries worldwide.



15/57

Extrusion Detection: Security Monitoring for Internal Intrusionsby Richard BejtlichAddison-Wesley Professional, ISBN: 0321349962

Extrusion Detection is a comprehensive guide to preventing, detecting, and mitigating se-curity breaches from the inside out. Bejtlich teaches you how to assess threats from in-ternal clients, instrument networks to detect anomalies in outgoing trafc, architect net-works to resist internal attacks, and respond effectively when attacks occur.

If you ve enjoyed Bejtlich s previous publications, especially The Tao of Network SecurityMonitoring, you will love this one.

Digital Identityby Phillip WindleyO'Reilly, ISBN: 0596008783

The author shares his extensive knowledge on the ideas, issues, and technologies be-hind a key concept known as Identity Management Architecture (IMA).

Focused on upper management and IT professionals working in this eld, the book cov-ers in details set of standards, policies, certications, and management activities that en-able companies to manage digital identity effectively.

Real Digital Forensics : Computer Security and Incident Responseby Keith J. Jones, Richard Bejtlich, Curtis W. RoseAddison-Wesley Professional, ISBN: 0321240693

If you are into forensics, this book is probably already on your book case. If not, youshould denitely check this out.

The authors provide ve different scenarios and show you what steps to take and whattools to use in the process of incident response. The book is complemented with a DVD

with all the evidence collected for each of the scenarios, which makes the educationalperspective of this book much more interesting.



16/57

Self-Service Linux: Mastering the Art of Problem Determinationby Mark Wilding, Dan BehmanPrentice Hall PTR, ISBN: 013147751X

In Self-Service Linux, two of IBM s leading Linux experts introduce a four-step methodol-ogy for identifying and resolving every type of Linux-related system or application prob-lem: errors, crashes, hangs, performance slowdowns, unexpected behavior, and unex-pected outputs.

If you re involved with deploying or managing Linux in the enterprise, it can help you sig-nicantly reduce operation costs and enhance availability.

Computer Privacy Annoyancesby Dan TynanO Reilly, ISBN: 0596007752

This is a very interesting little book that will make you think a bit more about your pri-vacy, both at home, work and online. It contains a myriad of good tips, each of them con-taining information on the actual annoyance and a possible solution.

Although the title of this book implies that it focuses on computers, the author also man-aged to give a lot of good tips on various real life stations, including dealing with the IRS,US government, postal service, etc.

(SCTS) Symantec Certied Technical Specialist: Small Business SecurityStudy Guideby Nik Alston, Mike Chapple, Kirk HausmanAddison-Wesley Professional, ISBN: 0321349946

Symantec s Certied Technical Specialist (SCTS), Small Business Security certicationallows security professionals to validate their knowledge of today s most crucial informa-tion security techniques in combination with Symantec s security products.

This guide covers the exam objective in depth; everything you need to know to pass yourexam the rst time. The book comes with a CD that contains a couple of SCTS sampleexams.

Essential PHP Securityby Chris ShiettO Reilly, ISBN: 059600656X

This hundred pager should be a must for every self-conscious PHP developer. A largemajority of PHP web applications had some kind of a security vulnerability, so develop-ers, start your engines. Essential PHP Security is a straight-forward book, it has 100pages and hosts a precise problem/solution type of content. This could also be a goodread to penetration testers, as it will denitely broaden their knowledge on the subject.



17/57

System and security administrators have long known the value in capturingand analyzing log data. Systems administrators tend to focus on operatingsystem logs, while security administrators focus on router, rewall, and simi-lar log data. Unfortunately these groups rarely see how system logs and se-curity log data can be used together to paint a better overall picture of what isgoing on in the environment.

The goal of this article is to educate system andsecurity administrators, and others, on the value inanalyzing disparate log data to discover potentiallymalicious behavior.

This article is broken up into the following sec-tions:

Log Data Basics Log Gathering Architecture Prepare Log Data for Analysis Analyzing Events for Threats Threat Analysis Example Tools of the Trade

Let s begin by summarizing the threat analysisprocess. The following ve steps briey discussthe process.

Step 1. Congure

Generally you will need to congure your systemsto begin emitting log data. This is system- anddevice-specic so this step will not be discussed inthis article.

Step 2. Understand

Understanding what sort of log data your systemscan emit is critical. It is through this understandingthat you are then able to effectively analyze datafor interesting behavior. It may be that you are wellversed on the nature of your systems and you canformalize what sort of things you will want to look

for. Or it may be that you are somewhat new toadministration of security systems and may needinput from others in your organization or from on-line resources. For example, your accountinggroup may have ideas on the sort of things to lookfor with respect to nancial systems and such.

Step 3. Collect

Aggregation is often used to describe the act ofcollecting log data to a central location. By collect-ing all log data to a central you are able to look atthings as a whole and perform effective analysis.

Step 4. Prepare

Preparing log data for analysis is performedthrough normalization . The end result of normali-

zation is the creation of an event, which is used inthe analysis process.

Step 5. Analyze

The fth and nal step is analysis. Here we areconcerned about discovering potentially maliciousbehavior.

Analysis is generally performed against events,but in some instances analysis is performedagainst raw log data.

Let s now begin the journey down the path tothreat analysis.



18/57

Log Data Basics

Log data is a general term used to identify infor-mation which can be used to better understandwhat is going on with a particular system, set ofsystems or network. Some systems, like operatingsystems, store log data on disk. Others like routersor hardware-based systems don t have internaldisks to store log data on; they simply emit logdata.

Most people think of a le on disk when they hearthe term log data or log messages. UNIX adminis-trators tend to think of /var/log/ or /var/adm asrepositories for log data. Windows people, on theother hand, are used to dealing with the EventLog. As for log data sources, again most peoplethink of UNIX or Windows servers, routers, andsuch.

While these are accurate, the source of log data isnot limited to a certain type of system. The follow-ing is a partial list of system/device classes whichare capable of generating log data.

Operating System (OS) Firewall Network Intrusion Prevention System (NIPS) Host Intrusion Prevention System (HIPS) Authentication Systems (Kerberos, Radius, etc.) Vulnerability Assessment (VA)

Anti-Virus (AV) Anti-Spam Router Switch

The type of information contained in log data var-ies greatly. Some examples of the type of informa-tion which could be used for threat analysis in-clude:

Login/Logout Messages User Account addition, modication, or deletion Disk Full Messages Firewall allow/deny Messages NIPS Messages Web Server Logs Many others

Log Data Transmission

Log data transmission deals with how data is sentand received. This includes knowing what trans-mission protocols your systems support and con-

guring them to send data. The most commonprotocol is Syslog. Generally speaking some pieceof software is run to gather log data sent via oneof these transmission protocols.

The following list of Internet-protocol specicmethods are utilized by many devices and sys-tems systems:

Syslog

Syslog (System Logger) is a simple UDP-basedprotocol. Syslog logging comes in two avors: lo-cal logging and remote logging. Local logging iswhere logs are generated and stored on the samemachine. Remote logging is where one machinegenerates a log message but forwards it on to an-other machine for storage. By default all datatransmission is sent in clear-text. Since Syslog isthe most commonly used mechanism, let s delveinto it a bit more. Syslog messages generally havethe following simple format:

The format is as follows:

Timestamp This is the time and date of when the messagewas created. If local logging is used then it sbased on the local machine s time. If the messagewas received from a remote machine then thetime is based on the remote machine.

Hostname The hostname can be an IP address (if no DNS

information for the IP address exists), fully quali-ed domain name (FQDN) or simply a hostname.

Message source The message source indicates, as you might haveguessed, the source of the message. Foroperating-system components or applications, thesource is usually a process name. Note that whenreceiving messages from devices like routers,switches, and rewalls, you generally will not get aprocess ID as part of the source. Often times allyou get is something along the lines of the vendorname.

Message The message contains specic detail on whathappened. Note that message formats betweenapplications, systems, devices, vendors, etc., alldiffer, e.g. it is very free-form in nature.

SNMP

SNMP (Simple Network Management Protocol) isalso UDP based.

There are three versions of SNMP: SNMPv1,SNMPv2, and SNMPv3. SNMPv3 adds security tothe protocol in the form



19/57

of authentication and encryption. Many systemsemploy SNMP traps for sending of log data.

SMTP

SMTP (Simple Mail Transfer Protocol) is TCP-based. While many systems support SMTP fornotication, it is rare to see a system which usesSMTP as its log data emission mechanism, but afew do exist. The default is to send in clear-text.

Beyond these Internet-standard methods, proprie-tary ones also exist. These are protocols and APIsthat commercial vendors have created. Somethese include the following:

Checkpoint OPSEC LEA

The Open Platform for Security (OPSEC) is anopen and extensible framework for managing all

aspects of network security. The Log Export API(LEA) is one API under the OPSEC umbrella. LEAcan be used to gather Checkpoint rewall logsfrom Checkpoint s SmartCenter management plat-form. The LEA API uses encryption to securelytransmit data.

Cisco RDEP/SDEE

The Remote Data Exchange Protocol (RDEP) isCisco s rst generation protocol for gather log datafrom its IPS product. The Security Device EventExchange (SDEE) extends and updates RDEP.Both clear-text and encrypted modes are sup-ported.

Sourcere E-Streamer

E-Streamer is a protocol used to gather log datafrom SourceFire IPS. Both clear-text and en-crypted modes are supported.

Windows Event Log

The Windows Event Log is Microsoft s centralsource for logging. There are three main log types:System, Application, and Security.

Log Gathering Architecture

Gathering log data requires you to congure yoursystems to emit log data. Once this is done, youthen need a place to capture all this data. At aminimum you need a server that will act as the

central collector or log server. Aggregation is usedto describe the act of gathering log data in oneplace. A log data architecture generally has anumber of components which are discussed now.

Collector

The collector is used to collect and aggregate logdata from log data sources.

Analysis Server

The analysis server does the actual work of ana-lyzing log data for threats. Note that the collectorand analysis server may be on the same machineor different machines for efciency.

Archive Server

The archive server is used to store log data, eitherin raw form, normalized form or both, so it can beanalyzed at a later time or for report generation.Typically a database is used to store this informa-tion.

Administrator Console

The administrator console is generally some pieceof software which is used for viewing log data,events, alerts, reports, etc.

Reporting

Reporting is generally performed on data in thearchive database.

Figure-1 (on the following page) depicts a basiclog-gathering architecture.

There are actually two architectures within Figure-1. The st one is the most basic. The rewall,router, database and Web server are all cong-ured to send their log data to the central logserver. The central log server is responsible notonly for gathering log data, but for preparing thedata for analysis.

The second architecture is one where a remote

collector is used at a remote network site. It iscalled a collector because it is responsible for col-lecting log data, but it forwards what it receives tothe central log server. There are several reasonsfor using a remote collector:

You may not want all log data owing over yourInternet link. You can lter out messages you don tcare about or want to analyze and save on band-width. The collector could prepare the data before it issent to the central server. This would allow theserver to not have to work as hard and spendmore time analyzing critical events. You may want to encrypt the data sent over theInternet.



20/57

Figure-1. Log gathering architecture

The nal component in the architecture is theadministrators/analysts who are consumers of thegathered log data and analyses. It is their job to beaware of what s going on both at the network leveland at the machine level. For more information oncreating a logging server, see Anton Chuvakin s

article Advanced Log Processing(www.securityfocus.com/infocus/1613). He alsodiscusses how to secure Syslog transmission.

Prepare Log Data for Analysis

While Syslog s protocol has a common format, thedevice- or system-specic data format itself varieswidely. This is because no two vendors pick theidentical format for messages and log data.

Preparing Log Data

Recall that Step 4 in the threat-analysis process isto prepare log data. This is a critical and importantstep in the threat analysis process. Unfortunately,it is also tedious and error prone. This is becauseyou have to know and understand the format ofthe log data you gather. Some vendors provideexcellent documentation on their message for-mats, while others either inaccurately document orprovide no documentation at all. Normalization isthe process of going from a specic format to acommon one without loss of precision. The outputof normalization is an event. This event is what isused during the analysis phase. But what is anevent?

Event Creation

Think of an event as the currency used within ananalysis system. How an event comes into exis-tence depends upon the underlying locomotionmechanism used for normalization. Here are some

example mechanisms.

Database A schema can be created which embodies anevent format. Log data is received, normalizedand inserted into an event table. Standard SQLcan then be used to analyze the event table. Theuse of a database is quite common and can makelife a little easier.

Programming language-specic Structure

The C programming language allows the pro-grammer to create user-dened types using struc-tures. Object oriented languages like Java andC++ facilitate the creation of user-dened typesvia classes. Regardless of the language used, thegoal is the same as with a database. The maindifference is that a database isn t used. Insteadyou have a system, written in one particular lan-guage, broken up by components. One compo-nent gets the log data, normalizes it. Events arecreated in a language specic manner andhanded off to an analysis component. The analy-sis component may be on the same machine asthe normalization component or it may be on aremote machine (for efciency purposes). Thismeans some sort of inter-process communication



21/57

(IPC) will need to be used to pass informationfrom one component to the next.

Flat-le A simpler way to create events is to use at-leswhere each line contains a CSV line of text. Eachvalue would map to specic eld in your normal-ized event. Similar to a database, the at lewould be processed for analysis.

Event Fields

Now that we have established what an event is,what sort of elds should we have in our eventstructure? The following list outlines some of themore common elds that are of interest to systemand security administrators.

Date and Time It is important to record the time the message was

received by the collector or server. Some vendorsalso include the time the message was created,which should be captured in another eld. Someproducts and systems emit epoch timestampswhile others generate normal month, day, time,etc. It is often easier to deal with epochs, so con-sider normalizing all date and times to an epoch.

Application/File Names This could either be the application which gener-ated the message or an application which at-tempted to perform an illegal action, e.g. a hostintrusion prevention system can identify potentiallymalicious applications.

Application Exit Codes Some log messages may contain exit codes,which could help point out dubious behavior.

Source and Destination IP Addresses and Ports Firewall and NIPS systems generate source anddestination IP address and port information whichcan be used to discover malicious behavior pat-

terns, among other things.

Taxonomy Type A Taxonomy is a set of types which are alignedaround conceptual boundaries. For example, onerewall vendor may emit a message which usesthe word accept, but a different rewall vendormay use the word allow. Through use of a tax-onomy, these two messages could be normalizedsimply as accept. But taxonimication doesn t stopat homogenous device normalization. It can also

be used for heterogeneous normalization.For example, let s say IPS vendor A emits logMessage-A. Firewall vendor B emits log Message-B. It turns out that Message-A and Message-B arethe same conceptually. This means that two dis-

tinct messages are now collapsed down to onesingle concept.

Priority The priority is used to determine how severe anevent is. Some of the log data you normalize willhave its own priority value as part of the message,while others will not. It is generally a good idea toestablish your own priority scheme and map yourlog data s priorities to this scheme. One simplescheme is to use low, medium, and high.

Protocol The most common are UDP and TCP.

ICMP Type and Code When the protocol is ICMP, don t forget to recordthe type and code.

Username

Capturing username information is very useful intracking down malicious attackers who log into amachine and attempt to do something nasty like llup hard disks, crash running programs, etc. Unfor-tunately, username information is generally onlyavailable in certain log messages.

Domain Domain could refer to Windows domain or thedomain name portion of an email address, etc.

Email Address An email address may be present in SMTP/POPmessages.

The Mechanics of Normalization

Normalization in the case of log data is sometimesreferred to as parsing. The most common wayparsing is performed is through regular expres-sions. It allows for the most exible processingpossible. Care must be taken, however, to ensureyou create regular expressions which perform as

optimal as possible. Jeffrey E. F. Friedl

s bookMastering Regular Expressions, 2nd Edition(www.oreilly.com/catalog/regex2) is one of thebest resources for learning everything you need toknow about regular expressions.

The following sections provide actual parsing ex-amples. Even though Perl is used with the exam-ples, the concept would be the same regardless ofthe language or technique used.

UNIX Login When someone logs into a UNIX system usingSSH, this activity is recorded in the form of a logmessage. The following is an example Syslogmessage from a Linux machine:



22/57

Jan 10 14:57:29 server login(pam_unix)[2653]: session opened for user root by LOG-IN(uid=0)

The following Perl snippet shows how to process this log messages.

# Assume $message contains the message my($month, $day, $time, $host, $process,

$pid, $user, $rest) = $message =~ m/^(\w{3}) (\d{2}) (\d{2}:\d{2}:\d{2}) (.*?) (.*?)\[(\d+)\]: session opened for

user (\w+) by (.*?)$/g;

Here I grab month, day, time, host, process, pid (process id), user, and rest.

Cisco PIX Cisco PIX is Cisco s rewall product. It is capable of generating an extensive amount of valuable log mes-sages. Here are two such examples.

Jan 11 2006 10:00:03: %PIX-4-106023: Deny tcp src dmz:10.0.3.4/36637 dstoutside:10.0.2.2/25 by access-group \"in_dmz\"

Jan 11 2006 16:21:25: %PIX-6-106015: Deny TCP (no connection) from 10.3.3.15/80 to10.21.1.3/41063 flags SYN ACK on interface outside

This illustrates and interesting point. Both of theseare TCP deny messages, yet neither of them haveexactly the same format. This is a common prob-

lem in the real world and you need to be aware ofit. So let s look at how we might parse these.

# Assume $message contains the message my($month, $day, $year, $time, $type, $protocol) = $message =~ /^(\w{3}) (\d{2})

(\d{4}) (\d+:\d+:\d+):.*?: (.*?) (.*?) /g;

my($srcIp, $srcPort, $dstIp, $dstPort) = $message =~/(\d+\.\d+\.\d+\.\d+)\/(\d+)/gc;

I use two regular expressions to process the mes-sage. The rst regular expression gets the month,day, year, and time. Notice how the PIX mes-sages, unlike the UNIX message, has a year aspart of the date. Next I grab the type of event andprotocol. The type for both messages is Deny.Protocol is the same for both, but one is upper-case and the other is lowercase.

The second regular expression obtains the sourceand destination IP addresses and ports. I used the/gc modier, which allows Perl

s regular expres-sion engine to keep matching after /g fails. This iswhy I only specify a single pattern but I am able toget both IP addresses and both ports. Unfortu-nately, this will not work for many PIX messages.Some PIX messages will contain NAT addresses,too, which would cause our regular expression tomiss some or all of the information we need.

It s worth while at this point to discuss some thingsthat can go wrong with parsing. The PIX type (inthis case Deny) just happens to be in the sameplace in both messages. The regular expression I

wrote takes advantage of this fact. However, thereare many PIX messages that either have no typeor have the type string some place else in themessage. Your parsing should be able to handlethese conditions.

One approach is to create message-specic pars-ers. Notice how both messages have a token

which looks like %PIX-X-YYYYYY. Each PIX mes-sage has this token. The six-digit number is aunique identier for the event. Fortunately Ciscodocuments the format for all PIX messages andthey do so by the version of PIX.

Analyzing Events for Threats

Richard Bejtlich has written that the process bywhich the intentions and capabilities of threats areassessed is called threat analysis. I really like this

denition because it simply makes sense.

It should be noted that threat analysis cannot re-place the human factor in network security. Threatanalysis techniques provide better information on



23/57

what is going on in an environment, but an analystor administrator may still need to investigate fur-ther by ring up a packet capture tool, inspect OSlogs, etc., to make a determination that somethingmalicious really happened. Let s now look at tech-niques used for analyzing log data for potentialthreats.

Correlation

Correlation is the buzzword used in conjunctionwith threat analysis. It is often times touted as apanacea. In reality it isn t. What people generallymean when they mention correlation is: looking atall events in aggregate and grouping similar thingstogether to see if they relate to each other in inter-esting ways. It is the aggregation of log data to asingle place which allows correlation to take place.In the context of log data, we want to group similarevents together to discover possible malicious be-

havior. The real goal of correlation is to provide

better intelligence to administrators so they caninvestigate possibly dubious behavior.

Some people may say why should I care aboutcorrelation since rewall, IPS, and other systemscan aid in the detection and prevention of mali-cious behavior? This is certainly true to a certainextent. But what about the situation where a cer-tain IPS event combined with a certain OS eventconstitutes a higher-level threat which cannot bedetected solely by the IPS event or OS event?This is where correlation is benecial.

Correlation, using log data, is generally accom-plished via two methods: real-time (or near real-time) and non-real-time. Generally speaking, real-time relies on rules to specify what things to lookfor; non-real-time analysis deals with methodswhich can either supplement real-time analysis orstand alone in its own right, but are generally done

after the fact, i.e. forensically. These topics willnow be discussed.

Real-time Analysis

Rules are simply a prescribed set of checks orconditions whose entire truth value is evaluated.There are many ways rules can be written. Forexample, you may use the if-then structure of aprogramming language to embed rules in applica-tion code. Or you way wish to purchase a stand-alone rule engine which evaluates events fed to itwith an externally created rule set.

The purpose of this section is simply to presentthe idea of rule-based analysis. A few pseudo-code examples will be provided to drive home thisanalysis technique.

Recall that our denition of correlation stipulatesthat we group events together. The rst kind ofgrouping involves events from the same devicetype. Consider the following example:

Event A = acceptEvent B = deny

IF (10 Bs are followed by 1 A)THENPossible scan success

This rule works on two rewall events. Event A is anormalized event with taxonomy accept. Event Bis also normalized to deny.

The rule itself is looking for 10 B s followed by asingle A, in other words 10 accepts followed by asingle deny. This form of analysis is useful, but wealso want to group across event types.

For example:

Event A = portscanEvent B = accept

IF (As destination IP == Bs destinationIP) AND(As destination port == Bs destination

port)THENPossible destination breach due to openfirewall rule

Here Event A is a normalized IPS port scan event.Event B is a rewall accept. The rule uses destina-tion IP address and port elds in Events A and B toidentify a possible scan breach due to an openrewall hole.



24/57

Non-real-time Analysis

The techniques discussed in this section can beused to supplement real-time analysis or asstandalone methods. It is the nature of thesemethods that they operate over data which hasbeen accumulated for some time period.

Statistical Methods

Statistical methods can be employed to discoverinteresting things that rules generally cannot. Afew of these methods are discussed now.

Baseline A baseline is simply a set of data which representsnormal values. Trends can be discovered byevaluating new data against an established base-line.

Thresholds and Windows With windowing we wish to discover possible du-bious behavior that occurs outside of a certainrange, e.g. time of day, etc. For example, you maywant to know any time your router s congurationchanges outside of scheduled maintenance win-dows. The comparison of some event against asimple baseline is considered thresholding. Forexample, you may wish to know when a user failsto login ve times in a row. The value ve is athreshold.

Never Before Seen (NBS) Detection NBS detection deals with determining when some-thing hasn t happened before. Marcus Ranum sNBS (www.ranum.com/security/computer_security/code) tool can aid in this endeavor.

Other Statistical Techniques The following statistical techniques can be usedby themselves or in conjunction with the othermethods discussed in this section.

Standard Deviation Moving Averages

Ratios Range Interquartile Range Variance Analysis

Vulnerability Correlation Vulnerability correlation is the use of vulnerabilityassessment data to determine how valid an eventis. For example, if your IPS detects that an at-tempt has been made to exploit some sendmailvulnerability on a Windows server, which isn t run-ning sendmail, then you can disregard this eventor set its priority lower.

External Data Correlation This technique is similar to vulnerability correlationin that it uses external data sources to validateevents. For example, you may take in a feed fromsome security Web site and correlate an increasein a certain type of event with the outbreak of

some new worm.

Final Thoughts

Never underestimate the value in learning fromothers. Here s a brief list of books I have founduseful for helping me think about threat analysis:

Building a Logging Infrastructure(www.sage.org/pubs/12_logging/) by Tina Bird andAbe Singer

Schaum s Outline of Statistics by Murray R.

Spiegel and Larry J. Stephens The Tao of Network Security Monitoring: BeyondIntrusion Detection by Richard Bejtlich Extrusion Detection: Security Monitoring for In-ternal Intrusions by Richard Bejtlich.

Threat Analysis Example

A walk through of how real-time analysis can beused to aid in threat analysis is probably in order.Let s say the following events show up in/var/log/auth.log on a Unix system:

Dec 20 15:00:35 host PAM_unix[11351]: check pass; user unknownDec 20 15:00:35 host PAM_unix[11351]: authentication failure; (uid=0) -> **un-known** for ftp serviceDec 20 15:00:43 host PAM_unix[11351]: check pass; user unknownDec 20 15:00:43 host PAM_unix[11351]: authentication failure; (uid=0) -> **un-known** for ftp service

But moments before this the following showed up in /var/log/daemon.log :

Dec 20 15:00:30 host in.ftpd[11351]: connect from 10.0.3.4



25/57

To understand what is going on here we need tohave access to messages written to both log les.But more importantly than this is that we have theproper knowledge and experience to know whatconstitutes a possible attack, break in, etc.

We rst need to normalize the events. Beyondthis, however, it is important to properly map themessages to a taxonomy. For example, the rstmessage in /var/log/auth.log could be classi-ed as credential-check . The second messagecould be auth-failure . We notice that the thirdand fourth messages are really the same as therst and second messages respectively. Finally,the message from /var/log/daemon.log couldbe classied as access-attempt .

The next step is to write a rule to combine or cor-relate these normalized events. Writing a rule to

catch such behavior is tricky. In the case of ourFTPD messages, we see that the process ID (thenumber between the square brackets, [11351]) isthe same. This is because the in.ftpd process(in /var/log/daemon.log ) spawned a sub-process to handle the incoming connection. Weknow the process name and the process ID be-cause of the string in.ftpd[11351]. Notice, how-ever, that /var/log/auth.log shows the sameprocess ID but different process names (PAM_u-nix[11351]). This means when crafting a rule to tiethese events together we will need to make surethe process ID is used to tie together these mes-sages into a single session. So how would we de-tect something like this? A rule can be used tospecify how to determine that something has hap-pened and then what to do about it. We can ex-press it in pseudo-English with the following:

Event A = credential-checkEvent B = auth-failureEvent C = access-attempt

IF((B.count >= 2 ) AND(A.processID == B.processID) AND (B.processID == C.processID) AND(TimeDifferenceBetween(A,B,C) = 2) AND(A.srcIp == B.srcIp) AND (B.srcIp == C.srcIp) AND(TimeDifferenceBetween(A,B,C)


26/57

Commercial Solutions

Security Information Management (SIM) and Se-curity Event Manage (SEM) companies havesprung up over the last ve or so years to meetthe growing emphasis on log data analysis. SIMsoftware is delivered either as an appliance orshrink-wrapped software and utilizes a three-tieredarchitecture. The rst tier is a collector which isused to gather and normalize log data. The sec-ond tier is an analysis and storage system. Thestorage system is used to store events in long-term storage. This is done for forensic purposesas well as historical reporting. The console admin-istrators use to view events is the third and nallayer. One advantage of commercial vendors isthey tend to support a wide variety of devise andsystems out of the box. This makes your job eas-ier, i.e. because you don t have to spend time wor-rying about log data format issues.

Some of the bigger players in the SIM market in-clude:

Intellitactics (www.intellitactics.com) ArcSight (www.arcsight.com) netForensics (www.netforensics.com) GuardedNet (www.guraded.net) LogLogic (www.loglogic.com) LogRhythm (www.logrhythm.com)

Open Source Solutions

In the open source realm you have a lot of differ-ent tools to choose from. These tools range fromSyslog daemon replacements to log analysis pro-grams to full-blown SIM solutions. The followinglist is by no means exhaustive. It is simply meantto give you a feel for what sort of open sourcetools are out there.

syslog-ng

syslog-ng (www.balabit.com/products/syslog_ng)is a replacement for the standard UNIX Syslogdaemon. It is unique in that it is highly congurableand supports TCP transmission and extensive l-tering. It also supports customizable data miningand analysis features.

High Performance Syslog

The San Diego Supercomputer Center (SDSC)maintains a high-performance Syslog replacement

(security.sdsc.edu/software/sdsc-syslog/). Itboasts the following features:

Input modules for socket, UDP network connec-tions, TCP/BEEP, etc. Message switch to perform log message routing Multiple output modules for UDP, TCP/BEEP,"syslog classic" les, structured les

Multi-processing - handles more input syslog

steams, provides better scalability Support for draft standards such as "syslog-reliable" (RFC 3195, syslog messages overBEEP).

Simple Event Correlator (SEC)

SEC (estpak.ee/~risto/sec/) is a Perl-based sys-tem for analyzing data via several different meth-ods like regular les, named pipes, and standardinput. It uses rules to instruct it how to analyze and

react to events. External programs or analysismodules can be spawned from rules for greaterexibility.

Open Source Security Information Manage-ment (OSSIM)

OSSIM (ossim.net) is an open source SIM toolthat aims to be as feature-rich as its commercialcounterparts. It supports normalization, correla-tion, and risk assessment among many other fea-tures.

LogAnalysis.Org

LogAnalysis.Org (loganalysis.org) is not an opensource tool, but is a resource for all things relatedto log data analysis. It includes mailing lists and acomprehensive resource library on log data analy-sis tools, systems, software, etc. This site shouldbe one you visit to learn more about what opensource (and commercial) tools are available.

Conclusion

Threat analysis involves gathering, normalizing,and analyzing log data.

The end goal is to correlate data from manysources to better detect dubious behavior, whichmay not be detected by a single source, and alerton it. Administrators and analysts use alerts to de-termine if a given situation requires further investi-gation or not.

Kevin J. Schmidt is a senior software developer at SecureWorks, Inc. (secureworks.com), an Atlanta, Georgiabased MSSP. He is a member of a dedicated software team who take security, threat analysis and correlationvery seriously. This team provides software tools and systems which allows the Security Operation Center(SOC) to ensure SecureWorks clients are well protected 24X7X365.



27/57

InfoSec World 20063 April-5 April 2006 Disney s Coronado Spring Resort, Orlando, USAwww.misti.com

Infosecurity Europe 200625 April-27 April 2006 Olympia, London, UKwww.infosec.co.uk

RSA Conference 200613 February-17 February 2006 McEnery Convention Center, San Jose, CA, USA2005.rsaconference.com/us/C4P06/

Black Hat Europe 2006 Briengs and Training28 February-3 March 2006 Grand Hotel Krasnapolsky, Amsterdam, the Nether-landshttp://blackhat.com

LayerOne 2006

22 April-23 April 2006 Pasadena Hilton, Los Angeles, California, USAwww.layerone.info/

InfoSeCon 20068 May-10 May 2006Hotel Croatia, Dubrovnik, Croatiawww.infosecon.org

iTrust 200616 May-19 May 2006 Piza, Italywww.iit.cnr.it/iTrust2006/index.htm

Eurocrypt 200628 May-1 June 2006 St. Petersburg, Russiawww.iacr.org/conferences/eurocrypt2006/



28/57

What follows are some of the biggest events of 2005 with comments by:

Bruce Schneier - CTO of Counterpane Internet Security and acclaimed se-curity technologist and author. Howard Schmidt - former Special Adviser for Cyberspace Security for theWhite House, was CSO of eBay and Microsoft. Dr. Gerhard Eschelbeck - CTO of Webroot, named one of Infoworld's 25Most Inuential CTO's in 2003 and 2004. Mikko H. Hyppnen - Chief Research Ofcer at F-Secure. Fyodor - acclaimed security researcher and author of nmap. Ira Winkler - author of "Spies Among Us".An increasing number of techniques and easieraccess to computer equipment enhances theknowledge of both the malicious users and thesecurity professionals. However, it always seemsthat the "dark side" has much more free time ontheir hands since they tend to be ahead of the in-dustry.

Windows users are ghting with all sorts of mal-ware and security holes year after year. "I know itis popular to blame Microsoft for security woes,but they really deserve it this year! From remotelyexploitable vulnerabilities in Windows core serv-ices like UPnP and MSDTC, to a barrage of se-vere IE vulnerabilities, Windows users were con-stantly under attack." said Fyodor. "Microsoftspends many marketing dollars touting their secu-rity, but they need to start backing this up with ac-tion." he added.

The media tends to spread FUD by writing storieswhere large percentages of Internet users are veryafraid to shop online, we see exceptionally bignumbers when it comes to identity theft and yet e-commerce is booming and everyone and their

mother are getting gifts for the holidays online.The truth is always somewhere in between - de-spite the media trying to publish "horror stories" inorder to increase readership.

When it comes to all these reports where we seeaverage users very paranoid Ira Winkler has an-other view on the situation: "As time goes on,people will only be more comfortable with comput-ers. They will use it for more and more applica-tions. Security is at best an afterthought, and themore ubiquitous the computer becomes, the lessthey will consider the threats involved with its us-age."

Every year analysts inform us that this year wasthe worst yet and that a bleak digital future awaits

just around the corner. I tend to be skeptical aboutsuch predictions so I'm going to let you decidewhat to make of 2005. The events depicted in this

article all left a mark on both the industry and theusers. As repercussions go, some are evident andsome will be seen in the upcoming months. All inall, it was an interesting year.



29/57

Not a great year for credit cards

CardSystems processed payments for multiplecredit card companies. In May the company suf-fered the largest data security breach to datewhen around 40 million credit card numbers werestolen. The affected companies were MasterCard,Visa, American Express and Discover.

The problem was not only in the fact that the inci-dent occurred in the rst place but in the fact thatCardSystems did not comply with the regulationsthat their customers had in place. Audits showedthat they weren't as secure as they had to be. Theresult? Not surprisingly, even after complying tothe demands of increased security the companywas sold in October.

Bruce Schneier comments on this situation: "Everycredit card company is terried that people will re-duce their credit card usage. They're worried thatall of this press about stolen personal data, as wellas actual identity theft and other types of creditcard fraud, will scare shoppers off the Internet.They're worried about how their brands are per-ceived by the public. And they don't want someidiot company ruining their reputations by expos-ing 40 million cardholders to the risk of fraud."

Howard Schmidt said: "I think that anytime abreach of security of any size, especially one that

contains consumer private information causes ex-ecutives to ask "Can this happen to us and if sohow do we x it?" With the compliance issues ta-king a bigger role in corporate governance worldwide I would expect this to continue to be a boardroom discussion which will increase security."

And just in time for the holidays, Guidance Soft-ware (a self-proclaimed leader in incident re-sponse and computer forensics) suffered a breachthat will probably get a lot of people red. The in-cident during which some 3,800 customer creditcard numbers have been stolen, occurred on No-vember 25th but wasn't discovered until December7th. Did Guidance Software contact their custom-ers immediately? No. In the age where even chil-dren use mobile phones, IM and e-mail, theychose to send out notices of the breaches viaregular mail. Why? They claim people change e-mail addresses too frequently while the location ofthe ofces stays the same. I guess they thinkthese companies also change their phone num-bers all the time. Even if they do, shouldn't they

keep an up-to-date database with contact informa-tion?

To make things even worse, the company storedcustomer records in databases that were not en-

crypted and if that wasn't bad enough they alsokept the three digit Card Value Verication (CVV)numbers despite the guidelines by MasterCardand Visa that prohibit the storage of the CVVnumbers after a transaction and require the data-bases to be encrypted. The company says theydidn't know these numbers were stored for alonger period of time. I don't know if this makesthings better or worse.

Rootkits go mainstream

On October 31st Mark Russinovich posted an en-try on his blog entitled "Sony, Rootkits and DigitalRights Management Gone Too Far" that sparked amedia frenzy. Russinovich discovered that Sonywas using a rootkit as a method of control forsome of their CDs.

Sony got under much re as both privacy advo-cates and the users were raging against such vilecontrol actions and started boycotting certain Sonytitles, bad reviews were starting to show up onshopping sites and Amazon.com contacted theircustomers and offered them a complete refund ifthey returned the "infected" CDs. At least now thepublic is much more aware of certain problems.

Assorted malware

Not surprisingly this year had thousands of pages

lled with reports of various types of malwarewrecking havoc. So, are things getting any betteror just worse when it comes to virus outbreaks? "Itseems better. In 2003 we had tons of large out-breaks. In 2004 we saw some. This year only ahandful." says Mikko H. Hyppnen. "However, thetransformation from hobbyist virus writers to pro-fessionals also means more targeted attacks.These stay under the radar and don't becomefront page news - the criminals don't want to endup on the front page. We're seeing less outbreaks- so the situation seems to be getting better. It'sactually getting worse" he adds.

The most talked about virus of 2005 is certainlySober which caused a lot of problems and dis-rupted e-mail trafc for both MSN and Hotmail. F-Secure cracked the code and learned how Soberactivates. More than 20 variants of the virus havebeen found since October.

Other "popular" viruses in 2005 were Za.D andseveral variants of Zotob. When it comes to num-

bers, Hyppnen says the situation seems better:"All of these cases were smaller than cases likethe Mydoom/Bagle/Netsky war or the Sasser out-break from 2004."



30/57

Is there any hope in sight for 2006? "We're afraidof several things. Automatic mobile phone viruses.WLAN viruses. Skype viruses. I'm afraid it's notgoing to get better" according to Hyppnen.

Ciscogate

A lot of media attention was on the Black Hat Con-ference in Las Vegas this year. Michael Lynn, aresearcher working for ISS, did a presentation ona security hole in Cisco's IOS. Since Cisco threat-ened to shut down the conference Lynn rst re-signed from his position at Internet Security Sys-tems but wouldn't back down from the presenta-tion. What was a sad example of bad PR is every-thing that Cisco did. They instructed the peoplebehind the conference to get the promotional ma-terial and rip out the pages containing the slides ofLynn's presentation. So 1984 of them.

Cisco claims the presentation was dangeroussince it contains information on IOS and that theinformation was obtained illegally. Lynn found theproblem while working for ISS under specic in-structions to reverse-engineer the Cisco operatingsystem. He noted that the release of informationwas necessary since the IOS source code wasalready stolen earlier and it was only a matter oftime before someone decided to engage in someillegal activity. To get his perspective on things Isuggest you read this interview at Wired(elfURL.com/141z).

I'm positive that if they hadn't made all this noise,much less interest would have surrounded thispresentation. Immediately after the conferenceCisco released a patch for the IOS vulnerability.Lynn was hired by Juniper Networks in November.

Common Vulnerability Scoring System allows IT managers to create a single standardizedand prioritized ranking of security vulnerabilities across multiple vendors and platforms.

Common Vulnerability Scoring System(CVSS)

The issues surrounding the scoring of vulnerabili-ties got a possible solution this year with the crea-tion of the CVSS ( rst.org/cvss/ ). Gerhard Es-chelbeck said: "CVSS allows IT managers to cre-ate a single standardized and prioritized ranking ofsecurity vulnerabilities across multiple vendorsand platforms. CVSS is relevant in all stages ofthe vulnerability lifecycle, from the time a vulner-ability is identied by a researcher to the time avulnerability needs patching within an enterprise.For computing the vulnerability score, CVSS con-siders not only the technical aspects of a vulner-ability, but also how widely a vulnerable technol-ogy is deployed within an enterprise. A multitudeof vendors have indicated their commitment to

support CVSS in their products, and enterprisesare currently introducing CVSS into their environ-ments. By utilizing this scoring system, organiza-tions can patch critical issues quicker, spendingless resources on low priority issues."

Phishing

This is the year when phishing stopped being con-fused with shing and basically everyone knowswhat it means. Howard Schmidt comments: "Iagree that the number of phishing scams is on theincrease all indications are that LESS people arefalling for the scams. In some cases the interna-tional law enforcement have made arrests of peo-ple who are running these scams which has

proven that people can be caught and will beprosecuted. Also, MANY technology steps havebeen taken to reduce the likelihood one will evensee the phishing emails. There was a period oftime where some people were scared away fromonline commerce because of phishing but all indi-cations that there is limited "if any" impact at all."

Opinions on top problems in 2005

The security related event that dened 2005

Fyodor: "I think the continued rise of botnets hasbeen the year's greatest trend. The Honeynet Pro-

ject has been researching these and identiedmore than 100 botnets containing at least 226,585unique compromised hosts. Much of this excellentwork was done by the German Honeynet Project,

and we released a paper. In the months sincethen, we've seen several people arrested for run-ning botnets of more than 100,000 machineseach. Increasingly, they have been using these forextortion: threatening crippling distributed denial ofservice (DDoS) attacks unless companies pay up."

The biggest online security threats in 2005

Gerhard Eschelbeck: "The security researchcommunity as well as vendors identify and publishon average 40 new security vulnerabilities perweek. These vulnerabilities provide a multitude ofavenues for attack and originate from many differ-ent areas. Incorrectly congured systems, un-changed default passwords, product aws, ormissing security patches are among the most



31/57

typical causes. Security vulnerabilities linger andconsequently create a breeding ground for at-tacks, leading to security breaches. Improperlypatched systems not only endanger themselves,but also put other users at risk.

It is not the security holes and vulnerabilities weknow about and can respond to that are the big-gest concern it is the security holes and vulner-abilities we do not know about and will be the tar-get of tomorrow."

Final thoughts

Was it worse than 2004? Better? Or did it justevolve to what you expected a year ago? It de-pends on how you look at it, how much inuence acertain event had on your job, on your home com-puter or on your

insecure mag 5

Documents