Skip navigation
All Places > Products > RSA Archer Suite > Blog > 2019 > March
2019

This is not an April Fools’ Day joke – RSA Charge registration fees go up from $595 to $995 on April 2. Trust us, you will not want to miss this year’s Charge event. REGISTER TODAY!

 

RSA Charge 2019 will provide you a place to discover game-changing business-driven security solutions to meet today’s greatest business challenges. Attendees will explore best practices and have opportunities to problem-solve and discuss ideas for product and service innovation to increase productivity. From customer case studies to training as well as one-on-one consultations and motivating keynotes, this year’s conference has something for everyone!

 

RSA Charge 2019 will deliver a host of new content and exciting opportunities through:

Customer-led case studies and hands-on workshops to share trends and issues specific to your industry

Thought-provoking keynote presentations that provides insights on RSA’s products, solutions and customer successes

Partner Expo highlights solutions that are driving high-impact business benefits using RSA’s solutions

Unparalleled Networking invites you to exchange ideas with your peers and RSA experts and save – early bird rates are $595 and available through April 1, 2019, then the regular registration price kicks in at $995. The RSA Charge 2019 website should be your go-to destination for all ‘Charge’ information - Call for Speakers, Agendas at a Glance, Full Agendas and speakers, Keynotes, and so much more.

 

RSA Charge 2019 will be in Orlando from September 16-19, 2019 @ Walt Disney World Dolphin & Swan Hotel, Orlando. 

 

REGISTER before April 2, save $400 and check out the RSA Charge 2019 website for continual updates like the one below:

 

Just Added: Looking for pre-conference training? Due to RSA Charge starting on a Monday and being on the Disney grounds, RSA has decided not to offer any pre-conference training this year but instead offer a whole RSA University track dedicated to your favorite training topics at no extra cost. That’s right, no additional cost!

 

There will also be RSAU representatives, onsite to talk shop and answer any and all of your questions, just another reason to attend RSA Charge 2019. We look forward to seeing you all in Orlando.

What is Operational Risk?

The Risk Management Association defines operational risk as “the risk of loss resulting from inadequate or failed internal processes, people, and systems, or from external events.” Sources of operational risk include natural and man-made disasters, cyber-attacks, errors, fraud, and regulatory or contractual non-compliance.

 

Why is the proper management of Risk so important?

In addition to operational risk, organizations today face a wide range of risks originating in different areas of their business, including risk to achieving strategies and objectives, credit risk, interest rate, liquidity, and market risk, political risk, and reputation risk, to name a few.  Many of these risks arise within the four walls of the organization and many are inherited through the extended third-party ecosystem that the organization engages. 

 

As an organization grows in size and complexity, converts to digital, moves into new markets, introduces new, more sophisticated or novel products and services, is subject to more regulatory obligations, extends its third party dependencies, or is exposed to political, social, or environmental challenges, it becomes much more difficult for the organization’s management and board of directors to understand and manage its risks.  Without a clear understanding of their risks, these organizations tend to experience more surprises and losses, and have a more difficult time achieving their objectives and strategies.  Some of these risks may threaten the very existence of the organization, or the livelihood of its managers and board of directors.  Consequently, these risks must be effectively identified, assessed, and managed to protect the organization’s leadership and ensure the organization can meet its objectives.

 

RSA Archer Risk Catalog

RSA Archer Risk Catalog provides the foundation to record and track risks across your enterprise, and establish accountability by named first and second line of defense managers. It provides a three-level roll-up of risk, from a granular level up through enterprise risk statements. Inherent and residual risk can be assessed utilizing a top-down, qualitative approach, with assessed values rolling up to intermediate and enterprise risk statements.

 

Key features include:

  • Consistent approach to documenting risk, assigning accountability, and assessing risks
  • Oversight and management of all risks in one central location
  • Ability to understand granular risks that are driving enterprise risk statements
  • Consolidated list of prioritized risk statements

 

RSA Archer Risk Catalog enables organizations to:

  • Obtain a consolidated list of the organization’s risk
  • Enforce a consistent approach to risk assessments
  • Prioritize risks to make informed decisions about risk treatment plans
  • Create accountability for the ownership and management of risk

 

The RSA Archer Risk Catalog is an essential use case of the RSA Archer Ignition Program, designed to empower organizations of all sizes to respond to risk with data-driven facts using a streamlined, fast time-to-value approach

 

Today, organizations are faced with complex and fast moving challenges.  RSA Archer Risk Catalog is one element of an effective Integrated Risk Management program.  Stressing the agility and flexibility needed by today’s modern organizations, integrated risk management brings together the various domains of risk across business activities (horizontally), connecting the activities to the strategies and objectives of the organization on an aggregated basis (vertically). This approach to risk management provides leaders with the most holistic understanding of risk facing their organization so they can make truly informed decisions about where to deploy limited capital and human resources to produce optimized returns for the organization while maximizing the likelihood of achieving the organization’s objectives.

 

