Vulnerability Protection A Buffer for Patching

Transcription

1 Vulnerability Prtectin A Buffer fr Patching A Lucid Security Technical White Paper February 2004 By Vikram Phatak, Chief Technlgy Officer Santsh Pawar, Vulnerability Analyst Lucid Security Crpratin 124 Suth Maple Street, Suite 200 Ambler, PA

2 Vulnerability Prtectin: A Buffer fr Patching Intrductin The purpse f this paper is t identify the prblem facing the netwrk security cmmunity regarding vulnerabilities and patches. It explains why current security technlgies such as firewalls, intrusin detectin and preventin systems, and autmated patch management slutins have failed in preventing vulnerabilities frm being explited. Finally an alternative apprach is prpsed that incrprates and builds upn existing security technlgies. A Strategic Prblem The standard dctrine fr netwrk security states that the best practice fr securing cmputer netwrks is a layered apprach. Hardening the perating systems and applicatins n cmputers by limiting the services ffered as well as installing the apprpriate patches is the first step. Setting up access cntrl t limit incming traffic bth at the bundary ruters as well as thrugh the use f firewalls cmes next. The final step invlves the use f intrusin detectin and preventin systems t identify attackers and prhibit their access t the netwrk. Unfrtunately, this strategy is failing and will sn be rendered inperable due t a flaw in ne f the assumptins n which it is based: patching cmputer systems. The rt f the prblem is the munting inability fr netwrk administratrs t keep cmputer systems patched. The issue that administratrs are facing is that the rate at which vendrs release patches fr vulnerabilities is increasing substantially, while the time span between the annuncement f new vulnerabilities and the release f explits t thse vulnerabilities is shrinking. The net effect is that system administratrs have mre patches t deply and less time t d s; rendering the current strategy f mitigating vulnerabilities an verwhelming task. Why Firewalls Fall Shrt Firewalls are designed t deny all traffic and nly allw certain traffic by explicit exceptin. This is a slid apprach, but ne that des nt extend well int the applicatin layer. One reasn this apprach des nt translate int the applicatin layer is that data paylad has ptentially infinite variatins, and therefre it is unrealistic t state that all data paylads are denied unless explicitly allwed. The allwed rule set wuld be infinitely lng. Based upn this reality, mst firewall vendrs have avided delving int the data paylad and have instead fcused upn the applicatin prtcl header. The prtcl headers have acceptable usage standards which can be translated int rules fr determining cmpliance which the firewall can then enfrce. The drawback t this apprach is that mst attacks actually adhere t prtcl standards as well as cmmnly accepted behavir, rendering the firewall blind t their malicius intent. There is strng evidence t supprt these facts. The mst undeniable evidence is that despite the widespread adptin f firewalls, attackers are getting int prtected netwrks bth directly and indirectly thrugh the use f wrms and trjans. They are getting thrugh firewalls via prts that have been left pen fr applicatins such as web, , DNS, and thers; expliting vulnerabilities in thse applicatins t which the firewall allws traffic Lucid Security Crpratin.

3 Vulnerability Prtectin: A Buffer fr Patching The Struggling IDS/IPS As mentined abve, mst explits tday adhere t bth prtcl standards and cmmnly accepted behavir; necessitating inspectin f the packet s data paylad in rder t determine whether r nt the cntent is malicius. This plays squarely int the strengths f Intrusin Detectin and Preventin Systems. IDS/IPS slutins are designed t allw all traffic and deny traffic by explicit exceptin. The benefit f this inverted lgic (cmpared t the firewall) is that IDS slutins can delve int the data paylad f packets in rder t identify traffic that shuld be denied since they have a finite list f traffic t prhibit. There are several prblems with intrusin detectin and preventin systems, hwever. Withut regular updates t their list f attacks t watch fr, they quickly fall ut f date and unknwingly allw attacks t cmprmise vulnerable systems. Even when their attack list is kept up t date, IDS/IPS slutins need t be tuned due t the excessive number f items cntained in their default list. An untuned IDS/IPS can suffer frm extremely pr perfrmance since each packet s data paylad cntents needs t be inspected and cmpared with each item in its list f attacks. And even if the IDS/IPS system emplys a state-machine-based parallel signature-matching engine (s that additinal rules d nt significantly impact perfrmance), it still falls prey t false psitives unless prperly tuned. With thusands f existing attacks and many thusand mre t cme, tuning has becme essential. When tuning, hwever, mst IDS/IPS administratrs ignre the firewall s cnfiguratin, r grup attacks based upn the service ffered. Fr example, an IDS/IPS is tuned t identify attacks n telnet (prt 23) even thugh the firewall nly allws http traffic (prt 80) r an IDS/IPS is tuned t watch fr http (prt 80) attacks and identifies IIS web server attacks when an Apache web server is in use. Bth are examples f false psitives results and nt nly create muntains f data fr an administratr t sift thrugh, they als negatively impact perfrmance. Finally, it takes a skilled individual t prperly tune an IDS/IPS and that skill cmmands a premium in tday s jb market. Als, the expense assciated with wning and prperly maintaining an IDS/IPS slutin shuld nt be verlked. Patches and Patching One slutin t this prblem is t patch the vulnerable system and clse the security hle. This strategy has been utilized successfully fr a number f years, yet it is nw becming impractical. There are mre patches that need t be deplyed The rate at which vendrs annunce new vulnerabilities and release patches fr thse vulnerabilities is increasing substantially. There is less time t deply a patch befre an explit is released The time span between the annuncement f new vulnerabilities and the release f explits t thse vulnerabilities is decreasing. There are mre cmputers that need t be patched The number f cmputers n the netwrk has increased. Deplying a patch can have an adverse effect n critical applicatins The perating systems f thse cmputers vary widely, as well as their installed patches and service packs (even within all Micrsft envirnments) Lucid Security Crpratin.

