Lesson 17-Web Components

1. Lesson 17-Web Components

2. Background • The World Wide Web was invented by Tim Berners-Lee in 1990 at the European Laboratory for Particle Physics (CERN) to give physicists a convenient method of exchanging information. • A common architecture was developed: • A common addressing scheme built around a Uniform Resource Locator (URL). • Linking documents with URLs through the Hypertext Markup Language (HTML). • Before the World Wide Web, the following methods were used to perform e-mail, chatting, games, and file and information sharing : • File Transfer Protocol (FTP) to move files. • Telnet to access other machines.

3. Current Web Components and Concerns • There are three main security tasks: • Securing a server to deliver content to users over the Web. • Securing the transfer of information between over the Web. • Securing the user's computer from attack through a Web connection. • Encryption • SSL and TLS • The Web • HTTP and HTTPS • Web Services • Directory Services (DAP and LDAP) • File Transfer • FTP and SFTP

4. Encryption (SSL and TLS) • Encryption: Secure Socket Layer (SSL) developed by Netscape and used in e-commerce • All browsers and Web servers support SSL. • Virtually, all sensitive financial traffic uses SSL • The Internet Engineering Task Force (IETF) embraced SSL in 1996 through a series of RFCs and named the group Transport Layer Security (TLS). • SSL 3.0- • RFC 2246 - “TLS Protocol Version 1.0” • RFC 2712 Added Kerberos authentication • RFCs 2817 and 2818 -Extended TLS to HTTP version 1.1 (HTTP/1.1) • TLS begins with an equivalency to SSL 3.0. • SSL and TLS are essentially the same protocol, but not interchangeable.

5. Encryption (SSL and TLS) • SSL/TLS is a series of functions within the OSI model which reside between the application layer and the TCP/IP implementation in the transport and network layers. • TCP sends an unauthenticated error-free stream of information • SSL/TLS adds message integrity and authentication through cryptographic • SSL/TLS can use separate algorithms and methods for: • -Encryption • -Authentication • -Data integrity • Each of these is negotiated and determined before the session starts.

6. How SSL/TLS Works • SSL/TLS uses cryptographic protocols. • The client requests for a secure connection and the server responds. • Both systems agree on a commonly held protocol (SSL v1, v2, v3, or TLS v1). • Commonly available cryptographic algorithms include Diffie-Hellman and RSA. • The handshake begins with the exchange to agree on parameters. • The systems exchange certificates and keys to enable authentication. • Certificate exchange is done via X.509 certificates. • Public key cryptography is used to establish authentication.

7. How SSL/TLS Works • The session continues • Once authentication is established, the channel is secured with symmetric key cryptographic methods and hashes, typically RC4 or 3DES for symmetric key and MD5 or SHA-1 for hash functions. • Session certificates • The use of certificates is a way to have a third party act as a notary • Certificates provide a method of proving who someone is, provided you trust the issuer.

8. SSL/TSL Certificates • SSL/TLS is designed to provide protection from man-in-the-middle attacks. • By authenticating the server end of the connection, SSL/TLS prevents the hijacking of a session. • By encrypting all of the conversations between the client and the server, SSL/TLS prevents eavesdropping certificate management options.

9. The Web (HTTP and HTTPS) • The Hypertext Transfer Protocol (HTTP) is the protocol for the transfer of hypertext-linked data over the Internet in plain text. • HTTPS encrypts the session data using either SSL or the TLS • Designed to run on top of TCP/IP, it can operate over lower-level protocols • It can’t function over a non-reliable protocol such as (UDP).

10. Vulnerabilities • Even though SSL/TLS is enabled, the user is not necessarily safe. • A Trojan program can records keystrokes and send information to an unauthorized user, • If the user connects to an untrustworthy site, a secure connection does not prevent the other site from running a scam. • Credit card information can be “lost” by the receiving company.

11. Web Services • A Web Service application is an application that interacts with the world using XML for data definition, WDSL for service definition and SOAP for communication with other software. • XML schemas and WDSL object definitions handle interaction with the host OS and all the network communication relating to access of the application’s objects. XML Schemas define communication interfaces and carry information between Web Services • SOAP is a method of invoking remote procedures over the Internet and is a framework for generalized XML messaging between applications. • Universal Description, and Discovery and Integration (UDDI), A Web-based distributed directory enables businesses to list themselves on the Internet and discover each other, similar to a traditional phone book's yellow and white pages. .