As your organization grows and changes, your risk management program must evolve and manage risk more holistically, with more agility and integration than before. Effective risk management is essential for improving an organization’s risk profile.  RSA Archer can help your organization better understand and manage its risk on one configurable, integrated software platform. With RSA Archer solutions, organizations can efficiently implement risk management processes using industry standards and best practices and significantly improve their business risk management maturity.

 

For more information, visit RSA.com or read the Datasheet.

 

Thorough due diligence is a necessity when entering into an agreement or contract with another party, especially in the case of mergers and acquisitions.  However, due diligence activities can apply to any business situation requiring an investigation where proof that a "diligent" effort was put forth to obtain pertinent information in a forthcoming matter.  In the case of mergers and acquisitions, due diligence is a vital activity and can take several months of intense analysis if the target firm is a large business with a global presence.  This process often unveils risk insights and can help your organization plan for impacts to the business.      

 

Organizations need a way to define what due diligence activities are required and to track the results of those activities.  The RSA Archer Due Diligence Management app-pack enables you to define and manage the due diligence activities required for a thorough investigation of the target entity. The offering defines a framework for all due diligence activities making it consistent and repeatable, while providing visibility into the status of due diligence activities.  The due diligence framework can be defined specifically for your organization to ensure everyone within the organization is conducting the required due diligence for every target entity.  Due diligence activities are assigned and reviewed to ensure all activities have been completed, resulting in lower risk mergers and acquisitions.

 

With the RSA Archer Due Diligence Management app-pack, you can determine the scope of each due diligence project, track the due diligence tasks to completion, confirm and verify information through investigation, and provide recommendations based off of factual data and reports.

 

RSA Archer Due Diligence Management allows you to:

  • Offer a consistent and repeatable process for conducting due diligence
  • Implement a structure for due diligence checklist
  • Obtain visibility into the status of the due diligence activities required

 

Interested in learning more about the RSA Archer Due Diligence Management app-pack? Join us for a Free Friday Tech Huddle on Friday, March 29 for a live demo. Free Friday Tech Huddles are only available to RSA Archer customers. If you are not yet a customer but you are interested in learning more, please contact your local representative or authorized reseller—or visit us at www.rsa.com.

 

What is Operational Risk?

The Risk Management Association defines operational risk as “the risk of loss resulting from inadequate or failed internal processes, people, and systems, or from external events.” Sources of operational risk include natural and man-made disasters, cyber-attacks, errors, fraud, and regulatory or contractual non-compliance.

 

Why is Operational Risk Management so important?

For many organizations, effective operational risk management is inherently complex. As organizations grow in size and complexity, convert to digital, move into new markets, introduce new, more sophisticated or novel products and services, becomes subject to more regulatory obligations, or extends its third party dependencies, it becomes much more difficult for the organization’s management and board of directors to understand and manage its risks.  Without a clear understanding of their risks, these organizations tend to experience more surprises and losses, and have a more difficult time achieving their objectives and strategies.  Some operational risks may threaten the very existence of the organization, or the livelihood of its managers and board members.  Consequently, these risks must be effectively identified, assessed, and managed by business unit leaders (the first line of defense) and executive management to adequately protect the organization’s leadership and ensure the organization can meet its objectives.

 

Without engaging the first line of defense in identifying risk, and using consistent methodologies and measurements to assess risk, there is no way to provide executive management and the Board with an accurate and aggregated view of risk across the business.  Good operational risk management protects the organization from operational losses and surprises.

 

RSA Archer Operational Risk Management

RSA Archer Operational Risk Management is a combination of use cases that are core to a typical operational risk management program. These elements include: Top-Down Risk Assessment, Bottom-Up Risk Assessment, Loss Event Management, Key Indicator Management, Risk and Control Self-Assessments, Issues Management, and Scenario Analysis. RSA Archer Operational Risk Management enables cataloging business processes and sub-processes, documenting risks associated with business processes, and  control procedures. Risk self-assessments can be performed on a top-down basis, through first line of defense self-assessments, and through targeted bottom-up assessments. Loss events can be cataloged, root-cause analysis performed and routed for review and approval. Key risk and control indicators can be established and associated with risk and control registers, respectively, and monitored to provide early warning of changes in the organization’s risk profile. By integrating these use cases, risk managers have a comprehensive operational risk management program that reinforces desired accountability and risk management culture throughout the organization, providing necessary transparency through reporting, dashboards, and notification alerts.

 

