Computer Internet network security News

You think the software you use is absolutely safe for your privacy?

The main problem is that most common PC users do not even suspect that they use unsafe software!

Think about it: your PC’s Operating System and the software you use collect and store some data about you without you even knowing it! Such features are made for your convenience, but at the same time they create leaks in your PC system.

Many malefactors may use these leaks in your PC and thus get access to your personal information.

Security software Security software

Our computers do what they do entirely because of the software code or “programs” we run on them. Some people create programs that do what most of us would not desire. Since programs completely control the computer, it is very important that we not run programs written by people we don’t know or trust. Doing so gives them complete control of our computer and all the information and power at its disposal.

• Install and maintain anti-virus software. This will help us refuse to run software code that is known to be damaging. However, we must keep in mind that it won’t protect us from hostile code the antivirus vendors haven’t seen. We must conscientiously refuse to run unknown code even when we’re partially protected by anti-virus software. Fast moving, email based viruses can circle the globe and infect a lot of computers before antivirus software can be updated to protect against them.

When we receive email, we can rarely be sure who sent it. The FROM: information is as easily spoofed as a return address on a letter. Virus code regularly sends out email in the name of the person using the infected computer. Accordingly, email attachments, which may contain malicious code, should all be treated with caution. Be particularly careful of unexpected or unusual email or attachments.

• Treat any email with executable attachments ( those with extensions such as .exe, .vbs, .js, .hta, .pif, and .shs) as you would hazardous waste material. Find out what it is from the sender before opening it!
• Some attachments carry more risk than others. Word and Excel documents (those carrying .doc and .xls extensions respectively) are generally safe assuming the software is kept up to date. However, some email clients will not display attachment names properly. An attachment named “resume.doc.exe” may be displayed as “resume.doc”. What looks like a low risk Word document is actually a high risk executable capable of taking complete control of our computer. This subterfuge is often used by virus writers to fool us into clicking malicious, but harmless looking, attachments.
• We can protect ourselves from this naming subterfuge by refusing to double-click attachments to open them. Instead, save the attachment to a file, open the application indicated by the visible extension, and use the application’s File->Open menu.

For example, if the attachment looks like “resume.doc”, right-click on it and save it to a file. Then open Microsoft Word and use Word’s File->Open menu to select the file just saved. If the file was maliciously named to look like a Word document but it really wasn’t, these extra mouse clicks will keep us from running code contained within the file. Similarly, files that appear as “budget.xls” or “myVacation.jpg” should be saved and opened with the File->Open menus of Excel or Netscape/IE respectively.

It is not as simple as double-clicking but it is a lot simpler than cleaning up after someone else’s code is run on our computer.

• Do not double-click file icons obtained from questionable places to open them. These might include files accessed from world-writable or untrusted shared drives. Instead, use the procedures described above for opening email attachments. Start the associated application (Word, Excel, Windows Media Player, Netscape, etc.) and use the application’s File->Open menu.
• Download software only from trustworthy sources. Do we trust the author? Do we trust the provider? Who did they trust? Who else had access to the files? Are we willing to risk control of our computer, its files, our accounts, and our electronic privacy to run this software?

Computer security Systems Computer security Systems

study by Reasoning, the leading provider of automated software inspection (ASI) services, concluded that the code quality of MySQL ranks higher than commercial equivalents.

Specifically, Reasoning found that:

MySQL code quality was 6x better than that of comparable proprietary code
MySQL benefits from the large communities of programmers who “battle test” the code
MySQL benefits from users who not only report bugs, but track down their root cause and fix them A follow up study by Coverity found that MySQL had an average of one bug in every 4,000 lines of code –results that are more than four times better than is typical with commercial software. MySQL has used Coverity products to detect and fix:

Crash Causing Defects
Performance Degradation
Security Vulnerabilities
MySQL Network certified software is tested on more than ten different platforms using tools from Coverity and Klocwork.

Data Security Data Security

Businesses are experiencing an alarming and growing number of security attacks
that can result in fi nancial losses. These security threats can pose a variety of
business risks, including:
• Loss of revenue
• Loss of customers
• Loss of intellectual property (including customer information)
• Loss of tangible property
• Loss of corporate communications
• Loss of reputation
• Interruption of internal/external operations
• Concern regarding privacy for customers, partners and employees
• Loss of data and source code
• Damage to brand
The security breaches can come from sources both external to and within the
organization in the form of hackers, competitors, and disgruntled employees. The
Internet is a major source of security attacks, especially with the number of Web
attacks rising from year to year.

