Softpanorama (slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-)

Potemkin Villages of Computer Security

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. 

Security is the field that attracts energetic know-nothings. In some organization it also serves as a dumping ground for manages who proved to be useless in their assigned function but which for some reason are difficult or impossible to get rid off. I know a case when a female sociopath was exiled into security because organization was afraid that she would exploit her gender in lawsuit if she is terminated (and this idea of using fender as a bullet-proof west of by female sociopath is more common that people realize). So there is always a danger that security in a particular organization is just a window dressing performed by people more concerted with their career and unable and unwilling to understand real challenges for the organization and its IT systems.

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, because they know that lion share of this expedites will be waisted. 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 (being politically correct helps). But less than 10% want to increase their security budgets (being realistic does not hurt either ;-)

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 implemented measures are useless or even harmful (Potemkin villages)

We should understand that 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 should be controlled by a security group and not oriented on larger domain helping to troubleshoot problem arising in networking ?).  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

Old News ;-)

[Apr 14, 2009] Security Software Protection or Extortion by Rick Broida and Robert Vamosi,

April 13, 2009 | PC World

As the Conficker worm sprang to life on April 1, talk here at the PC World offices turned to some interesting debates about how best to protect PCs from malware threats. In recent weeks we've run several helpful articles offering tips, tricks, and insights to keep you and your PC safe from Conficker and other malware on the Internet. At the same time, a few among us have revealed that they don't run any security software at all on their own machines--and have no intention of starting now.

Shocking as it may sound, there are plenty of experienced, knowledgeable technophiles out there who laugh in the face of danger as they traipse unprotected through the wilds of the online world. Among them is our own Hassle-Free PC blogger Rick Broida, who prefers what he deems the relatively minor threat of malware to the annoyance of intrusive, nagging security apps.

Is he insane? Naïve? To find out, we gave Rick a podium to speak on behalf of those who shrug off the safety of antimalware suites, and to defend his point of view in a debate with security correspondent Robert Vamosi, who regularly reports on malware and other security threats for PC World's Business Center. Who's right? Who's nuts? You be the judge. Share your view in our comments section.

First up, Rick Broida presents his assertion that security suites are an unnecessary nuisance compared with the threat of malware.

Rick Broida: We Don't Need No Stinking Security Software

Security software is a scam. A rip-off. A waste of money, a pain in the neck, and a surefire way to bring even the speediest PC to a crawl. Half the time it seems to cause more problems than it solves. Oh, and one more thing: It's unnecessary.

Heresy? Crazy talk? Recipe for disaster? No, no, and no. For the past several years, I've run Windows (first XP, and now Vista) without a single byte of third-party security software. No ZoneAlarm. No Norton Internet Security. No Spyware Doctor. Not even freebie favorite Avast Home Edition. I use nothing but the tools built into Windows and a few tricks I've learned.

Want to know how much time I've spent cleaning up after viruses, spyware, rootkits, Trojan horses, keyloggers, and other security breaches? None. I'll say that again: none.

Maybe I'm asking for trouble (that sound you hear is fellow PC World columnist Rob Vamosi nodding furiously), but after years of infection-free computing, I have no qualms about my methods. Your mileage may vary, and I make no guarantees. But if you want to rid your system of pricey, performance-choking security software, read on.

My first line of defense is my router. Like most, it has a built-in firewall that blocks all unauthorized traffic and makes my network more or less invisible to the outside world. The second line of defense is Windows. XP, Vista, and 7 have built-in firewalls that help protect against "inside" attacks, such as if a friend were to come over with his spyware-infected laptop and connect to my network.

Of course, a router can't stop viruses, phishing, and other threats that arrive via e-mail. My secret weapon: Gmail. As I noted in "Use Gmail to Fight Spam," I route mail from my personal domain to my Gmail account. (From there, I can access messages on the Web or pull them down via Outlook.) Gmail does a phenomenal job filtering spam--much of which is malware. The service also performs a virus scan on all attachments.

By using Gmail as an intermediary between my POP3 server and my PC, I've kept not only spam at bay, but malware as well. I don't know whether Windows Live Mail and Yahoo Mail offer similar amenities, but for me Gmail is a slam-dunk solution. Even phishing messages are few and far between. Of course, as an educated user, I know better than to click a link in a message filled with scary come-ons ("Your account has been compromised!").