Key features include:

  • Consolidated view into business processes, risks, controls, loss events, key indicators, and outstanding issues; an understanding of how they are all related; and accountability for each
  • Support for first line of defense self-assessments, and top down and bottom up risk assessments
  • Efficient management of self-assessment campaigns by second line of defense stakeholders, including necessary workflow to vet and challenge first line of defense assessments
  • Capture and perform root cause analysis on internal losses and near misses, and relevant external loss events, routing loss events to stakeholders for review and approval consistent with delegated authorities and loss type.
  • Enforce consistency in creation of risk and control registers through the use of risk and control libraries
  • Catalogue risk scenarios and capture and perform scenario risk assessments
  • Understand inherent and residual risk and observe changes in calculated residual risk while rolling up risks by business unit and enterprise risk statement
  • Robust key risk and control indicator program management to provide early warning and remediation
  • Consolidated issues management with a clear understanding at all times of the status of all open remediation plans and exceptions
  • Visibility into operational risk via predefined reports, risk dashboards, workflow, and notifications
  • Perform risk assessments qualitatively, quantitatively using monetary values, and support Monte Carlo simulation based on expert elicitation and loss events.

 

RSA Archer Operational Risk Management enables:

  • Better understanding of risks and controls throughout the organization
  • Improved risk management and risk management culture by engaging the first line of defense (business users) to take ownership of their risks and controls
  • Quicker detection and management of changes in risk profile
  • More efficient administration of the operational risk management program, allowing second line of defense teams to spend more time on analysis and less time on administration and reporting
  • Less time required to identify and resolve operational risk-related problems
  • Reduction in audit findings, surprises, loss events, and incidents,
  • Ability to clearly demonstrate the design and effectiveness of your organization’s risk management program

 

Today, organizations are faced with complex and fast moving challenges.  RSA Archer Operational Risk Management addresses the core requirements of an effective Integrated Risk Management program.  Stressing the agility and flexibility needed by today’s modern organizations, integrated risk management brings together the various domains of risk across business activities (horizontally), connecting the activities to the strategies and objectives of the organization on an aggregated basis (vertically). This approach to risk management provides leaders with the most holistic understanding of risk facing their organization so they can make truly informed decisions about where to deploy limited capital and human resources to produce optimized returns for the organization while maximizing the likelihood of achieving the organization’s objectives.

As your organization drives business growth through an extended ecosystem strategy, your risk management program must evolve and manage risk more holistically, with more agility and integration than before. Effective risk management is essential for improving an organization’s risk profile.  RSA Archer can help your organization better understand and manage its risk on one configurable, integrated software platform. With RSA Archer solutions, organizations can efficiently implement risk management processes using industry standards and best practices and significantly improve their business risk management maturity.

 

For more information, visit RSA.com or read the Datasheet.

 

What is Operational Risk?

The Risk Management Association defines operational risk as “the risk of loss resulting from inadequate or failed internal processes, people, and systems, or from external events.” Examples of operational risk include natural and man-made disasters, cyber-attacks, errors, fraud, and regulatory or contractual non-compliance.

 

Why is Bottom-Up Risk Assessment so important?

The introduction of new products and services, mergers and acquisitions, business process changes, and fraud are often viewed as risk projects to be evaluated when making decisions to move forward or enhance risk treatments. All too often, these kinds of operational project reviews are performed on an ad-hoc basis, using an unstructured and inconsistent approach. Bottom-up, project-oriented risk assessments are prone to incomplete and unreliable information. In addition, IT and business teams are often asked to collect the same assessment data via spreadsheets, Word documents, and email for different risk and compliance assessments. This manual approach results in missed project deadlines,  inconsistent and inaccurate risk assessments, risk treatments, and remediation plans. Manual approaches also often inefficient and expensive, and lack an easy way to compare results of multiple assessments. Since risks cannot be identified or assessed properly, losses, incidents, or other surprises related to the project may arise at a later date. Without visibility to or accountability in addressing known risks identified through bottom-up risk assessments, resource misallocation and slow implementation in risk treatment are the typical results.

 

RSA Archer Bottom-Up Risk Assessment

RSA Archer Bottom-Up Risk Assessment allows you to engage your teams via targeted project risk assessments. Projects can include such things as new and changing business processes, fraud assessments, new products and services, and proposed mergers, acquisitions, and divestitures.  Projects can be documented and questionnaires can be created with custom questions, as well as questions derived from RSA Archer’s extensive library of thousands of out-of-the-box questions. When risks are deemed too high, risk treatments and remediation plans can be documented and tracked through to resolution and approval.

 

Key features include:

  • Consistent approach to identify and assess project-related risk
  • Oversight and management of all risk assessments in process
  • Risk treatment plans are known across all assessments and implementation plans can be monitored to completion
  • Consolidated list of prioritized risk treatments and remediation plans
  • Visibility into assessment progress, risk treatments and remediation activity via pre-defined reports and risk dashboards
  • Named accountability for assessments and remediation plans

 

