1. Answer the following: a. Give a description for the following terms: Annual L
ID: 671476 • Letter: 1
Question
1. Answer the following:
a. Give a description for the following terms: Annual Loss Expectancy (ALE), Annual Rate of Occurrence (ARO), and Single Loss Expectancy (SLE).
b. If the ALE of an incident is $20,000 and the ARO is twice every 5 years, what is the SLE?
2. Explain the following XMLHTTPRequest object functions and their arguments:
a. open()
b. send()
3. Describe how PHP maintains sessions. Include how it can use the cookie to accomplish session management.
4. Name all 4 methods of dealing with risk mentioned in class; also give an example of each method and explain how your example fits the method.
Explanation / Answer
1. a)
Annual Loss Expectancy (ALE), Annual Rate of Occurrence (ARO), and Single Loss Expectancy (SLE).
1. SLE: This is defined as Expected loss in case of a compromise. This exposure factor is the measure or percent of damage that a realized threat would have on a specific asset
SLE is calculated as follows:
Single loss expectancy x Asset value = Exposure factor
Items to consider when calculating the SLE include the physical destruction or theft of assets, the loss of data, the theft of information, and threats that might cause a delay in processing.
2. ARO: This is defined as Annual probability of a compromise that is how many times is this expected to happen in one year? It is a threat analysis to determine the likelihood of an unwanted event.
3. ALE— This is defined as Expected loss per year from the compromise. It combines the potential loss and rate per year to determine the magnitude of the risk.
ALE is calculated as follows:
Annualized loss expectancy (ALE) x Single loss expectancy (SLE) = Annualized rate of occurrence (ARO)
1.b. ALE=$20,000
ARO is twice every 5 years
Formula to find SLE:
SLE = ALE / ARO
-------------------------------------------------------------------------------------------------------------------------------------
3. Php session management:
PHP session management consists of a way to preserve certain data across subsequent accesses.
A visitor accessing a web site is assigned a unique id, the so-called session id. This is either stored in a cookie on the user side or is propagated in the URL.
The session support allows to store data between requests in the $_SESSION superglobal array. When a visitor accesses a site, PHP will check automatically (if session.auto_start is set to 1) or on your request (explicitly through session_start()) whether a specific session id has been sent with the request. If this is the case, the prior saved environment is recreated.
$_SESSION (and all registered variables) are serialized internally by PHP using the serialization handler specified by the session.serialize_handler ini setting, after the request finishes. Registered variables which are undefined are marked as being not defined. On subsequent accesses, these are not defined by the session module unless the user defines them later.
Functions used in PHP session Managaement:
Boolean session_start( )
Initializes a session by either creating a new session or using an identified one. Checks for the variable $PHPSESSID in the HTTP request. If a session identifier isn't included in the request, or an identified session isn't found, a new session is created. If a session ID is included in the request, and a session isn't found, a new session is created with the PHPSESSIDencoded in the request. When an existing session is found, the session variables are read from the session store and initialized. Using PHP's default settings, a new session is created as a file in the /tmp directory. This function always returnstrue.
string session_id([string id])
Can be used in two ways: to return the ID of an initialized session and to set the value of a session ID before a session is created. When used to return the session ID, the function must be called without arguments after a session has been initialized. When used to set the value of the session ID, the function must be called with the ID as the parameter before the session has been initialized.
Boolean session_register(mixed name [, mixed ...])
Registers one or more variables in the session store. Each argument is the name of a variable, or an array of variable names, not the variable itself. Once a variable is registered, it becomes available to any script that identifies that session. This function calls the session_start( ) code internally if a session has not been initialized. The session_unregister( ) function is called to remove a variable from the session. Returns true when the variables are successfully registered.
Boolean session_is_registered(string variable_name)
Returns true if the named variable has been registered with the current session and false otherwise. Using this function to test if a variable is registered is a useful way to determine if a script has created a new session or initialized an existing one.
session_unregister(string variable_name)
Unregisters a variable with the initialized session. Like the session_register( ) function, the argument is the name of the variable, not the variable itself. Unlike the session_register( ) function, the session needs to be initialized before calling this function. Once a variable has been removed from a session with this call, it is no longer available to other scripts that initialize the session. However, the variable is still available to the rest of the script that calls session_unregister( ).
session_unset( )
Unsets the values of all session variables. This function doesn't unregister the actual session variables. A call tosession_is_registered( ) still returns true for the session variables that have been unset.
Boolean session_destroy( )
Removes the session from the PHP session management. With PHP's default settings, a call to this function removes the session file from the /tmp directory. Returns true if the session is successfully destroyed and false otherwise.
Cookies to manage session:
The setcookie() call needs to be before the HTML form because of the way the web works.
It takes three main parameters: the name of the cookie, the value of the cookie, and the date the cookie should expire.
The last three parameters of the setcookie() function allow to restrict when it's sent, which gives a little more control.
• Parameter four ("path") allows you to set a directory in which the cookie is active. By default, this is "/" (active for the entire site), but you could set it to "/messageboards/" to have the cookie only available in that directory and its subdirectories.
• Parameter five ("domain") allows you to set a subdomain in which the cookie is active. For example, specifying "mail.yoursite.com" will make the cookie available there but not on www.yoursite.com. Use ".yoursite.com" to make the cookie available everywhere.
• Parameter six ("secure") lets you specify whether the cookie must only be sent through a HTTPS connection or not. The default, "0", has the cookie sent across both HTTPS and HTTP, but you can set it to 1 to force HTTPS only.
. The first time a PHP script calls session_start( ), a session identifier is generated, and, by default, a Set-Cookie header field is included in the response. The response sets up a session cookie in the browser with the name PHPSESSID and the value of the session identifier. The PHP session management automatically includes the cookie without the need to call to the setcookie( ) orheader( ) functions.
The session identifier (ID) is a random string of 32 hexadecimal digits, such as fcc17f071bca9bf7f85ca281094390b4. As with other cookies, the value of the session ID is made available to PHP scripts in the $HTTP_COOKIE_VARS associative array and in the$PHPSESSID variable.
When a new session is started, PHP creates a session file. With the default configuration, session files are written in the /tmpdirectory using the session identifier, prefixed with sess_, for the filename. The filename associated with our example session ID is/tmp/sess_fcc17f071bca9bf7f85ca281094390b4.
If a call is made to session_start( ), and the request contains the PHPSESSID cookie, PHP attempts to find the session file and initialize the associated session variables as discussed in the next section. However, if the identified session file can't be found,session_start( ) creates an empty session file.
At some point in an application, sessions may need to be destroyed. For example, when a user logs out of an application, a call to the session_destroy( ) function can be made. A call to session_destroy( ) removes the session file from the system but doesn't remove the PHPSESSID cookie from the browser.
-----------------------------------------------------------------------------------------------------------------------------
2. XMLHTTPRequest Object functions:
a. Open():
The HTTP and HTTPS requests of the XMLHttpRequest object must be initialized through the open method. This method must be invoked prior to the actual sending of a request to validate and resolve the request method, URL, and URI user information to be used for the request. This method does not assure that the URL exists or the user information is correct. This method can accept up to five parameters, but requires only two, to initialize a request.
open( Method, URL, Asynchronous, UserName, Password )
The first parameter of the method is a text string indicating the HTTP request method to use. The request methods that must be supported by a conforming user agent, defined by the W3C draft for the XMLHttpRequest object, are currently listed as the following.
• GET
• POST
• PUT
• DELETE
• OPTIONS
The second parameter of the method is another text string, this one indicating the URL of the HTTP request. The W3C recommends that browsers should raise an error and not allow the request of a URL with either a different port or ihost URI component from the current document.
The third parameter, a boolean value indicating whether or not the request will be asynchronous, is not a required parameter by the W3C draft. The default value of this parameter should be assumed to be true by a W3C conforming user agent if it is not provided. An asynchronous request ("true") will not wait on a server response before continuing on with the execution of the current script. It will instead invoke the onreadystatechange event listener of the XMLHttpRequest object throughout the various stages of the request. A synchronous request ("false") however will block execution of the current script until the request has been completed, thus not invoking the onreadystatechangeevent listener.
The fourth and fifth parameters are the username and password, respectively. These parameters, or just the username, may be provided for authentication and authorization if required by the server for this request.
b) Send():
To send an HTTP request, the send method of the XMLHttpRequest must be invoked. This method accepts a single parameter containing the content to be sent with the request.
send( Data )
This parameter may be omitted if no content needs to be sent. This parameter may be any type available to the scripting language as long as it can be turned into a text string, with the exception of the DOM document object.
If a user agent cannot serialise the parameter, then the parameter should be ignored.
If the parameter is a DOM document object, a user agent should assure the document is turned into well-formed XML using the encoding indicated by the inputEncodingproperty of the document object.
If the Content-Type request header was not added through setRequestHeader yet, it should automatically be added by a conforming user agent as "application/xml;charset=charset," where charset is the encoding used to encode the document.
If the user agent is configured to use a proxy server, then the XMLHttpRequest object will modify the request appropriately so as to connect to the proxy instead of the origin server, and send Proxy-Authorization headers as configured.
----------------------------------------------------------------------------------------------------------------------------------
4. Methods to deal with risks:
• Risk assessment: find out which risks apply to your business and evaluate them. Management has to decide which risks will be treated or not. Information Packages for SMEs ENISA ad hoc working group on risk assessment and risk management
• Risk treatment: select and implement security controls to reduce risks. Controls can have different effects, like: o mitigation o transfer o avoidance and o retention of risks In the example given above, a disk encryption (that would strongly reduce the risk that competing companies get access to confidential data in case the laptop is stolen) is a measure of risk mitigation, an insurance covering the hardware replacement cost is a measure of risk transfer. An example for risk avoidance is to take on the laptop no more than the necessary data. You can and should use multiple security controls to treat risks. It is advisable to use different types of controls.
• Risk acceptance: Even when the risks have been treated, residual risks will generally remain, even after risk treatment has been performed or if controls are not feasible. The management has to accept the way risks have been treated. Thus, risk acceptance should always be a management decision. In our example, applying the four security controls mentioned above reduces the risk considerably, but there is still some residual risk: for example the unavailability of the notebook until it is replaced or the possibility that the encryption system used for disk encryption might be broken. Nevertheless, as in the first instance the possible impact is relatively small, and in the second one the probability that this happens (i.e. that the underlying encryption system is broken) is very small, the risks will probably be accepted.
• Risk communication: consists of informing decision makers and involved stakeholders about potential risks and controls. This phase is of high importance and should be integral part of the risk management process. Depending on the involved stakeholders, this communications might be internal or external (e.g. internal units or external partners).
Four Ways to Manage Risks:
1. Avoid - remove risk through eliminating the situation or activity that presents risk
2. Transfer - transfer risk through insurance or through leases/other types of contracts
3. Reduce - setting up policies, procedures, trainings, etc. that reduce the risks being undertaken
4. Retain - assume risk because some risks cannot be eliminated, it's worth assuming Risk Management Oregon.
Related Questions
Navigate
Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.