HIPAA defines a broad set of rules to govern how health care providers and related covered entities share and protect patient data. While the scope of HIPAA is far broader than an ethical hacking specialist is concerned, vulnerability assessments are often a vital component of HIPAA compliance. With that said, ethical hackers do not need to be experts on the entire HIPAA regulations, but there are some things they should be aware of.
One of the primary concerns during a vulnerability assessment for a HIPAA covered entity is the transmission and storage of ePHI (electronic Protected Health Information). There are 18 specific items that are considered ePHI:
Application vulnerability assessments evaluate sensitive information which may be disclosed to unauthorized parties, however, a good security consultant will always understand that “sensitive” is highly subjective. In the case of a HIPAA covered entity, the above 18 items should all be considered sensitive. Leakage of any data included in the above list can have serious consequences for the covered entity in question. HIPAA violations can have significant financial penalties, so never assume something ever so slightly sensitive is ok to disclose. What may normally be considered a Low Risk information disclosure issue to another industry, can sometimes be a High Risk issue to a HIPAA covered entity.
HIPAA does not get into the specifics or technical nature of vulnerability assessments. The HIPAA security rule simply mandates that covered entities “[c]onduct an accurate and
thorough assessment of the potential risks and vulnerabilities to the
confidentiality, integrity, and availability of electronic protected health
information held by the covered entity.”
In other words, if you have an application handling ePHI, you need to perform a vulnerability assessment against it. But being so vague is both good and bad. Application vulnerability assessments are highly subjective assessments and risks depend greatly on the business logic used. This is an important freedom to allow security experts to get the job done the right way. This allows the security tester to focus on the actual risk rather than a checklist which may not actually reflect a real life attack scenario.
On the other hand, it may allow for misguided decisions to be made about how risk should be identified. Healthcare is an industry that’s no stranger to products with exaggerated or false claims. There is no shortage of software companies who are ready to sell something that may lead organization to believe they are doing their due diligence in identifying risk.
As with any assessment, an ethical hacker is often the last line of defense in protecting against a breach; and a critical aspect of our job as ethical hackers is to protect the people who use these applications. We must not forget the level of sensitivity of data used by HIPAA covered entities and their applications. Special consideration should be given to handling of EMR/EHR records which contain detailed records of medical conditions and history.
Successful business operation is the ultimate goal of any security assessment. While electronic health records are relatively new, healthcare technology has greatly improved the care that individuals receive. Vulnerability assessments can be difficult, but it’s a fact of life that security testing must coincide with application deployment. By keeping both of these requirements in mind we can stay secure and keep moving forward.
For more information on Virtue Security services please see our vulnerability assessment datasheet.
Application vulnerability assessments are a vital part of a security process for any organization deploying online applications. Vulnerability assessments identify critical threats, sensitive information leakage, and a wide array of other security issues. While the discovery of these vulnerabilities is the most immediate value returned from an assessment, there are several other commonly missed benefits from them. If performing multiple engagements, an even greater opportunity is provided for organizations to build better long term security practices. Below are several things to keep in mind after performing an assessment:
As vulnerability assessments are conducted across multiple applications within an organization, a clear picture is often painted of areas in which need improvement. While vulnerabilities are often remediated with quick patches to insecure code, by putting slightly more effort into a long term solution an even larger benefit can be gained. This is a great opportunity to take the remediation and build it into the development process. Instead of creating many small code patches, build the patches into trusted frameworks which can be reused by many applications.
If issues of Cross-site Scripting (XSS) are a recurring problem, development teams should take the time to build proper input validation into request handling functions. This will ensure input is properly validated across the application, and that these controls are reused across the organization, rather than a few isolated areas.
A CISO looking at recurring XSS issues may wish to meet with lead developers and discuss long term solutions to input validation coding practices. Remember that each issue has a cost, both in terms of a security tester finding and reporting it, and the developers remediating the issue. Over multiple years, multiple applications, and multiple vulnerability assessments, the cost of issues can be compounded greatly.
Low Risk vulnerabilities are often not remediated if a significant cost associated with it. While threat prioritization is a necessity, Virtue Security strongly recommends Low Risk issues be remediated within 90 to 180 calendar days. While these issues often disclose only minimally sensitive information, it’s important to keep in mind this is still useful to an attacker. If an attacker were to discover every low risk item across an organization, chances are high that they will have an easier time carrying out other attacks against the organization.
Even small amounts of internal knowledge, can be used as strong leverage when carrying out social engineering attacks. An attacker can gain a lot of credibility if he or she is able to ask specific questions regarding internal systems or software. Additionally, some low issues have compounding risk; the existence of some low risk issues can increase the exploitability of higher risk issues.
To some, vulnerability assessments may be like a trip to the dentist; not everyone wants to go through an audit, but they exist to help. They may be conducted as part of a PCI, HIPAA, or regulatory audit, but it’s important that they ultimately exist to benefit the organization. Performing assessments with the only goal of maintaining compliance is not a sustainable practice. It’s also important to realize that compliance is only a short term goal, and only doing the minimum to meet these goals is a recipe for disaster.
Working with vendors to ensure the scope of assessments is properly defined is also critical for a thorough assessment. Ensuring test dates are fair and reasonable and start on time will only benefit the organization. Attempting to squeeze assessments into shortened time frames should be avoided if possible.
Large organizations should use multiple vendors; keeping a competitive atmosphere can deter a vendor from complacency and ensure engagements are performed with diligence. While some organizations perform direct simultaneous comparative tests between two vendors, this can result in assessments double in price. Organizations wishing to save money but still validate another vendor’s findings may wish to alternate applications between vendors on an annual or biannual basis. Over time, a weak security vendor may become apparent. Do consider that ethical hacking changes quickly, and additional issues should be expected to be discovered after one year’s time.
Application vulnerability assessments are one of the most cost effective ways to identify weaknesses in application business logic. By coordinating long term plans with development teams, even greater value can be obtained. To keep a steady value, work with vendors to make sure testing scope reflects real world attack scenarios and ensure testers have reasonable timeframes to complete testing. Thinking in terms of long term solutions often has far greater rewards than simply maintaining short term compliance. Avoiding a breach is the ultimate goal of just about everything we do, if we keep this in mind and properly manage short term goals, we will all be better off.
For more information on how you can get the most out of your next application vulnerability assessment, contact Virtue Security founder Elliott Frantz at email@example.com
Numeric parameters are control variables that drive almost every web application. As ethical hackers, modifying these numbers is one of the most basic but also most important tasks we perform. During a vulnerability assessment, parameters are modified thousands of times in different ways to test the security controls of a web application. Over the years, one of these ways has remained the most common and prevalent way to bypass access restrictions of an application: incrementing or decrementing numbers.
One of the most common places we see parameters we wish to modify are in simple GET requests:
Because this type of testing is such a repetitive task, we will talk for a moment on efficiency. While we normally use a proxy to intercept, modify, and send parameters to the server, we can modify these faster and easier than that. Because we encounter examples of this on almost every assessment, saving one or two seconds per test case is a valuable benefit. For this we turn to a small Firefox utility called URL Flipper. With this small add-on we can use Ctrl-Shift-Up or Ctrl-Shift-Down hotkeys to quickly “flip” through many parameters as well as view the output rendered in the browser.
As shown above, we used this to quickly flip through 10 or 20 “quantity” values. While in this example is useful for relatively small increments, it won’t serve us well for all test cases.
Incrementing numbers may often require us to search a far greater span of numbers than is feasible by this method. For very large groups of numbers where we may be searching for account numbers, profile IDs, etc, we can use a more powerful automated assistant. Burp intruder provides one of the most powerful scripted search and replace functions available to ethical hackers.
Here we use Burp intruder to specify a position (the ‘quantity’ parameter), and we will then set a type of payload. Below shows the payload configuration where we specify ‘Numbers’ as the payload type, and configure the range of values we wish to search for.
This is an extremely powerful way for us to search a larger set of parameters. But as we scan a larger range, making sense of the results becomes increasingly difficult. We don’t have the time to manually examine 200 or even 2000 results, so we will examine differentiation. Sorting by response length is an easy way to look for pages that might be different than the others. While this example does not show us a result set where we can sort for anything of value, sorting will be required in most real life testing. Burp also has a filter where we can search by string, regex, or response code.
There are many situations where application arithmetic can be abused to bypass business logic. One classic financial example is using fractions of cents. Imagine we have a money transfer function that transfers money from one account to another, how can we be sure the application properly handles all decimal values? What if an application ignored the values past the second decimal, but the database still honored the transaction? To test this we will replay the function several hundred times and compare the amounts in both accounts to what they were previously. Below shows an example of a request where such an attack might be feasible:
We can feed this again to Intruder to replay this. Instead of ‘numbers’ as a payload we will use ‘null payloads’:
These techniques can be applied to real attacks on the vast majority of web applications. And now that we have the technical methods covered, we can focus again on the logical attacks. When reviewing an application, we must constantly be aware of the function we are performing, and what control variables we possess. Are we viewing an order? Do we control an order ID parameter? Are we transferring money? Do we control the source account ID? This is what we must determine for every secure function within an application.
Another way we can sometimes subvert application arithmetic is by attempting to overflow stored integer values. We must remember that not all systems may treat integers the same. A front end Java application may handle the number 2,147,483,648 without any problem, while this same number may overflow a 32 bit signed integer on a backend system; this number may now be represented as a negative value.
In summary, below are four key areas to look for when the user controls numeric values used by the application:
While this is not a complete checklist for testing these parameters, it is something testers should keep in mind. Every application is unique and has a highly subjective threat model. In ethical hacking assessments, performing a thorough analysis of the functionality and then developing custom attacks must always be the first priority.
Want to go to AppSec USA for FREE? We are giving away a FULL conference pass to AppSec USA this week in New York City. This is open to all security professionals, so please send us your linkedin if you win. The winner will be announced on our twitter tomorrow November 19th at 12pm EDT.
Step 1: Retweet the contest announcement
Can be found at: https://twitter.com/VirtueSecurity
Step 2: Tweet us your best bad joke
We love bad jokes, but we also like technical jokes as well. Be creative and good luck! We will grab an open mic at the conference and read the best jokes received.
Ethical hackers should be well versed in Node when testing such an application. While traditional web application attack vectors remain the same, there are several critical caveats every pen-tester should be aware of. More information about NodeJS can be found at the project website: http://nodejs.org/ A great place to begin Node application security is the Node Security Project.
Professional ethical hackers should understand the full implications of CSP. While some may wish to recommend the use of such policies as part of a vulnerability assessment, it should at least be understood by those conducting a vulnerability assessment. In addition to CSP, HSTS and X-Frame-Options should also be given strong consideration.
NoSQL databases are simple and fast data stores which remove traditional constraints of relational databases. This less structured model favors speed and scalability over complex relational models. As a result NoSQL has flourished in big data industries but still growing in smaller applications. NoSQL provides little in terms of security at the database level and relies greatly on security at the application level.
HTML5 extensions are under active development and introduce a constant expansion of security concerns. Even the core HTML5 specifications which include extensions such as local storage, websockets, and CORS, are not always well understood by security professionals. At the time of this writing, many popular security tools still do not yet support interaction with websockets. This leaves a strong possibility that vulnerabilities nested within these technologies may go undiscovered by novice security testers. Ethical hackers must devote significant time to research these technologies and understand the full range of security implications each one requires.
A list of some draft extensions can be found at the following URL: http://www.w3.org/html/wg/wiki/ExtensionSpecifications
Large organizations with applications that face intense public exposure may benefit from running a bug bounty program. These programs reward independent security researchers for finding vulnerabilities on an individual basis. By offering a reward for each vulnerability found, they create a much greater incentive to responsibly disclose vulnerabilities rather than exploiting them for profit. These programs have already seen great success with large organizations such as Google, Twitter, Facebook, and now Yahoo!
One new company, Bugcrowd, has brought this testing model to companies which may not have the resources to handle such programs themselves. This type of security testing model can be difficult to manage and may incur significant false positives from less skilled ethical hackers. By providing vulnerability verification and payment services, Bugcrowd allows much smaller organizations to benefit from this type of testing.