Business security Business security

Perhaps the most important differentiation between all the SSL certificates available on the market today, is the strength of the brand behind the SSL technology. SSL technology besides ensuring secure transmission of data, is an essential element in providing online customers with the confidence to buy or use a product or service.
For example, the greater the number of users visiting a website, the greater the probability that some customers may not complete a transaction, simply because they do not recognise or trust the brand behind the SSL technology.
Inevitably the well known brands from the credible long standing CAs are the most expensive SSL certificates on the market. If you have a low volume or development website and you decide that your

ssl ssl

The following 10 considerations must be taken into account before deciding which CA and which type of SSL certificate to purchase? Each point will be discussed in more detail later.
1. What type of web site application. Low volume, professional or development?
2. How credible and stable is the CA issuing the SSL certificate?
3. What browser recognition is required?
4. Do I require a single root or intermediate SSL certificate?
5. What certificate strength is required?
6. Is technical support available from the CA for installation or CSR issues?
7. Do I need warranty?
8. What type of validation is required?
9. How fast do I want my certificate?
10. What budget do I have for my certificate?
Lets look at each point in turn.

ssl ssl

Assume that institutions simply maintained databases of (pseudonymous or identified) user ids and passwords. Note carefully that the idea here is that a member of the institutional user community has a single userid and password for access to all licensed resources, and not a separate userid and password for each licensed resource.

Using SSL-encrypted forms (which eliminates the problems of transmitting passwords in the clear), it would be fairly easily for a resource to ask for this userid and password securely; one could then have a special purpose protocol so that a resource could securely check whether the userid and password were valid by querying an institutional userid/password database server. Note that SSL can set up an encrypted connection with a server certificate but no client-side certificate.

The special purpose userid/password checking protocol doesn’t exist today, but is not hard to design or implement, and since it only needs to be implemented by the resource operator and by an institutional server or two at each licensee institution, it might be much less problematic than making all licensee community users go through the complications of obtaining and installing certificates on their machines. Further, similar protocols for userid/password checking are already in use for validating users to terminal servers (i.e. TACACS, RADIUS); these might be used, or at least adapted.

Users are already familiar with user ids and passwords, including the need to keep passwords secure, to change them, and to pick them well (or at least they are more familiar with these issues than, for example, certificate use). Userids and passwords can be carried in the minds of people rather than being installed on specific machines the way that certificates are; this helps with kiosks, computer labs, libraries and other shared machine settings — assuming that one can teach the user to log off when he or she is finished, rather than just leaving the machine signed on. Probably the biggest problem with this approach — which is not shared with certificates — is that the resource operator obtains a set of globally valid credentials for the user, and has to be trusted to keep them secure. There are also some secondary problems — Trojan horse resources that capture user ids and passwords under false pretenses, for example, are a much more serious threat than they are in a certificate exchange environment.

Let’s consider passwords and user ids carried over SSL encryption from the perspective of our requirements definition. It’s clear that they are feasible and deployable. Assuming that a protocol for verifying user ids and passwords with an institutional server is standardized and deployed, the amount of work faced either by a licensee institution or a resource operator is quite manageable. Special desktop software is not required for web access; for other protocols, such as Telnet, an SSL- capable Telnet is needed (my understanding is that some of these are under development). Z39.50 credentials are a particular problem because no Z39.50 interface to a service like SSL is currently defined. User ids and passwords are clearly linked to people rather than network addresses of machines. One problem with userids and passwords is that they don’t encourage seamless navigation among resources; each resource is going to explicitly annoy the user by asking for his or her userid and password on each visit.

While passwords represent relatively weak security, a system can be put in place to require them to be difficult to guess (by forcing the use of pass phrases rather than passwords, or avoiding use of words in a dictionary), and also insisting that they be changed frequently. The use of an SSL based transport removes the security problems of transmitting them in the clear. The protection provided by SSL will depend on whether US-only (long key) or international (short key) versions of SSL are supported by the user’s browser. Userids and passwords are subject to systemic compromise from two perspectives; if the institutional password verification server is compromised, new passwords would have to be issued to all members of the user community. Also, each resource operator now shares in the responsibility for keeping userids and passwords secure; if any resource operator’s site is retaining user ids and passwords, and is compromised, this will compromise all other resource operators as well as the home institution (if the institution is using the same userid and password for internal and external authentication and authorization purposes).