4 Vulnerability Prtectin: A Buffer fr Patching Applicatins are designed t wrk n specific builds f a given perating system. This means that when an perating system is patched, the sftware may r may nt functin prperly frm that pint frward. The applicatins themselves may cntain vulnerabilities which require patching; if the vulnerability in the applicatin is based upn the way it interacts with the perating system, the applicatin may n lnger functin nce it is patched. The X Factr: The Internet Explits are prpagating mre rapidly as mre and mre peple have access t infrmatin that was nce limited t small grups. Cmpanies are mre expsed tday than ever due t e-cmmerce applicatins which are integrated with back end business systems. Just as web services have becme prlific, s have rganizatins becme reliant n thse services. T Patch r Nt T Patch The fact is that nearly every applicatin and perating system running n a netwrk has t be patched at sme pint. Many applicatins and perating systems require a lt f patches ver time. Sme f thse patches themselves require patching. Patching requires sme thught and analysis, since patches have been knwn t break applicatins as well as intrduce new vulnerabilities themselves. The security update that was released by Micrsft in January 2001 t patch a security explit in Exchange 2000 server actually required a patching f its wn. Autmated patch management is a prmising, yet still develping technlgy. Sme f the issues that need t be addressed by an autmated patch management system are: What will be the affect f installing a patch n a system that s running a cmbinatin f these ther applicatins? (fr instance Apache and MySQL running n the same server) Is it pssible t rll back a patch if it creates prblems? The patch that was released last mnth was never applied. Can I install the latest patch directly withut installing the previus ne? Traditinally, netwrk administratrs are nt willing t install anything n a critical system that they dn t feel cnfident abut. As a result the idea f autmatically installing patches has had a difficult time gaining tractin. Autmated patch management systems will fail t realize their ptential as a tl until they can identify the varius applicatins n a given system and guarantee that the patches that are autmatically deplyed will nt cnflict with ther applicatins r the perating system, and that the system will functin in its intended way after applying a patch. The average enterprise deals with up t 80 patches a year, and a stunning 95% f attacks and security incursins take place after the patch intended t prevent them has been annunced says Keith Ferrell n (ref: Due t n fault f the administratr; many systems are left unpatched and vulnerable while he/she struggles t apply patches in a sane fashin Lucid Security Crpratin.

5 Vulnerability Prtectin: A Buffer fr Patching What is the slutin? It is clear that the administratr needs mre time t determine which systems need patching, which dn t, and which can t be patched. The answer is tw-fld: Additinal develpment in the autmated patch management field as well as a new type f prduct that can act as a buffer by stripping malicius cde frm relevant traffic. The first is simply a matter f time and mney. The secnd can be accmplished by adapting existing IDS/IPS technlgy s that it is a useful tl fr the purpse f Vulnerability Prtectin. Effective Vulnerability Prtectin requires an apprach that fcuses n what can harm a given system as ppsed t lking fr wh is attacking my netwrk (like an IDS). This shift in thinking abut attacks in terms f vectrs and layers is based upn certain assumptins: Nt every attack harms every system Cde Red nly effects Windws systems and des nt impact Linux r Unix systems. IIS web server Crss Site Scripting attacks d nt impact Apache web servers. Nt all traffic is allwed thrugh the firewall Telnet (prt 23) is nt allwed by the firewall; therefre attacks against telnet (prt 23) will nt get t the target system. The key t this new apprach hinges n a tw-step prcess that autmatically determines: 1) What resurces are expsed t attack and which are nt 2) and fr each expsed resurce (hst), what vulnerabilities exist and which d nt. This wuld enable the mdified Intrusin Preventin System t identify which traffic t watch; preventing relevant explits frm getting t a vulnerable target by drpping the malicius data paylad. The net effect f this slutin is that it wuld prtect vulnerable systems frm being explited until a patch is applied. Abut ipangel ipangel appraches Intrusin Preventin differently than ther IPS slutins by fcusing n vulnerability prtectin. ipangel actively discvers and guards security hles; buying administratrs the time t plan and test patches and upgrades. In additin, ipangel is easy t use and requires little maintenance due t its self-tuning and aut-update features. The result is that ipangel slves an imprtant prblem while making Intrusin Preventin practical and affrdable fr a wide variety f custmers. Abut Lucid Security Headquartered in suburban Philadelphia, Lucid Security is a leading develper f next generatin security sftware that defends netwrks against attacks; prviding real-time vulnerability prtectin. Lucid Security s prduct, ipangel, is affrdable, easy t use, and prvides unmatched prtectin against attacks. In December 2003, ipangel was named Best Emerging Technlgy by Infrmatin Security Magazine Lucid Security Crpratin.