RSA Archer Bottom-Up Risk Assessment provides:

  • Consistent approach to identify and assess project-related risk
  • Oversight and management of all risk assessments in process
  • Known risk treatment plans across all assessments and implementation plans that can be monitored to completion
  • Consolidated list of prioritized risk treatments and remediation plans
  • Visibility into assessment progress, risk treatments and remediation activity via pre-defined reports and risk dashboards
  • Accountability for risk assessment and remediation activities

 

Today, organizations are faced with complex and fast moving operational risk challenges.  Tracking changing business activities is a core best practice in Operational Risk Management.  RSA Archer Bottom-Up Risk Assessment is a key element of an effective Operational and Integrated Risk Management program to assess risk associated with changing business activities.  Stressing the agility and flexibility needed by today’s modern organizations, integrated risk management brings together the various domains of risk across business activities (horizontally), connecting the activities to the strategies and objectives of the organization on an aggregated basis (vertically). This approach to risk management provides leaders with the most holistic understanding of risk facing their organization so they can make truly informed decisions about where to deploy limited capital and human resources to produce optimized returns for the organization while maximizing the likelihood of achieving the organization’s objectives.

 

As your organization drives business growth, your risk management program must evolve and manage risk more holistically, with more agility and integration than before. Effectively performing Bottom-Up risk assessments is one ingredient to demonstrating real progress and improvement in decreasing business risk.  RSA Archer can help your organization better understand and manage risk assessments on one configurable, integrated software platform. With RSA Archer solutions, organizations can efficiently implement risk management processes using industry standards and best practices and significantly improve their business risk management maturity.

 

For more information, visit RSA.com or read the Datasheet.

 

 

 

Cross-site request forgery (CSRF) is an attack which forces an end user to execute unwanted actions on a web application to which they are currently authenticated.

 

CSRF vulnerabilities may arise when applications rely solely on HTTP cookies to identify the user that has issued a particular request. Because browsers automatically add cookies to requests regardless of the request's origin, it may be possible for an attacker to create a malicious web site that forges a cross-domain request to the vulnerable application.

 

CSRF is an attack which forces an end user to execute unwanted actions on a web application in which he/she is currently authenticated. With a little help of social engineering (like sending a link via email or chat), an attacker may force the users of a web application to execute actions of the attacker’s choosing. A successful CSRF exploit can compromise end user data and operation, when it targets a normal user. If the targeted end user is the administrator account, a CSRF attack can compromise the entire web application.

 

 

CSRF relies on the following:

[1] Web browser behavior regarding the handling of session-re-lated information such as cookies and http authentication information;

 

[2] Knowledge by the attacker of valid web application URLs;

 

[3] Application session management relying only on information which is known by the browser;

 

[4] Existence of HTML tags whose presence cause immediate access to an http[s] resource; for example the image tag img.

 

Points 1, 2, and 3 are essential for the vulnerability to be present, while point 4 is accessory and facilitates the actual exploitation, but is not strictly required.

 

Point 1)

Browsers automatically send information which is used to identify a user session. Suppose site is a site hosting a web application, and the user victim has just authenticated himself to site. In response, site sends victim a cookie which identifies requests sent by victim as belonging to victim’s authenticated session. Basically, once the browser receives the cookie set by site, it will automatically send it along with any further requests directed to site.

 

Point 2)

If the application does not make use of session-related information in URLs, then it means that the application URLs, their parameters, and legitimate values may be identified (either by code analysis or by accessing the application and taking note of forms and URLs embedded in the HTML/JavaScript).

 

Point 3) ”Known by the browser” refers to information such as cookies, or http-based authentication information (such as Basic Authentication; and not form-based authentication), which are stored by the browser and subsequently resent at each request directed towards an application area requesting that authentication.

 

 

The vulnerabilities discussed next apply to applications which rely entirely on this kind of information to identify a user session.

Suppose, for simplicity’s sake, to refer to GET-accessible URLs (though the discussion applies as well to POST requests). If victim has already authenticated himself, submitting another request causes the cookie to be automatically sent with it (see picture, where the user accesses an application on www.example.com).

The GET request could be originated in several different ways:

  • by the user, who is using the actual web application;
  • by the user, who types the URL directly in the browser;
  • by the user, who follows a link (external to the application)pointing to the URL.

 

These invocations are indistinguishable by the application. In particular, the third may be quite dangerous. There are a number of techniques (and of vulnerabilities) which can disguise the real properties of a link. The link can be embedded in an email message, or appear in a malicious web site where the user is lured, i.e., the link appears in content hosted elsewhere (another web site, an HTML email message, etc.) and points to a resource of the application.

 

If the user clicks on the link, since it was already authenticated by the web application on site, the browser will issue a GET request to the web application, accompanied by authentication information (the session id cookie). This results in a valid operation performed on the web application and probably not what the user expects to happen. Think of a malicious link causing a fund transfer on a web banking application to appreciate the implications.

 

By using a tag such as img, as specified in point 4 above, it is not even necessary that the user follows a particular link.

 

 

