 |
|
Softpanorama |
May the source be with you, but remember the KISS principle ;-)
|
|
"Just as in the private sector, many federal agencies are reluctant to make the investments required in this area [of computer security] because of limited budgets, lack of direction and prioritization from senior officials, and general ignorance of the threat."
|
As of today the quote above stands the test of the time. Limited budgets are not longer the case in government. But "lack of direction and prioritization from senior officials" as well as "ignorance" (not so much "ignorance of the threat" but general ignorance ;-) are still here.
Businesses are more conservative and more realistic. Even as mass media fret over everything from hacker threats to cyber terrorism, the majority of companies is reluctant to spend money on security. And probably rightly so, because the return on investment is questionable and in the current economic climate the money are tight. A full 40% of IT managers recently surveyed by IDC cite IT security as their No. 1 priority. But less than 10% want to increase their security budgets ;-) How can this be?
The answer is that despite the risks at the end of the day additional security measures does not save money or generate revenue. Moreover often they are useless or even harmful. 80% of the enterprise security is actually a byproduct of a sound architecture and other technical decisions. It looks like security is better dealt with on this level than increasing security staff or by paying top bucks to some Fortune 100 company for sending a couple of clueless or semi-clueless consultants who supposedly are able to fix the problems that the latest attack revealed in the infrastructure they do not understand :-).
In case of consultant it also can lead to the decision to buy and install YAPUST ("yet another pretty useless security tool"). For example network IDS are fashionable now, but in most cases they produce so many false positives that after a while all warnings they are safely ignored or most useful (but noisy) rules are simply disabled ;-). Network IPS are mostly harmful and better be avoided unless the organization has top guns in networking group (in this case the question arise why they are needed ?). And senior administration still believes that IDS/IPS is in place and "the company is protected" ... See also "Softpanorama laws of security"
Actually semi-forgotten network IDS sensor is pretty benign example.
"Security Uber Alles" types can do a lot of damage to productivity without any
real improvements in security. IPS is only one of many way to harm the
company. In some companies hidden sadists somehow
became firewall administrators :-(.
Still, there are a few bright spots. The first one is
open source security tools. They are free
and some of them are as good or even better/more flexible than their commercial counterparts.
Not to deploy them in some cases is as close to negligence as one can get.
Second is security training with some useful WEB resources both government
(CERT,
NIST National Checklist
Program,
NSA) and non-government
(SANS,
SecurityFocus (hosts BugTrack list),
searchSecurity, etc).
Security certification also might be useful if you consider it not an end in itself but as a first step. For additional references see also other pages on this site including my Solaris Security page and Security certification page. IS-security training for system and network administrators can substantially boost the level of security of IS without or with very little additional spending. That's why it's surprising to see that relatively few companies are making investments to ensure that their IT teams know how to secure their network and technology infrastructures, despite all the attention surrounding security since Sept 11. That's why I created this page. Not that I have any illusions about any particular Security certification ;-).
According to the InformationWeek Global Information Security Survey, fielded by Pricewaterhouse Coopers, only 27% of U.S. companies have conducted security training for system and network administrators. That statistic is only slightly better than the one in four companies around the globe (the study reached 8,100 people in 50 countries) that have conducted such training. That's why self-education is so important.
Dr. Nikolai Bezroukov
|
30814 CVE Vulnerabilities 160 Checklists 141 US-CERT Alerts 2192 US-CERT Vuln Notes 3259 OVAL Queries
Draft SP 800-123, Guide to General Server Security, is available for public comment.
This document is intended to assist organizations in installing, configuring, and maintaining secure servers. SP 800-123 makes recommendations for securing a server's operating system and server software, as well as maintaining the server's secure configuration through application of appropriate patches and upgrades, security testing, log monitoring, and backups of data and operating system files.
The document addresses common servers that use general operating systems and are deployed in both outward-facing and inward-facing locations.
Comments need to be received by June 13, 2008.
Posted by kdawson on Wednesday April 23, @08:03AM
from the stand-and-identify dept. captcha_fun writes"Researchers at Penn State have developed a patent-pending image-based CAPTCHA technology for next-generation computer authentication. A user is asked to pass two tests: (1) click the geometric center of an image within a composite image, and (2) annotate an image using a word selected from a list. These images shown to the users have fake colors, textures, and edges, based on a sequence of randomly-generated parameters. Computer vision and recognition algorithms, such as alipr, rely on original colors, textures, and shapes in order to interpret the semantic content of an image. Because of the endowed power of imagination, even without the correct color, texture, and shape information, humans can still pass the tests with ease. Until computers can 'imagine' what is missing from an image, robotic programs will be unable to pass these tests. The system is called IMAGINATION and you can try it out."
This sounds promising given how broken current CAPTCHA technology is.
December 28, 2007 | NIST
NIST announces the release of Special Publication 800-53, Revision 2, Recommended Security Controls for Federal Information Systems. This special update incorporates guidance on appropriate safeguards and countermeasures for federal industrial control systems.
NIST’s Computer Security Division (Information Technology Laboratory) and Intelligent Systems Division (Manufacturing Engineering Laboratory), in collaboration with the Department of Homeland Security and organizations within the federal government that own, operate, and maintain industrial control systems, developed the necessary industrial control system augmentations and interpretations for the security controls, control enhancements, and supplemental guidance in Special Publication 800-53.
The industrial control system augmentations and interpretations for Special Publication 800-53 will facilitate the employment of appropriate safeguards and countermeasures for these specialized information systems that are part of the critical infrastructure of the United States.
The changes to Special Publication 800-53, Revision 1 in updating to Revision 2, include:
- a new Appendix I, Industrial Control Systems;
- an updated low security control baseline with the addition of security control CP-4, Contingency Plan Testing and Exercises; and
- an updated Appendix A, References Section.
The regular two-year update to Special Publication 800-53 will occur, as previously scheduled, in December 2008.
Draft SP 800-115, Technical Guide to Information Security Testing, is available for public comment. It seeks to assist organizations in planning and conducting technical information security testing, analyzing findings, and developing mitigation strategies. The publication provides practical recommendations for designing, implementing, and maintaining technical information security testing processes and procedures. SP 800-115 provides an overview of key elements of security testing, with an emphasis on technical testing techniques, the benefits and limitations of each technique, and recommendations for their use. Draft SP 800-115 is intended to replace SP 800-42, Guideline on Network Security Testing, which was released in 2003. Please visit the drafts page to learn how to submit comments to this draft document.
Adobe PDF (762 KB)
NIST's Computer Security Division has completed the initial public draft of Special Publication 800-80, Guide for Developing Performance Metrics for Information Security.
This guide is intended to assist organizations in developing metrics for an information security program. The methodology links information security program performance to agency performance. It leverages agency-level strategic planning processes and uses security controls from NIST SP 800-53, Recommended Security Controls for Federal Information Systems, to characterize security performance. To facilitate the development and implementation of information security performance metrics, the guide provides templates, including at least one candidate metric for each of the security control families described in NIST SP 800-53.
Adobe pdf (1,153 KB)
The NIST Computer Security Division is pleased to announce for your review and comment draft NIST Special Publication 800-26 Revision 1, Guide for Information Security Program Assessments and System Reporting Form. This draft document brings the assessment process up to date with key standards and guidelines developed by NIST.
Please provide comments by October 17, 2005 to sec-report@nist.gov. Comment period has been closed.
Computer Security: Art and Science. Matt Bishop, University of California - Davis ISBN: 0-201-44099-7 Addison Wesley: 2003 Cloth; 1136 pp. Published: 12/02/2002 US: $74.99
Expensive and dull book that can be used for torturing CS students :-). Attempt of broad coverage that definitely might help to killing any interest to computer security for most students...
Description Table of Contents Appropriate Courses Preface Sample Chapter About the Author(s)
... Updated Open Source Security Testing Manual Available By Paul Desmond. Version 2
of the Open Source Security Testing Methodology Manual (OSSTMM) was posted on ...
Recently, notifications started going out regarding a number of critical vulnerabilities in BIND, the software that powers the majority of the name servers on the Internet. In an attempt to convey the importance of these holes, many computer security experts were referring to this as the next major Internet bug -- drawing near-panicked comparisons to the massive, widespread BIND attacks of 1998. Many even went to the point of proclaiming that this incident will be the next great Internet-crippling bug.
To an extent, the concern over the announcement of the BIND vulnerabilities is valid. The Internet works as we know it because when we type a site into our browsers or email clients, name servers translate that site's name into numbers that can be routed. Without functioning name servers, the Internet becomes a much different world. Imagine having to identify friends by their telephone numbers rather than by their names. The vulnerabilities that were released at the end of January could allow attackers to take down or take control of the majority of name servers on the Internet. It was imperative that server administrators be notified as soon as possible and alerted as to the crucial nature of this problem. They were notified promptly.
However, by the time the advisories reached many security experts and members of the press, the discussions had taken on a tone of hysteria. Before the advisory was made public, the root name servers -- those that disseminate name information to the rest of the Internet's name servers -- had already been patched. It remains for system administrators on the rest of the Internet to upgrade their servers ... and many large providers and corporations reacted quickly and appropriately. At this point, the majority of Internet backbone providers have upgraded their servers.
The possibility that these vulnerabilities will take down the entire Internet is an unlikely one at best. To prove how drastic a bug this is, many experts pointed to the 1998 BIND hole, which was indeed one of the most persistently exploited vulnerabilities on the Net for a long, long time. What the experts fail to mention, however, is that at the time, the Red Hat distribution of Linux set up BIND without prompting at installation. Many Linux users didn't know they were running BIND, so they didn't think they needed to apply the patch when it became available. It's no longer the case that Red Hat installs BIND automatically; there will be fewer servers running BIND unnecessarily or unknowingly, so this vulnerability will be less prevalent. Despite their widespread effect, the great BIND attacks of 1998 didn't cause the Internet to shut down. The Internet continued along just fine, except for a few hundred compromised servers and defaced Web pages, which hardly affect the functionality of the Internet as a whole.
Another incident that experts and journalists have used to display how overwhelming this set of vulnerabilities could be occurred in late January when Microsoft's Web pages were unavailable for several hours due to a DNS problem (http://abcnews.go.com/sections/scitech/DailyNews/microsoft010125.html). While it's true that this is an example of a Website being inaccessible due to a problem with name servers, the instance is otherwise unrelated to the BIND problem. Microsoft's name servers don't run BIND, and by all indications the troubles they suffered two weeks ago were in no way similar to those caused by the holes in BIND. The constant comparison, clearly intended to heighten concern about the destruction of the entire Internet if name servers go down, smacks of sensationalism.
IBM DeveloperWorks/Linux Security: Improving the security of open UNIX platforms -- simple MD5 checking shell script(bash) by Igor Maximov (uniug@cris.net). Nothing special.
[Dec 28, 2000] NSA Security-Enhanced Linux
The has a well-defined architecture (named Flask) for flexible mandatory access controls that has been experimentally validated through several prototype systems (DTMach, DTOS, and Flask). The architecture provides clean separation of policy from enforcement, well-defined policy decision interfaces, flexibility in labeling and access decisions, support for policy changes, and fine-grained controls over the kernel abstractions. Detailed studies have been performed of the ability of the architecture to support a wide variety of security policies and are available on the DTOS and Flask web pages accessible via the Background page (http://www.nsa.gov/selinux/background.html). A published paper about the Flask architecture is also available on the Background page. The architecture and its implementation in Linux are described in detail in the documentation (http://www.nsa.gov/selinux/docs.html). RSBAC appears to have similar goals to the Security-Enhanced Linux. Like the Security-Enhanced Linux, it separates policy from enforcement and supports a variety of security policies. RSBAC uses a different architecture (the Generalized Framework for Access Control or GFAC) than the Security-Enhanced Linux, although the Flask paper notes that at the highest level of abstraction, the the Flask architecture is consistent with the GFAC. However, the GFAC does not seem to fully address the issue of policy changes and revocation, as discussed in the Flask paper. RSBAC also differs in the specifics of its policy interfaces and its controls, but a careful evaluation of the significance of these differences has not been performed.
SecurityPortal - Ask Buffy Apache Security
I am trying to implement security on the Apache Server 1.3.12 running on a Linux Red Hat 6.2. Are there any good docs or how-tos on this subject?
Aejaz Sheriff
Very few security problems exist with the Apache server itself. Having said that, however, I suggest that you upgrade to Apache 1.3.14, which solves some security issues. For online documentation of the Apache server the following URLs are excellent:
http://httpd.apache.org/docs/misc/security_tips.html
http://httpd.apache.org/docs/The majority of Web-based security problems come from poorly written CGI programs, online databases, and the like. Razvan Peteanu has written the following article:
http://securityportal.com/cover/coverstory20001030.html - Best Practices for Secure Web Development
And I highly recommend reading it.
Buffy (buffy@securityportal.com)
Who should own Apache? I have nobody as the owner and the group, but I'm not sure if this is safe or not.
Brad
The usual default for "owning" Apache is user and group root:
-rwxr-xr-x 1 root root 301820 Aug 23 13:45 /usr/sbin/httpdAs for who Apache runs as, this is usually the user and group "nobody" or "apache." In both cases, these groups are heavily restricted from accessing anything important, from the httpd.conf file:
#
# If you wish httpd to run as a different user or group, you must run
# httpd as root initially and it will switch.
#
# User/Group: The name (or #number) of the user/group to run httpd as.
# . On SCO (ODT 3) use "User nouser" and "Group nogroup".
# . On HPUX you may not be able to use shared memory as nobody, and the
# suggested workaround is to create a user www and use that user.
# NOTE that some kernels refuse to setgid(Group) or semctl(IPC_SET)
# when the value of (unsigned)Group is above 60000;
# don't use Group nobody on these systems!
#
User apache
Group apacheMost Linux distributions now have a special user and group called "apache" for running the Apache Web server. This user is locked out (no password), the home directory is usually the www root, and no command shell is available. This is slightly safer than using nobody because the "nobody" account may be used by other services. If an attacker manages to get privileges of "nobody" on the system, she may be able to elevate privileges using some other software. Segmenting "apache" with different users is a better strategy.
Buffy (buffy@securityportal.com)
Slashdot Theo de Raadt Respond
Q: Would you and/or other members of the OpenBSD coders consider writing a book on secure, bug-free coding and auditing? Most programming books feature sample code that is written for pedagogical purposes. Quite often this runs contrary to how secure code should be written, leaving a gap in many a programmers knowledge. A book on audinting and how to avoid security pitfalls when coding would also make your life easier - less code to audit for OpenBSD, and more time top concentrate on nifty new features!!!
Theo:
There is perhaps a split between the two issues you bring up. On the one side is secure coding, as in code written to be secure by the original author(s). On the other side, auditing, which is where an outsider (or an insider) later on goes and tries to clean up the mess which remains. And there is always a mess. Perhaps part of the problem is that a huge gap lies between these two. In the end though, I think that a book on such a topic would probably have to repeat the same thing every second paragraph, throughout the book: Understand the interfaces which you are coding to! Understand the interfaces which you are coding to! Most of the security (or simply bug) issues we audited out of our source tree are just that. The programmer in question was a careless slob, not paying attention to the interface he was using. The repeated nature of the same classes of bugs throughout the source tree, also showed us that most programmers learn to code by (bad) examples. A solid systems's approach should not be based on "but it works". Yet, time and time again, we see that for most people this is the case. They don't care about good software, only about "good enough" software. So the programmers can continue to make such mistakes. Thus, I do not feel all that excited about writing a book which would simply teach people that the devil is in the details. If they haven't figured it out by now, perhaps they should consider another occupation (one where they will cause less damage).
OpenBSD has a well deserved reputation for security "out of the box" and for the fact the inbuilt tools are as secure as they're ever likely to be. However, the Ports system is, perhaps, an example of where the secure approach currently has limitations - an installation of OpenBSD running popular third-party systems like INN can only be so secure because the auditing of INN, and other such software, is outside the scope of the BSD audit.
My question is, has the OpenBSD team ever proposed looking into how to create a 'secured ports' tree, or some other similar system, that would ensure that many of the applications people specifically want secure platforms like OpenBSD to run could be as trusted as the platforms themselves?
Theo:
We have our hands already pretty full, just researching new ideas in our main source tree, which is roughly 300MB in size. We also lightly involved ourselves in working with the XFree86 people a while back for some components there. Auditing the components outside of this becomes rather unwieldy. The difficulty lies not only in the volume of such code, but also in other issues. Sometimes communication with the maintainers of these other packages is difficult, for various reasons. Sometimes they are immediately turned off because we don't use the word Linux. Some of these portable software packages are by their nature never really going to approach the quality of regular system software, because they are so bulky.
But most importantly, please remember that we are also human beings, trying to live our lives in a pleasant way, and don't usually get all that excited about suddenly burning 800 hours in some disgusting piece of badly programmer trash which we can just avoid running. I suppose that quite often some of our auditors look at a piece of code and go "oh, wow, this is really bad", and then just avoid using it. I know that doesn't make you guys feel better, but what can we say...
With the release of SGI's B1 code, and the attempts by many U*ixen to secure their contents via capabilities, ACL's, etc, ad nausium, how is OpenBSD approaching the issue of resource control?
... ...
Theo:
On the first question, I think there is great confusion in
the land of Orange Book. Many people think that is about security. It is not.
Largely, those standards are about accountability in the face of threat. Which
really isn't about making systems secure. It's about knowing when your
system's security breaks down. Not quite the same thing. Please count the
commercially deployed C, B, or even A systems which are actually being used by
real people for real work, before foaming at the mouth about it all being "so
great". On the other hand, I think we wil see if some parts of that picture
actually start to show up in real systems, over time. By the way, I am
surprised to see you list ACLs, which don't really have anything to do with B1
systems.
Did the drive to audit code come from the need or
the design of BSD? Or was it initially a whim? More imporantly, where did you
learn it from? Is their some "mentor" you looked too for ridge design? I have
to admire your team's daunting code reviewing...I wonder if I'll ever have
that kind of meticulous coding nature.
Theo:
The auditing process developed out of a desire to improve the quality of our operating system. Once we started on it, it becomes fascinating, fun, and very nearly fanatical. About ten people worked together on it, basically teaching ourselves as things went along. We searched for basic source-code programmer mistakes and sloppiness, rather than "holes" or "bugs". We just kept recursing through the source tree everytime we found a sloppiness. Everytime we found a mistake a programmer made (such as using mktemp(3) in such a way that a filesystem race occurred), we would go throughout the source tree and fix ALL of them. Then when we fix that one, we would find some other basic mistake, and then fix ALL of them. Yes, it's a lot of work. But it has a serious payback. Can you imagine if a Boeing engineer didn't fix ALL of the occurrences of a wiring flaw? Why not at least try to engineer software in the same way?
Older news were moved to a separate file due to volume -- see OSS Security Chronicle
Top dozen
Non-government
SANS,
SecurityFocus (hosts BugTrack list),
Vendors:
Government:
***** CERT
***** NSA
**** CIAC United States Department of Energy's Computer Incident Advisory Capability.
*** NIH Unix Security -- NIH Security Resources -- links from National Institutes of Health. One of the best collection of security-related links. A vast collection of computer security resources, including documents, links to other web pages, and tools. Outdated...
Information about major open source security tools can be found at Softpanorama University Classic Open Source Unix Security Tools. Here are some archives that one might find useful:
**** BugTraq -- full-disclosure UNIX security mailing list.
www.eds.org -- The Security-Audit Mailing list FAQ
Improving the Security of Your UNIX System by David A. Curry.The "SRI Paper" that has been widely distributed around the Internet. It was written in 1990 and was a predecessor to the UNIX System Security book. David A. Curry is the author of UNIX Systems Programming for SVR4 and is also active tool developer (see his home page for the complete list). Among them are (description are borrowed from the author's page):
How to improve security on SunOS.4.1.3 -- outdated, but some information can be useful
Improving the Security of Your Site by Breaking Into it -- famous (now outdated) SATAN-related paper. Not that SATAN was better than other, but the name provoke a media craziness that gave the authors a lot of exposure...
1993: An Architectural Overview of UNIX Network Security February 18, 1993 Robert B. Reinhardt breinhar@access.digex.com
See also CIAC advisories below. Shorter tutorials are listed in Articles. There is also a useful list at http://secinf.net/unix_security/
King & Spalding Law -- discussion of the standard of "reasonable care".
Open Source Code And Information Security: A Legal Perspective
Reprinted from E-Commerce Law Journal, Volume 1, Number 7, pp. 20-21 (July, 2001) and Volume 1, Number 8, pp. 17-19 (August, 2001).
By: Brad Slutsky
There are many reasons why companies need to protect their information assets. These reasons include maintaining competitive advantages, ensuring the integrity, authenticity, and availability of information, adhering to confidentiality commitments or other legal requirements, complying with duties to shareholders, and complying with duties to third parties. Typically, companies' obligations to secure their information assets are measured against a standard of "reasonable care". This article addresses the question of whether companies exercise "reasonable care" when they use open source code software to implement business functions
This version and its subsequent outputs whether be it HTML, PDF or any other derivatives can be distributed under the same licensing terms and conditions as the orginal Securing and Optimizing Linux i.e. as set forth in the Open Publication License; V1.0 or later, the latest version is presently available at www.opencontent.org/openpub/.
Please note even if i madhusudan (Madhu "Maddy"),<needaguru@yahoo.com> hold the copyright for the XML source(Markup), you still need to get permission from Gerhard Mourani<gmourani@openna.com> the orginal author of Securing and Optmising Linux, to make any changes to the content of this book. Please do read the licensing terms and conditions detailed below for additional information
This material may be distributed only subject to the terms and conditions set forth in the Open Publication License; V1.0 or later, the latest version is presently available at www.opencontent.org/openpub/.
Distribution of substantively modified versions of this document is prohibited without the explicit permission of the copyright holder.
Distribution of the work or derivative of the work in any standard (paper) book form for commercial purposes is prohibited unless prior permission is obtained from the copyright holder.
Please note even if I, Gerhard Mourani have the copyright, I don't control commercial printing of the book. Please contact OpenDocs @www.opendocspublishing.com/ if you have questions concerning such matters.
The logos, trademarks, symbols used in this book are properties of their respective compan(y)ies.
NIST
CERT:
See also: SecurityPortal -- recent security news. Good...
Red Hat
Caldera's security page.
See also metalinks:
Security FAQs - the list of security-related FAQs maintained by Internet Security Systems, Inc.
Shadow Password HOWTO Note. caldera 1.3 and later install shadow password file by default. RedHat 6.0 and later also instell shadow password file.
[Nov.7,1998] www.eds.org -- The Security-Audit Mailing list FAQ
Frequently Asked Questions (FAQ)
Copyright © 1996-2007 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. Submit comments This document is an industrial compilation designed and created exclusively for educational use and is placed under the copyright of the Open Content License(OPL). Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
Standard disclaimer: The statements, views and opinions presented on this web page are those of the author and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.
Last modified: May 08, 2008