Speaking of phishing, the latest versions of Firefox and Internet Explorer offer robust antiphishing tools. Both will sound the alarm if I attempt to visit sites known to be fraudulent, meaning that even if I click something that looks like, say, a totally legit PayPal or eBay link, I'll get fair warning. And that's just the tip of the safe-browser iceberg: Firefox and IE are way more secure than in the old days. They block pop-ups, provide Web site ID checks, protect against malware installation, and so on.

As for other threats, I'm comfortable leaving my PC in the capable hands of Windows Defender. Microsoft's antispyware tool runs quietly and efficiently in the background. I "check in" once in a while to make sure it's active and up-to-date, but otherwise I never hear a peep from it.

Of course, that could mean bad stuff is slipping past Defender, right? Sure, it's possible. That's why I occasionally run a system scan using Ad-Aware or Malwarebytes Anti-Malware. (I'm not completely insane, after all.) So far, so good: The scans always come up empty.

Last but not least, I exercise common sense. I don't open e-mail attachments from people I don't know. I don't download files from disreputable or unknown sources. I don't visit Web sites that peddle gambling, porn, torrents, or "warez." (Yeah, I know, I'm boring.) In other words, I keep my Internet nose clean, which in turn keeps my PC clean.

At the same time, I make sure that automatic updates are turned on for Windows, my Web browsers, and any other software that gets patched regularly. And, perhaps most important of all, I rely on multiple backup methods just in case my system really is compromised somehow. For example, my Firefox bookmarks are all synced to the Web via Xmarks (formerly Foxmarks). I use the online-backup service Mozy to archive my critical documents and Outlook PST file. And drive-cloning utility Casper makes a weekly copy of my entire hard drive to a second drive.

Ladies and gentlemen of the security-software jury, I rest my case. My only real evidence is Exhibit A: me. After several years with XP and about six months with Vista, I'm still cruising along without a security care in the world. So, are you going to lock me up or accept me as your new messiah? Either way, I'm good.

Next up, security correspondent Robert Vamosi argues the opposing view.

[Feb 27, 2009] NIST Computer Security Division released 2 draft publications

(Special Publication & NIST Interagency Report) today and 1 Mark-up

Copy of Draft SP --

1. Mark-up copy of Draft Special Publication (SP) 800-53 Revision 3

2. Draft Special Publication 800-81 Revision 1

3. Draft NIST Interagency Report (IR) 7517

1. Draft SP 800-53 Rev. 3: Recommended Security Controls for Federal Information Systems and Organizations

The following document provides a line-by-line (mark-up copy)  comparison between SP 800-53, Revision 2 and Draft SP 800-53,   Revision 3. It should also be noted that the section of the  publication addressing scoping considerations for scalability, was  inadvertently omitted from the public draft and will be reinstated in the final publication.

URL: http://csrc.nist.gov/publications/PubsDrafts.html#800-53_Rev3

******

2. Draft SP 800-81 Rev. 1: Secure Domain Name System (DNS) Deployment Guide

NIST has drafted a new version of the document "Secure Domain Name  System (DNS) Deployment Guide (SP 800-81)". This document, after a  review and comment cycle will be published as NIST SP 800-81r1. There  will be two rounds of public comments and this is our posting for the first one. Federal agencies and private organizations as well as  individuals are invited to review the draft Guidelines and submit  comments to NIST by sending them to SecureDNS@nist.gov before March 31, 2009. Comments will be reviewed and posted on the CSRC website.

All comments will be analyzed, consolidated, and used in revising the draft Guidelines before final publication.

Reviewers of the draft revised Guidelines should note the following differences and additions:

(1) Updated Recommendations for all cryptographic operations  relating to digital signing of DNS records, verification of the signatures, Zone Transfer, Dynamic Updates, key Management and  Authenticated Denial of Existence.

(2) The additional IETF RFC documents that have formed the basis for the updated recommendations include: DNNSEC Operational Practices

(RFC 4641), Automated Updates for DNS Security (DNSSEC) Trust Anchors

(RFC 5011), DNS Security (DNSSEC) Hashed Authenticated Denial of

Existence (RFC 5155) and HMAC SHA TSIG Algorithm Identifiers (RFC 4635).

(3) The FIPS standards and NIST guidelines incorporated into the updated recommendations include: The Keyed-Hash Message Authentication Code (HMAC) (FIPS 198-1), Digital Signature Standard  (FIPS 186-3) and Recommendations for Key Management (SP 800-57P1 & SP  800-57P3).

(4) Illustration of Secure configuration examples using DNS

Software offering NSD, in addition to BIND.

URL: http://csrc.nist.gov/publications/PubsDrafts.html#800-81-rev1

[Feb 17, 2009] SP 800-53, Revision 3 DRAFT Recommended Security Controls for Federal Information Systems and Organizations

NIST announces the release of the Initial Public Draft (IPD) of Special Publication 800-53, Revision 3, Recommended Security Controls for Federal Information Systems and Organizations. This is the first major update of Special Publication 800-53 since its initial publication in December 2005. We have received excellent feedback from our customers during the past three years and have taken this opportunity to provide significant improvements to the security control catalog. In addition, the changing threat environment and growing sophistication of cyber attacks necessitated specific changes to the allocation of security controls and control enhancements in the low-impact, moderate-impact, and high-impact baselines. We also continue to work closely with the Department of Defense and the Office of the Director of National Intelligence under the auspices of the Committee on National Security Systems on the harmonization of security control specifications across the federal government. And lastly, we have added new security controls to address organization-wide security programs and introduced the concept of a security program plan to capture security program management requirements for organizations. The privacy-related material, originally scheduled to be included in Special Publication 800-53, Revision 3, will undergo a separate public review process in the near future and be incorporated into this publication, when completed. Comments will be accepted until March 27, 2009. Comments should be forwarded via email to sec-cert@nist.gov.

Draft-SP800-53 Rev.3.pdf (2,112 KB)

Cisco study IT security policies unfair - Network World by By Jim Duffy ,

A better term for "unfair security policy" would be a "bureaucratic perversion". The level of detachment from reality is really crucial and can vary from "no clue" to "parallel universe". But the key element is "not do any harm". That's why extremely unfair security policies are often called administrative fascism.

Unfair policies prompt most employees to break company IT security rules, and that could lead to lost customer data, a Cisco study found.

Cisco this week released a second set of findings from a global study on data leakage. The first part dealt with common employee data leakage risks and the potential impact on the collaborative workforce.

Part two deals with the ‘whys’ of behavior that raises the risk of corporate data leakage. More than half of the employees surveyed admitted that they do not always adhere to corporate security polices.

And when they don’t, it can lead to leakage of sensitive data. Of the IT respondents who dealt with employee policy violations, one in five reported that incidents resulted in lost customer data, according to the Cisco study.

The surveys were conducted of more than 2,000 employees and IT professionals in 10 countries: the United States, the United Kingdom, France, Germany, Italy, Japan, China, India, Australia and Brazil. They were executed by InsightExpress, a U.S.-based market research firm, and commissioned by Cisco.

The study found that the majority of employees believe their companies’ IT security policies are unfair. Indeed, surveyed employees said the top reason for non-compliance is the belief that policies do not align with the reality of what they need to do their jobs, according to Cisco.

The study found that the majority of employees in eight of 10 countries felt their company’s policies were unfair. Only employees in Germany and the United States did not agree.

In Germany, even though the majority of employees felt their companies’ policies were fair, more than half of them said they would break rules to complete their jobs, the study found. Of all the countries, France (84%) has the most employees who admitted defying policies, whether rarely or routinely.

In India, one in 10 employees admitted never or hardly ever abiding by corporate security policies. Overall, the study found that 77% of companies had security policies in place.

But defiance may not be intentional. IT and employees have a disconnect when it comes to policy and adherence awareness, the study found.

IT believes employees defy policies for a variety of reasons, from failing to grasp the magnitude of security risks to apathy; employees say they break them because they do not align with the ability to do their jobs.

But IT could do a better job communicating those policies. The study found that, depending on the country, the number of IT professionals who knew a policy existed was 20% to 30% higher than the number of employees.

Torvalds: Fed up with the security circus By Ellen Messmer

"A lot of activity [in various security camps] stems from public-relations posturing."  "What does the whole security labeling give you? Except for more fodder for either of the PR camps that I obviously think are both idiots pushing for their own agenda?" Torvalds says. "It just perpetrates that whole false mind-set" and is a waste of resources, he says.

Creator of the Linux kernel explains why he finds security people to be so anathema 08/14/2008 , Network World Linus Torvalds, creator of the Linux kernel, says he's fed up with what he sees as a "security circus" surrounding software vulnerabilities and how they're hyped by security people.

Torvalds explained his position in an e-mail exchange with Network World this week. He also expanded on critical comments he made last month that caused a stir in the IT industry.

Last month Torvalds stated in an online posting that "one reason I refuse to bother with the whole security circus is that I think it glorifies -- and thus encourages -- the wrong behavior. It makes 'heroes' out of security people, as if the people who don't just fix normal bugs aren't as important. In fact, all the boring normal bugs are way more important, just because there's a lot more of them."

Never one to mince words, Torvalds also lobbed a verbal charge at the OpenBSD community: "I think the OpenBSD crowd is a bunch of masturbating monkeys, in that they make such a big deal about concentrating on security to the point where they pretty much admit that nothing else matters to them."

This week Torvalds -- who says the only person involved in the OpenBSD community with whom he talked to about the "monkeys" barb found it funny -- acknowledges others probably found it offensive.

Via e-mail, he also explains why he finds security people to be so anathema.

Too often, so-called "security" is split into two camps: one that believes in nondisclosure of problems by hiding knowledge until a bug is fixed, and one that "revels in exposing vendor security holes because they see that as just another proof that the vendors are corrupt and crap, which admittedly mostly are," Torvalds states.

Torvalds went on to say he views both camps as "crazy."

"Both camps are whoring themselves out for their own reasons, and both camps point fingers at each other as a way to cement their own reason for existence," Torvalds asserts. He says a lot of activity in both camps stems from public-relations posturing.

He says neither camp is absolutely right in any event, and that a middle course, based on fixing things as early as possible without a lot of hype, is preferable.

"You need to fix things early, and that requires a certain level of disclosure for the developers," Torvalds states, adding, "You also don't need to make a big production out of it."

Torvalds also says he doesn't care for labeling updates and changes to Linux as a security fix in a security advisory.

"What does the whole security labeling give you? Except for more fodder for either of the PR camps that I obviously think are both idiots pushing for their own agenda?" Torvalds says. "It just perpetrates that whole false mind-set" and is a waste of resources, he says.

It's better to avoid sticking solely to either "full and immediate disclosure" or ignoring bugs that might embarrass vendors, he points out. "Any situation that allows the vendor to sit on the bug for weeks or months is unacceptable, as is any situation that makes it harder for people who find problems to talk to technical people."

Torvalds says he's skeptical about the value of synchronized releases among vendors that favor the idea of an embargo of software vulnerability information until a fix from a vendor is ready.

That process discourages thinking about design changes to make it harder to have security bugs, Torvalds says. "So, the whole 'embargoes are good' mentality is just corruption from the vendors," he states. "But on the other hand, disclosure should not be the goal."

"I don’t believe in either camp," Torvalds concludes. What he does favor is to "have a model where security is easier to do in the first place -- that is, the Unix model -- but make it easy for people to report bugs with no embargo, but privately."

He says the Linux kernel security list "is private" in the sense that "we don't need to leak things out further" to get some software issue fixed. He says the process allows, though doesn't encourage, a five-day embargo, and "even then, I will forward it to technical people on an 'as needed' basis, because even that embargo secrecy is not some insane absolute thing."

Comments

Some people ...By Anonymous on August 17, 2008, 2:31 pm

I can't believe the genius behind Linux referred to proactively fixing all bugs, regardless of security implications as "masturbating", since that's quite obviously...

[May 16, 2008] Linux gets security black eye

May 16, 2008

As has been widely reported, the maintainers of Debian's OpenSSL packages made some errors recently that have potentially compromised the security of any sshd-equipped system used remotely by Debian users. System administrators may wish to purge authorized_key files of public keys generated since 2006 by affected client machines.

Simply using a Debian-based machine to access a remote server via SSH would not be enough to put the machine at risk. However, if the user copied a public key generated on a Debian-based system to the remote server, for example to take advantage of the higher security offered by password-free logins, then the weak key could make the server susceptible to brute-force attacks, especially if the user's name is easily guessable.

Administrators of servers that run SSH may wish to go through users' authorized key files (typically ~/.ssh/authorized_keys), deleting any that may have been affected. A "detector" script, available here, appears to compare public key signatures against a list of just 262,800 entries. That in turn suggests that if the user's name is known, a brute force attack progressing at one guess per second could succeed within 73 hours (262,800 seconds).

A full explanation of the problem can be found here. In a nutshell, Debian's OpenSSL maintainers made some Debian-specific patches that, according to subscriber-only content at LWN.net, were aimed at fixing a memory mapping error that surfaced during testing with the valgrind utility. The unintended consequence was a crippling of the randomness of keys, making them predictable, and thus possible to guess using "brute-force" attacks. And unfortunately, the Debian maintainers failed to submit their patches upstream, and thus the problem did not surface until very recently (there's certainly a lesson to be learned, there). Not surprisingly, brute force attacks are way up this week, LWN.net also reported.

Users of Debian and Debian-based distributions such as Ubuntu should immediately upgrade the SSH software on their systems. The new ssh-client package will contain an "ssh-vulnkey" utility that, when run, checks the user's keys for the problem. Users should re-generate any affected keys as soon as possible.

Also possibly affected are "OpenVPN keys, DNSSEC keys, and key material for use in X.509 certificates and session keys used in SSL/TLS connections," though not apparently Keys generated with GnuPG or GNUTLS. More details can be found here (Debian resource page), as well as on this webpage, which also links to lists of common keys and brute-force scripts that boast of 20-minute typical break-in times.

-- Henry Kingman

[May 16, 2008] Practical Technology » Open-Source Security Idiots

The key mechanism is really alarming. 

Sometimes, people do such stupid things that words almost fail me. That’s the case with a Debian ‘improvement’ to OpenSSL that rendered this network security program next to useless in Debian, Ubuntu and other related Linux distributions.

OpenSSL is used to enable SSL (Secure Socket Layer) and TLS (Transport Layer Security) in Linux, Unix, Windows and many other operating systems. It also includes a general purpose cryptography library. OpenSSL is used not only in operating systems, but in numerous vital applications such as security for Apache Web servers, OpenVPN for virtual private networks, and in security appliances from companies like Check Point and Cisco.

Get the picture? OpenSSL isn’t just important, it’s vital, in network security. It’s quite possible that you’re running OpenSSL even if you don’t have a single Linux server within a mile of your company. It’s that widely used.

Now, OpenSSL itself is still fine. What’s anything but fine is any Linux, or Linux-powered device, that’s based on Debian Linux OpenSSL code from September 17th, 2006 until May 13, 2008.

What happened? This is where the idiot part comes in. Some so-called Debian developer decided to ‘fix’ OpenSSL because it was causing the Valgrind code analysis tool and IBM’s Rational Purify runtime debugging tool to produce warnings about uninitialized data in any code that was linked to OpenSSL. This ‘problem’ and its fix have been known for years. That didn’t stop our moronic developer from fixing it on his own by removing the code that enabled OpenSSL to generate truly random numbers..

After this ‘fix,’ OpenSSL on Debian systems could only use one of a range from 1 to 32,768—the number of possible Linux process identification numbers—as the ‘random’ number for its PRNG (Pseudo Random Number Generator). For cryptography purposes, a range of number like that is a bad joke. Anyone who knows anything about cracking can work up a routine to automatically bust it within a few hours.

Why didn’t the OpenSSL team catch this problem? They didn’t spot it because they didn’t see it. You see Debian developers have this cute habit of keeping their changes to themselves rather than passing them upstream to any program’s actual maintainers. Essentially, what Debian ends up doing is forking programs. There’s the Debian version and then there’s the real version.

Usually, it’s a difference that makes no difference. Sometimes, it just shows how pig-headed Debian developers can be. My favorite case of this is when they decided that rather than allow Mozilla to have control of the logo in the Firefox browser, because that wasn’t open enough according to the Debian Social Contract, they forked Firefox into their own version: Iceweasel.

That was just stupid. This is stupid and it’s put untold numbers of users at risk for security attacks.

First, the mistake itself was something that only a programming newbie would have made and I have no idea how this ever got passed by the Debian code maintainers. This is first-year programming assignment. “What is a random number generator and how do you make one?”

Then, insult to injury, because Debian never passed its ‘fix’ on to OpenSSL, the people who would have caught the problem at a glance, this sloppy, insecure mess has now been used on hundreds of thousands, if not millions, of servers, PCs, and appliances.

This isn’t just bad. This is Microsoft security bad.

Now, there’s a fix for Debian 4.0 Etch and its development builds. Ubuntu, which is based on Debian,, also have fixes for it. In Ubuntu, the versions that need patches are Ubuntu 7.04, Feisty; Ubuntu 7.10, Gutsy; the just released Ubuntu 8.04 LTS Hardy, and the developer builds of Ubuntu Intrepid Ibex.

Debian has also opened a site on how to rollover your insecure security keys to the better ones once you’ve installed the corrected software.. For more on how to fix your system, see Fixing Debian OpenSSL on my ComputerWorld blog, Cyber Cynic.

[May 14, 2008] Securing the net-the fruits of incompetence

[May 8, 2008]  National Checklist Program Repository

30814	CVE Vulnerabilities
160	Checklists
141	US-CERT Alerts
2192	US-CERT Vuln Notes
3259	OVAL Queries

[May 8, 2008] CWE - Common Weakness Enumeration

[May 8, 2008] http://csrc.nist.gov/publications/PubsDrafts.html#800-123

Reasonably well-written draft. Good strcture. Uneven coverage of topics (weak for "6.4.1. vulnerability scanning (question of false positives is swiped under the carpet. Good list of additional documents on page D2.

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.

[Apr 23, 2008] Semantic Gap

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.

 [Dec 28, 2007] http://csrc.nist.gov/publications/PubsSPs.html#800-53_Rev2 

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.

 [Nov 14, 2006] Configuring Java Applications to Use Solaris Security.

 [Nov 14, 2006] Draft SP 800-115, Technical Guide to Information Security Testing.

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.

[Nov 1, 2006] Operational Security Capabilities for IP Network Infrastructure (opsec) Charter

• Framework for Operational Security Capabilities for IP Network Infrastructure (41497 bytes)
• Security Best Practices Efforts and Documents (59589 bytes)
• Operational Security Current Practices (90632 bytes)
• Filtering and Rate Limiting Capabilities for IP Network Infrastructure (44099 bytes)
• Service Provider Infrastructure Security (38329 bytes)
• Routing Control Plane Security Capabilities (40431 bytes)
• Logging Capabilities for IP Network Infrastructure (44543 bytes)

[May 4, 2006] Draft Special Publication 800-80, Guide for Developing Performance Metrics for Information Security

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.

[Aug 15, 2005] Draft NIST Special Publication 800-26 Revision 1, Guide for Information Security Program Assessments and System Reporting Form

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.

[Sept 11, 2004] http://secinf.net/unix_security/ 

A useful list of security papers, tutorials and FAQs. Looks like created in 2002 and never updated since.  

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)

eSecurity Planet: Trends: Updated Open Source Security Testing ...

... Updated Open Source Security Testing Manual Available By Paul Desmond. Version 2
of the Open Source Security Testing Methodology Manual (OSSTMM) was posted on ...

The sky is not falling By Dev Zaborav

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/httpd

As 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 apache

Most 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

Recommended Links

Top dozen

1. ***** NIST  CSRC Home Page -- for a government site this is simply outstanding ;-)
   • NIST Computer Security DRAFT Publications
   • Role Based Access Control
   • CC - Common Criteria for Information Technology Security Evaluation
   • AEC
