Security in Website Design - Research Paper Example

Introduction The rapid development of Information and Communication Technology (ICT) has led to the unprecedented growth of the World Wide Web both in terms of coverage and importance. The World Wide Web not only covers the entire world today, but is also being increasingly used by a growing majority of people the world over. Financial transactions through the web gave a completely new dimension to information sensitivity on the Web. Each website began to accumulate information or data that could be potentially misused. “Networked computer systems have become critical not only for conventional commercial and financial transactions, but for ad hoc informal, social interactions. These two uses of network infrastructures represent the two ends of a range of possible ways in which these infrastructures are being appropriated and utilized as sites of organizational practices as well as people’s work and everyday accomplishments. By the same token, they demonstrate the range of challenges in designing and implementing usable private and secure systems.” (Paula et al. 2005, pp. 25) Just as in the physical world, in the virtual world of the Web too a new type of cyber criminals emerged. Information is money on the Web, and cyber criminals began targeting information that they were not authorized to access or utilize. It was at the face of such an evolving situation that ‘security’ assumed overwhelming significance in the entire ICT gamut. The computer system had to be protected, the communication network had to be protected and the websites and the web servers had to be protected. The Importance of Designing for Website Security Access control through firewalls, maintaining information confidentiality through strong encryption processes, a range of intrusion detection systems, anti-virus and anti-phishing software are being deployed to provided security to information on the web and the Internet. While evolving technology offers many such security solutions for protecting the network as a whole, the servers and the client systems used to access the Web, a great deal also depends on the how websites are designed. “When a hacker attacks a network with no direct access to the internet, the first step is getting a user to access a malicious file or web site” (Borders & Prakash, 2004, pp.110). The design of any website has to take security into account right from the conceptualization and planning stages. This is essentially because of a second dualism that exists in the web-user interface – the balance between security and usability. Interface comprise the eight elements of navigation, site organization, searching ease, user-controlled navigation, links, cross-platform design, writing style, and multimedia capabilities (Song & Zinkhan, 2004, pp. 2). Again, it has been argued that what is crucial in providing security that is usable is that it is not just about designing systems and infrastructures that are more secure and trustworthy, but it is all about designing systems such as websites which are effectively secure rather than theoretically secure (Dourish et al. 2004). The fact is that theoretical security is always less effective than practical security i.e. unobtrusive security that can be practically implemented on a day-to-day basis. The concern in this case is that usable security is about the ways in which the users of the website would experience both privacy and security, albeit a technology, in routine life (Dourish and Anderson, 2005) and work given that the web is now as ubiquitous as was the telephone in earlier days and the personal computer in recent times. Moreover, effective security can come only with the full knowledge and participation of the users of a website. In fact security features have to be made visible enough to website users so that they are able to make informed decisions on the transactions and information exchanges they make, about the potential privacy and security problems that are inherent in such transactions and actions. Thus we find a clear indication of security infrastructures, including websites, being designed in a manner in which the security mechanisms applied are visible to the user in terms of their configurations, and related activities and their implications, so that the decisions of users are informed, and their actions are co-coordinated and appropriate to the security situation at hand. The Basic Security Considerations Security has to be taken into account in the entire development lifecycle of a website from initial conceptualization and planning through information structuring and categorization and coding and scripting to deployment, management and operation. The first task is to define the risks and assess them. Defining the risks would involve specifying the security requirements, deciding how the information is to be classified into different categories depending on their sensitivity. Sensitivity implies the impact that unauthorized access, modification; loss or disclosure of such information would have on the business. This would in turn identify the areas where the maximum security would have to be provided. An effective security policy would then have to be formulated and implemented. The assessment would however depend on the nature and information content of the website. If the website does not include any confidential information, then all that would be required would be a security policy with the minimal standards. However, if the website is more complicated and the content is sensitive in nature, then it is advisable to construct a threat model to identify both the threats and the vulnerabilities of the website. As already stated, website security is not oriented only around preventing information damage or theft but also consists of other factors such as usability of the website. Security would also include ensuring that the speed of the website adequate, that it complies with all regulatory and legal norms, is able to provide accurate and relevant data, is not cost prohibitive and, most important of all, is able to update security measures according to requirements and prevailing situations. It is therefore a balancing act between security, usability, cost considerations, legal implications, information relevance and effectiveness. The security level of a website is decided based on all these considerations (Tsygankov, 2004, pp. 265). The website design should incorporate provisions to validate all data on input and on output to provide security to users and their systems. A website does not only have content or inputs flowing in form its users but also from other sources such as RSS feeds, data purchased from external parties and from the organization’s own backend systems or that of other business partners. None of this data should be taken at face value and trusted and the mechanism for validation of such data should be built into the system. The design of the development process of the website should have security review factored in at all crucial phases and milestones of the development process, and the design should be flexible enough to be able to accommodate any changes necessitate by any contingency security requirement. The earlier a security risk or threat is anticipated the cheaper it is to mitigate. Software has always been a nagging source of threat. Any loopholes in the website codes or software could pose a potential threat. Attacks which are browser-based are usually oriented around the vulnerabilities of JavaScript codes (Yue & Wang, 2009, pp. 961). The design of the website should enable developers to work along a well-defined, and chalked out path following strict coding norms so that the end result is high-quality code that does not compromise on security. Ensuring that all software have the latest patches and upgrades as a part of the website design could go a long way in avoiding security problems (Carnaghi, 2004, pp. 3). Structured testing for security is a must. The design of the website should be tested not only for the intended but also for the forbidden or prohibited functionalities to judge the response of the security features in place. Adequate logging of website activities will allow auditing of the activities to detect abnormal activity, and get to the roots of any problem that may occur. The highest level of security risk is encountered at the deployment stage. Care has to be taken to deploy the website in a very controlled environment so that it can be ensured that all security measures are in place and nothing is left to chance. Finally, the design of the website should inevitably include disaster recovery and business continuity measures to fall back upon. All scenarios that could lead to the loss of availability of the website and the resultant impact on the business should be carefully analyzed before deciding on the disaster recovery and continuity measures that could be put in place. The design should be such that every conceivable security risk or threat is first identified, taken into consideration and assessed. Such risks are thereafter eliminated, reduced, insured for or accepted by the design of the website itself. Secure Socket Layer and Security Design SSL or Secure Socket Layer is a website security technology that is almost universally adopted by all design approaches. The Secure Socket Layer is a dominant security technology on the web which has facilitated the growth of e-commerce and other services which require high security for success. SSL technology today is the end product of long years of public scrutiny, and therefore holds a place of its own as far as trust and reliability are concerned. SSL is actually security at the Transport Layer of the TCP-IP protocol and is indicated by https which signifies http over SSL (Shin, 2008, pp. 5). Developed by Netscape in 1996, SSL is now the preferred method of securing data transfer over the Internet. At the core of SLL technology is the use of the public-and-private key encryption system. SSL provided privacy and confidentiality and ensures data integrity or protection against data tampering. SSL however instills trust and reliability by server authentication in the case of Business-to-Citizen (B2C) transactions and also optional client authentication in the case of Business-to-Business (B2B) transactions. Authentication implies ensuring that a web entity is who or what it claims to be. Server authentication verifies whether a server is actually what it claims to be and not a malicious threat. An SSL connection is allowed only if the server has digital certificate installed (Thawte, 2009). The digital certificate is actually an electronic file with the unique identifications of its holder be it an individual or a server. Digital certificates are issued or signed by an independent and trusted third party known as the ‘signer’ of Certifying Authority (CA) such as VeriSign and Thawte (Lizard, 2004, pp. 3). The other security mainstay of SSL is Encryption or the process of coding or ciphering information into a form that unintelligible to all. The transformed information is deciphered for the intended recipients. This ensures that only the intended recipient is able to access the information. In the public-private key encryption system, both the parties between which information transaction takes place have a pair of keys and mathematical codes that could provide them access to the information. One of these keys is a private one which must be kept secret and the other is a public one which is made public. Information is encrypted with the help of the combination of the sender’s private key and the recipient’s public key. This encrypted information can be decrypted only with the combination of the recipient’s private key and sender’s public key. Information security is ensured in this manner. Transport Layer Security (TLS) is the successor to SSL and provides stronger security for websites (Webmasterjm, 2009, pp. 1) Server-side Design Securities and User Participation Proper web design entails implementation of certain features at the server-side that could not only offer greater security but also help the website user be more aware of potential security threats and act accordingly to thwart such risks. Lapses in server-side design of websites confuse users and could result in major security compromises. Five such major design flaws identified by Falk, Prakash and Borders (2008, pp. 3) have been termed as follows: 1. Breaking the chain of trust that is required between the user and the website provider. 2. Presenting secure login options on insecure pages. 3. Providing contact information or security advice. 4. Inadequate policies for user ids and passwords. 5. Emailing security-sensitive information insecurely. A well-designed website would provide users with adequate security indicators and context so as to enable them to distinguish between content that is trustworthy and content that is not and could be malicious. This is what is defined as developing a chain of trust. Using Secure Socket Layer or SSL-protected pages in a website is a good example of how the design tries to provide users with such context. The padlock icon of SSL websites on the browser status bar is the first indication to the user that the site is SSL protected. It also indicates to the user that the site and its content can be trusted. The user may then look for the ‘https’ indication to confirm the SSL status. Once it is confirmed, website is taken to be secure, and can be defined as ‘root of trust’ (Falk et al. 2008, pp. 4). It is at this point that design of a website can play a crucial factor in ensuring or breaching security. Many website designs commit the blunder of redirecting the user to a second site with a domain name that is different from that of the original root of trust. This is a breach of trust and could lead to a potential lapse in security as the user is either completely unaware of the fact that he or she is out of the security shield, or is not sure whether the second domain is as secured or not. The chain of trust is thus broken and it is entirely up to the user to determine whether the new site is actually linked with the original root of trust or it is just an unrelated window which has popped up due to the unintentional triggering of some event or, in the worst-case scenario, as a result of a malicious threat or attack. The design of websites will therefore have to take into account all such incidents that may result in breaks in the chain of trust, and ensure that the user is pre-informed about the security status of the new site. The entire design effort should be concentrated around seamless browsing for the user without raising any security concerns. Users should never be presented with difficult or confusing security situations. In other words, the user interface must be contextual and not restrictive, it should be able to provide the user with transaction details, including the identity of the other party; it should leave minimal visual footprints, and it should guide the user on how to proceed (Camenisch, et al. 2006, pp. 42). The design of a website should not only ensure full security, but also provide the requisite security assurance when it comes to login pages. There are many examples of websites in which login pages and options are given on non-SSL pages making the user vulnerable to attacks such as man-in-the-middle. Such a problem arises, for example, when a secure JavaScript login window is on a non-SSL protected page. This could allow a man-in-the-middle or DNS-hijacking attack to spoof the whole page including the JavaScript login window. Adhering to the principle that it is important to secure the context along with the data channel makes for good website design. For example, putting contact information or security advice on a non-secure page is like putting up red herring for phishing and spoof attacks. The particular page can be easily modified to mislead customer into divulging sensitive information, thus compromising the security of the website. A strong website design will always incorporate strong policies for user ids and passwords (Reynoso, 2009, pp. 2). User ids and passwords are invariably in the first line of attack. Allowing email ids or social security numbers as user ids make the job of hackers easier because it is not very difficult to guess or actually trace such information out. If the design of the website does not include a firm policy for passwords, and allows weak passwords, the accounts may not be able to stand up to dictionary attacks. Finally, any website design which includes email traffic has to ensure that the email server is a secure one. Sensitive unencrypted information sent through an insecure email server is liable to be intercepted by attackers. Passwords or account statements sent through insecure email could spell financial disaster for the account holder. Phishing and Website Design Phishing attacks are designed to fool the user into divulging sensitive information by the use of fraudulent websites. The information is then misused by the attacker. Though website design has tried to counteract phishing attacks by providing various security indicators in websites, yet the ordinary user finds it very difficult to distinguish between legitimate and phishing sites. It has been found that phishing attacks takes advantage of the lack of computer and security knowledge of users and indulges in visual deception by creating dummy pages, texts or sites to deceive users. The best phishing sites are able more than 90 % of participants trained to detect fraudulent sites. (Dhamija et al., 2006, pp. 9). This indicates that the design approaches being adopted are not being able to meet the security requirements of websites because they may not be based on the practical capabilities of users. Empirical data also suggests that adoption of automated processes to take the user out of the decision making process in website security have inherent limitations based on human and social factors (Edwards et al. 2007, pp. 40). Under the circumstances it is urgently required to base new design approaches on the actual capabilities of users. It is more important incorporate security alerts for insecure conditions than security indicators for secure conditions as they are now. Also, security indicators should always be visible within the user’s periphery of concentration or focus of attention for them to be effective. Comparing Research Methodologies Falk et al. (2008) used automated software to analyze 214 websites of financial institutions for the security design flaws that they were looking for. The security design flaws were manually confirmed after being identified by the automated tool. The study preferred to use a second software to initially recursively download all the 214 websites. For identifying and analyzing breaks in the chain of trust of websites they ran the automated tool with two given conditions – insecure pages making a transition to secure pages and secure pages transiting to secure pages without any introduction or assurance whatsoever. For design flaws in login options, the Falk et al. (2008) used the automated tool to look for the strings ‘login’, ‘user id’ and ‘user password’. Once pages with these strings were detected, the study verified whether the login pages were secured or not and whether the JavaScript login window submitted the input data through SSL or not. In the case of contact information or advice that contained sensitive information and could compromise the security of the website, the automated tool was used to search for the strings ‘contact’, ‘information’ and ‘FAQ’. The study then verified whether the pages which contained the strings were secure or not. Websites were searched for matches of ‘email’, ‘social security number’ or ‘address’ against ‘login’ or ‘user id’ to identify user ids that could be guessed easily; similarly, after the tool identified pages with the string ‘password’ they were analyzed to find whether they had any policy for passwords on the basis of strings such as ‘recommendation’, ‘strong’ and ‘setting’. To find out if there were security lapses in the design as far as sending sensitive information over email was concerned, the automated tool was used to search for the strings ‘statements’, ‘passwords’, ‘sending’ and ‘email’ and the finds analyzed for proximity to each other. In the study conducted by Dhamija et al. (2006) on why phishing attempts can fool even seasoned and experienced users, a usability study was conducted to find out practically to what extent the participants of the study could distinguish between spoofed and real websites. The participants were presented with both websites that actually belonged to financial institutions and e-commerce companies and other which appeared to belong to such institutions. The participants were required to distinguish between the legitimate and fraudulent sites, and to give reasons on the basis of which they had come to their conclusions. The study was conducted on 22 participants. The basic eligibility requirement was that the participants had to be familiar with computer use, email and the Internet or Web. A majority of the participants selected were in non-technical fields of study whereas a minority was in technical fields so as to emulate as closely as possible a real-life sample population. The participants were however trained to look for fraudulent websites and identify security indicators on secure websites. A web archiving application software was used by the study to collect 200 unique phishing sites, out of which nine were sued for the study based on how representative they were of usual characteristics of phishing sites. Further, three additional phishing sites were created by the study based on advanced phishing attack features to include characteristics that were not represented in the collected sample. Each participant was presented with all the websites, but in random order. The participants were required to go through a total of 20 legitimate and fraudulent phishing websites. The main distinction between the research methodologies of the two studies is in their dependence on automated tools. While the study conducted by Falk et al. (2008) depended heavily on a software application for identification of security design flaws, the Dhamija et al. (2006) depended more on the empirical findings from a sample of participants. The Falk study was more controlled but restrictive in the sense that conditions were fed into the automation tool to obtain specific results. The security design flaws were pre-identified by the researchers leaving no possibility for the identification of new flaws. The conditions that were set to search out the flaws were also limited to those which the researchers thought were within the scope of their studies. In practical website interfaces there could be many other situations where design lapses could result in compromise of website security. The study confirms the findings of the software application through human interventions, but it in no way tries to go beyond the scope set for the software application searches. The research methodology adopted by the study is adequate for the objective of the study – that is to point out how design flaws could lead to security compromises or weaknesses; however the methodology is restricted when it comes to finding our the broad range of design flaws that could be responsible for security breaches. The Dhamija study on the other hand is more empirical in the sense that it uses a sample of participants to gauge to what extent users can be fooled by phishing attacks assuming that all best practices of website design for security are adopted. However, the study also utilizes a software application to initially identify and collect examples of phishing sites. It then complements the sample phishing sites by adding three more phishing sites especially created for the purpose, and based on the characteristics of the best phishing sites available. The study tries to bring in control by training the participants on what to look for in trying to distinguish between genuine and fraudulent sites. On the whole, the Falk et al. (2008) conducted a study which is more restricted in scope and therefore adopted a research methodology which is limited but suitable for the job at hand; on the other hand, Dhamija et al. (2006) conducted a study with a broader scope, and therefore adopted a research methodology which could take more variables into consideration and bring them under the purview of the study. Research Proposal Designing a secure website has to take several factors into consideration both at the server end and at the client end. It is however clear that a website can never be totally secure at the face of rapid evolution and development of new malicious attacks. Falk et al. (2008) has pointed out some the loopholes that security design lapses could lead to in the area of user involvement. Dhamija et al. has also shown that even when assuming that all design norms are followed, phishing attacks are likely to deceive a majority of users. The study has advocated a total change in the design approach. As malicious attacks grow more and more sophisticated, it will be all the more difficult for convention security design approaches to keep up with them. The key to an effective solution in such a situation would be the user. The need of the hour is to design websites in a manner in which the user is kept aware all the time of the security threats that may be faced. This has to be done in a way in which it becomes mandatory for the user to heed the security indicators. But the security indicators also have to be within the capability of the users to recognize and interpret. Every website design could incorporate a security prompt window which alerts the user to security threats, and at the same time, also offers choices of actions that can be opted for without jeopardizing the security of the website. Research Statement It is proposed to undertake a study to ascertain the information elements that could be effective in guiding the web user securely through every web access experience. The objective of the study will be to translate present security indicators into more comprehensible prompts at all threat junctures. The Research Methodology The research methodology would have to comprise an initial survey, preferably through a questionnaire, followed by more controlled sample study of participants. The survey, with a properly designed questionnaire, would provide the general basis on which to initially design the security prompts. The participants would have to be randomly selected with the only eligibility condition being that they would have to be familiar with computer systems and web access. A sample of websites will also have to be selected. This sample will have to be representative of most of the major security design lapses. The experiences of the users as they browse through the sample websites will have to be recorded and analyzed. The analyses of the data obtained will indicate where and how the user made wrong decisions. The study will then have to again take inputs from the same users to find out what kind of security prompts would have made it possible for them to avoid the security situations that they faced without disrupting their browsing experience. The study will attempt to fix the broad outlines of effective security prompts that design of websites could incorporate. References Borders, K., Prakash, A., 2004, Web Tap: Detecting Covert Web Traffic, University of Michigan, ACM 1-58113-961-6/04/0010 Camenish, J., shelat, a., Sommer, D., Zimmermann, R., 2006, Securing User Inputs for the Web, IBM Research, Zurich Laboratory, ACM 1595935479/06/0011 Carnaghi, B., 2004, Web & Internet Security Considerations, Available. http://www.webpointmorpheus.com Dhamija, R., Tygar, J., D., Hearst, M., 2006, Why Phishing Works, ACM 1-59593-178-3/06/0004 Dourish, P., & Anderson, K., 2005, Privacy, security… and risk and danger and secrecy and trust and identity and morality and power, Understanding collective information practices: Irvine, CA: Institute for Software Research. Technical Report UCI-ISR-05-1. Dourish, P., Grinter, R., Delgado de la Flor, J., and Joseph, M., 2004, Security in the Wild: User Strategies for Managing Security as an Everyday, Practical Problem. Personal and Ubiquitous Computing. Edwards, W., K., Poole, E., S., Stoll, J., 2007, Security Automation Considered Harmful? ACM 978-1-60558-080-7/07/09 Falk, L., Prakash, A., Borders, K., 2008, Analyzing Websites for User-Visible Security Design Flaws, Symposium on Usable Privacy and Security (SOUPS), 2008, Pittsburg. Lizard, A., 2004, Security Considerations for Website Developers, Available. http://www.informit.com/articles/article.aspx?p=332280 Paula, R., D., Ding, X., Dourish, P., Nies, K., Pillet, B., Redmiles, D., Ren, J., Rode, J., Filho, R., S., 2005, Two Experiences Designing the Effective Security, Institute for Software Research, University of California. Reynoso, R., 2009, Three Steps to greater Website Security, Webology eBusiness Solutions. Shin, S., 2008, SSL, Available. http://www.javapassion.com/j2ee/SSL.pdf Song, J., H,. Zinkhan, G., M., 2004, Features of Website Design, Perceptions of Website Quality, and Patronage Behavior, University of Georgia. Thawte, 2009, Securing your Online Data Transfer with SSL, Available. http://www.atomki.hu/atomki/CompGroup/2share/Securing_your_online_data_transfer_wih_SSL_.pdf Tsygankov, V., A., 2004, Evaluation of Website Trustworthiness from the Customer Perspective, A Framework, ICEC 2004, ACM 1-58113-930-6/04/10 Watson Hall Ltd, 2009, Top 10 Security Tips for Website Design, London Webmasterjm, 2009, Website Security, Available. http://www.webmasterjm.com/index.php/security-information Yue, C., Wang, H., 2009, Characterizing Insecure JavaScript Practices on the Web, International World Wide Web Conference Committee, ACM 978-1-60558-487-4/09/04 Read More