<?xml version='1.0' encoding='UTF-8'?><?xml-stylesheet href="http://www.blogger.com/styles/atom.css" type="text/css"?><feed xmlns='http://www.w3.org/2005/Atom' xmlns:openSearch='http://a9.com/-/spec/opensearchrss/1.0/' xmlns:georss='http://www.georss.org/georss' xmlns:gd='http://schemas.google.com/g/2005' xmlns:thr='http://purl.org/syndication/thread/1.0'><id>tag:blogger.com,1999:blog-4112114114279396444</id><updated>2011-11-27T15:32:42.614-08:00</updated><title type='text'>Learning Security</title><subtitle type='html'></subtitle><link rel='http://schemas.google.com/g/2005#feed' type='application/atom+xml' href='http://muni-on-security.blogspot.com/feeds/posts/default'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default?max-results=100'/><link rel='alternate' type='text/html' href='http://muni-on-security.blogspot.com/'/><link rel='hub' href='http://pubsubhubbub.appspot.com/'/><author><name>Muni</name><uri>http://www.blogger.com/profile/17249152356013880281</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><generator version='7.00' uri='http://www.blogger.com'>Blogger</generator><openSearch:totalResults>48</openSearch:totalResults><openSearch:startIndex>1</openSearch:startIndex><openSearch:itemsPerPage>100</openSearch:itemsPerPage><entry><id>tag:blogger.com,1999:blog-4112114114279396444.post-6623400595566532306</id><published>2011-11-06T16:38:00.000-08:00</published><updated>2011-11-06T16:38:24.499-08:00</updated><title type='text'>CA compromise continues...</title><content type='html'>Yet another Certificate Authority compromised. &lt;br /&gt;&lt;br /&gt;&lt;a href="http://www.theregister.co.uk/2011/11/04/ssl_still_hopelessly_broken/"&gt;http://www.theregister.co.uk/2011/11/04/ssl_still_hopelessly_broken/&lt;/a&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4112114114279396444-6623400595566532306?l=muni-on-security.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://muni-on-security.blogspot.com/feeds/6623400595566532306/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4112114114279396444&amp;postID=6623400595566532306' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/6623400595566532306'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/6623400595566532306'/><link rel='alternate' type='text/html' href='http://muni-on-security.blogspot.com/2011/11/ca-compromise-continues.html' title='CA compromise continues...'/><author><name>Muni</name><uri>http://www.blogger.com/profile/17249152356013880281</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4112114114279396444.post-3570761514443796513</id><published>2011-07-15T15:39:00.000-07:00</published><updated>2011-07-15T15:39:31.141-07:00</updated><title type='text'>Virtualization Security (Part 3)</title><content type='html'>&lt;b&gt;Virtualized Networking&lt;br /&gt;&lt;/b&gt;&lt;br /&gt;Full virtualization hypervisors can provide networking capabilities, allowing the individual guest OSs to communicate with one another while simultaneously limiting access to the external physical network. The network interfaces that the guest OSs see may be virtual, physical, or both. Typical hypervisors offer three primary forms of network access:&lt;br /&gt;&lt;br /&gt;1. Network Bridging. The guest OS is given direct access to the host’s network interface cards (NIC) independent of the host OS.&lt;br /&gt;&lt;br /&gt;2. Network Address Translation (NAT). The guest OS is given a virtual NIC that is connected to a simulated NAT inside the hypervisor. As in a traditional NAT, all outbound network traffic is sent through the virtual NIC to the host OS for forwarding, usually to a physical NIC on the host system.&lt;br /&gt;&lt;br /&gt;3. Host Only Networking. The guest OS is given a virtual NIC that does not directly route to a physical NIC. In this scenario, guest OSs can be configured to communicate with one another and, potentially, with the host OS.&lt;br /&gt;&lt;br /&gt;When a number of guest OSs exist on a single host, the hypervisor can provide a virtual network for these guest OSs. The hypervisor may implement virtual switches, hubs, and other network devices. Using a hypervisor’s networking for communications between guests on a single host has the advantage of greatly increased speed because the packets never hit physical networking devices. Internal host-only networking can be done in many ways by the hypervisor. In some systems, the internal network looks like a virtual switch. Others use virtual LAN (VLAN) standards to allow better control of how the guest systems are connected. Most hypervisors also provide internal network address and port translation (NAPT) that acts like a virtual router with NAT.&lt;br /&gt;&lt;br /&gt;Networks that are internal to a hypervisor’s networking structure can pose an operational disadvantage, however. Many networks rely on tools that watch traffic as it flows across routers and switches; these tools cannot view traffic as it moves in a hypervisor’s network. There are some hypervisors that allow network monitoring, but this capability is generally not as robust as the tools that many organizations have come to expect for significant monitoring of physical networks. Some hypervisors provide APIs that allow a privileged VM to have full visibility to the network traffic. Unfortunately, these APIs may also provide additional ways for attackers to attempt to monitor network communications. Another concern with network monitoring through a hypervisor is the potential for performance degradation or denial of service conditions to occur for the hypervisor because of high volumes of traffic.&lt;br /&gt;&lt;br /&gt;The security implications of networks internal to a hypervisor should not be minimized. For example, assume that an organization has two computers, one that acts as a public-facing web server and another that is an internal database server. The organization also monitors the switch that connects the two computers, watching for traffic that would indicate an attack on the database. If both of those servers were moved onto a single hypervisor, and the hypervisor’s virtual network was used for communications between the servers for increased efficiency, the ability to monitor all the traffic between the two systems would be lost unless the hypervisor itself can perform this monitoring that meets the organization’s security policies.&lt;br /&gt;&lt;br /&gt;To get around this loss of visibility, some organizations purposely expose network traffic between virtualized hosts to the physical network already in place in the organization. This requires the system on which the hypervisor is running to have multiple network interfaces, and this may significantly slow network communications as compared to a virtual-only network, but the advantage is that the organization does not need to change its security policies to gain the cost advantages of virtualization. Organizations should consider the tradeoffs between traffic being hidden within a hypervisor and the extra overhead and risk of exposing that traffic but being able to control it using the same tools already used for controlling other network traffic.&lt;br /&gt;&lt;br /&gt;(Reproduced from NIST publication SP800-125)&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4112114114279396444-3570761514443796513?l=muni-on-security.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://muni-on-security.blogspot.com/feeds/3570761514443796513/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4112114114279396444&amp;postID=3570761514443796513' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/3570761514443796513'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/3570761514443796513'/><link rel='alternate' type='text/html' href='http://muni-on-security.blogspot.com/2011/07/virtualization-security-part-3.html' title='Virtualization Security (Part 3)'/><author><name>Muni</name><uri>http://www.blogger.com/profile/17249152356013880281</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4112114114279396444.post-6601007860883759499</id><published>2011-07-12T13:29:00.000-07:00</published><updated>2011-07-12T13:31:41.399-07:00</updated><title type='text'>Virtualization Security (Part 2)</title><content type='html'>In full virtualization, existing hardware resources are utilized more efficiently by running multiple OS instances. It increases operational efficiency. Although, if one OS instance can access resources allocated for another OS instance, it becomes a security concern. Recent advances in CPU architecture have made full virtualization more secure by strengthening hypervisor restrictions on resources.&lt;br /&gt;&lt;br /&gt;Full virtualization has some negative security implications. Virtualization adds layers of technology, which can increase the security management burden by necessitating additional security controls. Also, combining many systems onto a single physical computer can cause a larger impact if a security compromise occurs. Further, some virtualization systems make it easy to share information between the systems; this convenience can turn out to be an attack vector if it is not carefully controlled. In some cases, virtualized environments are quite dynamic, which makes creating and maintaining the necessary security boundaries more complex.&lt;br /&gt;&lt;br /&gt;&lt;b&gt;Types of Full Virtualization&lt;/b&gt;&lt;br /&gt;&lt;br /&gt;There are two types: bare metal aka native virtualization and hosted virtualization. In native virtualization, the hypervisor runs directly on underlying hardware; whereas in hosted virtualization, the hypervisor runs on top of the host OS. In both bare metal and hosted virtualization, each guest OS appears to have its own hardware, like a regular computer. This  includes CPU, memory, storage, storage controllers and ethernet controllers etc.&lt;br /&gt;&lt;br /&gt;Deciding between these two types of virtualization is an important operational and security decision. Bare metal virtualization may offer better security depending on how well-secured hypervisor is, while hosted virtualization adds complexity and as a result increases  vulnerabilities. On the other hand, bare metal hypervisors run on a limited range of hardware than hosted hypervisors.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4112114114279396444-6601007860883759499?l=muni-on-security.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://muni-on-security.blogspot.com/feeds/6601007860883759499/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4112114114279396444&amp;postID=6601007860883759499' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/6601007860883759499'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/6601007860883759499'/><link rel='alternate' type='text/html' href='http://muni-on-security.blogspot.com/2011/07/virtualization-security-part-2.html' title='Virtualization Security (Part 2)'/><author><name>Muni</name><uri>http://www.blogger.com/profile/17249152356013880281</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4112114114279396444.post-8487274160232828063</id><published>2011-07-11T13:37:00.000-07:00</published><updated>2011-07-11T13:39:55.796-07:00</updated><title type='text'>Virtualization Security (Part 1)</title><content type='html'>Every technology brings its own security challenges. Virtualization is no different. In this series, I present a summary of virtualization from NIST publication &lt;a href="http://csrc.nist.gov/publications/nistpubs/800-125/SP800-125-final.pdf"&gt;SP800-125&lt;/a&gt;&lt;br /&gt;&lt;br /&gt;Let's start off with understanding different kinds of Virtualization. Mainly, we can categorize virtualization as follows:&lt;br /&gt;&lt;br /&gt;1. Application Virtualization: It is a virtual implementation of an API that allows applications to run across different platforms without modifications. JVM is an example of this type.&lt;br /&gt;&lt;br /&gt;2. Operating System Virtualization: It provides a virtual implementation of the OS interface where each application can run in a separate VM container. &lt;br /&gt;&lt;br /&gt;3. Full (hypervisor) Virtualization: One or more OSs and the applications they contain are run on top of virtual hardware. Each instance of an OS runs in a separate VM called a guest operating system. The guest OSs on a host are managed by the hypervisor, also called the virtual machine monitor (VMM).&lt;br /&gt;&lt;br /&gt;&lt;a href="http://www.parallels.com/products/virtuozzo/os/"&gt;This link has a pictorial view of full and operating system virtualization&lt;/a&gt;.&lt;br /&gt;&lt;br /&gt;NIST publication SP800-125 focuses on full virtualization. In next part, I'll start looking into details of full virtualization.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4112114114279396444-8487274160232828063?l=muni-on-security.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://muni-on-security.blogspot.com/feeds/8487274160232828063/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4112114114279396444&amp;postID=8487274160232828063' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/8487274160232828063'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/8487274160232828063'/><link rel='alternate' type='text/html' href='http://muni-on-security.blogspot.com/2011/07/virtualization-security-part-1.html' title='Virtualization Security (Part 1)'/><author><name>Muni</name><uri>http://www.blogger.com/profile/17249152356013880281</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4112114114279396444.post-5320836465884624613</id><published>2011-07-01T16:06:00.000-07:00</published><updated>2011-07-01T16:06:03.376-07:00</updated><title type='text'>Database Encryption - Balancing Security with Performance</title><content type='html'>Found an &lt;a href="http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.127.8228&amp;rep=rep1&amp;type=pdf"&gt;interesting paper&lt;/a&gt; on database security. Key takeaways:&lt;br /&gt;&lt;br /&gt;1. AES outperforms RSA and Blowfish. Not a surprise, given that performance was an important criteria for &lt;a href="http://en.wikipedia.org/wiki/Advanced_Encryption_Standard"&gt;AES&lt;/a&gt; selection. I missed rationale for RSA comparison though, how is asymmetric algorithm compared to symmetric algorithm?&lt;br /&gt;&lt;br /&gt;2. Encryption over network attached devices performs poorly due to couple of reasons. First, network delay, and second, additional encryption/decryption operations at end points to secure network traffic.&lt;br /&gt;&lt;br /&gt;3. Accelerated search index increases throughput and response time significantly for encrypted data. Only rows that match search criteria move to decryption step.&lt;br /&gt;&lt;br /&gt;4. Hybrid model where keys are stored in a HSM, while encryption/decryption operations are performed in software provides acceptable compromise between security and performance. Performing crypto operations in hardware has initialization overhead that offsets savings.&lt;br /&gt;&lt;br /&gt;5. DBA and SA (security administrator) should be separate to achieve security goals.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4112114114279396444-5320836465884624613?l=muni-on-security.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://muni-on-security.blogspot.com/feeds/5320836465884624613/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4112114114279396444&amp;postID=5320836465884624613' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/5320836465884624613'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/5320836465884624613'/><link rel='alternate' type='text/html' href='http://muni-on-security.blogspot.com/2011/07/database-encryption-balancing-security.html' title='Database Encryption - Balancing Security with Performance'/><author><name>Muni</name><uri>http://www.blogger.com/profile/17249152356013880281</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4112114114279396444.post-5241334470765504411</id><published>2008-12-04T02:37:00.001-08:00</published><updated>2010-07-27T21:27:05.418-07:00</updated><title type='text'>LDAP Authentication</title><content type='html'>One of the requirements of remote authentication is to support user authentication with LDAP. Basic LDAP authentication is a simple procedure and follows these 3 steps:&lt;br /&gt;&lt;br /&gt;1. LDAP Bind: First client should authenticate itself with LDAP server. This requires that client knows the bind address (called rootDN) and password for binding. This step establishes trust between LDAP client and LDAP server and paves the way for user authentication.&lt;br /&gt;&lt;br /&gt;2. LDAP query for user name: Next step is query to LDAP server with user name. LDAP client sends this query to LDAP server to determine if user exists on the server. If user exists then client proceeds with real user authentication otherwise authentication request is denied in this step.&lt;br /&gt;&lt;br /&gt;3. LDAP authentication: In this final step, client sends another LDAP Bind request with username that needs to be authenticated using the password taken from user input. If username and password matches on the LDAP server, authentication is successfully completed.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4112114114279396444-5241334470765504411?l=muni-on-security.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://muni-on-security.blogspot.com/feeds/5241334470765504411/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4112114114279396444&amp;postID=5241334470765504411' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/5241334470765504411'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/5241334470765504411'/><link rel='alternate' type='text/html' href='http://muni-on-security.blogspot.com/2008/12/ldap-authentication_04.html' title='LDAP Authentication'/><author><name>Muni</name><uri>http://www.blogger.com/profile/17249152356013880281</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4112114114279396444.post-3716214277863888764</id><published>2008-11-08T16:25:00.001-08:00</published><updated>2008-11-08T16:57:42.815-08:00</updated><title type='text'>Encrypting Keys for Storage</title><content type='html'>Suppose you get a security requirement to encrypt the passwords and keys that are stored on a device. How can this problem be solved without complicating the design? Encrypting passwords is easy, it is a well established practice in Linux and Unix world to create a one way hash of the passwords, mix it up with a salt and store it. One way hash algorithms are practically known to be non-reversible, so it is not easy to guess the password if a good algorithm is used.&lt;br /&gt;&lt;br /&gt;Problem comes with storing keys in encrypted format that can not be stored as one way hash e.x. keys for remote AAA servers such as RADIUS. Those keys are required to be present in clear text format when AAA client communicates with AAA server, otherwise client won't know what key to use.&lt;br /&gt;&lt;br /&gt;This can be solved in few ways:&lt;br /&gt;1. Have a hardware device that stores these keys and grants access permissions to only those applications that are on the white list. Although feasible, it adds to overall cost of device, as, such specialized hardware does not come cheap. This is very little gain for a lot of cost. It may be ok for a specialized security product that has a requirement of such hardware for other reasons, but not for a general purpose product that only needs to store keys.&lt;br /&gt;&lt;br /&gt;2. Come up with an external key management scheme where keys to encrypt are managed externally. Internally keeping encryption keys on the device defeats the purpose, if encryption key and encrypted data are in same place, it is not very hard to break it. This approach also does not pass the cost/benefit test for a general purpose device. Therefore, not feasible.&lt;br /&gt;&lt;br /&gt;3. Use a unique device attribute to generate a encryption key. This is a better approach from complexity perspective, but has the same problem of keeping the encryption key along with the encrypted data. No matter what algorithm is used, once it is known what attribute is used to generate the key, reverse engineering it may not be very hard. This is however, still the most practical approach that works considering the risk of compromise. In this case, goal is to encrypt the the secure key so that they are not easily known, not necessarily to protect against a determined attacker. A determined attacker is likely to find other ways to get secure keys.&lt;br /&gt;&lt;br /&gt;So, third approach is a reasonable compromise to hide the secure keys keeping in mind the risk and cost associated with other approaches. However, in some environments this poses another challenge. Many system administrators want to define a cookie cutter configuration for the devices they manage. They want to create a configuration on one device and then be able to apply same configuration seamlessly on potentially hundreds of similar devices. In this case, using unique device encryption keys means that the configuration created on one device can not be used on another device. For example, a AAA server key is encrypted with a unique device key, another device can not decrypt and read it, therefore making the cookie cutter approach infeasible.&lt;br /&gt;&lt;br /&gt;How can this problem be solved in a sensible way without compromising the security of stored data? I am still looking for a solution.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4112114114279396444-3716214277863888764?l=muni-on-security.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://muni-on-security.blogspot.com/feeds/3716214277863888764/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4112114114279396444&amp;postID=3716214277863888764' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/3716214277863888764'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/3716214277863888764'/><link rel='alternate' type='text/html' href='http://muni-on-security.blogspot.com/2008/11/encrypting-keys-for-storage.html' title='Encrypting Keys for Storage'/><author><name>Muni</name><uri>http://www.blogger.com/profile/17249152356013880281</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4112114114279396444.post-7152113134922046062</id><published>2008-08-06T12:04:00.000-07:00</published><updated>2008-08-06T12:08:14.319-07:00</updated><title type='text'>40 Million Credit Cards Theft Case</title><content type='html'>This ID theft case of 40 million credit cards is old news. However, people are being charged just now.&lt;br /&gt;&lt;br /&gt;&lt;a href="http://news.bbc.co.uk/2/hi/business/7544083.stm"&gt;http://news.bbc.co.uk/2/hi/business/7544083.stm&lt;/a&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4112114114279396444-7152113134922046062?l=muni-on-security.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://muni-on-security.blogspot.com/feeds/7152113134922046062/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4112114114279396444&amp;postID=7152113134922046062' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/7152113134922046062'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/7152113134922046062'/><link rel='alternate' type='text/html' href='http://muni-on-security.blogspot.com/2008/08/id-theft-case.html' title='40 Million Credit Cards Theft Case'/><author><name>Muni</name><uri>http://www.blogger.com/profile/17249152356013880281</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4112114114279396444.post-3711596297036554198</id><published>2008-08-03T21:59:00.000-07:00</published><updated>2008-08-03T22:26:54.740-07:00</updated><title type='text'>A Newbie's Way of Thinking Security</title><content type='html'>Pattern is highly repeatable. Every time I am asked to work on security, even before I have asked what the requirements are, other team members have a ready made security design. Key management? That's easy, we'll embed a key in source code of two end points, and both use the same key, so they are secure. Right? Wrong !!! I have heard it repeated so many times, and seen this approach used in so many products (some of them from top rated tech companies) that it's laughable.&lt;br /&gt;&lt;br /&gt;This seemingly simple solution is no solution at all. This solution is actually in search of a problem. What is the security problem that we are trying to solve? There is only one thing this key management solution is good for and that is if there is a reason to hide clear text data from naked eye. That's the only level of protection this scheme gives. Other than this, there is no other security benefit of this approach. Even then, almost always when non-security engineers hear the word 'key', default assumption is that it's about encryption. If they have inserted a key in the design, and applied an algorithm, without even giving a serious thought to what algorithm to use and why, all security problems magically disappear.&lt;br /&gt;&lt;br /&gt;Now, I am not saying that those engineers are dumb, it's just that they are not aware of security requirements which may or may not be directly related to a product function. For example, when engineers are developing a protocol, they are thinking in terms of utility of the protocol, not about how somebody will try to break that. It's the difference between mindset of creating vs. destroying. Security is about figuring about how many ways it is possible to destroy something and once you know that then figuring out the solutions to protect against those destructive techniques.&lt;br /&gt;&lt;br /&gt;Good news is, so far all the stories have ended well. Once we dive into the mechanics of security requirements and discuss about what needs to be done and why, engineers do understand. Although, some do complain about increasing their work :) Oh well, that's fine by me.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4112114114279396444-3711596297036554198?l=muni-on-security.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://muni-on-security.blogspot.com/feeds/3711596297036554198/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4112114114279396444&amp;postID=3711596297036554198' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/3711596297036554198'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/3711596297036554198'/><link rel='alternate' type='text/html' href='http://muni-on-security.blogspot.com/2008/08/newbies-way-of-thinking-security.html' title='A Newbie&apos;s Way of Thinking Security'/><author><name>Muni</name><uri>http://www.blogger.com/profile/17249152356013880281</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4112114114279396444.post-8074270415088956717</id><published>2008-07-26T22:22:00.000-07:00</published><updated>2008-07-29T12:10:10.252-07:00</updated><title type='text'>DNS Vulnerability</title><content type='html'>New DNS vulnerabilities discovered. &lt;a href="http://www.doxpara.com/"&gt;Interesting read.&lt;/a&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4112114114279396444-8074270415088956717?l=muni-on-security.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://muni-on-security.blogspot.com/feeds/8074270415088956717/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4112114114279396444&amp;postID=8074270415088956717' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/8074270415088956717'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/8074270415088956717'/><link rel='alternate' type='text/html' href='http://muni-on-security.blogspot.com/2008/07/dns-vulnerability.html' title='DNS Vulnerability'/><author><name>Muni</name><uri>http://www.blogger.com/profile/17249152356013880281</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4112114114279396444.post-2896506402225145758</id><published>2008-06-29T17:19:00.000-07:00</published><updated>2008-06-29T18:20:47.940-07:00</updated><title type='text'>Can Credit Card Use be Made Safer?</title><content type='html'>I love the convenience of shopping with credit card , but I hate the fact that stores, online as well as brick and mortar ones, store so much personal information and especially credit card numbers. Do an Internet search for "credit card compromise" and some mind boggling information comes up. Here is a sample: &lt;a href="http://www.msnbc.msn.com/id/6030057/"&gt;120 millions accounts compromised last year&lt;/a&gt; !&lt;br /&gt;&lt;br /&gt;Credit cards are authorized at the time of purchase, so there should be no need to store it for later use. For online shopping, there is some convenience of not re-entering the information with every purchase but cost is very high if merchant's database is compromised.&lt;br /&gt;&lt;br /&gt;The design of whole online shopping process is flawed. Perhaps this whole process could be designed differently with a much higher level of security. Couple of ways it could be done:&lt;br /&gt;&lt;br /&gt;Firstly, Internet payment service providers store credit card information and act as a gateway for all Internet transactions. This is much better than thousands of online retailers each one of which stores credit cards. Service providers will probably number in single digit, so there is less number of places where card information is stored. This model works reasonably successfully in the physical world with credit card issuers Visa, Master Card, and Amex etc. It could have been made to work in Internet. Incidentally, there are services which try to do exactly that: Paypal, Google Checkout and Amazon payments. These services are popular for transactions where parties don't trust each other. When it comes to online shopping, almost everyone trusts online stores implicitly and most of online stores don't use these services. Ideally, online services should have outsourced handling of customer information that is not required after transaction is over.&lt;br /&gt;&lt;br /&gt;Secondly, online shopping systems could have been designed with a client side application installed on user's computer that stored the credit card numbers and validated it every time a purchase is made. There is really no need for the merchant to store the credit card information as long as credit card authority authorizes the payment. This way the number of credit card compromises could have been reduced drastically. If a customer machine is compromised, it potentially gives away information about credit cards stored on that machine, which surely won't be in thousands or hundreds of thousands as is typically the case for merchant's database compromises. And it also provides the convenience that user does not need to enter the information for every purchase. In fact, it will be simpler compared to existing paradigm. Existing paradigm requires entry of credit card information for each online store, with client side application, entry needs to be done only once for the lifetime of the card. I know, why it did not happen this way, self interest of the merchants and system designers. They made their life easier at the expense of end users.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4112114114279396444-2896506402225145758?l=muni-on-security.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://muni-on-security.blogspot.com/feeds/2896506402225145758/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4112114114279396444&amp;postID=2896506402225145758' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/2896506402225145758'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/2896506402225145758'/><link rel='alternate' type='text/html' href='http://muni-on-security.blogspot.com/2008/06/can-credit-card-use-be-made-safer.html' title='Can Credit Card Use be Made Safer?'/><author><name>Muni</name><uri>http://www.blogger.com/profile/17249152356013880281</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4112114114279396444.post-9082994180391951984</id><published>2008-05-02T22:39:00.000-07:00</published><updated>2008-05-02T23:06:50.457-07:00</updated><title type='text'>Developing Secure Applications</title><content type='html'>Security risks in a system can come from variety of sources. It can come from a weakness in user interaction with the system, interdependencies of different components in the system, or from the implementation of the system itself. Here, we look at some of the vulnerabilities that can be introduced in the system implementation resulting in security risks. These vulnerabilities remain same across different software development paradigms and languages used for implementation. &lt;br /&gt;&lt;br /&gt;1. Never Trust User Input&lt;br /&gt;User input in an application must be validated against input rules of the application. A malformed input, if accepted unchecked in an application may provide window of opportunity for an attacker. To illustrate this with an example, an input field, accepting person’s name can only consist of alphabetic and perhaps numeric characters. Allowing special characters such as dollar ($) and star (*) can lead to very nasty attacks depending on the type of application. In many computer languages, special characters have special meanings, which if used inappropriately can compromise the integrity and availability of data. &lt;br /&gt;&lt;br /&gt;2. Be Careful With Output&lt;br /&gt;Output information that is necessary to perform a task for a user. To take the common example, passwords should never be shown on the screen when either setting it first time or later used for logging into the system. What data to display on a user interface and what not, is highly application dependent, still  “need to know” can be used as a general guideline. A user should be allowed access to only information that he or she needs to know in order to complete his task and no more. A security conscious application should validate access control before outputting data.&lt;br /&gt;&lt;br /&gt;3. Trust Experts for Crypto Implementation&lt;br /&gt;Many applications use cryptographic libraries to perform various security services. It is best to trust the library implementers with cryptographic implementation. Do not attempt to come up with your own secret algorithms and implementation. Many of the open source and proprietary libraries have gone through years of rigor to achieve the current level of trust. This is not to say, that such libraries whether open source or proprietary have no security holes. But they certainly have (Openssl e.x.) gone through rigorous reviews and bug fixes over the years. Leave crypto details to experts and channel your energy in securing the application.&lt;br /&gt;&lt;br /&gt;4. Protect Against Buffer Overflows&lt;br /&gt;Programs manipulate data in memory buffers. When data size that is being handled, exceeds the expected size, it results in internal memory buffer overflows. A skillful attacker can carefully craft the data to exploit buffer overflows and execute malicious code. Most of these attacks can be automated with tools and non skilled attackers only need to know how to use these tools. A typical vulnerability introduced by buffer overflow is escalation of privileges (admin access on windows, root access on Unix/Linux) to the system. Once an attacker has highest level of access on a system, it’s a cakewalk to compromise it further.  &lt;br /&gt;Buffer overflow problems can be avoided by checking the bounds for memory region where data is being written. This can be either done by programmer explicitly or provided as a language feature. A great number of security problems are caused by this category and application’s security is significantly increased by making it buffer overflow proof.  &lt;br /&gt;&lt;br /&gt;5. Use Secure Default Configuration&lt;br /&gt;Insecure defaults are common cause of compromised systems and loss of security. Microsoft has been notorious in the past for shipping software (e.x. Windows) with services, which a user may never use, running by default. But bad guys certainly find out about such services and have a good time exploiting those. Things have changed for the better in recent times and newer software from Microsoft ship with relatively secure default configurations, where user is allowed to choose the services rather than running everything by default. Most of the applications ship with multiple configurations/services, hence using secure defaults is important for all application vendors, not just Microsoft.  &lt;br /&gt;Using secure defaults is more difficult in practice than it sounds, mainly due to insecure configurations propagated in earlier generations of software. When later version of software suddenly changes the default behavior, end user’s application may stop working or break due to hidden dependencies. It can be a time consuming task to fix those issues, and it’s certainly worth the effort. Application developers should make sure that only absolute minimum services or configuration is provided at setup time and user is prompted to explicitly enable the functionality which he wants to use, rather than enabling it by default.   &lt;br /&gt;&lt;br /&gt;6. Force to change default password&lt;br /&gt;All software products without exception ship either with a default password or an empty password. If default password is not changed at the time of installation, system is a very easy target for attackers. A well intentioned administrator may simply forget or put password change in his to do list due to deadline pressures. Regardless, it opens vulnerability in the system. Therefore, application developers (vendors) must force the default password change at the time of installation or first use. Any system administrator worth his salt will prefer to be forced to change the default password and appreciate the security posture of the product.  &lt;br /&gt;&lt;br /&gt;7. Follow “less is better” approach  &lt;br /&gt;Useful applications come with many features, some commonly used and some obscure. Typically 80% of the users use 20% features of the application. Application developers should follow the mantra of least feature installation for enhanced security. This is somewhat similar to the principle of ‘using secure default configuration’, but goes deeper. When an application is installed, only the minimum required set of components should be installed by default, user should be asked and given a choice for installation of advanced components. (To read about an incident on installing hidden components, go to story of Sony BMG, http://www.schneier.com/essay-094.html). For most users, minimum installation will be good enough. For advanced users, they will know what extra features to install. If you are writing network applications, be extra careful. Networked applications are by definition exposed to threats; hence this principle becomes more important.  &lt;br /&gt;&lt;br /&gt;8. Follow “least privilege” principle  &lt;br /&gt;An application should run only with the privileges it requires. Not only this is necessary to prevent against intentional misuse by attackers but it also protects against unintentional mistakes committed by users. Within an application, not all of the code needs to run at the same privilege level. Depending on the resources used, different code segments may require different privilege levels. Application should be architected and implemented to keep this logical separation. It also provides other side benefits in ease of debugging and in adding auditing feature; ex. in a front end application, different access levels can be used for displaying read only data and read-write data (which could in turn be tied to user id).  &lt;br /&gt;For an application that makes calls to an external component (using DLLs or shared libraries), it should grant restricted permissions for allowed tasks only. This may require language level or Operating Systems support. Use where ever this support is provided.  &lt;br /&gt;&lt;br /&gt;9. Have multiple access levels  &lt;br /&gt;This is an extension of the principle of ‘least privilege’ at user level. A user should not be given more access rights than he requires. An application needs to define the access control methods it supports. Typically, role based access control is used in enterprise applications. Role based access control implies that a user is given access rights to the application based on his role in the organization; ex. in an employee management system, a regular employee can access only his records and a manager may have access to records of all his subordinates. One popular method to enforce role based access control in a centralized manner uses RADIUS/TACACS/LDAP servers. Administrators of the system should be given clear instructions on how to manage application roles (create, modify, delete etc.) and application should correctly &lt;br /&gt;enforce the access to data based on those roles.  &lt;br /&gt;&lt;br /&gt;10. Handle exceptions, errors and failures securely  &lt;br /&gt;A lot of code in any application is written to handle error conditions. This creates security holes if error handling code does not take proper care to keep the security environment consistent. It is important to leave the system in a valid and consistent security state in the event of errors and exceptions. A common mistake is to reveal too much information about the system under exception conditions. Here are some things which should be handled under exceptions.&lt;br /&gt;An application handling the security keys should remove and zero out the keys under conditions of unrecoverable exception. Failing to do so may leave the keys in memory even if application is no longer using it and may lead to compromise of application security. A web interface should not reveal information about database schema or tables in the backend if illegal queries are submitted. A backend database application should commit only complete transactions and have rollback mechanisms in place to avoid inconsistent data due to partial transactions.  &lt;br /&gt;&lt;br /&gt;11. Develop a security testing strategy &lt;br /&gt;It is well known that a bug found during development is cheapest to fix and a bug found in the field is costliest. Same is true for security bugs and vulnerabilities. Not only does security vulnerability create anxiety in customer’s mind for security of his systems and data, it also creates poor public perception. Security testing requires different kind of skills and mind set than regular functional testing. In order to have confidence in security of the application; security testing must be included in the project schedule. Security testing team should develop the security test suite along the lines of functional test suite. This security test suite can be run against regular builds and provides the baseline for security features. Just like broken functionality can be easily found out by functional test suites, broken security can be found out by security test suites. Once security issues are found, development team should be sensitive to those and take ownership to fix.  &lt;br /&gt;&lt;br /&gt;12. Avoid feature creep &lt;br /&gt;More components and features an application has, more the likelihood of introducing security vulnerabilities. Even if all components by themselves are secure, it is harder to test all the different ways components in an application interact. If an application has large number of components, it becomes almost impossible to test all permutations. It also provides a large attack surface for an attacker, since he has more things to try to attack and get around the security. Hence, it is advisable to keep the application as simple as possible and provide only necessary features.  &lt;br /&gt;&lt;br /&gt;In this post, I have outlined some general principles to write secure applications. Along with these, best software engineering practices also add to security. Some of the principles are worth repeating here. Reuse as much code as possible, perform regular code reviews, do unit tests, and most of all, think about security (just like one thinks about functionality) when writing code. In this list, thinking about security is arguably the hardest, not everyone can be a security expert (and need not be, only security awareness is enough for most people) therefore, enforcement of security enabled code should be left to a team of security experts. This team can enforce the best security development practices by using tools, education seminars, code reviews and any other method that makes sense in a particular environment.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4112114114279396444-9082994180391951984?l=muni-on-security.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://muni-on-security.blogspot.com/feeds/9082994180391951984/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4112114114279396444&amp;postID=9082994180391951984' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/9082994180391951984'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/9082994180391951984'/><link rel='alternate' type='text/html' href='http://muni-on-security.blogspot.com/2008/05/developing-secure-applications.html' title='Developing Secure Applications'/><author><name>Muni</name><uri>http://www.blogger.com/profile/17249152356013880281</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4112114114279396444.post-2384053059724674597</id><published>2008-04-20T17:48:00.001-07:00</published><updated>2008-04-20T17:59:07.645-07:00</updated><title type='text'>Routing Security on Internet</title><content type='html'>Even though the &lt;a href="http://asert.arbornetworks.com/2008/02/internet-routing-insecuritypakistan-nukes-youtube/"&gt;story &lt;/a&gt;of Pakistan's ISP bringing down YouTube.com is very old now, it highlights a very real threat to Internet Routing System. Anyone, who has looked at routing protocols knows that Internet is running on insecure protocols. So, events of this kind are waiting to happen either because of someone's misconfiguration (as in this case) or because of some sabotage. Until secure routing protocols are widely deployed, for Internet to keep working, all ISPs in the world must behave as good citizens of Internet.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4112114114279396444-2384053059724674597?l=muni-on-security.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://muni-on-security.blogspot.com/feeds/2384053059724674597/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4112114114279396444&amp;postID=2384053059724674597' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/2384053059724674597'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/2384053059724674597'/><link rel='alternate' type='text/html' href='http://muni-on-security.blogspot.com/2008/04/routing-security-on-internet.html' title='Routing Security on Internet'/><author><name>Muni</name><uri>http://www.blogger.com/profile/17249152356013880281</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4112114114279396444.post-5179803412675005855</id><published>2008-04-20T17:30:00.001-07:00</published><updated>2008-04-20T17:41:07.253-07:00</updated><title type='text'>Routing Security Presentation</title><content type='html'>An informational &lt;a href="https://svn.resiprocate.org/rep/ietf-drafts/ekr/ietf71/kmart-slides.pdf"&gt;presentation &lt;/a&gt;from Eric Rescorla on Routing Security. Points related to KMP (key management problem) are particularly interesting.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4112114114279396444-5179803412675005855?l=muni-on-security.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://muni-on-security.blogspot.com/feeds/5179803412675005855/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4112114114279396444&amp;postID=5179803412675005855' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/5179803412675005855'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/5179803412675005855'/><link rel='alternate' type='text/html' href='http://muni-on-security.blogspot.com/2008/04/routing-security-presentation.html' title='Routing Security Presentation'/><author><name>Muni</name><uri>http://www.blogger.com/profile/17249152356013880281</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4112114114279396444.post-5613553981104714791</id><published>2008-04-19T22:04:00.000-07:00</published><updated>2008-04-20T18:16:59.846-07:00</updated><title type='text'>Videos</title><content type='html'>Here are couple of interesting videos on google video. Set aside couple of hours if you plan to watch full videos.&lt;br /&gt;&lt;br /&gt;&lt;a href="http://video.google.com/videoplay?docid=-643828532267823915&amp;q=martin+hellman&amp;total=11&amp;start=0&amp;num=10&amp;so=0&amp;type=search&amp;plindex=2"&gt;Celebrating 30 years of Public Key Crytpo&lt;/a&gt;: I found this one very entertaining, especially comments related to NSA.&lt;br /&gt;&lt;br /&gt;&lt;a href="http://video.google.com/videoplay?docid=1762847950860111011"&gt;Security is Broken&lt;/a&gt;: A good talk about security problems in computer systems.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4112114114279396444-5613553981104714791?l=muni-on-security.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://muni-on-security.blogspot.com/feeds/5613553981104714791/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4112114114279396444&amp;postID=5613553981104714791' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/5613553981104714791'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/5613553981104714791'/><link rel='alternate' type='text/html' href='http://muni-on-security.blogspot.com/2008/04/security-videos.html' title='Videos'/><author><name>Muni</name><uri>http://www.blogger.com/profile/17249152356013880281</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4112114114279396444.post-1182014189824555592</id><published>2008-04-09T22:09:00.000-07:00</published><updated>2008-04-20T18:17:17.883-07:00</updated><title type='text'>Quote of the Day</title><content type='html'>"If you are concerned about the security of your computer, please disconnect it from Internet" - Symantec Install Process&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4112114114279396444-1182014189824555592?l=muni-on-security.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://muni-on-security.blogspot.com/feeds/1182014189824555592/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4112114114279396444&amp;postID=1182014189824555592' title='1 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/1182014189824555592'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/1182014189824555592'/><link rel='alternate' type='text/html' href='http://muni-on-security.blogspot.com/2008/04/security-quote-of-day.html' title='Quote of the Day'/><author><name>Muni</name><uri>http://www.blogger.com/profile/17249152356013880281</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>1</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4112114114279396444.post-4909034387422771578</id><published>2008-03-30T15:51:00.000-07:00</published><updated>2008-04-02T10:27:56.924-07:00</updated><title type='text'>Paper: Attacks on RSA system</title><content type='html'>I recently came across this &lt;a href="http://crypto.stanford.edu/~dabo/papers/RSA-survey.pdf"&gt;Attacks on RSA system &lt;/a&gt;paper. I sure need to improve my mathematics and number theory skills to understand it in its entirety. Nevertheless, what ever little I understood, I enjoyed.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4112114114279396444-4909034387422771578?l=muni-on-security.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://muni-on-security.blogspot.com/feeds/4909034387422771578/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4112114114279396444&amp;postID=4909034387422771578' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/4909034387422771578'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/4909034387422771578'/><link rel='alternate' type='text/html' href='http://muni-on-security.blogspot.com/2008/03/paper-attacks-on-rsa-system.html' title='Paper: Attacks on RSA system'/><author><name>Muni</name><uri>http://www.blogger.com/profile/17249152356013880281</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4112114114279396444.post-5020796030127098715</id><published>2008-03-19T23:39:00.000-07:00</published><updated>2008-03-19T23:43:19.307-07:00</updated><title type='text'>Threat Modeling</title><content type='html'>Threat modeling is a complex topic. There is no exact science that software developers can be taught to enable them to do threat modeling. I stumbled upon Adam Shostack’s MSDN blog discussing threat modeling. Even if you are a Microsoft basher, it’s worthwhile to leave that spirit aside for a while and focus on the content. There are many general guidelines that can be applied in a product development set up. Some of the things that I found interesting:&lt;br /&gt;&lt;br /&gt;- Most developers think in terms of developing features, so they are poor in terms of thinking about security. It is, in part, nature of the job, one focuses on the work with most ROI and developers don’t have a quantifiable ROI to think about security. &lt;br /&gt;&lt;br /&gt;- Even if a developer engages in threat modeling, in the absence of expert review, how does he validate that his threat modeling is accurate, sufficient, insufficient or even relevant?&lt;br /&gt;&lt;br /&gt;- Threat modeling process: clearly outlines the steps that one should take (second blog entry in the series: "The new threat modeling process")&lt;br /&gt;&lt;br /&gt;- STRIDE: This is a useful acronym to remember for what common threats to look out ( Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) &lt;br /&gt;&lt;br /&gt;&lt;br /&gt;&lt;a href="http://blogs.msdn.com/sdl/archive/tags/threat+modeling/default.aspx"&gt;MSDN Blog&lt;/a&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4112114114279396444-5020796030127098715?l=muni-on-security.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://muni-on-security.blogspot.com/feeds/5020796030127098715/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4112114114279396444&amp;postID=5020796030127098715' title='1 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/5020796030127098715'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/5020796030127098715'/><link rel='alternate' type='text/html' href='http://muni-on-security.blogspot.com/2008/03/threat-modeling.html' title='Threat Modeling'/><author><name>Muni</name><uri>http://www.blogger.com/profile/17249152356013880281</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>1</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4112114114279396444.post-4671210757133183790</id><published>2008-03-09T22:40:00.000-07:00</published><updated>2008-03-09T22:45:19.147-07:00</updated><title type='text'>Security Philosophy</title><content type='html'>What should be the general philosophy when dealing with security issues? Here are some thoughts.&lt;br /&gt;&lt;br /&gt;Perform a risk analysis&lt;br /&gt;Even before one invests in security, one needs to know what are the possible threats, and risks of the environment. An analogy is to know the doors and windows of your house. Those are the places that require security first.&lt;br /&gt;&lt;br /&gt;Less is more&lt;br /&gt;A network with less access points is more secure. All access point should be added in the network keeping in mind the business ROI, convenience and security. Every desktop, laptop and network access point is a potential security threat. In general, network access points are easier to secure as they are centralized and are not too many. As long as one follows the standard procedures of locking down the network devices (access controls, privileges, firewalls, patching etc.), one can be reasonably confident that network access points are secure. More troubling piece is the desktops and laptops under user control. It is harder to control user behavior, which sites they visit, which software they download and where they carry their laptops. An organization policy is helpful in defining such behaviors, but humans are fallible and ultimately, one has to deal with lapse in judgment of people in the organization. No matter how many layers of security are present, one ultimately has to be prepared for worst case scenarios. &lt;br /&gt;&lt;br /&gt;Simple is better&lt;br /&gt;Prefer a product that is simple to manage and understand and good at doing few tasks (preferably one or two). A product with lots of bells and whistles that claims to be everything to everyone has a high probability of introducing hidden security problems. Complexity is the enemy of security and more complex the product harder it becomes to have a verifiable claim of security.&lt;br /&gt;&lt;br /&gt;Educate users&lt;br /&gt;Ignorance is the worst enemy, Education is the best friend. Status of a society is directly related to the education level of the population. Educated people are better citizens and create a better society. So is true for security, people who are educated about security risks, how to avoid those and how to handle those when they do materialize are better for the organization. Security educated people are more likely to avoid situations leading to security compromises and better equipped to deal with consequences when compromises do occur. Unfortunately, security education is not a one time thing, and it needs to be re-enforced with employees on an ongoing basis. Any effective organization has continuous training programs to improve skill levels and prepare employees for new challenges. Security awareness must be made part of such training programs, this guarantees that employees are aware of its importance and it does not become an afterthought. Security is an inherent part of the functional job responsibilities and each and every employee must know and live up to this ideal.&lt;br /&gt;&lt;br /&gt;Be conservative&lt;br /&gt;Technological innovations make our life convenient and lead to productivity increases. However, in security world, best strategy is not to rely on the bleeding edge technologies and newest products. Any technology product takes time to mature and security products are no exception. New technologies and products unless proven in the wild for considerable length of time (each organization may have different levels of comfort) are likely to evolve and fix many security issues on an ongoing basis. Unless this technology or product fulfils an immediate need or plugs a gaping hole, which otherwise can not be fixed, ripping out old wares should wait for a while. &lt;br /&gt;&lt;br /&gt;Look for the best class of support&lt;br /&gt;When security incidents do happen, can you rely on customer support of your vendors to fix the issues in their wares? It is not a good idea to skimp on best class of support when it comes to security. What good is being penny wise and pound foolish if valuable data is compromised?&lt;br /&gt;&lt;br /&gt;Perform regular audit&lt;br /&gt;What is the use of building all the security protections if no one is going to check if those protections are effective? It is important to periodically perform security audit of systems and review of logs to identify security breaches if any and keep track of user’s activities.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4112114114279396444-4671210757133183790?l=muni-on-security.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://muni-on-security.blogspot.com/feeds/4671210757133183790/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4112114114279396444&amp;postID=4671210757133183790' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/4671210757133183790'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/4671210757133183790'/><link rel='alternate' type='text/html' href='http://muni-on-security.blogspot.com/2008/03/security-philosophy.html' title='Security Philosophy'/><author><name>Muni</name><uri>http://www.blogger.com/profile/17249152356013880281</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4112114114279396444.post-6950118632249199428</id><published>2008-01-04T18:32:00.001-08:00</published><updated>2008-01-04T19:08:11.053-08:00</updated><title type='text'>SecurtityNow Podcast</title><content type='html'>A good way to start new year on Security: Start listening to &lt;a href="http://www.grc.com/securitynow.htm"&gt;SecurityNow&lt;/a&gt;, I have been listening to this podcast off and on for last few months. Very useful podcast with lots of practical discussions and sometimes with more technical details. Hosts Steve and Leo keep the conversation interesting, so there is never a dull moment. This is like "Car Talk" of security domain.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4112114114279396444-6950118632249199428?l=muni-on-security.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://muni-on-security.blogspot.com/feeds/6950118632249199428/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4112114114279396444&amp;postID=6950118632249199428' title='2 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/6950118632249199428'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/6950118632249199428'/><link rel='alternate' type='text/html' href='http://muni-on-security.blogspot.com/2008/01/securtitynow-radio-show.html' title='SecurtityNow Podcast'/><author><name>Muni</name><uri>http://www.blogger.com/profile/17249152356013880281</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>2</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4112114114279396444.post-3661537183994343020</id><published>2007-12-30T21:38:00.001-08:00</published><updated>2007-12-30T21:40:52.913-08:00</updated><title type='text'>Security Novels?</title><content type='html'>Just did a Google search for "security novels" and found this &lt;a href="http://www.securitynovels.com/"&gt;link&lt;/a&gt;. Glad to find that someone writes novels about security... Will read it when have some time. In the meantime, if anyone else reads before me, let me know if they are any good.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4112114114279396444-3661537183994343020?l=muni-on-security.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://muni-on-security.blogspot.com/feeds/3661537183994343020/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4112114114279396444&amp;postID=3661537183994343020' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/3661537183994343020'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/3661537183994343020'/><link rel='alternate' type='text/html' href='http://muni-on-security.blogspot.com/2007/12/security-novels.html' title='Security Novels?'/><author><name>Muni</name><uri>http://www.blogger.com/profile/17249152356013880281</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4112114114279396444.post-6458199955945404016</id><published>2007-12-30T21:13:00.000-08:00</published><updated>2007-12-30T21:17:13.685-08:00</updated><title type='text'>Security Lectures</title><content type='html'>University of Washington has a cryptography course. The course material, lecture notes and videos are online.&lt;br /&gt;&lt;a href="http://www.cs.washington.edu/education/courses/csep590/06wi/"&gt;http://www.cs.washington.edu/education/courses/csep590/06wi/&lt;/a&gt;&lt;br /&gt;&lt;br /&gt;Lectures are very good, it will probably interest only those who want to get deeper into cryptography stuff. Anyhow, going through all of the lectures and assignments does  require a lot of commitment. Someday I hope to go through at least videos :)&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4112114114279396444-6458199955945404016?l=muni-on-security.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://muni-on-security.blogspot.com/feeds/6458199955945404016/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4112114114279396444&amp;postID=6458199955945404016' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/6458199955945404016'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/6458199955945404016'/><link rel='alternate' type='text/html' href='http://muni-on-security.blogspot.com/2007/12/security-lectures.html' title='Security Lectures'/><author><name>Muni</name><uri>http://www.blogger.com/profile/17249152356013880281</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4112114114279396444.post-5550457286197058885</id><published>2007-12-30T21:05:00.000-08:00</published><updated>2007-12-30T21:09:59.872-08:00</updated><title type='text'>An Important Security Question</title><content type='html'>&lt;a href="http://www.everydayfiction.com/security-question-by-ramon-rozas-iii/"&gt; An interesting security fiction &lt;/a&gt;. Nicely written.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4112114114279396444-5550457286197058885?l=muni-on-security.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://muni-on-security.blogspot.com/feeds/5550457286197058885/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4112114114279396444&amp;postID=5550457286197058885' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/5550457286197058885'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/5550457286197058885'/><link rel='alternate' type='text/html' href='http://muni-on-security.blogspot.com/2007/12/important-security-question.html' title='An Important Security Question'/><author><name>Muni</name><uri>http://www.blogger.com/profile/17249152356013880281</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4112114114279396444.post-8132261579418780950</id><published>2007-12-20T19:38:00.000-08:00</published><updated>2007-12-20T19:42:50.859-08:00</updated><title type='text'>Cost of Insecure Software</title><content type='html'>Can you take a guess? How much? 10… 20… 30… 40… 100… Billion? Read on, the numbers truly are shocking and are beyond my wildest imaginations.&lt;br /&gt;&lt;br /&gt;According to &lt;a href="http://www.darkreading.com/document.asp?doc_id=140184&amp;WT.svl=news1_4"&gt;this article&lt;/a&gt; in darkreading.com, the cost is $180B (billion) per year for US businesses (gasp…. only for US businesses, what about the whole wide world?). Agreed that this number is somewhat ‘soft’ and subject to adjustments, still it provides a reference point in the debate of how much insecure software costs.&lt;br /&gt;&lt;br /&gt;The article talks about a vulnerability tax (David Rice’s proposal) on software makers to reduce the impact. The whole debate about determining whether software is vulnerable is a can of worms. Consider this, software vendors even today have heated arguments about responsible disclosure and there is hardly any agreement industry wide on the subject. If a monetary penalty in the form of tax is added, then how much the same vendors will push back can only be imagined. If the proposal ever flies, hopefully it will be the beginning of a new age of secure software.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4112114114279396444-8132261579418780950?l=muni-on-security.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://muni-on-security.blogspot.com/feeds/8132261579418780950/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4112114114279396444&amp;postID=8132261579418780950' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/8132261579418780950'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/8132261579418780950'/><link rel='alternate' type='text/html' href='http://muni-on-security.blogspot.com/2007/12/cost-of-insecure-software.html' title='Cost of Insecure Software'/><author><name>Muni</name><uri>http://www.blogger.com/profile/17249152356013880281</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4112114114279396444.post-3393355234631233447</id><published>2007-12-06T20:07:00.001-08:00</published><updated>2007-12-06T20:26:11.670-08:00</updated><title type='text'>Client Apps: The Security Problem</title><content type='html'>The point &lt;a href="http://www.nytimes.com/idg/IDG_002570DE00740E18002573A100822399.html?ref=technology"&gt;this article &lt;/a&gt;makes is that client side application vulnerabilities are major cause of concern.&lt;br /&gt;&lt;br /&gt;It does not come as a surprise to security practitioners. The security of transport (primarily with SSL) has been in place for a long time, so attackers have moved to the weakest link in the chain i.e. client applications and users. Attackers utilize the fact that client applications are inherently trusted and users are gullible. Most of the applications are not coded with security in mind and not even tested against security vulnerabilities. So, it is no wonder that they are easy to compromise.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4112114114279396444-3393355234631233447?l=muni-on-security.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://muni-on-security.blogspot.com/feeds/3393355234631233447/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4112114114279396444&amp;postID=3393355234631233447' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/3393355234631233447'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/3393355234631233447'/><link rel='alternate' type='text/html' href='http://muni-on-security.blogspot.com/2007/12/client-apps-security-problem.html' title='Client Apps: The Security Problem'/><author><name>Muni</name><uri>http://www.blogger.com/profile/17249152356013880281</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4112114114279396444.post-31723600472995089</id><published>2007-12-05T22:21:00.001-08:00</published><updated>2007-12-05T22:35:37.599-08:00</updated><title type='text'>Crack Passwords with Google</title><content type='html'>This is an &lt;a href="http://www.lightbluetouchpaper.org/2007/11/16/google-as-a-password-cracker/"&gt;interesting story &lt;/a&gt;about how to crack passwords with a Google search.&lt;br /&gt;&lt;br /&gt;If passwords are stored in clear text, an unauthorized access to password database would reveal all passwords. To avoid this, password are stored as result of a one way hash function that converts passwords into an irreversible format. This effectively hides the passwords. Mathematically, it is not feasible to find out clear text password even if result of one way hash of the password is known. This scheme is still weak. First weakness is that if two users choose the same password, one way hash of both passwords will be same; it makes it easier for an attacker to compromise two user accounts by cracking the password of one. Worse, if one of the users can get access to the password database, he immediately knows the password of the other user that has the same password. Second weakness is that if hashed password database is accessible, a dictionary of hashes makes it trivial to lookup the clear text password. The password cracking attack with Google relies on this second weakness. With hashes of many of the common text string easily searched through Google, passwords stored only as a one way hash are trivially broken.&lt;br /&gt;&lt;br /&gt;Solutions to these weaknesses is to use salts. Salt is a set of random bytes that are appended to the clear text password before hashing. Salt is stored along with the hashed password and is visible to anyone with access to hashed password database. It solves both the problems. Same passwords now hash to different values assuming that salts are different (that is why it must be random) and dictionary of clear text hashes no longer allow easy lookup. Since, it is practically infeasible to generate a dictionary of all clear text passwords with all possible random salts.&lt;br /&gt;&lt;br /&gt;To appreciate what happens to those passwords which we routinely use and rely on for security, we should know about some password management schemes and their relative strengths and weaknesses. Here is an excellent &lt;a href="http://www.securityfocus.com/blogs/262"&gt;article &lt;/a&gt;on the topic.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4112114114279396444-31723600472995089?l=muni-on-security.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://muni-on-security.blogspot.com/feeds/31723600472995089/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4112114114279396444&amp;postID=31723600472995089' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/31723600472995089'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/31723600472995089'/><link rel='alternate' type='text/html' href='http://muni-on-security.blogspot.com/2007/12/crack-passwords-with-google.html' title='Crack Passwords with Google'/><author><name>Muni</name><uri>http://www.blogger.com/profile/17249152356013880281</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4112114114279396444.post-1499568434564268722</id><published>2007-12-05T21:53:00.000-08:00</published><updated>2007-12-05T21:57:14.808-08:00</updated><title type='text'>Facebook Backtracking on Beacon</title><content type='html'>Facebook has &lt;a href="http://news.yahoo.com/s/ap/20071205/ap_on_hi_te/facebook_about_face;_ylt=AmbXr0xe.xQLlLAdoruqh0us0NUE"&gt;changed the policy &lt;/a&gt;of its beacon marketing program and made it opt-in instead of opt-out. Sensible move I would say.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4112114114279396444-1499568434564268722?l=muni-on-security.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://muni-on-security.blogspot.com/feeds/1499568434564268722/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4112114114279396444&amp;postID=1499568434564268722' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/1499568434564268722'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/1499568434564268722'/><link rel='alternate' type='text/html' href='http://muni-on-security.blogspot.com/2007/12/facebook-backtracking-on-beacon.html' title='Facebook Backtracking on Beacon'/><author><name>Muni</name><uri>http://www.blogger.com/profile/17249152356013880281</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4112114114279396444.post-1300896037196903958</id><published>2007-12-02T21:21:00.000-08:00</published><updated>2007-12-02T21:22:09.776-08:00</updated><title type='text'>Skype Encryption Causing Trouble</title><content type='html'>According to &lt;a href="http://news.yahoo.com/s/nm/20071122/tc_nm/security_internet_germany_dc;_ylt=AkATB4AVpJ0ualt0D7c6mJus0NUE"&gt;this news&lt;/a&gt;, German police are not able to decipher Skype conversations. They claim it is causing problems in monitoring Skype calls by suspected criminals and terrorists. This is not first time law enforcement has complained about encryption issues. US government did not allow export of cryptographic software for a long time due to the same fear. World has changed a lot since then, even US government now allows export of cryptographic software (with some restrictions). Cat is out of the bag.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4112114114279396444-1300896037196903958?l=muni-on-security.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://muni-on-security.blogspot.com/feeds/1300896037196903958/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4112114114279396444&amp;postID=1300896037196903958' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/1300896037196903958'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/1300896037196903958'/><link rel='alternate' type='text/html' href='http://muni-on-security.blogspot.com/2007/12/skype-encryption-causing-trouble.html' title='Skype Encryption Causing Trouble'/><author><name>Muni</name><uri>http://www.blogger.com/profile/17249152356013880281</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4112114114279396444.post-661445763895383454</id><published>2007-11-27T20:08:00.000-08:00</published><updated>2007-11-27T20:11:19.725-08:00</updated><title type='text'>How to Convince CIO to Invest in Security?</title><content type='html'>Often times it is hard to justify investment in security technologies to CIOs. Security does not add to productivity directly, if anything it creates impediments in the day to day life of employees and it may introduce new processes and work flows. Most people do not take kindly to the the intrusion in their normal routines unless they have a proper context. It is certain though that lack of security will cause loss of productivity if a security incident does happen.&lt;br /&gt;&lt;br /&gt;Investment in security technologies is like insurance. As long as there is no incident, it appears to be unnecessary. But, even a single incident is enough to unite everyone in the understanding of its need. Think 9/11, after that unfortunate incident, how easily US government was able to convince people to support Patriot act. The fact that security incidents create an awareness of the threats can be effectively used for lobbying for implementing necessary controls and getting a bigger budget if required.&lt;br /&gt;&lt;br /&gt;I heard a talk at RSA security conference many years ago and it has stuck with me even after so long. I do not remember who gave the talk, but I do remember that it described a real life incident about how a group of network administrators convinced their CIO to invest in firewall technology (this is an old incident and long ago, in Internet time, it used to be hard to get money for purchasing firewall. I hope that today it is not the case and everyone responsible for security understands the importance of firewalls instinctively).&lt;br /&gt;&lt;br /&gt;The network administrators were making a case to purchase a firewall to CIO. They kept on coming up with presentation after presentation explaining how easy it makes for anyone on the Internet to access their corporate network and possibly steal valuable information. It went on for a few weeks but no amount of technical jargon and what if scenarios convinced the CIO about the need of a firewall. His answer always was, what they said was all good, but no one had broken into the network and stolen anything, so why would he care? After few weeks, the network team brainstormed about how to convince him. Finally, someone suggested an idea. They wrote a tool to monitor the network, capture and process all incoming traffic. They installed the tool on the network. After a while even they were surprised by what they found. Monitoring tool made it clear that the company network was being scanned thousands of times daily and few of those attempts were to exploit specific services. Armed with this data, they went back to CIO and it was easy to convince him.&lt;br /&gt;&lt;br /&gt;Moral of the story: whatever the security battle one has to fight, if we can find a way to make the threat visible to the decision makers, favorable results are likely.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4112114114279396444-661445763895383454?l=muni-on-security.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://muni-on-security.blogspot.com/feeds/661445763895383454/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4112114114279396444&amp;postID=661445763895383454' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/661445763895383454'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/661445763895383454'/><link rel='alternate' type='text/html' href='http://muni-on-security.blogspot.com/2007/11/how-to-convince-cio-to-invest-in_27.html' title='How to Convince CIO to Invest in Security?'/><author><name>Muni</name><uri>http://www.blogger.com/profile/17249152356013880281</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4112114114279396444.post-519662170809583136</id><published>2007-11-24T15:15:00.001-08:00</published><updated>2007-11-24T15:15:59.397-08:00</updated><title type='text'>Facebook Marketing Feeds</title><content type='html'>Facebook has a tool called 'Beacon' that enables marketing feeds from advertisers. It works by alerting friends about your online purchases from these advertisers. Program has an opt out feature on per advertiser basis, but does not allow to opt out entirely. Why should Facebook decide on its own what information we want to share with friends and what we do not? &lt;a href="http://news.yahoo.com/s/ap/20071121/ap_on_hi_te/facebook_ads;_ylt=Ahm..VbkCGaRBL0RJS0m4Aqs0NUE"&gt;Some users are complaining.&lt;/a&gt; Rightly so.&lt;br /&gt;&lt;br /&gt;MoveOn.org has started a &lt;a href="http://www.news.com/8301-13577_3-9821170-36.html?tag=cd.blog"&gt;campaign &lt;/a&gt; to change Facebook program to make it Opt-In instead of Opt-Out. Needless to say, anyone who cares about privacy seriously should support it.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4112114114279396444-519662170809583136?l=muni-on-security.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://muni-on-security.blogspot.com/feeds/519662170809583136/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4112114114279396444&amp;postID=519662170809583136' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/519662170809583136'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/519662170809583136'/><link rel='alternate' type='text/html' href='http://muni-on-security.blogspot.com/2007/11/facebook-marketing-feeds.html' title='Facebook Marketing Feeds'/><author><name>Muni</name><uri>http://www.blogger.com/profile/17249152356013880281</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4112114114279396444.post-638795658444188638</id><published>2007-11-22T12:33:00.000-08:00</published><updated>2007-11-22T14:14:40.170-08:00</updated><title type='text'>Tor Network: Anonymous Surfing</title><content type='html'>"Tor is an anonymity network" is the claim of the &lt;a href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#head-07125aa419ecbb1efea1184c87783c6e90a0f920"&gt;Tor &lt;/a&gt;. The idea behind Tor network is to hide the IP address of the originator, so that it is not possible to trace who is sending the traffic. If the traffic passing through the network is in clear text, this does not provide security to data content. Here are &lt;a href="http://www.torproject.org/overview.html.en"&gt;details &lt;/a&gt;of how it works. &lt;br /&gt;&lt;br /&gt;Basically if used correctly Tor technology works for its intended purpose i.e. anonymity only if traffic is encrypted end to end. If traffic entering and leaving the Tor network is in clear, then hiding IP address is pointless because identity could be easily revealed by reading the content. Security researcher &lt;a href="http://www.smh.com.au/news/security/the-hack-of-the-year/2007/11/12/1194766589522.html?page=fullpage#contentSwap1"&gt;Don Egerstad sniffed the traffic &lt;/a&gt;passing through the Tor network and exposed hundreds of sensitive emails and passwords, many of those belonging to different governments.&lt;br /&gt;&lt;br /&gt;Clearly, people using the Tor network do not understand the threat model. It is mind numbing to think that many of the world's governments are using this network without realizing what they are doing. Perhaps, exposure of this network is a setback to Intelligence community who had a potential goldmine of information from traffic flowing through this network. Or perhaps not, people who are ignorant enough to use this network, may not have even followed the news reports of this exposure and may still be using it as before.&lt;br /&gt;&lt;br /&gt;The lesson for us mortals from this incident is that do not be an early adopter of a new security technology without understanding its implications. Security is hard to get right and there are too many ways to compromise it. Focusing solely on one aspect of security could be disastrous. Security has to be looked as a whole and threat model must be properly understood instead of using an ad-hoc method. Ad-hoc solutions for security are a recipe for disaster.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4112114114279396444-638795658444188638?l=muni-on-security.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://muni-on-security.blogspot.com/feeds/638795658444188638/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4112114114279396444&amp;postID=638795658444188638' title='1 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/638795658444188638'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/638795658444188638'/><link rel='alternate' type='text/html' href='http://muni-on-security.blogspot.com/2007/11/tor-network-anonymous-surfing.html' title='Tor Network: Anonymous Surfing'/><author><name>Muni</name><uri>http://www.blogger.com/profile/17249152356013880281</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>1</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4112114114279396444.post-9114670775173536042</id><published>2007-11-19T20:48:00.001-08:00</published><updated>2007-11-22T11:11:52.174-08:00</updated><title type='text'>Math As a Security Threat</title><content type='html'>Adi Shamir (S in RSA) has circulated a research note about how a math error in a chip can cause failure of security of the electronic commerce system. &lt;br /&gt;&lt;br /&gt;The threat provides an insight into the possibilities of hardware bugs and how destructive they can be. Software security issues are already causing havoc on Internet, if a hardware bug of this kind is found and exploited, it will be a doomsday scenario. For now at least, this is still in the realm of imagination and a theoretical exercise.&lt;br /&gt;&lt;br /&gt;&lt;a href="http://www.nytimes.com/2007/11/17/technology/17code.html?ex=1353042000&amp;en=e018e67b66aa29c7&amp;ei=5124&amp;partner=permalink&amp;exprod=permalink"&gt;Read the story here&lt;/a&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4112114114279396444-9114670775173536042?l=muni-on-security.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://muni-on-security.blogspot.com/feeds/9114670775173536042/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4112114114279396444&amp;postID=9114670775173536042' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/9114670775173536042'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/9114670775173536042'/><link rel='alternate' type='text/html' href='http://muni-on-security.blogspot.com/2007/11/math-as-security-threat.html' title='Math As a Security Threat'/><author><name>Muni</name><uri>http://www.blogger.com/profile/17249152356013880281</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4112114114279396444.post-3437693211386351478</id><published>2007-11-19T20:20:00.001-08:00</published><updated>2007-11-21T10:09:43.499-08:00</updated><title type='text'>Bike Locks == British Nukes Security</title><content type='html'>An amusing &lt;a href="http://news.bbc.co.uk/2/hi/programmes/newsnight/7097101.stm"&gt;story &lt;/a&gt;about security of British Nukes. Thank God, no one felt like riding a bike while handling these bombs.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4112114114279396444-3437693211386351478?l=muni-on-security.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://muni-on-security.blogspot.com/feeds/3437693211386351478/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4112114114279396444&amp;postID=3437693211386351478' title='1 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/3437693211386351478'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/3437693211386351478'/><link rel='alternate' type='text/html' href='http://muni-on-security.blogspot.com/2007/11/bike-locks-british-nukes-security.html' title='Bike Locks == British Nukes Security'/><author><name>Muni</name><uri>http://www.blogger.com/profile/17249152356013880281</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>1</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4112114114279396444.post-4514866413133135768</id><published>2007-11-19T19:58:00.000-08:00</published><updated>2007-11-19T20:15:28.794-08:00</updated><title type='text'>List of ISPs Providing Security Software</title><content type='html'>This &lt;a href="http://www.simplehelp.net/2006/07/11/free-security-software-from-your-existing-isp/"&gt;article&lt;/a&gt;  lists the ISPs that provide security software (anti virus, personal firewall and anti spyware) either for free or at a discounted rate as part of broadband service. I strongly recommend downloading and installing the security software if you are using one of these providers. Since it's a service with no extra charge, there is no reason whatsoever to not use it. Security software does not guarantee that your PC is 100% secure, but it is a first line of defense and enormously better than not having any security software installed.&lt;br /&gt;&lt;br /&gt;There is one cautionary note: All this security software will slow down your system a bit. Although most of the time performance degradation should be acceptable.&lt;br /&gt;&lt;br /&gt;And &lt;a href="http://reviews.cnet.com/4520-3513_7-5579803-1.html"&gt;here &lt;/a&gt;is some rationale why ISPs should provide free anti virus and firewall.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4112114114279396444-4514866413133135768?l=muni-on-security.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://muni-on-security.blogspot.com/feeds/4514866413133135768/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4112114114279396444&amp;postID=4514866413133135768' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/4514866413133135768'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/4514866413133135768'/><link rel='alternate' type='text/html' href='http://muni-on-security.blogspot.com/2007/11/list-of-isps-providing-security.html' title='List of ISPs Providing Security Software'/><author><name>Muni</name><uri>http://www.blogger.com/profile/17249152356013880281</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4112114114279396444.post-7839727372716229829</id><published>2007-11-18T14:24:00.000-08:00</published><updated>2007-11-18T14:58:06.083-08:00</updated><title type='text'>Postal Mail Phishing: Seller Beware</title><content type='html'>Steve Bellovin has posted an interesting story about credit card fraud on his blog (check "Security Blogs" on right). It is a lesson for credit card companies on how to better respond to frauds and it is amusing for us to read how stupid callers can get. This reminded me of a postal mail scam which I narrowly escaped some time back. Here is the story.&lt;br /&gt;&lt;br /&gt;We put an item for sale on Craigslist for couple of hundred bucks. Someone from New Jersey (we are on west coast) sent us an email showing interest in purchase and claiming that we do not have to ship the item, someone will pick it from our house and ship it to New Jersey. It was a little surprising that someone in New Jersey will buy a couple of hundred dollar used item from west coast and ship it. Still, the guy had promised to send us a check by UPS the next day, so we thought as long as we are getting the money its fine. Sure enough, the check arrived the next day by overnight UPS and lo and behold it was in the amount of $3000. I sent the guy email telling him that there seems to be a mistake. He responded that it is ok, I can deposit the check in my bank account and give the difference in cash to whoever comes to pick up the item. &lt;br /&gt;&lt;br /&gt;As you have guessed by now, I became suspicious, it did not make sense. So I searched on the Internet for company name that issued the check and company was located somewhere in mid west, but the person emailing me had purported to be located in New Jersey. This was the last straw and so I sent that guy another email calling the deal off. He tried to persuade me in following email exchanges (I insisted on talking over the phone, but he never gave me a number) that I should give the cash only after check has cleared etc. etc.  I could not figure out at the time how the scam works as the guy claimed that I have to give the cash back only after I see the money in my account. Still, I thought to play it safe and after couple of confused days in which lots of email exchanges took place, I did not take the bait and shredded the check. (For the curious, I had offered to return the check by snail mail, but obviously the guy did not care about a fake check, so he said that I can tear the check and throw it away. Even though, deal was off by this time, it confirmed my suspicion that something was amiss. No one sends a $3000 check into an unknown person's hands and trusts them to tear it.)&lt;br /&gt;&lt;br /&gt;So, it was a narrow escape and finally I found out how it works. The scam takes advantage of the clearing time gap between bank's transactions. When you deposit a check, banks show the money in your account right away, even though it may take upto a week to clear the check to really get the money in your account from another bank. Banks assume that check is good at the time of deposit (a correct assumption most of the time) and will let you withdraw the money within next couple of days. However, after a week or so when bank finds out that check was fake (because the account did not exist or for other reasons) they will revert the transaction and take away the money from your account. You deposited a check, that bounced, no harm done, right ! But that is if you did not pay the scammer a cash back. Most people when they see the money in their account assume that money is really there and would give a cash back to scammer. Most people do not know about details of the banks clearing. Once you have given cash to the scammer, he disappears and a week or two later, bank comes after you for the amount that you thought you had in your account. You are left holding the bag, bank will not reimburse you for this, as they were not at all involved in paying the scammer, you were.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4112114114279396444-7839727372716229829?l=muni-on-security.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://muni-on-security.blogspot.com/feeds/7839727372716229829/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4112114114279396444&amp;postID=7839727372716229829' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/7839727372716229829'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/7839727372716229829'/><link rel='alternate' type='text/html' href='http://muni-on-security.blogspot.com/2007/11/postal-mail-phishing-seller-beware.html' title='Postal Mail Phishing: Seller Beware'/><author><name>Muni</name><uri>http://www.blogger.com/profile/17249152356013880281</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4112114114279396444.post-195552677274774619</id><published>2007-11-17T19:41:00.000-08:00</published><updated>2007-11-17T20:09:51.574-08:00</updated><title type='text'>Should Users be Security Experts?</title><content type='html'>Does your mom need to know about security to access Internet safely? Bruce Schneier thinks that is not acceptable. Security is a complex topic, we can not expect everyone to know about it. No amount of user education is going to make users security experts and give them the ability to fight off all existing and future threats. Burden of security needs to shift on the Internet industry as a whole.&lt;br /&gt;&lt;br /&gt;I agree with what Bruce says. After hearing him speak, it seems obvious, but more efforts are required to make the idea popular. Clearly, industry has a vested interest in putting the responsibility on users.&lt;br /&gt;&lt;br /&gt;It is an interesting interview to listen.&lt;br /&gt;&lt;a href="http://connect.educause.edu/blog/mpasiewicz/e07podcastanintervie/45439"&gt;&lt;br /&gt;Listen Bruce here&lt;/a&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4112114114279396444-195552677274774619?l=muni-on-security.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://muni-on-security.blogspot.com/feeds/195552677274774619/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4112114114279396444&amp;postID=195552677274774619' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/195552677274774619'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/195552677274774619'/><link rel='alternate' type='text/html' href='http://muni-on-security.blogspot.com/2007/11/should-users-be-security-experts.html' title='Should Users be Security Experts?'/><author><name>Muni</name><uri>http://www.blogger.com/profile/17249152356013880281</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4112114114279396444.post-4370058784312477667</id><published>2007-11-17T19:14:00.000-08:00</published><updated>2007-11-17T19:19:54.100-08:00</updated><title type='text'>Dilbert Security</title><content type='html'>Dilbert is really getting into security.&lt;br /&gt;&lt;br /&gt;&lt;a href="http://dilbert.com/comics/dilbert/archive/images/dilbert2007113333116.gif"&gt;Nov 16 Dilbert&lt;br /&gt;&lt;/a&gt;&lt;br /&gt;&lt;a href="http://dilbert.com/comics/dilbert/archive/images/dilbert2007111111117.gif"&gt;Nov 17 Dilbert&lt;br /&gt;&lt;/a&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4112114114279396444-4370058784312477667?l=muni-on-security.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://muni-on-security.blogspot.com/feeds/4370058784312477667/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4112114114279396444&amp;postID=4370058784312477667' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/4370058784312477667'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/4370058784312477667'/><link rel='alternate' type='text/html' href='http://muni-on-security.blogspot.com/2007/11/dilbert-security.html' title='Dilbert Security'/><author><name>Muni</name><uri>http://www.blogger.com/profile/17249152356013880281</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4112114114279396444.post-6417697745220036896</id><published>2007-11-16T23:35:00.000-08:00</published><updated>2007-11-17T20:02:02.345-08:00</updated><title type='text'>Free Anti Virus: More ISPs</title><content type='html'>I found that AT&amp;T is not the only ISP providing free anti virus install service. This service has been provided by AOL since 2004.&lt;br /&gt;&lt;br /&gt;&lt;a href="http://reviews.cnet.com/4520-3513_7-5579803-1.html"&gt;Read here&lt;/a&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4112114114279396444-6417697745220036896?l=muni-on-security.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://muni-on-security.blogspot.com/feeds/6417697745220036896/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4112114114279396444&amp;postID=6417697745220036896' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/6417697745220036896'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/6417697745220036896'/><link rel='alternate' type='text/html' href='http://muni-on-security.blogspot.com/2007/11/free-anti-virus-from-aol.html' title='Free Anti Virus: More ISPs'/><author><name>Muni</name><uri>http://www.blogger.com/profile/17249152356013880281</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4112114114279396444.post-4996937560186483855</id><published>2007-11-15T19:09:00.001-08:00</published><updated>2007-11-15T20:50:50.356-08:00</updated><title type='text'>Finding Out External IP of a Router</title><content type='html'>The DSL and Cable routers have two IP addresses, one is visible on internal network that PCs on home network see and second is visible on external network that Internet sees. For various reasons one may need to find external IP address of the router. There are few ways to do that, but simplest is to goto the &lt;a href="http://checkip.dyndns.org/"&gt;this link (http://checkip.dyndns.org/) &lt;/a&gt;from a computer inside your home network. It prints the external IP address of the router.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4112114114279396444-4996937560186483855?l=muni-on-security.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://muni-on-security.blogspot.com/feeds/4996937560186483855/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4112114114279396444&amp;postID=4996937560186483855' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/4996937560186483855'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/4996937560186483855'/><link rel='alternate' type='text/html' href='http://muni-on-security.blogspot.com/2007/11/finding-out-external-ip-of-router.html' title='Finding Out External IP of a Router'/><author><name>Muni</name><uri>http://www.blogger.com/profile/17249152356013880281</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4112114114279396444.post-3549716270903413808</id><published>2007-11-15T10:10:00.000-08:00</published><updated>2007-11-15T10:29:10.314-08:00</updated><title type='text'>Security Humor 2</title><content type='html'>Some more security humor(courtesy Cryptogram):&lt;br /&gt;&lt;br /&gt;&lt;a href="http://www.dilbert.com/comics/dilbert/archive/dilbert-20071020.html"&gt;http://www.dilbert.com/comics/dilbert/archive/dilbert-20071020.html&lt;/a&gt;&lt;br /&gt;&lt;br /&gt;&lt;a href="http://www.dilbert.com/comics/dilbert/archive/dilbert-20071022.html"&gt;http://www.dilbert.com/comics/dilbert/archive/dilbert-20071022.html&lt;/a&gt;&lt;br /&gt;&lt;br /&gt;&lt;a href="http://www.cartoonbank.com/product_details.asp?sid=119416"&gt;http://www.cartoonbank.com/product_details.asp?sid=119416&lt;/a&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4112114114279396444-3549716270903413808?l=muni-on-security.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://muni-on-security.blogspot.com/feeds/3549716270903413808/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4112114114279396444&amp;postID=3549716270903413808' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/3549716270903413808'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/3549716270903413808'/><link rel='alternate' type='text/html' href='http://muni-on-security.blogspot.com/2007/11/security-humor-2.html' title='Security Humor 2'/><author><name>Muni</name><uri>http://www.blogger.com/profile/17249152356013880281</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4112114114279396444.post-7784596221883668270</id><published>2007-11-12T11:52:00.000-08:00</published><updated>2007-11-12T11:54:58.200-08:00</updated><title type='text'>Security Humor</title><content type='html'>A Random Number Generator:&lt;br /&gt;&lt;a href="http://thecryptoblog.indosec.org/wp-content/uploads/2007/01/dilbert.png"&gt;http://thecryptoblog.indosec.org/wp-content/uploads/2007/01/dilbert.png&lt;/a&gt;&lt;br /&gt;&lt;br /&gt;Intel Security Video: Who says security is not entertaining&lt;br /&gt;&lt;a href="http://www.youtube.com/watch?v=12Icxthmpis"&gt;http://www.youtube.com/watch?v=12Icxthmpis&lt;/a&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4112114114279396444-7784596221883668270?l=muni-on-security.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://muni-on-security.blogspot.com/feeds/7784596221883668270/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4112114114279396444&amp;postID=7784596221883668270' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/7784596221883668270'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/7784596221883668270'/><link rel='alternate' type='text/html' href='http://muni-on-security.blogspot.com/2007/11/security-humor.html' title='Security Humor'/><author><name>Muni</name><uri>http://www.blogger.com/profile/17249152356013880281</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4112114114279396444.post-4908769111738690230</id><published>2007-11-11T11:46:00.000-08:00</published><updated>2007-11-11T15:11:23.417-08:00</updated><title type='text'>Security Lessons from “Unbreakable”</title><content type='html'>Oracle did “Unbreakable” marketing campaign few years ago for its products. I stumbled upon the paper “Unbreakable: Oracle’s Commitment to Security”. This is one of the most comprehensive write up I have seen on the security process of developing, maintaining and after sales support specifically targeted towards security. This paper was released in February 2002, almost 6 years later it is still very relevant. There are lots of lessons that can be learned and applied for developing a process for secure software development. Of course, this is easier said than done, but if anyone is looking for a TODO list, this paper covers it all.&lt;br /&gt;&lt;br /&gt;&lt;a href="http://www.oracle.com/technology/deploy/security/pdf/unbreak3.pdf"&gt;Read it here.&lt;/a&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4112114114279396444-4908769111738690230?l=muni-on-security.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://muni-on-security.blogspot.com/feeds/4908769111738690230/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4112114114279396444&amp;postID=4908769111738690230' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/4908769111738690230'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/4908769111738690230'/><link rel='alternate' type='text/html' href='http://muni-on-security.blogspot.com/2007/11/security-lessons-from-unbreakable.html' title='Security Lessons from “Unbreakable”'/><author><name>Muni</name><uri>http://www.blogger.com/profile/17249152356013880281</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4112114114279396444.post-3588733944064472139</id><published>2007-11-11T11:39:00.001-08:00</published><updated>2007-11-13T15:26:29.361-08:00</updated><title type='text'>Good that I installed Norton Anti Virus</title><content type='html'>A system scan by Norton Anti Virus that I installed some time ago found “Trojan: ByteVerify” on my system and few other security risks. Very scary.&lt;br /&gt;&lt;br /&gt;There is a lesson for everyone: Never delay installing anti virus, anti spyware, anti spam tools on your PC especially if these softwares are freely available via ISP. Check with your ISP, and if you don't want to pay for it, it is worthwhile to switch over to a service provider that provides this service.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4112114114279396444-3588733944064472139?l=muni-on-security.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://muni-on-security.blogspot.com/feeds/3588733944064472139/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4112114114279396444&amp;postID=3588733944064472139' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/3588733944064472139'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/3588733944064472139'/><link rel='alternate' type='text/html' href='http://muni-on-security.blogspot.com/2007/11/good-that-i-installed-norton-anti-virus.html' title='Good that I installed Norton Anti Virus'/><author><name>Muni</name><uri>http://www.blogger.com/profile/17249152356013880281</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4112114114279396444.post-3232026824756591342</id><published>2007-11-05T17:21:00.001-08:00</published><updated>2007-11-06T11:08:02.911-08:00</updated><title type='text'>Free Security Software Install from ATT</title><content type='html'>I have thought many times that ISPs should be providing their customers with the tools to protect against viruses and spywares. Somehow I missed to include it in my wish list.&lt;br /&gt;&lt;br /&gt;Recently I checked my AT&amp;T DSL email and was pleasantly surprised to find that AT&amp;T DSL service provides software installation on the PC for Norton Anti Virus, Norton Anti Spyware and personal firewall free of cost (well not really, I am already paying for the DSL service).&lt;br /&gt;&lt;br /&gt;This is a very good step in the right direction. Now, just sending an email and asking people to install is not enough, they should be more proactive and engage people in some other ways like giving one time incentives. A one time discount on the monthly bill can motivate customers to actually install this software. Even though software installation is already free, so that is a good incentive, but we have to assume that majority of customers have no clue about security (ok, they are dumb) and they will not read the email. Many of those, even if they read it, will not actually do it. It includes yours truly. &lt;br /&gt;&lt;br /&gt;That ATT email has been in my inbox for a long time, but I did not bother to open it as it is just another marketing email. I do not know why I opened it, it was just a brain wave that prompted me. Once I opened it, thankfully anti virus installation was the first item, so it caught my attention, I still do not know what rest of the email is about. And even after reading it, I took many days before I thought of trying to install it. And now I am glad that I tried it. Process was intuitive and easy. One thing which did not make sense is that they refuse to install Norton Anti Virus if another spyware is installed on it. I know, you are thinking it should be Norton Anti Spyware and not Anti Virus that should complain, but that is how it is. Norton Anti Spyware installed without complain, even in the presence of another spyware software, but Anti Virus will not install unless I remove the other spyware software. May be it is an evil ploy of Norton to take over the world's PCs. Who knows? &lt;br /&gt;&lt;br /&gt;So I installed it, but one thing still worries me, what if AT&amp;T has installed its own trojan horse to track my web activities along with the free software. For now, I am willing to live with that risk, and hope that it is not the case.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4112114114279396444-3232026824756591342?l=muni-on-security.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://muni-on-security.blogspot.com/feeds/3232026824756591342/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4112114114279396444&amp;postID=3232026824756591342' title='1 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/3232026824756591342'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/3232026824756591342'/><link rel='alternate' type='text/html' href='http://muni-on-security.blogspot.com/2007/11/free-security-software-install-from-att.html' title='Free Security Software Install from ATT'/><author><name>Muni</name><uri>http://www.blogger.com/profile/17249152356013880281</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>1</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4112114114279396444.post-815097440132531613</id><published>2007-11-03T16:39:00.001-07:00</published><updated>2007-11-03T17:17:37.580-07:00</updated><title type='text'>A Look at Online Crime Economy</title><content type='html'>I found this article on CIO site to be an eye opener. I knew it is easy to compromise online presence of a person, but after reading this article, I could only conclude that threat is far worse than we imagine. A wrong URL visit, a wrong click, opening a wrong email, anything can put you at risk. Worse, even without any of our fault, a genuine URL access may cause a security incident if server hosting the URL is compromised. And with sneaky tactics where trojans lie dormant for a long time, and morph themselves continuously to evade detection from anti virus, there is no telling when it will strike. &lt;br /&gt;&lt;br /&gt;It is a cliche, but a system is only as secure as its weakest link. If we can be attacked we will be, even if we are security conscious, we may still be attacked via the servers we visit.&lt;br /&gt;&lt;br /&gt;Read the gory details here:&lt;br /&gt;http://www.cio.com/article/135500/&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4112114114279396444-815097440132531613?l=muni-on-security.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://muni-on-security.blogspot.com/feeds/815097440132531613/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4112114114279396444&amp;postID=815097440132531613' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/815097440132531613'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/815097440132531613'/><link rel='alternate' type='text/html' href='http://muni-on-security.blogspot.com/2007/11/look-at-online-crime-economy.html' title='A Look at Online Crime Economy'/><author><name>Muni</name><uri>http://www.blogger.com/profile/17249152356013880281</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4112114114279396444.post-3595660911126854513</id><published>2007-09-07T13:28:00.000-07:00</published><updated>2007-09-07T13:30:15.374-07:00</updated><title type='text'>An Effective Security Strategy</title><content type='html'>One of my colleagues suggested a very effective security strategy: let everyone in the world meditate :-)  People who meditate typically are calmer, stable and less willing to harm others. If everyone in the world meditates, everyone will be fair, forgiving, compassionate, honest, sharing, and non-violent. If it ever becomes true, all of us will be inherently secure and there will be no need of external security strategies. Not a bad idea, however Utopian it is.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4112114114279396444-3595660911126854513?l=muni-on-security.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://muni-on-security.blogspot.com/feeds/3595660911126854513/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4112114114279396444&amp;postID=3595660911126854513' title='2 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/3595660911126854513'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/3595660911126854513'/><link rel='alternate' type='text/html' href='http://muni-on-security.blogspot.com/2007/09/effective-security-strategy.html' title='An Effective Security Strategy'/><author><name>Muni</name><uri>http://www.blogger.com/profile/17249152356013880281</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>2</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4112114114279396444.post-5806524232936077404</id><published>2007-08-26T13:40:00.001-07:00</published><updated>2007-08-26T13:41:35.771-07:00</updated><title type='text'>A Security Wish List</title><content type='html'>I wish following things happened to make our online and offline lives more secure. Items here are in no particular order; I penned these down as they came to me.&lt;br /&gt;&lt;br /&gt;An application that detects that a worm is attempting to access my email address book, block it and alert me. It is surprising that this is one of the most common ways worms spread and still there is no effective protection against it. &lt;br /&gt;&lt;br /&gt;An effective defense against identity theft: Even though it is a big security issue, still the best defense one has is paid monitoring services. There should be a better solution.&lt;br /&gt;&lt;br /&gt;Secure Software: All software applications should be developed, installed and deployed secure by default. It is a hard problem to solve, but it is solvable. As a first step, software vendors must start developing with security in mind.&lt;br /&gt;&lt;br /&gt;Liability for security issues: Software vendors must be liable for software security issues. How many industries are there that can get away with sloppy products? It is amazing that software industry has gotten away with it as long as it has. Bad software affects our lives as much as any other bad product, perhaps even more. With identity theft on rise, which often is caused by security breaches because of software bugs, situation has become worse.&lt;br /&gt;&lt;br /&gt;Auto install prevention: OS should be capable of preventing installation of spyware and trojan horses. If an application install is not initiated by user or through a remote management application, why does OS allow installing an application? It defies logic. How many good software applications we know those are installed without user's (or administrator’s) knowledge?&lt;br /&gt;&lt;br /&gt;Use of Hardware Tokens: All online sites should come together and share a hardware token based security mechanism; similar to what Paypal and some of the banks support. There is initial cost associated with it, but it makes a compelling business case for long term.&lt;br /&gt;&lt;br /&gt;Internet Payment System: There should be only few Internet payment authorities that handle the monetary aspect of online transactions similar to credit card companies like Visa and Master. It makes no sense to give my credit card information to a large number of retailers; anyone of which can compromise it. I would rather trust a small number of companies and hold them accountable. In fact, Visa and Master can make themselves a gateway for Internet money. I wonder why none of the big credit card companies have done it yet?&lt;br /&gt;&lt;br /&gt;Security education: More people need to be educated of the security risks in a networked world. It is just not enough that people secure their own computing environment and hope that their personal information will not be compromised. How many computer systems store our personal information today? There is no way to find out. At least we have to be aware of the risks, even if we do not have control over all of it.&lt;br /&gt;&lt;br /&gt;Stop asking personal information unless absolutely necessary: Vendors and companies must stop asking personal information (especially social security number) when not required. A friend of mine wanted to file a flexible spending claim (for those who do not know, it is a service that let’s you claim your medical expenses tax free within a certain limit). The claim form asks for social security number, he called up the service and told them that he does not want to provide this information written on a form. They immediately agreed to process the claim without that number. This was actually a surprise to my friend who was expecting an excuse. That makes me wonder why they even have that field on the form. It’s perhaps convenient to use that number in the software, but cost of that convenience could be very high for an individual.&lt;br /&gt;&lt;br /&gt;Stop giving personal information unless absolutely necessary: Another side of the coin applies to us, the people; collectively we should start refusing giving personal information when common sense tells us that it is not necessary. As an example, when you register in a flight school, the form asks for social security number. Why does a flight school need that number? When you sign up for a gym, they ask for social security number. Why does a gym need your social security number? If you do not pay up, they can block your access. Perhaps there can be arguments about reporting it to credit bureaus etc. but it is a weak one. In fact, it is an easy way for someone to mount a social engineering attack on anyone’s credit history. Let us first refuse to give the number and then see what happens. More often than not, they will still let you join.&lt;br /&gt;&lt;br /&gt;Mandatory disk encryption: All corporations and government organizations must be enforcing disk encryption as a best security practice. There is very often news of lost laptops that cause loss of millions of personal records. It should not come as a surprise that such news items not only come from government organizations but also from private companies. Both sectors have very weak protection in this regard. Why can’t these organizations mandate disk encryption for their laptops? No one uses company owned laptops without passwords today; (if password enforcement is not part of security policy, it’s a serious problem in itself) so why use it without disk encryption? There will be certainly costs associated with it, but less than what it costs to repair the damage when millions of personal records are compromised because of careless behavior of company’s employees. As a customer group we should demand such security features as a minimum level of entry. Moreover, as the technology spreads costs will go down.&lt;br /&gt;&lt;br /&gt;Secure wifi: Wireless networks must be secure by default. It is easier said than done, but it closes a big security hole.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4112114114279396444-5806524232936077404?l=muni-on-security.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://muni-on-security.blogspot.com/feeds/5806524232936077404/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4112114114279396444&amp;postID=5806524232936077404' title='1 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/5806524232936077404'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/5806524232936077404'/><link rel='alternate' type='text/html' href='http://muni-on-security.blogspot.com/2007/08/security-wish-list.html' title='A Security Wish List'/><author><name>Muni</name><uri>http://www.blogger.com/profile/17249152356013880281</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>1</thr:total></entry><entry><id>tag:blogger.com,1999:blog-4112114114279396444.post-2938210727268333947</id><published>2007-08-18T18:14:00.000-07:00</published><updated>2007-08-18T18:24:33.535-07:00</updated><title type='text'>Security and Virtualization</title><content type='html'>Virtualization has been a hot topic since last few years and if you have been following the rise of VMWare, with good reason. Virtualization can increase the resource utilization on servers and desktops (although not as common today, this is the next push for major virtualization players). It also helps reduce real estate, power and cooling costs, management overhead and downtime. Undoubtedly, with so many benefits, it is hard to deny the ROI. How does it all affect security? With the current paradigm of security focusing on physical devices, it is interesting to investigate this.&lt;br /&gt;&lt;br /&gt;Better Control&lt;br /&gt;In one sense, virtualization makes systems more secure. A virtual server can be easily rolled back to a previously known good state in case of virus and worm attacks. With a physical server it is so harder to do, but with virtual machines, if you have enabled snapshots, it is a piece of cake. &lt;br /&gt;&lt;br /&gt;Security Issues Still Remain&lt;br /&gt;Although one has a better control in terms of rollback and installation of OS image, all the security issues still remain. Virtualizing the hardware is not getting rid of other security issues such as system breach, data compromise, network attacks and so on. All the security pieces are still required for the protection of the network and systems in general. One still has to use firewalls, anti virus softwares, Intrusion Prevention/Dectection systems to protect the network.&lt;br /&gt;&lt;br /&gt;Cost of Security&lt;br /&gt;Cost of security in a virtualized environment can be significantly reduced by the properly architected network. The security software license costs will still remain the same assuming you are running same number of servers, however overall costs in terms of patching, maintenance, re-imaging the physical machines in case of virus/worm infections can be signifincantly reduced. In server farm environment, affected servers can be simply deleted, and recreated. Even better, a data center can be architected such that virtual servers keep getting re-imaged every few hours/days/weeks. This provides better security protection against all kinds of unknown security attacks which are not yet publicly known but available in the wild for exploits. Because server is constantly being re-imaged, even if it was compromised, after re-installation attacker has lost it. If the underlying exploits are not fixed, system can be again compromised, but in this cat and mouse game of security it gives you a leg up by destroying the bad things which happened.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/4112114114279396444-2938210727268333947?l=muni-on-security.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://muni-on-security.blogspot.com/feeds/2938210727268333947/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=4112114114279396444&amp;postID=2938210727268333947' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/2938210727268333947'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/4112114114279396444/posts/default/2938210727268333947'/><link rel='alternate' type='text/html' href='http://muni-on-security.blogspot.com/2007/08/security-and-virtualization.html' title='Security and Virtualization'/><author><name>Muni</name><uri>http://www.blogger.com/profile/17249152356013880281</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry></feed>