2. ***** CIAC -- provides vulnerabilities reports. The site also contains other materials but of much lesser quality and value.
3. ***** NSA -- NSA guidelines.  Not all of them are of equal quality (some can serve as an illustration of NSA degradation ;-) and some are outdated, but still ...
4. ****  The SANS Institute - A Cooperative Research and Education Organization -- contains top 20 list of vulnerabilities: questionable but still useful resource.
5. **** ISS security library.
   • Security FAQ Archive
   • UNIX Security Sites
6. **** Ronald L. Rivest Cryptography and Security -- nice collection of links
7. ***** Console/Firewall and Security  -- Freshmeat collection of tools
8. Security Focus - computer security information clearinghouse. Includes a calendar, free tools, forums, industry news, and a library.
9. ***+ Unix Security  --  NIH Security Resources -- links from National Institutes of Health. One of the best collection of security-related links. A decent collection of outdated computer security resources, including documents, links to other web pages, and tools. 
   • Alphabetized List of Public Domain Security Software
   • Network and Network Monitoring Software
10. *** Corporate Technologies Technical Library -- contains the list of free security software. Peter Galvin is chief technologist for Corporate Technologies, Inc.
11. *** http://www.cs.purdue.edu/coast/archive/data/category_index.html  -- COAST: outdated and badly maintained, but still sometimes useful
12. *** Root Shell -- Security and Exploit reference. A little bit speculative