12. Vulnerabilities of Web Services • The focus of an attack is the application’s Web interface, specifically, exploit vulnerabilities created by errors in the implementation of the interface. • A browser can be used to exploit a Web application vulnerability and then use the Web Server’s resources and privilege to access the app or attack it: • Vulnerabilities exist with XML , HTTP, SOAP Structure, WSDL, application vulnerabilities • A risk is associated with the actual Web Service code itself and the application programmer must develop secure code.

13. Directory Services (DAP and LDAP) • A directory is a data storage mechanism like a database with a network interface. • The data is hierarchically described in a tree-like structure. • The X.500 standard was created as a standard for directory services. • An X.500 directory is accessed through the Directory Access Protocol (DAP) and is difficult to implement on PCs. • This led to the Lightweight Directory Access Protocol (LDAP), which contains the most commonly used functionality and is the internet standard. • LDAP can interface with X.500 services. • LDAP can be used over TCP with fewer computing resources than full X.500 implementation.

14. SSL/TLS LDAP • LDAP over TCP is a plaintext protocol. • The LDAP server responds to specific queries • SSL/TLS provides several functions to LDAP services. • The SSL/TLS functionality secures the communication channel, • SSL/TLS establishes the identity of a source through certificates. • LDAP and SSL/TLS are separate independent protocols. • Interoperability requires correct setup.

15. FTP/SFTP • FTP is the protocol for exchanging files over the Internet in clear text. • Like HTTP and SMTP, FTP uses TCP/IP • A standard account called anonymous exists by default. • On a server, access permissions should be established to allow only downloading or only uploading or both. • Secure FTP (SFTP) should be used for confidentiality. • SFTP utilizes both Secure Shell (SSH) protocol and FTP to accomplish this task. • SFTP is an application program that encodes both the commands and the data passed. • SFTP must be on both the client and the server and is not interoperable with standard FTP. • SFTP operates in a similar way as FTP with a username and password • There is no anonymous SFTP account by definition.

16. Code Based Vulnerabilities • Browser functionality has grown to match different types of data transmitted, but plugins are still needed. Plugins are pieces of code written by third parties and distributed via the internet to increase a browser's ability to handle new data types and add new functionality. They may include malicious codes: • Buffer Overflows • Java and JavaScript • ActiveX • CGI • Server-Side Scripts • Cookies • Signed Applets • Browser Plug-Ins • Your trust in plug-ins should be based on knowing whom you are trusting.

17. Buffer Overflows • Fifty percent of the security incidents are from buffer overflow exploits. • When any program places data into a buffer and does not validate the input for correct length, the potential for a buffer overflow exists. • It is the result of poor programming practices. The concept is simple. • A hacker writes an executable and appends his code fragment to a legitimate response to a program on the target machine. • When the target machine reads through the too-long response, a buffer overflow condition causes the original program to fail. • The extra malicious code fragment is now in the machine's memory, awaiting execution. • If the hacker executed it correctly, the program will skip into the hacker's code, running it before failing.

18. Java and JavaScript • Java is based on the C language and was designed to be platform-independent. • Java and JavaScript operate through an interpreter called a Java Virtual Machine (JVM) on each platform • Java was designed to be used in trusted environments. • When it moved to the Internet, safety became an advertised benefit but safety is not security. • When the program is downloaded and run from the Internet, data may be sent across the Internet to an unauthorized user. • Writing data to the hard drive may cause deletions. • JavaScript runs within the browser; the code is executed by the browser itself. • it doesn’t access files or network resources directly, except through the browser functions.

19. Java and JavaScript • Security was added later without a comprehensive security model. • Most browsers do not have a mechanism to halt a running script short of aborting the browser instance. • This may not be possible if the browser has stopped responding to commands. • The number of ways JavaScript can interact with a system is high. • With so many opportunities for malicious code, the best advice is not to run JavaScripts or Java applets unless the source is trusted.

20. ActiveX • ActiveX is a collection of APIs, protocols, and programs developed by Microsoft to download and execute code over an Internet-based channel. • Microsoft developed Authenticode that uses digital signatures to verify source. • Safety and security are different things and Authenticode promotes neither in reality. • Authenticode provides limited accountability at the time of download and guarantees that the code has not been changed since the time of signing. • Authenticode does not identify whether a piece of code will damage a system, nor does it regulate how the code is used. examples of Authenticode options.

