Can you create a HIPAA compliant Amazon S3 Web Application? - browser

I am facing some questions when trying to design an S3 application using ASP.NET MVC and trying to stay HIPAA compliant.
My initial plan was to require an SSL connection to my web server, encrypt the images on my server, then send them to s3 using my private keys.
Here's my obvious concerns:
You cannot store unencrypted images in any temporary file cache when client views images within the browser.
Even if I setup an ashx to generically handle the image in memory, couldn't this get stored in cache?
Saying the images will be encrypted because you will be connecting to my server via https still does not guarantee all browsers will not cache data.
It's not possible to even consider the "Query String" with expiration option since data will be encrypted before being stored on disk at s3, and will again be decrypted at my server in memory.
I think my only option would be to write/purchase some sort of ActiveX component that will not expose the image as a simple html image source or write my app as a client side WinForm application.

On the face of it, it seems unlikely that cloud computing could be HIPAA compliant. Surely it is impossible to satisfy the Security Rule when the instance is hosted on someone else's hardware, tended by someone else's sysadmins?
However, Amazon have published a whitepaper on this very topic: Creating HIPAA-compliant Medical Data Applications with AWS. It is well-worth reading, and seems to address the main concerns. It does end with a disclaimer:
"This white paper is not intended to
constitute legal advice. You are
advised to seek the advice of counsel
regarding compliance with HIPAA and
other laws that may be applicable to
you and your business."
Naturally the same applies to any advice you get from some random bloke off Das Interwebs.

Contrary to some of the other answers, cloud computing and cloud data storage can in fact be HIPAA compliant (note that they were written in 2010, when this was a much tougher call).
There are two main things you should consider for this:
you must get the cloud provider to sign a HIPAA Business Associate Agreement (BAA)
you must adhere closely to the Security Rule in the development of your system (encryption, audit trails, etc.)
Here are some cloud providers that will sign BAA's:
Amazon Web Services
Rackspace
Windows Azure (as of July 2012)
(Up until recently, Amazon wasn't willing to sign a BAA, so even though they had a whitepaper on compliance, following their guidelines just didn't cut it - all that has changed, though).
For image storage, AWS has S3 and Azure has blob storage.
As far as your concerns about serving the images in the browser, I'm actually not sure how strict you have to be, but it seems like you could embed your images within:
a Java Virtual Machine (JVM)
Flash
Flex
HTML5
It looks like PracticeFusion started off using Flex & Flash and is in the process of gradually transitioning to HTML5.

The HIPAA and the credit card PCI compliance are basically impossible to implement, or trivial - it all depends on what consultant you hire to tell you what the meaning of a 'closed' network is - is that mathematically closed (which I would argue is the highest form), or is that closed as in behind a wall and not connected to the outside world, but trivially easy to eavesdrop with some basic equipment on the sidewalk outside?
When you get done with consultants, the fact that much computer equipment is leased, the fact that computers have usb ports and their users camera phones, how could storing encrypted data anywhere be a problem? If you store encrypted data on S3, then S3 is not storing ANYTHING other than random bits of garbage. Some key owned by you + the garbage = data and that only happens in your system.
I have seen 'HIPAA compliant' software that runs with no encryption on a PC with XP on it. Considering how many laptops are owned by botnets and keystroke loggers, the whole thing is an basically an exercise in deniability.
The HIPAA rules explicitly state that data does not have to be encrypted when its sitting on your users computer:
"Information systems housing PHI must be protected from intrusion. When information flows over open networks, some form of encryption must be utilized. If closed systems/networks are utilized, existing access controls are considered sufficient and encryption is optional."

A couple comments. Images served via https are not always stored in the browser cache. Even so, you can control this using headers.
When you upload an image you can stream it into memory and directly into a database using your favorite encryption technique. When the user requests a page with a url to an encrypted image, you simply call your controller, grab the encrypted data from the database, decrypt it in memory and return the image.
[AcceptVerbs(HttpVerbs.Get)]
public ActionResult ShowImage(string id)
{
ImageEntity image = Repository.For<ImageEntity>().Where(a => a.AssetIdd == id).First();
var decryptedImage = Decrypt(image);
ImageResult result = new ImageResult(decryptedImage.ImageData, decryptedImage.ContentType);
return result;
}
You use it like this:
<img src="/Assets/ShowImage/<%=Model.Id%>" alt="" />