Suppose the attacker sends the user an email inducing him to visit an URL referring to a page containing the following (oversimplified) HTML:

 

 

What the browser will do when it displays this page is that it will try to display the specified zero-width (i.e., invisible) image as well.

This results in a request being automatically sent to the web application hosted on site. It is not important that the image URL does not refer to a proper image, its presence will trigger the request specified in the src field anyway. This happens provided that image download is not disabled in the browsers, which is a typical

configuration since disabling images would cripple most web applications beyond usability.

 

The problem here is a consequence of the following facts:

  • there are HTML tags whose appearance in a page result in automatic http request execution (img being one of those);
  • the browser has no way to tell that the resource referenced by img is not actually an image and is in fact not legitimate;
  • image loading happens regardless of the location of the alleged image, i.e., the form and the image itself need not be located in the same host, not even in the same domain. While this is a very handy feature, it makes difficult to compartmentalize applications.

 

It is the fact that HTML content unrelated to the web application may refer components in the application, and the fact that the browser automatically composes a valid request towards the application, that allows such kind of attacks. As no standards are defined right now, there is no way to prohibit this behavior unless it is made impossible for the attacker to specify valid application URLs. This means that valid URLs must contain information related to the user session, which is supposedly not known to the attacker and therefore make the identification of such URLs impossible.

 

The problem might be even worse, since in integrated mail/browser environments simply displaying an email message containing the image would result in the execution of the request to the web application with the associated browser cookie.

 

Things may be obfuscated further, by referencing seemingly valid image URLs such as

where [attacker] is a site controlled by the attacker, and by utilizing a redirect mechanism on

 

Cookies are not the only example involved in this kind of vulnerability. Web applications whose session information is entirely supplied by the browser are vulnerable too. This includes applications relying on HTTP authentication mechanisms alone, since the authentication information is known by the browser and is sent

automatically upon each request. This DOES NOT include form based authentication, which occurs just once and generates some form of session-related information (of course, in this case, such information is expressed simply as a cookie and can we fall back to one of the previous cases).

 

 

Sample scenario

Let’s suppose that the victim is logged on to a firewall web managementapplication. To log in, a user has to authenticate himself and session information is stored in a cookie.

Let’s suppose the firewall web management application has a function that allows an authenticated user to delete a rule specified by its positional number, or all the rules of the configuration if the user enters ‘*’ (quite a dangerous feature, but it will make the example more interesting). The delete page is shown next. Let’s

suppose that the form – for the sake of simplicity – issues a GET request, which will be of the form (to delete rule number one)(to delete all rules).

The example is purposely quite naive, but shows in a simple way the dangers of CSRF.

 

 

Now, this is not the only possible scenario. The user might have accomplished the same results by manually submitting the URL or by following a link pointing, directly or via a redirection, to the above URL. Or, again, by accessing an HTML page with an embedded img tag pointing to the same URL.

 

In all of these cases, if the user is currently logged in the firewall management application, the request will succeed and will modify the configuration of the firewall. One can imagine attacks targeting sensitive applications and making automatic auction bids, money transfers, orders, changing the configuration of critical

software components, etc.

 

An interesting thing is that these vulnerabilities may be exercisedbehind a firewall; i.e., it is sufficient that the link being attacked be reachable by the victim (not directly by the attacker). In particular, it can be any Intranet web server; for example, the firewall management station mentioned before, which is unlikely to be exposed to the Internet.

 

Self-vulnerable applications, i.e., applications that are used both as attack vector and target (such as web mail applications), make things worse.

If such an application is vulnerable, the user is obviously logged in when he reads a message containing a CSRF attack, that can target the web mail application and have it perform actions such as deleting messages, sending messages appearing as sent by the user, etc.

 

 

 

How to Test:

Black Box Testing

For a black box test the tester must know URLs in the restricted

(authenticated) area. If they possess valid credentials, they

can assume both roles – the attacker and the victim. In this case,

testers know the URLs to be tested just by browsing around the

application.

Otherwise, if testers don’t have valid credentials available, they

have to organize a real attack, and so induce a legitimate, logged

in user into following an appropriate link. This may involve a substantial

level of social engineering.

Either way, a test case can be constructed as follows:

  • let u the URL being tested; for example, u =

http://www.example.com/action

  • build an html page containing the http request referencing URL

u (specifying all relevant parameters; in the case of http GET this

is straightforward, while to a POST request you need to resort to

some Javascript);

  • make sure that the valid user is logged on the application;
  • induce him into following the link pointing to the URL to be

tested (social engineering involved if you cannot impersonate

the user yourself);

  • observe the result, i.e. check if the web server executed the

request.

 

 

Gray Box Testing

Audit the application to ascertain if its session management is

vulnerable. If session management relies only on client side values

(information available to the browser), then the application is

vulnerable. “Client side values” mean cookies and HTTP authentication