21. CGI • The Common Gateway Interface (CGI) was a method of having a Web server execute a program outside the Web server process, but yet on the same server. • It passes information via environment variables to an independent program. • It executes the program and returns the results to the Web server. • CGI offers many advantages to Web-based programs. • The programs can be written in a number of languages, although Perl is preferred. • These scripted programs embrace the full functionality of a server, allowing access to databases, UNIX commands, and other programs. • If properly coded, CGI offers no more and no less risk than any other solution.

22. Server-Side Scripts • CGI has been replaced with newer server-side scripting technologies such as Java, Active Server Pages (ASP), and PHP. • They are similar to CGI – they allow programs to be run outside the Web server and return data to the Web server for end users via a Web page. • Each of these technologies has advantages and disadvantages. All have stronger security models than CGI. .

23. Cookies • Cookies are blocks of ASCII text passed back and forth between the Web server and the browser and act as a mechanism to maintain state in a stateless world. • State is a term that describes the dependence on previous actions. • An HTTP session served by a Web server is stateless. • Each request is independent of all previous requests. • Cookies were developed to bridge this gap. • Secure – The keyword [secure] in a cookie indicates that it is to be used only in an SSL/TLS session. • This does not indicate any other form of security. • Cookies are stored in plaintext on the client machine. • Cookie management is an invisible process.

24. Java Program Security – Signed Applets Local code is trusted to have full access to vital system resources, such as the file system, but downloaded remote code (an applet) is not trusted and can access only the limited resources provided inside the sandbox. • Java was the first general purpose programming language to consider security. • The original security model provided by the Java platform, known as the "sandbox" model, existed in order to provide a very restricted environment in which to run untrusted code obtained from the open network.

25. Signed Applets • JDK 1.1 introduced the concept of a "signed applet". A digitally signed applet is treated like local code, with full access to resources, if the public key used to verify the signature is trusted. Unsigned applets are still run in the sandbox. • JDK 1.2 introduces a number of improvements over JDK 1.1. All code, local or remote, can be subject to a security policy. • The security policy defines the set of permissions available for code from various signers or locations. • It can be hijacked as easily as a graphic or any other file. • The security concern of signed controls comes from how the control is used. • A hacker can create a file loss, buffer overflow or weaken a system. • The control will still function as designed, but the issue becomes who it is used by and how.

26. User, Group, and Role Management • Privilege management is the process of restricting a user's ability to interact with the computer system. • Users • For the effective management of privileges of many people on the same system, there must be a mechanism to separate people into distinct entities (users). • Groups • It is convenient and efficient to group users when granting different people (groups) access to something at the same time. • Roles • It is useful to grant or restrict access based upon a person's job or function within the organization (role). Modern operating systems use a combination of the described access control models. • Mandatory access control (MAC) • Discretionary access control (DAC) • Role-based access control (RBAC)

27. Mandatory Access Control • MAC controls access to information based on three criteria: • Sensitivity of that information. • Whether or not the user is operating at the appropriate sensitivity level. • Whether or not the user is authorized to access that information. • Each piece of information and every system resource (files, devices, networks, and so on) is labeled with its sensitivity level (such as Public, Engineering Private, Jones Secret).

28. Discretionary Access Control • Discretionary access control is the process of using file permissions. • Optionally, access control lists (ACL) are used to restrict access to information based on a user's identity or group membership. • The discretionary part of DAC means that a file or resource owner has the ability to change the permissions of that file or resource. • Under UNIX operating systems, file permissions consist of three distinct parts: • Owner permissions (read, write, and execute) • Group permissions (read, write, and execute) • World permissions (read, write, and execute)

29. Role-Based Access Control • RBAC manages access and privileges based on the user's roles. • In this method, first, the activities that must be performed and the resources that must be accessed by specific roles are determined. • After roles are created, and the rights and privileges associated with those roles are determined, users can then be assigned one or more roles based on their job functions.

30. Disaster Recovery Disaster Recovery • How to prepare for a disaster and how plans to mitigate the disaster dictate how long operations are disrupted. • It is more likely that business operations will be interrupted due to employee error. • Plans/Process Backups • Utilities • Secure Recovery • High Availability and Fault Tolerance • Computer Incident Response Teams • Test, Exercise, and Rehearse