Non-government

• SANS,

• SecurityFocus (hosts BugTrack list),

• searchSecurity

Vendors:

• [Sun] BigAdmin - DocsSecurity
• [Sun] Sun BluePrints OnLine - Security
• [OpenBSD] GeodSoft How-To Hardening OpenBSD Internet Servers Contents -- althouth this is about OpenBSD, the author really knows what he is talking about...
• [SUN] Technical Whitepapers and Publications by Lance Spitzner. Several papers really worth reading. The importance of honeypots is overblown...
• [Stokely Consulting]  Unix SysAdm Resources Firewalls & Unix Security

Government:

• ***** CERT

• ***** NSA

• **** AusCERT - Australian Computer Emergency Response Team
  • UNIX Security Checklist 
  • UNIX Security Checklist - The Essentials 

• **** 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...

University Centers

• COAST Hotlist Contents
  • LT 468 -- Internet and System Security -- links for the course 468 Dept. of Computer Sciences, Purdue University.
• Center for Secure Information Systems (CSIS) Home Page
• U.C. Davis Computer Security Group
• Computer Security Research Center, London School of Economics
• Information Security Research Centre
• http://www.isse.gmu.edu/~csis/
• http://www.cis.ohio-state.edu/hypertext/faq/usenet/computer-security/top.html

