DOCSLIB.ORG

Procedures for Handling Security Patches

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Procedures for Handling Security Patches Archived NIST Technical Series Publication The attached publication has been archived (withdrawn), and is provided solely for historical purposes. It may have been superseded by another publication (indicated below). Archived Publication Series/Number: NIST Special Publication 800-40 Title: Procedures for Handling Security Patches Publication Date(s): August 2002 Withdrawal Date: November 2005 Withdrawal Note: SP 800-40 is superseded in its entirety by the publication of SP 800-40 Version 2.0 (November 2005). Superseding Publication(s) The attached publication has been superseded by the following publication(s): Series/Number: NIST Special Publication 800-40 Version 2.0 Title: Creating a Patch and Vulnerability Management Program Author(s): Peter Mell, Tiffany Bergeron, David Henning Publication Date(s): November 2005 URL/DOI: http://dx.doi.org/10.6028/NIST.SP.800-40ver2 Additional Information (if applicable) Contact: Computer Security Division (Information Technology Lab) Latest revision of the SP 800-40 Revision 3 (as of August 7, 2015) attached publication: Related information: http://csrc.nist.gov/ Withdrawal SP 800-40 Version 2 provides basic guidance on establishing patch announcement (link): management programs, and guidance to organizations with legacy needs. Date updated: ƵŐƵƐƚϳ, 2015 NIST Special Publication 800-40 Procedures for Handling Security Patches Recommendations of the National Institute of Standards and Technology Peter Mell and Miles C. Tracy NIST Special Publication 800-40 Procedures for Handling Security Patches Recommendations of the National Institute of Standards and Technology Peter Mell and Miles C. Tracy C O M P U T E R S E C U R I T Y Computer Security Division Information Technology Laboratory National Institute of Standards and Technology Gaithersburg, MD 20899-8930 August 2002 U.S. Department of Commerce Donald L. Evans, Secretary Technology Administration Phillip J. Bond, Under Secretary for Technology National Institute of Standards and Technology Arden L. Bement, Jr., Director ii Reports on Computer Systems Technology The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the Nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analysis to advance the development and productive use of information technology. ITL’s responsibilities include the development of technical, physical, administrative, and management standards and guidelines for the cost-effective security and privacy of sensitive unclassified information in Federal computer systems. This Special Publication 800-series reports on ITL’s research, guidance, and outreach efforts in computer security and its collaborative activities with industry, government, and academic organizations. National Institute of Standards and Technology Special Publication 800-40 Natl. Inst. Stand. Technol. Spec. Publ. 800-40, xx pages (Mon. 2002) CODEN: XXXXX Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately. Such identification is not intended to imply recommendation or endorsem ent by the National Institute of Standards and Technology, nor is it intended to imply that the entities, materials, or equipment are necessarily the best av ailable for the purpose. U.S. GOVERNMENT PRINTING OFFICE WASHINGTON: 2002 For sale by the Superintendent of Documents, U.S. Government Printing Office Internet: bookstore.gpo.gov — Phone: (202) 512-1800 — Fax: (202) 512-2250 Mail: Stop SSOP, Washington, DC 20402-0001 iii Executive Summary Timely patching is critical to maintain the operational availability, confidentiality, and integrity of information technology (IT) systems. However, failure to keep operating system and application software patched is the most common mistake made by IT professionals. New patches are released daily, and it is often difficult for even experienced system administrators to keep abreast of all the new patches. Vulnerabilities are weaknesses in software that can be exploited by a malicious entity to gain greater access and/or permission than it is authorized to have on a computer. Not all vulnerabilities have related patches; thus, system administrators must not only be aware of vulnerabilities and patches, but also mitigate “unpatched” vulnerabilities through other methods (e.g. workarounds, firewalls, and router access control lists). To help address this growing problem, we recommend that organizations have an explicit and documented patching and vulnerability policy and a systematic, accountable, and documented process for handling patches. This document provides principles and methodologies for accomplishing this. One of several possible techniques is through the creation of a patch and vulnerability group (PVG). This group would facilitate the identification and distribution of patches within the organization. Its duties should include: 1. Creating an organizational hardware and software inventory 2. Identifying newly discovered vulnerabilities and security patches 3. Prioritizing patch application 4. Creating an organization-specific patch database 5. Testing patches for functionality and security (to the degree that resources allow) 6. Distributing patch and vulnerability information to local administrators 7. Verifying patch installation through network and host vulnerability scanning 8. Training system administrators in the use of vulnerability databases 9. Deploying patches automatically (when applicable) 10. Configure Automatic Update of Applications (when applicable). If organizations use the PVG approach, this would not diminish the responsibility of all systems administrators to patch the systems under their control. Each systems administrator would: 1. Apply patches identified by the PVG 2. Test patches on the specific target systems 3. Identify patches and vulnerabilities associated with software not monitored by the PVG Besides creating a PVG, organizations should be aware that applying patches and mitigating vulnerabilities is not always a straightforward process. To help with this, our document covers areas such as prioritizing patches, obtaining patches, testing patches, and applying patches. iv Acknowledgements The authors, Peter Mell of NIST and Miles Tracy of Booz Allen Hamilton (BAH) wish to express their thanks to Timothy Grance, John Wack, and Murugiah Souppaya of NIST and Alexis Feringa, Jennifer Tracy, Jonathan Holleran, Mark McLarnon, and Brian Kim of BAH for their research, technical support, and written contributions to this document. The authors would also like to express their thanks to all those who contributed input during the public comment period. v Applying Security Patches – Draft 3.0– 06/06/2002 Table of Contents 1. INTRODUCTION ............................................................................................................ 1 1.1 AUTHORITY ...................................................................................................................... 2 1.2 PURPOSE AND SCOPE........................................................................................................ 2 1.3 OBJECTIVE ........................................................................................................................ 3 1.4 AUDIENCE AND ASSUMPTIONS......................................................................................... 3 1.5 DOCUMENT STRUCTURE .................................................................................................. 3 2. CREATING AND IMPLEMENTING A PATCHING PROCESS.......................... 5 2.1 THE PATCH AND VULNERABILITY GROUP....................................................................... 5 2.2 SYSTEMS ADMINISTRATOR PATCHING RESPONSIBILITIES .............................................. 8 3. IDENTIFYING VULNERABILITIES AND APPLICABLE PATCHES ............ 10 3.1 VENDOR WEBSITES AND MAILING LISTS ...................................................................... 11 3.2 THIRD-PARTY WEBSITES ............................................................................................... 12 3.3 THIRD-PARTY MAILING LISTS AND NEWSGROUPS ....................................................... 13 3.4 VULNERABILITY SCANNERS........................................................................................... 14 3.5 VULNERABILITY DATABASES ........................................................................................ 16 3.6 OTHER NOTIFICATION TOOLS ........................................................................................ 17 4. GOVERNMENT VULNERABILITY IDENTIFICATION RESOURCES......... 19 4.1 CVE VULNERABILITY LIST............................................................................................ 19 4.2 NIST ICAT VULNERABILITY INDEX ............................................................................. 20 4.3 NATIONAL INFRASTRUCTURE PROTECTION CENTER .................................................... 21 4.4 CERT/CC....................................................................................................................... 23 4.5 FEDERAL COMPUTER INCIDENT RESPONSE CENTER (FEDCIRC)................................. 24 5. PATCHING PROCEDURES ....................................................................................... 26 5.1 PATCHING PRIORITIES ...................................................................................................
Load more