credentials (Basic Authentication and other forms of HTTP

authentication; not form-based authentication, which is an application-

level authentication). For an application to not be vulnerable,

it must include session-related information in the URL, in a

form of unidentifiable or unpredictable by the user ([3] uses the

term secret to refer to this piece of information).

Resources accessible via HTTP GET requests are easily vulnerable,

though POST requests can be automated via Javascript and are

vulnerable as well; therefore, the use of POST alone is not enough

to correct the occurrence of CSRF vulnerabilities.

 

 

Tools

Category:OWASP_WebScarab_Project

Category:OWASP_CSRFTester_Project

site_request_forgery.php (via img)

site_framing.php (via iframe)

Remediation

 

 

 

 

The following countermeasures are divided among recommendations to users and to developers.

 

Users

Since CSRF vulnerabilities are reportedly widespread, it is recommended

to follow best practices to mitigate risk. Some mitigating

actions are:

  • Logoff immediately after using a web application
  • Do not allow the browser to save username/passwords, and do

not allow sites to “remember” the log in details.

  • Do not use the same browser to access sensitive applications

and to surf freely the Internet; if it is necessary to do both things

at the same machine, do them with separate browsers.

Integrated HTML-enabled mail/browser, newsreader/browser

environments pose additional risks since simply viewing a mail

message or a news message might lead to the execution of an

attack.

 

 

Developers

Add session-related information to the URL. What makes the

attack possible is the fact that the session is uniquely identified

by the cookie, which is automatically sent by the browser. Having

other session-specific information being generated at the URL

level makes it difficult to the attacker to know the structure of

URLs to attack.

Other countermeasures, while they do not resolve the issue, contribute

to make it harder to exploit:

  • Use POST instead of GET. While POST requests may be simulated

by means of JavaScript, they make it more complex to mount an

attack.

  • The same is true with intermediate confirmation pages (such as:

“Are you sure you really want to do this?” type of pages).

They can be bypassed by an attacker, although they will make

their work a bit more complex. Therefore, do not rely solely on

these measures to protect your application.

  • Automatic log out mechanisms somewhat mitigate the

exposure to these vulnerabilities, though it ultimately depends

on the context (a user who works all day long on a vulnerable

web banking application is obviously more at risk than a user

who uses the same application occasionally).

 

 

 

Description of CSRF Vulnerabilities -

See the OWASP article on CSRF Vulnerabilities.

How to Avoid CSRF Vulnerabilities -

See the OWASP Development Guide article on how to Avoid

CSRF Vulnerabilities.

How to Review Code for CSRF Vulnerabilities -

See the OWASP Code Review Guide article on how to Review

Code for CSRF Vulnerabilities.

How to Prevent CSRF Vulnerabilites -

See the OWASP CSRF Prevention Cheat Sheet for prevention

measures.

 

 

 

 

 

 

In this example we will be using Burp’s CSRF PoC generator to help us hijack a user's account by changing their details (the email address associated with the account) on an old, vulnerable version of “GETBOO”.

The version of “GETBOO” we are using is taken from OWASP’s Broken Web Application Project. Find out how to download, install and use this project.

 

 

 

Burp Scanner is able to locate potential CSRF issues.

The Scanner identifies a number of conditions, including when an application relies solely on HTTP cookies to identify the user, that result in a request being vulnerable to CSRF.

 

 

To manually test for CSRF vulnerabilities, first, ensure that Burp is correctly configured with your browser.

 

In the Burp Proxy "Intercept" tab, ensure "Intercept is off".

Visit the web application you are testing in your browser.

 

Ensure you are authenticated to the web application you are testing.

 

In this example by logging in to the application.

You can log in using the credentials user:user.

 

Access the page you are testing.

Alter the value in the field/s you wish to change, in this case “Email”.

 

In this example we will add a number to the email.

 

Return to Burp.

 

In the Proxy "Intercept" tab, ensure "Intercept is on".

Submit the request so that it is captured by Burp.

 

In the "Proxy" tab, right click on the raw request to bring up the context menu.

 

Go to the “Engagement tools” options and click “Generate CSRF PoC”.

 

Note: You can also generate CSRF PoC's via the context menu in any location where HTTP requests are shown, such as the site map or Proxy history.

 

 

In the "CSRF PoC generator" window you should alter the value of the user supplied input.

 

In this example we will change to "newemail@malicious.com".

 

In the same window, click “Copy HTML”.

 

Open a text editor and paste the copied HTML.

 

Save the file as a HTML file.

 

In the Proxy "Intercept" tab, ensure "Intercept is off".

 

If necessary, log back in to the application.

 

Initially we will test the attack on the same account.

 

Open the HTML file in the same browser.

 

Dependent on the CSRF PoC options you may need to submit the request or it may be submitted automatically.

 

 

In this case we are submitting the request manually.

 