Archives

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:

• http://news.freshmeat.net/  -- Freshmeat quickfinder that allows you to find the latest versions of open source tools.
• http://appwatch.com/Linux  -- AppWatch does the same as freshmeat but in some cases more efficiently. 
• Cooker -- Another applications finder from Mandrakesoft.
• SuSE collection of security packages  Very well organized collection. Generally SUSE team is good in selecting packages. Red Hat is weaker.
  • SuSE Linux 6.3 (i386) - November 1999 -- the list of all packages
• http://www.linux-center.org -- The Linux Center

Usenet and lists

**** BugTraq -- full-disclosure UNIX security mailing list.

• Bugtraq Archives by thread
• Unix Security Software
• Unix securty mailing lists

RISKS-LIST RISKS-FORUM Digest

 www.eds.org -- The Security-Audit Mailing list FAQ

See Also

• IPsec protocol
• AV_links
• Red Hat Patches

History

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):

• Sendmail-CF -- "A fully complete, fairly powerful, and reasonably generic sendmail configuration file. Fully documented and much easier to understand than the stuff sendmail ships with",
• Bind  - "Patches to BIND 4.9.5-P1 to allow you to restrict the networks from which it will accept queries. This lets you run it on a firewall and know about both internal and external addresses, but protect the internal knowledge from the outside world".
• NFSwatch -- "A program to monitor Network File System traffic on a network, and summarize it in a number of different ways, including by client, by file system, by server, etc."

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

