Sunday, June 15, 2008

Kiddie Foods

Today some how trying to recall the memories of childhood food habits and found that its almost more than 15 years when I had such stuff in my food. So recalling all the dishes for end less future.
Let me know if i missed some thing.

  1. IDLI Sugar
  2. Chai Paratha
  3. Chai IDLI
  4. Chai Roti
  5. Bhujia Pyaj Roti
  6. Chai Lie
  7. Jaggery Ghee Roti (Gud, Ghee, Roti)

Friday, June 13, 2008

Search Result



Wednesday, June 11, 2008

Determine if SSL connections are truly secure

When users browse to a Web site that begins with https, they expect that connection to be secure via Secure Sockets Layer (SSL), a protocol for transmitting secure documents via the Internet. The majority of Web sites use this protocol to obtain sensitive data (e.g., shopping cart data and credit card numbers from customers).

An https Web site may make most users feel relatively secure, but this alone doesn't guarantee secure transactions. To properly protect your organization's users--as well as corporate data that nonsecure transactions could leave open to exposure--make sure your users understand how to properly evaluate a Web site's security.

Making the SSL connection

When it comes to online forms, secure servers (from an https site) do not actually serve most of them. This means that the form data may not be going where users think.

Note : Sorry because of limitation with Blog Spot I am enclosing the HTML tag < with "<".. Hope it does not impact ..

If you view the source HTML code of a Web page that you're entering credit card data into, you should see something like the following:

"<"form method="POST" action="/order.cgi"">"
or
"<"form method="POST" action="https://www.shop.com/cgi-bin/order.cgi"">"

If the form POSTs to an IP address, users should browse to another site. A Web site should send sensitive information only to a registered site.

Here are the four most common forms that users will encounter:

  • Form page http://www.shop.com/form.html with a form tag of "<"form action="/cgi-bin/login.cgi" method="get"">": This is not secure at all, and it doesn't encrypt any of the information.
  • Form page https://www.shop.com/form.html with a form tag of "<"form action="http://www.shop.com/cgi-bin/login.cgi method="get"">": This information isn't secure either. When the form sends the data, it initiates a new--not secure--HTTP session.
  • Form page http://www.shop.com/form.html with a form tag of "<"form action=https://www.shop.com/cgi-bin/login.cgi method="get"">": This securely transmits information to the form Web site.
  • Form page https://domain.com/form.html with a form tag of "<"form action=/cgi-bin/login.cgi method="get"">": This also securely transmits information to the form Web site.

Making sure data remains secure

By securely transmitting data and using SSL to collect sensitive information, a Web site implies that it will keep that information secure. But what really happens behind the Web site?

For example, most small companies don't host their own Web sites; instead, they use a Web hosting service. But Web hosting services typically turn that Web form data into an e-mail, a process that more than likely doesn't encrypt the data. This means that anyone with access to the e-mail can easily access customers' sensitive information.

Advise users to keep this in mind when surfing the Web, and make sure your organization's Web site makes an effort to reassure its customers about data security.

Handle security incidents in seven steps

The possibility of encountering a security incident grows each day. Don't wait until you're in the middle of a crisis before you begin to develop a rational plan for handling an attack. Being prepared for an incident is essential to the survival of your network and its resources. Incident handling begins with planning and establishing policies and procedures.

Developing a plan of attack for each type of security incident is crucial to the restoration of normal operation. Here are the most common incident categories:

  • Elevation of file privileges: A user or guest gains greater privileges.
  • Data alteration: Unauthorized users make changes to files.
  • Data theft: Unauthorized users remove data from the system.
  • Denial of service (DoS): Intruders launch an attack that denies legitimate access to the system.

An event can sometimes span multiple categories. For example, Web site defacement involves elevation of privileges and data alteration.

An essential action plan

Different events require different responses. However, you should follow these seven steps for every incident.

Step 1: Log everything.
Your documentation doesn't have to be fancy. It can be a Word document with screen shots or notes on a blackboard. The goal is to capture detailed information without destroying or contaminating potential evidence. Before you take further action, verify that you have an incident.

Step 2: Make appropriate calls.
Depending on the severity of the incident, the first call might be to your service provider, or it might be to an internal legal department to start a chain of custody for evidence. For each type of incident, develop of flow chart detailing whom to contact.

Step 3: Contain the incident.
Concentrate on limiting the extent of the damage to your network. Determine whether the incident is still in progress and requires monitoring or if you should take actions to stop the activity.

Step 4: Identify the point(s) of failure.
Discover how the incident occurred, and determine what you should do to ensure the same event doesn't reoccur.

Step 5: Solve the problem, and repair the damage.
Implement the solution you've determined is necessary to ensure that the security event doesn't happen again. This might be as simple as applying an operating system patch or adding a new rule to a firewall or router.

After you've plugged the security hole, repair any damage caused by the incident.

Step 6: Increase monitoring.
After restoring a compromised system to operation, continue to monitor for backdoors and repeat attempts. Make sure you've removed the cause of the incident, and ensure that the system is functioning normally.

Step 7: Learn from the incident.
Success yields a persistent hacker. Discover exactly what occurred, how it occurred, and what's necessary to ensure it doesn't happen again.