If the attack has been successful and the account information has been successfully changed, this serves as an initial check to verify whether the attack is plausible.

Now login to the application using a different account (in this example the admin account for the application).

 

Once you are logged in, perform the attack again by opening the file in the same browser.

The attack is successful if the account information in the web application has been altered.

 

A successful attack shows that the web application is vulnerable to CSRF.

For the attack to fire in a real world environment, the victim needs to access a page under the attacker's control while authenticated.

 

In our example web application, a new password can be set for the account using the email address. In this way an attacker could gain full ownership 

 

 

 

 

Generate CSRF PoC:

This function can be used to generate a proof-of-concept (PoC) cross-site request forgery (CSRF) attack for a given request.

To access this function, select a URL or HTTP request anywhere within Burp, and choose "Generate CSRF PoC" within "Engagement tools" in the context menu.

When you execute this function, Burp shows the full request you selected in the top panel, and the generated CSRF HTML in the lower panel. The HTML uses a form and/or JavaScript to generate the required request in the browser.

You can edit the request manually, and click the "Regenerate" button to regenerate the CSRF HTML based on the updated request.

You can test the effectiveness of the generated PoC in your browser, using the "Test in browser" button. When you select this option, Burp gives you a unique URL that you can paste into your browser (configured to use the current instance of Burp as its proxy). The resulting browser request is served by Burp with the currently displayed HTML, and you can then determine whether the PoC is effective by monitoring the resulting request(s) that are made through the Proxy.

Some points should be noted regarding CSRF techniques:

  • The cross-domain XmlHttpRequest (XHR) technique only works on modern HTML5-capable browsers that support cross-origin resource sharing (CORS). The technique has been tested on current versions of Firefox, Internet Explorer and Chrome. The browser must have JavaScript enabled. Note that with this technique, the application's response is not processed by the browser in the normal way, so it is not suitable for making cross-domain requests to deliver reflected cross-site scripting (XSS) attacks. Cross-domain XHR is subject to various restrictions which may prevent it from working with some request features. Burp will display a warning in the CSRF PoC generator if this is liable to occur.
  • Some requests have bodies (e.g. XML or JSON) that can only be generated using either a form with plain text encoding, or a cross-domain XHR. In the former case, the resulting request will include the header "Content-Type: text/plain". In the latter case, the request can include any Content-Type header, but will only qualify as a "simple" cross-domain request (and so avoid the need for a pre-flight request which typically breaks the attack) if the Content-Type header has one of the standard values that may be specified for normal HTML forms. In some cases, although the message body exactly matches that required for the attack request, the application may reject the request due to an unexpected Content-Type header. Such CSRF-like conditions might not be practically exploitable. Burp will display a warning in the CSRF PoC generator if this is liable to occur.
  • If you manually select a CSRF technique that cannot be used to produce the required request, Burp will generate a best effort at a PoC and will display a warning.
  • If the CSRF PoC generator is using plain text encoding, then the request body must contain an equals character in order for Burp to generate an HTML form which results in that exact body. If the original request does not contain an equals character, then you may be able to introduce one into a suitable position in the request, without affecting the server's processing of it.

CSRF PoC options

The following options are available:

  • CSRF technique - This option lets you specify the type of CSRF technique to use in the HTML that generates the CSRF request. The "Auto" option is generally preferred, and causes Burp to select the most appropriate technique capable of generating the required request.
  • Include auto-submit script - Using this option causes Burp to include a script in the HTML that causes a JavaScript-enabled browser to automatically issue the CSRF request when the page is loaded.

 

From <https://portswigger.net/burp/documentation/desktop/functions/generate-csrf-poc>

Recent high profile cyber attacks demonstrate that cyber incidents can significantly affect capital and earnings. Cyber incidents can have financial, operational, legal, and reputational impact. Costs may include forensic investigations, public relations campaigns, legal fees, consumer credit monitoring, and technology changes. As such, cybersecurity needs to be integrated as part of enterprise-wide governance processes.

 

With the increasing volume and sophistication of cyber threats and incidents, the Federal Financial Institutions Examination Council (FFIEC) developed the Cybersecurity Assessment Tool to help financial institutions identify their cyber risks and determine their level of cybersecurity preparedness. This assessment tool incorporates cybersecurity-related principles from the FFIEC's Information Technology Examination Handbook and maps back to the National Institute of Standards and Technology (NIST) Cybersecurity Framework.  The FFIEC developed this framework to help identify factors that contribute to your organization's cyber risks.  By understanding the factors that play into your organization's cyber risk, you can assess your level of preparedness and determine what risk management practices and controls are needed to mitigate and minimize your cyber risks.

 

The RSA Archer FFIEC-Aligned Cybersecurity Framework app-pack aligns with the FFIEC and NIST standards to provide a consistent and repeatable process for determining your organization's inherent risk levels and evaluating your cybersecurity maturity level. Using RSA Archer FFIEC-Aligned Cybersecurity Framework, action plans can be created and tracked to minimize inherent risk levels or achieve a desired cybersecurity maturity level.

 