Philosophy

• Musings on open source security models -- a very important article that discuss an issue "Is open source software less secure that closed source (commercial) software ?
•  Under fire!  -- an important article on troyanization of open source[March 18, 1999]
•  Web security How much is enough (Datamation January 1997) -- the paper is weak but the idea is important[June 24, 1999]

Tutorials

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

   

• Securing and Optimizing Linux Copyright © 2000 by Gerhard Mourani and OpenDocs, LLC.  Should be read critically. Contains some questionable advice

  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.

• Cable & Wireless Security Engineering Web Security checklist
  • Protection of TCP-IP Based Network Elements -- good
• ***+ Linux Security HOWTO  by Kevin Fenzi, kevin@scrye.com v 0.9.5, 1 March 1998 (many mirrors, main site is Linux Security How-To). Part 5 is especially useful.
• *** Linux Administrators Security Guide (LASG) -- version 0.1.7 is poorly organized, pretty basic and does not contain a lot of useful information, but it can serve as a starting document; this document cannot replace printed books.
• ***+ FreeBSD Security How-To  -- good and documents sound security practice and hardening.
• IT Security Cookbook - Securing UNIX -- an online book
• ftp://ftp.cert.org/pub/tech_tips/root_compromise
• Protection of TCPIP Based Network Elements
• KerbNet Security Software
• OpenBSD Security
• [Nov.5,1998] A Security Primer for UNIX system administrators at MIT