Recommended publications
  • Linux at 25 PETERHISTORY H
    Linux at 25 PETERHISTORY H. SALUS Peter H. Salus is the author of A n June 1991, at the USENIX conference in Nashville, BSD NET-2 was Quarter Century of UNIX (1994), announced. Two months later, on August 25, Linus Torvalds announced Casting the Net (1995), and The his new operating system on comp.os.minix. Today, Android, Google’s Daemon, the Gnu and the Penguin I (2008). [email protected] version of Linux, is used on over two billion smartphones and other appli- ances. In this article, I provide some history about the early years of Linux. Linus was born into the Swedish minority of Finland (about 5% of the five million Finns). He was a “math guy” throughout his schooling. Early on, he “inherited” a Commodore VIC- 20 (released in June 1980) from his grandfather; in 1987 he spent his savings on a Sinclair QL (released in January 1984, the “Quantum Leap,” with a Motorola 68008 running at 7.5 MHz and 128 kB of RAM, was intended for small businesses and the serious hobbyist). It ran Q-DOS, and it was what got Linus involved: One of the things I hated about the QL was that it had a read-only operating system. You couldn’t change things ... I bought a new assembler ... and an editor.... Both ... worked fine, but they were on the microdrives and couldn’t be put on the EEPROM. So I wrote my own editor and assembler and used them for all my programming. Both were written in assembly language, which is incredibly stupid by today’s standards.
    [Show full text]
  • (Un)Smashing the Stack
    Hello, Interwebs Hi, and thanks for reading this. As I mentioned a number of times during the talk this was one long, hard slog of a topic for me. My intent was not to duplicate existing research (Johnson and Silberman @ BHUS05, others), but to try to make this topic comprehensible for the typical security professional, who (GASP! SHOCK! HORROR!) may not necessarily grasp all the hairy internals of exploit development, but still is tasked with protecting systems. For the other 90% of us out there, our job is not to be leet, but rather not to get owned, something I hope to get a little bit better at every day. Since exploit mitigation is something that might bring us all a little bit closer to that, I wanted to explore the topic. Thanks much to BH for giving me the opportunity to do so, and to all of you for listening. Thanks also to all the amazing people working on these technologies, especially the PaX team and Hiroaki Etoh of IBM. -- shawn P.S. It’s actually Thompson that had the Phil Collins hair, not Ritchie. Sorry, Dennis. 28 75 6e 29 53 6d 61 73 68 69 6e 67 20 74 68 65 20 53 74 61 63 6b 0d 0a (un)Smashing the Stack 4f 76 65 72 66 6c 6f 77 73 2c 20 43 6f 75 6e 74 65 72 6d 65 61 73 75 72 65 73 20 61 6e 64 20 74 68 65 20 52 65 61 6c 20 57 6f 72 6c 64 Overflows, Countermeasures and the Real World Shawn Moyer :: Chief Researcher ---- SpearTip Technologies ---> blackhat [at] cipherpunx [dot] org Hey, who is this guy? ShawnM: InfoSec consultant, (quasi-) developer, husband, father, and raging paranoid with obsessive tendencies Chief Researcher at SpearTip Technologies Security Consultancy in Saint Louis, MO Forensics, Assessment, MSSP, network analysis Weddings, Funerals, Bar Mitzvahs I like unsolvable problems, so I’m mostly interested in defense.
    [Show full text]
  • Debian \ Amber \ Arco-Debian \ Arc-Live \ Aslinux \ Beatrix
    Debian \ Amber \ Arco-Debian \ Arc-Live \ ASLinux \ BeatriX \ BlackRhino \ BlankON \ Bluewall \ BOSS \ Canaima \ Clonezilla Live \ Conducit \ Corel \ Xandros \ DeadCD \ Olive \ DeMuDi \ \ 64Studio (64 Studio) \ DoudouLinux \ DRBL \ Elive \ Epidemic \ Estrella Roja \ Euronode \ GALPon MiniNo \ Gibraltar \ GNUGuitarINUX \ gnuLiNex \ \ Lihuen \ grml \ Guadalinex \ Impi \ Inquisitor \ Linux Mint Debian \ LliureX \ K-DEMar \ kademar \ Knoppix \ \ B2D \ \ Bioknoppix \ \ Damn Small Linux \ \ \ Hikarunix \ \ \ DSL-N \ \ \ Damn Vulnerable Linux \ \ Danix \ \ Feather \ \ INSERT \ \ Joatha \ \ Kaella \ \ Kanotix \ \ \ Auditor Security Linux \ \ \ Backtrack \ \ \ Parsix \ \ Kurumin \ \ \ Dizinha \ \ \ \ NeoDizinha \ \ \ \ Patinho Faminto \ \ \ Kalango \ \ \ Poseidon \ \ MAX \ \ Medialinux \ \ Mediainlinux \ \ ArtistX \ \ Morphix \ \ \ Aquamorph \ \ \ Dreamlinux \ \ \ Hiwix \ \ \ Hiweed \ \ \ \ Deepin \ \ \ ZoneCD \ \ Musix \ \ ParallelKnoppix \ \ Quantian \ \ Shabdix \ \ Symphony OS \ \ Whoppix \ \ WHAX \ LEAF \ Libranet \ Librassoc \ Lindows \ Linspire \ \ Freespire \ Liquid Lemur \ Matriux \ MEPIS \ SimplyMEPIS \ \ antiX \ \ \ Swift \ Metamorphose \ miniwoody \ Bonzai \ MoLinux \ \ Tirwal \ NepaLinux \ Nova \ Omoikane (Arma) \ OpenMediaVault \ OS2005 \ Maemo \ Meego Harmattan \ PelicanHPC \ Progeny \ Progress \ Proxmox \ PureOS \ Red Ribbon \ Resulinux \ Rxart \ SalineOS \ Semplice \ sidux \ aptosid \ \ siduction \ Skolelinux \ Snowlinux \ srvRX live \ Storm \ Tails \ ThinClientOS \ Trisquel \ Tuquito \ Ubuntu \ \ A/V \ \ AV \ \ Airinux \ \ Arabian
    [Show full text]
  • On the Quality of Exploit Code
    On the Quality of Exploit Code An Evaluation of Publicly Available Exploit Code, Hackers & Threats II, February 17, 2:00 PM, San Francisco, CA Ivan Arce, Core Security Technologies OUTLINE • Prologue: Context and definitions • Why exploit code? • Quality metrics • Examples • Epilogue: Future work PROLOGUE VULNERABILITIES & EXPLOITS Lets start by defining a common language • Vulnerability (noun) — “A flaw in a system that, if leveraged by an attacker, can potentially impact the security of said system” — Also: security bug, security flaw, security hole • Exploit (verb) — “To use or manipulate to one’s advantage” (Webster) — “A security hole or an instance of taking advantage of a security hole” EXPLOIT CODE Exploit code is not just “proof of concept” • Proof of Concept exploit - PoC (noun) — A software program or tool that exploits a vulnerability with the sole purpose of proving its existence. • Exploit Code (noun) — A software program or tool developed to exploit a vulnerability in order to accomplish a specific goal. — Possible goals: denial of service, arbitrary execution of code, etc An emerging role in the information security practice WHY TALK ABOUT EXPLOIT CODE? ANATOMY OF A REAL WORLD ATTACK The classic attack uses exploit code... ATTACKER Base Camp A target server is attacked and compromised The acquired server is used as vantage point to penetrate the corporate net Further attacks are performed as an internal user EXPLOIT CODE FUNCTIONALITY Exploit code becomes more sophisticated • Add a simple “listen shell” echo "ingreslock stream tcp nowait root /bin/sh sh -i" >>/tmp/bob ; /usr/sbin/inetd -s /tmp/bob &" • Add an account to the compromised system: echo "sys3:x:0:103::/:/bin/sh" >> /etc/passwd; echo "sys3:1WXmkX74Ws8fX/MFI3.j5HKahNqIQ0:12311:0:99999:7:::" >> /etc/shadow • Execute a “bind-shell” • Execute a “reverse shell” • Deploy and execute a multi-purpose agent Command shell, FTP, TFTP, IRC, “zombies”, snifers, rootkits..
    [Show full text]
  • Seth Arnold SARNOLD(7)
    SARNOLD(7) Seth Arnold SARNOLD(7) NAME Seth Arnold - sarnold(7) - +1-503-577-3453 - [email protected] SYNOPSIS I am versatile, able to quickly adapt to and excel in complex systems, especially those with subtle security and reliability problems. I enjoy talking with customers and users; my most recent supervisor noted I have a very good sense of the customer's voice. I support co-workers with enthusiasm, improving a team's productivity and morale. OPTIONS · 15 years experience developing software for Linux (Ubuntu, Debian, SuSE, Red Hat, Slackware, Caldera). · 6 years experience using OpenBSD, WinNT 4.0 / Win2K. · 4 years experience using NetWare 3.11, SCO 3.2.4.2, and SCO OpenServer 5.0. · Programming Languages: C, Ruby, Perl, Python, Java, Unix shell, SQL, HTML, LaTeX · Source code control systems: Git, Subversion, CVS, BitKeeper · Native English speaker; learning German I have expertise with Linux kernel internals, cryptography, security issues, software development and mainte- nance, and the TCP/IP family of protocols. I am familiar with the constraints and freedoms of open source licenses. I give confident, credible, and effective presentations about complex subjects. I participate in Free Software and Open Source communities. I have been part of the Open and Free Technology Community's NOC and a staff member on Freenode. HISTORY May 2005 { October 2007 Novell, Inc. / SuSE GmbH; Portland, OR, USA I joined the SuSE Labs research and development team when Novell acquired Immunix. My responsibilities at Novell / SuSE included: Software development Primary developer of AppArmor Mandatory Access Control policies for the SuSE Linux family of distribu- tions.
    [Show full text]
  • Linux As a Mature Digital Audio Workstation in Academic Electroacoustic Studios – Is Linux Ready for Prime Time?
    Linux as a Mature Digital Audio Workstation in Academic Electroacoustic Studios – Is Linux Ready for Prime Time? Ivica Ico Bukvic College-Conservatory of Music, University of Cincinnati [email protected] http://meowing.ccm.uc.edu/~ico/ Abstract members of the most prestigious top-10 chart. Linux is also used in a small but steadily growing number of multimedia GNU/Linux is an umbrella term that encompasses a consumer devices (Lionstracks Multimedia Station, revolutionary sociological and economical doctrine as well Hartman Neuron, Digeo’s Moxi) and handhelds (Sharp’s as now ubiquitous computer operating system and allied Zaurus). software that personifies this principle. Although Linux Through the comparably brisk advancements of the most quickly gained a strong following, its first attempt at prominent desktop environments (namely Gnome and K entering the consumer market was a disappointing flop Desktop Environment a.k.a. KDE) as well as the primarily due to the unrealistic corporate hype that accompanying software suite, Linux managed to carve out a ultimately backfired relegating Linux as a mere sub-par niche desktop market. Purportedly surpassing the Apple UNIX clone. Despite the initial commercial failure, Linux user-base, Linux now stands proud as the second most continued to evolve unabated by the corporate agenda. widespread desktop operating system in the World. Yet, Now, armed with proven stability, versatile software, and an apart from the boastful achievements in the various markets, unbeatable value Linux is ready to challenge, if not in the realm of sound production and audio editing its supersede the reigning champions of the desktop computer widespread acceptance has been conspicuously absent, or market.
    [Show full text]
  • Introduction to Free Software-SELF
    Introduction to Free Software Jordi Mas Hernández (coordinador) David Megías Jiménez (coordinador) Jesús M. González Barahona Joaquín Seoane Pascual Gregorio Robles XP07/M2101/02708 © FUOC • XP07/M2101/02708 Introduction to Free Software Jordi Mas Hernández David Megías Jiménez Jesús M. González Barahona Founding member of Softcatalà and Computer Science Engineer by the Professor in the Department of Tele- of the telematic network RedBBS. Universitat Autònoma de Barcelona matic Systems and Computation of He has worked as a consultant in (UAB, Spain). Master in Advanced the Rey Juan Carlos University (Ma- companies like Menta, Telépolis, Vo- Process Automatisation Techniques drid, Spain), where he coordinates dafone, Lotus, eresMas, Amena and by the UAB. PhD. in Computer Sci- the research group LibreSoft. His Terra España. ence by the UAB. Associate Profes- professional areas of interest include sor in the Computer Science, Multi- the study of free software develop- media and Telecommunication De- ment and the transfer of knowledge partment of the Universitat Oberta in this field to the industrial sector. de Catalunya (UOC, Spain) and Di- rector of the Master Programme in Free Software at the UOC. Joaquín Seoane Pascual Gregorio Robles PhD. Enigeer of Telecommunicati- Assistant professor in the Rey Juan ons in the Politechnical University Carlos University (Madrid, Spain), of Madrid (Spain). He has worked where he acquired his PhD. de- in the private sector and has al- gree in February 2006. Besides his so taught in the Computer Scien- teaching tasks, he researches free ce Faculty of that same university. software development from the Nowadays he is professor in the De- point of view of software enginee- partment of Telematic Systems En- ring, with special focus in quantitati- gineering, and has taught courses ve issues.
    [Show full text]
  • A Tamper-Resistant Framework for Unambiguous Detection of Attacks in User Space Using Process Monitors
    A Tamper-Resistant Framework for Unambiguous Detection of Attacks in User Space Using Process Monitors Ramkumar Chinchani and Shambhu Upadhyaya Kevin Kwiat Dept. of Computer Science and Engineering Air Force Research Laboratory University at Buffalo, SUNY 525 Brooks Road Amherst, NY 14260 Rome, NY 13441 Email: rc27, shambhu ¡ @cse.buffalo.edu Email: [email protected] Abstract with large projects [14], [9], [12], [11] suggest this. Maintaining high availability of these services is criti- Replication and redundancy techniques rely on the as- cal for the smooth functioning of any organization relying sumption that a majority of components are always safe and on those resources. These services can fail due to software voting is used to resolve any ambiguities. This assumption faults or attacks by intruders. Occurrence of faults can result may be unreasonable in the context of attacks and intru- in the unpredictable failure of the system. Intrusions are of- sions. An intruder could compromise any number of the ten likened to faults and successful attacks, like faults, leave available copies of a service resulting in a false sense of the system in an inconsistent or unusable state. security. The kernel based approaches have proven to be Fault detection and tolerance techniques have goals such quite effective but they cause performance impacts if any as dependability, reliability, availability, safety and per- code changes are in the critical path. In this paper, we pro- formability which are similar to the goals of intrusion pre- vide an alternate user space mechanism consisting of pro- vention and detection, and other security measures. How- cess monitors by which such user space daemons can be ever, the correspondence is not always one to one.
    [Show full text]
  • GNU/Linux Distro Timeline LEAF Version 10.9 Skolelinux Lindows Linspire Authors: A
    1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 Libranet Omoikane (Arma) Gibraltar GNU/Linux distro timeline LEAF Version 10.9 Skolelinux Lindows Linspire Authors: A. Lundqvist, D. Rodic - futurist.se/gldt Freespire Published under the GNU Free Documentation License MEPIS SimplyMEPIS Impi Guadalinex Clonezilla Live Edubuntu Xubuntu gNewSense Geubuntu OpenGEU Fluxbuntu Eeebuntu Aurora OS Zebuntu ZevenOS Maryan Qimo wattOS Element Jolicloud Ubuntu Netrunner Ylmf Lubuntu eBox Zentyal Ubuntu eee Easy Peasy CrunchBang gOS Kiwi Ubuntulite U-lite Linux Mint nUbuntu Kubuntu Ulteo MoLinux BlankOn Elive OS2005 Maemo Epidemic sidux PelicanHPC Inquisitor Canaima Debian Metamorphose Estrella Roja BOSS PureOS NepaLinux Tuquito Trisquel Resulinux BeatriX grml DeadCD Olive Bluewall ASLinux gnuLiNex DeMuDi Progeny Quantian DSL-N Damn Small Linux Hikarunix Damn Vulnerable Linux Danix Parsix Kanotix Auditor Security Linux Backtrack Bioknoppix Whoppix WHAX Symphony OS Knoppix Musix ParallelKnoppix Kaella Shabdix Feather KnoppMyth Aquamorph Dreamlinux Morphix ZoneCD Hiwix Hiweed Deepin Kalango Kurumin Poseidon Dizinha NeoDizinha Patinho Faminto Finnix Storm Corel Xandros Moblin MeeGo Bogus Trans-Ameritech Android Mini Monkey Tinfoil Hat Tiny Core Yggdrasil Linux Universe Midori Quirky TAMU DILINUX DOSLINUX Mamona Craftworks BluePoint Yoper MCC Interim Pardus Xdenu EnGarde Puppy Macpup SmoothWall GPL SmoothWall Express IPCop IPFire Beehive Paldo Source Mage Sorcerer Lunar eIT easyLinux GoboLinux GeeXboX Dragora
    [Show full text]
  • Meeting Critical Security Objectives with Security-Enhanced Linux
    Meeting Critical Security Objectives with Security-Enhanced Linux Peter A. Loscocco Information Assurance Research Group National Security Agency Co-author: Stephen D. Smalley, NAI Labs ■ Information Assurance Research Group ■ 1 Presentation Outline • Operating system security • The Flask architecture • Security-enhanced Linux • Example security server • Meeting critical security objectives • Future Direction ■ Information Assurance Research Group ■ 2 The Need for Secure OS • Increasing risk to valuable information • Dependence on OS protection mechanisms • Inadequacy of mainstream operating systems • Key missing feature: Mandatory Access Control (MAC) – Administratively-set security policy – Control over all subjects and objects in system – Decisions based on all security-relevant information ■ Information Assurance Research Group ■ 3 Why is DAC inadequate? • Decisions are only based on user identity and ownership • No protection against malicious software • Each user has complete discretion over his objects • Only two major categories of users: superuser and other • Many system services and privileged programs must run with coarse-grained privileges if not as superuser ■ Information Assurance Research Group ■ 4 What can MAC offer? • Strong separation of security domains • System and data integrity • Ability to limit program privileges • Protection against tamper and bypass • Processing pipelines guarantees • Authorization limits for legitimate users ■ Information Assurance Research Group ■ 5 MAC Implementation Issues • Must overcome
    [Show full text]
  • Counterpoint
    COVER STORY AppArmor vs. SELinux Novell and Red Hat security experts face off on AppArmor and SELinux COUNTERPOINT www.photocase.com Security Enhanced Linux or App Armor? Linux Magazine invited two well-known per- sonalities from Red Hat and Novell to debate the merits of their security systems. BY ACHIM LEITNER ovell and Red Hat are currently complexity of the resulting software. The doing battle to establish their re- Crispin Cowan, Novell Strict Policy that SELinux first provided Nspective products as competitive AppArmor[1] and SELinux have similar was found to be too strict to be usable, protection systems for Linux. Whereas goals of improving Linux security, but and so SELinux actively moved towards Red Hat adopted SELinux years ago, No- the goals differ in detail. AppArmor se- the AppArmor model with the Targeted vell introduced their AppArmor protec- cures individual applications against la- Policy, which simulates AppArmor’s tion system after acquiring Immunix. tent defects, and pro- Both systems are licensed under the tects an entire system Figure 1: Crispin Cowan: GPL, both aim to make Linux more se- against a particular “Simplicity is the soul of cure, and both give administrators more threat such as network security…SELinux seems to control over applications privileges. attack, by protecting all have been designed to meet We asked spokesmen from Novell and applications that face the NSA’s desire for arbi- Red Hat to explain why their security the network. SELinux trarily complex policy at the system is the best. Crispin Cowan, who instead sought to con- expense of usability…App- came to Novell from Immunix, will be trol the whole system, Armor was designed for talking first about the advantages of including assuring usability – to meet the needs AppArmor.
    [Show full text]
  • Sandboxing in Linux: from Smartphone to Cloud
    International Journal of Computer Applications (0975 - 8887) Volume 148 - No.8, August 2016 Sandboxing in Linux: From Smartphone to Cloud Imamjafar Borate R. K. Chavan CSE Department CSE Department SGGSIE&T Nanded SGGSIE&T Nanded India India ABSTRACT Desktops and Cloud Systems. [28, 55, 32] Traditional operating system security features provide security from most of the threats. In today’s internet world, Malicious and malfunctioning contents However, we need to add some extra defense to our systems. Sand- from the internet are regular problems for host systems such as boxing is an important security mechanism that lets programs and Smartphones, Desktops, Clouds etc. Almost all underlying oper- processes run in its isolated environment. Sandbox isolate running ating systems provide security from most of the threats. However, the program from host operating system and other running pro- we need to add some extra defense to our system. Sandboxing is grams on the system. Sandbox is an environment where the pro- an important security technique that lets programs run in its iso- gram can only access restricted set of resources. It is a way to re- lated environment. A sandbox is a tightly controlled environment strict a program’s ability to access resources. It is different from where programs run. It provides access to a tightly controlled set access control applied to running processes. Typically sandboxes of resources for programs, such as memory, scratch space on the only apply to programs explicitly launched into a sandbox, where disk, network access, and input devices. A program running in the as traditional access control methods apply to all programs.[34, 46] sandbox has just as many permissions as it needs without having The sandboxing is based on prevention instead of detection in the additional permissions that could be misused.
    [Show full text]