31. Categories of Business Functions • Categorize the various functions an organization performs to develop a BIA (Business Impact Assessment), and a DRP (Disaster Recovery Plan). • Critical  • Without the function, the basic mission of the organization cannot be accomplished. • Necessary for normal processing  • The organization can do without it for a short period of time (such as for less than 30 days). • Desirable  • The function is not needed for normal processing. It enhances processing. • Optional  • If the function is not needed • If the function does not fall into any of the categories • Consider eliminating this function

32. Disaster Recovery Plan • The focus of a disaster recovery plan (DRP) is on continued operation after a disaster. A DRP (disaster recover plan) defines the data and resources (hardware, software and computer personnel) necessary and the processes and procedures required to restore critical processes. • It is essential the DRP needs is approved by management.. • Needs to be tested periodically. • Needs management approval • Backups are key to DRP • Utilize offsite storage

33. Utilities - Power • Emergency power must be planned for in case of disruption • For short-term interruptions a UPS may suffice. • Beyond a few minutes, another source of power is required. • Backup generators are not a simple, maintenance-free solution. • Generators should be tested on a regular basis. • They can become strained if they power too much equipment, therefore, ensure the reserve capacity is beyond the anticipated load. • They take time to start up. A UPS should be used to for a smooth transition to backup power. • Generators are expensive and require fuel – they should be kept in a place where they can be fueled.

34. Secure Recovery • In the event an organization’s operations are disrupted, several companies offer recovery services that can remotely provide restoration services for critical files and data. These may include: • Power • Communications • Technical support • For the physical sites and the remote service—security is an important element and must be ensured. • Confidentiality • Integrity • Availability

35. Computer Incident Response Teams • A plan should include establishing a Computer Incident Response Team (CIRT) or a Computer Emergency Response Team (CERT). • The team should be created and team members notified before an incident occurs. • The team includes technical and non-technical individuals who provide guidance on ways to handle media attention, legal issues, management issues. • The team consists of permanent and ad hoc members. • The CIRT conducts investigations of the incident and makes recommendations about how to proceed. • Policies and procedures for investigation should also be worked out in advance. • It is also advisable to have the team periodically meet to review these procedures.

36. Test, Exercise, and Rehearse • The BCP, DRP, backup procedures, or method to address computer incidents and other plans should be tested. • all parties should practice the established procedures. • As many recovery functions as possible should be performed • Care should be taken not to impact actual operations. • Rehearsal of portions of the recovery plan should include: • Items that are disruptive to actual operations. • Items identified as needing more frequent activation due to either the importance or the need for continual practice

37. Policies and Procedures • Policies are high-level statements made by the management laying out an organization's position on some issue. • Policies are mandatory but are not specific in their details. • Policies are focused on the result – not the methods for achieving that result. • Standards are specifications providing specific details on how a policy is to be enforced. • Procedures are step-by-step instructions describing exactly how employees are expected to act in a given situation or to accomplish a specific task.

38. Policies and Procedures • There are security policies that every organization should have in place. • Acceptable use • Due care • Separation of duties • Password management • Other important policy-related issues include: • Privacy • Service level agreements • Human resources policies • Code of ethics • Incident response

39. Security Policies • The security policy should describe how security is handled from an organizational point of view. • The security policy should be reviewed regularly and updated as needed. • Policies should be updated less frequently than the procedures that implement them. • High-level goals do not change as often as the environment in which they must be implemented. • All policies should also be reviewed by a legal counsel. • A plan should be outlined describing how all employee training. • Policies can be made stronger by including references to the authority who made the policy. • CEO, or a department-level policy. • Refer to any laws or regulations applicable to the specific policy and environment.

40. Need to Know • Need to know and least privilege are principles that ensure that each individual in the organization is only supplied with the minimum amount of information and privileges they need to perform their tasks. • To obtain access to any piece of information, they must justify why they “need to know” it. • They will only be granted the bare number of privileges needed to perform their jobs. • A policy spelling out these principles as guiding philosophies should be created and address who may grant access or assign privileges.

41. Human Resources Policies • You should hire individuals that can be trusted with your data and that of your clients. • Once hired, keep them from slipping into the category of “disgruntled employee.” • You need policies to address when employees leave the organization. • Run background checks on prospective employees and check references. • Drug tests • Past criminal activity • Educational background • Work history • For sensitive environments, security background checks are required. • You must ensure that you hire the most capable and trustworthy employees. • Your policies should ensure this.