Granularity and extensibility. An institutional password server will just verify that a particular userid/password combination is valid (it would also know what resource operator was asking). In situations where an access management decision needs to be made that goes beyond validity of the userid/password pair, the key question is the locus of that decision. The resource operator will either have to maintain a list of valid Ids (identities) or the password server will have to keep information about what resources a userid has access to. Or the institution would have to offer resource operators access to a user attribute database keyed on userid.

Cross-protocol flexibility: because passwords operate at a higher level of abstraction than protocols they are general. Telnet and Z39.50 support should be straightforward, assuming that there is encryption on the link over which the passwords are transmitted, as discussed above.

Privacy and accountability. The use of user ids and passwords transfers personal information directly to the resource operator. This information may be pseudononymous or identified; it will not be anonymous. To this extent, it undermines privacy but offers accountability. Management data faceted by demographic categories will be available from the resource operator only to the extent that the licensee institution provides demographic data as a byproduct of userid/password validation. there is no opportunity for the licensee institution to collect statistical information directly, other than a count of how often userid/password pairs are validated by the various resource operators.

Summary: to the extent that an institutional password verification server controls the export of individual and demographic information, passwords could work surprisingly well in an SSL-protected context. A primary benefit is that users are familiar with the model. There are important missing pieces here, particularly the protocol to permit resource operators to verify userid/password pairs with institutions that issued them. Probably the greatest weakness of this approach is the dependency on each resource operator to protect userid/password pairs, and the danger of systemic compromise due to a security failure on the part of a single resource operator.

Further comments. Clearly, by issuing different passwords and userids for different resources, it is possible to reduce the interdependence among resource operators and the dependence on each resource operator in maintaining security. However, large numbers of passwords and userids are extremely unfriendly and confusing for users, and probably impractical. For users who only use a single machine (or who are willing to store a cookie file in a network file system), and for resources that don’t require high security, it’s certainly possible to store userids and passwords as cookies on the user’s machine (though many users have become "cookie-phobic" due to the overly dire publicity surrounding cookies); once stored, the user doesn’t have to enter them at all, improving seamless cross-resource navigation. This is the approach that is taken by many low-security commercial services in the consumer marketplace today.

Passwords Password-management, Passwords

Currently, IP source address filtering is the major mechanism used to implement authentication and access management for cross-institutional resource access. The way this works is that the licensee institution provides the resource operator with a list of IP addresses that are authorized access; this can include some wildcarding to permit entire subnets or networks to have access, and also occasionally incorporates exclusion lists (all hosts on a given net or subnet EXCEPT for the following specific hosts). There is general agreement that it is unsatisfactory for a number of reasons, and it is instructive to evaluate it against our seven functional requirements both to see where it works and where it actually falls short.

Feasibility and Deployment: This is relatively easy to deploy and manage from the perspective of both the institution and the resource operator. No special software is needed at the user side, and at the resource operator side the support is not difficult. There is some maintenance involved in keeping the tables at the resource providers up to date, but this is not unmanageable. It is necessary for the licensee institution to perform some analysis on access and use policies for the machines within the institution to make sure that machines that aren’t access-limited to the institutional community are excluded where necessary, and to educate members of the community that giving outsiders an account on a machine also gives them access to institutional resources that they may not be entitled to; there are some real dangers of access control breaches by the creation of proxies either through ignorance of the implications or deliberately.

Internet security Internet security

Having summarized the many and sometimes conflicting requirements that an access management system must address, we now consider a number of actual schemes currently in use or under consideration and analyze how well they meet these requirements.

It’s important to recognize that in solving real-world problems more than one approach may be relevant at a single institution; one might use one scheme for one class of users and a different scheme for another class. For example, an institution might choose to manage access for kiosks and public workstations by IP source address, and to use a credential scheme for other users. Indeed, virtually all of the major institutional systems that are currently being deployed combine multiple approaches. Also, note that approaches can be cascaded in a hierarchy; for example, a resource might be set up to first check whether a user could be validated by an IP source filtering approach but if the IP source address isn’t valid for access, the resource might then apply a credential-based access management test.