Etc

• Linux Security WWW
• Digest - Security digest

Magazines

• 2600 Magazine
• Phrack magazine
• CU Digest
• internet-security.de
• SAFER
• Infowar
• HWA.hax0r.news
• Legions of the Underground
• ZDNET Cybercrime
• HELP! Net Security

Government Publications

NIST

• NIST Computer Security Special Publications

CIAC

• CIAC-2305_UNIX_Incident_Guide_How_to_Detect_an_Intrusion (pdf)
• CIAC 2308 Securing Internet Information Servers (html) -- December, 1994
• CIAC 2316 Securing X Windows (html) -- John Fisher August, 1995
• CIAC-2317_Windows_NT_Managers_Guide (pdf) (1/30/1998)
• CIAC-2318 IRC On Your Dime
• Securing Mail Servers To Block Third Party Mail Relay
• CIAC-2307_Electronic_Resources_for_Security_Related_Information.pdf

CERT:

• Unix Computer Security Checklist -- old, weak, outdated ;-)
• Unix Configuration Guidelines -- marginal value

Vendors Pages

See also: SecurityPortal -- recent security news. Good...

IBM Security home page

• IBM Computer security links -- good

Red Hat

• Red Hat Linux Links Administration Security
• Red Hat Linux Security List Archive

Caldera's security page.

• Secure Networks Incorporated
• www.securityserver.com
• UNIX security sites -- ISS security library
• MLD's Unix Security Page - Unix & TCP/IP Network Security Page. Focused on system penetration and system designs which lead to security failures. Software available online.

FAQs

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.

Security HOWTO

[Nov.7,1998] www.eds.org -- The Security-Audit Mailing list FAQ

Frequently Asked Questions (FAQ)

• The WWW Security FAQ -- great resource
• computer-security/compromise FAQ
• Computer Security Evaluation FAQ, Version 2.1
• alt.security.keydist Frequently Asked Questions
• computer-security/sniffers FAQ
• SSH (Secure Shell) FAQ - Frequently Asked Questions
• computer-security/vendor-contacts FAQ
• info.cert -- Steps for Recovering from a UNIX Root Compromise
• JAVA Security FAQ
• Security Patches FAQ
• Firewall FAQ
• Solaris Security FAQ
• NT Security FAQ
• The Solaris Security FAQ
• Sendmail Security
• FreeBSD Security & Firewalls
• FreeBSD Security How-To
• How to make FreeBSD more secure
• Hardening FreeBSD
• Linux Security Howto
• Linux Administrator's Security Guide Official mirror
• SGI Security Pages
• Replay: Lock Red Hat Linux

ACL

• Access Control Lists
• Digital Unix Security Manual -- Product Version:  Digital UNIX Version 4.0 or higher March 1996
• SlashdotSGI open-sourcing XFS -- contains a very good discussion of ACLs

VPN

• Virtual Private Networks(VPN) In the Real World
• [June 24, 1999] VPNs: Proceed with caution (Datamation, June 1999)

X-Windows Security

• Crash Course in X Windows Security
• Securing X Windows
• X Security Intro