42. Employee Hiring and Promotions • Once hired, you should minimize the risk that the employee will “turn against you.” • Periodic reviews by supervisory personnel, additional drug checks, and monitoring of activity during work should be considered. • These reviews should be specified in the organization's policies. • Prospective employees should be made aware of these policies before being hired. • Your ability to monitor may be restricted if not spelled out in advance • New employees should be made aware of all pertinent security policies. • Documents should be executed acknowledging that they have read and understood them. • Changes to privileges should be clearly spelled out in their policies.

43. Employee Retirement, Separation, or Termination • Employees who retire by choice may announce their retirement weeks or even months in advance. • Limiting access to sensitive documents the moment they announce their intention is the safest thing to do, although it may not be necessary. • Each situation should be evaluated individually. • If they leave for a better job, you may decide to allow them to gracefully transfer their projects to other employees. • The decision should be considered carefully if the new company is a competitor. • If the employee is terminated, immediately revoke their access privileges: • Access cards, keys, and badges should be collected. • The employee should be escorted to their desk and watched as they pack their personal belongings. • They should be escorted from the building. • Combinations should be changed quickly once they have been informed of their termination.

44. Code of Ethics • Professional organizations have established codes of ethics for their members. • Each of these describes the expected behavior of their members from a high-level standpoint. • For organizations, a code of ethics can set the tone for how employees will be expected to act and conduct business. • The code should: • Demand honesty from employees. • Require that they perform all activities in a professional manner. • Address principles of privacy and confidentiality. • State how employees should treat client and organizational data. • Address conflicts of interest.

45. Incident Response Policies • An incident response policy and procedure should be developed to outline how the organization will deal with security incidents when they occur. • Preparation • Detection • Containment and Eradication • Recovery • Follow-On Actions

46. Preparation • Preparing for an incident is the first phase and steps should be established. • The points of contact should be determined. • Employees should be trained about the steps to take. • An incident response should be formed; the equipment necessary to detect, contain, and recover from an incident should be acquired; and those who will use the equipment should be trained. • Any additional training in areas such as computer forensics that are determined to be necessary should also be accomplished. • The incident response team is a critical part of the incident response plan.

47. Preparation • Team membership varies depending on the type of incident, some general points are: • A higher-level manager who can obtain the cooperation from employees as needed should lead. • A computer or network security analyst is useful • Specialists may be added for specific hardware or software platforms as needed. • The organization's legal counsel should be part of the team on at least a part-time or as-needed basis. • The public affairs office should be available on an as-needed basis to formulate the public response should the event become public. • The security office should also be kept informed. • There should be a point of contact for the team in case criminal activity is suspected.

48. Detection • The most likely group of individuals to discover an incident will be the network and security administrators via the organization's firewalls and intrusion detection systems. • Procedures should be established for administrators to check for possible security events. • The tools should be identified during the preparation phase described. • Any required training to operate the equipment should also be acquired. • A technique used by intruders is social engineering. • Training is essential to thwart social engineering attacks. • A policy on who will be required to receive this type of training and how frequently they should receive it. • Whatever the type of security incident suspected, and whoever suspects it, a reporting procedure needs to be in place for the employees. • Everyone should know who to call and what to do if something is suspected. • A reporting template should be given to any individual suspecting an incident • One of the first jobs of the incident response team is to determine if an actual incident has occurred. • Each reported incident must be investigated and treated as a possible incident.

49. Containment and Eradication • The team should quickly contain the problem. • Decide whether to restore operations or prosecute. • If the decision to prosecute is made, specific procedures need to be followed in handling potential evidence. • A decision that should be made quickly is how to address containment. • If an intruder is on the system, one response is to disconnect from the Internet until the system can be restored and vulnerabilities patched. • Once the incident has been contained and malicious software or vulnerabilities have been taken care of, the procedures described earlier should be put into action. • The goal should be to have the organization back to normal processing as soon as possible.

50. Follow-On Actions • Once the operations have been restored to their pre-incident state, a few details need to be taken care of. • Senior-level management should be informed of what occurred. • Recommendations should be made to improve processes and policies so that a repeat will not occur. • If prosecution of the individual responsible is desired, then additional time will be spent in helping law enforcement agencies and in possible testimony. • Training material should be developed or modified as part of the new policies and procedures.