Data Security access_management, Authentication, Data Security, institutional_systems, management_system, validated

Authentication strength is a somewhat subjective question. For many of the approaches that we will discuss, strength comes from the details of cryptographic algorithms and key lengths used; but part lies also in overall system design and implementation and in the realities of user behavior, and this can often be the source of the largest number of vulnerabilities. Some level of reason is called for here; most of the resources being access controlled, while certainly valuable assets, do not represent immanent dangers to public safety or national security if access control is breached. An access management system needs to be complemented by monitoring and other controls on the part of the resource operator to limit the impact of a breach. Further, there are after-the-fact legal remedies which can be applied to limit the damage caused by such a breach.

The cryptographic technology underlying many access management systems is legally sensitive on an international export and import basis, and may also be constrained by various national laws (though within the US, cryptographic technology can be employed freely, at least today).This is important for several reasons: resource access may cross national boundaries, and also because members of an institution’s user community may need to access networked information resources when traveling outside of their home nation. We will see international resource sharing consortia, and also see institutions in one nation licensing access to resources in other nations.

Computer-security access_control, access_management, Authentication, cryptographic_algorithms, cryptographic_technology, management_systems, networked_information_resources, Vulnerabilities

The basic cross-organizational access management problem is exemplified by most licensing agreements for networked information resources today; it also arises in situations where institutions agree to share limited-access resources with other institutions as part of consortia or other resource sharing collaborations. In such an agreement, an institution — a university, a school, a public library, a corporation — defines a user community which has access to some network resource. This community is typically large, numbering perhaps in the tens of thousands of individuals, and membership may be volatile over time, reflecting for example the characteristics of a student body. The operator of the network resource, which may a web site, or a resource reached by other protocols such as Telnet terminal emulation or the Z39.50 information retrieval protocol needs to decide whether users seeking access to the resource are actually members of the user community that the licensee institution defined as part of the license agreement.
Note that the issue here is not how the licensee defines the user community — for example how a university might define students, staff members and faculty (all of the problems about alumni, part time and extension students, adjunct faculty, affiliated medical staff and the like); it is assumed that the institution and the resource operator have reached some satisfactory resolution on this question. Rather, the issue is one of testing or verifying that individuals are really a member of this community according to pre-agreed criteria, of having the institution vouch for or credential the individuals in some way that the resource operator can understand. Such arrangements are often called “site” licenses, but this term is really inaccurate; while physical presence at a specific site may be one criteria for having access, a better term is “group” license or “community” license, emphasizing that the key consideration is membership in some community, and that physical location is often not the key me

Source http://www.cni.org/projects/authentication/authentication-wp.html

Computer-security access_management, access_resources, Authentication, information_retrieval_protocol, management_problem, networked_information_resources, telnet_terminal_emulation

There are actually less than 10 CAs issuing commercially available SSL certificates. The Appendix contains the full list of CAs. Until recently the SSL market has been monopolized by Verisign and Thawte. In 1999 Verisign acquired Thawte, and it became a Verisign subsidiary. In recent years, new global players providing enterprise class solutions such as GeoTrust (formerly Equifax Certificate Services) have also established themselves in the enterprise security market. In the last few months, other companies providing solutions for small to medium sized businesses have also started providing SSL certificates.
There is however confusion in the market because all CAs have reseller programs. Resellers are organizations that will resell the SSL CA’s certificates, often at different prices to the SSL CA themselves. Resellers are a great way to sometimes save money through discounted pricing, but are also an easy way to be overcharged for SSL! Be aware that some resellers will “re-brand” the CA’s certificate, thereby masking who actually issues the certificate and then offer their own re-branded certificates at inflated prices above the SRP of the CA themselves. Don’t be fooled by unknown brands – if an SSL Certificate is being sold under a brand that is not contained in the attached Appendix, the buyer should examine one of the reseller’s example certificates before purchase. It is very likely that the certificate has been issued by a CA featured in this white paper and will probably be available directly from the CA at a different cost, maybe even lower than the reseller offers it. Resellers provide exactly the same certificate and features provided by the CA themselves, so it is essential for buyers to know which CA that will issue the SSL certificate before purchasing through a reseller!
4

ssl ssl