How will I go about conducting an investigation in the cloud?
Just wondering!
Where will I start?
Do I need to start from the suspects system?
What will I be looking for in it?
Please, I need suggestions
Where will I start?
Do I need to start from the suspects system?
What will I be looking for in it?
Please, I need suggestions
It depends what you are interested in, the application running in the cloud,
a computer running the application as part of the cloud network or the complete cloud itself. It also depends on the cloud architecture, the cloud provider and the application provider what kind of data is available and waht part of the data is useful for the forensic investigation.
Regards
Martin Pfeilsticker
How will I go about conducting an investigation in the cloud?
The term "cloud" is a catchall term for all sorts of hosted services and applications. There is no one single "cloud" architecture and, in fact, the term is fairly useless insofar as forensics is concerned because it is not specific to a particular architecture. For example, software as a service (SaaS), platform as a service (PaaS), hosted applications and managed services, can all be implemented as "clouds" though they are very different things.
Cloud implementations may include creating virtual servers with processing distributed among many machines. It may involve "sharding" where individual rows in a database may be located on different systems than other rows.
There are also legal issues with respect to what part of the "cloud" belongs to the owner of the data and what part belongs to the service hosting the data. In the instance where you have peering between service providers, there can be issues related to who can legally consent to an examination.
And, of course, there is the issue of the applicability of the Stored Communcations Act to cloud computing services, at least in the US, and there are probably EU privacy issues as well.
In other words, how you would approach a cloud forensics job depends upon
* the architecture of the implementation
* the contractual relationship between the owner of the data and the contractor
* the contractual relationship between the contractor and peers or subcontractors
* the applicable laws in those jurisdictions where the data are actually hosted
There is no one way and no simple answer to your question.
I think it would be easier to help give direction on a subject so broad as this if you revealed more information about what you are looking for. For example, perhaps what you need is information about spreadsheets created, modified, and stored within Google Documents. Even that small amount of information would be easier to address than "How do I perform an acquisition and analysis of data in a cloud?" And, as has been stated, there are jurisdictional issues that might come to thwart you, especially if that data is stored by an entity that is in no way beholden to divulge it or how it was created or modified.
It would also be helpful to those who might guide you if you described how the user interacted with this entity - was there a client-side application, did the user access things via a web browser, was the content created solely on the user's machine and later uploaded, etc.
How will I go about conducting an investigation in the cloud?
Just wondering!
It largely depends on the cloud implementation. With some cloud implementations, data could actually be in China. In others…such as Terremark's…that's not the case at all.
Read this article in the latest Forensic Magazine.
The digital link is reproduced below.
http//
Hope it helps…..
-=Art=-
I would suggest that many of the issues raised in the article are indeed issues, but only to the uninitiated…
Although cloud computing might appear attractive to a business, it is not without its own unique problems and concerns. Accessing a remote server to initiate an application via the Internet presents several obvious security risks.
Yes, it does…but those concerns are no different from maintaining the server yourself. In fact, my experience as an incident responder shows that there are many organizations who do not have the knowledge or staffing to support managing servers that are accessed remotely…these are very often the avenue of compromise.
However, moving your servers into the cloud (depending upon the implementation) may mean that you're moving them into an infrastructure that has a well-established security infrastructure, complete with a well-staffed SOC, instrumentation and visibility in to the network and systems, as well as policies and procedures…all of those things that many organizations do not have.
Storage of sensitive corporate data on a remote server raises concerns regarding the privacy and accessibility of that data by an unauthorized second party.
No more so that if the systems were maintained in the corporate infrastructure…in fact, depending on the cloud vendor chosen, I would suggest that the concern would be even less, once controls have been validated.
The business or customer is not generally aware of the physical location of the data.
In some, yes. In others, no. Not at all. With some providers, your data may be in China. With others, if the IP address of the server takes you to the data center in Miami, FL, or Culpeper, VA, that's where your data will be…and data center staff know down to the rack, server, and hard drive where your data is located.
Likewise, they may not be able to discern what policies/procedures are in place to recover data should a server crash or become compromised. Legal and regulatory requirements and compliances may be lacking in the location(s) where the data is actually stored.
This is an age-old issue in businesses, and not something that will be overcome anytime soon…if you are "not able to discern" any of those things…DON'T purchase the services! If the locations where the data is stored are not in compliance, DO NOT purchase the services!
I can't tell you the number of times I've seen applications running on NT 4.0 SP 6 (not 6a, just 6) because someone sat down with a vendor, and the vendor said that upgrading the OS would have a negative impact on the application. This is extremely poor planning, and should be part of the natural selection of both vendors and their customers. If a vendor uses that as a business model, then the market should decide if they survive as a business. The same should be true for any who purchase their services.
The same applies to this issue…if you purchase "cloud" from a vendor and do not validate their compliance as it relates to your compliance and requirements, then shame on you for not doing your due diligence.
I agree that, like in many other articles related to digital forensics, often what appears in print is grossly oversimplified or even distorted by people who either aren't truly knowledgeable or use imprecise language.
On the other hand, while Harlan is correct that many of the potential issues can be mitigated by spelling out the terms in the contract or service agreement, in my professional experience, businesses don't always think about that in advance.
For example, I was involved with a very well known company that outsourced its call center to Asia in order to save money. It was only after there was a threat of legal action that we discovered that in attempting to save a few bucks, the company failed to specify a number of conditions which were minimally prudent with respect to protecting the integrity of their information. Put simply, they were going to save a lot of money so they weren't really interested in anything that would drive up the cost.
That, I fear, is the biggest concern with respect to "cloud" computing. Most of the service level agreements are being draw up by the cloud providers rather than the consumer. And while some customers are involving legal and technical teams in the formulation of these agreements with an eye toward their potential liability for preservation and discovery of ESI, not everyone looking to save costs can afford this kind of due diligence and some who can, may elect not to do so for financial reasons.
I suspect that some of this will be sorted out through court actions whereby the courts help to define the responsibilities of customers of these services to be in compliance with the various Rules of Evidence.
On the other hand, while Harlan is correct that many of the potential issues can be mitigated by spelling out the terms in the contract or service agreement, in my professional experience, businesses don't always think about that in advance.
I'm not sure I follow regarding the use of "on the other hand" here, as I was essentially saying the same thing you are. In fact, it's pretty clear that we're in full agreement.
That, I fear, is the biggest concern with respect to "cloud" computing. Most of the service level agreements are being draw up by the cloud providers rather than the consumer.
More importantly, I'm seeing that consumers of services don't know what they need and require ahead of time, but rather, go for lowest initial cost as a measure of "value". I saw this in the military, as well…examples abound. However, the point is that when purchasing products or services, one has to take into account their own requirements.
For example, trying to create something that's PCI compliant based on PoS devices that are not PCI compliant, and not understanding what constitutes a compensating control, will ultimately be a more expensive solution than paying the additional upfront $$ for PCI-compliant PoS devices.
If a "cloud" provider tells you what you need and writes up the SLA with no consideration for your requirements, or will not validate that they meet your requirements, vote with your feet. Walk away.
Like I said before, there are some "clouds" that you can buy into in which your data may end up on a server in China. There are others where that is simply impossible and will not happen.