With the RSA Archer FFIEC-Aligned Cybersecurity Framework offering, financial institutions can assess and measure their cybersecurity posture, address gaps, and report on cybersecurity posture in a meaningful way that is understood by all stakeholders.  

 

RSA Archer FFIEC-Aligned Cybersecurity Framework allows you to:

  • Offer a common language to communicate requirements and progress among stakeholders (internal, partners, contractors, suppliers)
  • Provide a method to understand larger cybersecurity ecosystem
  • Apply FFIEC best practices of risk management to improve cybersecurity and resiliency of critical infrastructure

 

Interested in learning more about the RSA Archer FFIEC-Aligned Cybersecurity Framework app-pack? Join us for a Free Friday Tech Huddle on Friday, March 8 for a live demo. Free Friday Tech Huddles are only available to RSA Archer customers. If you are not yet a customer but you are interested in learning more, please contact your local representative or authorized reseller—or visit us at www.rsa.com.

 

What is Operational Risk?

The Risk Management Association defines operational risk as “the risk of loss resulting from inadequate or failed internal processes, people, and systems, or from external events.” Examples of operational risk include natural and man-made disasters, cyber-attacks, errors, fraud, and regulatory or contractual non-compliance.

 

Why is Key Indicator Management so important?

The use of key indicators of performance, risk, and control are considered one of several best practices of a sound Operational Risk Management program.  In many risk management programs, the use of key indicators is implemented sporadically at the discretion of individual business units and division managers. Key indicator metrics may not be properly designed to accurately measure the intended activity, and the collection of indicator data may be accomplished in an unnecessarily costly and inefficient manner using spreadsheets and email. With missing or inefficient key indicator reporting, the organization is unable to accurately gauge or compare performance in terms of meeting strategic and operational goals, or understand drivers of risk and control. It also limits the organization’s ability to respond to emerging problems as quickly as possible.

 

RSA Archer Key Indicator Management

RSA Archer Key Indicator Management provides a means for organizations to establish and monitor metrics related to each business unit and activity within the organization.  Key indicators are also typically associated with other elements of your governance program, including risks, controls, strategies and objectives, products and services, and business processes to monitor quality assurance and performance.

 

Key features include:

  • Holistic key indicator management program
  • Association of key indicators with business units and named individuals, and establishment of key indicators of performance, risk, control, corporate objectives, business processes, and products and services, depending on your program implementation
  • Utilization of key indicator libraries to ensure consistency and quick deployment throughout the organization
  • Governance to ensure timely collection of indicator data
  • Stakeholder notification when indicators exceed acceptable boundaries
  • Consistent approach to calculating indicator boundaries and limits
  • Consolidated list of indicators that are operating outside boundaries, and associated stakeholder escalation and remediation plans
  • Accountability and management processes around remediation plans and action to bring key indicators back within acceptable boundaries
  • Visibility to key risk indicator metrics and remediation plans via predefined reports, dashboards, workflow, and communication channels.

 

Today, organizations are faced with complex and fast moving operational risk challenges.  To effectively manage risk, it’s not enough to know your organization’s strategies, objectives, risks and controls.  You need a way to understand if your strategies and objectives are being met; if your risk drivers are increasing or decreasing; and whether your controls are operating as designed or are under stress leading to failure. Tracking your key indicators, the Performance, Risk, and Control indicators associated with each of these elements is crucial in successful organizations today.  In addition, indicators associated with changing business activities are a good early warning of changing risk and performance profile. 

 

RSA Archer Key Indicator Management is an essential element of an effective Operational and Integrated Risk Management program to understand the organization’s risk and performance profile and operation of the existing internal control framework.  Stressing the agility and flexibility needed by today’s modern organizations, integrated risk management brings together the various domains of risk across business activities (horizontally), connecting the activities to the strategies and objectives of the organization on an aggregated basis (vertically), including these key indicators. This approach to risk management provides leaders with the most holistic understanding of risk facing their organization so they can make truly informed decisions, as quickly as possible, about where to deploy limited capital and human resources to produce optimized returns for the organization while maximizing the likelihood of achieving the organization’s objectives.

 

As your organization drives business growth, your risk management program must evolve and manage risk more holistically, with more agility and integration than before. Effectively deploying and utilizing Key Indicator management is one ingredient to demonstrating real progress and improvement in decreasing business risk.  RSA Archer can help your organization better understand and manage key indicators on one configurable, integrated software platform. With RSA Archer solutions, organizations can efficiently implement risk management processes using industry standards and best practices and significantly improve their business risk management maturity.

 

For more information, visit RSA.com or read the Datasheet.

 

 

 

Filter Blog

By date: By tag: