Skip to main content

Integrity in the Cloud

All communication, SSH and HTTP(s) using HTTP Signature, is verified as accurate/legitimate.
For all data I upload to my CSP, I can attach a signature (MAC) to verify if the contents have changed.
For all data I upload to my CSP, I am sure it will be the same in the future.
To have mutual auditability, I now want to expand that list to include the following:
For all data I upload to my CSP, I can ensure I have the latest revision of my data. Currently, this can’t happen without much work on either the customer's or the CSP's end.
I can ensure I am charged the correct amount for data at rest and data in motion by my CSP. 
but what about data fingerprints on my data?

Keyless Signature (KS) is a system based on the building blocks of MACs, high resolution timestamping, hash chains and hash trees. KS provides: proof of integrity, proof of time and proof of signing authority. It is considered keyless as it is based entirely on formal methods of hash functions and not cryptographic keys; essentially, key management is thrown out of the window as it's not needed.

The best part of KSI is that by the nature of the technology data is tamper-evident, signatures never expire, and it can be used by the user, the CSP and an arbitrary 3rd party (i.e. auditor) to verify both the order of events and that the event hasn't been altered.

So if a CSP has  technology integrated into their APIs and portions of their subsystems like storage, then not only will each data object have its own signature, but all future revisions of the data will have it as well, ensuring the order of operations (ie., that this rev came before this rev). So now we have #1 - #4 accomplished, how about #5? To accomplish #5, a CSP will have to extend KSI into every piece of their architecture.

Let’s say that as a CSP, I have incorporated Guardtime into my hypervisor rsyslog and BSM. I can tell that every log event and every event that is audited via BSM occured in the order that they were logged, that they actually occured (no tampering), and who performed the event. I also built all APIs to use Guardtime to log all events (either directly using node-guardtime or using rsyslog). What does that get me?

I now have a system where every event (CSP administrative or user) is independently verifiable by the CSP, the user and any 3rd party. I can show these events to the user at anytime to prove to them we did X, they did Y and at any point where there’s disagreement, we can go to any 3rd party arbitrator for verification. Also, as a CSP, I can now provide all account details for user with 100% certainty, which eliminates over and under charging by the CSP by providing the most accurate billing information.

Mutual auditability was thought to be an unattainable goal just a few years ago. Today, we are closer than ever to realizing it. In previous incarnations of mutual auditability in Cloud Computing, there was a DARPA project based on Attribution-based Architectures where each entity of the system could not forge their actions to provide a near leak proof system. The details of the system were not widely published. However, in the public cloud age, such a system didn't exist, until now. When you combine the latest rsyslog, BSM, and Guardtime, the public cloud provides a higher level of security than anything that can be done in-house.

Comments

Post a Comment

Popular posts from this blog

Real-Time Talk: Windows 10 IoT Core Background Tasks and ASP.NET Core Web Apps

Display useful information from your Windows 10 IoT Core application in an ASP.NET Core web app, essential for integrating IoT data into a solution. Windows 10 IoT background task talk with a web application using WebSockets. Problems As my path to this solution has been troublesome, I am listing here the main problems I faced so my dear readers have a better idea of dead-end streets along the way: I was not able to make the ASP.NET Core web application run under a Windows 10 IoT background service. I found no information about when or if it will be supported in the near future. ASP.NET MVC and ASP.NET Core have different SignalR implementations. I was not able to make a SignalR client for .NET Core work with SignalR hosted on a web application. I was able to make things work by directly using a WebSocket. It’s not as nice a solution as I had in my mind, but it works until things get better. Making the Background Task and Web Application Talk I worked out sim...
Post a Comment
Read more

Python and Parquet Performance

In Pandas, PyArrow, fastparquet, AWS Data Wrangler, PySpark and Dask. This post outlines how to use all common Python libraries to read and write Parquet format while taking advantage of  columnar storage ,  columnar compression  and  data partitioning . Used together, these three optimizations can dramatically accelerate I/O for your Python applications compared to CSV, JSON, HDF or other row-based formats. Parquet makes applications possible that are simply impossible using a text format like JSON or CSV. Introduction I have recently gotten more familiar with how to work with  Parquet  datasets across the six major tools used to read and write from Parquet in the Python ecosystem:  Pandas ,  PyArrow ,  fastparquet ,  AWS Data Wrangler ,  PySpark  and  Dask . My work of late in algorithmic trading involves switching between these tools a lot and as I said I often mix up the APIs. I use Pandas and PyArrow for in-RAM comput...
Post a Comment
Read more

DANGER (STILL) LURKS IN THE INTERNET OF THINGS (IOT)

All of the media, both “mainstream” and “tech”, has gushed over all of the new appliances and devices that are now in the category of what we would call the Internet of Things.  Items like home security,  home lighting, and refrigerators, to name a few. There are many advantages to having connected appliances and devices, Threats that can and will be exploited if unsuspecting users don’t secure them.   Two “layers” of security : The first layer of offering  is a security API that will provide [a way] to easily do a virtual patch, to prevent a remote attack, for example . . . the third layer is cloud: IoT cannot do anything without the cloud.  Most data is sent to the cloud and you will need to have proper protection and make sure the cloud is always available. In both situation Users are vulnerable, mostly due to their own apathy.  Users often either don’t know how to patch their own machines (and in this case, devices) or have glanced...
Post a Comment
Read more