No. HIPAA compliance is impossible due to the conflict between the network encryption requirement and the network monitoring requirement.

Related

Is it possible to find the origin of a request in nestjs? [duplicate]

Is there any way to restrict post requests to my REST API only to requests coming from my own mobile app binary? This app will be distributed on Google Play and the Apple App Store so it should be implied that someone will have access to its binary and try to reverse engineer it.
I was thinking something involving the app signatures, since every published app must be signed somehow, but I can't figure out how to do it in a secure way. Maybe a combination of getting the app signature, plus time-based hashes, plus app-generated key pairs and the good old security though obscurity?
I'm looking for something as fail proof as possible. The reason why is because I need to deliver data to the app based on data gathered by the phone sensors, and if people can pose as my own app and send data to my api that wasn't processed by my own algorithms, it defeats its purpose.
I'm open to any effective solution, no matter how complicated. Tin foil hat solutions are greatly appreciated.
Any credentials that are stored in the app can be exposed by the user. In the case of Android, they can completely decompile your app and easily retrieve them.
If the connection to the server does not utilize SSL, they can be easily sniffed off the network.
Seriously, anybody who wants the credentials will get them, so don't worry about concealing them. In essence, you have a public API.
There are some pitfalls and it takes extra time to manage a public API.
Many public APIs still track by IP address and implement tarpits to simply slow down requests from any IP address that seems to be abusing the system. This way, legitimate users from the same IP address can still carry on, albeit slower.
You have to be willing to shut off an IP address or IP address range despite the fact that you may be blocking innocent and upstanding users at the same time as the abusers. If your application is free, it may give you more freedom since there is no expected level of service and no contract, but you may want to guard yourself with a legal agreement.
In general, if your service is popular enough that someone wants to attack it, that's usually a good sign, so don't worry about it too much early on, but do stay ahead of it. You don't want the reason for your app's failure to be because users got tired of waiting on a slow server.
Your other option is to have the users register, so you can block by credentials rather than IP address when you spot abuse.
Yes, It's public
This app will be distributed on Google Play and the Apple App Store so it should be implied that someone will have access to its binary and try to reverse engineer it.
From the moment its on the stores it's public, therefore anything sensitive on the app binary must be considered as potentially compromised.
The Difference Between WHO and WHAT is Accessing the API Server
Before I dive into your problem I would like to first clear a misconception about who and what is accessing an API server. I wrote a series of articles around API and Mobile security, and in the article Why Does Your Mobile App Need An Api Key? you can read in detail the difference between who and what is accessing your API server, but I will extract here the main takes from it:
The what is the thing making the request to the API server. Is it really a genuine instance of your mobile app, or is it a bot, an automated script or an attacker manually poking around your API server with a tool like Postman?
The who is the user of the mobile app that we can authenticate, authorize and identify in several ways, like using OpenID Connect or OAUTH2 flows.
Think about the who as the user your API server will be able to Authenticate and Authorize access to the data, and think about the what as the software making that request in behalf of the user.
So if you are not using user authentication in the app, then you are left with trying to attest what is doing the request.
Mobile Apps should be as much dumb as possible
The reason why is because I need to deliver data to the app based on data gathered by the phone sensors, and if people can pose as my own app and send data to my api that wasn't processed by my own algorithms, it defeats its purpose.
It sounds to me that you are saying that you have algorithms running on the phone to process data from the device sensors and then send them to the API server. If so then you should reconsider this approach and instead just collect the sensor values and send them to the API server and have it running the algorithm.
As I said anything inside your app binary is public, because as yourself said, it can be reverse engineered:
should be implied that someone will have access to its binary and try to reverse engineer it.
Keeping the algorithms in the backend will allow you to not reveal your business logic, and at same time you may reject requests with sensor readings that do not make sense(if is possible to do). This also brings you the benefit of not having to release a new version of the app each time you tweak the algorithm or fix a bug in it.
Runtime attacks
I was thinking something involving the app signatures, since every published app must be signed somehow, but I can't figure out how to do it in a secure way.
Anything you do at runtime to protect the request you are about to send to your API can be reverse engineered with tools like Frida:
Inject your own scripts into black box processes. Hook any function, spy on crypto APIs or trace private application code, no source code needed. Edit, hit save, and instantly see the results. All without compilation steps or program restarts.
Your Suggested Solutions
Security is all about layers of defense, thus you should add as many as you can afford and required by law(e.g GDPR in Europe), therefore any of your purposed solutions are one more layer the attacker needs to bypass, and depending on is skill-set and time is willing to spent on your mobile app it may prevent them to go any further, but in the end all of them can be bypassed.
Maybe a combination of getting the app signature, plus time-based hashes, plus app-generated key pairs and the good old security though obscurity?
Even when you use key pairs stored in the hardware trusted execution environment, all an attacker needs to do is to use an instrumentation framework to hook in the function of your code that uses the keys in order to extract or manipulate the parameters and return values of the function.
Android Hardware-backed Keystore
The availability of a trusted execution environment in a system on a chip (SoC) offers an opportunity for Android devices to provide hardware-backed, strong security services to the Android OS, to platform services, and even to third-party apps.
While it can be defeated I still recommend you to use it, because not all hackers have the skill set or are willing to spend the time on it, and I would recommend you to read this series of articles about Mobile API Security Techniques to learn about some complementary/similar techniques to the ones you described. This articles will teach you how API Keys, User Access Tokens, HMAC and TLS Pinning can be used to protect the API and how they can be bypassed.
Possible Better Solutions
Nowadays I see developers using Android SafetyNet to attest what is doing the request to the API server, but they fail to understand it's not intended to attest that the mobile app is what is doing the request, instead it's intended to attest the integrity of the device, and I go in more detail on my answer to the question Android equivalent of ios devicecheck. So should I use it? Yes you should, because it is one more layer of defense, that in this case tells you that your mobile app is not installed in a rooted device, unless SafetyNet has been bypassed.
Is there any way to restrict post requests to my REST API only to requests coming from my own mobile app binary?
You can allow the API server to have an high degree of confidence that is indeed accepting requests only from your genuine app binary by implementing the Mobile App Attestation concept, and I describe it in more detail on this answer I gave to the question How to secure an API REST for mobile app?, specially the sections Securing the API Server and A Possible Better Solution.
Do you want to go the Extra Mile?
In any response to a security question I always like to reference the excellent work from the OWASP foundation.
For APIS
OWASP API Security Top 10
The OWASP API Security Project seeks to provide value to software developers and security assessors by underscoring the potential risks in insecure APIs, and illustrating how these risks may be mitigated. In order to facilitate this goal, the OWASP API Security Project will create and maintain a Top 10 API Security Risks document, as well as a documentation portal for best practices when creating or assessing APIs.
For Mobile Apps
OWASP Mobile Security Project - Top 10 risks
The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.
OWASP - Mobile Security Testing Guide:
The Mobile Security Testing Guide (MSTG) is a comprehensive manual for mobile app security development, testing and reverse engineering.
No. You're publishing a service with a public interface and your app will presumably only communicate via this REST API. Anything that your app can send, anyone else can send also. This means that the only way to secure access would be to authenticate in some way, i.e. keep a secret. However, you are also publishing your apps. This means that any secret in your app is essentially being given out also. You can't have it both ways; you can't expect to both give out your secret and keep it secret.
Though this is an old post, I thought I should share the updates from Google in this regard.
You can actually ensure that your Android application is calling the API using the SafetyNet mobile attestation APIs. This adds a little overhead on the network calls and prevents your application from running in a rooted device.
I found nothing similar like SafetyNet for iOS. Hence in my case, I checked the device configuration first in my login API and took different measures for Android and iOS. In case of iOS, I decided to keep a shared secret key between the server and the application. As the iOS applications are a little bit difficult to reversed engineered, I think this extra key checking adds some protection.
Of course, in both cases, you need to communicate over HTTPS.
As the other answers and comments imply, you cant truly restrict API access to only your app but you can take different measures to reduce the attempts. I believe the best solution is to make requests to your API (from native code of course) with a custom header like "App-Version-Key" (this key will be decided at compile time) and make your server check for this key to decide if it should accept or reject. Also when using this method you SHOULD use HTTPS/SSL as this will reduce the risk of people seeing your key by viewing the request on the network.
Regarding Cordova/Phonegap apps, I will be creating a plugin to do the above mentioned method. I will update this comment when its complete.
there is nothing much you can do. cause when you let some one in they can call your APIs. the most you can do is as below:
since you want only and only your application (with a specific package name and signature) calls your APIs, you can get the signature key of your apk pragmatically and send is to sever in every API call and if thats ok you response to the request. (or you can have a token API that your app calls it every beginning of the app and then use that token for other APIs - though token must be invalidated after some hours of not working with)
then you need to proguard your code so no one sees what you are sending and how you encrypt them. if you do a good encrypt decompiling will be so hard to do.
even signature of apk can be mocked in some hard ways but its the best you can do.
Someone have looked at Firebase App Check ?
https://firebase.google.com/docs/app-check
Is there any way to restrict post requests to my REST API only to requests coming from my own mobile app binary?
I'm not sure if there is an absolute solution.
But, you can reduce unwanted requests.
Use an App Check:
The "Firebase App Check" can be used cross-platform (https://firebase.google.com/docs/app-check) - credit to #Xande-Rasta-Moura
iOS: https://developer.apple.com/documentation/devicecheck
Android: https://android-developers.googleblog.com/2013/01/verifying-back-end-calls-from-android.html
Use BasicAuth (for API requests)
Allow a user-agent header for mobile devices only (for API requests)
Use a robots.txt file to reduce bots
User-agent: *
Disallow: /

How to persuade one that cloud platform is safe enough?

I am a co-founder of a startup company. We are not doing things of computer science or programming. We're making our own product. As a result, My partner and I use some cloud platform service, for instance, Google Drive, Slack, Facebook Messenger, and Google Hangout, to support us. We use them to share files of our development. The problem is that my partner is not a person who studies computer science or has enough background of information security. So he always hesitating to use those services to share important files. For example, with Slack, we can share code snippet in our team channels, but he think we should encrypt our code file to avoid any information leakage. I think encryption will lose the convenience feature to use such service. How do I convince my partner that he doesn't need to worry about the safety issue to share code or file on cloud platform services?
This is a very open-ended question, primarily because we don't know your partner.
Essentially, irrespective of how safe your platform is, it's only as safe as the hosts machine is—gain access to that and all the files are still compromised anyway.
Most of the day-to-day work can be done through the platforms mentioned however extremely sensitive files (e.g. server keys) should be passed physically through a data storage device (e.g. pendrive).
If you are geographical apart, you can transfer sensitive documents using PGP instead. For messenging you could use something such as Telegram or Signal.

How safe are "secret" keys in Windows 8 (WinJs) apps?

I'm doing a hobby project Windows 8 app in WinJS. As I'm calling an external api, which requires an api key and oauth authentication, I've got a number of keys that I need to keep "secret".
I've seen places around the web with detailed descriptions on how to get access to and also modify the source code for WinJs (and C#) apps on your computer. But I think those were in the beta/preview time frame?
My Google skills don't seem to be able to tell me if this has been fixed since, does anyone know?
If it wasn't fixed, how do people handle these situations?
Any tips and suggestions welcome :)
You have a couple options here.
Integrate Azure Mobile Services and have it do the oAuth if possible. Your keys remain secret in the cloud.
Store the main key encrypted in your WinJs application. The secret then is also encrypted and stored locally. I use https://github.com/cauld/winjs-oauth-for-twitter and have a slight revision that when I get the key back I store it in the credential manager.
Any local application compiled from any computer language can be tampered with, all you need is a debugger. If you encrypt everything I in theory can just load up a debugger, attach to the http stack library and watch the data go out (excluding even easier techniques like Fiddler to watch this data) and extract whatever I want - fairly easily. So the question is what are you trying to prevent?
If your app could be facilitated to launch a man-in-the-middle attack, you should not keep confidential data in plain form for a long time, in memory or on disk. Also, storing encrypted data locally, alongside with the algorithm and the algorithm key/hash is a recipe for security incidents.
There is no silver bullet to protect your code or data from probing by the end user (or someone who has physical access to the end user's machine), see the amount of game save editors and game trainers out there. Don't put your business logic or important data (e.g. in-app purchases) in plain text or similar, at least add some obfuscation

Considerations regarding a p2p social network

While the are many social networks in the wild, most rely on data stored on a central site owned by a third party.
I'd like to build a solution, where data remains local on member's systems. Think of the project as an address book, which automagically updates contact's data as soon a a contact changes its coordinates. This base idea might get extended later on...
Updates will be transferred using public/private key cryptography using a central host. The sole role of the host is to be a store and forward intermediate. Private keys remain private on each member's system.
If two client are both online and a p2p connection could be established, the clients could transfer data telegrams without the central host.
Thus, sender and receiver will be the only parties which are able create authentic messages.
Questions:
Do exist certain protocols which I should adopt?
Are there any security concerns I should keep in mind?
Do exist certain services which should be integrated or used somehow?
More technically:
Use e.g. Amazon or Google provided services?
Or better use a raw web-server? If yes: Why?
Which algorithm and key length should be used?
UPDATE-1
I googled my own question title and found this academic project developed 2008/09: http://www.lifesocial.org/.
The solution you are describing sounds remarkably like email, with encrypted messages as the payload, and an application rather than a human being creating the messages.
It doesn't really sound like "p2p" - in most P2P protocols, the only requirement for central servers is discovery - you're using store & forward.
As a quick proof of concept, I'd set up an email server, and build an application that sends emails to addresses registered on that server, encrypted using PGP - the tooling and libraries are available, so you should be able to get that up and running in days, rather than weeks. In my experience, building a throw-away PoC for this kind of question is a great way of sifting out the nugget of my idea.
The second issue is that the nature of a social network is that it's a network. Your design may require you to store more than the data of the two direct contacts - you may also have to store their friends, or at least the public interactions those friends have had.
This may not be part of your plan, but if it is, you need to think it through early on - you may end up having to transmit the entire social graph to each participant for local storage, which creates a scalability problem....
The paper about Safebook might be interesting for you.
Also you could take a look at other distributed OSN and see what they are doing.
None of the federated networks mentioned on http://en.wikipedia.org/wiki/Distributed_social_network is actually distributed. What Stefan intends to do is indeed new and was only explored by some proprietary folks.
I've been thinking about the same concept for the last two years. I've finally decided to give it a try using Python.
I've spent the better part of last night and this morning writing a sockets communication script & server. I also plan to remove the central server from the equation as it's just plain cumbersome and there's no point to it when all the members could keep copies of their friend's keys.
Each profile could be accessed via a hashed string of someone's public key. My social network relies on nodes and pods. Pods are computers which have their ports open to the network. They help with relaying traffic as most firewalls block incoming socket requests. Nodes store information and share it with other nodes. Each node will get a directory of active pods which may be used to relay their traffic.
The PeerSoN project looks like something you might be interested in: http://www.peerson.net/index.shtml
They have done a lot of research and the papers are available on their site.
Some thoughts about it:
protocols to use: you could think exactly on P2P programs and their design
security concerns: privacy. Take a great care to not open doors: a whole system can get compromised 'cause you have opened some door.
services: you could integrate with the regular social networks through their APIs
People will have to install a program in their computers and remeber to open it everytime, like any P2P client. Leaving everything on a web-server has a smaller footprint / necessity of user action.
Somehow you'll need a centralized server to manage the searches. You can't just broadcast the internet to find friends. Or you'll have to rely uppon email requests to add somenone, and to do that you'll need to know the email in advance.
The fewer friends /contacts use your program, the fewer ones will want to use it, since it won't have contact information available.
I see that your server will be a store and forward, so the update problem is solved.

Service for storing PCI sensitive data

I'm building a web application that handles sensitive PCI data (banking numbers, CC, SSNs, etc). Does anyone know of the best services out there to handle this data. I've looked into Rackspace and their PCI solution seems a little overkill for what I need as I mainly just need the database secured and there are really only a few pages that need to be compliant and won't receive a relatively large amount of traffic.
Note: A lot of the webpages don't require this data and receive higher load volume and I am planning on hosting these pages on the cloud.
I think you are looking for a tokenization service. A google search brings up plenty of alternatives.

Resources